4 ms·

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

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).

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).