8 ms·

This was how Unix was presented to me when I was first introduced to me. I was told it was like industrial machinery - designed for those who know how to use it

by __jal 10y ago

This was how Unix was presented to me when I was first introduced to me. I was told it was like industrial machinery - designed for those who know how to use it, efficient, dangerous if you aren't careful. Which is exactly what a good tool should be. When IDEs (the kind that comes as a GUI'ed bundle of things thought to be the most appropriate for the purpose by committee of someones, somewhere) started becoming popular, I didn't get it, at all. Put aside tool tips (which annoy me far more than is rational); it seemed to me that the idea was to build a toy model workshop on the work bench of a fully outfitted workshop. Why would anyone want to use that? Why bother in the first place? I mean, I do get it. And who knows, maybe if I used one of those long enough to break muscle memory and the conceptual assumptions that don't map, I'd change my mind. But so far, vi + shell + standard utilities + what I build have served me just fine, and if for some reason I were to need "more power", whatever that means, I'd probably move to emacs. And I still maintain that tool tips/balloon help/obscuring the very thing you're pointing at is a stupidly rude anti-pattern. Even worse is not making it possible to turn off.

coldtea 10y ago
>This was how Unix was presented to me when I was first introduced to me. I was told it was like industrial machinery - designed for those who know how to use it, efficient, dangerous if you aren't careful. Which is exactly what a good tool should be. The problem is that this is a whole lot of cargo cult. It does have the efficient parts, but it also has a lot of accumulated cruft, archaic limitations, arbitrariness, and plain bad decisions.
- joelthelion 10y ago
  > The problem is that this is a whole lot of cargo cult. It does have the efficient parts, but it also has a lot of accumulated cruft, archaic limitations, arbitrariness, and plain bad decisions. I don't think the problem is cargo culting. Replacing things with better solutions is hard. Take the venerable ANSI terminal. It's archaic and cryptic, I think most people would agree on that. Yet proposing a better, widely useful and backwards compatible alternative is extremely hard. Which is why no one has succeeded yet. There is still a lot of innovation, though. 10 years ago, we didn't have git, or ag, or autojump. Gdb has improved A LOT in the past few years, even if it's not immediately obvious when you open it.
  - faho 10y ago
    >I don't think the problem is cargo culting. Replacing things with better solutions is hard. Take the venerable ANSI terminal. It's archaic and cryptic, I think most people would agree on that. Yet proposing a better, widely useful and backwards compatible alternative is extremely hard. Which is why no one has succeeded yet. Making a better alternative isn't hard. Getting everyone to use it is.
    - joemi 10y ago
      I forget where I read this, but someone once talked about how a new standard can't just be "better". Instead it has to be _a lot_ better and probably even bring a lot of really good new stuff to the table, otherwise not enough people will bother switching to it.
  - beachstartup 10y ago
    > Yet proposing a better, widely useful and backwards compatible alternative is extremely hard. we keep inventing new stuff, but always end up just using it to emulate and display terminals in new and interesting ways. even my new, shiny 4G LTE + iOS + touchscreen mobile device is used to run a terminal emulator over ssh half the time. i've even use its web browser to run a web RDP session .. to display a terminal console. i think there's just something soothing about a screen full of text. it's a very efficient way of displaying information.
    - blakeyrat 10y ago
      Only certain types of information. It's not a great way to display, for example, a comparison between two similarly-edited movie trailers. Or a map of Bremen. Or the annotations on your 2016 second quarter financial sum-up spreadsheet. The big problem with the entire Unix philosophy is that it assumes all important data is text, when in the real world very little of it is. If you're one of the few people who can get away with text-based everything, it's great. If you're the vast majority of the population, it's a terrible idea.
      - 10y ago
