Why I want Swift to be your first language | Hacker News Reader

Why I want Swift to be your first language

aaronblock.com

33 pointsra88it74 comments

Why I don't want Swift to be your first language (from a student's point of view):

1. Where am I going to test my applications? Not all students have Apple's products (I never had any of them). On the other hand, if I use Python, or Java, or C/C++, I can test my application wherever I want.

2. As far as I know, Swift will be open source (at least, that's what Apple said). But Swift is not open source _at the moment_ (please correct me if I'm wrong).

3. Swift is a new language. If I type "Swift tutorial" on Google, and I type "Python tutorial" on Google in a second tab, I'll get much more relevant results for much more platforms when I type "Python tutorial".

I don't care how good the syntax is. If a programming language is not currently available on like every platform and if I can't build my application using whatever I want to use (including a text editor and a compiler), it's not a good choice for students no matter what you say.

At the end of the article, the author gives several reasons why he won't be teaching Swift to students yet. He includes each of your points. (With the assumption that eventually they will be moot.)

Nope.

He lists that there's no Windows IDE, which is far from being able to run the program everywhere and using whatever I want to use to build it (as I have said it). I also think that .NET languages (like Visual Basic .NET and C# .NET) are not a good starting language, even though one of them was my starting language thanks to my high school and my college (both taught me Visual Basic .NET for one year). Plus, he states that Swift is open source at the moment, which, as far as I know, is not true. He didn't mention any of those three points I made.

EDIT: Replaces .NET with .NET languages.

> I also think that .NET is not a good starting language

Well, that's sort of obvious, in that .NET is a platform for which many languages (VB.NET, C#, F#, Python, etc.) are available, not a language.

It came out wrong, but I was thinking about Visual Basic .NET and C# .NET. Not sure about the others since I never tried them. Thanks for pointing that out, I'll edit my comment.

Once it's open source, isn't it logical to conclude that there will be open source runtimes that run on non-Apple products? Give it a year or so.

Not even a year, about a month. Swift for Linux will arrive with the release of Swift 2.0, which will coincide with the release of Xcode 7, which will coincide with the release of iOS 9 ... which will coincide with the announcement of the next iPhone, which should be around late September, as usual.

Hm, do you think it'll only take a month for it to be ported to Windows?

I'm not an LLVM expert, but Swift is an LLVM frontend, so once it's open source, I think it should work for the various backends?

Right now the issue is library support - swiftc can already just spit out LLVM IR: https://github.com/kripken/emscripten/issues/2427

The stdlib would be included in the open source release.

Linux boxes would fulfill "non-Apple product" though. Unixy programming languages like Swift and Python have always been weird on Windows.

Could you elaborate on Python being weird on Windows?

Python is a set of packages. On Windows, you're supposed to use a distribution, such as Anaconda.

Even then, building some of the fancier libraries (with native code) by hand is bit involved.

In fact, Anaconda works very well on Windows, as long as you don't require extreme latest versions of modules.

Think of it this way: there's iTunes on Windows, but is it actually useful? In reality, it's buggy as hell, slow as hell, quite resource-hungry and requires hundreds of megabytes to install it (even though it's nothing more than a music player capable of being connected to other devices). And Windows version of iTunes contains a Windows port for years.

Now, if Apple actually released the code of its Windows port of iTunes, will Apple actually care about it enough to accept the contributions from the community and make the community feel welcome? Will iTunes on Windows drastically improve as the time goes on? Will developers on other platforms accept it and use it for their products? How well does it behave when compared to other programming languages? There are too many unknowns.

Although I'd love to see that future, I don't think that this will happen. In theory, releasing the code of something is all that is needed to do to make something actually useful. In reality, things are not that simple.

> I can test my application wherever I want.

And if you are using Java, not only can you test your application wherever you want, you can also write it wherever you want.

Languages that don't offer this multiple flexibility will have a tough time becoming a main teaching language in schools.

The article is missing what I think is the zeroth skill to teach beginning programmers - a love of hacking on things and getting results.

It's why I think Javascript is the best language to teach beginners. Yes, it's an ugly language. Yes, it has significant structural problems. Yes, it will bite you in hilariously difficult to find ways. But that doesn't particularly matter compared to teaching them that they can futz around with code and get interesting stuff done.

Processing is also pretty good, for a similar reason.

Lost me when he mentioned that ARC is better to teach than GC.

I'm the least fan of GC as anyone else but needing to have intro students worry about cycles seems like the last thing you want to teach first.

On the other hand, a student would likely be quite far along with an ARC language (well beyond intro) before they'd need to understand anything about the subtleties of it or even its existence. Until then, they can just treat it as though it were GC. One might even argue that if they're going to eventually learn manual memory management, ARC's subtleties might act as a good intermediate step. I think it's about a wash.

I don't see him state that. His argument seems to boil down to:

  1) I want to use a single teaching language.
  2) We need to teach them about memory management.
  3) C style manual memory management is too hard for beginners.

