[nSLUG] Re programming language choice

Oliver Doepner odoepner at gmail.com
Sat Mar 1 20:22:13 AST 2014


Once you have worked for a while with the code generation, navigation,
analysis and refactoring features of Intellij for Java and understand why
that level of tooling is only possible for a compiled, statically typed,
stable mainstream language like Java, you will see why working with
dynamically typed languages (javascript, ruby, perl, python, etc.) and/or
mediocre IDEs like VisualStudio (without Resharper) or glorified text
editors like SublimeText and the like is like stepping back into the
stone-age (or cowboy era) of programming.

People who have never experienced and/or fully grasped the power of that
kind of tooling often don't know and don't want to know what they are
missing and might perceive my position as arrogant, narrow-minded zealotry
of an armchair programmer. :o)

I agree, that low-level and core computing knowledge is a necessary
foundation, but that doesn't mean that "polyglot" is a requirement.

It can be helpful and horizon-widening to know concepts beyond what one
language offers. For example, I follow closely what other JVM languages
like Groovy, Clojure, Scala, Kotlin or Ceylon have to offer. But I won't
use them for any serious development until they have the same powerful,
reliable and free/open source tooling that I can use for Java.

Cheers
Oliver





On Sat, Mar 1, 2014 at 1:10 PM, George N. White III <gnwiii at gmail.com>wrote:

> On Fri, Feb 28, 2014 at 10:54 PM, Oliver Doepner <odoepner at gmail.com>wrote:
>
>
>> Polyglot, not sure. I am only bilingual. I can do bash and Java. :o)
>>
>> I had to do a little Ruby/Rails in the recent past and a little Perl in
>> the distant past.
>>
>> Polyglot can also mean: Knows a little bit of many languages, but isn't
>> expert in any. I prefer working with experts and it is ok with me if
>> developers have to be specialists to maintain expert level in a few areas.
>> :o)
>>
>> Each of the programming "ecospheres" (Java/JEE, HTML5/web/mobile, LAMP,
>> Unix shell, DotNet, C/C++, etc.) is so full of sub-technologes, libraries,
>> cool new frameworks that I find it hard or impossible to maintain expert
>> status in more than one of them.
>>
>
> The systems I work with use C, C++, java, python, perl, sh, fortran, IDL
> (a specialized image processing language), R, and matlab.   I'm not expert
> any of these, but can generally get stuff done by choosing the language
> that best fits the problem and getting help from language specialists when
> I encounter a roadblock.   Much of the IDL, C, and fortran
> code is being rewritten (by space agencies) in Java, python, and C++, so I
> get to compare the original fortran (IV and ratfor) with C++ versions. I
> have also made lab reference docs for a number of basic calculations using
> multiple languages for use in teaching (so students from diverse
> backgrounds can start with code in a language they know).  Reimplementing
> an existing system in a difference language has been very effective at
> revealing long hidden bugs as well as introducing new ones.
>
> In computing, there are fundamental ideas that are used in many languages,
> and fundamental problems (networking, ipc, resource management, etc.) that
> need to be addressed in many projects.  Someone with sound understanding of
> the fundamentals can pick up a new language fairly quickly, and use good
> judgment in evaluating approaches to the problems that are relevant to a
> particular project.   There are many "expert" programmers who are weak on
> the fundamentals but get by because they have lots of technical detail
> knowledge in a particular environment.  Such people often use a cookbook
> approach where they follow detailed recipes without actually understanding
> the process.
>
> LIbraries and frameworks change rapidly, so long immersion in a language
> is only a short term advantage.  Cookbook approaches can work well if the
> next project involves relatively minor incremental changes from last
> project.  There
> are usually excellent frameworks and libraries for tasks that occur often
> enough, but to some expert hammer users, every problem looks like a nail.
> If you a building a conventional shed, hire a hammer user, but if your shed
> isn't conventional you may need to find someone who can match the tool to
> the problem.
>
>
>
>> On Fri, Feb 28, 2014 at 12:48 PM, Ben Armstrong <
>> synrg at sanctuary.nslug.ns.ca> wrote:
>>
>>> On 28/02/14 12:32 PM, Jim Haliburton wrote:
>>> > If the "newbie" was hired for his skill in the particular language
>>> that they knew, then
>>> > management should listen to their views.  If it was for a generic
>>> skill set management has to
>>> > consider if the new outsider is going to try and change the company to
>>> his way of doing things.
>>>
>>> As for the rest of your wisdom learned through experience, I can't
>>> disagree. However, so far as it is possible, management should strive to
>>> hire polyglots instead, who tend to be smarter anyway. Then decide which
>>> language to use based on longer term factors than who you happen to have
>>> on your staff at this point in time. Surely that will change over time
>>> ...
>>>
>>> Ben
>>>
>>> _______________________________________________
>>> nSLUG mailing list
>>> nSLUG at nslug.ns.ca
>>> http://nslug.ns.ca/mailman/listinfo/nslug
>>>
>>
>>
>>
>> --
>> Oliver Doepner
>> http://doepner.net/
>>
>> _______________________________________________
>> nSLUG mailing list
>> nSLUG at nslug.ns.ca
>> http://nslug.ns.ca/mailman/listinfo/nslug
>>
>>
>
>
> --
> George N. White III <aa056 at chebucto.ns.ca>
> Head of St. Margarets Bay, Nova Scotia
>
> _______________________________________________
> nSLUG mailing list
> nSLUG at nslug.ns.ca
> http://nslug.ns.ca/mailman/listinfo/nslug
>
>


-- 
Oliver Doepner
http://doepner.net/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nslug.ns.ca/pipermail/nslug/attachments/20140301/5b7e11ab/attachment.html>


More information about the nSLUG mailing list