Re: Re: Web Languages

I agree that Java is still the choice language for large
enterprise
applications, and fortunately, the Java community has paid
attention
to the need for more agile flexible frameworks like RoR and
Django/Python, with the still relatively new Grails
framework.  Grails
allows for heavy OO Java integration, but also allows for
the rapid
deployment of RoR and Django.

So, watch for Grails job listings too in your unofficial
status.

Colleen Robledo, MLIS
Web Developer (PHP/RoR/Grails)

On Mon, Jul 14, 2008 at 12:55 PM, Tim Spalding <timlibrarything.com> wrote:
> The Craigslist data is interesting. Someone with time
on their hands
> should do it for various different markets. I suspect
SF leads the
> nation, with Cambridge, MA close behind, and that
Craigslist Maine is
> asking for Integer Basic programmers.
>
> On Mon, Jul 14, 2008 at 3:45 PM, Cloutman, David
> <DCloutmanco.marin.ca.us> wrote:
>> Tim,
>>
>> You may be right in the long run, if Ruby follows
the evolutionary path
>> of PHP, though I think PHP will adapt, with better
frameworks emerging
>> (like Symfony) and native Unicode support in PHP 6.
As far as Java goes,
>> I think it is the COBOL of the future. If you know
if, you'll probably
>> be able to find a legacy application to support for
the rest of your
>> life. And for many things, I still think it is a
choice development
>> language. For heavy duty OO programming, I really
think a strongly typed
>> language works better, and for that reason I do not
see Ruby or Python
>> being Java killers.
>>
>> I would not totally discount your book sales data.
It certainly
>> indicates the level of interest in learning a
technology. However, I
>> don't think it is necessarily indicates traction
for any particular
>> technology.
>>
>> My own unscientific metric for languages is
searching the Craigslist job
>> listing for the SF Bay Area. (This includes silicon
valley.) For my
>> purposes, I look at "internet engineering
jobs" and "web design jobs".
>> Here are today's numbers by keyword.
>>
>>                             PHP    Java   Ruby  
Python PERL
>> internet engineering jobs    110    71     22    
19     109
>> web design jobs              167    246    85    
98     31
>>
>>
>> It will be interesting to see how these numbers
shift when the first ROR
>> apps reach legacy status, as is currently happening
with PHP and
>> happened a few years back to PERL.
>>
>> - David
>>
>> ---
>> David Cloutman <dcloutmanco.marin.ca.us>
>> Electronic Services Librarian
>> Marin County Free Library
>>
>> -----Original Message-----
>> From: web4lib-bounceswebjunction.org
>> [mailto:web4lib-bounceswebjunction.org] On Behalf
Of Tim Spalding
>> Sent: Saturday, July 12, 2008 7:40 PM
>> To: Dan Scott
>> Cc: Marcie Pierson; Thomas Dowling; web4libwebjunction.org
>> Subject: Re: [Web4lib] RE: Open source support
models
>>
>>
>> Incidentally, lest you think I'm being a language
snob or bending the
>> evidence to my own ends, I was a Perl hacker once
and I program in
>> PHP. I do not know Ruby-or Python for that matter.
But I've tried to
>> hire smart, young programmers-for Perl when I was
at Houghton Mifflin
>> and for PHP at LibraryThing. The top talent out
there now has mostly
>> gravitated to Ruby and Python. I *hate* that, but
it is a fact.
>>
>> These is not some sort of bull feeling of mine, but
are exhaustively
>> documented every year by Tim O'Reilly in his yearly
book-industry
>> analyses. PHP, Java and C/C++ have shrunk five
years running. Ruby
>> came out of nowhere and is now quite
significant--particularly as Ruby
>> programmers seem to be less book-oriented than some
others.
>>
>> http://radar.oreilly.com/2008/03/state-of
-the-computer-book-mar-23.html
>>
>> Tim
>>
>> On Sat, Jul 12, 2008 at 10:26 PM, Tim Spalding
<timlibrarything.com>
>> wrote:
>>> Thanks for the correction on Evergreen.
>>>
>>> I wouldn't say I needed correcting on VuFind,
though. Saying that
>>> VuFind isn't mostly PHP because there are
chunks of shell scripting
>>> and HTML is like saying that a car isn't made
out of steel and glass
>>> because it also has leather seats and pockets
of air. Much the same is
>>> true of SQL and, depending on what you're doing
with it, JavaScript.
>>> And if you're going to count lines HTML against
lines of code, you
>>> should also factor in all the GIF and JPEG
images, not to mention
>>> Cascading Style Sheets. This way lies madness.
>>>
>>> Tim
>>>
>>>> Ha! Fact-checking is readily available for
a few of these projects at
>>>> http://www.ohloh.net/projects/evergreen/analyses/latest (for
>>>> Evergreen) and h
ttp://www.ohloh.net/projects/10977/analyses/latest
>>>> (for VUFind).
>>>>
>>>> So a correction: the business logic of
Evergreen is written primarily
>>>> in Perl and SQL, with a few optimized
sections rewritten in C. The
>>>> current catalogue interface is primarily
JavaScript with XHTML, and
>>>> the staff client user interface is written
in Mozilla XUL (XML +
>>>> JavaScript). The user interface for most
new staff client
>>>> functionality is being built with the Dojo
JavaScript framework.
>>>> Python is used for the internationalization
build infrastructure and
>>>> for the new EDI piece.
>>>>
>>>> The choice of language in the project
largely comes down to using the
>>>> most appropriate tool for the job. That's
one of the advantages you
>>>> get from building an application using a
service-oriented
>>>> architecture.
>>>>
>>>> --
>>>> Dan Scott
>>>> Laurentian University
>>>>
>>>
>>>
>>>
>>> --
>>> Check out my library at
>> http:
//www.librarything.com/profile/timspalding
>>>
>>
>>
>>
>> --
>> Check out my library at http:
//www.librarything.com/profile/timspalding
>>
>>
>> _______________________________________________
>> Web4lib mailing list
>> Web4libwebjunction.org
>> http://lists.we
bjunction.org/web4lib/
>>
>>
>> Email Disclaimer: http://www.co.marin.ca.us/nav/misc/EmailDisclaimer.cfm