If you accept #1 and #2, you can't start with a language with the full 'magic' of garbage collection, as it would have to be the only language, and you cannot teach #2 with it.

If, in addition, you accept #3, ARC makes sense to me. You can have your pupils implement quite a bit of advanced data structures such as trees and tries before you hit your first cycle, but there are 'real' data structures that use them, so you won't have to make up some artificial example to find one. Until that time, you can let your pupils think that the machine reuses memory as soon as it is no longer referenced.

I think his arguments make some sense, but I am not sure I'm fully behind #1.

Well, look at it this way: Python used (still uses?) very standard reference counting. It can go very far into the design.

What he's wrong about is that the choice is C style, ARC or full GC. There's another intermediate step which is achieved by using C++11 smart pointers - manual reference counted memory management.

The static-void-main-string-args argument is trotted out so often and to me is the most facetious. Every language has some syntax to learn and with any learning process it will need to be handwaved away. Basing any kind of decision on such a trivial thing seems odd to me.

When I here this argument made as to why one shouldn't use a language, you're right it is trivial. But when you're trying to find the right language to teach someone, the first impressions and learning curve matter deeply.

Trying to discourage the use of a language because of `public static void main` is as absurd as trying to sell a language because it lets you write `println("hello world")`.

Don't believe anybody who uses either of these tactics.

Discouraging the use of a language, and discouraging the choice of a certain language as the first language non-programmers are exposed to are two very different things.

The article was a reasonably persuasive argument for why Python should be your first language. Maybe someone should write "Why I want Swift to be relevant to non-Appleheads".

Except for the part where he specifically mentioned Swift's ARC as something to expose Intro students to vs. Python's garbage collection?

Isn't ARC almost exclusive to "Apple languages"? It seems like GC is much more relevant.

Not necessarily, C++11 has smart pointers which have reference counting.

- Python does not implement nullability as an ADT.

- Python does not have a type system worth mentioning.

Nullability is an interface, not a data type. Python objects can always be None, as per duck typing.

Python has a strong dynamic typing system, with metatypes, type rewriting and so on. You couldn't be more wrong. What it is missing is an easy way to declare interfaces - the idea is to use duck typing and handling exceptions when something goes wrong.

If its None, it neither looks, acts nor quacks like a duck.

With the exception of "Named parameters, a life sentence." every argument work for a Lisp based language as Racket for instance.

I'd also argue that a super simple language like Scheme (or stripped-down Racket) would be pretty close to ideal for a pure intro class.

Introductions should be about learning how to reason about abstractions, and how to transform problem-solving from what's going on in your head into code. When you start out with something so rigid like C or Java you really confine a student's ability to reason about a problem because there's so much syntax to keep track of.

A Lisp-like language will only help you if you stay in the lisp world. A C-like will help you with most of the world's current languages in the Tiobe list.

That's so not true in my opinion. There is a whole generation that was raised with Scheme as first language (and SICP ), I am particularly grateful that I was part of that and today I program (or had programmed) in most of the top languages in the Tiobe list as you say.

Both Common Lisp and Racket have keyword arguments, and even Clojure kind of has them(it cheats by using map destructuring). Common Lisps in particular are very powerful and flexible, see http://www.gigamonkeys.com/book/functions.html

Strict type system?

