I always find this assertion amusing. While it is true that development has stalled, the stall began with java. Java did not usher in a wave of innovation, which has somehow petered out. It merely allowed the ignorant to recreate the paradigms of the 1960's.
The web, so far, is semantically implemented exactly the same way as COBOL/3270 code, circa 1970. You have a dumb datastore, managed by bespoke code, talking to a semi-smart block mode terminal. The only difference is some syntax (COBOL on the mainframe vs. java on the server, 3270 edit language on the terminal vs. html/javascript on the browser), but the method is identical. Better ways were discovered between 1970 and 2000, but the folks, young-uns mostly, who stole the process were quite ignorant of these. They revel in "languages" rather than systems.
The principle reason this is so amusing is that there was far and away more innovation in systems through the 1980's. There were multiple mainframe machines, each with a specific instruction set (aka, architecture), as well as an emerging group of mini-computers, again, each with a specific architecture; among them explicitly parallel machines. Machines were innovated to solve problems heretofore unsolved. We've devolved to a near mono-culture: the X86 instruction set and z/ instruction set. The ARM processor is gaining some traction, and may pull us out of the weeds; it is aimed at a different problem.
All this kerfufle about concurrent languages is so misinformed, again, because those who consider themselves players weren't around when parallel architectures were first developed in the late 1970's. Those architectures basically went nowhere, and not because they were poor architectures, but because there aren't many problems (in the computer science sense) that benefit from parallelism. As to concurrency in linear problems, see Amdahl's law (it's been mentioned before).
The notion that ad hoc language creation will make it easy to use multi-core/processor machines to execute linear problems (virtually every application which is not a server) more efficiently, is fantasy. Even without Amdahl's law, simple logic (which one may argue is all Amdahl was expressing) makes it clear.
The problem which is staring the industry in the face is the re-siloing of applications as a result of web kiddies' love affair with languages rather than systems, which leads to the "explosion of data". Dr. Codd, bless his heart, gave us the answer: replace code with disciplined data. But because these self-appointed players have a hammer called "languages", they seek to create "new" ones to solve a problem (nail) which is not language solvable.
To accept that the solution is to implement shared, disciplined datastores, is to accept that each application is not going to be its own little fiefdom. Further amusement here, in that Bruce (and many others, as well) make much of "community" of coders in these discussions, but absolutely reject the notion that "community" can be applied to datastores. NEVER do that. If they did that, then there'd be so much less code to build. There'd be so much less "freedom" to make up one's own rules about this and that. So we get a Tower of Babel; each cabal of coders pissing on its territorial boundaries. My code. My data. You don't understand what I'm trying to do here. And so forth. And so very mainframe 60's. Your grandfather said the same thing.
Note that the multi-core/processor machine is not a new architecture, but rather just the aggregation of existing Von Neumann machines (linear execution with an existing instruction set). These are not machines based on an architecture which accepts code and parallelizes it for execution by some new non-linear instruction set.
This is all wasteful wheel spinning. The linear instruction sets are (save for register size expansion) fundamentally unaltered for 30 years (nearly 50 for the z/). ARM takes RISC to a logical conclusion, and attacks an utterly different problem from that of the X86 machines.
This proliferation of languages is scribbling around the edges. They all have to (compile to and) execute on the same old X86 instruction set. You can't (well, really) push a square peg in a round hole. Today's multi-machines aren't really designed for parallel algorithms (and how many of those are there?), they're just miniaturized versions of the IBM 360 MFT (that's 1965 for those keeping track) machines.
The answer to the density/speed/heat problem won't be found in such ad hoc language sand castles. It will require some really smart hardware engineers (are there any left?) figuring out the successor to the Von Neumann architecture. Have fun making new languages, but don't delude yourselves into thinking that you'll actually be solving the real problem. The problem isn't in high level application languages. The answer is either in databases (replacing code with data, leaving display to application languages) or in new hardware architecture.
Your talk was a good one. I liked it and I didn't knew more about ScalaTest more than the nam; and I liked the "FunSuite". I saw that you was very passionate about it and really liked an enjoyed to use Scala and ScalaTest to use it as an "enabler" into projects. You was prepared to "defend" by questions, a few came; and I had the intuition that you where a bit "desillusioned" (perhaps wrong word, I am not a native) about the reception of "the cool" things.
Those cool and beauty things remember me the elegant Smalltalk language and also after a few years concepts of ruby; its the same with Scala. If you a starter of Smalltalk like me, you can see how "elegant" and concise a language can be; but if you started with C/Pascal you are lost on that path (I think so; but there are exceptions).
So when I saw you so passionate about ScalaTest and now read your BlogPost, I connect them, and so I got that impression... perhaps I am wrong.
> > To innovate does not mean to make changes to something > > established > ... > > I can find other definitions... > > http://en.wikipedia.org/wiki/Innovation > > Well, the 2nd sentence of that definition says > > "It may refer to incremental and emergent or > radical and revolutionary changes in thinking, products, > processes, or organizations" > > Didn't somebody a long long time ago complain about the > sad state of cosmic computing and write that there was > "nothing new under the sun"? > > You and Bruce need to be more innovative in your > complaining. :-)
Well, it's 10% incremental and 90% radical, if you wish :-).
> To accept that the solution is to implement shared, > disciplined datastores, is to accept that each application > is not going to be its own little fiefdom. Further > amusement here, in that Bruce (and many others, as well) > make much of "community" of coders in these discussions, > but absolutely reject the notion that "community" can be > applied to datastores. NEVER do that. If they did that, > then there'd be so much less code to build. There'd be so > much less "freedom" to make up one's own rules about this > and that. So we get a Tower of Babel; each cabal of > coders pissing on its territorial boundaries. My code. My > data. You don't understand what I'm trying to do here. > And so forth. And so very mainframe 60's. Your > r grandfather said the same thing.
So very true! you nailed the problem 100%. There will be no real progress in computers until data is unified and separated from code.
As for concurrency/parallelism, 30 years ago Transputer shown the way (again, not real innovation, because the Transputer was based on existing ideas). As the wikipedia article says (http://en.wikipedia.org/wiki/Transputer), the ideas Transputer brought to the table have re-emerged today in different systems.
Maybe developing software is not at fun as it used to be. With all of this TFD/TDD and massive enterprise patterns, even some of the simplest tasks require tons of extra code and overhead. Where is the fun in that? I also think we have so many frameworks, servers, plugins, and assorted junk that the joy of hacking together something requires complex overhead. Along these lines, there are not many new things to build. How many ORMs or shopping carts do we need? I think you might see some excitement in areas such as mobile computing and parallel architectures. There might be some buzz around cloud computing.
Maybe the carrot is not there anymore. I have seen many good developers move into management or other careers because wages are being deflated by off-shore resources and H1x workers willing to break their backs for peanuts. I know this does not speak for the entire industry, I am just saying (in the corporate world), some of the people who might have been innovators are no longer holding the positions to be innovators.
> Maybe developing software is not at fun as it used to be. > With all of this TFD/TDD and massive enterprise patterns
The real area for innovation is in eliminating a lot of this. I am currently responsible to analyzing and correcting a lot of code that was delivered by a large consulting firm. I would say 75-80% of the code is redundant, unnecessary and has nothing to do with business or logistical requirements. A lot of this code merely increases the cost of maintenance without adding any value.
The enterprise patterns and frameworks that are so common in IT are designed to take the creativity out of development. Whether that's a good goal is debatable but I personally think they fail in this regard. Very few of these technologies that are considered considered indispensable actually help with the real problems faced in a chaotic IT environment. Many of them actually make things a lot worse.
> Maybe the carrot is not there anymore. I have seen many > good developers move into management or other careers > because wages are being deflated by off-shore resources > and H1x workers willing to break their backs for peanuts. > I know this does not speak for the entire industry, I > , I am just saying (in the corporate world), some of the > people who might have been innovators are no longer > holding the positions to be innovators.
Of course. It started a few years ago. A young-un of my acquaintance noted that his peers were opting out of systems because they couldn't justify the cost of the degree. In India (this happened at a time and place where there was an invasion), education is highly subsidized, so the wage earned need be less. Not to mention, this is an economic warfare tactic they're employing (pun intended).
If our capitalists really cared about the tech future, and our country's place in it, they wouldn't remove the incentive to pursue the work. Kind of hypocritical for Chicken Little to decry the sky falling while shooting down everything that moves.
"If our capitalists really cared about the tech future, and our country's place in it, they wouldn't remove the incentive to pursue the work. Kind of hypocritical for Chicken Little to decry the sky falling while shooting down everything that moves."
This one had me laughing out loud in my cube! I hope you don't mind my using this one at some point.
> If our capitalists really cared about the tech future, and > our country's place in it, they wouldn't remove the > incentive to pursue the work. Kind of hypocritical for > Chicken Little to decry the sky falling while shooting > down everything that moves.
The problem really comes down to management problems. Outsourcing is a knee-jerk reaction. Everyone assumes it sames money but don't even bother with the math. On a recent project, our contractors gave us a measly 15% discount on off-shore developers. Timezone issues and coordinating the holidays of three nations cost far more than that alone. Combine that with the inability of those developers to deliver working code as specified and the costs spiral out of control.
What most businesses seem to fail to realize is that outsourcing has made the average developer in the US far more qualified than they were 5 or 10 years ago (mostly through attrition) and these developers are more easily found and will accept lower wages. Saturation in India has had the opposite effect there. There are definitely good and great technical people there but they are already working for relatively good wages. The idea that there is a bottomless well of smart qualified developers willing to accept paltry wages just over the horizon is absurd.
> The real area for innovation is in eliminating a lot of > this. I am currently responsible to analyzing and > correcting a lot of code that was delivered by a large > consulting firm. I would say 75-80% of the code is > redundant, unnecessary and has nothing to do with business > or logistical requirements.
James - once you are done with this, I'd love to hear some of your thoughts and conclusions. What anti-patterns and bad practices did you find?
I faced a similar issue several years ago, with some horribly redundant code. I remember coming home and proudly telling my wife "hey, I wrote negative 1000 lines of code today".
As long as the US allows H1x workers in the US, those workers will agree to work for lower wages. Yes, I know the wages are supposed to be on par with other workers; however, the un-accounted-for overtime drives that salary into the ground. A local worker may object to excessive OT; unlike many of the H1x workers who will gladly work whatever hours are asked. They will do whatever is needed because the fear of losing their status far outweighs the working conditions. This is where there will be an endless supply of low-wage workers (in the USA, anyway).
> I faced a similar issue several years ago, with some > horribly redundant code. I remember coming home and > proudly telling my wife "hey, I wrote negative 1000 lines > of code today".
I've had those days too. I'm glad I'm not the only one that is proud of them :-)
> > The real area for innovation is in eliminating a lot of > > this. I am currently responsible to analyzing and > > correcting a lot of code that was delivered by a large > > consulting firm. I would say 75-80% of the code is > > redundant, unnecessary and has nothing to do with > business > > or logistical requirements. > > James - once you are done with this, I'd love to hear some > of your thoughts and conclusions. What anti-patterns and > bad practices did you find?
I've seen most of them before. One recent one is the the misuse of constants: psuedo code:
if (input.trim().equals(FIRST_NAME) {
setName(input);
}
/// ...
if (getName() != null) {
output.setAttr(FIRST_NAME, getName());
}
All the above accomplishes is that every new attribute requires a bunch of code changes as this kind of logic is repeated in every layer.
My real pet-peeve is the use of code generation against WSDLs. WSDLs are bad enough as it is. The last thing I need is tons of code strongly coupled to them. We have a lot of little utility web services now that do nearly the same thing against different targets but each one is generated from a separate WSDL. That means they all have different 'objects' to work with and each one has the logic redefined against different type hierarchies. Then the real-world necessitated we version the WSDLs. This means we have to branch the code just to support things like the addition of a new trivial attribute.
> I faced a similar issue several years ago, with some > horribly redundant code. I remember coming home and > proudly telling my wife "hey, I wrote negative 1000 lines > of code today".
Yep, it feels like I've written a net 0 lines of code in my career.
Flat View: This topic has 164 replies
on 11 pages
[
«
|
12345678
|
»
]
Previous Topic
