Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Fixing the Pain of Programming

Soulskill posted about 5 months ago | from the advil-for-the-dependency-headaches dept.

Programming 294

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

cancel ×

294 comments

Sorry! There are no comments related to the filter you selected.

Debuggers (5, Insightful)

Anonymous Coward | about 5 months ago | (#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:Debuggers (-1, Flamebait)

gweihir (88907) | about 5 months ago | (#47031525)

People that need debuggers will never be any good. For good programmers, a debugger occasionally safes some time.

Re:Debuggers (1)

Anonymous Coward | about 5 months ago | (#47031557)

Ah... /. trolls. In this site's defense, a statement like "People that need debuggers will never be any good." would not be considered trollbait on most other sites.

That's why I don't really miss this place that much. I just pop in from time to time to see if the air has cleared, but I am usually disappointed.

Re:Debuggers (1)

pla (258480) | about 5 months ago | (#47031649)

People that need debuggers will never be any good. For good programmers, a debugger occasionally safes some time.

This statement, while literally true, requires some qualification.

Knowing how to use a proper debugger can save you days of pain. But you also can't depend on always having the ability to use a good debugger - Simplest case, trying to debug remote code running on a server for which you have deploy-but-not-debug permissions on (this comes up a lot for me, actually).

And in those situations, the ability to track down a bug with nothing more than a set of print/alert statements saying "I got here, X=47" means the difference between "programmer" and "wizard's apprentice" (by which I mean if the IDE's wizard fails you, you end up almost drowning until a real programmer saves you).

Re:Debuggers (1, Insightful)

Anonymous Coward | about 5 months ago | (#47031777)

> the ability to track down a bug with nothing more than a set of print/alert statements saying "I got here, X=47" means the difference between "programmer" and "wizard's apprentice"

Really? Because in my experience it's the "apprentices" that tend to lean far too heavily on printf, which is always taught before debuggers and is much easier to use. They spend hours instrumenting everything only to find a bug that could have been located in a few minutes with breakpoints, watchpoints, and stepping. Then they leave behind them a trail of commented-out printf garbage that pollutes the codebase.

> if the IDE's wizard fails you, you end up almost drowning until a real programmer saves you

Because Real Programmers build houses using only hammers. Nailguns, screwdrivers, shovels, and power tools are for pussies.

Re:Debuggers (1)

am 2k (217885) | about 5 months ago | (#47031785)

Simplest case, trying to debug remote code running on a server for which you have deploy-but-not-debug permissions on (this comes up a lot for me, actually).

For these cases, you should set up a local mirror environment where you are allowed to debug. Of course, if you can't reproduce the problem locally (because of system-interdependencies or a critical database you aren't allowed to copy for testing due to privacy issues), you have a problem...

Re:Debuggers (1)

Desler (1608317) | about 5 months ago | (#47031813)

What a stupid statement. Debuggers, for example, are great reverse engineering tools.

Re:Debuggers (4, Insightful)

InsertCleverUsername (950130) | about 5 months ago | (#47031921)

People that need debuggers will never be any good.

People who work with trivially-simple applications and never have to deal with someone else's legacy mess will never be any good either.

Re:Debuggers (1, Interesting)

stenvar (2789879) | about 5 months ago | (#47031823)

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.

Smalltalk live images (3, Interesting)

angel'o'sphere (80593) | about 5 months ago | (#47030809)

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:Smalltalk live images (1)

Anonymous Coward | about 5 months ago | (#47030867)

bizare and dangerous, a bit like microsoft putting executable code into image files that actually steal data from you and send it to criminals.

Re:Smalltalk live images (0)

Anonymous Coward | about 5 months ago | (#47030961)

You don't say! https://en.wikipedia.org/wiki/Windows_Metafile#Vulnerabilities

Re:Smalltalk live images (2, Interesting)

arth1 (260657) | about 5 months ago | (#47030965)

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 allow you to do. And even that isn't safe - what if you froze in the middle of writing to an external drive, and another system modified the directory structure while offline?

What Smalltalk and similar environments do is giving you a safe playground that can be frozen, but also cannot access anything outside the playground directly, and requests to the playground manager to interface with the outside world are atomic and cannot be frozen.
It's fairly safe, but also far too limited for most programming jobs. You cannot use an etch-a-sketch to paint a house.

Re:Smalltalk live images (1)

Anonymous Coward | about 5 months ago | (#47031307)

Also, it was really easy to hose your image - 99% your own fault, 1% bug related. So you had to constantly keep backups copies every time you wrote more code or made changes objects. Which meant shutting down, copying the file somewhere usually to a separate floppy and restarting.

Smalltalk was really awesome for its time though. It was taught at my university instead of Fortran and Pascal as the main intro language and really help bring home the concept of OOP. Way ahead of its time.

The Golden Age of Programming (5, Interesting)

Latent Heat (558884) | about 5 months ago | (#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 . . .

Re:The Golden Age of Programming (2)

Oligonicella (659917) | about 5 months ago | (#47031187)

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 the other systems.

  One of the biggest problems in current systems is that the devs think they should have unfettered access. This is only a prescription for disaster.

Re:The Golden Age of Programming (1)

Kremmy (793693) | about 5 months ago | (#47031463)

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 without the access control causing no end of headaches.
But that's not the case.
Something as commonplace as web development, for example. If you're creating a single-page, static html document with inline CSS and JavaScript, you're probably good with the most basic editor and browser available on your platform, no matter what platform that is. But the moment you cross the line into something even slightly advanced using external scripts, you find yourself in a position where you require such things as an actual web server providing your web documents or the browser will securely pretend like your files are not a valid web document. You simply must modify your environment to progress.
This is the simplest example I can think of, if you do anything more complicated with development than the most basic and simple web page, noticeable access limitations means they aren't letting you do your job.

Re:The Golden Age of Programming (0)

Anonymous Coward | about 5 months ago | (#47031669)

Sorry, but devs absolutely need to be on a limited system!

Follow your example above, you're doing PHP/Python/whatever web programming, so you hop on a server and install all that. Another dev joins the team and finds he needs to amend the timeout or a system variable/setting, so he just jumps on and amends it. Dev #3 then finds this has broken something on the stuff he's working on, so he starts fiddling to try and fix it.

To me, devs should be programming against their own machines where possible (if they can't, then against a shared server - if changes are needed a request is put in that's signed off by a technical manager/lead/senior). When they want to properly deploy to a dev environment for testing/QA whatever, the files should be packaged up and sent to operations, along with the servers requirements. Otherwise you end up with the above situation where dev "works", but UAT doesn't because someone at some point changed some unknown option..

+1 Re:Smalltalk live images (2)

Paul Fernhout (109597) | about 5 months ago | (#47031765)

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, watching this play out of 30 years myself, much of what we get is just re-re-re-inventing the wheel. And there is a terrible waste in having to re-learning it slightly differently with slightly different bugs and limits, and little true progress. Often there is regress, since Smalltalk's keyword syntax is still more readable and expandable than C-like syntax.

Where would we be now if a truly free Smalltalk had had all the billions poured into it that Java had due to IBM and Sun's marketing clout and all the effort that has gone into JavaScript dues to Netscape/Mozilla/Google/etc.? Including the best of any LightTable ideas (a view with source when you hover over a name in code is indeed cool) and any other GUI improvements? As well as better libraries and better cross-platform support and better browser integration and so on?

Still, maybe JavaScript is the best we could hope for at this point, and better than we deserve, as someone else said and I echo in this submission from yesterday about James Mickens' last "USENIX "login" column explaining all that is wrong with the Web pages technically:
http://slashdot.org/submission... [slashdot.org]
Citing: https://www.usenix.org/system/... [usenix.org]

But we got that mess for social reasons (competition, centralization, monetarization), not technical one, like I mention here:
http://slashdot.org/comments.p... [slashdot.org]

Social stuff like ParcPlace not being willing to license ObjectWorks/VisualWorks cheaply to Sun when they wanted to do a set top project (which ultimately lead to sun making Java).

Could Smalltalk be improved? Yes. Even the syntax could, like by using more C-like strings and comments while keeping the keywords. Could it benefit from type annotations for optimization? Probably yes too. And could it benefit from being built from textual sources instead of an image (like GNU smalltalk). Again yes. But investments in that direction would have produced so much more benefits than something like Java or JavaScript.

That said, after all the pain and suffering and waste, Java and JavaScript/HTML5/CSS3 have finally become half-way decent platforms. I'm moving more in a JavaScript direction myself for mostly social and practical reasons, despite knowing how great Smalltalk was and seeing how much it could have become. I talk about that on Slashdot here:
http://slashdot.org/comments.p... [slashdot.org]
http://developers.slashdot.org... [slashdot.org]

Smalltalk might still get there building on Java and JavaScript as with these projects:
http://amber-lang.net/ [amber-lang.net]
http://www.redline.st/ [redline.st]

Mickens' comments are mostly true, but end up being tradeoffs for ubiquity and easy installs in the case of JavaScript -- even Alan Kay and Dan Ingalls agreed on that with their efforts toward the Lively Kernel driven by the fact they could not get many people to install Squeak or Squeak-based apps).
http://www.lively-kernel.org/ [lively-kernel.org]

this is why my kids won't be coders (0)

alen (225700) | about 5 months ago | (#47030851)

the more accessible you make it the more people get into it and the more of a commodity it will become

even now developing and coding is a commodity in a lot of fields or a secondary skill to being a math whiz and working with algorithms on data sets

Re:this is why my kids won't be coders (3, Insightful)

Shados (741919) | about 5 months ago | (#47030983)

Historically, so far, the easier you make it, the harder the problems become.

One of the most visible examples of this is in frontend web development. Now that we have jquery and a billion javascript librairies, we don't do the same simple web pages we used to in a fraction of the time (something that would have taken a month back then takes literally seconds today). Instead, we do crazy shit that were never meant to be done in a browser.

If we make that crazy shit easier, people will just go and do crazier shit.

Re:this is why my kids won't be coders (5, Insightful)

allcoolnameswheretak (1102727) | about 5 months ago | (#47031015)

Yeah, but this perception of programming is the real problem.

Programming is not a "pain" if you do it right. Most of the times programming is a "pain" because you are working with code or frameworks written by mediocre programmers who probably shouldn't be programmers. The more accessible you try to make programming, the more mediocre programmers will be encouraged to write code and software that will be a pain to work with.

Re:this is why my kids won't be coders (0)

Anonymous Coward | about 5 months ago | (#47031451)

software development as always been deflationary, the real benefits are startups when they get cheaper wages...

Re:this is why my kids won't be coders (0)

HellYeahAutomaton (815542) | about 5 months ago | (#47031595)

Programming is pain because most kids today are unmotivated, dumb, and too busy with their social network status and feeling good about themselves than to learn and do stuff. Crappy IDEs and lousy frameworks are a symptom, not a cause.

Re:this is why my kids won't be coders (2, Insightful)

Anonymous Coward | about 5 months ago | (#47031021)

the more accessible you make it the more people get into it and the more of a commodity it will become

even now developing and coding is a commodity in a lot of fields or a secondary skill to being a math whiz and working with algorithms on data sets

So true. I studied computer science at university, never graduated because I began consulting. Years later I am finishing a mathematics degree and regret ever pursuing computer science much less the IT career into which it led me. I came across the textbook for an introductory computer science course at a leading university in Canada; it was so dumbed down I almost cried. The notion everyone should learn to programme computers is ridiculous in the same sense everyone should should learn to wire their own home or repair their own automobile.

Re:this is why my kids won't be coders (2, Interesting)

ATMAvatar (648864) | about 5 months ago | (#47031685)

The notion everyone should learn to programme computers is ridiculous in the same sense everyone should should learn to wire their own home or repair their own automobile.

It's interesting you brought that up, because I think a similar analogy is necessary.

While most people do not (and should not) ever try to do advanced mechanic tasks like change out a transmission on their car, it is useful for people to understand basics like rotating tires and changing oil. Similarly with programming, I would not expect most people to pick up programming to the point where they can code up an OS, compiler, or even a typical SOA system. However, giving someone the tools to fiddle around with basic programming like static web pages with a little javascript or simple command-line applications to handle input from a user or a data file and spit out usable information can enhance their hobbies or even non-IT work.

Many people who became programmers after starting in some other field (either in school or the workplace) can recall situations where they used programming to aid in some aspect of their pre-IT life. There's no reason to shut the door for anyone else to do so.

Re:this is why my kids won't be coders (1)

umghhh (965931) | about 5 months ago | (#47031063)

correct. Coding has been difficult task for geniuses at the very beginning because of two reasons: price of equipment and difficulty of some of tasks at hand back at the time. These days almost enybody can do some coding - my kids learn scripting for office applications at school in 3rd grade - that is programming too. In my professional life I often deal with what you can call infrastructure projects where team size goes over 5persons and it cannot be squized in 3 months, usually having to work on existing code base and maintaining different versions of product in different phases of a life cycle.In such setups coding is a skill which requires quite some knowledge, it is just very important but minor thing - most of the time you deal with things that are not application coding but discussing architecture, ways of testing, release strategy, test automation strategy and some such. There are projects where teams refuse to deal with this issues in a structured way because they 'like coding' and ones where they accept that it is difficult to get done all these other things perfectly but it is nevertheless worthwhile as it saves some major stress later etc. In these setups coding is just part of project life but not the most important one. Testing or maintenance or any such thing is not part of any of the courses. It is still worthwhile as our office life is full of coding of some sort. It is a skill like (yes a car analogy!) car driving - most of us iin inustrilized world have a driving license and can drive but track bd bus drivers are still professionals with special license. The question is - do you want to be a track driver?

Re:this is why my kids won't be coders (1)

50000BTU_barbecue (588132) | about 5 months ago | (#47031265)

Smart parenting. If I have kids, I'll pound it into their heads that technical stuff is for hobbies only. Unfortunately I fear we are heading back to the historical mean for the human race, laborers work garbage jobs with no future, you have the "gentry" and you have the rich families that control everything by blood line.

The gentry would be notaries, lawyers, accountants, managers, etc all jobs which could have been equally well replaced by outsourcing or automation but will never, ever be.

I'd also encourage them to become rentiers, buy a rental property ASAP.

Now that I'm 40 and am still struggling to find work in a dwindling technical area in Montreal, I see other people my age making millions for doing nothing of any real value I can see.

One guy opened an expensive all-hype hair salon. He has 5 expensive cars. All he does is maintain an image.

Real estate agents and notaries provide little to no actual service but have a legal framework to ensure their jobs. Optometrists are another case of something that could easily be replaced by automation but will never be.

Simply put, if you interact with a machine of any kind, you'll either be stuck in stagnating wages or in the perpetual education (at your expense!) treadmill.

I don't see my local landlords or business owners wearing diapers because they fear for their future.

Re:this is why my kids won't be coders (0)

Anonymous Coward | about 5 months ago | (#47031433)

so your advice for your kids about what profession to pursue is to "be a rich owner" ?????

srsly what the fuck.

Re:this is why my kids won't be coders (1)

50000BTU_barbecue (588132) | about 5 months ago | (#47031501)

Pretty much, yes. Would you rather I tell my kids "be a poor peon to keep other people rich"?

You can do that if you want, but my eyes are opened now. I used to be idealistic too.

If you buy a rental property, it will generate passive revenues in ten years.

What will the code you wrote today do for you in ten years? Yeah, unless you own it, nothing.

You can keep investing your time and energy to make other people rich, that's fine, but why burden your children with your neuroses?

Re: this is why my kids won't be coders (0)

Anonymous Coward | about 5 months ago | (#47031601)

All your problems stem from the fact that you've taken the science away of programming

Re: this is why my kids won't be coders (1)

50000BTU_barbecue (588132) | about 5 months ago | (#47031729)

I wish your comment made sense. What are you trying to say?

Oh really now (1)

arth1 (260657) | about 5 months ago | (#47030869)

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 (1, Insightful)

CmdrEdem (2229572) | about 5 months ago | (#47030881)

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.

Re:The pain is good (2)

Antique Geekmeister (740220) | about 5 months ago | (#47030931)

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

Re:The pain is good (2)

MtHuurne (602934) | about 5 months ago | (#47031109)

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 (0)

Anonymous Coward | about 5 months ago | (#47031419)

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.

You sound like you need a safe word when engaged in sex

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.

Compiling code != Running the code.

  your support team must just love getting code from you

Re:The pain is good (5, Insightful)

pla (258480) | about 5 months ago | (#47031901)

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.

Lazy people (1)

nurb432 (527695) | about 5 months ago | (#47030887)

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' )

Re:Lazy people (0)

Anonymous Coward | about 5 months ago | (#47030977)

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' )

Yeah, imagine that. They want to use computers to AUTOMATE stuff.. Go figure..

Meanwhile.. "Back in MY day, we used to chisel 1's and 0's onto stone tablets, in FRACTIDECIMAL, and we LIKED IT!"

Re:Lazy people (0)

Anonymous Coward | about 5 months ago | (#47031213)

Yeah go figure.

A lot of managers/orgs/people can't figure out how to improve their paper processes, to eliminate duplication, but retain sufficient checks and balances, to order dependencies correctly but exploit locality, to do everything in a standard way but manage as an exception according to criteria and judgment.

But the same people should be able to implement easily a far, far more stringent formal model than that, on a machine which can't give meaningful semantic feed and which has no common sense.

Re:Lazy people (1)

nurb432 (527695) | about 5 months ago | (#47031339)

A lot of managers/orgs/people can't figure out how to improve their paper processes

Or define them in the first place.

Re:Lazy people - BULL! (1)

Anonymous Coward | about 5 months ago | (#47031081)

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' )

This is unmitigated bullshit! Edit/compile/link is NOT the object of coding. As a mathematician hacking semi-numerical algorithms, the programming languages (I use mostly C) are the easy/sensible part of the job. A Backus Naur diagram defines the language nicely, making things sensible. (making A[i] clearly the same as i[A].) But my IDEs to link/compile are a morass of no-reason-just-policy quagmires worthy of organized religions.

Coding is not a tedious religious rite to be memorized w/o question. Coding is a tool to get a job done, not an idol of obscurity to be worshiped.

Re:Lazy people - BULL! (1)

jpellino (202698) | about 5 months ago | (#47031645)

"a morass of no-reason-just-policy quagmires worthy of organized religions."

Thank you for cogently describing the current state of programming languages.

I was going to suggest by analogy that your neighborhood mechanic be up to speed not only your car, but your bicycle, steamboat, helicopter, Segway, pogo stick and diesel-electric train.

Re:Lazy people (1)

Oligonicella (659917) | about 5 months ago | (#47031215)

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

Re:Lazy people (1)

gweihir (88907) | about 5 months ago | (#47031521)

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.

Re:Lazy people (1)

ultranova (717540) | about 5 months ago | (#47031895)

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?

Havent you heard of Python (0)

Anonymous Coward | about 5 months ago | (#47030891)

Bizarely the OP apparently hasn't heard of python. How can you not run a python programme, the error messages tell you exactly where the problem is and almost how to solve it. If the OP is talking about C and the like you do know that they are the domain of professional programmers or hacker hobyists like myself not secondary skills in another field.

This is a problem of skill level not an IDE will solve it type of problem. Seriously no wonder the programming world is so screwed up with all these managers saying things like , get windows it will solve your high wages problem as you only need junior low wage workers to do your coding, and those type of shitty things. Programming is for professionals and we should be compensated for our skills not burned because the next fad language will make your workforce less expensive.

Re:Havent you heard of Python (0)

Anonymous Coward | about 5 months ago | (#47030963)

Bizarely the OP apparently hasn't heard of python.

Python was my first thought as well; VB.NET is pretty good for the problem domain he's discussing too.

It sounds like he's on a Java + Eclipse + Spring + Hibernate + GIT + Tomcat + JQuery + CSS rant, but there's good reason to rant against that mess.

Re:Havent you heard of Python (1)

gweihir (88907) | about 5 months ago | (#47031509)

In fact, for a time there were C interpreters that also did what Python does. Never caught on, because this is not the problem. In order to create programs of any worth, the programmer needs to understand what they do and needs to be able to hold a reasonably accurate model in their heads. That is why debugging with print statements works so well: A competent programmer only needs a hint of what the problem is, not every detail. People that need crutches like graphical debuggers and detailed error messages explaining every last bit do not have what it takes.

Re:Havent you heard of Python (1)

Anonymous Coward | about 5 months ago | (#47031827)

More importantly, prints give you a nice, time-ordered, sortable, compact, searchable, filterable state/event list.
I don't want slow-as-hell conditional breakpoints. I don't want to manually inspect the program state. Watchpoints admittedly can be very useful in specific circumstances (though a lot of the time it just means you really should make the code less of a mess).
I don't want to have to wait after each debug step until the program reaches the next. I'd rather let it run over night and look at a log file. Grep, vi etc. are perfectly usable with multi-GB text files (I once had a text editor warn me that the file was "very large". It was about 20 MB. I laughed. If its under 1 GB it's not a large text file).
Sure, use what ever you want. But if your debugger doesn't have extensive, easy to use data collection and analysis tools (I am not aware of one, but that might just be my ignorance) you'd probably be better of using print(f) most of the time.

Not an IDE, just a text editor (0)

Anonymous Coward | about 5 months ago | (#47030903)

Light Table isn't really an IDE. It's just a slow and simple text editor for "web development".

They probably spent more time on the design than on the features.
An outdated version of Notepad++ without any plugins would still be a better 'IDE'.

Stop trying to "fix" programming (0)

Anonymous Coward | about 5 months ago | (#47030905)

The less "brogrammers" we have, the better.

Re:Stop trying to "fix" programming (1)

Bengie (1121981) | about 5 months ago | (#47031013)

I always assumed "brogramming" was similar to "Pair programming", but urbandictionary gives a less professional image.

Difficulty Spectrum (4, Insightful)

Mr_Blank (172031) | about 5 months ago | (#47030927)

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:Difficulty Spectrum (1)

Anonymous Coward | about 5 months ago | (#47030947)

Programming is very easy. You only have to press keys in a keyboard.

Re:Difficulty Spectrum (2)

gnupun (752725) | about 5 months ago | (#47031037)

That's exactly what I hear non-programmers say about this profession.

Re:Difficulty Spectrum (0)

Anonymous Coward | about 5 months ago | (#47031717)

And those are the kind of people that I enjoy programming out of a job.

Re:Difficulty Spectrum (0)

Anonymous Coward | about 5 months ago | (#47031061)

PLUS you have to memorize which keys to press.

Re:Difficulty Spectrum (0)

Anonymous Coward | about 5 months ago | (#47031101)

A ZX Spectrum of difficulty...?

Re:Difficulty Spectrum (1)

gweihir (88907) | about 5 months ago | (#47031471)

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:Difficulty Spectrum (1)

fermion (181285) | about 5 months ago | (#47031859)

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 there were hundred error messages, for instance, it was because of mistype variables in the function call. I find that people mistake the reason we write 'hello world' programs. It is not to test the language, but to test the ability to compile, link, and run code on a platform. I remember well the first time my friends and I got an account on a Cray. It took us a day to figure out what to do. There was no one to call, as very few people have such expertise. Again, it is not just a matter of simple tools, but a critical mass of people who know how to use the tools and can help others. OTOH, one can make the tools as simple as possible, but it won't change the nature of people. That is, most people don't really have a good grasp of cause and effect. It is like people tailgating on the highway. We know that an accident will at some point occur, but people without such a concept of cause and effect do not. This is why I think programming is of such pedagogical value. It teaches students cause and effect. It teaches students that there are rules that if followed will lead to predictable results. Something like python can reduce the pain of compiling and running, but nothing can reduce the pain of trying to solve a problem if one thinks that rules are arbitrary.

We need a new standard (0)

Anonymous Coward | about 5 months ago | (#47031051)

This is why we need a new standard for languages to solve the problem of setting up, runing, debugging, and hot swapping the code.

Wait a moment...

Honestly, having a language built-in on stock pc is perhaps easier. Like including Basic in BIOS. Excel (and VBA) is now taking its place as commoner's programming tools.

And if Excel cell data validation is such an advanced, even hidden feature to most users, perhaps the problem is not about difficulty of getting commoner to handle professional tools.

You Have To Enforce It (1)

Jaime2 (824950) | about 5 months ago | (#47031095)

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:You Have To Enforce It (1)

iONiUM (530420) | about 5 months ago | (#47031195)

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.

Re:You Have To Enforce It (0)

Anonymous Coward | about 5 months ago | (#47031269)

Oh how great that would be. Where I work, I have spent the last couple of years (really) trying to get a working development environment in our local office. Remote builds works, but after months of work the team that actually manages the builds put their hand up and gave up, saying they have no idea why it was impossible to build on our machines, when it works well in their office. Mind you, we are actually on the same network. You might think I'm kidding, but the build process is so convoluted that not a single person in the company actually knows how the whole thing actually works.

Re:You Have To Enforce It (0)

Anonymous Coward | about 5 months ago | (#47031497)

Most of the Industry uses Makefiles...

Actually feedback at all levels is a big problem (1)

NotSoHeavyD3 (1400425) | about 5 months ago | (#47031125)

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 minute explanation that they've not really fleshed out, then run silent for 3 weeks. (Yes, I've literally developed something that was requested and it got used for a couple of minutes and got "This isn't what I wanted." talk. It's very aggravating.)

They are right about one thing ... (0)

Anonymous Coward | about 5 months ago | (#47031127)

One of the most painful lessons beginners have to learn is just how often everyone is wrong about everything.

Well put! Programming would be ten times more pleasant (it is already easy, but so tedious ...) if the documentation were more palatable and available. Cudos to the authors for trying to make the process more streamlined.

On the other hand they are mostly talking about web development. I wish someone would put some though into similar tools for embedded stuff

You can't fix the pain of learning. (0)

Anonymous Coward | about 5 months ago | (#47031131)

Beeing a great programmer is to master a form of ART.
Becoming great programmer means you either was gifted with it, or have mastered all the techniques by doing hard work.
You are never going to get good at anything without going through the pain of learning.

Re:You can't fix the pain of learning. (1)

gweihir (88907) | about 5 months ago | (#47031457)

Indeed. And people that are unable to debug simpler things wit print statement do not understand their code at all. This is not a tool problem.

Fix programming by stopping gratuitous change (0)

Anonymous Coward | about 5 months ago | (#47031147)

To "fix" programming, stop this constant churn of change for the sake of change. I just saw Microsoft is scrapping ASP.NET and starting over with a new framework. They're still calling it ASP.NET, but the internals are incompatible with what they have now. Every year or two, there's some new MVC library, ORM framework, version control system, language. Stop changing things randomly and gratuitously and get some stable industry standards. Change for the sake of change doesn't improve the situation, it makes it worse.

Re:Fix programming by stopping gratuitous change (0)

Anonymous Coward | about 5 months ago | (#47031323)

I get called a "Luddite" when I say this. Shows you what the average programmer knows...

Re:Fix programming by stopping gratuitous change (0)

Anonymous Coward | about 5 months ago | (#47031517)

Luddite...

Eclipse? (3, Informative)

drolli (522659) | about 5 months ago | (#47031149)

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

Re:Eclipse? (0)

Anonymous Coward | about 5 months ago | (#47031335)

"thich"? This which?

Re:Eclipse? (1)

Anubis IV (1279820) | about 5 months ago | (#47031397)

"That" or "which", I believe, though I'm certainly not sure. Perhaps they didn't know which one to use?

Re:Eclipse? (2, Insightful)

Anonymous Coward | about 5 months ago | (#47031553)

You are certainly right about eclipse being an elephant.

Re:Eclipse? (0)

Anonymous Coward | about 5 months ago | (#47031909)

Yeah, if only Eclipse actually were a decent IDE.

Teach my tone-deaf sister to sing (2)

OpinionatedDude (1323007) | about 5 months ago | (#47031157)

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 to listen is not hard...for people who are good at it. People who suck at singing should just do the world a favor and not try it in public. The fact that the world has a limited number of programmers, and an even smaller number of good programmers and an even smaller number of really-really good programmers is simply that people are all different. Some of them can sing. Some of them can do technology. Some of them are jocks. Some of them just take up space. (Hey, it may be harsh, but it is accurate.) On the other end of the millions of different bell curves that could be used to describe humanity, there are some people who excel at bad things, like the Hitlers and the Lawyers of the world. Sadly though, this sort of "how can we make programming accessible to the masses" nonsense will never go away. That is simply because there are people on this planet who are six sigma at asking stupid questions.

Re:Teach my tone-deaf sister to sing (0)

Anonymous Coward | about 5 months ago | (#47031543)

Programming has always gotten easier and cheaper, if you want a 6 figure salary you are supoose to solve the harder problems for us and the industry to move forward...

Re:Teach my tone-deaf sister to sing (1)

jpellino (202698) | about 5 months ago | (#47031607)

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 he wrote something that we think of as enduring, put in the 10,000 hours that's typical.

People involved in reductionist endeavors (science, math, programming) are the worst to judge talent development, as their talents reside mostly in cogitating about stuff. When you do so, the odd thing about that is that you're relying on your internal assessment of talent - which to sum up is "I've always been as smart as I am now" - the mind is lousy at seeing its own progress. Any athlete can point to larger muscles, faster times, higher scores, musicians can hear their progress in performance recordings, artists and writers can see proof of their evolving skills. Much less so for "brainy" people. Example? Look at your use of language. Clearly it evolved. Now think back to when you were three. Tell me something that you can remember from then. Will you tell me the story in your three-year-old voice with a three-year-ol'd vocabulary? Nope. Bet you'll use words you didn't learn until much later. It's like looking through the other end of the telescope.

Your understanding of your understanding expands with your expanding understanding, so you don't see the expansion.

Hence the programming world does (as you kind-of suggest) need to look to other disciplines to see how to ensure talent development.

If you only want the prodigies, it's going to be a long, lonely run.

like dude (0)

Anonymous Coward | about 5 months ago | (#47031189)

> that evaluating code is always safe
You haven't really thought that through. That means there's a lot that it can't do (including knowing if the evaluation completes).

> a uniform (logical) data model where every piece of state is globally addressable
You haven't really thought that through. That means there's either hidden stuff it can't access, or it will be extremely fat.

> a model for change that tracks history and causality
You haven't really thought that through. Causality can be very granular, and even cyclic.

> a powerful query language that can be used for querying code, runtime state, causal graphs, profiling data
You haven't really thought that through. It will scale with toy web projects until you make a complex state machine (or need security).

> composable gui tools with transparent guts
You haven't really thought that through. Sounds like Swing but will break down as soon as you need multilevel composition patterns.

> a smooth interface to the old world so we don't end up sharing a grave with smalltalk
You haven't really thought that through. You can't do all of that, introduce nondeterminism and complete transparently, and do it efficiently and understandably.

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

w3woody (44457) | about 5 months ago | (#47031201)

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.

There needs to be a continuum (1)

jpellino (202698) | about 5 months ago | (#47031355)

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 rushes to pooh-pooh anything other than a full-blown professional language as "programming". Got it. Hour of Code was an inch deep and a mile wide. Understood.
And that's the problem. What's a kid who gets inspired by that first experience to do - jump into a CS course that's an inch wide and a mile deep?
To extend another analogy used elsewhere in these comments, it's like going from applying a bandaid to being handed a scalpel and suture set.
Want to make a lot of money? Create a language that mimics their maths experience - that explains variables, arrays, transformations, algorithms, sets, etc. in a way that they can parallel and apply.
Yes, cue the snarky comments, but I miss BASIC and HyperTalk. Very low learning "floor" and pretty-darn-high learning "ceiling". RunRev / LiveCode has huge potential as it uses hypertalk-ish syntax and actually does something tangible in short time. The engineering equivalent of such a continuum is LabView, but yes, it's basically for instrumentation, no, you can't produce standalone apps, etc.
Huge need for a continuum / bridge.

The $316000 Notepad (0)

Anonymous Coward | about 5 months ago | (#47031373)

If one tried this $316000 masterpiece, it's nothing but a fancy notepad at the moment. IDE needs top quality intellisense, project references etc. It has none of these, even rudimentary things like line numbers is missing.

One can only hope they spend several years developing this thing, though I suspect this is the final and the developers will take a holiday on remote Island with rest of the money.

Physical Exercise is hard too. (0)

Anonymous Coward | about 5 months ago | (#47031389)

You'll find that even if you give someone all the workout clothes they need and equipment, they'll struggle to use it. They'll be aching and moaning through every exercise. Struggling to find the motivation and not eating the correct meals. Most people consider this part of it but some think that it should be easier. Maybe we should tie their feet to the stair-stepper and let the machine move their legs. Maybe we should predigest their food for them like a bird. Oh America! When will we see that all work is too difficult for mankind and finally build a gym that removes all the challenge from challenging yourself!

Wasn't all this solved at the end of the 80s and e (0)

Anonymous Coward | about 5 months ago | (#47031391)

Wasn't all this solved at the end of the 80s and early 90s with Borland and MS IDEs?

Re:Wasn't all this solved at the end of the 80s an (2)

gweihir (88907) | about 5 months ago | (#47031449)

Yes. Turns out people unable to program lack talent, insight, dedication, but not an IDE.

What nonsense (1, Insightful)

gweihir (88907) | about 5 months ago | (#47031439)

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.

Just use Vim or Emacs (0)

Anonymous Coward | about 5 months ago | (#47031555)

IDEs cost you time and induce bad habits. You end up spending too much time debugging the IDEs themselves and becoming dependent on the crutches they provide. I've seen Java developers who don't know how to run their program without Eclipse installed.

My advice is to use vi(m) or emacs.

On Almost Every Professional Project I've Been On (2)

Greyfox (87712) | about 5 months ago | (#47031585)

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?

s/emperical/empirical/ (1)

RonBurk (543988) | about 5 months ago | (#47031591)

It's right before the sentence that accuses the world of choosing to be illiterate.

Be careful what you wish for (1)

Rambo Tribble (1273454) | about 5 months ago | (#47031625)

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.

For those who think programming should be hard... (1)

gestalt_n_pepper (991155) | about 5 months ago | (#47031745)

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 at meeeee! Look how smart I am! Whoo hoo!

But if you're trying to make *money* programming, or actually have to get a task done, you need all the help you can get. If you have a manager or officer breathing down your neck to GET IT DONE so millions aren't lost, or someone doesn't die, you need effective tools.

Bottom line? Get over yourselves. The IDE is there to make accomplishing a task as easy as possible. It serves no other purpose. It should make everything easily known and obvious. Moreover, it should actually HELP YOU solve your problems. Otherwise, it's just another idiotic software failure.

Beginners .... start servers ... opem ports ... (1)

RichMan (8097) | about 5 months ago | (#47031805)

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.

Consider Visual Studio (0)

Anonymous Coward | about 5 months ago | (#47031811)

it solves many of these problem, Microsoft even has a free version (Express) - if you want to use Pro for a while, you can even 'rent' it by the month from the link below

Express:
http://www.visualstudio.com/en-us/products/visual-studio-express-vs.aspx

Online:
http://www.visualstudio.com/en-us/products/visual-studio-online-overview-vs

Logical impossibility (2)

Chelloveck (14643) | about 5 months ago | (#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.

What pain of programming? (2)

bucket_brigade (1079247) | about 5 months ago | (#47031933)

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

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?