apple swift

[juan_gandhi]

So, with the new "Apple language", object-oriented Java people are going to do what?
There must be some deep philosophy, explaining why they are so retarded.
I think.

I mean, I kind of heard an explanation from Josh; in my translation it sounds like this: "Java programmers are not very smart anyway, let's not overload them with closures and all that stuff."

The correlation I was writing about lately kind of shows itself again.
Weird.

Well, it's not Scala, of course; but it's a nice step in the right direction, I think.

Comments

[alamar.livejournal.com]

Well, now we've got lambdas, why complain?

I haven't seen apple language but I assume it is an unsafe toy that calls native libraries on every cough? Do not want.

[garote]

Hmm? What do you mean by "unsafe"?

[dmytrish.livejournal.com]

No, it has borrowed from modern languages surprisingly much (http://www.reddit.com/r/programming/comments/274t5s/apple_swift_programming_language_unveiled/chxgtfh), at the first glance I see a lot of things from Rust: no-nil-values, structured enums like functional ADTs, static compilation, type inference, so underrated C# nullable values (Int?, ?. operator), generics (hi to lame Go!), the right approach to mutability (to ditch it as much as possible or to limit it at least), etc, etc.

In general, languages designed by Apple may often be elitist and highly experimental (Dylan as ThinkDifferentLisp, Objective-C with its strong flavor of Smalltalk, very human AppleScript, etc), so I would not expect Swift to be just another scripting language hacked on top of C run-time.

[garote]

I was particularly surprised to see closures appear. So far I've only been using them in Javascript and Perl, but my experience has been that they are about 15% added flexibility for about -40% readability. That is, they make it harder to tell what's going on, more than they reduce development time.

[dmytrish.livejournal.com]

Closures may be not The Comfortable Thing and not the nostrum to be used everywhere, but they're The Right Thing to have because of their theoretical profoundness. SICP explain in depth how to use them to build higher-level primitives.

[garote]

A higher level primitive ... how might that differ from an ordinary C++ class?

[vaddimka.livejournal.com]

Closures are bad! The Great Oracle forbids it!

[fatoff.livejournal.com]

Эппль-свифт, то для гурманов. Опять вокруг меня всё эпплем заставлено, ответственно заявляю, пока что у них Обжектив-Си есть краеугольный камень, интенсивно и беспроблемно мешаемым прямо в том же файле с Си-Плас-Плас.

[migmit.livejournal.com]

Very interesting. No monads or continuations, which is a shame, but seems to be a decent language anyway.

[thedeemon.livejournal.com]

Swift has classes and inheritance, Java people should feel fine about it.

[mikkim08.livejournal.com]

I mean, I kind of heard an explanation from Josh; in my translation it sounds like this: "Java programmers are not very smart anyway, let's not overload them with closures and all that stuff."

Допустим. А что означает в данном случае "not very smart" ? Не поймут, что такое closures и не будут их использовать вообще или будут их использовать неправильно, что приведет к дополнительным багам ?

[freedom_of_sea.livejournal.com]

да кложуры есть те же самые объекты с состоянием внутри. Ты их делаешь (конструктор) и потом вызываешь. Проверив что не нуль. Даже фабрики делают для кложуров. Иногда скажут - гляди вот новое...
А по сути со времен C callbacks ничего новоого и нет. foreach map и grep вот и все что привнесла функциональщина

[dkfl.livejournal.com]

разве это не просто замена AppleScript?

[thedeemon.livejournal.com]

ํНет, это Objective-C замена.

[sassa-nf.livejournal.com]

думаю, третье: "хер его знает, чем это обернётся!"

[alamar.livejournal.com]

I mean that your program may segfault due to error in library or your code, or corrupt data. And that's the end of the show.

[migmit.livejournal.com]

I really want to see the language that makes it impossible. So far, I haven't seen one. Well, except Malbolge.

[alamar.livejournal.com]

Well, it's very hard to actually crash JVM or corrupt memory unrelated to the task at hand. Your code might malfunction but all the other code in the system will live on.

[migmit.livejournal.com]

> Your code might malfunction but all the other code in the system will live on.

Which is exactly what happens when something segfaults, so what's the difference?

[alamar.livejournal.com]

No. After segfault you can't assume your process is in working condition.

With JVM this is not the case, any number of exceptions doesn't hurt the whole process.

[dmytrish.livejournal.com]

Ну так выкатили это чудо буквально позавчера.

[dmytrish.livejournal.com]

Я бы скорее сказал, что классы — это такие усложненные замыкания с сабтайпингом.

[migmit.livejournal.com]

> With JVM this is not the case, any number of exceptions doesn't hurt the whole process.

You mean, "process" in the OS sense? Who cares, JVM not failing is exactly the same as the OS not failing.

[alamar.livejournal.com]

No, it's not exactly the same. It's not even nearly the same.

OS is a loose coupling of processes, while JVM program is a tight mess of interacting services.

OS only has kill switch that allows it to destroy whole processes losing everything inside. JVM ensures every service inside behaves well so there's no reason to hard-kill everything. The worst thing you normally see is an exception. This allows for very different architectures than unsafe platforms permit.

[migmit.livejournal.com]

> OS only has kill switch that allows it to destroy whole processes losing everything inside. JVM ensures every service inside behaves well so there's no reason to hard-kill everything. The worst thing you normally see is an exception.

Again: what's the difference between "hard-killing" the misbehaving OS process and unhandled exception killing the misbehaving service?