[erlang-questions] Breaking out of a foldl

[Attila Rajmund Nohl]

2009/6/1, Joe Armstrong <erlang@REDACTED>:
> On Sat, May 30, 2009 at 6:19 PM, Mazen Harake
> <mazen.harake@REDACTED> wrote:
>> Because it is a hack?
>>
>> a "fold_until" would be much smoother.
>
> Uuugh - smoothness?????????????
>
> Why have two functions when one (the existing foldl) is perfectly adequate?
>
> The use of throw to abnormally terminate a recursion is not a hack.
> That is what
> catch-throw was designed to do. exit/1 is for raising errors, throw/1 is for
> abrupt termination of a computation.

Yeah, but it's syntax is somewhat misleading. People with
Java/C++/Eiffel/etc. background would expect that exceptions should be
used in exceptional situation, not instead of a return statement
(which Erlang lacks).

[...]
> Wirth (the blessed) said something like (paraphrased) every time we
> add something
> to a language we should ask *what can we remove*. If we just add stuff
> to languages
> (or libraries) - without removing stuff, we add additional complexity
> so we violate
> the principle of being as simple as possible.
>
> I am often horrified by libraries that offer dozens of different ways
> to do essentially the
> same thing - this makes the documentation almost unreadable (since it is
> unclear
> which the kernel methods are) and makes learning very difficult.
>
> Libraries should provide a small set of primitive parts which can be
> glued together
> to solve a large number of problems. If the set of parts is large then
> learning the library will be very difficult. If you don't know all the
> functions in a library then
> programming using the library will be painfully slow since you will
> have to google
> your way through large volumes of documentation.
>
> If you really really want fold_until then I suggest you make your own
> personal library
> (mylib.erl) where you put fold_until (and every other additional
> function that you think
> is missing from the standard libraries) - then one day when you are
> satisfied that
> your library has proved useful you can publish it.
>
> Exactly what should be in the standard libraries is an extremely
> difficult problem-
> I think they should contain small sets of orthogonal functions and err
> on the side
> of generality. If two function do more of less the same thing one of
> them should be removed.

I disagree. Every Erlang project I've seen had it's own tracing module
built on top of dbg. They all had very similar functions that did
nearly the same thing. This obviously means that the dbg module needs
a function that simply turns on tracing on a function of a module.
Yes, it could be done with dbg:tpl, but why shall I type every time
[{'_',[],[{return_trace}]}] into the shell? Also the equivalent of
lists:keyfind was probably implemented countless times in most Erlang
projects.

I do think it's better to have often needed code in the standard
library. First of all, it's standard, so every programmer should be
familiar with it. On the other hand the "helper" functions in the
various mylib libraries are probably not well known to anyone except
the author. The above mentioned tracing modules had functions doing
essentially the same, but each with a slightly different syntax which
is quite annoying.

Using third party libraries (e.g. someone's released mylib) has other
drawbacks. It might not be useable at all due to licensing. It's an
other dependency that has to be followed (e.g. when a bugfix release
comes out). It might not be maintained anymore. It doesn't have the
same user base as the standard library, so it might have more bugs.
>From the management point of view it's better to work with the
standard library and in-house code, without 3rd party libraries.

I think that the standard library should first and foremost make
programming easier. For example, the JTable class in Java has 7
constructors. A couple of them probably could be removed to get a more
minimal code - but the removed code will popup in the applications
many more times and probably with many more bugs.