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

61–70 of 229 posts

Re: Kotlin Is Better

#61

Post by dmix »

gavinpc wrote: post #59
pje wrote: post #48

The "ew gross weird" reaction to Scala and Clojure is tremendously disappointing (especially coming from someone whose thesis is basically "give this new language a chance")

He was initially excited about Clojure, as a Lisp enthusiast, but as I recall he had a clash with the community about the direction of the language. https://groups.google.com/d/msg/clojure/JiK-WLFT65M/spBka_gs...

More context here:

https://news.ycombinator.com/item?id=2466731

With replies directly from Rich Hickey regarding Steve Yegge's "yes language".

Steve is certainly no stranger to Clojure.

Edit: also of interest in the discussion, Clojure is now #50 on TIOBE's top 50 list of languages. Notably OCAML didn't break #50 (or Common Lisp). I don't put much value in those lists personally but it does have economic value.

Re: Kotlin Is Better

#62

Post by flukus »

bitL wrote: post #43
marktangotango wrote: post #38

Earlier quoted context omitted.

So did Delphi handle dynamically resizing and positioning layouts? My impression is all the old highly productive gui languages (Delphi, Visual Basic, ...) used absolute positioning. Personally I'd rather have a more complex gui framework (css, swing, wpf) that handles positioning than to be forever cursed tweaking pixel width, height, x, y values.

Yes, if you set anchors on each component you wanted to be resizable (more specifically, all four sides could have had an independent anchor).

Same with winforms. I'm not sure if it was added at some point or always there, if it was always there I wish I knew about it a lot sooner.

Re: Kotlin Is Better

#63

Post by gavinpc »

dmix wrote: post #61
gavinpc wrote: post #59

Earlier quoted context omitted.

He was initially excited about Clojure, as a Lisp enthusiast, but as I recall he had a clash with the community about the direction of the language. https://groups.google.com/d/msg/clojure/JiK-WLFT65M/spBka_gs...

More context here: https://news.ycombinator.com/item?id=2466731 With replies directly from Rich Hickey regarding Steve Yegge's "yes language". Steve is certainly no stranger to Clojure. Edit: also of interest in the discussion, Clojure is now #50 on TIOBE's top 50 list of languages. Notably OCAML didn't break #50 (or Common Lisp). I don't put much value in those lists personally but it does have economic value.

Thanks, that's the one I was looking for.

Re: Kotlin Is Better

#64

Post by badminton1 »

icedchai wrote: post #54
pje wrote: post #48

The "ew gross weird" reaction to Scala and Clojure is tremendously disappointing (especially coming from someone whose thesis is basically "give this new language a chance")

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 think it has changed for good. There are also initiatives to simplify Scala (e.g: dotty), and initiatives to go native (e.g: Scala native via LLVM). I think Scala has some good potential.

Re: Kotlin Is Better

#65

Post by sidlls »

jayd16 wrote: post #41
sidlls wrote: post #18

Earlier quoted context omitted.

It's a pretty terrible design to couple activity state to the physical orientation of the device.

No, you don't understand. The state is serialized and stored. You might navigate away or pop into a windowed state. These things might rebuild your activity and the idea is your state should be serializable. The idea is every activity can be restarted outside of your control and your state should be fully storable.

No, I understand the Android Activity lifecycle quite well. I think it has severe flaws from a design perspective.

Re: Kotlin Is Better

#66

Post by zengid »

>How many languages can you name that were built with IDE support from the ground up?

Visual Studio Code is pretty nice with TypeScript. I've enjoyed having the autocomplete for my little Phaser game.

Re: Kotlin Is Better

#67

Post by hota_mazi »

bpicolo wrote: post #20

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…

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

Re: Kotlin Is Better

#68

Post by hota_mazi »

Scarbutt wrote: post #21
cromwellian wrote: post #14

The only problem with Steve's rant is that he starts out describing his experience with APIs, but then it turns into an issue of better languages. Presumably Kotlin doesn't wrap the entire Android API with some kind of better API, but most Android API calls would be direct Kotlin->Java calls, so how does Kotlin solve the nasty API issue? Really, this seems to be another Java critique by Steve. He's also written criti…

I was asking myself the same question, then he wrote: Kotlin manages to help you route around just about all of Android's Red Lights, and turns the experience into something that on the whole I now find superior to iOS development. I haven't done any android and don't know kotlin either, so maybe someone here who does can expand on this.

I think Steve is unjustly being harsh on the Android API, probably because he's not very experience with it, and I suspect that he'll be hard pressed to produce an example of an API that's completely ugly with Java but is somehow good with a Kotlin wrapper.

Re: Kotlin Is Better

#69

Post by hota_mazi »

sidlls wrote: post #18
jayd16 wrote: post #10

Earlier quoted context omitted.

It's hard to pass objects like that because it's a terrible idea. If you can't serialize the object then your state isn't stored and you'll possibly lose that object on a screen rotation and activity restart.

It's a pretty terrible design to couple activity state to the physical orientation of the device.

How would you do it?

Re: Kotlin Is Better

#70

Post by cromwellian »

andybak wrote: post #35
Scarbutt wrote: post #21

Earlier quoted context omitted.

I was asking myself the same question, then he wrote: Kotlin manages to help you route around just about all of Android's Red Lights, and turns the experience into something that on the whole I now find superior to iOS development. I haven't done any android and don't know kotlin either, so maybe someone here who does can expand on this.

And this paragraph: > I was first in line to throw the Android book at the wall and give up last summer, but now with Kotlin I'm finding Android programming is, dare I say it -- enjoyable? I think this suggests that Android's "bad" APIs weren't all that bad to begin with, but rather that Java has been masking Android's neat functionality with a bunch of Java-y cruft.

I don't think it's Java fault per se, just the API design. Java8 streams, RxJava, BufferKnife injection, Guava, etc are pretty nice to use, especially in combination with Java8. There's no async/await, but if you use ReactiveX, you don't really need it.

Kotlin looks very nice, I'm just pointing out that if the Android View/Fragment lifecycle design is an issue, language design isn't the cause or solution, and most likely, you will need a middleware/facade to mitigate it.

Post reply on HN