[erlang-questions] Was Re: Bug ?! now Erlang comment (LONG LONG)

[Robert Virding]

Forgot to add another major fault:

+ The difference between exits and errors (previously called faults) is 
definitely bogus and a big mistake to boot.

Originally there was no noticeable difference between exits and errors, 
doing '1+a' and exit(badarg) would give you the same thing at all 
levels. THIS WAS INTENTIONAL! For the same reason doing exit/2 had 
exactly the same effect on the other processas exiting the current 
process. If you read Joe's thesis you uses exit like this.

Then someone added stacktraces to errors. This was good thing of course, 
but now exits and errors were different. Unfortunately instead of fixing 
exit/1 this difference was cemented by adding erlang:error (before that 
erlang:fault) and separating both in try. So instead of one uniform 
mechanism now there are similar but different and incompatible ones.

This is a similar problem as with links and process monitoring.

Robert

P.S. I still don't understand how someone could break link/1. The fix to 
unlink is ok.

Robert Virding wrote:
> Thomas Lindgren wrote:
> 
>>--- Robert Virding <robert.virding@REDACTED> wrote:
>>
>>
>>
>>>I believe it is important to keep things clean,
>>>consistent and elegant 
>>>otherwise you will end up with a language built on
>>>exceptions.
>>
>>
>>So what is your opinion on Erlang of today? (half :-)
>>
>>Best,
>>Thomas
> 
> 
> I have been debating with myself whether to answer this but in the end I 
> gave in and decided that I would.
> 
> Omn the whole I think we got things right but there are some things 
> which are wrong. Some are new, some are old and some are even my fault. 
> :-) So here is a collection of comments, major and minor (major marked 
> with +):
> 
> - The naming and argument orders of the standard libraries is 
> inconsistent. While this can seem trivial it does break the principle of 
> least astonishment and therefore causes unnecessary problems.
> 
> - The syntax could have been cleaned up a bit. No, I don't see any 
> problems with having ';' as separator not a terminator. Being able to 
> write "foo(X) -> X;." sucks.
> 
> + Should have had proper variable scoping, what is right for Prolog is 
> not best for Erlang. I would also have all variables in patterns as 
> fresh variables and have explicit tests for equality with already bound 
> variables.
> 
> + The concept of what a BIF (Built In function) is is a mess. Now it 
> seems to mean something written in C. That is something we addressed in 
> the standard and got right. A BIF is a function which is part of the 
> langauge but without special syntax. So spawn and link are just as much 
> Erlang as ! and receive but they look like functions. BIFs have the same 
> dignity as the emulator, both ARE the language.
> 
> What language a BIF is written in is irrelevant.
> 
> Most BIFs can be called through the module erlang so having the module 
> erlang as part of OTP just does not make sense.
> 
> - Some of the BIF names are too long, tget and tset would have been better.
> 
> - A suggestion in the standard was to have BIFsin different modules not 
> just erlang, for example atom, tuple, number, proc, ... This would have 
> been much better and could have been added with a minimum of trouble.
> 
> + There is no layering in the standard libraries, all is part of OTP. 
> This make is difficult to build small, stand-alone application. In 
> essence you tend to get what OO was accused of: you want the banana but 
> get the whole gorilla as well. Yes, you can make a tool which extracts 
> what you want but that is a work-around not a fix.
> 
> Many of the libraries are so fundamental that having them managed by OTP 
> does not really make sense, they are below that necessary for it.
> 
> Joe and I discussed this alot and we agreed on the principle but not on 
> all the details. I would like to see something like:
> 
> ____________________________________________________________________
> 
> 		erlang emulator + BIFs (see above)
> ____________________________________________________________________
> 
> 	basic libraries - lists, file, io etc. (maybe layered as well)
> ____________________________________________________________________
> 						|
>    OTP	| included applications - compiler, etc	|
> _________________________________________________
> 
> 			user apps, OTP based or otherwise
> ____________________________________________________________________
> 
> The system is useable without OTP and applications can choose at what 
> level they need the libraries. I hope the diagram is understandable.
> 
> - Binaries are nice but I don't really like the bit syntax, although I 
> haven't really sat down and come up with a better alternative.
> 
> - Records as they stand are not beautiful. However, it is important to 
> remember that when they were introduced it was an absolute requirement 
> that they would be as fast as using tuples directly. Even this 
> implementation was suspect. I kid you not.
> 
> - Structs or dictionaries as suggested by Richard O'K would be a BIG WIN.
> 
> + All forms of communication between processes should be asynchronous. 
> Messages signals, links, ALL of them. You send them off and depending on 
> what you do you may get an exit signal back. Originally the only thing 
> which broke this principle was sending to a local registered process, 
> now, however, more things break it. Link for example.
> 
> Why worry you may ask. Well, everything which is asynchronous will 
> automatically scale to distributed systems, synchronous calls don't! 
> This may also affect multi-core implementations which are going to be 
> very important.
> 
> + Originally there were two basically different types of objects in 
> Erlang: static terms and things with dynamic state, processes.
> 
> A process is something which has process semantics, you communicate 
> through messages, can link to it and exchange exit signals. N.B. how a 
> process is implemented is irrelevant it is the external semantics which 
> define a process.
> 
> Unfortunately there two (at least) things in erlangwhich don't conform 
> to this principle, ETS tables and ports. They're coming next.
> 
> + ETS tables are neither and this causes problems. ETS was conceived to 
> solve two main problems: fast, near constant access to large tables; and 
> to get around the garbage collection problem in the erlang 
> implementation. If you have a LARGE process then it is noticeable when 
> the emulator stops during a collection. This problem still exists today.
> 
> The solution to the second problem was to keep ETS tables in a 
> completely separate area and copy data to/from processes. Unfortunately 
> this implementation detail, which it is, affected the interface and 
> instead of solving the real problem, i.e. the copying, work-arounds were 
> added to minimise this, match_XXXX, select_XXXX, ms_transforms. No one 
> can claim that match patterns and matchspecs are beautiful or fit in 
> with the rest of erlang. These are just work-arounds to minimise copying 
> and would be unnecessary if the implementations was fixed. Then you 
> could use a proper pattern to select and all you would need is fold.
> 
> Getting back ETS tables are neither static data or processes and break 
> the principle.
> 
> + Ports are funny. Originally when they were conceived they had only 
> process semantics, in fact we actually debated whether to have a 
> separate data type at all. They were modelled on UNIX streams, the idea 
> being that you could insert various filters along the way without the 
> users noticing. This is no problem with processes.
> 
> However, the the various port_XXXX commands were added and now ports are 
> different. Ironically, the manual calls the process interface illogical 
> because it is different from the function interface.
> 
> - if should really have been what cond is today. Is cond today?
> 
> - The abstract form of the erlang syntax should have been in a form 
> which could be described by records.
> 
> - and/or and andalso/orelse are different semantically and having both 
> is a win, although some people don't think so.
> 
> - catch should not have been an operator but instead catch ... end.
> 
> - Erlang does not need currying.
> 
> - Erlang was originally designed to follow the KISS principle.
> 
> + Perhaps we should have defined the message interface more often 
> instead of wrapping everything in an access function? You can do more 
> with the interface.
> 
> + You need both link and monitor_process, it would have been better to 
> have a more basic primitive on which both are built. Easier to under 
> stand the interactions.
> 
> Having everything consistent makes it easier to understand and lessens 
> the risk of strange interactions. If everything is a process and obeys 
> the (asynchronous) process semantics then it easier to understand the 
> interactions. They will all be explicit in the code (even the mistakes 
> :-)) and not so dependant on which order you do things because sometimes 
> you get a fault and sometimes a signal so if they are in the wrong order 
> then somethings won't get done.
> 
> Special cases just cause problems in the long run.
> 
> That's about it for the first go. I will willingly debate any of my 
> comments on the erlang, but don't expect me to change my mind. Being, as 
> I am, right.
> 
> Robert
> 
> "I'm not arrogant, I'm right!"
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>