In addition to being a space-hogging recapitulation of an old, boring Usenet joke, a lot of your checks are wrong; some of them are because the Usenet joke is lame, but some of them are just you missing things, like the fact that Swift interacts directly with C/ObjC, uses the same IDE as Cocoa developers already use, &c.

This lame Usenet joke was a way of punching down at people joining language newsgroups trying to get people to pay attention to their half-baked language ideas. This, on the other hand, is a language that was introduced on stage at WWDC by Chris Lattner. You can see how especially clumsy the joke is by the fact that you checked off a reason Swift "wasn't going to fly". Obviously, it's going to "fly" just fine on the Mac and in iOS.

I posted the checklist partly in jest, but also because I think it illustrates how every programming language ends up stuck with the same trade-offs.

Well, I thought it was funny and I enjoyed reading through the list. You're absolutely right that it provides an insight into the past language efforts and the trade-offs that they inevitably encounter.

I hope you remember that when someone tells you something like 'it doesn't work here' that it's an opinion rather than a fact, regardless of how they phrase it.

The USENET era, while sometimes dated, was probably one of times in 'geek' history where we were the closest to one another. The internet was interpersonal, and i'm glad that someone is still trying to propagate the humor and spirit from that time.

I'm not actually familiar with the context in which this checklist was originally written. But I really love it for two reasons:

First, it demonstrates how programming languages have been making the same tradeoffs for years, to the point that someone was able to make a checklist of what's wrong with any programming language that still works years later.

Second, you can fill this out for any of the big programming languages and many will do very badly. It shows how whether a programming language succeeds is unrelated to how good it is. An actually accurate checklist would have one item:

You're programming language will succeed because:

[X] It is tied to a popular platform.

It really doesn't work here, but also, while I appreciate the spirit you pasted it in, that wasn't the spirit it was written in. (And it takes up a huge amount of space).

It is kind of huge. I tried deleting all the non-checked ones but that defeats the purpose, which is for everyone to form their own opinion of what should be checked.

WTF is usenet?

You make some good points but this post is coming across as really snarky. Might be worth lightening the tone some.

source: http://colinm.org/language_checklist.html

upvoted but needs editing

While half of the things you checked in that copy-paste are wrong, let me take the bait and say why it will work:

- it's not just an arbitrary language, it's the new officially sanctioned programming interface for Apple's gigantic, wildly profitable ecosystem

- it's much more concise than Objective-C

- it's faster than Objective-C

- it's safer than Objective-C

- it has more features than Objective-C

- ...yet it's fully compatible with Objective-C and C code running alongside in the same app.

And last, but not least, if you know how Apple works, you know that somewhere in the range of WWDC 2016-2018, Craig Federighi will be on stage, showing a pie chart and saying "Over 92% of developers have ported their apps to Swift, so screw the other 8%, we're discontinuing Objective-C".

Moving fast and constant change is the name of the game at Apple.

1) So was Java for a bit. It sucked. Developers ignored it.

2) UIApplication.sharedApplication.delegate vs UIApplication.sharedApplication().delegate - nope. It isn’t more concise. It appears to be a wee bit more verbose.

3) Some benchmarks on the web are saying otherwise. It adds extra bridging and ARC for numbers. I don’t see how it can be faster and even if it is - nobody cares about speed. If I need to beat it, I can drop to C, IMP cache, and kick Swifts sorry little ass.

4) Safer - like the TSA says flying without nail clipp ers is safer? It doesn’t solve any problems I actually have. I think my last type error was in 2005 - took about a minute and a half to find it. I routinely work in dynamically typed languages and avoid static typed languages like the plague they are. I’m not opposed to type annotations when they help, but these just look like cargo cultism - like a lot Swift’s silly “features”.

5) It has less features where it counts - basically a less capable object model, weaker meta model, and more budensome interaction with C code than Objective C and a number of useful Objective C features have been walled off. I have Objective C code that cannot be written in Swift.

6) Except for that kind of dynamic stuff like performSelector: afterDelay: withArguments: and that pesky NSInvocation that isn’t available.

There are better projects around than this pile of crap. I will not be porting anything. Quite a lot of code I have can’t be ported.

