Fastest prototyping language?

I want to write programs as fast as I can. Which language should I learn?

Using program length as a rough indicator, Forth is the choice. Samples I've seen like web servers, operating systems, database managers, etc. are significantly shorter in Forth.

But I've seen some really short Perl and Haskell routines too.

And Lisp is supposed to allow you to work at such high levels of abstraction that it should also make short applications.

Ruby gets a lot of comments about short line counts compared to Perl and Python.

Assuming
   -identical toolset library functionality,
   -maximum expertise in all the candidate languages
   -no concern of readability, "transparent" design, or 
    execution speed
which language syntax will allow you to write your program fastest?

In b4 machine code.

What sort of problems can I solve with Lisp though?

>>41
Anything, Lisp is Turing-complete. I don't know about Touring-completeness, but it can be easily extended by implementing BBCode, which is Touring-complete.

Can you create, say, a shmup in openGL using LISP?

Graham is snorting something. Here's why Lisp isn't more popular:

* there isn't a one (and only one) canonical release
* this canonical release should be actively supported
* this canonical release should have a modern "batteries-included" library
* it should be free

Wow. That was short. It's also absolutely required for any language that isn't being pushed by a large commercial entity to have a hope in succeeding.

Except that Lispniks, in their brilliance, are finding excuses why having a myriad different CL and non-CL implementations is totally awesome.

Oh, being stuck with SLIME doesn't help either. Nothing wrong with it, but the majority of people aren't going to learn Emacs for one language.

>>44
Ja, PG knows this. Those five points are the drive behind Arc. Basically like Perl, being not just a language specification, but also a free implementation, with supported libraries and community.

>>45
Well, see, this is the part I'm a bit confused by...

He plans to make a canonical version by making yet another Lisp?

Well, I wish him luck. What languages need are strong leaders, otherwise they slow to a crawl with design by committee.

>>45
too bad that unless PG implements the whole web application framework by himself (he could do it, since, well, he and robert worm sort of invented the concept of web application), then arc won't be popular. It doesn't do anything about the fragmented lisp community except fragmenting it more.
Of course that's if, and only if, pg ever releases arc. I wouldn't bet on it.

LISP is a good language, but the fact that a person like Erik Naggum uses it (see Usenet) makes LISP fail by association.

>>48
What's wrong with Erik Naggum?

One word Lorena Bobbit with a knife.

All women fail by association.

dur hur hur! :)

>>46
And PG wouldn't make a strong leader? Practical all the suave Lisp noobs bone him.

>>47
Oh, sure, this is all on the pretext of it ever being released, which I doubt it will be. Considering PG's philosophy is "People have been waiting fourty years, they might as well wait an extra two," translation: "I'll take as long as I want on it."

>>48
If the fail by association rule is so influential, I hate programming because I hate Eric S. Raymond, and he never shuts the fuck up about "hackers".

It seems to be the natural life cycle. Lisp is the second oldest programming language after FORTRAN. I gather that it did have strong leaders who are retired or dead now. Perl is the elder "scripting" language, and Larry Wall has slowed down and yielded to the dreaded committee, hence the rise of Python and Ruby and their young turk leaders.

Back to the practical matter of Fastest Prototyping Language I should Learn Right Now: here's what I'm focusing on:
**3 Families of Languages. The S-expression family includes Lisp and Scheme and intersects substantially with Python/Ruby/Perl. The stack-based family includes MANY Forths and extended Forths like Factor. The ML family includes Haskell and Caml. Of these 3 families, the S-expression seems best for fast prototyping because it's flexible and malleable. The others seem to require you to go back and start from the beginning when you want to make a substantial change. Scheme is the simplest in the S-expression family, so I'm starting there to get my mindset. plt-scheme.org is the best looking intro I've found.
**FFI. Many interpreters use libffi to let you call regular .a and .dll libraries, making the C and C++ standard libraries available to you. I'm coming from C and I know those libraries well. If the interpreter (byte code compiler for you precision fags) lets me call into user32.dll and put some windows on the screen, then I'm in my home territory.
**CPAN. A huge, centralized repository of finished routines, tested and indexed. You can plug them into your project or use them as examples. I don't know if any of the other languages have surpassed Perl's CPAN yet. Although I will write my top control logic in Scheme or whatever, I will look for a way to call Perl and pass data to and from it, even if I have to use files to make that work.

There are counter-arguments. You can get so good at Haskell or Forth that you get your program mostly right the first try and end up with tiny, elegant code. I don't think I'll ever be that smart, though. The Lisp hacking philosophy suits my stumbling idiot, one-little-step-at-a-time approach better.

