Whatever Happened To 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.
Programming == Cut & Paste (Score:4, Insightful)
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 (Score:5, Insightful)
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:As a writer of crappy code.. (Score:5, Insightful)
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.. (Score:5, Insightful)
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.. (Score:4, Interesting)
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.. (Score:5, Insightful)
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:As a writer of crappy code.. (Score:4, Insightful)
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.. (Score:4, Insightful)
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: (Score:3, Insightful)
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: (Score:3, Interesting)
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 look
Re: (Score:3, Interesting)
Re:Programming == Cut & Paste (Score:5, Insightful)
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: (Score:3, Insightful)
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 m
Re: (Score:3, Insightful)
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
Re:Programming == Cut & Paste (Score:5, Insightful)
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: (Score:3, Funny)
You want to troll on slashdot? Write original strawmen first!
Re: (Score:3, Insightful)
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 th
Re: (Score:3, Insightful)
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"
Re: (Score:3, Informative)
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 doi
Not even fucking close (Score:3, Insightful)
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 requirem
Well what's wrong with that? (Score:4, Insightful)
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? (Score:4, Insightful)
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...
Re: (Score:3, Insightful)
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 [wikipedia.org] 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 frustr
Implement some things yourself (Score:3, Insightful)
Re:Implement some things yourself (Score:4, Funny)
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 (Score:4, Funny)
You, need, to, add, more, commas,.
Re:Implement some things yourself (Score:5, Funny)
Re:Implement some things yourself (Score:5, Funny)
You need, to boldly add, more commas [where no commas, have been placed, before!]
Re: (Score:3, Interesting)
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-del
Re: (Score:2)
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 (Score:4, Insightful)
No, it won't bite. It will segfault.
Frameworks (Score:3, Informative)
Re:Frameworks (Score:4, Insightful)
Re: (Score:2)
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 (Score:5, Insightful)
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 (Score:5, Insightful)
Re:Frameworks (Score:5, Insightful)
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 (Score:5, Insightful)
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 (Score:5, Insightful)
Increase in number of runs per second (Score:5, Insightful)
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 (Score:5, Insightful)
Re:Frameworks (Score:5, Insightful)
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: (Score:3, Insightful)
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 scien
Re:Frameworks (Score:4, Insightful)
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: (Score:3, Informative)
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: (Score:2, Insightful)
Re:Frameworks (Score:5, Informative)
Re: (Score:2)
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...
DNRTFA (Score:2)
That sushi in the banner is imitation crab. That's a red flag.
Reminds me... (Score:2, Insightful)
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: (Score:2)
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.
Next Next Finish Programming (Score:5, Interesting)
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 (Score:5, Interesting)
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: (Score:2)
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 g
I want to slap the author (Score:5, Insightful)
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: (Score:3, Interesting)
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 "p
On my first job, my boss said (Score:2, Insightful)
Car analogy! (Score:3, Insightful)
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! (Score:4, Funny)
Car analogy:...
What you are attempting to do is very difficult. Please leave it to the professionals.
Re:Car analogy! (Score:5, Interesting)
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").
Re:Car analogy! (Score:4, Insightful)
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.
Crappy frameworks, tools and web standards (Score:5, Insightful)
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 (Score:5, Insightful)
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: (Score:3, Insightful)
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: (Score:3, Informative)
...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 bee
Re: (Score:3, Interesting)
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 sho
Re: (Score:3, Insightful)
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 differe
Misleading summary. (Score:5, Informative)
"Good programmers write good code... (Score:5, Funny)
I stole this, and I don't know where it is stolen from!
Re: (Score:3, Informative)
That would be Pablo Picasso.
You can still program, if you're an engineer (Score:5, Informative)
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: (Score:2)
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...
Same thing that happened to the rest of IT.... (Score:2)
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".
Magic incantations you say.. (Score:2)
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: (Score:3, Insightful)
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 tha
Re: (Score:3, Interesting)
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 [wikipedia.org].
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.
The Issue (Score:2, Insightful)
Specialization is for Ants (Score:3, Insightful)
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 (Score:5, Interesting)
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.
Glad I'm writing embedded stuff (Score:3, Informative)
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.
You know Programming is in trouble (Score:4, Funny)
You know Programming is in trouble when being "the goto guy" has become a compliment, rather than an insult.
Try Embedded Programming (Score:3, Informative)
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. (Score:5, Insightful)
I think a better analogy would be to say that today's programmers are more like a Cargo Cult [wikipedia.org].
Re: (Score:2, Insightful)
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: (Score:2)
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 indi
Re: (Score:3, Insightful)
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 cann
Re: (Score:3, Funny)
Do you mean the cretans that pass for programmers ...
What do you have against people from Crete?
... I'll leave peacefully.
Okay, okay
Re: (Score:3, Insightful)
Re: (Score:2)
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: (Score:2, Funny)
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. (Score:5, Insightful)
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. (Score:5, Interesting)
"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. (Score:5, Funny)
Re:Idiot. Seriously. (Score:5, Funny)
slashdot. where don knuth is an idiot because he cant grasp the awesome power of php
Re: (Score:2, Interesting)
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 w
Re: (Score:2)
Re:Idiot. Seriously. (Score:4, Insightful)
"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: (Score:3, Interesting)
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 o
Re: (Score:2)
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.
Re: (Score:3, Informative)
---
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 t