Here's the offending page: Introducing Swift
The page claims that "Swift is the result of the latest research on programming languages" and goes on to mention that "inferred types make code cleaner and less prone to mistakes," which are a feature whose roots date back to the 50s and have first been famously used in the ML programming language (1972); and mentions that "modules eliminate headers and provide namespaces" which date back to who the fuck knows; and says that "memory is managed automatically" even though it uses reference counting (RC), thus fails at collecting cyclic structures unless some links in them are explicitly declared weak to break up the cycle. Contrast this to garbage collection (GC), which dates back to around 1960, has no problems with cyclic structures, and is understood to perform better than reference counting.
(To be more precise, I've been unable to find a good comparison of well-optimized RC and well-optimized GC; although the latter has been shown to perform (significantly) better for naive implementations. Most research seems willing to dismiss RC from the get-go since it fails to handle cyclic garbage anyway. However, don't believe lies about GC performing badly, and do your own reading if you want to be well-informed.)
But the killer feature of Swift is, of course, that "you don’t even need to type semi-colons." That's 21st century innovation for you.
Let's look at the bulleted feature-list on that page.
This is a fancier way to say "we support closures, and this time the language doesn't have the horrible design flaw of treating them and other functions as distinct data types," in other words the "unified with function pointers" part is just utter marketing bullshit.
Closures themselves, which ought to be the only type of function in a language, date back to at least 1975: the original Scheme report briefly explains how they can be compiled to efficient code.
Depending on where you look, tuples are more or less nothing but fixed-length arrays, in any case a trivial data structure. Lumping this together with multiple-value (MV) returns, by the way, shows only the ignorance (or willingness to flaunt and deceive) of the author: the whole POINT of MV returns is to avoid creating a data structure for the return value and having to destructure it again at the call-site; there will generally be syntactic support for directly populating a number of variables with the returned values, or passing them as the arguments for another function instead.
Correction: That's my ignorance. In a statically typed language, working with tuples does not necessitate creating and destructuring data structures at run-time.
This strategy dates back at least to 1994; probably (much?) older but I can't be arsed to look around, my reference of 1994 is ANSI Common Lisp (CL). You can browse the Common Lisp HyperSpec (CLHS) online, which is essentially ANSI CL in HTML form.
Scheme also has had MV returns standardized in R5RS which is from 1998.
These date back at least to the Common Lisp Object System (CLOS), again from ANSI Common Lisp. See defgeneric in the CLHS.
You mean like in pretty much any programming language since FORTRAN?
I mean, OK, many languages make it unnecessarily verbose and cumbersome to iterate over collections and/or ranges, but it's never more than some trivial syntax that's needed to lift that annoyance. Be it with a hygienic macro system, or built-in syntax like dozens of languages nowadays have. It's incomprehensible to me why someone would flaunt this as a major selling point of a language in this day and age.
(Oh and would you look at that Wikipedia page; apparently Dylan, a previous language by Apple, had hygienic macros! Nowadays people don't know what they are, I'm not sure why, maybe because the overlords deemed the masses too stupid to make good use of them.)
So like any language supporting OOP? After spending too much energy on the last point, I'm just going to shut up about this.
Presumably McCarthy's original LISP had these. To give a concrete reference, have a MACLISP Reference Manual from the freaking Software Preservation Group, because that thing is more or less literally a relic. It's from 1974. It's also what they first implemented Scheme on, so some good history there. Page 33 has delete (like filter), page 83 explains map. What, you thought functional programming was something new?
On to other stuff.
That section basically explains the development method used by Lisp users since times of yore. The concept of a REPL which Swift mentions so proudly dates back once more to the oldest Lisp implementations. Lisp machines and Smalltalk IDEs have long been praised for their interactivity. So yeah, welcome to the 80s, or something. I won't link to sources here, my head is hurting.
Under this section we see a lot of things listed which are the bread and butter of any modern high-level language. And with modern I mean anything that popped up since ten years before my birth. That is, the 80s, I'm not very old.
If you compare Swift to languages like Perl, Python, Ruby, and JavaScript, it might seem nice that it's been designed with native compilation as a first-class goal despite seeming to be a "scripting language" kind of convenient, interactive language, but compiling properly high-level languages (which is to say I'm excluding "portable assembly" languages like C) to native code and getting high performance is surely nothing new; just look at OCaml, Haskell, or some Scheme implementations. Especially Scheme in this case, since it's a similarly "scripty" language. In any case, there is no innovation here.
Swift is not an innovative language. It has nothing new, and I don't see it coming from any outstanding research background. Apple merely came up with an acceptably "modern" language to use instead of the disgusting cruft that is Objective-C. If you want to see nifty new programming language features you might want to look at Rust instead, which actually came up with some ideas that seem to be new.
Oh and:
Indeed, one of my major complaints about the computer field is that whereas Newton could say, "If I have seen a little farther than others, it is because I have stood on the shoulders of giants," I am forced to say, "Today we stand on each other's feet." Perhaps the central problem we face in all of computer science is how we are to get to the situation where we build on top of the work of others rather than redoing so much of it in a trivially different way. Science is supposed to be cumulative, not almost endless duplication of the same kind of things. -- Richard Hamming, 1969
Site design inspired by motherfuckingwebsite.com .
Copy whatever the hell you want from this page.