[erlang-questions] "Erlang, the next Java"

[Zac Brown]

Well I suppose thats true in ways though to me when different functions
are written functionally you're drastically narrowing down where your
bugs are and more often than not you can just take a moment to think
about the code and rationalize where your bottleneck in your message
passing is but I do see your point no less.

Zac


Nohl Attila Rajmund wrote:
> On Fri, 10 Aug 2007, Zac Brown wrote:
> [...]
>> My only other qualm with that article is (at least to me) the author
>> seemed to belittle the functional aspect of Erlang. I think thats
>> somewhat of a naive look at the language seeing as the functional aspect
>> is what helps make Erlang reliable. All the minimizing of most of the
>> side effects is an important trait in Erlang due to its functional
>> nature. I can see his point but I still think he counted that aspect of
>> the language a little too trivially.
> 
> I'm not sure he's wrong. The "no side effect" slogans of functional
> languages sound great, but as soon as you put a ! into your function,
> you've got a side effect - and you do it pretty soon, because the strong
> point of Erlang is the concurrency, so you have a good number of
> processes (even if it's hidden in OTP). So - in my experience - the
> functional nature is a drawback of the language, it leads to clumsy code
> like this:
> 
> HR1=HugeRecord#hugeRecord{someField=NewValue},
> ...
> HR2=HR1#hugeRecord{someOtherField=OtherValue},
> ...
> HR3=HR2#hugeRecord{someReallyOtherField=ReallyOtherValue},
> 
> In one function I saw HR7 (some earlier HR* were deleted). It could lead
> to really hard to catch bugs if someone uses HR1 even after HR2 was
> updated.
>                 Bye,NAR
>