511–520 of 573 posts
Earlier quoted context omitted.
... or you could just move to coffeescript and have something even more clay-like than python running everywhere.
its still javascript with its quirky behavior in the end.
Earlier quoted context omitted.
The point on having Swift on other platforms means you can write software for things other than iOS/OSX. It's a fun, modern language that brings A LOT to the table that js/py/rb don't (type checking and the ability to distribute binaries, for starters).
But programmers don't want better languages[0]. Programmers mostly just want what they already have. You can't overcome that kind of resistance just by saying "look, here's a language that's more fun and modern". Programmers say they want better languages, but good luck trying to convince them to switch to a new language just by its merit. The only tangible benefit of Swift is that it can be used instead of Objective…
> But programmers don't want better languages
With TypeScript and/or ES6(7)+Babel. These have a pretty healthy userbase between them and there's a lot of excitement around ES6 which leads me to think that developers do want better languages.
Also... I want a better language. I'm not sure how you'll convince me otherwise and I don't think I'm alone in this sentiment.
Do they want a "different" language... maybe, maybe not. I suppose my comment about Apple "positioning" (and I'm careful to use that word) Swift as a replacement to Javascript can make a lot of sense to Apple and people who develop for iOS and OS X.
Firstly, Apple doesn't need buy in from other browser vendors. They can supply a Swift runtime with Safari (desktop and mobile) and I think it would be no more difficult to write a Swift to ES5 transpiler than it is to write an ES6/7 to ES5 transpiler, meaning that web devs can be agnostic about what browser their web app is running on and make demote Javascript to simply being a build task.
Secondly - Swift is going to have a lot of developer support. Because native apps are are increasingly dependent on a corresponding Web API - I think it's reasonable to expect people to be happy about sharing code between the front and back ends of their apps. I think nodes biggest advantage over any other server-side languages is that I can use node packages in both place.
Thirdly - I don't think Apple really cares wether "web developers" have an issue with this. They care about providing tools and solutions for people who develop for and use their platforms. If they can make the case that Swift is going to be "better" than Javascript by some metric we don't know right now, then that's what they'll do. Everyone else can go cry in a corner.
Also, Down-votes? Really? It's not the most radical idea in the world and I fail to see how someone could take offence from it.
PS: Apologies but I don't have time to watch that video right so I hope I haven't got the wrong end of the stick.
Earlier quoted context omitted.
> They can interoperate through OS-level abstractions like pipes and via C APIs on at the process level. And you can't do this in OSX or iOS? > The average Unix desktop or server is probably running code written in 5-10 languages, more or less transparently to the user The average iPhone is probably running code written in just as many (if not more) languages - C, C++, Obj-C, Swift, and Javascript are a given before…
Sandboxing is a pretty big modulo. I actually don't have any opinion on how many languages have 'first-class' support on iOS. My understanding is that it's somewhat more complicated to create natural-seeming bindings from other languages to Objective-C APIs than it would be for C APIs, and that there are restrictions in the type of applications you can distribute using other languages (no downloadable code outside th…
Earlier quoted context omitted.
If you use Scala for your view layer, why would you even want to use Go for your back end?
Very true. I am starting to not see the point of Go. It's about the same performance as the JVM languages and the JVM is just as easy to deploy. On the JVM you get to choose between Clojure, Scala, Ruby, Groovy, Kotlin, and more. JVM is just as easy to deploy as a Go binary too. Personally, I plan to stick with JVM languages plus Rust.
Open the rosettacode web site. Choice any algorithm you are familiar with. Place Go version and Java version. Compare the number of words and lines.
Compare the Maven hell with how Go solves the same problems.
Earlier quoted context omitted.
Very true. I am starting to not see the point of Go. It's about the same performance as the JVM languages and the JVM is just as easy to deploy. On the JVM you get to choose between Clojure, Scala, Ruby, Groovy, Kotlin, and more. JVM is just as easy to deploy as a Go binary too. Personally, I plan to stick with JVM languages plus Rust.
Here is how to see the point of Go: Open the rosettacode web site. Choice any algorithm you are familiar with. Place Go version and Java version. Compare the number of words and lines. Compare the Maven hell with how Go solves the same problems.
This places Swift right along Golang and Rust as the new interesting language.
I toyed with implementing Swift on the JVM (which is very doable by the way). The problem I've found with Swift is the minute size of the standard library. This has forced a large amount of Swift libraries to make calls to Objective-C/Cocoa classes libraries which makes it very non-portable. I haven't checked any time recently, but if a large, stable, swift-specific stdlib were to emerge then I believe it could defin…
Earlier quoted context omitted.
Kotlin is positively awesome, but when I tried it (admittedly last year) it didn't seem ready for production yet. It worked all well as long as stuff was kept simple, then I used Realm.io, wrote some unit tests and got all sorts of NoClassDefFoundError exceptions, dexmaker errors etc. Long story short, I couldn't fix it. As I said, it's been a while. I hope things have been improving and continue to improve. The lang…
It's pretty damn closed to 1.0. They just released M12 which adds support for interop with Java libs that use annotation processing such as Dagger.
Earlier quoted context omitted.
The fact that I don't use OSX has been a barrier to getting better at iOS development. Hackintoshing has proven to be quite elusive and the vmware and vbox USB layers in Linux don't convince virtualized OSX enough to transfer over apps to my iDevices. I'm not convinced you can get to high quality by testing strictly on emulators. If anyone has an old mac that can run modern xCode (you probably know what this constitu…
Xcode is written Xcode, not xCode. Thank you and good night. ps. if you have any friends who work in Apple retail, twice a year or so they have a big clear out of some of the internal use machines. You can pick up fairly good machines for very very cheap. They had 2009 white MacBooks for 170 bucks or so the last time.
Earlier quoted context omitted.
Supporting Linux is a surprise, but I think it's a great move on their part. Think: How many iOS apps are frontends to a server API? And how many of those APIs are running on Linux servers? Swift on Linux means ~all the code for a client-server iOS app can be written in the same language.
I agree, with the type of growth Swift has shown in the past, there is going to be a big demand for Swift developers now. Swift could possibly rule the mobile/web. I have already added it on my #TODO list :)