For that exists Typed Racket: http://docs.racket-lang.org/ts-guide/

Ooh fun!

It doesn't look like a particularly radical change from any other so called modern curly bracket language to me. It also doesn't seem to have any native multitasking/multiprogramming features, at least none were mentioned on the Swift2 summary page. Anyway, what sort of students are we talking about here? If they are physics or engineering students then they will have to learn whichever language that the tools they use needs, if they are CS students then surely the language itself is one of the objects to be studied in which case there ought to be more than one.

It doesn't need multitasking/multi programming as a language feature because these are provided by GCD as a library.

Swift is inherently tied to the OS X / iOS APIs (just as Objective-C is). It's a one platform language and will never be (and never intended to be) a general purpose language for all platforms.

Neither are "inherently tied" to OSX or iOS. They may be practically tied due to who drives them and their competitors lack of incentive to ever invest in them, but from a pure language point of view they are agnostic.

Almost the entire OSX API is built on the Objective-C object dispatch model. Swift and Objective-C are built for this model specifically.

It doesn't make sense to run Swift (or Objective-C) without the underlying platform API. You can do it (and Apple does; iTunes for Windows is built with such a shim) but it's not practical.

The only reason Swift even exists is that no other language (other than Objective-C) fit with the object model of the OSX API. So they had to make their own. As much as other languages don't interface well with OSX is as much as Swift doesn't interface well with every other platform.

> So they had to make their own (again).

Objective-C wasn't created by Apple or NeXT.

Fair point but it doesn't change the argument.

Well then: Ruby integrates very nicely with Cocoa and UIKit via RubyMotion, so they didn't need to develop their own language.

MacRuby (which RubyMotion uses on OS X) is a custom version of Ruby with some significant changes under the hood and a lot of compatibility shims:

https://github.com/MacRuby/MacRuby/wiki/How-Does-MacRuby-Wor...

And MacRuby itself is written using Objective-C.

Objective-C (and now Swift) is OS X's system language and they are not applicable as a system language for any other platform.

You've moved the goalposts so far I'm not sure you're even in the same stadium anymore.

I'm not sure that's fair since you brought up MacRuby which is completely irrelevant to how well Swift would work for non-Apple platforms.

It completely undermines it. You have the direction of your dependency arrows mixed up.

Objective-C doesn't play nicely with other operating system APIs. Literally the only OS it plays nicely with is the one written for it specifically. It has found no success anywhere else. The direction doesn't even matter; both the language and the platform have evolved together.

Objective C plays nicely with any C and C++

You're wrong on all accounts. The Objective-C dispatch model is based on Smalltalk.

Most OSX apps and services still aren't even written in Objective-C and many (most actually) platform APIs are still in C.

You can compile Objective-C using the gnu compiler and have been able to for ages.

Swift is an amalgam of many different programming languages and styles, including Rust. None of which have anything specific to do with OSX/iOS about them.

> The Objective-C dispatch model is based on Smalltalk.

I meant the low-level dispatch of methods; the application binary interface that Objective-C uses to communicate with the APIs that make up almost the entire OS X GUI API. You can't mix that with the ABI for Windows API or any Linux toolkit (except GNUStep).

> Most OSX apps and services still aren't even written in Objective-C

Most OS-X apps aren't written in Objective-C? Really? Come on. If it was written specifically for OS X or iOS then it's almost guaranteed to be in Objective-C.

> You can compile Objective-C using the gnu compiler and have been able to for ages.

Nobody says you can't. But the only real useful thing you can with that is link to GNUStep.

> Swift is an amalgam of many different programming languages and styles, including Rust. None of which have anything specific to do with OSX/iOS about them.

At the high-level you are right but on the low-level it's specifically designed to interface with Objective-C APIs which exist in OSes from only one manufacturer. You can't separate Swift from that. The fact that it's an amalgam of OS X specific technology makes it unsuitable for other OSes. It doesn't really have that much in common with Rust either.

> Almost the entire OSX API is built on the Objective-C object dispatch model.

False. Cocoa is a significant part of OSX, but there are C api's for most of the frameworks.

> Swift and Objective-C are built for this model specifically.

False.

