Ioke Tries To Combine the Best of Lisp and Ruby

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

Comments

Try Io

[QuantumG]

http://www.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

[fucket]

Ten?

Re:Try Io

[Smauler]

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 is, despite it's incarnations (or deformations, depending on who you believe) still king, and it was designed in 1972.

Re:Try Io

[Kingrames]

Two. hand in your geek badge.

Re:Try Io

[MrNaz]

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

[Tumbleweed]

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

Re:Try Io

[BountyX]

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:Try Io

[julesh]

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

Re:Try Io

[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 because it's a battle-hardened language, not because of some machine restriction you seem to think exists.

Re:Try Io

[digitig]

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.

Re:Try Io

[Anonymous Coward]

Fancy language constructs are a trap. If you find them useful it is only because they (temporarily) hide your own bad design decisions.

Is that another way of saying real programmers code assembly? Because taken out of context and to its logical conclusion, your argument would seem to imply that.

Language constructs can be good, and can be bad; if your language is too full of them, it becomes write-only, but if it's too lacking, you end up with Java and you need to use design patterns to do everything (people using more functional languages laugh at the pattern hype in OO world, because most design patterns are really just ways of working around the limitations of Java and still getting your work done).

Re:Try Io

[xouumalperxe]

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.

Re:Try Io

[larry bagina]

faster than STL?

Re:Try Io

[DuckDodgers]

Good point.

But the thing is, I can't get paid to use Haskell or Lisp at my job or at any other publicly listed software development job within a hundred miles of my house.

I've been trying to come up with a business model that lets me write my own software in a functional language and keep my kids in school and my mortgage paid. But I haven't found anything yet. So for the moment, I'm stuck with Java to pay the bills.

I realize Design Patterns are hype to overcome language limits. But since I'm not a wealthy retiree with the freedom to spend my time writing only code that interests me, the patterns are the best I can do to reduce some portion of the frustrations of Java development.

Re:Try Io

[Requiem18th]

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.

Re:Try Io

[abigor]

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?

Re:Try Io

[xouumalperxe]

you're still a good hash function away from an actual, usable hash map with STL. Plus, python's dicts have very fancy collision resolution, and some other such goodies.

Re:Try Io

[Chapter80]

Combine Lisp and Ruby, wouldn't that give you Loobie?

Re:Try Io

[SanityInAnarchy]

But the thing is, I can't get paid to use Haskell or Lisp at my job or at any other publicly listed software development job within a hundred miles of my house.

I work with Ruby and Javascript all day -- both more LISP-ish than they get credit for -- and I live within walking distance of work.

Re:Try Io

[SanityInAnarchy]

No, bytecode is not used for compiled code. Wrong again. When java is run on a machine it gets translated into bytecode by the jvm then the jvm executes that instruction set.

Google "Just In Time compilation". Then Google for gcj.

The short answer is: From the application developer's perspective, yes, you are writing for the Java virtual machine. But that's got nothing to do with what actually happens. Sun's JVM dynamically compiles bytecode to native code. GCJ can even statically compile Java bytecode into a native executable, just like C.

And just because I can: No, you're not even right about the JVM translating to bytecode. That's done by the Java compiler.

such as advanced memory managment

Another fallacy -- turns out, for the most part, modern garbage collectors actually outperform manual memory management, and certainly simple reference counting. There are some circumstances where you want to write custom memory management, for performance reasons -- but to choose a language ahead of time for that reason is premature optimization. You can always rewrite that one part of your app in C.

Go look at PHP vs Python benchmarks for hashing and then tell me it dosn't matter when you need a server side script to hash 3k video files.

It doesn't matter. CPU time is cheaper than developer time.

If you need to hash 3k video files, and you happen to have a PHP script ready -- yes, it's going to be slower. So you go to Amazon EC2 and you fire up a bunch of instances -- much cheaper than hiring someone to rewrite it all in Python, and certainly not C.

Re:Try Io

[syousef]

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 is, despite it's incarnations (or deformations, depending on who you believe) still king, and it was designed in 1972.

Yet, so few are learning how to code in C and all new work seems to get done in Java. We recently had need to train a couple of Java developers in C. We eventually found a couple of suitable courses but you'd be surprised how little good training is available. You'd also be surprised how little C is sought in the job market, at least for business/finance industry programming. I certainly was.

Re:Try Io

[tkinnun0]

you're still a good hash function away from an actual, usable hash map with STL.

Hmm, Source->Generate hashCode() and equals()... not good enough for you? Every decent IDE should have something like that.

Re:Try Io

[Up Cracky]

despite it's (C's) incarnations (or deformations, depending on who you believe) still king, and it was designed in 1972.

A lot of that is inertia, hubris and "real" programmers unwilling to leave 1985.

C is the lowest common denominator. If I want to talk to a low level library, or pop up a window then you can almost always trust there to be a C interface. If the proper interfaces existed for higher level languages then it would be safer to use them. My current alpha rant http://upcracky.blogspot.com/2008/10/do-you-see-what-i-see.html goes into more detail about this. It's starting to drive me nuts.

In C you can write blindly fast code, but it comes at the expense of wasted slices of a finite lifetime. You gain speed, but you usually don't need it. Computers are faster than ever and, for many programs, they spend most of their time sitting idle waiting for a human to hit a key or click a mouse.

C has more space for picky little bugs (like memory management). Unfortunately we "real" programmers take great pride in finding these little nits. We should spend less time taking pride in nit hunting and more time asking why we're wasting our monkey cycles on languages that have us do what a computer can do better.

C also has a good, free, popular compiler. Now that Java has open sourced we my see C get some competition in the daemon field. Secure daemons are more important that fast ones.

Re:Try Io

[BountyX]

I stand corrected. Looking back I agree with you and the other anon post. I was mixing and mashing the java compiler with the java virtual machine as if they were the same (athough I meant the JVM in a strict sense, but after suggested research it appears I am wrong). Next time, I'll approach things from a more scientific perspective and not get worked up over an anon post. Seems like my knowledge of java is outdated. Looking at recent benchmarks, java compilers are much more efficient than I last recall. The preformance differences in the language seem negligable at this point which pretty much takes the processor completly out of the equation.

Re:Try Io

[xouumalperxe]

It might be "good enough", but "good enough" isn't "the fastest implementation available", is it?

Re:Try Io

[marnues]

such as advanced memory managment

Another fallacy -- turns out, for the most part, modern garbage collectors actually outperform manual memory management, and certainly simple reference counting.

I feel the need to cry BS. Perhaps garbage collection is better when someone doesn't get memory management. And for large systems where its hard to track down memory leaks, I don't see why you wouldn't use garbage collection. But it is not possible for garbage collection to perform better than a competent engineer.

Re:Try Io

[Kingrames]

2 characters in the character set makes it binary, even if they are i and o.

Re:Try Io

[DuckDodgers]

That's cool. I work in an interesting problem domain with a great group of people, under a genuinely nice CEO. If Java's what I have to put up with to stay here, I can live with it.

Re:Try Io

[SanityInAnarchy]

Perhaps garbage collection is better when someone doesn't get memory management... But it is not possible for garbage collection to perform better than a competent engineer.

You'd think so, wouldn't you? But it's not always true.

There are other ways as well -- every malloc and free that you write inline with your code is, well, more code. Which means more cache misses. A garbage collector should fit into cache for the duration of its run, and then be swapped out.

Certainly, it won't always win. And by definition, a human can always do at least as well because a human can at the very least write that garbage collector, and possibly other things on top of it. But if you care about performance, it is something to consider.

Re:Try Io

[fatphil]

Well cried. Even the knowledgable proponents of GC (Boehm, Zorn) admit there's an overhead to it, but try to dismiss the overhead as negligible, using wording such as "typically competitive" and "only slightly higher". The quick translation of such claims into English is "yup, you got us, they are actually slower and use more memory, sorry".

Re:Try Io

[EvanED]

But it is not possible for garbage collection to perform better than a competent engineer.

It is. In addition to the link posted by the other reply, I've got another argument. I think a lot of this comes from here though I haven't looked at that page for a while.

First, realize that memory allocation in a C world can actually be fairly expensive. I've been tangentially related to a program where the team responsible for it saw a substantial performance improvement simply by switching malloc implementations. Current malloc implementations can be fairly complex, using one of several allocation strategies depending on the size.

By contrast, a malloc in a GC'd language can be dirt simple; in almost-C pseudocode:

void* malloc(size_t size)
{
    static void* next = [start of heap];
    void* mem = next;
    next += (size + sizeof(struct malloc_header));
    (struct malloc_header*)(mem)->size = size;
    (struct malloc_header*)(mem)->gc_info = 0;
    return mem;
}

Basically, just keep advancing a pointer.

Second, deletion in the C malloc world can also be expensive for the same reason allocation is. (In that case depending on the allocation strategy you also have to coalesce neighboring blocks, etc.) Deletion in the GC world -- in the strictest sense -- is free, because the GC will do nothing. If we want to be more fair we compare C's deletion costs to GC costs. There C will usually, but depending on the memory behavior, perhaps not by as much as you'd think. If the program allocates a lot of short-lived objects, that's a lot of deletion work that C will have to do but a GC'd program won't, because the GC cost is only determined by the live objects. Sure each live object will be much more expensive than a C delete, but there could be far fewer of them.

Third, I would argue that to be correct, a C program needs to behave correctly with respect to deleting stuff, or else a long-lived process could run out of memory or start using enough that the system starts behaving very poorly. But at the same time, it's easy to see program types out there that are very short-lived; most of the standard Unix utilities fit this bill. In a GC'd world, it's entirely possible for such a process to have zero deletion cost period if the GC is never invoked. The C version is chugging around deleting things because it needs to in order to be safe, but the GC version is being more optimistic in the sense that it doesn't bother incurring any cost until it figures out that the process is using too much memory. In the case where the process is short lived it wins: the C program incurs extra cost from all its allocation and deallocation, while the GC version incurs none. In the long-lived case, the GC version still behaves correctly and won't put the sort of pathologically bad memory pressure that the C version would have if you didn't delete stuff.

