> Hating the sort of work a language is usually used for is something different, however.
Right on the mark. My day job involves working on a very interesting Java project (which actually doesn't hurt much by being in Java; C++ is the typically used languages for these sorts of projects). All else being equal, however, I'd stay away from job listings that only require Java (or that mention J2EE), as they typically imply "write web applications". Now a job listing that asks for domain specific knowledge (e.g., search algorithms) and asks for "Java, C# or C++ knowledge" (i.e., whoever wrote it is clued enough to know to that learn one of these, you know the other two) is different matter. That being said, I'd rather these listings say "Knowledge of C and any OO language" instead: Java and C# programmers who don't know C#, don't know those languages are doing behind the scenes (and would be out of clues as to why their application leaks memory despite running in a VM with a GC, or why the GC is causing their app to stop for whole seconds).
> Perl is the one exception, of course. All right-thinking humans hate perl.
For an alternative opinion on Perl, I'd suggest looking at "Non-Lisp languages to learn" Chapter in Doug Hoyte's "Let Over Lambda". He makes a very compelling point of Perl being a "beautiful blub": UNIX ideology taken to the logical extreme, but giving a developer lot of freedom as a result (see Class::Mop or Moose for example).
That being said, I completely understand you. There's some languages I can't stand. In my case that would be ASP, PHP and Visual Basic. These languages (and the code bases written in them) tend to reduce one's power to that of a fourteen year old with no computer science background. They took 90s/early 2000s Java/.NET anti-pattern of "re-usable commodity developer component" model () to the logical extreme: these languages don't offer any* tools that enable one skilled developer to compete with many (cheaper) unskilled coders. Whereas Java suffers from typically being used for very uninteresting tasks, these languages can only be used for very uninteresting tasks.
(*) Of course, since it's Java it would be "IReusableCommodityDeveloperComponent developer = ReusableCommodityDeveloperComponentFactory.getReusableCommodityDeveloperComponentInstance()", with bunch of XML files binding that factory to a university or even a trade school.
I thought "UNIX ideology" was "streams in motion; streams at rest." (Everything reads streams and produces streams; you create complex programs by piping a stream through smaller programs.) Shell scripting is really the pinnacle of UNIXism.
I was thinking "there's more than one way to do it". Perl can also handle streams very efficiently and do lots more. Having worked in the operations world, I also find shell scripting to be an anti-pattern. Automation/tools built as shell scripts are much more brittle and harder to make _production_ ready (i.e., running 24/7 in a datacenter with no human intervention, but being held up to a strict SLA).
Perl (as well as Ruby and to a lesser extent Python) lets you scale from simple scripts to full-on tools. It's easy to write pipes, filters, one-liners and simple scripts in Perl. You can then add logging to them (using the excellent log4perl package), let them make socket calls to a monitoring system (or embed a server in them to let a monitoring system connect to them), debug them with a real debugger, extend them to call C libraries (xs is easy) and package them into classes and packages, allowing others to re-use them as components of other systems.
Comments
> Hating the sort of work a language is usually used for is something different, however.
Right on the mark. My day job involves working on a very interesting Java project (which actually doesn't hurt much by being in Java; C++ is the typically used languages for these sorts of projects). All else being equal, however, I'd stay away from job listings that only require Java (or that mention J2EE), as they typically imply "write web applications". Now a job listing that asks for domain specific knowledge (e.g., search algorithms) and asks for "Java, C# or C++ knowledge" (i.e., whoever wrote it is clued enough to know to that learn one of these, you know the other two) is different matter. That being said, I'd rather these listings say "Knowledge of C and any OO language" instead: Java and C# programmers who don't know C#, don't know those languages are doing behind the scenes (and would be out of clues as to why their application leaks memory despite running in a VM with a GC, or why the GC is causing their app to stop for whole seconds).
> Perl is the one exception, of course. All right-thinking humans hate perl.
For an alternative opinion on Perl, I'd suggest looking at "Non-Lisp languages to learn" Chapter in Doug Hoyte's "Let Over Lambda". He makes a very compelling point of Perl being a "beautiful blub": UNIX ideology taken to the logical extreme, but giving a developer lot of freedom as a result (see Class::Mop or Moose for example).
That being said, I completely understand you. There's some languages I can't stand. In my case that would be ASP, PHP and Visual Basic. These languages (and the code bases written in them) tend to reduce one's power to that of a fourteen year old with no computer science background. They took 90s/early 2000s Java/.NET anti-pattern of "re-usable commodity developer component" model () to the logical extreme: these languages don't offer any* tools that enable one skilled developer to compete with many (cheaper) unskilled coders. Whereas Java suffers from typically being used for very uninteresting tasks, these languages can only be used for very uninteresting tasks.
(*) Of course, since it's Java it would be "IReusableCommodityDeveloperComponent developer = ReusableCommodityDeveloperComponentFactory.getReusableCommodityDeveloperComponentInstance()", with bunch of XML files binding that factory to a university or even a trade school.
> UNIX ideology taken to the logical extreme
I thought "UNIX ideology" was "streams in motion; streams at rest." (Everything reads streams and produces streams; you create complex programs by piping a stream through smaller programs.) Shell scripting is really the pinnacle of UNIXism.
I was thinking "there's more than one way to do it". Perl can also handle streams very efficiently and do lots more. Having worked in the operations world, I also find shell scripting to be an anti-pattern. Automation/tools built as shell scripts are much more brittle and harder to make _production_ ready (i.e., running 24/7 in a datacenter with no human intervention, but being held up to a strict SLA).
Perl (as well as Ruby and to a lesser extent Python) lets you scale from simple scripts to full-on tools. It's easy to write pipes, filters, one-liners and simple scripts in Perl. You can then add logging to them (using the excellent log4perl package), let them make socket calls to a monitoring system (or embed a server in them to let a monitoring system connect to them), debug them with a real debugger, extend them to call C libraries (xs is easy) and package them into classes and packages, allowing others to re-use them as components of other systems.