Swift supports the Objective-C dispatch model only in a special legacy mode for compatibility that must be enabled on a class by class basis. Swift's default dispatch model is static, just like most other compiled languages and has no impedance mismatch with other OSs.

The rest of your argument is based on these false statements and is simply wrong.

Totally false. Not only is there no such tie, Apple is preparing a Linux open source release.

You can compile Objective-C on Linux but nobody does.

That just goes to prove that there is no tie.

Nobody does because it's tied to Objective-C runtime, Cocoa etc. which don't work well either in Windows or Linux - due to different dispatch model. GNUstep is essentially a compatibility library, works sort of meh and is incomplete. See the other leg of the thread.

It's tied to the objective-c runtime to the same extent that other dynamic languages e.g. Ruby, are tied to their runtimes. That hasn't stopped them.

I agree that the poor state of GNUStep and indeed the fact that it even tries to be a compatibility layer discourages users.

However objective-c is not tied to GNUStep. And this line of reasoning is irrelevant to swift.

Neither swift nor its standard library are tied to OSX at all. Moreover the applications for which a Linux versions will be useful, i.e. servers, will not be handicapped by the lack of access to Cocoa.

At this point of time, being cross-platform (at least the 3 of win,mac,linux) is a basic 'hygiene factor' for programming languages. I mean, even experimental niche tools and hobbyist systems are expected to do that and almost all of them do.

I have access to all kinds of systems, but this is not a consumer item, and it should work everywhere; a mac-only requirement is just as unacceptably limiting for general purpose computing as a windows-only requiremet.

Swift isn't actually open-source yet, is it?

Once it is, I think the reasons explained in this article for using Swift as an introductory language make sense.

Maybe after they open source Swift they'll have some free time to work on Steve Jobs' announcement that FaceTime would be an open video calling standard.

Swift is not open source. It might be in the future, and if they do follow through, the release is slated for "later this year." I hope they do, but I also can't blame anyone who decides to wait and see.

A source on that: http://appleinsider.com/articles/10/06/07/apple_announces_op...

By now, 99% of people have forgotten that FaceTime was ever supposed to be more than video calls between Apple devices. I'd hope they won't try and pull the same thing on the developer community who tend to be more in the loop.

That's a fair point. IIRC, FaceTime actually ran into patent trouble that kept it from being a P2P protocol, so they couldn't really open it up.

I have also heard that the first time the FaceTime engineers found out the protocol was going to be open sourced was when Steve announced it live on stage to the world.

I'm not happy with what happened to FaceTime but I don't think Swift is in the same boat. It seems to have the backing of all the relevant parties and shouldn't face any hurdles like the patent stuff that sank FaceTime. And they gave a hard deadline for themselves to stick to. I'm pretty optimistic about it happening.

FaceTime was prevented from being open sourced by a patent troll. Continuing to repeat misinformation about this in threads like this is not a reflection on Apple, and is clearly irrelevant to whether Swift will be open sourced.

Pay attention to Chris Lattner and his track record if you want a realistic view of whether the open source promise is likely to be kept for Swift.

And whose fault is that? I think is both sides. The patent troll for obvious reasons but also Apple (or Steve Jobs) for announcing something that they cannot achieve.

That is why people have a hard time believing any Open Source promises made by Apple. And yes I know they have some open source projects available right now.

By your logic, anyone who ever runs into trouble with a patent troll should never be trusted again. Clearly this is absurd.

No, anyone who promises things he cannot fulfill may have his trust in doubt. It doesn't matter if the problem was internal or external.

What would you think if Apple went to announce next Wednesday that the new iPhone will have a sapphire screen, but on launch (after a bunch of people preoder the phone) they announce it's normal glass because a provider couldn't deliver.

Whose fault would that be, the provider's? Apple's? Both?

[citation needed]

Citation: http://bfy.tw/1Vpt

The semicolon thing had me scratching my head. Are people teaching Java without an IDE that shows syntax errors very visibly?

hell, i work with python using vim and i can see syntax errors on it. it's really a basic feature when you are writing code.

also, swift has syntax that can bite new developers just like any other language.

Reply on news.ycombinator.com