911–920 of 970 posts
Earlier quoted context omitted.
the typing system seems to be from ecmascript as well var distance:Double = 70.0
This type annotation syntax comes from ML in the 70s (60s?).
Earlier quoted context omitted.
I'm not sure if you're kidding or not. IDE integration for a new language? They wrote it themselves. Do you think it would have been harder to integrate an existing language? Fast & native also also trivially solvable. I don't know about interop with Objective-C, that's probably the hardest part from your list. But complaining about IDE integration when they're also the creators of the IDE is... silly...
I see that you don't really understand what's needed for real IDE integration. Please, understand one of the main reasons of Apple creating Clang... (hint: because the GCC guys wouldn't take their patches to improve Objc-C & add facilities for IDE integration fast enough) Clang was easier to integrate with an IDE than GCC, and I strongly believe (after seeing what apple showed yesterday) that swift integration is eve…
As a detached Apple-related news follower, can some please update me: Is Swift going to become the new main development language for iOS?
If it's actually faster than Objective-C like Apple claims, then I'd bet on it, yeah.
Earlier quoted context omitted.
There's no real objective measure for either 'conciseness' or 'safety', in general terms. Whether or not it's faster in the real world is yet to be seen, and creeping featuritis has never been the hallmark of a great programming language. It makes good press release and marketing speak, but those assertions are a long way from making the OP 'wrong'.
There are objective measures. There aren't necessarily 'absolute' ones. Lisp is relatively more concise than C or Java for the same tasks. Java is relatively safer than C for the same tasks.
What is the advantage of "func funcName() -> returnType{ }" over "returnType funcName(){ }"?
func funcName() -> Int -> String { return { (i: Int) -> String in return i.toString() } }
Earlier quoted context omitted.
OS X handles some of this by assigning mnemonics to keyboard keys with the meta key (on mac keyboards, Option, or the "windows" key on the standard layout) held down. For instance, the registered trademark symbol ® is just option+r. ∑ is option-w. Diacritics are two-stroke combinations, to get é, you'd type option-e, which puts the ´ on the screen, and then type the e to complete the character. Some of them definitel…
"OS X handles some of this by assigning mnemonics to keyboard trademark symbol ® is just option+r. ∑ is option-w." And, after they ran out of mnemonics, they sprinkled the rest of the characters on the keyboard (almost; I think they tried hard to keep things memorable, but some combinations are just plain of the "if you don't know it, you 'll never guess". The Apple logo is on the k key, for instance (IIRC). Mnemonic…
Why doesn't Apple try to make easier to learn and easier to use programming languages instead of focus on the more difficult ones like Objective-C?
Why not use BASIC, Python, Ruby on Rails, Java, or even Pascal for their new language so you get more people to become developers and make iOS and OSX apps in greater numbers because it is easier?
I mean they could have just used Monodevelop: http://monodevelop.com/
Made a tool to convert Winforms to Cocoa Forms to port some Visual Studio C# and Visual BASIC apps to iOS and OSX, and win over the Windows-Only developers to the Apple platforms?
This Swift language seems so hard to learn, almost like F# or something. Not as hard as Haskell, but for the average developer it is going to be painful to learn.
Earlier quoted context omitted.
How is Swift safer than Obj-C? I'm not sarcastic or anything by the way, I just don't understand yet the foundation behind that statement.
Are we talking about type safety or general security? Either way, Swift does better than ObjC in both regards. ObjC was exceptionally type-unsafe. Any object type could be implicitly converted to and from the `id` type: NSString* foo = @"hello world!"; id bar = foo; // no warning NSDictionary* baz = foo; // no warning The Foundation collections all used `id` for the values and keys when they had keys. `NSDictionary`…
-UnsafeButWarn compiler options -> replaces safe versions of arithmetic / arrays with unsafe ones, but issue runtime warnings whenever unsafe behaviour has occurred. Meant for debugging the runtime into never going unsafe, such that checks can be disabled.
-Unsafe compiler option -> replaces safe operations with unsafe ones. Meant for the production version that has been extensively tested but needs to run as fast as possible.
Earlier quoted context omitted.
How is Swift safer than Obj-C? I'm not sarcastic or anything by the way, I just don't understand yet the foundation behind that statement.
It does not have features that often lead to bugs. E.g. the switch statement does not allow fall through and enforces a default case.
Earlier quoted context omitted.
I see that you don't really understand what's needed for real IDE integration. Please, understand one of the main reasons of Apple creating Clang... (hint: because the GCC guys wouldn't take their patches to improve Objc-C & add facilities for IDE integration fast enough) Clang was easier to integrate with an IDE than GCC, and I strongly believe (after seeing what apple showed yesterday) that swift integration is eve…
Well, that may be true for GCC but Ruby, Python & co are well integrated into many third party IDEs. So that point, at least, is moot.
Most (if not all) IDE's Ruby and Python integration is BS.
We're talking about real AST-based highlighting and suggestions, auto fixes, autocomplete for all APIs available (AND your own custom modules), integration with the debugger and the build system, and in Swift's case also integration with the REPL, LighTable-style live-variables and Brett-Victor-inspired live coding environment.
This is not your grandfather's PyCharm.