- __jal 10y ago
  > The problem is that this is a whole lot of cargo cult. Please do explain. Where do I use symbolic representations of technology to attempt doomed magic rituals? As far as the rest of it, everything accumulates cruft. That's why people write new things. And yes, there have been bad decisions. (Just, IMHO, meaningfully fewer than other OSes.) But perhaps I'm blinded by my cargo-cultish ways, can you point to an archaic limitation that you've run in to recently? I'm ignoring "arbitrariness", as that generally is both highly opinion-driven and generally subject to correcting ignorance of the decision-making process that went it to it. So usually "arbitrary" things are actually one of the other listed categories.
  - pavlov 10y ago
    symbolic representations of technology to attempt doomed magic rituals I believe that's the official tagline for GNU Autoconf?
    - chetanahuja 10y ago
      Exactly. Sometime in early 1990's, the first configure.ac file was created. Today, every configure.ac file in existence can trace it's ancestry to that original file through a long, unbroken chain of copy-paste operations.
  - coldtea 10y ago
    >Please do explain. Where do I use symbolic representations of technology to attempt doomed magic rituals? Perhaps you are not aware that cargo cult has a metaphorical meaning in computing that's about carrying forward baggage that's not relevant, because it worked/mattered in the past, and giving the whole past thing more importance than an objective view would. >As far as the rest of it, everything accumulates cruft. That's hardly an excuse not to get rid of it periodically in the fear of losing compatibility with some 30+ year old script or device mode. Terminal EMULATORS are a perfect example in an age where someone close to 30 probably has never even seen an actual terminal.
- dasil003 10y ago
  Another problem is the scope of the stack and problem space to be addressed. Someone can easily come up with a better solution to some subset of the problem, but it won't be interoperable and have the features necessary to solve the problem that all the people using the original solution expect. If you have a big enough fundamental improvement you can motivate the change to happen over time, but by the time that transition is done you've accumulated a whole different set of crufty legacy.
combatentropy 10y ago
> And I still maintain that tool tips [...] is a stupidly rude anti-pattern Amen, brother
- wruza 10y ago
  And that moment when you point at it, but that f-ing pop up doesn't actually pop up...
qwertyuiop924 10y ago
Hey, don't ask me. I'm an emacs user. I have a fully outfitted workbench on top of my workbench, specifically optimized for text editing, which can interface with the workbench beneath it, so you never have to leave.
overgard 10y ago
The difference is IDEs understand the underlying structure of the code, including relationships between entities, symbol types in their context, indexes for searching, and so on. That allows you to express transforms that can't be expressed if everything is just a text stream. I can grab a chunk of a function in resharper and do an "extract method", and it can figure out data dependencies, or I can do a "find usages" for a variable called "map" and not pick up every comment that has the word "map" in it, or I can move a class to a new module and let it figure out all the call sites that need to change their using statements. Comparing unix to an IDE is like comparing a CSV file to a relational database. They both store data in tables, but you're not going to replace Postgres with grep, I hope, even though you could do very basic "queries" with grep. And unix can never be a very good IDE, comparatively, because "text streams" are not a sufficiently good data structure for representing program structure.
- __jal 10y ago
  There is nothing about text streams that prohibit tools from understanding whatever language you're writing in. Unless you have an very interesting compiler, your IDE is processing text, too. But also, you seem to believe that somehow communication between applications is somehow limited to pipes, which makes the comparison inapt. Ignoring the category error (text format in a data file vs. server application + storage), please explain what your IDE does that cannot be communicated over a socket? Or dbus (oh god please don't, but the point stands)?
  - exceptione 10y ago
    I am not the parent you reply to, but see my previous reply for the capabilities you miss in 'dumb' editors. "here is nothing about a text streams that prohibit tools from understanding whatever language you're writing in" Well it might be true that you can deduce the language of some text stream but you need to make a big step in order to interpret it. You are talking about a compiler. Well a compiler takes a compilation unit, not some stream of text. To infer the semantics of a program the program needs to be present, not a part of it. Granted, a program might be broken up in independent modules, of course. Make no mistake, a 'dumb' editor like sublimetext could understand a php symfony or a java struts project, if it would get the same analysis tools available in eclipse for example. It could be done, but it is massively more difficult than just running a syntax highlighter and running a rough tagger on some text. Its sad because I believe that fast, slim, editors that know as much as a massive IDE is the best of both worlds. I have seen the code for eclipse -- there is so much dancing, it's a miracle that handling a key press eventually completes in some time.
