5 ms·

It's interesting how dev tools went from text-based 80s to GUI 90s and then back to text-based. As well as the terminal, think about Markdown vs WYSIWIG, Visual

It's interesting how dev tools went from text-based 80s to GUI 90s and then back to text-based. As well as the terminal, think about Markdown vs WYSIWIG, Visual Studio/XCode vs Ruby on Rails, YAML config files vs XML with visual editor, etc. Terminal is good because its unconstrained. But most of the time I would prefer a GUI interface. We just need to blend the two approaches better and always have a terminal fallback.

bitwize 4y ago
This is because as Linux started taking over the server space, it brought with it a culture of "stone knives and bearskins" tooling from old-school Unix -- and most applications these days are web applications. One of the major disappointments of recent years is seeing Microsoft backpedal from promoting Windows as the premier development platform and embracing (to extend or extinguish?) Linux with its command lije bullshit. Windows in the late 90s was an entire environment based on composable components, linked together via discoverable interfaces. It had a software composition story far superior to Unix pipes. We should be able to build entire web and cloud infrastructures by wiring components together visually, and using visual inspection tools to debug problems as they happen in the pipeline. Not monkey about with YAML and JSON.
- bradrn 4y ago
  > Windows in the late 90s was an entire environment based on composable components, linked together via discoverable interfaces. It had a software composition story far superior to Unix pipes. I’ve never heard anything about this (probably because it was before my time); could you elaborate?
  - muststopmyths 4y ago
    Sounds like COM. Comparing a programming framework to pipes seems a bit over the top though. I don't know anyone who'd seriously advocate building a large application solely from small programs piping their output to other small programs. I've already complained previously about the new Microsoft though, so I have sympathy with the underlying sentiment :)
  - zwkrt 4y ago
    I think parent is talking about the COM interface.[1] powershell still has a legacy of object oriented manipulation as opposed to text/line based manipulation. I’m too much living in Unix world to give more insight as to how well it functioned though. https://en.m.wikipedia.org/wiki/Component_Object_Model https://en.m.wikipedia.org/wiki/Component_Object_Model
- necovek 4y ago
  Imagined from the same fold as COM (which you are likely talking about) was CORBA, an international standard for "object" interoperability. Guess what came out of that? It's one of those systems that's perfect (as in perfectly abstracting away everything) but notoriously and impractically complex. COM is only slightly less so. The downfall of all the object-oriented approaches is that we don't really think about objects, but instead of actions ("functions") we perform, which is much simpler as well. Basically, you don't see bread and say bread->eat() (or at least your doctor will tell you not to :)) but instead look for something to eat() and then stick bread in it once you find it (eat(bread)).
  - vaughan 4y ago
    person->eat(bread)
    - necovek 4y ago
      That's a good point. But as soon as you've got someone else who needs to eat (cat->eat(), dog->eat()...), it is still better to go with a functional approach: feed(person, bread) Basically, my abstraction was bad for that case, but it is so much easier to move from eat(bread) to eat(person, bread) and then rename that to "feed" than to introduce object inheritance/composition and think about the commonality between dog and person if all you want to do is feed them. Sure, there are cases where purely OOP approach is not burdensome, and may even be easier, but functional approach, as an explicit superset of possibilities, will usually be simpler and more understandable.
- vaughan 4y ago
  > We should be able to build entire web and cloud infrastructures by wiring components together visually 100%. I think this is the next wave of development. Back to the future. > Not monkey about with YAML and JSON. The key difference this time needs to be two-way sync between code and visual. Having a serialized format (YAML/JSON) for wiring at some level is important though, but it should be easily modifiable by humans. In the last wave, we left this two-way syncing behind. An example of this is XCode's NIB files and Interface Builder. NIB weren't designed for humans to modify so everything had to be done through IB which made certain things a pain, and created a lot of VCS churn. I've been thinking about whether we can achieve a two-way syncing (text <-> diagram) visual programming interface by interacting with the AST of a (subset of) an imperative language and using data flow tracing (via code instrumentation). I wonder what the minimal data structures needed are to represent most of configuration programming. Such as state machines, streams, graphs (dependency tracking).
