On 1/10/07, Gabriel Sechan <[EMAIL PROTECTED]> wrote:




>From: [EMAIL PROTECTED]
>On Tue, Jan 09, 2007 at 04:30:29AM -0600, Gabriel Sechan wrote:
> > THe idea of one language being better than another for "productivity"
is
> > pure bullshit.  No language is more productive than any other, except
>for
> > personal experience in it.  What tends to speed or not speed things up
>is
> > availability of libraries that can reduce the need to write code.
>
>What do you mean?  Do you mean if you know Lisp and assembly equally well
>that
>you'll be as productive in each?  Even if you have same amount of
libraries
>in
>each?  I find that hard to believe.

I think you'd have a hard time finding someone who truely knew assembly
and
Lisp equally well.  But yes, if you had the same libraries for each, you'd
be equally productive in each.

I can see your argument that most languages offer little enough efficiency
over one another to trump knowledge and comfort in a language, but this one
I won't buy. The pure number of steps it takes to do something simple in
assemby argues against doing anything efficiently ( when viewed from the
programmers stand point, not the machines). Assembly is nice if you are
doing things like writing interrupt handlers. Perl is nice for handling
strings. I don't know what Java is nice for, but I am sure it is for
something.  C/C++ is nice, because of the standards they follow, and
vastness of libraries available make them versatile, and able to compile
code for so many platforms.

You have to decide when you start a project what will be the basis of your
technology choice. If it is people you already have, then you should use
tools they are comfortable with. If you are going to build a team for the
project, then you may choose the best tools for the type of project you are
working on, and then choose the people basis of those tools. It makes no
sense to choose a tool that no one on you team knows.

--
JD Runyan

--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list

Reply via email to