Whatever Happened To Programming?

Mirk writes "In a recent interview, Don Knuth wrote: 'The way a lot of programming goes today isn't any fun because it's just plugging in magic incantations — combine somebody else's software and start it up.' The Reinvigorated Programmer laments how much of our 'programming' time is spent pasting not-quite-compatible libraries together and patching around the edges." This 3-day-old article has sparked lively discussions at Reddit and at Hacker News, and the author has responded with a followup and summation.

Comments

Programming == Cut & Paste

[Anonymous Coward]

Programming is becoming nothing more than cutting and pasting, especially with languages like java, that provide libraries that do "the hard stuff" and let programmers concentrate on "programming".

Programmers are now a dime a dozen. I can find 10 people who can cut and paste available on the internet and modify it to do what they want.

Good programmers on the other hand, are few and far between.

It seems everyone wants to be a "software engineer", but nobody wants to focus on the "hard stuff", and instead chant "let java/X do it for you".

Re:Programming == Cut & Paste

[binarylarry]

That's because programming isn't usually an endurance challenge.

"Making something that works" is more important than "talking about how hard you made your job for yourself"

Re:Programming == Cut & Paste

[EastCoastSurfer]

It seems everyone wants to be a "software engineer", but nobody wants to focus on the "hard stuff", and instead chant "let java/X do it for you".

I guess it depends on the goal of the programmer/engineer. If my goal is the solve a problem for a customer (as opposed to doing something to simply learn it) then I'm going to do that in the most efficient way possible. Should I be writing an entire stack of libraries every time I need to solve a problem? I hope not. Libraries that already exist make it possible to focus on and build solutions to even harder problems.

BTW, I think there is a lot of skill needed to be able to look at problem, figure out what libraries can/can not help and then pull it all together into a cohesive solution.

Re:Programming == Cut & Paste

[crazycheetah]

I wouldn't separate that too much. Some of us exist that can do the "hard stuff" and might even find and fix a bug in some of the libraries from time to time. However, when we're just making an app that works and fits in with the environment, a lot of the "hard stuff" has been done and is likely to be less buggy and more consistent with the environment than redoing the whole thing ourselves. Then, if it's open source, we can just fix bugs we find in the "hard stuff" and focus more on what we're actually doing.

Hell, things like basic sockets and other things that are fairly easy, really--every once in a while I forget to back that up or something stupid and instead of just doing it all from memory and by hand, I just copy and paste it off the internet, then rework it to my liking (by this time, I know the commands, but copy and paste is just faster). Of course, some times I like to do things that have already been done, only try to do it in a new way, just as an exercise (I'm down to programming as a hobby at this point).

I wouldn't be too harsh on copy and pasting, though. It can be a great learning exercise if you peel it apart and actually understand exactly what is going on and the different ways you can alter it. It's also a great way to get to know an open source library and be able to fix any bugs you find, or even add features to it, if that's your fancy. That's generally how I've done anything in that regard, to be honest.

Re:Programming == Cut & Paste

[benjamindees]

If my goal is the solve a problem for a customer then I'm going to do that in the most efficient way possible.

I realize you're just tooting your own horn, but you're living in fantasy land if you think this is how it actually works, or even should work. The customer might not even want the "most efficient" thing. They might want an over-engineered thing. They might want the safest thing. They might want the most environmentally responsible thing. They might want the most flexible thing or the most interoperable thing. They might want the thing that works with whatever broken systems they already have. They might want the thing that they can build upon to grow their business in the future. Hell, you might be getting paid by the hour, so your incentive might be to create things in the least efficient, but still passable, way possible.

Re:Programming == Cut & Paste

[j_kenpo]

I have to agree with parent. I've written an implementation of every method I use from libraries such as STL or Java at least once in my life, sometimes in such painful languages as assembly. I did it just for the sheer joy of it (yes, I love programming that much) and as a learning experience. In all those years, I learned a very important lesson, don't reinvent the wheel. I have yet to receive a set of requirements from a client that say "give me the least efficient/over engineered way to do X" that would compel me to ever again need to re-write a quick sort algorithm, container implementation, or string parser.

Re:Programming == Cut & Paste

[profplump]

You're making two assumptions here to make the grandparent seem wrong; he's only wrong if your unstated assumptions hold.

1) That "solve a problem for a customer" does not already consider all of a customer's requirements, including safety, over-engineering, environmental responsibility, flexibility, interoperability, or scalability. To the contrary, I'd suggest that all of those consideration are part of "the problem".

2) You're assuming that "most efficient" means "least amount of coding time". I'd argue that "most efficient" could easily include total costs/time not only in the first draft, but over the life of the project, including use of the finished code and future maintenance.

Re:Programming == Cut & Paste

[benjamindees]

First of all, just taking safety for instance, it's nearly impossible to determine how to solve a safety problem in the "most efficient" way possible. What's the "most efficient" way to build a safe nuclear reactor? Make one that is 100% melt-down proof? You waste nuclear fuel. Make one that is completely incapable of being repurposed for nuclear weapons? You increase cost beyond market feasibility. Don't build nuclear power plants at all? People die from lack of energy. What's the "most efficient" way to build a safe car? What's the "most efficient" way to build a safe bridge? There are simply far too many variables, all interdependent in subtle ways, to consider. Add an extra layer of corrosion allowance, for instance, and you may prevent a bridge from collapsing and save a dozen lives. On the other hand, you may trigger a resource shortage that bankrupts a major company and destroys a thousand. Physical implications are obvious, but software is analogous. Spend ten billion dollars writing the perfect space shuttle control software, and you might save a dozen astronauts. Fail to develop a viable space exploration program in time, and humanity could be wiped out by the next asteroid. You're right, though, those aren't really software problems per se, and should be clearly defined as part of "the problem". Often they aren't.

But, yes, I'm assuming #2. I think it's clear from the GP that this is the manner in which "most efficient" was used.

But my point is also that it's not just the "efficiency" of the program itself or it's maintenance. It's the efficiency of the entire business and how the software fits into it. The cost of software in most business cases is trivial compared to it's benefits. Which, I think, is the reason we see so much software being re-invented over and over again to begin with. What isn't taken into account, though, is the cost of getting software wrong.

Re:Programming == Cut & Paste

[Eudial]

Programmers who primarily do java are in most cases the quintessential deadbeat programmer. They're cheap labor; but as with most cheap labor, you get what you pay for. In this case, a bunch of cargo cult code pieced together from examples in the javadocs and from java blogs.

The thing about Java is that it allows anyone to write bad, but functioning code. It's possible to write good Java code as well, but it's exceptionally rare to see, as the training wheels that allow people to get bad code to work frustrates the hell out of people who don't actually need them.

If your goal is to ship the product ASAP no holds barred, then a Java programmer or five is what you seek. If your goal is to ship a well written product that is maintainable and efficient, then you seek someone with actual programming skills.

Re:Programming == Cut & Paste

[bertok]

I have to agree with parent. I've written an implementation of every method I use from libraries such as STL or Java at least once in my life, sometimes in such painful languages as assembly. I did it just for the sheer joy of it (yes, I love programming that much) and as a learning experience. In all those years, I learned a very important lesson, don't reinvent the wheel. I have yet to receive a set of requirements from a client that say "give me the least efficient/over engineered way to do X" that would compel me to ever again need to re-write a quick sort algorithm, container implementation, or string parser.