carterehsmith 10y ago
> vi + shell + standard utilities + what I build That is good. Can you tell us, what exactly did you build with "vi + shell + standard utilities + what I build"
- __jal 10y ago
  Mostly systems tools for managing operations in companies with complex internet presences.
wodenokoto 10y ago
> ... dangerous if you aren't careful. > Which is exactly what a good tool should be. That's a really stupid requirement.
deleted 10y ago
[deleted]
jimbokun 10y ago
"I was told it was like industrial machinery - designed for those who know how to use it, efficient, dangerous if you aren't careful." Neal Stephenson expressed this same idea very eloquently: http://www.cryptonomicon.com/beginning.html http://www.cryptonomicon.com/beginning.html

by __jal 10y ago

coldtea 10y ago

>This was how Unix was presented to me when I was first introduced to me. I was told it was like industrial machinery - designed for those who know how to use it, efficient, dangerous if you aren't careful. Which is exactly what a good tool should be. The problem is that this is a whole lot of cargo cult. It does have the efficient parts, but it also has a lot of accumulated cruft, archaic limitations, arbitrariness, and plain bad decisions.

joelthelion 10y ago
> The problem is that this is a whole lot of cargo cult. It does have the efficient parts, but it also has a lot of accumulated cruft, archaic limitations, arbitrariness, and plain bad decisions. I don't think the problem is cargo culting. Replacing things with better solutions is hard. Take the venerable ANSI terminal. It's archaic and cryptic, I think most people would agree on that. Yet proposing a better, widely useful and backwards compatible alternative is extremely hard. Which is why no one has succeeded yet. There is still a lot of innovation, though. 10 years ago, we didn't have git, or ag, or autojump. Gdb has improved A LOT in the past few years, even if it's not immediately obvious when you open it.
- faho 10y ago
  >I don't think the problem is cargo culting. Replacing things with better solutions is hard. Take the venerable ANSI terminal. It's archaic and cryptic, I think most people would agree on that. Yet proposing a better, widely useful and backwards compatible alternative is extremely hard. Which is why no one has succeeded yet. Making a better alternative isn't hard. Getting everyone to use it is.
  - joemi 10y ago
    I forget where I read this, but someone once talked about how a new standard can't just be "better". Instead it has to be _a lot_ better and probably even bring a lot of really good new stuff to the table, otherwise not enough people will bother switching to it.
- beachstartup 10y ago
  > Yet proposing a better, widely useful and backwards compatible alternative is extremely hard. we keep inventing new stuff, but always end up just using it to emulate and display terminals in new and interesting ways. even my new, shiny 4G LTE + iOS + touchscreen mobile device is used to run a terminal emulator over ssh half the time. i've even use its web browser to run a web RDP session .. to display a terminal console. i think there's just something soothing about a screen full of text. it's a very efficient way of displaying information.
  - blakeyrat 10y ago
    Only certain types of information. It's not a great way to display, for example, a comparison between two similarly-edited movie trailers. Or a map of Bremen. Or the annotations on your 2016 second quarter financial sum-up spreadsheet. The big problem with the entire Unix philosophy is that it assumes all important data is text, when in the real world very little of it is. If you're one of the few people who can get away with text-based everything, it's great. If you're the vast majority of the population, it's a terrible idea.
    - 10y ago
__jal 10y ago
> The problem is that this is a whole lot of cargo cult. Please do explain. Where do I use symbolic representations of technology to attempt doomed magic rituals? As far as the rest of it, everything accumulates cruft. That's why people write new things. And yes, there have been bad decisions. (Just, IMHO, meaningfully fewer than other OSes.) But perhaps I'm blinded by my cargo-cultish ways, can you point to an archaic limitation that you've run in to recently? I'm ignoring "arbitrariness", as that generally is both highly opinion-driven and generally subject to correcting ignorance of the decision-making process that went it to it. So usually "arbitrary" things are actually one of the other listed categories.
- pavlov 10y ago
  symbolic representations of technology to attempt doomed magic rituals I believe that's the official tagline for GNU Autoconf?
  - chetanahuja 10y ago
    Exactly. Sometime in early 1990's, the first configure.ac file was created. Today, every configure.ac file in existence can trace it's ancestry to that original file through a long, unbroken chain of copy-paste operations.
