It's not duplicate syntax. `func` adds a named function to the current environment, and `->` only describes an anonymous function. It's the equivalent of `function foo(...)` vs `function(...)` in JS.
Can you not `func(foo){}`? Because that is what would bother me.
`func(foo){}` and `(foo) ->` seem too similar, for my taste at least. Sure, the difference is that one is always anonymous, where as one is sometimes anonymous.. but we've been using `function` as both named and anonymous for ages
Sorry, I don't want to blame any frameworks in particular. There's already too much bad blood in scala land. Let's just say there have been many instances where I had a really hard time understanding a piece of code and it turned out there was an implicit conversion hidden somewhere out of sight that was the missing piece of the puzzle, and in most instances there would have been a simpler design without implicits. Most great pieces of software, such as unix, are great not because they use very complicated concepts but because of how simple they are. Finding that simplicity is the key. Very frequently people don't see the importance of simple things like the presence of hints in code to where the related pieces are. Implicits break this flow. The number of places implicit conversions can be defined at is mind boggling. And even when some code doesn't use implicits the possibility of implicits does harm. When you don't understand some code, well who knows there may be an implicit conversion in play.
At least in Java, non-final variables can't be used inside anonymous inner classes. Also, it's easier for me as a developer to read "final" and know that (referential) immutability is guaranteed by the compiler instead of having to read the local scope, which likely contains method calls that may or may not modify that variable.
val and final have stronger meanings when your objects are immutable. True immutability makes reasoning far easier than just referential immutability.
> At least in Java, non-final variables can't be used inside anonymous inner classes.
Aren't those members/fields not variables? If so, then those are effectively global not local, so that's a completely different story – I'm talking strictly about local variables.
> True immutability makes reasoning far easier than just referential immutability.
Yep, immutable types and constant global bindings are great.
I still don't understand why you consider having a compiler-enforced restriction on mutation worse than letting readers figure out what was the developer's intent.
In Java, the only "downside" is having to add "final" as a modifier, which is negligible.
In Scala, the alternative is to declare that variable as "var" instead of "val". When would you ever choose var over val if your object isn't supposed to mutate?
That's just a weird wart of Java – not allowing anonymous inner classes to close over non-final variables was just a cheat to avoid having to implement proper closures; I have no idea what the technical impediments to doing so were when that decision was made, but plenty of languages, including Scala, have real closures.
> In Scala, the alternative is to declare that variable as "var" instead of "val". When would you ever choose var over val if your object isn't supposed to mutate?
It's an extra keyword, an extra complication in the language – one more binary choice to multiply with all the other options. It would be nice to get rid of the distinction altogether.
In Scala, there are both mutable and immutable data structures. Immutable data structures are preferred, however there are some cases in which a dash of mutability can simplify the code, especially in cases where Java inter-op is a must.
Not mentioned here: pattern matching. It certainly goes a long way to ensure all cases are being handled, since the compiler lets you know when your patterns are non-exhaustive.
"Yes, you can write more concise code; yes, you have a more advanced type system; yes, you can pattern match. There are hundreds of other reasons that Scala makes a great language. When a language can offer me constructs to write more correct code, I'll always be willing to deal with the learning curve."
I think the point was that these are the things that he thinks are of more value to developers than the other good things that Scala offers.
I thought it was worth mentioning as a separate point; just saying "you can pattern match" doesn't say much, when it's actually a key feature to guarantee certain correctness in a program.
Pattern matching offers mainly correctness and conciseness, maybe the correctness part should have been emphasized more.
The author never mentions artistic merit, presumably because it's a result of his premise. If you can't cheat at art, it's because there's nothing to cheat for, so there's no such thing as artistic merit.
I don't quite agree with your conclusion as written, because I think you can make the point that purely skill-based efforts do not have artistic merit. For instance, the frozen fish packager in an assembly may not be seen as having artistic merit in the his or her endeavors. This is because the effort is not creative, but following a process. It is not meant to provide any aesthetic value or entertainment, but is meant to achieve another objective.
On the other hand, if you mean that nothing intended as art can lack artistic merit, making the concept of "artistic merit" useless in that context, then I fully agree.
I couldn't imagine myself doing that somewhere with little room, like a crowded elevator or subway. The functionality is nice, but it looks utterly ridiculous.
It's not the same to be observed by some invisible or unknown entity than to be observed directly by a person. Someone pointing a digital camera at a person is usually more disturbing than a CCTV camera doing the same thing.
Also, Google Glass may be constantly recording in private places usually without CCTV: homes, dinner tables, meetings, etc.
In my opinion, both are equally disturbing. CCTV often though we don't notice, don't have a choice, or can't as easily express, "WTF is your problem" towards the obnoxious person recording us without consent and clearing exactly what they plan to do with these recordings. When buying stuff at the store, the store does not offer my the option of consent regarding their ubiquitous camera systems. However, the hope is that the camera systems in this context will not be used to exploit, ridicule, or manipulate my very thoughts. With a person I am interacting with, the odds are not as good, but consent of interaction is also easier to withdraw without seriously affecting my ability to survive. I can choose to interact with people who aren't constantly recording me, if I prefer.
Myself I like making field recordings of nature sounds. I've noticed though that a lot of people are concerned when I pull out my Zoom field recorder and start recording them during conversations. They generally don't like it. I don't blame them. I don't like it either. So I either record discretely (which is illegal in many states) or not at all. I don't blame them for not wanting me to record their private conversations though, because their concerns and their desires to have a private conversation are completely legitimate.
