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

[Max Bourinov]

Guys, you know in Russia, in circus people use to teach real bears to drive
bikes...

The same with Java and multithreading... It is possible... The question is
what for is there is cool Erlang! in here :-)

I wish great weekend for everybody :-)


On Fri, Nov 11, 2011 at 5:55 PM, Tim Watson <watson.timothy@REDACTED>wrote:

> 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/7f7c6cb7/attachment.htm>