3 ms·

Reading such posts really makes me wonder how people wrote UNIX (up to V7) with just ed and an ASR33. And productive, they were. I've seen some old timers on A

by rahen 4y ago

Reading such posts really makes me wonder how people wrote UNIX (up to V7) with just ed and an ASR33. And productive, they were. I've seen some old timers on ACME who dislike even the "distraction" of syntax coloring with modern editor such as vim. I wonder how they would fare with something like MS VSCode.

Jorengarenar 4y ago
>the "distraction" of syntax coloring Also known as "spitzensparken blinkenlichten"
- rahen 4y ago
  Liebe!
oblio 4y ago
The complexity of any software system built in the 70s and 80s is laughably low compared to the biggest system we build today. Their constraints were much harsher, but the fact of the matter is the end result was rather simple by today's standards. I think just the Bluetooth stack in a modern OS contains as much code as an entire Unix kernel from any time up to 1990 or so.
- rahen 4y ago
  Don't underestimate the complexity of software built in the seventies either for the business, financial or scientific world. We already had virtual machines, HA, realtime and distributed computing back then. Some code running at CERN or NASA was far more complex than a bluetooth stack, yet was also written with teletypes or ADM-3A style terminals.
  - viridian 4y ago
    As someone who has worked on both sides of the coin in the finance world in consumer credit processing, I think the person you are replying to is more right than wrong, but it's also a matter of how you view the idea of complexity. I've worked on 30+ year old systems where the code base is absolutely immense, but the <complexity density> of this stuff is very, very low on average compared to the magical bullshit that happens on a simple UI render of some template react app in 2022. Folks had very little in the way of abstractions at their fingertips, and the languages themselves weren't nearly so helpful in helping you manage complexity, so applications were usually long, shallow, and operating under a litany of fixed boundaries that define and drive a significant amount of behavior for you. The biggest source of complexity was having to manage your own unique `personal operating system` of bespoke resources at any given time, where each developer was carved into an incomplete walking repository of both business processes and software practices with the passing of each year.
    - oblio 4y ago
      To put it more simply, software can't be more simple in aggregate because we can trivially rely on insanely complex components others have built and made available. Components which were simply not available back then. Yes, the glue on top might be trivial, but even that frequently isn't. And if anything breaks down, the humans at the top are normally expected to handle it, no matter where in the stack it is.
  - oblio 4y ago
    I admire what people built with stone tools, but at the end of the day, a modern skyscraper is a marvel of complex engineering with no rival in that world. I'm not saying that NASA or CERN people were dumb or anything, they were probably smarter than the average dev today. But even a genius can only go so far with limited tools. An elite slinger from the Roman times will probably lose at least 8/10 against a Russian mobilized soldier with 2 weeks of training, armed with an AK-47. That's how progress works, we both learn ourselves, and more than that, we make powerful and accessible tools.
viridian 4y ago
Having worked with a handful of terminal CLI purists I'm convinced most of the people who bang the drum hard for vi and emacs aren't nearly as productive as they think they are, and instead evangelize it largely for some mixture of these reasons: 1) They have a strong preference for keyboard only operation 2) It serves as a cultural cachet, or shibboleth, to signal how elite and pure a developer they are 3) they wish to continue working in the same environment they have been for years or decades, and learning new key binds, trying to find equivalent features and testing new features isn't worth some potential benefit Everything else, like differences in RAM consumed, total install size, etc seem like post-hoc metric seeking for folks who have already decided what they like.
- progman32 4y ago
  I find that many people "banging the drum hard" for a text editor are falling for the same kind of faulty thinking. In my experience, the only situations a colleague has been slowed down in a significant way by their choice of editor seem to boil down to two categories: - Haven't put in the time to actually learn the tool (i.e. using vim purely in insert mode, or VSCode as a plain text editor, constantly going back to a file manager to find and open files) and get stuck in a particularly horrible workflow. - Burn hours daily fiddling with their setup, chasing perfection. Neither of these are typically caused by the tool itself. At the end of the day... I'm confident most devs can be quite effective using just DOS EDIT or Notepad if pressed. As for me.... unless I'm doing something specialized, I catch myself trying to eke out that last 1% productivity boost from my editor and ask myself... is this really the best thing to be messing with? Usually, it's not. Honestly, writing documentation or doing a quick prototype is much higher return.
