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".
Implement some things yourself (Score:3, Insightful)
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:Frameworks (Score:5, Insightful)
Re:Idiot. Seriously. (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.
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...
On my first job, my boss said (Score:2, Insightful)
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"
Comment removed (Score:3, 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.
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: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: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: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: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: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 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: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:Frameworks (Score:4, Insightful)
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.
The Issue (Score:2, Insightful)
Re:Frameworks (Score:2, Insightful)
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:Magic incantations you say.. (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 that will more or less do the trick) and it will also tell you what you have to drop into that function to make the magic happen.
Now, math has been a while ago for me, but I cannot remember it being THAT easy.
Increase in number of runs per second (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)
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.
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”.
Re:Frameworks (Score:5, Insightful)
Re:Programming == Cut & Paste (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 might want the thing that they can build upon to grow their business in the future. Hell, you might be getting paid by the hour, so your incentive might be to create things in the least efficient, but still passable, way possible.
Re: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.
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.
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 requirements out some dumb-ass business analyst, who can barely speak the language, much less actually put something in writing and doesn't even know or care about the fucking applications they're writing requirements against.
Or perhaps you don't care about getting your airline reservations, airfare and seat assignments correct when you book them.
Well what's wrong with that? (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:Programming == Cut & Paste (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 compel me to ever again need to re-write a quick sort algorithm, container implementation, or string parser.
Re:Programming == Cut & Paste (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 that "most efficient" could easily include total costs/time not only in the first draft, but over the life of the project, including use of the finished code and future maintenance.
programming is better off... (Score:2, Insightful)
Re:Frameworks (Score:2, Insightful)
I've promoted the idea of "helpers" instead of "wrappers" (what you call frameworks). Wrappers hide you from the guts, but helpers allow you to work with them at a higher level when convenient without preventing you from getting at the guts when needed. You date helpers, but have to marry wrappers. It's usually easier to get out of a date than marriage (except maybe in Hollywood).
Helpers have the primary goal of automating the drudgery of common idioms, not to prevent you from sticking your tongue in the fan by locking it away, as frameworks often do.
And (good) helpers tend to be designed with a smaller granularity such that you can mix and match and rewrite and toss as needed. They may take more work initially than a framework, but they are also more flexible.
Helpers differ from "traditional" libraries in that they are a kind of framework, or set of frameworks, but with looser coupling between the parts.
Re:Crappy frameworks, tools and web standards (Score:1, Insightful)
MS listened and produced silver-light and WPF. There are more solutions from other software companies.
But for some reason everyone got the HTML/WEB/AJAX bug and think that the web is a good and reasonable solution for everything.
The WEB sucks for dev of desktop like applications (and that even includes HTML5).
I blame google and gmail for inspiring people to use the web in that unintended way.
Re:I couldn't agree more (Score:2, Insightful)
But, you realize, that's entirely true. Here's a vaulted car analogy:
American cars were historically bolted together, or welded together from standard parts supplied by thousands of different suppliers. If you wanted to, you can take an old American truck, completely disassemble it, replace almost any piece and re-build it from the ground up. That business model worked when the design costs of a car were vastly greater than the manufacturing costs. By using standard parts, those costs were spread out over many years and many models. Each part was not optimized to each car, but it was cheaper to manufacture and maintain regardless. American car manufacturers stuck with this, due to several factors, even in the face of superior competitors with vastly different processes. We all know how that turned out.
Today, almost every piece of a car is custom-designed, not shared with other models. Robots weld auto bodies into a single piece. People spend more time working in the design phase, not as much in the manufacturing. Trimming excess materials from the design is nearly a science. The cost of repairing or rebuilding a car is prohibitive compared to the cost of simply buying a new one. American car companies that failed to adapt, along with their parts suppliers, are going bankrupt.
Now, is one model superior to the other? No. They each have strengths and weaknesses. Asian workers were not necessarily better-off than American workers, despite their technological advantages. Asian automotive companies evolved in an environment rich in talented labor and poor in natural resources. They used design and lots of mental "work" to conserve natural resources. American automotive companies evolved in the opposite environment, poor in skilled labor and rich in unskilled labor and natural resources. They used natural resources and unskilled labor to make up for lack of skilled design work.
Ideally we would all be best off if we lived in an environment rich in natural resources and talented labor, while still conserving both. Technology, correctly applied, can help us achieve this. But only if the advances of technology are not negated by the proliferation of unskilled labor or wasteful resource consumption.
Re:Crappy frameworks, tools and web standards (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:Programming == Cut & Paste (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" way to build a safe car? What's the "most efficient" way to build a safe bridge? There are simply far too many variables, all interdependent in subtle ways, to consider. Add an extra layer of corrosion allowance, for instance, and you may prevent a bridge from collapsing and save a dozen lives. On the other hand, you may trigger a resource shortage that bankrupts a major company and destroys a thousand. Physical implications are obvious, but software is analogous. Spend ten billion dollars writing the perfect space shuttle control software, and you might save a dozen astronauts. Fail to develop a viable space exploration program in time, and humanity could be wiped out by the next asteroid. You're right, though, those aren't really software problems per se, and should be clearly defined as part of "the problem". Often they aren't.
But, yes, I'm assuming #2. I think it's clear from the GP that this is the manner in which "most efficient" was used.
But my point is also that it's not just the "efficiency" of the program itself or it's maintenance. It's the efficiency of the entire business and how the software fits into it. The cost of software in most business cases is trivial compared to it's benefits. Which, I think, is the reason we see so much software being re-invented over and over again to begin with. What isn't taken into account, though, is the cost of getting software wrong.
Re:Implement some things yourself (Score:4, Insightful)
No, it won't bite. It will segfault.
Re:Crappy frameworks, tools and web standards (Score:2, Insightful)
Regarding Flex, I was hoping for an open standard. Maybe it will help motivate an open standard(s) if and when it perfects the art of GUIs. It can show what's possible, and its weaknesses also suggest some improvements.
HTML browsers were popular largely because they were based on open-standards; namely HTTP, HTML, and to a lessor extent JavaScript and CSS. A GUI browser could be the same kind of animal, but instead influenced by desktop and CRUD idioms directly instead of as an after-thought.
Re: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)
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:Frameworks (Score:1, Insightful)
congratulations. you picked the wrong framework then.
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:2, Insightful)
Re:As a writer of crappy code.. (Score:2, Insightful)
Yes, people learn from other people's experiences. But some seem to think it's only them that do..
Re:Magic incantations you say.. (Score:2, Insightful)
"Now, math has been a while ago for me, but I cannot remember it being THAT easy."
The whole problem of modern mathematics is exactly this. It is not organized in an efficient manner. Programmers are not algorithm writers. Programmers are organizers -- and this is very important to understand. If one of my programmers would produce code that is that badly documented, that badly organized as mathematicians -- I would fire him.
And this is the main misunderstanding that TFA has. Writing algorithms is just a minor part of our job.
Re:As a writer of crappy code.. (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:Increase in number of runs per second (Score:2, Insightful)
And yet, Twitter is still around and still relevant. Which shows that one can get away with taking these short-cuts and still achieve the ultimate aim of your project. I see people getting bogged down in the details of which software architecture/model to use all the time (never mind sort algorithms!), so much so that they lose sight of their objectives. What often happens is that someone (usually me) then does a quick end-run around them in <insert scripting language here> and we eventually move on. People wonder about the prevalence of dodgy scripts in the world today; I say this habit of programmers taking their eye off the ball is one of the reasons. Never underestimate the advantage of being first to market.
Re:Programming == Cut & Paste (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 frustrates the hell out of people who don't actually need them.
If your goal is to ship the product ASAP no holds barred, then a Java programmer or five is what you seek. If your goal is to ship a well written product that is maintainable and efficient, then you seek someone with actual programming skills.
Re:As a writer of crappy code.. (Score:2, Insightful)
The code base I work on would be improved by a rewrite. But in doing so it would actually be a matter of putting more effort into using the libraries (they do too much manual string manipulation for example that could be done using existing library calls; it's Qt based stuff).
At the same time it would cut lines of application code and make seeing the algorithm easier. I've just swapped 2500 lines for 850 lines whilst increasing functionality.
Cost benefit wise it's impossible to say in advance was it worth it.
Re:As a writer of crappy code.. (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:Frameworks (Score:5, Insightful)
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: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:Frameworks (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 scientist, not a programmer"). The result was still written in perl, by the way.
The improvement meant that the script could be used a hundred times a day with different parameters, something that would have taken months. Your suggestion is to buy a thousand machines to crunch the numbers instead of optimising the script. That just doesn't make sense to me.
Re:Frameworks (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: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.
Real world example (Score:1, Insightful)
Here's a real world example of me stringing together libraries that already exist.
I'm currently working on a project that requires parsing some HTML, and performing magic on it to transform it into HTML decorated with auto-generated code.
What I'm interested in writing is the transformational magic. What I could be writing is the HTML parser.
Now, while a fun project, why the heck would I want to write my own HTML parser? Well, I have a very specific set of requirements, that it turns out most HTML parsers aren't very good at. (These are more API issues, rather than parsing issues. It turns out most DOM-oriented parsers, which most HTML parsers are, tend to be horrible at what I want to do, due to HTML having weird rules like implicitly closed elements.)
Instead of deciding this is a great opportunity to reinvent the wheel, I spend a day and a half looking at a wide range of HTML parsers, writing code and evaluating each one.
You know what? Eventually, I find someone who wrote a library that solved exactly the problem I wanted to solve. Someone who had the exact same problem as me, and has spent who knows how many untold man-hours creating a debugged and elegant library.
Now, someone tell me why it would have been better to have spend that day and a half getting just 10% of the job done, when I can just use someone else's wonderful library and build just a little bit of glue to my own problem domain on top of it.
Most of my "programming" time is spent looking for an existing body of code that will help me solve the problem, not actually coding a solution to the problem itself. 90% of any programming problem has already been solved before, a mantra I constantly repeat to myself every time I feel the least bit tempted to try and solve a problem from scratch. Do enough research, look hard enough, and most of the time you can find the solution.
And if you don't, that's a great opportunity to contribute a new library that might become widely used. :-)
I think this shift is more about open source than anything else. Over the last 10-20 years, we've collectively built up this amazing body of code that anybody can use, without any commercial barriers standing between adopting different technologies. It's allowed us to push code reuse much further than we could in the past, and there's been a tremendous net benefit from it. Dismissing that progress as not being "real programming" is just incredibly naive.
Re:Crappy frameworks, tools and web standards (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 different from Delphi. It also has a comparable widget library (complete with absolute positioning that you like), and the ability to write everything in code.