[erlang-questions] Where's Dijkstra when we need him?

[Tim Watson]

On 11 November 2011 05:28, Max Bourinov <bourinov@REDACTED> wrote:

> As a former java programmer i confirm that i became 180% happier when
> i started to write code in Erlang.
>
>
At work I still write code in Java, as well as Erlang and a few others. I
have the same experience, that when programming in Erlang I enjoy coding a
lot more and tend to spend more time and energy focussed on getting the
architecture right and representing/understanding the domain properly. I am
a productive java developer, but it takes a lot more effort and the tooling
is a prerequisite to getting that level of productivity, rather than a
choice - in Erlang I *can* choose to use ErlIDE, but vi/emacs will do fine
as well. The same isn't true for building large java applications.


> All those fansy things like spring, orm, hibernate, jmx, and many
> other strange words are absolutelly useles when it comes time to build
> a system that "never" fails - memory leaks and unexpected gc ruins all
> java advantages, moreover i love parallel programs which is almost
> impossible wrire in java.
>
>
Most server side java programs are "parallel" though right? Anything you
deploy in a web container (like Tomcat) is running in a multithreaded
environment, and despite the difficulties in writing correct multithreaded
programs in an imperative language, it is possible to do it. It's just a
lot more work for the programmer. Don't forget you can create deadlocks and
race conditions in your Erlang code to, unless you think carefully about
the design. It's just that these situations come up less often, usually
*only* when you've got side effects or global/shared state. By contrast, in
java/c++/etc you have side effects and shared state *all* the time (with
every line of code), which is why they're harder work to get right.

So let's try and be very clear - in Erlang it is easier to write correct
parallel programs.

I'm under the impression that memory leaks can occur in *any* language that
allows dynamic allocation. Java and Erlang both have a VM that does so and
incorrect programs can cause this to grow uncontrollably causing the VM to
run out of memory. I've seen *plenty* of threads on this list talking about
beam "out of memory" problems. And for the record, there is no *perfect* GC
that I'm aware of, all of them make trade offs for various reasons.


> 11.11.2011, в 9:06, Matti Oinas <matti.oinas@REDACTED> написал(а):
>
> > People have taken too literally the phrase don't reinvent/reimplement
> > the wheel. They will use the wheel even if it is wrong size and is
> > triangle shaped instead of a circle.
> >
>

Yes this is particularly prevalent in the java/.net world and is often the
source of the bloat-ware that Mr O'Keefe witnessed first hand. Having said
that, there are some things in the java world that are actually better, not
least of which is having some degree of standards around commonly used
APIs. Java developers have one official API for database access, logging,
instrumentation and monitoring (JMX that was mentioned earlier) and so on.
It is, quite frankly, a pain in the backside having to keep rewriting your
code when you decide to move from log4erl to lager, or from postgres to
mysql - and god forbid that you have to support multiple databases or APIs,
because then the pain is really on. We *should* try to fix this IMO.

Also if you're building a product to sell, then your consumers *probably*
want to have some level of control over things like logging levels, rolling
log files and so on. O&M teams DO NOT want to have to learn 10 million
different ways of doing this for every application, and it is there that
java applications have an advantage because they pretty much *all* use the
same configuration(s). This is also true for profiling and monitoring
(i.e., everyone just uses JMX, whether the application is doing anything
special or not), though hopefully the super-cool dtrace support for Erlang
will eventually standardise that bit for us.

Standardisation can be a good thing and the consistency and standardisation
of APIs in java actually drives *down* cost and complexity, which is why so
much of the world is still using it, despite the terrible bloat that often
comes with it. It is a nod to just how incredible Erlang/OTP is that Erlang
programs are still easier (and more fun) to build.


> > --
> > /*******************************************************************/
> >
> > try {
> >    log.trace("Id=" + request.getUser().getId() + " accesses " +
> > manager.getPage().getUrl().toString())
> > } catch(NullPointerException e) {}
> >
> > /*******************************************************************/
> >
> > This is a real code, but please make the world a bit better place and
> > don’t do it, ever.
> >
>
>
Yes well that is just bad code, as you say. I've written some *terrible*
Erlang code especially when I was first learning. Abusing the process
dictionary, doing far too much local error handling and defensive coding,
etc. The secret here is to mentor and educate developers to encourage them
to adopt good behaviours.

One of my favorite Dijkstra quotes, describes why I think that Erlang is
better, but also perhaps why java is still far more successful: "Simplicity
is a great virtue but it requires hard work to achieve it and education to
appreciate it. And to make matters worse: complexity sells better".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20111111/ae9f9baf/attachment.htm>