POLL: What's your favorite language?

One vote per person.  Posts that appear to be bot generated or same person will not be counted.

I'm going with java(and by that I really mean java+eclipse).  Programming without eclipse is like putting a screw into hard wood without pre-drilling a hole.

C

>>8
invented unhygienic namespaces
Are you high or just tollan?

>>39
Who gives a shit about tail recursion? I don't.

>>43
He doesn't care. Neither do I.

>>44
He doesnt care, but I do.

>>45
He cares and therefore is retarded by induction.

>>46
He expressed no indication of caring or otherwise and therefore has avoided being judged as he has another.

>>43
OO programming lends itself to placing calls in a proper tail position quite naturally. It is a shame OO languages still haven't caught up to 1975.

I really, really, really like python.  more than any other language.  Its fun and great.

>>48
That's why 1975 is used so much in production environments, right?

Oh yeah, and let's not forget that even academia is moving on to other languages.

That's why 1975 is used so much in production environments, right?
Whether it is or not has no bearing on my comment. I am not suggesting Scheme be forced on everyone in all environments. I am suggesting that tail call elimination fits well with OO code.

Factor. Because LISP hasn't caught up to 1958 yet.

>>42
All right, that was a bad wording. I'm sure Scheme didn't invent unhygienic namespaces, but as far as I know, no significant Lisp dialect at the time had such a brain-dead misfeature. Perhaps I should have said it imported unhygienic namespaces, or that it brought them to Lisp.

I both agree and disagree with >>35. It's true that a programming language is just a tool, but unlike a literal tool, a programming language (like a human language) allows you to convey ideas, so it's not strange that someone will have a language they like more simply because it lets them to better convey their ideas.

My personal favorite is C++. What can I say? I like it. If I had learnt C first, I would probably have liked C better, but I didn't.
I've read the arguments on C++'s bad design, but I don't really agree with most of them, and I think the benefits outweight the costs.

C++ was designed for large code projects, with code reuse and forced abstraction layers(Forced Objectification of Code) to
make programs more enterprisey/flexible. They failed miserably and most C++ code is just C with couple of nice features tacked on, like operator overloading.


_______________________________________________
http://xs135.xs.to/xs135/09042/av922.jpg
Only the dead have seen the end of war.

Sage for ignorant ass FV

"Any language with regular expressions" > COBOL > C > *

Regexp are the only thing that come close to the stuff you can do with variable declarations in COBOL.

>>57
C structs can do a lot more than COBOL's variable declarations can. Or were you counting on nobody actually knowing COBOL here?

>>55
C++ was also designed to give the programmer choice, even if it meant that he could choose wrong. With that in mind, I think it's safe to say that it's the users' fault.

>>57
That's one stupid argument. You can add regexes to any language just by using a library. What does it matter if the language already has them?
In any case, just the fact that you think COBOL is better than C renders all your arguments invalid.

>>59
I ENJOYED using COBOL more, look at the thread title - I never said COBOL was better. Regexps trump the thing I loved most about COBOL. So I could finally "lay it to rest" in my mind.

Since COBOL is "too old" to be good, any language "that makes use of regexp either built-in or through an external library" is more enjoyable (in my mind).

>>59
It's all well and good to look back after you have finished something, and say that you with your infinitive wisdom intended for it to turn out exactly like that from the start. As much as I like Dennis Ritchie, don't think for a second C++ was designed to give the programmer choice.

>>57
Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems. ...

>>54
Some languages are tailored for a specific part of problem space.  If I'm writing something headless, distributed and networky, with a bit of database on the side, I'd much rather be doing it in Erlang -- but even though it now has a wxWidgets binding, I wouldn't think of doing UI programming in it, given the choice.

>>58
Forgotten about the joys of level 88? Let me preface this by saying that maybe I need to look deeper into structs, and I haven't used COBOL for a while.

In COBOL I can declare a variable called "CUST-ID" that I want to be a single character followed by 4 digits (i.e. C1234) as part of that declaration I can create a boolean variable called "CUST-ID-CHECK" that is automagically true ("Y") if data entered into "CUST-ID" is the correct format.

But you already knew COBOL so you already knew this right? How do I do it with structs?

Makes input validation easy & keeps the code "cleaner" imho. But I had to "move on" so now I like using Regexps,

>>62
You realise you bashed the use of regexps just before basically saying "the right tool for the job".

Which is kind of the problem with this whole thread, people code different types of programs, and have to balance resource usage/speed to code completion/maintainability/etc, the other problem is bias towards whatever language you started with. Start with a low-level language and go to an "easy" higher-level language which will be your favourite?

D

>>53
I'm not really sure I understand this criticism. Can you elaborate on why this is a problem?

>>66
I'm not >>53, but his issues are probably with the duality of symbol values. In Common Lisp, a symbol can have a functional value and a normal value, when you call a function such as (symbol params), it will work, but if you pass it as a parameter, you have to get the symbolic value located in the parameter/local variable/binding, so you would use (funcall symbol params). Some Common Lisp programmers actually like this duality, while other prefer the way Scheme implements it. He may also be talking about how packages and symbol import/export works in LISP vs modules in Scheme, but I don't know how modules work in Scheme, so I can't talk about that.

>>34
Japanese is not a programming language.

