News for hackers. Stuff that matters.
Re:Writing that changed how I think about programming languages by RetroTechie on Wednesday May 14, 2025 @09:57AM (#43984618)
>The point of Mr. Ousterhout’s argument is that there are only two choices:

Ultimately, it all compiles down to assembly (which is executed), or an interpreter (which is executed). Assembly all the way. The real choice here is: turn into assembly ahead of time (programmer's code becomes assembly), or do so at runtime (assembly interprets programmer's code). Or some in-between like JIT compilation. And: what guardrails you put in place.

So you could say that higher-level languages are just a way to make tedious/nasty assembly coding more palatable. Eg. by producing error reports vs. just crashing a machine. Or provide a sandbox. Or provide a model of computation that fits well with programmer's thinking.

Between those, you simply need some useful abstractions. Preferably ones that are simple yet versatile/universal.

Eg. a (bitmap) "screen" could just be a flat memory space (framebuffer). Or a 2-D array of pixels, potentially with "pixel" defined elsewhere.

Programmer doesn't care how GPU is coerced into displaying those pixels, low-level code doesn't care what higher-level software does to produce them.

And then have as few as those abstractions as possible (but no less!). Tcl: "everything is a string". Lisp: "everything is a list". Unix(-like): "everything is a file". Etc.

Personally, I have a soft spot for languages that punch above their weight for expressiveness / few but useful abstractions vs. their implementation size. Things like Forth, Tcl or Lua come to mind.

But hey that's just me. Developers & organisations they're in make their own choices.

Re:Writing that changed how I think about programming languages by sph on Wednesday May 14, 2025 @12:20PM (#43986328)
> So you could say that higher-level languages are just a way to make tedious/nasty assembly coding more palatable.

Well, the point of scripting languages is mostly dynamic typing and dynamic binding, which means resolving bindings at runtime, which means slower in execution. There is no silver bullet: you want speed, you need a clunky language that compiles to fast machine code. If you want ease of use and less ceremony, you’ll get a slower language.

Re:Writing that changed how I think about programming languages by static_void on Wednesday May 14, 2025 @02:16PM (#43987593)
Dynamic languages are definitely easier to use for highly dynamic problems.

They are not necessarily easier to use for statically-knowable problems.

Static languages get benefits in correctness and speed.

Key word is dynamic.

Re:Writing that changed how I think about programming languages by MaxBarraclough on Wednesday May 14, 2025 @04:45PM (#43989016)
> The real choice here is: turn into assembly ahead of time (programmer's code becomes assembly), or do so at runtime (assembly interprets programmer's code). Or some in-between like JIT compilation. And: what guardrails you put in place.

A language's preferred compilation/interpretation model is, roughly speaking, orthogonal to its type system and to whether it emphasises speed of development, correctness, or performance. Also, many languages can practically be implemented using various compilation/interpretation models. There are interpreters for C, for instance, and ahead-of-time machine-code compilers for Java.