Hacker News new | ask | show | jobs
by dboreham 1736 days ago
The comments about Scala resonated. I've been working in a a large Scala codebase for the past few months. I've become a partial fan of the language, however: there have been multiple conversations like : (in screen share with colleague) "See that double right arrow there? What's that mean? (after attempts to find answer in books, SO, etc, and trying to guess based on the three/four other uses the language makes of double right arrow that I've already grokked). Colleague: "Uhh, dunno, beats me".

On reflection, I think if the Scala creators had been a bit less obsessed with symbology and had either a) used keywords rather than symbols more often or b) consistently only ever used a symbol for the same one purpose; the outcome would have been significantly better.

There are just too many symbols to cover them all in a short book or cheat sheet, and symbols are very SEO-unfriendly. And even if you do find the relevant medium article, it's not necessarily clear that you're looking at the same use case for that particular symbol.

7 comments

I've been a Scala and FP developer since 2009ish and it suffered initially from over-enthusiasm to make it seem 'futuristic' as a rejection of the overly verbose reality of enterprise java codebases.

There's been a lot of sensible work in the core codebase since then to move towards more coherent idioms, unfortunately the 'we can make Scala into Haskell' crowd have since taken up the mantle and everyone has become obsessed with the idea that no boilerplate starter project is complete without cats or similar which perpetuates barely-legible and unnecessary confusion in situations that should be simple.

If you can't use an IDE to jump to the definition (or list all possible definitions) of a function, then aren't you missing one of the main benefits of a statically-typed language? If you can't use the static types for static analysis, what's the point?
You can indeed jump to the method definition in IDEA, although getting the IDE to a good point of dealing with implicits, typeclasses, and their ilk has been a long road.
Jump to definition is not some special benefit of static typing. Every Common Lisp IDE that I know of offers it, for example.
Jump to definition is only one part of static analysis. Typechecking is another, performance is a third one.
You can't jump to the definition of something that's essentially a keyword in the form of a symbol.
Compile time verification of correct syntax and spelling is important aspect
> I think if the Scala creators had been a bit less obsessed with symbology

This might not be something to pin on the language designers, if you're using certain third-party libraries. Indeed it is possible to name a method pretty much whatever you want, with some constraints[0]. Wanna call it "!^"? Go ahead! But, this is afoul of the naming convention in many cases[1]--acknowledging that the convention may have previously been a bit more lax in this regard.

OTOH the distinction between "::" and ":::", and the implications of stuff like "<:" often do require a refresher if they're not part of one's day-to-day.

[0] https://stackoverflow.com/questions/7656937/valid-identifier... [1] https://docs.scala-lang.org/style/naming-conventions.html

A house is leaking from the roof.

If the language designers allow methods named "!^", then someone will actually name a method "!^".

Most languages allow a variable called "i", but it is for the programmer to choose when that is appropriate.

!^ might be useful, if the code implements an algorithm which uses this notation in the literature.

A hoarder never throws anything away because it "might be useful". That is not a useful criteria for choosing language features.
I think variables names and infix operators/method names are very different.
> A house is leaking from the roof.

Should one prefer the case where an adult cannot order a steak, because a baby can't chew it? Like, there is a grammar for acceptable identifiers, and it is a little broader than most. To me it seems like a good thing that unicode/multibyte identifiers are allowed, and that not more than the necessary portion of the top keyboard row symbols is reserved.

Yes, I'd like to have a beer with the people who think it's smart to allow punctuation as identifiers. Hopefully by the third pint I could change their minds...
Not a scala programmer, but I searched for "scala cheatsheet" and got the answer:

https://docs.scala-lang.org/cheatsheets/

Double arrow seems to have multiple uses - for anonymous functions (like in js) and for pass-by-reference arguments (I guess scala is pass-by-value by default).

(Surprised at how Erlang-y it feels, especially WRT pattern matching)

As noted in the parent, I read the cheat sheet. It doesn't cover the use case for => I was trying to understand.

The best (but still not exhaustive) doc is : https://stackoverflow.com/questions/7888944/what-do-all-of-s...

Sure but the issue is that when a single symbol has multiple meanings that presents an obstacle to learning the language and understanding a code base.
How do you feel about = (assignment and equality check)? Or > which can be used for markup or less than or part of a function arrow? Or {} which can be used as a block or as an object? Or : which can be used for...so many things! Even the humble . can be used to dereference or as a decimal point. My point is that if "a symbol having multiple meanings" is a problem, then basically all languages have a problem.
Obviously that's a bad idea, which is why many languages don't overload = with two purposes.

{} always means "group of related stuff"

: always means : (sic) separator between a thing and something about the thing.

Well Java isn't too bad in that regard. It uses = for assignment and == for equality.
I wonder if clojure codebase found a right balance there. Hickey made it explicit to have short but very obvious nouns except a few macros)
I think it's more library authors that are to blame than the language author. He merely opens the gate for that kind of overloading, maybe too liberally.
I don't think symbols necessarily need to be SEO friendly. I think Google just doesn't treat them as well as they could?
They need to be google-friendly, or they need to exist in a world where code-friendly search tools exist.
Isn't that the same thing?