4 ms·

Needing an IDE for a shell!? "Tooling" is a design smell. It's building hacks on hacks to make bad design and lack of understanding somewhat manageable. For b

Needing an IDE for a shell!? "Tooling" is a design smell. It's building hacks on hacks to make bad design and lack of understanding somewhat manageable. For better systems all you need is a shell and a text editor. That said, we do need a better shell. But definitely one with UNIX and CLI mentality.

9dev 3y ago
Emulating a printer connected to a typewriter is a design smell.
- jampekka 3y ago
  I agree. It maybe wasn't design smell when it was designed but 50 years later it definitely is a design/culture smell. Doesn't make "tooling" any less smelly though.
  - 9dev 3y ago
    Maybe it is time to rethink what a terminal is, and get rid of the restriction to be text-only? There is really no reason for that, other than Typewriter heritage.
    - jampekka 3y ago
      It's been that time for decades. And it has been retought many times but never seems to catch on. I think even unices have abandoned the UNIX philosophy and turned largely into "there's an app for that", so maybe there's not much interest for a better composable UI.
    - mbreese 3y ago
      There are some terminals that can display inline images, but those features aren’t commonly used. Why? Text works. Text is the lowest common denominator for working with data. This is why terminals are still primarily text based. This is also why stdin/out/err are also commonly text based (when the user is expected to view it). Text is simple and easy to parse. Binary data exchange formats (or objects) come in and out of vogue, but text just keeps on working.
      - 9dev 3y ago
        Is that so? Because the way I see it, there are a bazillion different tools, plus decades of accrued knowledge only related to massaging data into text and back to structures. How many human brain cycles are wasted to data conversion on the Terminal? Text is a lousy abstraction. It may have worked well 50 years ago when computing was limited to researchers on American universities, but the digital world back then has little in common with ours. Acting like extending the shell to anything beyond plain text would require switching to fancy new serialisation formats every other year is a red herring. The only thing it takes is admitting a shell isn’t used on typewriters but modern computers, where humans use high-resolution screens and programs can exchange structured data. Everything else follows, and is well suited for standardisation. But that will never happen as long as grumpy sysadmins insist that cobbling together grep and sed in some arcane incantation is the only thing we ever need.
        jampekka 3y ago
        When the alternative is to fire up some mess of an IDE with some nightmearish COM/.NET/ProtoBuf/whathaveyou overengineering marvels, I take grep and sed every time. Simple text-based structured data format (something like YAML) with possibility to embed binary would be the way to go IMHO. And of course one should be able to show graphics in the terminal. But we're not gonna get it. Open source tol is being rapidly enshittified by corporate EEE with their badly overengineered enterprise crap. :(
        9dev 3y ago
        I don't know why you seem to think we can only have "super-lightweight 2kb C binary" or "giant over engineered Java-IDE" - there's lots of space in between. I don't think anybody would want to give up snappy terminals, but at the same time, why does this have to imply loosing out on half a century of user experience research??
        jampekka 3y ago
        The original proposal in the thread was PowerShell+IDE. That's overengineering on top of overengineering on top of overengineering.
pjmlp 3y ago
Welcome to the world of Lisp Machines, Xerox PARC and ETHZ. Unfortunely taken away due to UNIX's free beer offerings.
- jampekka 3y ago
  I almost daily daydream of the alternate timeline where MBAs and greed didn't destroy Lisp Machines. And lament that we ended up with this horrible pile of hacks that makes everything needlessly painful.
  - geophile 3y ago
    Is that what happened? MBAs and greed destroy a lot, but I’m not sure about Lisp machines. Beautiful hardware and software, but unbelievably expensive, and custom hardware was bound to lose out on performance.
    - jampekka 3y ago
      Symbolics/Noftsker is often attributed as the reason for the Lisp "split" and turning Lisp machines proprietary (and needlessly expensive). The arrival of microcomputers, and horrors like Microsoft, were of course a major reason too. https://www.gnu.org/gnu/road-to-gnu.en.html#betrayed https://www.gnu.org/gnu/road-to-gnu.en.html#betrayed https://www.gnu.org/gnu/road-to-gnu.en.html#betrayed https://www.gnu.org/gnu/road-to-gnu.en.html#betrayed
      - lispm 3y ago
        The "MIT Lisp Machine" were developed as prototypes at the MIT AI Lab, with DARPA money (Defense Advanced Research Projects Agency, a research funding part of the US military). The machines were mostly hand-made and did cost a little under $100000 to make. Only very few (200 ?) were ever made for use at MIT. The military wanted (!) to have better/cheaper generations of these computers for Research&Development and for deployment of applications. So it was decided to set up commercial companies: LMI and Symbolics were founded. LMI later sold a license to TI. The market for these machines was high-end: installations could cost anything from $50000 to $200000. In the first years these machines mostly went into military and government projects: military was sponsoring the deployment and first improvements (like the development of Lisp-specific CPUs). Basically that's not unusual from many other government sponsored research, which later got marketed by a startup. The Lisp they were using was standardized starting 81/82 (also with the help of Symbolics). This standard then was ported to PCs, Macs, Workstations and Mainframes. The Lisps were available free or commercial (a few hundred dollar to several thousand, depending on the vendor). The Lisp machines itself remained tied to special hardware and mostly died in the late 80s and early 90s. Various other free and commercial offerings of Lisp for PCs/Macs/UNIX systems died or survived... The whole thing was initially financed by a large customer: the government (-> DARPA). This customer demanded commercial versions to be able to use them beyond the few prototypes. Roughly 10k machines (my estimate) were built and sold. At the same time cheaper Lisp systems were developed by universities and commercial competitors. Free / Open Source versions of Common Lisp (the Lisp dialect then also on the Lisp Machines) were developed by CMU (CMUCL), in Germany (CLISP, CLICC), in Japan (KCL), ...
