[YouKnowBetter]

I cannot agree more. I started when a computer did not have an OS, let alone 1.000 applications.

You got dropped right into the interpreter. There was not already a GB of OS loaded that you had a hard time to learn. All the code that was there was what you wrote (copied) yourself.

The processor & interpreter was about as fast as you could think, so it was easy to follow and step though (mentally). Reversing to assembly was the logical next step and since the programs where small, it was easy to learn & memorize.

After years of coding yourself, you'd stumble on the first OS, which consisted of the most rudimentary libraries that one could basically read & remember.

Years later still, the first rudimentary networking picked up. Slow and not business critical so again easy to experiment with. By the time I connected the first commercial network to "the internet" downtime of email for less than 24 hours was not even noticed.

I do not envy the kids who nowadays stand 0 change to ever learn the complete stack of code running on any modern device. From what I see, they all are "stuck" on top of a GUI with only the slightest idea of what happens between their mouse and the actual hardware (and even that is often not hardware anymore).

[3rdAccount]

I haven't read it yet, but I think Nand2Tetris was meant to address this.

Petzold's CODE is also really good going from logic gates to microprocessors to assembly language.

I still wish you could buy something like a Pi board that has just an interpreter and compiler on it as well as a textbook and you implement a simple version of a file system, text utilities, task manager...etc.

[aerotwelve]

I find myself asking the same things when it comes to the lower-level software side of things. I find this area fascinating as well, but it's all so "invisible" in modern systems.

I graduated from a CS program (BS) a few years ago, and the projects I'm still most proud of existed "lower" in the stack: implementing FAT16, writing compilers/interpreters (I still have my Brainfuck interpreter!), playing around with paging in MULTICS, and the like.

These were all very toy-like (with good reason, a semester is only so long), but since I enjoyed them I've found myself asking things like "I wonder how the process scheduler/virtual memory manager/in OS X is handling [whatever I'm doing at the moment]? What does my stack look like right now? How are all of these threads communicating with each other, what are they saying?"

You can occasionally see this in the console when something is going wrong, but usually not when the system is operating normally. When the OS is handling a heavy load brilliantly, that's kind of when I'm most impressed, and therefore most interested.

