[ale] {OT} -- For the programmer on the list

[JD]

On 01/12/2012 03:36 PM, Steve Brown wrote:
> As a Java developer by day (server side, not client side applications), I would
> love to join in or counter your complaints, but they are too abstract for me to
> understand what it is that you're complaining about. My main problem with Java
> is its future in Oracle's hands. Another problem would be the slow pace of
> language improvements. That problem is somewhat minimized by groovy in the short
> term. In the long term, as always, I'm exploring other languages. Are there
> languages that address the problems you have with java, but that also fill the
> same niche of large-team development? More precisely, languages that inhibit a
> team members ability to do something "clever"/unexpected and allows them to
> focus on the business requirements? I've always enjoyed python for that reason;
> "there should be one, and preferably only one, obvious way to do it". However, I
> don't really like python's lack of static typing for non-trivial,
> multi-developer, projects. Not exactly an insurmountable problem, I know, just a
> personal preference.
> -Steve Brown
> 
> 

Clearly, everything should be written in R. There is no need for any other
language whatsoever.

Check out RosettaCode to see how experts in each language solve the same problem
with the different languages.
See: http://rosettacode.org/wiki/99_Bottles_of_Beer#R


On a serious note, I love the language Java, but pretty much hate all the
implementations. I remember when Sun came to our lab around 1994-ish showing off
this cross-platform language with write-once, run anywhere capabilities. We were
writing cross-platform C/C++ for about 10 different platforms using some
expensive tools (anyone remember Visix Galaxy or XVT). Most of that team
switched to writing Java around 2000. I did not. I'm not an expert at Java, but
my impressions are:
* Eats RAM (much more that a C++ program would use)
* Slow during runtime (old link http://sprout.stanford.edu/uli/java_cpp.html )
* Garbage collection runs at the wrong time
* Extremely slow desktop program startup
* Ugly GUI controls - opinion
* Eclipse requires 16GB and a Core i7 to be usable; it is slow on a Core i5.
* Java devs actually believe they don't need to understand the platform they are
running on. I have stories of developers claiming that rewriting a C app running
on Intel CPUs in Java running on a SPARC CPU would result in greater
performance. Complete BS, except that their C app was total crap to start.

To me, the best place for Java is on the server-side. It makes wonderful sense
there and allows the back-end OS to be swapped out easier. That helped Sun, HP,
IBM *nix servers become more competitive when larger scale are required.

I completely disagree with the desire for one and only one way to accomplish
something - I recognize the great things about strict frameworks just to the
point where they don't let you do something necessary (RAILS is famous for
this).  Only-one-way works for neophyte programmers, not for experts, IMHO.  I
like Python and Ruby as languages too.

I don't really understand your comment about large project teams and complexity.
Interface documents have been around for years. I've worked on projects with
250+ devs.  We used interface documents and exchanged header files early. For
smaller projects, we'd write code stubs to validate acceptable inputs as the
first coding step.

Ada was designed to help large scale government coding projects become more
efficient. http://rosettacode.org/wiki/99_Bottles_of_Beer#Ada  I don't know
whether it achieved that goal or not. It certainly never became commercially
popular.

I didn't mean to display so much of my ignorance all at once. Oh well.