Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Is programming dead?

By japhar81 in Culture
Fri Nov 24, 2000 at 04:09:43 PM EST
Tags: Software (all tags)
Software

I walked into the office this morning at 8am (yes, I'm working today, I know its black friday, I'm still working). Anyway, I stroll in, and find an email from the powers-that-be (my boss's boss's boss) asking for a 3-tier database application to be written by monday. By noon, the app is written, tested, and shipped, which made me wonder, is programming a dead art?


The advent of point-and-click programming was cool. When VB came around, it meant that I could hack together a prototype of an application in a day, and then work off that when writing my C++. Then came along Delphi, yeah, it used pascal, but it compiled as tightly as some C++, and reduced development time. Soon after all that came scripting, the latest fad. It seems more and more that programmers are basically writing api's on top of api's adding layers of simplification. For example:
  1. Someone wrote a C compiler using ASM.
  2. Someone wrote a C++ compiler using C.
  3. Someone wrote the STL using C++.
  4. Someone wrote MFC using STL and C++.
  5. Someone wrote VB using MFC.
  6. Someone wrote a script interpreting email app (an email api in effect) using VB.

Nice progression of simplification. Yesterday, I watched my little cousin (14) write a script for his game to do some AI thing (Don't ask me, I don't get the games he plays).

Now, I realize that someone is always going to be needed to write/improve the underlying tools like VB, but realistically, how many programmers will be needed for that? MFC has gone through god knows how many releases, but its still basically the same codebase, just bug fixes here and there, and some enhancements for new tech, but the MFC team at M$ is what? 5 people? I don't remember exactly, but it's around there. So what I'm wondering is, are we reaching the point where everyone and their grandmother can program a pc to do what they want? I'm not trying to be elitist here, but if that's the case, will we programmers become a dying breed as our skillset is picked up by virtually everyone with a pc? Maybe I've had too much turkey, but, for some reason, I can't help but wonder.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
Are programmers a thing of the past?
o Yes. 1%
o No, they're gods, and they shall remain. 44%
o Not any time soon. 34%
o Possibly. 2%
o At some point. 4%
o Japhar81 is a crackhead. 12%

Votes: 114
Results | Other Polls

Related Links
o Also by japhar81