>>68
OP never specified that he meant a programming language. ＮＩＨＯＮＧＯ is a language.

>>69
It's implied, seeing as this is a programming board. And since you're using the English alphabet, why not use the English translation? Or were you implying that I did not know 日本語 translates to Japanese?

>>68
I dont see why it coulndt be.

>>2
And programming in Java is like sticking your dick into a very slow-cooking toaster.
That sounds sort of nice. I think i'll try that. The slow-cooking toaster, that is.

>>66
Yes, >>67 has the right of it. Common Lisp has separate namespaces for functions and variables, or said another way, a symbol has both a function cell and a value cell. If I bind a symbol to a value using “let”, or “defvar”, or if it's a parameter to a function, then that symbol's value cell is bound. If I define a function with “flet”, “defun” “labels”, or run “(setf (symbol-function 'foo) (lambda ...))”, then the function cell is bound.

Variable lookups use the value cell, and function lookups (for example when a symbol appears in the car of list to evaluate — a function call like “(foo)”) use the function cell. So for example, the following causes no collisions.
* (setf (symbol-value 'foo) 3)

3
* (setf (symbol-function 'foo) (lambda () (print 'something)))

#<FUNCTION (LAMBDA ()) {ACBA5C5}>
* foo

3
* (foo)

SOMETHING
SOMETHING

The upshot is that I can use names like “list” and “floor” for variables without clobbering any functions, which is absolutely wonderful. And even better, it means that I don't have to worry about accidentally clobbering functions that a macro I'm using relies on.

Scheme, for no reason at all, failed to copy this feature, and it's led to no end of trouble. Ugly variable names and bizarre “hygienic” macro systems are the big warts. Hey Scheme, maybe if you hadn't put your toilet in your kitchen, you wouldn't be freaking out over “hygiene”.

>>73
I guess I don't see what the problem is. I've never come across a case where I needed a variable and a function to have the same name in the same lexical scope. I've noticed myself shadowing list a lot but I've not yet run into any problems. Usually when I need list, a clearer variable name is already in place.

Can you give a non-foo example? Or is this just one of those "preference" issues without major substance behind it?

Macros, like I said. I don't have any particular example in mind, except for “list”, which I have used plenty of times. The point is that it's not necessary to think about whether you're punning a name. Probably for slot accessors I've used functions and variables with the same names in the same scope.

These threads always devolve into language aspects v. other language aspects very quickly. Saging my own post because it's worthless.

I've been getting depressed lately because I think I have no favorite language anymore.

C just needs too much boilerplate for a basic object-oriented framework (which is what all large projects boil down to anyway). You lose the logic in the thousands of lines of code. Same goes for all the old languages, e.g. Fortran, COBOL, etc.

C++ is too god damn huge. This is the depressing part; any attempt to wrap up the boilerplate of C results in incredibly complex rules on construction/destruction, etc. Then there's STL, which is fucking horrible, but it would hardly matter even if it was awesome because everyone writes their own anyway and it still sucks.

Java is horrible. Horribly, horribly god damn needles-in-my-eyes fucking HORRIBLE. Worst language on this list, bar none. I won't even bother describing why. Feel like finding out on your own? Try, say, making a generic array slice function (then try doing it in J2ME). Go for it. Failed yet? Not only is it not high-level, it's not even low-level. It's just fucking trash.

C#, D are somewhat better than Java, but still have many of the same problems. They're quite similar under-the-hood, which is where many of the problems stem from.

Objective-C is a horrible language. It's just C with an external object-oriented framework stapled on with bizarre syntax. Runtime method dispatch through a hashtable? God damn, that's slower than Java.

Lisp variants seem to have nice syntax, until you realize they're really just turing tarpits and you can't actually make anything scalable with them. The syntax also misleads you about how powerful they are wre introspection, reflection, etc. They aren't.

Haskell is, honestly, a joke. Let's make all functions pure. Great idea! Aw fuck, we have to interact with an *environment*, and take input from a *user*... What a hackish kludge of a language, where interactivity is barely a second thought.

bash->awk->Perl->PHP are all one and the same, freaking shell scripting languages, I don't care what anyone says. No one should ever have written more than a handful of lines of code in them, and the only reason they did is because CGI was built by hackers who didn't really like to program.

Python is closest, but I've slowly been drifting towards believing that python's raw power is actually a hindrance to the maintainability of code. *Everything* is a first class object, modifiable at runtime: runtime code compilation? of course check. modifying the function list in a module (as a simple dictionary)? check. changing the methods on individual instances of objects, including operators? check. trivial expansion of arguments, etc? check. trivial introspection of variable lists on objects? check. It's just crazyness. You know things people *shouldn't* do get done anyway because it lets you solve your problem in four lines of code instead of forty, so you end up with a huge mass of spaghetti.

Christ. Here I am thinking I made a terrible career choice. Fuck this shit.

>>78
Lisp variants seem to have nice syntax, until you realize they're really just turing tarpits and you can't actually make anything scalable with them.

Tell that to ITA. Lisp has been scaling for decades. I don't think it's going to stop for you.

>>76
But this problem doesn't disappear just because functions have a separate namespace. What about index variables? i, j, k... standard index variables in simple circumstances but it's the same problem, you are just accustomed to using i and j and not "list" and "rep[resentation]" or etc.