Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Programming Education Open Source Software

Fixing the Pain of Programming 294

Posted by Soulskill from the advil-for-the-dependency-headaches dept.
An anonymous reader writes "Light Table is a Kickstarted, open source IDE that's been trying to integrate real-time feedback into code creation. Part of their process has been figuring out how to improve the practice of programming, from top to bottom. They've put up a post about the troublesome aspects of programming that we've learned to deal with and take for granted, but which need solving if programming is to be made accessible for more people. 'Surprisingly, one of the most common difficulties we have heard from beginners is just running code. Even if we were to hand [a new programmer the whole source code] they would likely still struggle to actually use it. They have to install dependencies, compile code, start servers and open ports. At each step the errors are difficult to diagnose and time-consuming to fix.' But these problems extend to experienced coders, too: 'The simplest question we could ask about our application is "what is the current state." Bizarrely, very few programming environments give you any help on this front. Many programmers get by with nothing but print statements.' It's interesting to see somebody working on these issues, instead of accepting that they're the status quo and just part of the experience of programming."
This discussion has been archived. No new comments can be posted.

Fixing the Pain of Programming More

Fixing the Pain of Programming

Comments Filter:

  • Debuggers (Score:5, Insightful)

    by Anonymous Coward on Sunday May 18, 2014 @07:34AM (#47030797)

    I suppose this is addressed by the old quote "What is the best language for x?"

    "I don't know. Which has the best debugger?"

    • Re: (Score:2, Interesting)

      by stenvar ( 2789879 )

      For an experienced programmer in a statically typed language (like C++), there are three things that catch bugs before you even get to a debugger: the static type checker, runtime assertions, and unit tests. If any one of them triggers, it is usually obvious how to fix stuff even without a debugger.

      Debuggers should be simple, minimal, and reliable, so that the 1-2 times a year that you need them, they get the job done correctly and without having to remember a lot of complicated stuff.

      • Re:Debuggers (Score:5, Funny)

        by UnknownSoldier ( 67820 ) on Sunday May 18, 2014 @02:05PM (#47033101)

        > there are three things that catch bugs before you even get to a debugger:

        Yes, but the "hard" bugs are the ones that happen at run-time. Those depends on the context such as Networking, Rendering, and AI bugs that can be a real PITA to track down.

        Race Conditions, and Deadlock are hairiest ones.

        There has to be a comprehensive list someplace aside from the usual

        * syntax (compile time)
        -- variable mis-spelt
        * logic
        -- classic "fencepost" bug
        * run-time
        -- race conditions
        -- deadlock

        On a half serious note:

        * Bohrbugs: Most of the bugs that we come across are reproducible, and are known as Bohrbugs.
        * Heisenbugs: All experienced programmers have faced situations where the bug that crashed the software just disappears when the software is restarted
        * Mandelbugs: When the cause of the bug is too complex to understand, and the resulting bug appears chaotic,
        * Schroedinbug: Sometimes, you look into the code, and find that it has a bug or a problem that should never have allowed it to work in the first place

        http://www.opensourceforu.com/... [opensourceforu.com]

        • Re:Debuggers (Score:4, Informative)

          by gweihir ( 88907 ) on Sunday May 18, 2014 @04:30PM (#47033899)

          Unfortunately, for Race Conditions and for Deadlocks, debuggers are mostly useless, as they change the runtime-characteristics. Typically, you end up with "Heisenbugs" that vanish or change dramatically as soon as you run under a debugger. Also if you think finding these by tests, you have already lost. You need to avoid these by design and find them with code-reviews and specialized tools.

      • For an experienced programmer in a statically typed language (like C++), there are three things that catch bugs before you even get to a debugger: the static type checker, runtime assertions, and unit tests. If any one of them triggers, it is usually obvious how to fix stuff even without a debugger.

        Debuggers should be simple, minimal, and reliable, so that the 1-2 times a year that you need them, they get the job done correctly and without having to remember a lot of complicated stuff.

        1-2 times a year? That's certainly not typical for game development, at least in my experience. We're in our debuggers all the time - in fact, it's considered good practice to step through new code you've just written to make sure everything seems to be looking and working as you'd expect it to. With the development we do, there's not always an obvious correct or known solution to the problem you're trying to solve. Or, even if it is a problem with a well-known solution, it can involve writing rather co

        • Re: (Score:3, Insightful)

          by gweihir ( 88907 )

          Game development is different. For example, you cannot easily unit-test things like what is displayed on the screen or whether something runs smooth or not. There are other differences. Anyhow, the discussion is not about being able to use a debugger or even having one. It is about people that need one even for simple things and these people have no business writing code in the first place.

  • Smalltalk live images (Score:4, Interesting)

    by angel'o'sphere ( 80593 ) <angelo.schneider ... e ['oom' in gap]> on Sunday May 18, 2014 @07:37AM (#47030809) Journal

    I simply don't get why not all programming languages/development environments support live images like Smalltalk..

    For those who don't know what that is: in Smalltalk the IDE and the running program are 'the same'. Your 'program' (what you code) never stops and/or is restarted. It just 'freezes' like a laptop and is 'restarted' or awaken at it previous state.

    That means if you send me your 'source code' you are actually sending me a sleeping, but running! program.

    • Re: (Score:3, Interesting)

      by arth1 ( 260657 )

      No program is an island. You can stop programs as an OS function in many operating systems, but resuming is a bit harder, as everything they presumed about the system at runtime may have changed, including displays, disk status, sockets, time zones, connected devices, or anything else.

      It's a bit like freezing you when you dash down a hill to reach the bus, and then unfreeze you in a glass store.

      The only somewhat safe way of saving and resuming a state is if you save and resume an entire OS - like most VMs

      • It's a bit like freezing you when you dash down a hill to reach the bus, and then unfreeze you in a glass store.

        They unfreeze me in the Apple Store? Cool!

    • The Golden Age of Programming (Score:5, Interesting)

      by Latent Heat ( 558884 ) on Sunday May 18, 2014 @08:24AM (#47031007)
      There is this, what should we call it, a mythology of a Golden Age of Programming?

      I don't use mythology in a perjorative sense that this is all pretend or wishful nonsense. I use it in the best Joseph Campbell-Hero-With-Many-Faces sense, of a dim recollection of The Way Stuff Used to Be. This is a way of communicating an Underlying Truth about the Human Condition.

      Apparently there was this era of things such as this Smalltalk that you allude to. Another version of this I hear from tales is Common Lisp. And Lisp Machines, specialized hardware and expensive workstations on which these "live images" would reside. So maybe these tales of direct, personal communication with the gods taking place with the Bronze Age Greek heros was not made up?

      I guess there was this Barbarian Invasion of Bearded Men from the land called "New Jersey", especially a high place among the rolling plains they called "Murray Hill"? There is this piece of non-canonical scripture that our elders have been trying to supress known as the Unix Hater's Handbook explaining how we came to our present age and how this Golden Age entered into myth. Our elders warn against reading this heretical tract as dangerous to our souls.

      As Jerry Pournelle describes the intervening Dark Age between now and that heroic or Golden Age, it isn't so much that people forgot how to develop and maintain a live image programming system such as Smalltalk or Common Lisp, it was that people forgot that such a thing could exist, and we attribute such things to gods or space aliens.

      But then again, just as there is talk of ancient creatures in deep lakes in Scotland or in the remote sections of Zaire or Southeast Asia, there are accounts that Smalltalk or Common Lisp are still in use . . .

      • The favorite part of my career was working in banking. Sounds backwards, as people often view it as so restrictive and stogy. We had development, QA an production environments that only touched through Control updating processes. While the first two were perforce smaller physical systems, all were software clones as far as operating systems and in-house software layout. I was development. I spent many an hour in high-level meetings arguing against my work mates that development had no business touching

        • Re: (Score:2)

          by Kremmy ( 793693 )
          One of the biggest problems in current systems is that devs need unfettered access to get their jobs done.
          You can't put a developer on a locked down system and expect them to get anything done. People who work with development of software can't have their operating environment actively working against them. If the world had stuck more to UNIX norms, we'd probably be in a far more palatable situation with systems that are actually designed to allow multiple people to get work done using the same hardware wi
      • You jest, but if this guy had actually looked at history, he might have learned something. So far the project is just another in a long line of projects that failed to bring programming to the masses. Applescript, COBOL, BASIC, Visual basic, hypercard.....the list goes on. Maybe they will succeed where the rest failed, who knows?

        For my money, the best way to introduce someone to the concepts of programming is LOGO. Give an 8 year old a keyboard and a turtle and within an hour she's programming.

        • The summary probably gives the wrong impression. The lighttable project is about improving the practice of programming for all programmers not just beginners. And he's probably better read in the history of such things than you are.

    • Mod parent up. Not sure if this New Yorker cartoon from the most recent issue will stay around long, but I saw it this morning and it sums up how I feel about much of computer software development the last thirty years since Smalltalk:
      http://www.newyorker.com/image... [newyorker.com]

      A character says "The new house is almost ready!" and it looks exactly the same as the rundown house in almost exactly the same location.

      Software could be better, like the character could in theory have built a better house. But in practice, wa

    • That means if you send me your 'source code' you are actually sending me a sleeping, but running! program.

      With all my data in it? What could possibly go wrong!

  • TFS says:

    Part of their process has been figuring out how to improve the practice of programming, from top to bottom.

    The problem here is that depending on top to bottom only works well on very small scale and very large scale. In reality, you need both top to bottom, bottom to top, side to side, diagonal, and too often even a bit of pogostick programming.

  • The pain is good (Score:2, Insightful)

    by CmdrEdem ( 2229572 )

    When you spend 8 hours troubleshooting an open-source project to compile with a third party proprietary library it feels damn good to make it work. Coding is good because it's hard. The higher the stakes the more the accomplishment of that task will make me proud/happy.

    Sure... there are some places where things should be simple. When I install an IDE I expect it to compile a hello world just after typing the proper code.

    • > The higher the stakes the more the accomplishment of that task will make me proud/happy.

      While true, this has little to do with the time wasted learning the basic layout of the build tools and auto-configuration tools. The time wasted constantly retweaking and hand-compiling individual components as source code is updated is just that for most programmers: time wasted.

    • I would like to spend more of my time creating new things rather than fighting to make existing things work together.

    • Re:The pain is good (Score:5, Insightful)

      by pla ( 258480 ) on Sunday May 18, 2014 @10:47AM (#47031901) Journal
      When you spend 8 hours troubleshooting an open-source project to compile with a third party proprietary library it feels damn good to make it work. Coding is good because it's hard. The higher the stakes the more the accomplishment of that task will make me proud/happy.

      Sorry, but no. If I have a known-working source tree that I want to work with just to tweak one tiny nuisance, I want to download it, open the project, make the change, then build/test/deploy.

      In gaming, you have the concept of artificial vs natural hardness. When the game makes you do things just right with cheap tricks like an almost unavoidable trap right before boss / end of the level, when it requires pixel-perfect jumps, when it has insanely complex or tedious puzzles to solve, when it has time limits that require you to essentially memorize which buttons to mash and when, when it doesn't allow saves except at completely useless spots, the devs have made it artificially hard because they failed to make it challenging through more natural means.

      In coding, we have the same problem, except we don't (usually) do it to ourselves intentionally - And you describe the most egregious example of it, configuring dependencies. I love a good challenge in writing actual code. Optimizing a tight loop cycle by cycle, importing useful numbers from a BOL file that everyone else has given up on, implementing a new (to me) algorithm in language X (I had a great time learning SQL for that reason, because most of my stock tricks from the C world don't translate well). Those all leave me feeling deeply satisfied at the end of the day. When, however, I can't even get the damned thing to build because I have to tweak 17 obscure dependencies:

      "Oh yeah, it doesn't work with the newest 2.17.99 release of WidgetBlaster, you need to hunt down 2.17.94"
      "Oh, you used the default build parameters for WidgetBlaster? Heh, you have to pass it the undocumented NoFleem flag at compile time"
      "Yeah, NoFleem doesn't actually have any effect unless you install the not-obviously-required WidgetFleem library first"
      "Well, you can't actually do it in one pass, since WidgetFleem has a circular dependency on WidgetBlaster - So build WidgetBlaster without NoFleem, then build WidgetFleem, then rebuild WidgetBlaster with the NoFleem option".
      "Oh yeah, it only works in GCC 4.4.x, they changed the optimizer after that one and it breaks WidgetFleem."
      "Did I mention you need to cross-compile it from an OS X machine because a critical buildtool doesn't exist on Windows?"

      Shit like that drives me up the wall, I have zero patience for - or enjoyment of - trying to work around someone else's quirky build environment. If your code depends on obscure external packages, include them in your source tree, and include building them in your default project/makefile, period. I don't care if it makes your source tree 2.5GB, because I'll need to download them all anyway, and at least you know the right versions to include.

      • I understand and agree with all objective stuff you say. I never meant that everyone should enjoy the kind of troubleshooting I enjoy. There are some cases where I really get pissed off. But when I set myself to, for instance, compile source code from a third party developer I'm accepting and expecting trouble, with little to no support from the original party, and I get proud of myself when I figure it out. That is true for me at least.

        • Re: (Score:2)

          by pla ( 258480 )
          Fair enough - I suppose if you enjoy that, hey, whatever you like doing, you like doing!

          Me, I love getting down as close to the CPU as I can and making it beg for mercy. But I suppose I can appreciate, if not personally enjoy, what you describe.

          We might work well together. :)

      • Actually i once had a similar circular dependency where you had to recompile one part of the software with a different -D switch on the compilers command line.

    • When you spend 8 hours troubleshooting an open-source project to compile with a third party proprietary library it feels damn good to make it work. Coding is good because it's hard.

      Golf is hard.

      But golf doesn't pretend to be anything other than a game which is defined by the wholly artificial --- and unnecessary --- obstructions it places in your path,

  • Just suck it up. If it was easy then everyone would do it. ( actually it is easy, people are just whiny lazy asses these days and want everything to be done for them, and presented on a silver platter, paid for by someone else via some 'wealth distribution plan' )

    • Programming may be easy per se. Programming well is not.

    • Re: (Score:2)

      by gweihir ( 88907 )

      Nonsense. Laziness has nothing to do with it. It requires real and specific talents. If these are not there, forget it. Just the same as you cannot turn everybody (or even a significant minority) into competent, say, violinists or mathematicians, so you cannot turn most people into competent programmers.

    • actually it is easy, people are just whiny lazy asses these days and want everything to be done for them, and presented on a silver platter, paid for by someone else via some 'wealth distribution plan'

      What do the sins of the owning class have to do with programming?

    • Given that the Slashdot's general sentiment is that users should use open source because they can just fix it themselves, a response berating folks who want to be able to make changes easily is pretty lame. Not that I'm accusing the Open Source religion of being fully of cranks and charlatans, but come on!

  • Difficulty Spectrum (Score:5, Insightful)

    by Mr_Blank ( 172031 ) on Sunday May 18, 2014 @08:08AM (#47030927) Journal

    Programming has a spectrum of difficulty. The tools can always be improved to make the easier parts easier and the harder parts more manageable, but in the end the hard parts are hard because of the nature of the work; not due to lack of tools.

    In more mature fields the spectrum of difficulty is well understood and no one expects the hard parts to be easy. If a person can write a "hello world" program then it should not be expected they will have the wherewithal to roll out healthcare.gov. If a person can apply a bandage to a skinned knee then it should not be expected they will have the wherewithal to do brain surgery; regardless of how good the tools are.

    • Re: (Score:2)

      by gweihir ( 88907 )

      Well said. But apparently, most people still do not get that programming is hard and therefore not for everybody. They seem to think it is somehow like doing a simple administrative desk job.

    • Re: (Score:2)

      by fermion ( 181285 )
      A lot of this has to do with following instructions and the availability of expertise. When I was very young i had no problems running basic programs on the teletype. When I learned FORTRAN, yes the error messages were cryptic, but after a semester I could get it running. I could not manually link now to save my life, but back then it was no big deal to hook into the IMSL library. By the time I got to college, i could diagnose almost any common error just by looking at the message. Most of the time, if

  • One of my rules at work is: "If I check it out in Visual Studio and press 'Start', it better compile and run". It's not acceptable to make the next guy figure out how to run a program. Everyone I work with thinks I'm overreacting at first, but when they go to fix an issue in four-year-old code they've never seen before, they suddenly get it. Bonus points for starting the test suite by default instead of the actual program.

    • Re: (Score:2)

      by iONiUM ( 530420 )

      I'm surprised this isn't the norm already? What kind of shitty environments/code are people working with?

      At all the companies I've worked at (all Visual Studio), if you got source from TFS, it was guaranteed just pressing 'start' would compile and run it, regardless of whether it was WinForms, ASP.NET, Silverlight, etc. That's just expected, and if I ever started a job and the code didn't just run, I'd assume people there didn't know what they were doing.

  • I realize this is a tangent to what the post is talking about. However there is a related feedback that's a big problem for me. Getting feedback from "user". So at least in my company it often turns out one manager is a big user of the software. Guess which office door is closed pretty much all day and no answering e-mails of any kind? It's very difficult to give mangers like that what they want when the only time they'll tell you is they pop-up behind you while you're doing something else, give you a 3-5 m

  • Eclipse? (Score:4, Informative)

    by drolli ( 522659 ) on Sunday May 18, 2014 @08:47AM (#47031149) Journal

    I mean, thats the elephant in the room, isnt it. I found that everything thich can be automated easily is automated in eclipse.

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      You are certainly right about eclipse being an elephant.

  • Whenever I see one of these headlines about how there is a supposed shortage of programmers and we should make it easier so "stupid people" will come to save the day, it just makes me think "what the what?" I have an awesome sister. She can't sing. She makes people cover their ears and the dog runs out of the room. Are we going to solve today's broken music scene by making singing easier and coaxing my sister to become a singer? I don't think so. Singing is easy. Doing it well enough that people want

    • We'll skip the false dichotomy and get to the good part:

      "Singing is easy. Doing it well enough that people want to listen is not hard...for people who are good at it. "

      OK, except for the concept of talent development. Yes, there are people who can sing the minute they open their mouths. Those who go straight from the birthday part to a career are the incredibly small minority. Most people who are good at something as adults were not exactly that good to begin with. As good as young Mozart, by the time h

    • A strange example, considering we now have people who aren't exceptional singers but have charisma and looks and are auto-tuned to make them marketable.

  • Often we do this to ourselves. (Score:5, Interesting)

    by w3woody ( 44457 ) on Sunday May 18, 2014 @08:58AM (#47031201) Homepage

    More than once I've seen the existing functionality of an IDE's automatic (or semi-automatic) compile, run and debug loop sabotaged by some (sometimes mandated) third party plugin which is supposed to make things "easier." I've watched as people poorly integrate Java Spring into a project and render it impossible to use Eclipse's debug button because of badly constructed project dependencies. ("Oh, if you want to run the project, just drop into the command-line terminal and type 'ant someobscurebuildproduct run'; it's pretty easy, why are you complaining?") I've seen people integrate Maven into a build process in ways which guarantee the project will stop compiling at some unspecified time in the future by improperly scoping the range of libraries that will be accepted. (And I'm not a fan of Maven or CocoaPods or other external dependency resolution tools anyway, as in part it presumes the external libraries we link against that are hosted outside of our source kits will honor their public interface contracts as minor revisions roll out, something which isn't always true.)

    I've seen refactoring which adds code bloat (rather than simplifies the code). I've seen home-rolled configuration files which make code discovery functions break code discovery functions in Eclipse useless (do you really need to home-roll you own class loader, and specify Java classes in JSON?). I've seen plenty of 'voodoo stick waving' standing in for good coding practices. I've seen the lava flow anti-pattern obscure a simple Java RTL call in 20 discrete layers of classes, each added on by another refactoring that did nothing but make things more obscure.

    I've seen weird blends of ant and makefile build processes which took a product that should have taken perhaps 5 minutes to build take over an hour, and build processes so broken that it was impossible to shoe-horn into an IDE without rewriting the entire project. ("Real programmers use 'vi.'" *shakes head*)

    In fact, I have a working theory about programmers--and that is this: Most programmers think something should be a certain level of difficulty. And when a project turns out to be easier than they think it should be, they add artificial complexity until it reaches the expected level of difficulty. At some point, the project then needs to grow, making things organically more difficult--but the artificial difficulty added by the programmer who thought things were too easy before then simply sabotage the project. This is why quite a few projects I've worked on over the past 25 years have failed.

    This is why I have no hope for any project that attempts to fix the problem. That's because the problem is cultural, not technological. We've had IDEs which had integrated debugging and one-button build + run processes going back to the 1980's--yet somehow we always glom to the next big thing, oh, and sorry about breaking your IDE--but this next big thing is SO important it'll totally compensate for the fact that we broke your edit/run/debug cycle.

    Meaning I guarantee you the moment someone builds a fool-proof IDE which makes it brain-dead simple to edit, compile, run and debug an application, some damned brain-dead fool will come along, worried that things shouldn't be harder, and break the system.

    • (And I'm not a fan of Maven or CocoaPods or other external dependency resolution tools anyway, as in part it presumes the external libraries we link against that are hosted outside of our source kits will honor their public interface contracts as minor revisions roll out, something which isn't always true.)

      That's why you depend on a specific version.

  • of programming environments where the stuff kids use early on has tangible links to the stuff they'll use later on.
    Code is not code is not code. The AP exam alone has been through three languages (Pascal, C++, Java) and their official caveat isn't reassuring.
    I can teach young kids Scratch, Stagecast, NXT all day every day and they love it and learn to solve problems.
    Trouble is there's no bridge between that and "real" programming. The parentheses are mine, but there's no volume knob on the chorus that ru

  • What nonsense (Score:2, Insightful)

    by gweihir ( 88907 )

    Yes, I usually get by with print statements as well, because I do not need anything else! Learning to debug is a critical part of learning how to program. Taking that away is plain harmful. Advanced debuggers give you more, but anybody that cannot debug simpler print-statements does not have the level of understanding of the code that is absolutely required to make it any good.

  • The build system has been by far the worst part of it. There's no one whose job it is, quite often the programmers are in an unfamiliar environment. I do a lot of UNIX work, and most of the devs came from some other environment and are frequently not even familiar with the language we're using, much less the tools the OS provides. On C projects I've seen everything from home-rolled perl or shell scripts to cascades of make that would fail due to missing dependencies several times before building after you resolved them all. Most of the time, the developers on those projects had no idea there was a debugger on the system or that with just a bit of work it would show you where a segfault had occurred.

    So it seems to me that most of the pain of programming is bad programmers who can't be bothered to learn about the tools they're working with or even the hammer that they're using to solve every problem. So why do you think your hammer's going to be better, again?

  • It's right before the sentence that accuses the world of choosing to be illiterate.
  • Making programming more accessible by more people may result in well-functioning programs being as common as well-functioning governments are where voting is more accessible by more people.

  • You're a bunch of over-testosteroned, machismo idiots.

    Offense definitely intended.

    First point. Machines and software exist to serve *people* and for no other reason. To the extent that they do that, they are "good." Anything less is "bad." Simple enough for you?

    Second point. Programming is not about "overcoming intellectual challenges." Don't flatter yourselves. Nobody cares how you feel. Programming is either about money or masturbation. If the latter, make it as hard as you like. Go for it. Wheeeee! Look

    • When people say 'programming should be hard' usually they mean 'programming is irreducibly complex.' There's no way around the fact that programming is hard.

  • I don't see why beginner programmers should be starting with servers or ports. Where are the basic fundamentals of programming before they approach things like servers and ports where one should be thinking about task blocking, threading and security above and beyond the "make it do what it want" level.

  • Logical impossibility (Score:3)

    by Chelloveck ( 14643 ) on Sunday May 18, 2014 @10:47AM (#47031903)

    First, why does programming need to be accessible to more people? That's exactly the opposite direction a mature technology goes. It use to be easy to fix your own car, but now with the modern engine and manufacturing techniques it's damn near impossible for most people to do more than add consumables. It used to be easy to fix electronics, but now it's impossible to take things apart and if you do you find everything is done in literally a black box of a chip and there's nothing you can do to it. These things have good points and bad points and I'm not here to argue for or against them, just to say that mature technology tends towards "no user-serviceable parts inside". Why would you expect programming to be any different?

    Second, the pain in programming doesn't come from the tools. Yeah, it's a pain to learn the tools, but that's a pain that's short-lived. The real pain comes from the nature of programming. It's caused by having to tell the computer in excruciating detail exactly what you want it to do. In order to tell the computer you have to figure it out for yourself, without glossing over any "you know what I mean" steps, because the computer certainly doesn't know what you mean. And not only do you have to tell it how to do the job when everything is working as it should, you have to anticipate all the ways in which things could fail and tell the computer what to do in those cases, too. THAT'S the painful part of programming -- the programming. No tool is going to fix that.

  • The only "pain of programming" I have experienced was always the result of my own poor design choices. Is there an IDE for that?

  • I found it hilarious that the post bemoans the state of getting started with a new environment, and how it invariably requires a tutorial, and that is terrible.... And then you download their software and you're presented with a blank screen and no idea how to get started... so you turn to you guessed it.. a tutorial.

    And then a tutorial that isn't even illustrated, so you can't tell what is supposed to happen with you hit cmd/ctrl+enter... I get a little checkbox next to my line of code.. I don't know what

  • 1. Use a powerful editor that you know well.
    2. Don't use Windows.

    There you go. Done.

  • Switch the functionality of the '.' and ';' characters in C style languages. For me, it's perfectly fine with what '.' and ';' do and mean, but apparently it's a real struggle for those learning programming. While in University I'd be talking with somebody struggling in their Introduction to Computer Programming class, or somebody who was a CS major, and then dropped out and the number 1 complaint was how they were upset with how the program wouldn't compile because they were missing a ';' at the end of a s
  • Here is the best quote in the article:

    GETTING STARTED - First we need to get a development environment running. Let's try clojure: [example]. At this point you have already lost 99% of the population and we haven't even touched on css or templates yet.

    That's how you teach beginners.

  • They looked at this problem before, and came up with Netbeans. They looked at it again and the result was Eclipse. I don't hold out much hope.

    Disclaimer: currently trying to [re]learn java (did a bit when it was 1.1) and I'm wondering if it'd just be better to use gedit or even vi...

  • I always thought programming was fun!

    Maybe if it's painful to you, you should try a different line of work.

  • Why does everyone need to be a programmer? Why does someone imply, programming is a pain?
    Todays tools are okay, and who can't be a programmer, doesn't need to. We do not need to simplify laws, so everyone can be a lawyer, so we do not need to change programming just to have everyone as a programmer.

Slashdot Top Deals

If all the world's economists were laid end to end, we wouldn't reach a conclusion. -- William Baumol

Close