I highly doubt that this has much to do with laziness and much more to do with a nasty positive feedback cycle of post-purchase rationalization (for most time is the most important thing they can invest) and commitment bias.

There are a huge number of languages out there and it takes a large investment to become highly proficient in any one of those. Once you make that choice and sink all that time into becoming great with it you start to fall prey to the trap of post-purchase rationalization by seeking out confirmation of your decisions. Once you have placated your doubts, you rationalize the increased investment to become even better (that's commitment bias, also known as irrational escalation). And then you start the cycle all over again.

The exact same phenomenon occurs in all investment scenarios be it phones (android v. iphone), video games (xbox v. playstation), or programming languages.

It doesn't have to be irrational. Haskell could easily be better than Common Lisp, but I doubt that the difference is sufficiently large to justify the cost of switching. So I don't.

I've been going through many, many programming languages over the years. Many of them I can't even remember anymore. Some of them I have stuck with for a long time, simply because they were most suitable for the kind of problems I was trying to solve at the time.

Originally I was very much in favour of finding the 'One language to rule them all'. Being able to do everything with a single language seemed like a no-brainer. But what all these years of try-outs have taught me is that such a language simply does not exist. And I will go one step further to state that they shouldn't exist.

The problem with every single language which tries to be good at everything, is that it inevitably ends up being mediocre at best and a major clusterf*ck at worst (I am looking at you, c++). Yes, it may be able to solve every problem out there, but not at significant cost to the programmer and development cycle. Inordinate amounts of complexity make the whole business of writing a useful application nothing short of a nightmare. A nightmare that you just do not have to put up with.

Lately I have come to realize that the quest for that one language has been a monumental waste of time. I have since settled on a DSL strategy. Pick a problem and then find a language/toolset that is uniquely suited to solve that problem in the most efficient way possible. Not only does this make the development cycle less painful, it teaches you a great deal about the problem domain your are facing, without having to deal with all the superfluous nonsense that a general-purpose language would impose upon you.

By adhering to this strategy, the obvious side effect is that there is no such thing as a favourite programming language. It all depends on what you are trying to accomplish. For the time being, my focus lies on Go. Not because I think it's the best thing that ever happened to the world, but because it solves /my problems/ elegantly and (almost) painlessly. This doesn't mean I will be using it for everything though. I would not even consider using it for something UX/UI related. For the simple reason that it is definitely not the ideal tool for this job. Just like I won't consider using Javascript to build servers and other distributed systems.

Use the right tool for the right job.

Edit: When it comes to DSLs, I would even add this: If you can't find a suitable toolset/language for your problem, consider creating your own.

At Goldman, this was the precise approach in the group I worked in. Create a DSL that prices equity derivatives. Create a DSL that handles bond math. Create a DSL that lets junior traders whip up custom swing UIs of their exposures. One big problem with this approach is what happens when you get hit by a truck ? The programmers you hire to replace you don't want to learn your DSL, nor want to write code in some custom DSL. Its not a transferable skill. I cannot put a bullet point in my resume saying - I wrote bond math code in GS custom DSL. What would that even mean ? Maybe I just invoked some routine and it did all the bond math for me, so what specific skill did I learn other than memorizing your DSL's syntactical conventions ? So this sort of approach doesn't work for anybody in the long run, except the DSL creator who can justifiably be very proud of accomplishing a shitload of tasks using 2 lines of a custom DSL.

You worked with bond math -- that's what goes on the resume. It doesn't matter a lot whether it was a custom DSL or a custom library in a common language. Nobody trusts your resume anyway. It just has to start the conversation in the right direction.

Whether it's good for the organization is situational. Wherever you go, new hires have to learn the codebase before they can be really effective. It helps if it uses common tools and languages, but it also helps if it is well-factored. If using a custom DSL results in much better-factored code, it can be a net win.

There are so many languages out there. It's hard to get a job by leveraging your skill in the small subset you know without passing up a lot of opportunities involving the ones you don't.

This is an argument against proprietry languages, not DSLs.

"Lately I have come to realize that the quest for that one language has been a monumental waste of time."

A question that arises from this, how can you communicate this with too many intelligent developers that foam at the mouth for what they use, and don't waste a moment to scoff, snide or look down on others?

That behaviour, itself is kind of ironic, because in school I'm sure most of us weren't very popular or cool because no one knew what the internet was, nor were computers universally cool(er).

I wonder sometimes if it's not like continuing the uppity behaviour some may not have gotten over and instead turn on their fellow developers.

I wouldn't say that programmers are too lazy to learn new languages. It's just difficult to keep so much in your head and to reliably use all the different languages without having to recall the particularities of that language, its build and run time oddities, IDE, etc. My advice is to pick a few languages and learn them well. It's a waste of your brain-power to only know 10% of ten different programming languages and to have to learn how the other nine do that (whatever that may be). You're far better off knowing 60% of three languages. That's my experience anyway.

Edit: The three I suggest are:

1. C or C++

2. Java or C#

3. Python or Ruby

4. (optional) Linux Bash scripting or Windows PowerShell

Your list is very short and consists of languages that are quite similar to each other. I recommend learning ten or so programming languages from several different paradigms. It will take about a decade but it will be worth it.

You should include one flavor of Lisp, a statically typed functional programming language (like Haskell or ML) and another declarative programming language (like Prolog).

Of course, by being proficient in any of the languages you mentioned will probably guarantee you a safe job, but having broader horizons in programming and computer science will make your programming career more diverse and interesting.

"We play both kinds of music in here, Country and Western!"

I fully agree. It takes a long time to get familiar enough with a language that you can really use it very well. It takes practical experience building real products to get enough of a feel of what the strengths and weaknesses really are. This precludes learning a very large amount of languages, even for someone who's a full-time programmer with some liberty to goof off.

Even if you know several of those languages, if you've coded in one for a while, the odds are good you won't remember the syntax intricacies, the gotchas, etc when moving to the next one, not to mention what the name and argument order of every function in the standard library is.

Blaming programmers for being too lazy to learn new languages is silly. We use languages to solve problems. Working in an unfamiliar language makes the problem harder to solve, not easier. Unless the new language is a much better fit to the problem at hand. That's why its handy to know a few with widely different characteristics.

If there's a language that can hit many positive characteristics at once, it's more useful to know well than one that doesn't. That isn't laziness. That's called being smart.

I would add a functional language to this list. Even if you're not going to use it for real world programming it's likely that it will change the way you code. This is something that is often said and I think you need to experience it for yourself to understand what it means. For example learning a bit of Erlang and Scheme has changed the way I program in Python.

Obligatory PG essay on "If [Functional Programming] makes you a better programmer, [why wouldn't you use it all the time?]" for massive upvotes. (Please don't upvote this comment.)

http://paulgraham.com/avg.html

Python has functional features, but if you perceive it as being better than functional languages for functional programming, then I'm going to assert that you need to do some more serious functional programming. I say this as both a Python person and a functional programmer: Python can do functional programming, but it discourages it heavily, which is why whipping up e.g. parser combinators or monads is definitely possible but usually has some odd mismatch and either requires Python hackery or results in verbose and tedious code.

The comment about car and cdr suggests that your functional experience is a Lisp dialect; might I suggest Haskell or ML? Haskell ranges from beautifully readable to inscrutable, depending on who wrote the code—definition of arbitrary operators is beautiful, if used sparingly, and terrifying, if used heavily—while the MLs are much more consistent, but don't push you into the functional zone nearly as much and consequently are more immediately useful but less mind-expanding.

So you bring up some good points, I admit I am a little saddened to see my comment downvoted though and hope to clear a few things up. First the point I was making was about my experience, I understand I do not have deep functional programming experience. I don't perceive Python as being better than functional languages for functional programming, but rather I see it as offering the good functional qualities I personally have seen while still being good at other paradigms, I imagine if you desire pure functional programming it probably does not stack up to pure functional languages.

My experience is an AI class in Lisp and TA-ing a class that taught students Scheme and a lot of Python experience, so you are right, perhaps I should check out Haskell or ML for better readability. Although I think Python discourages functional programming itself, from what I've seen it heavily encourages functional features, between lambda functions, functions as first class objects, and list comprehension which offers mapping, filtering, and reducing. I know there are other functional features that I haven't been exposed to, but as far as the techniques taught at a college level class, I feel Python incorporates functional features beautifully, and I now find myself using functions as objects, lambdas, mapping, filtering, and reducing nearly every day I program. I know the "pure-ness" of functional languages isn't there as Python encourages side effects, but as far as giving average programmers functional power while maintaining readability, I like Python's adaptation of functional techniques.

Mine are: 1. Python - mixed with C extensions used in a functional way 2. Java - when I need better compile time tools and analysis such as static typing 3. AutoIt - Windows scripting

I have also dabbled in C++, C#, Ruby, and Perl, you need to experiment occasionally

I tend to believe that it's important for a developer to pick up a couple of languages. But a point that I often see people miss is that it isn't so important to learn the language's libraries and basic syntax, as it is to learn the languages idioms.

There have been many times that I have seen Java guys learn ActionScript3 only to misuse properties (unecessary Java style setter methods everywhere, no closures, etc) and other features simply because they didn't learn the core values of the platform. I doubt that they really gained much lasting value from the exercise in the end, despite using it for a few months.

A few days with Clojure or another functional language in which they really focused on the core idioms of the language would have been more valuable from a learning standpoint, IMO.

See, my problem is that I realized that productivity is not bounded by the language itself but also bounded by the tools and ecosystems around it.

Once I finished writing the code, I still have to debug, refactor, produce some sort of code documentation, do a build and deployment, handle dependencies, package it up, and probably signed the code (optional..), potentially produce a nicely formatted changelog.

Writing _just_ the code is half of the battle unless writing sample code is all you do.

The reason I am annoyed with Python is simple.

It isn't that Python is a bad language--it's just not very good. Which is fine: plenty of languages are not very good and I don't mind. The issue is that it is extremely overrated, especially here on HN. And this translates to real inconvenience for me--I am forced to use Python when I would be better off with something else.

So the issue is not that I'm not willing to learn--I am! I even know Python fairly well (I do use it both at work and in classes, after all). And I am familiar with plenty of other languages, some worse but several better. So it is going to annoy me when somebody--yet again--presents Python as the best language you absolutely have to learn.

If you already know some similar languages, learning Python next is not your best option. Learn something interesting and different: Scheme, Scala, Clojure, Haskell, C, Go, assembly, Smalltalk...etc.

I think you're overestimating the importance of popularity because AutoIt is so specialized and moreover proprietary.

All of the languages I've listed have very good open source implementations and active communities. (Except assembly. But assembly is special, so let's ignore it.) Additionally, all the languages work and are stable.

Really, AutoIt is almost a straw man: it does not compare to any of the languages I listed at all. Reading about it, it seems that almost any modern programming language is going to have much better features, support, implementations, performance...etc.

If AutoIt is the standard you're holding Python too, of course Python is going to seem wonderful! But that's not very telling: any modern language is going to seem magical in that comparison.

If you've only ever used AutoIt and Python, you should really consider learning some other languages. It will give you a much better perspective, and make you think in new ways. I particularly suggest learning a statically typed functional programming language like Haskell.

I know a good bit of other languages, lots of C family and Java, and dabbled with Ruby, Perl, and a few others. I got turned off of the functional languages mainly by Lisp though, as I found it to be unreadable. Perhaps I will try Haskell some day, but so far I am not impressed with purely functional languages for most tasks I do, mainly image and file processing.

As with everything else in life, this is a compromise. It's a compromise of programming knowledge vs. the time to learn it and the time to keep learning. 10 programming languages, like others have mentioned seems exorbitant and you'll likely be spreading yourself thin. Knowing a functional language, an OOP language or two should be sufficient as your core languages. This isn't to say you shouldn't dabble in new languages and frameworks as they come out, but unless you're willing to cross bridges, the amount of time you'll spend learning the language, getting accustomed to new tools etc. will cost you more in time than is worth it to keep up to date with your core languages (especially if they're as fast-paced as Ruby).

this, a thousand times this. I am a person who loves learning. And learning new programming languages is always a nice experience, but we are all human beings with limited time in our hands. Learning a new language every month sounds like fun but how much time can you devote for that? How well will you learn it? Will it be worth the time spent? Will it spread your horizons enough or would that time have been better spent in actually keeping up with the developments in your language (field)?

If I can and have built good or even excellent software in language X and then run into people telling me that X stinks then it's quite easy to find myself defending it. Not on the basis that it's a perfect language, but that it's a workable tool for many situations. Realizing that no language is perfect and that different languages better suit different tasks, it's not uncommon to find yourself being defensive.

I do agree with the points the author makes. I'm just pointing out that there are other reasons to be defensive, and some of them actually stem from knowing multiple languages and programming paradigms.

I find people's knowledge of other languages is largely hearsay, opinion and rumor.

Rarely facts. Ironic for such a fact driven group (developers).

I think there's a big difference between being defensive (caring to change the other persons mind) and clarifying (telling people they don't have all the facts and leaving it at that).

I prefer this reasoning for why people get emotional about programming languages:

When someone says, "Your programming languages sucks", they're also saying, "The way you go about approaching problems sucks", and essentially, "The way you think is wrong".

I think its reasonable for people to get emotional about a claim like that.

Why? It may be common to get emotional, but wouldn't it be much better to get rational about a claim like that?

Ahh, he obviously only thinks this because he hasn't learn Haskell yet ;-)

Just reading the title I knew Haskell or Lisp will be mentioned.

I agree that every programmer should learn one of the functional languages, although I personally wouldn't want functional programming to be my daily job.

Bravo. Language selection is almost always preference. But does it stop at languages?

I have been a bit of a polyglot in the past 15+ years. Not really by choice but how work led me. I picked up tips and tricks in several languages. Being able to use more than one language is like having more than one toolbox for the job. My dad had a toolbox for plumbing, another one for electrical, another one for general stuff.

Knowing more than one language is akin to being well traveled, being less ignorant of other cultures and people and generally noticing that people everywhere have more in common with how they live (or code).

Maybe English is as close as we have for a general language, perhaps folks who are a little zealous about their language of choice and inadvertently look down on others are wanting their language to become the english of programming.

Maybe we see difference when we want and connection when we want.

If we look in the Web space, the reality is most languages paired with a capable MVC framework for the Web, all are pretty capable in many of the same areas.

If we have an equally capable Ruby (with rails or Siatra), Python (with Django), PHP (with Cake or CodeIgniter) and let's an asp.NET MVC developer.. They would probably all come out with a pretty similar result.

First, all of these languages are all pretty old. Started in the 90's. The frameworks that we get attached to being hip, to me are our equivalent of culture, what's in fashion and capable today, ready to be replaced tomorrow by the next fashionable thing.

The tools don't guarantee success. Work with tools that are more rigid, and you have one kinds of problems. Work without any structure and you can make a horrible mess in any language. After having seen messes in every language, I am not convinced that any language is incapable of making a mess.

There are few things, and few times where any framework + language will provide a huge difference over another time wise. Where you save time in one, it'll take more time elsewhere compared to another framework + language.

If there is a language that truly gives you a feature, or an edge for your specific app, so be it. But in the web app space, I don't always see it so much, with so many great tools in so many capable languages.

"Why are so many developers so very emotional when it comes to their favorite programming language?"

Even more to the point... Why are developers so emotional about things like editors? All of these things (computer languages, editors, compilers, etc.) are just a means to an end: the end being a software system that, hopefully, makes the users life easier and/or provides them with something new to do.

Funny, when you put it in terms of editors, the answer for both editors and languages leapt out at me: claims to hardcore-ness, personal preference, familiarity, and basic human irrationality. We like to think programmers/hackers/whatever are all logical and rational because they code for computers, but... not really. All the usual social and behavioural weirdness applies.

All of those things are software systems that makes the developers life easier and/or more interesting.

Have you never met a tradesman who can talk at length about their drills and powertools? It's the same thing.

Developers are emotional about their tools because those tools enable them to create. Trying to use an unfamiliar tool can be unpleasant, in a viscerally emotional way, because little muscle-habitual movements don't have their expected effect. It's like trying to walk with your shoelaces tied together: you can do it, but it's annoying and sometimes you forget and hurt yourself.

Because editors are the means by which you translate your ideas into code, which is the means by which you translate your ideas into functionality. The more familiar you are with each of these means, the more automatic and transparent the process becomes.

If you mean to ask why developers believe their setup to be universally superior to all others, well, then it's most likely because they're too caught up in their own world to understand how subjective they're being.

I understand why people form attachments to a specific language and I can't deny that I have my own preferences. However when you stick to just one or two languages you're really limiting yourself and your projects, I see the tendency to try and pigeon hole every task into whatever language people are comfortable with and ignore others that might be better suited for that specific task. When you strip away frameworks most of the languages are very similar and jumping between them is not very difficult.

Primarily I use Objective C, PHP and Javascipt however I have done projects in python, Ruby, C++ over the years.

TLDR: The word for dog in Spanish is perro, however both dog and perro represent the same thing and a dog can always be trained to bark no matter what language you use to tell it to bark.

I feel that I've already wasted too much time deliberating with myself over which language to use. Sometimes the choice may be obvious (e.g., C for embedded devices). But when it's not obvious, most likely any of the languages you are even considering would get the job done.

This article makes the naive assumption that you can only use one language per project.

If I could pick one combination of languages for all my projects, I would rather have the combination of C++ and Lua for example (and maybe also C#, if I'm developing a Windows app) than a single language like Java, Python or Haskell.

I expect that is why C has survived so well - so many languages integrate well with it (and C itself integrates well with assembly.) Go does not have that advantage, and for that reason I doubt it will ever replace C.

Some commenters seem to think the only reason to learn a bunch of languages is to have a bunch of tools ready to apply to whatever problem comes along next, and yes, it is difficult to know many languages well enough to do that. However, I think they're missing the point of this blog post: dabbling in a bunch of significantly different languages makes you aware of the limitations of the (smaller set of) languages you use heavily enough to count as "ready to apply."

...for what?

If I'm a systems programmer for 100% of the time, chances are if I've chosen C or Go, then it probably actually is good enough (compared to the alternatives).

You never code any automation, scripts, testing, etc around your main codebase? Or do you program those in C? (gargle).

Some people do. /notme

I tend to find that Go is so multi-paradigm that it fits all my use cases well. It's a perfect high and low level language, fits entirely in your head, has decent testing support, scales code-quantity wise very well and is very fast.

It traditionally replaces all the areas I'd use Python, C# and C beforehand.

I see less requirement for "picking a language for the job" thanks to this.

It only sucks as a shell scripting language for which I use sh.

Actually I think that Go is exactly lacking lots of paradigms and is only good enough for people looking for a better C, as it lacks many of the abstractions from mainstream languages.

But if you are conformable with it, by all means use it.

What abstractions in particular? I'm interested from the perspective of resolving any issues in that space.

The following concepts are lacking:

- generics - enumerations (the iota thing feels like a poor man's enums) - operators as method names - lack of exceptions leads sometimes to ugly defer/recover patterns - some data types are special like maps, as you cannot implement similar types yourself

Are there any "real languages" that don't suck at shell scripting? I use node in client side code but glue things together with bash.

Yes: Perl. This was the original use case for the language. We used to have to glue together sh, awk, sed, grep, CLIs (custom C), etc in order to automate anything in Unix. Perl brought all of this functionality under one roof with a simple, coherent interface.

Most every complaint I read about Perl (too flexible, weird sigils) is a direct reflection of the system it was replacing. It's funny to read how people love that there's more than one way to do just about anything in Linux, but gasp that there are too many ways to do equivalent actions within Perl. They're one in the same. (I am not going to re-re-address its "readonly" nature since that's a red herring which applies to any language.)

Don't tell a lie. What's the best way to interleave two Python lists? http://blog.jarrodmillman.com/2010/10/whats-best-way-to-inte...

Fucking many ways to do something also in Python.

I used perl for about 5 years for general scripting tasks. It's not about there being too many ways to do something for me, it's that you need to know the subtlety of each one and cryptic abbreviations.

Can you suggest a real usable pragmatic option to Perl on a Unix scripting environment?

Python and Ruby tried to compete with Perl at the large application level. Interacting with databases and other stuff kind of things.

That still doesn't fulfill the requirements Perl was invented for. Larry Wall invented Perl not because he wanted a Python or Ruby, The Python and Ruby of that time were already present in the form of C. Perl was invented because C couldn't do a certain things well. Namely it never natively blended with the Unix philosophy. It couldn't do 'Text' properly. It could not be what awk, sed, grep and other Text processing utilities combined together would be.

Besides all that, Perl is a natural evolution to bash, shell, sed, awk, tr, cat and many many other text processing utilities combined together working together in a very large application. That continues to remain Perl's biggest and most distinctive unbeatable advantage so far.

Perl is a natural extension to Unix, and it has evolved to now be capable of doing nearly everything. If the name Perl would not have been given to Perl, it would probably Unix programming language. Think of it in that terms.

Do you know why despite so much trolling, bashing and criticism Perl receives. It still manages to grow and thrive year after year, decade after decade? Its because Perl is same as C, Lisp, SQL etc. Its a first time done right language.

Anything that is likely to replace Perl, will be a bad replacement to Perl. Or at maximum will be or look like Perl(Eg Perl 6).

To kill Perl you may have to kill the whole Unix philosophy. Because that is what Perl is. Its a natural extension to Unix.

Perl is here to stay for decades to come.

Every new generation of programmers will discover Perl and use it just like how every new generation of programmers discover and use C and Lisp. That is what enables stuff like DuckDuckGo to be built in Perl.

One can build anything in any language(considering the mathematical possibility). So by this definition we can all go back to building in Nand gates. But that is not what its all about.

Languages get used because they do a certain job well. Perl does, what it was designed to do very well. That is precisely what Larry wall's water bed theory of complexity is about(http://en.wikipedia.org/wiki/Waterbed_theory).

You have a problem with CPAN? With CPAN, really? A ecosystem that is considered as a killer feature which no other language has managed to emulate so far?

And Perl is monolithic???? Really? Are you aware what you are talking about. Are you just debating for debating's sake? Perl is probably the most extensible and flexible languages that is out there. That is what enables modules like Devel::Declare(http://search.cpan.org/~zefram/Devel-Declare-0.006011/lib/De...) to be written. Which is what enable gems like Moose to be built(http://search.cpan.org/search?query=Moose&mode=all)

Outside Lisp, Perl is probably the most flexible and most extensible language that exist. The entire CPAN is a standing proof of that.

Have you read Mark Jason Dominus's Higher order Perl, Have you read chromatic's Modern Perl? When you talk of elegance and power?

You call Perl a mess of a hundred text processing utilities. Can you show me one language that does regular expressions as well as Perl? Can you show me one language that handles Unicode better than Perl? Every other language I know creates huge spaghetti mess for even simple things like opening files and matching regular expressions. Have you used things like Parse::RecDescent??

Perl also gave a lot of other beautiful things to the world. Thinks like the Artistic License.

Not just that Perl is the only language community that has had more syntax based feature additions in the recent past than the rest. They have managed to release great features in the recent past.

There is too much in Perl core but Python with all those batteries is good, right?

Oh, C'mon. Why make your hypocrisy so apparent?

Java and C# do Regex and Unicode better? What was this? Java and C# have Perl compatible regular expressions(PCRE) I don't really understand what you mean when you say Java and C# do Regexes better than Perl. Because they are copied from Perl. Besides a single Regex in those languages comes wrapped in layers and layers code surrounded by 10's of lines of exception handling mechanisms. Perl is the only language which deals with such use cases sanely.

Perl was the first general purpose scripting language which had first class support regular expressions. Associative arrays. And you call that shoe horning? What about all other scripting language that added the same thing. Python doesn't even have multi line lambda's. Ruby make OO one true way of programming by its very language design.

Let me tell you what problem you have.

You hate Perl for some reason. You are just looking for reasons to justify that. While none exist.

As I said like it or not Perl is here to stay for decades. Because no matter how you bash, troll and whine about Perl. Its utility is supreme in certain areas which is very difficult to beat.

With all due respect to a fellow member, how does Java do Regex better than perl? When I attempt to use the Java Regex, I miss several features I am used to even in Python. Perl invented Regex, which helps explain why the syntax does what it should.

If you use Perl in CGI only then you seem to misunderstand lots of stuff. The Perl interpreter is loaded once per FastCGI task, so noone waits.... its the startup (which is then 100times faster against C# or Java, but whatever, not the topic). So please, dont compare Apples with Pears.

I rarely use Perl CGI. I haven't since about 2002.

Regarding C# and Java startup. It's not an issue. You can warm start appdomains/JVMs. We do this.

Once it's running, both Java and C# run rings around most things.

Impressive post... Perl Marketing and DuckDuckGo wanna thank you for those wise words :-) (from a guy working for both). Would be nice if you would get into contact with me: getty@duckduckgo.com or getty@cpan.org ;)

In probably 99% of Perl code, you only need to know two cryptic symbols: $! for errno and $? for child-process exit status. And if you're programming in shell now, you're already using $?.

Yes, there are symbols for handling autoflush on handles, input/output record separators, etc. But rarely will you need to use these items. In fact, we have methods for handling these situations for quite some time now.

For instance, to unbuffer your output you'd use $|, but now you just use $filehandle->autoflush(1). Another example would be undefining the input record separator so that you could pull in an entire file with one read, but now that's handled via Slurp::slurp_file.

Regarding "cryptic abbreviations", do you know about "use English;"? It provides readable names for all the "ugly punctuation variables". It's included as part of the core Perl install.

http://perldoc.perl.org/English.html

use English in itself is a sign of much turdyness.

It depends on your definition of real language. I consider Ruby and Perl to be real, production level language, and they are both excellent as glue languages.

Python, on the other hand, would need some helper functions to make the interface intuitive. But you only need to define them once, and then off you go.

D seems to work rather well as a scripting language.

  http://dlang.org/rdmd.html

Note the first line of the D "shell script":

  #!/usr/bin/rdmd

It is statically typed and non interactive. I'm not sure I could get on with that as a scripting language.

I've not found one yet! If anyone has any suggestions I'd love to know.

I've heard that scsh (The Scheme Shell) is good, but haven't tried it myself. Even though my web app is written in Scheme, I still have a few bash scripts.

I think chicken scheme is even nicer for that kinna stuff.

I have to say that I've found go to actually be pretty awesome as a scripting language, though I've not used it a lot for this purpose a lot myself. The type inference + straight-forward standard library helps a lot with it.

I've said it (or some variant of it) before: domain knowledge is tremendously valuable. If I have full access to my toolbox of personal libraries, I can be extremely productive in C++. If I don't, or if my new employer bans Boost, or STL, or importation of libraries (all very common C++ problems), then I suddenly feel like a junior programmer again, plodding along.

I agree that language exposure broadens your horizons. Even old PHP changed my approach to some degree, and right now I'm working on learning functional languages. That doesn't change the fact that I'm dramatically more productive on my primary platform.

If you can't use Boost and STL, you're C++'ing in the stone age.

Yep. Yet until fairly recently, many people were still distrustful of STL due to the various implementations and the godawful compiler errors. As for Boost, at my last company, I had to stage a long battle in order to get even a minimal portion of Boost into our product.

exch writes in the comments "Lately I have come to realize that the quest for that one language has been a monumental waste of time.".

I'm not sure. For one, that quest is how better languages are developed.

But there is another thing that bothers me. A lot of languages are good enough, and could be considerably better, if only the designers were not stubborn, or if only they had the resources and the will to break backwards compatibility for a while.

Take Python for example. Wouldn't it be better with:

- A better default UI kit than TK. - The GIL removed. - A JIT of JVM calibre. - Something like goroutines. - Optional static typing (and/or type inference). - Some way of AOT compilation (with an appropriate runtime). - Proper and easy to use closures (like Ruby/JS etc). - A better syntax to replace the double underscore thing. - Something like Virtualenv built-in. - Something like PIP built-in. - A redesigned base library, with the cruft removed and simpler interfaces

For a lot of those, there exist workarounds, half-baked implementations, etc.

Now, some people will say: "those will complicate the language", etc. But most of those changes are orthogonal, remove very real pain points, and some are even totally transparent to the programmer (like the GIL removal, or the JIT presence), while others enable totally new ways of using it. So, most complaints are of the "I don't want any change" variety.

Consider this thought experiment, to obliterate those complaints: if Python DIDN'T ALREADY EXIST AT ALL, and you were presented with two languages, one like the above (Python-A) and another like the existing 3.0 one (Python-B), which would you prefer?

I'd say that despite the complaints from current Python users on the changes above, 100% of the people would take Python-A. Right?

Now, nothing on the list is technically impossible (most are quite normal). But they require: the will of the core maintainers, a community to do them, money to back them up, etc. Actually, it just takes a major lead like Guido to be hell-bent on them, and lots of money, but not that much.

So, while a "perfect Python" (or a 100% improved one) is a possibility, it's sad to see that it's not actually achievable.

I can find similar pain points for most other languages (a PHP with a re-organized basic library with sane conventions and namespacing, a Javascript that's at Harmony-level on every browser, Ruby with better performance, Go with some way to write generic code besides interface{}, C with actual fuckin' strings, etc etc).

I agree at least with the C replacement part. For everything else restricting to Python is too restrictive (pun intended), as it depends a lot on what problem you are trying to solve with which constraints.

I would be very interested to see you produce a modern website that way.

Not that I'd recommend it, but it would be possible using Pyjamas, which compiles Python to JavaScript code.

> So the only point in your snark comment was "you will also need javascript".

Right. Javascript is not Go or Python. You will need more than those two languages.

>Plus, you could even code your javascript in Python, with Pyjamas ;-P

Please don't do that.

> Right. Javascript is not Go or Python. You will need more than those two languages.

Well, not necessarily. You can make a cool website without javascript at all. What with those fancy CSS animations and transitions etc.

> Please don't do that.

Why? Not that different from using Coffescript, or the Closure Compiler. And transparent to the end user.

> Not that different from using Coffescript

It is pretty different from using CoffeeScript. CoffeeScript produces output you wouldn't mind having to work with if you had to switch to JS. PyJamas produces a tangled mess that won't play nice with other JS libraries.

> or the Closure Compiler.

Yeah, don't do that either.