sublinear 4y ago
Strongly disagree. GUIs are just a distraction. The same CLI knowledge can be used to write scripts for common tasks. GUIs don't add any value beyond visually showing some structure, but CLIs can do just the same and often do. Do you have any examples of tools where the GUI is more useful than the CLI, and could you explain why that is?
- massysett 4y ago
  > Do you have any examples of tools where the GUI is more useful than the CLI, and could you explain why that is? Browsing photographs.
- jerpint 4y ago
  I used to be of this opinion. Now I think more “GUIs are great once you’ve mastered the CLI and know what underlying operations you want to execute”. A GUI I discovered recently that I really like is docker-desktop. I used to do everything from the CLI. The gui gives me a much better overview of everything. If I need to dive in to the CLI, I know exactly where to go.
  - vaughan 4y ago
    The problem is that when you need to perform a task on some data being rendered by the GUI that is not supported by the GUI. Usually bulk tasks. Like, for all your docker containers, run a certain command. A compromise is that GUIs should print the commands that can be run to get the output they are rendering and to perform the actions they are doing. Like a little command palette at the bottom of the window. Then the user can always break out into terminal.
- vaughan 4y ago
  The other day I was doing some `make` stuff. I was passing in a bunch of env vars and flags. I wanted to tweak them between each run. I would have preferred to have check boxes to enable/disable certain flags. Rather than copying into Then in the output, I have a bunch of make tasks and child make files running. I care about the output for each makefile as it runs, but then would prefer it to collapse when its finished. Otherwise its too difficult to see each step of the build process. A terminal cannot do this. XCode does it kind of well. At the end of build too, when it reports errors, I'd like to jump up to the errors. Almost every command output I would prefer to view as a GUI table or as a webpage. The problem is that then, instead of just printing output, now I am dealing with a huge mess of frontend frameworks and build toolchains.
deleted 4y ago
[deleted]
layer8 4y ago
Not sure if it really “went back to”, but an important reason is that Microsoft dropped the ball on consistent and power-user-friendly Windows GUI, and the year of the Linux desktop remains perpetually in the future.

bitwize 4y ago

This is because as Linux started taking over the server space, it brought with it a culture of "stone knives and bearskins" tooling from old-school Unix -- and most applications these days are web applications. One of the major disappointments of recent years is seeing Microsoft backpedal from promoting Windows as the premier development platform and embracing (to extend or extinguish?) Linux with its command lije bullshit. Windows in the late 90s was an entire environment based on composable components, linked together via discoverable interfaces. It had a software composition story far superior to Unix pipes. We should be able to build entire web and cloud infrastructures by wiring components together visually, and using visual inspection tools to debug problems as they happen in the pipeline. Not monkey about with YAML and JSON.

bradrn 4y ago
> Windows in the late 90s was an entire environment based on composable components, linked together via discoverable interfaces. It had a software composition story far superior to Unix pipes. I’ve never heard anything about this (probably because it was before my time); could you elaborate?
- muststopmyths 4y ago
  Sounds like COM. Comparing a programming framework to pipes seems a bit over the top though. I don't know anyone who'd seriously advocate building a large application solely from small programs piping their output to other small programs. I've already complained previously about the new Microsoft though, so I have sympathy with the underlying sentiment :)
- zwkrt 4y ago
  I think parent is talking about the COM interface.[1] powershell still has a legacy of object oriented manipulation as opposed to text/line based manipulation. I’m too much living in Unix world to give more insight as to how well it functioned though. https://en.m.wikipedia.org/wiki/Component_Object_Model https://en.m.wikipedia.org/wiki/Component_Object_Model
