×

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!

Dumbing Down Programming?

timothy posted more than 4 years ago | from the accessible-is-not-dumb dept.

Programming 578

RunRevKev writes "The unveiling of Revolution 4.0 has sparked a debate on ZDNet about whether programming is being dumbed down. The new version of the software uses an English-syntax that requires 90 per cent less code than traditional languages. A descendant of Apple's Hypercard, Rev 4 is set to '...empower people who would never have attempted programming to create successful applications.' ZDNet reports that 'One might reasonably hope that this product inspires students in the appropriate way and gets them more interested in programming.'"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

578 comments

A Natural Progression Yet So Many Caveats (5, Insightful)

eldavojohn (898314) | more than 4 years ago | (#30239900)

There's two major sides to this issue. One seems (note I said seems, not implying at all that it's unavoidable) to be that the more human readable and dummy proof the more overhead you pay when you design/implement a programming language. You might find the C/C++ crowd commonly accuse the Java or Ruby crowd of this overhead. Indeed, Java has a garbage collector designed to protect you from memory leaks and Ruby is an interpreted language that pays a mild additional overhead since it cannot be optimized upon compilation. But that's another debate altogether, it just is evident that the more you move away from actual machine language and assembly then more overhead you pay (generally).

The other side of this issue is that computers are our servants, not the other way around (and if anyone reading this is a bot or script, don't you forget that). I don't recall where I read it but this is the reason why the string is the most important data structure in computer programming. Because simply put, the string is the best way to communicate with the user. What follows from this logic is to screw the optimizers (or 'misers, if you will) and make the servant learn the language of the master--not the other way around. And isn't this how the most complex applications have progressed? Once requiring training and years of experience, now even a kindergartner can master a word processor. Computers and applications will forever be bending over backwards for the most important thing to us: us.

And yet if an implementation of a language incurs on average of 10% overhead, your hardware will catch up in a matter of months.

And yet if you run a data center the size of Google's and have several applications in said implementation running on hundreds of thousands of machines, a cycle here and a cycle there isn't so laughable to work toward saving. And isn't it the big players that ensure the lengthy life of a language and its implementations?

So it's a good debate with several sides. Personally, I love the fact that I can code a web application in Ruby, run some old C code off sourceforge in Java with JNI (sort of) and bust out a C++ application for manipulating ID3 tags across my entire music library. To those arguing against Rev4, I ask simply "why not?" I mean, you don't have to use it, it's a natural progression so let it happen. Maybe you'll find it useful for prototyping? Maybe you'll find it's a useful tool for some problems and your toolbox will grow? Who knows?

In the end, I would like to opine that the the chip makers are forcing us towards languages that make multi-threading more intuitive and useful. I mean they concentrate on threads communicating or even implementing APIs to help automate (by enabling what is appropriate to multithread) in loops and algorithms. That's going to be a large factor on whether a new language is adopted and survives.

Re:A Natural Progression Yet So Many Caveats (4, Interesting)

mwvdlee (775178) | more than 4 years ago | (#30239976)

The simple truth is that many applications don't need that much performance or strange features and if a language like this enables more people to make their own custom apps, then I applaud it.

Some people will argue "job-security through obscurity", but if your job depends on other people not understanding what you do, it's bound to end sooner rather than later anyway.

I do wonder what the limits of this language are feature-wise. What type of applications could you NOT make with this language?

Re:A Natural Progression Yet So Many Caveats (3, Informative)

mwvdlee (775178) | more than 4 years ago | (#30240064)

Reply to myself

Just looked at the portfolio of their consulting bussiness; they use their own language only for the simple bits and use other languages for the interresting stuff. Other projects they don't even use their own language at all.

Says enough to me.

Re:A Natural Progression Yet So Many Caveats (3, Interesting)

MightyMartian (840721) | more than 4 years ago | (#30240120)

You're quite right. Plenty of applications don't need the kinds of optimization one is going to get with C/C++. What concerns me, as we've seen with Ruby or PHP suddenly finding their way into production servers, and suddenly all the design choices (ie. simplicity vs. efficiency, footprint, etc.) come and bite you in the ass. There seems to have been this attitude over the last ten years as memory and storage prices have fallen that if you have a slow app, just throw it on a faster computer and away you go! Java UI's have suffered from this sort of "the future will fix it" thinking for 15 years now.

Re:A Natural Progression Yet So Many Caveats (3, Insightful)

icebraining (1313345) | more than 4 years ago | (#30240222)

Isn't the best approach to develop fast, identify the bottlenecks and then rewrite those parts in a faster language, like Python C modules?

Re:A Natural Progression Yet So Many Caveats (1)

umghhh (965931) | more than 4 years ago | (#30240210)

Here I fixed that for you: "In real life your job is bound to end sooner rather than later anyway". If that is so then why should we care?

Re:A Natural Progression Yet So Many Caveats (3, Interesting)

Daishiman (698845) | more than 4 years ago | (#30240316)

It doesn't really matter in the web as 90% of the time is spent hitting the database.
Youtube runs pretty much 100% on Python, Facebook runs on Erlang and PHP. Erlang has the benefit of being highly scalable, yet it is relatively slow.
Speen in the web doesn'trelly matter much. What's important is scalability, and today's shared-nothing approach pretty mucha guarantees that at the language level.

Re:A Natural Progression Yet So Many Caveats (1)

sys.stdout.write (1551563) | more than 4 years ago | (#30239994)

I think the debate is more over the syntax of the language than the implementation of it.

Note that:
myString.pop()
and
remove the last character from myString

produce the same thing in the end. I guess I don't follow your concerns about overhead..

Re:A Natural Progression Yet So Many Caveats (1)

MightyMartian (840721) | more than 4 years ago | (#30240156)

printf("h");
printf("e");
printf("l");
printf("l");
printf("o");
printf(" ");
printf("w");
printf("o");
printf("r");
printf("l");
printf("d");
printf("\n");

and

printf("hello world\n");

produce the same thing too, but unless you've got some pretty damned smart optimization going on, one is going to be far more efficient than the other. If it's compiled, then the overhead of a good optimization is going to be at compile time. For an interpreted language, well, all that tokenization and such, even with JIT compilation, means at least once, your app is going to get kind of clunky.

Re:A Natural Progression Yet So Many Caveats (2, Insightful)

TheCarp (96830) | more than 4 years ago | (#30240320)

True, but the looser the syntax, the more that you need to know to debug. Supporting complete natural language is a daunting task. Whatever constructs that you don't employ end up forming an exceptions list.

To be honest, the language is hardly the real problem. Its been a while since I did it, but I picked up my first couple from books. The challenge was seldom the language itself, and more about breaking down a task logically into discrete units and defining them, ordering them, and putting the right logic around them.

Text based languages had many reasons to evolve the way that they did. However, I see nothing invalid about producing code in a way and or language that defines this information in a different manner. Couldn't you just as easily replace the text editor with a flow chart where each operation or function was represented as an object in the chart? Not saying this is how I want to roll, but, I see no reason that it couldn't be made functionally equivalent.

In truth, I am not sure that it will shorten the time that it takes to learn, as it will still take time to learn the skills of putting the pieces together. A calculator makes you an instant basic math wiz. Addition, subtraction, no need to learn times tables. However, its not going to obsolete learning the concepts. It can't make you an algebra god.

Once you learn one or two languages, picking up another is usually easy (I never really gave lisp a fair shake, but it was the exception). The concepts are the same. I would imagine that a person who became proficient with something more hypercard like would have little trouble translating those concepts and learning some of the high level text languages.

-Steve

 

Re:A Natural Progression Yet So Many Caveats (4, Interesting)

mustafap (452510) | more than 4 years ago | (#30240020)

>the more human readable and dummy proof

Actually those two are exclusive, not inclusive.

Re:A Natural Progression Yet So Many Caveats (2, Insightful)

broken_chaos (1188549) | more than 4 years ago | (#30240250)

Not entirely. In some cases they can be, but not in others.

They might be if something is opaque enough that anyone who is not a 'dummy' will simply fail to produce something working. Like trying to create an assembly program with no knowledge. However, they might not be if they're more in-between incomprehensibility and English. Like someone enters the wrong command into a shell.

For the latter, imagine if, instead of "rm -rf *", you'd have to type "delete all files in this folder, and I'm sure I want to do this". It's more verbose and much less efficient, but it's both more human-readable and likely much more dummy-proof. If someone can more easily understand what they're doing, they're more likely to stop and realise it may not be what they actually intended to do.

Underhanded Way to Increase Comments in Code (5, Insightful)

reporter (666905) | more than 4 years ago | (#30240050)

This progression toward using English words and syntax to program a computer is less about dumbing down code and more about encouraging people to document their code.

Ideally, a programmer should document each section of code by writing a block of comments explaining (1) why the code is used and (2) how the code works -- in plain English. However, given the intense pressure to produce code by an unreasonable deadline (imposed by brutal managers risking a bullet through their head), the first thing that is sacrificed is comments. Not writing comments saves several minutes per section of code and -- in total -- saves days of work over the course of the project. In other words, not writing comments means that an impossible deadline becomes slightly more possible.

A programming language that uses mostly English words and syntax is essentially an environment for self-documentating code: the holy grail of brutal managers everywhere. However, this self-documentation addresses only "how the code works". The programmer must still write comments explaining "why the code is used". Still, getting half of a loaf is better than getting nothing at all.

Re:Underhanded Way to Increase Comments in Code (0)

Anonymous Coward | more than 4 years ago | (#30240152)

The only thing a natural language programming environment helps with is fear of symbols. Self documenting code can be written in any high level programming language. The key is keeping the code readable, instead of trying to avoid a formal syntax, because that can't be done. There is a certain amount of information that people can hold in visual perception at the same time and modern languages are pretty good at neither exceeding that amount for common structures nor making structures so expressive that they are no longer readable at a fluid speed.

Re:A Natural Progression Yet So Many Caveats (2, Informative)

rolfwind (528248) | more than 4 years ago | (#30240226)

You might find the C/C++ crowd commonly accuse the Java or Ruby crowd of this overhead. Indeed, Java has a garbage collector designed to protect you from memory leaks and Ruby is an interpreted language that pays a mild additional overhead since it cannot be optimized upon compilation. But that's another debate altogether, it just is evident that the more you move away from actual machine language and assembly then more overhead you pay (generally).

Progression? Like chronological? "Garbage collection was invented by John McCarthy around 1959 to solve problems in Lisp."

http://en.wikipedia.org/wiki/Garbage_collection_(computer_science) [wikipedia.org]

In fact, I would argue that the "overhead" is the best case scenario for the C/C++ type languages because these are usually measurements on programs written by people who know exactly what they are doing and furthermore have had multiple eyeballs look at that code over and over and over again. But is that speed really there for the average code. How many OS security flaws are still discovered because of incorrectly implemented pointers or function calls like malloc (checks and what not). And so, what about bugs that use resources.

But one thing code can never get away from, no matter how highly you're abstracting, is that the programmer has to know what they are doing. That's why it's a tool. There is no replacement for that. Photoshop can't make you an expert photographer either or turn crap photos into masterpieces. Why would anybody expect a programming language do the same for a programmer? It might hold your hand more and keep you out of trouble, but idiots always have ways to get around the idiot-proofing.

Re:A Natural Progression Yet So Many Caveats (1)

zoney_ie (740061) | more than 4 years ago | (#30240282)

Plus the more "optimised" languages don't cease to exist, and are available for use where more appropriate than a "friendly" language. Indeed there exists a spectrum of languages, with situations where each can be appropriate (although obviously some particular languages have disadvantages or even a degree of "brokenness" as all of them are pretty much characteristic human creations, and some more so than others).

Personally I like getting the opportunity to code in various languages - one quickly gets comfortable with the idiosyncrosies of each, and to be honest, I think the experiences coding in higher or lower level languages are complementary (one has a better understanding of what functionality you want to manually create in lower level languages, and in the higher level ones you have a better idea of the implications of using certain features).

It's all great fun really - although possibly my viewpoint is biased by an academic setting.

Re:A Natural Progression Yet So Many Caveats (2, Insightful)

SharpFang (651121) | more than 4 years ago | (#30240296)

I can say one thing.
You've never done embedded programming.

No chips that have to work in temperatures between -40C and +120C.
No devices that work 120 meters under surface of water which is 1800 meters above sea level and good 4 hours of march from the last road where you can get by car.
No chips for appliances, toys and small devices where $0.03 per unit savings by choosing a model with 64 bytes(!) of RAM instead of 128 bytes of RAM converts to a six-digit profit.
No devices where failure to perform according to specs and fail gracefully will land you in prison for between 2 and 15 years.
No devices that run a dozen sensors and send the results every hour over GPRS running off a single battery the size of a standard "A/R20" for a year.
No devices where you measure time between sending out a beam of light and receiving it bounced off the obstacle, to determine distance with 5cm resolution.
No devices where you have to do error correction, encoding and driving control and data lines at 100 megabit/second - or more precisely, at one bit per 10 nanoseconds plus/minus 1.5 nanosecond.

This kind of applications won't have the hardware catching up to let you replace C, Asembly and VHDL with Ruby or Java for decades yet.

BAD IDEA (0)

Anonymous Coward | more than 4 years ago | (#30239906)

PHP and VB have dumbed down programming too much. Managers love it because they can hire less skilled (and cheaper) employees; end users suffer with shitty programs.

Obviously, you can (and do) write shit software in any language, but at least other languages let you write well designed software.

Re:BAD IDEA (1)

Skapare (16644) | more than 4 years ago | (#30239914)

At first I read that as "PHB has dumbed down programming too much". But that is part of it.

Re:BAD IDEA (3, Insightful)

hairyfeet (841228) | more than 4 years ago | (#30240046)

The reason VB got a bad rap isn't because of VB, which IMHO is fine if it is used as intended, it is the fact that too many folks tried to stick a square peg in a round hole and use VB where it didn't belong.

VB does ONE job and does it quite well-GUIs for databases. That's it. Nothing fancy, just a quick and basic GUI so sally secretary can input data into a database and get data out of it. While you may argue that you can do the same thing in other languages, which of course you can, the simple fact is most SMBs and SOHOs simply couldn't afford it. Hiring a programmer isn't cheap, whereas with VB even a simple PC repairman like myself can whip off a nice GUI for a database, which in my experience is one of the biggest needs for a custom app that most SMBs have and is why VB is still the # 3 language for business, even though MSFT has done everything they can to kill it.

So if you want to complain about dumbing down in general please do. But VB when used as intended by someone who knew the limits of the language was and still is just fine for the job at hand. For making custom GUIs for databases I have yet to see anything that works as easily and as affordable as VB does in that role.

Re:BAD IDEA (1)

MightyMartian (840721) | more than 4 years ago | (#30240212)

I've been working for three days to clean up a Microsoft Access app written in VBA, and I can tell you right now, that even for that limited purpose, VB can suck badly. The same applies to PHP, where I spent weeks trying to clean up an absolutely horrific (and huge) PHP-based site.

The full-blown VB wasn't too bad. I used VB6 to write a customized Accounts Receivable application using MySQL as the database server via ADO. Microsoft makes a decent IDE, and I did plenty of in-code documenting, as well as sensible variable names, static typing, and so forth. It was a relatively easy program to debug and update. I've also done quite a bit of PHP coding, and enforce similar standards. So the lesson is that any language can be used to write good code, or bad code.

But VBA and PHP both open the door too much. They allow people to get themselves into horrendous messes, or in larger shops, allow crappy coders to create vast, inefficient, poorly written and insecure apps.

Re:BAD IDEA (1)

timmarhy (659436) | more than 4 years ago | (#30240280)

so what your arguement is that due to the l33tne$$ of C/C++ no one could write a crappy application? bullshit. you only need to attend uni and look at first year programming assignments to see that's completely untrue. All i'm hearing from you is whinging about all the work your getting cleaning up crappy programmers work, dude you should be THANKING the crap programmers of the world, as they shall keep you in work for the rest of your life.

Re:BAD IDEA (1)

MightyMartian (840721) | more than 4 years ago | (#30240330)

I'm whining a bit, and I never denied that any language can produce shit. But languages like VB and PHP practically encourage it. Maybe it will keep me in work, but I have guys breathing down my neck because I didn't add a new module to a VBA inventory management app in two days because the thing was so poorly written. Meanwhile, other projects fall behind because I have to disentangle some terrifyingly bad program.

Twice now I've suggested rewrites from the ground up, arguing that it would take me less time to duplicate the app but with easy capacity for adding features as they are required, and have been shot down because "So-and-so spent three months on that and we don't want to throw out our investment." I don't mind the pay, but being paid to smack your head against the wall still makes getting your head smacked against the wall hurt.

Re:BAD IDEA (1)

timmarhy (659436) | more than 4 years ago | (#30240252)

there is nothing stopping you writing brillant apps in VB or PHP. dumming down a language also makes it harder to make mistakes in the first place, producing BETTER quality apps. your logic is seriously flawed.

What's new? (5, Insightful)

Rising Ape (1620461) | more than 4 years ago | (#30239910)

People have been saying this since FORTRAN meant you didn't need to know assembly language to make use of a computer.

Re:What's new? (5, Insightful)

WED Fan (911325) | more than 4 years ago | (#30240040)

If I had mod points I'd find someway to give all of them to you for insight. What follows in this thread is the same tired religious discussion. Back in my day of programming that included paper tape, teletype terminals on time shares things were tough. We were making fun of the new little "home" computers. I can't tell you how many computer languages that I sneered at. I was sure C++ would go down in flames, same for Java. I was sure Modula-2 would be the next great thing. The simple fact that people don't like that languages they hate are still seeing wide spread usage shows that the discussion is more religious than logic.

Re:What's new? (5, Insightful)

ScrewMaster (602015) | more than 4 years ago | (#30240188)

People have been saying this since FORTRAN meant you didn't need to know assembly language to make use of a computer.

Yes, they have. But at least FORTRAN, for the things that it did do, it did very well. However, in a more modern context dumbed-down languages invariably have severe restrictions on performance and capability, which makes makes them unsuitable for many purposes. Putting that aside for the moment, the reality is that unless you're coding mindlessly-simple applications, coding is hard. It just is, and it takes both skill and talent to pull off a well-written application, and I don't care what language you're talking about. Furthermore, to a skilled developer a dumbed-down language is a liability ... it just gets in the way. A better approach to this problem is to identify and train more good programmers, but that costs money and time. Certain people think they see a cheap way out by replacing sophisticated developers and their tools with sophisticated tools and simpleminded developers. Good luck with that.

This all comes down to one faulty but cherished premise (one of many held by today's business community, I might add): that complex, reliable applications can be built by minimally-skilled developers if we can, somehow, just put enough power into the tools. The problem is, the tools aren't the problem, it's the people. In the end, software development is as much an art as it is a science, and there really aren't enough artists to go around.

All such attempts to short-circuit the need for skilled developers are doomed to failure until such time as computers truly can program themselves. Of course, at that point it won't really matter, and most of us software engineers will be slapping burgers anyway.

Hooray for the second coming of the biz programer (0)

Anonymous Coward | more than 4 years ago | (#30240208)

Never has software sucked so badly as today. We have "professional" programmers trying to implement business rules, what a mess.

I work in the nonprofit sector. The mailing list, volunteer, and client managers are just terrible. Someone take GiftWorks out back and just shoot that piece of junk. BlackBaud Raiser's Edge, who the fuck has $150,000 to just bring up a splash screen?

I long for the good old days of Paradox/DOS and dBaseIII. It was a snap for anyone with a triple digit IQ to write an app that would keep track of financial and inkind donations.

C#, Java, C, and the rest of them have ruined American business. They are horrible tools.

Lowering the bar (1, Flamebait)

Skapare (16644) | more than 4 years ago | (#30239926)

Let dumber people program and you end up with dumber programs. Way back in year 2000 I found that most of the Y2K bugs were actually from more recently written programs in dumbed down languages.

Re:Lowering the bar (5, Insightful)

GWBasic (900357) | more than 4 years ago | (#30240134)

Let dumber people program and you end up with dumber programs. Way back in year 2000 I found that most of the Y2K bugs were actually from more recently written programs in dumbed down languages.

I don't see it that way.

After spending a few years in garbage collected land, I was assigned to work on a C++ application. The C++ application was a mere SOAP wrapper for a database, so it wouldn't have any noticeable performance advantages over an equivalent program written in a garbage collected language.

The problem that quickly became obvious to me, and why I ran away from the project, is that manual memory management is so time consuming; even as an expert programmer, that the "soft and easy" languages are more about letting great programmers get more things done in less time.

This is even the approach taken in Python; the recommendation is to write well-tuned libraries in C for the parts where C will increase performance. For parts where C is a waste of time, Python lets you not worry about silly details.

Re:xkcd relevance (1)

sa666_666 (924613) | more than 4 years ago | (#30240012)

I absolutely agree. Making a programming language easier wrt syntax might make it somewhat clearer to understand (the language itself). However, the hard part is the logic behind it, and I don't see that ever being made easier. Logical/critical thinking and being able to break down a problem into subproblems is required for any programming activity, no matter what language you use. Make the syntax as clear as you want; you still need to understand the problem and apply reason in a logical fashion. Some people just can't do the latter, no matter how easy you make the language itself.

Not to sound elitist, but this is 'garbage in, garbage out' in action. If you're not the type of person able to reason through a problem, you'll never be a good programmer.

Re:xkcd relevance (4, Insightful)

jedidiah (1196) | more than 4 years ago | (#30240112)

In this respect, I think "clarity" is improved much more by using constructs from mathematics than from "english".

So computing languages that try to avoid classic mathematical syntax are probably more a reflection of "the fear of math" rather than "the fear of computers". Although there's bound to be some overlap. The real problem in both cases is widespread fear and ignorance. This isn't just about people writing their own programs. The reluctance to learn and explore hamper the usefulness of basic end user interfaces (GUIs).

We may be encouraging people to run with scissors when they haven't even figured out turning over yet.

Re:xkcd relevance (1)

owlstead (636356) | more than 4 years ago | (#30240262)

I agree absolutely. Of course, an easy to program language can still make life easier. A well designed set of APIs can make life easier. And then you can top it off by making sure most use cases are covered. Don't forget that there is an awful lot of repetition out there. Of course, if it is all repetition then there is probably a product sitting somewhere on a shelf.

Personally I'm not so in favor of these kind of "natural" languages. Give me a language that is very abstract and well defined instead. Just make a very good IDE for it with drag and drop for designing stuff. And make sure it is easy to use and easy to configure and supply a very good API. But don't go into dynamic typing systems and such, because they twist the mind. Basically such systems force you to think abstractly, and most computer programming comes down to creating an abstract system from the solution you formed in your head.

Of course, many people will have trouble forming anything in their head, let alone solutions to computing problems (just trying to top your last remark here ;).

Re:xkcd relevance (0)

Anonymous Coward | more than 4 years ago | (#30240328)

if your ideas can be implemented in a "dumbed-down" language, then your problem is solved!

the chosen language needs to be an appropriate way of describing the tasks you want to do. Simpler languages are bad. More complex languages are bad.

Interesting, yet exaggerated... (5, Insightful)

rdean400 (322321) | more than 4 years ago | (#30239940)

The big thing I notice in their "competitive comparisons" is that they strive to make Java, C#, C++, and PHP as verbose as possible when they're creating what looks like it should be optimal Rev code.

I wonder if they didn't compare themselves to Ruby or Python because they couldn't contrive examples that produce huge LOC differences?

Re:Interesting, yet exaggerated... (2, Insightful)

arevos (659374) | more than 4 years ago | (#30240232)

I wonder if they didn't compare themselves to Ruby or Python because they couldn't contrive examples that produce huge LOC differences?

Probably. There's no difference in length between:

get the last item of line 2 of URL url

And:

open(url).readlines[1].split(",").last

I guess the former is easier to read, but languages that have a lot of "magic" in them tend to be pretty bad at scenarios the developers didn't think of. Which will inevitably turn out to be something you want to do.

I could care less, it isn't truly FREE (1, Interesting)

Anonymous Coward | more than 4 years ago | (#30239944)

Oh wow a proprietary software development system? It's a new world boys there are plenty of solutions out there and just because these guys have marketing dollars doesn't mean people will take them up on it.

Unless it is open, it will die.

Remember all those old proprietary platforms? They are all but dead. It is a new age, get used it.

Re:I could care less, it isn't truly FREE (2, Insightful)

DAldredge (2353) | more than 4 years ago | (#30239964)

.net appears to be doing rather well.

Re:I could care less, it isn't truly FREE (2, Insightful)

sznupi (719324) | more than 4 years ago | (#30240116)

...which is largely due to external factors.

(not saying .Net isn't nice, but ask yourself if it would do that well if it came from some small 3rd party dev)

Re:I could care less, it isn't truly FREE (1)

hairyfeet (841228) | more than 4 years ago | (#30240170)

But MSFT appears to be trying to open [slashdot.org] .NET one piece at a time. I find it kinda funny that most of the posts on that story were complaints, first folks complained that MSFT was locked down, and then they try to open parts up and get the "embrace, extend" bit thrown at them. Kinda damned if they do, damned if they don't in that regard.

Its been being "dumbed down" since the start (2, Insightful)

jaymz2k4 (790806) | more than 4 years ago | (#30239956)

The development of new languages and new ways of simplifying coding has been a part of the computer landscape since the whole thing began. You can argue that coding in Python is a form of "dumbed down" assembly. I wouldn't think of creating a webapp with assembly! Django has "dumbed down" much of the mundane parts I often have to create and dealing with forms and templating. But the one thing I have noticed is that no matter how easy "programming" gets there are still people that will just not "do it".

I still can't see the masses suddenly deciding that they're going to program applications now. Hell, most of the people I know think conditional formatting in excel is just too much effort. I can see this just being used by actual programmers for users but I dont think it will see in a swath of uber-uber-amateur programmers all of a sudden.

There's more than one way to do it. (1)

wkitchen (581276) | more than 4 years ago | (#30239960)

You get what you want. Someone else gets what they want. What's to get bent out of shape over?

Little point in trying (5, Insightful)

4D6963 (933028) | more than 4 years ago | (#30239982)

Dumbing down programming can only get you so far towards the democratisation of programming : the most dumbed down programming language still requires a user whose mind can express algorithms. And of all the people who can express algorithms and would want to, few are limited by the commonly used languages, that is, if you have a mind made for creating algorithms, learning to use a programming language will be fairly trivial.

Re:Little point in trying (3, Insightful)

QRDeNameland (873957) | more than 4 years ago | (#30240124)

I think one issue here is the concept of "dumbing down", which goes back to COBOL at least. PHBs have always had this idea that better tools will make it so that that people who have little talent or interest in programming (or as you say, can express algorithms) can write software. That, I think, will always be a pipe dream.

However, the goal of "simplifying programming" will always be a valid and necessary one, just due to the nature of advancing technology. The trick is to adjust the goal from "helping people with little programming competence to write software" to "create tools that enable competent developers to be more productive and their work less tedious".

Quit complaining (1)

pkbarbiedoll (851110) | more than 4 years ago | (#30239986)

Ok stop acting like Luddites and embrace the new economy. Programming is currently complicated and requires costly developers to write and maintain. In order to increase efficency, lower payroll, and satisfy shareholder demand, languages like runrev should be embraced by business.

This innovation is no different than automation on the assembly line. The global economy has changed around you - it is time to recognize trends and retrain. Otherwise you may find yourself out of a job and career.

/snark

Re:Quit complaining (3, Insightful)

Anonymous Coward | more than 4 years ago | (#30240108)

I hope they embrace this stuff like crazy. There's nothing better for our careers than lots of shitty code written by people who are just barely above monkeys in terms of intelligence.

Why is that? Because they will fuck it up horribly. And then they will need real programmers to come in and clean up the mess. If you don't mind getting your hands dirty, there's a huge amount of work to be done.

This is perhaps the best thing to hit the industry since outsourcing to India. My company has been fixing their fuckups for the past decade.

It's entertaining to see them screw up. It's even better to see the outsourcing managers who have to come to us and admit that their "cost-saving" measures will now cost their companies 5x to 10x what it would have had they just done it properly and had real programmers write their code.

Re:Quit complaining (3, Insightful)

gbjbaanb (229885) | more than 4 years ago | (#30240162)

Unfortunately, that makes sense to managers only. Those of us at the coal face know that you can hire cheaper, less skilled programmers and let them loose with easy-to-use languages (eg Visual Basic) and you will get a monstrous mess that is impossible to maintain.

If you make them use a reasonably difficult language, most of them will not bother becoming programmers. This a good thing.

One other point that is never noted in these ideas to simplify programming and make programmers generic 'coding resources' is that a good, experienced, coder can do more work ( that is better quality) than half a dozen cheap, less skilled coders. This is never factored into management ideas of how you can outsource your coding and get the same quality for a tenth the price. This could be why a lot of outsourced contracts don't tend to last unless they're lost in a sea of big-corporate bureaucracy.

Oh, and don;t forget that the more you chop and change programming languages, the less programmers you have who are experienced using them - you will get C programmers who have 40 years experience, you tend to get programmers who've "had a tinker" with languages like runrev.

Re:Quit complaining (0)

Anonymous Coward | more than 4 years ago | (#30240224)

Except that programming real non-trivial software can only get marginally easier by improving tools. The real difficulty is understanding and defining the problem and the exact solution.

If you don't understand this you are the one who doesn't recognise the trend...

Re:Quit complaining (1)

MightyMartian (840721) | more than 4 years ago | (#30240292)

If that's the case, then the shareholders better get used to shitty software written by people with no experience and no discipline, which get more expensive and difficult to manage all the time. They should be ready for "cheap" in-house apps written by non-programmers to cost them progressively more as time goes by, until the cost outweighs what simply an initial investment in someone with experience and know-how would have cost.

Re:Quit complaining (1)

trouser (149900) | more than 4 years ago | (#30240326)

All my life, I have searched for a car that feels a certain way. Powerful like a gorilla, yet soft and yielding like a Nerf ball. Now, at last, I have found it.

It actually doesn't look that good (3, Interesting)

thetoadwarrior (1268702) | more than 4 years ago | (#30240000)

Mind you I only skimmed a couple pages in the tutorial but it's just a programming language adding more words and more typing because it may do something like spell out add rather than using +. That may let idiots grasp programming a bit more than they would have before but programming as it is does not require a degree in rocket science. It just requires that you actually have enthusiasm for rather than thinking it's just a way to make lots of money.

Not everyone is a programmer just as not everyone is a mechanic, painter, etc. I don't think we have a lack of programmers but a lack of dirt cheap programmers and companies will do whatever they can to lower wages. Perhaps they'd be better off make better programs to earn more profits.

Re:It actually doesn't look that good (1)

MichaelSmith (789609) | more than 4 years ago | (#30240094)

Back when I was at college and I had to write some cobol a friend of mine who was a biology student came past. She saw the code and commented on how easy it was to read. Maybe this thing is a bit like cobol.

Re:It actually doesn't look that good (1)

Monkeedude1212 (1560403) | more than 4 years ago | (#30240106)

I went through a couple pages of the tutorial, and I agree, it doesn't really make anything EASIER. As a programmer it sure isn't easier to Read then something Like Visual basic, or even Java. I find myself trying to figure out some of their nuances more then I am trying to follow their code, for example, they use Repeat instead of While. Were while statements one of the things that confused most people?

And Essentially, yes,
"put item 1 of allItems into myArray"

IS easier to read, however if you don't know how arrays work it won't do you any good. And essentially if you DO know how Arrays work, then

myArray.Add(allItems[1])

Shouldn't confuse you at all. Essentially its all syntax, and once you learned one 3rd generation language you've basically learned them all, because an If is and If and an Else is an Else. No matter how many brackets you need, it'll still do the same thing.

Now, if you find the Syntax in Java scary - you should take a look at some Lisp.

Re:It actually doesn't look that good (1)

azav (469988) | more than 4 years ago | (#30240350)

But isn't "myArray.Add(allItems[1])" visually more confusing?

Illustrated a little, it might look like this:

objectToDoSomethingTo.functionInObject(usingAnotherArrayVariable[itemNumberOfItemInArray])

In the majority of languages today, this is the way things work but doesn't it seem really backasswards when compared to the simple and verbose "put item 1 of allItems into myArray".

Certainly not English (1, Insightful)

Anonymous Coward | more than 4 years ago | (#30240004)

Natural languages are full of ambiguities, so these "natural language programming environments" always use a more formal syntax (and semantic) and only look superficially like a natural language. Until you can actually talk to a computer (and the computer can take all the context into account), programming in such a language irritates people to no end when they stumble upon one of the differences between the programming language and the natural language it imitates.

Programming is the act of understanding and structuring a problem. The coding that follows is practically trivial compared to that first step. There's certainly a need for more programmers, because more and more is automated and someone has to write that software, but please don't create the impression that you can eliminate thinking from programming. Fixing bad code costs more than writing good code.

AppleScript? (1)

BoxedFlame (231097) | more than 4 years ago | (#30240014)

Is it just me or does their language look just like AppleScript?

And how can you claim that:
set foo to bar on baz
is "less code" than
bar.foo = baz
? 90% less? Yea right.

Re:AppleScript? (1)

johanatan (1159309) | more than 4 years ago | (#30240056)

Maybe it is a functional language. They make the same claim. The extra few characters for English syntax are far outweighed by the structural gains. [Of course, I know this isn't true as even most o-o/imperative programmers don't really understand the functional model of computing].

Re:AppleScript? (1)

MasterPatricko (1414887) | more than 4 years ago | (#30240290)

From what I see rev4 is certainly not functional programming. Functional programming is approaching programming from a mathematical point of view. Certain problems - especially ones that can be isolated to a mathematical definition - are much easier to solve using functional programming rather than imperative programming. Other problems - especially when interfaces to the user and other programs are needed - become a lot harder. So I'd be interested to hear what functional programming language is claiming a 90% reduction in code in all cases ...

Recursive acronym for a dumbed down language (3, Funny)

Skapare (16644) | more than 4 years ago | (#30240016)

Here is my suggestion for a recursive acronym name for the next dumbed down programming language: Imbecile Means Beginner's Easily Coded Interactive Language Environment

Submarine article (4, Insightful)

bjourne (1034822) | more than 4 years ago | (#30240018)

Paul Graham [paulgraham.com] wrote a very informative article [paulgraham.com] about "news stories" like this one many years ago. And congrats to the company behind RunRev, it is not that often /. runs slashvertizements for costly commerical software no one has ever heard of.

Too many keywords (1)

Frans Faase (648933) | more than 4 years ago | (#30240024)

With a language with so many keywords, there are almost no valid variable names left to be used. The list is way too long. Even scrolling through the list takes some time. To me it seems more than half of the keywords are used in less than 1% of the functions. Finding the right keyword for calling some function is going to take a long time. It seems to me that this is the wrong way to solve the programming problem. I strongly doubt whether the claims that this environment save you money are based on solid facts.

Marketing Fluff (0)

Anonymous Coward | more than 4 years ago | (#30240054)

Please stop sending marketing fluff in as if it is news.
The related article and the supposed replies on it have been constructed as a media release for this companies programming product.

I could argue a number of points about this article and the underlying software.

But what is the point? To help market this product for a company that wants to do viral marketing?

No thank you.

If you agree: mark me up but please don't reply/add to this.

Rev4 syntax (2, Insightful)

ickleberry (864871) | more than 4 years ago | (#30240072)

is it just me or does an ordinary 'easy' programming language like PHP, VB or python seem much easier to work with? the syntax of rev4 seems far too verbose, not nearly enough parenthesis.

also if you understand how the machine works is there any real need to program in 'plain english'? the syntax doesn't quite make sense to me like other languages would. for example it seems more logical to have a loop to move something along by a tiny amount and then wait a bit rather than telling it to move a thing from one side to the other "in 5 seconds". with plain english you also end up with stuff that has multiple equally valid meanings

i have nothing against making programming easier, just don't think this is the right way to go about it. a good IDE with syntax highlighting and prompting features like VB and a good set of libraries with decent error handling is better than any of this plain english stuff that introduces mostly redundant keywords for the sake of having plain english

Re:Rev4 syntax (1)

Monkeedude1212 (1560403) | more than 4 years ago | (#30240268)

not nearly enough parenthesis.

Pretty sure thats what they were going for, but I agree with you.

It doesn't matter that you don't have to use any Brackets when you use an Array with Rev4. If you know how Arrays work you are used to calling their functions, then it makes MORE sense to use the

Arrayname.Function(variables)

syntax every other language uses instead of their

Perform this Function with Arrayname using variables

Syntax that they use in Rev4. I just don't like it, it makes it LESS readable to anyone who knows how to program, and I don't really see anyone wanting to start programming picking up a new language that isn't broadly used (Like C++ or Java or VB)

Re:Rev4 syntax (1)

Nerdfest (867930) | more than 4 years ago | (#30240272)

I'm not even sure the language is that relevant in most cases. Bad programmers will write bad code in any language ... and most people, especially your 'average Joes' are bad programmers. The bad code will almost always be there, some languages just make it easier to spot and fix. Some languages put up enough of a barrier that most non-professionals don't try to use it. This is not necessarily a bad thing.

Re:Rev4 syntax (1)

azav (469988) | more than 4 years ago | (#30240288)

To your main point, yes. Yes it is.

Easier, that is.

Why do you feel the need for parenthesis? I find the curly brackets and parens more cumbersome then they are worth in many cases.

Boh (1)

cheesybagel (670288) | more than 4 years ago | (#30240096)

Ah HyperCard [wikipedia.org]. Never used it because Macs were too expensive and mostly monochromatic at the time. But I used something which was probably similar: INOVAtronics CanDo!

The problem with such solutions is that they are usually inflexible in terms of the applications you can make and often produce lower performing applications (i.e. use more memory and processor time). I still remember corporate suits droning off in business magazines in the 90s how Rapid Application Development tools would soon make programmers obsolete leading to a wondrous wave of cheap microserfs. RAD tools only had staying power in things like GUI design tools. This "Revolution 4.0" just seems like a hyped up "web 2.0" version of the same thing.

Re:Boh (1)

dbcad7 (771464) | more than 4 years ago | (#30240204)

My Dad was into Hypercard.. He spent hours making a fancy CD catalog "program",, It's not what I would call programming, but I wasn't going to tell him that.. From what I remember it was a combination of database, animation and graphics.. although a little more complicated, you could just as well call making an animated GIF "programming".. and maybe it is..

The past (0)

Anonymous Coward | more than 4 years ago | (#30240102)

The programming world seems to run in about a 30 year cycle. Java = Pascal reinvented (pointers are too hard) Java bytecodes = UCSD Pascal p-system reinvented picoJava hardware = Intel i432 reinvented Revolution 4.0 = COBOL reinvented - similar claims Those who fail to learn from history are doomed to repeat it.

Re:The past (1)

osu-neko (2604) | more than 4 years ago | (#30240310)

The programming world seems to run in about a 30 year cycle. Java = Pascal reinvented (pointers are too hard) Java bytecodes = UCSD Pascal p-system reinvented picoJava hardware = Intel i432 reinvented Revolution 4.0 = COBOL reinvented - similar claims Those who fail to learn from history are doomed to repeat it.

And those who don't know history are doomed to post idiotic shit about it. (BTW, Pascal has pointers, and as a language is about ten times closer to C than to Java. Code translates between the two pretty easily, mostly all the same concepts, types, and structures, Pascal just has a more verbose syntax and C has looser type-coercion rules.)

Programs written in English? That's COBOL! (0)

Anonymous Coward | more than 4 years ago | (#30240146)

I'm sorry, but I don't see what the fuss is about.

How is whatever Revolution is doing any different from
        MULTIPLY HOURS-WORKED BY HOURLY-RATE GIVING GROSS-PAY
or
        PERFORM WEEKLY-CALCULATIONS VARYING WEEK-NUMBER FROM 1 BY 1 UNTIL WEEK-NUMBER IS GREATER THAN 52
?

Face it, programming languages are designed for human consumption. Computers don't care whether you wrote it in COBOL or C++ or Revolution; they only know machine language, not programming language. The purpose of a programming language is to allow the programmer to express a set of instructions in a way that s/he and other programmers understands.

Programming and System Design (1)

prefec2 (875483) | more than 4 years ago | (#30240150)

Today the real problem is in system design. While is some cases you create a special language to solve a special problem of a domain (domain specific languages DSL), in other places you use generators. Even though modern languages are all able to express component, class and object structures. In principle you can express modern OO designs in any language. If they have created a new language then they can most likely reduce the number of typed characters, but what they cannot reduce is the number of rules and definitions which make up the specification of the application.

Also most time in modern software design is spent for requirements engineering and development of the architecture. Followed by test planning and test implementation (if not done automatically from the specification). And only 1/3/ - 1/4 of the time (sometimes even less) is used for implementation. So honestly I do not believe their advertisements and I do not believe that their language is sooooo much easier to use than all the other languages available.
 

Read-only languages... (1)

PhunkySchtuff (208108) | more than 4 years ago | (#30240174)

I, whilst not being a programmer, do dabble in programming and I find these "natural syntax" languages, such as AppleScript, to really be read-only languages (as opposed to something like perl that's write only)

Reading through the code for an AppleScript program, it's pretty easy to pick up what's happening even if you're not overly familiar with the language. What is difficult is to write it properly, as it's so close to English, yet it's still got quite a rigid and structured syntax, so you need to use the exact form for it to work.

Re:Read-only languages... (1)

osu-neko (2604) | more than 4 years ago | (#30240242)

Pretty much, yes. Anyone can read the code, but only programmers can write it.

If someone suggests this can allow non-coders to code, they're over hyping it. Still, it's nice for the sake of actual programmers trying to read and maintain other people's code. But, programmers can read code anyhow, so if you think it makes maintenance more than just a tad bit easier, you're also over hyping it.

In other words, it's kinda nice, but if you expect any sort of big benefit from it, you'll be disappointed.

C++/ADA (1)

incubbus13 (1631009) | more than 4 years ago | (#30240190)

When I went to the CS department at college, they informed me the C++ classes I took in junior college were no longer applicable to their CS degree, because they'd changed what was CS210-211 to ADA from C++. "Because we wanted students to spend less time debugging and more time writing code". Er...I'm no master coder, but in my experience, any project over 100 lines involves spending more time debugging than actually writing code. I thought that's just how it was.

I am all for languages that are easier to use. But coding should be hard. It is hard. And setting people up with the expectation that there's very little debugging involved, or that they can write killer apps in 45 minutes is crazy and counter-productive.

K.

Re:C++/ADA (1)

azav (469988) | more than 4 years ago | (#30240274)

I beg to differ. Coding doesn't have to be hard. Debugging is debugging... or is it problem detection and solving? Clarity of your code and clarity of the language structure you are using either helps or hinders debugging.

Part of coding is how good your IDE is in telling you what is going on. Another part is how understandable your code is and that is dependent on the structure of the language you are coding in.

One word: Haskell! (1)

Hurricane78 (562437) | more than 4 years ago | (#30240234)

It alone moved me from a normal commercial software developer, to the forefront of scientific development in informatics, and made me so much a better programmer at normal programs, it’s not even funny.

Then again, I am one of the rare kind of people who still think that intelligence is cool, and being better because you worked to be better, should be rewarded. Instead of rewarding those who do worst, and dumbing everything down, just for the nature to create better idiots, and thereby creating a feedback loop straight to Idiocracy.

But maybe I will write the heart-lung-machine software then, while they write the VB and Access applications of the future. ^^

Is it really dumbing down? (1)

azav (469988) | more than 4 years ago | (#30240238)

Is it really dumbing down or are the languages that we use more obtuse than necessary? The common syntaxes of the day are left over from language design when every bit mattered. If English-ish syntax is more clear, then why not use it?

Isn't it more about clarity of the language than about shortest code possible?

Easy to read, yes (0)

Anonymous Coward | more than 4 years ago | (#30240256)

I can imagine that a lot of people that aren't programmers looks at this language (and the examples) and thinks that it's easy to learn.

Sure, it is easy to read, but is it easy to write?

Don't be deceived (1)

davidwr (791652) | more than 4 years ago | (#30240278)

/* Shortest useful program ever. */ /* prerequisite: Someone else already did the heavy lifting. */
#include
int main(int c, char **v)
{
    initializestuff();
    for(;;) {
        doforever();
    }
}

There, I wrote an entire operating system in less than 10 lines!

The real issue... (1)

ironicsky (569792) | more than 4 years ago | (#30240284)

The real issue isn't how easy a languages command structure is, because memorizing function calls and syntax is easy. The real problem, IMHO, is people... People are not taught to think analytically and structurally. That is the problem. How can you code without analytical skills. When I learned programming 10 years ago I was taught to draw it out on paper.. Flow chart style. If the flow chart starts getting to big you need to split off a function, eventually creating a rough sketch of how your program will work. People with analytical skills can learn anything if explained how something works.

On another note, I don't want programming languages getting to the point where its like speaking english... Imagine the code... *shudder*

All you young kids with your fancy 1s and 0s (3, Funny)

davidwr (791652) | more than 4 years ago | (#30240294)

When I was a boy all we had were 1s, and we had to break those off of trees. If we wanted zeros we had to find a willow tree and bend the one around until both ends met....

Now get off my lawn!

I'm not convinced at all (1)

Mutatis Mutandis (921530) | more than 4 years ago | (#30240308)

Look at the tutorials; for example the File I/O [runrev.com] code. I concede that to the average person without any programming education, this may look simpler than its C++ or Python counterpart, but is this syntax really simpler? I think not! On contrary this bit would be easier to code, with a rather lower risk of time-consuming compile errors, in many traditional languages.

I've seen enough attempts to "dumb down" computer languages for people whose computer programming examination only asked: "Which of the following three is not a valid BASIC keyword: (a) PRINT (b) GOTO (c) TERMINATE?" (I kid you not -- when I was at university, this was the level of knowledge expected from bachelor's students in, if I remember correctly, veterinary medicine.) Generally these languages did not succeed in making computer programming easier; they only succeeded in making it look superficially easier. The threshold appears lower for the uninitiated, but after the first three days there is no advantage and you're stuck with a stupid syntax.

The real choice, as far as I can tell, is between a "minimalist" design of a language which provides only those features that a developer is expected to really need, and a "maximalist" design that provides the extra features a programmer might like to have to save him some time and make code look more elegant. The pair Java and C#, despite their similarities in syntax, exemplify the contrasting approaches very well. Personally, having seen how even professional programmers can mess up their exception handling and mismanage their dependencies, I am firmly minimalist. Never mind time saved in writing code, that barely matters. What matters is time saved in code reviewing and debugging, and that is nearly always easier in a minimalist language.

That said, I hope there would be a market for a good, simple language suitable for automation purposes: Something that is suitable for anything from writing macros in a text editor to controlling a complicated robot, for which people now usually reinvent the wheel -- generally producing something roughly triangular with an off-set axle.

Even in Universities (3, Insightful)

Anonymous Coward | more than 4 years ago | (#30240322)

This can be seen even in universities, there are CS majors with no education in ASSEMBLER or C during the whole studies, some haven't even used C++.

And money dictates here too. We are forced to study that horrible, disturbed nightmare that is Symbian for mobile development class, although I did manage to talk the lecturer into allowing one half of the course test to be for Android if one wanted it to.

I don't consider myself a good coder; my experience comes via a hobby from a simple c-like language which pretends to have objects. I've also seen some so, so much better coders, especially within in the demo scene, but even I can see that the level of a regular CS student is horrible. There are few rare gems out there, but the average is nasty. It'd be absurd to expect them to learn those languages to any decent level within the regular course times either.

The efficiency of one's code is hardly ever noted within courses. It's good if it works. There's probably just so huge need for 'bulk coders' and other 'it professionals' that they've had to dumb down most of the courses. There are only a few rare courses which really challenge you (logic programming being the usual cause), and they're not needed to get the papers.

It's infuriating having to drowse through such highest level education.

VisualBasic (1)

goathumper (1284632) | more than 4 years ago | (#30240338)

I remember the days of VisualBasic, when it was billed as a means to facilitate the development of applications without requiring any real programming or software (or computer, for that matter!) expertise. I also remember what came after those days...

Simply put - though VB was "wildly successful" - but how many pieces of software built on it are still around *because they were built properly*? Most of those tools have been thrown aside because they were grossly inadequate in performance, architecture, design, etc.

I was a witness to countless fusterclucks and saw how many systems had to be re-done from scratch because some genius businessman believed what he read on the brochures only to realize that there was no such promise and now his hordes of customers were demanding delivery on the promises made. Needless to say, there were no shortage of *REAL* programmer jobs in those days :)

The problem was never with the language per-se, as I'm sure the problem won't be with Rev4. The problem was always with design, architecture, concepts, and implementation choices. As noted above by the xkcd reference, there's no substitute for clarity regardless of the tool you choose to implement your program.

I'm not knocking the tools themselves, I'm knocking the fact that they're billed as ways to "bring programming to the masses".

Just like not everyone should handle nuclear material or toxic substances or operate on a human body, not everyone should *program* computers. As such, the really big benefit I see for this kind of tool is as an end-user interface mechanism (or facilitator) - especially in conjunction with language recognition. There are some interesting ideas there that are definitely worth exploring...

Few things.... (1)

dragisha (788) | more than 4 years ago | (#30240340)

a) Any system even fools can use - will be used only by fools.

b) I really liked these "up to"s... They tell so much.

Why not dumb it down? (1)

harmonise (1484057) | more than 4 years ago | (#30240342)

Is there a reason that it should not be dumbed down? Should it be kept difficult for some reason? If a person can adequately express their problem and how it should be solved to a computer, and the computer can take that expression and solve the programmer's problem, I don't see what the issue is.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...