Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Whatever Happened To Programming?

kdawson posted more than 4 years ago | from the you-had-zeros? dept.

Programming 623

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.

cancel ×

623 comments

Sorry! There are no comments related to the filter you selected.

Programming == Cut & Paste (4, Insightful)

Anonymous Coward | more than 4 years ago | (#31386474)

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 (5, Insightful)

binarylarry (1338699) | more than 4 years ago | (#31386568)

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"

Half a Century of Crappy Computing (0, Troll)

rebelscience (1717928) | more than 4 years ago | (#31386874)

Half a Century of Crappy Computing [blogspot.com] . It's much worse than people think. Crappy code is all around. Computing started out on the wrong foot. The mathematicians and the Turing Machine worshipers are to blame.

Re:Programming == Cut & Paste (4, Insightful)

EastCoastSurfer (310758) | more than 4 years ago | (#31386686)

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 (3, Informative)

crazycheetah (1416001) | more than 4 years ago | (#31386726)

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.

Implement some things yourself (2, Insightful)

thenextstevejobs (1586847) | more than 4 years ago | (#31386478)

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

Re:Implement some things yourself (3, Funny)

Yokaze (70883) | more than 4 years ago | (#31386654)

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 (5, Funny)

kyrio (1091003) | more than 4 years ago | (#31386692)

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

Re:Implement some things yourself (4, Funny)

Nerdfest (867930) | more than 4 years ago | (#31386810)

Try reading it as William Shatner would.

Re:Implement some things yourself (-1, Troll)

Anonymous Coward | more than 4 years ago | (#31386764)

Your comment is "gay"er than an picnic basket...

Re:Implement some things yourself (1)

shutdown -p now (807394) | more than 4 years ago | (#31386898)

Some things are over-engineered.

And yet, it's often more efficient to take an over-engineered thing that is already there and working (and though it has quirks, those are already well-known), rather than writing your own perfect one.

Re:Implement some things yourself (1)

benjamindees (441808) | more than 4 years ago | (#31387000)

But it's important not to confuse "an over-engineered thing that is already there and working" with whatever under-engineered thing just happens to be laying around.

Frameworks (2, Informative)

Nerdfest (867930) | more than 4 years ago | (#31386480)

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 (0)

Anonymous Coward | more than 4 years ago | (#31386492)

for alot of tasks i can write a better solution from first principles faster than you can use your 20 gallon bucket of glue

Re:Frameworks (4, Insightful)

Nerdfest (867930) | more than 4 years ago | (#31386504)

... 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 (-1, Troll)

Ethanol-fueled (1125189) | more than 4 years ago | (#31386662)

Knuth:

When I was fourteen, I wrote space-invader games in BASIC on a VIC-20. If you were interested in computers back in 1982, I bet you did the same...It's not what we dreamed of as fourteen-year-olds and trained for as eighteen-year-olds.

Yeah, because all of us totally had PCs as kids. Except that stepping out into the daylight and becoming interested in sex was much more awesome.

When I was 18, I wrote multi-user dungeons in C on serial terminals attached to a Sun 3...

In C but not in assembly? What a pussy.

we're looking up the EnterpriseFactoryBeanMaker class in the 3,456-page Bumper Tome Of Horrible Stupid Classes (Special Grimoire Edition), because we can't remember which of the arguments to the createEnterpriseBeanBuilderFactory() method tells it to make the public static pure virtual destructor be a volatile final abstract interface factory decorator.

Nice jab against Java, but if you can't code multi-user dungeons in assembler then there's a reason why your bosses stuck you with Java, dumbass.

Are you gonna argue with Knuth? Huh? Are you? Didn't think so.

Oh yeah, you're so bad, I bet you're man enough to hit your dick with a hammer. That from a man who spent his entire life masturbating to his own source code while the rest of us were riding bikes and getting pussy.

I want to make things, not just glue things together...Tuna nigiri. For me, there is a sort of metallic flavour to most raw tuna; but belly tuna, the fatty cut known as toro, is just sensational...

Wow, you even fement your own sushi-vinegar and then hand-assemble every bit of rice grain-by grain until you're left with a perfect oblong shape? Do you grate and color your own wasabi? Do you catch the fish and cut that piece yourself? No, you don't, so shut the fuck up sissyboy.

I understand, I think, how we landed up here. I wish I know how we can get out.

You'll get out soon enough when your job goes to India, asshole!

Re:Frameworks (0)

Anonymous Coward | more than 4 years ago | (#31386816)

Nice jab against Java, but if you can't code multi-user dungeons in assembler then there's a reason why your bosses stuck you with Java, dumbass.

A "factory" is a functor over a type. The pattern gets in the way of its conceptual clarity. It is clearer in assembler. Or Haskell or C or anything that isn't object oriented in a painfully baroque way.

Re:Frameworks (2, Insightful)

Ethanol-fueled (1125189) | more than 4 years ago | (#31386878)

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

Re:Frameworks (0)

Anonymous Coward | more than 4 years ago | (#31386836)

Parent wrote:

we're looking up the EnterpriseFactoryBeanMaker class in the 3,456-page Bumper Tome Of Horrible Stupid Classes (Special Grimoire Edition), because we can't remember which of the arguments to the createEnterpriseBeanBuilderFactory() method tells it to make the public static pure virtual destructor be a volatile final abstract interface factory decorator.

Nice jab against Java, but if you can't code multi-user dungeons in assembler then there's a reason why your bosses stuck you with Java, dumbass.

You fucking idiot, there are no destructors in Java. And I prefer men, not women.

-- dKnuth@gayMenMeet.com

Re:Frameworks (1)

tsalmark (1265778) | more than 4 years ago | (#31387024)

Your not a programmer are you? Knuth was not writing space invaders as a kid, he wrote the bible instead. Knuth is one of the wizards of academic programming. The article is by some guy who quotes Knuth a little to try and justify his rant.

Re:Frameworks (5, Insightful)

Opportunist (166417) | more than 4 years ago | (#31386740)

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 (5, Insightful)

Todd Knarr (15451) | more than 4 years ago | (#31386902)

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 (1)

Opportunist (166417) | more than 4 years ago | (#31386940)

I agree. But try to sell that to your boss who just sees a framework, drums on it with his index finger and insists you use it because "it can do everything". You start coding, you make record progress for about 80% of the project because the framework lets you start at about 60% and then you hit a wall.

Want to swap shirts? I have a drawer of these.

Re:Frameworks (1)

Pence128 (1389345) | more than 4 years ago | (#31386904)

I think there are still areas where 1) is the way to go, for example in very small systems where it could mean the difference between a $1 chip and a $2 chip in a $10 product, the choice is obvious. Sure, it's not exactly glamours, but if saving a couple of bytes and shaving microseconds off loops are what you like to do, give it a thought.

Re:Frameworks (1)

Opportunist (166417) | more than 4 years ago | (#31386970)

Certainly. I am actually in one of the few places where 1) is still the right choice. When you're dealing with an industry that reinvents itself every other month, waiting for a RAD tool to surface is a surefire way to get out of business fast.

I'm just saying that in most application programming environments, it is not. Provided a company actually pays programmers to develop something "own" instead of just buying whatever toolbox already exists, you are usually facing a problem that stock code can handle. And unless you are dealing with literally tens of thousands of concurrent users, it is almost certainly cheaper to simply get a bigger machine with more ram and CPU horsepower than letting programmers optimize the code.

Re:Frameworks (1)

tepples (727027) | more than 4 years ago | (#31386990)

And unless you are dealing with literally tens of thousands of concurrent users, it is almost certainly cheaper to simply get a bigger machine with more ram and CPU horsepower than letting programmers optimize the code.

Unless I can extract a 10-fold speedup by using explicit temporary tables to work around MySQL 5's query optimizer's inefficiencies in evaluating equi-joins to a GROUP BY subquery, so that it doesn't have to do so many unnecessary table scans.

Increase in number of runs per second (4, Insightful)

tepples (727027) | more than 4 years ago | (#31386930)

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:Frameworks (1)

shutdown -p now (807394) | more than 4 years ago | (#31386996)

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.

Depending on the scope of the framework in question, and the size of the development team, option 1 can take indefinite time (on the "we're going to release it next month" schedule).

Case in point. In one of the companies I've worked in the past, the architect was one of those "eccentric genius" type of guys - at least as far as management was concerned. If he thinks he's got the right idea, that's what the rest of the team will do...

Now, most of the code in the company is written in C++, but then it came to writing a distributed "enterprisey" application where a lot of code was obviously high-level. It was correctly observed that C++, and the typical frameworks that you get for that, is not the perfect tool for the job. The "genius", however, decided that none of the existing language/framework combos - Java, .NET etc - are to his liking, because (I quote) "they are designed by idiots for idiots".

And so the company, under the guise of working on a major product, instead started to develop an ultimate framework for high-level app development - this covered the whole spectrum: a tracing garbage collector, type reflection, object remoting, serialization, XML parsing, database access (direct SQL execution as well as ORM). One of the biggest chunks was a new, in-house UI framework complete with XML layouts, data bindings, and its own scripting language with a bytecode interpreter, and, eventually, a rudimentary JIT. Gladly, we didn't go for a language of our own for other code - it was still C++, though heavily augmented by various proprietary metadata files, and code generation.

Now, don't get me wrong. It was actually pretty fun to work on this, for the most part - I did the database & ORM stuff, and I really did learn a lot about how ORMs work, and, more importantly, why they work that way, and have the limits they do. But...

All things on the list were there... in theory. In practice, because of the pace at which it was all written, bugs were spawning faster than they could be squashed. And, because of certain very dubious architectural decisions, the performance was dismal for most layers. It was really ridiculous to see C++ reduced to performance levels several times, and occasionally two orders of magnitude, below Java and .NET. Again, this was also a good educational experience, in a sense that I've suddenly found out why some things in Java and .NET are that way (and also, apparently, why they are the same - when there really is only one good way to do something).

End result: one project built on that framework canned mere months after "imminent release" was announced (management was still oblivious to the whole thing back then), another one dragged for two years, "we're going to release this in two months" all the way, and finally aborted when the sheer magnitude of perf and stability problems was exposed. The "genius" was let go shortly afterwards.

Last I heard about the place, they've switched back to C++ all the way, and Qt for the framework (apparently, management tried to penny-pinch, but then realized that it's better to spend money now rather than have the repeat of the past fiasco). They seem to be doing a lot better - at least the second failed project was restarted from scratch on a new foundation, and ultimately released without slipping the schedule too much.

Re:Frameworks (4, Insightful)

complete loony (663508) | more than 4 years ago | (#31387016)

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 (1)

bryanduxbury (1235994) | more than 4 years ago | (#31387020)

There are still plenty of places where it's important to get that extra 10% runtime. It's just that writing your average web app or silly desktop application simply aren't those places anymore.

Personally, I like this development - you don't have to bother so much with stuff you need to "just work" so that you can spend time optimizing and improving where it counts. My admin UI is "slow", but the libraries and business logic I'm using in my Hadoop applications are hella optimized.

If you are more interested in working on the latter kind of problem, maybe it's time you try to find a different job. (Incidentally, Rapleaf is hiring engineers.)

Re:Frameworks (4, Informative)

tomhudson (43916) | more than 4 years ago | (#31386658)

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 (1)

Opportunist (166417) | more than 4 years ago | (#31386876)

Quite true. But try to explain that to your boss. And in the odd chance that you actually managed to convince him to throw his quarter report in favor of a long term investment, because instead of 2 months he's now facing a year of dev time, try to dodge your coworkers who now really have to learn programming instead of simply slapping together a few pieces of ready-made cut/paste snippets.

Been there, done that, actually even got a t-shirt...

Re:Frameworks (0)

Kohath (38547) | more than 4 years ago | (#31386948)

You know what else doesn't scale and is hard to debug and maintain? Almost everything.

There's no magic answer. "Increase the budget by 4X to implement an elegant, scalable solution" isn't a magic answer either.

Re:Frameworks (3, Insightful)

jomama717 (779243) | more than 4 years ago | (#31386820)

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 (1)

Opportunist (166417) | more than 4 years ago | (#31386860)

Whenever you hear a coworker say something like "$framework will handle that for you", duck and cover. It will end up in a horrible mess.

Use frameworks. But do not rely on them. Know what they are doing. And most of all, know their limitations. Not knowing them will come back and bite you in those parts that make sitting uncomfortable for weeks.

Re:Frameworks (5, Insightful)

Hurricane78 (562437) | more than 4 years ago | (#31386982)

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.

Idiot. Seriously. (-1, Flamebait)

BadAnalogyGuy (945258) | more than 4 years ago | (#31386484)

Knuth had his day. That day is the equivalent of building stone tools and hunting with rocks and sticks.

Today we are using bows and arrows. We have left the stone tools behind and can now express our imagination in ways that are simply beyond the scope of TAOCP.

But remember, we are still only using bows and arrows. The next big thing will be gunpowder.

Re:Idiot. Seriously. (5, Insightful)

Saint Stephen (19450) | more than 4 years ago | (#31386496)

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 [wikipedia.org] .

Re:Idiot. Seriously. (2, Insightful)

morgan_greywolf (835522) | more than 4 years ago | (#31386548)

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.

Re:Idiot. Seriously. (0)

Anonymous Coward | more than 4 years ago | (#31386616)

Yeah, I was going to say, as a trained programmer, although I use the libraries others have made, I'm not some ignorant savage.
I didn't do stellar in my algorithms class at University, getting only a B-, but I learned enough to realize THIS IS SERIOUS BUSINESS. Fortunately, there were plenty of kids who "got" the advanced challenges of algorithms, so the new generations aren't all slack-jawed, either, maybe just me.

I just tend to do a better job when someone has executed those algorithms for me correctly, and I can get onto building a system for my client. I don't want them to pay because I
couldn't implement the best algorithms for each data structure I use.

Re:Idiot. Seriously. (1)

EastCoastSurfer (310758) | more than 4 years ago | (#31386732)

Even within the group of actual programmers you need different skill sets for different problems. Think of a general contractor and the plumber working for him. The GC knows enough about plumbing (algos) so he knows what he needs and doesn't get screwed, but he isn't the one who builds out all of the plumbing. His skill is getting together all the other parts required to build the house (complete piece of software that solves a customers problem) rather than knowing every intimate detail of how each individual job is done. Think generalist versus specialist.

Re:Idiot. Seriously. (2, Insightful)

Opportunist (166417) | more than 4 years ago | (#31386778)

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.

Re:Idiot. Seriously. (2, Insightful)

DigiShaman (671371) | more than 4 years ago | (#31386588)

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?

Re:Idiot. Seriously. (1)

sorak (246725) | more than 4 years ago | (#31386638)

And every profession can say the same about how much smarter people were before they had calculators/internet research tools/software, when they had to use slide rules and learn mental shortcuts, because they didn't have the tools we have today. That's life; One generation plants a tree...The next one gets the shade.

Re:Idiot. Seriously. (2, Funny)

Sulphur (1548251) | more than 4 years ago | (#31386728)

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. (4, Insightful)

quadelirus (694946) | more than 4 years ago | (#31386770)

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.

Re:Idiot. Seriously. (0)

Anonymous Coward | more than 4 years ago | (#31386858)

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.

Yes, and no. Your sense of history is warped. Academics have always known that programming is a form of constructive proof, and all that it entails. But the engineers ran with C's execution model in the 1970s. It has been a long struggle to get "high level" features in procedural languages, mostly because of the work of a few academics working on functional and OO languages. Later, Sun decided to do Java.

If "early" programming is like writing proofs, "modern" programming ought to be like combining proofs. And it is, in principle. That's all well and good. This is especially easy if you have a language which allows easy combinations of proofs. OO can be the wrong model for combining your proofs. (Especially if you're not quantifying over object-like things...)

Re:Idiot. Seriously. (4, Interesting)

dcollins (135727) | more than 4 years ago | (#31386894)

"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 [slashdot.org]

Re:Idiot. Seriously. (5, Funny)

Nerdfest (867930) | more than 4 years ago | (#31386514)

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

Re:Idiot. Seriously. (5, Funny)

convolvatron (176505) | more than 4 years ago | (#31386518)

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

Re:Idiot. Seriously. (1)

morgan_greywolf (835522) | more than 4 years ago | (#31386570)

Yeah. I'm definitely getting off of Knuth's lawn.

Re:Idiot. Seriously. (0, Redundant)

clarkkent09 (1104833) | more than 4 years ago | (#31386656)

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.

Re:Idiot. Seriously. (0)

Anonymous Coward | more than 4 years ago | (#31386670)

No joke.

It's much easier to grasp the awesome list of 300 fast food and department store job history bullets that other programmers have on their resumes.

Re:Idiot. Seriously. (2, Interesting)

ooooli (1496283) | more than 4 years ago | (#31386776)

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. (1)

dbIII (701233) | more than 4 years ago | (#31386528)

The problem here is trying to use those bows and arrows for deep sea fishing :)

Re:Idiot. Seriously. (3, Insightful)

dkleinsc (563838) | more than 4 years ago | (#31386640)

"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.

Re:Idiot. Seriously. (-1, Redundant)

uberdilligaff (988232) | more than 4 years ago | (#31386830)

Amen, bro.

Re:Idiot. Seriously. (1)

Opportunist (166417) | more than 4 years ago | (#31386750)

The comparison is pretty apt. It takes some training to hit something with bow and arror. Any moron can pick up a firearm and pull the trigger for effect.

I'm fairly sure the next gen of dev tools will turn anyone into a programming genius. But that's ok by me, I guess we'll be turned from soldiers into weaponsmiths, to stay in the analogy.

DNRTFA (1)

chicago_scott (458445) | more than 4 years ago | (#31386486)

That sushi in the banner is imitation crab. That's a red flag.

Surprise surprise (0)

Anonymous Coward | more than 4 years ago | (#31386526)

1. As a technology matures less time is spent inventing it and more time implementing it.

2. Programming, for anyone who pays for it, is not about it being fun; it's about getting shit done, and leveraging the effort of those who beat the path you need to walk usually results in cheaper, more stable, and more secure software than writing it from scratch. Fanatics, please note the word "usually" before taking out your flamethrowers.

Reminds me... (2, Insightful)

Anonymous Coward | more than 4 years ago | (#31386552)

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...

Re:Reminds me... (1)

Pinky's Brain (1158667) | more than 4 years ago | (#31386910)

He went down the rabbit hole a little too far though ... to a point where so few can follow him that he is designing hardware only he can use. Which is obviously going to be a hard sell.

Re:Reminds me... (1)

EastCoastSurfer (310758) | more than 4 years ago | (#31386956)

Cool, so I'll guess for each problem we'll start with writing the OS... I'm only half joking. If need to build a website do I need to start by building a web server or can I use Apache?

Starting at the appropriate level of abstraction (and understanding the trade offs) is in of itself a skill. It could be argued that in order to solve more complex problems you HAVE to start at a higher level of abstraction or else you mentally get bogged down in the details (many of which do not matter as long as they just work).

Welcome To The Real World (0, Flamebait)

tpstigers (1075021) | more than 4 years ago | (#31386558)

So your job sucks. Welcome to the club. Just about everyone's job sucks. Do you think your geekdom exempts you from this? Suck up and deal, Nancy.

Next Next Finish Programming (4, Interesting)

theodp (442580) | more than 4 years ago | (#31386560)

THE DUMBING-DOWN OF PROGRAMMING [salon.com] (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 (5, Interesting)

Tablizer (95088) | more than 4 years ago | (#31386684)

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.
   

Re:Next Next Finish Programming (1)

Opportunist (166417) | more than 4 years ago | (#31386788)

Every time you simplify something you also take away flexibility. You cannot retain the same level of flexibility and raw power with simpler tools, unless the original tool was too complex to begin with. It might be possible to rearrange and document better, it is possible to make it more approachable by offering a cleaner, more appealing, more intuitive or easier to grasp interface, but you cannot "dumb it down" without taking away power from it.

For reference, see almost every graphical interface for any given Linux CLI program.

I don't like wizards that much (1)

rebelscience (1717928) | more than 4 years ago | (#31386916)

I like drag and drop better but I think the ultimate goal of programming research is to open up application development to as many people as possible. Why I Hate All Computer Programming Languages [blogspot.com] .

On my first job, my boss said (2, Insightful)

blai (1380673) | more than 4 years ago | (#31386566)

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

too much resources available (0)

Anonymous Coward | more than 4 years ago | (#31386590)

back in the day you only had 3583bytes available to code ... :)
Now we have way too much RAM / CPU / whatnot, so streamlined code is not needed anymore, most of the time at least.

Car analogy! (3, Insightful)

Anonymous Coward | more than 4 years ago | (#31386602)

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! (4, Funny)

BadAnalogyGuy (945258) | more than 4 years ago | (#31386630)

Car analogy:...

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

Re:Car analogy! (3, Insightful)

phantomfive (622387) | more than 4 years ago | (#31386852)

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.

! Car analogy (1)

oddaddresstrap (702574) | more than 4 years ago | (#31386938)

Nice try, but, at best, a "vehicle" analogy. To be more precise, a truck analogy.

Crappy frameworks, tools and web standards (5, Insightful)

syousef (465911) | more than 4 years ago | (#31386636)

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 (4, Insightful)

Tablizer (95088) | more than 4 years ago | (#31386812)

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 (1, Interesting)

shutdown -p now (807394) | more than 4 years ago | (#31387014)

It's time to build a dedicated open-source GUI/CRUD browser that can handle desktop, MDI, data grids, tree controls, and CRUD-like applications with grace.

You mean, like Access? Or, in some way, even SharePoint?

Misleading summary. (5, Informative)

BitterOak (537666) | more than 4 years ago | (#31386668)

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.

Re:Misleading summary. (0)

Anonymous Coward | more than 4 years ago | (#31386944)

He does now.

"Good programmers write good code... (5, Funny)

fatp (1171151) | more than 4 years ago | (#31386702)

excellent programmers steal excellent code."

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

Re:"Good programmers write good code... (2, Informative)

binarylarry (1338699) | more than 4 years ago | (#31386754)

That would be Pablo Picasso.

what's the deal with don knuth? (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#31386710)

So he wants to write a book on compilers, if he ever finishes his series of books on computer programming for people who time travelled back to the early 1960s. Really? If he knew jack hit about compilers, how does he explain TeX? TeX isn't a typesetter, it's a poorly thought out programming language. How poor? "How do I ..." questions on comp.text.tex are invariably answered with "Use perl/python/ruby/awk/sed/etc". Imagine if the answer to "how do I loop from 1 to 100 in java?" was "write a python script to generate the unrolled loop code."

Band-aid approach (1)

cormander (1273812) | more than 4 years ago | (#31386736)

"pasting not-quite-compatible libraries together and patching around the edges" is quite an acceptable form of programming, and can take some real skill to do well. It's called the band-aid approach, which is effective for small, startup companies looking to get off the ground, and large companies looking to save a buck.

easy (-1, Troll)

pydev (1683904) | more than 4 years ago | (#31386760)

It's easy to see what happened to programming: the industry was taken over by people who "wrote space-invader games in BASIC on a VIC-20", "wrote multi-user dungeons in C", and "worked deep down in the guts of a text database system — still C".

Moot Issue (1)

Redlazer (786403) | more than 4 years ago | (#31386766)

It works just like everything. The simple stuff is simple, but it takes time and understanding. If you free up the mind to concentrate on harder things, while having something else take care of the simple things, we move forward.

Its about PROGRESS. Why else do we have machines and computers? What are they for? What are doing for us?

Doing things the hard way sucks. I'd much rather develop something that will do it the hard way so I never have to do it the hard way again.

-Red

You can still program, if you're an engineer (4, Informative)

Sarusa (104047) | more than 4 years ago | (#31386774)

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:You can still program, if you're an engineer (1)

Tablizer (95088) | more than 4 years ago | (#31386862)

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...

This is similar to what Paul Graham has said about OOP, but I think he's talking more about Java than say SmallTalk:

Object-oriented programming is popular in big companies, because it suits the way they write software. At big companies, software tends to be written by large (and frequently changing) teams of mediocre programmers. Object-oriented programming imposes a discipline on these programmers that prevents any one of them from doing too much damage. The price is that the resulting code is bloated with protocols and full of duplication. This is not too high a price for big companies, because their software is probably going to be bloated and full of duplication anyway. [emphasis added]

http://www.paulgraham.com/noop.html [paulgraham.com]

Re:You can still program, if you're an engineer (1)

Opportunist (166417) | more than 4 years ago | (#31386908)

But they see this as a net positive because they have a new acronym to put on their resume.

You need to write a complex framework for that? I was under the impression that 90% of the Java-related three-letter-thingies are made up anyway...

Re:You can still program, if you're an engineer (1)

psych0munky (1673632) | more than 4 years ago | (#31387012)

At my present job they really don't care what language I do things in as long as the job gets done

Hrm...maybe I am reading into things from your post a bit here, but there is a lot to be said for standardization when everyone is doing things differently...lack of standardization is only sustainable in small teams or small quantities.

Just take a look at what Henry Ford did...most people think his big contribution was the ubiquitness automobile...I disagree, the ubiquitness of the car today was only a result of Ford's contributions. By standardization was he able to achieve this ubiquitness. He standardized the parts different vehicles were made out of, this made them cheap, reliable and easily maintainable. He standardized worker relations (8 hour work day, switching people to do different jobs to prevent boredom, etc), to make people more productive.

To quote Men in Black, "a person is smart, people are dumb panicky animals", well guess what? Corporations are made up of people, not a single person...if you want to make it in a capitalist society, you better learn to deal with it.

The 'pasting not quite compatible libraries together' approach is a Java/COBOL thing of minimizing the damage incompetent consultants can do

I am hearing that you think that corporations that are hiring these jobs out are specifically asking people to do this so that the impact of mediocrity isn't so painful. I respectfully disagree. In the company I work for, we have hired out many jobs to contractors (both on and off-shore), and the results are pretty much the same. I honestly don't think that my bosses go out and ask them to write crappy code...in fact I was in a meeting with consultants that my bosses crashed, stating efectively, the order of priorities are On time, Maintainable and on budget.

Nay, to me the problem we are facing is one of the ugly sides of a capitalist society: greed. The consultants want to make more money. My company wants to spend less money so they can keep it for themselves or to acquire more stuff to make more money. It seems that the "trinity" of a decent capitalist society, greed/quality/freedom, has taken an unbalancing shift towards the first item: greed. As a result, product quality suffers. As a further result, the greed drives a desire of the corporations providing good and services to restrict consumers freedoms. Somehow we need to get the balance back in order. I am just not sure how to do that, beyond a revolt (which I am sure won't happen because most people are both producers and consumers. Because of that, logically, I would think that the system should right it self...but then I remember the system consists of people, not a person.

Same thing that happened to the rest of IT.... (1)

MadMorf (118601) | more than 4 years ago | (#31386786)

Unfortunately, most of us are not "engineers" any more, we're factory workers on a production line...

Unless you're working for the company making the tools, you're using someone else's wrench to build that "truck".

The pictures of meat are really disgusting (0)

Anonymous Coward | more than 4 years ago | (#31386798)

Can't read the article - there should be a graphic images warning!

Magic incantations you say.. (1)

Zetta Matrix (245803) | more than 4 years ago | (#31386806)

By analogy, if I invoke several theorems and lemmas to do a mathematical proof rather than killing myself by deriving them again, then I must not be having fun because I'm just plugging into magic incantations.

Errrr... no. These "shortcuts" improve productivity for both programmers and mathematicians and that's good. Getting down to nuts and bolts is also good because it promotes understanding.

Moving on...

Re:Magic incantations you say.. (2, Insightful)

Opportunist (166417) | more than 4 years ago | (#31386924)

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.

Re-use verses Plug'n'Play (1)

bgibby9 (614547) | more than 4 years ago | (#31386838)

I think that when we started, we used libraries because we didn't know HOW to do certain things, but as we grew (hopefully) we learned how to do those things and found better more efficient ways to build them. Then we found out that libraries attempt to be generic enough for any purpose, then saw that life can rarely utilise generic libraries for 100% of our requirements so we built bloated software. Then we learned that certain concepts require "from scratch" work, even if it is "re-inventing the wheel" every now and then, to ultimately realise that sometimes you can re-use code and some times you can't! We all have to go through the hard yards as no-one will ever "just believe" you when you tell them otherwise :)

The Issue (2, Insightful)

Seraphim_72 (622457) | more than 4 years ago | (#31386870)

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.

Isn't he the guy who defends using goto statements (-1, Flamebait)

Billly Gates (198444) | more than 4 years ago | (#31386918)

I do not think I could trust this guy with [acm.org] anything programming related. He surely would not have passed computer science 101 with my instructors.

Re:Isn't he the guy who defends using goto stateme (1)

Opportunist (166417) | more than 4 years ago | (#31387006)

I use gotos you insensitive clod!

I just call them JMPs.

Lack of imagination? That's your problem! (0, Troll)

Hurricane78 (562437) | more than 4 years ago | (#31386942)

He seems to bitch about not being able to write something fundamentally new... but ignores that you have to think of actually inventing something new beforehand. Maybe he is more of an engineer, and less of an inventor/scientist. (Two types that complement and need each other.)

I don't do much library gluing, since I chose to concentrate on inventing new things. Revolutionary things.
It’s just a choice. Nothing is stopping him from doing the same.
But I don’t even consider the gluing bad. Actually it only shows how far we have come, when we have nearly perfect standard libraries for everything and its dog. Generalizing algorithms and making things reusable are corner stones of programming. And they are great ones!

If you want to code something new, you need to come up with something revolutionary.

So: Mr Knuth: How about we team up: I deliver new ideas that nobody came up with yet, and you get something to code that nobody ever coded before. How about that? I bet we would make a great team! ^^

Specialization is for Ants (2, Insightful)

DeionXxX (261398) | more than 4 years ago | (#31386986)

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”.

I couldn't agree more (1)

Fnord666 (889225) | more than 4 years ago | (#31387002)

We should take this revised approach in a number of areas, not just programming. We shouldn't be just grabbing bolts and nuts out of a bin. We should be hand machining each one that way you know they will work correctly and that they will go together. You can't trust that any old bolt you might buy will necessarily work. If this approach was good enough for the 19th century, it should be good enough for the 21st.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>