Earlier quoted context omitted.
Only AdSense.
Isn't AdSense a pretty big deal within google?
Swift is like Kotlin
331–340 of 364 posts
Re: Swift is like Kotlin
#332Re: Swift is like Kotlin
#333Earlier 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.
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
#334Earlier 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 ;))
Re: Swift is like Kotlin
#335Earlier 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…
Re: Swift is like Kotlin
#336Earlier 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).
Re: Swift is like Kotlin
#337Earlier 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.
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
#338Earlier 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.
Re: Swift is like Kotlin
#339Earlier 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.
Re: Swift is like Kotlin
#340Earlier 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-...