>>
>>
>
>
>
> --
> Check out my library at http:
//www.librarything.com/profile/timspalding
>
>
> _______________________________________________
> Web4lib mailing list
> Web4libwebjunction.org
> http://lists.we
bjunction.org/web4lib/
>
>



-- 
Colleen Robledo
http://www.colleenroble
do.net


_______________________________________________
Web4lib mailing list
Web4libwebjunction.org
http://lists.we
bjunction.org/web4lib/

A similar idea, that is a little more in my comfort zone,
but probably
not as slick as Grails is the Resin / Quercus, which gives
you a Servlet
container with a built-in Java port of PHP 5. Its far from
perfect, but
one person at Code4lib in February said he was using to
scale his Drupal
installation.

http://www.caucho.com/

---
David Cloutman <dcloutmanco.marin.ca.us>
Electronic Services Librarian
Marin County Free Library 

-----Original Message-----
From: web4lib-bounceswebjunction.org
[mailto:web4lib-bounceswebjunction.org] On Behalf Of Colleen
Robledo
Sent: Monday, July 14, 2008 1:14 PM
To: Tim Spalding
Cc: web4libwebjunction.org
Subject: Re: [Web4lib] Re: Web Languages


I agree that Java is still the choice language for large
enterprise
applications, and fortunately, the Java community has paid
attention
to the need for more agile flexible frameworks like RoR and
Django/Python, with the still relatively new Grails
framework.  Grails
allows for heavy OO Java integration, but also allows for
the rapid
deployment of RoR and Django.

So, watch for Grails job listings too in your unofficial
status.

Colleen Robledo, MLIS
Web Developer (PHP/RoR/Grails)