(It is true that in practice this benefit basically isn't seen because languages with GC tend to also have large VMs that take a while to start up and will greatly overshadow the allocation costs the C program incurs.)

Fourth, the extra cost of getting memory allocation right can easily come at the expense of other optimizations that someone working in a GC language would have time to do, or bugs that the GC developer would have time to fix, or features that the GC developer would have time to implement. It's true that this doesn't apply in the sort of ideal "give a great C programmer and a great GC language programmer the same task, give them as much time as they need, and measure the result" problem, but it the real world it still matters.

Now, the concession. I still suspect that almost all the time, a well-written program written in a manually-managed language will win out over an equally well-written version in a GC'd language. But at the same time, this is far from necessarily the case.

Re:Try Io

[tkinnun0]

An "actual, usable hash map" does not require "the fastest [hash function] implementation available". Otherwise, there would be very few hash maps in use.

The "Source->Generate hashCode() and equals()..."-generated hash function runs in O(n) where n is the amount of data to be hashed. What kind of collision rates have you experienced with real world data to warrant a better hash algorithm?

Re:Try Io

[xouumalperxe]

The original argument was that Python dicts provide a superb implementation of hash maps. Someone answered that perhaps STL-based hash maps might compete, and I said that those were a hash function away from a full implementation. That's when you brought up IDE-generated hash functions, to which I answered that those would still be a far cry from Python's implementation. Collision resolution was simply something I know that Python has very well optimized, and why it's such a good general-purpose implementation, not making a point that it was something that happened every other request for a value.

"Best"?

[FlyByPC]

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

Re:"Best"?

[mechsoph]

Make that: (? (is there (part a best (of lisp))))

Re:"Best"?

[QuoteMstr]

The parentheses just disappear after you've coded Lisp for a while. Also, try paredit.el 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 dispatch solution.

Re:"Best"?

[QuoteMstr]

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

Re:"Best"?

[cheater512]

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

Re:"Best"?

[hachete]

Dylan had a very powerful macro system.

http://www.opendylan.org/

with all the advantages of a late-bound language.

Re:"Best"?

[shutdown -p now]

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

Re:"Best"?

[Haeleth]

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

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

Re:"Best"?

[digitig]

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

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

Surely
(p_best_part_exists 'lisp)

Re:"Best"?

[tyler.willard]

If Lisp were that good, it would have done better in the marketplace.

Please.

Market performance has fuck all to do with the success of superior technology. Case in point: the Amiga.

Re:"Best"?

[Simon Brooke]

(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 this morning, and thought, 'oh, no, not another language with bloody stupid syntax.'

Re:"Best"?

[Antique Geekmeister]

Then, if market performance and superior technology have nothing to do with each other, why should anyone invest their money in research? Or are you saying that all technology is performance art, and we may as well paint our bodies paisley and recite poetry from lightposts, because it's just as useful?

Let's look at it again: if Lisp were that superior in solving big problems, it would have solved some of them. As it is, Lisp faces real problems in garbage collection and system resource management, or at least it has traditionally faced such problems. If combining it with Ruby helps address those, great. But I'll believe it when I see it performing well. Even theoretically addressable problems like the traveling salesman problem, or chess playing, break down badly in Lisp until you ignore its 'layers of abstraction' approach and pay attention to the lower levels of the problem.

Yes, I've had to program in Lisp, and it's wonderful for writing an exciting few lines of demoware. But I've also cleaned up after people taught awful, awful habits of ignoring the interface between those 'layers of abstraction' and leaving the problem of formatting data or I/O to someone else entirely.

Re:"Best"?

[ukbazza]

Was that before he went electric ?

Re:"Best"?

[tyler.willard]

Then, if market performance and superior technology have nothing to do with each other, why should anyone invest their money in research? Or are you saying that all technology is performance art, and we may as well paint our bodies paisley and recite poetry from lightposts, because it's just as useful?

This is pure sophistry.

So you don't dig Lisp: fine. However, trying to defend the idea that economic success implies technological superiority is wholely without merit.

Re:"Best"?

[K. S. Kyosuke]

if Lisp were that superior in solving big problems, it would have solved some of them

I think it actually did. :-)

As it is, Lisp faces real problems in garbage collection and system resource management, or at least it has traditionally faced such problems.

When? Where? Any Lisp app I have ever seen has performed much more system-resource-friendly than, e.g., Java apps. And Java is considered a "real" and "businesslike" programming language these days, whatever it means.

Even theoretically addressable problems like the traveling salesman problem, or chess playing, break down badly in Lisp until you ignore its 'layers of abstraction' approach and pay attention to the lower levels of the problem.

Hear, hear! Code written by a lousy programmer performs poorly - what a news...

Re:"Best"?

[dkf]

However, trying to defend the idea that economic success implies technological superiority is wholely without merit.

Because that would imply that your favourite language is a failure, and you find that conclusion unacceptable?

Lisp is a power tool for a Very Smart Person. Like all such tools, they're difficult to master. The truly successful stuff tends to be usable in an effective manner by people who aren't VSPs. (For example, making it easier to see where the costs of resource management are biting makes it easier for programmers to get good performance. Well, for a large enough fraction of programmers for most SW companies to have at least one on staff...)

Re:"Best"?

[TheRaven64]

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 (Io doesn't, Lisp optionally can). The thing that makes me hate Io is that, no matter how much I like the language idea and underlying semantics, the scoping rules are completely insane. They are full of weird corner cases that make understanding even short bits of code a real problem.

Re:"Best"?

[tyler.willard]

Because that would imply that your favourite language is a failure, and you find that conclusion unacceptable?

Hardly.

My personal tastes don't enter into it. I've slung enough (read hundreds of KLOCs) C or C++ to recognize the fact that its commercial success is more of an historical accident than a testament to its characteristics. Also, I'm something of a dilettante when it comes to Lisp; however, that hasn't kept me from appreciating its merits.

Lisp is a power tool for a Very Smart Person. Like all such tools, they're difficult to master. The truly successful stuff tends to be usable in an effective manner by people who aren't VSPs.

I think we're in agreement here. However, again, this doesn't speak to the technological "disposition" of the language. In fact, this seems contrary to your point about the marketplace favoring the best technology.

Re:"Best"?

[harry666t]

http://xkcd.com/224/

Re:"Best"?

[pz]

As it is, Lisp faces real problems in garbage collection and system resource management, or at least it has traditionally faced such problems.

You are confusing reputation with reality.

LISP was the first language that required garbage collection, and that radical idea was fought tooth-and-nail by the rest of academia and industry. But the garbage collection technology developed was fast and reliable (I knew many of the people intimately involved in making the GC for Scheme at MIT). There was certainly an overhead that was paid for running a GC, but the smart folks at various academic and research institutions figured out how to minimize that overhead, and, moreover, spread it out pretty evenly so that your mission-critical system didn't suddenly go autistic for 30 seconds while it went through a sweep.

Fast forward to today. You do realize that Perl has a built-in garbage collection system, right? And that Perl runs thousands upon thousands of web sites, some of which are quite large and commercially successful? That there are thousands of people using it every day?

So, my conclusion: having or not having a garbage collector is not a relevant issue. Lisp just does not, "face real problems in garbage collection and system resource management," nor did it "traditionally [face] such problems." You are parroting an old and stale bit of propaganda.

If these issues were so crippling, as you imply, then how would it be possible to write an entire operating system in LISP? Perhaps you never saw any of the machines like that, but they were legion. There were at least three reasonably successful companies started on that very idea.

But your final paragraph above ("But I've also cleaned up ...") complains about something that has absolutely nothing to do with LISP, but with poor programming. I've taught LISP at MIT, and find that people who have learned LISP from the classic text Structure and Interpretation of Computer Programs (notice the title does not say anything about LISP or Scheme) are far better programmers than those who have not. The people who have not been taught LISP make more of the egregious errors you suggest, because the standard way of learning LISP, in the classroom with SICP, beats the idea of proper use of abstraction into the students.

In other words, and politely, most of your post is bunk.

Re:"Best"?

[Fujisawa Sensei]

Then, if market performance and superior technology have nothing to do with each other, why should anyone invest their money in research?

Sales and marketing.

In a technology market if you don't do research to revise old products and create new ones, your sales and marketing people have nothing to sell and your technology will die. Technological superiority has little to do with this.

Re:"Best"?

[Raffaello]

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"?

[ciggieposeur]

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

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

Re:"Best"?

[Antique Geekmeister]

That's not being a 'lousy programmer'. The problem results from following the most elementary paradigms of Lisp programming: ignore what is happening at the higher and lower levels, and avoid specifying the interfaces to those other details in detail. The results are very painful to clean up.

Re:"Best"?

[Antique Geekmeister]

I'm afraid that my experience was in cleaning up after some of your peers, or possibly even students of yours. The people I had to clean up after were taught by Jerry Sussman at MIT, and they learned extremely bad habits of completely ignoring the higher and lower levels of the problems. I've read Jerry Sussman's 'koans' of Lisp programming, and agree with them overall. It's a shame that the lessons of those koans didn't seem to show up in the programmers _I_ met out of that course.

The result was the _excessive_ use of abstraction, to such extents that I had to go in and violate the abstractions to explain 'You are presenting the data in the wrong order: if you present it in the correct order, which you have been taught not to think about, you eliminate 95% of the load that you are seeing. You need to think about what the system is doing with the numbers, not ignore the underlying hardware or infrastructure.'

A compiled language, like C or even Java, can also try to deal with this by unrolling loops and transforming structures to avoid such classic problems. An interpreted language cannot, and the programmer must understand the limitations, which these gentlemen were never taught.

Re:"Best"?

[DragonWriter]

If Lisp were that good, it would have done better in the marketplace.

Lisp did fairly well in the areas where the problems it solved particularly well were common; C and friends did well where the things it dealt with well were the main challenges. when C was conquering the world, the latter were more common than the former. Increasingly, the problems Lisp deals with well have become relevant to more software, but C-based languages are pretty entrenched (both in systems and in programmer's minds), so instead of Lisp seeing a resurgence, you see C-like languages with more and more Lisp-like features bolted on. (The same is true with "Smalltalk" in place of "Lisp", too.)

Re:"Best"?

[Antique Geekmeister]

It's hardly sophistry, it's the whole point of the patent system and of how I get paid. Technological superiority has market value: while market failure is not proof of technological inferiority, it's proof that the features are not so stunning and useful that they've demonstrated their value other than in the ivory tower. I like the ivory tower: a great deal of fascinating work occurs there, and the lessons of a Lisp expert like Jerry Sussman are fascinating. But the language and its teaching propagate real errors.

Re:"Best"?

[Antique Geekmeister]

Where do you see these benefits? If the C-like languages are already implementing the desirable features, then what do we need new implementations of Lisp for?

Re:"Best"?

[DragonWriter]

If the C-like languages are already implementing the desirable features, then what do we need new implementations of Lisp for?

I don't recall arguing that we need new implementations of Lisp, and this story is not about a new implementation of Lisp, but of a language with syntax that is friendlier to programmers versed in today's dominant, C-like languages that incorporates some of the powerful features of Lisp and Smalltalk.

As for where Lisp has an advantage, it seems to me to be largely in implementing large solutions, at the levels at which dynamic scripting languages are increasingly popular as glue languages for components written in relatively C-like languages like C# and Java (each of which themselves, compared to C, have adopted quite a few Lisp-ish features), and implementing even larger systems, where its quite popular now to do what amounts to coding in XML (via, e.g., BPEL), which is like coding in Lisp but with two angle brackets and an identifier everywhere Lisp would have a paren.

The latter seems to benefit a lot (though this isn't the only useful feature for it) from the code-data interchangeability that you get from homoiconicity, one feature of Lisp (and executable XML) that it is extremely difficult to graft onto a programming language not designed for it from the ground up (and which, unsurprisingly, Ola Bini has chosen as one of the design features of Ioke.)

Re:"Best"?

[DragonWriter]

Lisp is a power tool for a Very Smart Person. Like all such tools, they're difficult to master.

The same is true of C.

I would be inclined to think that syntax-heavy languages like C are harder to grasp initially for a complete newbie than syntax-light languages like Lisp, but also provide a higher barrier to learning languages with a different basic syntax if one of them is the first one you learn in depth, since then so much of your understanding of programming is tied up not in understanding of logical structure but understanding of particular syntax.

Re:"Best"?

[Antique Geekmeister]

Now go read the fine article where it says:

> I have several goals with the language but the most specific one is to create a language that combines the things I like about Ruby and Lisp together.

That sounds perilously close to yet another verson of Lisp. But I accept the concept that a new language might merge the best features of the languages. But let's hope that he avoids the worst features, in the process, because those worst features were absolutely terrible, at least when I had to explain the harsh realities that a layer of abstraction is often poked through by the magician's swords of hardware and data structures.

Re:"Best"?

[Antique Geekmeister]

Sales and marketing do not need to rely on technological supriority. It's one of many features to market, but genuine technological superiority can provide useful features, lower production costs, reduce maintenance, etc. Now Lisp made a lot of promises to elevate computing. Its great promises to understand the human mind, to deal with ever larger and more complex problems, seems to have not been borne out.

Re:"Best"?

[DragonWriter]

Now go read the fine article where it says:

I have read not only TFA, but the much more useful entries on Ola Bini's blog going into detail about the language design, before posting. I know this violates expectations of Slashdot behavior...

I have several goals with the language but the most specific one is to create a language that combines the things I like about Ruby and Lisp together.

That sounds perilously close to yet another verson of Lisp.

Ruby's more like Smalltalk than Lisp, certainly a lot of its unique strengths come from there. Taking those strengths and wedding them to the best features of Lisp doesn't sound like it would get you Lisp.

Further, Ola Bini's more detailed descriptions of what he's done so far and wants to do, including the Ioke code samples, don't look a lot like Lisp.

Re:"Best"?

[ventonegro]

Try it and you'll understand.

Re:"Best"?

[drxenos]

No, no, no. Dylan Thomas, not Bob Dylan!

Re:"Best"?

[Fujisawa Sensei]

Sales and marketing do not need to rely on technological supriority. It's one of many features to market, but genuine technological superiority can provide useful features, lower production costs, reduce maintenance, etc. Now Lisp made a lot of promises to elevate computing. Its great promises to understand the human mind, to deal with ever larger and more complex problems, seems to have not been borne out.

I never said technological superiority, I specified the opposite. I said newer, and revised.

Genuine technological superiority is nice; but in the real world, the product with the best marketing is usually what wins out. If the superior technology can survive long enough, it may win eventually. But the short-term victory belongs to S&M, and that's were next months revenue comes from.

Re:"Best"?

[Antique Geekmeister]

But you're not the one who said technological superiority doesn't matter. I suspect you underestimate its power. But if Lisp is so amazingly technologically superior, as many of its proponents claim, where is the long-term technical success? It remains a pretty minor set of tools in the computing world, despite its elegance.

Outlook negative

[incripshin]

Ola Bini has no beard. The only proof you need that this language will fail?

Re:Outlook negative

[ignavus]

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

Re:Outlook negative

[clarkkent09]

He seems to have the required determination though. His name can be rearranged to "No Alibi" and also "I No Bail"

Hmm, so he's got the weird looks, unusual name and anagrams working for him, but the lack of beard is a serious handicap for a language developer. I guess the future of this language is still up in the air

Re:Outlook negative

[Haeleth]

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

Poor Grace Hopper...

Yet another wannabe Lisp minus macros

[ari_j]

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 if you want to target the JVM.

Re:Yet another wannabe Lisp minus macros

[Maian]

*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, for example. If you don't like keyword arguments, you can define a new method type that doesn't have them. The DefaultMethod currently in Ioke could be implemented purely in Ioke, using macros.

Re:Yet another wannabe Lisp minus macros

[BotnetZombie]

You can also use Clojure, for a Lisp-like jvm language with macros.

Re:Yet another wannabe Lisp minus macros

[ari_j]

The rest of the article? Just how new around here are you, exactly? :)

I still think that it's easier to use macros with S-expressions than with a Ruby-like syntax, but I wish these iokers* luck.

* - In Latin, Jehovah is spelled with an I.

Re:Try harder on the naming front...

[Praedon]

Right, it's ioke. And unfortunately for me, at 1:30am in the morning eastern time, the link is very much slashdotted, but would love to see the info on it... yay for checking slashdot in the morning when I wake up!

Prototype-based? I'll pass.

[QuoteMstr]

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.

Re:Prototype-based? I'll pass.

[Maian]

The problem with JavaScript is that it doesn't have any mechanism to create new syntax simulating classes that desugars down to prototypes. Instead, you have all these ugly hacks.

So really, prototypes aren't bad. It's just that having only prototypes can feel clunky at times.

Re:Prototype-based? I'll pass.

[Animats]

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.

Re:Prototype-based? I'll pass.

[Artraze]

> 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==TRUE), but that's why TRUE is defined as !FALSE (not 1) by clever people, and simply not defined most of the time.

Python: FWIW, Python does have a bool type, it's just that it doesn't really matter (as with a typedef in C). The thing is that without strong types, and the auto-bound, semi-singleton True and False, people never bother typing 'bool' unless they want the true value of an object (i.e. 'bool(obj)').

I think that the Python bit underscores my point: boolean types just don't matter. Python's got it, and you don't even know! Computers only test if something is zero. If it is, it's false, and if it's not, it's true. C exposes this behavior explicitly, while Python sort-of does it in it's rather complex OO way.

Re:Prototype-based? I'll pass.

[Antique Geekmeister]

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.

Re:Prototype-based? I'll pass.

[Haeleth]

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, which means that things end up being more readable, not less, because you can see exactly which characters are literals and which are metacharacters at a glance.

Re:Prototype-based? I'll pass.

[johannesg]

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

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.

So true...

Re:Prototype-based? I'll pass.

[omuls are tasty]

You should've read his comment more thoroughly before replying:

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.

Booleans were only introduced in Python 2.3, and yes, I would call that a "boner" for such a high-level language.

And as a matter of fact, a similar response applies to the other poster for C++ (and Java) and generics. Actually, I think the GP directed the "painfully" part of his post to these two.

Re:Prototype-based? I'll pass.

[LarsWestergren]

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 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 programming over the years. :)

Re:Prototype-based? I'll pass.

[grumbel]

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.

Re:Prototype-based? I'll pass.

[harry666t]

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

Re:Prototype-based? I'll pass.

[JasterBobaMereel]

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

Re:Prototype-based? I'll pass.

[Zerth]

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.

Re:Prototype-based? I'll pass.

[stygianguest]

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.

Python's object system is also a hack with dictionaries, and although my instincts tell me that this is a very bad idea for big programs, it has been used for fairly large systems and libraries. I personally don't really understand how these big programs can be built. Perhaps there's a lot of failed projects that we've never heard of. After all, failed projects do have a tendency to go unnoticed. My guess is that the Python community has a successful culture, one that encourages good coding practices. If so, then I'm amaized that it can make such a difference, but I'm convinced it wouldn't work in most cases.

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.

Ioke is cute indeed. I just think it won't introduce enough new idea's to make it successful. But in my opinion it wouldn't be the syntax's fault, and especially not the points you mention.

Haskell has both whitespace as operators and customiseable operator precedence. These features are loved by the Haskell community. They allow one to avoid much of the parenthesis you'd find in lisp programs. Custom operators are very powerful and should be used carefully, but they can lead to very nice library interfaces.

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.

Agreed, I can find far to few use cases on the Ioke website anyway. In particular, where are all the examples showing how Ioke is much better than plain Io?

Re:Prototype-based? I'll pass.

[Raffaello]

if something is partially visible, it's visible.

If I put my hands in my pockets, thus obscuring them, it doesn't make me invisible.

Re:Prototype-based? I'll pass.

[DragonWriter]

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.

Oh, boo-friggin'-hoo. Ola Bini isn't putting a gun to your head and forcing you to use Ioke tomorrow to replace banking systems. Its, overtly, something he developes primarily for his own sake and shares publicly, and that is exploratory.

Plus, Ola Bini, being (among other things) "a core JRuby developer", one would suspect, all that unfamiliar with working with code written by others.

Lisp Syntax

[mechsoph]

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

[grumbel]

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.

Re:Lisp Syntax

[Wolfbone]

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 11))

