3 ms·

Why couldn't we have achieved this assembly-line production system with procedural programming? Just separate the project into files, assign each programmer to

by tboyd47 12y ago

Why couldn't we have achieved this assembly-line production system with procedural programming? Just separate the project into files, assign each programmer to a file, say, "Write a function called X, that takes input A, and returns output B," the manager writes the main() function that pulls them together, and there's your assembly line. It may be a dumb question, but I'm honestly asking.

bane 12y ago
In a sense you do. Most OO languages like Java are procedural languages as well. But OO offers the "advantages" of bundling everything in a given work-unit together. While something like C may leak state or names all over the place and you end up with similar/same methods being improperly used and that all needs to be tracked or disambiguated somehow. Lots of people consider namespacing and packaging up your source well as a way to do this. I think that works up to a point, but once you start hitting really big projects, I think the way that Java enforces and cleans up some of this optional stuff and makes these things as part of the language makes it a little more natural. Instead of having to be careful about your work (meaning if you aren't something will go wrong), you simply have to do the best practice to make progress. On smaller projects, where the manager can review every commit, every line of code, every way that work was done, and can enforce a cohesive and singular idea about how it should be done, it can work. But once the scope expands beyond what one management drone can handle it starts to become something that falls into the next layer of Management Science abstraction. tl;dr Making things that are optional in some languages into requirements (or the code won't work) seems to have been a good optimization.
- deleted 12y ago
  [deleted]
waps 12y ago
Because most real applications don't model very well as a dataflow system at all. If you're thinking of linux utilities, I'm sure you see everything "works fine" as a dataflow system. Now imagine writing a complex application like Excel, or Photoshop procedurally. It's not impossible. During the Windows 3 series that was actually done. Here's how it looks : http://www.transmissionzero.co.uk/computing/win16-apps-in-c/ http://www.transmissionzero.co.uk/computing/win16-apps-in-c/ Read through it. Ideally install Borland C++ in a windows 3.1 in Dosbox and make it work. Then you will fully understand why people switched to OO. But the more general reason is this : procedural programming doesn't allow you to raise the abstraction level of your code more than a bit. OO allows for more "distant" abstractions. Algorithms that are far further removed from the actual datatype being operated on. Since we've seen a regression in program complexity due to web browsers being the main application delivery method, OO is falling out of favor. On the other hand, maybe mobile development is simply the pendulum already swinging back. Both android and ios apps are OO apps, by necessity. And as everybody (hopefully) agrees, they beat the pants of websites.
- tboyd47 12y ago
  Not necessarily. For apps that don't have rich UIs (i.e. apps that could practically be websites), WebViews can reduce cost by allowing you to use the same HTML for both iOS and Android apps. So I think it's really more of a grey area depending on the situation. But yeah, I wouldn't want to write Excel in procedural C.

by tboyd47 12y ago

bane 12y ago

In a sense you do. Most OO languages like Java are procedural languages as well. But OO offers the "advantages" of bundling everything in a given work-unit together. While something like C may leak state or names all over the place and you end up with similar/same methods being improperly used and that all needs to be tracked or disambiguated somehow. Lots of people consider namespacing and packaging up your source well as a way to do this. I think that works up to a point, but once you start hitting really big projects, I think the way that Java enforces and cleans up some of this optional stuff and makes these things as part of the language makes it a little more natural. Instead of having to be careful about your work (meaning if you aren't something will go wrong), you simply have to do the best practice to make progress. On smaller projects, where the manager can review every commit, every line of code, every way that work was done, and can enforce a cohesive and singular idea about how it should be done, it can work. But once the scope expands beyond what one management drone can handle it starts to become something that falls into the next layer of Management Science abstraction. tl;dr Making things that are optional in some languages into requirements (or the code won't work) seems to have been a good optimization.

deleted 12y ago
[deleted]

waps 12y ago

Because most real applications don't model very well as a dataflow system at all. If you're thinking of linux utilities, I'm sure you see everything "works fine" as a dataflow system. Now imagine writing a complex application like Excel, or Photoshop procedurally. It's not impossible. During the Windows 3 series that was actually done. Here's how it looks : http://www.transmissionzero.co.uk/computing/win16-apps-in-c/ http://www.transmissionzero.co.uk/computing/win16-apps-in-c/ Read through it. Ideally install Borland C++ in a windows 3.1 in Dosbox and make it work. Then you will fully understand why people switched to OO. But the more general reason is this : procedural programming doesn't allow you to raise the abstraction level of your code more than a bit. OO allows for more "distant" abstractions. Algorithms that are far further removed from the actual datatype being operated on. Since we've seen a regression in program complexity due to web browsers being the main application delivery method, OO is falling out of favor. On the other hand, maybe mobile development is simply the pendulum already swinging back. Both android and ios apps are OO apps, by necessity. And as everybody (hopefully) agrees, they beat the pants of websites.

tboyd47 12y ago
Not necessarily. For apps that don't have rich UIs (i.e. apps that could practically be websites), WebViews can reduce cost by allowing you to use the same HTML for both iOS and Android apps. So I think it's really more of a grey area depending on the situation. But yeah, I wouldn't want to write Excel in procedural C.