Re: Meeting agenda robot

----- "Bruce Perens" <bruce(at)perens(dot)com> wrote:

> http://antoniocangiano.com/2007/12/03/the-great-ruby-shootout/

It depends on what you are doing. One thing is certain, the JavaVM can run Ruby code competitively and YARV cannot do the reverse.

> The main reason I'd not tremendously recommend building new projects in
> Java is efficient utilization of the programmer, and of the subsequent
> programmers who will have to maintain the project. Performance will not
> be the critical factor for this project.
>
> For best readability by subsequent maintainers, either Python or Ruby
> should be recommended. The disciplined can write elegant software in any
> language, but some languages are better at guiding the programmer to do
> so than others.

Here, your argument falls flat. My whole point is that the Java VM can execute Ruby code, so you can code in Ruby (or Haskell for that matter) if that suits your fancy. What you cannot do in a Ruby environment is invoke Ruby methods (or Java or Haskell or whatever) from PHP code... which you can do in Java via Quercus. The sheer scale of the Java based toolsets is the point. Neither Ruby nor Python has something that is vaguely a challenger to Eclipse. Its closest competitor is NetBeans, which is still written in Java.

Real time memory profiling, multi-processor clustering (terracotta), caching, message queues and a whole host of other technologies are all quite mature on the Java VM while they are in the infancy or don't exist at all for Python and Ruby.

I have solved many commercial contracts using the Java system and I frankly find it frustrating to have offers of assistance shot down because of ill-informed language bigotry. A short list of systems we've recently built out:

http://everestresearchinstitute.com
http://checkmark.heart.org
http://listingpr.com
http://radiusdp.com

There are others (some of a more significant scale) that I cannot discuss for contractual reasons. I would be curious to see some examples from those of you who are working in Ruby and Python.

--
Ean Schuessler, CTO Brainfood.com
ean(at)brainfood(dot)com - http://www.brainfood.com - 214-720-0700 x 315

On Wed, 2008-12-24 at 14:30 -0600, Ean Schuessler wrote:
> ----- "Bruce Perens" <bruce(at)perens(dot)com> wrote:

> I have solved many commercial contracts using the Java system and I frankly find it frustrating to have offers of assistance shot down because of ill-informed language bigotry. A short list of systems we've recently built out:
>
> http://everestresearchinstitute.com
> http://checkmark.heart.org
> http://listingpr.com
> http://radiusdp.com

> There are others (some of a more significant scale) that I cannot discuss for contractual reasons. I would be curious to see some examples from those of you who are working in Ruby and Python.
>

{Python}

Google?
Various contracts I can't talk about including video editing
Civilization 4?
Visio?
Pretty much *all* of Redhat's and Ubuntus toolset
DR Project
Trac
Washington Post
PITRTools
US Congress Votes Database
Train Check

Joshua D. Drake

P.S. I hate RoR so don't ask.

--
PostgreSQL
Consulting, Development, Support, Training
503-667-4564 - http://www.commandprompt.com/
The PostgreSQL Company, serving since 1997

Ean Schuessler wrote:
> The sheer scale of the Java based toolsets is the point.
Uh-huh. You could start reading about the Java Toolset today, and still
not have learned the whole thing twenty years from now. Certainly when
writing any of my own code, I will not have the capability to run PHP,
Java, and Ruby in the same environment. I will not even have the More
Than One Way To Do It offered by perl. And somehow the work will get
done, reasonably quickly, and in an environment that I have a reasonable
chance of understanding in my useful lifetime.

Lucasfilm's operation is very strongly Python based.

Bruce

Joshua D. Drake wrote:
> {Python}
>
> Google?
> Various contracts I can't talk about including video editing
> Civilization 4?
> Visio?
> Pretty much *all* of Redhat's and Ubuntus toolset
> DR Project
> Trac
> Washington Post
> PITRTools
> US Congress Votes Database
> Train Check
>
> Joshua D. Drake
>
>
> P.S. I hate RoR so don't ask.
>
>
>

Previously Ean Schuessler wrote:
> Real time memory profiling, multi-processor clustering (terracotta),
> caching, message queues and a whole host of other technologies are all
> quite mature on the Java VM while they are in the infancy or don't
> exist at all for Python and Ruby.

I wonder why that is relevant to the SPI website though. Did the SPI
website suddenly start doing more than a few dozen hits per day?

Wichert.

--
Wichert Akkerman <wichert(at)wiggy(dot)net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.

Previously Joshua D. Drake wrote:
> {Python}
>
> Google?

youtube at least

W.

--
Wichert Akkerman <wichert(at)wiggy(dot)net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.

My experience in volunteer projects is to informally poll the
potential developers for the implementation language and/or platform
and select the one with the most widespread willingness to use/learn
it. Very few volunteer projects end up having performance issues, and
if that happens, you're probably best off rewriting the whole thing,
anyway, so making a lanugage/platform switch is a very minor issue at
that point.