as opposed to

val = (cos(sqrt(3)) - (2 + h)) * floor(m, 11)

is preferable to me even though I spend far more time writing maths on paper than I do writing code for computations and might've been expected to find the switch to infix notation jarring. I also like the way the change to prefix form in numerical computations takes away the need to remember (where) to put in the extra brackets one often needs because of considerations of operator precedence.

Re:Lisp Syntax

[fahrbot-bot]

it might be easy to parse for a computer, but very definitvly not for a human

Believe me, you get used to the parens very quickly. In addition, all good LISP editors pretty-print code nicely making debugging relatively easy -- I can spot errant pretty-printed code from across the room.

As for the parsing, a working LISP interpreter only requires about 5-7 primitive functions, usually written in C, with all the others written in LISP (though many others are usually written in the lower-level language for efficiency). An example (though inefficient) list of required primitives are: CAR, CDR, READ, EVAL, PRINT

Re:Lisp Syntax

[grumbel]

Believe me, you get used to the parens very quickly.

The problems aren't the parenthesis, the problem is the lack of advanced syntax. Everything in Lisps looks the same, no matter if its a function, a macro, an assignment, a piece of data or whatever. It is impossible to tell what a piece of code does from the structure alone, because everything looks the same. And no, time won't help, I have spend plenty of time with Scheme and the only thing I have learned is that its today just as annoying on day one.

There is a reason why Python, Ruby, etc. are popular and Lisp not so much and that reason is in large part its syntax.

Re:Lisp Syntax

[dkixk]

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, [...]

Readable. Clean. Two of the most useless words ever used in a discussion about programming. They both reek of the kind of plain spoken "I know it when I see it" sophistry which tries to mask ones own petty preferences with a false sense of "natural" consensus. Unfortunately, this phrase, "I know it when I see it," has stuck in vernacular while almost no one remembers that Potter Stewart later recanted his view in Miller v. California, in which he accepted that his prior view was simply untenable. No programming language has ever been readable to anyone not already schooled in programming. No mathematical notation has ever been readable to anyone not already schooled in mathematics. This feckless obsession with syntax has got to be one of the biggest wastes of brain power since theologians debated how many angels could fit on the head of a pin. One of the examples of using the Lisp pretty printer published at around the same time as its introduction, if I my history is correct, was using the pretty printer to print a subset of Lisp as Pascal. Dylan already tried adding a more Algol-like syntax to Lisp. Paul Graham's Arc is yet another go at tacking some kind of level of extra syntax to Lisp. Qi has already added a sophisticated static typing system to Lisp. There is absolutely nothing new or interesting about any of this.

Re:Lisp Syntax

[fahrbot-bot]

Everything in Lisps looks the same, no matter if its a function, a macro, an assignment, a piece of data or whatever. It is impossible to tell what a piece of code does from the structure alone, because everything looks the same.

There is a reason why Python, Ruby, etc. are popular and Lisp not so much and that reason is in large part its syntax.

Which is why LISP popular in AI. Self-modifying code is easy in LISP. Automatic generation and execution of abstract-data types (a research project in college) is easy in LISP (well, less difficult). Automatic code generation, analysis and proof is easier...

When I was in college, I read about a code translation program written in LISP. Translated itself into FORTRAN - ugly, ugly proof of concept result :-)

Still, to everything it's own purpose...

Re:Lisp Syntax

[Tiny Elvis]

Everything does not look the same. There are very common patterns that you will begin to spot almost immediately, like:

(defun func (args)
  code)
 
(let ((bindings
      bindings))
  code)
 
(do ((bindings
      bindings))
    (stop-form ret-form)
..code..)

And so on. As a lisp programmer these things will immediately register when you look at lisp source.

Re:Lisp Syntax

[renoX]

In AI maybe, but trust me in normal program the less you have self-modifying code/generated code, the better: when there's a bug how do you debug it?

Your debugger doesn't undestand all these generated thing, so you have to undo 'manually' the transformation to be able to find what is wrong..

Re:Lisp Syntax

[DragonWriter]

There is a reason why Python, Ruby, etc. are popular and Lisp not so much and that reason is in large part its syntax.

