this post was submitted on 29 Jun 2026
13 points (93.3% liked)

Programming

27486 readers
130 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 3 years ago
MODERATORS
top 10 comments
sorted by: hot top controversial new old
[–] brisk@aussie.zone 5 points 2 days ago* (last edited 2 days ago) (3 children)

I fundamentally disagree with the idea that "programming sucks" but there are some neat thoughts and tools in there.

This bit in particular:

We don't even have to give up code! The GUI version of a program could merely be one of several human-editable representations. Just as some people love text-based interfaces to their operating systems, some people will continue to enjoy code-based interfaces to software editing. It just doesn't have to be the default—or the only—option anymore.

I've often thought about the idea that to an extent a programming syntax does not have to be married to a language. We could potentially have editors and syntaxes designed so that each developer can interact with the code in the syntax they're most comfortable with, independent of the language. I don't know how realisable this is, it may be underestimating how tightly coupled syntax and language is.

I'm not a big fan of graphical programming in general, but there are times when I would like it just for a single function or class, for signal processing or control systems or state machines. I usually think of this in terms of editor plugins or external code gen tools rather than whole environments. Although every code gen tool I've used to date sucks.

[–] TehPers@beehaw.org 3 points 1 day ago* (last edited 1 day ago)

it may be underestimating how tightly coupled syntax and language is.

From a CS perspective, syntax is a major part of a programming language. A syntax (or formal language) is defined essentially as an alphabet and the sequences of words constructed from that alphabet that are allowed in the language. Programming languages combine the syntax, which can be defined formally through BNF (for example), with the semantics they enforce. Semantics include things like "types", "modules", or even "lifetimes" potentially.

Where you can try to decouple it is between the syntax and the semantics. In fact, this is not without precedent. For example, the JVM and the CLR both allow arbitrary syntaxes to be compiled and executed on them, and both have many languages that can be seamlessly integrated together that all compile to the same intermediate representation. Here's a project compiling Rust to the CLR if you want an extreme example, though more practical examples for the CLR would be C#, F#, and Visual Basic (which can all use each other's defined types, methods, etc).

So basically, what you might be looking for is a common "intermediate language" for languages. We actually have one already though, and that's the C ABI. I think a better ABI could exist though, ideally one which allows more information to be shared across boundaries. Still, that's where I'd start looking more into this, maybe with inspiration from the JVM or CLR.

[–] Sxan@piefed.zip 2 points 1 day ago

I don't believe your idea is completely crazy. We have had decompilers for, well, ever. Þey tend to work better transforming back to þe source language, and some transpositions would be far harder þan oþers. Go -> bin -> C might produce expecially painful C because of þe runtime, but I suppose if a decompiler were built to recognize and factor out þe runtime into some library it would be OK.

Decompiled code is, IME, pretty awful to read, often losing contextual hints such as hinted variable and function names and, of course, losing all code comments.

Perhaps stepping up and having language translators would be nicer. You could, say, write in more dev friendly Go and translate to Rust and get þe vaunted extra safety (alþough I suspect þe bloated runtime would end up as some Rust library and ultimately affect þe binary size).

Ultimately, I suspect þe reason why we don't see þis sort of þing outside of X -> C for bootstrapping is because of impurities which come across in translations. Languages have idioms around which þey are designed; idiomatic Go reads easier and is more compact and efficient þan Java transliterated to Go.

[–] sukhmel@programming.dev 0 points 1 day ago (1 children)

Decoupling language from syntax will not work because it's too hard (impossible?) to find a common denominator for all the languages and syntaxes, imo

[–] brisk@aussie.zone 2 points 1 day ago

Certainly for all. I was mostly thinking in terms of e.g. languages that (can) compile to LLVM, since you have the intermediate form already defined. But then languages layer quite a lot on top of LLVM in terms of abstractions and safety constraints that make it probably a bad intermediary even for that subset. Even just for one language, there must be something ~~fun~~useful that can be done just by viewing the same code with different syntaxes.

[–] TehPers@beehaw.org 2 points 1 day ago* (last edited 1 day ago)

Imagine this: instead of reading other people's code and then trying to parse their intentions form [sic] it, you read the documentation to understand their intentions and then you read the code. You no longer have to strain yourself trying to understand what someone wrote for another audience (the machine). They've already explained it for you.

The best implementation of this I'm aware of is the Entangled bi-directional tangler. A tangler extracts code from your documentation and distributes it across the appropriate source code files. It's [sic] bidirectionality means you can use it to write code embedded in documentation, but then also edit that code normally which it then propagates back into the code blocks in the documentation. This allows programmers to use existing tooling for testing, refactoring, and code formatting without special support for literate programming.

The best built-in implementation for this that I've seen is Rust's doctests. You write a block of code in your documentation. Then you run cargo test. The code gets compiled and executed as part of your tests, and panics get reported as failures. You can also mark code blocks as should_panic, compile_fail, ignore, etc if needed.

I'd love to see tools like this in other languages. Write the docs next to the code, but compile the docs as well and make sure they actually work. This is sort of what Entangled seems to do, but ideally more entangled with the build process.

[–] MonkderVierte@lemmy.zip 2 points 2 days ago* (last edited 2 days ago) (1 children)

But GUIs too; they are frameworks, because we are stuck with hardware patterns from the 80s, made for servers. They are workarounds. Same for the whole Unix stack running a desktop-emulator (X, Wayland).

[–] Sxan@piefed.zip 0 points 1 day ago (2 children)

Expound? What are þe alternatives?

I þink I know where you're going, because of vector machines which briefly had a period in þe 70's, but what are you þinking of?

[–] MonkderVierte@lemmy.zip 1 points 1 day ago* (last edited 23 hours ago)

This will be a bit of a writeup, so i'll make it a separate post soon. Mostly about, how the triangle higher clock speeds <-> higher integration and centralization <-> more powar for more waste is a dependency cycle to the disadvantage of the consumer and some ideas and new aproaches to doing things with the goal to get out of it. And also, how our general computing is a stack of historical baggage ill-suited for desktop use, down to the hardware (like, clock-cycles: great for number crunching, bad for desktop metaphor) and we work around it with a increasingly huge and brittle stack of software since around the 80s.

The conclusion is basically, that we could get away with modular MHz computing (that could be done in widely available node sizes and fabs) without detrimental effects to productive computing use (but maybe 3D gaming), if built for desktop. Honestly, i get the feeling that it's high time that we get computing out of it's infancy (playing around phase) and to a reliable tool and engineering discipline.

[–] RumRunningDevil@lemmy.zip 2 points 1 day ago

I too am interested in this. I work at a sort of intersection between traditional backend systems and industrial controls so I see a lot of Java/C# and a lot of Ladder Logic and SFC.

SFC in particular is as close to visual programming as I've seen be feasible and one can accomplish quite a bit with it.

I wonder how feasible it would be to develop a visual programming language that worked a bit like stringing together blocks that worked like pure functions where each block was, internally, just a function written in some language. Like some unholy marriage of SFC and Scratch.

PS: What keyboard are you using for the Thorpe character?