On Mon, Jul 14, 2008 at 12:55 PM, Tim Spalding <timlibrarything.com>
wrote:
> The Craigslist data is interesting. Someone with time
on their hands
> should do it for various different markets. I suspect
SF leads the
> nation, with Cambridge, MA close behind, and that
Craigslist Maine is
> asking for Integer Basic programmers.
>
> On Mon, Jul 14, 2008 at 3:45 PM, Cloutman, David
> <DCloutmanco.marin.ca.us> wrote:
>> Tim,
>>
>> You may be right in the long run, if Ruby follows
the evolutionary
path
>> of PHP, though I think PHP will adapt, with better
frameworks
emerging
>> (like Symfony) and native Unicode support in PHP 6.
As far as Java
goes,
>> I think it is the COBOL of the future. If you know
if, you'll
probably
>> be able to find a legacy application to support for
the rest of your
>> life. And for many things, I still think it is a
choice development
>> language. For heavy duty OO programming, I really
think a strongly
typed
>> language works better, and for that reason I do not
see Ruby or
Python
>> being Java killers.
>>
>> I would not totally discount your book sales data.
It certainly
>> indicates the level of interest in learning a
technology. However, I
>> don't think it is necessarily indicates traction
for any particular
>> technology.
>>
>> My own unscientific metric for languages is
searching the Craigslist
job
>> listing for the SF Bay Area. (This includes silicon
valley.) For my
>> purposes, I look at "internet engineering
jobs" and "web design
jobs".
>> Here are today's numbers by keyword.
>>
>>                             PHP    Java   Ruby  
Python PERL
>> internet engineering jobs    110    71     22    
19     109
>> web design jobs              167    246    85    
98     31
>>
>>
>> It will be interesting to see how these numbers
shift when the first
ROR
>> apps reach legacy status, as is currently happening
with PHP and
>> happened a few years back to PERL.
>>
>> - David
>>
>> ---
>> David Cloutman <dcloutmanco.marin.ca.us>
>> Electronic Services Librarian
>> Marin County Free Library
>>
>> -----Original Message-----
>> From: web4lib-bounceswebjunction.org
>> [mailto:web4lib-bounceswebjunction.org] On Behalf
Of Tim Spalding
>> Sent: Saturday, July 12, 2008 7:40 PM
>> To: Dan Scott
>> Cc: Marcie Pierson; Thomas Dowling; web4libwebjunction.org
>> Subject: Re: [Web4lib] RE: Open source support
models
>>
>>
>> Incidentally, lest you think I'm being a language
snob or bending the
>> evidence to my own ends, I was a Perl hacker once
and I program in
>> PHP. I do not know Ruby-or Python for that matter.
But I've tried to
>> hire smart, young programmers-for Perl when I was
at Houghton Mifflin
>> and for PHP at LibraryThing. The top talent out
there now has mostly
>> gravitated to Ruby and Python. I *hate* that, but
it is a fact.
>>
>> These is not some sort of bull feeling of mine, but
are exhaustively
>> documented every year by Tim O'Reilly in his yearly
book-industry
>> analyses. PHP, Java and C/C++ have shrunk five
years running. Ruby
>> came out of nowhere and is now quite
significant--particularly as
Ruby
>> programmers seem to be less book-oriented than some
others.
>>
>>
http://radar.oreilly.com/2008/03/state-of
-the-computer-book-mar-23.html
>>
>> Tim
>>
>> On Sat, Jul 12, 2008 at 10:26 PM, Tim Spalding
<timlibrarything.com>
>> wrote:
>>> Thanks for the correction on Evergreen.
>>>
>>> I wouldn't say I needed correcting on VuFind,
though. Saying that
>>> VuFind isn't mostly PHP because there are
chunks of shell scripting
>>> and HTML is like saying that a car isn't made
out of steel and glass
>>> because it also has leather seats and pockets
of air. Much the same
is
>>> true of SQL and, depending on what you're doing
with it, JavaScript.
>>> And if you're going to count lines HTML against
lines of code, you
>>> should also factor in all the GIF and JPEG
images, not to mention
>>> Cascading Style Sheets. This way lies madness.
>>>
>>> Tim
>>>
>>>> Ha! Fact-checking is readily available for
a few of these projects
at
>>>> http://www.ohloh.net/projects/evergreen/analyses/latest (for
>>>> Evergreen) and h
ttp://www.ohloh.net/projects/10977/analyses/latest
>>>> (for VUFind).
>>>>
>>>> So a correction: the business logic of
Evergreen is written
primarily
>>>> in Perl and SQL, with a few optimized
sections rewritten in C. The
>>>> current catalogue interface is primarily
JavaScript with XHTML, and
>>>> the staff client user interface is written
in Mozilla XUL (XML +
>>>> JavaScript). The user interface for most
new staff client
>>>> functionality is being built with the Dojo
JavaScript framework.
>>>> Python is used for the internationalization
build infrastructure
and
>>>> for the new EDI piece.
>>>>
>>>> The choice of language in the project
largely comes down to using
the
>>>> most appropriate tool for the job. That's
one of the advantages you
>>>> get from building an application using a
service-oriented
>>>> architecture.
>>>>
>>>> --
>>>> Dan Scott
>>>> Laurentian University
>>>>
>>>
>>>
>>>
>>> --
>>> Check out my library at
>> http:
//www.librarything.com/profile/timspalding
>>>
>>
>>
>>
>> --
>> Check out my library at
http:
//www.librarything.com/profile/timspalding
>>
>>
>> _______________________________________________
>> Web4lib mailing list
>> Web4libwebjunction.org
>> http://lists.we
bjunction.org/web4lib/
>>
>>
>> Email Disclaimer:
http://www.co.marin.ca.us/nav/misc/EmailDisclaimer.cfm

>>
>>
>
>
>
> --
> Check out my library at
http:
//www.librarything.com/profile/timspalding
>
>
> _______________________________________________
> Web4lib mailing list
> Web4libwebjunction.org
> http://lists.we
bjunction.org/web4lib/
>
>



-- 
Colleen Robledo
http://www.colleenroble
do.net


_______________________________________________
Web4lib mailing list
Web4libwebjunction.org
http://lists.we
bjunction.org/web4lib/



_______________________________________________
Web4lib mailing list
Web4libwebjunction.org
http://lists.we
bjunction.org/web4lib/