Actually, I'd argue that the reason is that Python and Ruby were comparatively new at the time when people were looking for the benefits they provide, where by then Lisp (and, for that matter, Smalltalk) was not new, and thereby inherently uncool.

That Python and Ruby syntax is more familiar to users of C-style languages is also helpful (though that's probably a result of when they came about; since both were created after C had taken over the world).

Everything in Lisps looks the same, no matter if its a function, a macro, an assignment, a piece of data or whatever.

Yeah, its kind of like XML that way.

Of course, XML is probably a popular data representation and even, increasingly, a popular way to express executable processes (i.e., programs) for large systems (e.g., in the form of BPEL) for a reason.

Homoiconicity is a good thing.

Re:Lisp Syntax

[fahrbot-bot]

In AI maybe, but trust me in normal program the less you have self-modifying code/generated code, the better: when there's a bug how do you debug it?

Granted, less is better, but you do what you gotta do. You debug it like other (basically) data-driven programs (which I write a lot in Perl) - carefully :-) In the end, the simple, regular syntax makes it easy(ier) to do things almost impossible in other languages. Everything has its place...

One of the coolest system I ever used was a Xerox Dandelion back in 1985. A dedicated LISP workstation running InterLISP-D. Everything was written LISP, including the editor, so you could edit/run your code live. I think the one we had for our research project cost ~$50,000.

Re:Lisp Syntax

[majiCk]

[...] Take that away, and you might as well just use ML.

And then you'd get a powerful static type discipline to boot! Hey, come to think of it, maybe that's actually more useful than being able to treat code as data...

Re:Lisp Syntax

[mechsoph]

Eh, static types can be useful sometimes, but they're not the cure-all to software bugs that some people seem to think.

There's nothing fundamental to lisp (aside from the CL spec...) the precludes using static types. These people even did it.

Re:Lisp Syntax

[renoX]

While I agree that no syntax is natural, it still remains that programmers like some syntax better than others, and even if it's only fashions they're quite strong: currently Lisp has no chance to become a widespread PL again due to its syntax (too bad though that it wasn't used for documents as XML's syntax is even worse).

Re:Lisp Syntax

[Nicolay77]

AFAIK (I mean, I have shown the code to my friends and this is their feedback):

C++ is more readable for computer engineering guys. They've been using that syntax for years. They have their own cruft in their heads already (just try to make them change their favorite code editor to see this).

Lisp is more readable for math and physics guys. Yes, when I let them see Lisp code, they had no previous exposure to C++ syntax, except for that very semester. Who would guess?

So, to me your comment is more about programming culture that any real intrinsic quality of the language.

Re:Lisp Syntax

[dkixk]

While I agree that no syntax is natural, it still remains that programmers like some syntax better than others, and even if it's only fashions they're quite strong: currently Lisp has no chance to become a widespread PL again due to its syntax (too bad though that it wasn't used for documents as XML's syntax is even worse).

Is it even worth responding to a post that starts with the admission that no syntax is natural, that programmer preference can be based on things as fickle as fashion, but somehow that which is as it is now must always be and that which once was will never come again? Or perhaps you mean to imply that Lisp syntax is bad syntax in some kind of Chomsky deep grammar sense, like 80s perms were so hideous that they will never come back in style. But I definitely don't want to leave the impression that I'm comparing Lisp syntax to 80s perms. And I certainly don't want to discuss fashion with anyone on /.

As John McCarthy explained in History of Lisp

The project of defining M-expressions precisely and compiling them or at least translating them into S-expressions was neither finalized nor explicitly abandoned. It just receded into the indefinite future, and a new generation of programmers appeared who preferred internal notation to any FORTRAN-like or ALGOL-like notation that could be devised.

It wasn't that no one was technically able to realize the syntactic layer of meta-expressions. In fact, apparently someone from the Arc crowd has bothered to write a reader for M-expr syntax. As people started becoming familiar with the S-exprs, they found no benefit in continuing to work on M-exprs. Not to mention that the very lack of syntax is what makes Lisp macros so powerful.

So, I agree that Lisp will probably never become popular with anyone who would rather spend their time worrying about things like skinny ties or wide ties, tight pants or baggy pants, arrows or dots, or ~%$#@!, etc. Lisp will probably continue to be interesting to people who would rather focus on programming language semantics exactly because it frees one from almost all of the superfluous concerns of syntax. Oh, and when they're done, they could also easily add a nice syntactic layer on top of it, but they probably won't bother because who needs it? Besides, someone else will probably come along and "invent" a new language which will steal the ideas, but make sure it's wearing the right pants and has the right hair. Apparently, we have Python to thank for the return of significant whitespace, an idea which should have died with Fortran and punch cards. Talk about the 80s perm of programming language syntax.

Re:Lisp Syntax

[renoX]

I was going to reply but I changed my mind: your post is so full of itself, that it really doesn't deserve a reply..

Re:Lisp Syntax

[dkixk]

Hello? Pot? Yeah, this is kettle. I just called because I wanted to tell you that you are so black.

Ah, but you did replay. Fortunately for me, the complete lack of content in your comtemptuously unresponsive reply means that I can ignore your humble proclamations of The Way Things Are.

Now, I wasn't claiming that all language exploration was, is, or ever will be done exclusively in Lisp. However, the fact that Lisp syntax so throughly supports macros and other forms of syntactic abstraction makes it very good for exploration. Consider, for example, Context-Oriented Programming. Pascal Costanza has been very active in this area of language research, having worked on both ContextJ* and ContextL, the former an implementation of aspect-oriented programming in Java and the later being AOP in Lisp. He had the following to say about AOP and Lisp:

It's no wonder that the Java crowd likes AOP so much. In Java, you neither have macros, nor higher-order functions nor a serious reflective and/or metaobject API. In other words, there are no (convenient) ways to do metaprogramming, except for some mild versions thereof in java.lang.reflect, or the cumbersome ways via inner classes, or if you dare to do this, via hacking around with custom class loaders. (Ah yes, together with annotations, Sun has also introduced some tools to do program transformation...)

