4 ms·

> Systems were simpler, side-effects were better understood and contained. I'm going to disagree, here. Things were as difficult as they ever have been since.

> Systems were simpler, side-effects were better understood and contained. I'm going to disagree, here. Things were as difficult as they ever have been since. Systems and side-effects are better understood only in hindsight. Coding in assembly because higher-order language wasn't invented yet. Coding in a text editor because IDEs were not a thing. Searching linked lists because what's a data-base, not to mention SQL. Needing to keep things lean because 32kb was an ungodly waste. In that light, things are easier than ever. One can be both professional and whimsical. In fact, I'd argue that true mastery will only come with a sense of fun and interest in your craft. Applying whimsy can be an engineering decision. Using 418 when any error code will do, for example, if it affects nothing else.

deleted 5y ago
[deleted]
patmorgan23 5y ago
There's like 4 or 5 extra layers of abstraction/frame works in most systems these days.
- TuringTest 5y ago
  So what? If your tech stack is worth its salt, those layers will be mostly removed at compilation. Reductions in performance often are due to developers mixing up their layers of abstraction and repeating work among several of them, rather than by having several layers adding more powerful abstractions. It's good that a developer has cursory knowledge of how those layers work (e.g. to avoid re-adding checks at the upper layers of something that is already guaranteed by the lower ones), but there's no need to be an expert at all them.
  - int_19h 5y ago
    Can you give an example of a tech stack worth its salt by these criteria?
    - TuringTest 5y ago
      (tl;dr: the problem is not in the abstractions, is current standard engineering practices of bringing the full layer for each abstraction instead of just the few parts you need to solve your problem). I'd say something like Docker containers, running a wasm engine, targeted by a lean library with a sane high-level programming language - either a santard-looking imperative language like Haxe, or some esoteric opinionated functional thingie like Julia or Elixir. (It could also be something like Vue, Angular or React, but those aren't exactly 'lean', being specialiced in working with the full browser DOM and web servers). Each layer abstracts away the lower levels (virtualization & compartmentalization to run on any hardware, bytecode to run on any OS or browser engine...), allowing you to potentially use it without being tied to one specific implementation of that layer. Higher layers provide increasingly more complex and powerful abstractions, with standardized code that's been created by experts in the field with efficiency in mind, and debugged through hundreds or thousands of client projects; making them likely more performant and robust than anything a single development team could ever build on their own (except for extremely limited domains run on dedicated hardware). And ideally they have the plus side of working side-by-side with other applications or libraries, running in the same system without being engineered to work only with a single "official stack", allowing you to mix-and-match the best abstraction for each problem being solved, instead of forcing you into a single solution for all your software. That level of flexibility (plus the simplification of the layers below) is worth the runtime penalty imposed by several piled-up abstraction layers. That's why we don't code everything on assembly anymore.
int_19h 5y ago
These were all solved problems in the 90s already - we had plenty of high-level languages, including those with integrated IDEs and even databases (dBase comes to mind!). SQL was already around. 32Kb was something from another era.

deleted 5y ago

[deleted]

patmorgan23 5y ago

There's like 4 or 5 extra layers of abstraction/frame works in most systems these days.

TuringTest 5y ago
So what? If your tech stack is worth its salt, those layers will be mostly removed at compilation. Reductions in performance often are due to developers mixing up their layers of abstraction and repeating work among several of them, rather than by having several layers adding more powerful abstractions. It's good that a developer has cursory knowledge of how those layers work (e.g. to avoid re-adding checks at the upper layers of something that is already guaranteed by the lower ones), but there's no need to be an expert at all them.
- int_19h 5y ago
  Can you give an example of a tech stack worth its salt by these criteria?
  - TuringTest 5y ago
    (tl;dr: the problem is not in the abstractions, is current standard engineering practices of bringing the full layer for each abstraction instead of just the few parts you need to solve your problem). I'd say something like Docker containers, running a wasm engine, targeted by a lean library with a sane high-level programming language - either a santard-looking imperative language like Haxe, or some esoteric opinionated functional thingie like Julia or Elixir. (It could also be something like Vue, Angular or React, but those aren't exactly 'lean', being specialiced in working with the full browser DOM and web servers). Each layer abstracts away the lower levels (virtualization & compartmentalization to run on any hardware, bytecode to run on any OS or browser engine...), allowing you to potentially use it without being tied to one specific implementation of that layer. Higher layers provide increasingly more complex and powerful abstractions, with standardized code that's been created by experts in the field with efficiency in mind, and debugged through hundreds or thousands of client projects; making them likely more performant and robust than anything a single development team could ever build on their own (except for extremely limited domains run on dedicated hardware). And ideally they have the plus side of working side-by-side with other applications or libraries, running in the same system without being engineered to work only with a single "official stack", allowing you to mix-and-match the best abstraction for each problem being solved, instead of forcing you into a single solution for all your software. That level of flexibility (plus the simplification of the layers below) is worth the runtime penalty imposed by several piled-up abstraction layers. That's why we don't code everything on assembly anymore.

int_19h 5y ago

These were all solved problems in the 90s already - we had plenty of high-level languages, including those with integrated IDEs and even databases (dBase comes to mind!). SQL was already around. 32Kb was something from another era.