Hi everyone!
Since a sizable portion of the Flink code is now in Scala (and more is coming in the API projects), I think we need to define a few guidelines for Scala programming. Scala is very powerful and has a lot of "magic" features that allow you to design killer nice APIs, but also make reasoning about code harder. Through the use of implicit parameters, lazy parameters, overriding of base operators, functions that take code blocks, etc, you can easily write code that does something entirely different than what it looks like initially. For APIs, I think we should embrace the power of these features to make the APIs nice, convenient, and with intuitive syntax. After all, the elegance of the API matters a lot. For the runtime or anything below the APIs, I propose to refrain to a large extend from the magic features. For those parts, I think it matters most that the code is predictable, it is easy to understand the implications for also non-expert Scala programmers, and it is possible to peer review it through GitHub (where you do not see a difference between a lazy or an eager parameter). One example of such a change would be https://issues.apache.org/jira/browse/FLINK-1548 Summary: Be magic in the APIs, be explicit and simple in the runtime. Greetings, Stephan |
+1 to the idea
I suppose no really action item for FLINK-1548? Maybe add doc about contributing to Scala portion? On Saturday, February 14, 2015, Stephan Ewen <[hidden email]> wrote: > Hi everyone! > > Since a sizable portion of the Flink code is now in Scala (and more is > coming in the API projects), I think we need to define a few guidelines for > Scala programming. > > Scala is very powerful and has a lot of "magic" features that allow you to > design killer nice APIs, but also make reasoning about code harder. > Through the use of implicit parameters, lazy parameters, overriding of base > operators, functions that take code blocks, etc, you can easily write code > that does something entirely different than what it looks like initially. > > For APIs, I think we should embrace the power of these features to make the > APIs nice, convenient, and with intuitive syntax. After all, the elegance > of the API matters a lot. > > For the runtime or anything below the APIs, I propose to refrain to a large > extend from the magic features. For those parts, I think it matters most > that the code is predictable, it is easy to understand the implications for > also non-expert Scala programmers, and it is possible to peer review it > through GitHub (where you do not see a difference between a lazy or an > eager parameter). > > One example of such a change would be > https://issues.apache.org/jira/browse/FLINK-1548 > > Summary: Be magic in the APIs, be explicit and simple in the runtime. > > Greetings, > Stephan > |
I thought about adding a wiki page for that.
On Sat, Feb 14, 2015 at 7:16 PM, Henry Saputra <[hidden email]> wrote: > +1 to the idea > > I suppose no really action item for FLINK-1548? Maybe add doc about > contributing to Scala portion? > > > On Saturday, February 14, 2015, Stephan Ewen <[hidden email]> wrote: > > > Hi everyone! > > > > Since a sizable portion of the Flink code is now in Scala (and more is > > coming in the API projects), I think we need to define a few guidelines > for > > Scala programming. > > > > Scala is very powerful and has a lot of "magic" features that allow you > to > > design killer nice APIs, but also make reasoning about code harder. > > Through the use of implicit parameters, lazy parameters, overriding of > base > > operators, functions that take code blocks, etc, you can easily write > code > > that does something entirely different than what it looks like initially. > > > > For APIs, I think we should embrace the power of these features to make > the > > APIs nice, convenient, and with intuitive syntax. After all, the elegance > > of the API matters a lot. > > > > For the runtime or anything below the APIs, I propose to refrain to a > large > > extend from the magic features. For those parts, I think it matters most > > that the code is predictable, it is easy to understand the implications > for > > also non-expert Scala programmers, and it is possible to peer review it > > through GitHub (where you do not see a difference between a lazy or an > > eager parameter). > > > > One example of such a change would be > > https://issues.apache.org/jira/browse/FLINK-1548 > > > > Summary: Be magic in the APIs, be explicit and simple in the runtime. > > > > Greetings, > > Stephan > > > |
+1
2015-02-15 17:47 GMT+01:00 Stephan Ewen <[hidden email]>: > I thought about adding a wiki page for that. > > On Sat, Feb 14, 2015 at 7:16 PM, Henry Saputra <[hidden email]> > wrote: > > > +1 to the idea > > > > I suppose no really action item for FLINK-1548? Maybe add doc about > > contributing to Scala portion? > > > > > > On Saturday, February 14, 2015, Stephan Ewen <[hidden email]> wrote: > > > > > Hi everyone! > > > > > > Since a sizable portion of the Flink code is now in Scala (and more is > > > coming in the API projects), I think we need to define a few guidelines > > for > > > Scala programming. > > > > > > Scala is very powerful and has a lot of "magic" features that allow you > > to > > > design killer nice APIs, but also make reasoning about code harder. > > > Through the use of implicit parameters, lazy parameters, overriding of > > base > > > operators, functions that take code blocks, etc, you can easily write > > code > > > that does something entirely different than what it looks like > initially. > > > > > > For APIs, I think we should embrace the power of these features to make > > the > > > APIs nice, convenient, and with intuitive syntax. After all, the > elegance > > > of the API matters a lot. > > > > > > For the runtime or anything below the APIs, I propose to refrain to a > > large > > > extend from the magic features. For those parts, I think it matters > most > > > that the code is predictable, it is easy to understand the implications > > for > > > also non-expert Scala programmers, and it is possible to peer review it > > > through GitHub (where you do not see a difference between a lazy or an > > > eager parameter). > > > > > > One example of such a change would be > > > https://issues.apache.org/jira/browse/FLINK-1548 > > > > > > Summary: Be magic in the APIs, be explicit and simple in the runtime. > > > > > > Greetings, > > > Stephan > > > > > > |
+1
On Mon, Feb 16, 2015 at 3:18 PM, Fabian Hueske <[hidden email]> wrote: > +1 > > 2015-02-15 17:47 GMT+01:00 Stephan Ewen <[hidden email]>: > >> I thought about adding a wiki page for that. >> >> On Sat, Feb 14, 2015 at 7:16 PM, Henry Saputra <[hidden email]> >> wrote: >> >> > +1 to the idea >> > >> > I suppose no really action item for FLINK-1548? Maybe add doc about >> > contributing to Scala portion? >> > >> > >> > On Saturday, February 14, 2015, Stephan Ewen <[hidden email]> wrote: >> > >> > > Hi everyone! >> > > >> > > Since a sizable portion of the Flink code is now in Scala (and more is >> > > coming in the API projects), I think we need to define a few guidelines >> > for >> > > Scala programming. >> > > >> > > Scala is very powerful and has a lot of "magic" features that allow you >> > to >> > > design killer nice APIs, but also make reasoning about code harder. >> > > Through the use of implicit parameters, lazy parameters, overriding of >> > base >> > > operators, functions that take code blocks, etc, you can easily write >> > code >> > > that does something entirely different than what it looks like >> initially. >> > > >> > > For APIs, I think we should embrace the power of these features to make >> > the >> > > APIs nice, convenient, and with intuitive syntax. After all, the >> elegance >> > > of the API matters a lot. >> > > >> > > For the runtime or anything below the APIs, I propose to refrain to a >> > large >> > > extend from the magic features. For those parts, I think it matters >> most >> > > that the code is predictable, it is easy to understand the implications >> > for >> > > also non-expert Scala programmers, and it is possible to peer review it >> > > through GitHub (where you do not see a difference between a lazy or an >> > > eager parameter). >> > > >> > > One example of such a change would be >> > > https://issues.apache.org/jira/browse/FLINK-1548 >> > > >> > > Summary: Be magic in the APIs, be explicit and simple in the runtime. >> > > >> > > Greetings, >> > > Stephan >> > > >> > >> |
+1
On Mon, Feb 16, 2015 at 3:38 PM, Aljoscha Krettek <[hidden email]> wrote: > +1 > > On Mon, Feb 16, 2015 at 3:18 PM, Fabian Hueske <[hidden email]> wrote: > > +1 > > > > 2015-02-15 17:47 GMT+01:00 Stephan Ewen <[hidden email]>: > > > >> I thought about adding a wiki page for that. > >> > >> On Sat, Feb 14, 2015 at 7:16 PM, Henry Saputra <[hidden email] > > > >> wrote: > >> > >> > +1 to the idea > >> > > >> > I suppose no really action item for FLINK-1548? Maybe add doc about > >> > contributing to Scala portion? > >> > > >> > > >> > On Saturday, February 14, 2015, Stephan Ewen <[hidden email]> > wrote: > >> > > >> > > Hi everyone! > >> > > > >> > > Since a sizable portion of the Flink code is now in Scala (and more > is > >> > > coming in the API projects), I think we need to define a few > guidelines > >> > for > >> > > Scala programming. > >> > > > >> > > Scala is very powerful and has a lot of "magic" features that allow > you > >> > to > >> > > design killer nice APIs, but also make reasoning about code harder. > >> > > Through the use of implicit parameters, lazy parameters, overriding > of > >> > base > >> > > operators, functions that take code blocks, etc, you can easily > write > >> > code > >> > > that does something entirely different than what it looks like > >> initially. > >> > > > >> > > For APIs, I think we should embrace the power of these features to > make > >> > the > >> > > APIs nice, convenient, and with intuitive syntax. After all, the > >> elegance > >> > > of the API matters a lot. > >> > > > >> > > For the runtime or anything below the APIs, I propose to refrain to > a > >> > large > >> > > extend from the magic features. For those parts, I think it matters > >> most > >> > > that the code is predictable, it is easy to understand the > implications > >> > for > >> > > also non-expert Scala programmers, and it is possible to peer > review it > >> > > through GitHub (where you do not see a difference between a lazy or > an > >> > > eager parameter). > >> > > > >> > > One example of such a change would be > >> > > https://issues.apache.org/jira/browse/FLINK-1548 > >> > > > >> > > Summary: Be magic in the APIs, be explicit and simple in the > runtime. > >> > > > >> > > Greetings, > >> > > Stephan > >> > > > >> > > >> > |
+1
Good point. In general, keeping the common/runtime as simple as possible is quite important > On 16 Feb 2015, at 16:05, Till Rohrmann <[hidden email]> wrote: > > +1 > > On Mon, Feb 16, 2015 at 3:38 PM, Aljoscha Krettek <[hidden email]> > wrote: > >> +1 >> >> On Mon, Feb 16, 2015 at 3:18 PM, Fabian Hueske <[hidden email]> wrote: >>> +1 >>> >>> 2015-02-15 17:47 GMT+01:00 Stephan Ewen <[hidden email]>: >>> >>>> I thought about adding a wiki page for that. >>>> >>>> On Sat, Feb 14, 2015 at 7:16 PM, Henry Saputra <[hidden email] >>> >>>> wrote: >>>> >>>>> +1 to the idea >>>>> >>>>> I suppose no really action item for FLINK-1548? Maybe add doc about >>>>> contributing to Scala portion? >>>>> >>>>> >>>>> On Saturday, February 14, 2015, Stephan Ewen <[hidden email]> >> wrote: >>>>> >>>>>> Hi everyone! >>>>>> >>>>>> Since a sizable portion of the Flink code is now in Scala (and more >> is >>>>>> coming in the API projects), I think we need to define a few >> guidelines >>>>> for >>>>>> Scala programming. >>>>>> >>>>>> Scala is very powerful and has a lot of "magic" features that allow >> you >>>>> to >>>>>> design killer nice APIs, but also make reasoning about code harder. >>>>>> Through the use of implicit parameters, lazy parameters, overriding >> of >>>>> base >>>>>> operators, functions that take code blocks, etc, you can easily >> write >>>>> code >>>>>> that does something entirely different than what it looks like >>>> initially. >>>>>> >>>>>> For APIs, I think we should embrace the power of these features to >> make >>>>> the >>>>>> APIs nice, convenient, and with intuitive syntax. After all, the >>>> elegance >>>>>> of the API matters a lot. >>>>>> >>>>>> For the runtime or anything below the APIs, I propose to refrain to >> a >>>>> large >>>>>> extend from the magic features. For those parts, I think it matters >>>> most >>>>>> that the code is predictable, it is easy to understand the >> implications >>>>> for >>>>>> also non-expert Scala programmers, and it is possible to peer >> review it >>>>>> through GitHub (where you do not see a difference between a lazy or >> an >>>>>> eager parameter). >>>>>> >>>>>> One example of such a change would be >>>>>> https://issues.apache.org/jira/browse/FLINK-1548 >>>>>> >>>>>> Summary: Be magic in the APIs, be explicit and simple in the >> runtime. >>>>>> >>>>>> Greetings, >>>>>> Stephan >>>>>> >>>>> >>>> >> |
Moved this to the Wiki:
https://cwiki.apache.org/confluence/display/FLINK/Coding+Guidelines+for+Scala On Mon, Feb 16, 2015 at 4:29 PM, Paris Carbone <[hidden email]> wrote: > +1 > > Good point. In general, keeping the common/runtime as simple as possible > is quite important > > > On 16 Feb 2015, at 16:05, Till Rohrmann <[hidden email]> wrote: > > > > +1 > > > > On Mon, Feb 16, 2015 at 3:38 PM, Aljoscha Krettek <[hidden email]> > > wrote: > > > >> +1 > >> > >> On Mon, Feb 16, 2015 at 3:18 PM, Fabian Hueske <[hidden email]> > wrote: > >>> +1 > >>> > >>> 2015-02-15 17:47 GMT+01:00 Stephan Ewen <[hidden email]>: > >>> > >>>> I thought about adding a wiki page for that. > >>>> > >>>> On Sat, Feb 14, 2015 at 7:16 PM, Henry Saputra < > [hidden email] > >>> > >>>> wrote: > >>>> > >>>>> +1 to the idea > >>>>> > >>>>> I suppose no really action item for FLINK-1548? Maybe add doc about > >>>>> contributing to Scala portion? > >>>>> > >>>>> > >>>>> On Saturday, February 14, 2015, Stephan Ewen <[hidden email]> > >> wrote: > >>>>> > >>>>>> Hi everyone! > >>>>>> > >>>>>> Since a sizable portion of the Flink code is now in Scala (and more > >> is > >>>>>> coming in the API projects), I think we need to define a few > >> guidelines > >>>>> for > >>>>>> Scala programming. > >>>>>> > >>>>>> Scala is very powerful and has a lot of "magic" features that allow > >> you > >>>>> to > >>>>>> design killer nice APIs, but also make reasoning about code harder. > >>>>>> Through the use of implicit parameters, lazy parameters, overriding > >> of > >>>>> base > >>>>>> operators, functions that take code blocks, etc, you can easily > >> write > >>>>> code > >>>>>> that does something entirely different than what it looks like > >>>> initially. > >>>>>> > >>>>>> For APIs, I think we should embrace the power of these features to > >> make > >>>>> the > >>>>>> APIs nice, convenient, and with intuitive syntax. After all, the > >>>> elegance > >>>>>> of the API matters a lot. > >>>>>> > >>>>>> For the runtime or anything below the APIs, I propose to refrain to > >> a > >>>>> large > >>>>>> extend from the magic features. For those parts, I think it matters > >>>> most > >>>>>> that the code is predictable, it is easy to understand the > >> implications > >>>>> for > >>>>>> also non-expert Scala programmers, and it is possible to peer > >> review it > >>>>>> through GitHub (where you do not see a difference between a lazy or > >> an > >>>>>> eager parameter). > >>>>>> > >>>>>> One example of such a change would be > >>>>>> https://issues.apache.org/jira/browse/FLINK-1548 > >>>>>> > >>>>>> Summary: Be magic in the APIs, be explicit and simple in the > >> runtime. > >>>>>> > >>>>>> Greetings, > >>>>>> Stephan > >>>>>> > >>>>> > >>>> > >> > > |
Free forum by Nabble | Edit this page |