
Your favourite programming language is not good enough - pors
http://blaag.haard.se/Your-favourite-programming-language-is-not-good-enough/
======
jbondeson
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.

~~~
ced
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.

------
exch
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.

~~~
dxbydt
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.

~~~
bluesnowmonkey
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.

------
16s
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

~~~
rhizome31
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.

~~~
tobiasSoftware
I hate functional programming languages but love functional programming. I
think the way Python does it is really good, combining the power with
readability, whereas the functional languages I've seen are completely
unreadable (operators named caadr and car?). So I totally agree with you.
Spend a few weeks diving into functional languages, then run away as fast as
you can IMO.

~~~
andolanra
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.

~~~
tobiasSoftware
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.

------
jsight
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.

------
hello_moto
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.

------
tikhonj
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.

~~~
tobiasSoftware
First a disclaimer, I am a major Python fan. While I don't wish to argue with
you, I'd like to share a personal experience that made me realize the
advantages of popularity. I began my hobby programming with a language named
AutoIt that pretty much no one knows about. This is a Windows scripting
language and began to use it to build mainstream software. A couple years into
that I realized my mistake and switched to Python. The advantages I gained
from using such a popular language were:

1\. Tons of 3rd party libraries. AutoIt had nearly none. In Python I use
Numpy, PIL, NLTK, OpenCV, and more.

2\. The language worked. AutoIt had bugs. At least one bug was part of the
language, I found it through coding that would happen in a college level
class. Popular languages have bugs too, but they have been tested more
thoroughly, and problems are pushed to be fixed more.

3\. The language was supported. AutoIt programs were thought to be a virus by
my computer. Python on the other hand is even supported by Eclipse, and I have
been using PyDev lately.

4\. The basic features were good. AutoIt only had a list data structure
nothing else. While AutoIt had a lot of specialty functions, there were many
more I ended up building from scratch that I should not have needed to. Also,
Python has lots of nice features, such as list comprehensions.

5\. People knew what I was talking about. Whenever I told people I coded in
AutoIt, they were always confused and had no idea what I was saying. I love
being able to tell people I am a Python programmer and they are like, hey
cool, do you like this feature?

Now AutoIt is an extreme example as I haven't heard of it even on Hacker News
so the languages you mention might not have such problems. But I'm guessing
some of those problems exist in some form. Just my two cents on a personal
experience of how popularity can actually matter in some ways.

~~~
tikhonj
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.

~~~
tobiasSoftware
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.

------
instakill
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).

~~~
LefterisJP
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)?

------
dwc
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.

~~~
j45
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).

------
gilgad13
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.

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

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

------
Void_
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.

------
j45
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.

------
ericHosick
"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.

~~~
afterburner
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.

------
kenrikm
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.

------
tjr
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.

------
finnw
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.

~~~
tobiasSoftware
I love the combination of C and Python. Python's my favorite language, but the
speed totally sucks. So I code my core algorithms in C and everything else in
Python.

------
kd0amg
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."

------
davedx
...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).

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

~~~
pnathan
Some people do. /notme

------
bwarp
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.

~~~
MatthewPhillips
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.

~~~
fabricode
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.)

~~~
bwarp
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.

~~~
kamaal
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.

~~~
bwarp
I'll probably get downvoted for this. I know Perl very well which is why I
don't use it.

I disagree with you...

If UNIX was a schizophrenic, paranoid, indecisive, eclectic, personality-
disorder equipped operating system, then you'd be right but it's not. It's
pretty well thought out (I exclude Linux from that which is a right mess).

Perl is not a natural evolution of, but a putrid mishmash of shell, sed, awk,
tr, cat etc bundled into an incongruous monolithic blob with groupies from the
cult of CPAN knocking off the edge cases left right and centre when it doesn't
do what you want (using bits of C in some cases!!).

Perl is not the UNIX philosophy of small tools and loose coupling. It's
entirely the opposite: A monolithic turd that just won't flush.

DuckDuckGo was probably built in Perl beause the individual who built it
probably knew Perl. You could build DDG in C# or Java if you really wanted!
(and it'd spend less time waiting for the Perl interpreter to tick).

~~~
kamaal
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...](http://search.cpan.org/~zefram/Devel-
Declare-0.006011/lib/Devel/Declare.pm)) to be written. Which is what enable
gems like Moose to be
built([http://search.cpan.org/search?query=Moose&mode=all](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.

~~~
bwarp
CPAN is a mess of poor maintenance and poor documentation. It's also painfully
coupled to everything.

Perl is monolithic. There is too much in the core.

I've read large chunks of HOP whilst tryingand I just can see how some things
are pooly shoehorned into the language. Some of the tricks with the reference
semantics are horrible.

Java and C# do Regex and Unicode better than Perl. Go does unicode better than
Perl. The API in C# is not much more verbose and the RE implementation is
significantly faster. It's also much easier to unit test.

Perl has too much syntax - so much so it doesn't fit in your head.

I think Perl has a nostalgic attraction but that is it.

~~~
kamaal
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.

~~~
bwarp
Perl is not the root of all things. I think you'll find computer science got
there first.

As for associative arrays and regular expressions, I think Perl blatantly
nicked those from awk!

The problem I have is that Perl is the "jack of all trades, yet the master of
none".

I'm fed up of the Perl monk(|ie)s preaching like religious nutbags every 5
minutes. I'm tired of hearing it. I'm tired of oh perl is jesus' sandals.

It's a WAS not an IS.

------
georgieporgie
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.

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

~~~
georgieporgie
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.

------
batista
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).

------
Kilimanjaro
If you need to program in C, use Go. For everything else, use Python.

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

~~~
batista
Well, Python is perfectly capable of producing a modern website.

Hell, even Go is (even used for some Google end-user visible web stuff).

So the only point in your snark comment was "you will also need javascript".
Well, duh. But that's in the client code, no reason to have it in the backend.

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

~~~
mistercow
> 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.

~~~
batista
> 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.

~~~
mistercow
> 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.

