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.

BBCode, of course.

J

Haskell. You'll spend a significant amount of time thinking, but the actual writing part won't take long and will result in relatively short code that is unlikely to have many bugs, if any at all. As a bonus, it tends to end up quite readable as well.

Haskell is the worst possible language for prototyping. It requires you to plan out every tiny little faggot detail of the program before you write it, and if you make a design error early on in a haskell project it's almost impossible to go back and change it because of the type system. It was a language designed by academics so that they have something to write papers to about (and boy, have they capitalized).

Perl CPAN (http://www.cpan.org/) has huge amount of modules you can use, so you won't have to implement everything yourself. Nice because it works, is tested etc. etc.

This is at least good for prototyping, where you can hack together a product with modules that don't necessary have to have the exact functionality you desire.

>>5 clearly isn't very good at Haskell

>>4 and >>7 cleary have never written any real programs in his life time. go get your phd and jerk off to your type inference. leave the real coding to the rest of us.

I'd have to say Python.

C++

Groovy is like a super version of Java. It can leverage Java's enterprise capabilities but also has cool productivity features like closures, builders and dynamic typing. If you are a developer, tester or script guru, you have to love Groovy

I'd say lisp, but you have to be good at it.

>>8
No fag. I know what a ukelele is because i've been playing stringed instruments since I was 4.
I started on the portuguese version of the ukelele, the cavaquinho.

It's not line count/characters as much as abstractions.

Perl can do certain things in one line and small numbers of characters, but it's domain-specific. Start writing complex programs and you have to do grunt work like all the other languages.

Prolog is good.  Check out "Software Blueprints: Lightweight Uses of Logic in Conceptual Modelling" by David Robertson and Jaume Agusti.

>>1
http://factorcode.org/

>>16
Factor fag

>>17
lisp fag

Ruby, Python or Perl, depending on what you need.

If you plan to go the Forth route, then -- based on what I've seen -- Factor is indeed a good choice.

>>1
Why "prototyping"? Just write the good thing at once. Let me explain. You take a flexible language, which probably means Python, Ruby or a LISP dialect. Then you start writing. As you progress, you'll be seeing how it should actually be implemented or improved. Because you properly abstracted and modularized the project (you did, right!?) and didn't make any retarded decision from the start, you replace part by part, until you're satisfied enough. And you end with the final product, written in a language that makes it fun to write and cheap to maintain.

>>4 [low bugs]
>>6 [large, growing, organized library]
>>11 [news to me. I'll look.]
>>12 [confirm my suspicion. Big learning curve is OK for pros.]
>>14 [Perl is domain-specific. Extraction and Report Language. Yep.]
>>15 [add Prolog to the list]
>>16 [good-looking documentation and samples, likely good intro to Forth]

Thanks for those replies.

>>20
Because many (not all) projects need the final, production version to be compiled to native code with an optimizing compiler tuned to the local CPU. So I distinguish the protoyping stage from the optimizing stage; the first stage goal is fast development, the second stage goal is fast execution. I know the leading byte code compilers are pretty quick, but if your customers will use your product hours every day for years, every second you can save them counts. Think of that every time your computer keeps you waiting.


Forth is stil at the top of my list, but post #6 reminded me of the value of CPAN: tons of code gathered in one place and indexed. That could outweigh everything else in terms of saving time.

Regarding high level abstraction, I've seen this mentioned a lot, but I haven't found good examples of it in full-size applications. However, I HAVE found good examples of Forth factoring in applications. I'm sure I'm just looking in the wrong places. Anyone know some LISP applications that use good abstraction principles?

>>21
Optimization is only worth if the time you waste optimizing is smaller than the total time all of your users waste waiting for the unoptimized program to complete through the program's life cycle, multiplied by a factor of worth (e.g. one user hour worth 0.1-0.5 development hours since you are (usually) much smarter than your users and do more important work). If that's the case, then I don't have anything against optimization; however, beware that optimizing algorithms is a lot of fun (and it happens almost instantly in O(1) space and time in the mind of a Satori programmer), but optimizing implementations can be very boring, especially if you have to work with C++. Also, try to optimize just the vital parts and keep the rest running on Python/Lisp/whatever.

Although >>20,22 does like to ramble, he has a point.

90% of your CPU time will likely be spent in less than 10% of the code. If you profile then recode only the speed-critical sections in a low-level language, you'll get the whole project done in a quarter the time, and it'll be almost as fast. As an added bonus, your program will remain flexible.

What a bargain.

I might add that an painless way to bind to C is my no.1 requirement for a high-level language. As long as you have that, you can paper over any speed or library deficiencies.

Fine.

As expected, I didn't get 1 clear favorite (/prog/. heh).
So, I'll just have to learn them all.

I started looking for web sites to learn these languages.
Perl, Ruby, Python, and Haskell have main sites and canonical
packages including introductory manuals.
The others are more scattered.
For Forth, factorcode.org looks as good as any so far.
For Lisp and Scheme, there is so much that I can't see the
best place to start. After 20 minutes, here's my list:
Lisp resources
   CLOCC, Common lisp Open Code Collection. http://clocc.sourceforge.net/
   Lisp Cookbook: http://cl-cookbook.sourceforge.net/
   Lush, mix Lisp and C: http://lush.sourceforge.net/
   ECL interpreter and to-C compiler. http://ecls.sourceforge.net/
   Graham: http://www.paulgraham.com/onlisp.html
   Practical Common Lisp: http://www.gigamonkeys.com/book/
   Successful Lisp: http://www.psg.com/~dlamkins/sl/contents.html
   various resources: http://lisp.org/
   list of books and sites: http://www.lispmachine.net/
   blog: http://pschombe.wordpress.com/
Scheme resources
   SICP: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html#%_toc_start
   The Scheme Programming Language: http://www.scheme.com/tspl3/
   Guile: http://www.gnu.org/software/guile/guile.html
   Scheme cookbook: http://schemecookbook.org/
   Scheme code repository: http://planet.plt-scheme.org/
   Scheme in a web browser: http://sourceforge.net/projects/tryscheme
   small interpreter with FFI, embedded in GIMP: tinyscheme.sourceforge.net
   PLT manual: http://download.plt-scheme.org/doc/301/html/mzscheme/
   various references: http://www.schemers.org/
   blog: http://pschombe.wordpress.com/
   web server in Scheme: http://sunet.sourceforge.net/

Is there a de facto main Scheme site that I'm not seeing?

Nevermind. I'll start here for Scheme
   http://www.plt-scheme.org/

+scheme: htdp.org

Did anyone say Scheme?

SICP or GTFO ;)

>>28
http://wiichan.net/c/src/118457391339799.jpg

what >>28 said, http://mitpress.mit.edu/sicp/full-text/book/book.html

>>25
needs moar prolog

also. does the [url] bbcode work? let's try it

[url="http://en.wikipedia.org/wiki/Prolog";]pen0r[/url]

>>31
i fail it

>>31,32
Failure of epic proportions.

   SICP: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html#%_toc_start
   SICP: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html#%_toc_start
   SICP: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html#%_toc_start
   SICP: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html#%_toc_start
   SICP: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html#%_toc_start
   SICP: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html#%_toc_start
   SICP: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html#%_toc_start
   SICP: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html#%_toc_start
   SICP: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html#%_toc_start
   SICP: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html#%_toc_start
   SICP: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html#%_toc_start
   SICP: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html#%_toc_start
   SICP: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html#%_toc_start
   SICP: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html#%_toc_start
   SICP: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html#%_toc_start
   SICP: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html#%_toc_start
   SICP: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html#%_toc_start
   SICP: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html#%_toc_start
   SICP: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html#%_toc_start
   SICP: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html#%_toc_start
   SICP: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html#%_toc_start
   SICP: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html#%_toc_start
   SICP: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html#%_toc_start
   SICP: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html#%_toc_start
   SICP: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html#%_toc_start
   SICP: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html#%_toc_start
   SICP: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html#%_toc_start
   SICP: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html#%_toc_start

onlisp is a great book for macros. that's all i'm gonna say. and yes, I believe macros are like the ultimate abstraction.

I have information relevant to this conversation.

"What do you think of ML and its derivatives?

Most hackers I know have been disappointed by the ML family. Languages with static typing would be more suitable if programs were something you thought of in advance, and then merely translated into code. But that's not how programs get written.

The inability to have lists of mixed types is a particularly crippling restriction. It gets in the way of exploratory programming (it's convenient early on to represent everything as lists), and it means you can't have real macros.

http://www.paulgraham.com/lispfaq1.html

This Graham guy makes sense.

"People frightened by Lisp make up other reasons for not using it. The standard excuse, back when C was the default language, was that Lisp was too slow. Now that Lisp dialects are among the faster languages available, that excuse has gone away. Now the standard excuse is openly circular: that other languages are more popular.

(Beware of such reasoning. It gets you Windows.)

http://www.paulgraham.com/iflisp.html

>>36
>>37
PAUL GRAHAM IS ALWAYS RIGHT.

"People frightened by Lisp make up other reasons for not using it. The standard excuse, back when C was the default language, was that Lisp was too slow. Now that Lisp dialects are among the faster languages available, that excuse has gone away. Now the standard excuse is openly circular: that other languages are more popular.
Lisp was too slow. But now there are a lot of other languages that are slower, so that makes Lisp better.
I don't think so.

>>39
No. What makes Lisp better is that it got much faster — to the point of being just barely slower than portable assembly C language — and that today we have machines which are fast enough not to care about execution speed much.