+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 <trohrm...@apache.org> wrote: > > +1 > > On Mon, Feb 16, 2015 at 3:38 PM, Aljoscha Krettek <aljos...@apache.org> > wrote: > >> +1 >> >> On Mon, Feb 16, 2015 at 3:18 PM, Fabian Hueske <fhue...@gmail.com> wrote: >>> +1 >>> >>> 2015-02-15 17:47 GMT+01:00 Stephan Ewen <se...@apache.org>: >>> >>>> I thought about adding a wiki page for that. >>>> >>>> On Sat, Feb 14, 2015 at 7:16 PM, Henry Saputra <henry.sapu...@gmail.com >>> >>>> 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 <se...@apache.org> >> 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 >>>>>> >>>>> >>>> >>
