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

72 of 578 comments (clear)

  1. A Natural Progression Yet So Many Caveats by eldavojohn · · Score: 5, Insightful

    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.
    1. Re:A Natural Progression Yet So Many Caveats by mwvdlee · · Score: 4, Interesting

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

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

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

      --
      Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
    2. Re:A Natural Progression Yet So Many Caveats by mustafap · · Score: 4, Interesting

      >the more human readable and dummy proof

      Actually those two are exclusive, not inclusive.

      --
      Open Source Drum Kit, LPLC deve board - mjhdesigns.com
    3. Re:A Natural Progression Yet So Many Caveats by mwvdlee · · Score: 3, Informative

      Reply to myself

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

      Says enough to me.

      --
      Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
    4. Re:A Natural Progression Yet So Many Caveats by Have+Brain+Will+Rent · · Score: 3, Funny

      COBOL is reborn!!!

      --
      The tyrant will always find a pretext for his tyranny - Aesop
    5. Re:A Natural Progression Yet So Many Caveats by MightyMartian · · Score: 3, Interesting

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

      --
      The world's burning. Moped Jesus spotted on I50. Details at 11.
    6. Re:A Natural Progression Yet So Many Caveats by jd2112 · · Score: 2, Funny

      Regular expressions must really be dummy proof!

      --
      Any insufficiently advanced magic is indistinguishable from technology.
    7. Re:A Natural Progression Yet So Many Caveats by icebraining · · Score: 3, Insightful

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

    8. Re:A Natural Progression Yet So Many Caveats by rolfwind · · Score: 2, Informative

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

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

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

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

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

    9. Re:A Natural Progression Yet So Many Caveats by broken_chaos · · Score: 2, Insightful

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

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

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

    10. Re:A Natural Progression Yet So Many Caveats by SharpFang · · Score: 2, Insightful

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

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

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

      --
      45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
    11. Re:A Natural Progression Yet So Many Caveats by Daishiman · · Score: 3, Interesting

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

    12. Re:A Natural Progression Yet So Many Caveats by TheCarp · · Score: 2, Insightful

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

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

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

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

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

      -Steve

       

      --
      "I opened my eyes, and everything went dark again"
    13. Re:A Natural Progression Yet So Many Caveats by eldavojohn · · Score: 3, Insightful

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

      The part where I stated that Rev4 may be an appropriate tool for some tasks can be applied to all languages/tools. No one's writing web applications in assembly. And no one's using Jakarta Struts to control an embedded device.

      Nowhere did I make any claims that Ruby, Java or Rev4 will ever replace C, Assembly or VHDL for these problems. I was speaking about the largest chunk of desktop applications and applications that a non-coder might be able to use Rev4 to produce.

      Furthermore, Rev4 makes no such claims to tackle a single one of the examples you listed. So the premise to the discussion was Rev4 and its target users. No one is going to select a "dumbed down" language or technology to tackle any of the problems you listed and no one is claiming Rev4 is going to someone who's never coded tackle the problems you listed.

      They are interesting problems and must be kept in mind before declaring "No one will ever program in assembly again!" But I made no such claims nor should anyone. It would take a fundamental revolution in hardware and at least one hundred years to be able to make any such claim.

      --
      My work here is dung.
    14. Re:A Natural Progression Yet So Many Caveats by Narpak · · Score: 4, Funny

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

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

    15. Re:A Natural Progression Yet So Many Caveats by SharpFang · · Score: 2, Interesting

      A traffic lights controller.

      Failure to react (detect the condition and perform action) within the regulatory 300 milliseconds since a green light occurring on two colliding directions (~100ms to detect current, ~100ms for the mechanical switch to cut off power, leaves 100ms for the software) equals our fault. If someone dies - Unintentional causing of road traffic accident with a fatality as consequence. The same rules apply as if I ran over someone by car, as result of my own traffic violation.

      Of course the 15 years option would be for malicious intent, like a hidden "all green" mode resulting in multiple deaths.

      And of course the level of redundancy of the cut-off systems and general paranoia in the software is awe-inspiring.

      --
      45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
    16. Re:A Natural Progression Yet So Many Caveats by somersault · · Score: 5, Funny

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

      are you really sure?

      user@computer:~$ yes I am sure

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

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

      just making sure

      user@computer:~$ delete the fucking files already

      final answer?

      user@computer:~$ killall friendlybashhelper

      are you sure?

      --
      which is totally what she said
    17. Re:A Natural Progression Yet So Many Caveats by aix+tom · · Score: 3, Informative

      Well. Not the "failure to perform according to specs directly", but the results that may cause.

      I did program PLCs for a while, and if I messed up the emergency stop procedure in an obvious way, and someone would have died as a result, I might have faced jail time for reckless homicide or involuntary manslaughter. Although I have heard only a few cases where there where actual convictions, and most of those were placed on probation instead of actually going to jail, like in the case of this electrician.

      In the case of the Therac-25 incidents, there were too many contributing factors to really pin down the problem to one person. The person who originally wrote the software wrote it for the Therac-20, where it didn't cause any problems because of additional hardware interlocks, so technically the software worked on the "machine" it was written for. So the cause for the incident was not an obvious one, like using a not suitable language for the task.

    18. Re:A Natural Progression Yet So Many Caveats by innocent_white_lamb · · Score: 2, Interesting

      Plenty of applications don't need the kinds of optimization one is going to get with C/C++
       
      Optimization aside (though it's nice to have), stuff written in C is about as future-proof as you can get with computers. C has been around for 37 years now, and userland code written in 1972 can generally be compiled with a modern ISO-compatible C compiler with very few or no modifications.
       
      Sure, printf() isn't necessarily all that pretty in a GUI environment, but that's not exactly the point -- it still works.
       
      C does take a bit of thought and it might take a bit longer to get a usable result out of, but that result will generally be serviceable a lot longer than a program written in the programmer's flavour-of-the-week.
       
      Maybe it's just my approach, but I would rather put in a bit more time up front and have something that I can just recompile to run on a CPU that hasn't been invented yet, instead of having to rewrite it from scratch.

      --
      If you're a zombie and you know it, bite your friend!
    19. Re:A Natural Progression Yet So Many Caveats by ottothecow · · Score: 3, Informative
      I have written in it...obviously not the new release but some sort of earlier version.

      It is a joke...its code runs so slow. I was happy not to be using VB but soon realized that VB is at least reasonably quick. It makes sense that the creators don't use it...anyone capable of creating a language is perfectly capable of writing in a better language.

      It could be good for gui prototyping...it made very fast gui interfaces that were fully interactive and you could actually extend it pretty far. It just ran so slow that I can't see any benefit for using it in a professional environment. The extra time your users will have to spend waiting on the program would far outweigh the time/money it would take to hire someone to do it right (or even VB-right)

      --
      Bottles.
    20. Re:A Natural Progression Yet So Many Caveats by Simetrical · · Score: 4, Informative

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

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

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

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

      --
      MediaWiki developer, Total War Center sysadmin
    21. Re:A Natural Progression Yet So Many Caveats by Have+Brain+Will+Rent · · Score: 2, Interesting

      I don't think the point is whether or not someone would still start a project in it (that certainly wasn't my point) but that it was based on the same idea as the article summary mentions and was in fact successful if you use a metric for success based on the number of programs written in it. There almost certainly far more programs written in Cobol than in Fortran. And even though there may still be a lot of Fortran programming still going on in scientific/engineering circles, given the relatively tiny size of that programming community I bet there are still a competitive number of Cobol programs still running out there even though there may not be any more being developed.

      Since I didn't make myself clear the very first time let me say - what is being proposed has been proposed before in the form of Cobol (old boss, new boss thing). Cobol may not have been successful at the goal of enabling non-programmers to turn out useful code but given its very widespread use in the real world it was certainly successful just as a programming language. So while the new idea may not be any more successful than Cobol in enabling non-programmers to generate useful software (but, hey it might!) it may still yield useful tools for the generation of software by actual programmers.

      --
      The tyrant will always find a pretext for his tyranny - Aesop
    22. Re:A Natural Progression Yet So Many Caveats by Dragonslicer · · Score: 3, Insightful

      But take some hack's C or Python code and then have to sift through it and fix it up just so you can make it a bit more modular.

      Bad programmers will be bad programmers no matter what language you give them. Some languages, however, are easy enough to figure out that even bad programmers can write something that mostly works.

    23. Re:A Natural Progression Yet So Many Caveats by whoop · · Score: 2, Insightful

      You must be confusing Slashdot for rational thinking. You see, 'round these parts, every article the describes something new must be the only one of its kind to exist.

      ChromeOS? It's gotta be able to serve 500 trillion web hits, decode MRI scans, run MS Exchange to 10 people in an office, telephone you when the temperature outside goes above 50, and browse web sites from the couch. If it cannot do all that, and everything everyone in the world wants to do, it's useless.

      Nintendo Wii? It cannot play the simplest version of Pong 40,000 in 1080p across fourteen 10,000-inch televisions with fully realistic explosions. Therefore, it is crap.

      So, don't let it surprise you that this little "language" is crap since it cannot do some things.

    24. Re:A Natural Progression Yet So Many Caveats by mcrbids · · Score: 4, Insightful

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

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

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

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

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

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

      --
      I have no problem with your religion until you decide it's reason to deprive others of the truth.
    25. Re:A Natural Progression Yet So Many Caveats by Simetrical · · Score: 2, Interesting

      The thing is, many webapps are actually DB bound despite appearing to be webserver bound, because they store most of their state in the database (and nearly the rest of it at the user's browser).

      Now this means you are shifting the burden of locking, serialization and other tricky stuff to the DB.

      When you do that, you can have as many identical webservers as you want (scaling "horizontally")- since the state is all at the DB (and most of the rest in the user's browser).

      Okay, in that sense I agree that databases are the major optimization concern for web apps, at least from a scalability perspective. It's worth pointing out, though, that this doesn't save you from latency issues, only scalability issues. If your PHP app takes 500 ms to generate a page, it doesn't matter how much hardware you throw at it, users' experience is going to be considerably worse than it should be. On Wikipedia, large pages can take literally 20 seconds or more of CPU time to generate – although this is hidden by two different layers of caching, so it's not usually visible to most users.

      --
      MediaWiki developer, Total War Center sysadmin
  2. What's new? by Rising+Ape · · Score: 5, Insightful

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

    1. Re:What's new? by WED+Fan · · Score: 5, Insightful

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

      --
      Politics is the art of looking for trouble, finding it everywhere, diagnosing it incorrectly and applying the wrong fix.
    2. Re:What's new? by ScrewMaster · · Score: 5, Insightful

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

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

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

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

      --
      The higher the technology, the sharper that two-edged sword.
    3. Re:What's new? by eddy+the+lip · · Score: 5, Insightful

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

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

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

      --

      This is the voice of World Control. I bring you Peace.

    4. Re:What's new? by WED+Fan · · Score: 2, Informative

      Let me rework my own comment: People really hate when a language does well despite their hate for the language. It rises to an almost religious fervor.

      Now, I can has my edit button?

      --
      Politics is the art of looking for trouble, finding it everywhere, diagnosing it incorrectly and applying the wrong fix.
    5. Re:What's new? by scamper_22 · · Score: 2, Interesting

      Are we moving up the value chain of programming? Of course.

      However, almost all the things we can automate via compilers are things you wouldn't want to do anything.
      Who wants to code the assembler for a for loop? I welcome C!
      Who wants to code a GUI specifying pixel positions and handling resizing? I welcome come GUI designers and XAML.
      Who wants to write protocols encoding and decoding data? I welcome XML serialization and RPC! ...

      None of those things make good programs. Heck, using the right libraries and programmers that like nice sounding function and variable names, you can make c# or java really easy too.
      I've never found anyone hampered by syntax. A semi-colon here or brace there is simply not an obstacle to me.

      I taught computer science in high school. You would be amazed at the difference. Some students get it... and some just don't. Even a simple thing like variable assignment.
      Those that can get it...they get variable assignments, they get sequential steps, they get functions... they really pick up the fundamentals of any language quite quickly. The rest is design.
      I don't think people who can program can ever understand the mind of someone who doesn't get these things. I suspect its why some kids get algebra and some just don't.
      They're unable to understand variables and abstract notions.

      The only things you can really remove the programming from are those whose rules are pretty static. Things like very very very basic forms backed by a DB. But a variety of companies and environments already allow you do do such things.
      Anything that you can write a compiler for or auto-code generator for, I welcome.

  3. xkcd relevance by A+beautiful+mind · · Score: 5, Interesting
    --
    It takes a man to suffer ignorance and smile
    Be yourself no matter what they say
    1. Re:xkcd relevance by Brian+Gordon · · Score: 5, Funny

      Reminds me of this famous forum post.

    2. Re:xkcd relevance by jedidiah · · Score: 4, Insightful

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

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

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

      --
      A Pirate and a Puritan look the same on a balance sheet.
  4. Interesting, yet exaggerated... by rdean400 · · Score: 5, Insightful

    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?

    1. Re:Interesting, yet exaggerated... by arevos · · Score: 2, Insightful

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

      Probably. There's no difference in length between:

      get the last item of line 2 of URL url

      And:

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

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

    2. Re:Interesting, yet exaggerated... by Nahor · · Score: 2, Insightful

      There's no difference in length between:

      get the last item of line 2 of URL url

      And:

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

      I wonder what the code becomes if the URL contains a list separated by ':' or a more complex data structure.

      With such an example, I can make an even better language. I'll call it dot. It has only one character: a period. Here is how it compares:

      .

      which in that verbose Revolution 4 language gives (approximately):

      get the item 42 of the line 3465 of the structure 3 that contains "foo" in the record 6 counting from 3 of the 38990nd [...rest cut to avoid the slashdot lame filter...]

      Now, my language does only one thing but it's unbeatable at it :)

  5. Its been being "dumbed down" since the start by jaymz2k4 · · Score: 2, Insightful

    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
  6. Re:I could care less, it isn't truly FREE by DAldredge · · Score: 2, Insightful

    .net appears to be doing rather well.

  7. Little point in trying by 4D6963 · · Score: 5, Insightful

    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!
    1. Re:Little point in trying by QRDeNameland · · Score: 3, Insightful

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

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

      --
      Momentarily, the need for the construction of new light will no longer exist.
  8. It actually doesn't look that good by thetoadwarrior · · Score: 3, Interesting

    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.

  9. Recursive acronym for a dumbed down language by Skapare · · Score: 3, Funny

    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
  10. Submarine article by bjourne · · Score: 4, Insightful

    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.

  11. Re:BAD IDEA by hairyfeet · · Score: 3, Insightful

    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.
  12. Underhanded Way to Increase Comments in Code by reporter · · Score: 5, Insightful
    This progression toward using English words and syntax to program a computer is less about dumbing down code and more about encouraging people to document their code.

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

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

    1. Re:Underhanded Way to Increase Comments in Code by vadim_t · · Score: 4, Insightful

      Ideally, a programmer should document each section of code by writing a block of comments explaining (1) why the code is used and (2) how the code works -- in plain English.

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

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

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

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

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

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

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

    2. Re:Underhanded Way to Increase Comments in Code by GigaplexNZ · · Score: 2, Insightful

      The calculate distance comment is completely redundant as the variable that it is being assigned to is already named distance. Unless, of course, the intention was to state that it was in fact calculated instead of magically pulling a number out of a hat. You don't need one liner calculations to be commented to state their intentions if the variable names are chosen properly (which is what self documenting code is largely about).

    3. Re:Underhanded Way to Increase Comments in Code by julesh · · Score: 2, Funny

      You really cannot turn every one-liner into separate function. Really.

      Why not?

  13. Time to read "No Silver Bullet" again by turing_m · · Score: 5, Informative
    --
    If I have seen further it is by stealing the Intellectual Property of giants.
  14. Rev4 syntax by ickleberry · · Score: 2, Insightful

    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

  15. Re:Quit complaining by Anonymous Coward · · Score: 3, Insightful

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

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

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

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

  16. Re:I could care less, it isn't truly FREE by sznupi · · Score: 2, Insightful

    ...which is largely due to external factors.

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

    --
    One that hath name thou can not otter
  17. Re:Lowering the bar by GWBasic · · Score: 5, Insightful

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

    I don't see it that way.

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

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

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

  18. Re:Quit complaining by gbjbaanb · · Score: 3, Insightful

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

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

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

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

  19. All you young kids with your fancy 1s and 0s by davidwr · · Score: 3, Funny

    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.
  20. Even in Universities by Anonymous Coward · · Score: 3, Insightful

    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.

  21. Nope by Colin+Smith · · Score: 5, Insightful

    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
    1. Re:Nope by 1s44c · · Score: 2

      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.

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

  22. Re:Lowering the bar by GWBasic · · Score: 2, Insightful

    boost::shared_ptr

    Yup, I worked with that when it was appropriate. That's not the issue. The real issue is that, when using boost::shared_ptr, you need to treat memory on the heap and stack differently. It's kind of silly to worry about these things in a thin SOAP wrapper for a database where the database is the real bottleneck and the overhead of garbage collection is negligible.

    The other issue that I failed to mention is that compiling C++ is often an order of magnitude slower then newer languages. This slow compile time is much more "expensive" then any lost sales due to requiring a slightly faster CPU and slightly more RAM.

    I can give you another example: An AI researcher that I know of re-wrote newer versions of her algorithm in Java instead of C++. Even though garbage collection givers her some visible performance implications, she can program and test her algorithms much faster, which has tangible economic value for her company.

  23. Age old quest: COBOL and SQL by kbahey · · Score: 4, Insightful

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

  24. Stupid argument by jcr · · Score: 3, Insightful

    They said the same thing about COBOL.

    -jcr

    --
    The only title of honor that a tyrant can grant is "Enemy of the State."
  25. Re:Lowering the bar by GWBasic · · Score: 2, Informative

    But in the hands of the in-experienced or sloppy coder ... they can unleash the most horrendous leak riddled code possible.

    The same can happen in a garbage collected environment: Nothing will ever be collected!

    There was a bug in version 1.0 of .Net where, if you used a calendar control, your entire window wouldn't be collected. If your window referenced other data, it wouldn't be collected as well.

    Cause of the bug: The calendar control "forgot" to unregister its event handler for the "system colors change" event, thus keeping an active reference after the window was closed.

    It's also important to understand that garbage collection isn't "magic" memory management. It's just meant to be less time consuming. This is because a poor programmer will still forget to release resources that need to be explicitly released and thus end up "leaking" memory.

  26. Less code = faster? by henrypijames · · Score: 3, Insightful

    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.

  27. Slick by thePowerOfGrayskull · · Score: 3, Interesting

    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.

  28. dBase / Clipper by daver_au · · Score: 2, Interesting

    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.

  29. Re:Lowering the bar by Anonymous Coward · · Score: 2, Interesting

    I choose you to pick on :)

    Python is a very good example. Recently I have spent many hours writing a C app (because of the possible destinations of this app this made sense being an embedded application). Then I ended up on another embedded box that had python on it. Easy right? Port it use the same structs and what not right. Just use class and pop everything in. Wrong. I was out of memory PDQ. Processor usage was crap. Short story is I ended up 'optimizing' to the language. Basically tricking python to preform correctly. Not what I should be having to do in a language.

    Learning/using a language is not about 'how hard it is to manage things' or 'getting things done faster'. It is about what the language is intended for and cost trade offs. Python is meant for smallish short to the point scripts. Sure you can write large programs in it. I have written crazy programs in DOS batch script. C is meant to be lean and mean and 'on the metal'. But that comes at a cost as you have pointed out.

    The 'dont worry about it your hardware will catch up' crowd really ticks me off. It shows a true lack of care in their craft. With 4g type languages such as python, Ruby, Perl, VB, and C# there *ARE* trade offs. Ignore those details of what they do and why they do it at your own risk. To demonstrate I will show you a nice example of the sort of thing I talk about. It hits all the points.

    I will use a C struct to show it

    struct abc{ int a; int b; int c; } abcstruct;

    Clearing out that struct in C is a snap of a call to memset. In a 4gl I have to set each var to 0 with an abc.a=0 type thing. Pass this struct into other parts of the system are a snap as the rest of the system probably expects C type structs. But with a 4gl I have to 'thunk' it. Not to leave C un picked on I will show something python does 'very' well.

    x = [1,2,3,[4,5,6,7]]

    and poof x is already inited properly with variables. In C that would be a painful exercise of properly nesting things and getting it 'just right'. Then iterating over that struct is a snap in python as it is 'built in'. But with C it is a tedious exercise in nest for loops and type definition.

    Higher level languages are good at what they do and have their place. But many times people become enamored with them because of the 'ease of programming'. That ease of programming comes at a cost.

    I have noticed many times programmers are in love with their language of choice. Usually it is whatever they learned first. So they see that language as the 'naturally' right one.

    As a side note whoever came up with the idea of not having a begin and end in python needs to have a tire iron taken to their heads. Sure it makes your code all 'nice and pretty' by default. But it also creates bugs (I am on my 5th one this year because I misstyped a tab).

    Also back to the original point Let dumber people program and you end up with dumber programs very true! In *any* language you can write dumb things. It doesn't take much usually either. But let dumb people write things and you will end up with dumb code. I have seen awsome programs written in javascript, grotesque monstrosities in python, and works of art in C. But it all comes down to understanding what you wrote is going to cause the compiler/interpreter to do to your code.

  30. It will be just as successful as previous attempts by shutdown+-p+now · · Score: 3, Insightful

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

  31. 90% claim is fake by bbn · · Score: 2, Insightful

    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.

  32. So what if it's easier or "dumber"? by Infernal+Device · · Score: 2, Insightful

    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!"
  33. Re:It's not about the learning curve. by Mortice · · Score: 2, Interesting

    All right, I can't resist. A ruby implementation...

    def should_uncheck(item)
        item.checked? && current_font.provided_styles.include? item.style
    end

    menu.items.select{|item| should_uncheck?(item)}.map{|it| it.uncheck}

    You could do something similar in any language supporting higher-order functions. The code meets your requirement of not expressing things through nested loops and reads more like "do this to all items for which 'condition' is true." That said, Inform7 is very cool. :)