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.
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.
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.
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.
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.
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?
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
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
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
"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.
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.
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
just remove all+the+search+terms
The same link here with extra words highlighted.
Saying Java is nice because it works on all OS's is like saying that anal sex is nice because it works on all genders.
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 silver bullet of programming already exists. Link.
For a minute there I thought you meant this silver bullet
I know that I am a much better programmer after a couple of "silver bullets".
Take the cheese to sickbay, the doctor should see it as soon as possible - B'Elanna Torres, "Learning Curve"
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).
[
Sadly it's the type of art where they paint with feces.
--- Ban humanity.
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
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.
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.
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
If you think this post had alot of obscenities, you should have seen the email I sent to salon.
Salon writes good articles for the most part, and they have had rough financial times. If ignoring an "internet commercial" means they get money to keep writing articles such as this one, so be it. I do not like it, but I understand they are just playing the system. I understand economics well enough to know that this is a necessary evil.
Now, as to your comment, please try to be constructive. I communicate with companies and my Congressmen on a regular basis, both email and snail mail. Some of the issues are very dear to me, such as the letter I wrote to Dell berating them for laying off American call center employees to outsource to India. Not once in my letter did I swear or come across as uneducated, unintelligent, or uncaring. Swearing and other vulgar language does nothing to help your cause. Be constructive. Do not just say "ads suck," provide them with a solution to your perceived problem. I think you will be hard pressed to do this, however. Their solution is very good for their company and not too intrusive to their readers, although it is intrusive.
24 beers in a case, 24 hours in a day. Coincidence? I think not!
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
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.
I think you're over stating your case.
In pure line count a minimal Java Hello World would only have one additional line.
It is crammed with keywords, and it contains the notion of Objects and Classes.
But I see that as a good thing - you can concentrate on the mainline code and introduce the student to control flow and so forth, but when you come to the concepts of classes you've got a nice immediate example to point to.
It's so much easier to teach a language when a common reaction to new information is "oh, I wondered what that was for" rather than "why would I ever need that ?"
Finally I have to completely disagree with you about type safety. A perfectly written and comprehended program does not need type safety. A real world program will never be either, and type safety will prevent some of the nastiest bugs from occurring and keep your data intact.
I have no problem with C in its place, but its place is not as a learning language or as a business language.
D.
--- These are not words: wierd, genious, rediculous
Lack of soap!
-sig- It's not stupid, it's advanced -sig-
> > > If you think this post had alot of obscenities,
> > > you should have seen the email I sent to salon.
> > Now, as to your comment, please try to be constructive.
> Try actually reading what he's pissed off about - the ad
> he got required his interaction before he could continue.
So? It's a *Slashdot* slip-up, not a Salon one. If he was angry, he should have berated "timothy" (the Slashdot editor of this story) for wasting people's time pointing to the Salon article without stating it wasn't free (this probably means timothy subscribes to Salon.) And then, maybe, also scold the story submitter (who was quite probably another Salon subscriber.)
Instead this guy blows up, spews profanities on Slashdot, *and* sends a (much worse) attack letter to
>
To be angry on somebody for no reason is not acceptable - anywhere.
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!
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.
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.
"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.
How does this get modded "insightful"? I'm sort of tired of people parading around their ignorance about programming disguised as 'good design sense'.
"Type-safety is like training wheels."
Yeah, right. One day you graduate to the level of Supreme Programming God, with the power to effortlessly remember the exact types of all the "void *" pointers they left lying around. And of course, you don't need type safety when interfacing to other people's code, because you're just so damn intelligent, you instantly understand everything about their code and don't need those 'training wheels'. Because lord knows we all understand exactly what the other programmers mean and don't need no steenking type system to communicate what should and shouldn't be legal.
"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."
I love Slashdot for these kind of broad-brush statments. Which language uses exceptions or RTTI as its 'main tool', exactly? And who the hell thinks exceptions and templates are more complicated than implementing the same features _without_ exceptions or templates.
My guess: someone who has never written a large program* or a program that actually requires generic programming or sophisticated exception handling (yes, sometimes it is OK to just print an error message and quit). The stuff about type safety also suggests near-total lack of experience with programming large systems with portions of the system written by other people.
Also, absent turning newlines into spaces, how do you write a properly formatted 1-line "Hello World" program in C? If you're going to complain about Java's main declaration and System.out, you should at least take into account C's main declaration, and the equally inscrutable (to a first-year student) '#include' line.
* Pre-emptively: to the people that always post about how you don't actually need to ever build large systems, because you can always build elegant collections of small, gem-like, perfect tools, please close your Web browsers and finish your sophomore CS homework.