Slashdot Mirror
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.'"
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.
My work here is dung.
People have been saying this since FORTRAN meant you didn't need to know assembly language to make use of a computer.
You'll never find a programming language that frees you from the burden of clarifying your ideas.
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
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?
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.
You just got troll'd!
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.
http://www.virtualschool.edu/mon/SoftwareEngineering/BrooksNoSilverBullet.html
If I have seen further it is by stealing the Intellectual Property of giants.
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.
No, I will not work for your startup
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.
Deleted