Compared to those options, tools like AspectJ, Spring AOP, and so on, are a breeze. (And due to clever marketing, the Java people don't even realize that they are using a (limited) subset of metaprogramming techniques here.)

It's interesting to note that in C#/.NET world, AOP hasn't caught on. I suspect that this is due to the inclusion of first-class methods from the start.

Lispers and Schemers are, in general, not impressed by AOP because macros, higher-order functions and, in CLOS, a full-fledged metaobject protocol make metaprogramming very convenient and, after an admittedly steep learning curve, very straightforward.

And it is exactly Lisp's homoiconic syntax which makes macros so convienent in the language. In my apparently not so humble opinion, Prolog is another one of the few homoiconic languages. One of my favorite examples of the power of Lisp macros comes from Paradigms of Artificial Intelligence Programming , in which Peter Norvig implements a Prolog as Lisp compiler in Lisp which effectively introduces a new dialiect of Lisp with support for unification. Franz weaponized it and now includes it in their Lisp as Allegro Prolog . How many languages allow for one to completely and seamlessly embed another language in it?

Allegro Prolog does not attempt to be ISO compliant or implement the entire language. Many standard Prolog arithmetic, predicate operators, and I/O operators are not implemented, as they are a subset of the standard Common Lisp operators

But they could, if they wanted to bother to write reader macros for ISO Prolog syntax. But what's the point? They don't have the Prolog syntax but they've got all of the Prolog semantics. So, yes, perhaps Lisp will never become a mainstream programming language because it has an atypical syntax that many programmers don't like. However, I think that is being just a little bit full of one's own petty preferences for things like {$@.->*!%?} over () to dismiss all that flexiblity just because of syntax.

Re:Lisp Syntax

[renoX]

Well your other post said basically Lisp is for interesting people, all the other who cares about syntax doesn't matter, what do you expect me to answer to this??

Lisp is probably very good for research as it free the researcher from syntax, but for the other 99% of developpers who don't do language research but who maintain existing programs in C, C++ or Java, I doubt that you would convince them that syntax doesn't matter..
That's why the next big programming language may be one of those: D, Scala, Ruby or Python but not Lisp.

As for AOP, personnaly I've never liked it (seems like a mess for anything but logging), I think you can mostly solve the same issue in more advanced language with mixins with less crosscutting concerns. I've seen less and less articles in favor of AOP and more and more against it, so I'm not convinced that it won't join 'push' and the like in the big rubbish bin of the failed ideas in computing..

Re:Lisp Syntax

[dkixk]

Well your other post said basically Lisp is for interesting people, all the other who cares about syntax doesn't matter, what do you expect me to answer to this??

Fair enough. I didn't mean to imply anything like that but perhaps I went to far when I mentioned 80s perms. ;-)

Lisp is probably very good for research as it free the researcher from syntax, but for the other 99% of developpers who don't do language research but who maintain existing programs in C, C++ or Java, I doubt that you would convince them that syntax doesn't matter.. That's why the next big programming language may be one of those: D, Scala, Ruby or Python but not Lisp.

Well, I am one of the bulk of those programmers maintaining an existing system. At least, that's what I do for my day job. And I doubt that is likely to change anytime even within the next decade, if I continue to stay with the same company. Our system is simply not going to be rewritten in any new language unless it is the first to introduce something amazing like a DWIM feature. In fact, if you listen to some of the pundits, the next big programming language just might be COBOL. Legacy inertia can often be the immovable object standing in the way of the unresistable force of the Next Big Thing. And I've personally gotten so sick of the YASL family breeding like rabits that I won't bother looking at another one unless it does something significantly different from all of its cousins.

But it seems I am guilty of having thrown another shovel full on the steaming pile of myth that Lisp is only good for research. Practical Common Lisp is full of excellent examples of using Lisp for "normal" problems. My personal favorite exmaple is the way he uses macros to help with the task of parsing ID3 tags in MP3 files. Having had to deal with things like ASN.1 compilers in the past, I immediately fell in love with the way he basically did the same thing as is done with ASN.1 but without ever leaving Lisp.

I currently use Common Lisp (mostly SBCL and sometimes Clisp) everyday for the kinds of tasks for which I would have reached for Perl in the past. An Emacs user, I'm merely a "M-x slime" away from wherever in Lisp I may want to be, including the entire mush of elisp floating out there in the tubes of the internets. CL-PPCRE already gives me in Lisp most of what I might have missed from Perl. Implemented entirely in Common Lisp, it even out performs Perl's regular expression engine for some benchmarks. But what I love about using Lisp for these kinds of "write once" "scripting" tasks is that I have full access to all of Lisp's features if I find it useful. For example, I've been able to use Allegro Prolog for an install script of somewhat limited intelligence. (I'll try posting code after this because I'm having problems with /. formatting rules.)

As for AOP, personnaly I've never liked it (seems like a mess for anything but logging), [...]

Okay, but the point wasn't so much AOP as it was how unnecessary it is introduce a whole new programming language tool to get the same functionality from Lisp. To introduce AOP into Java required mucking about with the core of the Java language. In Lisp, "all" one needs to do is crank out some macros and perhaps a few new meta-objects.

And so much of all of this is made possible by Lisp's macros which are, in turn, so useful because of the very syntax which is what so many people love to hate.

Oh boy!

[jjohnson]

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

Re:Oh boy!

[Maian]

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.

Re:Oh boy!

[LarsWestergren]

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.

Re:Oh boy!

[DragonWriter]

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.

Oh noes, he is sharing information about his personal language design project with people (and soliciting input) before he has a production-grade system ready for release. Horrors!

Look, if he was a big company, and he was trying to sell the idea that some competitors offering shouldn't be used because Ioke was going to be out Real Soon Now and would be so much better, and only had outlines and ideas and a very minimal implementation of some fraction of those ideas, then, yeah, this would be "too early" and deserve criticism on that basis. But that's not what he's doing.

Clojure

[slasho81]

If you're looking for a modernized lisp on the JVM, check out Clojure: http://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:Clojure

[shutdown -p now]

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 announcements of those pretty much every week on LtU. It may be interesting if it really explores some new dark corner in language design (particularly experiments with more powerful typing systems). But "combining the best of X is Y" is not it, sorry.

Re:Clojure

[slasho81]

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, the language designer and main implementer.

The 5th screencast, Clojure Concurrency, 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:Clojure

[slasho81]

Slides and code for the 5th screencast about Clojure linked in the parent message.

Re:Clojure

[shutdown -p now]

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

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.

STM is seriously cool, but present-day implementations are still too slow (even though the scalability is theoretically much better... but hey, we've got to run it on today's hardware). The rest of the bunch don't seem to be unique on the first glance - at least I don't think there's anything there that F# + PLINQ don't cover (and possibly something else - it just so happens that I'm mostly a C++ and .NET guy, so that's what I'm most familiar with).

Lost in a sea of

[Tablizer]

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

Yep, combining Lisp and Scheme does it for me ...

[wombat21]

Is there a (popular) dynamic language that --hasn't-- combined facets of both Lisp and Scheme in its design ? And (inevitably) gotten it 'wrong' according to the Lisp/Scheme diehards on /. ? We want it all - purity, simplicity, power and blinding speed - but every 'new' language/platform will be held up to the light of these two standards. For mine, the language is only part of the equation - its the libraries that the community contributes which make it practical to use language X over language Y. I'll stick with Perl, Python and Java for now. YMMV, and probably will.

Per-function optimization

[ion.simon.c]

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

Re:Per-function optimization

[Haeleth]

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.

Re:Per-function optimization

[xouumalperxe]

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.

Re:Per-function optimization

[Raffaello]

Another quite common tradeoff is between safety and debuggability on the one hand, and speed on the other. When developing one will globally declaim:

(declaim (optimize (speed 0) (safety 3) (debug 3)))

to ensure that the compiler inserts all possible safety checks and maintians as much debugging information as possible for use in stack backtraces when you drop into the debugger.

When a function or method is fully tested and debugged, and a profiler shows that it is indeed a hot spot in need of maximum compiler speed optimization, one then adds whatever type declarations may be necessary and locally declares:

(declare (optimize (speed 3) (safety 0) (debug 0)))

This way you have maximum safety and debuggability when developing code, but once you know something is a hot spot and you've fully debugged and tested it, you can remove the safety checks and debugging info and just optimize execution speed for that function only.

Meanwhile, you can continue to develop the rest of your code with the highest safety and debug settings getting the best of both worlds.

Re:Per-function optimization

[xouumalperxe]

Yes, I thought of that example as well, but figured that, even if logical and actually useful, it'd be too vulnerable to "you're not seriously shipping with debugging turned on" followed by "but you don't need to optimize code before gold". Even if those would be completely barbaric things to say, I wanted to avoid stupid arguments over them :).

Re:Per-function optimization

[petermgreen]

I can think of at least a couple of big ones

One is compiler bugs/dubious optimisations, like it or not compilers often have bugs. They also sometimes make optimisations that are ok per the standard but break your assumptions. Being able to turn off optmisations on a per function basis would allow such issues to be worked arround easilly without knocking the entire source file down to a lower optimisation level.

Another is size vs speed, in an embedded application both memory and cpu time are often in short supply and being able to decide which to prioritise on a per function level could be very usefull.

Re:Yep, combining Lisp and Scheme does it for me .

[__aabvlw4075]

Um, Scheme is a Lisp.

Re:Awesome another langauge

[ABasketOfPups]

Not one single soul in the world who was ever going to make a language, is now not going to, because of that rant.

Re:Try harder on the naming front...

[stjobe]

I think it should be pronounced "joke", which seems to fit...

Re:Awesome another langauge

[Waccoon]

I say we stop all development entirely!

Its likely in this cause being that its built on the JVM, that people should probably just use java anyway.

I'm not a Java expert, but... Java does everything that Ruby and LISP does without having to jump through hoops?

So...

[julesh]

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

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.

Re:So...

[Haeleth]

Unfortunately that nice small regular syntax is only for the Lisp core. The actual language that you need to program in has all kinds of other syntactic features, starting with 'symbols and `(macro ,@quoting) and going rapidly downhill from there.

Re:So...

[JasterBobaMereel]

People who do not know Lisp are doomed to reimplement it - badly

Re:So...

[JesseMcDonald]

You don't actually have to use those features, of course -- they're just shorthand. The 'symbol pattern, for example, is just translated by reader macros into (quote symbol), and `(macro ,@quoting) becomes (append (list (quote macro)) quoting).

The actual syntax of Lisp is defined in terms of data structures, not characters, and at that level there are really only two atomic forms, literals and symbols, and three list forms: special operators, macros, and function calls.

Re:So...

[z-j-y]

Next smallest and most regular syntax for a useful language is probably smalltalk

What?! You are saying that Turing Machine Language is not a useful language?

Joke?

[shoban]

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

Joke Tries to Combine the Best of Lisp and Ruby

Re:Joke?

[machine321]

They should have called it Luby. I can see the want-ads now, "Experienced Luby programmer wanted for large adult web site."

Re:Joke?

[cyborch]

Hmm... How could you possibly suggest Luby and not go with an Engrish joke?

Re:Try harder on the naming front...

[fractalVisionz]

Right, it's ioke.

You mean, "Right, it's a joke." In some browsers, the bottom of the j is cut off. I invented a new language too, named asdlkj. It is whitespace combined with brainf*ck that sits atop the microsoft JVM that compiles down to executable php.

Here is some sample code (tabs in [tab]):
+ + + + +[tab]<[. -]-.[tab] [tab]>-- [tab]<.+.

I'm still trying to understand what it's supposed to do.

Logic compression

[TheLink]

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 powerful for a certain field will have good defaults so that a programmer does not have to do as much work to compress the rules. Typical faxes will compress very well using the standard fax compression method.

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

You can have a newfangled language which has better compression that other programming languages so that you only need 1000 lines to do X, but it still is not that attractive if you still have to write all 1000 lines yourself, in contrast to using a language which requires 2000 lines to do X, but you only have to write 500 of those lines yourself. Others have already written the other 1500 lines AND best of all have documented and are maintaining them :).

Marketing and positioning can be quite important in order to somehow convince enough people who like writing those 1500 lines to take up your new language.

You can't expect lazy crap programmers like me to write all that code :). We'd rather do stuff like:

use LWP; ...

Or:

import pyrad.packet
from pyrad.client import Client

Another problem with some languages favoured by CS academicians is they require very very smart people, and there are far fewer very very smart people than smart people (and far fewer smart people than stupid people).

At a certain point conciseness (compression level) isn't as significant compared to the other overheads.

So the ultrageniuses might not be much faster than the "merely smart" in writing the modules that the stupid people are likely to want to use, even if they use your superconcise language.

And if there are 10x more "merely smart" than ultrageniuses, no wonder the stupid people pick the less powerful language - there might be 3-5x more libraries that they'd want to use.

The ultrageniuses would be doing ultragenius stuff, so the modules they write might not be so useful for stupid people like me.

And that's why some crappy languages are so popular (but I could be wrong since I'm stupid).

Re:Logic compression

[JJJK]

A language can still do both... D for example. It can be easy like java (with a garbage collector), if you want you can still allocate/free memory yourself, use pointers, inline assembly, or you can go wild using templates and string mixins everywhere and write ten times less code.

Re:Logic compression

[Medievalist]

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

I realize you're making a larger point, but... I actually worked for several years with a guy who programmed exactly that way. In any language.

Ed's programs took ages to write, but were awesomely simple to maintain.

I'm pretty sure my brain would explode and dribble out my ears if I was required to write code that way.

Re:Logic compression

[try_anything]

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 of C development in a dramatic way. Writing in C used to involve a lot of pain in searching for libraries, packaging the libraries for your platform, and managing the installation and deinstallation of the libraries. Now you can just have to package your own code and let the package manager handle your dependencies. Let's hope other languages that are lacking a distribution system figure out how to piggyback on the Unix package managers.

Compare programming in Perl, Ruby, or even C to the state of affairs in Common Lisp -- my favorite language-as-a-language -- where gossip on comp.lang.lisp is the means of finding a library, a url posted on comp.lang.lisp is the means of distribution, and soliciting example code on comp.lang.lisp is the means of documentation. The situation has improved dramatically thanks to CLiki, but CLiki seems to be the work of few next-gen Lispers who understand that such a site is de rigeour, rather than a natural practice by the community as a whole. You get the feeling that many old-school Lispers don't think there's any real advantage to the lazy, ignorance-enabling, immediate gratification way of doing things.

Personally, I love being able to just download a library, install it in a standard way, look at a few examples on the library's web site, and refer to the automatically-generated documentation as needed, but I understand that some people find such a procedure to be utterly tasteless and devoid of adventure. When I was a high schooler taking Latin I, I remember thinking how wonderful it would be if suddenly everything I tried to read was in Latin. Everything at the supermarket -- just a blank package labeled in Latin. Street signs: all the same color and shape, just Latin text. I could struggle through and maybe get bad grades for a year, and then I'd be ninja at Latin. Nowadays such a prospect, while still exciting, fills me with panic. I have too many responsibilities. It would take me three hours to plan and execute a trip to the grocery store. I couldn't check whether the pharmacist handed me the right pill bottle. I'd lose my job. Where would I find a date who wouldn't be weirded out by my unexplainable ineptitude? Starting a project where I had to write most of the libraries myself would feel the same way.

I think all programmers now admit that convenience can trump aesthetics, and real convenience trumps potential convenience, but it's the younger generation that will drive progress, because they simply aren't willing to put up with a language that has no libraries and no community institutions. Most people writing new languages these days take it for granted that their language has to provide good documentation and immediate, natural integration with a vast array of libraries. A decent C ffi no longer suffices, unless your language feels like C and has a traditional code-compile-run cycle. At the moment the only good platforms for a new language are Java and the .NET CLR. Here's hoping Parrot takes off, too, so we have a access to an amenity-rich, library-rich language platform for short-lived programs that need to start up quickly.

Re:Logic compression

[ciggieposeur]

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 HTTP sockets or threads or GUI or ... and there isn't a single decent FOSS Lisp implementation that actually runs on Windows/Mac/Unix.

I finally found my answer though: Clojure.

There's something pretty cool with using Lisp to wrap a Java/COM bridge, pulling data into JFreeChart and analyzing it with Commons Math.

Re:Logic compression

[InverseParadox]

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?"

My brain keeps wanting to interpret those "X" es as the X Window System... and powerful as Lisp may be, I quite sinceriously doubt that it can do the full X Window System in less than a few thousand lines. ^_^

Re:Logic compression

[ClassMyAss]

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 set to automatically add Javadoc stubs to every method you write, it's almost impossible not to properly document your public interfaces; you feel "dirty" until you fill those guys in, and since it only takes a few seconds to do so, people actually tend to do it. And exporting a full set of HTML documentation based on that is a click away. Compare that to most other languages, where half the time the only way to figure out what the hell is going on in a library is to read tutorials or actually dig into the source code.

No surprise

