5 ms·

I'm not sure why Swift is controversial. Objective-C was all but lock in to Apple's ecosystem. If you want cross platform there are other options. Why shouldn't

by mamp 12y ago

I'm not sure why Swift is controversial. Objective-C was all but lock in to Apple's ecosystem. If you want cross platform there are other options. Why shouldn't Apple try to optimise development for their ecosystem? Playgrounds are pretty impressive, as is the interoperability with Objective C e.g. dynamic translation between Objective C and Swift. I wish Microsoft had made it easier to mix and match F# with C#. Swift has some pretty nice features to improve programming safety such as stronger static typing, type inference (not as good as functional languages), a very nice syntax for option types, discriminated unions, pattern matching, improved focus on immutability. It's impressive that Swift introduces all these functional goodies without programmers having to blow a socket trying to convert completely to pure functional programming. For example the Intermediate Swift presentation at WWDC 14 has a pretty elegant way to implement elements of what Scott Wlaschin calls 'railway oriented programming' (http://fsharpforfunandprofit.com/posts/recipe-part2/ http://fsharpforfunandprofit.com/posts/recipe-part2/). As much as I love functional programming I think they've done a pretty good job supporting Cocoa development and improving programming safety. My hope is that Swift will be a gateway drug for FP.

Intermernet 12y ago
I think the problem is that Swift has a proprietary license and Objective C doesn't. I actually think this is likely to be the death of Swift in a completely different way; that of community support and tooling. It's much easier and more fun to write libraries, port to different platforms, and optimise compilers and runtime on open platforms. Flash suffered from this problem, Silverlight suffered from this problem, RealAudio etc. etc. Apple should just open-source the entire language (runtime, implementation, spec etc.) and let the community make it stronger. Seemed to work with Google and Go!
- Jtsummers 12y ago
  C#'s implementation was closed source and tied to a totally novel (at the time) API suite in .NET. Swift has the advantage that it's tied to already known APIs, and that it can call into C/ObjC code, and they can call into Swift. At this stage it's probably too early to say whether Apple will or will not open source their Swift implementation. Again, pointing to a successful proprietary language, C# didn't have an open implementation until Mono came along in 2004. And that project had to develop a lot more infrastructure. We just (I hate that word, but in this case it's not totally wrong) need a compiler front-end for Swift. Under the hood it's using the same LLVM workflow that clang uses. So keeping the language closed-source won't last for long anyways. EDIT: C# could call into C++ from the start, and I believe the reverse was also true. So platform-wise, MS matches the Swift<->ObjC/C bridge as well. I forgot about that detail.
  - drdaeman 12y ago
    Indeed, source code availability of the compiler implementation and accompanying infrastructure doesn't really matter. It takes time but it could be re-implemented from specs. The problem with C# and .NET is (was) that they are patent-encumbered and that's the real game stopper. It took quite a long time and a lot of debate on .NET suitability for a Free Software movement to settle that matters somehow (recent releases under Apache license seem to fix many issues, though, although that still needs a statement from FSF's lawyers). I'm unaware about Swift relationship to software patents. Does anyone know?
  - ygra 12y ago
    C# can call C, but not C++, except for COM interfaces (which have a defined external interface and mechanisms to get around the drawbacks of C++ libraries). To use normal C++ from C# you have to implement a bridge that's both C++ and managed code.
    - Jtsummers 12y ago
      Ah, ok. I've seen it in code bases but never had to touch those sections (and it's not used in anything I'm developing, pure C# code for my projects). Thanks for the info.
  - narag 12y ago
    If you're arguing that C# succeeded despite not being open source, consider that Microsoft's tools at the time were EOL'd, so transition was forced for MS tech users.
- mattgreenrocks 12y ago
  What do you think the 'community' would do that Apple isn't able to? Languages are not meant to be designed by committee.
  - Intermernet 12y ago
    Apple can retain the core design decisions (like the Linux kernel) but the code should be open to pull requests and design improvements. To use Go as an example, the entire Windows port was done outside of the core team, and is now a supported platform. The same goes for ARM, PPC64 etc. Also, huge performance improvements in core features such as channels were implemented by non Google employees. If Apple open Swift, it can find hold in all sorts of niches they didn't expect it to, and can benefit from an entire community of developers who can fix the language's problems rather than be frustrated by them.
deleted 12y ago
[deleted]
chazu 12y ago
GNUStep's Objective-C framework makes it easy to port desktop apps written in Obj-C over to other systems, and includes newer features like ARC, so I wouldn't say Obj-C locks you into AppleLand at all, at least for desktop apps. From a slightly different angle, I personally think Obj-C is a very neat alternative to C++, and that it would flourish outside of the context of Apple's frameworks if more folks started to use it as such. While I'm happy that iOS development will be a little less difficult now thanks to Swift, it makes me sad to think that Obj-C might not get as much attention from newer developers who like the way the language extends C with Smalltalk-style OO and message passing.

by mamp 12y ago

Intermernet 12y ago

I think the problem is that Swift has a proprietary license and Objective C doesn't. I actually think this is likely to be the death of Swift in a completely different way; that of community support and tooling. It's much easier and more fun to write libraries, port to different platforms, and optimise compilers and runtime on open platforms. Flash suffered from this problem, Silverlight suffered from this problem, RealAudio etc. etc. Apple should just open-source the entire language (runtime, implementation, spec etc.) and let the community make it stronger. Seemed to work with Google and Go!

Jtsummers 12y ago
C#'s implementation was closed source and tied to a totally novel (at the time) API suite in .NET. Swift has the advantage that it's tied to already known APIs, and that it can call into C/ObjC code, and they can call into Swift. At this stage it's probably too early to say whether Apple will or will not open source their Swift implementation. Again, pointing to a successful proprietary language, C# didn't have an open implementation until Mono came along in 2004. And that project had to develop a lot more infrastructure. We just (I hate that word, but in this case it's not totally wrong) need a compiler front-end for Swift. Under the hood it's using the same LLVM workflow that clang uses. So keeping the language closed-source won't last for long anyways. EDIT: C# could call into C++ from the start, and I believe the reverse was also true. So platform-wise, MS matches the Swift<->ObjC/C bridge as well. I forgot about that detail.
- drdaeman 12y ago
  Indeed, source code availability of the compiler implementation and accompanying infrastructure doesn't really matter. It takes time but it could be re-implemented from specs. The problem with C# and .NET is (was) that they are patent-encumbered and that's the real game stopper. It took quite a long time and a lot of debate on .NET suitability for a Free Software movement to settle that matters somehow (recent releases under Apache license seem to fix many issues, though, although that still needs a statement from FSF's lawyers). I'm unaware about Swift relationship to software patents. Does anyone know?
- ygra 12y ago
  C# can call C, but not C++, except for COM interfaces (which have a defined external interface and mechanisms to get around the drawbacks of C++ libraries). To use normal C++ from C# you have to implement a bridge that's both C++ and managed code.
  - Jtsummers 12y ago
    Ah, ok. I've seen it in code bases but never had to touch those sections (and it's not used in anything I'm developing, pure C# code for my projects). Thanks for the info.
- narag 12y ago
  If you're arguing that C# succeeded despite not being open source, consider that Microsoft's tools at the time were EOL'd, so transition was forced for MS tech users.
mattgreenrocks 12y ago
What do you think the 'community' would do that Apple isn't able to? Languages are not meant to be designed by committee.
- Intermernet 12y ago
  Apple can retain the core design decisions (like the Linux kernel) but the code should be open to pull requests and design improvements. To use Go as an example, the entire Windows port was done outside of the core team, and is now a supported platform. The same goes for ARM, PPC64 etc. Also, huge performance improvements in core features such as channels were implemented by non Google employees. If Apple open Swift, it can find hold in all sorts of niches they didn't expect it to, and can benefit from an entire community of developers who can fix the language's problems rather than be frustrated by them.

deleted 12y ago

[deleted]

chazu 12y ago

GNUStep's Objective-C framework makes it easy to port desktop apps written in Obj-C over to other systems, and includes newer features like ARC, so I wouldn't say Obj-C locks you into AppleLand at all, at least for desktop apps. From a slightly different angle, I personally think Obj-C is a very neat alternative to C++, and that it would flourish outside of the context of Apple's frameworks if more folks started to use it as such. While I'm happy that iOS development will be a little less difficult now thanks to Swift, it makes me sad to think that Obj-C might not get as much attention from newer developers who like the way the language extends C with Smalltalk-style OO and message passing.