I've come with a rule of thumb I tell younger programmers:

Do it yourself, then throw it away and use the standard library instead.

The idea is that if you haven't implemented an algorithm or something yourself at least once, you don't really understand it. Once you've gained that understanding however, you're better off using the polished and bug-fixed version everyone else is using.

Re:Programming == Cut & Paste

[Sir_Lewk]

You want to troll on slashdot? Write original strawmen first!

Implement some things yourself

[thenextstevejobs]

Go ahead. It won't bite. Some things are over-engineered.

Re:Implement some things yourself

[Yokaze]

Some things may be over-engineered. But in my experience, more often it is the case, that people rather re-invent the wheel,
than they bother to try to understand, what someone else has done, and how it is supposed to work.
And over time, it will bite. Usually not the one who wrote the code, because that person is gone, but the project in whole.
And no, I don't see a difference in "own code" and foreign libraries, from a "long" term perspective, it is the same.

Re:Implement some things yourself

[kyrio]

You, need, to, add, more, commas,.

Re:Implement some things yourself

[Nerdfest]

Try reading it as William Shatner would.

Re:Implement some things yourself

[jayveekay]

You need, to boldly add, more commas [where no commas, have been placed, before!]

Re:Implement some things yourself

[dgatwood]

Agreed, mostly. If you have an XML parser for free (e.g. in a web browser), them XML is a great way to push structured data around. If you have to roll it yourself, it's horrible. Using libraries, it's somewhere in-between, depending. If you're going into a toolchain that expects XML or if you're working with a lot of structured text data, XML is probably a good choice. That said, it's quite possibly the most overused technology. Far too many people just automatically use XML where CSV file or tab-delimited text file would do the same job with tens of thousands of lines less code.....

And regular expressions are for light text processing and/or single-use (write-only) tools. Using them where a parser would normally be used is the quickest way to create fragile code that breaks constantly. :-) Been there, tried to maintain that, then ripped it all out and wrote a token-based parser.

Re:Implement some things yourself

[Interoperable]

No, it won't bite. It will segfault.

Frameworks

[Nerdfest]

There's still lots of interesting programming going on, and lots of interesting new languages. The ''Magic Incantations' are the same frameworks you used to have to write yourself, and even then you generally only did it once. It's gotten a lot easier to share the common solutions now, and we're free to do the real work.

Re:Frameworks

[Nerdfest]

... and in those cases you should. There's nothing wrong with re-inventing the wheel in some cases, especially where you don't want to drag around a ridiculous framework that does way more than you need.

Re:Frameworks

[tomhudson]

It isn't even a question of faster ... a lot of those "glued-together solutions" don't scale and are impossible to debug and maintain.

Re:Frameworks

[Opportunist]

The problem is simply: Why bother?

You are usually facing two choices:

1) Create a slick, nifty, fast framework yourself that does what you need. It will be lightning fast.
2) Use some sluggish can-do-everything-and-more framework out of the box that does 10 times what you need. Basically, it's like delivering a soup cube with a flat bed.

Option 1 will take about five times the development time, but save you well over 60% runtime.

Your boss will outright fire you if you opt for option 1. Why? Because it takes 5 times dev time for 0.5 seconds saved during use.

Machines today are fast. Much, much faster than what we need for programs to run. Hell, even games are today produced with sluggish frameworks that waste resources left and right, and they tend to be the programs that are most time-critical an "ordinary" user would get to see.

I hate this development as much as anyone who learned programming during a time when memory was scarce and gaining 10% run time speed was worth everything. But that simply ain't true anymore. Today you have programmers (I use that term loosly now) that look at you blankly when you ask them what sort algo they used, then they give you the name of some library function. No, they have no idea what the function does. Only that it somehow automagically sorts the stuff. Why this one and not the other one? Because they know this one, or it was the first the help file spit out when they searched for a "search function". But then again, it does not matter. The other function that might have been faster because it happens to implement an algo that is more fitting to the problem at hand would have saved about 0.0something seconds, because the machine running the program eventually is fast enough that it means jack what algo you use. Memory amounts today mean that it is pointless to ponder whether you really need double linked lists or whether you get by with single linked ones. Or that you use variables smaller than DWords to store integers.

So it doesn't really matter anymore whether you can program, or whether you even know just how much space and time you just wasted with that horrible choice of library functions that will probably eventually even do the work but are just about the worst choice for the problem presented. Modern computers are fast enough and have enough ram to compensate for programers' inaptitude.

Re:Frameworks

[jomama717]

Frameworks, like anything else, are fantastic when used properly but unruly beasts when they are used incorrectly. My current bane is legacy code that is a poorly thought out amalgamation of early version frameworks. I can hear my predecessors squealing with delight and saying things like "Spring and hibernate will magically handle all of my transaction boundaries and multi-threading? Neato!!" as I slog through 3-4 hundred line stacktraces (no joke) trying to debug a race condition. Brutal.

Re:Frameworks

[Ethanol-fueled]

A "factory" is nothing more than a buzzword which is part of the cancer that is killing Java.

Re:Frameworks

[Todd Knarr]

Except that what really happens is that you end up trying to use a sluggish can-do-everything-and-more framework that does 10 times what you need it to do but fails to do 2-3 critical things that you absolutely need to do. And between the time spent learning the can-do-everything framework and what parts of it you don't care about and the time spent kludging and hacking on it to fill in the missing bits, you end up spending more time than it'd've taken you to write your own from scratch or using more primitive tools.

Been there, done that, got the drawer full of t-shirts.

Re:Frameworks

[Hurricane78]

I absolutely hate frameworks. They are the same as libraries. But without the ability to plug them into anything. They want to be the core of your application, and not play with anything else.
They are a very “enterprisey” concept.

Please, all, stop doing frameworks, cut them into their aspects, and start doing libraries again! Nobody wants you elaborate all-encompassing framework that is its own inner platform and yet unfortunately lacks the very function you need the most.

Re:Frameworks

[complete loony]

That's the kind of thinking that leads to batch jobs taking an hour, that should be done in 5 minutes or less. I've seen way too many "programmers" that don't understand what their high level language is doing being their backs, so they end up copying memory around all the time. Or going off to ask the database the same question over and over in a loop because they couldn't be bothered to refactor the code so it cached the answer.

Re:Frameworks

[benjamindees]

That's the kind of thinking that leads to batch jobs taking an hour, that should be done in 5 minutes or less.

I've said this before and I'll say it again, because I've created plenty of unoptimized "batch jobs" that take longer than they should.

COMPUTERS ARE CHEAPER THAN HUMANS

A cubicle filled with racks of computers running inefficient batch jobs costs a tiny fraction of a competent person sitting in the same cubicle and optimizing every little thing by hand. And a program written in a high-level language is probably cheaper to maintain over the long run as well.

Re:Frameworks

[Tablizer]

I absolutely hate frameworks. They are the same as libraries. But without the ability to plug them into anything. They want to be the core of your application, and not play with anything else.

I've promoted the idea of "helpers" instead of "wrappers" (what you call frameworks). Wrappers hide you from the guts, but helpers allow you to work with them at a higher level when convenient without preventing you from getting at the guts when needed. You date helpers, but have to marry wrappers. It's usually easier to get out of a date than marriage (except maybe in Hollywood).