The others seem to require you to go back and start from the beginning when you want to make a substantial change.
you obviously didn't look at factor much.

>>53
You've caught me in my serious day, I'm serious Anonymous and this is serious post. I'll propose Python, but I'll comment on its pros and cons here.

Of these 3 families, the S-expression seems best for fast prototyping
I'd say this family seems best for anything (at least anything that's real work). Real work requires changes (it mostly is made of changes) and you need to take as little time as possible, and want as much flexibility as possible.

I favour Python as a practical language, yet here's my main gripe with it: it has statements.

FFI
Python has awesome FFI. It has ctypes, which is simple and what you need, but you mentioned Win32 programming. Python also has PyWin32, which takes an extra step and makes it a bit more Python-friendly, function by function (so it's XBOX), and you may want to have a look at it as well. You also said something about GUIs. Python is probably the best of the languages you're considering here. Not only it supports Win32 (either natively or through FFI), but it also supports WxWidgets, Qt, GTK, Tk, and god knows what else (I've even seen custom small UIs on top of SDL+OpenGL), as well as several console interfaces (try Urwid, looks awesome).

CPAN
Just Python's standard library is a pretty decent contender as it's packed with all kinds of useful stuff, from SQLite to an SGML parser. Then you have the Python Cheese Shop, which is not as large as CPAN, but has good stuff.

Fastest prototyping language? Huh. Anything that doesn't slow your prototyping down is fast enough. And that's down to how well you know your shit.

>>54
>you obviously didn't look at factor much.
I obviously haven't looked at any of them much as I'm trying to pick one to start with. I've seen more comments about speedy Lisp development than I have about speedy Forth development. I know that's a lame basis for picking one over the other, but that's all I've got without investing the time to learn the language. If you're The Factor Guy that keeps bringing it up, please pick your favorite sample Factor app and post a link to it.

>>55
Good post. I do expect to go somewhere after my Scheme intro, most likely Python or Ruby. Cheese Shop is a strong plus. The others like PyWin32 amount to library interfaces which I require of any language anyway.

And PG wouldn't make a strong leader? Practical all the suave Lisp noobs bone him.
Well, yes, that was the point. Normally I'd dismiss Arc out of hand as pointless reinvention, but if PG does somehow release it, there's a real hope for the Lisp community.

Also, Lisp seems to be getting a lot more exposure recently. Hopefully some fresh blood will flood out the stagnancy.

If not, all roads lead to Lisp anyway. The LAMP languages (excluding PHP) are a big leap up from most C and ALGOL derivatives.

And that's down to how well you know your shit.
And the language providing you with the tools to do it with.

All languages are a straight-jacket. Some are just a lot looser than others.

>>55
tl;dr

>>55
Your post was far too long, and as a result, I didn't read it.

>>60-61
Ok, I'll write a tl;dr version for you:

1. Use Python lol
2. Main gripe: has statements >_<
3. Awesome FFI: ctypes, plus PyWin32
4. GUIs? ctypes, PyWin32, Qt, GTK, Tk, Urwid, even more
5. CPAN? Standard lib already pretty good, then you have Python Cheese Shop

>>58
Well, yes, that was the point. Normally I'd dismiss Arc out of hand as pointless reinvention, but if PG does somehow release it, there's a real hope for the Lisp community.

Oh, I see.

Also, Lisp seems to be getting a lot more exposure recently. Hopefully some fresh blood will flood out the stagnancy.

[Common Lisp[/u]
I guess so. The only gripe I have against Lisp is the implementations (compilers/interpreters) and documentation. It needs to be open source and stable, and cross-platform, with working threads, FFI, sockets etc. made easy as pie with good up to date documentation. All the good Lisps for Windows are proprietary, for example.

Scheme
Recently I've found Scheme's implementations to be of much higher quality. E.g. PLT Scheme is very good, it has green threads, sockets, GUI and FFI (e.g. using OpenGL, TCL from Scheme), that's all I've tried so far. But they are all stable and very easy to use. It comes with shit loads of examples including a few games that use OpenGL that work straight off. I've written an IRC library in it thus far. I haven't tried others but I hear good things about Chicken Scheme and SISC.

>>63
I favour Scheme over Common Lisp for three reasons:
1. Cleanliness of design (2-Lisp and all that crap that goes against LISP's very principles)
2. Lack of legacies (progn? mapcar? It's bad enough we have car and cdr, insert stupid Lisp joke)
3. PLT Scheme

my other car is a cdr

Some relevant discussions here, although they don't shed a WHOLE lot of light on the "which language" question: http://c2.com/cgi/wiki?ForthVsLisp