Slashdot Mirror
Whatever Happened To Programming?
Mirk writes "In a recent interview, Don Knuth wrote: 'The way a lot of programming goes today isn't any fun because it's just plugging in magic incantations — combine somebody else's software and start it up.' The Reinvigorated Programmer laments how much of our 'programming' time is spent pasting not-quite-compatible libraries together and patching around the edges." This 3-day-old article has sparked lively discussions at Reddit and at Hacker News, and the author has responded with a followup and summation.
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".
Go ahead. It won't bite. Some things are over-engineered.
Long live the BSD license
There's still lots of interesting programming going on, and lots of interesting new languages. The ''Magic Incantations' are the same frameworks you used to have to write yourself, and even then you generally only did it once. It's gotten a lot easier to share the common solutions now, and we're free to do the real work.
That sushi in the banner is imitation crab. That's a red flag.
I think a better analogy would be to say that today's programmers are more like a Cargo Cult.
I'm already at the gunpowder stage. My code has been blowing up for years.
slashdot. where don knuth is an idiot because he cant grasp the awesome power of php
1. As a technology matures less time is spent inventing it and more time implementing it.
2. Programming, for anyone who pays for it, is not about it being fun; it's about getting shit done, and leveraging the effort of those who beat the path you need to walk usually results in cheaper, more stable, and more secure software than writing it from scratch. Fanatics, please note the word "usually" before taking out your flamethrowers.
The problem here is trying to use those bows and arrows for deep sea fishing :)
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.
My blog
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...
THE DUMBING-DOWN OF PROGRAMMING (1998): "My programming tools were full of wizards. Little dialog boxes waiting for me to click "Next" and "Next" and "Finish."...Dumbing-down is trickling down. Not content with infantilizing the end user, the purveyors of point-and-click seem determined to infantilize the programmer as well."
"Don't even try reinventing the wheel. This is not an assignment. Just use whatever code you can find."
In soviet Russia, God creates you!
Yeah. I'm definitely getting off of Knuth's lawn.
My blog
It would seem to me that the argument is based on whether or not the wheel should have to be re-invented for each programming project. If the code is good, why not reuse it as a module?
Life is not for the lazy.
back in the day you only had 3583bytes available to code ... :)
Now we have way too much RAM / CPU / whatnot, so streamlined code is not needed anymore, most of the time at least.
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.
Yeah, I was going to say, as a trained programmer, although I use the libraries others have made, I'm not some ignorant savage.
I didn't do stellar in my algorithms class at University, getting only a B-, but I learned enough to realize THIS IS SERIOUS BUSINESS. Fortunately, there were plenty of kids who "got" the advanced challenges of algorithms, so the new generations aren't all slack-jawed, either, maybe just me.
I just tend to do a better job when someone has executed those algorithms for me correctly, and I can get onto building a system for my client. I don't want them to pay because I
couldn't implement the best algorithms for each data structure I use.
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.
These posts express my own personal views, not those of my employer
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.
"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.
I am officially gone from
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.
Negative moral value of force outweighs the positive value of good intentions.
Warning! Before you read the linked article or its followup too deeply, be aware they are not by Donald Knuth. Instead, the author has a brief quote from Donald Knuth in his first blog, and the other link is a followup story. So, "the author" referenced in the Slashdot summary is NOT Donald Knuth. I made the mistake of reading the followup article first, and then when I read the original, I found a brief quote from Donald Knuth which tipped me off to the fact that the author was not Donald Knuth, and as far as I can tell, Donald Knuth doesn't even know this author.
If I can be modded down for being a troll, can I be modded up for being an orc, or a balrog?
No joke.
It's much easier to grasp the awesome list of 300 fast food and department store job history bullets that other programmers have on their resumes.
excellent programmers steal excellent code."
I stole this, and I don't know where it is stolen from!
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.
Even within the group of actual programmers you need different skill sets for different problems. Think of a general contractor and the plumber working for him. The GC knows enough about plumbing (algos) so he knows what he needs and doesn't get screwed, but he isn't the one who builds out all of the plumbing. His skill is getting together all the other parts required to build the house (complete piece of software that solves a customers problem) rather than knowing every intimate detail of how each individual job is done. Think generalist versus specialist.
"pasting not-quite-compatible libraries together and patching around the edges" is quite an acceptable form of programming, and can take some real skill to do well. It's called the band-aid approach, which is effective for small, startup companies looking to get off the ground, and large companies looking to save a buck.
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.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Its about PROGRESS. Why else do we have machines and computers? What are they for? What are doing for us?
Doing things the hard way sucks. I'd much rather develop something that will do it the hard way so I never have to do it the hard way again.
-Red
Guns don't kill people, "with glowing hearts" kills people.
I think the difference is like that between mathematics and engineering. Programming used to be more of a math, you were basically writing an executable form of a proof. Now programming is more about assembling all the previously developed tools to produce a useful result in the same way that engineers use a bunch of mathematical tools (that they may not necessarily know how to derive--and for that matter don't need to) to build a bridge. For a mathematical guy like Knuth, the engineering bit is a drag (for me as well) and the act of problem solving is the interesting part. I would even wager that to such a person the means (or methods of solving) are more important than the end result. The beauty is in the elegance of the solution, not in the fact that we now have a solution. Now programming is much more of an engineering task. The tools might as well be black boxes that we assemble in different ways to produce results. Another type of person likes this sort of thing (not me). These people are more interested in the ends, not the means. They are more driven to produce something cool rather than to produce something in a cool way. (Am I making any sense?)
Neither of these groups is better or worse than the other, just different. Both are needed for progress. There will always be mathematical problems to solve, and there will always be a need to apply the toolbox created by such mathematics to practical tasks with an emphasis on results rather than methods.
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.
Not to mention that he can't grasp the awesome power of 300 APIs (sorry, "technologies") each with three letter abbreviation names starting with J that make up the resume of a typical Java programmer.
Agreed, but the problem is that most of those "technologies" are bloated, designed by committee, buzzword-loaded crap. The problem is *not* that we have found better ways to share code than we used to. I mean, I'm all for crafting beautiful, optimally efficient snippets of code that do one thing perfectly. But have you ever noticed that you can do things in a couple of hours now that 10 years ago would have taken weeks? Being able to cobble together a prototype fast is *hugely* useful and important. Now who was it again who said that premature optimization is the root of all evil? Hmmm...
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.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
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".
Goofy, Geeky Gifts and More!
Can't read the article - there should be a graphic images warning!
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...
I think that when we started, we used libraries because we didn't know HOW to do certain things, but as we grew (hopefully) we learned how to do those things and found better more efficient ways to build them. Then we found out that libraries attempt to be generic enough for any purpose, then saw that life can rarely utilise generic libraries for 100% of our requirements so we built bloated software. Then we learned that certain concepts require "from scratch" work, even if it is "re-inventing the wheel" every now and then, to ultimately realise that sometimes you can re-use code and some times you can't! We all have to go through the hard yards as no-one will ever "just believe" you when you tell them otherwise :)
http://www.gibby.net.au
I think the difference is like that between mathematics and engineering. Programming used to be more of a math, you were basically writing an executable form of a proof. Now programming is more about assembling all the previously developed tools to produce a useful result in the same way that engineers use a bunch of mathematical tools (that they may not necessarily know how to derive--and for that matter don't need to) to build a bridge.
Yes, and no. Your sense of history is warped. Academics have always known that programming is a form of constructive proof, and all that it entails. But the engineers ran with C's execution model in the 1970s. It has been a long struggle to get "high level" features in procedural languages, mostly because of the work of a few academics working on functional and OO languages. Later, Sun decided to do Java.
If "early" programming is like writing proofs, "modern" programming ought to be like combining proofs. And it is, in principle. That's all well and good. This is especially easy if you have a language which allows easy combinations of proofs. OO can be the wrong model for combining your proofs. (Especially if you're not quantifying over object-like things...)
How many unique programming problems are there? The first guy that designs an efficient steam engine is a great engineer. What about the 100 guys after him that vary on his theme? What about the next 1000 or 10,000? Seems to me this is a complaint about no one inventing something as revolutionary as the wheel. Hey author - you can't, it has been done already! And as someone has already pointed out this is *not* from Knuth. This might as well get the 'Get off my lawn' argument then.
Slashdot, where armchair scientists get shouted down and armchair theologians get modded up.
"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
We know where leadership by an anti-intellectual "strongman" who scapegoats minorities and likes boisterous rallies goes
I like drag and drop better but I think the ultimate goal of programming research is to open up application development to as many people as possible. Why I Hate All Computer Programming Languages.
Rebel Science News
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.
Nice try, but, at best, a "vehicle" analogy. To be more precise, a truck analogy.
He seems to bitch about not being able to write something fundamentally new... but ignores that you have to think of actually inventing something new beforehand. Maybe he is more of an engineer, and less of an inventor/scientist. (Two types that complement and need each other.)
I don't do much library gluing, since I chose to concentrate on inventing new things. Revolutionary things.
It’s just a choice. Nothing is stopping him from doing the same.
But I don’t even consider the gluing bad. Actually it only shows how far we have come, when we have nearly perfect standard libraries for everything and its dog. Generalizing algorithms and making things reusable are corner stones of programming. And they are great ones!
If you want to code something new, you need to come up with something revolutionary.
So: Mr Knuth: How about we team up: I deliver new ideas that nobody came up with yet, and you get something to code that nobody ever coded before. How about that? I bet we would make a great team! ^^
Any sufficiently advanced intelligence is indistinguishable from stupidity.
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”.
We should take this revised approach in a number of areas, not just programming. We shouldn't be just grabbing bolts and nuts out of a bin. We should be hand machining each one that way you know they will work correctly and that they will go together. You can't trust that any old bolt you might buy will necessarily work. If this approach was good enough for the 19th century, it should be good enough for the 21st.
'The tyrant will always find pretext for his tyranny.' - Aesop's Fables
I use gotos you insensitive clod!
I just call them JMPs.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Knuth should stop whining about the state of programming and going finish writing his books with his fonts and his text formatting system written in his language making use of his assemble language.
So I had this long diatribe all written and ready to post. It was about how it's terrible that web applications really suck to develop because there are a minimum of 5 different technologies that you have to know just to get off the ground and that every "innovation" has been a kludge on top of other kludges meant to twist a static content delivery platform into an interactive applications platform. But I scrapped it since that's a dead horse and I'm just some random jerk anyway.
Then I actually RTFA and decided I'd rather respond to Knuth's quoted sentiment:
Well, I wouldn't want to go into it as a career, but programming is a hobby of mine. I like to make applications, but I have neither the patience nor time to design even a trivial application that doesn't blatantly steal 90% of its code from other (open source) sources. The only way I know how to program is basically what Knuth said: I paste other people's frameworks, libraries, classes, and functions together into an application of my own. I don't want to spend months refining logic and algorithms. Although I do take the time to research The Right Way to do something, I don't particularly care if my code is elegant, I just want it to work and then get to the business of actually using the application.
And what's wrong with that, anyway? Isn't the point of modern programming paradigms to reuse whatever existing components you can, to save yourself time and headaches from re-inventing the wheel? If I need AES-256, there's no way in hell I'm writing it myself when there are dozens of existing implementations out there for nearly every language by people who are much smarter than me, and which are packaged up into nice little bundles that I can wget into my source tree and use right away. How is that anything but a good thing?
Crappy code is all around.
Crappy code exists because it works. It matters not how elegant a solution is; it matters that such is, in fact, a solution.
Disclaimer: I'm a sysadmin, not a programmer.
Boot Windows, Linux, and ESX over the network for free.
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.
Advice: on VPS providers
Well... maybe the projects you(?) are involved in are shit?
Hey, I found a way to kill Knuth: Create “Clippy’s ’Microsoft Visual PHP’, Clickwheel Tablet Edition”! (A browser game^Wapplication of course.),
He will die from a heart attack, and then spin in his grave... round and round and round... wheeee.
Any sufficiently advanced intelligence is indistinguishable from stupidity.
We now live in a connected world. There is no longer a need to keep re-inventing the wheel. When it comes to the building blocks of a program, chances are someone has already implemented what you want to do, has done it better than you can, and their solution has been time-tested. There's just no need to implement your own Malloc routine. I think of it more like graduating from basic Lego bricks to the more exciting "Expert Builder" series with a greater palette of modules that can make more interesting creations quickly. What does scare me is that a new generation of programmers might take all of this for granted, and never try and understand things at a machine level. High level languages are great, but there's a lot to be said for understanding what's going on behind the scenes. When things go wrong, being able to "think like the machine" enables you to solve things quickly
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.
be the "somebody" who make the libraries...ultimately you might like kernel coding?
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.
If someone is passing you on the right, you are an asshole for driving in the wrong lane.
If you want to implement code that adheres to a set of standards you can either use a library or implement a solution yourself. I want to watch the blog author explain to management why his application isn't going to make a release date because he has to finish up his SMTP implementation. "Just a few more days and I'll be able to send that confirmation e-mail to a user." I personally like leveraging the power of frameworks so I can focus more on my specific problem domain. It's also a huge bonus when someone new joins the company and you can point them to some good community based documentation, rather than walking them through the in's-and-out's of some in-house framework.
Given how many crappy programs there are that crash because the author decided to code up buggy versions of library code, I'd say programming is alive and well.
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.
Weaselmancer
rediculous.
My systems software professor had a massive hard on for java, and thus all the C/C++ we needed for Computer Architecture was no where to be found for 90% of my 20 person class. My comp arc professor told us to learn it the weekend before the first lab. Three people did, I already knew enough to write our very simple code.
Professor wanted us to annotate and explain assembly generated by a rather simple C program. He also wanted us to watch registers and make note of the changes in registers and stack and base pointers as we stepped through the program. After lab was over all but two students complained about having to even think about assembly code.
Next lab we played around with a special vector library the prof had made so we could see the difference between vector and scalar math. Me and another guy did the lab and started looking at the assembly and noticed that about a third of the assembly generated in a series of successive adds could be removed. No one else looked at the structure of the assembly, they just complained about having to annotate it again.
It's not the programming, it's the programmers.
You mad
When you want a car you should build your own iron foundry? Just because the people already making iron have not done a perfect job?
Go away, Louis.
"Slow down, Cowboy! It has been 3 years, 7 months and 26 days since you last successfully posted a comment."
Because the higher-level and powerful your module is, the less likely it'll be exactly what the next job needs, hence the dilemma between reinvention and reuse. I don't think anybody is advocating writing literally everyone from scratch. Low level libraries are easily reused.
for some people it may seem less fun, if so nobody is stopping you for writing libraries yourself (except for maybe employers who are concerned about something called 'return on investment') however another take is that programmer's don't get stuck with writing mundane functions that have already been written 1,000s of times. the use of libraries can deliver more reliable applications in less time. library developers can specialize in a particular function and good libraries do functions much better than 'write it yourself' a classic example is encryption libraries...although easy to write your own encryption library, there are so many ways security can be weakened that you may not realize unless you are specializing in this field. in the end programmers are developing better applications, and delivering them more quickly use of libraries live on...
> 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".
Programming titles are getting very wanky: Software Developer, Software Engineer, Software Architect, Senior Software Enterprise Architect, etc. The frightening thing is you'll need some of these who have never coded in their life, but feel qualified to design software for others to write.
At heart, we're all programmers and those designers that know bugger all about software should really choose another career.
I've heard this for the past 15+ years. Funny thing is, the guys that tell this same sad story never say how much they miss the days of writing in Assembly.
Personally, I don't care to re-implement concatenating two strings regardless of the language.
The probability that a theory predicts correctly, gets higher when the theory gets simpler.
The probability that a program is useful in new situations, gets higher when the program gets smaller.
This has been proven mathematically with algorithmic information theory.
However, Keeping It Simple, Stupid, is very hard and costly, and most people have an instinct for hoarding that gets in the way.
Kim0
You know... Spiderman's uncle.
That sounds exactly like something he would say.
Mit der Dummheit kämpfen Götter selbst vergebens
Programming used to be more of a math.
It still is but it's now also a business. The mathematical side is still being actively developed but the people who work on it aren't writing iPhone apps. Nothing has been lost, but the enterprise side of programming now dwarfs the academic side.
So if this is the future...where's my jet pack?
Cargo cult is right. Or at least superstitious at times. I do run into programmers who have inherited code that don't want to touch it or who do some arcane ritual they don't understand, because that's what has worked before. Sometimes the code is just too ugly to understand, or you don't have time to spend figuring it out. There's also the superstition part of doing what you were taught in school without thinking about it further; like experienced programmers who insist you remove all your gotos, or have a single return from a function, etc.
To some extent it's true. If things are going too well, then you are getting spoiled and won't be able to handle the next hard gig when the fun-bubble finally pops.
Table-ized A.I.
^ Microsoft OS programmer ;-)
Table-ized A.I.
"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.
I'm betting 0x$5.00 that he doesn't have one.
Yeah, that paper where he argues for a well-balanced viewpoint that gotos should be eliminated in some cases but not others couldn't have passed computer science 101 with your instructors because he wrote that in 1974, most likely before your CS department existed and your instructors were still learning their times tables.
I'll admit there may be a lot of cutting and pasting in a language with as much boilerplate as Java, but go even higher-level, to something like Ruby...
Cutting and pasting is non-DRY, and is thus (rightly) discouraged. In fact, I'd almost argue that new programmers should have to spend a few months with copy and paste disabled, so they learn proper code re-use.
In fact, you're describing two very different mentalities. Having your language or libraries handle "the hard stuff" is actually the exact opposite of cutting and pasting. If you're doing it right, you notice when you're tempted to cut and paste some code, and you extract that functionality into a library so you don't have to. On the contrary, "cut-and-paste" programmers would be equally at home in C, since they don't care about proper code re-use -- to them, "code re-use" means, as you suggested, finding something on Google they can copy, paste, and modify to their needs.
Now, to address your real argument: I don't know about you, but I only have so much time. I mean, forget the excuses, I'm only going to live so long. Why would I waste my life solving the same problems over and over? Why would I want to implement a sorting algorithm yet again when other people (like Knuth) have done it better, and there are other, much more interesting problems to solve?
I mean, that's almost like bitching that no one has to do the limit of the difference quotient anymore, now that we have these fancy things called "derivatives" -- or that no one has to do Reimann sums anymore, now that we have the Fundamental Theorum of Calculus. Hey, if you want to do derivatives as limits-of-difference-quotients for the rest of your life, go right ahead, but if you're going to do math, wouldn't you rather invent the next grand physics theory?
There's nothing intrinsically "harder" about programming at a low level, it's just less productive.
Don't thank God, thank a doctor!
I think the guy's point was that Knuth wrote that in the 70s, and it's now the 10s - a gap of forty years in which he has capitalised off his earlier work but not really brought anything that revolutionary to the table since. His original work stands as a classic, bring together a vast amount of highly relevant information and algorithms for the programmers of the 70s/80s. It has a lot less relevance in this age because most of his work is now part of some standard library or framework.
I've written plenty of things as useful as TeX but that doesn't mean I'd call Knuth an idiot.
All those moments will be lost in time, like tears in rain.
There will always be mathematical problems to solve
May I have a proof?
Though seriously, who's to say that some variant of Hilbert's Program won't be discovered which deals with statements humans actually care about in some sense (getting around Godel's Incompleteness Theorems; one also has to ignore consistency proofs :( ), or that the universe won't die a heat death? Wouldn't it be sad if all of our reasoning/coding/work went "poof" as the density of matter and energy in the universe went to zero, and everything that ever was or will be was churned ever closer to nothing?
Sorry, I couldn't help trying to add a little rigor to an argument that's biased towards being unbiased.
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).
Sometimes this is the case because they believe they owe their users nothing, and don't think or care about the risk to their reputation.
But sometimes it's deliberate to better sell their book, which properly documents the project. Thus it's ironic that FOSS is often paired with documentation that is both proprietary and not open for community editing,
Well, using libraries is a great learning experience. Sometimes you can learn a lot about a problem if you implement the solution yourself. But your coding style will improve most when you see how others implement the same. It helps you to be more open minded.
Of course one has to be extremely careful whether to use a library at all, and which one to pick.
Jeez that guy's hard to take seriously.
Using the rhetorics of conspiracy nuts makes you a conspiracy nut.
Truth arises more readily from error than from confusion. -Francis Bacon
I didn't knew about cargo cults. It seems like an odd, ridiculous concept but still it exists. Thanks for posting that. Kudos.
Author: Programming was fun, people knew how it worked. Now everyone just glues stuff together. People should love it!
You: Elitist jerks like! You forget that these things are tools! Get stuff done! If we could have a black box that magically spit out code when a monkey pressed a button it would be ideal!
Yes, everyone wants to get stuff done, but that often magically assumes that it comes without a trade off. Sometimes the trade off is cheap, or likely, expensive to someone else, since apparently you wont be around when it bites you in the ass.
Apparently the author likes coding, you feel that the cost effectiveness of the method justifies the end.
Apparently learning how to cook something easy, fun, fresher, and tastier than microwaved crap is a waste of time.
May I also suggest finding a different job where you don't feel the to push for the lowest common denominator?
The idea of a browser is a grand fail. What is required is a data/code distribution platform. A platform that:
-handles security transparently, with encryption at all communication paths.
-handles (lazy) resource distribution, updating, versioning and caching.
-provides a *binary* protocol for managing information.
-treats code as data, so as that code can be managed by the system just like data.
Anyone up for this task? an open source project could be created...
I think everyone agrees that writing documentation is not very interesting. Unfortunately, it's a vital part of software engineering. As I a software engineer myself, I had spent some times in the past trying to write good documentation, but it always ended out of date because writing the actual code is always a priority.
In my opinion, a high-level programming system that allows the programmer to develop a solution without looking at the implementation details is the solution to the problem. The programming system would be used to describe the business logic and the actual functionality of the system. The programming system could then produce a template for the actual implementation in one of the available programming languages. The high level code would be the documentation of the system.
After seing time after time programmers construct their own framework inside frameworks, their own overloading inside overloading, etc, if it would be better for a task to be delivered to code monkeys to design a domain specific language.
The convoluted programming I have seen sometimes is beyond description
If you have a specific problem in a specific domain that has to be coded by average programmers, maybe better design a language for that specific task and be done with it. With as little overloading, re-encapsulating and re-objecting as possible.
Let that for the real software designers.
I want the software engineer who writes the drive-by-wire code for my car to UNDERSTAND COMPLETELY how the software works. I sure hope they don't grab some black-box libraries, slap them together and call it done.
"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
The sad thing is that I recognise those exact same responses from when I submit critical security vulnerability reports to various development groups and companies.
Don't reinvent the wheel without a good reason.
Sometimes you really have to reinvent. eg. I once rewrote std::string for a program and it loaded text files three times faster.
[Of course I did it after suitable profiling and analysis, doing it at the start of coding "just in case" would be wrong]
No sig today...
Knuth had his day. That day is the equivalent of building stone tools and hunting with rocks and sticks.
Today we are using bows and arrows. We have left the stone tools behind and can now express our imagination in ways that are simply beyond the scope of TAOCP.
But remember, we are still only using bows and arrows. The next big thing will be gunpowder.
You are a fucking idiot, and you are a perfect example of why everything runs like shit these days.
The issue with Knuth is his insistence on machine code representation and the time he spends analyzing something like mere linked lists... philosophically, I am much more inclined to be fond of the way McCarthy did it with Lisp, and this was a long time ago too...
I want to play Free Market with a drowning Libertarian.
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.
Two main things:
1 - Laziness
2 - Unreasonable deadlines
---- Booth was a patriot ----
Back in the 1990's, all the rage was about "software components", what was back then a dream. Those who came up with COM and Corba and OpenDoc envisioned a world where software components would be as easy to put together as electronic components.
Well, that's the world we live in now. Just type "./configure; make" and use it. Why complain? It's a good thing. It makes us more productive. It allows our poor brains to keep up with Moore's law. See http://xlr.sourceforge.net/Concept%20Programming%20Presentation.pdf for more...
-- Did you try Tao3D? http://tao3d.sourceforge.net
Oh yeah, I agree totally. The mathematical side is still very much alive and well, it just isn't the majority of whats done under the umbrella of programming any more. Also, as one other commenter pointed out in response to my post, there have been engineering apps as well. I think that Knuth is probably (potentially unfairly) lamenting that the majority of programming these days has become engineering (this is because there are lots of things that need to be built and so many more engineering tasks, not because there are fewer mathematical tasks).
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.
you're a string theorist?
Isn't this the Story of Mel, all over again, just on a higher level of abstraction?
cpghost at Cordula's Web.
You know Programming is in trouble when being "the goto guy" has become a compliment, rather than an insult.
"My country, right or wrong; if right, to be kept right; and if wrong, to be set right." --Senator Carl Schurz (1872)
That is beautiful. If you don't use it as a sig (seeing as you don't have one set) then I'll definitely be stealing it to use as mine.
Slashdot: where don knuth is an idiot because he cant grasp the awesome power of php
I think an important side effect of all this pasting a bunch of different libraries/frameworks together is the difficulty of finding a job.
20 years ago if you knew C you probably were qualified for most jobs. Now you have to know several different languages not to mention whichever frameworks de jour are popular at the company you wish to join.
If this trend increases we may get to the point that there will be jobs posted that nobody qualifies for except those who already work at the company.
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.
Open Source(in general not only as FSF puts it) is a really good concept, but it also have promoted using code that you don't quite understand and patching it up until "it works". The equivalent in physics would be blindly joining equations from others until you make a new theory.
Most programmers no longer learn in a way that promotes self sufficiency, they have to use library X but they don't need to know how it works, even thought most of the time the resulting software would be better and with a shorter development phase if they did.
A good programmer knows what he is doing, he does not expect things to magically work out due to a large amount of binary duct tape.
For the last year, I've participated/headed our company's effort in replacing our existing python code hell with a transactional framework (in C++ with services in any language) that provides fault tolerance, easy deployment, secured event collection (because they provide billing info), load balancing, speed and scalability.
It is well documented, has example code and test cases, and it received good feedback from the rest of the devs.
I've starting to push it internally for an open source release since I thought that a framework that focuses on fault tolerance, transactional routing and scalability and other ops-oriented problems would be a good thing for the world.
Ironically enough, one of the main reasons for developing our own framework was that clobbering together ACE + X + Y + whatever would yield a framework hybrid that seemed to messy for us to rely on. We would not know the code base, be (initially) dependent on community provided bug fixes and we would still have to write a ton of glue to get everything off the ground. So after a bit of soul searching regarding Not Invented Here, we decided to strike out on our own.
However, after reading TFA, I realise that I may actually be Satan himself planning to release a new and improved rider of the apocalypse on the world.
Why is this wrong? The company is bogged down by a crappy framework with huge performance issues and unclear API boundaries. Our new framework is 20-1000 times faster, provides a clearly defined API, and is asked for by other dev teams.
Rolling our own framework gave us a single integrated (but not monolithic) codebase where the developer can log, store events, send transactions, do threads, manage signals, access DB backends and read configuration data using one API.
The framework does take ownership of the main loop, and you do need to write plugins for your services. You can, however, register your own descriptors with the poll dispatcher in order to get a callback whenever traffic happens on it. We provide a basic worker thread model, but you are free to launch as many additional threads as you want.
What did I do wrong? Should I be shot?
Back in the 1990's, all the rage was about "software components", what was back then a dream.
Back in the '70s, software components were already achieved, in UNIX pipes and filters. They really WERE as easy to put together as electronic components. Extending the dataflow model to structured data with a nice 2d shell that let you tie your pipes and filters together in ways that the UNIX shell couldn't dream of seemed like the obvious next step. Instead what we have today is LINPACK on steroids. It doesn't matter whether your framework is FORTRAN, COM, or EnterpriseJavaBeansOnHoliday, or whether you spend all your time looking up the parameters of ObscureFunctionThatAlmostDoesWhatYouNeed, or figuring out why ComplexClassYouNeed doesn't support StandardMethodThatEveryOtherClassSupports, or researching the efficient way to do INSERT OR UPDATE in YetANotherNotQuiteSQL, the API always seems to be a huge ugly mess that reminds me of the 47 parameters (or however many it is) you need to specify an open file call in OS/360.
There seems to be a shortage of people who actually know how to design an API. It's like library designers get halfway through Stage 2 and go "Man, this is boring... oh well, I've implemented everything I need, let's release it and call it done".
Finished your "Christian AI" yet? why don't you go work on that?
Abstraction Physics clearly shows that programming is a recursive process of creating and using abstractions.
There is no issue with reuse but only a need to better generate code that is more appropriate for the application under development rather than from some other intended works.
I'm working at a company that has a few very solid products that need to be updated. I'm throughly enjoying recreating these products with modern tools. The pathetic old micro-controllers that don't have on-board emulators, serial drivers, and interface logic are replaced by chips that are simple to use and way faster. I've started a controller project using the Open Embedded framework to provide the base. I've been able to cross off every standard feature as working in just a week and I am spending my time on just the applications and drivers unique to my companies' project. In a week I already have more functionality than the original programmers provided after three years of work. And for all the "but when I wrote everything I knew how everything worked complaint," is it really that hard to read a few howto's about someone else' project. I've written my own TCP/IP stack, I don't need to do it again, nor do I need to use the version I wrote for a company years ago. I've written a bunch of Ethernet drivers, writing even one again will bore me to death. True there was a sense of satisfaction to knowing that everything in a software product was the work of your own. But, who cares, been there done that in college or before should satisfy that craving. As bitbake chugged along for eight hours putting over 4,000 packages into my product, I couldn't care less that I wasn't even going to bother to read the names of the packages much less write them.
Do you mean the cretans that pass for programmers ...
What do you have against people from Crete?
... I'll leave peacefully.
Okay, okay
The higher the technology, the sharper that two-edged sword.
Even if that was true(and it isn't) there is plenty of people that don't know how to use a bow and an arrow.
Now programming is more about assembling all the previously developed tools to produce a useful result
How does it go? "If builders built buildings the way programmer write programs, the first woodpecker to come along would knock down civilization."
More than a little truth in that remark. The further we get away from understanding our tools, the more likely we are to use them improperly.
The higher the technology, the sharper that two-edged sword.
... and not a professional programmer.
Here's a little story:
Once upon a time, there were 5 friends. Each was in the cart making business. Each manufactured every part of his cart from scratch, because that's the way REAL cart makers made their carts back then. Their carts consisted of wheels, an axle, the body of the cart, the traces, and a yoke. Each of these friends happened to make one component of their carts better than the rest, and at least one part very poorly. Making a cart is a time consuming process, so one of the friends decided that he would purchase his worst part, the wheels, from his friend who made wheels the best. His friend thought that it was wierd that his friend would only want to purchase wheels from him, but because cartmaking is a tedious, low-pay job, he obliged. He could use the extra money.
This worked great. His carts were now that much better because he no longer had the weakness of the wheels to worry about. AND he got his job done faster since he only had to purchase them. So he then decided to approach his friend who made the best axles. While they didn't fit the wheels exactly, they were a good enough fit with a bit of tinkering. And so he went to each friend, purchasing a bit of a cart until he didn't actually have to build any of the parts himself, he only had to get them to work together.
People came to him because he built superior carts made with the best products, but he wasn't actually working all that hard because other people were making the parts for him. Soon, the demand for his carts was so great that his friends quit making carts altogether and simply made their cart parts for him. They were losing business to his superior carts anyway, and were making parts and subsequently, money much faster than if they were making entire carts by hand.
And they all lived happily everafter. Until that bastard Ford came along and wiped them all out.
But its called Flash. Check it out. I know, huh? You think I'm crazy. I think I'm crazy. But its not your grandfathers Flash anymore.
Use Qt/ Win32/ Perl/ VB/ GCC - well just about anything You are using libraries written by someone else. For Perl it is called CPAN and is an advertised strength. The only person who arguably does not use a third party library is someone who programs FGPA arrays without a macro assembler. Engineers do not make their own screws and screwdrivers anymore, and whilst it may well be interesting to do so, the industrial revolution tells us that there are better things to do with our time. The points made on trying to make integration easier are useful.
It's not fun because it's a job. If it was supposed to be fun, you'd be paying your boss to do it, rather than the other way around.
...Java.
Sorry, but the whole programming experience started to go downhill when the enterprise and corporates bought into the whole Java way of life, and the Java ecosystem.
Let me describe three development teams in the investment bank where I work:
Team A uses Perl, Python and Ruby - their apps get released regularly, mostly work well, are serviced by a smaller team, and the users overall are happy.
Team B uses C/++ across Windows and Unix - their apps have slightly longer release windows, work very well, have a similiar sized team, and the users remain happy.
Team C uses Java - their apps always seen to have broken releases (wrong version of that JAR?), require a larger team, and the users are not too happy.
Having sat in on the code reviews, development and architecture reviews with the three teams, it was very interesting:
Team A uses at most one framework, and a few libs per project. Code is easy to read, production restarts are quick, and the overall designs simple, clean and well thought out.
Team B uses QT, Boost and a few in house libs per project. Code again is well laid out, production layout well maintained, and there is very little cruft in there.
Team C uses J2EE, Weblogic, Hibernate, Hessian, Spring (and a thousand other bits), the meetings are a disaster, each piece of code seems to have a prerequisite three minimum design patterns squeezed in, littered with annotations, and is quite a nightmare to follow. Production management of their apps is a disaster. Architecture seems to be standard Java J2EE practise of a thousand three letter acronyms, and lots and lots of frameworks.
Sadly, I do have to work with all three teams, and it seems as the IT organisation has a permanent hard-on for everything Java (as the offshore outsourcers promise a thousand coders at bottom dollar rates), guess which way we are going.
If you love programming, avoid Java.
If you were allowed to just take the already invented wheel, that'd be great. Unfortunately, you're building a motorcycle and all you have for a framework is a VW with the wheels fused on. You can make something vaguely motorcycle like if you cut it down the middle and add counterweights so it doesn't fall over, but it weighs 5 times more, will kill the rider if he tries to exceed 20 MPH, has a turning radius larger than a log truck and looks like crap. Yes, it is a two wheeled vehicle with a motor, but actually claiming you built a motorcycle is a bit of a stretch. But thank the gods you didn't re-invent the wheel!
I've had a lot of fun in the past year precisely because I have had to implement some of the common lower-level facilities myself.
Some examples:
1: I failed to find a super-ultra lightweight library for navigating XML and extracting its data, so I wrote my own. Now I have XML processing with the small memory footprint I need for my embedded applications.
2: I failed to find a very-low-overhead state-machine framework with modern conveniences, so I wrote my own. I can now write state-machines in a framework with OO-inspired features (such as inheritance of event handlers, and "ctor/dtor" events (automatically-fired enter-state/exit-state events)) that has a very small memory footprint necessary for embedded applications.
I code in C++ 10 hours a day. So I don't know what you're talking about.
I found XUL poorly thought out and designed to build browsers more so than CRUD apps. It appeared the designers of XUL don't understand the needs of CRUD apps. I didn't see things that suggested industry experience and scars from time in the trenches.
Table-ized A.I.
FTW dude.. FTW.
Why won't /. give me modpoints anymore?
http://www.masturbateforpeace.com/
We are all standing on the shoulders of giants walking steadily up the ladder of greater abstraction.
If you can read this... 01110101 01110010 00100000 01100001 00100000 01100111 01100101 01100101 01101011
Amusingly, you could make the same point about Shakespeare. And you'd be just as wrong.
Crumb's Corollary: Never bring a knife to a bun fight.
Cablevision is a bunch of Nazi fascist. FiOS and the like isn't even an option in my area and they know this so if I can and threaten they pretty much just laugh in my face. Cablevision is my ONLY option unless I want something really horrible.
James Dolan should be deported from the US for being an fucking asshole. The Knicks would probably actually become a winning franchise again. How embarrassing was the Knicks losing to the Nets last night. The Nets were 6-55 before beating the Knicks.
Good job Dolan!
It is not about real or unreal programmers. It is about systems versus application programmers. I am a systems programmer, and I write BIOSs, bootloaders, operating systems, and libraries. Because that is what interests me. I am not interested in financial applications, or I would be writing in Cobol at some bank. The breadth of skills required to be a functional systems programmers was more interesting to me and some others. There is more to programming than popping up a dialog box and responding to some buttons. I think I am a real programmer. I don't do BASIC.
... in every new language's press release of "ease of code-reuse", but it's actually quite hard to do and requires thought.
Perhaps if someone ever ACTUALLY comes through on that decades-old promise with real modules that work properly when re-used, we'll stop seeing thousands of buffer-overflow retarded bugs in code every year and software security "experts" (who rarely actually FIX the software, just find the holes in it -- which isn't getting to the root-cause problem, but there's good money in prolonging the solution) will have less to do.
+++OK ATH
Something reminds me of Idiocracy, where whenever the powers that be couldn't make sense or use of something, instead of deferring to it, they just called it 'Faggy' and ignored it.
...
The problem is not that large amount of software can be developed, and is developed using large amount of pre-existing code. It's not even that large amount of software is excruciatingly boring to develop because the easiest -- and right -- way to do it is to use large libraries and write a very small amount of original code to implement the functionality expected from new software.
The problem is, software is being developed by incompetent people in incompetent manner, and incompetent people use libraries, frameworks, protocols and programming ideologies as crutches, to develop seemingly working software despite their incompetence. Those people hunt for libraries, protocols and code to cut and paste, so they can implement their software despite having no idea how it is supposed to work. It does not matter if code they use is poorly suited for their purposes. It does not matter if it's pre-alpha quality code going into a safety-critical project. It does not matter if those programmers' assumptions are wrong, and they use libraries in unsafe way, produce countless buffer overflows in supposedly not-buffer-overflow-capable language and create massive mess with allocated and unallocated memory. It doesn't matter that they fundamentally misunderstand data formats and protocol they are using, so their software stops working the moment it leaves the environment it was developed in -- often the developer's desktop. The users and management expect those things to happen, and let those programmers continue for months in their perma-debugging cycle until everything is shoehorned into whatever seems to work well enough that the customer would pay for it. And the next person who will have to reuse THAT code, or merely interact with it, is given the task to write more new crud to keep old crud from breaking.
The problem is not that people use existing code -- the problem is that stupid, ignorant people who should have never been allowed to write software that will be used by others, use existing code to hide the fact that they are unfit to program. And another related problem is that this is tolerated.
I am a "real programmer". I was a programmer for more than two decades, I studied EE and CS, I had to implement algorithms in C because I was writing programs in C when pre-made implementations did not exist, I had to re-implement them again because I had to make those implementations and they had to be more efficient and generalized, and I had to implement them once more when I had to deal with unusual environments where existing implementations did not work.
I spend most of my time using and adapting other people's work. I develop software for embedded environments that have all kinds of constraints that usually are not taken into account, and most of my effort goes into taking an established piece of software, making it work there, and building on it. I can reimplement it from scratch. My implementation would be likely better suited for my particular purpose. It may not be that much of an effort to create such a thing. However others' implementations are being actively developed by many people, and are portable between multiple platforms. And by using those existing libraries and pieces of infrastructure I can keep this portability and benefit from ongoing development when I have to extend my software. So I would rather use and contribute to those projects than creating yet another thing with identical functionality and completely different implementation and interface.
However often a time comes when I look at all available options, and see nothing that I want to reuse. Existing implementations are all made with assumptions that are not and can not be met within a system that I am developing. There are frameworks that I would use otherwise, however they are monolithic, require large amounts of resources, introduce unnecessary complexity, have far-reaching effect on the models and style of development, and for that particular application I only need a trivial piece of their functionality. And then t
Contrary to the popular belief, there indeed is no God.
You have a head start since TeX has been around for decades and have known shortcomings and strong points. Your software would also need to have the same penetration, expandability, etc. to qualify. But at that point you would realize that you are an idiot to go though such lengths to call someone else one.
MacBeth is not currently available as a library you can link into your novel.
All those moments will be lost in time, like tears in rain.
Okay, so what did Einstein bring to the table after the mid forties? What about Bohr? Oppenheimer?
What Knuth delivered was no just a pair of shoulders for computer science to stand on for the next decades, it was a huge scaffolding.
Granted, we're taking it for granted, just like we do with all the other crap that we don't see put to use every day. Like sanitation. Imagine how quickly civilized society would break down, if all sewers, waste treatment and garbage collection just disappeared. That'd give you an idea of just what Knuth has provided for us.
Had his day.
Just doing a fly-by here.
Guess what? The answer is gray. Some problems require the use of "big libraries" and some problems require the use of "minimal surface area" as I call it. Programming has become a game of finding out when to use one approach versus the other. There is no "one size fits all" for any one problem.
However, my approach to the trade/craft? Do the simplest thing that could possibly work. Get a working prototype early and optimize it as needed.
What is so hard about re-inventing the wheel?
It is heart warming to see how some people describe Indians and people in other localities as stupid.
I am sure most people tha claim to be able to "solve problems" would not last a week in th cut throat environment of the outsourcing shop in Mumbai.
But keep dreaming. The market for IT skills is telling you clearly where things are going but you hold to the last stone against the overwhelming current of change like if it was real firm land.
Programing has been difficult because we were in the infancy of the profession, mechanics and other simlar fields have undergone similar transformations, programming is not immune to this trend.