davearonson
Forseth
Nothing is perfect unless its perfect for the job ahead
@Qqwy has the best analogy I have ever heard on the subject.
patterns aren`t generally bad. they are pointers to how to get a specific thing done. if something doesnt smell right using a pattern then no problem. We are programmers we of all people should be able to think for our selves as problem solving is 90% of our work.
There is **** that needs to be done and there are a number of ways to shovel it. Don`t be a tool and use the hammer ! And a shovel is good enough for small projects
ps : I am not saying the hammer is bad its awesome for dealing with nails in wooden planks, Im just saying Id prefer a shovel.
3
mmport80
Thanks for the enlightenment guys - lots of nice nuggets.
I reckon there’s a lot of scope for Elixir to use macros to simplify concepts or perhaps more importantly use them to enforce things that could otherwise trip people up.
There are quite a few Erlang OTP books on my bookshelf. Distributed computing is tough - but isn’t Elixir in the game of bringing OTP goodness to the masses? : )
I think diving into Lisp macros more and perhaps experimenting with those ideas in Elixir could be fruitful…
0
LSylvester
This strongly reminds me of philosophy (because it is. Really!). It’s common for someone to say “I had a thought about the way the Universe works, but then found out someone else already had that theory”. I’ve done it. Surely, everyone has? With patterns and programming, someone with little skill may tackle a problem that they see with an idea that turns out to be a pattern. They might not know this at the time, but there it is. Then, at the other end of the scale, we have the philosopher, who is well read and educated in theories. The pattern expert, who knows many patterns theorised by many computer scientists.
The point is, a pattern is just an idea that someone noted on paper for solving a given task. The philosophical theory that suggests a reality. Fact is, other people have probably had the same idea prior and further people will have the same idea without realising it was already a known thing. However, it fits the requirement and it allows the process to continue, so it is used.
Ultimately, we should not wonder whether patterns are good or bad; only, do they solve the problem at hand? If we know the pattern before hand or we devise the pattern for a new problem, it makes little difference, since any solution to any problem can be identified as a pattern, and is guaranteed that status if we tackle a future yet similar problem with the same approach.
2
hubertlepicki
I don’t know if Joe Armstrong doesn’t use OTP or not. But his focus is most likely different than yours. He’s interested in language development and providing useful primitives to build stuff like OTP. You are, most likely, interested in building applications that use appropriate abstractions.
I remember back in the day, when I worked in early Rails or PHP projects, I inherited a e-commerce solution from other programmer. I was chosen because I speak Polish, and code comments were in Polish. What no one told me, was that the programmer did write whole e-commerce store in single PHP file, with no database (but files as storage) and there was no single function or object definition inside. It was large if-clause, wrapped in case, wrapped in if, and then used bunch of goto labels to redirect the flow.
I met the guy at some point, told him that his code is crazy and we needed to write it from scratch, because no one could get their heads around his “solution”. Why would you do something like that? - I asked. “It’s because I am really assembly programmer, and that’s what I do best, and I don’t really believe functions, objects or database have any significant value for me”.
So here you go. If you want to write code that will make you proud, take the bare bones and build your own abstractions on top of that, that suit your taste. If you want your code to be understood by other programmers - use the patterns and libraries that they are familiar with.
6
bibekp
Just to reiterate from above, as there are a lot of posts → use exactor.
If you look at Sasa’s code you will notice a lot of macros just like “Lisp-world”.
If you are new to OTP and the syntax and conventions are a bit overwhelming this can really clean things up. If you have used OTP enough, you may just dismiss this lib as OTP may then at that point feel simple to you.
Language / framework designers always have to decide on how to balance the needs of people starting out and people that are very well experienced. Some of Sasa’s libraries fills some gaps. The Core team is actively working on parts of this..
For example look at the proposal around Experimental.DynamicSupervisor
We have a couple goals by introducing a dynamic supervisor:
- Simplify the API and usage of both Supervisor modules. Most of the documentation in the Supervisor module is full of conditionals: "if the supervisor type is :simple_one_for_one, it will behave as X, otheriwse as Y." The differences in behaviour with little surrounding context makes supervisors hard to learn, understand and use;
- Provide out-of-the-box supervisor sharding for cases where the supervisor itself may be a scalability concern;
- Provide a built-in registry to avoid developers unecessarily using dependencies like gproc or incorrect dependencies like global;
- Implement the GenStage specification so dynamic supervisors can subscribe to producers and spawn children dynamically based on demand;
While you are at it, take a look at the fsm library as well. Gave me a great option when I did not want to use gen_fsm but instead being able to use an FSM w/o having to create a process. Apparently there is a new module gen_statem as well.
Also con_cache is cool to though I haven’t had a chance to play with it.
Part of learning Elixir is learning the functional programming building blocks, map, reduce, filter, take, head, tail, and if you really want to “learn Elixir” to do fault-tolerant, distributed work learning the OTP building blocks and the new Elixir Experimental backend libs 
So yes indeed, OTP is waay baad a***
2
JamboJustin
I know most people on this forum are fairly nuanced towards OO programming, but I submit that encapsulation in the sense of combining data and methods was flat out a terrible design decision. Ironically, it created brittle and tightly coupled code. As experienced OO programmers repeatedly banged their head against the consequences of this, they created the famous Design Patterns for minimizing the harm of encapsulation: inversion of control, dependency injection, fascades etc., Most books on OO programming style seem geared towards getting this water back in the dam.
Design Patterns became the touchstone of good programming. “Oh you’re a programmer? Have you read Design Patterns?” But as functional programming grew more popular and the limitations of OO programming became more apparent, that started to reverse. Functional programmers began to sneer at patterns as lipstick on a pig. Now patterns are bad. See also: the lisp quote referenced at the start of the thread.
It’s ironic because SICP, which is how most LISP programmers learned their trade, is all about patterns. It’s most the pattern-centric book on programming I’ve ever seen. And if you are going to create objects, then GoF patterns are also really good. OO + GoF >> OO. Patterns are good.
3
DianaOlympos
Exactly that. Interestingly, it is not what encapsulation was meant to mean. Thank you, you enabled me to finally find a way to wirte my rant on RPC vs Message Passing in a way that make sense !
1
davearonson
Patterns are good.
Yes… where needed. Not as a checklist (“oops, forgot to use Abstract Factory, now where can I shoehorn that in?”), not where inappropriate (“hey, let’s make each instance of this class its own Singleton!”), etc… but mainly to make up for deficiencies in the language. Hence the confusion of, for instance, Java programmers migrating to Ruby:
- “So how do you do Dependency Injection?”
- “You just… inject your dependencies.”
- “Uh, right, but, ummm… what frameworks do you use for that?”
- “Why would we need a framework to do something so trivial?”
Or from any typical OO language to any typical FP language… finding so many of their classical patterns Just Don’t Apply.
1
citizen428
Which IMHO led to a form of “not invented here syndrome”, with lots of different macros for various use cases, many of which only cover the author’s specific need and not the more general case.
0