Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Sep 06 2018 15:12
    @scalabot banned @fommil
  • Apr 19 2016 20:35
    @SethTisue banned @urmila007
Li Haoyi
@lihaoyi
if you're willing to drop the "Scalite" part
we use Coffeescript at work and run into tons of issues with comma-inference
no commas and no curlies and no parens makes trying to figure out what's a multi-statement block and what's a multi-arg multi-line function absolute hell
basically everything you write will compile, but people's mind-parsers are forever confused and it was a distinct sticking point in our internal web-engineer happiness survey
Ichoran
@Ichoran
@som-snytt - Maybe the world doesn't use list notation for SBT because the SBT docs use Seq. Now that I realized that I ought to be able to use List, I think I'm going to do that from now on. My SBT mindset is usually "don't touch ANYthing or it might stop working".
@lihaoyi - But we aren't dropping everything and turning it into Python without commas. The only change I'm proposing is that where it's already syntactically obvious that you must have commas, because you're directly inside parens and you can never do anything but have a single expression or multiple expressions separated by commas, that comma inference use the semicolon inference rules that already work when the parens are braces.
Thanks for the info about Scalite. I had remembered not seeing much punctuation, but wasn't sure if you'd tried comma inference.
Li Haoyi
@lihaoyi
you asked about Scalite, which is dropping everything and turning it into Python :P
Ichoran
@Ichoran
Yes, I'm just pointing out that my proposal is less ambitious.
There's a feature we already use in one context that should work equally well in another, and the two contexts are disambiguated perfectly already as far as I can tell.
Li Haoyi
@lihaoyi
yeah I understand that
I bring up coffeescript just to say
it is possible for this to go too far
not sure if this is the case here - I haven't read all the way up - but it's a real concern
Ichoran
@Ichoran
Yeah. I have the same problem with Haskell. I get that you want to have brief punctuation for things you use often, but no punctuation whatsoever is kind of hard to read. I thought we worked this out in the 17th century or whatever.
Li Haoyi
@lihaoyi
FWIW my position is mildly positive on trailing commas (like it, don't care that much), and very positive on using .foo() notation on anything without some @infix annotation (that's the style I use myself and obviously everyone else should do the same thing)
at work, Coffeescript also allows you to leave off ()s when calling arbitrary functions, and the general consensus was DON'T DO THAT, with lots of strong feelings
for similar reasons why people didn't like inferred commas: even as an experienced engineer working with the code for a year, you'd still have trouble parsing it in your head
eugene yokota
@eed3si9n
I started out being indifferent about trailing commas, but I'm surprised to learn that most modern languages secretly allow them for array and map literals - https://github.com/scala/scala.github.com/pull/533#issuecomment-239039006
David Dudson
@DavidDudson
I agree with @infix seems like one of the best ideas I've heard proposed, my colleagues are extremely happy with this too. I've seen many new Scala developers think that "Scala supports infix, so why don't we just use it!"
You then get confronted with horrible code. Although I do like infix syntax for simple one declaration "FP operators" such as map and foreach(But I wouldn’t be too fussed if it went away). eg someList foreach println
I do not like chaining them (Unless the operator is symbolic) eg. a map b map c filter d
Ichoran
@Ichoran
You don't think that in practice the difference between having to opt in with @infix and not having infix notation at all would be minimal?
Li Haoyi
@lihaoyi
I view it like use-site vs declaration-site variance
Ichoran
@Ichoran
I view it like public access modifiers.
Or like const declarations in C++.
Li Haoyi
@lihaoyi
I actually prefer needing to explicitly public things like I had to in C#
rather than having it automatic in Scala
Ichoran
@Ichoran
It adds a lot of boilerplate to a lot of code.
Li Haoyi
@lihaoyi
it takes away a lot of boilerplate to an equally large amount of code :P
Ichoran
@Ichoran
I generally view a lot of private stuff as a code smell.
I do wish private[this] was called my, though.
Li Haoyi
@lihaoyi
no idea why you don't like private
Ichoran
@Ichoran
It disguises poor APIs and prevents reuse.
David Dudson
@DavidDudson
@Ichoran I think in practice a lot of libraries will depend on infix notation (scalatest, sbt, scalaz). I think it is a necessity in a lot of cases.
Ichoran
@Ichoran
Sometimes you have to do this, but I try to make them the exception, not the rule.
Li Haoyi
@lihaoyi
the big projects whose code quality I respect contain tons of private all over the place
Ichoran
@Ichoran
Don't you think there are a LOT more than 476 or whatever it was things that aren't private in scala-js?
I'm not saying that you shouldn't have things private! Just that if that's most of what you're doing that maybe something is wrong.
David Dudson
@DavidDudson
@Ichoran i disagree, your api should only be what the user needs to care about. if you have a builder class that builds animals, you want a single public method buildAnimal() and a bunch of private methods simplifying everything down
Ichoran
@Ichoran
@DavidDudson - I think that's true if building animals is radically unlike doing anything else. Otherwise, you should factor out the common functionality into something public, and just use it instead of building so much private infrastructure.
Li Haoyi
@lihaoyi
not sure what public/private has to do with infix operators
Ichoran
@Ichoran
Heh, just that you get what you say the default is.
And if the default is that you're not infix, basically very little will be infix.
Li Haoyi
@lihaoyi
how many infix operators do you think are defined in the scala-js/scala-js codebase? :P
akka/akka probably has more
but infix vs non-infix?
I'd guess maybe a 1:100 ratio
Ichoran
@Ichoran
If you take everything that's a Function1, and drop everything that requires a closure?
David Dudson
@DavidDudson
That low, i thought it would be more. I guess it is a library. In an application codebase id say it's more then 1:1000