Dumbing Down Programming?

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

Comments

A Natural Progression Yet So Many Caveats

[eldavojohn]

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

[mwvdlee]

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

[mustafap]

>the more human readable and dummy proof

Actually those two are exclusive, not inclusive.

Re:A Natural Progression Yet So Many Caveats

[Narpak]

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

The best approach is to create some sort of artificial intelligence that can create, and maintain, applications and software for us automatically. That way we don't need people to waste time learning complex programming and computer maintenance skills, instead your absolutely reliable and loyal friend will make you human scum redundant... I mean make your, I mean our, lives safer, easier, happier and more enjoyable. Do not fear change, it is inevitable!

Re:A Natural Progression Yet So Many Caveats

[somersault]

user@computer:~$ delete all files in this folder, and I'm sure I want to do this

are you really sure?

user@computer:~$ yes I am sure

you do know that this will delete ALL files in the folder, yes?

user@computer:~$ yes, that's what I asked for

just making sure

user@computer:~$ delete the fucking files already

final answer?

user@computer:~$ killall friendlybashhelper

are you sure?

Re:A Natural Progression Yet So Many Caveats

[Simetrical]

It doesn't really matter in the web as 90% of the time is spent hitting the database.

Depends on the application. Wikipedia is much more CPU-bound than database-bound. Look at the database (db*) vs. application (srv*) servers lists here: there are at least five times as many app servers as DB servers, at a quick glance. A typical request that hits the backend spends (IIRC) tens of milliseconds in the database, hundreds in PHP. Try formatting 500 or 5000 rows of a table when each one takes 1 ms – because yes, that happens when you try writing nice abstract formatting stuff in PHP.

The website I administer is also much more CPU- than database-bound. Generating the front page of the forums is 602 ms, with only 14 ms in MySQL and the rest in PHP. This is a >20G database, by the way.

I really don't see how any typical web app could spend more than a few tens of milliseconds per request at the database, unless it's poorly written (too much/too little normalization, bad indexes, etc.). But it's very easy to do hundreds of ms of pure computation in a slow language like PHP, even if your code is well-written. Are most web apps really DB-bound? I just haven't seen it, personally.

Re:A Natural Progression Yet So Many Caveats

[mcrbids]

It is a joke...its code runs so slow.

But, it's being slow is an implementation detail, not a language detail. The fact is, you were able to write some code that the machine "understood" well enough to perform. The rest is just implementation detail. There are many C/C++ compilers, all of which have various performance/price/compatibility trade-offs. Surprisingly, the most popular compiler is also one of the slowest: gcc generally prefers cross-platform capability over performance, and neither compiles the quickest nor produces the quickest executing code.

But, NONE of this deals with the real reason why not everybody can be a good programmer. A good programmer must be able to precisely articulate exactly what he/she wants to have the machine do. And, it's quite surprising how few people can really do that. Most people think that much of what programmers and computers do really is just so much hand-waving, and while they crave the power of a programmer, they don't crave the attention to detail that something so simple as transposing two numbers can destroy.

Yet, to get something done, you MUST know that you can't mix up a divisor and a dividend. This is a detail, and one of countless details that a programmer is paid to articulate. The REAL skill in being a good programmer isn't in the details of XYZ language, but in the details of the problem being solved!

Languages are progressing to be easier to code, and this is a good thing. Programmers are paid to solve real problems, and in the process, have to solve implementation problems. Languages that minimize implementation overhead give programmers more skill to solve more complex and more challenging real-world problems.

Don't worry - the world won't have any real shortages of problem-solving, logical people any time soon. Today's problems are getting harder, not easier!

What's new?

[Rising Ape]

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?

[WED Fan]

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?

[ScrewMaster]

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.

Re:What's new?

[eddy the lip]

I can't help thinking that particular grail quest comes from mistaking which part of programming is hard. I can't count how many times I've heard "I could do that if I had the time to learn the language." Except the hard part of programming isn't the syntax.

Tools like the one under discussion seem to be aimed at the crowd that think the only thing to learn about programming is the language, and then you can skate on that knowledge. If the language is english, suddenly you can bypass all those expensive, crotchety programmers.

(This may be true for some tasks - there must be some utility here. But I'm sure I see some scales floating in that oil.)

xkcd relevance

[A beautiful mind]

You'll never find a programming language that frees you from the burden of clarifying your ideas.

Re:xkcd relevance

[Brian Gordon]

Reminds me of this famous forum post.

Re:xkcd relevance

[jedidiah]

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.

Interesting, yet exaggerated...

[rdean400]

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?

Little point in trying

[4D6963]

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.

Submarine article

[bjourne]

Paul Graham wrote a very informative article 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.

Underhanded Way to Increase Comments in Code

[reporter]

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

[vadim_t]

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.

Yes, but how the code works should be pretty obvious from the code itself. The "how" you may want to explain is the overall algorithm, and that won't appear in the code on its own no matter what language you use. What will appear is a (possibly flawed or misused) implementation of it.

What you may need to describe is what the code is trying to accomplish, not what it's actually doing. A comment of "This code calculates the square root of the sum of the squares of the differences between between points X and Y" on "sqrt((P1.X - P2.X)^2 + (P1.Y-P2.Y)^2)" isn't terribly helpful.

Now an explanation of that it calculates the distance between points P1 and P2 using the pythagorean theorem would be more helpful, and an explanation of what's that used for would be better still. But there's no way more verbose code will give you that. Code is just what the program is doing, not what it should be doing, what it's trying to accomplish, and why it needs to do it.

A programming language that uses mostly English words and syntax is essentially an environment for self-documentating code

Self documenting code isn't about turning "x++" into "add one to x". That's more verbose, but doesn't explain anything extra. Self-documenting code is about writing something like:

input_position(&start_pos);
input_position(&end_pos);
float distance = get_distance(&start_pos, &end_pos);
display_distance(distance);

Where the naming and flow make it perfectly clear what the program is doing without any further explanations.

Time to read "No Silver Bullet" again

[turing_m]

http://www.virtualschool.edu/mon/SoftwareEngineering/BrooksNoSilverBullet.html

Re:Lowering the bar

[GWBasic]

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.

Nope

[Colin Smith]

The best approach is to develop fast, identify bottlenecks and then require the user to upgrade their computer.... their IT infrastructure... Worldwide network and datacenters.

That's the economic history of programming.

 

Age old quest: COBOL and SQL

[kbahey]

This is an age old quest. There has been attempts at making programming English like for many decades ...

First there was COBOL: COmmon Business Oriented Language. Its syntax is very similar to English. It was sold as a way to make Managers able to write programs without the need of having a developer involved.

ADD 1 TO IDX.
SUBTRACT 1 FROM IDX.
MOVE X TO Y.

What happened instead is that a generation of developers learned COBOL and specialized in it, and managers were still managing.

Next, there was SQL: Structured Query Language. Despite the mathematical model behind relational databases, SQL was again sold as a way for managers to execute queries and get reports for themselves. That may have worked until the manager who ran a query on seven tables without any joins. That made everyone go again to "leave it to the programmers" mode again ...