Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Kotlin Is Better

steve-yegge.blogspot.com

Post reply on HN
Print view View original

181–190 of 229 posts

Re: Kotlin Is Better

#181

Post by whateveracct »

thr0waway1239 wrote: post #92
runT1ME wrote: post #74

Earlier quoted context omitted.

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…

You might have actually convinced people to not consider Scala. You are saying, Scala is great, except for these small things: 1. Modify your codebase to use microservices 2. Modify your IDE habits to be more REPL friendly 3. Modify your team coding habits even if it makes it hard for one person to work on the other person's codebase.

Also, re: 1...you don't have to use microservices. You just need non-monolithic compilation units. This just means breaking up your application into library code that doesn't need re-compilation.

GF mentioned microservices because they end up forcing this by design, but nowhere does it say "you must use microservices or else get horrible compile times"

Re: Kotlin Is Better

#182

Post by whateveracct »

mateuszf wrote: post #115
whateveracct wrote: post #97

Earlier quoted context omitted.

But the thing is if you modify your habits, it's so much more efficient than most other languages. It's reasonable to have to learn knew coding style when paradigm-shifting languages. Why isn't it reasonable for there to be other new behaviors as well?

Because there are other languages, which also provide the benefits, but without these downsides.

Hah no there aren't. I work in Haskell (one of the few languages that is as or more efficient as Scala) and these things still arise with it. And they're not a problem because you do them and you end up programming better than in a language without these things :)

Re: Kotlin Is Better

#183

Post by hota_mazi »

mpweiher wrote: post #79
hota_mazi wrote: post #67

Earlier quoted context omitted.

> 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…

