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.
At first I read that as "PHB has dumbed down programming too much". But that is part of it.
now we need to go OSS in diesel cars
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.
now we need to go OSS in diesel cars
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?
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.
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.
jaymz
You get what you want. Someone else gets what they want. What's to get bent out of shape over?
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!
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
Whose idea was it to put light peach text on a white background?
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.
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.
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.
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
now we need to go OSS in diesel cars
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.
Football Odds
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.
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.
ACs don't waste your time replying, your posts are never seen by me.
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.
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
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.
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.
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.
Specialist Mac support for creative pros, Melbourne
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.
It can't get dumber than this.
http://dilbert.com/2010-12-13
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.
The world's burning. Moped Jesus spotted on I50. Details at 11.
Does 'magic' still work?
Isn't SQL somewhat like that? I mean:
select color from hair where name = "Mike";
http://dilbert.com/2010-12-13
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. ^^
Any sufficiently advanced intelligence is indistinguishable from stupidity.
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?
- Zav - Imagine a Beowulf cluster of insensitive clods...
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.
If you mod me down, I will become more powerful than you can imagine....
/* 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!
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
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.
If you mod me down, I will become more powerful than you can imagine....
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*
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!
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Look at the tutorials; for example the File I/O 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.
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.)
"Convictions are more dangerous enemies of truth than lies."
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.
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.
The world's burning. Moped Jesus spotted on I50. Details at 11.
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...
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.
http://opencm3.net, http://www.nongnu.org/gm2/
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.
Cory Doctorow talking about cloud computing makes as much sense as George W Bush talking about electrical engineering.
If English was a language easy to communicate clearly and unambiguously what we wish to do, we wouldn't need lawyers.
Phillip.
Property for sale in Nice, France
There are still a significant number of shops running Office 2003, so it's still true today.
The world's burning. Moped Jesus spotted on I50. Details at 11.
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
Even if you can bring programming to the masses, workaday programmers better hope that nothing those masses produce becomes important, because such things inevitably land on their desks when they need a tweak and the author has moved on. Maintainability is a quality that is difficult for even experienced programmers to put into their work. First timers rarely see the costs a year down the road of any implementation decisions, usually because they don't yet know there are multiple implementation possibilities.
What do you mean they cut the power? How can they cut the power, man? They're animals!
I was already well into programming when I bought a Sharp MZ-80k. While everyone else was shipping with a version BASIC, the Sharp shipped with Pascal. That probably shaped my good opinion of Modula-2.
Politics is the art of looking for trouble, finding it everywhere, diagnosing it incorrectly and applying the wrong fix.
I haven't actually seen this language, so I can't say for sure, but I would argue that many programming concepts are easier to express in actual code, or at least pseudocode, than in anything truly resembling English. Even when we talk to other programmers, we talk about concepts like strings and characters, which are ultimately the language of the machine, not us.
So, this could make it easier to learn to program, but this should not be seen as something in the same vein as Excel, Access, Filemaker, or anything of that nature. Those are tools that let non-programmers make a program, and non-DBAs make a database -- but they are both inferior for real programmers to use, and even when they aren't, they mean the programmer doesn't have to learn what's going on under the hood.
But as a programmer, you do need to know what's going on under the hood. When the abstraction breaks down, you need to know how and why. It's one thing to let the garbage collector handle memory management, but if you understand what it's doing, you can make little tweaks to make your program smaller and faster, while still letting the garbage collector do the heavy lifting.
In other words, read The Law of Leaky Abstractions. As Joel says:
The law of leaky abstractions means that whenever somebody comes up with a wizzy new code-generation tool that is supposed to make us all ever-so-efficient, you hear a lot of people saying "learn how to do it manually first, then use the wizzy tool to save time." Code generation tools which pretend to abstract out something, like all abstractions, leak, and the only way to deal with the leaks competently is to learn about how the abstractions work and what they are abstracting. So the abstractions save us time working, but they don't save us time learning.
So, in other words, the real question we should be asking is whether this tool is better than existing tools, like Python or Ruby. There have been other attempts at RAD which I think fall far short of that goal.
To answer the question "why not", you have to understand the damage that is done by allowing non-programmers to try to program. Think of the damage which is done with this simple Visual Basic command:
I mean, that's almost as bad as GOTO, probably worse, because that leads to silent errors. It leads to growing a codebase full of errors that happen all the time, of dead code, and of random Bad Things happening, all of which would at least make your app raise a noisy error during development (so you'd fix the problem). But no, you silently ignore them...
That isn't strictly VB's fault, but there seem to be so many crappy VB coders for whom this was the next logical step after Excel formulas. Since the actually decent coders tend to prefer things like C# (in the MS world, at least), I don't see much of a reason for VB to exist, and it seems to actually be causing more harm than good.
That's where I view every attempt at a "dumbed down" language -- if it doesn't improve things for actual programmers, it'll probably do more harm than good.
Don't thank God, thank a doctor!
The funny thing is, when I read the tutorial, they lost me on the "Getting Started" page.
As soon as they start with GUIs and toolbars with icons that you need to click, I don't understand what is happening anymore.
Please correct me if I got my facts wrong.
Am I the only one seeing the irony of calling something "Revolution" and then adding version number 4.0 to it?
I think that about sums it up nicely...
I am a programmer around long enough to literally hear bulldozers and chain-link fences clinking around big holes in the ground at the sight of the word "developer". (Insert more hallucinogenic curmudgeonly grumbling here.)
More on topic, I have no qualms admitting that "fast and easy" programming "solutions" might indeed be so, but still can't help but wonder what else is missing. What are the consequences of "fast and easy" programming?
Those words bring to mind news articles of car and train wrecks, where speed is always an aggravating factor, and attaining that speed never seems too difficult or too ambitious at the onset, prior to the accident.
A wreck is definitely not desirable if one aspires to Quality (in the ZAMM --Pirsig sense), for a wreck completely removes the moment of perception from the scene, by removing the perceiver (or more precisely, the motivating force (perhaps in the gravest cases, the life) of the perceiver).
I think, rather than pushing "fast and easy", a better pair of adjectives would be "strong and flexible" (like a rope, or a towel, say). The programming languages, environments and mindsets based on these fundamental metaphors admit guidance from a mentor (on the "other end" of the experience divide, pulling) quite readily.
The consequences may in the end result in "fast and easy" development of the program, of the programmer, of the mindset, anyway. It depends not only on the budding programmer, but also on the relationship between the teacher and the student (both of whom may be the same programmer, why not?).
Creativity is not limited to people who have the skills needed to bring their dreams to reality. Low level programming languages stop many creative people from bringing their ideas to the computer. High level languages like Revolution allow more people to create their own software, whether it is single-use utilities, applications for personal use only or commercial applications.
:-)
But this is always how technology develops: the pioneers have to do everything the hard way, then those of us who follow behind can use their tools to make things easier and easier. Of course the people who have invested in learning how to do things the hard way feel resentful of the newcomers who seem to be getting so much for free, but progress cannot be halted and when easier ways exist, why should we insist that people learn to do things in any way that is more difficult than the task requires. On that basis, programs should only be written in machine code, not this new-fangled assembler
And on the other hand, C and C++ practically force you to be a psychic in finding bugs, because the memory allocation merrily ignores duplicate freeing of memory till it barfs a second later. You can use debug memory allocators, but then the program is so slow that you never get to the situation you need to debug.
Hey don't blame me, IANAB
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 ...
2bits.com, Inc: Drupal, WordPress, and LAMP performance tuning.
They said the same thing about COBOL.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
But languages like VB and PHP practically encourage it.
How? Its one thing to say it, and another thing to justify it. In my experience, VB has all the same basic design-freedoms that the C language has (functions, structures, a wide assortment of branching instructions), but also has classes and mostly-enforced garbage collection.
I am wondering why you've picked VB as the language easy to make a mess of things in, when quite clearly its even easier in C.
BASIC is a common language for business applications because 30 years ago people who took a programming course learned this language. You couldn't buy a desktop that didnt come with some sort of BASIC (for many computers it was in ROM), so it made sense to teach it. So there the company is, with many employees but no professional programmers on staff.. but Bob from accounting listed his BASIC programming credentials on his resume. So lets give Bob a few days before crack at it before we go looking for an expensive alternative like contracting the work out.
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
That program probably did not start as something worthy of a Design Monument.. that thing of beauty that gets the author to pat himself on the back. Also remember that in almost any language, its easier to write code than to read it. Mature code ends up looking ugly, but all those operations have or had a real purpose. That funny looking bit whose purpose you can't understand, thats probably a bug fix and you too will need to do something like it somewhere.. and it too will look just as ugly.
Its easier to write code than to read it. Design Monuments don't last in the real world.
"His name was James Damore."
Sure. Dumb it down far enough and many of those writing software today will be able to do it.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
Pascal just has a more verbose syntax and C has looser type-coercion rules.
The two reasons that I try to use neither, especially the bit about C's non-explicit type promoting. It eventually leads to a hard-to-find bug in any non-trivial project.
"His name was James Damore."
Heh - sidestepping the non-random causality of programming and reclusive...
To grow a field it helps to create a large base of people who at least "appreciate" it. Pick the exact timing you like, but suddenly we went from when growing up learning computers was "nerdy" to "connected".
Businesses are the art of getting midline people to handle some stuff that just burns hours, saving the power hitters to really churn out something. "Using 90% less code" seems to be the kind of thing that's made for this.
My first Journal Entry ever, in 8 years! http://slashdot.org/journal/365947/aphelion-scifi-fantasy-horror-poetry-webzine
I remember reading almost all of these exact same marketing buzzwords and hype ten years ago. The only difference was that then the "amazing, revolutionary language" was called REBOL.
Exact same business plan, as far as I can tell. Exact same hyperbolic language. Enough so that I wonder if the same copywriter did a search/replace on the old pamphlets. It's yet another moderately OK high-level language, but that comes in three versions:
(1) Free (of cost), but fairly crippled
(2) Expensive
(3) "Enterprise", i.e. REALLY expensive.
And just like REBOL ten years ago, it promises "revolutionary" cross-platform support, while dropping or being slow to update the non-Windows versions.
The linked blog/review of the language seemed to have comments solely from paid-shills. The reviewer himself was interesting, but all the comment at foot read like almost certain astroturfuing.... gee, just like REBOL did back in the 1990s. When you actually look at the "amazingly readable and compact" code... well, it looks a lot like AppleScript and a few other similar approaches to syntax. But one thing I noticed in particular is that the "unbelievably short" code samples were about the same as the ones I'd use in Python, or Ruby, or Perl, or AWK. At least in length; Python feels more readable to me... once you give up the silly conceit that Rev syntax isn't syntax because it kinda-sorta-a-little-bit reads like English. Rev *is* shorter than Java or C++, but that's not exactly anything amazing.
Buy Text Processing in Python
From TFA: "I suppose that adds up, 90 per cent less code equates to ten times faster."
Really? I suppose you can write haiku ten times faster than stream-of-conscious recordings, too?
There's one thing that computer code and natural language text have in common: For both, confusing "writing" with "typing" is moronic.
Access's VB interpreter is very damned close to VB6. I have no idea what you're talking about.
The world's burning. Moped Jesus spotted on I50. Details at 11.
I'm already appalled just by seeing all these stock happy face images. Also, never heard of it before. What is this for stuff, man.
Pascal was the second language I took a class in, and it basically only in that class I used Pascal. I wanted to take Modula but it wasn't taught where I went.
Falcan
Should there be a Law?
Seriously, this is slick. I don't mean the language (it appears I need to install a plugin to view samples, which is a bit silly - I just want to see the language). No, I mean the advertising. Post it to slashdot with a title the casts it in doubt; link to the web site that requires you to install the plugin... poof! instant installed client base.
For some reason there are those in the programming profession (usually the "we code to live" crowd who will slide easily into management as soon as possible) who cannot seem to get it into their thick skulls that "everybody wants to program a computer" is just about as true as "everybody wants to repair their own car." Non-programmers are that way because they are neither emotionally nor intellectually equipped by either nature or nurture to be a computer programmer (let alone a good one). Only 1% of the Earth's population are scientists or engineers. Making the tools employed by software engineers easier isn't going to make it (more) interesting or any easier for that 99% of the population who are not.
As far as making programming easier for programmers... Don't you get it? We like it hard. The harder the better. Most of us would be as happy as pigs in shit if our masters would let us program everything up in assembly language. If we could get away with it, every shell script would be written as one, big, fat, hairy regular expression. Real programmers don't want "easy," we want "control" and are more than happy to put up with the lack of ease having more control invariably entails. Programming languages that are more like human languages? That sounds like documentation to me. And you know how much programmers love writing documentation.
Computer programmers are not your typical breed of cat. To us, 200 milliseconds is a long time. Indeed, every day at work we manipulate space and time with hardly giving it a second thought. We are the poster children for OCD. We'd rather be "in the zone" struggling to craft an elegant solution to a very difficult problem than be in the real world struggling with very difficult people. We despise organized fun. We can't understand why "normal people" don't get the concept of indirection. We have working memories that rival those of Chimpanzees. To us, "average," "normal" and "easy" are swear words. And, truth be told, most of us would do what we do without pay if we could (and, judging by the number of open source programming projects on the Internet, a significant number of us can). We don't code to live, we live to code. We can't resist an intellectual challenge. If you want a programming project done quickly, just tell the programmer(s), "There's no way you can do that in a <pick-your-time-period>!" The best way to avoid a programmer at family gatherings? Give him or her a book of (mathematical) puzzles. You won't see him/her again until every puzzle in that book has been solved. Does any of this sound like (part of) a description of "your typical business person?"
Programming computers isn't difficult because the tools aren't close enough to English (or whatever human language you prefer). Programming computers is difficult because highly-structured problem solving is difficult. And its not really something they teach in school. Probably because its as hard to teach as are the problems it is most suited to solve. It may, indeed, be something you can't teach because the student either has "it" or doesn't. To do it well requires mental discipline, above-average intelligence, attention to detail, the willingness (indeed, insatiable desire) to continually learn new concepts and tools and, most of all, an insane amount of persistence. Most people don't have that particular constellation of traits. Making programming tools simpler will not turn these people into programmers any more than the advent of power tools and embedded, computerized control/diagnostic systems turned people who weren't auto mechanics into auto mechanics.
One "Aw, Shit!" is worth 100 "Ata boys!"
Wow Deja Vu.
I remember the xBase (dBase / Clipper etc) languages being touted as the programming solution for non programmers. Programmers would be out of jobs, everyone would be writing their own applications. My first programming job when I left University was writing business applications in Clipper.
Comment removed based on user account deletion
... which is to say, not at all.
The idea is not new, and something like this has been tried pretty much since the notion of a programming language higher-level than assembler was invented. Most of them die straight away. A few enjoy brief prominence, but then die anyway (e.g. dBase and dialects, and many other "4GL").
Very few survive and take over some niche, but by that time they've inevitably strayed from the original "can be understood by any random guy" design goal. One example of such is SQL - yes, originally, it was intended to be a language in which managers and like-minded non-techies could easily write queries for reports etc. Yeah, right... every time I'm explaining why you can't write WHERE after GROUP BY, and have to use HAVING instead, I chuckle to myself.
One of the astro-turf comments in TFA reads like this:
"Even though ‘90-per cent less code than traditional languages’ reads like a big claim, it is valid one.
If you have a string you want to extract the first 3 characters of the second word on the 5ths line from and display it in an alert box, how many lines of code would you need to write in traditional languages? In rev this is a one-liner.
answer char 1 to 3 of word 2 of line 5 of theString /* where theString is a variable that holds the content */"
Of course any competent programmer can do the same in just as little code. For java it would be something like this:
alert(theString.replaceFirst("(.*\n){4}\\s*\\S+\\s+","").substring(0,3));
or
alert(theString.split("\n")[4].trim().split(" +")[1].substring(0,3));
This is roughly the same amount of code. Not 90% less.
"Text processing" is apparently touted as one of the strong points of the language. Yet, I am sure old fashioned perl and regular expressions are likely more concise and powerful. As shown above, even java can compete.
How would this fare with real programming tasks? First order functions? List comprehension? Closures? A sound typesystem? You could go on forever.
These topics seem to be ignored. This is a VisualBasic clone, not an attempt at a language that you would create "real" programs in.
"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."
Now ask yourself why this happened more with VB than, say, with C++ and you'll see why and to what extent VB's bad reputation is a well earned one.
on off switches. Everything else is just some higher lever Abstraction!
Why can't someone attack a profession like Law or Medicine with a tool like this? Seriously? Imagine:
"Our new Suem 4.0 system makes it possible to practice law without passing difficult bar exams!"
Don't hire expensive lawyers to represent you in court when you can use Suem 4.0 to help you defend yourself! Defend yourself against Murder charges! Rape charges! or even Embezzlement! Now anyone can practice law!
"Our new Surge 4.0 system makes surgery possible with 90-per cent less precision!"
Why pay for expensive surgeons when you can operate on your own brain! Perform tumor excisions and Lobotomies in just minutes of training!
[signature]
thanks for catching & correcting.
So what if it's easier or dumber or whatever?
Most of us aren't out there revolutionizing the world with our leet skills - we're pulling numbers out of a database and shuffling them into some other database. It happens - we get paid.
If this language gets some of the shovelwork off my back and frees up time for me to solve some interesting problems, then I'm all in favor of it. If it provides a way for me to earn an income (or someone else to) then I'm all in favor of it.
If it gets a few more people interested in programming, I think the world can handle that. Just because there's a new language on the block doesn't mean that all the other languages are suddenly useless. After all, we still have stuff written in COBOL floating around.
The big picture guys will still hire programmers to do what we do because we can think about a task and break it down into it's component steps.
"My God...it's full of trolls!"
The problem I've found with some of the so-called "easier" languages is they tend to attract the lowest common denominator, and they tend to go quickly from "easy" to hard or nearly impossible for more complex tasks that are outside their parameters. This leads to a lot of people without proper education making "applications" which suck horribly, or that do a number of extremely nasty workarounds in order to do a given function
It's not a set rule, but I've seen enough horribly mangled pieces of "simple" programming to believe that it's fairly common.
++++++++++>[->++++++++++++>+++++++++++>++++++++++>+++>++++++++++>++++++++++---.>+++++.>+.>++.>--.>++.
there will be always lower layers with which people will need to work with, when the needs arise. it has never been different.
on top of that, every software develops its own characteristics and workings after they grow big enough. regardless of what level programming language they are written on.
the most blunt, straight example for this are the php 'scripts' of a few years ago. over years, they have developed and grown to such a level that they have become expertise areas in themselves, and in places like elance, rentacoder, those expertises are specifically being asked for, instead of being labeled as 'php developer'. you may see 'phpbb expert', 'oscommerce developer', 'drupal wiz' requests a lot more than straight 'php developer' requests and so on.
it seems that this doesnt change with platform, and always holds true.
Read radical news here
VB does ONE job and does it quite well-GUIs for databases...
Either you missed the whole .Net thing, or you should be careful to note in your comments that you know you're talking in the present tense about a version that's been out of date for about 7 years.
Learning only one language.
> VB does ONE job and does it quite well-GUIs for databases
As long as you don't mind being completely and utterly locked into a single, closed platform.
Isn't the best approach to develop fast, identify the bottlenecks and then rewrite those parts in a faster language, like Python C modules?
That would work except in cases where the platform's sandbox policy allows managed user programs (e.g. Python, Java, Lua, C#) but bans unmanaged modules (e.g. C, except for the subset of C++ that can run in the CLR). Java applets run in such an environment, and so do Xbox 360 games from smaller firms.
it's dumbed down.
While I agree that making languages simpler is good, VB6 really is the quintessential example of how it can be bad. But it wasn't the language's fault.
VB6 was easy and pretty so it attracted the post-dot-bomb "teach yourself Visual Basic in 21 days" crowd who suddenly were writing enterprise software. I worked at a company with 2 sister projects: One was entirely VB6, coded mostly by former analysts and beginner programmers. It was easy to hire people for this project. The other was a mix of C++/VB6 coded mostly by experienced C++ programmers. The entirely-VB project was a mess and they could not keep people on the project. The other project became the company's bread-and-butter. Both were managed by the same manager, and were closely related. It really made a great case study.
The VB6 developers (not all of them -- but many of them) were just simply inferior, and the product sucked. That's not VB6's fault, but it does show the downside of making things "simpler."
Last comment:
ON ERROR RESUME NEXT
I've been a hard core C/C++ programmer for years, but over the past few years I ended up working with 4GLs and "smart" frameworks. For the things they did well, they were great. You could spew out functionality at a much faster rate than with C/C++ or Java. But if you tried to do anything "out of the box", you tore your hair out trying to get around the limitations of the 4GL.
Most recently I took up functional programming with Erlang. It's taken me about 6 months to become truly proficient with the language, but it's very powerful for developing concurrent systems and services. Like any other language, it has it's limitations (for example, the ODBC interface casts 64-bit integers from the database to strings instead of true 64-bit integers. Integers are "unlimited" in Erlang, but when you have to send things over the wire the lack of true 64-bit integers is a real pain.)
I've worked with innumerable frameworks over my career. Each had certain tasks they were well-suited for. None was a generic "solves all problems" toolkit.
The one thing I did learn is that programming with "smart" frameworks and 4GL's is boring. Only the most technically-challenged programmers seem to stick with them, for the simple fact that there is nothing to make the job challenging or interesting when using such tools. They don't "dumb down" programming -- they just simplify their set of special cases and drive away the programmers who actually understand how machines work and how they process data. Unfortunately that also means that the teams of 4GL programmers are left helpless when they have to tackle an out-of-the-box problem, because they simply don't have the skills and experience to "bend" the tool to their will.
I do not fail; I succeed at finding out what does not work.
Obligatory Futurama:
Leela: "Uh, g- uh, getting back to the, uh, matter, uh-uh, if it please the court... Fry, there's nothing else here. You only wrote two pages of dialogue!"
Fry: "Well, it took an hour to write. I thought it would take an hour to read."
Comment of the year
I think there are two key advantages to revTalk.
1) It enables people who are not full-time programmers to undertake projects they normally wouldn't consider doing otherwise. It's possibly true that someone who knows a more traditional language could write something that executes faster or more efficiently, but if you reduce a five-hour process down to 10 minutes, you're still getting a significant boost in productivity, even if "real" programmer could write code that did the process in 3 minutes.
2) It is definitely more readable, and often shorter. As an example, there was a "readbility challenge" for coding a while back. The task was to write a routine that would determine all possible two-word anagrams given a starting word and a word list. See http://selfexplanatorycode.blogspot.com/
I can't post the code of the winning entry; Slashdot reports "Filter error: Please use fewer 'junk' characters. But you can find it here: http://www.reddit.com/r/sdcc1/comments/6wru4/leonardo/
--------
And here is the code in revTalk:
constant alphabet = "abcdefghijklmnopqrstuvwxyz"
on mouseUp
put "documenting" into sourceWord
put url "http://someserver.com/wordlist.txt" into wordList
repeat for each character c in alphabet
if c is not in sourceWord then filter wordList without ("*" & c & "*")
end repeat
put sortWord(sourceWord) into sourceWord
repeat for each line firstWord in wordList
repeat for each line secondWord in wordList
put firstWord & secondWord into testWord
if the length of testWord is the length of sourceWord then
if sortWord(testWord) is sourceWord then
put firstWord && secondWord & return after anagramList
end if
end if
end repeat
end repeat
put anagramList
end mouseUp
function sortWord theWord
repeat for each character c in theWord
put c & return after theSortedWord
end repeat
sort theSortedWord
replace return with empty in theSortedWord
return theSortedWord
end sortWord
It is shorter and (in my opinion) much more readable.
But languages like VB and PHP practically encourage it.
How? Its one thing to say it, and another thing to justify it. In my experience, VB has all the same basic design-freedoms that the C language has (functions, structures, a wide assortment of branching instructions), but also has classes and mostly-enforced garbage collection.
I believe it is not the language that matters so much as it is the APIs and tools associated with using a language. But there are also some differences between actual languages.
Java can be very strict - even putting requirements on file names. While this can be a pain, it does make things easier for other programmers that have to understand your work.
Python programs tend to be very clean and easy to read. This is largely a result of enforced indenting for loops and such.. (my opinion at least)
Both Objective C and Smalltalk have a unique way of making method calls. Unlike other OOP languages, methods tend to be very descriptive. It is difficult to misinterpret the the meaning of arguments or pass then in the wrong order. It is also much easier to understand the meaning of methods written by others.
While I basically agree with your premiss that any language can be bastardized, different languages do offer some advantages. But as I said previously, it is the APIs and tools that really make the difference. For example, if VB templates better supported the MVC paradigm we wouldn't have nearly as much crappy code out there. VB basically encourages you to put application logic into presentation code. For comparison, look how NeXTStep used Interface Builder to design GUI elements. Elements were compiled into NIB files that then linked to the application logic. The tools encouraged the separation thereby resulting in a better design.
The problem with a programming language based on English is that now companies will have to train their programmers on English spelling.
An "English-like syntax" won't help. It's been tried, starting with COBOL-60. Things to look up: "The Last One", "ZoomRacks", "HyperCard". The programming language of HyperCard, HyperTalk, was amazingly similar to COBOL-60.
But that's not the right question. The question is, can programming be made easier by having the computer help the user more? Not with command completion or syntax coloring, but with something that has more of a clue about what the user is trying to do.
It's worth realizing that spreadsheets are the predominant "user programming" system. Within their domain, they're straightforward.
(1) Does it get the job done?
(2) What it completed on time?
(3) Was it within budget?
If the answer to these questions is "yes", then the tool did its job. And, in my experience, a "dumbed down" language often works better than other languages. C/C++ software often fails because of (2) and (3).
Sadly, Hypercard, Applescript, and Revolutions aren't "dumbed down", they are simply "dumb": they are just as complex as many other programming languages, they just use a syntax that gives the false appearance of being "easy". It seems easy because people looking at it think "hey, this is just like natural language, I can figure out what this does". That's a good hook to get people programming, but it gets them stuck with an inferior tool.
and it takes both skill and talent to pull off a well-written application
In light of the recent article about achievements in games, http://games.slashdot.org/article.pl?sid=09/11/26/0628247, and the broader implications of those ideas, I'd like to point out:
Becoming good at programming, and writing good applications, is something that you can achieve if you put in enough effort.
Back when I just learned C, I had the "joy" of looking at undecipherable stack traces (with no symbols) every time my programs would segfault. At my current skill level, they probably would have been easy to figure out, but they weren't back then. Yet, I stuck to it and stubbornly printf-debugged my programs, eventually learning the patterns and principles that make for good C programs.
If you want to become a programmer, or a good programmer, or a better programmer, effort does pay off. Big time.
One interesting example of "dumbing down programming" is the RPGMaker series, particularly the VX and XP versions.
You can do basically all of your game eventing, scripting, resource editing, etc, a using user-friendly gui, no need to touch programming code. And you can do some fairly involved "eventing" logic, which is basically a very high level scripting language that you edit through user-friendly dialogue boxes.
But you can also start digging into the lower details. Actually, the core of the RPGMaker game engine is Ruby code, including an interpreter, which loads, interprets, etc the above resources. And that engine is very easy to extend, using custom Ruby coding. And in fact there is a huge number of custom scripts you can download from third parties to customize your games that way. Basically you can customize just about anything that way, except for the user-friendly editor that most people use.
If the language is english, suddenly you can bypass all those expensive, crotchety programmers.
And the thing is, even if the syntax is word-heavy rather than symbol-heavy, it's still not easier to learn!
Why not? Because you still need to understand the weird, contorted formal grammar of a programming language. How do you say widget.visible = true in English? "Set widget's visible to true"? "Set the visible of the widget to the value true"? "Set visible of window to true"?
Furthermore, you also need to know what you can and can't talk about. How do you come up with "Import the sha1sum function from the cryptography package" on your own? You need to read the standard library documentation (or at least the index) to know that this is a sensible thing to say.
One thing that using a word-heavy syntax might do is make it easier for new programmers to understand the meaning of what they're writing. Does = test for equality or does it assign? Which one was == again? It's easier to understand "if myvariable equals 10 then [...]" than "if myvariable == 10: ..." if you don't have a good memory for symbolic syntax. However, that's the easy part and the part you learn as one of the earliest things.
Being word-heavy is good for some things. I don't know that everyone agrees which things those are, nor that everyone agrees on the value of being good at those things. In fact, I think people disagree on those :)
This may or may not help, take a chunk of the code affected by the addition of the new code you're trying to build and rewrite it as part of the updates and don't tell anyone. Probly do this first so you have the added motivation to not tell anyone you've done it. you'll cop flack in the short term but just say this code you're fixing is such a house of cards that you have to be very careful around it while adding your new stuff, and in the long run you'll be making your job easier and quicker. Pretty much i've found this is the BEST method of getting old code re-written (besides having it being so obviously slow that it's almost useless)
This is a joke. I am joking. Joke joke joke.
The article is advertising disguised as a question, kind of the opposite of "when did you stop beating your wife".
I suppose if you define "traditional languages" as C or assembly language, then you might save 90% of the code. Compared to other scripting languages, however, Revolution is a mess. The Revolution environment may help you get started programming, but it would almost certainly be a better and more effective environment if they dumped their awful scripting language.
I think it is appropriate for this topic to be a source
of discussion at ZDNet. Could we who read slashdot
please be spared this waste of time.
Thank you.
Dennis Allard
I've noted two things about this,
1) It builds on a language called hypertalk, apparently; this seems to be something like what you could imagine COBOL would look like if it had been designed today. Not that COBOL is a bad language as such, but as anybody knows who has ever had to maintain old COBOL programs, the fact that it is supposed to be sort of "human language" like is a hindrance rather than a help to understanding.
COBOL, as well as hypertalk it seems, have been designed on the false assumption that what makes programming hard is the weird looking programming languages; the real truth is that programming is hard because it involves analysing a task in every detail, so you can write the code that does it, and it always turns out that doing even simple things encompasses a lot more detail than one would have imagined.
2) Isn't this "90%" claim simply an iteration of the old one that used to accompany all the interface design tools? It wasn't true then, and it isn't now either of course. It is true that you can whip out a prototype in no time with such tools; but there is always so much more to design and programming than that. It's like Oracle Forms - you can easily make a simple application that allows you to input and retrieve data from a single table, but a real application will involve perhaps tens of tables with any number of triggers and constraints that have to work together; and of course, you don't just display the raw data on-screen, there will be name lookups, pictures etc etc. Programming is complicated because real life is.
The article asks if this sort of "ease of programming" will dumb down programming? I don't think it will get worse than it is. Bad programmers will produce crap, good one will produce good programs; and Darwin is our friend and benefactor here (that's Charles Darwin, not the OS, BTW).
YOU decide!
Seastead this.
I once built a custom vertical market cross-plattform desktop application in RunRev. The functions of the little app where speced to the last detail and the user interface was designed and drawn out down to the last pixel, Font requirements included. Coaxing the IDE into not sucking by adding 3rd party extensions and such was a bit of a hassle, but all in all the project went very well.
We used RunRev 2.x with various 3rd party extensions including a font-compiling plugin (which in the end didn't work) and a more IDE-like extension of the RunRev enviroment that eased coding.
The visual and object oriented style of building apps in stackware is pretty cool and can be insanely fast, fluent, concurrent and bugsafe. You get concurrent from the first minute on, because Stackware usually uses the DMI approach, which is pretty cool in itself. The way the runtime integrated with it's own DMI (Direct Manipulation Interface) and compiles it's current state into the deployable app is something one has to get used to, but it actually is OOP in its purest form, if you get the hang of it. This sort of developement is a direct descendant of the Smalltalk way of doing things and makes the Java/.Net way look like ancient weedy spagetti-basic.
Yet RunRev uses a PL called TransScript, something like a bizar resemblence of SQL and Lingo that tries to emulate english for dummies. An attempt which, of course, doesn't work. That's the biggest gripe I have about these commercial types of stackware. Building a new PL and throwing out the junk we've got from C and it's ancestors is a good thing, but putting in SQLs failiures of a end-user-interface language is bad and the results are usually accordingly. The one FOSS project that aimes in a stackware direction that I know of is Squeak and it uses Smalltalk, which probably is a way better to go.
Any way you look at it, stackware and visual development has a lot going for it if it is done right. .Net, [fill in generic Big-Fat-Appstack here] and whatnot up and down the street, to be honest. I'm not suprised they claim to have saved half a million in costs, and I actually believe it's true.
It actually kicks all other dev-methods imaged by Eclipse, Java,
My 2 cents.
We suffer more in our imagination than in reality. - Seneca
so... are we supposed to overlook that percent is spelled "per cent" in an article about dumbing down?
If you make programming more accessible to people with limited knowledge in the field, you will end up with lots of barely working programs... Some of these programs will get used in situations where they really shouldn't, and are likely to have lots of bugs and/or security holes. You already see it, it's very easy for novices to write programs in visual basic or php, so you see lots of very sloppy programs out there with lots of security holes...
As someone who runs a webserver hosting sites for other people, a lot of these people upload very shoddily written php code that gets exploited. I had a spam outbreak a couple of days ago because someone managed to find a vulnerability in a php script that let them run arbitrary commands as the webserver user.
That said, i think computers should encourage users to learn by default, like they used to do in the days of BASIC being built in. Computer back then had a relatively simple programming language built in, and would come with big thick printed manuals encouraging you to learn about it...
Today you get thin paper instructions that barely cover how to unpack the box, and software that goes out of its way to hide the underlying system from the pretty interface.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
language once, and the syntax turned out to be pretty similar to Rev4. Basically, one needs a simple way to control flow, a simple way to express logic, a simple way to manipulate data, and a simple way of interacting with the user.
A huge part of writing an effective language is anticipating how the writer *thinks* something should be stated before they've even tried to write it. If your target programmer is someone without formal programming training, you want to avoid anything that assumes an understanding of abstract programming concepts such as object orientation. Rev4's use of natural language "glue" and it's simple verb-object sentence structure follows pretty well the way a non-programmer would think.
As others have pointed out, however, just simplifying the language is not enough. To get a real boost in productivity, one needs to add a lot of *useful* abstractions to data manipulation and user interactions. That generally means lots of pre-built functions that do meaningful work (as the non-programmer would define it) for very little effort. This is essentially the same role that human vocabulary plays: by using a single word, we can express an entire concept. Give me a vocabulary with several thousand words and a simple sentence structure, and there's not a lot I can't convey.
I've only looked at Rev4 very briefly, but it does seems to have a pretty large and useful vocabulary. There are useful abstractions of data structures (looks a lot like hypercard, actually), useful abstractions of UI, and useful abstractions of string manipulation operations. I can easily imagine being pretty productive with this as my first programming language.
All these simplifications and abstractions, of course, come with a cost: extensibility. The more lower level a language is, the easier it is to get it to do things not envisioned by the language writer. I don't know this for sure, but I highly suspect that if the card-stack data abstraction won't cut it for your needs, then writing in Rev4 will be painful and frustrating.
There will always be a need for varying levels of programming languages. If a user needs something done that is so easy that it could be done by a non-programmer, then why hire a programmer to do it with a more capable language? It's not like programmers aren't busy enough. There's plenty of work for everyone.
"We receive as friendly that which agrees with, we resist with dislike that which opposes us" - Faraday
A language that reads like english? You have "invented" COBOL...
Weren't we there one before with 4 GLs? See Wikipedia
...richie - It is a good day to code.
What part of "The best approach" are you having trouble understanding? I never said this is how most people do it. The part about implementing in "as maintainable a fashion as possible" addresses your changing requirements concern, and the fact that you didn't tell management it will be done when it gets done and help them understand why they are clueless enough to believe that they can change requirements without delaying the release (in as politically correct a way as possible, of course) explains to me why you think that none of this can actually work in the real world. I guarantee you I have more than 20 years experience developing software, and the above comes from real world experience that you clearly have yet to figure out how to get.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
regardless of the language in use, programming still requires the ability to think logically to develop a solution to whatever problem the programmer is trying to solve.
Of the hype/panic induced by RoR marketing campaign few years ago. "The framework that obsoletes programmers, and lets anyone code web apps!". Yea well, we know how that went.
As for this particular effort, Revolution 4.0, I'm afraid guys you picked the wrong target to market to (computer geeks). We're not fooled by the verbose English syntax. It's still a pretty pedestrian scripting language from what can be seen in the examples.
I had very good higher math from highschool and from a college level math course years ago. But no programming background, training, etc.
Tried to lean Java as my first stab at programming. Let's just say, I learned enough to create endless exception errors (or seemingly so).
Then, back tracked a bit, taught myself JavaScript, for where I was knowledge-wise, it was the proper entrance point.
From there, taught myself C, and while I did that, I even ventured into learning a bit about assembly (which, in hindsight, helped broaden my understanding of what my C code was doing that the lowest levels). Then, re-visited Java with much better results and also learned some C++ (but I am still very much a fledgling C++ coder).
The problem, as I see it, isn't the need to dumb programming down, there are really two tracks (maybe more) here:
1. Programming for those that want to stay away from the lowest levels of computer processing and
2. Those who want to code as close to bare metal as possible for speed, etc.
Both are needed, in different situations. And, some in "1", as they gain more knowledge, will gravitate to "2".
It is really a matter of personal interest, what problems the programmer is trying to solve and that sort of thing.
From my own experience (briefly noted above), the basics, what is happening with the system when you code a particular thing, helped me really evaluate what I was trying to do with a particular function or piece of code, which I then used to improve past code I had written and improved my programs for new projects I tackled.
I've seen and written a variety of highly complex server applications in C and C++.
You just have to get it right. And memory errors aren't all that nasty to debug, not when you've got good tools like valgrind and/or purify.
Precisely!
One only needs to look at what was done in Hypercard to see that this will actually be useful to many people, especially with modern hardware underneath it.
It will be used for inappropriately complex systems, of course, but so it goes. Many people will find it's wonderful for the problem they want to solve, for which they'd never hire a "real" programmer.
When I was designing a scripting language for testing wireless protocols I modeled parts of it on Hypertalk -- I allowed programmers to use either message[id] or 'id of message', for instance. It wasn't particularly fast, compared to what one could do in C, but it was certainly more usable by someone who understood the domain but wasn't a programmer.
The testers found it very useful. The people writing the protocols weren't interested in using it to produce realtime efficient implementations, but nobody expected it to be used that way. I was surprised to find some testers, who were also programmers, using it to write load generating tests, though.
Very few people need to extract every bit of efficiency out of a dual core CPU in order to manage their model railroad and train collection, or their knitting pattern collection, but the relatively inexpensive computer they might buy will certainly have such a CPU in the near future. Such a machine will run such an application very satisfactorily, and they'll be able to make it do just what they want.
Go find a copy of Danny Goodman's Hypercard Handbook and see how well it explained how to use the language. People did great things with it -- but they weren't interested in writing operating systems.
joe
I haven't posted the article here, and trolls are those who express opinions without ever knowing anything about the subject. By the way, I haven't said anything about 90% less code.
Have you tried the product? Did you understand how to use it? Did you give it a fair trial? If don't then keep your opinions fair like "Hey, I doubt this true but I haven't tried."
Internet forums like slashdot are full of experts in subjects they didn't knew about 5 minutes before checking TFS. Now tell me, did you try the damn language? Did you ever used some xTalk language (hypercard, metacard, supercard, omo, rev)? If you did not and you claim anything is phony then you're being trollish, also, posting anon doesn't help to keep a nice civilized discussion.
Now, if you want to have a good talk, at least I am here to shed some clue to this environment that most here never heard of. Just ask and I will try my best to answer, and maybe you'll have a better knowledge base to evaluate and form opinions, even if negative.
-- Por mais que eu ande no vale das trevas e da morte, meu PowerMac G4 Não Travará!!!
"revTalk" is the language and "RunRev" is the company name
Model Masters
The focus on languages puts too much focus on the tool. There are many languages in the world but most people of whatever culture have little of importance to say.
PROGRAMMING is the production of a useful set of instructions for a machine to follow. That means you must ANALYZE the problem and realize that you must make decisions about every possible result of every possible path. That is the hard part of programming. Providing languages that aren't so hard help get folks to realize the crux of the issue isn't the programming, it is the THINKING. If programming classes didn't have to spend so much time on semicolons and proper indenting, they could spend more time on how to properly frame a problem statement in the first place.
"I have written in it...obviously not the new release but some sort of earlier version."
Can you list what version you used? I tried the new version and it seems extremely fast and responsive.
Also, I like the idea of coding once and deploying everywhere (most everywhere). RevTalk seems to be a rather useful tool for quite a few of the projects I am working on.
But you could make that argument about most of the tech today "We wouldn't have all these viruses if folks had to use PDP and CP/M instead of just going "clicky clicky". A side effect of making ANYTHING accessible is that you will get some of the stupid along with the smart, should we make everything as hard as possible just to discourage the dumb?
My statement still stands though. I have built several applications in VB6 for companies, yes including the dreaded "VB+Access" app, that are still running quite well several years since they were created. And since a "smart layman" like myself could easily adapt to VB6 (I started out on the VIC20, so BASIC was like a first language to me) it allowed these companies, who never would have been able to afford a custom app, the ability to have EXACTLY the application they required to increase productivity- A custom GUI on a database.
And THAT is why I still keep VB6 around to this day, and say that .NET will never reach the penetration that VB6 did, because VB6 was a RAD for the masses. The most I charged for one of those "custom apps"? A whole $750. Show me a C/C++ programmer that will develop a custom app for a small company for THAT price. The reason I could do it is the fact that the GUI practically designs itself in VB6, and by recycling code snippets I had kept since my old VB class in college it was quite easy to get an app up and running. I have yet to see a language that makes it that easy and affordable to create custom apps. VB6 really was one of a kind and is still quite useful to this very day, as long as you accept its limitations. The reason VB6 still has quite a large following is its main job just so happens to be one that many SOHO/SMBs need badly to increase productivity. And in the end isn't that what companies want from a program in the first place?
ACs don't waste your time replying, your posts are never seen by me.
(I'm only posting this because I want it archived with this article.)
This reminds me of the paper "The Camel Has Two Humps," which details the author's theory that some people just aren't cut out for computer programming because they lack the ability to conceptualize in a machine-friendly manner.
This is a problem that is not best served by "dumbing down" computers to be useable by people who have no business programming them, in the same manner as television shows should not be dumbed down to be readily accessible to the visually-impaired.
Why is so little effort being spent making it easy for me to repair my own car with soft, clean, lego-like tools?
If you want to be a plumber, you have to be willing to occasionally shove your arm into a pile of s#it to solve a problem.
If you want to program computers, you have to be willing to occasionally shove your brain into a pile of mathematics to solve a problem.
I'll believe computer programming is "ready for the masses" when plumbing is "ready for the masses".
It's all about the tubes, people.
If there's no incentive to make code maintainable, most coders will end up making a mess regardless of language. It's all a matter of old-fashioned carrots and sticks. (Sure, there are exceptions who attempt to make maintainable code regardless of pressure from management, deadline, or peers, but we are not talking about them.)
The OOP "pattern" crowd sometimes goes hog-wild with "Gamma" OO patterns and shoehorns everything into the most convoluted pattern they can find for the job, for example. It creates "job security" because only they know what they did and finding another mad gamma pattern zealot whose used to overdoing them may be difficult for the company.
Bad code usually comes from laziness or zealotry or both. Zealots try to force everything into The One True paradigm even if it doesn't belong. Lazy people skip comments, leave in ugly and unnecessary duplication, create functions with giant parameter lists because they don't want to re-factor variable scoping, and the opposite: too many global variables, etc.
There are always ways to cut corners and/or create a Chinese Puzzle, and if the incentive is there, they'll take advantage of it. No programming language can spank such people.
Table-ized A.I.
This reminds me of a programmer from the FreeDOS Project who argued to change/deprecate the behavior of the /Y ("Yes") option to the FreeDOS FORMAT command, so that it would instead display something like:
A:\> FORMAT /Y C:
... _
This command will erase the contents of your C: drive !!
Do you really REALLY want to do this ??
Type YES in all caps to format
I thought that was really dumbing down the command, coddling the user way too much. If you felt compelled to protect the user from themselves, I'd prefer the /Y option trigger a message and a 5-second countdown, press Ctrl-C to abort.
VBA is very similar to VB6, if that's what you mean. There are rumors that Microsoft will be overhauling and/or replacing it within a decade, perhaps with something better matching the dot-net framework, or go toward a more scriptish direction.
Table-ized A.I.
And those who don't know history are doomed to post idiotic shit about it... Pascal just has a more verbose syntax and C has looser type-coercion rules.)
And the reason for this is that Pascal was designed as a teaching language.
No, you're trolls because you criticize it without even looking at it and kicking its tires. Some of the people posting here in defense of the product are doing so not because they are paid to do so but rather because, unlike you, we did download it and kick its tires... and we're happy customers.
I tried to use this language/RAD environment. Kept getting hit with show stopping bugs. There's a million of them. For starters, the plugin for web content apparently runs continuously as a process in the background. Don't know if they fixed that yet. Of if they will. Uninstallers and updaters didn't work (uninstaller corrupted my Windows registry for version 3.5). The memory management is awful, and leaks abound when using externals (for example, databases and browsers). The list goes on. And on. Right now this is a very pretty package, but it's not ready for the big leagues. The underlying code needs to be vetted. I'd recommend sticking with open source alternatives such as wxpython or Tcl/Tk if you want to avoid these issues. There is nothing more frustrating than having a show stopping bug and having to deal with a commercial vendor that won't give you the time day or treats you like a child. I think "opacity" is the word that describes them.
A big problem here is that there is a niche of programmers that wants/needs to create commercial applications, especially for entertainment and education needs, but the RAD tools have really gone to hell from the commercial vendors. I started out using Authorware in 1998, which was quite lovingly "discontinued," but was very stable. Then came Macromedia Director, which was god damned rock solid through MX 2004 (although essentially abandoned for Flash by Macromedia; they had like one engineer working on it at the time of the sale to Adobe). Adobe took Director and sent the code base to Bangalore, India, to a bunch of engineers who've made a complete mess out of things from what I can tell. I don't think its a coincidence that the CEO of Adobe is a graduate of the universities of India himself. Anyway, they're stuck at version 11.5, which is an unholy pile of junk (and it will cost you a cool grand, btw). Director, the program that built Macromedia, is essentially dead and along with it just about the only commercial programming alternative for the unwashed masses without computer science degrees.
The fact of the matter is that RunRev doesn't "dumb down" anything except the programmer. It's a complete struggle to use, but really only because it's not a stable programming environment. If it worked as advertised, we would be awash in RunRev apps. In my opinion, and it's just my opinion (as the owner of an Enterprise license from RunRev), Runtime Revolution is amateur night in the programming world. On the other hand, Tcl/Tk has a totally whacked syntax (upvar anyone?) but it is very fast and very very stable. Especially version 8.4 (you can get it from ActiveState for Windows). wxPython is probably the best choice, however, and you can create binary apps if commercial is your thing.
Is it just me, or is commercial development software in general becoming more buggy?
The Death Penalty: Killing people to show others that killing people is wrong.
Just for the exercise, using function composition:
class EString(f: (String) => Unit) {
def char(begin: Int) = new Object { def to(end: Int) = new EString(s => f(s.substring(begin-1,end))) }
def word(number: Int) = new EString(s => f(s.trim.split(" +")(number-1)))
def line(number: Int) = new EString(s => f(s.split("\n")(number-1)))
def of(s: String) = f(s)
}
def answer = new EString(println _)
val theString="1\n2\n3\n4\nabcd efgh ijkl\n6"
answer char 1 to 3 word 2 line 5 of theString
You can write revTalk in another language!
Now the revTalk critics are probably going to whine that they don't understand higher order functions. Then realize that you do actually learn something useful during these years at college. Sooner or later, you will find yourself in a situation where there is a need for something more advanced than extracting a word from a string.
You would not need to understand how the library is written to use it though.
A language like this will allow management types to do their own prototyping. This could mean less hassle for programmers, as the manager can flesh out a working prototype t use as a model for production apps.
I understand alot of old schoolers who are incredible at C++, Assembly, or any of the myriad of difficult languages would scoff at things being so easy, but learning programming might not seem like such a daunting task to younger kids and newcomers. Back in junior high school, I remember learning Basic, which was rather easy but didn't seem very robust. It encouraged me to expand my horizons outward, more and more, with Pascal and the like. I got reinterested in programming during college while taking a Visual Basic course, being amazed at what impressive things could be accomplished so easily since I was gone.
I supposed many older schoolers would see this the same way as retired players would see Major League Baseball allowing steroids. They didn't have to pay their dues learning a difficult and convoluted language while creating thousands of line of code to create something worthwhile. Just like how MLB players on steroids didn't have to lay the foundation of hard work to earn their stripes. The accomplishments would seem to come too easy. Thats the way life is nowadays, thats all I have to say about that. It happens in almost every facet of existence anymore, there are easier ways to do or learn anything invented everyday. The important thing to do is keep your chin up, all you old schoolers, because you will always be a repository of knowledge when it comes to things such as proper programming structure, redundancy elimination, and the like. Not to mention that you'll have a different perspective on error elimination, efficiency, and process improvement. Programming could become too easy, but they can't take your wisdom.