> whatever dumb writer You're new to this HN thing? Steve Yegge is kind well known around this here parts... Also you seem to be responding to the (meant as joke) title, not TFA.
> You're new to this HN thing? No, not really. > Steve Yegge is kind well known around this here parts... Well, I haven't noticed. > Also you seem to be responding to the (meant as joke) title, not TFA. Actually, to TFA as well. His arguments are trivial generics without much substance. Such articles irritate me greatly.
> articles
Ah, see, a Yegge blog post isn't an article, it's an essential touchstone of the computer geek experience. You don't get persuaded by his arguments, but instead… delighted, filled with whimsy, and joy?
sarcasm off, his posts also fall south of my reading:substance ratio
the title has been made politically correct - the actual title is "Why Kotlin Is Better Than Whatever Dumb Language You're Using". I wonder if that was intentional editorial oversight.
> Sometimes they do exactly what you need, and 70% of the time they're just totally useless. I thought that but PyCharm scores way better than 70%. I even trust it to do automatic refactors. Sometimes... > The zippiness on reaction to my typing is another huge deal. If it's anything other than instantaneous, then I notice my editor in a negative light. Maybe I grew up on IDE's but I type stuff in full only if autocom…
I think I'm pretty sensitive to even a minor typing delay. That's not necessarily true for everybody, but it irks me. > I even trust it to do automatic refactors. Sometimes. Function extract refactors and the like are definitely within the realm of possibility. Once you want to refactor code across many files it becomes a lot harder in dynamically typed code, for sure. I guess for a long time I sort of had this view…
More often snippets like this can be even more straightforward:
var somestuff = from x in someList
where x.Id > 7
select x.Name
> for non-static languages like Python, they're just not very good Yup. Because they can't. Without type annotations, IDE's are pretty much incapable of offering automated refactorings without human supervision (and yes, that includes Smalltalk IDE's). They can give you some primitive auto completion and navigation, but that's pretty much it.
> Yup. Because they can't. Actually they can. > incapable of offering automated refactorings without human supervision > (and yes, that includes Smalltalk IDE's) Patently false. Everyone repeat after me: automated refactoring was invented on Smalltalk with the Refactoring Browser. Again. Automated refactoring was invented on Smalltalk with the Refactoring Browser. The lack of static type information was considered a…
Well, he/she isn't saying anything about smalltalk, but talking about python. Are you sure these two pose the same problems when it comes to automated refactoring? Apart from just lack of static typing, these languages could be miles apart when it comes to how dynamic they are and what problems this poses to automated refactoring. For example, the fact that attribute access in python can be delegated to a function that will receive the attribute name as an argument and decide whether that object has this attribute or not and what it is, or the fact that you can dynamically generate a new class whose attribute names and implementation come from outside as function arguments. How would you deal with automating the renaming of such an attribute when it is defined and used across wildly varying circumstances. I have no idea if smalltalk can do this, or even if my examples are good examples of showcasing the automated refactoring problem, but just raising a point.
i wonder what server side platform are they using ? there's been a lot of buzz around vertx+kotlin or Reactor ... and with android support, it is a very compelling stack to have for android focused startups.
if they begin to build first class hooks for tensorflow in kotlin (as they might already have, considering Tensorflow Lite on android), i think it could replace python as the first language for data scientists.
I worked on a commercial project that used Scala. Never again. Compiles were slow, IDE support was terrible, everyone had their own subset they used. I'm sure it's improved since 2010.
I work on a large Scala team. We use microservices so my regular compile times are somewhere between 4s and 20s. I rarely have to do a full rebuild. IDE support is bad, that's a good criticism but a good chunk of us don't use IDEs, and instead write it like a dynamic language. Live inside the REPL, copy paste back and fourth. As for 'subsets' everyone uses, I find this advantageous. Our team strongly encourages a pur…
Scala IDE support is bad? What IDE are you using?
I find IDE support in IDEA almost on par with that of Java. It is very fast, has accurate error highlighting, very good smart autocomplete, understands advanced Scala features, supports most refactoring I care of, but most importantly works reliably.
> Yup. Because they can't. Actually they can. > incapable of offering automated refactorings without human supervision > (and yes, that includes Smalltalk IDE's) Patently false. Everyone repeat after me: automated refactoring was invented on Smalltalk with the Refactoring Browser. Again. Automated refactoring was invented on Smalltalk with the Refactoring Browser. The lack of static type information was considered a…
Well, he/she isn't saying anything about smalltalk, but talking about python. Are you sure these two pose the same problems when it comes to automated refactoring? Apart from just lack of static typing, these languages could be miles apart when it comes to how dynamic they are and what problems this poses to automated refactoring. For example, the fact that attribute access in python can be delegated to a function th…
> isn't saying anything about smalltalk
Very specifically was: "(and yes, that includes Smalltalk IDE's)"
> Yup. Because they can't. Actually they can. > incapable of offering automated refactorings without human supervision > (and yes, that includes Smalltalk IDE's) Patently false. Everyone repeat after me: automated refactoring was invented on Smalltalk with the Refactoring Browser. Again. Automated refactoring was invented on Smalltalk with the Refactoring Browser. The lack of static type information was considered a…
Automatic refactoring in dynamic languages are nowhere need to those in java. Just rename method - with static typing you know it was changed correctly everywhere, full stop. Implementation of refactoring code is easy. With javascript, you just don't know what can potentially come in as argument of function, so you don't know whether object function call can or can not be renamed. Smalltalk authors seeing static typi…
Please: re-read the comment and preferably the links as well. Once again: automatic refactoring tools were invented on Smalltalk.
> Smalltalk authors seeing static typing as major potential problem
Authors saw lack of static typing as a major potential problem. It just wasn't. Again: reading helps. A lot.
I've started to come around on a similar thought recently, after a few years avoiding static typing in python. I've been toying with C# specifically. C# with visual studio is, I think, the most productive environment I've come across in programming. It's ergonomically sound, straightforward, and the IDE protects me from all sorts of relevant errors. Steve mentioned Intellij is a bit slower than he'd hope typing somet…
Once you manage to get the shortcuts, create a few "Views" it gets even better.