Slashdot Mirror
Why Programming Still Stinks
Andrew Leonard writes "Scott Rosenberg has a column on Salon today about a conference held in honor of the twentieth anniversary of the publishing of 'Programmers at Work.' Among the panelists saying interesting things about the state of programing today are Andy Hertzfeld, Charles Simonyi, Jaron Lanier, and Jef Raskin."
here is the link to the ppl on the panel, and talks about their backround
No thanks. The first two paragraphs didn't make me want to read anymore. I'll wait for the comments of the slashdoters to appear.
In response to a Salon article on the state of programming today, GoofyBoy posted a witty and insightful comment. Its sparked a large thread of apologists and public outrage from a wide range of slashdot readers and trolls.
Want to read the whole comment? You have two options: Subscribe now, or watch a brief ad and get a free day pass. If you're already a subscriber log in here.
The surprise isn't how often we make bad choices; the surprise is how seldom they defeat us.
The silver bullet of programming already exists. Link.
Someone with a @salon.com address submits a story to slashdot linking to a Salon article. That article costs money to read. Slashdot posts the story anyway.
Could an AC please post the full text?
Gates' Law: Every 18 months, the speed of software halves.
If they did this as a round table, I would have been sad to have missed it. You just know that at some point in the discussion, Raskin and Hertzfeld would have gotten into a fistfight over who the real father of the Mac was. "Two geeks enter, one geek leaves..."
If using Linux is about choice, how come people complain when I choose to use Windows?
Please keep in mind that being only nearly 20, the depth of my personal experience is not that of say, someone who was around when UNIX was first rolled out. However, I have been in my day an avid C and BSD (mostly FreeBSD, but some NetBSD) user.
Honestly, from where I sit (you may agree or not), programming and computer stuff in general has become a lot less like a science or craft, and more like a factory job. In the early days programmers who physicists, engineers, and mathamaticians. Today programmers are just programmers. More and more computer science departments are teaching using Java. Why? because it helps people to understand how the computer works? no. Simply, because it's what the industry is using.
I had 4 technicians from Cox over at my house yesturday because my parents couldn't figure out what was wrong with the cable modem. They were the most filthy, disgusting bunch I have ever seen and were dressed more like gas station attendants than professionals. Why? because that sort of work has become blue-collar and low-rent.
Programmers are no longer expected to be educated beyond their field. they are being educated to produce software, not to be COMPUTER SCIENTISTS. How many graduates of say, ITT Tech would actually understand Knuth, even if they have ever heard of him? Likely, not many. That is why software sucks. That is why the programming "trade" sucks. and that is why companies can send the jobs abroad to people who work for peanuts. Programming is just like stamping "Ford" on the grill in a Detroit assembly plant these days and nothing more.
Why software still stinks
Programming must change -- but how? At a reunion of coding pioneers, answers abound.
- - - - - - - - - - - -
By Scott Rosenberg
March 19, 2004 | In some quarters today, it's still a controversial proposition to argue that computer programming is an art as well as a science. But 20 years ago, when Microsoft Press editor Susan Lammers assembled a collection of interviews with software pioneers into a book titled "Programmers at Work," the idea was downright outlandish. Programming had long been viewed as the domain of corporate engineers and university computer scientists. But in the first flush of the personal computer era, the role of software innovator began to evolve into something more like the grand American tradition of the basement inventor -- with a dollop of the huckster on top and, underneath, a deep foundation of idealism.
It made sense that the people writing the most important code for the new desktop machines were ragged individualists with eccentric streaks. At a panel on Tuesday (sponsored by the SDWest conference and Dr. Dobb's Journal) that celebrated Lammers' book, seven of the 19 original subjects of "Programmers at Work" lined up on stage to talk about what's changed in software over the past two decades -- and demonstrate that they have lost none of their cantankerous edge.
In "Programmers at Work," Lammers told the crowd, "I looked at the programmer as an individual on a quest to create something new that would change the world." Certainly, the panel's group lived up to that billing: it included Andy Hertzfeld, who wrote much of the original Macintosh operating system and is now chronicling that saga at Folklore.org; Jef Raskin, who created the original concept for the Macintosh; Charles Simonyi, a Xerox PARC veteran and two-decade Microsoft code guru responsible for much of today's Office suite; Dan Bricklin, co-creator of VisiCalc, the pioneering spreadsheet program; virtual-reality pioneer Jaron Lanier; gaming pioneer Scott Kim; and Robert Carr, father of Ashton-Tate's Framework.
But for all their considerable achievements, this was not a group content to snooze on a heap of laurels. In fact, though the hour-and-a-half discussion was full of contention, one thing all the participants agreed on was that software today is in dire need of help. It's still too hard: not only for users struggling to make sense of poorly designed interfaces, but for programmers swimming upstream against a current of constraints that numb creativity and drown innovation.
Today's Daypass sponsored by LowerMyBills.com
These veterans shared a starting-point assumption that the rest of the world is only slowly beginning to understand: While computer hardware seems to advance according to the exponential upward curve known as Moore's Law (doubling in speed -- or halving in cost -- every year or two), software, when it advances at all, seems to move at a more leisurely linear pace.
As Lanier said, "Software inefficiency can always outpace Moore's Law. Moore's Law isn't a match for our bad coding."
The impact of this differential is not simply a matter of which industry gets to collect more profits. It sets a maddening limit on how much good we can expect information technology to achieve. If computers are, as it has often been put, "amplifiers for our brains," then software's limitations cap the volume way too low. Or, in Simonyi's words, "Software as we know it is the bottleneck on the digital horn of plenty."
Most successful programmers are at heart can-do engineers who are optimistic that every problem has a solution. So it was only natural that, even in this relatively small gathering of software pioneers, there were multiple, and conflicting, ideas about how we should proceed in order to break that bottleneck.
Simonyi believes the answer is to unshackle the design of software from the details of implementation in code. "There are two meanings to software design," he explained on Tuesday. "One is, desi
... reading this, does this mean that Windows comes from a dumpster??
Anyway, there's a lot of valid points in that article. Where I work we have the system on peer-review where everytime you submit your branch it has to be approved by someone else. Basically the person just scans through the code, looking for the general idea of how things were implemented.
In general I'd have to agree, but in this case seeing as Salon was simply trying to get money by having one of their own staffers(?) submit the article here, I think it would be well deserved. ;)
It's such a simple concept. The more of anything we have, the more the mediocre stands out. With millions of writers, we get self help books, assorted garbage, and several really excellent works.
Programming has an artisitic side, the creativity, vision, and insanity required to apply oneself to a project is much like the authoring of a book. Many have the skills, know the principles, but even then, few have the internal extra to create.
I may know language and syntax, but I'm nowhere near the league of Shakespear, Tolkien, Asimov, or Clancey. Fortunately for me, they are nowhere near my league when it comes to putting code together.
We have millions of coders - 60 percent will have average skills, 20 percent will be below average (or plain suck), and 20 percent will be above average, including that rare 2 percent of the absolutely insane, don't let them out on weekends, make sure they get fed, check they haven't peed themselves brand of genius.
I'm writting a Perl program in windoze. Using Perl cause that at least makes the job bearable (fuck Java and the assholes who invented it). But since this is 'doze, i gotta use mofukin threads instead of fork! What a fuckin sham. Anyway, I'm asking alll u Perl elite muthafuckaz out there how can a brotha tell if his damn modules are thread-safe or not? And don't tell me to read the muthafukin manual, cause it only sez that if the module doesn't say "y0 i do threads" then it's not safe. WTF? That tells me jack shit is what. It doesn't tell me how to really find out WTF is going on behind the scenes. Someone's gotta know the dealie, y0!
The article is of obvious interest to a large subset of the Slashdot community, and the editors made the choice to post it here. If he/she hadn't posted it, someone else would have, so I don't see how who made the initial post is relevent.
paul reinheimer
That is very damn much ON TOPIC. Fuckwit.
courtesy of wikipedia,
"In the common law theft is usually defined as the unauthorised taking or use of someone else's property with the intent to deprive the owner or the person with rightful possession of that property or its use."
By posting the artile here, we arent depriving the copyright owner of its possession or use.
If i make a noise am i stealing someones silence ?
Copyright infringment isnt stealing, its copyright infringment.
It is entirely possible to survive in many companies as a bad programmer who nonetheless manages to be productive and produce seemingly non-buggy code. They may even appear to be especially hardworking and motivated because of the poor design that they have to spend extra time working around as they add features.
The forces that allow this phenomenon to self-perpetuate are:
=Lack of people who know how to manage engineers properly, know how to recognize good ones and bad ones and how to motivate the ones you have to be productive.
=Lack of good project management skills that inevitably leads to crunched schedules and poor quality code, also lack of perception on the part of management as to why software is having problems with performance, bugs or schedule to complete
=Lack of desire to retain good engineers or cultivate improvement in the junior ones
=Lack of communication between engineering and whomever is giving them work, especially regarding desired features and schedule
=Lack of quality control, lack of oversight, lack of checkpoints in project progress
It doesnt help that the concept of "good engineering" is so hard to measure- a few things are "obviously bad" but most things are not. Even if someone is being completely wrong headed about one particular concept, it is entirely possible that they are exceptionally strong in many other areas within that field. It eventually boils down to "the proof being in the pudding" with the pudding being exceptionally complex to make and subject to the whims of the royal pudding tasters when done.
"Still, that picture of Bill Gates dumpster-diving for operating-system code was hard to shake."
/
Process becomes product???
\
L
For programming to get "good" it's going to have to get unfun. No more will long haired super cool geniuses plug away for hours on end.
It'll have to be a managed engineering process with all the fun and excitement of a CPA convention.
Moore's Law is one reason why software still stinks. Instead of perfecting systems within the confines of a limited amount of resources, its too easy to just assume more MHz, MB, amd Mbps.
With exponentially increasing resources, nothing ever stabilizes and everyone knows it. If people design software with the assumption that it will be totally obsolete and replaced in 18 months, they create software that is so badly designed that it must be replaced in 18 months.
Until hardware performance plateaus and people get off the upgrade-go-round, programming will be sloppy and ugly.
Two wrongs don't make a right, but three lefts do.
I think what they MEANT to say is "Why Programmers Still Stink"
The two are remarkably similar. As time goes on, analagous roles to those found in the production of physical machines/structures (such as concept artists, architects, engineers, construction workers) will be defined for digital creation. Actually, this has already happened. Perhaps what's lagging behind is the partitioning of education that leads to these professions?
Every time you read this, I am going against my principles.
I agree with you, but only partly. Another problem is that some people are interested in programming applications as a ends in itself - e.g. their whole life revolves around implementing solutions to other people's problems. The guy from cox probably couldn't care less about Knuth - it's just what he's being told to do. Perhaps this isn't so much a problem as it is a side-effect of the need for programming services.
That's because business has a need to get their problems solved, and finds the most effective tool to do it - in this case, generic problem solvers or programmers. This is work that is easily outsourced.
Back in the day, the guy programming was solving problems to make -his- life easier. It's not a stark distinction, but one that needs to be made. My formal training is as an EE, I I took MANY more advanced mathematics courses than the CS people at least at the undergraduate level. We did a grand total of three programming courses, all of them offered by the CS faculty, and when I was there, we were taught Modula-2. It's since moved to Java. They don't start out teaching the virtual machine or bytecode, either. Pointer? Eh?
Anyway, back to my point - I used Matlab, C, Assembly, you name it in my digital systems courses. We were not taught those things; we were expected to know them or learn them on our own to solve the problem at hand.
Using a calculator to solve a problem and making the calculator are different things.
..don't panic
It's difficult to believe that Simonyi could be ignorant of the many many years of development of CASE tools and AI projects that have promised to build software systems from specifications.
In 1980, a Professor told a lecture hall of Sophomore Computer Science students, myself included, that almost none of them would have jobs in programming, because in just a few years we would have AI systems that would build software systems from specifications that subject specialists could input.
I don't think we are even a little bit closer to that dream today than we were 24 years ago.
Maybe I'm confusing things here, though. Specifications aren't exactly the same as design. I know that I've sat through some CASE tool presentations where they implied that the work was all done when the design was done, but they were doing some pretty fast hand waving. I believe that those tools did not live up to the promises of their marketing.
Am I off-base here? Has Simonyi cracked this problem with something entirely new?
When we have the power to build highly generalized, evolutionary programs we might start to approach the reliability levels seen in nature. We will look back on all these fancy programming metaphors we have now as barely better than hunter-gathering. We haven't even had our programming agricultural revolution, let alone our industrial one.
Sorry, I don't think any of those people have much credibility left: they have been in the business for decades, they have had enormous name recognition. We have seen the kind of software they produce. If they knew how to do better, they have had more opportunities than anybody else to fix it. I think it's time to listen to someone else.
I admittedly haven't read the article (yet), but I'd like to include a few reasons of my own that programming stinks. As you might guess, I am a programmer.
My friends and I compare a lot of computer things to car things. Most likely, we do that because we are enthusiasts of both. Fast cars and fast software are very similar in many respects.
A little background information on cars is necessary to gain the full effect of my argument about programming. Although the next three paragraphs may seem unnecessary at first glance, I assure you that I am a careful writer and that you should read them.
Car enthusiasts fall into quite a few categories. For example, people who restore classic Mopar or Chevy cars enjoy making everything look like "mint" condition. Usually, every part of the car is so spotless and beautiful that you could eat off the engine. On the other end of the classic car spectrum, there are those who will tub out the entire car and concentrate only on performance features. These cars may not look like much, but they'll break your neck if you push the gas too hard. And of course, there is an entire spectrum of prefenences between these two ideals.
In most of these categories, the hard core enthusiasts like to do the ENTIRE job themselves. They won't let anyone else touch their cars. The wanna be's will usually contract out nearly everything, because they want the glamor of showing up at car shows and showing off their machine, but can't hold a screwdriver and don't know the difference between a 6-point wrench and an Allen wrench. And of course, there is an entire spectrum of car knowledge, experience, and do-it-yourself levels in between these two extremes.
Somewhere in the middle of the two extremes are people like my friends and I. We do a lot of work ourselves, but when it's a complex or high-risk job, or if we don't feel like doing it because it's boring and time consuming, we'll have a professional do it. There are auto mechanics who do pretty much any job. And there are mechanics who specialize in a specific area. For example, I have my radiator guy, my transmission guy, my engine rebuilding guy, my chrome plating guy, my carpet guy, my headliner guy, and the list goes on and on. I use each specific person for the job he excels at because I understand thoroughly what I am about to explain.
Programmers are a lot like the car enthusiasts that I am and whom I describe above. Some prefer to do EVERYTHING, like that guy who wrote 386BSD and wouldn't insert other peoples' code improvements. (The project got forked and now you've got the *BSDs, and that guy is no longer involved as far as I know.) Some prefer to concentrate only on a specific area of software, such as graphics, numerical algorithms, kernel schedulers, assembly optimizations, databases, text processing, and the list goes on and on forever. Even an area such as graphics can break down into a plethora of categories, such as charting software, user interfaces, etc.
The biggest reason that software sucks, in my opinion, is the very same reason that the automotive repair industry sucks. I wouldn't be surprised if programmers are just as hated as car mechanics. The programmer's boss is just like the old lady who takes her car to the mechanic. Neither knows anything about the job at hand. The only thing they know is that it costs them big and the results suck.
For the programmer's boss, the software contains bugs, is difficult and confusing for the customer to use, and takes much too long to develop, so the market window closes, the project goes over budget, and maybe higher management cancels the project altogether.
For the little old lady, the car broke down. The mechanic wants to fix it properly. But doing so will take weeks (believe me). The symptoms are caused by one or more problems, which require several new parts and quite a lot of labor to repair. The parts may be hard to find. The old ones may need to be rebuilt. And generally, people don't like renting a car for t
If they don't care enough to read their own copy, I sure as hell am not going to read it.
Jeesh, whatever happened to quality control?
Ads can be (are not always) annoying, in any medium, but they make the content possible.
... Na und? An editor or writer with a publication or website can submit just like anyone else; I'm glad when they're up-front about it. Would you rather A. Leonard have submitted more sneakily from a throwaway hotmail account? :)
Radio ads drone on seemingly forever, but they pay for me to listen to Coast to Coast a.m. once in a while, or NPR (whose ads, in the form of begging, are even worse, but whose content is better). Television ads, on programs not caught to TiVo, can be obnoxious, too.
The Salon article *can* cost money (that is, you can subscribe to Salon to read it), but you can also watch an ad (or you can click on the ad and carefully look away from it) and then read the article for free. That's what I do. Sites not run as charities need to pay for their content somehow: Even some commercial websites don't make money per se, but are justified by other means (goodwill, information spreading leading to sales, etc), and some are free to read and make money with banners. Salon, unlike some sites, has provided two ways to read their stuff, meaning (I hope) that they stay in business, since I like some of their original stories. Note that reading Salon by the watch-ad/get-daypass means doesn't require you to give them demographic information, answer surveys, surrender your email, click checkboxes to avoid (yeah right!) spam, choose a password, or pay any money.
Probably someone will come up with a way to block the content of the interstitial Salon ads: the arms race continues. But I prefer their approach to the increasing number of news sources that require registration and / or a paid subscription. The New York Times is annoying but hard to ignore as a news source, enough so that we link to it from Slashdot despite the required registration process; other papers, barring unusal circumstances, we won't link to because it's annoying to keep so many username / password combinations and have to login to read their content.
And that it's someone from Salon who submitted
Cheers,
timothy
jrnl: http://tinyurl.com/c2l8yr / foes: http://tinyurl.com/ckjno5
They are really short and you get a free day pass if you view it... I just leave the ad running and look at someting else until it finishes (except for the click through ones). It really is a nice solution for a site that needs revenue and isn't a major news site like cnn.com.
Peer reviews only work when you, the one who authored the code, explains it to a group of peers (even one will do). And a "peer" can be the night janitor. You'll be shocked when you see your own mistakes -- only when you're explaining it to someone new to it.
The article doesn't provide much of the actual discussions so it's really hard for me to decide if I agree with the experts. From the article, it seems to imply that there are problems with software. That much is nothing new. Software is fragile and implemenation is difficult. However, the article doesn't really seem to get at the reason, other than to say we lack the necessary tools. So, while I agree with that much, it's nothing shocking or particularly insightful. It's disappointingly shallow for a Salon article.
:P
The only real shocking part to me was the Bill Gates quote. He's an Open-Source man at heart or just a hypocrite.
EvilCON - Made Famous by
So for this biomimetic approach to work would require a dramatically different machine architecture from what we have now. Of course this would also require the rewrites of all existing Operating Systems and lots of existing application and library software. So 'emulate biological systems' is a nice easy answer that does not really answer anything in the near term.
[Set Cain on fire and steal his lute.]
That sounds like most IT jobs. I've found that IT is different from research and academia. Where I work, at an insurance company, I started referring to what I do as shoveling data. Because my entire job can be summed in one flow chart. Begin, open file, read file, process data, end of file? no. read file. end of file? yes. close file. end of program.
It's mindless. The problem with programming today is that yes, it has become a commodity. Something that people expect you to be able to sit for 8 hours a day and do continuously, without thinking or having any input of your own whether WHAT your doing is really worth it.
There is no creativity in the corporate world, I think thats why so many people choose to work on open source software.
http://github.com/gbook/nidb
Charles Simonyi, former MS Chief Scientist and inventor of the horror that is Hungarian Notation? I guess they picked him as an example.
Perhaps linear, logical, engineering geek-types are the wrong type of people for the job. We haven't made the computers smart enough so the people with real design skills can use them properly.
Because Programmers don't bathe.
Its pretty sad when a commercial OS ships a debugger with their system but no compiler.
No wonder I was always so square; I spent all my time cultivating an image of rugged individualist.
Got to change with the times, I suppose.
Sheesh, evil *and* a jerk. -- Jade
Public Sevice Advertisement
HELP FREE JIM! YOU COULD BE NEXT
Indefinitely Detained US Citizen
"editors made the choice to post it here"
What're you, new?
They got paid to post it, or my name isn't Bipperton Fusslebeak.
"One is, designing the artifact we're trying to implement. The other is the sheer software engineering to make that artifact come into being. I believe these are two separate roles -- the subject matter expert and the software engineer."
Funny chap talking about how design and implementation should be separate. Seems a bit ironic considering he was the one who create Word docs where the layout and content are all packed into one file. Most decent solutions separate the layout from the content (eg: Latex, HTML/CSS). If Simoyi was a web programmer he'd be laying out his html with tables.
Hehe this would make a good base for a philosophy or sociology paper. Anyone taking a class? you could steel it!
now i've seen everything
The article is crap. A typical snippet:
This is similar to many articles before disparaging the WIMP (Windows, Icons, Mouse, Pointer) model. A bunch of "visionaries" who see that we've used this same model for some time and therefore are convinced it is horribly limiting, and that we are using it solely because the people who actually make systems have less imagination than people who write these kinds of articles. [*] They never have any but the most vague suggestions of a better model. They certainly never take the time to explore its limitations longer to ensure it really is workable (much less actually an improvement).
In fact, this article is so vacuous that I'm not sure what they think stinks about software, much less why. And certainly not how to fix it.
[*] In fairness, this article mentions people who have done some impressive work in the past (and is thus atypical of the genre). But still, I do not see any suggestions for a fundamentally better model or even any concrete problems with the existing one.
new designers? eh? ;-)
and for that matter, who can you design something if you don't have a logical, linear thought process?
intuition? yeah, that'll fly... or rather, i'd rather not fly in an aircraft designed in such a fashion.
...and more than that, totally ignorant regarding matters of US Law. Please STFU.
I have been working professionally in software development for not quite 24 years with experience in aerospace/defense, established commercial, "dot com", and a post dot-com startup companies plus I dabble in Linux. This still means this is a series of single data points taken in different industries at different times so take what I have to say with a grain of salt.
The worst programming problem is unrealistic expectations on the part of management. What it really will cost and how long it will take is always too much and too long so budgets and schedules get cut. At least aerospace/defense makes an attempt to figure this out and bid the contract accordingly. The commercial world looks at when the next trade show is or something else equally irrelevant and then says it has to be done by then with the staff that's available. They end up getting what they paid for and blaming the programmers when it crashes (See my sig. Yes, I do software QA). Established commercial companies aren't quite as bad but there is still a tendency for making the sale to somehow trump in the determination of what can be developed with the time and resources available. The resources may be there but there is a tendency to try to produce a baby in one month by getting nine women pregnant and then wondering why there is no baby after the month is up in spite of publishing detailed schedules.
In contrast, I think one of the primary reasons free/open source software tends to be of significantly higher quality is that these factors don't come into play. A feature or program either is ready or it is not. If it is not, it stays as a development project until it either dies of apathy or enough people are attracted to it to make it into something real. For established projects, you have people like Linus who "own" the project and ensure that contributions only get incorporated if they pass muster.
I find it amusing that one of the criticisms of FOSS is that the schedules are unpredictable but the reality is that software development schedules ARE somewhat unpredictable* but at least the FOSS development process recognizes this and instead focuses on the quality of the program rather than pretending it doesn't exist and coughing up something that isn't really done based on someone else's absurd schedule.
* If someone develops the same sort of software over and over again (think IBM) they will eventually gain enough experience to have a reasonable shot at scheduling and resourcing a project correctly. The fewer data points you have, the less likely you are to get it right.
They that can give up essential liberty to obtain a little temporary safety deserve neither safety nor liberty.
Ben
You should be getting an insightful along with the funny. Programming as a field is trying it's utmost to be an engineering field and failing badly. Just imagine if bridges and skyscrapers were built by the same process software was? The first woodpecker would bring civilization down. From the start, the gaining of insight into the problem is a laborous, error prone process. Then there's the misjudging of resources. Followed by the scrambling of an overworked, undereducated workforce (a technological sweatshop). Then there's the final push to get out something that would never pass inspection by an independent agency. There's an overall lack of discipline to the whole process. Oh yes! There are people trying to bring order to this chaos, but who's going to motivate the people running the show to impliment them? At least in engineering people die, and the government finds out what went wrong and issues edicts that foster change. There's no such process in software creation. There's also the issue of inertia. How many times have we heard "this is the way it's always been done"? Or the better way will cost too much (funnily the airlines use the same excuse). No we'll grow up when the pain get's to be unbearable, and everyone's on the same page of desperation.
And to last the "fun" aspect. Is engineering "fun"?
instead of shitty WIMP interface we need to move towards a more personalized interface. imagine: the user can now "raise" his own applications the way he wants. all applications start out with the same code and state (virtual DNA) and over the course of time the user can gently steer his application in the right direction. if the application starts crashing, the user can virtual "spank" the program so it learns not to engage in such behavior. and if the app is preforming excellent, the user can reward it by giving more resources to eat. hey man, this is some good shit isn't it/ it bet nobody though this shit up before. damn i'm a mofukin genius, like that elite mofo who posted about Perl threads earlier... damn this is some good shti man.
damn i'm hungry now, gonan eat somethin
Uh, I haven't read the salon article.
I think it comes down to a matter of discipline. One of the things that made Unix such a success is KISS. Unix is built around the philo that you should focus on one thing and do that one thing well. Tools in Unix don't re-invent the wheel to get stuff done; they rely on other tools.
Another thing that comes to mind is what Apple's VP of hardware engineering Jon Rubenstein said in an interview. He said that engineers get too creative when they do work, and end up engineering things that do not need engineering - the rote work, as he put it. You have to get engineers to be creative in the non-rote work.
IMO, Java is too complicated and easily gets in the way (I'm not going to touch C++ here). At least with C you can start off with a one-line Hello World program. I've seen first-year CS students trying to understand the many lines of code that constitutes a Java Hello World program (there are so many elements to a typical Java HW example; the class declaration, the static main declaration, the exception handler, System.out, etc. Every token except for "Hello, world!" is gobbldygook to newbies). In the case of C, it can go either way. To a well disciplined programmer, C programs can be extremely elegant. On the other hand, you can end up with some really fug-ugly code. However, a Pascal programmer is more likely to use C in an elegant way because Pascal is simple enough to make a programmer focus on the task, restricting the programmer's freedom to do stupid things.
Although many argue that type-safety is incredibly important, that you can get really weird behaviour if you don't have type-safety, and that it's important that languages restrict programmers by being type-safe. Uh, no. Type-safety is like training wheels. If your program is well structured, 'types' in the program are for the most part irrelevant. What matters is what the code is doing, and knowing what the general flow of the program accomplishes. In a well-structured program with a well-defined execution flow, the data that moves around should always be well defined anyway.
Here's another way to look at it (something an old professor brought up). What useful program has no input and produces no output? There is no such thing. Your job as a programmer is to transform your input sources to your desired output products. And the path to get that done should be as simple as possible. Unfortunately, we've got languages with templates, boxing/unboxing, exceptions, RTTI, etc as our main tools, that often provokes us to design systems that are more complicated than they should be.
Really, it's like an artist trying to make a painting, and going out and buying a self-cleaning, featherweight, self-balancing $1K paintbrush. That's way beyond the point, isn't it? An artist needs to envision their artwork and realize it in their medium of choice. Similarly, a programmer needs to understand the problem they need to solve and then efficiently implement it on their target system (be it a PC or an automated toaster oven). Language features don't make programmers write better programs; discipline does. I can't remember the example perfectly, but it's something like, if you give a team 20 tools to do the job, they'll try and use all 20 tools. If you give a team 4 of those tools that they really need, they'll find a solution too - and a more efficient one.
Anyway, KISS. You need to focus on what execution paths your program takes and what affects those execution paths (and note that exceptions throw a wrench into that. I avoid them). Don't get too creative with the language you're using. The best thing for a programmer to do is to learn how to program non-trivial projects in several different languages (Java and C++ don't count as different languages). And then hopefully more programmers will demand cleaner programming environments that aren't just souped-up C++ clones, and programming will stink less. (Take a look at Smalltalk some time).
Moderators should have to take a reading comprehension test.
Quoting the article: "Giving the [software architects] tools to shape software will transform the landscape, according to Simonyi. Otherwise, you're stuck in the unsatisfactory present, where the people who know the most about what the software is supposed to accomplish can't directly shape the software itself: All they can do is 'make a humble request to the programmer.'"
As a programmer who recently stopped working for a very very very large computer firm that sells both hardware and software, let me say that Simonyi's point makes zero sense. Tools already exist to "shape software," and they are known as programming languages like Visual Basic, C, C++, C#, Java, Perl, PHP, Python, etc...
I'm frankly sick of architects (that's the term for people who say they design software but don't actually design software) who bemoan the gap between their glorious visions and the real products their teams end up producing. These people need to click "Close" on their UML models and go get their hands dirty by writing parts of the production code. Then they'll understand the real-world constraints that their codeless design didn't account for, like internationalization, performance bottlenecks, user authentication, heterogenous networked environments, and ACID transaction support (to name the first few).
Oh yeah, and the reason open-source developers wrote a Unix-like operating system (Linux) and put a Windows-like interface on top of it (X11 + GNOME/KDE) is because these are both very reasonable and mature solutions for a variety of computing needs. If any of you architects out there want something besides Linux that conveniently abstracts away 99.9% of the hardware interaction yet also provides an easy-to-learn interface for general users, you are more than welcome to write it yourself. Or you can model it in UML, click some buttons, and hope it compiles.
Why do I think software sucks? Because market droids and architects who forgot how to program get together and promise their customers AI in only six months.
The linked page didn't mention that Charles Simonyi is the Hungarian for whom the term, Hungarian Notation is named.
Hungarian Notation is that Microsoft Windows programming naming strategy where the first few characters of a variable name should hint to the reader as to its data type. So hToolbox tips you to understand that it was a HANDLE type, even without scrolling your editor up a couple pages to find out; papszEnvironment would likewise tell a Win32 devotee that it was a Pointer to an Array of Pointers to Zero-terminated Strings.
It's not the first such instance of binding data type and name, and it won't be the last. For example, FORTRAN compilers have long had implicit variables; any variable not otherwise declared that started with I, J, K, L, M, or N would be assumed to be an integer, where most other variables would assume a real (floating-point) type. So FORCE(LAMBDA) directs the code to a real scalar from a real array, given an integer index. Many programmers start a routine with IMPLICIT NONE to disable this assumptive behavior, as mistakes are easy to make when you let the machine decide things for you.
BASIC would use sigils at the end of the variable names (NAME$, COUNT#, and scripting languages like Perl use sigils that precede the name %phones, @log, $count).
[
Well as I pointed out elsewere. Software unlike engineering is more open-looped. First internally there's not enough feedback to correct most of the errors (usually because of money). Second when it leaves the place of it's production there's no review process for fitness of purpose. this is one of the reasons OSS works in that no matter how imperfect the original design is. There's a constant review and refining process going on the bring it in line with community standards. Also maybe software creation could learn something from book creation. War and Peace wasn't created fully formed, but through a refining process from a general description to the final manuscript. And last we need to get the trees from our sight, and gaze over the forest.
Sadly it's the type of art where they paint with feces.
--- Ban humanity.
LINDON, Utah, Mar 20, 2004 -- The SCO Group, Inc. (Nasdaq: SCOX), the owner of every operating system dammit and a leading provider of Linux-based solutions, today announced a lawsuit to be filed against Microsoft Corporation for its alleged violations of its UNIX software agreement with SCO.
President and CEO Darl McBride addressed reporters from outside his bunker in Provo: "We have reason to believe that all existing versions of Microsoft Windows contain SCO intellectual property, and that this information was obtained by illicit means from the garbage cans at the Computer Science Center".
Bill Gates was too busy laughing to be reached for comment.
(This is only funny if you RTFA, and maybe not even then).
Vanya's Law: "In any culture without irony, fart jokes will be the highest form of humor."
"Software is fragile and implemenation is difficult. "
I've stated elsewere that our software will be tolerant when our hardware is. If our software is fragile, it's because we've built upon a bed of sand.
Unrealistic expectations? Yes. Of the management? That's the least of our problems. The "common sense" expectations for software are vastly unrealistic. Modern software tools are incredibly complex systems, both in the number of internal "degrees of freedom" and in their interaction with the environment. Yet they are expected by the public at large to function properly under circumstances which could be more different from what it was designed for than, say, driving a Ford across the lake (why is nobody complaining that Ford was lax in their testing because they only tested their cars on roads, which, after all, cover a tiny fraction of Earth surface?)
At the same time, software is perhaps the only industry where everyone is a friggin expert. Most people (in the US anyway) happily pay someone $25 to change their oil. How many are willing to pay someone $25 to install a new sound card in their PC and load drivers? And, if you look at the complexity of interactions between parts of the system and open-endedness of the interface with the environment, oil change is downright primitive compared to sound card change. But no, for some reason it should be "easy". Look at everyone who enables "expert mode" on their software, while even "novice mode" presents more controls than a smal airplane.
And the only people who actually understand the complexity of the software, the software engineers, somehow let themselves become convinced that software really should allow millions of users to do thousands of things they want, the way they want, all at once, and be "easy" at the same time.
the article is called "programming stinks" and you can't even read the article unless you have Flash-root-my-computer-Media installed.
It's not sexy, but a fact of life is that much of what programmers do is maintain code that somebody else wrote. By now, a lot of very smart people have worked out the details of how a wheel should be designed. If everybody uses that standard wheel, then anybody can put a new tire on it. But, if you think you know better, go ahead and make yours non-standard. Just get used to people who come behind you saying unkind things about you.
DO
NOT
USE
PERL
THREADS
thank you, and good night!
Maybe a close coupling between code and higher-level representation? So how does a memory leak look in UML? What about an undeclared variable? Or the code block that never gets executed?
A representation of code that harnesses the strong points of our visual system. Maybe even audio. "Hey Bob! Does this code sound odd to you?"
1) User expectations for software are a lot higher than they were when the fossils in the article were in their prime. Give me a break, what wasn't better than DOS 3.1?
2) Software companies need to keep Wall Street happy by making their deadlines, which means they are willing to ship buggy code. Does that mean programmers aren't as good as they used to be?
Yes, but the suit would ask for damages. At this point in Salon's evolution, I suggest that reprinting this (fairly entertaining IMO) article serves only to enhance Salon's reputation as a quality publication.
Illegal and arrogant by the reprinter? Sure. Damaging? Less sure.
(Of course, when Salon can argue that its site-admissions are materially down because of rampant infringement, then the horse trans-chromatizes...)
Seeing bad movies only encourages them. Watch responsibly
The ads require you to have the crossover plugin for flash support, so yes you still have to pay to visit the site, either to salon or codeweavers.
I hate programming now. I loathe the thought of it. Not because I hate the act of programming, but the systems I have to work with.
Sure, in the nice old days, the C64 and IBM PC were fairly easy to code for, but they also gave you very little bang for the buck. The nice thing was a couple hours of programming could get something nice out.
Now, it can take me a couple hours to do even a simple notepad application from scratch. I'm forever spending lines of code to fill in structures or respond to all the events an API wants.
The computers got more powerful, and the APIs also got more powerful, but now I spend so much time filling out basic structures that I don't need. I'd rather a lot of that stuff was user configurable or stored in an XML file somewhere. I don't want to have to know about allocating & positioning fonts! I just want to dump it in a nice scrolling box.
It's like a bureacratic nightmare writing code now. Sure, there's MFC, etc., but that's like the "easy" tax form. The moment you want to do just one thing different, you're back to square one. And the learning curve, sheesh!
That's why I like projects like XUL. We've made the APIs so programmer centric, that I can't breathe anymore. I just want to code the important stuff then let someone else make the GUI pretty.
The bitter lessons of a veteran coder: http://bitterprogrammer.blogspot.com
One reason I believe that programming is bad these days is that the market is flooded with poor programmers. At my school, many freshmen come in with lofty goals about being computer systems engineers, or electrical engineers, or something like that, but they get their little freshmen butts kicked by the carriculum and end up dropping engineering. Most people I've seen this happen to end up switching to Computer Science or IT. Combine these people with those who came into college to do CS or IT, and you have a glut of people entering the market trying to score programming jobs. And some of these people are those who kinda just fell into it with no real interest other than to graduate college. I think CS carriculums should be more intensive so as it isn't used as a fallback major for those who can't hack it in other fields.
The thing was, even in the late 80's, to mention that a particular approach would be 'elegant' was the kiss of death; it meant that you were amusing yourself at the company's expense rather than doing your job. There was still a strong desire in big companies to control programming with methodologies and basically attempt to do things in such a way that talent was not required. It was like the military - they don't/didn't want talent; they wanted interchangeable programmers that could be put onto any job.
This is undoubtedly still true today in many cases.
But, more and more, companies want senior talented people. And more and more, companies realize that when a talented programmer claims to have an elegant solution, it means simple, reliable and fundamentally sound.
More and more, companies are realizing that any idiot can write complicated software; it takes a really good programmer to write a simple, sound solution.
Of course, I am talking about real programming here, not dragging boxes around on a form and putting 2 lines of code behind a button.
"When the going gets weird, the weird turn pro" -- HST
If anybody else goes to Simonyi's company and still can't figure out what they're talking about (mostly because it's vapourware at the moment, I believe), may I direct you to this Wiki. It turns out that he thinks source transformation tools will change the world.
I'm told that my university is one of the leading source transformation research centres in the world, but the only interesting things they're producing right now are for understanding legacy systems. So yes, there's probably a lot of money in source transformation, but it's also boring as hell.
Fred Brooks said it best: There is no silver bullet. Programming is hard. If Simyoni can come up with a tool to write kernel drivers for users based on a general English description input of the task given by voice command, I'll be more than happy to take off my badge and go write screenplays or something.
Seriously, it says almost nothing. What does this have to do with programming sucking?
There are two kinds of people in this world, those who divide people into groups, and those who don't.
Let's not forget that the folks at Salon use and develop the open source CMS system Bricolage (homepage, Salon tech notes on their choice, Linux Journal article, Another).
They're not exactly the bad guys around here.
"Nothing was broken, and it's been fixed." -- Jon Carroll
Admittedly it was outside of the letter of the law to post this outside of its home site. But this is the internet. The expectation is to be able to link to another part of someone else's site so that we have this inter-related "web" of information. The commercialization of the internet with broadcast paradigm limitations destroys the peer-to-peer web-like nature of the ... of the web. Linking was supposed to be the proper attribution format for the web. The salon web site (and several other web sites) don't really allow this any more. The are definitely resources available through the internet, but they are no longer really part of the web, as they have chosen not to play by the rules and guidelines of the medium. If they don't want to play by the rules, they can leave.
As for copyright: Copyright was meant to limit copying with copy presses. The world wide web is not what the provision was designed for. I haven't visited Salon since they went with this advertising scheme. I would not have gone to their site if this hadn't been posted here. I'm reading web pages for news, and if I wanted to mindlessly watch ads as I was told to by my corporate masters, I'd be watching TV instead. If salon wants to force ads, they should be on TV or Radio. This is the wrong format for that crap. I don't think this loses them anything, as many other people here feel the same way and won't even go through the hassle of a free reg. to read NYTimes articles.
After I lost my third slashdot username and just started signing my AC posts. If I couldn't post as an AC, I wouldn't post at all. I have better things to do than jump through someone else's hoops.
Anyway, even the letter-ignoring law abiding slashdotters understand the bad karma of direct posting, but the impetus for doing so was that the submission of this article appeared to be an intentionally subversive advertising ploy. "Submit to a news site so that they will do the work of advertising for us so we don't have to pay for it, then force them to watch ads so that we get paid for it." Even if it wasn't like that, it surely fails to avoid the appearance of impropriety; and as cynical and paranoid as the techno-elite usually are, it was assumed that someone was trying to pull a fast one, so we pulled back.
I'm glad I got to read it. It was nice. If it hadn't been posted, I wouldn't have read it. Salon gained from this by having content attributed to them that was of decent quality. I'd consider going back if it hadn't been made quite clear that they are still doing the crap that made me start my boycott of them to begin with. If they didn't want the article put up on slashdot, then someone from salon shouldn't have sent it in.
I have no remorse for a commercial organization failing to reap the full financial rewards of exploiting a non-profit web site, just like I have no tolerance for SPAM or unsolicited phone calls hijacking a communications service for the purpose of advertising against the will of the audience. Not to mention leveraging laws well outside their intended boundaries to bully common citizens into compliance with unfair practices.
- theed.
Nobody knows how it should be done. Plain and simple. Sure there are 50 different ways to shuffle 1's and 0's around to produce something that kind of solves a problem someone may or may not have (customers seldom even know the problem they are paying to solve).
.NET?)
Add to that the string of phbs, development team, testing team. Then you end up with people who don't really understand the problem, solving it with tools that we don't know if they work or not, or which they might not even fully understand. (Have you proved GCC is correct lately? How about
So until we can get a method that ties programming to what it really is (problem solving) we get to poke about blindly in the dark to find our 'solution' and hope it shuts up the customer long enough for them to write the check. We're slowly getting there, but because programming is still a new thing it hasn't been remotely fully explored yet.
There's lots of room to figure out how to make a computer solve a problem once it's defined. Finding the problem is a major portion of the battle. The rest comes in finding a repeatable, provable way to solve it.
Until that happens youll need your blindfold and poking stick handy.
Yep.. developing stinks.. spend hours on end writing free code, watch all your jobs leave for another country and finally pay to read a reporters rant on why your profession stinks. If you're developer you're probably wondering why you aren't a reporter instead
did you forget to take your meds?
Writing software is difficult because it actually is complex - a piece of software of any size has more "moving parts" than (almost?) any other thing people build.
Things have gotten better over the last 50 years - high-level languages, object-oriented design and information-hiding to reduce interdependencies.
But software is still one of the most complex things people make. Better tools and approaches help, but there are no silver bullets - software is complex because it is complex.
"When the going gets weird, the weird turn pro" -- HST
Bridging the gap between the producer and the consumer is the discipline of systems analysis. Regardless of how productive or gelled the team, is it building the right product?
In the limit, I guess the ideal software is developed by an uber genius for his own use.
Could you please refrain from using Foul Language on this site.
/. has no age verification your comment post has surely caused damage to many young children who's lives will be forever ruined.
If you continue I will file a complaint with the FCC and have you fined.
Free speech in a public forum should be free of anything that may be offensive. Since
... doesn't fit on a bumper sticker, so no one is really concerned about it.
Seriously.
Physics is about finding the one inch formula. One of which is e=mc^2
Accounting is about making sure that the accounts ballance. Profit is the difference between cost and revenue. Cost plus Profit equals Revenue. Accountants recognize that they are part of both the "Cost" and "Profit". Good business management recognizes that eliminating the Cost will also eliminate the Revenue, which will also eliminate the Profit.
Programing is not currently about finding the least expensive way to solve a problem. It is about finding a usable way to help people accomplish their desires.
Computer Science, such that it is, in most cases is a euphamism for Software Engineering. The goals of Software Engineering when I was going to school was to write "provable" software. "Provable" software is software that you can "prove" every line of it does exactly what the "engineer" who wrote it intended, nothing more, nothing less. If the developer writes to variable "n" in function "A", and the scope of the design is that variable "n" is only applicable to function "A" then when function "B" changes variable "n", it should not affect what function "A" expects it to be.
That is a very simplified version of what Software Engineering is all about. Software development is supposed to be about using the tools that software engineers have used to build useful software. All too often it is about using tools other software developers have created instead, because other software developers have gone ahead and created something to work with, because they got tired of waiting on Software Engineers to get over being elietist, and actually putting together provable designs.
A suspension bridge is a beautiful piece of engineering. It is also very often a very beautiful piece of hardware. The Tacomma Narrows disaster happens when a piece of engineering comes across a situation that the engineer was not expecting, and didn't design for.
Likewise software developers are using unproven tools to acomplish various tasks. Then they are being asked to work arround the problems that come up when their tools encounter situations that the developers of those tools had no idea would ever be asked of those tools.
As a result, we currently get buffer overflows, memory overruns, as well as hundreds of other problems that can best be described as anoyances, and at worst be described as security flaws.
------
Alternatives to the WIMP design, as well as the Unix understructure.
While Lanier bemones the fact that we have not "surpassed" the Unix and Windowing mode of computer archetecture and interface, at best he can be said to have waved his hands at a new direction, (VR). The only "improvement" I have observed is the time based document stream view that has come out of MIT, and even that can be considered a WMP view (minus the icons at the moment.) For some people this very well may be an improvement, though I think it is only useful to those people who look at time centric management of information. In other words, I think it's a great way to manipulate stuff like e-mail, but probably wouldn't be of particular use in managing a book store inventory.
"Mind Mapping" seems to me to be a "better" way of managing information, but I don't know that it is a great idea as an interface for a computer. Perhaps that's based upon my own limitation as my input to a computer is a small set of serial interfaces, rarely used concurrently, and the output is a couple of serial interfaces, and a "screen" or "window" of data that I process as information.
As long as that is what my interface to a computer is, I will probably run into limitations as to what I can expect from a computer. Those limitations are going to affect how I interact with the computer, as well as how I, and others, develop software for the computer.
Rather than bemoning the current state of the art as being of the same
You never know...
Despite a million programming and language books in the market, the code you're interested in using with is never in the books.
Even online sources aren't always perfect. Visual Studio library CDs with a cazillion examples is actually one of Microsoft's better offerings.
I think comparing the progress that software development makes to the progress of hardware development is a fundamental mistake. Moore's Law depends upon the properties of the materials we're using and our ability to exploit them--chip fabrication, heat conduction, power consumption--not upon our ability to design chips. It's not the chip layout that's improving, it's our ability to milk what's already in the materials, which yields exponential growth. We're not responsible for that growth curve, the materials are. Doubling the length of our lever gets us the ability to move four times the weight.
Software, on the other hand, is all about design. Of course it's not going to double in power every 18 months--we're not doubling in design ability every 18 months. If the computing of our hardware were limited to our chip design abilities, it would be going just as slowly.
Anyone who loves or hates any language, platform, or manufacturer, doesn't know what they're talking about.
While I appreciate your points-- and could relate them to any number of trades-- I have to wonder if there will be any solution, ever.
I mean, cars have been around for a while now, right? Mechanics aren't appreciated any more now then they were 5 or 10 years ago, as far as I know.
For the record, I'm neither programmer nor mechanic-- I cut fish for a living. And your points apply there too.
sounds like you don't do anything for yourself... imagine how you will feel if you actually do some simple maintainance on your car... how does it feel to have someone own your vacation?
Just switch keyboard language to Dvorak or something. I did that and the guy looked at me funny and said "I'll, let you handle that one!" and promptly exited.
This is coming from a game programming point of view, but I think it applies to all facets of software development. Programming sucks these days because of the communities it has created.
I'm not going to be a Yancy and specify where these points aren't applicable. Take what you read here with a grain of salt, but I guarantee you can apply one of these to an experience you've had.
- Zealot Trolls.Answering someone's question with a code solution that contains even the pettiest OO fault, even if it has nothing to do with OOP, will get you nothing but a bunch of OOP zealots on your ass, saying 'WRONG! That shouldn't be public' or 'WRONG. The destructor should be virtual' or 'WRONG. Should pass by reference'. You get the point. There are more and more trolls on boards these days looking to stroke their ego by posting extremely minor corrections to mostly correct solutions.
- Wheel Engineers. Stop making 3D engines. Stop making WinSock networking wrappers. Stop making ray-tracers. Stop making things that have been done 1000x before unless a)It's for fun/educational purposes. b) You're going to do something someone else hasn't. Even if there's _one_ thing in your coding project that someone hasn't done before, it's definitly worth it to create. Red-Faction was the last game IMO that added anything new to the world of 3D engines, other than 'taking advantage of x graphics card feature'. Physics is another area to inovate with game engines. Please Stop Re-Inveting The Wheel and giving it some cheezy name.
- Meatless Code. Anyone who has worked with the 3DS Max SDK knows what I'm talking about. Important data is fragmented everywhere, and accessed in 10 different ways. You spend more time reading the API docs than you do programming. I was reading through some ASP.net code the other day, and it took 45 lines to update a table with an SQL command. I read through it, and it could be done with 5 narrow lines of perl code. With C++, you could probably spend a solid two weeks writting generic 'manager' code that does absolutely nothing. Programmers need to learn to draw the line between 'productive' code and 'silly' code. Having a DataObjectFactoryCreatorManager class for 'ping' program, is a bit silly.
If I could do the world a favour, it would be to send all coders a letter that simply said "You are not the best. Live with it.". If I read another reply to a simple question with some dork awkwardly throwing in that he's "A 20 year C programmer who wrote a compiler on a TSK-110ZaxonBeta when I was 11". No one cares about your background unless they ask, or it's relevant.
Other than that, programming is fine. Except for Java.
- Mr.Oreo
It's a country. India.
I like to call it "India"
I think you're looking for this article :P
I am currently paid strictly because of my value to answer questions on a huge array of questions. I am not a brilliant coder, I am a horrible networker, I understand MS Windows only on a superficial basis. So what am I paid for my ability to answer the questions off the cuff, cut through the he said she said arguments between Networking and programming when there is a problem.
There is a definite role for "intergration specialists" which are not integration specialists but computer generalists that understand a little about everything.
Most important question is not what you know but whether you can apply that knowledge to the questions at hand.
The thing is, Java is somewhat high-level. There are things that go on under the hood that you won't learn about, but once in a while pop up anyway. For example, being taught Java, you won't learn about the difference between memory allocated on the heap, and memory allocated on the stack. And yet...
This does not work (it doesn't even compile):
There's nothing wrong with the code; the problem is that Java pretends to support closures but really doesn't. To use x in the anonymous inner class, you need to declare it final. But if you declare it final, you can't do the x = "b" assignment.
I'm familiar with C, so I understand the difference between the heap and the stack. I can infer that x (the reference to the string, not the string itself) is allocated on the stack. It is not uncommon for instances of anonymous inner classes to outlive the stack frame they were created in, so the compiler doesn't know whether or not x (on the stack) will still exist when the object's run() method is called. So it makes a _copy_ of x, but in order to pretend that it is still x, the compiler wants you to declare it final so that the original and the copy can never get out of sync.
Having experience with C, I know the heap is a safe place to put things that may need to outlive the current stack frame:
It's ugly, but it works. The reference called x needs to be declared final (because it's on the stack) but the reference contained in the array does not need to be final (because it's on the heap).
Because of my experience with lower-level stuff, I understand how Java is faking its support for closures, and how to work around the limitations. This is only one example; there are many other times when understanding things from a closer-to-the-metal perspective gives insights that would be lost if things were only understood from a high level. Joel Spolsky summed this up fairly well: Leaky Abstractions
If one compares the industrial revolution with the so called "information age", we are somewhere in the early 1800's. The industrial revolution resulted from the experimentation of scientists with formal training and tinkerers with informal training. The information age is no different. During the first few decades of the information age, those who worked with computers were both scientists and engineers with formal training, as well as tinkerers with informal training.
After the foundation of the industrial revolution was laid, two professions emerged, the engineer who designed the machines, and the mechanic who maintained them. Some of the previous posts noted with dismay the similarities between blue collar workers and graduates of technology programs and certificate holders. Computer science and engineering is still barely older than 40 years old. Since the demand for programmers is still very large (even if the demand is being met in India), simple jobs are being delegated to programmers with training lacking theory. These are the mechanics of the information age and they have their place.
The "technician programmer", is on the same level as those technicians who obtain degrees in "engineering technology". The technician programmer is well suited for cranking out small system administration scripts, coding SQL, creating database front ends, and developing websites. Like machinists, they work with tools that are comparatively simple, and repetitive in nature. Occasionally, a complex problem requires a new method of applying the tool. A machinist can make engine parts, but can't design an engine in the same way a technician level programmer can create a database, but not the database engine.
Unfortunately, the tech schools try to convince both their graduates and businesses that technician programmers are able to do more than this. In the current economy, businesses would much rather pay a tech school graduate to customize an off the shelf solution, than an unemployed programmer trained as a scientist or engineer. However, there will always be jobs for systems programmers and software engineers, as long as someone is willing to pay for new ideas. The difference between the "technician programmer" and computer scientist and engineer needs to be recognized, just as the difference between the appliance repairman and the electrical engineer, and the mechanic and mechanical engineer is recognized.
We have not seen the true next generation of computers. Miniaturization and speed increases are the results of advancements in materials science and electrical engineering. Computer science and software engineering are still using ideas from the first generation of technology. The majority of computers (PC's) run a von Neumann architecture, with software written in languages that are procedural, even if support for classes and objects is included. Classes and objects simply create a method of abstraction to enable the problem to be approached in modular manner. Not that this is bad, but the models and techniques of computer programming are based on the limitations of hardware technology from the 1960's and 70's. The tradeoff between performance and ease of use are still issues in software engineering. The next generation of computers may eliminate the constraints of current methods, as well as introduce new constraints. It's all part of an ongoing process called technology. This is a good thing.
most programmers are poorly trained. compiler makers need to cater to the largest market to get the most developer market share. Hence they write compilers that appeal to the majority, which is comprised of mostly poorly trained programmers. These compilers allow too much flexibility because bad programmers whine during the compiler's beta testing phase if they don't have all of these flexibilities to allow them to write quick hacks, no design, gotos, inefficient algorithms, etc.
"Hungarian"
Maybe you should try C++ Builder 5.
It's as easy as VB and you don't
have to mess with MFC.
The auto-generated code is "CLEAN"
and readable and looks a bit like simplified Java.
Do today's programmers really have the identity they used to?
How innovative are they? A bunch of IRC-loitering script-kiddies that spend all their time trying to take down other IRC-loitering script kiddies? And at the end of the day, what do they have to show for it?
When I was 13 I was programming for a major university, at 14 working for a Fortune 500 company.
When I was in high school, I faked my way into an ACM programming competition in the local college and got 2nd place against all the college kids. I would have had first place but I was so far ahead, I stopped and didn't realize that one college kid had waited until the last minute to submit his jobs for review..
At age 23 I won Editor's Choice in PC Magazine for a Shareware program I wrote. I sold over 100,000 copies. I exhibited at Comdex and travelled around the world.
I really don't consider myself that great of a programmer, or that anyone else couldn't have done this - I didn't have any special privilges - I just was passionate about what I did, but I do think if Grand Theft Auto, or TVLand had been at my disposal, none of that would have happened.
Back in the days, programmers were obsessive about really creating things and doing new stuff that nobody said was possible. Nowadays, the "programmers" I run into (and I use that term loosely) are little more than shills for the lame-ass high-level, unstable development environment that allow them to get fleeting contract jobs. They take great pride in making sure nobody else understands their code, and they suck ass.
Computers changed the world, but you'd never know it looking at this new generation of lazy, self-absorbed, pothead, ADD programmers on the scene now. If this offends you, you're one of them; if it doesn't, then you can probably relate regardless of what age you are.
1. When I was a kid our operating system was a programming language.
Not to be confused with the "When I was a kid we walked a mile in the snow up hill both ways nude just to get a candle"
Progression and "Computers sucked back then" aside we had easy access to a programming language and people didn't say "kids can't write code" well actually SOME people did but those same people think kids can't do anything.
Even ferther back before home computers kids couldn't access computers but collage students could get access to the schools mainframe and before that...
The point is that the notion that programming is something only profesionals should do is very new.
For example: Script kiddies..
Script kiddies is something new (well new as of 10 years ago).
In the 70's and 80's children didn't download scripts, recepies or 0 days. Kids wrote there own programs.
Today script kiddies have to rely on more experenced programmers to write simple scripts to get the job done.
Profesionals think thats good. "Think how bad things would be if thies kids could write code?".
You may think this comes with a userfriendly operating system. But this actually comes from Dos.
The profesional PC software develupment tools were priced well outside the price rage of the avrage user let alone someone who just forked over over $1,000 for a home computer. (In the 1970's $1,000 was a lot for a home computer).
Even today $100 is a lot to ask just to "mess around".
As a result the PC discuraged non-profesional software develupment. I think this was IBM and Microsofts way of attracting profesional software develupment. You had no threat of compeating with public domain counterparts.
In the 1970's video games were like a gateway drug to programming. But with the death of the "programming language as the os" systems a whole generation of tech savy kids grew up never knowing how to write code.
I don't see how someone who learnned how to code in a Microsoft trainning session could keep pace with a programmer who wrote his/her "Hello world" before hitting puberty.
I'm sure we can all find industreal practaces that contribute to the poor quality of code but quality control didn't exist 20 years ago so why is software quality taking a nose dive?
The problem is not the art, it's the "artists".
Programmers are analagous to lawyers now. It used to be that passion and a genuine interest was why most people were in this business. Now most people arbitrarily pick CompSci because they think that will give them career stability, and really giving a damn about the art of programming doesn't matter much. So like lawyers, you have this new breed of people in the industry who are just there for the money and have no appreciation for the work and the accomplishment. You don't see lawyers trying to use their craft to change the world.. you see them chasing around ambulances. Likewise, you don't see programmers these days trying to make things better.. you see them promoting ASP, Java, PL-SQL, and a hoarde of other get-bys so they can collect their check and move on.
Why software still stinks
Programming must change -- but how? At a reunion of coding pioneers, answers abound.
- - - - - - - - - - - -
By Scott Rosenberg
March 19, 2004 | In some quarters today, it's still a controversial proposition to argue that computer programming is an art as well as a science. But 20 years ago, when Microsoft Press editor Susan Lammers assembled a collection of interviews with software pioneers into a book titled "Programmers at Work," the idea was downright outlandish. Programming had long been viewed as the domain of corporate engineers and university computer scientists. But in the first flush of the personal computer era, the role of software innovator began to evolve into something more like the grand American tradition of the basement inventor -- with a dollop of the huckster on top and, underneath, a deep foundation of idealism.
It made sense that the people writing the most important code for the new desktop machines were ragged individualists with eccentric streaks. At a panel on Tuesday (sponsored by the SDWest conference and Dr. Dobb's Journal) that celebrated Lammers' book, seven of the 19 original subjects of "Programmers at Work" lined up on stage to talk about what's changed in software over the past two decades -- and demonstrate that they have lost none of their cantankerous edge.
In "Programmers at Work," Lammers told the crowd, "I looked at the programmer as an individual on a quest to create something new that would change the world." Certainly, the panel's group lived up to that billing: it included Andy Hertzfeld, who wrote much of the original Macintosh operating system and is now chronicling that saga at Folklore.org; Jef Raskin, who created the original concept for the Macintosh; Charles Simonyi, a Xerox PARC veteran and two-decade Microsoft code guru responsible for much of today's Office suite; Dan Bricklin, co-creator of VisiCalc, the pioneering spreadsheet program; virtual-reality pioneer Jaron Lanier; gaming pioneer Scott Kim; and Robert Carr, father of Ashton-Tate's Framework.
But for all their considerable achievements, this was not a group content to snooze on a heap of laurels. In fact, though the hour-and-a-half discussion was full of contention, one thing all the participants agreed on was that software today is in dire need of help. It's still too hard: not only for users struggling to make sense of poorly designed interfaces, but for programmers swimming upstream against a current of constraints that numb creativity and drown innovation.
These veterans shared a starting-point assumption that the rest of the world is only slowly beginning to understand: While computer hardware seems to advance according to the exponential upward curve known as Moore's Law (doubling in speed -- or halving in cost -- every year or two), software, when it advances at all, seems to move at a more leisurely linear pace.
As Lanier said, "Software inefficiency can always outpace Moore's Law. Moore's Law isn't a match for our bad coding."
The impact of this differential is not simply a matter of which industry gets to collect more profits. It sets a maddening limit on how much good we can expect information technology to achieve. If computers are, as it has often been put, "amplifiers for our brains," then software's limitations cap the volume way too low. Or, in Simonyi's words, "Software as we know it is the bottleneck on the digital horn of plenty."
Most successful programmers are at heart can-do engineers who are optimistic that every problem has a solution. So it was only natural that, even in this relatively small gathering of software pioneers, there were multiple, and conflicting, ideas about how we should proceed in order to break that bottleneck.
Simonyi believes the answer is to unshackle the design of software from the details of implementation in code. "There are two meanings to software design," he explained on Tuesday. "One is, designing the artifact we're trying to implement. The othe
That's an interesting point. Somebody will often post a copy or mirror of an article or web site if the original has been slashdotted. The copy has been presented because the original is unavailable due to technical reasons: It is the author's intent to keep the page up, but there isn't enough bandwidth. Is that still copyright infringement if permission hasn't been obtained prior? What about Google's cache?
It is impossible to enjoy idling thoroughly unless one has plenty of work to do.
- Jerome Klapka Jerome
Then you usually don't hear from them again. Want to know why? Because they're wrong.
The fact is that regardless of what methodologys used when developing software, in the end you are simply giving instructions to the computer what to do. No matter how many layers of tools you try to add on top of this, in the end you want to giveinstructions to the computer how it should solve the problem at hand. What it all boils down to is that the more complex the problem is, the more detailed must your instructions to the computer be.
Allow me to give an example: If you have some calculations to perform you can do that in a spreadsheet app, but when your formulas grows more complex you start scripting the spreadsheet. After a while even that isn't enough and you write a separate VB (or other scripting language) app to do this for you. Again, the problem might grow to the level that even your scripting language can't handle it and you sit there with a full app implemented in Java or C++ which solves your original problem. If you happen to be a CS professor, you will start thinking: "why did I have to write this app so solve this simple problem? Programming sucks! We haven't evolved in 20 years! I'm going to write an app that takes the complexity out of programming!", you will publish an article on this, and then you'll spend the next couple of years trying to solve a problem that doesn't exist.
Are you old enough to remember the craze about 4GL? The reasoning behind that is exactly the same as what Charles Simonyi says:
Right. Brining programming to non-programmers. Think about it. Does it make sense? As soon as you start programming, you ARE a programmer. Why, then, do you want to limit yourself to a limiting point-and-click tool? This is where 4GL failed. While making it very easy to connect a few database tables together, the real business logic was hard or even impossible to create, and the resulting apps were extremely difficult to understand and impossible maintain.
One of the best tools that helps programming in recent years is, in my opinion, IDEA. It's a Java IDE that doesn't assume that the programmer is stupid and doesn't understand programming, but rather automatically creates the boilerplate code for you while you write the code. You still work with the code, you just don't have to write all of it.
There's an enormous difference between IDEA and the "4GL mindset". While IDEA acknoledges that the best way of writing code is by typing in the instructions that will actually run, the 4GL mindset assumes that people are incapable of learning this and need fancy icons instead. Allow me to clarify:"icons is not a good way of representing computer code.
It feels to me that the people who claim these things have realised that they are not the worlds bet programmers. They realised that programming can be hard, but instead of acknowledging this and try to be better, they decide that it's the "state of programming today" that is at fault. That if they don't know how to write good code it's got be the tools fault. It couldn't possible be that some non-academics can be better programmers than them, now could it?
So
The fact is that regardless of what methodologys used when developing software, in the end you are simply giving instructions to the computer what to do.
Blah. In imperative languages, you do.
In pure functional languages like Haskell, you don't.
And I really don't know why neural networks aren't used en masse to train computers.
I started off by thinking that I'd argue with the basic premise of this article - because for me programming DOESNT stink. But for me as a "web developer" the problems are relatively simple and well defined; the tools relatively mature and apt for the tasks in hand. I'm NOT having to reinvent the wheel like I often used to 5-10 years ago.
:-
But thats just for me and with MY approach to software development atm. In areas where the tools (languages, compilers, IDE, even OS) arnt well development things do certainly stink. A few years ago I had the job of writing some apps for windows CE. One of those apps was Java based, the other C++. It was a nightmare for several reasons
- The LANGUAGES. I was forced to use a VERY early version of Java. It was PAINFUL having to develop libraries of essential functions and routines from scratch. For the C++ work - all I had to do was write a simple web browser. I already had the renderer - writing the remaining code, something which would have been perhaps 1 days work with perl/python/c# - took over a month.
- The TOOLS. The Java IDE was OK...not great but OK. The VRE however...well lets just say that it never left beta. Visual C++ for WindowsCE? PRAY you never have to use it.
- The DOCUMENTATION. Often missing, or incorrect; I would often be using guesswork to figure out how to use an API call or how to do X.
- The TRAINING. HAHAHAHAHHAHAHAHAHAH.
The point of the above being that where a platform is mature and has had the time and investment in tool/language/documentation/knowledge asset development, it is possible to select a tool which will assist and enable the development work. PROGRAMMING SHOULD NOT STINK ON A MATURE PLATFORM WHEN THE CORRECT TOOLS ARE SELECTED FOR THE TASK IN HAND. For immature platforms - without the investment in tools, without the care and attention that is given to mature systems - then yes, it is going to suck. If you still think it "stinks" and are using a mature platform and tools...well sometimes complex problems DO stink to solve, however many people program for the joy/pleasure of solving those problems. If youre NOT enjoying it...think of a career change!!
Oh the above said though...yes SOFTWARE still stinks. Bigtime. But THAT is a seperate issue entirely and has much more to do with the fact that *software development processes* often stink.
Lack of soap!
-sig- It's not stupid, it's advanced -sig-
Is that it doesn't foster conceptual innovation. I still haven't made up my mind about software patents because it's a bloody damn shame that the author of Visicalc isn't making zillions of dollars off his idea just because some people one-upped him in a few months.
If you've ever worked in a non-IT job, you'd have seen the vast masses automating their work and occasionally doing actual programming (with things like IF clauses on cell formulas) within the spreadsheet framework.
Programming for the masses.
What conceptual innovations has the open source software movement come up with after the days of emacs and tex? I just see it one-upping its commercial counterparts (often doing it better, smarter).
As Steven Landsberg once put it, "the whole economics can be summarized in one principle: *people respond to incentives*". In open source, the incentive is on doing things closer to the UI (e.g. developing k3b, not cdrecord) and, what's worth, looking at what major companies with big pre-coding research labs do, and ripping them off. That's what the Octave folks have done with Matlab, that's what Mozilla's done with Opera and tab browsing, and that's what the KDE people have done with (kill kill kill) MSFT and integrated local file explorer/web browser.
The incentives are all wrong, and I'm really, really worried.
But still, I do not see any suggestions for a fundamentally better model or even any concrete problems with the existing one.
Its the editor!
No, not the IDE, its the model we use.
I've coded almost daily for over 25 years, so ponder this!
We're working the parse tree once removed and are forced into prose by the ancient conventions and a pathetic need to print.
We lack a model in which we work the parse trees symbolically/pictorially using the keyboard. One where we can zoom structurally, rotate and slice our model by patterns, flows and data-access regardless of instance and without regard for 'files'.
From the 'forest for the trees' department.
Cheers!
"Ads can be (are not always) annoying, in any medium, but they make the content possible."
Because there wasn't anything on the internet before people came along thinking they could get fantastically rich by posting tripe and charging for it?
Oh look, a free independant website. And another. And another. Must be an optical illusion.
It is now official - a Netcraft survey has confirmed: programming is dying
Yet another crippling bombshell hit the beleaguered AOL hax0r community when recently a survey conducted confirmed that up-to-date and factually-correct warez account for less than 40 percent of all submitted code, that CVS has fallen to pieces through the oppressive power of the editors, and that high school graduates won't fill out thinning ranks of programmers. Coming on the heels of the latest Netcraft survey which plainly states that programming has lost more students, this news serves to reinforce what we've known all along. Programming is collapsing in complete disarray, as further exemplified by failing dead last [leethax0r.orgcomedu] in the recent Netcraft survey.
You don't need to be a Kreskin to predict programming's future. The hand writing is on the wall: Programming faces a bleak future. In fact there won't be any future at all for it because programming is dying. Things are looking very bad for the site. As many of us are already aware, programming continues to lose coders. Red ink flows like a river of blood. Sourceforge is the most endangered of them all, having lost 62% of its open sourceteers.
Let's keep to the facts and look at the numbers.
Something about USENet post ratios, and the goat website going offline. Additionally, windows, menus, icons, and pointers are apparently both a bad idea and obsolete. Punch cards were the right answer, and only decades of difficult market restructuring will achieve a successful return to punch cards, this time driven by Haskell, thus obviating the need for monads.
Due to the troubles of Mozilla, abysmal sales and so on, Netscape went out of business and will probably be taken over by AOL who sell another troubled browser. Now AOL is also dead, its corpse turned over to yet another charnel house.
All major surveys show that programming has steadily declined in market share. Programming is very sick and its long term survival prospects are very dim outside of India. If programming is to survive at all it will be among programming dilettante dabblers. Programming continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, programming is dead.
Fact: programming is dying
This isn't news, it's a poorly written opinion piece.
Move along, nothing to see here.
The problem of near infinite time investment... of time and work versus finite amount of resources for small customer payoffs / results. It takes massive investments of time to get the computer to do some of the most basic interface and problem solving tasks so that humans can do and perform some simple tasks, even today. Tools and compiler/language development needs to get better. Right now many programs are too fragile, very hard for the end users to modify (without recompilation), and they are far from robust. Think of it this way, in an ideal world any program should be able to run on any platform without having to be recompiled and any necessary hardware/software dependencies would be automagically emulated (assuming you have the CPU power). Computer scientists have yet to create decent "building blocks" and tools that don't require a thorough understanding of how the tool itself was made. i.e. you don't expect a construction worker to know the workings of how his tool(s) was made or came to be manufactured or how it works internally, he can use it to perform all tasks from the intended "purpose" without ever having to understand how it was made or works internally from a single domain of functionality. Too many times programmers have to have cross disciplinary knowledge of their tools/etc that should not be required to get the job done. Weak analytic/development tools to help other programmers and new programmers demystify what is going on without having to write lengthly comments to tell other programmers what sections of code mean. This should tip you off right there that if you have to comment and explain something that should be as obvious as reading plain english sentences that mean the same thing you've got severe weakness on multiple person projects that shouldn't be there. No one ever gets confused about- "Today I went to the supermarket and bought some food." with "Today I picked up some food at the supermarket." If you look at computer programming languages today, its like learning a foriegn language because you're forced to "learn the rules", syntax of how the language works AND how it parses and a million other little "gotchas" when it interprets your code. Right now programming tools to create things are simply in the dark age. How many lines of code does it take to create buttons, lists, input boxes, programmer and user friendly functionality from scratch? It takes a massive investment of time and energy today just to create the meaningful building blocks let alone full programs.
Show me a non-trivial piece of software software that doesn't stink. I'm willing to bet that it flat out just does not exist. Period. I have never in my 20 years of programming seen a large piece of software that didn't stink. I've worked at all sorts of places. Open-source, small companies, large corporations, government agencies, and all of the software sucks.
We should not be asking the morons who put us where we are to fix the problem. To suggest they have a clue is ludicrous.
We need something fresh, something new, something creative to solve this problem. We have yet to hear from the person or people who will give us a revolution in software. It doesn't have to be like it is. We have been approaching the creation of software from the wrong angle since the beginning.
The ratio of people to cake is too big
hmmm... Mechanics are more like IT people. Like the techs that fix your network connection and install your new hard-drive.
I think programmers are more like the engineers that designed the cars and parts you're talking about.
As others have mentioned I think one of the major problems in communication. The moron who put that spark plug in an inaccessible position behind the header is no different than the moron who cut and pasted the same code in 50 places throughout an application.
I have been working in industry for a bit over 7 yrs and have made a few observations that I believe makes software suck:
-People try to rely on process to fix 'common sense'. By common sense I mean being careful, meticulous, and using one's brain for each situation one comes across. Granted, I work in a large corporation and this may not apply to some of the smaller companies, but I have noticed that when we find a bug, or have some sort of other development issue, management tacks on more process to fix it. It's of course normal for people to make mistakes but sometimes you just have people that continually use poor judgement - get rid of those people and get others who can do the job right!
-Today's engineers have a large tendancy to overarchitect, doing MUCH more than is required; overthinking what possible changes may occur in the future and designing code around that idea (this idea isn't bad in and of itself, but I have found people get carried away in this area) - What happened to the KISS principal?
-I may sound horribly outdated, but I have serious questions as to whether OOP has bought us anything as an industry. Sure, when used properly, I believe it can have some benefits. BUT I think it gives the programmer so many powerful tools, that incompetant programmers (of which are there many) turn those tools into powerful weapons. Most of the projects I have dealt with have been C based (~90%) - the rest, some sort of OOP (the remaining 10%). Even though the quantity of procedural code greatly outnumbered the OOP, the two most confusing, sh*ttiest pieces of garbage were OOP - I don't this this is a cooincidence. I have found that people can learn the techniques and tools of OOP, but often they fail to understand the philosophy and why it was developed in the first place. Abuse of OOP creates mass amounts of crap code that needs to be maintained.
The problem isn't the tools. The problem is that people don't know what to do with them. It's either been done before, or you need to invent it. How are different tools supposed to ease invention or make people more creative? Ever notice how when you *do* encounter someone with a a creative spark, they manage to get the job done with the tools available?
I would take this kind of bullshit seriously if someone could present the following: "I have a great idea, and here's what it is, but I can't implement it well using the tools available." Basically, all we're hearing from these folks are excuses as to why they haven't accomplished anything.
Because Programmers Don't Shower?
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
Please mod parent up: +5, Funny!
The only reason programming stinks is because algorithms can't be proven to work as intented. Unless a completely different method of 'programming' is invented, no matter what the language is, a tiny error will cause systems to collapse.
And this point (algorithm proof) is what distinguishes intelligent beings and computers: intelligent beings can prove an algorithm in their minds, whereas computers can't.
This is why the best programmers are the ones with the greatest analytical and synthetical capability: they are able to hold a much bigger model of an application and its states in their heads, than others, while simultaneously they can dip into the greatest level of detail.
I am intrigued with the idea that Lisp was the answer to everything -- strong typing but dynamic typing, eval-loop command line, and all of that. Now Lisp took a hit in the aftermath of the Lisp machine days, but with computers and Moore's law and advances in compiler and language technology, maybe it is time for the idea to come back.
Lisp, they say (Paul Graham, et al), was the victim of worse is better, and while a SUN workstation, Unix, and C were no where as "elegant" as Lisp and a Lisp-M, they were a heck of a lot cheaper, and people felt they could solve much the same problems with that setup and more. Now saying C is a Lisp replacement is a stretch, but saying Java is a Lisp replacement is getting a little closer (GC, reflection).
How about Python as a worse-is-better substitute for Lisp? Even Paul Graham admits it is getting close.
Python is Free as in Speech, Free as in Beer, a unified language with no spun-off dialects. Java has SUN controlling it, C# has Microsoft owning it.
If Python is to become the heir to Lisp, it is going to need arrays of value types, compilers (yeah, yeah, I know about various array classes and Psyco, but they are works in varying degrees of progress). But speaking as a Delphi programmer who has done some work in C++, Java, and C#, I think Python has potential and is something I am going to be looking at as it evolves.
He can fucking say whatever the fucking hell he fucking wants.
It's the POINT that should count, not the style.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
Any CS department that allows themselves to be considered a "fallback" is doing the entire CS community a huge disservice. Are they teaching programming with VB6 and database design with Access (or MySQL) or something?
Now Lisp took a hit in the aftermath of the Lisp machine days, but with computers and Moore's law and advances in compiler and language technology, maybe it is time for the idea to come back.
:-).
The problem w/ Lisp seems to be that not many programmers like it. Even the ones that try to like it, and learn it in school.
If you teach someone Python, it is extremely probable that the pupil will become a Python fan. Teaching people Lisp (or Scheme) seems to have pretty much the opposite reaction. Some of it is probably due to shoving FP down their throats, but not all.
Lisp, they say (Paul Graham, et al), was the victim of worse is better,
Wasn't it Richard Gabriel?
How about Python as a worse-is-better substitute for Lisp? Even Paul Graham admits it is getting close.
Actually, Python already seems to have replaced Lisp. Only the die-hard macro freaks stick with Lisp, most dynamic typing - first class functions - simple semantics people have picked up Python.
If Python is to become the heir to Lisp
Curious wording you have here. Python has beaten Lisp in popularity ages ago. Perhaps you mean a technical heir to Lisp? Lisp is by far not a "king" in anything, except perhaps power of expression. Many would argue that it is too powerful to be practical.
But speaking as a Delphi programmer who has done some work in C++, Java, and C#, I think Python has potential and is something I am going to be looking at as it evolves.
Better yet, starting hacking in Python right now. It doesn't *need* to evolve, it's excellent as it stands. I'll take all the evolution with open arms, but the beauty of programming in Python can take your breath away even now.
It really opens your eyes and helps you see how the rest of programming community seems to be still living in dark ages. I believe this is how Lisp people feel about their language too, so I guess we are in the same boat in a way. There seems to be a weird synchronizity b/w Lisp and Python. Both are probably manifestations of some deeply profound programming archetype
Save your wrists today - switch to Dvorak
Your basic structured, modular, procedural program has a fairly predictable flow of control. But what do you do if you have a GUI file list view and some program "underneath" deletes a file. I don't know if there is a simple way to do this in a procedural model, but in an OO system you simply have a call back to notify the file list view that the available files have changed and the file list view updates itself.
Now the call back could be implemented as the override of a virtual method to the base class, or it could be a Java style action listener, or it could be a call to a function referenced by a function pointer in a table as with Gnome. In any event, you start to get interesting side effects and interactions when you do this. Anytime you invoke a method of an object that calls out to anything, there is no way to insure that it doesn't call back in to that object to a method that changes the state of the object out from under you as it will.
OO solves one problem, that is provides elegant expressions of ideas that would be a rats nest of procedure hierarchies, state variables, and polling loops, but introduces another problem: "Hey, where did that method call come from?"
Don't the good folks at Salon know that no one at Slashdot ever bothers to read the article?
When it comes to GUI programming, nothing beats Smalltalk in the ease department. Smalltalk is smart enough to make some convenient assumptions and dynamic enough to let you whip up data structures as you need them, so the nature of having to fill out structs like tax forms is somewhat ameliorated.
Cocoa has ease and power somewhat approaching Smalltalk's, which is why it's so popular.
N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
A poster above state one part of the problem: you have to give the computer explicit, detailed instructions to get it to do anything useful. Using a non-procedural language doesn't change this fact, because the other part of the problem is that the machine is a procedure machine. All modern CPUs are Von Neuman machines, they work by proceeding from one instruction to the next unless they encounter a branch. On this type of machine it will always be possible for a single error to bring the whole system down. With programmable "hardware" it may well become possible to start building machines that are partially non-procedural, but the Von Neuman architecture actually works - so it won't be going away anytime soon.
The industry's been happy with the trend because it drives salaries down or at least keeps them from going up as fast as they would have if only people interested in computers had gone into fhe field. Take a bunch of dimwits, slap them in a contracting house, use some marketroids to spice up the product by lying about it and you have yourself a business. It's not doing Computer Science or computer scientists any favors but who cares? Everyone's making boatloads of money.
Hell of it is, even if you could buck this trend and hire an entire company of very strong programmers and compliment them with very strong managers, you'd have a hard time differentiating yourself from the other bozos in the market.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
This image of Gates liberating source code print outs from dumpsters made the whole artlicle worth reading.
Religion is the main cause of atheism.
Just a random, but somewhat related thought....
IIRC, Stephen Wolfram has argued that there exists a Principle of Computational Equivalence. (Kolmogorov and Chaitin said similar things in a more rigourous way.) In short, PCE says that any computation to describe certain phenomena would take a similar amount of time to occur as the phenomena itself. In other words, massive parallelism or some other intrinsic property causes some phenomena to be so computationally intractable, that it would be just as quick to take a measurement of the phenomena as opposed to mathematically computing it ourselves. Algorithmic Information Theory says that some data is so random that the program to describe it is of a similar message length (in terms of information) as the actual data itself. Thus there is a hidden complexity in the data.
I wonder what Kolmogorov's view of Brooks' Mythical Man Month would be. Could it that software is complex because software is Complex? Perhaps we've reduced software to it's most reduced form. In other words, maybe there exists no more efficent way of describing the phenomena we wish to describe. Is the data that we describe in the business world is so random, that no set of instructions can reduce it by any signifigant order?
What do you mean my sig is repetitive? What do you mean my sig is repetitive? What do you mean....
Gates went on to say "... In my case, I went to the garbage cans at the Computer Science Center and I fished out listings of their operating systems."
Doesn't he realize those operating systems are copyrighted? Bill Gates programming knowledge, and thus his entire empire, is based on copyright infringement. The shock! The horror! How dare he learn from the efforts of others without paying a licensing fee!
Seriously, the irony is killing me. I mean making me laugh.
The enemies of Democracy are
Many people have attacked the problem from how Developers should write software. As many have mentioned, the ridiculous management schedules and push to just "get it out the door" tends to lend itself to corner cutting in design, coding, testing, etc.
I think that it is up to the End Users to start demmanding better. None of "This Software is provided with no warranty" crap. Somewhat expected from Free Software, but I can't begin to understand how real businesses that spend millions of dollars on commercial software can continue to stand this. If you bought a car with even a fraction of the defects seen in most commercial software packages, you would return that thing so fast it would make the dealer's head spin.
People will argue that building a car and building a desktop application have entirely different sets of risk and expectations. The desktop application will (probably) not kill you when it crashes. There are all sorts of regulations and lawsuits that exist to keep the manufactures very concerned about the quality of their product.
The same is needed in the software industry. Until there is a major demand for high quality products, where users no longer expect or even tolerate that they will find bugs, software will continue to give into buggy, quick and dirty code that must be replaced every 18 months.
There exist software industries today that have incredibly tight quality control and testing (medical & military for instance) and will not tolerate bad code or bugs. Their Software is far less feature rich but far more robust.
End Users of the software need to demand higher standards from their software before the state of programming will really get better.
"There are two meanings to software design," he explained on Tuesday. "One is, designing the artifact we're trying to implement. The other is the sheer software engineering to make that artifact come into being. I believe these are two separate roles -- the subject matter expert and the software engineer." Giving the former group tools to shape software will transform the landscape, according to Simonyi. Otherwise, you're stuck in the unsatisfactory present, where the people who know the most about what the software is supposed to accomplish can't directly shape the software itself: All they can do is "make a humble request to the programmer."
I work on a project where real time control software is written by software artists who only know software. Getting them to meet the needs of the project is like pulling teeth. They do not understand the needs of real time control software. If others beg and negotiate a lot they can get some of what they need.
Getting this project to work has been excruciatingly slow and frustrating.
But this is beautifull code. It is the easiest to read code I have ever seen. It is the best organised code I have seen. But the performance ot what the code does is rather poor.
I used to work in a very competative industry. The hardware control engineers would write the control code. We would gets things functioning quicky. The code would really meet the needs of the project.
But it was butt ugly code!
Is there some way to get what the projects need and get readable well organised code too?
Religion is the main cause of atheism.
That's a fair question, and one that comes up repeatedly.
The best explanation I've seen so far is that no-one wants to risk the test case, on either side. There is a strong case that Google's cache, the Wayback Machine, the Google Groups archive of Usenet, and various other on-line archives are in blatant violation of copyright law as it applies in many countries and under international agreements. The only defence they're going to have when someone does try it on is a series of arguments based on fair use provisions (which not every jurisdiction agrees on) and acting for the public good, in that they arguably provide a useful service.
In opposition to that, there are numerous potentially damaging side-effects of these sites, which are easy to overlook unless you've been the victim -- for example, if you're Salon and you fold due to lack of advertising and/or subscription revenue because some smart-ass posts your new article over on /. every time you write one.
It's just a case waiting to happen, and as someone who's discussed this issue in some detail on several occasions, I think the outcome should be clear, both morally and according to the law as it applies in most places. I certainly wouldn't want to hold Google stock when the verdict was announced...
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
"Oh look, a free independant website. And another. And another. Must be an optical illusion."
Sorry, could have been clearer. I was talking about commercial websites (like Salon). Independent / non-commercial / non-reader-paid websites (such as tax-supported ones) are great too.
timothy
jrnl: http://tinyurl.com/c2l8yr / foes: http://tinyurl.com/ckjno5
OK, before we start, let's be clear that you just said all that matters. If you object to anything else, it's nothing but your personal opinion, and if you want things to change, you should be campaigning to update the law, not ranting on Slashdot.
The Web would be nothing but an academic toy without that commercialisation. The use of the technology is evolving quickly, just as any new field does, but that evolution does not give it the right to violate the accepted rules of society. The Internet is nothing special in the eyes of the law, nor should it be. It is simply a new context, which requires clarification or adjustment, not a complete departure from existing norms. Understand this, please.
No, it wasn't. It was designed to promote the generation of content in the interests of society, by recognising that producing good content requires investment, and that by offering reasonable guarantees to the authors in return for that investment you will encourage content generation.
I dislike the fact that the editors accepted the submission under the circumstances, but two wrongs do not a right make. And cut with the "impetus" crap: someone does this pretty much every time there's an interesting article hidden behind a front-end, even when all the front-end asks is a little advertising revenue from you in exchange for showing you their article.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
This is some serious copyright infringement, man. Ripping an article verbatim and posting it on another site.
Back in the early 90's, I took a programming languages class. I was amazed that the first non-trivial program I ever wrote, that worked correctly after the first successful compile, was written in ADA.
"I don't know why I bothered to type this in."
On the other hand, a professional in this field who isn't at least aware of the benefits of both low-level languages and functional programming probably has such a hole in general knowledge of their subject that they'll never be a "truly good programmer". You don't have to use them, any more than you have to be some sort of L337 Hax0r d00d who runs Linux because it's cool. But some awareness and appreciation of the strengths and weaknesses of different tools and approaches is elementary to becoming a competent practitioner of any craft -- not an expert, just competent.
Until we get away from this attitude that writing a basic database front-end in Visual Basic or an eight-week course in Java and OO qualifies you as a competent professional, and get back to the point where the average developer has a basic appreciation of the broader issues in their subject, we will continue to write crappy code, the world will continue to succumb to script-kiddie hacker wannabes, business software will never live up to its promise of boosting efficiency for the real work your company does (whatever that is), and so on. That's what you get for hiring incompetents, and sadly, incompetence has become the norm in our industry.
This is not elitism. It's simply advocacy of learning your subject before practising it, and taking a little pride in your work. Both are terribly old-fashioned values in today's high-tech world, and terribly politically incorrect, but there you go. You wanted to know how to improve things; I'm just telling it as it is.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Physical products - cars, desks, pacemakers, light bulbs, you name it - are produced from engineering drawings that specify exact dimensions, materials, tolerances. They are manufactured on machines that themselves have been engineered to great precision.
Until software can be specified with such a degree of precision, until there is a software 'engineering diagram' that leaves nothing to be misinterpreted or misunderstood the developer will be left to his own machinations, and the industry will be left to the capabilities of its practicioners.
As it stands, no one can tell the developer just exactly what they wish to have built, no developer can be sure they've met the full set of true (not the stated) requirements.
Better languages, better software tools, better developer training will only do so much. It must eventually come down to the software 'Engineering Diagram' that is precise, accurate, and that ensures that the measure of correctness is unmistakeable.
- Sig this!
>The problem, IMO, is that providing a specification that is detailed enough and correct enough to generate a correct program from is just as hard as writing the correct program in the first place.
Absolutely.
Once upon a time, there was a chemical plant. I read about it in a book about safety engineering.
The chemical engineers gave the programmers a spec that looked complete and reasonable. Among other things it said that in the event of an alarm condition the software should "step away from the controls", leaving everything unchanged.
Then one day the software had just added a chemical to a tank that caused a reaction. It was about to start the cooling water when an alarm went off, due to an irrelevant gearbox overheating elsewhere in the plant. The reaction went ahead without the expected cooling. Boom.
The chemical engineers were so skilled that their knowledge was implicit. It never occurred to them that someone might start the reaction first and then turn on the cooling water. The programmers didn't know chemical engineering and it didn't occur to them that the order mattered (though certainly they should have wondered if there were atomic transactions with the plant controls!).
In some ways writing a specification is harder than writing a program -- you can't run a specification to see how it work. If you could, it would be a program.
Its simple really.. Employers don't want quality.. I constantly got criticized when I started making something truly great. Mainly because my boss lacked technical understanding.
Yeah sure. Pick up a "Programming X in 24 Hours", play with it for about four years, and you too will be just as well-trained as the mechanical engineer who designed your car engine.
Not.
Some of these comments were valid 10-20 years ago when case tools were a lot worse. But it is changing. He needs to do some coding again to whats out there.
"Sorry, could have been clearer. I was talking about commercial websites (like Salon)"
Yep, it's pretty awful watching people like Salon trying to operate a website -- kind'a like watching an amateur at anything failing.
For any other website, it's surprisingly simple. Write something interesting, put it on the web, and people come to your site and read it.
Then newspaper companies try the same, and completely fail.
They design a subscription system, spend years sorting out credit-card handling, account management, setting up the website to track people, setting up systems to stop images being linked to, setting up referer logs and browser-detects, setting up banner advert servers, loggers, and systems to charge advertisers. Setting up systems to convert simple text stories into flash or images or 10 frames, or anything to make it more difficult to copy.
And then after a hundred thousand dollars have disappeared into website design, start copying stories from the newspaper onto the website. And wonder why so few people are jumping the hurdles to get to any of their content.
Then having a meeting, wondering why nobody's subscribed, and spending thousands more dollars setting up a system where people can watch an advert and do something to prove they read it, and setting up a temporary ID and making it so people can use that ID to read content, and doing the logging and the tracking and the cookies to make sure that only one person can use each ID at a time.
And they wonder why the website isn't making a profit.
Eventually they get a few thousands of subscribers, and rack their brains trying to think how to make the site more profitable, even as they spend 60K per year on DBAs to handle all the user-ID and user-tracking databases, and the same again on support staff to handle lost passwords and account cancellations.
Yep, it's like watching a newbie bricklayer's wall falling down each time he builds it and wondering what's wrong. So bad to watch, you almost feel compelled to go over and offer them a clue. But they'd never take it. They know what they want, and it's big-budget.
I'd say you have to educate the people writing the code. Either you give the coders a quick introduction to control theory or you give the hardware engineers a course in writing readable code. You could of course do both and try to make them "meet at the middle".
My point isn't that you should teach the CS guys how to solve control theory problems, you already have people for that. The point is teaching them enough so that they know they actually don't know anything.
That would be EXACTLY, DIAMETRICALLY wrong.
In the real-world, programs need-to be idiot-proof, because the number of idiots that purchase the software will FAR outnumber the uber-geniouses that will. Guess which demographic will cost the developer more in time spent doing technical support? (hint: not the geniuses.)
Geniuses can get by with an application that requires the user to do things like translate coordinates from an n-dimensional array into a linear string (1-dim array), because they can do those things in their head. The rest of us want computer programs in order to AVOID doing tasks like that.
MAYBE the perfect programmer is one who is suffering from multiplepersonality disorder: an idiot and a genius with access to the same knowledge, of course!
Or maybe it's not that simple.
What is the difference between a small revolutionary change and a large evolutionary change?
I've gone through the silly day passes before, and I'm using lynx! It doesn't require any plugins, just clicking through 10 or so ad banners that I can't see. :)
You guessed it, in Win32, wParam is 32-bits long.
Hungarian notation is misleading and counter-productive, and should be consumed with the greatest of caution.
Writing stuff in C gives you speed and almost total freedom. Nowadays you can even write drivers entirely in C. Pascal and Ada tried to address quality issues by limit the freedom with declarations. OO languages like Simula, C++ and Java tries to address reuse. Interpreting languages like BASIC, Perl (semi) and shell scripts adresses the compile time issue. But who/what adresses the way we attack the problem?
The common denominator for all languages needs to be adressed. The text file! Just think about it, how much time is spent just to format and handle the chunks of code that should carry out your creative solutions? More than you think including missing #includes, linker arguments, shared/private symbols, bugs related to text file scope (static globals) and lazyness not refering across text file boundaries properly when the project grows.
Smalltalk tried to adress this by making everything OO in a super inheritence metaphore, but to me at least I just got confused because the base functionality is so huge. Maybe they are onto something but its far too complex to gain popularity and I don't think it has the simplicity needed to succeed. Many incremental compiler projects has been promissing I think but we haven't seen a real usable and working environment yet.
I do think that with some slight adjustments to the C language removing the text file as scope and the #include CPP directive a base for a better and creative programming paradigm could start. Instead all globals (variables and functions) should be stored in a "scope tree" where the actual storage should be language idependent. Each level in the scope tree should require an API declaration. Each node could be idependently compiled and incrementally linked. Emacs would work directly on the scope tree. The system should be able import C projects and detach the code from the text file structure.
This would give the programmers back some of the energy and creativeness wasted on dull tools and malfomed source code trees of today, without loosing the huge C base of sources out there and instead focusing on the language itself.
I know this is just a dream I have had for a long time and maybe someone already started on a similar project somewhere?
I have been working in industry for a bit over 7 yrs and have made a few observations that I believe makes software suck:
-People try to rely on process to fix 'common sense'. By common sense I mean being careful, meticulous, and using one's brain for each situation one comes across. Granted, I work in a large corporation and this may not apply to some of the smaller companies, but I have noticed that when we find a bug, or have some sort of other development issue, management tacks on more process to fix it. It's of course normal for people to make mistakes but sometimes you just have people that continually use poor judgement - get rid of those people and get others who can do the job right!
-Today's engineers have a large tendancy to overarchitect, doing MUCH more than is required; overthinking what possible changes may occur in the future and designing code around that idea (this idea isn't bad in and of itself, but I have found people get carried away in this area) - What happened to the KISS principal?
-I may sound horribly outdated, but I have serious questions as to whether OOP has bought us anything as an industry. Sure, when used properly, I believe it can have some benefits. BUT I think it gives the programmer so many powerful tools, that incompetant programmers (of which are there many) turn those tools into powerful weapons. Most of the projects I have dealt with have been C based (~90%) - the rest, some sort of OOP (the remaining 10%). Even though the quantity of procedural code greatly outnumbered the OOP, the two most confusing, sh*ttiest pieces of garbage were OOP - I don't this this is a cooincidence. I have found that people can learn the techniques and tools of OOP, but often they fail to understand the philosophy and why it was developed in the first place. Abuse of OOP creates mass amounts of crap code that needs to be maintained.
What school do you go to? At my school people who failed out of CS ended up being Chem E.
Yea, I'll never be able to understand we people keep
writing c code, in large projects, when ada is available.
I don't know anybody who's learned a real lisp in school. Generally, it's scheme taught with a focus towards recursion and lambda. Scheme is a language which has been intentionally trimmed to be as "pure" as possible.
Lisps which have more built-in functionality aren't covered. Like iteration! OO! All sorts of useful things. Common Lisp is a completely different experience from Scheme. I was taught Scheme in school. Hated it. Now love Common Lisp and even Emacs Lisp (in Emacs, at least).
So I disagree that many programmers have been taught Lisp and dislike it. That's like saying that people have been taught C++ and disliked it when really, they've been taught C or java. (Both in the same family, but very different.)
The reason we do this is largely because Ada compilers tend to be expensive, buggy or huge (sometimes all of these). That said, Ada is a really nice language to program in. It was the primary teaching language at Adelaide University when I did my degree, and certainly helped force good programming habits. Although it's possible to write horrible code in Ada, it requires a particularly dedicated kind of stupidity, and the nice thing is, that if you get a clean compile, you can be pretty sure the program will do something sensible (but not necessarily what you intended).
What a long, strange trip it's been.
One thing I'd like to see cleaned up in Python is support for functional programming. Proponents like to go on and on about how well Python handles FP, but in reality it is awkward at best. The first thing that jumps out is that a lambda body can contain only one expression. This doesn't sound terribly restrictive until you realize that Python has a sharp divide between "expressions" (they may return values) and "statements" (they don't return values, and may have an implicit block), and that there is no explicit block construct. The former makes it kind of hard to make useful closures (since assignment statements are statements, after all), and the latter makes lambdas useless for all but the most trivial uses (after which you have to fall back on named functions for their implicit block). The obvious solution would be to make an explicit block-making expression, but I don't know how this would work with the current practice of specifying all (implicit) block scope through identation. Another annoying thing is the inability to pass operators as HOFs (but then again, this ends up as one of the few uses for the crippled lambda).
One thing that Python totally rules at is structured imperative programming. Here is where the block-indentation really pays off - it allows a minimal syntax in terms of irrelevant punctuation, and mandates a legible writing style. Indeed, in C (and especially in C++), it is very easy (in the case of C++, I think it's encouraged) to write unreadable code - all the Python I've seen and done so far makes me think that one has to work against the language to produce hard to read code. And the C++ integration of Python can't be beat (the only Qt I like is PyQt). As I've stated in a recent posting, I think the best way to write C++ applications is in Python.
In the great CONS chain of life, you can either be the CAR or be in the CDR.
"There are two meanings to software design," he explained on Tuesday. "One is, designing the artifact we're trying to implement. The other is the sheer software engineering to make that artifact come into being. I believe these are two separate roles -- the subject matter expert and the software engineer."
There are two types of people in this world: those who can write code, and those that can't who whine and bitch about how hard programming is so they come up with stupid ideas like this one in hopes they can shackle the talents of those who can program their lame ideas.
Ruby on Rails Screencast
Quick way to drown out your code with noise.
Only people seem to benefit by it are rape and pasters ---
they tend to appreciate the unique namespace 47 lettered variables afford.
Because it IS hard and has very few ubiquitous engineering disciplines and practices to support creating a distinguished craft out of it.
It also offers lucrative fallacies to explain further the lack of those qualities. First, as opposed to "programming" (the real craft) "coding" (a more common practice) is NOT hard and almost any technical person can write code. And coding is unfortunately commonly mistaken for programming. Designing and writing maintainable programs that are as simple and elegant as possible, and then actually maintaining them is not included in the skillset of many people in the business. Most of the commercial software sucks and has a relatively short life.
Secondly, companies not investing in quality helps creating a breeding pit of bad, non-sustaining program-making habits. Sadly enough, customers are kind of used to the unfunctionality of computer programs, they won't demand standards on software quality. Therefore, it's not profitable to do a good job since technically inferior products often conquer the markets and set actually good products aside due to non-technical factors (as it was with Microsoft Windows).
I wonder how that works on the 'net? If they missed out on 20,000 hits on a 2 MB video, does that mean Slashdot would have to stream 40 GB of their video ad data to /dev/null?
Forget thrust, drag, lift and weight. Airplanes fly because of money.
Back in the days of DOS, I got hold of FST Modula-2. Previously I'd been writing C. What an eye-opener that was. I learned so much about "good programming" from using Modula-2 for a while. Later I had to do some work in Pascal (Turbo Pascal 7). I really think that using strict, strongly-typed, well-designed languages is a very valuable experience that every programmer should have.
Stick Men
I thought he was a MIT grad that just sat around growing his dreads and pretending to be a visionary.
Just say no to license servers!!
There are good programmers and bad programmers just like there are good engineers and bad engineers.
Your example of designing an engine is the same thing as saying any Joe can learn to write an OS in 24 hours. Not.
Some stuff is complex, some isn't dumbass.
The reason we do this is largely because Ada compilers tend to be expensive, buggy or huge
Wrong, wrong, and wrong.
GNAT, the GNU Ada compiler, is Free (as in speech and beer), commercially supported, and has been integrated into mainstream GCC development. Get it. Use it. Love it.
Users of debian can simply "apt-get install gnat" (and also think about getting gnat-gps gnat-doc ada-mode and ada-reference). Other distros probably have similar packages, Others can check GNUAda.org, which has packages for Linux, NetBSD, DOS, and OS/2.
I studied CS at NYU and took a programming languages class with Robert Dewar (main author of GNAT and president of AdaCore, the company behind GNAT, among other things (SPITBOL, anyone?)). One of the best classes I've taken at college.
Some programmers/consultants are the same way. The rate quoted is a little on the high side, and the work that sucky ones do is dodgy at best and is non-functional at worst. But, the client still has to pay, and he/she feels they were taken advantage of.
Both professions are ones that, a) the simple stuff is easy to do such as oil changes or Excel spreadsheets/VB, b) the harder stuff is exceedingly difficult to do yourself, and c) when you decide to take the harder things on, oftentimes you wish you hadn't because the problem is worse.
ACHTUNG! Das computermachine ist nicht fuer gefingerpoken und mittengrabben. Ist nicht fuer gewerken bei das dumpkopfen.
Having spent 20 years as a programmer, I can tell you that the first thing I have to do when working with someone straight out of school is to deprogram him/her. CompSci teachers just don't live in the real world of budgets and deadlines. Schools are geared to teach you how to take tests, nothing more. It takes a lot of personal effort to really learn something, and all a school can do is expose you to information. If all you do is pass tests, then you haven't really learned anything.
Programming is an art, and not a science. You may know the words and the grammar, but that doesn't mean you know how to write a novel. I can't tell you how many times I've had to clean up someone's "Gee, see what I can do" code that is overly complex, using language features that are inappropriate for the task at hand in the attempt to gain the appearance of proficiency.
A lot of programmers today forget that the purpose behind writing a program is to actually help another human being. They get caught up in the joys of this language, or that syntax, or -- heavan forbid -- which license is better to release the program under -- that they forget why they're here. You don't learn that in school. You learn that by being a user yourself, and remembering your struggles.
The reason that programming has turned into an assembly plant operation is that there aren't enough "artists" to go around. The economy in general, and IT in particular, will be seriously hurt by this, because companies don't recognize the distinction between the "artist" and the "factory worker". The artist is put on the assembly line for low wages, and has neither the urge, nor the means to innovate. Open Source will also be hurt by this, as such programming requires both time and money (hardware, at least, is not free), neither of which will be provided in abundance by the assembly plant.
Some days, I swear I should've learned to be a Plumber. At the very least, it's difficult to do that job from India!
P.S., Do you really expect that anyone in a place like /. would get your reference to Donald Knuth? Come on.
"My country, right or wrong; if right, to be kept right; and if wrong, to be set right." --Senator Carl Schurz (1872)
*cough*
Algorithms can be mathmatically proven, and have been.
The problem is wheither they can be proven completely in practical terms, not to mention proving an implementation of a particular algorithm.
In the time it would take for me to complete a proof of some piece of software I wrote, I could write a dozen (or even hundred) other programs. That and trying to develop the skills to perform a rigorous proof would have to be developed, which are (usually) never taught in a typical CS program at a university. Instead, mathamatical proofs of algorithms are usually a side curisoity that is done maybe once or twice (in a lifetime), and even then you give up trying unless it was a simple "Hello World" application.
I've also heard that good programmers are people who can visualize in multiple dimensions. This is not an easy skill, and in reality something quite rare. Most people can only visualize in two dimensions, with a great deal of struggling trying to get things to fit in a third. Even to grasp that there could be a fourth dimension and what that could be like is even harder to find still. I have some (simple) software I've written that has 10-15 dimensions of variables applying and relating to each other, and trying to convey that to somebody who doesn't get it can be quite difficult. If you've done some serious programming, I'm sure that you can relate to this, although you may not be thinking in the dimensional aspect unless it is pointed out to your directly.