More scripting languages

What exception handling constructs are in R5RS?

I was referring to dynamic-wind. With the addition of dynamic-wind, there are two distinct notions of ``current continuation'' in Scheme: the thing passed by call-with-current-continuation, and the actual current continuation, which in includes all relevant before and after thunks.

I guess this observation proves something, but I'm not quite sure what. Perhaps it simply shows that I'm confused.

• Scheme was never intended by its authors as a "useful" language
• contrary to your apparent belief, many people actually find reified continuations rather useful.

other than that, nice article, except I'm not quite sure what is it you want to "discuss".

(re: GB. GB's official goal is to provide compatibility with MS Office document formats. it's authors seem to despise Basic).

and yeah, I wish we all could just work on some kind of Lisp machines instead of this crappy Unix thing (and that if we are lucky) with all those crappy languages.

articles ought to have a point, or at least a direction, or at least some amusement value. you'll get a better catalog of languages at dmoz, without the inaccuracies and omissions, and perhaps even a note of insight into why all these languages exist and what they're good for. new dialects of an object-basic are not even surprising enough to merit mention; they're just windows-user compatibility layers.

I fear that this is going to come out looking like a flame, but I assure you it isn't intended as such. Here goes nothing, anyway.

I'm unsure how someone can both decry bloat and praise Common Lisp in the same article. Sure, the language itself is fairly simple as 50-year-old languages go, but the library is the union of the libraries of about five pre-existing Lisp implementations. The result is an unholy mess of very similar and inconsistently named functions of which probably about ten people on Earth know what they all are and what they all do.

OK, that's the rant over. Surely the moral of the story is that there's no arguing over taste? Every now and then someone suggests that we need a "super language" which will accommodate everyone's programming style, with the most recent suggestion that I heard being something based on concurrent constraint logic/functional languages.

Of course the idea is flawed. What we truly need is either a family of languages, or at least a framework by which different languages play nice with each other so you can "mix and match". Ironically, it looks like the best suggestion so far is going to be... wait for it... .NET from Microsoft. Amongst other things, .NET provides a framework for binary compatibility between disparate languages; your Perl structure and your Haskell data type can be interchanged freely. This is something that the Open Source community should seriously look at.

Someone once said that the best way to think of Tcl is not as a scripting language, but as a C library. I find that to be a relevant statement, as the true power of Tcl is not as yet another scripting language (something it does ok, but maybe not as well as some other things like Python), but in the ease with which one may extend it in C, or include it in C programs. Maybe I'll write an article on this model of programming some day - I find that for some things, it is really really nice.

Pseudonym writes:

Ironically, it looks like the best suggestion so far is going to be... wait for it... .NET from Microsoft. Amongst other things, .NET provides a framework for binary compatibility between disparate languages; your Perl structure and your Haskell data type can be interchanged freely. This is something that the Open Source community should seriously look at.

Your mention of this idea (complete language interoperability) piqued my interest; so I had a look around. I skimmed all the articles I could find on this subject.

To me it seems the only way microsoft's .NET framework is any different from COM is that it places the burden of data marshalling with the *compiler* rather than the programmer. The whole purpose of IDL is to allow programmers to define the types their code uses so that some library in the same memory space (read: no sockets) could translate data between components written in different languages.

In my opinion, leaving this functionality in a library is much better for everyone than planting marshalling metadata in every binary. Many of us who have tinkered with some functionality of CORBA (and yes, in this context -- component systems -- CORBA is a lot like COM) have run into the situation where functionality XYZZY from the spec hasn't been implemented in the ORB. The options left at this point are to either extend the ORB or look for another one that complies more exactly to the spec. Often the latter is the easier choice, what with the lately large selection of free CORBA orbs.

But now, if you graft that functionality into the compiler, and there's a bug, what are you going to do? switch compilers? And what about all of the extra code involved in interoperability? At least with IDL and CORBA you can tell where this code came from when you're debugging your executable...

So, as a conclusion, I really don't see why CORBA is shunned. It can be the binary interoperability god everybody wants. Just remember, if you link two CORBA objects together that use the same ORB, the entire network layer is cut out, leaving only one or two layers of adapters. In the case of two objects written in different languages linked to the same ORB, the biggest added indirection is that of data marshalling. This is something you're just never going to eliminate, even by requiring all compilers to emit metadata about interfaces and data structures.

please change the line (in your minds of course ;)

'the whole purpose of IDL...'

to

'one of the main purposes of IDL...'

I have taken part in many a language war in the past (fairly recent past too), so I can't pretend to be some wise guru. But if there is one thing I've learned it's that There Is No Right Language. All languages have their place. Visual Basic might be a step backwards for many, but it has vastly simplified application development on Windows, and given a VB development system on UNIX, we could look forward to easy porting of such apps.

I've programmed in something like 14 or 15 different languages over the years. I don't consider any of them to be "off topic" or "bad languages". They each had or have their place. I've written a network proxy in Python, a circuit simulator in Haskell, a proof engine in C++, a distributed mandelbrot generator in Ada. Heck, I even wrote a Lisp interpreter in BASIC when I was a kid.

When I choose a language for a project I have to take into account the availability of tools, the longevity of the code, maintainability, interoperability, available libraries, available resources, speed, space, safeness, etc., etc. Lisp might be the right choice for one project, might be dead wrong for another.

By all means tell me something new and show me something that might help me in my work, but let's ditch the tired "the world would be a better place if everyone just programmed in x" arguments.

I did not advocate a ``everyone should program in Lisp'' line. I was merely objecting to the most common extension languages, and pointing out certain alternatives that I believe to be more suitable. I do of realise that the Lisp family is not the only possible choice, hence my mention of Smalltalk and ML.