- coldtea 10y ago
  >Please do explain. Where do I use symbolic representations of technology to attempt doomed magic rituals? Perhaps you are not aware that cargo cult has a metaphorical meaning in computing that's about carrying forward baggage that's not relevant, because it worked/mattered in the past, and giving the whole past thing more importance than an objective view would. >As far as the rest of it, everything accumulates cruft. That's hardly an excuse not to get rid of it periodically in the fear of losing compatibility with some 30+ year old script or device mode. Terminal EMULATORS are a perfect example in an age where someone close to 30 probably has never even seen an actual terminal.
dasil003 10y ago
Another problem is the scope of the stack and problem space to be addressed. Someone can easily come up with a better solution to some subset of the problem, but it won't be interoperable and have the features necessary to solve the problem that all the people using the original solution expect. If you have a big enough fundamental improvement you can motivate the change to happen over time, but by the time that transition is done you've accumulated a whole different set of crufty legacy.

combatentropy 10y ago

> And I still maintain that tool tips [...] is a stupidly rude anti-pattern Amen, brother

wruza 10y ago
And that moment when you point at it, but that f-ing pop up doesn't actually pop up...

qwertyuiop924 10y ago

Hey, don't ask me. I'm an emacs user. I have a fully outfitted workbench on top of my workbench, specifically optimized for text editing, which can interface with the workbench beneath it, so you never have to leave.

overgard 10y ago

The difference is IDEs understand the underlying structure of the code, including relationships between entities, symbol types in their context, indexes for searching, and so on. That allows you to express transforms that can't be expressed if everything is just a text stream. I can grab a chunk of a function in resharper and do an "extract method", and it can figure out data dependencies, or I can do a "find usages" for a variable called "map" and not pick up every comment that has the word "map" in it, or I can move a class to a new module and let it figure out all the call sites that need to change their using statements. Comparing unix to an IDE is like comparing a CSV file to a relational database. They both store data in tables, but you're not going to replace Postgres with grep, I hope, even though you could do very basic "queries" with grep. And unix can never be a very good IDE, comparatively, because "text streams" are not a sufficiently good data structure for representing program structure.

__jal 10y ago
There is nothing about text streams that prohibit tools from understanding whatever language you're writing in. Unless you have an very interesting compiler, your IDE is processing text, too. But also, you seem to believe that somehow communication between applications is somehow limited to pipes, which makes the comparison inapt. Ignoring the category error (text format in a data file vs. server application + storage), please explain what your IDE does that cannot be communicated over a socket? Or dbus (oh god please don't, but the point stands)?
- exceptione 10y ago
  I am not the parent you reply to, but see my previous reply for the capabilities you miss in 'dumb' editors. "here is nothing about a text streams that prohibit tools from understanding whatever language you're writing in" Well it might be true that you can deduce the language of some text stream but you need to make a big step in order to interpret it. You are talking about a compiler. Well a compiler takes a compilation unit, not some stream of text. To infer the semantics of a program the program needs to be present, not a part of it. Granted, a program might be broken up in independent modules, of course. Make no mistake, a 'dumb' editor like sublimetext could understand a php symfony or a java struts project, if it would get the same analysis tools available in eclipse for example. It could be done, but it is massively more difficult than just running a syntax highlighter and running a rough tagger on some text. Its sad because I believe that fast, slim, editors that know as much as a massive IDE is the best of both worlds. I have seen the code for eclipse -- there is so much dancing, it's a miracle that handling a key press eventually completes in some time.

carterehsmith 10y ago

> vi + shell + standard utilities + what I build That is good. Can you tell us, what exactly did you build with "vi + shell + standard utilities + what I build"

__jal 10y ago
Mostly systems tools for managing operations in companies with complex internet presences.

wodenokoto 10y ago

> ... dangerous if you aren't careful. > Which is exactly what a good tool should be. That's a really stupid requirement.

deleted 10y ago

[deleted]

jimbokun 10y ago

"I was told it was like industrial machinery - designed for those who know how to use it, efficient, dangerous if you aren't careful." Neal Stephenson expressed this same idea very eloquently: http://www.cryptonomicon.com/beginning.html http://www.cryptonomicon.com/beginning.html