Effective Elixir?
637 views
Skip to first unread message
Peter Minten
Aug 26, 2013, 9:19:23 AM8/26/13
to elixir-l...@googlegroups.com
Hi all,
Looking at our current documentation it seems to me that the type of
document that's needed most is something like Effective Go
(http://golang.org/doc/effective_go.html).
Effective Go is so effective in the Go world because it tells people how
to best write code. It's somewhat of a combination of a style guide with
a very practical guide to solving common problems. It answers questions
like "how do I handle errors?" and "how do I make the best use of
concurrency tools?".
Effective Go, more than any other document, embodies the philosophy of
the Go language. Now Go has a very well defined philosophy and very
clear rules on what's a good idea and what's not. So far I haven't
really gotten that vibe from Elixir.
The benefit of the clear philosophy of Go is that it's easy to get
started, there is a well defined way to do things. The downside is that
some people consider it to be too restrictive.
So my main question is: would it be possible to create an Effective
Elixir document? Do we have a clear vision to put in there? Or would it
become a document with lot's of "you could do this, or that, or that"
type of answers?
Maybe there's a middle ground in that Effective Elixir would be a
document that explicitly defines best practices but is clear that it's
perfectly OK to do something else completely, just make sure you know
what you're doing.
To get an idea of what kind of stuff I think would go into Effective
Elixir here's a (short) brainstorm.
* First paragraph of docs should be a descriptive line, preferably in an
active form.
* When to use |> and when not.
* Resist the urge to solve everything with a macro.
* How do use @type and @spec. Encourage people to at least use them on
public functions.
* Prefer protocol classes like Dict over directly calling implementation
modules (ListDict). When to use protocols and how to use them.
* How to call Erlang from Elixir and Elixir from Erlang. Gotcha's with
interoperability.
* How to deal with errors: prefer {:ok, val}|{:error, msg} type
responses over try-rescue, separate stuff that's likely to fail into
processes (error kernel principle).
* Basics of multiprocessing: explain spawn, receive, etc; introduction
to Elixir style OTP.
Again, my main question here is if Elixir has a sufficiently clear
philosophy to write clear guidelines on how to write code.
Greetings,
Peter Minten
Looking at our current documentation it seems to me that the type of
document that's needed most is something like Effective Go
(http://golang.org/doc/effective_go.html).
Effective Go is so effective in the Go world because it tells people how
to best write code. It's somewhat of a combination of a style guide with
a very practical guide to solving common problems. It answers questions
like "how do I handle errors?" and "how do I make the best use of
concurrency tools?".
Effective Go, more than any other document, embodies the philosophy of
the Go language. Now Go has a very well defined philosophy and very
clear rules on what's a good idea and what's not. So far I haven't
really gotten that vibe from Elixir.
The benefit of the clear philosophy of Go is that it's easy to get
started, there is a well defined way to do things. The downside is that
some people consider it to be too restrictive.
So my main question is: would it be possible to create an Effective
Elixir document? Do we have a clear vision to put in there? Or would it
become a document with lot's of "you could do this, or that, or that"
type of answers?
Maybe there's a middle ground in that Effective Elixir would be a
document that explicitly defines best practices but is clear that it's
perfectly OK to do something else completely, just make sure you know
what you're doing.
To get an idea of what kind of stuff I think would go into Effective
Elixir here's a (short) brainstorm.
* First paragraph of docs should be a descriptive line, preferably in an
active form.
* When to use |> and when not.
* Resist the urge to solve everything with a macro.
* How do use @type and @spec. Encourage people to at least use them on
public functions.
* Prefer protocol classes like Dict over directly calling implementation
modules (ListDict). When to use protocols and how to use them.
* How to call Erlang from Elixir and Elixir from Erlang. Gotcha's with
interoperability.
* How to deal with errors: prefer {:ok, val}|{:error, msg} type
responses over try-rescue, separate stuff that's likely to fail into
processes (error kernel principle).
* Basics of multiprocessing: explain spawn, receive, etc; introduction
to Elixir style OTP.
Again, my main question here is if Elixir has a sufficiently clear
philosophy to write clear guidelines on how to write code.
Greetings,
Peter Minten
Steve Domin
Sep 10, 2013, 2:14:08 PM9/10/13
to elixir-l...@googlegroups.com, peter....@online.nl
Hello Pete,
Being new to Elixir and having used Go a lot I can only agree with you.
I'd have loved to have that kind of document when I started to learn Elixir.
I also wonder if the language is mature enough for that though ?
Alexei Sholik
Sep 10, 2013, 2:42:38 PM9/10/13
to elixir-lang-core, peter....@online.nl
My gut tells me that in order for such a document to be most useful and representative of good coding practices, it has to be backed by one or more fairly large or at least production-ready projects.
In other words, what criteria can we come up with to describe maintainable Elixir code? I'd say, by looking at existing projects developed and maintained by a team of developers.
Nevertheless, one could write an opinionated (or principled if you like) guide based on his/her own experience in software industry, or in dealing with Erlang in the past. Anyone feeling confident enough to claim such a role?
--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Best regards
Alexei Sholik
Peter Minten
Sep 10, 2013, 4:00:29 PM9/10/13
to elixir-l...@googlegroups.com
My experience with trying this is that it gets hard beyond the very basics. I would say that the coding style used in the main elixir repo should be the basis of the template. But getting that written down correctly in a way that's educational but not too verbose or restrictive is difficult.
Maybe we need a PEP 7 style document first and reach consensus on that. We also need to document useful idioms in some place (wiki?), that will help newcomers get a feel for the language.
Alexei Sholik <alcos...@gmail.com>schreef:
Maybe we need a PEP 7 style document first and reach consensus on that. We also need to document useful idioms in some place (wiki?), that will help newcomers get a feel for the language.
Alexei Sholik <alcos...@gmail.com>schreef:
Alexei Sholik
Sep 10, 2013, 4:23:51 PM9/10/13
to elixir-lang-core
There is a beginning of a style guide https://github.com/alco/elixir/wiki/Contribution-Guidelines#coding-style
Peter Minten
Sep 11, 2013, 5:19:02 AM9/11/13
to elixir-l...@googlegroups.com
Yes, that would be a good start. However I notice that the main Elixir
repo doesn't fully conform to this style guide, for example the rule
about only putting the bit after -> in a case on the same line if this
is done for all cases doesn't seem to be used in the main repo (see for
example File.mkdir!/1).
Maybe the first question we should concern ourselves with is what the
general "style culture" of Elixir is.
Take for example the extremes Go and PHP. Go is very opinionated with
such clear style rules that they actually have a program to enforce it
(and it doesn't come with many options to customize it), the benefit is
that all Go code looks alike and once your mind has become accustomed to
reading Go reading other people's Go code is easy. On the other end we
have PHP which doesn't come with a coding style and is very "just do
whatever you want". It offers freedom but other people's PHP code can be
very hard to parse mentally.
Erlang comes with a programming rules document
(http://www.erlang.se/doc/programming_rules.shtml) which seems to be
slightly less strict than Go's rules but does define a common standard.
Erlang also has things like the OTP design principles which are in
effect higher level design guidelines.
Ruby on the other hand doesn't have a general coding style, though (in
my limited Ruby experience) I do have the impression that there is
somewhat of a cultural norm about how good ruby code look.
So what is the culture of Elixir? There aren't really that many larger
projects outside of the elixir-lang github repos so it's a bit hard to tell.
>>>> (http://golang.org/doc/**effective_go.html<http://golang.org/doc/effective_go.html>).
repo doesn't fully conform to this style guide, for example the rule
about only putting the bit after -> in a case on the same line if this
is done for all cases doesn't seem to be used in the main repo (see for
example File.mkdir!/1).
Maybe the first question we should concern ourselves with is what the
general "style culture" of Elixir is.
Take for example the extremes Go and PHP. Go is very opinionated with
such clear style rules that they actually have a program to enforce it
(and it doesn't come with many options to customize it), the benefit is
that all Go code looks alike and once your mind has become accustomed to
reading Go reading other people's Go code is easy. On the other end we
have PHP which doesn't come with a coding style and is very "just do
whatever you want". It offers freedom but other people's PHP code can be
very hard to parse mentally.
Erlang comes with a programming rules document
(http://www.erlang.se/doc/programming_rules.shtml) which seems to be
slightly less strict than Go's rules but does define a common standard.
Erlang also has things like the OTP design principles which are in
effect higher level design guidelines.
Ruby on the other hand doesn't have a general coding style, though (in
my limited Ruby experience) I do have the impression that there is
somewhat of a cultural norm about how good ruby code look.
So what is the culture of Elixir? There aren't really that many larger
projects outside of the elixir-lang github repos so it's a bit hard to tell.
Oren Ben-Kiki
Sep 11, 2013, 5:36:09 AM9/11/13
to elixir-l...@googlegroups.com
As a very old hand at coding, I find myself attracted to the Go end of the spectrum when it comes to the style culture. Not that the the standard Go style is a 100% match to my tastes; but having all the code be in a uniform style, without any ifs/buts/whens makes reading it so much easier.
This is doubly important when newcomers are writing code. It takes time for style to become automatic, and newcomers are too busy thinking about other, more semantic issues, so they end up writing something random looking like "for (i=0;i < 5;i++){" which makes your head hurt when you try to parse it (yes, I know this is a C example, but you get the idea).
I found that having a program just fix everything into a uniform style is great. One less thing to worry about, both as a newcomer and as a reviewer.
Another, non-obvious benefit to the Go approach is that it forced the language designers to think long and hard about the syntax and enabling of automatic tools to manipulate source code.
Go's syntax is *very* simple (consider, for example, the long-wrapped-lines parsing). They were forced to make it so to allow for the automated tools they wanted - the formatting program being one, but there's a whole culture of "automatic tools to manipulate go code" such as gofix which is all dependent on the same mindset. Which, again, is great.
I can only hope other languages embrace this mindset. It is, of course, way too late for monstrosities such as C++, but Elixir is in a good place (actually, so is Erlang).
--
Best regards
Alexei Sholik
--
You received this message because you are subscribed to the Google Groups
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an
--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscribe@googlegroups.com.
Peter Minten
Sep 11, 2013, 5:47:44 AM9/11/13
to elixir-l...@googlegroups.com
On 09/11/2013 11:36 AM, Oren Ben-Kiki wrote:
> As a very old hand at coding, I find myself attracted to the Go end of the
> spectrum when it comes to the style culture. Not that the the standard Go
> style is a 100% match to my tastes; but having all the code be in a uniform
> style, without any ifs/buts/whens makes reading it so much easier.
> This is doubly important when newcomers are writing code. It takes time for
> style to become automatic, and newcomers are too busy thinking about other,
> more semantic issues, so they end up writing something random looking like
> "for (i=0;i < 5;i++){" which makes your head hurt when you try to parse it
> (yes, I know this is a C example, but you get the idea).
>
> I found that having a program just fix everything into a uniform style is
> great. One less thing to worry about, both as a newcomer and as a reviewer.
>
> Another, non-obvious benefit to the Go approach is that it forced the
> language designers to think long and hard about the syntax and enabling of
> automatic tools to manipulate source code.
>
> Go's syntax is *very* simple (consider, for example, the long-wrapped-lines
> parsing). They were forced to make it so to allow for the automated tools
> they wanted - the formatting program being one, but there's a whole culture
> of "automatic tools to manipulate go code" such as gofix which is all
> dependent on the same mindset. Which, again, is great.
I fully agree, Go's approach is great and it makes maintaining code much
> As a very old hand at coding, I find myself attracted to the Go end of the
> spectrum when it comes to the style culture. Not that the the standard Go
> style is a 100% match to my tastes; but having all the code be in a uniform
> style, without any ifs/buts/whens makes reading it so much easier.
> This is doubly important when newcomers are writing code. It takes time for
> style to become automatic, and newcomers are too busy thinking about other,
> more semantic issues, so they end up writing something random looking like
> "for (i=0;i < 5;i++){" which makes your head hurt when you try to parse it
> (yes, I know this is a C example, but you get the idea).
>
> I found that having a program just fix everything into a uniform style is
> great. One less thing to worry about, both as a newcomer and as a reviewer.
>
> Another, non-obvious benefit to the Go approach is that it forced the
> language designers to think long and hard about the syntax and enabling of
> automatic tools to manipulate source code.
>
> Go's syntax is *very* simple (consider, for example, the long-wrapped-lines
> parsing). They were forced to make it so to allow for the automated tools
> they wanted - the formatting program being one, but there's a whole culture
> of "automatic tools to manipulate go code" such as gofix which is all
> dependent on the same mindset. Which, again, is great.
easier. They do get a lot of flak for that though, it's not uncontroversial.
> I can only hope other languages embrace this mindset. It is, of course, way
> too late for monstrosities such as C++, but Elixir is in a good place
> (actually, so is Erlang).
depending on how badly people abuse them. Elixir is a lot more flexible
than Go and that may make an automated tool harder to write.
Consider: it's good style to use () parens with functions but with
macro's you often want to leave them off (especially when "do" gets
involved). But I'm not sure this applies to all macro's.
> On Wed, Sep 11, 2013 at 12:19 PM, Peter Minten <peter....@online.nl>wrote:
>
>> Yes, that would be a good start. However I notice that the main Elixir
>> repo doesn't fully conform to this style guide, for example the rule about
>> only putting the bit after -> in a case on the same line if this is done
>> for all cases doesn't seem to be used in the main repo (see for example
>> File.mkdir!/1).
>>
>> Maybe the first question we should concern ourselves with is what the
>> general "style culture" of Elixir is.
>>
>> Take for example the extremes Go and PHP. Go is very opinionated with such
>> clear style rules that they actually have a program to enforce it (and it
>> doesn't come with many options to customize it), the benefit is that all Go
>> code looks alike and once your mind has become accustomed to reading Go
>> reading other people's Go code is easy. On the other end we have PHP which
>> doesn't come with a coding style and is very "just do whatever you want".
>> It offers freedom but other people's PHP code can be very hard to parse
>> mentally.
>>
>> *programming_rules.shtml<http://www.erlang.se/doc/programming_rules.shtml>)
>> which seems to be slightly less strict than Go's rules but does define a
>> common standard. Erlang also has things like the OTP design principles
>> which are in effect higher level design guidelines.
>>
>> Ruby on the other hand doesn't have a general coding style, though (in my
>> limited Ruby experience) I do have the impression that there is somewhat of
>> a cultural norm about how good ruby code look.
>>
>> So what is the culture of Elixir? There aren't really that many larger
>> projects outside of the elixir-lang github repos so it's a bit hard to tell.
>>
>>
>> On 09/10/2013 10:23 PM, Alexei Sholik wrote:
>>
>>> There is a beginning of a style guide
>>> https://github.com/alco/**elixir/wiki/Contribution-**
>> common standard. Erlang also has things like the OTP design principles
>> which are in effect higher level design guidelines.
>>
>> Ruby on the other hand doesn't have a general coding style, though (in my
>> limited Ruby experience) I do have the impression that there is somewhat of
>> a cultural norm about how good ruby code look.
>>
>> So what is the culture of Elixir? There aren't really that many larger
>> projects outside of the elixir-lang github repos so it's a bit hard to tell.
>>
>>
>> On 09/10/2013 10:23 PM, Alexei Sholik wrote:
>>
>>> There is a beginning of a style guide
>>> Guidelines#coding-style<https://github.com/alco/elixir/wiki/Contribution-Guidelines#coding-style>
>>>>>> <http://**golang.org/doc/effective_go.**html<http://golang.org/doc/effective_go.html>
>>>>> .
>>>>> For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>>>>> .
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Best regards
>>>> Alexei Sholik
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google Groups
>>>> "elixir-lang-core" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send an
>>>> email to elixir-lang-core+unsubscribe@**googlegroups.com<elixir-lang-core%2Bunsu...@googlegroups.com>
>>>>>
>>>>
>>>>
>>>> --
>>>> Best regards
>>>> Alexei Sholik
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google Groups
>>>> "elixir-lang-core" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send an
>>>> .
>>>> For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>>>> .
>>>>
>>>>
>>>
>>>
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "elixir-lang-core" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to elixir-lang-core+unsubscribe@**googlegroups.com<elixir-lang-core%2Bunsu...@googlegroups.com>
>>>>
>>>
>>>
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "elixir-lang-core" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> .
>> For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>> .
>>
>
Oren Ben-Kiki
Sep 11, 2013, 5:52:45 AM9/11/13
to elixir-l...@googlegroups.com
Yes, Elixir has two big obstacles to this - optional parenthesis and macros (which is almost the same thing).
Having a setting that says "preserve original source code decision" might be a valid choice... Even Go respects the original source's decision to wrap long lines, for example. For Elixir doing the same for parenthesis would probably make sense.
But this is just one issue out of many - there's indentation, comments alignment ("flexible tabs"), etc. etc.
email to elixir-lang-core+unsubscribe@**googlegroups.com<elixir-lang-core%2Bunsubscribe@googlegroups.com>
.
For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
.
--
Best regards
Alexei Sholik
--
You received this message because you are subscribed to the Google Groups
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elixir-lang-core+unsubscribe@**googlegroups.com<elixir-lang-core%2Bunsubscribe@googlegroups.com>
.
For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
.
--
You received this message because you are subscribed to the Google Groups
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elixir-lang-core+unsubscribe@**googlegroups.com<elixir-lang-core%2Bunsubscribe@googlegroups.com>
.
For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
.
--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Steve Domin
Sep 11, 2013, 5:58:59 AM9/11/13
to elixir-l...@googlegroups.com
I'd love too that other languages embrace this mindset, Elixir could definitely be one of them.
I'm not experienced enough with Elixir to foresee all the difficulties but I can definitely see that it would be hard to make such a tool as gofmt.
But even if it doesn't do much if think it's still valuable to have a tool like this, enforcing simple style rules.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
Bruce Williams
Sep 11, 2013, 6:52:39 AM9/11/13
to elixir-l...@googlegroups.com
At the risk of sounding like a contrarian, I probably fall into non-"official guidance" side of the spectrum here. I think community driven/supported style guides that people can debate about are a good thing, but trying to set anything into stone (outside standard, per-project contribution guidelines, which I fully support), especially this early in Elixir's life would have a negative effect on a community that's really just starting to grow.
Ruby was brought up as an example. I think some of the best things about the Ruby community (which I've been involved in since 2001) have come out of the fact that, stylistically, people have "voted with their feet." It's made for a much livelier, less authoritarian-feeling community (not that I think anyone's going that route here), and has prevented early bad/weird style decisions from living on past their usefulness because an official document had to be blessed/accepted/voted on by committee.
IMHO, If a language community can't naturally bend towards improved readability and portability without setting official rules, it's got more serious problems. Recommendations are fine (I'm not a proponent of complete chaos), but style discussion and evolution should be a part of general community culture.
Cheers,
Bruce
(And I didn't even say anything about Go's "progressive" choice of tabs. I'm kind of proud of myself.)
--email to elixir-lang-core+unsubscribe@**googlegroups.com<elixir-lang-core%2Bunsubscribe@googlegroups.com>
You received this message because you are subscribed to the Google Groups
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an
.
For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
.
--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Peter Minten
Sep 11, 2013, 7:46:56 AM9/11/13
to elixir-l...@googlegroups.com
I don't think you sound like a contrarian at all. Getting a range of
views is exactly why I started this discussion.
There are several ways to do a style guide:
With a top-down style guide the rules come first and implementations are
adapted to it. This worked in Go quite well because it's a new language
and hence there isn't much inertia in it.
A bottom-up style guide on the other hand documents whatever practice is
common in the community. It formalizes the consensus in the community.
This kind of style guide works very well with mature languages where
there's a clear "cultural ruleset".
How well a style guide is followed is another matter. In Go the style
guide is followed because it's enforced by the gofmt program and there's
a very strong cultural rule about following the rules.
In Python the style guide (PEP 7) is generally followed but not
mandatory. Plenty of projects deviate from it but the general Python
culture is to follow it.
The fact that a style guide is official doesn't necessarily mean that
it's mandatory. That is always up to the individual projects.
You assert that a strict style guide "from above" would have a negative
effect on the community. Could you explain that? It seems at odd with
the idea that a strict set of rules helps newbies.
You also assert that an official style guide can make bad style
decisions live longer than they otherwise would because they are "carved
in stone". But that can be said as well about a cultural, unwritten,
style guide. With the unwritten cultural rules you have a risk of old
but obsolete coding practices being so common that all tutorials and
half the stack overflow answers still use them (see lots of PHP
tutorials that propose writing SQL injection prone code). Culture has
inertia as well. With a style guide however things have to be debated,
which at least increases the chance of something thinking about the first.
I do agree that a style guide is useless if it can't be updated. There
has to be a clear mechanism to say "this used to be the best way, but
now please use this".
>>>>>> *programming_rules.shtml<http:****//www.erlang.se/doc/**programmin**
>>>>>> g_rules.shtml <http://www.erlang.se/doc/programming_rules.shtml>>)
>>>>>>> Guidelines#coding-style<https:****//github.com/alco/elixir/wiki/****
>>>>>>> Contribution-Guidelines#**coding**-style<https://github.com/alco/elixir/wiki/Contribution-Guidelines#coding-style>
>>>>>>>> (http://golang.org/doc/******eff**ective_go.html<http://golang.org/doc/****effective_go.html>
>>>>>>>> <http://**golang.**org/doc/**effective_go.**html<http://golang.org/doc/**effective_go.html>
>>>>>>>>>
>>>>>>>> <http://**golang.org/doc/**effec**tive_go.**html<http://golang.org/doc/effective_go.**html>
>>>>>>>> <http://**golang.**org/doc/effective_go.**html<http://golang.org/doc/effective_go.html>
>>>>>>>> email to elixir-lang-core+unsubscribe@******googlegroups.com<
>>>>>>>> elixir-lang-****core%2Bunsubscribe@**googlegroup**s.com>
>>>>>>>> .
>>>>>>>> For more options, visit https://groups.google.com/****gr**
>>>>>>>> oups/opt_out <https://groups.google.com/**groups/opt_out><
>>>>>>>> https://groups.**go**ogle.com/groups/opt_out<https://groups.google.com/groups/opt_out>
>>>>>> elixir-lang-****core%2Bunsubscribe@**googlegroup**s.com>
>>>>>> .
>>>>>> For more options, visit https://groups.google.com/****gr**oups/opt_out<https://groups.google.com/**groups/opt_out>
>>>>>> <https://groups.**go**ogle.com/groups/opt_out<https://groups.google.com/groups/opt_out>
>>>> For more options, visit https://groups.google.com/**grou**ps/opt_out<https://groups.google.com/groups/opt_out>
>> 'cvml', 'elixir-lang-core%2Bunsu...@googlegroups.com');>.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
views is exactly why I started this discussion.
There are several ways to do a style guide:
With a top-down style guide the rules come first and implementations are
adapted to it. This worked in Go quite well because it's a new language
and hence there isn't much inertia in it.
A bottom-up style guide on the other hand documents whatever practice is
common in the community. It formalizes the consensus in the community.
This kind of style guide works very well with mature languages where
there's a clear "cultural ruleset".
How well a style guide is followed is another matter. In Go the style
guide is followed because it's enforced by the gofmt program and there's
a very strong cultural rule about following the rules.
In Python the style guide (PEP 7) is generally followed but not
mandatory. Plenty of projects deviate from it but the general Python
culture is to follow it.
The fact that a style guide is official doesn't necessarily mean that
it's mandatory. That is always up to the individual projects.
You assert that a strict style guide "from above" would have a negative
effect on the community. Could you explain that? It seems at odd with
the idea that a strict set of rules helps newbies.
You also assert that an official style guide can make bad style
decisions live longer than they otherwise would because they are "carved
in stone". But that can be said as well about a cultural, unwritten,
style guide. With the unwritten cultural rules you have a risk of old
but obsolete coding practices being so common that all tutorials and
half the stack overflow answers still use them (see lots of PHP
tutorials that propose writing SQL injection prone code). Culture has
inertia as well. With a style guide however things have to be debated,
which at least increases the chance of something thinking about the first.
I do agree that a style guide is useless if it can't be updated. There
has to be a clear mechanism to say "this used to be the best way, but
now please use this".
>>>>>> g_rules.shtml <http://www.erlang.se/doc/programming_rules.shtml>>)
>>>>>>
>>>>>> which seems to be slightly less strict than Go's rules but does define
>>>>>> a
>>>>>> common standard. Erlang also has things like the OTP design principles
>>>>>> which are in effect higher level design guidelines.
>>>>>>
>>>>>> Ruby on the other hand doesn't have a general coding style, though (in
>>>>>> my
>>>>>> limited Ruby experience) I do have the impression that there is
>>>>>> somewhat of
>>>>>> a cultural norm about how good ruby code look.
>>>>>>
>>>>>> So what is the culture of Elixir? There aren't really that many larger
>>>>>> projects outside of the elixir-lang github repos so it's a bit hard to
>>>>>> tell.
>>>>>>
>>>>>>
>>>>>> On 09/10/2013 10:23 PM, Alexei Sholik wrote:
>>>>>>
>>>>>> There is a beginning of a style guide
>>>>>>> https://github.com/alco/****elix**ir/wiki/Contribution-**<https://github.com/alco/**elixir/wiki/Contribution-**>
>>>>>> which seems to be slightly less strict than Go's rules but does define
>>>>>> a
>>>>>> common standard. Erlang also has things like the OTP design principles
>>>>>> which are in effect higher level design guidelines.
>>>>>>
>>>>>> Ruby on the other hand doesn't have a general coding style, though (in
>>>>>> my
>>>>>> limited Ruby experience) I do have the impression that there is
>>>>>> somewhat of
>>>>>> a cultural norm about how good ruby code look.
>>>>>>
>>>>>> So what is the culture of Elixir? There aren't really that many larger
>>>>>> projects outside of the elixir-lang github repos so it's a bit hard to
>>>>>> tell.
>>>>>>
>>>>>>
>>>>>> On 09/10/2013 10:23 PM, Alexei Sholik wrote:
>>>>>>
>>>>>> There is a beginning of a style guide
>>>>>>> Guidelines#coding-style<https:****//github.com/alco/elixir/wiki/****
>>>>>>> Contribution-Guidelines#**coding**-style<https://github.com/alco/elixir/wiki/Contribution-Guidelines#coding-style>
>>>>>>>> <http://**golang.**org/doc/**effective_go.**html<http://golang.org/doc/**effective_go.html>
>>>>>>>>>
>>>>>>>> <http://**golang.org/doc/**effec**tive_go.**html<http://golang.org/doc/effective_go.**html>
>>>>>>>> <http://**golang.**org/doc/effective_go.**html<http://golang.org/doc/effective_go.html>
>>>>>>>> elixir-lang-****core%2Bunsubscribe@**googlegroup**s.com>
>>>>>>>> .
>>>>>>>> For more options, visit https://groups.google.com/****gr**
>>>>>>>> oups/opt_out <https://groups.google.com/**groups/opt_out><
>>>>>>>> https://groups.**go**ogle.com/groups/opt_out<https://groups.google.com/groups/opt_out>
>>>>>>>>>
>>>>>>>> .
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Best regards
>>>>>>>> Alexei Sholik
>>>>>>>>
>>>>>>>> --
>>>>>>>> You received this message because you are subscribed to the Google
>>>>>>>> Groups
>>>>>>>> "elixir-lang-core" group.
>>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>>> send an
>>>>>>>> email to elixir-lang-core+unsubscribe@*****
>>>>>>>> .
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Best regards
>>>>>>>> Alexei Sholik
>>>>>>>>
>>>>>>>> --
>>>>>>>> You received this message because you are subscribed to the Google
>>>>>>>> Groups
>>>>>>>> "elixir-lang-core" group.
>>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>>> send an
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups
>>>>>> "elixir-lang-core" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>>> an
>>>>>> email to elixir-lang-core+unsubscribe@******googlegroups.com<
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups
>>>>>> "elixir-lang-core" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>>> an
>>>>>> elixir-lang-****core%2Bunsubscribe@**googlegroup**s.com>
>>>>>> .
>>>>>> For more options, visit https://groups.google.com/****gr**oups/opt_out<https://groups.google.com/**groups/opt_out>
>>>>>> <https://groups.**go**ogle.com/groups/opt_out<https://groups.google.com/groups/opt_out>
>>>>>>>
>>>>>> .
>>>>>>
>>>>>>
>>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "elixir-lang-core" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to elixir-lang-co...@**g**ooglegroups.com.
>>>>>> .
>>>>>>
>>>>>>
>>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "elixir-lang-core" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> For more options, visit https://groups.google.com/**grou**ps/opt_out<https://groups.google.com/groups/opt_out>
>>>> .
>>>>
>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "elixir-lang-core" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to elixir-lang-co...@googlegroups.com <javascript:_e({},
>>>>
>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "elixir-lang-core" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> 'cvml', 'elixir-lang-core%2Bunsu...@googlegroups.com');>.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
Steve Domin
Sep 11, 2013, 9:08:53 AM9/11/13
to elixir-l...@googlegroups.com, peter....@online.nl
Bruce, I don't think it's about setting anything in stone,
To come back to Ruby I think it's one of the worst experience I had when starting to learn a new language, even if part of the problem was certainly the environment in which I learnt it.
There is a thousand ways to do one thing and it's very hard to find a one-stop shop
Go on the other hand with its gofmt tool and the Effective Go guide is a pleasure to start with because you're "guided". It tells you the language has been designed like this and here is the effective way to use it. It doesn't prevent the community to come up with a new patterns and rules, to experiment, nor does it prevent the styleguide to evolve.
Gustavo Brunoro
Sep 11, 2013, 10:01:09 AM9/11/13
to elixir-l...@googlegroups.com, peter....@online.nl
I agree with alco's first mail: Elixir doesn't have a fairly large and production-ready project to serve as reference to good practices.
Having an _official_ style guide now could slow down the evolution of the language: as said before, Go isn't as flexible as Elixir and likely wouldn't see as much changes on style, driven by new macros or language features.
That said, I think we're still on a phase of building that Elixir culture. Even small things such as naming conventions for conversion functions are still being discussed. Less of such discussions would come up, as those practices would be already standardized on the official style guide and less prone to change. Would it be worth to have an official style guide that's still changing at a very fast pace?
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
Bruce Williams
Sep 11, 2013, 1:12:54 PM9/11/13
to elixir-l...@googlegroups.com
Peter,
My follow-up is pretty much in line with what Gustavo said here.
I'm not against style guides at all -- it's the "official" quality (and especially the tone in which it's announced) that I generally worry about from a community growth -- and yes, enjoyment -- perspective. I don't think an official guide "top down" guide is needed here -- and I think there enough people that care about the language syntax and standard usage (many of which are in this list) to contribute to the discussion. It's not always about a mature community codifying best practices, but a developing community documenting and weighing early trends. There is still a lot of movement, and that's a good thing.
I'm not active enough in Go to understand how fast gofmt evolves, or how much "process" it adds to what (I think) should be more natural, direct evolution of the language, but Elixir is a much larger language outside the control & marketing of a big company like Google, and I think that matters.
(I may comment more on your reply in a bit -- this email was painstakingly tapped out on a phone.)
Bruce
Peter Minten
Sep 11, 2013, 1:26:42 PM9/11/13
to elixir-l...@googlegroups.com
Well I started this discussion to get an idea if there is community
support for a single style guide. It seems instead the community is
rather split on it.
For what it's worth I don't think there necessarily needs to be an
official style guide as long as there don't end up being multiple style
guides competing with each other. For a style guide to make any sense at
all it needs to be prominent (easy to find) and be well supported by the
community. Whether it is "officially" blessed is fairly irrelevant.
I see a style guide primarily as documentation for newcomers, to give
them an idea of how to write good code.
I do wonder though whether underneath the discussion about a style guide
is actually a culture clash between two philosophies: there is one right
way to do it (Python) and there is more than one way to do it (Perl).
In the phase in which Elixir is right now we see the language culture
slowly developing. People come in from all sorts of backgrounds and
bring in bits of the culture from the languages they have worked with in
the past. I see cultural influences from Erlang (obviously), Ruby and
Clojure but also from Go, Python and Haskell.
The discussions we are having now are in some way a search for the
fledging Elixir culture. It is fascinating to see and be a part of this
process.
support for a single style guide. It seems instead the community is
rather split on it.
For what it's worth I don't think there necessarily needs to be an
official style guide as long as there don't end up being multiple style
guides competing with each other. For a style guide to make any sense at
all it needs to be prominent (easy to find) and be well supported by the
community. Whether it is "officially" blessed is fairly irrelevant.
I see a style guide primarily as documentation for newcomers, to give
them an idea of how to write good code.
I do wonder though whether underneath the discussion about a style guide
is actually a culture clash between two philosophies: there is one right
way to do it (Python) and there is more than one way to do it (Perl).
In the phase in which Elixir is right now we see the language culture
slowly developing. People come in from all sorts of backgrounds and
bring in bits of the culture from the languages they have worked with in
the past. I see cultural influences from Erlang (obviously), Ruby and
Clojure but also from Go, Python and Haskell.
The discussions we are having now are in some way a search for the
fledging Elixir culture. It is fascinating to see and be a part of this
process.
Christopher Keele
Sep 11, 2013, 2:37:52 PM9/11/13
to elixir-l...@googlegroups.com
This discussion encapsulates the two most fascinating parts of Elixir: it's a young, naissent language that's still evolving; and it's drawing a very diverse community of developers.
I'm split between the desire for a single style guide, and an interest in watching what styles evolve organically. (Not too attracted to the idea of a programmatic style enforcer though—I feel that would hamper the evolution of a language no matter where it's at in its evolution.)
I don't think this question can be answered right now, we'll have to wait and see. The lack of several flagship Elixir projects well-known by the community does make it harder to assess any sort of consensus in its young culture.
Perhaps a middle path, to help steer us towards discovering the stylistic preferences of the community? I propose instead of recommending a single style guide to new developers, we encouraged all projects to cultivate a STYLEGUIDE.md. It would make it trivial to programmatically collect and track the evolution of our sense of style. As trends repeat, they can be aggregated into a more canonical document.
Aside from word-of-mouth, there are several ways we could try and encourage developers to maintain such a document.
The easiest way would be to introduce the idea in Mix, either in its documentation, through a task that installs Elixir's own STYLEGUIDE.md, or by adding a template STYLEGUIDE.md on project generation, with four empty headers: Code, Tests, Documentation, and Examples (or DocTests).
Another simple way to encourage this would be to study conventions in Elixir itself and give it its own STYLEGUIDE.md, which it probably could use anyways. As mentioned above, we could find a way in Mix to install that into projects.
A third useful and motivating tool could be some sort of online codex of these style guides, programmatically scraped from Elixir repositories on GitHub, with searching, ranking, and discussion features.
This would let the community 'vote with their feet' and encourage an organic discovery and evolution of our style, while enabling the development of a central style guide.
Producing a higher-level introduction to beneficial patterns like Effective Elixir would also be easier, since it wouldn't have to document the lower-level coding style, while still conforming to the community's preferences in its examples. Also, this would give us a way to discover production-ready projects that are well maintained and actively concerned about the style and practices of their applications, from which we could derive patterns to recommend.
Peter Minten
Sep 12, 2013, 7:16:26 AM9/12/13
to elixir-l...@googlegroups.com
I fear that your idea would actually encourage fragmentation of styles.
Once a project settles on a certain style it's very unlikely that
they'll change it. Writing a style guide is carving your style in stone,
it's very hard to change afterwards (nobody wants to clean up the code).
So in the end there would be several styles floating around and newbies
getting confused.
On 09/11/2013 08:37 PM, Christopher Keele wrote:
> This discussion encapsulates the two most fascinating parts of Elixir: it's a young, naissent language that's still evolving; and it's drawing a very diverse community of developers.
>
> I'm split between the desire for a single style guide, and an interest in watching what styles evolve organically. (Not too attracted to the idea of a programmatic style enforcer though�I feel that would hamper the evolution of a language no matter where it's at in its evolution.)
>>>> 2013/9/11 Steve Domin <st...@stevedomin.com (mailto:st...@stevedomin.com)>
>> To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com (mailto:elixir-lang-co...@googlegroups.com).
Once a project settles on a certain style it's very unlikely that
they'll change it. Writing a style guide is carving your style in stone,
it's very hard to change afterwards (nobody wants to clean up the code).
So in the end there would be several styles floating around and newbies
getting confused.
On 09/11/2013 08:37 PM, Christopher Keele wrote:
> This discussion encapsulates the two most fascinating parts of Elixir: it's a young, naissent language that's still evolving; and it's drawing a very diverse community of developers.
>
>
> I don't think this question can be answered right now, we'll have to wait and see. The lack of several flagship Elixir projects well-known by the community does make it harder to assess any sort of consensus in its young culture.
>
> Perhaps a middle path, to help steer us towards discovering the stylistic preferences of the community? I propose instead of recommending a single style guide to new developers, we encouraged all projects to cultivate a STYLEGUIDE.md. It would make it trivial to programmatically collect and track the evolution of our sense of style. As trends repeat, they can be aggregated into a more canonical document.
>
> Aside from word-of-mouth, there are several ways we could try and encourage developers to maintain such a document.
>
> The easiest way would be to introduce the idea in Mix, either in its documentation, through a task that installs Elixir's own STYLEGUIDE.md, or by adding a template STYLEGUIDE.md on project generation, with four empty headers: Code, Tests, Documentation, and Examples (or DocTests).
>
> Another simple way to encourage this would be to study conventions in Elixir itself and give it its own STYLEGUIDE.md, which it probably could use anyways. As mentioned above, we could find a way in Mix to install that into projects.
>
> A third useful and motivating tool could be some sort of online codex of these style guides, programmatically scraped from Elixir repositories on GitHub, with searching, ranking, and discussion features.
>
> This would let the community 'vote with their feet' and encourage an organic discovery and evolution of our style, while enabling the development of a central style guide.
>
> Producing a higher-level introduction to beneficial patterns like Effective Elixir would also be easier, since it wouldn't have to document the lower-level coding style, while still conforming to the community's preferences in its examples. Also, this would give us a way to discover production-ready projects that are well maintained and actively concerned about the style and practices of their applications, from which we could derive patterns to recommend.
>
> --
> Christopher Keele
> Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
> I don't think this question can be answered right now, we'll have to wait and see. The lack of several flagship Elixir projects well-known by the community does make it harder to assess any sort of consensus in its young culture.
>
> Perhaps a middle path, to help steer us towards discovering the stylistic preferences of the community? I propose instead of recommending a single style guide to new developers, we encouraged all projects to cultivate a STYLEGUIDE.md. It would make it trivial to programmatically collect and track the evolution of our sense of style. As trends repeat, they can be aggregated into a more canonical document.
>
> Aside from word-of-mouth, there are several ways we could try and encourage developers to maintain such a document.
>
> The easiest way would be to introduce the idea in Mix, either in its documentation, through a task that installs Elixir's own STYLEGUIDE.md, or by adding a template STYLEGUIDE.md on project generation, with four empty headers: Code, Tests, Documentation, and Examples (or DocTests).
>
> Another simple way to encourage this would be to study conventions in Elixir itself and give it its own STYLEGUIDE.md, which it probably could use anyways. As mentioned above, we could find a way in Mix to install that into projects.
>
> A third useful and motivating tool could be some sort of online codex of these style guides, programmatically scraped from Elixir repositories on GitHub, with searching, ranking, and discussion features.
>
> This would let the community 'vote with their feet' and encourage an organic discovery and evolution of our style, while enabling the development of a central style guide.
>
> Producing a higher-level introduction to beneficial patterns like Effective Elixir would also be easier, since it wouldn't have to document the lower-level coding style, while still conforming to the community's preferences in its examples. Also, this would give us a way to discover production-ready projects that are well maintained and actively concerned about the style and practices of their applications, from which we could derive patterns to recommend.
>
> --
> Christopher Keele
Oren Ben-Kiki
Sep 12, 2013, 7:33:35 AM9/12/13
to elixir-l...@googlegroups.com
This is why having a tool that enforces a single style and ruthlessly using it before every commit allows easier evolution of the style with time - because you can just re-run the tool with updated version or settings when the consensus shifts. If, however, there are no tools to enforce the style, then changing it becomes a manual, tedious and error prone operation - the cost becomes too high and people will stick with the old style. And since this is manual, this style will be different for every project... so there would be very slow evolution, if at all, of the "commonly used style".
On Thu, Sep 12, 2013 at 2:16 PM, Peter Minten <peter....@online.nl> wrote:
I fear that your idea would actually encourage fragmentation of styles. Once a project settles on a certain style it's very unlikely that they'll change it. Writing a style guide is carving your style in stone, it's very hard to change afterwards (nobody wants to clean up the code). So in the end there would be several styles floating around and newbies getting confused.
On 09/11/2013 08:37 PM, Christopher Keele wrote:
This discussion encapsulates the two most fascinating parts of Elixir: it's a young, naissent language that's still evolving; and it's drawing a very diverse community of developers.
I'm split between the desire for a single style guide, and an interest in watching what styles evolve organically. (Not too attracted to the idea of a programmatic style enforcer though—I feel that would hamper the evolution of a language no matter where it's at in its evolution.)
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscribe@googlegroups.com (mailto:elixir-lang-core+unsub...@googlegroups.com).
--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscribe@googlegroups.com.
Saša Jurić
Sep 12, 2013, 8:40:29 AM9/12/13
to elixir-l...@googlegroups.com, peter....@online.nl
I'll probably get bashed for this, but I'll say it anyway: I hate style guides.
The ones I have been involved with were usually concerned with low-level aesthetic details, which I find less relevant in the grand scheme of things.
For me, it's almost irrelevant whether a developer writes
{:a, :b}
or
{ :a, :b }Sure, it may bug me a little when looking at the inconsistent code, but it's equally easy to read both versions.
That said, I think Peter raised interesting point in the original post:
It's somewhat of a combination of a style guide with
a very practical guide to solving common problems.
This other part, how to solve common problems seems more exciting and relevant. Given that Elixir and Erlang are unlike mainstream platforms, such as Java, Ruby and other OO/mutable based platforms, this is the area where I think most confusion, malpractice and misunderstanding might arise. And I talk from my personal experience - I came to Erlang from OO a couple of years ago, and I'm not ashamed to admit I abused many constructs to make my experienced more similar to OO, and I also misused many constructs due to the lack of knowledge about the platform.
Topics such as error handling, processes vs ets vs functional structures, registered names vs. pids, functional idioms, records vs private records, hashes vs lists vs ets, iolists and similar - these are the ones that I think would be much more interesting and useful.
Most style guides I saw never treated such common idioms, patterns and trade-offs they bring. In a sense I can sympathize, these are harder topics to treat and there are no unique answers. It's usually easier to say "always put space after you open a curly brace" and be done with it. Never mind that a developer writes inefficient or poorly structured code. All that matters is that the code is aesthetically uniform.
In all fairness, higher level topics, such as common patterns usually get some treatment in books, but keep in mind that a book reader is struggling with the syntax, and may gloss over or neglect this aspect due to the vast quantity of new material.
Therefore, a more high level guide, a guide that assumes a reader is familiar with syntax and building blocks, and discusses common situations when they should be applied - that is something that I would consider much more useful than a plain low level style guide.
Peter Minten
Sep 12, 2013, 10:40:16 AM9/12/13
to elixir-l...@googlegroups.com
Though I see the benefit of style guides you have a point that they're
about the trivial details and don't focus on what really matters: good code.
In my experience good style and good code do often go together, but
that's probably because someone who writes good code has good discipline
and someone who has good discipline tends to write in a consistent
style. You are right that writing in the right style does do anything
for the quality of the code.
Thinking about this a bit more it's more of a scale of subjects from the
trivial and concrete (where to put the spaces) to the complicated and
abstract (thinking in terms of processes).
I guess what we want is a "Thinking Elixir" advanced level book,
something like "https://github.com/mezzohaskell/mezzohaskell". Note
however how well that went, progress on that book is extremely slow. I
fear that's the fate of any big central document.
Maybe we shouldn't try to create something big but focus on incremental
progress: blog posts[1], better documentation, etc. This is how we will
gradually discover what works well in Elixir and what doesn't.
One thing we need to do better however is organize the information
that's available in a way users can find it. I'm not quite sure how to
achieve that though.
[1] Shameless self-promotion: I've been working on identifying some less
obvious patterns at http://pminten.github.io/
On 09/12/2013 02:40 PM, Saša Jurić wrote:
> I'll probably get bashed for this, but I'll say it anyway: I hate style
> guides.
> The ones I have been involved with were usually concerned with low-level
> aesthetic details, which I find less relevant in the grand scheme of things.
>
> For me, it's almost irrelevant whether a developer writes
> {:a, :b}
> or
> { :a, :b }
>
> Sure, it may bug me a little when looking at the inconsistent code, but
> it's equally easy to read both versions.
>
> That said, I think Peter raised interesting point in the original post:
>
> It's somewhat of a combination of a style guide *with
>> a very practical guide to solving common problems*.
about the trivial details and don't focus on what really matters: good code.
In my experience good style and good code do often go together, but
that's probably because someone who writes good code has good discipline
and someone who has good discipline tends to write in a consistent
style. You are right that writing in the right style does do anything
for the quality of the code.
Thinking about this a bit more it's more of a scale of subjects from the
trivial and concrete (where to put the spaces) to the complicated and
abstract (thinking in terms of processes).
I guess what we want is a "Thinking Elixir" advanced level book,
something like "https://github.com/mezzohaskell/mezzohaskell". Note
however how well that went, progress on that book is extremely slow. I
fear that's the fate of any big central document.
Maybe we shouldn't try to create something big but focus on incremental
progress: blog posts[1], better documentation, etc. This is how we will
gradually discover what works well in Elixir and what doesn't.
One thing we need to do better however is organize the information
that's available in a way users can find it. I'm not quite sure how to
achieve that though.
[1] Shameless self-promotion: I've been working on identifying some less
obvious patterns at http://pminten.github.io/
On 09/12/2013 02:40 PM, Saša Jurić wrote:
> I'll probably get bashed for this, but I'll say it anyway: I hate style
> guides.
> The ones I have been involved with were usually concerned with low-level
> aesthetic details, which I find less relevant in the grand scheme of things.
>
> For me, it's almost irrelevant whether a developer writes
> {:a, :b}
> or
> { :a, :b }
>
> Sure, it may bug me a little when looking at the inconsistent code, but
> it's equally easy to read both versions.
>
> That said, I think Peter raised interesting point in the original post:
>
>> a very practical guide to solving common problems*.
Dave Thomas
Sep 12, 2013, 11:25:01 AM9/12/13
to elixir-l...@googlegroups.com
Folks:
My strong suggestion—let's stop talking about style and instead let's all write some code. Lots of it. Tens of thousands—hundreds of thousands—of lines.
And, more importantly, let's all read other people's code. Take note of what you like and don't like. Incorporate those observations into your own work.
If we all do this, a good style will evolve over time. At that point, and if you all still feel the need, our collective experience can be captured in a document.
In the meantime, the only truth is code.
Dave
pe medeiros
Sep 12, 2013, 4:29:58 PM9/12/13
to elixir-l...@googlegroups.com
totally agree with Dave.
I think is too early and the community is still growing. Now at the beginning I think is more important to grow into codes and tools.
But I'd also love to have some unofficial guide written by someone else. Only with his own insights about style .
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
Pedro Henrique de Souza Medeiros
----------------------------------
Cel: +55 (61) 9197-0993
Email: pedr...@gmail.com
Beautiful is
better than ugly,
Explicit is better than implicit,
Simple is better than complex,
Complex is better than complicated.
The Zen of Python, by Tim Peters
Christopher Keele
Sep 12, 2013, 4:57:10 PM9/12/13
to elixir-l...@googlegroups.com
I think collecting personal insights that was the gist of my proposal, but on reflection I can see it wading towards Wadler's law.
> In the meantime, the only truth is code.
Love this!
Nicholas Faiz
Sep 12, 2013, 7:19:19 PM9/12/13
to elixir-l...@googlegroups.com, da...@pragprog.com
+1.
On a side note, while I like Effective Go, there's another way to create technical documentation worth considering. A subsection of Node community has been working on this for some time - https://github.com/substack/stream-handbook . There's nothing stopping you from picking a particular topic in Elixir and writing a 'How to' on it, and sharing it as a work in progress.
On a side note, I find a lot of #elixir-lang activity goes on in other timezones. If anyone else in AEST is hacking on Elixir, let me know. I'm using it most weekends. I usually lurk on freenode as nicholasf or nicholas_
Cheers,
Nicholas
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
Chris Keele
Sep 17, 2013, 12:26:15 PM9/17/13
to elixir-l...@googlegroups.com, peter....@online.nl
When we do get to a more advanced Elixir patterns book/guide/site, instead of Effective Elixir or mezzoelixir, can we call it the Codex? Because that's a wicked perfect name.
Reply all
Reply to author
Forward
0 new messages