<https://javamagic.blog/2018/05/29/kotlin-consider...
# feed
m
geez, there is almost 0 content in that post
👍 6
b
sooo data classes are harmful, but static variables are fine? at least be consistent.
t
I think many software devs like boilerplate and excessive engineering. It's like they enjoy unnecessary puzzles rather than solving a problem as effectively as possible.
d
None of the posts on the site that I saw had any content. Would be nice if the author went into details about his complaints, because it's hard to even critique them without the author providing context or reasoning.
h
link bait? such a trolling piece
🧌 4
t
I don't think this is a trolling piece. Just heavily biased and unsubstantial in content.
👍 1
h
Love reading these posts. Makes me feel less stupid 😆. Thanks thomas
e
Those people love doing unnecessary puzzles so that they feels like doing sth
v
Don't be quick to jadge. Maybe he is paid by the LOC
e
Oh damn you're right‼️
r
Another complaint about
val
,
var
,
let
, etc. when almost every new language uses local type inference…
h
Even java 10 does. Lol
😸 1
d
I think his complaint about var/val was specifically that they look visually similar, not due to type inference. Although when quizzed on when he ran into a problem with that similarity on Twitter he didn't have any examples.
p
I, a kotlin lover, would be able to write more content against kotlin than this...
4
x
^ yes, the var/val thing is that it's hard to read the difference The complaint about the data class thing is the lack of a static keyword, why annotate with @JvmField, the implication this is simply more boilerplate I feel like his arguments against the null stuff is pretty weak. It's like saying don't wear kevlar 'cause you can still get shot in an unprotected area.
r
If he wants visual clues, then that’s something an IDE is for… (better yet — don’t use var)
p
yes, I actually like the var/val thing, because that allows you to get used to always start with
va
and the decision of final or variable is just a character 😛
x
I will say, it's pretty weak argument... Heck I only use kotlin for gradle and I can come up with better reasons. Though I'm worried about abuse of local type inference in java... and I wish in java we had been given option for
var
to always be final... since most of the time I don't actually have a use case for a local variable to be nonfinal, and if I do... I usually would call that code smell. Reason I'm worried about inference is not all concrete classes are as clean as java's core ones, meaning I think we'll suddenly see methods being used, or seen that wouldn't normally be available if you were assigning to an interface. of all the features they could have chosen to add, this was the weakest one imho. I'd still much rather have had a way to define a property without all the boilerplate...
h
If I read this correctly, there's a complaint about
val/var
hard to read in
printed kotlin
. Wow, remind me of an old Software competition 10 years ago when we had to print our whole project's source code and submitted that thick book 😄