It's been my experience that its this effect that makes students and beginners feel like its hard, while in actual (measured) fact, it's easier and leads farther, sooner. But of course the flip side is that it weeds out poor programmers sooner, as they can only survive by only twiddling your thumbs. P.S. And note that functional programs as measured at Ericsson tends to be equally shorter
The bottleneck of most software is maintenance, not the original writing. It might be less code, but can future maintainers, who may not have been part of the original team, read it, understand it, and be able to change it in a timely and safe manner?
Remember, it's not that there aren't skilled Americans to do the job, there aren't skilled Americans *available*. If you look at the highly paid IT/engineering jobs that require 10+ years or experience, almost every company out there has a bunch of openings *all the time*. They are very difficult to fill.
If a co wants "10 years of experience in X", even a citizen with 4 years of X and a PhD will not "qualify". You cannot manufacture experience. The co's need to be encouraged to break out of the HR paradigm of 10-in-X-or-bust mindset.
There often seem to be two different audiences for software products: those who just want it to work well and stay consistent, and those who like newfangled or fancy features and are willing to live with glitches and confusion to have them. It's hard to satisfy both types of users.
Ironically, Java lambda's are often used to work around its poor OOP model. In a good OOP language, it would be easy to add an "On Click" method to a given GUI widget. Seems like a straight-forward and common feature, but Java provides no easy to let the listener know about such a method, such that one has to talk to a GUI listener directly instead via lambda's. (Maybe there's a way around this, nobody I know has solved it yet, without side-effects.)
OOP is currently about turning everything into reusable, plug-able modules without needing to constantly repeat yourself.
Currently? Why did "they" change it?
It often fails at those goals because real-world variations-on-a-theme often don't fit a nice hierarchical taxonomy. Sure, OOP doesn't have to be tree-shaped, but it gets uglier than the alternatives when it's not.
You are exaggerating its popularity. OO domain modelling is dying out. Get some real science and real numbers, I'm tired of hollow opinions from blOOwhards.
Older versions of Windows have a "Favorites" sub-menu on the left side of File Explorer. When I had to convert to Windows 10 at work, the "Favorites" links were automatically migrated into something called the "Quick Access" (QA) menu. So far so good: it converted old stuff into its new convention.
However, "Favorites" used alias names, similar to naming a Windows Shortcut. But QA doesn't (at least not by default). Instead, QA uses the last actual folder name in the path as the displayed title.
I thought QA simply rudely renamed my Favorites titles, so I right-clicked on them to "fix" the titles. Turns out I wasn't looking at an alias, but the live folder name.
The result is I inadvertently renamed network folders used by hundreds of employees! Of course trouble-tickets started popping up like pop-corn. I put two and two together, and quickly renamed them back, and then went for a walk to dry off the sweat.
For what it's worth, per "OOP" here's my preferred definition of "object": a map or map-like data structure that can hold both attributes and behavior (or pointers to behavior). These units of behavior are typically called "methods". And objects facilitate easy or automatic referencing a parent object(s) for attributes or behavior not explicitly defined in a given map.
("Classes" are a language-specific variation or restraint on the concept.)
In short, a glorified map data structure (AKA "dictionary").
(a) you have not been exposed to good OOP code or (b) you are not smart enough to comprehend that OOP can be incredibly wonderful.
Re (a): Show us one! Show us a practical and realistic example app. Avoid those dealing biology, physics, or geometry because those are not representative domains. Most business objects are defined by laws or market forces, and subject to a lot of changes. Physics stays the same, but intellectual property and laws do not.
Maybe a college system that tracks students, teachers, classes, grades, etc. Then show us how OO makes it better in terms of fewer bugs, maintainability, etc. Invite readers to run some change scenarios on it.
Re (b): For the sake of argument*, let's say some of us are just inherently too dumb to get OOP (at least OOP domain modeling). Should we just exit software development? But what if we are perfectly productive using other paradigms/techniques? Just because we suck at paradigm X doesn't mean we also suck at paradigm Y.
And there are other skills involved in software engineering, such as people skills, writing skills, UI design, other IT skills such as server admin, and domain knowledge (knowing the customer's industry).
We may be good at these others but suck at OO. That's not reason enough to toss us because there are other important factors the org that hires us is weighing.
* I personally believe it's either a bunch of hooey, or a personal choice being mistaken for a universe truth.
I meant that related functions/methods and state can be grouped under a local or virtual name.
ref1 = new bigFooClass(...); ref2 = new bigFooClass(...);... ref1.attributeX = 7; ref2.attributeX = 42;
Here we assign a handy local shortcut reference name to each instant, and easily keep instance 1 (ref1) separate from instance 2 using our handy shortcut reference name.
For example, in the old days if you had two files open at the same time, it was too easy to visually or actually cross-mix the file handles between instances.
If PHP was so awful that I wasn't able to use it to make money
Sorry, I still don't see a strong relationship. An esoteric convoluted tool (ECT) could make one a lot of money because it's often hard to find experienced and skilled experts such that an org relying on an ECT system that needs maintenance would be willing to pay a premium for it.
There are well-paid Java coders and poorly paid Java coders; there are well-paid PHP coders and poorly paid PHP coders.
The supply versus demand versus difficulty relationship is complex and changes over time, and often driven by tech fads. I haven't seen any clear-cut patterns other than the rise and fall of techie supply can vary differently than a rise and fall of demand; and that if you are on the right boat at the right time, you can make good bucks.
We've managed to take something meant for web pages and figured out how to embed fucking operating systems into it.
You mean several operating systems, as each client (device) has a different browser brand and/or version, creating Client-Version-Combo-Hell, which I rant is arguably worse than DLL-Hell elsewhere in the story replies.
You are hopping back and forth between technical issues and personal finance. It's mixing apples and oranges such as to confuse the reader.
I believe it's best to evaluate a given language/tool's technical merit from it's earning power separately. Perhaps there is a relationship, which would make an interesting discussion if enough details were given.
I like the idea of using "Table Oriented Programming" for feature and variation management. For a simplified example, consider this table layout:
person (table) --------- personID hasFeatureA hasFeatureB hasFeatureC hasFeatureD hasFeatureEtc...
Each person instance (row) then has these Boolean "cells" filled in with Yes or No (or value parameters in some cases).
(A variation of this is a many-to-many table of "roles" for a given person, which is more flexible because we don't have to add columns for each new feature.)
This means a person can fulfill any role we have implemented by simply checking a box.
We don't have to dig around in or reshuffle hierarchies. We don't even have to define hierarchies or taxonomies* up front: we just check-mark the features we want, buffet-style.
Now, some combinations may not be allowed by law or shop rules, and we can put validation on our table to prevent or flag such combinations, such as a person not allowed to be customer and a vendor at the same time.
We can also have templates for common patterns so that a feature template can be applied to a given person to save time from manually marking each box.
And the implementation doesn't clog up our view of the features, for that's elsewhere. It's nice and compact to visually sift.
In practice it's often not so smooth to do all things this way, but a degree of it can bring about a lot of flexibility and reduce code reshuffling.
* One might point out that "person" is already declaring a kind of taxonomy. If corporations are later treated like people (SCOTUS-style), then calling it "person" may be a mistake. We can make a single generic object such as "entity" or "party" or something, but often that confuses maintainers in my experience. We sometimes have to force some concreteness into designs so people can relate to it.
A good many OO-domain-modelling (OODM) proponents agree that trying to force everything into hierarchical taxonomies fails in most domains and that "composition" OODM is the way to go (which is closer to the set-theory-based variation management I talked about). I'm surprised there are still hold-outs for "mass trees".
One can force things into hierarchies, but that doesn't mean one should. Objectively verifying that taxonomies don't violate certain rules says very little of their ability to be useful to maintainers or anybody else. Humans maintain code, not math. LSP is a narrow metric, like optimizing a car for gas mileage above anything else (room, comfort, speed, repair costs, etc.)
Most domain nouns I encounter either cannot be hierarchically classified, or any hierarchical classification is likely temporal, accidental, or forced.
In other words, one can take an given feature set and FORCE them into a hierarchy(s) and say, "See, I have LSP-passing trees!" But that says nothing of the quality or future-friendliness of such designs.
Perhaps over time designers can become "tree whisperers" to detect and codify hierarchical domain taxonomies properly (for a wide range of useful metrics). But it's not clear when this point is reached and if anyone can obtain that ability or just "special" people. Time has to test designs to see if they are reasonably worthy, and the designer may be retired by then.
and refactoring is necessary to adapt to that.
I agree that code-rework after requirements changes are necessary no matter what technique is used, but that doesn't tell me why tree-OODM is "better" at flexing or better at anything else.
Having some very good people on staff who get involved in these things, we generally do it right.
There are masters of any paradigm/technique. There are COBOL GOTO masters who can write and read GOTO code fast and easy. If a GOTO shop can find enough of those experts, they are humming! (Newer COBOL doesn't have to rely on GOTO's, by the way, but there's a lot of old code floating around.)
I suspect a lot of Grand Paradigm/Tool claims are purely personal: the tool fits YOUR mind(s) better. That's fine, but please don't extrapolate that to all minds and/or a universal truth without universal evidence.
Slashdot Mirror
The bottleneck of most software is maintenance, not the original writing. It might be less code, but can future maintainers, who may not have been part of the original team, read it, understand it, and be able to change it in a timely and safe manner?
If a co wants "10 years of experience in X", even a citizen with 4 years of X and a PhD will not "qualify". You cannot manufacture experience. The co's need to be encouraged to break out of the HR paradigm of 10-in-X-or-bust mindset.
There often seem to be two different audiences for software products: those who just want it to work well and stay consistent, and those who like newfangled or fancy features and are willing to live with glitches and confusion to have them. It's hard to satisfy both types of users.
Ironically, Java lambda's are often used to work around its poor OOP model. In a good OOP language, it would be easy to add an "On Click" method to a given GUI widget. Seems like a straight-forward and common feature, but Java provides no easy to let the listener know about such a method, such that one has to talk to a GUI listener directly instead via lambda's. (Maybe there's a way around this, nobody I know has solved it yet, without side-effects.)
Currently? Why did "they" change it?
It often fails at those goals because real-world variations-on-a-theme often don't fit a nice hierarchical taxonomy. Sure, OOP doesn't have to be tree-shaped, but it gets uglier than the alternatives when it's not.
Then fork KDE3 and tell 4+ to go fork themselves.
I was only trying to encourage you to clarify your claim(s) since earning power and tool "goodness" are not closely related.
And I'm not trashing PHP, largely because most the mainstream languages also suck such that PHP's suckage puts it roughly on par.
You are exaggerating its popularity. OO domain modelling is dying out. Get some real science and real numbers, I'm tired of hollow opinions from blOOwhards.
Instant burgers, Brilliant!
Practical examples are welcome.
Older versions of Windows have a "Favorites" sub-menu on the left side of File Explorer. When I had to convert to Windows 10 at work, the "Favorites" links were automatically migrated into something called the "Quick Access" (QA) menu. So far so good: it converted old stuff into its new convention.
However, "Favorites" used alias names, similar to naming a Windows Shortcut. But QA doesn't (at least not by default). Instead, QA uses the last actual folder name in the path as the displayed title.
I thought QA simply rudely renamed my Favorites titles, so I right-clicked on them to "fix" the titles. Turns out I wasn't looking at an alias, but the live folder name.
The result is I inadvertently renamed network folders used by hundreds of employees! Of course trouble-tickets started popping up like pop-corn. I put two and two together, and quickly renamed them back, and then went for a walk to dry off the sweat.
For what it's worth, per "OOP" here's my preferred definition of "object": a map or map-like data structure that can hold both attributes and behavior (or pointers to behavior). These units of behavior are typically called "methods". And objects facilitate easy or automatic referencing a parent object(s) for attributes or behavior not explicitly defined in a given map.
("Classes" are a language-specific variation or restraint on the concept.)
In short, a glorified map data structure (AKA "dictionary").
Okay, but please don't extrapolate this to managing personnel: it sounds painful.
Re (a): Show us one! Show us a practical and realistic example app. Avoid those dealing biology, physics, or geometry because those are not representative domains. Most business objects are defined by laws or market forces, and subject to a lot of changes. Physics stays the same, but intellectual property and laws do not.
Maybe a college system that tracks students, teachers, classes, grades, etc. Then show us how OO makes it better in terms of fewer bugs, maintainability, etc. Invite readers to run some change scenarios on it.
Re (b): For the sake of argument*, let's say some of us are just inherently too dumb to get OOP (at least OOP domain modeling). Should we just exit software development? But what if we are perfectly productive using other paradigms/techniques? Just because we suck at paradigm X doesn't mean we also suck at paradigm Y.
And there are other skills involved in software engineering, such as people skills, writing skills, UI design, other IT skills such as server admin, and domain knowledge (knowing the customer's industry).
We may be good at these others but suck at OO. That's not reason enough to toss us because there are other important factors the org that hires us is weighing.
* I personally believe it's either a bunch of hooey, or a personal choice being mistaken for a universe truth.
I meant that related functions/methods and state can be grouped under a local or virtual name.
ref1 = new bigFooClass(...); ...
ref2 = new bigFooClass(...);
ref1.attributeX = 7;
ref2.attributeX = 42;
Here we assign a handy local shortcut reference name to each instant, and easily keep instance 1 (ref1) separate from instance 2 using our handy shortcut reference name.
For example, in the old days if you had two files open at the same time, it was too easy to visually or actually cross-mix the file handles between instances.
Sorry, I still don't see a strong relationship. An esoteric convoluted tool (ECT) could make one a lot of money because it's often hard to find experienced and skilled experts such that an org relying on an ECT system that needs maintenance would be willing to pay a premium for it.
There are well-paid Java coders and poorly paid Java coders; there are well-paid PHP coders and poorly paid PHP coders.
The supply versus demand versus difficulty relationship is complex and changes over time, and often driven by tech fads. I haven't seen any clear-cut patterns other than the rise and fall of techie supply can vary differently than a rise and fall of demand; and that if you are on the right boat at the right time, you can make good bucks.
You mean several operating systems, as each client (device) has a different browser brand and/or version, creating Client-Version-Combo-Hell, which I rant is arguably worse than DLL-Hell elsewhere in the story replies.
You are hopping back and forth between technical issues and personal finance. It's mixing apples and oranges such as to confuse the reader.
I believe it's best to evaluate a given language/tool's technical merit from it's earning power separately. Perhaps there is a relationship, which would make an interesting discussion if enough details were given.
I like the idea of using "Table Oriented Programming" for feature and variation management. For a simplified example, consider this table layout:
person (table)
---------
personID
hasFeatureA
hasFeatureB
hasFeatureC
hasFeatureD
hasFeatureEtc...
Each person instance (row) then has these Boolean "cells" filled in with Yes or No (or value parameters in some cases).
(A variation of this is a many-to-many table of "roles" for a given person, which is more flexible because we don't have to add columns for each new feature.)
This means a person can fulfill any role we have implemented by simply checking a box.
We don't have to dig around in or reshuffle hierarchies. We don't even have to define hierarchies or taxonomies* up front: we just check-mark the features we want, buffet-style.
Now, some combinations may not be allowed by law or shop rules, and we can put validation on our table to prevent or flag such combinations, such as a person not allowed to be customer and a vendor at the same time.
We can also have templates for common patterns so that a feature template can be applied to a given person to save time from manually marking each box.
And the implementation doesn't clog up our view of the features, for that's elsewhere. It's nice and compact to visually sift.
In practice it's often not so smooth to do all things this way, but a degree of it can bring about a lot of flexibility and reduce code reshuffling.
* One might point out that "person" is already declaring a kind of taxonomy. If corporations are later treated like people (SCOTUS-style), then calling it "person" may be a mistake. We can make a single generic object such as "entity" or "party" or something, but often that confuses maintainers in my experience. We sometimes have to force some concreteness into designs so people can relate to it.
A good many OO-domain-modelling (OODM) proponents agree that trying to force everything into hierarchical taxonomies fails in most domains and that "composition" OODM is the way to go (which is closer to the set-theory-based variation management I talked about). I'm surprised there are still hold-outs for "mass trees".
One can force things into hierarchies, but that doesn't mean one should. Objectively verifying that taxonomies don't violate certain rules says very little of their ability to be useful to maintainers or anybody else. Humans maintain code, not math. LSP is a narrow metric, like optimizing a car for gas mileage above anything else (room, comfort, speed, repair costs, etc.)
Most domain nouns I encounter either cannot be hierarchically classified, or any hierarchical classification is likely temporal, accidental, or forced.
In other words, one can take an given feature set and FORCE them into a hierarchy(s) and say, "See, I have LSP-passing trees!" But that says nothing of the quality or future-friendliness of such designs.
Perhaps over time designers can become "tree whisperers" to detect and codify hierarchical domain taxonomies properly (for a wide range of useful metrics). But it's not clear when this point is reached and if anyone can obtain that ability or just "special" people. Time has to test designs to see if they are reasonably worthy, and the designer may be retired by then.
I agree that code-rework after requirements changes are necessary no matter what technique is used, but that doesn't tell me why tree-OODM is "better" at flexing or better at anything else.
There are masters of any paradigm/technique. There are COBOL GOTO masters who can write and read GOTO code fast and easy. If a GOTO shop can find enough of those experts, they are humming! (Newer COBOL doesn't have to rely on GOTO's, by the way, but there's a lot of old code floating around.)
I suspect a lot of Grand Paradigm/Tool claims are purely personal: the tool fits YOUR mind(s) better. That's fine, but please don't extrapolate that to all minds and/or a universal truth without universal evidence.
And most still only promises.
Have them open their paychecks
"My God, it's full of trolls!"
Hey, if AQ gives better ISP service than the big telecoms, I'm signing the hell up!
It's not more evil, just switching Devil brands.
The terrorists should declare themselves corporations, THEN they'll get freedom-of-speech.