[Sycraft-fu]

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.

Re:No surprise

[phoenixwade]

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

Re:No surprise

[TeknoHog]

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 things, because you could use a more suitable language and retain that information all the time.

Re:No surprise

[savuporo]

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

[jhol13]

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/

Re:No surprise

[Estanislao Mart�nez]

That's because C deals with how computers actually think.

Only to the extent that processors are designed to run C programs; and ss it happens, contemporary processor designs are more complex than the would otherwise need to be, in order to better support C programs. Look at Itanium as a (commercially) failed attempt to design processors otherwise.

Re:No surprise

[alyosha1]

That's because C deals with how computers actually think.

No. C presents a highly idealised representation of how computers actually think. According to C, there are two types of data storage; disks and memory. One is accessed through fopen() etc., and the other through malloc() and its kin.

However, on any modern OS, calling fopen(), read() may well return me data that was residing in-memory in a file system cache, and a call to malloc() may well result in a pointer to data that's actually residing on the harddrive in the swap file. Then throw in things like L1, L2 cache into the mix, and we realise that we are writing code against an imaginary, idealised machine. I'd suggest that even by the time we reach 'C', we're in the realm of 'nothing at all to do with how the processor works'.

So why not keep going, and build newer storage models that don't make an arbitrary division between 'memory' and 'disk', and certainly don't force these upon the end-user?

Some of the nicest programs I've used recently, such as Adobe Lightroom, have done away with the concept of a 'Save' button entirely - changes the user makes to data are immediately reflected in the SQLite datastore. The end user, who's not a programmer, doesn't need to maintain a mental model of memory, filesystems etc.

Re:No surprise

[SanityInAnarchy]

That's because C deals with how computers actually think.

It actually really doesn't. Assembly is closer, but still not what's actually going on.

For example yes, pointers are confusing and you can get in to trouble with them. However, that is actually how a processor handles things.

Yes, registers are confusing and you can get in trouble with them. However, that is actually how a processor handles things.

There's a reason you use C, and not assembly. It's the same reason I use Ruby, and not C.

you need to be able to write a program based on how the computer thinks, not on how you do.

When performance is critical, yes.

When it's not -- and it's usually not -- it's infinitely more important to have a program structured well enough that you can work on it a month, a year, five years from now.

Consider Doom. Since the source was released, a lot of the efforts to improve it -- other than the obvious, like porting it to OpenGL -- have been to remove all the clever optimization hacks, and rewrite all the assembly in C, so that it's portable. And this had to be done in order to port it to architectures other than x86 -- all of which are so ridiculously fast that Doom's performance really doesn't matter.

Doom was released in 1993. In 15 years, which of your optimization hacks -- in assembly or in C -- are going to make it difficult to work with your software? What platforms are you not going to be able to target because you wrote it so low-level? (Think: Doom could probably run as a Java applet in a web browser, but it wasn't written in Java, or in any high-level language that can now target the JVM.) What obscure bugs do you still have because you didn't quite manage your memory as well as you thought?

Re:No surprise

[ClassMyAss]

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.

And yet a VM performing all possible optimizations is actually capable of outperforming optimized C code precisely because of the fact that there's no opportunity to mess with pointers directly; pointers end up confounding some of the most important optimizations (ones aimed at reducing cache misses, which are going to become more and more important as processor speeds go up and memory speeds stay the same - most processors currently just sit around waiting for memory access, not actually doing anything, and this will only get worse over time).

It's already very simple to show code where the JVM (yes, in its current form, where it doesn't apply even some of the most basic optimizations) outperforms similar C code; this type of thing is going to become more and more common over time as VMs get more sophisticated. And ironically, the only reason memory layout optimizations are even possible is that VM languages tend to remove the ability to directly refer to memory addresses (after all, how can you move an object around in memory safely if you let the programmer hold variables that directly refer to the location the object is stored in?).

It's like the argument about coding assembly vs. using an optimizing compiler - yes, in the "good old days" it was probably pretty easy to hand code better assembly than your compiler could produce, but over time the number of tricks that the compilers use has grown to the point where now only the hardest-core of assembly hackers could likely outdo even a decent compiler, and most people would just end up writing slower assembly than their compiler would output based on the C that they could write with a tenth the effort. Right now we're nearing the end of the "good old days" of manual memory management; pretty soon, we'll hit the crossover, and from there on out, VMs will actually be the best choice in terms of performance.

