Live data from Hacker News

Swift is like Kotlin

nilhcem.com

331–340 of 364 posts

Re: Swift is like Kotlin

#333

Earlier quoted context omitted.

Well, you already have java formal verification tool named Bandera http://bandera.projects.cs.ksu.edu/people.shtml (which name is obviously choosen by Oksana Tkachuk, one of the tool authors)

As a native Spanish speaker I'm not aware of any negative connotations of the word bandera . In Spanish it just means "flag", so any other meaning is hard to google for. What am I missing? Just curious.

one (Google Images): https://www.google.ru/search?q=bandera+una+unso&num=20&newwi...

two (Wikipedia): https://en.wikipedia.org/wiki/Stepan_Bandera

If you want to piss off a clinical... eww, not a russian, but a post-soviet russian-speaking citizen of Russian Federation (with a little putin in his head), you may place a Stepan Bandera photo on your userpic and name youself as ukrainian nationalist.

If you want to piss off a real ukrainian nationalist, you may use a Stalin phono, or any other communist leaders.

From the point of sight of normal people, both of these sides is braindead. "A plague on both your houses".

Re: Swift is like Kotlin

#334

Earlier quoted context omitted.

> Here in Ukraine it would be very hard to get adoption of a programming language that is named after a Russian military base. Well, except if you are an Ukrainian of Russian descent and root for the (ex)home team...

Which is actually not the case for most Ukrainians of Russian descent: Most of ethnic Russians in Ukraine signed for the Ukrainian army, fighting against Putin’s invasion, against the same Russians that came from the other side. (from http://marginalrevolution.com/marginalrevolution/2017/05/con... . Note the source is Kasparov, who is not an entirely unbiased source where Russia is concerned ;))

Well, it's a big question - what is real "ethnic" russian. It's like an "ethnic USA citizen".

Re: Swift is like Kotlin

#335

Earlier quoted context omitted.

I get your point now. Yes, it is read-only, not immutable. For me, I only need read-only. I think kotlin wasn't meant to be pure functional. I see it as object oriented with some functional programming. out of curiosity, what cases will you use an immutable collection instead of a read-only? I cannot imagine any use case where immutable is a gain over read-only.

"Read-only" would not implement structural sharing. Consider the situation where you had a linked list with 10,000 elements and you wanted to return a new list with one new element added to the 'head' of the list. With "read-only" you would literally have to make a new linked list with 10,001 elements which would kill performance. While semantically correct, immutability via deep-copying is very impractical. So, immu…

Sorry, I don't see the difference. With read-only you can create a new object which is the first element of the list and also points to the rest of the list. Instead of an structure you have an "immutable" object.

Re: Swift is like Kotlin

#336

Earlier quoted context omitted.

You now have https://github.com/Kotlin/kotlinx.collections.immutable

Cool. This needs to be built into the language or somehow standardized by the community. With lack of standardization of immutable collections, there would be lots of different ways that libraries would implement immutability. This would result in losing one of the main benefits of functional programming (i.e. awesome composability).

This is already in the language. It is just an interface which makes the common lists only visible as immutable objects. But inside they are a normal list. And in this case the object is read-only, not immutable, as we were discussing in the other comment thread.

Re: Swift is like Kotlin

#337

Earlier quoted context omitted.

"Read-only" would not implement structural sharing. Consider the situation where you had a linked list with 10,000 elements and you wanted to return a new list with one new element added to the 'head' of the list. With "read-only" you would literally have to make a new linked list with 10,001 elements which would kill performance. While semantically correct, immutability via deep-copying is very impractical. So, immu…

Sorry, I don't see the difference. With read-only you can create a new object which is the first element of the list and also points to the rest of the list. Instead of an structure you have an "immutable" object.

Yes, but the resulting object is not a "List" and hence would not inter-operate with any function that took a List as input.

In essence if the original object implements a List _interface_, then the new one should as well. If you do all of this, then you've essentially implemented immutability and structural sharing. But then you have to do this for 10 other Collection types as well.

Now, you could do all this, but I could do it as well and do it differently. Then my function which took MyList as argument would not interoperate with your function that wants to pass YourList as argument.

Something as fundamental as an (immutable) collection needs to be standardized so that all functions can take these and return them and thus compose easily.

This is the case with languages that implement immutability like Elixir, Haskell etc.

Re: Swift is like Kotlin

#338

Earlier quoted context omitted.

Cool. This needs to be built into the language or somehow standardized by the community. With lack of standardization of immutable collections, there would be lots of different ways that libraries would implement immutability. This would result in losing one of the main benefits of functional programming (i.e. awesome composability).

Well, that is part of the Kotlin project itself, so I assume it is or will be built in, should the proposal succeed.

Not sure about the governance model of Kotlin. Hopefully it succeeds.

Re: Swift is like Kotlin

#339

Earlier quoted context omitted.

Why are you citing an FP comp Sci professor? I must've missed something

seeing reduce in swift made me think about the universality of fold, which is the paper linked.

Ah, was about to say that all goes back to lambda calculus by Church and could be found in Lisp probably around ~1958.

Re: Swift is like Kotlin

#340

Earlier quoted context omitted.

Is the Native AOT compiled, or just a different byte code VM? I assume the latter?

The Kotlin/Native compiler produces standalone executables that can run without any virtual machine. > https://blog.jetbrains.com/kotlin/2017/04/kotlinnative-tech-...

Nice...if only a good REPL, I could finally leave Python.
Post reply on HN