- prmoustache 4y ago
  > 1) They have a strong preference for keyboard only operation Sounds like having a strong preference for keyboard only to edit text and code is the natural way. I don't think most vscode user are using mouse a lot either and if they do that, they are doing it the slow and inefficient way as vscode can be entirely piloted with the keyboard as well.

by rahen 4y ago

Jorengarenar 4y ago

>the "distraction" of syntax coloring Also known as "spitzensparken blinkenlichten"

rahen 4y ago
Liebe!

oblio 4y ago

The complexity of any software system built in the 70s and 80s is laughably low compared to the biggest system we build today. Their constraints were much harsher, but the fact of the matter is the end result was rather simple by today's standards. I think just the Bluetooth stack in a modern OS contains as much code as an entire Unix kernel from any time up to 1990 or so.

rahen 4y ago
Don't underestimate the complexity of software built in the seventies either for the business, financial or scientific world. We already had virtual machines, HA, realtime and distributed computing back then. Some code running at CERN or NASA was far more complex than a bluetooth stack, yet was also written with teletypes or ADM-3A style terminals.
- viridian 4y ago
  As someone who has worked on both sides of the coin in the finance world in consumer credit processing, I think the person you are replying to is more right than wrong, but it's also a matter of how you view the idea of complexity. I've worked on 30+ year old systems where the code base is absolutely immense, but the <complexity density> of this stuff is very, very low on average compared to the magical bullshit that happens on a simple UI render of some template react app in 2022. Folks had very little in the way of abstractions at their fingertips, and the languages themselves weren't nearly so helpful in helping you manage complexity, so applications were usually long, shallow, and operating under a litany of fixed boundaries that define and drive a significant amount of behavior for you. The biggest source of complexity was having to manage your own unique `personal operating system` of bespoke resources at any given time, where each developer was carved into an incomplete walking repository of both business processes and software practices with the passing of each year.
  - oblio 4y ago
    To put it more simply, software can't be more simple in aggregate because we can trivially rely on insanely complex components others have built and made available. Components which were simply not available back then. Yes, the glue on top might be trivial, but even that frequently isn't. And if anything breaks down, the humans at the top are normally expected to handle it, no matter where in the stack it is.
- oblio 4y ago
  I admire what people built with stone tools, but at the end of the day, a modern skyscraper is a marvel of complex engineering with no rival in that world. I'm not saying that NASA or CERN people were dumb or anything, they were probably smarter than the average dev today. But even a genius can only go so far with limited tools. An elite slinger from the Roman times will probably lose at least 8/10 against a Russian mobilized soldier with 2 weeks of training, armed with an AK-47. That's how progress works, we both learn ourselves, and more than that, we make powerful and accessible tools.

viridian 4y ago

Having worked with a handful of terminal CLI purists I'm convinced most of the people who bang the drum hard for vi and emacs aren't nearly as productive as they think they are, and instead evangelize it largely for some mixture of these reasons: 1) They have a strong preference for keyboard only operation 2) It serves as a cultural cachet, or shibboleth, to signal how elite and pure a developer they are 3) they wish to continue working in the same environment they have been for years or decades, and learning new key binds, trying to find equivalent features and testing new features isn't worth some potential benefit Everything else, like differences in RAM consumed, total install size, etc seem like post-hoc metric seeking for folks who have already decided what they like.

progman32 4y ago
I find that many people "banging the drum hard" for a text editor are falling for the same kind of faulty thinking. In my experience, the only situations a colleague has been slowed down in a significant way by their choice of editor seem to boil down to two categories: - Haven't put in the time to actually learn the tool (i.e. using vim purely in insert mode, or VSCode as a plain text editor, constantly going back to a file manager to find and open files) and get stuck in a particularly horrible workflow. - Burn hours daily fiddling with their setup, chasing perfection. Neither of these are typically caused by the tool itself. At the end of the day... I'm confident most devs can be quite effective using just DOS EDIT or Notepad if pressed. As for me.... unless I'm doing something specialized, I catch myself trying to eke out that last 1% productivity boost from my editor and ask myself... is this really the best thing to be messing with? Usually, it's not. Honestly, writing documentation or doing a quick prototype is much higher return.
prmoustache 4y ago
> 1) They have a strong preference for keyboard only operation Sounds like having a strong preference for keyboard only to edit text and code is the natural way. I don't think most vscode user are using mouse a lot either and if they do that, they are doing it the slow and inefficient way as vscode can be entirely piloted with the keyboard as well.