Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister

Jaron Lanier is a Schmuck

by Dominus (Parson)
on Dec 14, 2000 at 10:33 UTC ( #46585=perlmeditation: print w/replies, xml ) Need Help??

Caution: The following article is very grumpy.

Ovid posted a node recently that had a link to this rancid article. The rancidity was not Ovid's fault of course, and I would like to thank him for pointing to it.

The article is about some super-genius named Jaron Lanier, who must be really k00l, because he hangs with Sean Lennon. Jaron has this to say for himself:

"The hardware side of computers keeps on getting better and cheaper at an exponential rate," writes Lanier. "[But] this breathtaking vista must be contrasted with the Great Shame of computer science, which is that we don't seem to be able to write software much better as computers get much faster."

Which is, uh, false.

OK, story time. Back in the 1970s, IBM assembled a big team of programmers to produce a new product. They spent millions of dollars and hundreds of programmer years. The outcome was the IBM Fortran H compiler. It was a really excellent compiler.

Back in the 1970's, that's how you wrote a compiler. That's how much it cost and that's how long it took.

These days, if you are nineteen years old and going to university to get a CS degree, you take a one-semester class called 'Compiler Design'. As your final project for that class, and maybe your midterm project also, you write a compiler. Total cost, zero. Total programmer-years, 0.67. It won't be a very good compiler, but a third-year CS student is not a very good programmer.

Jaron Lanier has the gall to say that we don't know how to write software any better than we did before, when every nineteen-year-old kid is now expected to do the work of a crack team of programmers in half the time.

Thirty years ago, Perl would have been completely unthinkable. There were 'list-processing languages' and 'string-processing languages'. Nowadays, if your language doesn't have list processing and string processing and a ton of other stuff, nobody will use it. People won't even bother to laugh at it. Thirty years ago recursion was a weird and difficult concept and most languages didn't support it.

Thirty years ago, there were no window systems. If anyone had had the idea to write a widget toolkit, they would have failed, because there was no OOP. Heck, forget OOP. Thirty years ago, there was hardly any structured programming.

Thirty years ago, regexes had just been invented and it was big news that you could use them for pattern matching. Thirty years ago hashes were a difficult concept.

Thirty years ago, nobody knew how to index 1300 million web pages and then instantly find the ones that people wanted. Nobody would have dared to try.

Thirty years ago, the idea of NP-completeness had not been invented. Nobody had the slightest idea that some problems were intrinsically hard. Nobody had even seriously thought that it might be possible for a problem to be intrinsically hard.

You may not believe how primitive was our understanding of network programming thirty years ago. Thirty years ago, the guys designing the telnet protocol for the ARPAnet (this was before the internet) were trying to figure out how the protocol should communicate the details of the line-wrapping discipline. Today if you tried to include line-wrapping in a remote login protocol, everyone would laugh at you. "Let the program on the remote end deal with it," they would say. They might add "Duh! Everyone knows that." They would be right. The ARPAnet guys eventually figured that out. Too bad Jaron Lanier wasn't around then; he could have saved them a lot of time.

Bah. Anyone who tells you that we haven't made progress in software is selling something that isn't worth buying.

"Great Shame of Computer Science," my butt.

Replies are listed 'Best First'.
Re: Jaron Lanier is a Schmuck
by dws (Chancellor) on Dec 14, 2000 at 14:04 UTC
    Devil's advocate time.
    "The hardware side of computers keeps on getting better and cheaper at an exponential rate," writes Lanier. "[But] this breathtaking vista must be contrasted with the Great Shame of computer science, which is that we don't seem to be able to write software much better as computers get much faster."
    Behind this statement is the observation made 30 years back by Jerry Weinberg that when you peel back the onion on most technical problems in software, you'll quickly get to a people problem. If you think the people side has improved over the past 30 years, read Weinberg's "The Psychology of Computer Programming," written in 1971. Or better, pick up the Silver Anniversary Edition (1998), which adds some commentary on how well the original has held up. The problems in software that Weinberg talked about 30 years ago are ones you still see today.

    Sure, we're seeing multiplier effects based on software tools getting better, but having been in this business for long enough to have lived through long-range trends, I don't see that we're much better at simple things like communicating with each other than we were 30 years ago. We have better tools, and improved methodologies, but the classes of problems I see in development today differ from those I saw 20 years ago only in detail. We have interfaces based on objects and UML to describe them, but we still get "oops, didn't I tell that that we changed the design?" or "yeah, it's more complicated to do this this way, but I'm getting to use this cool new algorithm/pattern" on a regular basis. People or groups don't get along, and their disagreements spill out into the product. Introverted developers still let themselves get run over by Extroverted Marketing managers in schedule negotiations, and products still suffer because time for QA got squeezed out at the end of a death march. In the meantime, I have a Palm V in my pocket, more computing power in my study than most colleges had 30 years ago, and am burning CDs for backup instead of waiting in line to put a magtape onto a tape drive.

    Software development is a human activity, and we're not any better at being humans than we were when we were feeding carddecks into room-sized mainframes.

      Said []:

      > Software development is a human activity, and we're not any better at being humans...

      That may be true. But if that's the cause of whatever Jaron Lanier thinks he sees, then it has nothing to do with "Computer Science", so I'll stand by my assessment of him.

(Ovid - on the shoulders of giants)
by Ovid (Cardinal) on Dec 14, 2000 at 22:29 UTC
    Thanks for some great comments regarding that article. I liked your points and think I have not changed, but "shifted", my mind a little bit.

    Maybe the software is nice, but many programmers still suck. Much of what he have today is built upon past knowledge. That's a good thing because experience counts. But really, despite the crud that Matt Wright spews out, his code is often better than much of the "production" code out there. Some of the dreck that I've had to work on is a crying shame. What's a crying shame isn't necessarily that it's so bad, but that it's so easy for me to spot the flaws. I am NOT a programming guru. I work hard to learn more and to find newer and better ways of doing things, but I have a long way to go.

    Would you agree with me if I said "programmers still suck?" Much of what you mention above is based upon past successes. The people who worked with these ideas were brilliant pioneers and certainly we have some today. But I am still concerned about the mass of uneducated programmers that we have today. They ride the "gravy train" provided for them by companies desperate to have anyone who can "do the job" -- whatever that means.

    An interesting idea was raised in the previous thread on this topic: licensed programmers. A few months ago, some friends and I were discussing trying to formulate a group, or "guild", for independant certification of computer professionals1. It initially grew out of an idea where geeks would for an association to defend "ethical" principals. Programmers wouldn't work for companies that pull stunts like etoys, for example. There was enough disagreement regarding "ethical" that somehow the idea evolved into "guild" concept.

    The guild was a fairly straightforward idea: having and MCSE or RHCE is nice for the boss, but can you really do the work? I know people who have CS degrees who can't code worth a darn (one actually argued with me that liberal use of "goto" is a good thing). Sigh. Our frustration stemmed from the fact that programmers who build upon past successes aren't suddenly good programmers. Sure, I can build a a dynamic Web site and toss on search engines and a nifty database back end. If you threw me back 5 years ago, much of what I do would cause a lot of oohs and ahhs. Today, it's recognized that I am standing on the shoulders of giants. In no way does this make my code better unless I am willing and able to take the time to learn why the "giants" wrote such nifty code.

    This has unintended consequences which causes modern software to have new problems. Ten years ago, did most people sit around and worry about their credit card being stolen online? Fifteen years ago, we worried about whether we should buy and IBM, Apple, or Atari because we wondered who would win. But by and large, whenever I worked on those systems, I didn't find my machine crashing every twenty minutes with a blue screen of futility2. Software apps were small (well, with 64K of memory, they had to be) and were focused on the task at hand. Why the hell does my word processor have an embedded photo editor? More features does not mean better software.

    To rehash my point: standing on the shoulders of giants does not make me a giant. Software is bigger and more glamorous, but I think that companies are in such a mad rush to hire people that they just don't care/know if what they are putting out is any good. I acknowledge that the overall level of code quality is better: less "spaghetti" code, greater modularization, etc, but it's a slow and painful process. Our profession would be better if we found some way to address this.


    1. I suggested the name of our site be, but I got a lot of blank stares. :(
    2. Of course, I could be looking at this with my rose-colored nostalgia glasses.

    Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

      I know this is will probably strike many as not proper monestary behavior, but the title of Ovid's piece has me cackling to the memory of an old tune.

      If you have real audio cackle along to Standing On the Shoulders of Freaks

      Ok downvote me now.. I'll get back to my studies

      A guild of programmers would be an interesting idea. Currently we have many, many ways to become a qualified programmer but qualified does not automatically equate to good. A point of example is my... erm... friend from uni *cough* She now has a masters degree in computer science, and a very good one at that... I know, I wrote most of the assignments for her :P

      Me? I dropped out half way through my second year of my BSc :)

      So, which of us is the better programmer? Obviously this is an extreme case but the point is there. She is considerably better qualified than me yet would have problems displaying 'Hello, world' on the screen. I write programs for a living and, even with no qualifications beyond my Brainbench grading, must be doing something right... people keep on offering me more and more money to do it :) :) :) :)

      A guild that just offered qualifications would be next to useless... there are literally hundreds of other ways to get those qualifications. A guild that maintained a level of membership based on it's members consistantly meeting fixed criteria would be totally revoloutionary.

      It is certainly worth thinking about...

      It's all very easy to say that programmers shouldn't work for places like foo that do bar if you've never been in that position. What if you take a great job at foo, they treat you well, you get to hack Perl all day, and then one morning Slashdot reports that one of the lawers there just did bar. Should you just bail on a great thing because one lawyer did something you don't fully approve of?

      My point is just that it's not as clear as you may think. There were lots of great people at eToys, and abandoning your job at the first sign of trouble doesn't seem like much of a solution.