necovek 4y ago
Imagined from the same fold as COM (which you are likely talking about) was CORBA, an international standard for "object" interoperability. Guess what came out of that? It's one of those systems that's perfect (as in perfectly abstracting away everything) but notoriously and impractically complex. COM is only slightly less so. The downfall of all the object-oriented approaches is that we don't really think about objects, but instead of actions ("functions") we perform, which is much simpler as well. Basically, you don't see bread and say bread->eat() (or at least your doctor will tell you not to :)) but instead look for something to eat() and then stick bread in it once you find it (eat(bread)).
- vaughan 4y ago
  person->eat(bread)
  - necovek 4y ago
    That's a good point. But as soon as you've got someone else who needs to eat (cat->eat(), dog->eat()...), it is still better to go with a functional approach: feed(person, bread) Basically, my abstraction was bad for that case, but it is so much easier to move from eat(bread) to eat(person, bread) and then rename that to "feed" than to introduce object inheritance/composition and think about the commonality between dog and person if all you want to do is feed them. Sure, there are cases where purely OOP approach is not burdensome, and may even be easier, but functional approach, as an explicit superset of possibilities, will usually be simpler and more understandable.
vaughan 4y ago
> We should be able to build entire web and cloud infrastructures by wiring components together visually 100%. I think this is the next wave of development. Back to the future. > Not monkey about with YAML and JSON. The key difference this time needs to be two-way sync between code and visual. Having a serialized format (YAML/JSON) for wiring at some level is important though, but it should be easily modifiable by humans. In the last wave, we left this two-way syncing behind. An example of this is XCode's NIB files and Interface Builder. NIB weren't designed for humans to modify so everything had to be done through IB which made certain things a pain, and created a lot of VCS churn. I've been thinking about whether we can achieve a two-way syncing (text <-> diagram) visual programming interface by interacting with the AST of a (subset of) an imperative language and using data flow tracing (via code instrumentation). I wonder what the minimal data structures needed are to represent most of configuration programming. Such as state machines, streams, graphs (dependency tracking).

sublinear 4y ago

Strongly disagree. GUIs are just a distraction. The same CLI knowledge can be used to write scripts for common tasks. GUIs don't add any value beyond visually showing some structure, but CLIs can do just the same and often do. Do you have any examples of tools where the GUI is more useful than the CLI, and could you explain why that is?

massysett 4y ago
> Do you have any examples of tools where the GUI is more useful than the CLI, and could you explain why that is? Browsing photographs.
jerpint 4y ago
I used to be of this opinion. Now I think more “GUIs are great once you’ve mastered the CLI and know what underlying operations you want to execute”. A GUI I discovered recently that I really like is docker-desktop. I used to do everything from the CLI. The gui gives me a much better overview of everything. If I need to dive in to the CLI, I know exactly where to go.
- vaughan 4y ago
  The problem is that when you need to perform a task on some data being rendered by the GUI that is not supported by the GUI. Usually bulk tasks. Like, for all your docker containers, run a certain command. A compromise is that GUIs should print the commands that can be run to get the output they are rendering and to perform the actions they are doing. Like a little command palette at the bottom of the window. Then the user can always break out into terminal.
vaughan 4y ago
The other day I was doing some `make` stuff. I was passing in a bunch of env vars and flags. I wanted to tweak them between each run. I would have preferred to have check boxes to enable/disable certain flags. Rather than copying into Then in the output, I have a bunch of make tasks and child make files running. I care about the output for each makefile as it runs, but then would prefer it to collapse when its finished. Otherwise its too difficult to see each step of the build process. A terminal cannot do this. XCode does it kind of well. At the end of build too, when it reports errors, I'd like to jump up to the errors. Almost every command output I would prefer to view as a GUI table or as a webpage. The problem is that then, instead of just printing output, now I am dealing with a huge mess of frontend frameworks and build toolchains.

deleted 4y ago

[deleted]

layer8 4y ago

Not sure if it really “went back to”, but an important reason is that Microsoft dropped the ball on consistent and power-user-friendly Windows GUI, and the year of the Linux desktop remains perpetually in the future.