Frankly, we'd be there already if Sun wasn't in control of the Hotspot JVM - they are too resistant at the moment to adding further optimizations to the VM, even though they know exactly what they are and how to implement them, for the fear that people will balk at the miniscule increases in compilation time. Or maybe it's really because they are in poor financial shape and don't have enough people on the project to properly do these things, esp. since the bulk of business users are already satisfied with the ~50% to 75% of C speed that they already get. But make no mistake - the theory is solid, and there are already very simple cases where a literal port of C code to Java will make the code 3x faster (try computing over a pair of long float arrays in both, something like a sum of products - on my machine that simple bit of code runs quite a bit faster in Java than in C because Java doesn't have to arrange each array contiguously in memory).

Re:No surprise

[marnues]

Low-level stuff is generally messy. As far as I've ever seen you have either clean or efficient. Since you like c++ code pretty much tells me you're not going for efficiency. Unless compilers have changed much since 2003 (the last time I touched c++, thank $DEITY) it produces unnecessarily bloated apps. I can't think of a reason to be writing low-level code unless you want efficiency...

Re:No surprise

[joshuac]

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.

You can say all the same for a low-level language like assembly, only more so, which makes it the coal mine canary for a "mid level" language like C. In 10 to 15 years I suspect you may see the same percentage of development done in C as you see in assembler today. Why "hand code" your entire video game in C when you can lazily write in very high level language like Java and still get 30+ frames per second?

Go back 15 years, you would still see relatively plenty of hand coding in assembler. Now, almost never except maybe in very small, tight subroutines.

Re:No surprise

[savuporo]

Read Joint Strike Fighter coding guidelines, and then come back and lets discuss this again. Or any embedded C++ reference material.

C++ doesnt produce bloat, programmers do.
I work with embedded systems often, in some instances with few tens of KBs of RAM available, sometimes even way less and i have rarely encountered a task where C code would be desirable, except where you are fitting in a piece of functionality between predefined C-like interfaces.
Assembler, yes, for these few performance-critical routines and the app happens to be cpu performance bound ( most arent ) , but not C.

Re:No surprise

[ventonegro]

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.

I use C in my day job and I like it, but I prefer to code in Scheme because it is closer to what a human being thinks. 95% of the software out there do not need to run at full CPU speed, so we can spare ourselves the pain and code quickly in an elegant, beautiful language.

BTW, despite all prejudices, Scheme is not as slow as most people believe.

Re:No surprise

[badkarmadayaccount]

You have just reinvented the one-level memory model of Multics and its kin. Congratulations. Ironicaly, they were made because people then thought they would be using Solid State Storage, which is happening just now.

Re:No surprise

[badkarmadayaccount]

Mod parent up, pretty please!

Re:No surprise

[mgiuca]

Why would I want to write software based on how computers think when I have languages which work how I think?

Developer time is far more expensive than CPU time these days, so we really need to cater to those people in most cases.

(Sure, there are platforms and situations where it's necessary to use lower level languages, but I reckon the wide majority of cases would benefit from more efficient development in a higher-level language).

Re:No surprise

[lsatenstein]

I am just an old dos c programmer, and here is my take. C is a wonderful language for multiprocessors, even if the low level programming paradigm is followed. The changes will not be in the language, but as I see it, in the function call process. When a function is invoked, the function may be treated as a task and therefore, for it's execution life may be scheduled to one of the processors in the multi-processor chip. That means that if the compiler is not intelligent, we may have to add function property type qualifiers similar to "static" or some other property. That new type would tell the operating system how to schedule the function to a processor. There of course would be some mechanism to force functions to specific processors or to be separate or bound together on the same one.

Thanks

[pjt33]

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.

Re:Awesome another langauge

[johannesg]

Not one single soul in the world who was ever going to make a language, is now not going to, because of that rant.

I don't know. I was going to invent a language this morning, but after reading this I'm having second thoughts.

What should I do?

From the RA:

[digitig]

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

(eq high-level-language scripting language)=false

[teazen]

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 language. I'm sure even the most rabid PHP fanboi (if they even exist), will agree with me.

There are a good number of high-level languages which are a good bit more flexible at a much higher performance rate than Python. Take some of the functional languages like Haskell or ML, Lisps like CL or Scheme, or Forth or Smalltalk. Not that shootouts say everything, but just compare a few benchmarks at http://shootout.alioth.debian.org/

And why are they faster? Because they can be (byte-)compiled quite efficiently. Python however was never designed with compiling in mind. And as such, there still isn't a worthy full-fledged Python compiler for real-live use. And as I understand it, Python is very dynamic in a way that's gonna be quite hard to compile.

Now Python is an elegant scripting language that is easy to pick up, has a nice and big standard library and has it's niche, but people that dare to write ' is vastly superior, both in overall design and performance, to other languages that provide a similar level of abstraction', either blatantly choose to ignore decennia of computer science, or still have a lot of cool stuff to learn.

Why is ruby everyone's boyfriend

[Anonymous Coward]

Seriously, why is everything in/about/emulating Ruby right now? From what I understand, this implementation isn't necessarily that much like Ruby, but given the summary it seems people would like to think/hope so.

Don't get me wrong, I like Ruby but I would never seek to emulate it. The language libraries are inconsistent and poor in many cases and there are other serious design issues. It's a cute little language great for shell scripting and quick one-offs, but I still cannot take it seriously after trying to prototype out various projects in it and seeing many weaknesses.

If you're not using some existing implementation/framework in Ruby such as Rails, why use it at all? Smalltalk and Lisp have done the same things are more much better since the beginning of time. Both languages are far cleaner, with Smalltalk having the better syntax IMO and Lisp having the advantage in power. If you could combine Smalltalk's dev environment and VM with Lisp's power, then we would have something worthy of actually looking at.

Re:Awesome another langauge

[Anonymous Coward]

In the old days some people had a terribly complicated device called a "stove" which they used to prepare all kinds of different food. There was no standardization at all. Everybody used different ingredients and different ways to prepare the food. It was horrible. But then came the golden age of standardization. MacDonalds and Starbucks rule!

Re:Awesome another langauge

[Jesus_666]

How many sources of electrical power can you get in your home right this moment where you live?

Let's see... I'm hooked up to the electrical grid and I have some chemical batteries lying around. That makes two. I also have a USB charging cable for my NDS, which is different from directly plugging the DS into the wall. So I have three different kinds of power source I can readily remember, the self-sustaining solar calculator not counting. And no, I wouldn't want to standardize on any one of them as they all have applications for which they are not good for.

We can't standardize on one single language because no single language is suitable for all tasks. I wouldn't want to do embedded programming in C# and I wouldn't want to write a large application or a shell "script" in C.

A replace-them-all language would have to fulfill all of the following requirements:
- be object oriented
- not be object oriented
- be functional
- be imperative
- be declarative
- be low-level and close to the metal
- be high-level and completely abstracted
- have a large class library
- have a tiny runtime
- have a garbage collector
- not have a garbage collector
...and so on.

Your Father's Parantheses

[iangoldby]

Lisp Cycles

Still one of my all-time favourites.

I keep wanting to say "Loki",

[CustomDesigned]

the Norse trickster god. Seems like a better name for a language.

C++ has no generics????

[mario_grgic]

Ever heard of templates?

Re:C++ has no generics????

[Animats]

Ever heard of templates?

Templates were not in the original C++. They were added years later. For years, people were using unchecked down-conversions and horrible macros to work around that mistake. That's my point.

This already exists

[Reverend528]

We already have a programming language with a simple syntax and the strengths of Lisp and Ruby. It's called Lisp.

Re:This already exists

[Abcd1234]

We already have a programming language with a simple syntax and the strengths of Lisp and Ruby. It's called Lisp.

Actually, it's called Smalltalk.

Re:This already exists

[frank_adrian314159]

I'd take either, given the alternatives.

Use a Real Language

[dauwhe]

Meh. Call me when someone writes an operating system in XSL.

Lots of bad languages to choose from

[argent]

The good programmers already have PLENTY of GOOD languages to choose from

Unfortunately, they also have plenty of bad languages to choose from, and they tend to choose the ones that suck the most.

Perl. C++. Java.

Good languages like Lisp and Smalltalk get no respect. Attempts to graft C/Pascal syntax on Lisp and Smalltalk get no respect.

I like to see new languages tried. Maybe one that doesn't actually suck will catch on.

Re:Lots of bad languages to choose from

[mabinogi]

Good languages like Lisp and Smalltalk get no respect. Attempts to graft C/Pascal syntax on Lisp and Smalltalk get no respect.

That's because grafting C/Pascal syntax on Lisp or Smalltalk is a stupid idea. At least it is in the case of Smalltalk - I've never used Lisp.
Smalltalk's syntax is just about the Whole Point.
(and I don't get the "whaaa, it doesn't look like C, it must be HARD" objection people get to the Smalltalk syntax. It's extremely simple, consistent and clear. I'd much rather have to spend hours looking at Smalltalk than C, or Java, or (shudder)Perl)

I like to see new languages tried. Maybe one that doesn't actually suck will catch on.

Me too. There's still plenty of things to be tried yet, and any research or new languages that may mean that something manages to usurp Ruby as fad language of the day sounds good to me.

Re:Lots of bad languages to choose from

[argent]

I like Lisp syntax. I like Smalltalk syntax. I got no complaints about either.

Why?

[FloDo]

Why are you all crying when a new language comes out? For my point of view designing a language is like art, and often a opportunity to explore new paradigms/designs choices/technologies. No one forces you to use this language, like no one forces you to listen to some particular song or some other artwork.

Re:Why?

[tkinnun0]

Your boss might force you, at the penalty of your job.

Re:Try harder on the naming front...

[bryxal]

That's the whole base code of Windows 7

Re:We don't think with 1 datastructure

[Estanislao Mart�nez]

Why not instead of lists, use maps + lists ? You can of course express a map with lists but maps/"names" are so natural to think with that I think it would be easier to express ideas with it. "Naming" is very natural, and I don't think names as lists of lists.

Take care to distinguish between the syntax of the language and the interpretation of the expressions in the language. Lisp uses the native syntax for lists to represent code. That doesn't mean that all the code must be translated into lists data structures. For example, you can have a macro that transforms a list representation of a map to code to construct an actual map at runtime.

How does it look decompiled?

[Call Me Black Cloud]

If it's built to run on a JVM the output can be decompiled by a Java decompiler (like JAD). How crazy does the output look, going from Ioke to Java bytecode to Java source code? Or vice versa - could one take .class files, decompile them into Ioke, and be able to work with them?

But Seriously Folks

[walkerp1]

Did anyone else read that as Joke with a serif-compensating complex?

We already have Tcl

[wiredlogic]

Tcl is already the closest thing to a rational, usable lisp without the parentheses. It's grammar is only slightly more complicated. Most lisp goodies that aren't there by default can be easily added if one desires.

Re:We already have Tcl

[Maian]

I'm not familiar with Tcl, but I've read that it doesn't support closures. That's a major deal-breaker in comparison to Lisp.

Re:Awesome another langauge

[BitZtream]

True, but I feel much better. The good thing about new languages is at least the people writing them free up space for me to get useful employement while they wonder off and waste time.

Re:(eq high-level-language scripting language)=fal

[SanityInAnarchy]

Python is very dynamic in a way that's gonna be quite hard to compile.

But not impossible.

Look at LLVM. It runs C. It can statically or dynamically compile bytecode, and the generated executable is comparable to one straight out of gcc -- sometimes faster, because of optimizations which can really only be done at runtime.

I don't know about Python, but I know that a fork of Ruby (Rubinius) has been looking at it. So I absolutely think a dynamic language like Python can be made to run much faster, maybe faster than C.

Oh, and the other languages you mention -- cool, but also quite weird. Given the choice, how many people would really rather write LISP syntax than Python syntax? I like a lot of the ideas of LISP, and I realize that these scripting languages are just catching up, but there's a reason it stands for Lots of Insidious Silly Parentheses.

The loudmouth school of Lisp programing

[Estanislao Mart�nez]

The problem results from following the most elementary paradigms of Lisp programming: ignore what is happening at the higher and lower levels, and avoid specifying the interfaces to those other details in detail. The results are very painful to clean up.

I think your idea of this "elementary paradigm of Lisp programming" is way too monolithic. I do agree that there's a loudmouth Lisp programming school that preaches some really awful practices, like "use (singly-linked) lists as your only data structure."

However, the worst Lisp code I see suffers from too little abstraction, not too much. The worst, stupidest case is using lists as records, and accessing the "fields" of a "record" through concrete list operations. ("Ok, I want to get the date of this transaction. Um, is that the third element of the list, or the fourth one?" Or even worse: "Aaaargh, this code I'm reading actually uses the cdadr procedure!") Then they use their "records" in an inner loop, and their O(n) algorithm ends up with an O(n^2) implementation. And when you try to fix it, well, you have to find all the places they create a new "record" to create a real record data structure, and find all the places they access the "fields" and do the same.

It's particularly annoying because the problem should never have happened: the program should have been written from the beginning to treat the records as an abstract data type, instantiated and accessed only through specialized procedures dealing with that type. Then you can change the implementation of the type without changing the code that uses the type. (And if the program could really benefit from using lists as a syntactic representation of the type, then the right way to do it is to provide functions that translate the between the private implementation of the type and the list-based external representation.)

But of course, if you write your code like that from the beginning, you might as well not use lists as the freaking implementation type to start with. The lesson is precisely what I started with: the loudmouth "use (singly-linked) lists as your only data structure" school of Lisp programming is evil.

Re:The loudmouth school of Lisp programing

[Tiny Elvis]

Um. Lisp has lots of data structures besides singly linked lists. There is no 'loudmouth Lisp programming school' that I know of preaching use of only lists.

Re:The loudmouth school of Lisp programing

[Antique Geekmeister]

Oh, my. Oh, dear. You're giving me flashbacks of dealing with those MIT trained clowns. Not this particular issue, but similar ones of using the examples they must have learned in the first half of the term to deal with problems beyond the scope of the course material, and relearning lessons learned the very hard way in other fields. My favorite fun with them involved the fact that people make keyboard errors, and you *must* verify that their arguments are valid before proceeding to implement their typos.

Re:The loudmouth school of Lisp programing

[QuoteMstr]

Incidentally, Emacs suffers from exactly the disease you describe. Consider the result of parse-partial-sexp:

(parse-partial-sexp from to &optional targetdepth stopbefore oldstate
commentstop)

Parse Lisp syntax starting at from until to; return status of parse at to.
Parsing stops at to or when certain criteria are met;
  point is set to where parsing stops.
If fifth arg oldstate is omitted or nil,
  parsing assumes that from is the beginning of a function.
Value is a list of elements describing final state of parsing:
  0. depth in parens.
  1. character address of start of innermost containing list; nil if none.
  2. character address of start of last complete sexp terminated.
  3. non-nil if inside a string.
        (it is the character that will terminate the string,
          or t if the string should be terminated by a generic string delimiter.)
  4. nil if outside a comment, t if inside a non-nestable comment,
        else an integer (the current comment nesting).
  5. t if following a quote character.
  6. the minimum paren-depth encountered during this scan.
  7. t if in a comment of style b; symbol `syntax-table' if the comment
        should be terminated by a generic comment delimiter.
  8. character address of start of comment or string; nil if not in one.
  9. Intermediate data for continuation of parsing (subject to change).
If third arg targetdepth is non-nil, parsing stops if the depth
in parentheses becomes equal to targetdepth.
Fourth arg stopbefore non-nil means stop when come to
  any character that starts a sexp.
Fifth arg oldstate is a list like what this function returns.
  It is used to initialize the state of the parse. Elements number 1, 2, 6
  and 8 are ignored.
Sixth arg commentstop non-nil means stop at the start of a comment.
  If it is symbol `syntax-table', stop after the start of a comment or a
  string, or after end of a comment or a string.

It doesn't help that RMS doesn't believe in keyword arguments.

Re:The best of LISP?

[Bootarn]

Flamebait? Sorry, I purely meant this as a joke.

Obviously I went too far on this one, and for that I apologise.

Lisp has arbitrarily much syntax, actually...

[Estanislao Mart�nez]

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.

No, this isn't quite true. Lisp has plenty of syntax; they just call it "special forms." In fact, Lisp has arbitrarily much syntax, given mechanisms to define your own special forms (i.e., macros). Note that this isn't all good, because people can go crazy with macros and write code that's really hard to understand and, what's worse, really hard to debug.

What Lisp doesn't have a lot of is lexical syntax, nor operator precendence. If you look at a Lisp program, there may be unfamiliar syntax in there (i.e., macros whose syntax you don't know), but faced with that, you can at least tell how stuff is nested. (The one big exception to the lexical syntax part is reader macros. Reader macros are utterly evil, if you ask me, precisely because their use makes the above not hold anymore.)

After programming for several years in Lisp, I must say the syntax has me spoiled. Every time I try to understand a complex arithmetical or boolean expression in Java or SQL, I actually end up translating it to properly indented Lisp code in a scratch file, which makes it much, much easier to read. "Oh, so this is an addition of three summands, the first of which is the quotient of the subtraction of two things and the addition of four others."

Also, every time I try to get my head around something like Haskell, I just can never remember all the line-noise little infix operators that Haskell programmers insist on using. (In Lisp code you might have all sorts of crazy operators, too, but they'd just be functions or macros with long, descriptive names, like MONAD-BIND instead of >>= or whatever the hell line noise operator they use in Haskell for that.)

"Excessive" abstraction?

[Estanislao Mart�nez]

The result was the _excessive_ use of abstraction, to such extents that I had to go in and violate the abstractions to explain 'You are presenting the data in the wrong order: if you present it in the correct order, which you have been taught not to think about, you eliminate 95% of the load that you are seeing.

My first reaction to this is that it doesn't sound as "excessive" use of abstraction; rather, it sounded either as use of incorrect abstractions, or as a failure to model the execution of the algorithm. Two points here:

1. Unordered data structures aren't any more "abstract" than ordered ones; they just have an interface that obeys a different contract.
2. If an unordered data structure truly is an architectural requirement in the system at some level, but ordered execution of steps is needed to guarantee acceptable performance, then the program arguably should analyze the unordered data structure at some level to compute the best order of execution, and then execute in that order. (This is what I mean above as "modeling the execution of the algorithm": write the program so it can reason about what's the best order to do stuff, performance-wise. Even simple heuristics can make a difference.)

C and Java programmers are, as a general group, very bad at using abstractions too. Most often, they just use too few of them, the resulting code is too tightly bound together, and it's difficult to reuse or replace individual pieces of the resulting programs. Too many constructs that specify how to do something, instead of what result to achieve. (Compare for loops to map.)

Structuring a system in terms of nested abstractions is not at all bad for later performance tuning. In fact, what you described above sounds like the correct way to optimize such a system: find places where the interface between nested abstractions is a bottleneck, and rewrite in a more concrete manner to eliminate the cost. Basically, if you have poorly performing module A written in terms of B and C, replace A with a module A' that incorporates the necessary features of B and C, but without the abstraction layer bottleneck.

However, I object to calling that "violating the abstractions," because the interface of A' to its clients remains the same as before, and B and C may still be used in other places where they do help. All you're changing is the internal details of a module, so as not to use costly lower-level abstractions. Abstraction is about hiding internal details of the part of the system. If somebody insists that A should use B and C in the name of "abstraction," they're getting the idea completely backwards: the point of abstraction is precisely to make it possible to change A without having to change anything else. But the trick is only do this in places where performance is actually bad, so you reap the benefits of code reuse or implementation speed elsewhere in the system, where you do use B and C.

A compiled language, like C or even Java, can also try to deal with this by unrolling loops and transforming structures to avoid such classic problems. An interpreted language cannot, and the programmer must understand the limitations, which these gentlemen were never taught.

Um, there are plenty of Lisp systems out there that use compilation. What makes you think that Lisp systems cannot unroll loops?

Re:"Excessive" abstraction?

[Antique Geekmeister]

You present a cogent analysis of the issues, thank you. But you've missed a critical point. They were taught, very firmly, to treat each layer of abstraction as entirely unique and unrelated to the other layers. You cannot know that the data structure has a particular order, (one that they were reversing, which was the problem I tried to explain to them!), without stepping to a lower level than the project was originally described at. For example, under heavy load, reading a data file backwards is a nasty performance hit on disk I/O because you still have to often spin the disk to get back around to the previous block. Yet they were either not taught to, or specifically enjoined not to, think or program in such terms. They were apparently graded on 'elegance' in the sense of doing subtle recursions, rather than on understanding and being willing to go down or up a level of abstraction to address a problem.

It made cleanup a mess. There were some useful and subtle things they did that were valuable, but oveall, the systems were terrible until I went through and did things like unrolling loops, switch various styles to iterative rather than recursive operation to gain control of necessary resources, and generally think in lower terms than they'd learned. I'd love to hear that such courses have improved, but it seemed built into the basic text they learned from. (And yes, it was Jerry Sussman's book.)

Re:"Excessive" abstraction?

[Estanislao Mart�nez]

They were taught, very firmly, to treat each layer of abstraction as entirely unique and unrelated to the other layers.

...which is correct at the logical level, but not the physical level, indeed. Same suspicion as before: they've picked the wrong abstractions. I'd restate your point the following way: physical performance considerations constrain which are the correct abstractions to pick.

Basically, two of the goals of computer engineering are:

1. Build highly modular systems out of reusable, easily modifiable pieces.
2. Have those systems perform fast enough.

The problem is that most programmers have a very hard time nailing both of those at the same time. Using abstractions performantly requires one to have an intuitive, high-level understanding of how the abstractions will translate to the physical layer.

For example, under heavy load, reading a data file backwards is a nasty performance hit on disk I/O because you still have to often spin the disk to get back around to the previous block.

...therefore the correct abstraction for file access, if you must process the whole file, should be that reading a file produces a stream of items, you write the algorithm so that it consumes the input in whatever order the stream supplies it, and so that it processes the smallest sequential "window" of the input that it possibly can work with. Therefore, the abstractions you choose should not be incompatible with these considerations. Recursive list algorithms, in particular, fail it here.

In my experience, the corresponding kind of idiocy in the C/Java world is hardcoded SQL queries with awful performance. In fact, SQL is a perfect example here, because writing performant SQL requires you to understand at a high level how your queries are be translated into sequential execution plans. If you don't have such a high-level mental model, you can very easily write logically correct queries that perform a thousand-fold worse than the best logically equivalent ones. To use the abstraction performantly, you also need a model of how it's going to perform. The good news is that the latter model can normally be abstract; you can think of SQL query execution in terms of query rewriting, pushing filtering conditions down to table access methods, statistical properties of tables like index value skews, etc.

PS: my job involves writing Lisp programs that generate SQL queries for high-performance bulk data transformations, so everything I'm saying here is completely unsurprising when you look at it from that angle. The code has to take analyze schema descriptions to generate abstract syntax trees that get translated into largely SQL text that must execute as efficiently as possible. There is absolutely no way you can do this without considerable abstraction and reasoning about the performance implications of every bit--including the performance characteristics of third-party RDBMSes that you have little control over...

Arrogant much?

[rewt66]

Yeah, you know which languages are best. What a pity that 99% of working programmers are too stupid to see the light and move to a good language.

Or is it just possible that they're right and you don't see the whole picture?

At least I can read for content.

[argent]

Yeah, you know which languages are best.

I know which ones are *worst*. Which is the point I was making, not that Lisp or Smalltalk are the best, but that they (and most other modern languages) are better than C++ or Perl.

Or is it just possible that they're right and you don't see the whole picture?

About as likely as the possibility that Fortran was the best programming language in the '80s.

What makes a programming language popular involves a lot of things that have nothing to do with the quality of the language itself.

If bad design was all that relevant to success, Microsoft would have gone out of business 20 years ago.

Re:At least I can read for content.

[rewt66]

You said that Perl, C++, and Java "suck the most", and that Lisp and Smalltalk are "good languages". You then quibble with my use of the word "best" as failure to read for content. Try reading my post for content before you get too critical. My point was your arrogance, which you display again in your reply. Yeah, you know better than all the rest of us working programmers out there, we're just stupid sheep for picking such lousy languages, and you know so much better than us which languages are good. "What makes a programming language popular involves a lot of things that have nothing to do with the quality of the language itself." Here you have to do one of two things. Either you assume that we are all idiots for working with bad tools, or else you have to define "the quality of the language itself" as meaning something other than its usability for producing actual working programs in the real world. Both positions are elitist and arrogant.

Re:At least I can read for content.

[argent]

You said that Perl, C++, and Java "suck the most", and that Lisp and Smalltalk are "good languages".

Um, yes? Good doesn't mean "best".

Yeah, you know better than all the rest of us working programmers out there, we're just stupid sheep for picking such lousy languages

Don't be deliberately daft. If you're a "working programmer" you know that "working programmers" don't get to pick the languages that are going to be used for a project. I'm working on software right now that uses C++ and Perl components. Not because I like them, but because they're what the rest of the project is using. That doesn't change the fact that the whole project would have been a lot better using languages that were well adapted to the problems that we're actually dealing with.

But, yes, I do know better than most programmers, because I've worked with more languages and systems than most programmers. My first job was in COBOL, I've written code in Fortran, Forth, Ratfor, Postscript, Lisp, Java, Javascript, SQL, DBLI, blah blah blah blah... that doesn't make me smart or them stupid, it just means I've got a broader perspective.

The idea that broad experience makes me unqualified to comment because I'm not some kind of ideal "average joe" is a lot more arrogant than anything I've written here.

Re:At least I can read for content.

[rewt66]

Sorry, you still fail. First: Good doesn't equal best. Granted. But, to review, you picked on one word and criticized my ability to read for content. In doing so, you showed a failure of your own to read for content. I pointed this out. You ignore that and criticize one word. Fine. I concede you the ticky-tacky point about the one word. Enjoy your resounding victory. Second: Your experience exceeds mine, though not by too much. And, I'll totally grant you that sometimes languages (and other tools) get chosen for stupid reasons. But it's still rather arrogant for you to assume that everyone making such choices is either less experienced or less wise than you. Your experience may let you see that a different tool would be a good fit for your project. You might even be right (after factoring in availability/cost of experienced programmers in less-popular languages, maintainability, and other such considerations that often are ignored by language zealots). You might be right - for your project. But you're calling a lot of people idiots (yeah, my word, not yours), and a fair number of them have as much experience as you, or even more. In short: It's still arrogance. For all your experience, don't assume that everyone else is ignorant.

Re:At least I can read for content.

[argent]

*sigh*

It's not just one word, you came right out of the starting blocks ragging on me about my choice of "the best" languages.

And now you're raving on about how "everyone" is this, that, or the other thing.

But, whatever, you "win". Ciao.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Um...

[Estanislao Mart�nez]

I think what you really want is a good Scheme implementation. MzScheme might do it for you, unless you want something more compilation-oriented (though MzScheme does have JIT these days, I hear).

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:(eq high-level-language scripting language)=fal

[SanityInAnarchy]

Some properties are just much harder to make efficient, because it's hard to give guaranties on behaviour, while it perhaps wouldn't be so hard if the specification would be slightly different.

While true, I think that sometimes the changes aren't too bad.

And you don't need guarantees to optimize -- just educated guesses. You always keep enough around so that if your guess is wrong, you can drop the optimization and start over.

eval is never going to be fast, in any language, and you can make a lot of assumptions by ignoring it. But being able to eval when you really want to, even if it's a performance hit, is a beautiful thing.

I know eval is generally bad practice outside of an interpreter shell. It's a good example, though, because the things we really care about (define_method, method_missing, etc) are all somewhat less dynamic (and less troublesome) than eval. And if eval works, you can probably add any of those that are missing.

'maybe faster than C' is just wild speculation on your part. Lots of high-level languages try to be faster than C. It ain't easy.

Enough of them get close that I start to think the main factor is the amount more research that goes into improving C speed, both by compiler experts and by actual hardware manufacturers.

And I must say I just love your stab at Lisp.

I can't take credit, that's an old one. Probably as old as Pathologically Eclectic Rubbage Lister, which is actually official.

Surely that's the thing God used to create the universe.

You'd think so...

Bringing forward syntax as an argument is extremely silly in my view.

Actually, I've discovered this is a central point, and sometimes more important than actual power.

Code is communication. With your peers, perhaps with you a month from now, even with the machine itself. It is a way to translate your intent into actual instructions so unambiguous a machine can follow them.

This has implications for all three of those parties. Speaking to others is important, because there's only so much you can do by yourself. Speaking to yourself a month from now is important, because there's only so much you can do while keeping the whole program in your head -- I would argue that readability is almost more important than how easily you can write code.

And it even matters for the machine -- because if you've managed to write a program which codifies only your intent, and nothing more -- which says much more about what you want done than how you want it done -- then that "how" can change, based on whatever is more efficient for the circumstance at hand.

It's true that a powerful-but-ugly language can do all of the above, provided everyone can read it well. What's important is how well it maps onto how you think, and how you actually communicate. Ruby, to me, is very readable and very natural -- I can express myself well in it, and when I read a chunk of Ruby, I actually understand what it does, even if I don't quite understand how.

The same cannot be said of most Lisp. I read a block of incredibly beautiful lisp, but it's only beautiful once I get it. And that takes awhile. It's like a Koan -- it certainly expands my mind, probably makes me a better programmer. But not for everyday use -- I don't want to try to use a Koan to order dinner. ("May I take your order?", "Give me the taste of a sugarless marshmallow.")

That, and... c'mon. Take a lesson from python and make at least some of those parens implicit.

Re:Try harder on the naming front...

[spongman]

Actually, the win7 codebase is missing one of the '+'s

Re:(eq high-level-language scripting language)=fal

[metamatic]

Given the choice, how many people would really rather write LISP syntax than Python syntax?

I'd take Lisp syntax over the stupidity of semantically significant indentation any day.