Re: Jaron Lanier is a Schmuck
by lemming (Priest) on Dec 14, 2000 at 11:05 UTC
    I'm stating the obvious, but Mr. Lanier has to make bold statements like that to sell himself and get to stay k001.

    However, I think the point that can be gotten is that we have programmers fresh out of school doing the majority of program design while the experienced ones are being managers. And being management these days seems to be mainly political battles. Why do it then, $$$ or power. And good programmers rarely make good managers. So the shame is not in Computer Science, but the way business is set up now. If it doesn't produce a press release, it's not worth the effort.

    Maybe I should go take an anti-cynical pill
      Any thoughts as to solutions? Much of the difficulty seems to be companies with a large IS staff acting as if it's two different companies - an "us versus them" mentality. One time, a headhunter arranged an interview with one company for which I was woefully underqualified. They brought in one of their software developers and I was asked a long list of technical questions about mainframes. Since I had no mainframe experience, I kept saying "I don't know about that." After I said that six or seven times, I stopped her and asked "this is the bad part of the interview, isn't it?" Everyone laughed themselves silly and I wound up with a new job and a substantial pay raise. Huh? Clearly, the developer was not impressed with my technical ability, but management was impressed with my demeanor. Who cares what the developers think? (On the other hand, see this post of mine for a balancing viewpoint)

      It seems I was hired, in part, because the management was impressed with my poise during the interview. While I went on to do great work with them (and a solid reference with a definite "willing to rehire" when I left), I shouldn't have been hired on "poise." Admittedly, there were some mitigating factors that I won't mention as they'll seem like bragging, but I question the decision to hire me.

      How do managers assess a programmer? Plenty of programmers can talk the talk and then stumble the walk. Bringing in "programmers" to question me is not necessarily an answer. If I was interviewing with this company, I would be highly suspicious of the ability of their programmers to adequately assess my ability. I truly believe that an independant "guild" or something similar (that's not tied to a particular product like the MCSE) could greatly benefit our profession. I just discovered, which purports to create such a guild. I don't know anything about them -- this isn't an endorsement -- but it might be a start.


      Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

        A lot of studies have been conducted in the last 20 years trying to identify the best predictors for success when hiring new employees. Companies bet a lot of money on new employees: good ones make the company lots of money. Bad ones (at best) don't help the bottom line and (at worst) COST money. The results of these studies show that "technical skills" (i.e., how well you can perform the technical requirements of the job) are not nearly as good a predictor of success as the non-technical skills related to the job. The "non-technical" skills I'm talking about are general, touchy-feely things such as making sure you don't (for example) hire an introvert to be a salesman, or hire someone who prefers to work alone and expect them to work in a team environment. Regular old "technical skills" can be taught to the right person in time, but you'll never be able to teach a non-detail oriented person a subject like accounting. It just won't work.

        The bottom line is that the enlightened manager is much, much better off hiring someone who knows absolutely nothing about the technical requirements of job, but who otherwise has all the right personality traits, than hiring someone who is a technical wiz but does not have the other personal traits that will ensure success.

        It sounds to me like your employers were pretty enlightened, and it doesn't surprise me that you were ultimately a success in that job. And yes, it's those non-technical traits that a good manager gets at during an interview.

        Gary Blackburn
        Trained Killer

        I'd guess that you were not hired for poise, and since you don't tell us how the swimsuit portion of the interview went (bragging eh?), the most probable reason for your hiring was a combination of:

        • you appeared intelligent
        • you admitted when you didn't know something
        • you assessed the building stress and futility of the questioning, and dealt with it using a simple, humerous, and polite question that made everyone feel better about what they were doing there

        IMHO, these are all features (or at least indications of them) you want to find in employees, but often don't. Yes plenty of people can stumble around and look the part, and that is precisely why an interviewer must use less tangible measures than test results to select people. In a previous company I was involved in staffing a software development group which was to do a major overhaul of a DOS-based scheduling system and move it into Win32 (all in C and assembly at the time). We built a test of basic C skills, but as I recall the results were not in any way related to the eventual hiring decisions.

        If someone has the right personality they can learn what you need them to know. In many cases even the best programmers would need to learn a great deal in order to build an application in specific field about which they know nothing.

        I'd like to be able to assign to an luser

      I'd like to agree that this is a sad and all-too-common problem. I'd also like to say that I've seen companies get this right with good management, good programmers who make good managers, promoting good programmers that don't make good managers so they don't feel the need to become bad managers for the promotion, etc.

      Sure, this is still the exception. But there are good books on how to manager software development well and I've seen those techniques work.

              - tye (but my friends call me "Tye")
Re: Jaron Lanier is a Schmuck
by Adam (Vicar) on Dec 14, 2000 at 23:14 UTC
    I'm sorry, but your statement:
    Thirty years ago, the idea of NP-completeness had not been invented. Nobody had the slightest idea that some problems were intrinsically hard. Nobody had even seriously thought that it might be possible for a problem to be intrinsically hard.
    Is just plain wrong. P/NP discussion is almost 100 years old and comes out of Mathematical Logic. The halting problem is older then computers... unless you count a Turing Machine.

    Church, Turing, Hilbert, Frege, Goedel... those guys were working on this stuff when light bulbs were still a novel idea.

Re: Jaron Lanier is a Schmuck
by FouRPlaY (Monk) on Dec 14, 2000 at 19:46 UTC
    I've heard this "Software Sucks" argument before - I didn't believe it then and I still don't now.

    I'm glad to finally have some ammo to shoot back with. I'm not even a 3rd year CS student, I'm barely 2nd (half way through first), so I'm glad that you pointed all these changes out that happened.

    Thank's for the post Dominus, I can now get some more info and rejoin the debate.

    Learning Perl or Going To die() Trying

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://46585]
Approved by root
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (3)
As of 2018-06-25 04:30 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (126 votes). Check out past polls.