Ratings and Reviews
Community Rating
Average Rating: 4.8/5.0Number of Ratings: 42Number of Reviews: 2
My Review of Erlang |
||
| You have not rated or reviewed this project.Click below to rate/review. | My Rating: | |
| New Review | ||
Most Helpful Reviews
Although Erlang has existed for more than 20 years it was new to me in 2007. I investigated at the repeated insistence of a trusted friend. Coming from a nearly entirely OOP background I found the Actor Model style of programming foreign yet very compelling.
Erlang enables a style of programming where you build a network of Communicating Sequential Processes. The State Pattern is relatively difficult to write properly and not obvious on first inspection of code in Java yet it is trivial to write and read State Pattern code in Erlang. Every process is a state machine and the messages are used to change the state. This is much closer to the hardware design approach of Mealy/Moore machines I studied in my Digital Logic courses.
I find designing a program or application in Erlang incredibly straight-forward. A big part of this is due to the fact that the Actor Model encourages remarkably clean modular boundaries. Another part is the fact that Erlang supports Pattern Matching. Pattern Matching on first inspection seems like glorified IF statements, but it is much more than that. The ability to author a function in multiple clauses based on what the function is called with fundamentally improves the speed of authoring and resultant comprehensibility of my code
In Erlang, if the last statement evaluated in a function is a call to another function the program continues sequentially to the called function. In Java a recursive stack call would be required and the system would eventually run out of stack space. In Erlang there is no actual stack recursion occurring. This fact allows you to model the state of a process as the function it is executing combined with the arguments to that function. This is remarkably simpler to understand in code and makes many Anti-Patterns like God Objects that plague developers in OOP languages obvious, painful, ugly and easy to avoid.
Erlang enables a discontinuous innovation in developer productivity by allowing the replacement of the fundamentally flawed and misdirected mess that is OOP with the Actor Model. How well are traditional Java applications going to work on 100-core processors?...
A language with decent concurrency that is becoming popular. Other than Limbo, there are few alternatives out there.
Good to see that people are slowly realizing how hopeless the pthreads-like concurrency model is. Go Erlang!
Most Recent Reviews
A language with decent concurrency that is becoming popular. Other than Limbo, there are few alternatives out there.
Good to see that people are slowly realizing how hopeless the pthreads-like concurrency model is. Go Erlang!
Although Erlang has existed for more than 20 years it was new to me in 2007. I investigated at the repeated insistence of a trusted friend. Coming from a nearly entirely OOP background I found the Actor Model style of programming foreign yet very compelling.
Erlang enables a style of programming where you build a network of Communicating Sequential Processes. The State Pattern is relatively difficult to write properly and not obvious on first inspection of code in Java yet it is trivial to write and read State Pattern code in Erlang. Every process is a state machine and the messages are used to change the state. This is much closer to the hardware design approach of Mealy/Moore machines I studied in my Digital Logic courses.
I find designing a program or application in Erlang incredibly straight-forward. A big part of this is due to the fact that the Actor Model encourages remarkably clean modular boundaries. Another part is the fact that Erlang supports Pattern Matching. Pattern Matching on first inspection seems like glorified IF statements, but it is much more than that. The ability to author a function in multiple clauses based on what the function is called with fundamentally improves the speed of authoring and resultant comprehensibility of my code
In Erlang, if the last statement evaluated in a function is a call to another function the program continues sequentially to the called function. In Java a recursive stack call would be required and the system would eventually run out of stack space. In Erlang there is no actual stack recursion occurring. This fact allows you to model the state of a process as the function it is executing combined with the arguments to that function. This is remarkably simpler to understand in code and makes many Anti-Patterns like God Objects that plague developers in OOP languages obvious, painful, ugly and easy to avoid.
Erlang enables a discontinuous innovation in developer productivity by allowing the replacement of the fundamentally flawed and misdirected mess that is OOP with the Actor Model. How well are traditional Java applications going to work on 100-core processors?...