Most extension languages start with a toy language with poor structure and bad behaviour w.r.t. extension. As such languages get extended, they suffer of a phenomenon in which a single concept is split into multiple distinct ones; the best known example being the miraculous multiplication of casts in C++. (C++ didn't of course start as a toy language, but the process of extension that C underwent is analoguous.)

An extension language does intrinsically undergo extension, as it includes the domain-specific data structures of the aplication it is embedded in. For this reason, I believe that it is important to base an extension language on a language known to be extensible without pain. Lisp family languages are known to have this property, hence my choice.

cmm: I'll answer your comments about Scheme by private mail.

jonathan: while I most definitely agree that there is no universally best language, there is such a thing as bad language design. By the way, I have no major objection to Python (yet?), and my ending comment was only aimed at preventing the discussion from going in a direction that I'm not really interested in.

It is hard to intuit what the topic is from the original post. The author starts by saying seems unhappy that people build system with Perl and C++. Later he extolls the virtues and Lisp. Finally he mentions a bunch of other neat languages and says that Python is off-topic.

If the topic is alternatives to Perl for scriping, then Python seems completely on topic. Python is a fun, practical language. It is possible to build fairly large systems with it. It is straightforward to extend it with interfaces to new C and C++ libraries or to embed it within another application. There's even an implementation in Java that provides the same extending and embedding facilities for a JVM.

If Python isn't relevant to this discussion, maybe it shouldn't be title "more scripting languages."

If it did, you'd see people porting over their evil VB code to Tcl/Tk, Python, or one of the solutions you mention. No, this has to do with an effort, that is somewhat in vain, BTW, to migrate the code with minimal modifications over to Linux from Windows. There's lots of evil constructs in VB that just don't move over to these other languages well- like "ON N GOTO", etc.

Apparently, people are convinced that scripting should be done in a badly designed, inconsistent language that bloats as we speak, that ``real'' applications should be done in another badly designed, inconsistent language that bloats even faster, and the twain shall never meet.

For many years, people have written Free software using an amazingly flexible language that can be used for five-line scripts as well as for full-fledged applications and complete Operating Systems. It's called Lisp.

jch, you'll have to forgive me if I mistook your article as a "my language is better than your language" post ;-)

However, I'm not sure what it is you want to discuss exactly. You comment:

By the way, I have no major objection to Python (yet?), and my ending comment was only aimed at preventing the discussion from going in a direction that I'm not really interested in.

My first concern on reading this was that many of the arguments over languages stems from people not being interested in another opinion, or not understanding it, but I'm guessing this is just me reading too much into your phrasing and that you didn't mean it so bluntly.

It did make me think though about an earlier topic of conversation about Computing Science. You rightly point out that there is a lot of bad language design about. I wonder if this is because many programmers honestly don't know much about language design. Whilst I'm sure many people without degrees have become hugely successful, I am greatly concerned when people are advised not to bother with Computing Science degrees. Sure a degree in Computing Science may not teach you to program better, but I'm convinced it teaches you to be a better programmer.

I never learned how C++ templates work at Uni, but I did learn what parametric polymorphism is. After an afternoon perusing a C++ manual I understood templates. Yet I have seen many C++ programmers who still don't really understand them.

And now I see that I've taken the discussion in a direction you probably didn't want it to go :-)

aaronv writes:

To me it seems the only way microsoft's .NET framework is any different from COM is that it places the burden of data marshalling with the *compiler* rather than the programmer. The whole purpose of IDL is to allow programmers to define the types their code uses so that some library in the same memory space (read: no sockets) could translate data between components written in different languages.

Let me first point out that specific information on the details of .NET is not available at the time of writing. There's a lot of hype and marketspeak, but little technical information. So I could be talking complete rubbish here and not know it. Apologies in advance if this is the case.

An implementation of IDL for some language is really a compiler. Some of the new CORBA ORBs are actually looking into generating marshalling and demarshalling code. Compilers of most languages already have to deal with "foreign functions" or whatever they're called in the language in question. Hell, even most C/C++ compilers have ways to put in assembly language. It's not such a large leap to integrate IDL functionality with the compiler proper. Microsoft are already doing it with COM and Visual C++. Their particular implementation, IMO, is truly kludgy and would make any "serious" compiler writer wince, but the idea is not without appeal.

There are problems with it, of course, and I would never suggest that the Open Source community embraces and extends .NET sight unseen. However we should look at the ideas behind it and ransack what we think we might like to use, just like we always do.

So, as a conclusion, I really don't see why CORBA is shunned. It can be the binary interoperability god everybody wants.

It's shunned partly because of the perceived performance impact. Historically, I can see where that came from, but it needn't be that way. It won't be the "interoperability god everyone wants", of course. You won't see IIOP being a significant Beowulf protocol any time soon, for example, because it's just too heavyweight for the sorts of problems that MPI and PVM solve better. And, let's face it, Sun RPC isn't going anywhere...

Anyway, I'd like to see more research on generating code for marshalling and demarshalling because, as you say, it is the biggest added indirection for applications using the same ORB on the same machine. Then I'd like to see some actual benchmarks comparing the .NET common binary interface with optimised CORBA. I think we'll find that CORBA will compare very well.

How come no one mentions Lua, a Pascal(!)-style extension language that can be used as a script language (of course) and is one of the fastest, smallest language designed for embedding in applications?

Let me first point out that specific information on the details of .NET is not available at the time of writing. There's a lot of hype and marketspeak, but little technical information. So I could be talking complete rubbish here and not know it.

The enlightened people all do. I learned Lisp by using and extending Emacs and I was amazed with how Lisp allowed the scripting to get so tight to the implementation. There is a very thin line between Emacs customization and code that is "part of" emacs. I'll be starting work on a Jabber client in Scheme soon - contact me if you want to help.