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
Ghost
@ghost~54f4b69115522ed4b3dcb16d
The #ifdef idea is something that might show up in policy someday, so that would be another lack of parity, aside from trailing commas.
Ichoran
@Ichoran
Well, it's complicated because the justification for f(x,y,z,) is because it is hard to edit otherwise.
That kind of says, "editor issue" to me.
If an easy language fix is enough to get around a difficult editor problem that affects everyone, that's not a bad thing, though.
Nobody I've heard has said that f(x, y, z, ) is easier to read or makes more sense.
soc
@soc
I think people need to fix their editors. They can display/show whatever they want as long as it doesn't end up in the source code.
hell, I always let ScalaIDE show semicola, even if I never write them down.
Ichoran
@Ichoran
So my view is that people need to do a better job arguing just how bad it is to edit that, and just how hard it is to make editors that can do it right. Then I'd be more likely to buy the argument that it's worth it to change the language.
soc
@soc
@Ichoran +1
this is way more disruptive and way more pointless than SIP-12
Ichoran
@Ichoran
I don't know. I'm willing to be convinced that this is a substantial gain with modest pain. But I haven't heard that argument spelled out at all. It's mostly, "yeah, I find putting commas where they belong a little annoying", to which "yeah, and I find reading all those trailing commas annoying" is a perfectly adequate counterargument.
What is the use case where one is spending a substantial fraction of one's time struggling with commas? Is this really the best solution?
Dale Wijnand
@dwijnand
I don't even know if this is a sane alternative to consider, but what would either (or better, both) of you feel if it were restricted to multi-lines?
Ichoran
@Ichoran
And, you know, it's not just commas. You have the same problem with ++ and so on.
soc
@soc
+1. I think editors can place/display commas and semicola wherever they want. That's perfectly fine, I just don't want to read them.
Ichoran
@Ichoran
It would at least be less disruptive if it was restricted to multi-lines. I read the lines, not the commas, in any case then.
eugene yokota
@eed3si9n
one of the arguments I see is trailing commas (or leading in that sense) makes diff easier to read or makes merges easier. not sure if those are substantiated claims.
soc
@soc
then people need to fix their tools
eugene yokota
@eed3si9n
DBA in my last company I worked was huge fan of leading commas for writing SQL
soc
@soc
"let's change the language because diff sucks" is an awful argument
Ichoran
@Ichoran
Anyway, I have a train to catch. And the compiler is a tool, @soc, so the question is in which tool the fix belongs, which is a question both of difficulty and appropriateness of domain.
soc
@soc
I have already seen the damage to code style caused by that. I want to have less of that, not more.
Dale Wijnand
@dwijnand
btw, there's a whole list of explanations, examples and justifications in the "Motivation" part of the document: https://github.com/scala/scala.github.com/pull/533/files#diff-f9e653a64fed5a100070a5f4df282048R23
soc
@soc
@Ichoran what I meant is that people need to fix the tools that are broken, not change a completely unrelated tool as a workaround.
Dale Wijnand
@dwijnand
then let's take out inferred semicolons?
not scalac's fault there either
soc
@soc
I'd be perfectly happy to remove semicola from the language
there are some places which require semicola which makes this troubling
Dale Wijnand
@dwijnand
No, I said remove inferred semicolons, ie. put semi-colons back into the language, like Java, because that's also your tools fault, not scalac's.
soc
@soc
I like to see the semicola, that's why I have cofigured my IDE to show them
why?
eugene yokota
@eed3si9n
so there's only one way to write Scala
soc
@soc
that doesn't mean I want to have them in the source code everywhere. same for commas.
hopefully. we are getting there.
Dale Wijnand
@dwijnand
what's wrong with having them in the source code?
get your tool to not show them to you
actually, all your tools
soc
@soc
see? because they are only relevant when I'm actually editing my code. just like trailing commas. let the IDE show them if you want.
eugene yokota
@eed3si9n
to dangle or not could be up to each project/company using style enforces, no?
soc
@soc
that's exactly why I don't want this additional variation.
this language will be the laughing stock for all detractors. Scala's marketing is bad enough already. I'd at least have one month in a year where we didn't produce embarrassing news.
Dale Wijnand
@dwijnand
it shouldn't be scalac's responsibility to infer semicolons for you, you should fix your tools to deal with them.
and while we're at it, write your types, scalac's done with inferring those too, fix your tools.
soc
@soc
this is nonsense
Dale Wijnand
@dwijnand
it's your argument
soc
@soc
no, it's not.
Dale Wijnand
@dwijnand
taken to the extreme you don't want
eugene yokota
@eed3si9n
LISP has very regular syntax, but ppl laugh exactly about that. can't control ppl
Dale Wijnand
@dwijnand
You don't want to fix all your tools to deal with semi-colons and types, you want scalac to infer those for you, well I'm done with micro-managing commas all the time in comma-separated elements, and I would like scalac to deal with it instead of me. You know, it's the computer..
soc
@soc
Scala infers line endings. that it signifies those infered line endings with semicola is a legacy artifact.