If you're interested in languages like this, often called "High-Level Assemblers", you might be interested in L.in.oleum[0], a portable assembler designed to aid the creation of a sequel to the game Noctis IV, or Octo[1], a purpose-built HLA I designed targeting the Chip8 virtual game console.
The idea of conforming a language specification directly to the constraints of a platform is highly idealistic, of course, but nevertheless one which has a lot of contemporaneous applicability. Yet, the vogue appears to be more inclined towards abstraction. Here, we see the abstract in its most naked form: the owner of the hardware is the same as the owner of the software. They are the first user.
So this is quite a poignant item for the HN crowd. Do we need more, or less, of this sort of thing? Methinks, more.. but it may be knee-jerk borne from a few decades of jade.
I'd say not idealistic at all, it's an entirely practical thing. Early LISPs were coded directly to the instruction set and register widths of the 36 bit IBMs they were written on. BCPL and B were likewise untyped languages with the "word and pointer are the same thing" assumption baked in. Fortran and the IEEE floating point standard evolved in lockstep, etc...
I've only got a very small value of "few" to jump into this argument, but let me provide a (slightly hyperbolic) counterpoint: electrical engineers often are crap programmers.
Don't get me wrong, some of the best programmers I've worked with graduated with an EE degree, but they were working as programmers. If you're not, than matters concerning programming require a context switch that often isn't fully made, resulting in a slightly messed up mindset that usually doesn't produce the most optimal results.
This is similar to programmers doing UI/UX, which most of the time doesn't even result in a good UI for programmers, let alone mortal users.
Not saying that this was the case here, though. When you've got some serious hardware constraints, it's easy enough to lowball your ambitions, even though theoretically something more generic could be made. Not every team has a Niklaus Wirth in it.
platforms are transitory - portability is still the oracle worth worshiping at. Look at the folks who ported Version 7 Unix to x86 - 35-40 year old code, running on a new platform.
I often wonder about how much programmers of my generation are missing out on because of our relative lack of understanding of the full stack of software and hardware. Many of my peers have never written C code outside of school and largely expect to only work in high level scripting languages like Python or Ruby.
I think you're definitely missing out a bit if you don't know anything about low-level stuff. If you've never programmed in C or something like it. I'm a compiler writer, ant it seems to me people who have only ever used high-level programming languages have pretty poor intuitions about the cost of the language features they use.
This being said, I think there there are many more programmers today than there were in the 1980s. So while there is a smaller proportion of programmers doing low-level stuff, there are still many programmers with low-level work experience. I'm doing a PhD in compiler design and I've been approached by several major companies. I think I've been approached 8 or 9 times now. There is still quite a bit of demand for low-level expertise. Low-level coding isn't going to disappear, and luckily for us, the internet allows us to archive all of this knowledge like never before.
I'm sorry, I thought that term died a long time ago. What exactly is a scripting language to you and how is it different than whatever you may call a "normal" programming language?
Basically perl, Python, sh/bash, and so on. Not C or C++. (Well, there's '#!/usr/local/bin/tcc -run' [1] which can do C but, you know, that's the exception to the rule.) Moar here: [2]
That's insane. Perl and Python are both general purpose programming languages. This reminds me of the days Java developers used to call Ruby developers "script kiddies."
So if C and C++ are the only true programming languages, we're all just script kiddies? :/
No. I didn't say anyone was a "script kiddie." I merely stated that the manner in which Perl and Python function is different than the manner in which C and C++ function and that's enough of a difference that they belong in two categories of languages: 'scripting languages' (which are not compiled to assembly and typically require an interpreter) and 'compiled languages' (which can be compiled to assembly and typically do not require an interpreter.) Nor did I say Perl and Python aren't suitable for general purpose tasks. If you think 'using a scripting language' is the same as 'being a script kiddie,' then you're just wrong. [I don't know enough of how Java or Ruby function to say which category they belong in.]
I recall somebody (can't recall who or when) gave this definition: a scripting language is one where most of the work gets done by invoking programs written in a different language. So sh and bash (etc.) are definitely scripting languages, Python (etc.) can be used as scripting languages, even if that isn't their typical use.
This is actually a bit closer to hardware archaeology, i.e. reverse engineering the decade's old HD20 hard drive. But of course hardware has tons of software built into it, and even more so these days.
[0]http://en.wikipedia.org/wiki/Linoleum_(programming_language) [1]https://github.com/JohnEarnest/Octo