Java killed WebObjects. Lets not let Swift kill Cocoa.

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` will accept any object as a key, even though it will only work if the key is copiable and hashable, and it does mean that you could have keys of fundamentally different types in the same collection. Values can be heterogeneous too.

As far as type safety goes, Swift is on par with modern languages.

ObjC also inherited several security issues of the C language, like unchecked arrays and unchecked arithmetic. Swift performs bounds checking by default (you can manipulate raw arrays with `UnsafePointer<T>`) and has checked arithmetic by default (you can allow overflows by prefixing the operator with `&`, so `&*`, `&+`, etc). It also never requires you to allocate and deallocate buffers yourself.

So Swift is more secure because it has no buffer overflows, no integer overflows (though they're more an issue when you have buffer overflows) and no unsafe memory management. These are by far the three most commonly exploited vulnerabilities in software.

Thanks for your elaborate answer, I very much appreciate it. After these discussions, Swift sounds like adopting the best of the worlds of fast and dangerous (C, C++, Fortran), slow and easy (Python, Ruby) and slow and safe (Haskell) languages (I'm listing the extreme examples here from my perspective rather than the actual influences to Swift). I especially like the 'safe by default - unsafe optional' stance, since this gives you the ability to create a working program quickly, but still optimise it later through introducing unsafe behaviour. This can allow Swift to be used for HPC purposes further down the road (provided [1] substantial parts will get Open Sourced, [2] it gets implemented on Linux and [3] it gets support for parallel computing both on node, core and accelerator level). Without having worked with it yet, here's what I'd love to get in order to use it for HPC:

-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.

Dynamic typing is not "type unsafe". Objective C objects are completely "type safe". They are actually true objects in that they can receive and potentially handle any message sent to them.

This is an advanced but powerful feature and is in fact exactly what Dr Alan Kay meant when he coined the term "Object Oriented". Any system that has abstract data types that does not have a default message handling capability is not actually "Object Oriented" and the "type safety" brigade strikes me as a bit like depression era prohibitionists. They can't handle it so nobody should have it.

The "type safety" thing is a myth. I have worked on colossally sized systems written in PERL/Mason, PHP, Ruby, Smalltalk, Java, and C++. You'll note that all but the last two are "type unsafe" by your definition and yet I think my last "type related" error was sometime around 2003.

Also, not all collections are meant to be homogeneous.

>ObjC also inherited several security issues of the C language, like unchecked arrays

Objective C developers use NSArray and NSString. Raw arrays and pointers to raw memory are beyond exceptionally rare in Objective C. This is just more prohibitionist propaganda. In the cases where there really are raw memory accesses - you need them - but for the most part Objective C provided safe alternatives and were used heavily (NSData for instance rather than raw arrays and NSString instead of arrays of char).

Nobody is going to do audio or video processing in Swift. The CoreAudio team used C/C++ because when you need performance, you need performance and bounds checking is inefficient.

I heard this sermon from the C++ people in 1992, and then the Java people in 1998 - there's nothing new here and the myth of "type safety" vs "type unsafe" still isn't really true. It is just a lot of baggage and lost capability we are being sold here.

Raw C is potentially unsafe. Objective C - not so much. You can write quite a lot without even using a pointer (apart from id - a safe dynamically typed pointer).

For one, Swift avoids what Tony Hoare calls his Billion Dollar Mistake (conflating optionality and reference types). Because Tony Hoare introduced null references to Algol W, most Algol-derived and Algol-inspired statically typed languages since have made all pointers/references nullable. Some, like Java, have bolted on Lint-like null checkers an afterthought (see @Nullable, @NotNull) outside of the official compiler.

It's really nice to have the compiler not allow callers to pass null to functions where passing null wouldn't make sense, isn't useful, or the programmer was just too lazy to implement null checks. More than half of the functions I write have inputs where null wouldn't have an obvious meaning.

Objective-C's treatment of nil receivers is particularly handy for programming in the small and particularly bad for programming in the large. Sending a message to nil (similar to calling a method on null in many other languages) does nothing other than returning 0 cast to the type of variable you're storing the return value in. Chugging along accidentally accumulating nulls in many cases is worse than segfaulting and giving a nice stack trace.

Certainly in the realm of automated trading software, segfaulting when hitting a programming error is preferable to most other failure modes. Of course, failing to compile is often (though not always) the best failure mode.

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.

The lack of fall through makes me a bit sad since I think that it's a very powerful programming construct and it usually only hurts people new to the concept - but of course one can live without it.

Three things.

First of all, while you can't do this:

    case val:
    case val:
    case val:
        ...

You can do this in Swift, which does the same thing:

    case val, val, val:
        ...

Second, you can fall through in Swift, but you need to ask for it:

    case val:
        ...
        fallthrough
    case val:
        ...

So don't be sad.

And third... Seriously now, it's a "very powerful programming concept"? I bet 9 times out of 10 you use this very powerful programming concept in other languages, you did it by accident, not because you needed its pawa.

Thanks for the clarification on how to use it in Swift - like this it's indeed the perfect solution by enforcing it to be explicit. Having multiple cases rolled into one is also a very nice option. The snark wasn't really called for though. No, I don't 'use' it by accident, that would in most cases just become a bug. I use it when it makes code more concise rather than having nested ifs. Consider for example ACL rules where you set different privileges by default according to an access level.

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.

How objective can something be if the criteria vary depending on the comparison?

I'm not sure what you mean.

Lines of code is an objective measure. How meaningful that might actually be, well, that's subjective.

So you take a language with null pointers, unsafe pointer access, possibility of array and buffer overflows (C and Objective-C).

And then you take another where you have no null pointers, no direct pointer access, and no possibility for array and buffer overflows (Swift).

And you say "nah, I look at these two, and I can't objectively tell which is safer"? Are you fuckin' kidding me?

Regarding speed, it's been proven faster by benchmarks, and by the fact the very reason Swift doesn't mix C types and Objective-C types is so the compiler can better reason and optimize the resulting code.

I think you're putting words into his mouth, and perhaps intentionally misrepresenting what he wrote.

Swift was announced just a few hours ago. While we can make assumptions about its safety based on its feature set, or we can assume that the very vague performance details Apple provided are valid in a real-world setting, none of this has really been tested or verified independently yet.

What cratermoon wrote is perfectly legitimate. Let's try Swift out in the real world, perhaps for a year or two. Let's get some real data. Then let's analyze that actual data, rather than engaging in unsubstantiated speculation, or trusting some vague performance graphs shown in a conference presentation.

I'm not misrepresenting what he wrote, I'm directly responding to it.

While you may not be aware with recent language development and modern LLVM-based languages in general, to me and many others what was announced at WWDC today wasn't just a set of buzzwords and marketing speak.

Anyone who has been into language design and watched the keynote today can make a pretty good guess about the properties of Swift. There's a book with hundreds of pages of examples and description of the language semantics on iBooks right now. I've been reading it before I posted. I've been playing with the beta Xcode as well.

Swift is not revolutionary in terms of its feature set. But what makes it quite interesting is the fact this is now an official language for Apple app development, and it's quite a bit ahead of Objective-C in... yes. Safety, performance and conciseness. Fact.

I'd prefer to see how it fares in the real world before jumping to such conclusions like you seem to be so willing to do.

You may not have been around to experience it first-hand, but we heard a lot of claims made back in the 1990s about how Java and the JVM would increase security and safety.

The arguments made then even overlap with some of those being made in this case! The lack of direct pointer access and manipulation, automated memory management and better bounds checking are some examples of the arguments used then and now.

Yet if you work with computers at all, I'm sure you'd know that many of those claims did not materialize. Flaws have been found in the various implementations of Java and its VM, and these have affected its security and safety in very serious and significant ways, many times over.

Perhaps things are different in the case of Swift. But we won't be able to say for sure until later on, once it has undergone some significant real-world use.

And you're telling me... with a straight face... that Java's lack of direct pointer access, automatic memory management and bounds checking do not make it safer and more secure compared to C and C++?

You really should stop talking.

That's obviously not what I wrote, and you would know this had you bothered to read my comment.

I'm saying that such features alone do not actually guarantee safety, if the language's implementation happens to have flaws.

There hasn't been sufficient time and opportunity to see what Swift is like in practice. It's premature to say anything conclusive about it at this point, aside from stating that we don't yet have enough information about it.

The "flaws" discovered in Java aren't in the language, but in the most popular JVM implementations, most of which - surprise - are implemented in C (for the lack of a better alternative).

Writing in Java still remains monumentally harder to fuck up in compared to writing all your code in C or C++.

Furthermore, while Java relies on said relatively complicated interpreter + JIT virtual machine for its execution, Swift has no such virtual machine. All code is analyzed statically and compiled to machine code. The Objective-C runtime which it uses (which is not new - it's the same fucking Objective-C runtime) is a tiny C library, which implements a few basic low-level routines, such as dynamic message-to-method resolution.

So next time it's best for you to shut your mouth if you're ignorant about an issue, than telling people who know better than you to "wait for conclusive evidence".

I am looking forward to see if Graal[1] replaces Hotspot in Java 9, thus replacing the amount of C/C++ code in the reference implementation.

[1] Oracle's JIT implemented in Java, from the meta-circular JVM Maxime

And quite a bit behind in flexibility and dynamism.

Giant step backwards. Vtables? I don't think so.

override keywords? WTF? Its not so much they removed the C as the "Object".

Thanks for posting!