> > (and yes, that includes Smalltalk IDE's)

> Patently false.

It's a mathematical fact.

Without type annotations, refactorings are never safe and need supervision from a human.

Did you notice that the "Refactoring Browser" calls itself just that, not "Automatic"?

Because it can't provide that guarantee. Even renaming a function is dangerous and can break a program when you don't have type annotations.

I have a lot of respect for Smalltalk and the pioneering work it accomplished, but the refactoring browser was just a powerful string replacement engine, nothing more. Which is not a knock on the engineers and scientists who invented it: it simply, mathematically, could not do more than that.

Re: Kotlin Is Better

#184

Post by fauigerzigerk »

Larrikin wrote: post #177
fauigerzigerk wrote: post #172

Earlier quoted context omitted.

What's the advantage of extension functions compared to plain functions? fun String.shout() = this + "!!!" fun shout(s: String) = s + "!!!" Looks pretty much the same to me. Extension functions use static dispatch so what's the point of using member syntax? Also, extension functions can be overwritten by a member function with the same signature. That seems quite fragile to me considering the class and the extension…

I use extension functions on classes I don't own to add functionality I think the class should have had or would be extremely useful for my project if a certain type of class had the functionality. Your example would require a static utility class in Java or an object in Kotlin to use every where, the extension functions can just be inside of a kotlin file. So the difference would be in Kotlin object StringUtilClass(…

That surprises me. I would have thought that you could do this in Kotlin just as you can in Java with static import:

  import StringUtilClass.*
  shout("I'm mad")

Re: Kotlin Is Better

#185

Post by runT1ME »

apta wrote: post #164
runT1ME wrote: post #74

Earlier quoted context omitted.

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…

> We use microservices so my regular compile times are somewhere between 4s and 20s. What framework or library are you using to write said services?

Scalaz, Http4 for web stuff, Netty/scalaz-stream otherwise. We really don't need "frameworks" to be insanely productive in Scala, just a few tried and true libraries. This also really helps when jumping into new projects, there's never "magic" beyond just the features the language provides.

Re: Kotlin Is Better

#186

Post by mpweiher »

irishsultan wrote: post #170
mpweiher wrote: post #109

Earlier quoted context omitted.

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.

This may depend a lot on coding style and uniformity of coding conventions, something likely to be the case on the Smalltalk system (as it was designed by a small and focussed team) and less likely to be the case on a system using many different libraries, some of which might have names conflicting with names you use. Even then you still need manual supervision in that it may work in 99% of the cases, but for a parti…

Yours is first and foremost a theoretical argument. The authors of the Refactoring Browser and I understand these theoretical concerns (about not having static type safety). However, there is theory and there is practice. The two are not identical, and practice trumps theory (see also: science). And in practice, that theoretical concern appears to not have been an issue.

You also argue with hypotheticals (may...depend, likely be the case etc.). Why is that so? Is it because you can't accept that reality doesn't conform to your theory?

Once again: the argument was "you can't". That is as patently false as can be, in reality is it not just "you most definitely can", but "this system is extremely well suited for building this type of tool and in fact the whole category was invented on that system".

And your theoretical concerns notwithstanding, people who have actually used the system consider it best-of-breed.

A scientific approach adapts theory to observation. Theology adapts observation to theory.

Re: Kotlin Is Better

#187

Post by Larrikin »

fauigerzigerk wrote: post #184
Larrikin wrote: post #177

Earlier quoted context omitted.

I use extension functions on classes I don't own to add functionality I think the class should have had or would be extremely useful for my project if a certain type of class had the functionality. Your example would require a static utility class in Java or an object in Kotlin to use every where, the extension functions can just be inside of a kotlin file. So the difference would be in Kotlin object StringUtilClass(…

That surprises me. I would have thought that you could do this in Kotlin just as you can in Java with static import: import StringUtilClass.* shout("I'm mad")

Personally I find that less clear where shout is coming from and how to use it. It would also make autocomplete less useful as mentioned

Re: Kotlin Is Better

#188

Post by mpweiher »

hota_mazi wrote: post #183
mpweiher wrote: post #79

Earlier quoted context omitted.

> 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…

> > (and yes, that includes Smalltalk IDE's) > Patently false. It's a mathematical fact. Without type annotations, refactorings are never safe and need supervision from a human. Did you notice that the "Refactoring Browser" calls itself just that, not "Automatic"? Because it can't provide that guarantee. Even renaming a function is dangerous and can break a program when you don't have type annotations. I have a lot o…

> Without type annotations, refactorings are never safe

There is a difference between "I can prove this is safe" and "this is safe". You guys need to start figuring out the difference between theory and practice.

Re: Kotlin Is Better

#189

Post by smichel17 »

specialist wrote: post #162
Tharkun wrote: post #156

Yet Another Java Rant. In my book, Java is a fine language, and has been since Java SE 6 was released back in 2006. It keeps getting better, too. "Glacial" pace or not. Whenever any kind of discussion about Java comes up, people start ranting about XML configuration or annotations. These are not language problems. These are developer problems. If you don't like XML or annotations, then don't use them. Problem solved.…

Kotlin (Ceylon, C#, Nice, Boo, Groovy, etc) isn't better. Just different. What I want, as a devoted Java partisan, is a Java (Oak) experiment do-over. More more and less less. A fantasy hypothetical effort I call Encore™. What are the sources of programming errors? Engineer them away. What causes the most boilerplate? Engineer those away. I've got a laundry list that I've collected over the years. Maybe I'll scrub it…

Why do you think data classes are dumb? The only thing I think they're missing is an automatic method to serialize to JSON or other text format, eg, so they can be easily stored in an android preference.

Re: Kotlin Is Better

#190

Post by ubertaco »

mpweiher wrote: post #79
hota_mazi wrote: post #67

Earlier quoted context omitted.

> 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…

Here's the thing: guided, interactive refactoring is not the same as automatic refactoring. If I can hit a button to inline all usages of a method (as in IntelliJ), that's not the same as using a tool that can point out candidate locations for inlining what might be the method.

Furthermore, the reason Smalltalk pulled all this off is because it is/was metadata-heavy. Every object could be interrogated about its shape and capabilities (in the form of asking about its "slots"), even though there were no static type annotations. It's sorta like the runtime-typing stuff done by Dialyzer in the Erlang/Elixir world nowadays, and the tooling and code all ran together in the same runtime/VM instance.

Clearly this is not the case for Python, Ruby, or Javascript, where the tooling runs in a separate process from the code, and there's very little metadata that tooling can query without just up and executing the whole program. In fact, this particular lack of metadata is why PEP-484 exists (https://www.python.org/dev/peps/pep-0484/) adding "type annotations" that are really just runtime metadata hints.

So no, a language without static typing or metadata is not as tooling-friendly as a language with such requisite available analyzable information, and certain categories of refactoring cannot confidently be done automatically.

Smalltalk was not as "loose" as Javascript or Python, not by a long ways. The level of metaprogramming it was capable of was only enabled by the level of metadata it made available to its hybrid, in-process runtime/design-time tooling.

Post reply on HN