Helpers have the primary goal of automating the drudgery of common idioms, not to prevent you from sticking your tongue in the fan by locking it away, as frameworks often do.

And (good) helpers tend to be designed with a smaller granularity such that you can mix and match and rewrite and toss as needed. They may take more work initially than a framework, but they are also more flexible.

Helpers differ from "traditional" libraries in that they are a kind of framework, or set of frameworks, but with looser coupling between the parts.

Re:Frameworks

[EsbenMoseHansen]

Tragic story :) For C++ (also Java these days) knowing and researching what libraries are available is more than half the battle. I was readíng the list of what he was doing, and Qt provides at least he beginning of everything there in the language he wanted (C++), excepting the garbage collection (which makes little sense in GUI programming in general and especially none in Qt). That that was what they ended up with was even more funny in a tragic kind of way.

Re:Frameworks

[Burnhard]

Part of your skill as a developer is in applying the correct framework or library to the problem at hand. If your framework doesn't do the two or three critical things you want it to then I suggest you've chosen the wrong framework!

Re:Frameworks

[obarel]

That's just not true.

My first task at my previous job was to speed up a perl script that took 12 hours to run. That meant that until you got the results, you were stuck. It meant that "tweaking" the input parameters required a lot of preparation work, or just wasted a huge amount of time.

I didn't know perl, but I knew how to program and how to optimise. It took me two days to learn perl (just enough for the task) and to reduce the runtime to 30 seconds (I was told about the original programmer "he's a scientist, not a programmer"). The result was still written in perl, by the way.

The improvement meant that the script could be used a hundred times a day with different parameters, something that would have taken months. Your suggestion is to buy a thousand machines to crunch the numbers instead of optimising the script. That just doesn't make sense to me.

Re:Frameworks

[benjamindees]

A factor of 12 improvement is, in my experience, fairly typical. And, yes, you can maintain 100 computers for the price of a single competent programmer. So, while it's not the best solution, it is certainly a very economical one.

A factor of 1400 improvement, as you claim, is simply ridiculous.

Re:Frameworks

[gbjbaanb]

no, you cannot maintain 100 computers for the price of a single programmer - because you'll have to hire (or pay) for the sysadmins to manage them. There's a lot of hassle involved in computers that you probably don't realise occurs between hardware and software setup, there's networking issues, updates and managed downtime. In most corporates, just having 1 extra computer will cost as much as that programmer in terms of meetings, requests, forms and project managers for the assignment of computer to project, plus security reviews, etc etc etc.

A factor of 1400 improvement is not ridiculous. I've seen similar - a colleague wrote some code, but becuase he didn't realise the interaction of his way convoluted OO code, he ended up doing 3 pages (that's printout) of DB queries for every update packet - of which he received around 3 a second. Slow is not the word. Fixing it involved a little cache and remembering the results of the first query he made instead of repeatedly asking the DB for the same data.

Re:Idiot. Seriously.

[Saint Stephen]

I think you're seriously wrong. Have you ever seen the mathematics behind the early algorithms? Hardly sticks and rocks.

I think a better analogy would be to say that today's programmers are more like a Cargo Cult.

Re:Idiot. Seriously.

[Nerdfest]

I'm already at the gunpowder stage. My code has been blowing up for years.

Re:Idiot. Seriously.

[convolvatron]

slashdot. where don knuth is an idiot because he cant grasp the awesome power of php

Re:Idiot. Seriously.

[morgan_greywolf]

I think a better analogy would be to say that today's programmers are more like a Cargo Cult [wikipedia.org].

Do you mean the cretans that pass for programmers by banging together some JavaScript and PHP code snippets found by googling things like "JavaScript menus" to produce a website, or do you mean actual programmers? If the former, I agree, if the latter, well, no.

Reminds me...

[Anonymous Coward]

Reminds me of what Chuck Moore wrote once... that one needs to rewrite things from the start, to be near to the problem -- so near, in fact, that incredible savings in code -- and thinking -- can be accomplished, as well as new horizons discerned...

Next Next Finish Programming

[theodp]

THE DUMBING-DOWN OF PROGRAMMING (1998): "My programming tools were full of wizards. Little dialog boxes waiting for me to click "Next" and "Next" and "Finish."...Dumbing-down is trickling down. Not content with infantilizing the end user, the purveyors of point-and-click seem determined to infantilize the programmer as well."

Re:Next Next Finish Programming

[Tablizer]

It's not so much "dumbing down", but rather becoming a swamp navigator instead of an engineer. You can't just know principles, you have to also know the swamp.

More time is spent trying to figure out how to use and work around limitations of existing libraries and tools and less about designing such tools from scratch.

It can be roughly compared to what's going on in the automotive repair industry. You used to see all the parts involved and how they interact. Now a computer controls servos and if things don't work, you have to use Sherlock Holmes-like abilities to figure what's going on in the sealed dark-gray-box provided by Ford or Nissan that controls most of it. It's now about studying the relationship between the controller and the parts rather than "fixing the parts" directly.

It's a shift away from being The Wright Brothers toward being Sherlock Holmes: doing your best with limited clues by poking and prodding and digging instead of just making it "right". Instead of being a constructor, now we're deconstructors more or less.
   

On my first job, my boss said

[blai]

"Don't even try reinventing the wheel. This is not an assignment. Just use whatever code you can find."

Re:Idiot. Seriously.

[DigiShaman]

It would seem to me that the argument is based on whether or not the wheel should have to be re-invented for each programming project. If the code is good, why not reuse it as a module?

Car analogy!

[Anonymous Coward]

The article states that, no matter how important are things like unit tests, they are fundamentally in a supporting role to programming proper.

As someone who practices test-driven development and programming-by-contract, I fundamentally disagree. Tests, for me, is what defines the requirements and interfaces. The code itself is just the implementation. From the business logic perspective, HOW a program does something is secondary to WHAT it does.

Car analogy: imagine a programmer as a truck driver, and the project manager as the one who has his goods shipped. The programmer doesn't care much about what he ships (as long as it's not explosives or something like this) -- he cares about the route he's going to take to deliver those goods as fast and efficient as possible. That's all great. But the project manager doesn't care, nor should he. For him, the goods are the primary value, and the route the truck takes is the supporting value. As long as the goods arrive undamaged and on time, nobody other than the driver cares what route they went through.

We have a basic conflict of perspectives here. Programmers think it's all about how good their code is internally, and think that the coding is the most important part of the application, arguing that without that, the application obviously wouldn't work. But users and payers for that code do not care about those matters, they see a white-box perspective only. Just like the goods shipper, they care more about the goods than how they are delivered. And if the truck driver gets too bitchy about how and what goods he wants to deliver, it's usually easier to get a new truck driver than change your goods or shipping schedule.

Re:Car analogy!

[BadAnalogyGuy]

Car analogy:...

What you are attempting to do is very difficult. Please leave it to the professionals.

Re:Car analogy!

[phantomfive]

Unit tests are a tool, a good tool, but only one tool. They have a place where they are useful, and a place where they are worse than useless. People who think they are good for everything are usually the kind of people who only do specific types of code.

Unit tests are awesome in compilers. It's software that has the exact same output every time, doesn't have a changing spec, and doesn't change very much. They also tend to work nicely for business logic.

