Forgot your password?
typodupeerror
Programming IT Technology

Ioke Tries To Combine the Best of Lisp and Ruby 255

Posted by timothy
from the like-a-sibilant-jewel dept.
synodinos writes "Ola Bini, a core JRuby developer and author of the book Practical JRuby on Rails Projects, has been developing a new language for the JVM called Ioke. This strongly typed, extremely dynamic, prototype-based, object-oriented language aims to give developers the same kind of power they get with Lisp and Ruby, combined with a nice, small, regular syntax."
This discussion has been archived. No new comments can be posted.

Ioke Tries To Combine the Best of Lisp and Ruby

Comments Filter:
  • Try Io (Score:5, Informative)

    by QuantumG (50515) * <qg@biodome.org> on Monday November 10, 2008 @01:26AM (#25700645) Homepage Journal

    http://www.iolanguage.com/ [iolanguage.com]

            Io is a small, prototype-based programming language. The ideas in Io are mostly inspired by Smalltalk (all values are objects, all messages are dynamic), Self (prototype-based), NewtonScript (differential inheritance), Act1 (actors and futures for concurrency), LISP (code is a runtime inspectable/modifiable tree) and Lua (small, embeddable).

    • Re:Try Io (Score:5, Insightful)

      by Smauler (915644) on Monday November 10, 2008 @01:48AM (#25700743)

      New languages are announced every week or so in different places... it doesn't change the fact that the language that most big projects rely on now is one of the old guard. C [wikipedia.org] is, despite it's incarnations (or deformations, depending on who you believe) still king, and it was designed in 1972.

      • Re:Try Io (Score:5, Insightful)

        by MrNaz (730548) * on Monday November 10, 2008 @02:30AM (#25700949) Homepage

        The idea of these new languages (Python, Java, Ruby, and presumably ioke) is to abstract very common functions to increase the speed of development.

        Every layer of abstraction increases the "power" of the language from a development point of view, allowing developers to do far more than they could with a single line of code, trading off flexibility, and performance.

        The idea of a new language is to deliver as much "quick access" functionality as possible (saving the developer having to implement their own low level functionality such as string classes, array handling and perhaps memory management) while compromising as little as possible on flexibility and performance.

        If ioke delivers a best-yet mix of these trade offs, then it stands a chance to become the Next Big Thing. Personally, I think that Python is the state of the art when it comes to highly functional development languages that still deliver good performance and flexibility. It's not quite fast enough to write an operating system in (although there was an effort called Unununium which tried but never took off), however it is vastly superior, both in overall design and performance, to other languages that provide a similar level of abstraction such as PHP.

        • Re:Try Io (Score:5, Insightful)

          by julesh (229690) on Monday November 10, 2008 @04:10AM (#25701357)

          [Python]'s not quite fast enough to write an operating system in (although there was an effort called Unununium which tried but never took off)

          Unununium's kernel was, I believe, written in C. The user interface, userspace applications and drivers would have all been written in Python.

          Unununium didn't take off because its developers had no clue about OS design. They apparently spent most of their time boasting about how their operating system didn't have a kernel (it did; its kernel was a slightly modified Python interpreter[1]) and how it was such an innovative design (when all it did was replicate some of the achievements of traditional language-based systems that were popular in the academic research community in the 70s and early 80s, cf. Smalltalk-80, which although now generally considered just as a language was originally considered by its developers and users as an operating system, or the earlier CMU Hydra system which was built around similar principles), and not enough time actually writing the damned thing.

          [1]: The issue seems to be one of understanding what a kernel is. The unununium developers seemed to believe the defining factor of a kernel is that it provides inter-process protection by allocating different memory spaces to the different processes. Under this view, many modern OSs don't have kernels, including Singularity and JX. Also, some older ones, including 16-bit Windows and Amiga.

        • Logic compression (Score:3, Interesting)

          by TheLink (130905)
          I sometimes look at programming as a form of Compression. In this case it's decision/rule/logic compression.

          You can express any program with an infinite list of "IF THEN"s, but that's not very useful (and way too much typing).

          So that's where programming languages come in. Not all compression algorithms are great for all sorts of data and situations, similarly not all programming languages are good at all things. Of course there are some compression algorithms which are just plain crap :).

          A language that's p
          • While a lot of CS academics like languages that are powerful for the code you have to write (which is a good reason), do not be surprised when programmers in the real world pick languages that are powerful for the code they don't have to write (aka modules/libraries).

            I bet that's aimed at the comp.lang.lisp crowd :-) "Nah, there's no library for X, but why does it matter when it only takes a few hundred lines to implement X in Lisp?"

            Besides the availability and quality of libraries, a language's culture and institutions are critical. CPAN is a boon. Javadoc is my favorite thing about Java and the one feature/practice I wish was present in all the other languages I use. Modern package management systems (apt-get et al.) have modernized and streamlined the experience

            • Amen.

              I really really wanted to do CL for the rest of my days as a programmer-turned-engineer (and now have the freedom to code applications just how I like them) but dangit if the libraries just SUCK. How to send email to a SMTP server that requires TLS? How to do threads? How to do a basic GUI? Serve a web page? How to package it up?

              And by golly how to write multi-platform code (e.g. Windows/Mac/Unix)? It doesn't help for c.l.l to say "just use the functions in CLTL/HyperSpec" when you need to do HTT

            • Re: (Score:3, Funny)

              by ClassMyAss (976281)

              Javadoc is my favorite thing about Java and the one feature/practice I wish was present in all the other languages I use.

              Right on - I think the importance of Javadoc being an official part of the language as opposed to some add on is often underestimated when people wonder why Java caught on so well, and the fact that most IDEs integrate Javadocs so seamlessly is extremely helpful. I've still never seen another language that has such a practical and actually used documentation system.

              When your IDE is s

        • by digitig (1056110)

          If ioke delivers a best-yet mix of these trade offs, then it stands a chance to become the Next Big Thing.

          I'm glad you said a best mix, not the best mix, because the best trade offs depends on what you're actually doing, which is why the good programmer will have at least a couple of languages under their belt.

        • There's more out there in high-level land than the current crop of scripting languages.

          It's funny you mention that Python isn't QUITE fast enough to write an operating system in. I'd say it's dead-slow to write an operating in. Some guys at OLPC thought it was a good idea to write a window-manager in Python. And that is already dead-slow. Python as of now is still an interpreted scripting language. And I wouldn't exactly set the bar as low as to take PHP as a classic example of a fast, well designed lang
        • Every layer of abstraction increases the "power" of the language from a development point of view, allowing developers to do far more than they could with a single line of code, trading off flexibility, and performance.

          That's mostly true, but not necessarily so. For example, take Python. One of the nice things it does is making dictionaries (ie, hash maps) piss easy to use. Now, it is true that that can lead to abuse, and make you use dictionaries for everything (and, in fact, much of python is implemented atop its own dictionary system). However, when you do want to write code that uses hash maps extensively, you're unlikely to find a faster implementation of hash maps anywhere.

      • by Tumbleweed (3706) *

        it doesn't change the fact that the language that most big projects rely on now is one of the old guard. C is, despite it's incarnations (or deformations, depending on who you believe) still king, and it was designed in 1972.

        That's why I like D. It's basically C with modern concepts built (elegantly) into the core language. No need to get all crazy with things like Ruby, etc. Plus it's compiled. :)

      • by BountyX (1227176)
        That's because processor instruction set is essentially the same. Use a processor that takes BYTE code as its instruction set and you end up with a java platform. In the real world, most people have intel based instruction sets.
        • Re: (Score:2, Informative)

          by Anonymous Coward
          Good lord, you haven't done a damn thing at the low level, have you? First, the instruction set argument is complete nonsense -- there's no such thing as a "BYTE code" instruction set, it's a format for compiled code, and the code becomes x86 before it runs on your CPU.
          Second, what you're running on should never relate to language choices unless you're running on an embedded platform. Java code is compiled to the CPU just like everything else, it's just done at runtime.
          You miss the point: people use C b
      • No surprise (Score:5, Informative)

        by Sycraft-fu (314770) on Monday November 10, 2008 @04:52AM (#25701541)

        That's because C deals with how computers actually think. All this new stuff with languages is wonderful, and often has some uses in various cases, however none of it relates to how a computer actually works. C is a good "mid level" language. By that I mean it does a good job of structuring programs in terms of how they actually work on a processor, while still being fairly easy for a human to work with.

        A lot of people get caught up in their "flavour of the month" language and forget that none of this relates to how computers actually work. For example yes, pointers are confusing and you can get in to trouble with them. However, that is actually how a processor handles things. It has registers that are pointers to memory locations of things it needs (like a pointer to the instruction to execute). So while more restrictive, managed references might be nice, they've nothing at all to do with how the processor works. That means you have to implement additional code overhead to deal with that sort of thing, and that you are losing the ability to optimise in certain ways.

        Basically C is likely to remain strong until we just have more CPU power and memory than we know what to do with on all platforms (embedded included). Until then there is the need to generate optimised programs. To do that, you need to be able to write a program based on how the computer thinks, not on how you do.

        • Basically C is likely to remain strong until we just have more CPU power and memory than we know what to do with on all platforms (embedded included). Until then there is the need to generate optimised programs. To do that, you need to be able to write a program based on how the computer thinks, not on how you do.

          In other words, C or a variant will remain strong forever.

          We will always need optimized programs because, like my desk, available space always fills with something, and the more somethings we can cram into that space, the happier we are...

        • by TeknoHog (164938)

          In my impression, C is how a single-processor computer thinks. The way we're currently getting more CPU power is via multiple processors and SIMD.

          My pet peeve is the idea of autovectorizing compilers; they are necessary because people are using a sequential language to solve parallel problems. When you write up a matrix multiplication in C, you are throwing away essential information about the calculation. A parallelizing compiler will try to recover this information by guesswork. It's a silly state of t

        • by savuporo (658486)

          c++ is better though, and i sincerely hope that the world is moving towards c++ based interfaces ( some opsyses already do, like Symbian and a few RTOSes ive come across )

          Even for really lowlevel stuff, like 8-bit MCU programming i prefer c++ over C these days ( exceptions off, rtti off ) due do simple constructs like wrapping resource locks etc. and templates save the day more often than C practice of preprocessor macros.

          In short, i favour simpler, cleaner code.

        • Re:No surprise (Score:4, Insightful)

          by jhol13 (1087781) on Monday November 10, 2008 @10:19AM (#25704261)

          C is likely to remain strong until we just have more CPU power than [...]

          We already do (have more than C can handle[1]): dual and quad core processors.

          There is as of now no really good parallel (or multi-threaded) language. Java and Erlang are perhaps the best, which essentially says where we stand right now.

          Please do not talk about Posix thread libraries, they do tell enough about the memory model. Java was the first language to define one, but it is not 100% clear. C++ is just about to define one for itself[2].

          Therefore for example D is not the next language.

          [1] Not that you said or even implied that.

          [2] http://www.hpl.hp.com/personal/Hans_Boehm/c++mm/ [hp.com]

      • by abigor (540274)

        Well, as someone who is currently writing C firmware code, I'd have to disagree. Most big projects (in terms of lines of code) these days are Java, I'd say. C is good for embedded stuff like what I'm getting paid for, and for low-level systems stuff like your operating system kernel, but when it comes to enterprise apps, desktop apps, etc., who is using C?

    • Hey! it basically it is Io for the JVM! What's not to like? (Except the JVM).

        Io feels so right, I always have suggested Io instead of Javascript for browser scripting.

  • "Best"? (Score:3, Funny)

    by FlyByPC (841016) on Monday November 10, 2008 @01:28AM (#25700653) Homepage
    (There's (a best) (part (of LISP)))?!?
    • Re: (Score:3, Funny)

      by mechsoph (716782)
      Make that: (? (is there (part a best (of lisp))))
      • Re: (Score:3, Funny)

        by Haeleth (414428)

        Oh, please. There's a macro for this:

        (best-part-exists? 'lisp)
        ==> t

        • by digitig (1056110)

          Oh, please. There's a macro for this:

          (best-part-exists? 'lisp)
          ==> t

          Surely
          (p_best_part_exists 'lisp)

          • Re:"Best"? (Score:4, Informative)

            by Raffaello (230287) on Monday November 10, 2008 @10:34AM (#25704551)

            underscores? in lisp? are you mad!!?

            (best-part-exists-p lisp)

            i.e., hyphens as separators, p for predicate rather than the schemish question mark of you parent, and no need to quote lisp which is clearly being treated as a variable pointing to a language entity here, not a raw symbol in need of quotation.

    • Re:"Best"? (Score:5, Interesting)

      by QuoteMstr (55051) <dan.colascione@gmail.com> on Monday November 10, 2008 @01:51AM (#25700759)

      The parentheses just disappear after you've coded Lisp for a while. Also, try paredit.el [mumble.net] for Emacs. With that turned on, you don't edit text, but sexps. It's wonderful, once you get used to it.

      As for Lisp itself, well, 20 years ago did for the first time many of the things that mainstream languages today are just beginning to obtain, like closures, arbitrary lexical scoping, highly dynamic data structures, and (in Scheme's case) call/cc. One thing gcc just implemented is per-function compiler optimization settings. Common Lisp has had a facility for that since the beginning of time.

      One thing that still isn't matched by other languages, however, is Lisp's macro system. It's far more powerful than C macros. You can define new control structures, implement sub-languages, and construct any higher-language construct you want. And these features you build all look just like native language constructs.

      And don't even get me started o CLOS, which is one of the very few object-oriented systems to provide a clean multimethod [wikipedia.org] dispatch solution.

      • Have you had your eyes checked recently?
        If you cannot see *that* many brackets then something is horribly wrong. ;)

      • Re:"Best"? (Score:4, Interesting)

        by hachete (473378) on Monday November 10, 2008 @02:43AM (#25701007) Homepage Journal

        Dylan had a very powerful macro system.

        http://www.opendylan.org/ [opendylan.org]

        with all the advantages of a late-bound language.

      • It seems to me that per-function optimization settings would be useful in very few real-world cases.

        • by Haeleth (414428) on Monday November 10, 2008 @04:19AM (#25701393) Journal

          Yes, people often don't see the point of things they've never tried, or of features that are missing from their current favourite language.

        • Of course it's useful. Optimization flags tend to end up becoming a time/space trade-off. Extend that trade-off too far, and you get yourself into problems with not fitting all the code you want in L1 cache (plus bigger binaries, but that's a smaller issue). By using a low level of optimization on most of the code, then inlining and aggressively optimizing the inner-loop type of functions, you get the best of both worlds.
      • CL is great, and CLOS is wonderful (clean multiple inheritance, multimethods, etc - it really is the pinnacle of OO). But the real problem with Lisp today is the lack of static typing, even opt-in (there are type-hints, yes, but they are really more of an optimization hints - they may be ignored by the compiler at will, and type mismatches are essentially U.B., no checking required).
    • by QuoteMstr (55051)

      Also, it's
      (best-part-p 'lisp)
      you insensitive clod. :-)

    • (There's (a best) (part (of LISP)))?!?

      There is, and you just quoted it. The best part of LISP is that there's no bloody syntax; everything is clean, regular and simple. Of course this isn't true of Common LISP, but Common LISP isn't really LISP at all.

      I have to admit I took a look at Io [iolanguage.com] this morning, and thought, 'oh, no, not another language with bloody stupid syntax.'

      • The main good part about lisp is that data and code are represented in the same way. Any transform you can do on data, you can do on code. This makes metaprogramming incredibly easy - something like 90% of the GoF patterns can be implemented as Lisp macros, for example.

        Io has some syntax, but not much more than Smalltalk, which has assignment, message passing, and literals. After using Objective-C and Smalltalk for a while, I'd hate to switch back to a language which doesn't have infix parameter names (

    • Lisp Cycles [xkcd.com]

      Still one of my all-time favourites.

    • (There's (a best) (part (of LISP)))?!?

      (defmacro with-decent-lisp [& forms]
          `(with-clojure ~@forms))

  • Outlook negative (Score:5, Insightful)

    by incripshin (580256) <markpeloquin@@@gmail...com> on Monday November 10, 2008 @01:29AM (#25700667) Homepage
    Ola Bini has no beard. The only proof you need that this language will fail?
    • by ignavus (213578)

      However, he wears a hat AND has an "unhealthy" interest in programming languages. So maybe it will succeed after all.

    • by Haeleth (414428) on Monday November 10, 2008 @04:22AM (#25701413) Journal

      No, no, you've got it backwards. Designing a successful language gives you a beard.

      Poor Grace Hopper...

  • the same kind of power they get with Lisp and Ruby, combined with a nice, small, regular syntax

    In other words, this is just a reinvented Ruby targeted to the JVM. Without macros, what's the point? Why not just stick with Common Lisp and get all the power of Lisp, not just some of it, and still have a "small, regular syntax"? You can even use ABCL [common-lisp.net] if you want to target the JVM.

    • Re: (Score:2, Informative)

      by Maian (887886)

      *sigh*

      It would help if you actually read the rest of the article:

      Just like Lisp, Ioke provides syntactic abstractions. They take two forms, the first one is macros, which is basically like method calls with lazy arguments that can be evaluated in special ways. The other form is syntax, which works a lot like Common Lisp defmacro. These together provide the possibility of creating new control structures and define new abstractions. The language is powerful enough to allow you to create your own method types,

  • by QuoteMstr (55051) <dan.colascione@gmail.com> on Monday November 10, 2008 @01:42AM (#25700713)

    I haven't used Self, but going by my experience with Javascript, prototype-based languages suck compared to conventional class/metaclass based ones. The problem is that parents of types must be *instances* of their parent types, and there isn't always a suitable kind of instance to use as a prototype. Either you end up coding around the prototype system and emulating conventional constructors, or you end up specifying special uninitialized states for base classes.

    Prototype languages make it easy to use the GoF prototype design pattern, true, but I find myself thinking "hrm, I need a new type" far more often than "Hrm, I need a prototype system for object initialization."

    Also, Python and CLOS style metaclasses give you all the flexibility of a prototype system.

    I'm all ears for any advantages the latter might have.

    • by Animats (122034) on Monday November 10, 2008 @02:29AM (#25700937) Homepage

      I haven't used Self, but going by my experience with Javascript, prototype-based languages suck compared to conventional class/metaclass based ones.

      Generally true. Javascript was never intended for writing large programs. The object system is basically a hack on top of dictionaries. That's easy to implement, but doesn't scale well.

      This is one of the classic things one can do wrong in language design, and which tend to have to be fixed in later versions, painfully. Some other classic boners are leaving out a "bool" type (C and Python), not providing generics in a statically typed object-oriented language (C++ and Java), and not designing in separate compilation (ISO Pascal).

      Ioke is cute, but there's just no really good reason for such a strange syntax, and it's going to turn too many people off. Using whitespace as an operator (really!) is probably a bad idea. The ability to change the operator precedence dynamically may be "fun", but does not lead to readable or maintainable code. Experience with "read macros" in LISP indicates that rewriting code during input isn't good for readability either. On top of all this, Ioke allows regular expressions in code, like Perl. (It's not clear from the description if you can use regular expressions in the read macros to rewrite the regular expressions in the code. I think you can.) So Ioke brings together the least readable features from four different languages.

      People who come up with "l33t" ideas like this need to be put on maintenance programming of code written by others for six months or so.

      • by Artraze (600366)

        > Some other classic boners are leaving out a "bool" type (C and Python)...

        I've never understood why this bothers people.
        For the two languages you give:

        C: In C, everything is a number. This is because everything is a number at the level of the processor, and C is all 'low-level' like that. If the processor is only going to check whether something is zero or not, why enforce that a given number is _precisely_ one or zero? There is some confusion by people who don't understand this who will type (x==TR

        • Everything is a number in C, but binary choices are very common in logic. It's at the core of every 'if' statement: having to re-invent booleans in so many different forms for different uses is just painful.
        • by grumbel (592662)

          If the processor is only going to check whether something is zero or not, why enforce that a given number is _precisely_ one or zero?

          Because it expresses much more precisely what you intend to do. Having a "bool is_visible()" in a GUI toolkit makes sense, having a "int is_visible()" not so much, which is why everybody ends up doing macro hacks of BOOL, gboolean and whatever. Lack of basic features in a language just leads to lots of hacking around to get those features into the language down the line, its simply annoying.

          • by Zerth (26112)

            There's your problem. Visibility isn't a bool, it is at least an int, or maybe a float. Think, man! The object may have only partial concealment.

        • Explicit boolean types were not a part of Python until some version (I don't remember which).
      • by Haeleth (414428)

        On top of all this, Ioke allows regular expressions in code, like Perl.

        This is a good idea; it makes the regular expressions themselves much easier to read, with less escaping than is required in languages that insist on putting them in strings. Regular expressions are already complicated enough without requiring you to write crazy stuff like "\\\\\\*" just to match a backslash followed by an asterisk.

        It also makes it feasible for syntax-highlighting editors to treat all regular expressions specially, whic

      • by johannesg (664142)

        This is one of the classic things one can do wrong in language design, and which tend to have to be fixed in later versions, painfully. Some other classic boners are leaving out a "bool" type (C and Python), not providing generics in a statically typed object-oriented language (C++ and Java), and not designing in separate compilation (ISO Pascal).

        C++ most definitely has generics (templates!). Feel free to hate the syntax, but they are there.

        As for the other poster who #defines TRUE as !FALSE, that of course does not work - or at least, not as he seems to intend it:

        const int a = 3;

        if (a == TRUE) ...

        This will still fail, because it expands to

        if (a == !FALSE) ...

        which itself expands to

        if (a == 1) ...

        which gives a result that I would rate as incorrect. And if by some miracle the author did intend for this to be correct, he is really overdue for a good b

      • Ioke is cute, but there's just no really good reason for such a strange syntax

        I'm not sure Ioke is the language for me, but I think it is interesting that he is experimenting with syntax and trying out new things. He has blogged [olabini.com] about his reasons for using space as the method operator, and the consequences.

        People who come up with "l33t" ideas like this need to be put on maintenance programming of code written by others for six months or so.

        I've worked with Ola. Trust me, he's done plenty of maintenance prog

      • Whitespace as an operator .... you mean like Python ....? (It's the one thing I hate about Python)

      • Ever heard of templates?

  • Lisp Syntax (Score:5, Insightful)

    by mechsoph (716782) on Monday November 10, 2008 @01:47AM (#25700733)

    People think that s-expressions are a poor syntax. These people are wrong.

    Seriously, if you give yourself the change to wrap your head around it, s-expressions are both elegant and powerful. Representing your code as a data structure is what makes lisp lisp. Take that away, and you might as well just use ML.

    • Re:Lisp Syntax (Score:5, Insightful)

      by grumbel (592662) <grumbel@gmx.de> on Monday November 10, 2008 @07:36AM (#25702235) Homepage

      Seriously, if you give yourself the change to wrap your head around it, s-expressions are both elegant and powerful.

      Elegant and powerful? Sure. But Readable? No way.

      I like S-Expressions as XML replacement a lot, since for representing simple structured data its quite nice. But it just doesn't lead to very readable code when it comes to programming, even after some years toying around with Scheme, I still find "a = 5 + b" a hell of a lot more readable then "(set! a (+ 5 b))". The first paints a visual picture with clear symbols, the other is just token soup, it might be easy to parse for a computer, but very definitvly not for a human. Array access and a lot of other basic stuff is just a total mess in s-expressions.

      • by Wolfbone (668810)
        I think it must be a matter of personal preference and/or usage pattern which form one considers more readable. Personally, I find s-expressions more readable - especially the more complex ones - because of the uniformity of the functional structure and the natural way in writing Lisp that they are laid out and aligned in two dimensions on the 'page' So e.g:

        (setf val (* (- (cos (sqrt 3))
        (+ 2 h))
        (floor m 1
  • Oh boy! (Score:5, Insightful)

    by jjohnson (62583) on Monday November 10, 2008 @01:49AM (#25700753) Homepage

    Another pocket language with idiosyncratic design choices that seem just right to the understimulated nerd looking for fame.

    • Re:Oh boy! (Score:4, Insightful)

      by Maian (887886) on Monday November 10, 2008 @02:08AM (#25700827)
      He's announcing it way too early. He has practically nothing to show. There's only one tiny code example that I can see to gauge its merits.
      • He's announcing it way too early. He has practically nothing to show. There's only one tiny code example that I can see to gauge its merits.

        When he announced it on his blog a couple of months ago it he said it was in progress. He is still experimenting with the syntax and semantics of the language, so I think it is currently mostly interesting for those who want to discuss ideas and experiment themselves.

  • Clojure (Score:5, Informative)

    by slasho81 (455509) on Monday November 10, 2008 @02:16AM (#25700871)
    If you're looking for a modernized lisp on the JVM, check out Clojure: http://clojure.org/ [clojure.org]
    All the goodies of lisp, the JVM, and functional programming without all the bad outdated stuff. It's a very cool language.
    • Re: (Score:3, Insightful)

      In my opinion, those are the three projects that one has to look into for cool (if you're a PL geek) stuff that is nonetheless bordering on mainstream: Clojure, Scala, and F#. Last two in particular, as Scala seems to be the "future of Java" to many advanced Java programmers who got tired of language limitations, and F# is being made a first-class supported language for the next .NET and Visual Studio release.

      Meanwhile, yet another my-own-programming-language-of-the-day is getting old. There are announce

      • Re:Clojure (Score:4, Interesting)

        by slasho81 (455509) on Monday November 10, 2008 @03:58AM (#25701319)
        There is a lot of buzz around Scala and F#, and considering the limitations they lift from the more conventional mainstream languages it's understandable. But I think Clojure transcends both these languages and many other new on-top-of-another-platform languages because it doesn't just take the latest trendy language features and mix them with new syntactic sugar. It has a very well thought design that feels very right, elegant, and powerful.

        I can't recommend enough the screencasts by Rich Hickey [clojure.blip.tv], the language designer and main implementer.

        The 5th screencast, Clojure Concurrency [blip.tv], is most recommended by me for programming language aficionados. It's a long overview of the language and its philosophy regarding concurrency programming. After I saw that one, I was very excited about Clojure in a way that none of the latest languages made me feel.
        • Re: (Score:3, Informative)

          by slasho81 (455509)
          Slides [googlegroups.com] and code [googlegroups.com] for the 5th screencast about Clojure linked in the parent message.
        • There is a lot of buzz around Scala and F#, and considering the limitations they lift from the more conventional mainstream languages it's understandable.

          I think the buzz is not so much about lifting limitations as it is about those two moving into mainstream application development alongside the likes of Java and C#. It is that upcoming ability to use those nice language features in large real-world production projects that's so exciting (for me at least). Playing with Haskell is one thing, but this is qu

    • by pjt33 (739471)

      Looks interesting. I've been wanting a functional language with a read-execute loop which I can put on my PocketPC for a while, but not finding anything. I'll have to play around and see what I can do with Clojure.

  • by Tablizer (95088) on Monday November 10, 2008 @02:53AM (#25701059) Journal

    Oh great, you combine the white-space-tab problem with the Lost in a Sea of Parentheses problem to get lost in a sea of white space ;-P

  • So... (Score:5, Insightful)

    by julesh (229690) on Monday November 10, 2008 @03:55AM (#25701291)

    the same kind of power they get with Lisp and Ruby, combined with a nice, small, regular syntax

    So, it's Lisp then?

    Seriously... in terms of small regular syntaxes you don't get smaller and more regular than Lisp:

    s_expression = atomic_symbol \
                                / "(" s_expression "."s_expression ")" \
                                / list

    list = "(" s_expression ")"

    atomic_symbol = letter atom_part

    atom_part = empty / letter atom_part / number atom_part

    letter = "a" / "b" / " ..." / "z"

    number = "1" / "2" / " ..." / "9"

    empty = " "

    (source [unige.ch]).

    Next smallest and most regular syntax for a useful language is probably smalltalk, but that's too long to post here. It's worth noting that smalltalk (particularly its first-class statement blocks) was a heavy influence on ruby. Smalltalk also gets close to hitting the 'nice' requirement, which IMO Lisp is a long way from.

  • Joke? (Score:5, Funny)

    by shoban (190941) on Monday November 10, 2008 @03:56AM (#25701303) Homepage

    My eye sight must be getting bad... I misread this as:

    Joke Tries to Combine the Best of Lisp and Ruby

  • "Since it's quite terse and provide powerful features for succinctness, it should be very maintainable."
    Yeah, sure. We all know how maintainable APL and Forth are. Wikipedia identifies as a feature of write-only code "syntax which permits (or encourages) the writing of very dense code." I can't help thinking that "Those who do not learn from history are doomed to repeat it".

  • by Reverend528 (585549) * on Monday November 10, 2008 @09:13AM (#25703161) Homepage
    We already have a programming language with a simple syntax and the strengths of Lisp and Ruby. It's called Lisp.

Lo! Men have become the tool of their tools. -- Henry David Thoreau

Working...