If you select the current hot silver bullet / current best stable
performance platform and end up with nobody (or very few) people
willing to develop on it, the choice is obviously wrong. Of course,
you want to enforce coding conventions to keep the code base clean and
legible, and I don't think any of the potential languages here (yes,
including Perl) are inherently illegible.

--
* Sufficiently advanced magic is indistinguishable from technology (T.P) *
* PGP public key available @ http://www.iki.fi/killer *

On Thu, Dec 25, 2008 at 01:38:21PM +0200, Kalle Kivimaa wrote:
> My experience in volunteer projects is to informally poll the
> potential developers for the implementation language and/or platform
> and select the one with the most widespread willingness to use/learn
> it.

This is the key point, I think. For example, there are a very large
number of Java programmers out there in the world, yes, but in my
experience a *much* smaller percentage of them are willing to
volunteer on open source programs. Java has become the "Cobol" of
computer languages --- which is not meant as a slight on the language,
but to characterize the sort of programmers that make up a very large
percentage the programming community. They are business/application
programmers, that program on a 9-5 basis, and when they are done, they
go home and they coach Little League or sit in front of a television
and veg.... they don't (as a *very* broad generalization) volunteer on
open source projects, at least not to the same extent that you will
see in the C, Perl, and Python worlds.

The other problem I see is that many Java programmers are, quite
frankly, not very good at writing programs (performant or long-term
maintainable, in my experience). And before you say that "performance
doesn't matter", I have had the misfortune to be forced to use a
proprietary mail program written in Java where it takes a full second
to delete a message, and then display the next message in the mail
folder --- on the fastest, most modern laptop I could find (and this
was *after* I stuffed it to the gills with 4GB of memory; the
performance before I did that doesn't bear thinking about.) Think
about that for a second; and think how much of disastrous usability
matter that would be. How could such a horrible performance/usability
disaster come to pass?

Because of the Java class libraries; there must be easily a dozen
levels of abstractions in the Java class libraries itself, plus
another dozen or so levels of abstractions in either J2EE or Eclipse
stack; and then if you use the Rich Client Platform (RCP) on top of
Eclipse, there's another half-dozen abstractions right there; and
that's before you get to doing anything in the application! There are
*so* many levels of abstractions between the Java application
programmer and the bare metal, that if you say words to them such as
"blowing your I-cache" or "cache line", most of them will stare
blankly at you, with a deer-in-the-headlights-look and no idea what
you are talking about. Given their language of choice, they had no
possible hope of being able to control that sort of issue, so it
ceased to exist for them.

So the critical matter is not the richness of the toolset, or the
number of programmers, or the average performance of the language ---
if you can find a talented Java programmer, who understands
performance issues and who isn't afraid to dive into the dozens of
layers of Eclipse or Java class libraries to understand why some
application class has become O(n**4) --- or heck, understands what the
big-O notation means in the first place (you can write fast,
performant code in any language, just as you can write Fortran in any
language). No, the key is which language you are most likely to find
a large pool of good, talented programmers who are willing to
volunteer for your project; not just now, but also 10-15 years from
now.

I'd suggest that the only programming languages likely to meet that
test are C, Perl, and Python, but what's important is the criteria and
understanding why that's important.

- Ted

----- "Theodore Tso" wrote:

> So the critical matter is not the richness of the toolset, or the
> number of programmers, or the average performance of the language ---
> if you can find a talented Java programmer, who understands
> performance issues and who isn't afraid to dive into the dozens of
> layers of Eclipse or Java class libraries to understand why some
> application class has become O(n**4) --- or heck, understands what the
> big-O notation means in the first place (you can write fast,
> performant code in any language, just as you can write Fortran in any
> language). No, the key is which language you are most likely to find
> a large pool of good, talented programmers who are willing to
> volunteer for your project; not just now, but also 10-15 years from
> now.
> I'd suggest that the only programming languages likely to meet that
> test are C, Perl, and Python, but what's important is the criteria and
> understanding why that's important.

I do agree with this point. The tool doesn't provide the talent. I'll take a good team writing in a bad language over the reverse any day of the week.

I do take issue with the "richness of the toolset" statement. NIH is a crippling disease and I think leveraging a mature code base gets you more bang for the buck than reinventing the wheel almost every time.

--
Ean Schuessler, CTO Brainfood.com
ean(at)brainfood(dot)com - http://www.brainfood.com - 214-720-0700 x 315

On Thu, 2008-12-25 at 12:27 +0100, Wichert Akkerman wrote:
> Previously Joshua D. Drake wrote:
> > {Python}
> >
> > Google?
>
> youtube at least
>

Google requires it for their cloud.

> W.
>
--
PostgreSQL
Consulting, Development, Support, Training
503-667-4564 - http://www.commandprompt.com/
The PostgreSQL Company, serving since 1997