Display: Sort:
Is programming dead? | 25 comments (25 topical, editorial, 0 hidden)
Evolving, not dying. (4.33 / 9) (#1)
by whatnotever on Fri Nov 24, 2000 at 01:15:13 PM EST

are we reaching the point where everyone and their grandmother can program a pc to do what they want?

You point out, here, that programming certainly isn't dying. Rather, more and more people are doing it. They're just doing it at a higher level. What you really seem to be talking about is the death of low-level programming. I'm reminded of the story about "the Real programmer," but I forget his name so I can't find it. It involves rotating magnetic cores, though...

You're right, we're always building layers of abstraction upon layers of abstraction, to make it easier to use, faster to code. The only danger here is if we forget how the lowest levels work. As long as people still understand how a microprocessor works and other people know the other steps above that, we're fine. But if everyone just learns VB, we're screwed.

If, indeed, humanity atrophies except for the push-button finger, then when the button breaks, no one will know how to fix it.

But programming is not dying. These levels of abstraction allow for larger, grander programs. There are programs that simply could never be written in assembly.

And, back to the original topic, there will always be people pushing the limits of the current levels, creating new levels, or just generally being "elite" in various ways. Perhaps fewer than there are currently, but they won't disappear.



The Story of Mel, a Real Programmer (4.00 / 9) (#4)
by paxtech on Fri Nov 24, 2000 at 01:56:20 PM EST

The story you're referring to can be found here.

Highly recommended reading for anyone who hasn't seen it.

--
Paxtech
"Rarely is the question asked: Is our children learning?" - George W. Bush
--
"Eggs or pot, either one." -- Ignignot
[ Parent ]
No it isn't, you're just in the wrong area (3.66 / 9) (#2)
by Carnage4Life on Fri Nov 24, 2000 at 01:29:17 PM EST

Simply because there is a vast proliferation of programmers making cookie cutter apps in VB does not mean programming is dead by a long shot.

As the number of people claiming to be programmers increases due to the technology boom, the number of people who do real programming (i.e. stuff that needs a CS background) begins to look insignificant mainly because it is small relative to the amount of drag N drop programming being done.

Case in point: The companies that hire real programmers (Microsoft, Oracle, IBM, Sun, etc) are hiring more people than ever before. Compilers, Network libraries, IDEs, interpreters, web browsers, operating systems, databases , distributed applications, games, transaction systems, etc. all require real programming and there are lots of developers out there writing this code.

Simply because you work in an environment where you can't see the people who are creating the architecture that makes your job easier does not mean that programming is a dead art, it simply means lots of real programming has been done to make this particular area easier for developers to work in.

4. Someone wrote MFC using STL and C++.


MFC predates the STL. Although it is likely that some people use the STL in new MFC applications I doubt that any MFC code is written with the STL, that of course explains MFC's proprietary collection classes.



Real Programmers links (3.50 / 4) (#8)
by Pac on Fri Nov 24, 2000 at 03:03:40 PM EST

If you are interested in real programmers, these links may be useful:

Real Programmers Don't Use Pascal

The story of Mel

They are old, but change Fortran for C++ in the first text (and Unix for Linux in the last paragraphs) and there you go. Mel, on the other hand, is timeless. Enjy :)

Evolution doesn't take prisoners


[ Parent ]
Why? (none / 0) (#25)
by a humble lich on Wed Nov 29, 2000 at 08:06:23 PM EST

Why would you want to change FORTRAN to C++. C++ forces you to do all sorts of things that are against everything a Real Programer stands for (like declaring variables). Bah. I can almost except Real Programers who use C (my favorite kind of assembly), but C++ is for Quiche Eaters. The only thing I would add to modernize it is that Real Programers are also known to program on a VAX.

[ Parent ]
No programming is not dead. (3.50 / 6) (#3)
by mpenza on Fri Nov 24, 2000 at 01:47:38 PM EST

I can understand why you may think that, but let me assure you that you are wrong. Personally, I do alot of more low level C/C++ programming developing huge pseudo-realtime control systems with hot-failover capabilities and such. The code must be extremely tight, fast and reliable. (For example, we had to develop new methods of hot-failover because nothing like we needed has been done before. With a single code base without parellel processesing, we can detect a hardware or software failure and switch to a standby process/machine in under 1 second with no interuption detectable to the user 90% of the time).

However, I also receive a number of industry journels, and they have all seemed to stray away from traditional C/C++ programming. Fair or not, I place alot of the blame on the larger companies such as Microsoft, IBM, Oracle, HP, etc... They are so strongly pushing rapidally developed multi-tier, client server form of application for e-business or whatever else is currently hot, and seem to ignore the more traditional programming that still occurs.

To sum it up, I don't see MY skill set as something that will be "picked up by virtually everyone with a pc". How many VB programmers or database developers or 14 year olds write programs that override NT's GINA DLL or develop a new patentable method of hot-failover or must use inline ASM because the code must be faster and tighter?

Remember what you're actually doing (3.66 / 6) (#5)
by dreamfish on Fri Nov 24, 2000 at 02:03:54 PM EST

Programming is a means, not an end (well, certainly from a business point of view). You create software to solve a given problem according to a set of requirements. How it's done, and by whom, is effectively immaterial. Your boss got the software he wanted so you achieved your aim.

I always wondered about people who are naturally suspicious of IDEs believing that command-line programming is 'real' programming. APIs and frameworks, like STL, allow us to concentrate on creating the solution so we don't have to waste time re-inventing the wheel by messing about with low-level protocols or writing new wrappers.

Let's all abandon the idea that if it takes you a long time hacking at lower levels the result is better (and the process is more 'pure') because it's harder.

APIs != IDEs (none / 0) (#23)
by Simon Kinahan on Tue Nov 28, 2000 at 06:42:43 AM EST

I agree 100% about the importance of high level frameworks to support application development. The Java class libraries, for instance, save amazing amounts of time that would have to be spent rewriting stuff from scratch in vanilla C++.

However, this is nothing to do with IDEs. Most existing IDEs I've see do more harm than good. Graphical debuggers and so on are useful, but code generation via wizards and drag-and-drop GUI construction can unleash software-engineering nightmares if the auto-generated code needs to be made to do anything the IDE developer did not anticipate. I'm all for raising the level of programming (I'm a big Smalltalk fan), but easing the writing of code at the expense of its readability and maintenance is definitely shooting yourself in the foot.

Simon

If you disagree, post, don't moderate
[ Parent ]
Not dying, diversifying. (3.33 / 6) (#6)
by simmons75 on Fri Nov 24, 2000 at 02:36:35 PM EST

You seem to define "programming" as the art of writing low-level code to get something done. I think that the current state demonstrates the power of division of labor.

Not everyone should have to do everything themselves. I throw neat little things together with Perl once in a while to accomplish some specific task, sometimes bash script, etc. Tell me, what would you rather do:

type a couple of lines of shellcode to change the names of files or

write a program in asm that changes file names by implementing its own calles to your hd controller, implements its own fs code, etc ad nauseum

I'll take bash, please. And frankly, I think that's how it should be. Why should "real programmers" be tied up doing things like putting together a custom DB app? Or anything that could be done in a scripting and/or specialized language? This is a *good* thing. =)
poot!
So there.

The decline and fall of computer programming? (4.28 / 7) (#7)
by Pac on Fri Nov 24, 2000 at 02:50:19 PM EST

Computer programming will never die. From Lego Mindstorms to shuttle controls systems, we will be forever tinkering and playing with complexity.

The example upon which this post was build is biased. Clicking a few clicks to put up a small database application is not really programming. In this case, most real programming was done before, by the people who build the IDE and the components, the people who deloped the RDBMS and the people who projected the particular database in use.

Is the development of environments that can almost program for you a bad thing? Hardly. It makes room for the development of ever more complex programs, dealing with more and more aspects of reality. Here you will always need programmers.

Remember also Moore's law. Software has yet to reach the capacity of five years ago computers. And the hardware has not stopped there. With more, better hardware you need more better systems. And you can do all the old things, but more of them (which is not the same thing after you gain a magnitude or two in any dimension). So, more and more programmers will be needed to cope with it, not less.

Another consequence of this ideas is that the user enviroment gets more and more complex but the user expects it to be more and more easier to use. So even the existence of easy-to-use programming tools does not let us conclude that the average user will be able to make sense of them.

Finally, I can't help but wonder how well documented was this 3 hour effort you described. Not that it would be a problem to have one or two small undocumented apps running around the place. But how will you make sense of an enterprise with a thousand small undocumented apps, some even doing core enterprise jobs?

PS:
One clarification:
"Someone wrote MFC using STL and C++."

MFC does not use STL. As a matter of fact, MFC pre-dates STL. MFC uses only C++ standard library plus Windows main libraries.

Evolution doesn't take prisoners


If it ain't broke... (2.66 / 3) (#10)
by whatnotever on Fri Nov 24, 2000 at 05:52:38 PM EST

"With more, better hardware you need more better systems."

Why? I don't believe there is a direct cause/effect relationship there. Need is not based on ability.

Someone's .sig around here says something to the effect of "Software designers are so infatuated with the fact that they can, that they don't stop to think if they should." Okay, so I'm not sure that's *entirely* relevant... :)

[ Parent ]
Only the paranoid survive (2.75 / 4) (#13)
by Pac on Fri Nov 24, 2000 at 11:48:13 PM EST

Life in the edge is both very rewarding and amazingly dangerous. The bullet the will kill you is already loaded. A smiling face hides a hideous menace, a friendly nod has a thousand meanings, nine hundred and nineth nine of them murderous.

The problem of present corporate landscape (or the problem of globalization) is that the competitive edge has mutated into a elusive and mean mistress. Every day, seven days a week, from 0 to 24, you must be awake searching for the next menace to your livehood. Because if you are not, your livehood will be pulled from under your feet by the funny guy from Moscow or by the gorgeous lady from Delhi.

So, the very rules of the game mandate that if one can, (some)one will.

Evolution doesn't take prisoners


[ Parent ]
MFC and STL (1.00 / 3) (#17)
by ucblockhead on Sat Nov 25, 2000 at 10:51:32 AM EST

MFC actually implements a lot of things that STL eventually came along and implemented better. Things like the string class, a list class, etc.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]
to be honest, i couldn't care less (1.33 / 6) (#9)
by monkeyfish on Fri Nov 24, 2000 at 05:35:45 PM EST

i'll be coding for a long, long time. so the future of the industry or the availability of jobs doesn't concern me too much. since my choice is made, why worry?

OT: VB Rant (2.28 / 7) (#11)
by delmoi on Fri Nov 24, 2000 at 05:52:54 PM EST

I recently got hired to do some Java/SOAP (SOAP is an XML based remote Procedure call protocol). Programming for a company. I knew Java and XML so I figured it's be easy. I knew most of the coding going on though was VB and I had done a little VB in the forced into to comp Sci class here at Iowa State.

About a week after I got hired, they canceled the Java project and put me to work on VB.

GOD DOES IT SUCK. The OO stuff in VB is simply not there (No inheritance, what's up with that?). The syntax for exception handling is painful (you use GoTos for god sake). The severe lack of multithreading is pretty annoying to. VB was fun in class when we were writing little 50 line programs but trying to write a real app in it is an exercise pain.

I'd rather code in scheme or something....

Anyway, no programming isn't a dead art, it's just that you're not "really" programming :P After all, someone has to write all those APIs.
--
"'argumentation' is not a word, idiot." -- thelizman
Its not OO (3.00 / 1) (#20)
by ChannelX on Sat Nov 25, 2000 at 11:13:51 PM EST

The OO stuff in VB is simply not there (No inheritance, what's up with that?). The syntax for exception handling is painful (you use GoTos for god sake).

Yes...it isnt there because VB 6 is not OO...it's object-based. As to exception handling it doesn't have that either.

[ Parent ]

A good definition of "object oriented" (2.00 / 1) (#21)
by Xenophon Fenderson, the Carbon(d)ated on Mon Nov 27, 2000 at 09:35:44 AM EST

In "What's in a Name?," Kent Pitman makes the case that the notions of identity and intent to extend are at the core of object-oriented programming, not some check-list of features. But read the paper, not just my poor paraphrasing, as Mr. Pitman always has an interesting point to make.



--
Rev. Dr. Xenophon Fenderson, the Carbon(d)ated, KSC, mhm21x16, and the Patron Saint of All Things Plastic fnord
I'm proud of my Northern Tibetian heritage!
[ Parent ]
Consider the 'important' programs (3.50 / 2) (#12)
by pak21 on Fri Nov 24, 2000 at 06:26:53 PM EST

is programming a dead art?

No (IMHO). As I see it, it's getting easier for non-wizards to be able to create programs - but the real killer apps for any platform (Gnome and friends for Un*x, the Linux/BSD kernels, Office for Windows, whatever else you want to lump in here) are still written by traditional programmers - they're certainly not a quick weekend hack knocked off in somebody's back room.

Also, coming at this question as a theoretical/computational (astro)physicist, I do wish there were more programmers around - you really do see some truly awful code...

Real men are masochists. (4.16 / 6) (#14)
by bitwise on Sat Nov 25, 2000 at 01:54:04 AM EST

Computers were invented to save time.

I use scripting languages a lot these days. Not only do they provide much more seamless dynamic error checking, but they tend to get software released with less bugs. Sure, they run slower than an equivalent C/C++ program would - but that's why we're inventing faster computers.

Apart from complex mathematics (reasearch and game development), the speed usually isn't necessary. Computer time is cheap. Human labour is precious.

Compilers haven't advanced as much as they could have over the last few years. Theoretically, an optimising perl/python compile could reach speeds very close to the equivilent C code, if it was intelligent enough. I think that's were the real onus is on the engineering students these days. We now have the luxury of decently sped computers and a lot of the time, resorting to C code for something that could be done in 5 lines of python is just a waste of time.

Take the C++ STL. Its vectors are a higher level than the C arrays, and yet a sort on them usually takes a lot less time to complete (due to the C++ inlining the compiled sort function). This is an example of clever programming, where we can achieve both the best speed available (bar hand-written ASM), and yet still code more productively.

While it may be fun to constantly reinvent the wheel, it's not productive. I don't think there's any danger the world will lose all its 'real' programmers. There's always those that like to dabble, and there are some applications that require that level of hardware interaction.

But for the most part, today's 'real programmers' are the ones that get things done.




--
eschew obfuscation ;)

factual errors (3.00 / 4) (#15)
by boxed on Sat Nov 25, 2000 at 08:05:46 AM EST

MFC does not use the STL and VB was not made with MFC.

Eh, what? No, it isn't (2.66 / 3) (#16)
by joto on Sat Nov 25, 2000 at 08:19:58 AM EST

Eh, what's your point. The whole idea of programming is to build abstractions. Do you want to make things harder? Well, simply stop doing whatever you do, the hardest way is to do it by hand. Why program?

Building API's on top of each other is what programmers should be doing. It is what good software engineering is all about.

If you would prefer to have that db-app written in assembler without using anything but bare metal (or, if you prefer, directly in opcodes as Mel, the real programmer in jargon.txt would do), then be my guest. I wouldn't be impressed by your efforts, only dumbfounded.

I'm not familiar with VB and such, but if a three-tier database for your company was designed, built, tested, documented and shipped in a weekend as a simple VB hack, I'm duly impressed. I somehow find the claim to good to be true and suspects there will be several reimplementations and bugfixes to go with your boss^3 requirements, but still, I'm impressed by the state of the art.

I would say that based on what you say in your article, programming is extremely healthy. The idea of taking someone else's high-quality code, and using it in your project to make very sophisticated projects easily is the essence of programming.

I don't think we are quite there yet. Maybe we will never be there, but I want everyone to be able to program easily. Yet, let's face it. Programming is still hard. That some things has been made easier is a good thing. Fine, problem solved! Let's face some new frontiers. Hack the world!

"One True Language" (4.55 / 9) (#18)
by ucblockhead on Sat Nov 25, 2000 at 11:19:39 AM EST

It is almost entirely perception, and comes from the all-too-prevalent feeling that there is "One True Language" that everyone should be using. That with the arrival of Java/VB/Whatever, that C++ is dumped into the dustbin of history. The problem is that there is no one true language, and the biggest problem we have today is the use of languages where they aren't appropriate.

I still remember when C++ became big, and when that happened, all of a sudden everyone was supposed to chuck whatever tools they used. And sadly, many did. And many crappy systems were built. The error is that new languages rarely replace old languages. They add to the programmer's toolbox. Java did not "replace" C++, despite what many Java bigots say. It added to the programmer's repetoir.

Your list implies a progression that isn't entirely there. C++ did not replace C. MFC did not replace base API calls. VB did not replace MFC. Today, I write GUI applications using the base Windows C++ API, not MFC, for performance reasons. I've written other apps using MFC, when performance was less important. I've even done VB stuff when performance was even less important than that. None of these things replaced the others. They added to my toolbox.

If you go out and look, you'll find modern apps written in all of the things you list, including C. I know of a very prominent MP3 player that doesn't even use much of the Windows API, preferring to hand code most of the GUI stuff for performance. This doesn't mean everyone should do that, and this doesn't mean that they were silly to do it that way. It is an option. We need lots of options.

All that's changed is that people have created systems that allow others to create software with less programming knowledge than before. But this comes at a cost, and such systems will have limitations both in what sorts of software can be produced and also with what sorts of performance characteristics that software can have. Those limitations will always be there, or at least will be until we get some sort of true AI, for the simple reason that programming is a hard task. So anyway, there will always be the equivalent of today's C using system programmers. They may use other languages, but the job will still be hard. The only thing that is changing is that people are finally getting clues and realizing that systems languages are not good for higher level tasks like database applications. And they are finally starting to build the systems to do that.

Programming isn't "dead". The number of ways to program is broadening.


-----------------------
This is k5. We're all tools - duxup

Abstractions make it easier... (4.14 / 7) (#19)
by daystar on Sat Nov 25, 2000 at 11:24:23 AM EST

.. at BOTH ends ofthe spectrum.

New abstractions in programming make it easier to do the old tasks, but they always make programmers worry that their skills are becoming obsolete. The thing is: every advance make NEW things possible. The old problems that you had to stay up all night and struggle with are now solvable by nitwits, but new abstractions enable you to do things that you had never thought of. They just were not possible.

The best example of this is SQL. SQL was created so that programmers didn't have to construct database queries by hand anymore. Managerial types who want the data can write their OWN damn select statements. But look at the things programmers have accomplished because of sql. Look at the level of complexity Oracle has put into pl/sql! None of that was possible ten years ago.

If you define "programming" as "the specific tasks that programmers spent all of their time on when I was learning it", then yes, programming is dead. I think most of us have a definition more along the lines of "creatively solving problems in the best way possible... using a computer", and THAT isn't gonna go away until the human race runs out of PROBLEMS, at which point we all become game programmers....

Two other points:
1) the example of sql is not unique. I think that you could make a similar case for the STL, expect, perl, emacs, compilers... just about anything that's advanced the "state of the art".

2) I work in a shop where we use an old ISAM database, so any "query" that ANYBODY wants must be coded by hand, in c, at a pretty low level. From that perspective, SQL is the most beautiful thing in the world....

--

--
There is no God, and I am his prophet.

Not Even Close to Being Dead (4.00 / 1) (#22)
by John_Booty on Mon Nov 27, 2000 at 02:15:48 PM EST

That's definitely a good question! On the surface, it's tempting to think that programming might be dead, dying, or at least deprecated. A lot of programming work now involves getting pre-built software components to work with eachother, rather than coding everything from scratch.

Still, you're not going to be able to accomplish anything without skilled programmers. Getting those software components to work together is not as easy as snapping Legos together.

True, we can now accomplish tasks in perhaps 1/5 of the time as we would have in the old days, when we were doing everything from scratch. However, don't you think managers and clients know that?!? Since we can accomplish things 5x as fast, we only get 1/5 of the time to accomplish them in, so it all evens out. We're still being pushed just as hard, and we need to be just as skilled.

I have personally seen several companies go down in flames because they thought that making software was now "easy" and you could just snap together software now with no muss, no fuss.

For example, right now I'm working on a project where I'm coding piece of server software that talks to a number of point-of-sale devices, as well as out company's master database server over the Internet.

It seems like an easy job... I can talk to the point-of-sale devices via their manufacturer's API, and use an off-the-shelf Winsock TCP/IP API to talk to the database server. Minimal programming required. Right? Wrong!

It has still required a ton of work to complete this project. Most software is theoretically simple, but 99% of the work and aggravation lies in the details... dealing with the poorly-documented point-of-sale system's API... developing a fairly advanced polling routine so that the system performs well... developing caching techniques so that the system functions even when the link to the database server is down, etc, etc. Without good programmers on this job, absolutely nothing would have been accomplished.

Sure, programming has changed because of the great reliance on pre-built objects, but it hasn't gotten any easier or less important. Us programmers are just able to work more efficiently, and accomplish more in less time.


_______________________________________________________________
Anime, game, and music reviews at www.bootyproject.org... by fans, for fans.
IA (3.00 / 1) (#24)
by kubalaa on Wed Nov 29, 2000 at 02:30:08 AM EST

I don't see that "programming" in the sense of "giving the computer some commands and seeing what it does" is any more dead now than it was in the days of punchcards; it's just that more information is already inside the computer for your convenience.

Anyways, you're mixing up "code-slinging" with "Information Architecture." Code-slinging isn't programming anyways, and information architecture will NEVER be dead. Before you tell a computer to do something, you have to decide what that something is and why it's doing it to begin with.

Is programming dead? | 25 comments (25 topical, 0 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!