ImprobableTruth 3y ago
And what are these "better systems"?
- jampekka 3y ago
  GNU for example.

9dev 3y ago

Emulating a printer connected to a typewriter is a design smell.

jampekka 3y ago
I agree. It maybe wasn't design smell when it was designed but 50 years later it definitely is a design/culture smell. Doesn't make "tooling" any less smelly though.
- 9dev 3y ago
  Maybe it is time to rethink what a terminal is, and get rid of the restriction to be text-only? There is really no reason for that, other than Typewriter heritage.
  - jampekka 3y ago
    It's been that time for decades. And it has been retought many times but never seems to catch on. I think even unices have abandoned the UNIX philosophy and turned largely into "there's an app for that", so maybe there's not much interest for a better composable UI.
  - mbreese 3y ago
    There are some terminals that can display inline images, but those features aren’t commonly used. Why? Text works. Text is the lowest common denominator for working with data. This is why terminals are still primarily text based. This is also why stdin/out/err are also commonly text based (when the user is expected to view it). Text is simple and easy to parse. Binary data exchange formats (or objects) come in and out of vogue, but text just keeps on working.
    - 9dev 3y ago
      Is that so? Because the way I see it, there are a bazillion different tools, plus decades of accrued knowledge only related to massaging data into text and back to structures. How many human brain cycles are wasted to data conversion on the Terminal? Text is a lousy abstraction. It may have worked well 50 years ago when computing was limited to researchers on American universities, but the digital world back then has little in common with ours. Acting like extending the shell to anything beyond plain text would require switching to fancy new serialisation formats every other year is a red herring. The only thing it takes is admitting a shell isn’t used on typewriters but modern computers, where humans use high-resolution screens and programs can exchange structured data. Everything else follows, and is well suited for standardisation. But that will never happen as long as grumpy sysadmins insist that cobbling together grep and sed in some arcane incantation is the only thing we ever need.
      - jampekka 3y ago
        When the alternative is to fire up some mess of an IDE with some nightmearish COM/.NET/ProtoBuf/whathaveyou overengineering marvels, I take grep and sed every time. Simple text-based structured data format (something like YAML) with possibility to embed binary would be the way to go IMHO. And of course one should be able to show graphics in the terminal. But we're not gonna get it. Open source tol is being rapidly enshittified by corporate EEE with their badly overengineered enterprise crap. :(
        9dev 3y ago
        I don't know why you seem to think we can only have "super-lightweight 2kb C binary" or "giant over engineered Java-IDE" - there's lots of space in between. I don't think anybody would want to give up snappy terminals, but at the same time, why does this have to imply loosing out on half a century of user experience research??
        jampekka 3y ago
        The original proposal in the thread was PowerShell+IDE. That's overengineering on top of overengineering on top of overengineering.

pjmlp 3y ago

Welcome to the world of Lisp Machines, Xerox PARC and ETHZ. Unfortunely taken away due to UNIX's free beer offerings.

jampekka 3y ago
I almost daily daydream of the alternate timeline where MBAs and greed didn't destroy Lisp Machines. And lament that we ended up with this horrible pile of hacks that makes everything needlessly painful.
- geophile 3y ago
  Is that what happened? MBAs and greed destroy a lot, but I’m not sure about Lisp machines. Beautiful hardware and software, but unbelievably expensive, and custom hardware was bound to lose out on performance.
  - jampekka 3y ago
    Symbolics/Noftsker is often attributed as the reason for the Lisp "split" and turning Lisp machines proprietary (and needlessly expensive). The arrival of microcomputers, and horrors like Microsoft, were of course a major reason too. https://www.gnu.org/gnu/road-to-gnu.en.html#betrayed https://www.gnu.org/gnu/road-to-gnu.en.html#betrayed https://www.gnu.org/gnu/road-to-gnu.en.html#betrayed https://www.gnu.org/gnu/road-to-gnu.en.html#betrayed
    - lispm 3y ago
      The "MIT Lisp Machine" were developed as prototypes at the MIT AI Lab, with DARPA money (Defense Advanced Research Projects Agency, a research funding part of the US military). The machines were mostly hand-made and did cost a little under $100000 to make. Only very few (200 ?) were ever made for use at MIT. The military wanted (!) to have better/cheaper generations of these computers for Research&Development and for deployment of applications. So it was decided to set up commercial companies: LMI and Symbolics were founded. LMI later sold a license to TI. The market for these machines was high-end: installations could cost anything from $50000 to $200000. In the first years these machines mostly went into military and government projects: military was sponsoring the deployment and first improvements (like the development of Lisp-specific CPUs). Basically that's not unusual from many other government sponsored research, which later got marketed by a startup. The Lisp they were using was standardized starting 81/82 (also with the help of Symbolics). This standard then was ported to PCs, Macs, Workstations and Mainframes. The Lisps were available free or commercial (a few hundred dollar to several thousand, depending on the vendor). The Lisp machines itself remained tied to special hardware and mostly died in the late 80s and early 90s. Various other free and commercial offerings of Lisp for PCs/Macs/UNIX systems died or survived... The whole thing was initially financed by a large customer: the government (-> DARPA). This customer demanded commercial versions to be able to use them beyond the few prototypes. Roughly 10k machines (my estimate) were built and sold. At the same time cheaper Lisp systems were developed by universities and commercial competitors. Free / Open Source versions of Common Lisp (the Lisp dialect then also on the Lisp Machines) were developed by CMU (CMUCL), in Germany (CLISP, CLICC), in Japan (KCL), ...

ImprobableTruth 3y ago

And what are these "better systems"?

jampekka 3y ago
GNU for example.