4 ms·

At the heyday of the madness people were busy building object-over-network abominations like CORBA. There was even an unpleasant period of time in the 90's whe

At the heyday of the madness people were busy building object-over-network abominations like CORBA. There was even an unpleasant period of time in the 90's when people tried to make some of the Linux OS distro end-user apps run off of CORBA to bring about the interconnected "sea of objects" vision, slowing things down a lot. No wonder OO style is widely overused. It's overused in part, because it's easily sold. It's easy to make sound-bites out of the doctrine. At the same time, it's a bit nebulous and it's easy to describe all of reality this way at first glance. (That said, in the right hands, it can make for some dandy, clean software. The tricky part is the "right hands.") Basically, software is organizational politics. Software methodologies are dogma, with nothing to back them up, except maybe some savvy design and at times some mathematics. However, these aren't sufficient to deal with the complexities brought in by business needs, the real world, and the complications of developer communities. We're back in the alchemy days of the programming discipline. This is perhaps why minimalism often rules the day. Do as little as possible. Make do with as little as possible. Make apps and modules as small as possible. As much as possible, do no harm.

deleted 8y ago
[deleted]
0815test 8y ago
> There was even an unpleasant period of time in the 90's when people tried to make some of the Linux OS distro end-user apps run off of CORBA to bring about the interconnected "sea of objects" vision, slowing things down a lot. That was a thing on the GNOME desktop (GNOME being short for GNU Networked Object Model Environment). The CORBA framework was called bonobo, and it was basically a very early version of what's now achieved via dbus. KDE had its own equivalent, known as DCOP. AIUI, both systems were replaced altogether when dbus became a thing.
smileypete 8y ago
>Basically, software is organizational politics. I'd go further to say that software management is (often, mostly?) organizational politics. Software itself is about the flow of control and data, trouble often follows where dogma obscures this fundamental.
- stcredzero 8y ago
  Software itself is about the flow of control and data, trouble often follows where dogma obscures this fundamental. Trouble always follows where dogma conflicts with first principles and empirical data. More correctly, a significant part of software development is organizational politics. The "flow of control and data" inevitably gets you embroiled in that.

deleted 8y ago

[deleted]

0815test 8y ago

> There was even an unpleasant period of time in the 90's when people tried to make some of the Linux OS distro end-user apps run off of CORBA to bring about the interconnected "sea of objects" vision, slowing things down a lot. That was a thing on the GNOME desktop (GNOME being short for GNU Networked Object Model Environment). The CORBA framework was called bonobo, and it was basically a very early version of what's now achieved via dbus. KDE had its own equivalent, known as DCOP. AIUI, both systems were replaced altogether when dbus became a thing.

smileypete 8y ago

>Basically, software is organizational politics. I'd go further to say that software management is (often, mostly?) organizational politics. Software itself is about the flow of control and data, trouble often follows where dogma obscures this fundamental.

stcredzero 8y ago
Software itself is about the flow of control and data, trouble often follows where dogma obscures this fundamental. Trouble always follows where dogma conflicts with first principles and empirical data. More correctly, a significant part of software development is organizational politics. The "flow of control and data" inevitably gets you embroiled in that.