(maybe this kind of procedural output would be dreadfully boring or unreadable due to the complexity of a modern system if I actually saw it, I don't actually know of course.)

[exikyut]

`perf top` on Linux, and doing a (really) deeeep dive on the perf and BPF APIs, may be of interest.

The possibly-incorrect impression I get of the performance-analysis related areas of the kernel is that they're a bit siloed (in the same way that X11 is siloed, and only a very small group of people look at it), which may render it bit functionally academic. (It's newer code, though, so there's less chance of eccentricity, FWIW.) Isolation does have benefits - with less chaos to keep up with and less bus factor, the code is changing less and the maintainers have more mental bandwidth to post on mailinglists :), so you have more opportunity to get a good understanding of what's going on.

I don't have the same low-level experience you do, but I do share the same interest in wanting to understand "what's really going on" - and I incidentally want to make a Linux system monitor tool that vacuums up as much information that the kernel is willing to make available to it. `htop` and friends surface a very caricatured picture from maybe 1-10% of the data the kernel has to offer at any given moment.

[pjc50]

One of the original concepts for the Pi was an Atmel-based system that booted into BASIC.

Unfortunately these days you can have simplicity or you can have a web browser but not both. And without a web browser a computer feels extremely limited.

[lisper]

Yeah, this. The simplicity of early computers came with a cost: they couldn't really do very much. You can recapture the essential parts of that simplicity today by, for example, firing up a Python interpreter, which is just as easy to learn as BASIC and much more capable. You can live inside a Python prompt for a very long time before you really start to hit the limits. (Or, even better IMHO, inside a Lisp prompt :-) But the fact of the matter is that the technology that makes modern web sites possible is complicated, and there is just no way around that.

[52-6F-62]

Re: Nand2tetris

I was going to reference the same thing. Particularly the text Elements of Computing Systems.

https://mitpress.mit.edu/books/elements-computing-systems

[exikyut]

Not sure what to make of it[s downloadability], but I found a PDF: https://archive.org/details/TheElementsOfComputingSystems_20...

[squarefoot]

This seems a nice and open platform to experiment with; strictly speaking not what you are looking for but can be tailored to the task: https://wiki.odroid.com/odroid_go/odroid_go To me it also looks like a great gift for tech oriented kids.

Many Espressif MCU boards come with Lua already installed, and some other boards are supported by eLua. https://github.com/whitecatboard/Lua-RTOS-ESP32 http://www.eluaproject.net/

[zenojevski]

It might not exactly be the same as operating real hardware, but I have tried to address this by creating a small VM that is simple to use, understand, and modify[1].

[1] https://latenightsnack.io

[earenndil]

Idk why would it have to be dedicated hardware that already has an interpreter/compiler on it. You could make your own mini-os. It's relatively simple to make something that boots in qemu, and once you've done...you can do anything!

[3rdAccount]

The point is to grok the entire system: Hardware, OS, compiler, interpreter...etc.

I think building a FORTH would be educational, but I've never seen a tutorial (including JonesForth) that can take you from zero to Forth. Everyone just says it is easy. Maybe it is more or less obvious with more Assembly background?

[exikyut]

Okay, here's an oddball answer: https://github.com/servo/skia/blob/master/forth/

Skia used to include a really simple Forth implementation written in C++. According to https://groups.google.com/forum/#!topic/skia-discuss/joAyAl1... it was intended for straightforward/simple scripting, and for some reason promptly got deleted shortly after being brought up.

[In case you haven't noticed yet, the official Skia repo is at /google/; I've linked to /servo/'s obviously-old copy above, but there are more than enough forks and clones for the code to be findable elsewhere too.]

I kind of like this implementation because it's both incredibly context-specific and generalized all at the same time, and it isn't Bare Metal Implementation #79,513. And it's C++, too, although this is not (overly) abused.

[mtreis86]

Check out Interim, http://dump.mntmn.com/interim-paper/

[codeulike]

I do not envy the kids who nowadays stand 0 change to ever learn the complete stack of code running on any modern device.

I also started back when things were simple (BBC B with interpreted BASIC, no GUI).

Having transitioned to modern development, I think the bare bones system was good for self-learning. But for the last 2 decades I've worked on systems where many layers were hidden from me (Windows, RDBMS, Salesforce etc) and most of the time it doesn't matter. I very rarely need to learn anything about low levels Windows stuff. With SQL Server you need to learn a bit about query plans and how to influence them, and where to put indexes. But mostly, you can ignore lower layers and just let them get on with what they do. And thats the whole point isn't it?

One huge exception to this is the modern web stack, if you think of the browser as the bare metal, with HTML and JS and CSS as some sort of machine code. On top of that you have Content Management systems and PHP and so so many JS frameworks. And whatever you do, soon enough you need to get down to the HTML/JS/CSS level. So thats the modern equivalent to our experience of the old days - no matter how many frameworks and CMSs we throw at the web, everyone still has to know their HTML/JS/CSS to get anywhere.

Perhaps one day we will escape from that and people will reminisce about angle brackets and escaping ampersands.

[Nursie]

> most of the time it doesn't matter.

It's true.

However to have an understanding of things from top to bottom is definitely a benefit. People get silo'd in their various layers and lack comprehension of much that's going on below (or above) them.

It can make you a more rounded developer, to have a good idea of the whole stack, even if it's not always in-depth and some of the mental models used aren't strictly true.

[codeulike]

Its a benefit, but whats the cost/benefit of the time it takes to learn that, vs maybe learning something else?

[Nursie]

As someone who's coded everything from web front ends to embedded systems with no OS and manual memory partitioning, via mainframes, network management tools and all sorts of other things, I'd say the benefit is pretty high!

Someone needs to know how it all works, someone needs to build the kernels, the low-level libraries, the compilers, network protocols server programs etc etc.

You can certainly have a great career without them, I wouldn't dispute that.

[linkmotif]

Yeah you’ll never step in the same water twice, but I was born in 85 and I don’t miss 90s hardware much, not even nostalgically. Do you miss 70s hardware? I mean in terms of what you can practically get out of it, not how nice the keys felt. Yeah I missed seeing and learning from a lot of advancement unfold, but progress has been massive and I do enjoy my computer-video-phone global communication device. What an amazing thing to have seen in a lifetime. As a kid I did not expect there to be videophones.

You’re right, my generation definitely missed a lot but I hope some day to work through NAND2Tetris. Furthermore, also I didn’t study CS, but a good CS/EE program would really take you through first steps. No matter what, you can’t keep a book from a scholar. There appear to be many resources to learn this stuff if one has the opportunity. Combine NAND2Tetris with the x86-64 assembly on Ubuntu book I saw here yesterday and you should be golden, right?

[Koshkin]

> Do you miss 70s hardware?

Yes; IBM System 360/370, for example, was a marvel of engineering and design, with a remarkable history [1]; so were the first microprocessors, such as MOS Technology's 6502 [2]. The best part was, you could know all of it, if you wanted, down to the transistor level - the geek's Holy Grail. With modern chips/systems you cannot any longer, not even with the Raspberry Pi.

I wish IBM's revolutionary architecture lived on in our PCs; good engineering pays off, and today's software could be more sane, as people would be learning from the giants rather than wasting time on a massive scale trying to reinvent the wheel.

[1] https://www.amazon.com/IBMs-Early-Systems-History-Computing/...

[2] http://visual6502.org/

[wiz21c]

Yeah, but the problem is that it takes time. Learning assembly takes time ('cos you need to understand the whole system at the level of machine code : bios calls, memory protections, interrupts, DMA, graphics cards, sound card, I/O,...). Then you have to go up a level into the OS stuff (hello file systems, processes, threading, paging). Then once you get that, you have to learn how a (extreme example) Java VM connects to all of that (welcome GC, optimization, compiler, byte code). then, ah finally, something one can easily understand : Java code :-)

(and don't even start me on WS/rest over HTTS over SSL over IP).

Learning stack by stack, one generation at a time, let us, old gray beards, digest the whole thing. But now, starting from scratch ? Not even with a 10 feet pole.

[linkmotif]

Yeah it’s not the same but it’s amazing starting from scratch at a new baseline. Every generation of humans has had to do that with everything.

I missed out on all the stuff you mentioned and really want to learn it, but I am grateful that I get to use all this stuff that’s developed. Instead of spending time learning the above listed fundamentals, which would have been revelatory in its own way, I have the opportunity to use Java on Kubernetes to build and operate globally whatever Internet software dream comes to mind. It’s not the end all, and I am crippled by lacking fundamentals, but it’s so much more than before and I am grateful to have the opportunity to have these tools.

[wiz21c]

Well, admitedly, I don't use all that knowledge at all times. Like many around, I'm super satisfied by being able to write a very complex SQL query knowing that : I won't be constrained by memory, I don't have to think about why the transaction will work, why my connection to the DB will work, how the SQL engine will optimize the damn thing. I just have to contemplate something that it almost business code and produces almost business results.

It's just that I have that warm, reassuring feeeling that if I have to dig down, I'll be able to. Too bad I almost never have to; abstraction works way too good :-)

I'm sure one can be a very good programmer not knowing the assembly stuff behind. And even myself, I don't know exatcly how a CPU works (I mean, I get the logic of it, but I wouldn't be able to make one from scratch) :-)

[dep_b]

Well the start of the '90s was still Amiga time, which was the biggest leap in home computing ever but that really happened in the 80's. Then it was followed by the dark ages of PC gaming catching up while people played on dumb consoles.

Around when the Voodoo cards came along (1996?) things got really interesting again. Also about any keyboard that shipped was decent still, Silicon Graphics and Macs (even the beige ones) were really nice looking but expensive machines. Had a SCSI drive hooked up to a PowerBook 1400, that was pretty much as cool as having an external Thunderbolt SSD now.

The ASUS P2B of course was amazingly stable for it's time, however if you had a dual Celeron 300A @450MHz you were really the king. Dial-up modems getting upgraded to T1 lines or cable modems. That was a huge speed boost.

So yes the 90's were nice, but just no comparison to what happened between '77 and '87 (the year the Amiga 500 got introduced).

[pjmlp]

The way I see many devs on Emacs and vim doing development is hardly any different than when I got to university in early 90's.

They might be using a modern laptop, but their screen is hardly different from those beige UNIX terminals with green phosphor screen and VT100 keyboard that I had to use the first couple of semesters.

[TeMPOraL]

Vim/Emacs are local maximas in terms of productive UX, they'll still be here in 20 years. What's different might be the amount of compute those environments control. A keychord or three can easily trigger a big rebuild on a computer somewhere in the network.

[pjmlp]

I disagree, for me the local maximas in terms of productive UX is the vision of XEROX PARC workstations, partially implemented on OS X/iOS, Android and Windows development workflows.

Even AT&T later moved into it with Plan 9 and Inferno, with ACME.

[TeMPOraL]

I did some amount of Android and Windows development; what particular pieces of the PARC vision do you have in mind?

[pjmlp]

IDE based development, GUI designers, REPLs, graphical debuggers, edit-and-continue, component based frameworks, structured data command line (PowerShell), apis to interact with GUI apps from devenv, dynamic configuration of running apps.

All to be found on Interlisp-D, Smalltalk, Mesa XDE, Mesa/Cedar environments.

[Koshkin]

> local maxima

Yes - local, very local.

[eesmith]

For a while I thought the same. Then I starting meeting more people from the generation before me, who complained about how the kids nowadays (meaning me and my generation) didn't really know how the machines worked. The kids only wrote code, but since they didn't build and maintain the hardware, they didn't grok the full stack.

And to be fair, they are right. There was a level of UART programming and video logic control that I never understood, because they required knowledge of analog circuitry that was beyond me.

As I grew older, I realize that every generation has people who that about the next one. Sure, car engines in my g'grandfather's day were so simple that anyone could take one apart and really learn how it works. But I prefer the benefits of modern engines.

BTW, the first real OSes were in the 1960s. I do not think you started with computers in the 1950s. And how is it that "all the code that was there was what you wrote (copied) yourself" when you were "dropped right into the interpreter"? - who wrote the code for the interpreter?

[jacquesm]

> There was not already a GB of OS loaded that you had a hard time to learn. All the code that was there was what you wrote (copied) yourself.

Typically you had 16K of ROM BASIC, if you were really lucky on a half decent machine (BBC or so) you would have something more akin to todays BIOS in another 16K. So there was some code there, just not easily accessible or replaceable.

[ur-whale]

> From what I see, they all are "stuck" on top of a GUI with only the slightest idea of what happens between their mouse and the actual hardware (and even that is often not hardware anymore)

I tend to agree with the feeling, but, on the other hand, only the really worthy will chose to dig in and really understand how a computer works.

Separating the wheat from the chaff.