They are horrible for dealing with GUIs. This should be obvious. They are not as good at dealing with systems that have lots of complexity. The reason for this is because the number of tests required to make sure something works can increase exponentially, and of course so does the amount of code you have to write. I also haven't had much luck with them in embedded systems.

Re:Car analogy!

[DaveV1.0]

Speaking as an ex-over-the-road truck driver, it is a bad analogy because truckers do care about what they are carrying. They have to because they have to comply with different weight and bridge laws in each state. Truckers need to know if the load could shift, leak, etc.

And, no trucker wants a load that is not what the manifest says. Makes delivery difficult and if the load is inspected and the contents of the trailer does not match the contents of the bill of lading then the driver might have be in serious trouble.

Shippers may require the route not go over a certain altitude, through certain areas (New York City for one), or require a specific delivery time frame ("You have to be there on Wednesday between 6AM and 9AM").

Crappy frameworks, tools and web standards

[syousef]

I'm currently a J2EE (and C, but predominately Java J2EE) programmer, familiar with Hibernate, Spring, as well as the old school EJB 2 mess. I wasn't always a Java programmer. I've taught C and coded with it commercial. I also have commercially used a variety of other platforms from VB and Delphi, to Smalltalk, to C++.

Here's the core of the problem: The web is a horrible platform. I went from Rapid development drag and drop screen design in the late 90s to the abomination that is hand crafted JSP against shitty state based environments. Sure our applications are more scalable now, but I'm still hand crafting code to talk to a database object. There are tools out there that spit out mediocre code (hibernate tools come to mind). But nothing that I'm aware of spits out a good set of CRUD classes with corresponding unit tests. Why do we ever have to hand write this shit? (I haven't used Grails and Groovy extensively but I understand scaffolding has similar issues and not being as mature the people I've worked with have had to work around issues with transactionality)

Then you take a look at the GUI layer. Hand writing CSS and JSP? Really? In 2010? SHIT. Hand writing code for simple controllers. Never mind if you do actually end up doing anything non-standard in which case good luck getting into the guts of the documentation for Spring MVC or Struts or similar. And then you have to deal with having to redeploy your application to see simple changes OR using exploded views that don't update properly and leave you debugging a problem for 4 hours that should take 4 minutes.

