Scala Plenary Meeting Report 2011/10/04

10 replies

Tue, 2011-10-18, 13:25

adriaanm

Joined: 2010-02-08,

This summary is intended for Scala contributors and maintainers, and assumes a certain familiarity with Scala's internals.
It is for your information only, provided “AS IS” with no warranties and it confers no rights (okay, if you ask nicely we'll think about it).

Scala Plenary Meeting Report 2011/10/04 (apologies for the delay)

Attending

Luc: fixes for generics, more bugfixing
Nada: lms javascript, simple example working
Grzegorz: Scala+GWT+IDE hacking and interview with Phil, (with Nada) recursive functions work in lms, we draw Koch snowflakes using canvas
Adriaan: continuous builds for virtualized-scala, finished up typedReifiedNew, documenting virtualized-scala to get ready for PEPM2012 tool paper (with Tiark)
Vlad: working on a submission for PEPM2012 (workshop of POPL)
Tiark: Delite struct flattening / struct of array <-> array of struct transform
Frederik: presentations for Typesafe
Tom: from Tubingen in Germany, research of database supported program execution, developed Ferry (used by Chris)
Vojin: hacking delite and lms, merged Tiark’s work on loop folding
Philipp: working on source contexts, talk next week
Lukas: upgrading jira and fisheye (review tool)
Chris: returned yesterday, starting off database integration in scala
Miguel: support for clr genericsEugene: macro proposal, more details, split the proposal into several parts: core vs other (see https://github.com/xeno-by/kepler/tree/master/papers for more details)
Stefan: setting up stuff, project Sliq (relational database project)
Phil: typesafe stuff, paper on vector concat, scala-lang pages, working with Greg on GWT
Martin: reflection and staging, this week project planning, teaching
Heather: thread pools cleanup, students, semester projects, translating slides for programmation avancee
Manohar: benchmarking resources - establish how to deal with very different benchmarks - none of the targets have similar
Toni: company stuffAlex: teaching, specialization tickets, meetings with students. Hacking on Delite with Vojin while working on collections support.
Trond: training coursesIulian: build infrastructure is now built and served from our own servers, moved source code to github, beta11
Paul: driving around solving misteries in his van :) - performance work in case classes,
Tiark: hacking delite

Discussion

GitHub move status [adriaan]
what’s the ETA? which repo will it be based on? (I’m sitting on a lot of forks of scala/scala)
I set up Jenkins for scala-virtualized using my github repo (jenkins monitors integration branch, merges it into master and pushes back to github when ant build is successful), if we know which repo we’ll be using, can’t we start doing this already (stay with ant but move to github)
That is, if SBT build is not around the corner?

Disclaimer: the git plugin for jenkins is usable (by complementing it with the github plugin) but not great (merging integration branch into master and pushing back is a little rough: will need to hack plugin to disable pushing jenkins’s internal tags to github); they’re working on a rewrite, no idea about the ETA of that one, of course.
Discussion:

Regarding the scala/scala rewrite: Any chance to also fix the comment style to be in line with the stdle guide? Afair the proposal to do that was shot down because of “we can't rewrite the whole source, every fork will break” last time ... so if exactly this rewrite is happening now it might make sense to include that.

Regarding JIRA and “move to Assembla?”:If we want to move from JIRA's “MBA-micromanages-work-of-developers”-style to a more developer-centered style, what about YouTrack? Wouldn't that more or less fit the requirements?

Regarding the scala/scala rewrite: Any chance to also fix the comment style to be in line with the stdle guide? Afair the proposal to do that was shot down because of “we can't rewrite the whole source, every fork will break” last time ... so if exactly this rewrite is happening now it might make sense to include that.

If you have a command that works against all versions of Scala, I'm willing to try it. As of now, I can't rewrite all history here without breaking the build-ability of all history.
Currently we will be fixing some whitespace formatting issues and end of line styles.

Regarding JIRA and “move to Assembla?”:If we want to move from JIRA's “MBA-micromanages-work-of-developers”-style to a more developer-centered style, what about YouTrack? Wouldn't that more or less fit the requirements?

Regarding the scala/scala rewrite: Any chance to also fix the comment style to be in line with the stdle guide? Afair the proposal to do that was shot down because of “we can't rewrite the whole source, every fork will break” last time ... so if exactly this rewrite is happening now it might make sense to include that.

What's the recommended style in the guide? Generally, I would be skeptical that we need conformity here. Comment style is probably the least of our standardization worries. I am totally easy with reading different versions of doc comments. In fact, they might all have their place. It's like insisting on blank lines or forbidding them. Depending on the context, blank lines can increase or decrease readability. One size does not fit all.

Speaking as a novi (novi === newbie), without a dog in the matter (except that I'd like scaladoc to support runnable @example [even as compiled to javascript] and I'd like it to do what Swing knew it needed, namely, a way to express "slices" of a fat interface [for pedagogic purposes, at least]):

I noticed somewhere the recommendation for the * aligned at the second star of /**. I assumed it was another Martinism, like "+ (no space intervening) for string concat (though in fact he abjures the new scaladoc alignment).

My contribution to the conversation: as an adopter, it actually helps me to have mnemonic cues that I'm "not in Kansas anymore."

When I switched from C to Java, switching from K&R braces (where vi's ]] works) reminded me what I was up to. My method braces are also line-ending, and it seems somehow pathetic when I see them on the next line.

Similarly, in adopting Scala, I follow Martinisms such as "+ religiously because it tells my brain which language my fingers are typing (where typing means "striking keys on a keyboard", and not what a typechecker does).

This issue is especially acute when coding as a novi in both Java and Scala. Just switching from "Foo foo" to "def foo: Foo" (while trivial) results in a certain number of "argh"-edit-recompile moments each day.

My reaction to the "new scaladoc convention": Isn't that odd, but look, it makes perfect sense, because the indentation aligns with that other Scala convention, :se tabstop=2. (I.e., the stars align with my method code.)

It's worth noting that four-space indentation looks legacy to me now.

Recall that in C, tabs were useful because they would print (on paper, which one never uses these days) at ts=8, but at ts=4 on a CRT. In these latter days, ts=2 (albeit tabs converted to spaces). This is a powerful cue (to the brain, or whatever subsystems thereof) that we are coding in Scala and not in legacy languages.

In this spirit, /** This method does something * that will blow your mind
*/ def foo: Foo = { something() mindBlowing // aligns with doc stars }is cognitively useful. Just as one likes to write a one-liner function if possible, one writes a one-liner doc comment (for the same reason, brevity) but later expands it by hitting <return> and writing more words.

I was raised to ensure my C code was "self-documenting." I would propose that Scala's putative "dearth of documentation" is really a search for the sweet spot of self-documentaton, with many one-liners and occasional multi-liners. Long docs are probably really @examples.

The old song goes, "Everything's up-to-date in Kansas City," so maybe one doesn't want a cue that one isn't in Kansas anymore.