Programming language

Go on, /prog/. What's your language(s) of choice and why?

*/prog/
fuck.

Scheme, it allows me to masturbate to abstract bullshite from the comfort of my text editor.

Ada

>>5
This is the only meme generator macro that I will ever truly approve of.

Python
C

Learned Python first
Was going to learn c++, found /prog/ and decided to learn C instead
Will probably learn more later

C, it gets the job done and I am comfortable with the syntax.

Since no one is ever going to say it: Java.  Despite myself, I actually enjoy using it.
Crazy, I know.

Haskell. I enjoy being a smug Haskell weenie and writing short and elegant software.

C. But that's boring so forget why.

Languages which (sadly) aren't (and why):

Clojure
I'm prejudiced against JVM. I wouldn't let that stop me, but more than one person has quoted access to Java libs as a plus.

Go
The "Go way" demands lots of boilerplate. C with libs for concurrency, comms and GC would be more concise. It was very promising until I realized this.

Erlang
It is my primary concurrent language. I just don't write using concurrency as much as I should.

ECMAScript
For want of a satisfactory implementation.

Honorable (not-so-sadly) mentions:

Python
Ideally I want strong concurrency, powerful closures, tailcall elimination and NO EXCEPTIONS. Obviously not Python.

Haskell
Tries hard to deny the machine. That's not a bad thing (except when it is) but most of my work is highly machine-relevant.

Perl
Been there, done that--what was I thinking? (Everything, apparently. All at once.)

[spoilers]^V_i^a_b^l_e [overline]HASKELL[/overline] ^S_o^l_u^t_i^o_n^s[/spoilers]

>>13
Viable B B c o d e Failure more like

>>10
You'll change your mind once you learn a decent language.

C for CPU-intensive things, Python for getting things done.
These are the languages most people who aren't idiots will use for their own projects, because they're the best in their respective fields.

http://blog.aegisub.org/2008/12/if-programming-languages-were-religions.html

>>16
Pretty surprised how many people here have said this. I do exactly this as well, and have for several years in my past 3 jobs and in my hobby projects. C for the application/game itself, Python for any and all related tools (code generators, editors, art exporters/importers, etc.) and for web development.

>>18
I'm actually still surprised anyone uses Python for anything.

>>12
The "Go way" demands lots of boilerplate. [...] It was very promising until I realized this.
Explain.

Common Lisp.
It was more of an accidental encounter - I rewrote the conditions system before learning about the CLHS.

>>18
Python for web development? But I do agree with you and >>16. It's just Perl, not Python.

i ruin thread
epic boxxy

i ruin thread
epic boxxy

>>22
Does that need an explanation because you don't know Go, or because you disagree?

Anyway, look at Rob's more-or-less recent post to the mailing list about exceptions (sorry, I don't have a link.) I don't care for exceptions, but there's a lot of jumping through hoops to get it working. OTOH it fixes defer, which is a good thing.

>>19
We'd love to hear your superior alternative.

>>28
I don't know Go. You said the "Go way" requires boilerplate. What is the "Go way"? Is it some verbose coding style people use that isn't required by the language?

>>25
Yep. Plenty of websites are written in Python (e.g. YouTube, Reddit). There are several frameworks out there (Django, Pylons).

>>30
The boilerplate is required. Take exceptions (I found the link):

http://groups.google.com/group/golang-nuts/browse_thread/thread/1ce5cd050bb973e4

The boilerplate required is fairly small (there are worse cases, like dealing with arrays of channels), but the code is far more ambiguous than traditional exceptions handling mechanisms. I'd rather write twice as much and have clear code, which is rarely possible. (The same problem arises with FSMs, arrays of channels and so on.)

I enjoy the fact that they're building features out of the language; the problem is this isn't Perl so you can't just use Exceptions; and have a syntax that supports you. Instead you've got the machine bits all over the floor, and it's not clear to an onlooker whether they are part of one machine or part of another.

>>25
Perl and Python are both good choices for "getting things done", the only problem with Perl IMO is dealing with it through C is horrible. I was trying to fit something heavy into a Perl script once. I gave up trying to make an extension, and instead wrote a C app that took its args on the command line, because XS was so disgusting.

>>32
Odd, I don't mind putting C in Perl. OTOH, Perl itself should not be put into anything (neither should Python.)

>>31
Yeah, that's horrible. I don't think you're ``supposed'' to write programs with exceptions in Go, though, so they have only themselves to blame. With the kind of hyper-robustness they are probably aiming for, it seems better to handle truly exceptional circumstances at the thread or process level by bailing out and letting the monitor thread restart you.

>>25
http://www.netfunny.com/rhf/jokes/99/Nov/perl.html

ONE WORD THE FORCED INDENTATION OF CODE THREAD OVER
and I feel kind of bad about it :-(

>>36
But do you ｆｅｅｌ　ｋｉｎｄ　ｏｆ　ｂａｄ　ａｂｏｕｔ　ｉｔ？

>>34
It's true. They always had a notion that exceptions would eventually be addressed. The reason they are "needed" is that there are operations that can crash the runtime--simple things like illegal array indexing. Rather than patch that up with existing facilities, they choose to invent a new mechanism. They definitely don't want anyone writing Erlang in Go, so linked processes--basically what you suggest--are out. Oh, but you can implement them on top of the exception handling you are now obligated to implement.

In theory they might standardize the way the libraries treat exceptions to the degree that "library exceptions" takes on consistent semantics. A package might then make sense for handling these exceptions, but I've got no faith that users will reproduce those semantics. The mailing list is filled with fanbois, regurgitating anything said by {Ken|Rob|Russ|etc} in answer to questions about the wisdom of any decision--usually inappropriately. If that's representative of the userbase... well I've seen the code these people write.

It's kind of sad. At first I was hyped for a new concurrent language but then the bad decisions started coming. After a while I realized that goroutines don't even get scheduled very well at all, so any bad decisions I make about when to yield/resume coroutines will trounce Go. The only other interesting thing they did was interfaces, which I still like, but these are not a substitute for generics any more than void **data is--and manual unboxing is a reputedly slow procedure (much slower than instantiating the unboxed type? Almost certainly.)

Don't change these.

Name:		Email:
Entire Thread Thread List