It's a complete mess. It's WAY more complicated than it should be. I should be focused on the business problems - modelling the backend, getting the algorithms right for complex transactions etc. Instead there are people arguing that such simplicity leads to sloppy programming (usually mentioning VB as if the same programmers wouldn't have made a mess with something more complex). Well if you have nothing better to do than some stupid little dance just to get a web page up, that's your issue. For me that is a stupid statement. There's always a genuinely complex issue to solve without inventing one.

Re:Crappy frameworks, tools and web standards

[Tablizer]

Here's the core of the problem: The web is a horrible platform.

I agree and I've ranted about this several times on slashdot. Customers and bosses really want desktop-like apps, but existing browsers can only do this if you stretch them far beyond what they were originally made for: eBrochures. It takes 5 different programming and markup languages that break on each new browser version incriment.

It's time to build a dedicated open-source GUI/CRUD browser[1] that can handle desktop, MDI, data grids, tree controls, and CRUD-like applications with grace. No more bending and kicking the eBrochure paradigm to act like real desktops. JavaScript was not meant to be a systems language and DOM was not meant to be a desktop-like nor CRUD GUI.

Until people wake up to this harsh reality, web programming will continue to suck. It's like NASA trying to make everything with left-over shuttle parts, resulting in waste, bloat, and dead nauts. Blow up the fucking Shuttle and make a real system!

[1] Or a powerful plugin.

Re:Crappy frameworks, tools and web standards

[Tablizer]

but it's still a shuttle ;-) I meant more like the Aries platform(s) that was meant to use existing Shuttle parts and designs in order to quicken the pace to be ready by the Bush administration's deadlines. But it's not an ideal platform when judged by itself. It's a hack that traded time for elegance and economics.

Re:Crappy frameworks, tools and web standards

[gaspyy]

I know I'm about to get lynched by a mob of angrey slashdotters for saying this, but have you tried Flex? As in that Eclipse-based IDE & (open source) SDK? It's basically flash, but it works.

I'm not even going to suggest the other piece of technology from Microsoft, that includes the words "silver" and "light"...

Re:Crappy frameworks, tools and web standards

[Tablizer]

Regarding Flex, I was hoping for an open standard. Maybe it will help motivate an open standard(s) if and when it perfects the art of GUIs. It can show what's possible, and its weaknesses also suggest some improvements.

HTML browsers were popular largely because they were based on open-standards; namely HTTP, HTML, and to a lessor extent JavaScript and CSS. A GUI browser could be the same kind of animal, but instead influenced by desktop and CRUD idioms directly instead of as an after-thought.
     

Re:Crappy frameworks, tools and web standards

[tonywestonuk]

...its called Java. You may have heard of it! - A Java Webstart program can run on anywhere, with vastly less coding for platform differences than, say, coding a website to run perfectly between different browsers, and has everything you want, right now.

    However, the slashdot crowd (and others of similar ilk) have already condemned, and dismissed the Java GUI for not been quite as fast, or looking exactly like a native app....even though these differences nowadays are very slight. Java has been banished from the desktop.

Now Microsoft are coming along with Silverlight, which I guess will do a similar thing (though, will probably work like crap on non M$ platforms), and in 10 years, the world will rejoice how Silverlight has brought us out of the dark Web based internet dark ages, tying us all to windows platform for ever more...

Im getting too old for this, hence my cynicism.

Re:Crappy frameworks, tools and web standards

[phillipsjk256]

What annoys me is that we have had thin clients for decades: using remotely hosted software has been mature for as long as I can remember. VT100 emulation even works across a modem link. Want a GUI? the X Window system has been around for over a decade as well.

I like the Lynx browser: it uses external programs for also most everything. Even things like YouTube can work if you hand off the .flv to a video player. Browsers should not be acting as an OS replacements with their own schedulers. IMO, browsers should not be handling client-side scripting at all: hand that Java Applet off to an interpreter.

Don't get me started on the "pixel perfect" cult.

Re:Crappy frameworks, tools and web standards

[shutdown -p now]

No CSS, No HTML just "I put this component at X,Y and that is where it is at run time.

That is not how Qt works.

And even when you get that, as soon as your end user changes DPI setting in OS, or (on Unix platforms) font face & size, or, God forbid, you need to do localization, and suddenly discover that all strings are of different lengths - then what?

Desktop UI programming has got dynamic layouts for a reason. All modern UI toolkits have them. Don't try to pass the lack of them as some kind of advantage.

By the way, from the point of view of programmer, Access is not fundamentally different from Delphi. It also has a comparable widget library (complete with absolute positioning that you like), and the ability to write everything in code.

Re:Idiot. Seriously.

[dkleinsc]

"Knuth had his day."

Wow. Just wow.

First, I want you to write a work that tops TAOCP. Or at the very least show your check from Knuth for finding an error. Oh, wait, I highly doubt you've done either. It can be how you can express your imagination in ways that are beyond TAOCP if you like.

Next, write some software at least as useful as TeX.

Then, and only then, can you call Knuth an idiot.

Misleading summary.

[BitterOak]

Warning! Before you read the linked article or its followup too deeply, be aware they are not by Donald Knuth. Instead, the author has a brief quote from Donald Knuth in his first blog, and the other link is a followup story. So, "the author" referenced in the Slashdot summary is NOT Donald Knuth. I made the mistake of reading the followup article first, and then when I read the original, I found a brief quote from Donald Knuth which tipped me off to the fact that the author was not Donald Knuth, and as far as I can tell, Donald Knuth doesn't even know this author.

"Good programmers write good code...

[fatp]

excellent programmers steal excellent code."

I stole this, and I don't know where it is stolen from!

Re:"Good programmers write good code...

[binarylarry]

That would be Pablo Picasso.

Re:Idiot. Seriously.

[Sulphur]

One generation plants a tree...The next one gets the shade.

Then the squirrels show up and try to mine the bird feeders for freebies. Meanwhile the birds are ducking the guys who are learning to use blowguns.

Re:Idiot. Seriously.

[quadelirus]

I think the difference is like that between mathematics and engineering. Programming used to be more of a math, you were basically writing an executable form of a proof. Now programming is more about assembling all the previously developed tools to produce a useful result in the same way that engineers use a bunch of mathematical tools (that they may not necessarily know how to derive--and for that matter don't need to) to build a bridge. For a mathematical guy like Knuth, the engineering bit is a drag (for me as well) and the act of problem solving is the interesting part. I would even wager that to such a person the means (or methods of solving) are more important than the end result. The beauty is in the elegance of the solution, not in the fact that we now have a solution. Now programming is much more of an engineering task. The tools might as well be black boxes that we assemble in different ways to produce results. Another type of person likes this sort of thing (not me). These people are more interested in the ends, not the means. They are more driven to produce something cool rather than to produce something in a cool way. (Am I making any sense?)

Neither of these groups is better or worse than the other, just different. Both are needed for progress. There will always be mathematical problems to solve, and there will always be a need to apply the toolbox created by such mathematics to practical tasks with an emphasis on results rather than methods.

You can still program, if you're an engineer

[Sarusa]

I've dealt with Chinese and Indian outsourced code before - it's rather interesting. They take fragments of code they find via Google, paste them together, and do the bare minimum of editing to make it compile and say 'okay, we've fulfilled our contract, ship it.' This is what suffices for 'programming'.

On the other hand, I am still solving interesting problems with real programming at my current company, so I still think it's a lot of fun. The key point is that the programming is part of the /problem solving/. Code pigs have no concept of problem solving, just making the program work (by which they mean compile, or matching the sample screens). Engineers are solving problems, and the program is just a part of that. At my present job they really don't care what language I do things in as long as the job gets done, because solving the problem in the most practical manner is the most important thing. In practice this means I use C for things that actually do require high performance and minimal memory usage (this is still an issue in embedded programming), Python for everything else that I can, and domain specific languages for things like servo controllers or FGPAs.

The 'pasting not quite compatible libraries together' approach is a Java/COBOL thing of minimizing the damage incompetent consultants can do. I've seen it time and time again - once an Enterprisey Java programmer encounters sufficient complexity, a hormone kicks in and they create a framework to simplify this complexity. It does so, initially, but eventually ends up being 2-10x as complex as the original problem they were trying to simplify. But they see this as a net positive because they have a new acronym to put on their resume.

So basically, like every single damn post I've seen on here lamenting the state of programming, and repeating every damn comment I've made again and again, it boils down to 'solve problems as efficiently as you can'. Absolute rules, in programming or religion, are for people who are too simple to handle complexity. This is the difference between an engineer and a code pig.

Re:Idiot. Seriously.

[ooooli]

Not to mention that he can't grasp the awesome power of 300 APIs (sorry, "technologies") each with three letter abbreviation names starting with J that make up the resume of a typical Java programmer.

Agreed, but the problem is that most of those "technologies" are bloated, designed by committee, buzzword-loaded crap. The problem is *not* that we have found better ways to share code than we used to. I mean, I'm all for crafting beautiful, optimally efficient snippets of code that do one thing perfectly. But have you ever noticed that you can do things in a couple of hours now that 10 years ago would have taken weeks? Being able to cobble together a prototype fast is *hugely* useful and important. Now who was it again who said that premature optimization is the root of all evil? Hmmm...

Re:Idiot. Seriously.

[Opportunist]

I wish I could agree, but that's basically what is wanted today: Cheap people who can somehow slap together a program that kinda-sorta does what the boss wants.

At least in application programming you're seeing a trend that runs in this direction. You have a lot of RAD tools for instant webpages, instant databases, instant office applications. Of course there will always be room for "real" programmers in areas that either move too quickly to give RAD tools a chance to get a footing or where the problems cannot easily be split into neat little building blocks that can be slapped together with a construction kit.

But for most office applications, you don't even need a "real" programmer anymore today. Well, you'd need one to make it a sensible, fast and secure application, but let's face it, who needs that? Ok, they'd probably need that. But they don't want to pay the price.

The Issue

[Seraphim_72]

How many unique programming problems are there? The first guy that designs an efficient steam engine is a great engineer. What about the 100 guys after him that vary on his theme? What about the next 1000 or 10,000? Seems to me this is a complaint about no one inventing something as revolutionary as the wheel. Hey author - you can't, it has been done already! And as someone has already pointed out this is *not* from Knuth. This might as well get the 'Get off my lawn' argument then.

Re:Idiot. Seriously.

[dcollins]

"I think a better analogy would be to say that today's programmers are more like a Cargo Cult."

Responses to the recent MS-random-browser thread ("the faulty shuffle is close enough", "this guy's being pedantic", "knowing algorithms is a bad use of company time") are pretty good evidence of that.

http://developers.slashdot.org/article.pl?sid=10/02/28/1837223

Re:Magic incantations you say..

[Opportunist]

The difference is maybe that you actually have to know why and how those theorems work. Because else you could not use them. Not knowing why a certain mathematical rule is applicable means that you cannot apply it, not knowing whether its use would be "legal" from within the mathematical ruleset.

This is not the case with library functions. All you have to know is what you want to accomplish, you drop that info into the help file, it spits out a function (most of the time not really the best one, but one that will more or less do the trick) and it will also tell you what you have to drop into that function to make the magic happen.

Now, math has been a while ago for me, but I cannot remember it being THAT easy.

Increase in number of runs per second

[tepples]

Machines today are fast. Much, much faster than what we need for programs to run.

Until you get slashdotted. Having a sharp increase in number of runs per second can show just how fast your program isn't. And look at all the fail-whales soon after Twitter caught on.

Memory amounts today mean that it is pointless to ponder whether you really need double linked lists or whether you get by with single linked ones. Or that you use variables smaller than DWords to store integers.

Until you try to shave pennies from a mass-manufactured part.

Re:Increase in number of runs per second

[tfrayner]

And yet, Twitter is still around and still relevant. Which shows that one can get away with taking these short-cuts and still achieve the ultimate aim of your project. I see people getting bogged down in the details of which software architecture/model to use all the time (never mind sort algorithms!), so much so that they lose sight of their objectives. What often happens is that someone (usually me) then does a quick end-run around them in <insert scripting language here> and we eventually move on. People wonder about the prevalence of dodgy scripts in the world today; I say this habit of programmers taking their eye off the ball is one of the reasons. Never underestimate the advantage of being first to market.

Specialization is for Ants

[DeionXxX]

As a Presentation Layer guy I can tell you that I’m seeing a shift of the types of successful developers out there in the field. Those developers that can bounce around between different API’s and syntaxes are the ones that are in demand and those developers that know one technology or platform well aren’t.

I personally think it’s because of the fragmented nature of our target platforms. Programming for one platform is a luxury most programmers don’t have nowadays. This is why frameworks came to be and are used so heavily. Just abstracting the differences between platforms is enough for most developers to ditch “hand coding” and deal with the integration issues. Look at the popularity of Javascript frameworks like jQuery. Nobody coded in the way jQuery works before jQuery (the whole chaining thing, and anonymous functions), yet now more than 50% of websites (made up number) use jQuery.

To become a successful developer in the next decade, you must be a generalist. It’s a completely different way of thinking. You have to actively try NOT to learn too much of one platform for fear that it’ll bias you against all the other languages you’ll have to work in. For example, coming from more structured languages, seeing the jQuery chaining and use of anonymous functions would turn off most developers and they’d shy away from using it. However, it’s the best tool for the job currently, and not using it based on it’s weird syntax would be a mistake. Same thing applies to MXML, WPF, LINQ, C#’s var, etc and all sorts of new improvements to languages that people don’t use because they’re “different” and give you “less control”.

Docs

[afabbro]

From the article: "...it’s a tedious exercise in impedance-matching, requiring lots of time spent grubbing around in poorly-written manuals that tell you everything the code already told you (because it was generated with JavaDoc or Rdoc or whatever), and none of the high-level stuff that you actually need to be told."

Ah, so the real problem is poor documentation.

I work all day in a programming language written by one of the biggest software companies in the world. The documentation is complete, detailed, and accurate. For large things, there's an accompanying "concepts" doc. While I have (very rarely) run into something that needs clarification in some sort of corner case, I've never come across any part of their language, libraries, or objects that wasn't thoroughly documented, with examples.

On the other hand, I don't think I've ever come across an open source product that had barest minimum of documentation. What does exist is typically out of date (and observations of such are met with "read the changelog!" - lame). There's certainly nothing that explains the major concepts in the code - at best, there's some guide to functions or objects, and usually that only because it can be autogenerated. Sometimes there are examples - though more typically, a few mini examples are the only documentation.

Documentation writing sucks. Programmers don't enjoy it. It's highly amusing to me that the two areas that are the least fun for programmers - GUI design and documentation - are the two worst parts of open source projects.

BTW, in the 80s, programmers were excited about OOP because it promised rich object libraries. Someone would create objects to do X and we'd never have to code X again - no one, ever! And now everyone complains programming is just stringing together libraries.

I want to slap the author

[Sycraft-fu]

Whining about "infantilizing" the end user? WTF? I get really tired of the elitist attitude that some computer types have that computers should be hard. They seem to think it should be some sort of almost mystical priesthood that you have to work at for many years to be allowed in.

Bullshit.

Computers are tools, nothing more. they exist to allow humans to do tasks that we otherwise can't do, or at least can't do easily. As such they should be as easy and accessible for an average person to use. Ideally they would require no training and be usable by even extremely mentally challenged individuals. The more we can simplify them, the better. They should be adapted to work how we want, we should not have to adapt to them.

Well guess what? Programming is another part of that. Ideally, we'd have computers that could more or less program themselves. People would tell the computer what they wanted it to do in plain English (or other natural language) and it would figure out how to make that happen. Obviously we are a very long way away from this, but the easier we can make it, the better.

Even as it stands currently, where you do need training/practice to be a good programmer, there's a lot to be said for easy tools to make parts of development quicker and more robust. The user interface would be a good example. If all UI elements have to be coded in C++ and then compiled to see how it works, it is going to take a long time to develop and change. Goes double if others (like artists usability experts) are working on it as well. You write it, compile it, send it to them, they test it, write up problems, send it back, etc.

Much better to have a simple GUI interface for laying out the GUI. You can make changes much quicker and easier, and see what you are doing to confirm it is what you want. Also, should the design change, a redesign is much faster and easier.

I really get tired of this idea that computers and programming should be hard, that we don't want it accessible. Bullshit. You should want that in general, because it makes it available to more people, and even for you, because the ease of use can save you time. Yes, it allows for people to write programs that don't understand it. Deal with it. The microwave allows geeks everywhere to easily prepare food without understanding how to do it. Doesn't mean we should demand everyone become a master chef and cook all their food from only elementary ingredients. That will give you tastier food, but there's something to be said for having a meal ready in 5 minutes with 0 effort.

Re:I want to slap the author

[apoc.famine]

Part of the issue is that "programming" is no longer what it used to be, yet everyone still uses the term.

It's the difference between BBS and "Web 2.0". It used to be that geeks only could get a modem and some BBS software running which would allow them to connect to the entire world. Now my grandmother can tweet about the birds at her feeder, and someone in Tajikistan can read about them.

There is a fundamental split now between "designing and writing code" and "programming applications". You want to "program applications". The author and a number of people posting here want to "design and write code". These are two very different things.

I previously worked in a job "programming applications" for customer service reps. I had a stupid-easy gui toolbox, and pre-written database calls. All I did was link the two together, and provide some feedback for the operator. Currently, I'm in scientific computing, writing some bare-bones code to parse an obtuse, undocumented data structure into a usable format. I've got none of the nice easy stuff I had before. It's raw file reads and writes, slowly stepping through lines of output, trying to figure out wtf is going on. No gui, no buttons, nothing but some console output.

Based on the article and comments here, it seems that we almost need to split "programming" up into some clearer terms. There's building a car, and there's driving one. There's writing raw code, and there's using pre-made tools to do a job quickly and efficiently. If I wanted one of those things done well, I wouldn't hire someone who was an expert at the other. Right tool for the job and all....

Not even fucking close

[Fujisawa Sensei]

Programming is becoming nothing more than cutting and pasting, especially with languages like java, that provide libraries that do "the hard stuff" and let programmers concentrate on "programming".

I really need to worry about opening and closing JDBC connections, parsing SOAP calls by hand or writing socket listeners. Sure its interesting, the first 4 or 5 times you do it. But I have better things to do with my time that rewriting the wheel for every fucking application. That shit is already there; learn to fucking us it.

And sure this crap boils down to pushing tokens between multiple apps, and CRUD database apps. The banging out of code is rarely the tough part.

The tough part squeezing the requirements out some dumb-ass business analyst, who can barely speak the language, much less actually put something in writing and doesn't even know or care about the fucking applications they're writing requirements against.

Or perhaps you don't care about getting your airline reservations, airfare and seat assignments correct when you book them.

Well what's wrong with that?

[Weaselmancer]

It seems everyone wants to be a "software engineer", but nobody wants to focus on the "hard stuff", and instead chant "let java/X do it for you".

I don't see the problem there.

Not every programmer you're going to run into is going to be a brilliant assembly level kernel hacker. Some of them (these days anyway) are going to be mediocre. Using libraries that a lot of people have looked at, found the bugs for, and documented so that the "hard stuff" works reliably gives these people a chance at success. Not everyone coding these days is some uberhacker. Code that works is really the bottom line here.

Reason being - programming has moved from a small niche position to an industry. And the demand for programming is large. And the number of people who can perform difficult tasks like coding in assembly is small. Wizards are rare and demand is larger than that. So how do you bridge that gap? Easy languages and tools and lots of libraries to increase the number of available programmers that can meet the demand. Let the gurus stick to the heavy stuff and let the mediocre programmers spend their time solving tasks in their ability range.

It's simply market pressure.

Re:Well what's wrong with that?

[CptPicard]

Not every programmer you're going to run into is going to be a brilliant assembly level kernel hacker. Some of them (these days anyway) are going to be mediocre.

I would have to disagree with the notion that a programmer is either brilliant by being an "assembly-level kernel hacker" or then he is mediocre and "just uses library calls". This is the kind of weird dichotomy I tend to see from the most arrogant-ignorant low-level guys who probably don't have much of a theoretical CS background, or something. Software does not work on a continuum from hardware level to stupid cut and paste code monkeys.

The most brilliant programmers I know are the ones who have a loads of insight into the working and structure of software in general, regardless of language and/or proximity to hardware. It is all about identifying the problem solution and then making use of some formalism to describe that solution in computable terms. IMO good Lispers are hard to beat in this regard...

programming is better off...

[chentiangemalc]

for some people it may seem less fun, if so nobody is stopping you for writing libraries yourself (except for maybe employers who are concerned about something called 'return on investment') however another take is that programmer's don't get stuck with writing mundane functions that have already been written 1,000s of times. the use of libraries can deliver more reliable applications in less time. library developers can specialize in a particular function and good libraries do functions much better than 'write it yourself' a classic example is encryption libraries...although easy to write your own encryption library, there are so many ways security can be weakened that you may not realize unless you are specializing in this field. in the end programmers are developing better applications, and delivering them more quickly use of libraries live on...

Re:I couldn't agree more

[benjamindees]

But, you realize, that's entirely true. Here's a vaulted car analogy:

American cars were historically bolted together, or welded together from standard parts supplied by thousands of different suppliers. If you wanted to, you can take an old American truck, completely disassemble it, replace almost any piece and re-build it from the ground up. That business model worked when the design costs of a car were vastly greater than the manufacturing costs. By using standard parts, those costs were spread out over many years and many models. Each part was not optimized to each car, but it was cheaper to manufacture and maintain regardless. American car manufacturers stuck with this, due to several factors, even in the face of superior competitors with vastly different processes. We all know how that turned out.

Today, almost every piece of a car is custom-designed, not shared with other models. Robots weld auto bodies into a single piece. People spend more time working in the design phase, not as much in the manufacturing. Trimming excess materials from the design is nearly a science. The cost of repairing or rebuilding a car is prohibitive compared to the cost of simply buying a new one. American car companies that failed to adapt, along with their parts suppliers, are going bankrupt.

Now, is one model superior to the other? No. They each have strengths and weaknesses. Asian workers were not necessarily better-off than American workers, despite their technological advantages. Asian automotive companies evolved in an environment rich in talented labor and poor in natural resources. They used design and lots of mental "work" to conserve natural resources. American automotive companies evolved in the opposite environment, poor in skilled labor and rich in unskilled labor and natural resources. They used natural resources and unskilled labor to make up for lack of skilled design work.

Ideally we would all be best off if we lived in an environment rich in natural resources and talented labor, while still conserving both. Technology, correctly applied, can help us achieve this. But only if the advances of technology are not negated by the proliferation of unskilled labor or wasteful resource consumption.

As a physicist,

[Kim0]

I can tell that the problem is a lack of Ockhams Razor:

The probability that a theory predicts correctly, gets higher when the theory gets simpler.
The probability that a program is useful in new situations, gets higher when the program gets smaller.

This has been proven mathematically with algorithmic information theory.

However, Keeping It Simple, Stupid, is very hard and costly, and most people have an instinct for hoarding that gets in the way.

Kim0

Re:As a physicist,

[physburn]

I'm a physicists too, but Ockham's Razor hasn't been proved, from Wikipedia:

---

In science, Occam’s razor is used as a heuristic (rule of thumb) to guide scientists in the development of theoretical models rather than as an arbiter between published models.[4][5] In the scientific method, Occam's razor is not considered an irrefutable principle of logic, and certainly not a scientific result.[6][7][8][9]

---

I've actually had a good look and Ockham's Razor from the point of view of information theory. See, my blog. The trouble stopping the Razor been robust, is finding a fair language to express the scientific theory in a minimally small way.

Re:As a writer of crappy code..

[TheLink]

As another writer of crappy code:

The advantage of using libraries is it means you write less code.

The less code you write, the fewer bugs you create, and less code you are directly responsible for fixing and documenting.

Yes the libraries won't be perfect, but in general they should be less crap than your code (especially if used and fixed by many others).

People who like "writing everything" themselves should use stuff like Lisp- programming languages that are powerful because they allow a programmer to personally write all sorts of stuff.

The rest of us should use languages that are powerful because they allow the programmer to NOT have to personally write all sorts of stuff :).

The "real programmers" can sneer at us, but we'll have completed the project way before they have finished writing the BIOS, bootloader, operating system, libraries and editor so that they can actually start writing the "real program"...

Re:As a writer of crappy code..

[Dhalka226]

They're probably right; it probably would be better if they re-wrote it.

It's not because of what badasses they are or what terrible programmers their predecessors were, contrary to what most people believe in their heads. It's because it's easy to see what a program is supposed to do once it's done.

The reality is hardly any software is finished as the exact same project it started as. Requirements get changed at the worst possible times, the scope redefined, the timelines shortened. And yeah, at that point getting a working product out is the most important thing. Rewriting it probably WOULD result in better code, which may or may not be justification enough for doing it.

And hey, there's also a good chance those same things happen to them on their rewrite. Oops.

Re:Idiot. Seriously.

[BlackHawk-666]

I think the guy's point was that Knuth wrote that in the 70s, and it's now the 10s - a gap of forty years in which he has capitalised off his earlier work but not really brought anything that revolutionary to the table since. His original work stands as a classic, bring together a vast amount of highly relevant information and algorithms for the programmers of the 70s/80s. It has a lot less relevance in this age because most of his work is now part of some standard library or framework.

I've written plenty of things as useful as TeX but that doesn't mean I'd call Knuth an idiot.

Re:As a writer of crappy code..

[paeanblack]

My main point here is that I have seen WAAAAAAAAAYYYYY too many arrogant programmers talking from their bum about how much better THEIR code would be if only THEY had a chance to rewrite it.

The same is true for everyone from novelists to plumbers to aircraft designers. The second time through generally yields a better result; it's just frequently not an option. This doesn't make anyone arrogant, it's just life.

Re:As a writer of crappy code..

[TangoMargarine]

Crappy code is code that people other than the original developer(s) can't maintain. Some degree of elegance is implied therein.

Re:As a writer of crappy code..

[neumayr]

The arrogance stems from the emphasize on THEIR code, which THEY are rewriting.
Yes, people learn from other people's experiences. But some seem to think it's only them that do..

Re:Magic incantations you say..

[drewhk]

"Now, math has been a while ago for me, but I cannot remember it being THAT easy."

The whole problem of modern mathematics is exactly this. It is not organized in an efficient manner. Programmers are not algorithm writers. Programmers are organizers -- and this is very important to understand. If one of my programmers would produce code that is that badly documented, that badly organized as mathematicians -- I would fire him.

And this is the main misunderstanding that TFA has. Writing algorithms is just a minor part of our job.

Re:As a writer of crappy code..

[ThePhilips]

The "real programmers" can sneer at us, [...]

That's not about it.

As long as you understand what you write, it's fine.

The problem is with the newer generation of Java/C# who: can't write their own algorithms thus inevitably depend on libraries, manage to have problems integrating the libraries together and (worst) do not understand how/why the stuff works.

the BIOS, bootloader, operating system, libraries and editor

That's a misconception about the "real programmers".

The difference between the "new programmers" and the "real programmers" is that later were still taught math and computer architecture - former were taught only syntax of a sandboxed programming language. Later know why/how software/hardware works at least in general, former have to rely on book which tell them that it would works.

Those who are actually try to reinvent "the BIOS, bootloader, operating system, libraries and editor" are not "real programmers": those are last remaining artifacts of the DOS times, the times when it all fit 64K.

Re:As a writer of crappy code..

[fuliginous]

The code base I work on would be improved by a rewrite. But in doing so it would actually be a matter of putting more effort into using the libraries (they do too much manual string manipulation for example that could be done using existing library calls; it's Qt based stuff).

At the same time it would cut lines of application code and make seeing the algorithm easier. I've just swapped 2500 lines for 850 lines whilst increasing functionality.

Cost benefit wise it's impossible to say in advance was it worth it.

Re:As a writer of crappy code..

[fuliginous]

I agree from a different view that goes like this. Good programmers/software engineers are expensive so companies like to pay cheaper people. To enable use of cheaper people tools and processes are introduced.

One such tool is languages that have buckets of libraries or core tools that the new people merely have to extend or tweak.

Knuth is lucky that most things he needed didn't exist then so using libraries wasn't an option. If everything he needed already existed he'd have picked a different area to work in.

Re:As a writer of crappy code..

[fuliginous]

You presume that a month or twenty down the line the original author can still maintain it. Most crappy code that doesn't holds as true.

Re:As a writer of crappy code..

[Anonymous Coward]

The thing is, most people want to rewrite the code because it is too hard to understand. In which case they probably don't understand it when they do the rewrite and end up making at least as bad mistakes as the original authors.
_If_ they fully understood it, in most cases it wouldn't be so hard to just attack the most problematic parts and improve them - for example in quickly written code there is often a lot of cruft where only a few lines can be changed to make the code simple, smaller and overall better while being almost certain that it still does _exactly_ the same thing (if necessary under a few assumptions documented with asserts).
Admittedly this might end up with everything being rewritten, but with an understanding of the old code and the new code, with change control, and a way to do regression testing where you can say: the bug is in these at most 100 lines of code, which reduces greatly the debugging costs of the rewrite.

Re:Magic incantations you say..

[bertok]

The difference is maybe that you actually have to know why and how those theorems work. Because else you could not use them. Not knowing why a certain mathematical rule is applicable means that you cannot apply it, not knowing whether its use would be "legal" from within the mathematical ruleset.

This is not the case with library functions. All you have to know is what you want to accomplish, you drop that info into the help file, it spits out a function (most of the time not really the best one, but one that will more or less do the trick) and it will also tell you what you have to drop into that function to make the magic happen.

Now, math has been a while ago for me, but I cannot remember it being THAT easy.

Except that there's a little issue with that nice theoretical model: leaky abstractions.

If you blindly use functions (actually methods) without an understanding of what they do internally, you will get burned.

This is why crap code deadlocks. This is why crap code leaks memory. This is why crap code can't run on anything except a specific version of Windows with a specific version of IE.

Re:As a writer of crappy code..

[PhrstBrn]

I'd mod you up if I had points.

Most of the code I call "crappy code" is stuff I'm asked to look at because somebody found a reproducible defect, I look at the code, blink twice, and wonder how we haven't had a "oops, all of our data is gone" scenario yet. Fortunately I keep daily backups around...

And, of course, when I ask the original developer to "fix it", they can't seem to figure it out, even when giving step-by-step instructions how to reproduce the defect, over, and over, and over, and over.

I've looked at some of these CGI apps "web developers" put out, and I wonder if they have any brain cells between their two ears. Just using some sort of MVC architecture would be a good start to fixing 99% of the problems I see with shitty web code, and at least keep things somewhat more organized (if only just slightly)

Glad I'm writing embedded stuff

[slashbart]

Hello World.

I've spent most of my career on embedded projects, and I'm still doing real programming, from bit banging an I2C or Dallas onewire bus, writing a custom assembly routine to provide a uC-OS-II task switch on an ethernet chip interrupt, or interfacing with some higher level Tcl stuff. To get the whole thing working mix in some shell, awk, python xslt, stir well, and get space qualified software. Oh and when all that starts to get boring, throw in some FPGA programming for a completely new way of doing things. I love my jobs!
Really, I think embedded software is often more interesting than most web-, gui- or server apps. The disadvantage is that you pretty much need an electronics degree (which I do), to be able to do it effectively.
Last but not least, it often pays pretty good, and the quality requirements are high, which means that there is time allocated to make something good. Google for 'Declic' on linuxjournal.com if you want to see what I'm talking about.

Re:As a writer of crappy code..

[vadim_t]

In programming the best version is generally the third.

The first is the "I don't know what I'm doing" version, which gets written by trying without much thought, ugly hacks, and without a decent design. Sometimes it does work quite well however, as despite not being very pretty it does what it's supposed to.

The second is "V1 is crap, but now that I have figured it all out I can do better!". Often a horrible mess, due to things like wanting to make everything modular, adding every feature possible, and using the latest cool tech and design patterns where they don't belong. Turns out to be slow, huge, buggy and overly complicated to use. There's even a name for this: "second system effect".

Based on the lessons learned from the lack of planning in the first and the excesses of the second, the third version has a good chance of being actually decent.

Re:Car analogy

[CDPS]

Few programmers start to write a program by designing a new OS, etc., so your analogy is simply a strawman. How about this car analogy: when designing a new car you are allowed to use only already existing auto parts; you are not allowed to custom design hardly any part on the "new" automobile. This is the real analogy with patching together existing library routines to build a new program: connecting together a set of already existing auto parts to make a "new" car. Does this better analogy still sound just fine? Obviously depends on what one is reusing and how complicated that was to engineer.

You know Programming is in trouble

[Prototerm]

You know Programming is in trouble when being "the goto guy" has become a compliment, rather than an insult.

Try Embedded Programming

[DCheesi]

In embedded programming there's still plenty of opportunity for ground-up design. Eg. writing a new driver for custom or unsupported hardware, creating custom applications to do whatever unique thing your widget does, etc.

Yes, you tend to get into framework-hell on the GUI side, and occasionally in other areas as well. But even then I get a sense of pride knowing that I made these things work on a platform they were never designed for.

Re:Idiot. Seriously.

[ScrewMaster]

Do you mean the cretans that pass for programmers ...

What do you have against people from Crete?

Okay, okay ... I'll leave peacefully.