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.
Name:
Anonymous2007-07-15 14:11 ID:NfT0fxK4
BBCode, of course.
Name:
Anonymous2007-07-15 14:52 ID:tjpj9R6y
J
Name:
Anonymous2007-07-15 15:01 ID:dQ83wE4i
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.
Name:
Anonymous2007-07-15 16:38 ID:oGMlVLax
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).
Name:
Anonymous2007-07-15 17:09 ID:fcYRB4tl
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.
>>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.
Name:
Anonymous2007-07-15 18:29 ID:bvfQcyob
I'd have to say Python.
Name:
Anonymous2007-07-15 18:29 ID:tXjcxWpB
C++
Name:
Anonymous2007-07-15 19:22 ID:HXgHb0kv
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
Name:
Anonymous2007-07-15 20:08 ID:ODVtb9sc
I'd say lisp, but you have to be good at it.
Name:
Anonymous2007-07-15 20:18 ID:D/7FPBAE
>>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.
Name:
Anonymous2007-07-15 21:06 ID:D/7FPBAE
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.
Name:
Anonymous2007-07-15 21:31 ID:KdeWKrzH
Prolog is good. Check out "Software Blueprints: Lightweight Uses of Logic in Conceptual Modelling" by David Robertson and Jaume Agusti.
If you plan to go the Forth route, then -- based on what I've seen -- Factor is indeed a good choice.
Name:
Anonymous2007-07-16 3:46 ID:IJyao4Ma
>>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.
Name:
Anonymous2007-07-16 10:44 ID:/Gbnttbz
>>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?
Name:
Anonymous2007-07-16 10:52 ID:IJyao4Ma
>>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.
Name:
Anonymous2007-07-16 12:59 ID:fobsDSZo
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.
Name:
Anonymous2007-07-16 13:01 ID:fobsDSZo
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.
Name:
Anonymous2007-07-16 15:43 ID:yF6okWmh
Fine.
As expected, I didn't get 1 clear favorite (/prog/. heh).
So, I'll just have to learn them all.
onlisp is a great book for macros. that's all i'm gonna say. and yes, I believe macros are like the ultimate abstraction.
Name:
Anonymous2007-07-17 13:16 ID:C8rlspRM
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.
"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.
"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.
Name:
Anonymous2007-07-17 15:13 ID:EY9ivdmo
>>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.
Name:
Anonymous2007-07-17 16:08 ID:8GEC5c+h
What sort of problems can I solve with Lisp though?
Name:
Anonymous2007-07-17 16:36 ID:EY9ivdmo
>>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.
Name:
Anonymous2007-07-17 18:38 ID:8R6Rjlfa
Can you create, say, a shmup in openGL using LISP?
Name:
Anonymous2007-07-17 19:50 ID:8Aljcjyb
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.
Name:
Anonymous2007-07-17 21:13 ID:WuVspxeC
>>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.
Name:
Anonymous2007-07-17 22:57 ID:quJW2bCZ
>>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.
Name:
Anonymous2007-07-17 23:04 ID:WfBAWB0c
>>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.
Name:
Anonymous2007-07-17 23:34 ID:R7HTYt1a
LISP is a good language, but the fact that a person like Erik Naggum uses it (see Usenet) makes LISP fail by association.
>>46
And PG wouldn't make a strong leader? Practical all the suave Lisp noobs bone him.
Name:
Anonymous2007-07-18 8:57 ID:KbDw+ohB
>>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".
Name:
Anonymous2007-07-18 11:55 ID:qqeggLB1
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.
Name:
Anonymous2007-07-18 14:12 ID:mqklU27n
>>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.
Name:
Anonymous2007-07-18 14:52 ID:R7W6j3UH
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.
Name:
Anonymous2007-07-18 14:58 ID:rbzWLWvj
>>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.
Name:
Anonymous2007-07-18 15:54 ID:Rw8vULon
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.
Name:
Anonymous2007-07-18 16:00 ID:Rw8vULon
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.
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
Name:
Anonymous2007-07-18 18:53 ID:KbDw+ohB
>>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.
Name:
Anonymous2007-07-19 5:41 ID:e8wzSZ3X
>>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