Forgot your password?
typodupeerror
Programming

Whatever Happened To Programming? 623

Posted by kdawson
from the you-had-zeros? dept.
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.
This discussion has been archived. No new comments can be posted.

Whatever Happened To Programming?

Comments Filter:
  • by Anonymous Coward on Saturday March 06, 2010 @11:30PM (#31386474)

    Programming is becoming nothing more than cutting and pasting, especially with languages like java, that provide libraries that do "the hard stuff" and let programmers concentrate on "programming".

    Programmers are now a dime a dozen. I can find 10 people who can cut and paste available on the internet and modify it to do what they want.

    Good programmers on the other hand, are few and far between.

    It seems everyone wants to be a "software engineer", but nobody wants to focus on the "hard stuff", and instead chant "let java/X do it for you".

    • by binarylarry (1338699) on Saturday March 06, 2010 @11:47PM (#31386568)

      That's because programming isn't usually an endurance challenge.

      "Making something that works" is more important than "talking about how hard you made your job for yourself"

    • by EastCoastSurfer (310758) on Sunday March 07, 2010 @12:09AM (#31386686)

      It seems everyone wants to be a "software engineer", but nobody wants to focus on the "hard stuff", and instead chant "let java/X do it for you".

      I guess it depends on the goal of the programmer/engineer. If my goal is the solve a problem for a customer (as opposed to doing something to simply learn it) then I'm going to do that in the most efficient way possible. Should I be writing an entire stack of libraries every time I need to solve a problem? I hope not. Libraries that already exist make it possible to focus on and build solutions to even harder problems.

      BTW, I think there is a lot of skill needed to be able to look at problem, figure out what libraries can/can not help and then pull it all together into a cohesive solution.

      • Re: (Score:3, Insightful)

        by benjamindees (441808)

        If my goal is the solve a problem for a customer then I'm going to do that in the most efficient way possible.

        I realize you're just tooting your own horn, but you're living in fantasy land if you think this is how it actually works, or even should work. The customer might not even want the "most efficient" thing. They might want an over-engineered thing. They might want the safest thing. They might want the most environmentally responsible thing. They might want the most flexible thing or the most interoperable thing. They might want the thing that works with whatever broken systems they already have. They m

        • Re: (Score:3, Insightful)

          by j_kenpo (571930)

          I have to agree with parent. I've written an implementation of every method I use from libraries such as STL or Java at least once in my life, sometimes in such painful languages as assembly. I did it just for the sheer joy of it (yes, I love programming that much) and as a learning experience. In all those years, I learned a very important lesson, don't reinvent the wheel. I have yet to receive a set of requirements from a client that say "give me the least efficient/over engineered way to do X" that would

          • by bertok (226922) on Sunday March 07, 2010 @08:33AM (#31388930)

            I have to agree with parent. I've written an implementation of every method I use from libraries such as STL or Java at least once in my life, sometimes in such painful languages as assembly. I did it just for the sheer joy of it (yes, I love programming that much) and as a learning experience. In all those years, I learned a very important lesson, don't reinvent the wheel. I have yet to receive a set of requirements from a client that say "give me the least efficient/over engineered way to do X" that would compel me to ever again need to re-write a quick sort algorithm, container implementation, or string parser.

            I've come with a rule of thumb I tell younger programmers:

            Do it yourself, then throw it away and use the standard library instead.

            The idea is that if you haven't implemented an algorithm or something yourself at least once, you don't really understand it. Once you've gained that understanding however, you're better off using the polished and bug-fixed version everyone else is using.

        • Re: (Score:3, Insightful)

          by profplump (309017)

          You're making two assumptions here to make the grandparent seem wrong; he's only wrong if your unstated assumptions hold.

          1) That "solve a problem for a customer" does not already consider all of a customer's requirements, including safety, over-engineering, environmental responsibility, flexibility, interoperability, or scalability. To the contrary, I'd suggest that all of those consideration are part of "the problem".

          2) You're assuming that "most efficient" means "least amount of coding time". I'd argue th

          • Re: (Score:3, Insightful)

            by benjamindees (441808)

            First of all, just taking safety for instance, it's nearly impossible to determine how to solve a safety problem in the "most efficient" way possible. What's the "most efficient" way to build a safe nuclear reactor? Make one that is 100% melt-down proof? You waste nuclear fuel. Make one that is completely incapable of being repurposed for nuclear weapons? You increase cost beyond market feasibility. Don't build nuclear power plants at all? People die from lack of energy. What's the "most efficient"

    • Re: (Score:3, Informative)

      by crazycheetah (1416001)

      I wouldn't separate that too much. Some of us exist that can do the "hard stuff" and might even find and fix a bug in some of the libraries from time to time. However, when we're just making an app that works and fits in with the environment, a lot of the "hard stuff" has been done and is likely to be less buggy and more consistent with the environment than redoing the whole thing ourselves. Then, if it's open source, we can just fix bugs we find in the "hard stuff" and focus more on what we're actually doi

    • Programming is becoming nothing more than cutting and pasting, especially with languages like java, that provide libraries that do "the hard stuff" and let programmers concentrate on "programming".

      I really need to worry about opening and closing JDBC connections, parsing SOAP calls by hand or writing socket listeners. Sure its interesting, the first 4 or 5 times you do it. But I have better things to do with my time that rewriting the wheel for every fucking application. That shit is already there; learn to fucking us it.

      And sure this crap boils down to pushing tokens between multiple apps, and CRUD database apps. The banging out of code is rarely the tough part.

      The tough part squeezing the requirem

    • by Weaselmancer (533834) on Sunday March 07, 2010 @01:57AM (#31387206)

      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.

      • by CptPicard (680154) on Sunday March 07, 2010 @07:49AM (#31388632)

        Not every programmer you're going to run into is going to be a brilliant assembly level kernel hacker. Some of them (these days anyway) are going to be mediocre.

        I would have to disagree with the notion that a programmer is either brilliant by being an "assembly-level kernel hacker" or then he is mediocre and "just uses library calls". This is the kind of weird dichotomy I tend to see from the most arrogant-ignorant low-level guys who probably don't have much of a theoretical CS background, or something. Software does not work on a continuum from hardware level to stupid cut and paste code monkeys.

        The most brilliant programmers I know are the ones who have a loads of insight into the working and structure of software in general, regardless of language and/or proximity to hardware. It is all about identifying the problem solution and then making use of some formalism to describe that solution in computable terms. IMO good Lispers are hard to beat in this regard...

    • Re: (Score:3, Insightful)

      by Eudial (590661)

      Programmers who primarily do java are in most cases the quintessential deadbeat programmer. They're cheap labor; but as with most cheap labor, you get what you pay for. In this case, a bunch of cargo cult [wikipedia.org] code pieced together from examples in the javadocs and from java blogs.

      The thing about Java is that it allows anyone to write bad, but functioning code. It's possible to write good Java code as well, but it's exceptionally rare to see, as the training wheels that allow people to get bad code to work frustr

  • by thenextstevejobs (1586847) on Saturday March 06, 2010 @11:31PM (#31386478)
    Go ahead. It won't bite. Some things are over-engineered.
  • Frameworks (Score:3, Informative)

    by Nerdfest (867930) on Saturday March 06, 2010 @11:31PM (#31386480)
    There's still lots of interesting programming going on, and lots of interesting new languages. The ''Magic Incantations' are the same frameworks you used to have to write yourself, and even then you generally only did it once. It's gotten a lot easier to share the common solutions now, and we're free to do the real work.
    • Re:Frameworks (Score:4, Insightful)

      by jomama717 (779243) * <jomama717@gmail.com> on Sunday March 07, 2010 @12:41AM (#31386820) Journal
      Frameworks, like anything else, are fantastic when used properly but unruly beasts when they are used incorrectly. My current bane is legacy code that is a poorly thought out amalgamation of early version frameworks. I can hear my predecessors squealing with delight and saying things like "Spring and hibernate will magically handle all of my transaction boundaries and multi-threading? Neato!!" as I slog through 3-4 hundred line stacktraces (no joke) trying to debug a race condition. Brutal.
      • Whenever you hear a coworker say something like "$framework will handle that for you", duck and cover. It will end up in a horrible mess.

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

    • Re:Frameworks (Score:5, Insightful)

      by Hurricane78 (562437) <deleted@slashd[ ]org ['ot.' in gap]> on Sunday March 07, 2010 @01:13AM (#31386982)

      I absolutely hate frameworks. They are the same as libraries. But without the ability to plug them into anything. They want to be the core of your application, and not play with anything else.
      They are a very “enterprisey” concept.

      Please, all, stop doing frameworks, cut them into their aspects, and start doing libraries again! Nobody wants you elaborate all-encompassing framework that is its own inner platform and yet unfortunately lacks the very function you need the most.

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

  • Reminds me... (Score:2, Insightful)

    by Anonymous Coward

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

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

  • by theodp (442580) on Saturday March 06, 2010 @11:47PM (#31386560)

    THE DUMBING-DOWN OF PROGRAMMING [salon.com] (1998): "My programming tools were full of wizards. Little dialog boxes waiting for me to click "Next" and "Next" and "Finish."...Dumbing-down is trickling down. Not content with infantilizing the end user, the purveyors of point-and-click seem determined to infantilize the programmer as well."

    • by Tablizer (95088) on Sunday March 07, 2010 @12:09AM (#31386684) Journal

      It's not so much "dumbing down", but rather becoming a swamp navigator instead of an engineer. You can't just know principles, you have to also know the swamp.

      More time is spent trying to figure out how to use and work around limitations of existing libraries and tools and less about designing such tools from scratch.

      It can be roughly compared to what's going on in the automotive repair industry. You used to see all the parts involved and how they interact. Now a computer controls servos and if things don't work, you have to use Sherlock Holmes-like abilities to figure what's going on in the sealed dark-gray-box provided by Ford or Nissan that controls most of it. It's now about studying the relationship between the controller and the parts rather than "fixing the parts" directly.

      It's a shift away from being The Wright Brothers toward being Sherlock Holmes: doing your best with limited clues by poking and prodding and digging instead of just making it "right". Instead of being a constructor, now we're deconstructors more or less.
         

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

      For reference, see almost every graphical interface for any g

    • by Sycraft-fu (314770) on Sunday March 07, 2010 @01:42AM (#31387140)

      Whining about "infantilizing" the end user? WTF? I get really tired of the elitist attitude that some computer types have that computers should be hard. They seem to think it should be some sort of almost mystical priesthood that you have to work at for many years to be allowed in.

      Bullshit.

      Computers are tools, nothing more. they exist to allow humans to do tasks that we otherwise can't do, or at least can't do easily. As such they should be as easy and accessible for an average person to use. Ideally they would require no training and be usable by even extremely mentally challenged individuals. The more we can simplify them, the better. They should be adapted to work how we want, we should not have to adapt to them.

      Well guess what? Programming is another part of that. Ideally, we'd have computers that could more or less program themselves. People would tell the computer what they wanted it to do in plain English (or other natural language) and it would figure out how to make that happen. Obviously we are a very long way away from this, but the easier we can make it, the better.

      Even as it stands currently, where you do need training/practice to be a good programmer, there's a lot to be said for easy tools to make parts of development quicker and more robust. The user interface would be a good example. If all UI elements have to be coded in C++ and then compiled to see how it works, it is going to take a long time to develop and change. Goes double if others (like artists usability experts) are working on it as well. You write it, compile it, send it to them, they test it, write up problems, send it back, etc.

      Much better to have a simple GUI interface for laying out the GUI. You can make changes much quicker and easier, and see what you are doing to confirm it is what you want. Also, should the design change, a redesign is much faster and easier.

      I really get tired of this idea that computers and programming should be hard, that we don't want it accessible. Bullshit. You should want that in general, because it makes it available to more people, and even for you, because the ease of use can save you time. Yes, it allows for people to write programs that don't understand it. Deal with it. The microwave allows geeks everywhere to easily prepare food without understanding how to do it. Doesn't mean we should demand everyone become a master chef and cook all their food from only elementary ingredients. That will give you tastier food, but there's something to be said for having a meal ready in 5 minutes with 0 effort.

      • Re: (Score:3, Interesting)

        by apoc.famine (621563)
        Part of the issue is that "programming" is no longer what it used to be, yet everyone still uses the term.

        It's the difference between BBS and "Web 2.0". It used to be that geeks only could get a modem and some BBS software running which would allow them to connect to the entire world. Now my grandmother can tweet about the birds at her feeder, and someone in Tajikistan can read about them.

        There is a fundamental split now between "designing and writing code" and "programming applications". You want to "p
  • "Don't even try reinventing the wheel. This is not an assignment. Just use whatever code you can find."
  • Car analogy! (Score:3, Insightful)

    by Anonymous Coward on Saturday March 06, 2010 @11:52PM (#31386602)

    The article states that, no matter how important are things like unit tests, they are fundamentally in a supporting role to programming proper.

    As someone who practices test-driven development and programming-by-contract, I fundamentally disagree. Tests, for me, is what defines the requirements and interfaces. The code itself is just the implementation. From the business logic perspective, HOW a program does something is secondary to WHAT it does.

    Car analogy: imagine a programmer as a truck driver, and the project manager as the one who has his goods shipped. The programmer doesn't care much about what he ships (as long as it's not explosives or something like this) -- he cares about the route he's going to take to deliver those goods as fast and efficient as possible. That's all great. But the project manager doesn't care, nor should he. For him, the goods are the primary value, and the route the truck takes is the supporting value. As long as the goods arrive undamaged and on time, nobody other than the driver cares what route they went through.

    We have a basic conflict of perspectives here. Programmers think it's all about how good their code is internally, and think that the coding is the most important part of the application, arguing that without that, the application obviously wouldn't work. But users and payers for that code do not care about those matters, they see a white-box perspective only. Just like the goods shipper, they care more about the goods than how they are delivered. And if the truck driver gets too bitchy about how and what goods he wants to deliver, it's usually easier to get a new truck driver than change your goods or shipping schedule.

    • by BadAnalogyGuy (945258) <BadAnalogyGuy@gmail.com> on Saturday March 06, 2010 @11:57PM (#31386630)

      Car analogy:...

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

    • Re:Car analogy! (Score:4, Insightful)

      by phantomfive (622387) on Sunday March 07, 2010 @12:49AM (#31386852) Journal
      Unit tests are a tool, a good tool, but only one tool. They have a place where they are useful, and a place where they are worse than useless. People who think they are good for everything are usually the kind of people who only do specific types of code.

      Unit tests are awesome in compilers. It's software that has the exact same output every time, doesn't have a changing spec, and doesn't change very much. They also tend to work nicely for business logic.

      They are horrible for dealing with GUIs. This should be obvious. They are not as good at dealing with systems that have lots of complexity. The reason for this is because the number of tests required to make sure something works can increase exponentially, and of course so does the amount of code you have to write. I also haven't had much luck with them in embedded systems.
  • by syousef (465911) on Saturday March 06, 2010 @11:58PM (#31386636) Journal

    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.

    • by Tablizer (95088) on Sunday March 07, 2010 @12:39AM (#31386812) Journal

      Here's the core of the problem: The web is a horrible platform.

      I agree and I've ranted about this several times on slashdot. Customers and bosses really want desktop-like apps, but existing browsers can only do this if you stretch them far beyond what they were originally made for: eBrochures. It takes 5 different programming and markup languages that break on each new browser version incriment.

      It's time to build a dedicated open-source GUI/CRUD browser[1] that can handle desktop, MDI, data grids, tree controls, and CRUD-like applications with grace. No more bending and kicking the eBrochure paradigm to act like real desktops. JavaScript was not meant to be a systems language and DOM was not meant to be a desktop-like nor CRUD GUI.

      Until people wake up to this harsh reality, web programming will continue to suck. It's like NASA trying to make everything with left-over shuttle parts, resulting in waste, bloat, and dead nauts. Blow up the fucking Shuttle and make a real system!

      [1] Or a powerful plugin.

      • Re: (Score:3, Insightful)

        by gaspyy (514539)

        I know I'm about to get lynched by a mob of angrey slashdotters for saying this, but have you tried Flex? As in that Eclipse-based IDE & (open source) SDK? It's basically flash, but it works.

        I'm not even going to suggest the other piece of technology from Microsoft, that includes the words "silver" and "light"...

      • Re: (Score:3, Informative)

        by tonywestonuk (261622)

        ...its called Java. You may have heard of it! - A Java Webstart program can run on anywhere, with vastly less coding for platform differences than, say, coding a website to run perfectly between different browsers, and has everything you want, right now.

        However, the slashdot crowd (and others of similar ilk) have already condemned, and dismissed the Java GUI for not been quite as fast, or looking exactly like a native app....even though these differences nowadays are very slight. Java has bee

      • Re: (Score:3, Interesting)

        What annoys me is that we have had thin clients for decades: using remotely hosted software has been mature for as long as I can remember. VT100 emulation even works across a modem link. Want a GUI? the X Window system has been around for over a decade as well.

        I like the Lynx browser: it uses external programs for also most everything. Even things like YouTube can work if you hand off the .flv to a video player. Browsers should not be acting as an OS replacements with their own schedulers. IMO, browsers sho

  • Misleading summary. (Score:5, Informative)

    by BitterOak (537666) on Sunday March 07, 2010 @12:06AM (#31386668)
    Warning! Before you read the linked article or its followup too deeply, be aware they are not by Donald Knuth. Instead, the author has a brief quote from Donald Knuth in his first blog, and the other link is a followup story. So, "the author" referenced in the Slashdot summary is NOT Donald Knuth. I made the mistake of reading the followup article first, and then when I read the original, I found a brief quote from Donald Knuth which tipped me off to the fact that the author was not Donald Knuth, and as far as I can tell, Donald Knuth doesn't even know this author.
  • by fatp (1171151) on Sunday March 07, 2010 @12:12AM (#31386702) Journal
    excellent programmers steal excellent code."

    I stole this, and I don't know where it is stolen from!
  • by Sarusa (104047) on Sunday March 07, 2010 @12:27AM (#31386774)

    I've dealt with Chinese and Indian outsourced code before - it's rather interesting. They take fragments of code they find via Google, paste them together, and do the bare minimum of editing to make it compile and say 'okay, we've fulfilled our contract, ship it.' This is what suffices for 'programming'.

    On the other hand, I am still solving interesting problems with real programming at my current company, so I still think it's a lot of fun. The key point is that the programming is part of the /problem solving/. Code pigs have no concept of problem solving, just making the program work (by which they mean compile, or matching the sample screens). Engineers are solving problems, and the program is just a part of that. At my present job they really don't care what language I do things in as long as the job gets done, because solving the problem in the most practical manner is the most important thing. In practice this means I use C for things that actually do require high performance and minimal memory usage (this is still an issue in embedded programming), Python for everything else that I can, and domain specific languages for things like servo controllers or FGPAs.

    The 'pasting not quite compatible libraries together' approach is a Java/COBOL thing of minimizing the damage incompetent consultants can do. I've seen it time and time again - once an Enterprisey Java programmer encounters sufficient complexity, a hormone kicks in and they create a framework to simplify this complexity. It does so, initially, but eventually ends up being 2-10x as complex as the original problem they were trying to simplify. But they see this as a net positive because they have a new acronym to put on their resume.

    So basically, like every single damn post I've seen on here lamenting the state of programming, and repeating every damn comment I've made again and again, it boils down to 'solve problems as efficiently as you can'. Absolute rules, in programming or religion, are for people who are too simple to handle complexity. This is the difference between an engineer and a code pig.

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

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

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

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

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

    Moving on...

    • Re: (Score:3, Insightful)

      by Opportunist (166417)

      The difference is maybe that you actually have to know why and how those theorems work. Because else you could not use them. Not knowing why a certain mathematical rule is applicable means that you cannot apply it, not knowing whether its use would be "legal" from within the mathematical ruleset.

      This is not the case with library functions. All you have to know is what you want to accomplish, you drop that info into the help file, it spits out a function (most of the time not really the best one, but one tha

      • Re: (Score:3, Interesting)

        by bertok (226922)

        The difference is maybe that you actually have to know why and how those theorems work. Because else you could not use them. Not knowing why a certain mathematical rule is applicable means that you cannot apply it, not knowing whether its use would be "legal" from within the mathematical ruleset.

        This is not the case with library functions. All you have to know is what you want to accomplish, you drop that info into the help file, it spits out a function (most of the time not really the best one, but one that will more or less do the trick) and it will also tell you what you have to drop into that function to make the magic happen.

        Now, math has been a while ago for me, but I cannot remember it being THAT easy.

        Except that there's a little issue with that nice theoretical model: leaky abstractions [wikipedia.org].

        If you blindly use functions (actually methods) without an understanding of what they do internally, you will get burned.

        This is why crap code deadlocks. This is why crap code leaks memory. This is why crap code can't run on anything except a specific version of Windows with a specific version of IE.

  • The Issue (Score:2, Insightful)

    by Seraphim_72 (622457)
    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.
  • by DeionXxX (261398) on Sunday March 07, 2010 @01:14AM (#31386986)

    As a Presentation Layer guy I can tell you that I’m seeing a shift of the types of successful developers out there in the field. Those developers that can bounce around between different API’s and syntaxes are the ones that are in demand and those developers that know one technology or platform well aren’t.

    I personally think it’s because of the fragmented nature of our target platforms. Programming for one platform is a luxury most programmers don’t have nowadays. This is why frameworks came to be and are used so heavily. Just abstracting the differences between platforms is enough for most developers to ditch “hand coding” and deal with the integration issues. Look at the popularity of Javascript frameworks like jQuery. Nobody coded in the way jQuery works before jQuery (the whole chaining thing, and anonymous functions), yet now more than 50% of websites (made up number) use jQuery.

    To become a successful developer in the next decade, you must be a generalist. It’s a completely different way of thinking. You have to actively try NOT to learn too much of one platform for fear that it’ll bias you against all the other languages you’ll have to work in. For example, coming from more structured languages, seeing the jQuery chaining and use of anonymous functions would turn off most developers and they’d shy away from using it. However, it’s the best tool for the job currently, and not using it based on it’s weird syntax would be a mistake. Same thing applies to MXML, WPF, LINQ, C#’s var, etc and all sorts of new improvements to languages that people don’t use because they’re “different” and give you “less control”.

  • Docs (Score:5, Interesting)

    by afabbro (33948) on Sunday March 07, 2010 @01:31AM (#31387064) Homepage

    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.

  • by slashbart (316113) on Sunday March 07, 2010 @09:22AM (#31389494) Homepage
    Hello World.

    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.

  • by Prototerm (762512) on Sunday March 07, 2010 @11:25AM (#31390718)

    You know Programming is in trouble when being "the goto guy" has become a compliment, rather than an insult.

  • by DCheesi (150068) on Sunday March 07, 2010 @11:47AM (#31390968) Homepage

    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.

"Consistency requires you to be as ignorant today as you were a year ago." -- Bernard Berenson

Working...