Prototyping what Swift can look like in educational settings


(Donald Pinckney) #1

Hi all,
Personally, I love Swift, and I am curious to see if it will be used in educational settings, not necessarily even CS education. As something of an experiment to see how Swift could currently look in education, I coded a Swift playground (sorry, very Mac specific right now!) that is a rewriting of a lab activity we did in my 3rd quarter of physics. For those who are interested in educational aspects of Swift, and have a Mac to run this code, feel free to check out my attached playground, and give any sort of feedback, with respect to either the code or more philosophically where you think Swift could go with education.

Cheers,
Donald Pinckney

Schrödinger.playground.zip (287 KB)


(Tom Sheffler) #2

Thanks for sharing this playground! I hadn’t seen anything quite like it, and it’s illuminating some of the possibilities.

···

On Jan 5, 2016, at 10:42 PM, Donald Pinckney via swift-users <swift-users@swift.org> wrote:

Hi all,
Personally, I love Swift, and I am curious to see if it will be used in educational settings, not necessarily even CS education. As something of an experiment to see how Swift could currently look in education, I coded a Swift playground (sorry, very Mac specific right now!) that is a rewriting of a lab activity we did in my 3rd quarter of physics. For those who are interested in educational aspects of Swift, and have a Mac to run this code, feel free to check out my attached playground, and give any sort of feedback, with respect to either the code or more philosophically where you think Swift could go with education.

Cheers,
Donald Pinckney

<Schrödinger.playground>

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users


(Dru Satori) #3

There is a huge potential here. The weakness, today at least, is that with Swift 2.0, there remain some difficulties in terms of being dependent upon reaching out to Objective C to accomplish some tasks. Looking at what is coming with Swift 3.0, and the work done on the Linux port, I think there is a clear roadmap that makes many of these issues go away, but right now, today, I think it is a tough sell into the edu market.

···

On 1/6/16, 1:42 AM, "swift-users-bounces@swift.org on behalf of Donald Pinckney via swift-users" <swift-users-bounces@swift.org on behalf of swift-users@swift.org> wrote:

Hi all,
Personally, I love Swift, and I am curious to see if it will be used in educational settings, not necessarily even CS education. As something of an experiment to see how Swift could currently look in education, I coded a Swift playground (sorry, very Mac specific right now!) that is a rewriting of a lab activity we did in my 3rd quarter of physics. For those who are interested in educational aspects of Swift, and have a Mac to run this code, feel free to check out my attached playground, and give any sort of feedback, with respect to either the code or more philosophically where you think Swift could go with education.

Cheers,
Donald Pinckney


(Jens Alfke) #4

Coming from the perspective of business applications market (Java and C#), I see major problems in moving to Swift.

Did you intend to hijack an unrelated thread instead of starting your own? If so, that’s bad netiquette. I’ve retitled the reply for you, to hopefully split off this thread.

The String class is a disaster.

Flaming: Again, bad netiquette. How about offering some concrete examples of what you dislike about strings? (Bonus points for showing that you understand Unicode and aren’t just pining for an outdated array-of-UTF16 model like Java's.)

Optionals present a giant spider web of interconnectedness and syntax idiosyncrasy that does not provide any real advantage compared with Java/C#.

How about “no more NullPointerExceptions?” And again, “no real advantage” is just opinion with nothing behind it. Optionals have a long history in functional languages and a lot of users of said languages who feel that they’re beneficial.

The fact that Ints, etc. are not really primitives (unwrapping is required, sometimes explicit, sometimes implicit) is a major dislocation for those coming from all C-syntax-based languages.

Integers are primitives. More so than in Java, C# or other “managed” languages, since Swift compiles directly to machine code.

The lack of non-checked exceptions (that is exceptions not declared with a throws clause on the func def) is problem.

Swift doesn’t have exceptions at all; its error handling is fundamentally different, despite reusing some common names like “throw”. I suspect you haven’t really understood how error handling in Swift works, since “non-checked” isn’t an attribute that has any meaning in Swift’s model.

The lack of packages and/or namespaces is another giant gaping hole.

I agree with this, but I think it’s something that’s going to be addressed in the future (see the current work on the package manager.)

—Jens

···

On Jan 6, 2016, at 9:34 AM, Don Wills via swift-users <swift-users@swift.org> wrote:


(Don Wills) #5

[soapbox]

Coming from the perspective of business applications market (Java and C#), I see major problems in moving to Swift. It's simple too different. The String class is a disaster. Optionals present a giant spider web of interconnectedness and syntax idiosyncrasy that does not provide any real advantage compared with Java/C#. The fact that Ints, etc. are not really primitives (unwrapping is required, sometimes explicit, sometimes implicit) is a major dislocation for those coming from all C-syntax-based languages. The lack of non-checked exceptions (that is exceptions not declared with a throws clause on the func def) is problem. The lack of packages and/or namespaces is another giant gaping hole.

I had high hopes when I first looked into Swift. Those hopes have been dashed, and I don't see anything in my limited view of the plans for Swift 3.0 that addresses any of these concerns or several others that I did not mention.

[/soapbox]

Don Wills

···

On Jan 6, 2016, at 10:15 AM, Dru Satori via swift-users <swift-users@swift.org> wrote:

There is a huge potential here. The weakness, today at least, is that with Swift 2.0, there remain some difficulties in terms of being dependent upon reaching out to Objective C to accomplish some tasks. Looking at what is coming with Swift 3.0, and the work done on the Linux port, I think there is a clear roadmap that makes many of these issues go away, but right now, today, I think it is a tough sell into the edu market.

On 1/6/16, 1:42 AM, "swift-users-bounces@swift.org on behalf of Donald Pinckney via swift-users" <swift-users-bounces@swift.org on behalf of swift-users@swift.org> wrote:

Hi all,
Personally, I love Swift, and I am curious to see if it will be used in educational settings, not necessarily even CS education. As something of an experiment to see how Swift could currently look in education, I coded a Swift playground (sorry, very Mac specific right now!) that is a rewriting of a lab activity we did in my 3rd quarter of physics. For those who are interested in educational aspects of Swift, and have a Mac to run this code, feel free to check out my attached playground, and give any sort of feedback, with respect to either the code or more philosophically where you think Swift could go with education.

Cheers,
Donald Pinckney

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users


(Jens Alfke) #6

1. The lack a Character type that are the constituent elements of a String
2. Missing methods (Java names used): valueOf, charAt, trim(), length(),

No offense, but it sounds like you haven’t read the justifications in the Swift book or on the web. The short form: Unicode is complicated, necessarily so because human writing is complicated. Even the notion of a “character” is problematic. To quote from objc.io's (prerelease) Advanced Swift book: "But even when encoded using 32-bit code units, what a user might consider 'a single character' — as displayed on the screen — might require multiple code points composed together. Most string manipulation code exhibits a certain level of denial about Unicode’s variable-width nature. This can lead to some unpleasant bugs.”

charAt isn’t available because a String is not just a simple “array of characters” as in older / more simplistic languages. Ditto with length.
valueOf IIRC is for converting to/from integers — there are methods on the integer types for that.
trim is one of those methods that is supplied in the Foundation framework, which hasn’t been ported to a Swift-native version yet so isn’t available outside Apple platforms.

getBytes(), toUpperCase(), toLowerCase()

getBytes is basically a UTF-8 view.
Upper/lowercase conversions are again part of Foundation.

3. The lack of the + operator for appending

You can add this in a couple of lines of code if it’s important to you.

4. The lack of a StringBuilder (Java again) class

Apples and oranges. Java needs StringBuilder/StringBuffer because its String is always immutable. In Swift mutability is an aspect of the variable containing the String, so the String class itself contains mutating methods.

—Jens

···

On Jan 6, 2016, at 10:30 AM, Don Wills <don.wills@portablesoftware.com> wrote:


(Jens Alfke) #7

The cost of !, ? and ?? everywhere in the language is a huge coding and maintenance inconvenience for the programmer error condition referencing a variable that contains the value null.

It’s not so much about null, as it is about whether a variable definitely contains a value or not. (You can have optionals for non-pointer types like ints.) It’s not what you’re used to. Some Mac/iOS programmers have been complaining because the bindings to Cocoa APIs were suboptimal and exposed a lot of optionals where they didn’t need to.

Basically this argument is like a JavaScript or Python programmer looking at Java or C# and complaining that static typing adds a huge coding and maintenance inconvenience with all those type declarations and casts. No, not really, and it has a ton of benefits to safety; it’s just not what they’re used to.

The fact that you claim Ints are primitives and Loïc Lecrenier in an email three minutes prior writes "Swift does not have primitives, but I consider that a plus..." Which is it?

I’m not sure what Loïc meant; maybe he can explain. Ints are primitives in that they are basically the same as ints in C or C++. They’re inline values of 1 to 8 bytes size that can be stored on the stack or inside structs/classes. I believe there’s some transparent boxing that goes on if you cast an int type to an Any value, but it’s more common to use generics for this.

Note that an Array<Int> is vastly more efficient than the Java equivalent, because the generated code will store the int values directly instead of boxing them up as objects. That is, a Swift Array<Int> is comparable in implementation and performance to a C++ std::vector<int> or a C int[].

Swift doesn't have exceptions? What are the "throws" clause on funcs and the try and throw statements?

Please read the book! Swift error handling is syntactic sugar around the practice of having a function return a flag value on failure (false / nil / 0 / etc) combined with an ‘out’ parameter that will store an error object describing the failure. There is no stack unwinding going on.

This convention has been used for a long time in the Cocoa frameworks and Swift basically bakes it into the language syntax, with some improvements. I think it’s an excellent compromise — the typical try/catch exception mechanism is very flexible but makes exceptions very expensive to throw and bloats the code to add all the metadata tables to handle recovery.

I come from the perspective of 45 years of experience in dozens of programming languages. Swift seems to be trying to be everything to everybody - a bridge from Obj-C, functional, imperative, procedural, object-oriented with a somewhat Java and C-like syntax.

*Shrug* If we’re comparing, I’ve got about 38 years’ experience if you count Tiny BASIC as a language. I don’t see Swift as having a kitchen-sink approach at all; keep in mind that it’s designed by people with a lot of experience designing and implementing languages that are heavily used for very pragmatic application and system programming.

I don’t know if you’ve been following the field of statically-compiled languages, but there’s been a lot of innovation recently after a long drought. Look at Rust and Go, for example. Both are subject to the same objections you made above. I just see it as language designers learning from the past and adopting new techniques that prove valuable.

Anyway, if there’s one thing I can leave you with, it’s: Read The Fine Manual. Swift came equipped from day one with a very well-written book that explains the language quite well. I don’t think you’ve read it, or if you did, it was much too quickly, because you’ve missed some fundamental points. There’s nothing wrong with skimming, but it doesn’t give you the authority to dismiss a language outright or make pronouncements about why it’s broken.

—Jens

···

On Jan 6, 2016, at 10:30 AM, Don Wills <don.wills@portablesoftware.com> wrote:


(Don Wills) #8

Points well taken.

Coming from the perspective of business applications market (Java and C#), I see major problems in moving to Swift.

Did you intend to hijack an unrelated thread instead of starting your own? If so, that’s bad netiquette. I’ve retitled the reply for you, to hopefully split off this thread.

The String class is a disaster.

Flaming: Again, bad netiquette. How about offering some concrete examples of what you dislike about strings? (Bonus points for showing that you understand Unicode and aren’t just pining for an outdated array-of-UTF16 model like Java's.)

I didn't want to post a tome about String, but here's a basic list of features/methods missing in String:

1. The lack a Character type that are the constituent elements of a String
2. Missing methods (Java names used): valueOf, charAt, trim(), length(), getBytes(), toUpperCase(), toLowerCase()
3. The lack of the + operator for appending
4. The lack of a StringBuilder (Java again) class

Optionals present a giant spider web of interconnectedness and syntax idiosyncrasy that does not provide any real advantage compared with Java/C#.

How about “no more NullPointerExceptions?” And again, “no real advantage” is just opinion with nothing behind it. Optionals have a long history in functional languages and a lot of users of said languages who feel that they’re beneficial.

The cost of !, ? and ?? everywhere in the language is a huge coding and maintenance inconvenience for the programmer error condition referencing a variable that contains the value null.

The fact that Ints, etc. are not really primitives (unwrapping is required, sometimes explicit, sometimes implicit) is a major dislocation for those coming from all C-syntax-based languages.

Integers are primitives. More so than in Java, C# or other “managed” languages, since Swift compiles directly to machine code.

The fact that you claim Ints are primitives and Loïc Lecrenier in an email three minutes prior writes "Swift does not have primitives, but I consider that a plus..." Which is it?

In addition, memory management (your reference to "language management") has nothing to do with whether or not integers are primitives. In Java, "int" is a primitive and "Integer" is not.

The lack of non-checked exceptions (that is exceptions not declared with a throws clause on the func def) is problem.

Swift doesn’t have exceptions at all; its error handling is fundamentally different, despite reusing some common names like “throw”. I suspect you haven’t really understood how error handling in Swift works, since “non-checked” isn’t an attribute that has any meaning in Swift’s model.

Swift doesn't have exceptions? What are the "throws" clause on funcs and the try and throw statements?

The lack of packages and/or namespaces is another giant gaping hole.

I agree with this, but I think it’s something that’s going to be addressed in the future (see the current work on the package manager.)

—Jens

I come from the perspective of 45 years of experience in dozens of programming languages. Swift seems to be trying to be everything to everybody - a bridge from Obj-C, functional, imperative, procedural, object-oriented with a somewhat Java and C-like syntax. I've seen this movie before - it was called PL/I and was the IBM answer to merging COBOL and FORTRAN. Survivors: COBOL and FORTRAN. It appears to me that Swift is today's PL/I.

Don

···

On Jan 6, 2016, at 11:02 AM, Jens Alfke <jens@mooseyard.com> wrote:

On Jan 6, 2016, at 9:34 AM, Don Wills via swift-users <swift-users@swift.org> wrote:


(Erica Sadun) #9

Don,

I love your playground. This highlights a few areas where I really would love to see some enhancements from the playground team. Here are a few off the top of my head. My actual list is longer:

* Your students should be able to have an appropriate input and submission component that isn't compiled -- answering in freeform language to the questions.
* Playgrounds need a "reset" button that enable any tweaks to return to a pristine state for starting over.
* Playgrounds should offer a "compute this outside" option, that allows you to add code *inside* the pages but have them computed outside. For example in your playground there's the harmonic oscillator, and a few other number-crunchy stop points.
* Playgrounds should be able to integrate video and audio snippets so it's not just all text text text for lessons
* Playgrounds need support for grammar / spelling tests and writing tools.
* Playgrounds should also include annotation tools (highlighting, notes) similar to what we see in iBooks as well as snippets/note support for collecting items (both text and code) between lessons

I could go on but I think you get the idea of how great it is to see this kind of development and how far it could be pushed for even better teaching/learning experiences.

-- Erica
p.s. I have a book on playgrounds in iBooks, if you want to ping me off-list, I'll send you a promo code

···

On Jan 6, 2016, at 11:32 AM, Tom Sheffler via swift-users <swift-users@swift.org> wrote:

Thanks for sharing this playground! I hadn’t seen anything quite like it, and it’s illuminating some of the possibilities.

On Jan 5, 2016, at 10:42 PM, Donald Pinckney via swift-users <swift-users@swift.org> wrote:

Hi all,
Personally, I love Swift, and I am curious to see if it will be used in educational settings, not necessarily even CS education. As something of an experiment to see how Swift could currently look in education, I coded a Swift playground (sorry, very Mac specific right now!) that is a rewriting of a lab activity we did in my 3rd quarter of physics. For those who are interested in educational aspects of Swift, and have a Mac to run this code, feel free to check out my attached playground, and give any sort of feedback, with respect to either the code or more philosophically where you think Swift could go with education.

Cheers,
Donald Pinckney

<Schrödinger.playground>

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users


(Loïc Lecrenier) #10

Hi Don,

I don’t understand these complaints.

The String class is complicated, but it is not a disaster, it just needs more convenience methods. See: https://www.mikeash.com/pyblog/friday-qa-2015-11-06-why-is-swifts-string-api-so-hard.html for an explanation of the String API.

Optionals is an essential feature for writing safe code. I don’t see how it presents a giant spider web of interconnectedness. Plenty of languages have optionals (Rust, Haskell) and it has brought nothing but advantages.

Swift does not have primitives, but I consider that a plus: every type has access to the same features. It makes the language more consistent and more flexible. Also note that there is no performance cost to the way Swift represents Int. They are just as efficient as C’s int.
I also don’t understand what you mean by “unwrapping is required, sometimes explicit, sometimes implicit”.

I won’t comment on non-checked exceptions. But I’m not convinced this is a very valuable feature.

Maybe I’m misunderstanding what you mean by “package”, but isn't the Swift Package Manager a good solution for packages?
Namespaces also exist, although it is quite rudimentary. There is a proposal draft for “beefing up” import that tries to improve that.

Honestly, it seems like you haven’t given Swift a fair shot, and wanted to see a Java/C# clone instead.
It is also evolving very quickly, so I wouldn’t lose hope :slight_smile:

Regards,

Loïc

···

On Jan 6, 2016, at 6:34 PM, Don Wills via swift-users <swift-users@swift.org> wrote:

[soapbox]

Coming from the perspective of business applications market (Java and C#), I see major problems in moving to Swift. It's simple too different. The String class is a disaster. Optionals present a giant spider web of interconnectedness and syntax idiosyncrasy that does not provide any real advantage compared with Java/C#. The fact that Ints, etc. are not really primitives (unwrapping is required, sometimes explicit, sometimes implicit) is a major dislocation for those coming from all C-syntax-based languages. The lack of non-checked exceptions (that is exceptions not declared with a throws clause on the func def) is problem. The lack of packages and/or namespaces is another giant gaping hole.

I had high hopes when I first looked into Swift. Those hopes have been dashed, and I don't see anything in my limited view of the plans for Swift 3.0 that addresses any of these concerns or several others that I did not mention.

[/soapbox]

Don Wills

On Jan 6, 2016, at 10:15 AM, Dru Satori via swift-users <swift-users@swift.org> wrote:

There is a huge potential here. The weakness, today at least, is that with Swift 2.0, there remain some difficulties in terms of being dependent upon reaching out to Objective C to accomplish some tasks. Looking at what is coming with Swift 3.0, and the work done on the Linux port, I think there is a clear roadmap that makes many of these issues go away, but right now, today, I think it is a tough sell into the edu market.

On 1/6/16, 1:42 AM, "swift-users-bounces@swift.org on behalf of Donald Pinckney via swift-users" <swift-users-bounces@swift.org on behalf of swift-users@swift.org> wrote:

Hi all,
Personally, I love Swift, and I am curious to see if it will be used in educational settings, not necessarily even CS education. As something of an experiment to see how Swift could currently look in education, I coded a Swift playground (sorry, very Mac specific right now!) that is a rewriting of a lab activity we did in my 3rd quarter of physics. For those who are interested in educational aspects of Swift, and have a Mac to run this code, feel free to check out my attached playground, and give any sort of feedback, with respect to either the code or more philosophically where you think Swift could go with education.

Cheers,
Donald Pinckney

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users


(Jeremy Pereira) #11

Points well taken.

I didn't want to post a tome about String, but here's a basic list of features/methods missing in String:

1. The lack a Character type that are the constituent elements of a String
2. Missing methods (Java names used): valueOf, charAt, trim(), length(), getBytes(), toUpperCase(), toLowerCase()
3. The lack of the + operator for appending
4. The lack of a StringBuilder (Java again) class

In Swift, String is intended to be Unicode correct. This means that the concept of “character” is actually quite complex. It’s impossible to define charAt and length without doing a linear search through the string.

getBytes() in Java is a disaster, although the variants where you specify an explicit character set are fine and for UTF8 and UTF16 have an explicit equivalent in Swift e.g.

let foo = Array("föo".utf8) // Array of UInt8 [102, 195, 182, 111]

valueOf() is covered by string interpolation e.g.

let number = “\(myDoubleVariable)”

trim() and toWhateverCase() are missing but are discriminatory to non latin alphabets.

The + operator does exist for strings and StringBuilder is unnecessary because a var string can be mutated.

var foo = “gfds”
foo += “fgfd"

Oh look += works for strings too.

The cost of !, ? and ?? everywhere in the language is a huge coding and maintenance inconvenience for the programmer error condition referencing a variable that contains the value null.

Actually, I think the optional syntax is great. It forces you to think about and deal with the equivalent of null pointers. Or put it this way, if Java programmers were forced to handle all the possible cases where they might have a null pointer instead of sweeping it under the carpet as they do, the maintenance overhead and inconvenience would be far worse than with Swift. Swift provides compiler support for answering the question “could this value be nil”. Java doesn’t, which probably explains why the logs of many large Java systems frequently contain stack dumps from null pointer exceptions.

The fact that you claim Ints are primitives and Loïc Lecrenier in an email three minutes prior writes "Swift does not have primitives, but I consider that a plus..." Which is it?

The concept of “primitive” has no meaning in Swift. In Swift, there are value types and reference types and user defined types and “built in” types are of equal rank. Clever compiler optimisation allows some types to compile down to CPU native types, but that is an implementation detail.

Swift doesn't have exceptions? What are the "throws" clause on funcs and the try and throw statements?

In Swift, you throw errors, not exceptions. The word exception is (more or less) reserved for conditions that terminate the process.

There are no unchecked errors but then why would you not want to handle an error condition if it occurs? Why would you not want to know that an API can throw an error?

I think Java’s checked exceptions are fine, but it really should not be possible to catch an unchecked exception.

The lack of packages and/or namespaces is another giant gaping hole.

I agree with this, but I think it’s something that’s going to be addressed in the future (see the current work on the package manager.)

—Jens

I come from the perspective of 45 years of experience in dozens of programming languages. Swift seems to be trying to be everything to everybody - a bridge from Obj-C, functional, imperative, procedural, object-oriented with a somewhat Java and C-like syntax. I've seen this movie before - it was called PL/I and was the IBM answer to merging COBOL and FORTRAN. Survivors: COBOL and FORTRAN. It appears to me that Swift is today's PL/I.

Having programmed in it quite a bit (a statement that, with respect, I think does not apply to you) I can tell you that it is a joy to use. I love the fact that I can pick the programming paradigm that is best suited to the problem I am trying to solve. Furthermore, it has the advantage of being the language of choice for the most successful mobile platform in terms of actual money. Now that the toolchain is open source, I can only see its sphere of influence expanding.

···

On 6 Jan 2016, at 18:30, Don Wills via swift-users <swift-users@swift.org> wrote:

On Jan 6, 2016, at 11:02 AM, Jens Alfke <jens@mooseyard.com> wrote:

Don

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users


(Dru Satori) #12

See, while discussing applicability to the Edu world, I think you can really dissect the languages themselves, and create compelling cases. The problem you guys have flipped this too, the business development world is a ton more complex.

I love Swift as a language. I enjoy working with Xcode. But as a business developer, Swift the language is fine. Swift the development platform isn’t there yet, and for the most part, it has nothing to do with the issues raised to this point in this discussion. Hence the reason I am even speaking up, something I would not normally do in this phase of a discussion.

When discussing languages in a business development context, the language itself is such a small part of the puzzle. In so many cases, the choice of language is dictated by pressures outside the scope of this discussion, but there are some factors that directly influence these decisions that are language as a platform limitations.

One of the key questions is always one of developer competencies. Swift, as a language is a departure from the languages most business developers are comfortable in. It may use LLVM, but it is not a “C” style language, in fact, it feels more like a scripting language than many languages at this level. If you look at the business world, you see a lot of Java, C#, some VB.net, and a good bit of C/C++. Each of these languages has strengths and weaknesses, but all of them are, at this point, mature languages. Fundamental syntax is static and slow to change. Rich libraries of tools are purpose built, well understood (bugs and all), and these platforms are ready to go for business usage, complete with developer competencies.

Swift, right now, today, isn’t.

- Is it a good language? Absolutely.
- Is it a mature language? Not yet. The basics feel like they are solidifying, the supporting libraries are coming along, but not quite there yet.
- Does it have rich libraries? Sort of. It let’s you build upon existing C libraries, though there can be some tap-dancing involved in order to make things work exactly as expected but in terms of Swift native libraries? That ball is *just* getting rolling.
- Does the business development developer have competency in the language? Not many, and those that do, it is heavily focused on the iOS toolkits and subsets.

For example, say medium size business with a dev team of say 3 developers for their internal applications already has a product, but then need to make it mobile. Let’s assume that they have a really progressive architecture. Today, the server side is MySQL with an Apache interface serving up a REST JSON interface to a ‘rich’ client application running on Windows machines. IT is probably a mix of C# and PHP, perhaps even all C#. Choosing Swift for the iOS platform is a tough sell, today. Objective C is an easier jump, it has richer libraries, and the language is closer to C# than Swift is.

And, that is a best case scenario. Think worst case, and unfortunately, I think this is far more prevalent than the above best case.

Worst case? The application is client server, fat client written in VB6, using ODBC or RDO.NET for direct data access to a Microsoft SQL Server database. The whole stack has been held together with duct tape, sure glue and bailing wire for the last 4 years. They know they have to start over. How do you sell Swift in that environment? You need to sell a single stack, with libraries and tools. Right now, Swift can’t offer that. Truth be told, out of the box neither can Objective-C.

There needs to be growth in the library department, and that work isn’t going to come from Apple (exclusively). That’s where open source Swift 2 and 3 come into play, and it *can* become a compelling sell, even if it is not quite there yet.

If you dig and poke at Swift on OS X, what you quickly figure out is that it can be used as both programming language and scripting language fairly easily. You can see the beginnings of a language that could readily be used as both server side language, and client side consumption language, all with the things that Swift is trying to bring to the table to address one standing issues that exist in both Objective-C and it’s underlying C heritage that make writing good, difficult to exploit code, hard.

I’ll use my own small business as an example. We have an aging client server environment. A wholesale move to cloud ready technologies is not in the budget (we like eating). A slow migration however, is. We fully understand the limitations, and have been slowly building our server stack in Swift, and believe me, we are tracking Swift.org closely, for the possibility of running that stack on Linux servers. But right now, the challenges that Swift faces just doing seemingly basic things, like reading environment variables in order to process a CGI interface request is a challenge to do in a platform neutral manner in Swift. Try database access, or other similar “business” activities. It isn’t there yet.

Sorry for the wall of text. The summary is simple, the potential is there, but no, today, Swift is not a prime business development environment.

···

On 1/6/16, 1:30 PM, "Don Wills" <don.wills@portablesoftware.com> wrote:

Points well taken.

On Jan 6, 2016, at 11:02 AM, Jens Alfke <jens@mooseyard.com> wrote:

On Jan 6, 2016, at 9:34 AM, Don Wills via swift-users <swift-users@swift.org> wrote:

Coming from the perspective of business applications market (Java and C#), I see major problems in moving to Swift.

Did you intend to hijack an unrelated thread instead of starting your own? If so, that’s bad netiquette. I’ve retitled the reply for you, to hopefully split off this thread.

The String class is a disaster.

Flaming: Again, bad netiquette. How about offering some concrete examples of what you dislike about strings? (Bonus points for showing that you understand Unicode and aren’t just pining for an outdated array-of-UTF16 model like Java's.)

I didn't want to post a tome about String, but here's a basic list of features/methods missing in String:

1. The lack a Character type that are the constituent elements of a String
2. Missing methods (Java names used): valueOf, charAt, trim(), length(), getBytes(), toUpperCase(), toLowerCase()
3. The lack of the + operator for appending
4. The lack of a StringBuilder (Java again) class

Optionals present a giant spider web of interconnectedness and syntax idiosyncrasy that does not provide any real advantage compared with Java/C#.

How about “no more NullPointerExceptions?” And again, “no real advantage” is just opinion with nothing behind it. Optionals have a long history in functional languages and a lot of users of said languages who feel that they’re beneficial.

The cost of !, ? and ?? everywhere in the language is a huge coding and maintenance inconvenience for the programmer error condition referencing a variable that contains the value null.

The fact that Ints, etc. are not really primitives (unwrapping is required, sometimes explicit, sometimes implicit) is a major dislocation for those coming from all C-syntax-based languages.

Integers are primitives. More so than in Java, C# or other “managed” languages, since Swift compiles directly to machine code.

The fact that you claim Ints are primitives and Loïc Lecrenier in an email three minutes prior writes "Swift does not have primitives, but I consider that a plus..." Which is it?

In addition, memory management (your reference to "language management") has nothing to do with whether or not integers are primitives. In Java, "int" is a primitive and "Integer" is not.

The lack of non-checked exceptions (that is exceptions not declared with a throws clause on the func def) is problem.

Swift doesn’t have exceptions at all; its error handling is fundamentally different, despite reusing some common names like “throw”. I suspect you haven’t really understood how error handling in Swift works, since “non-checked” isn’t an attribute that has any meaning in Swift’s model.

Swift doesn't have exceptions? What are the "throws" clause on funcs and the try and throw statements?

The lack of packages and/or namespaces is another giant gaping hole.

I agree with this, but I think it’s something that’s going to be addressed in the future (see the current work on the package manager.)

—Jens

I come from the perspective of 45 years of experience in dozens of programming languages. Swift seems to be trying to be everything to everybody - a bridge from Obj-C, functional, imperative, procedural, object-oriented with a somewhat Java and C-like syntax. I've seen this movie before - it was called PL/I and was the IBM answer to merging COBOL and FORTRAN. Survivors: COBOL and FORTRAN. It appears to me that Swift is today's PL/I.

Don


(Jens Alfke) #13

The bigger point is that in Swift you always know at the call site whether something can fail. That is, you can see the possible flows of control by inspecting the code.

Consider this block of code:
  { foo(); bar(); endFoo(); }
If foo is called, will endFoo() also be called?

In C++/Java/C# it’s not possible to tell without doing extensive analysis of the implementation of bar (and everything that bar calls), because bar might throw an exception and derail this flow of control. (And worse, some later code change far away might add an unchecked exception, making your analysis wrong!) This then requires adding noise in the form of a ‘finally’ block or a helper class implementing RAII, if it’s really important that endFoo be called. In a lot of cases this is “too much trouble” so a lot of code gets left like above, and will break some invariant if the endFoo call gets skipped.

In Swift you can be sure that, if this block is entered, all three functions will be called. (Unless the process hits a fatal exception like an assertion failure or bus error and exits.) If it’s possible for bar to fail, then
(a) the call to bar will have to be prefixed with ‘try’, which is a yellow flag to the programmer noting the possibility*; and
(b) the block will have to be inside a `do … catch` block, in the same function, to handle the error. An error in bar() can’t just abort the function silently. Any cleanup that has to be done will be explicit.

—Jens

* The requirement of the ‘try’ prefix means that if a function that isn’t failable later gets modified to be failable, every call site will now trigger a compile error due to the missing ‘try’ keyword. This means the programmer who made the change will have to go through the codebase and consider the possibility of failure and adjust the call site accordingly. This is a really good thing!

···

On Jan 6, 2016, at 11:40 AM, Jeremy Pereira via swift-users <swift-users@swift.org> wrote:

In Swift, you throw errors, not exceptions. The word exception is (more or less) reserved for conditions that terminate the process.

There are no unchecked errors but then why would you not want to handle an error condition if it occurs? Why would you not want to know that an API can throw an error?


(Greg Parker) #14

Swift's error system does put some burden on careful API design. The API author does need to choose "throwing" vs "not throwing" correctly up front.

On the other hand, the API author does not need to predict *which* errors might be thrown in the future. That avoids most of the difficulty for most API.

The API author's loss is the API client's gain. For anything that does not throw, the API client does not need to defensively assume that everything could throw in the future. This is good because writing exception-safe code is hard, especially if you can't test it.

We decided this was the right distribution of pain. The API author needs to plan ahead a little bit (but not as much as in a pure checked-exception system). The API client is safe almost everywhere against the threat of unusual control flow, and the presence of unusual control flow is always marked `try` when it is necessary.

···

On Jan 6, 2016, at 1:12 PM, Don Wills via swift-users <swift-users@swift.org> wrote:

On Jan 6, 2016, at 1:15 PM, Jens Alfke <jens@mooseyard.com> wrote:

* The requirement of the ‘try’ prefix means that if a function that isn’t failable later gets modified to be failable, every call site will now trigger a compile error due to the missing ‘try’ keyword. This means the programmer who made the change will have to go through the codebase and consider the possibility of failure and adjust the call site accordingly. This is a really good thing!

It also means that every third party API provider will *never* be able to change any method signature from failable to non-failable or vice-versa. That is a really bad thing! This concern is why Microsoft rightly chose to have *only* non-checked exceptions in C# (Java has both checked and non-checked).

--
Greg Parker gparker@apple.com Runtime Wrangler


(Donald Pinckney) #15

Hi Erica, and others with feedback,

Thanks for your positive feedback about my playground. Top of my list for critical features would be what Loïc mentioned, some mathematical notation support inside the playground markdown. Currently I embedded PDFs which I rendered using LaTeX, but it would be amazing to perhaps have native LaTeX support in playgrounds.

Erica,
I really like all your suggestions, and I can certainly feel how they could contribute to creating very interactive learning resources. I'm not quite understanding the 3rd bullet, but I'm sure it's just as great of a suggestion as the others ;).

Donald Pinckney

···

Sent from my iPhone

On Jan 6, 2016, at 10:48 AM, Erica Sadun <erica@ericasadun.com> wrote:

Don,

I love your playground. This highlights a few areas where I really would love to see some enhancements from the playground team. Here are a few off the top of my head. My actual list is longer:

* Your students should be able to have an appropriate input and submission component that isn't compiled -- answering in freeform language to the questions.
* Playgrounds need a "reset" button that enable any tweaks to return to a pristine state for starting over.
* Playgrounds should offer a "compute this outside" option, that allows you to add code *inside* the pages but have them computed outside. For example in your playground there's the harmonic oscillator, and a few other number-crunchy stop points.
* Playgrounds should be able to integrate video and audio snippets so it's not just all text text text for lessons
* Playgrounds need support for grammar / spelling tests and writing tools.
* Playgrounds should also include annotation tools (highlighting, notes) similar to what we see in iBooks as well as snippets/note support for collecting items (both text and code) between lessons

I could go on but I think you get the idea of how great it is to see this kind of development and how far it could be pushed for even better teaching/learning experiences.

-- Erica
p.s. I have a book on playgrounds in iBooks, if you want to ping me off-list, I'll send you a promo code

On Jan 6, 2016, at 11:32 AM, Tom Sheffler via swift-users <swift-users@swift.org> wrote:

Thanks for sharing this playground! I hadn’t seen anything quite like it, and it’s illuminating some of the possibilities.

On Jan 5, 2016, at 10:42 PM, Donald Pinckney via swift-users <swift-users@swift.org> wrote:

Hi all,
Personally, I love Swift, and I am curious to see if it will be used in educational settings, not necessarily even CS education. As something of an experiment to see how Swift could currently look in education, I coded a Swift playground (sorry, very Mac specific right now!) that is a rewriting of a lab activity we did in my 3rd quarter of physics. For those who are interested in educational aspects of Swift, and have a Mac to run this code, feel free to check out my attached playground, and give any sort of feedback, with respect to either the code or more philosophically where you think Swift could go with education.

Cheers,
Donald Pinckney

<Schrödinger.playground>

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users


(Joe Groff) #16

You can resiliently go from failable to not failable just fine without recompiling code; the compiler will warn about redundant try's, but it isn't an error, and the try keywords can be cleaned up easily. Introducing failability to non-failable APIs fundamentally requires all of your users to now audit their code for error safety; some languages choose not to let the compiler help you with this. Note that unlike Java, we intentionally don't restrict errors to a particular type, so you can introduce new failure modes without breaking your API.

-Joe

···

On Jan 6, 2016, at 1:12 PM, Don Wills via swift-users <swift-users@swift.org> wrote:

On Jan 6, 2016, at 1:15 PM, Jens Alfke <jens@mooseyard.com> wrote:

* The requirement of the ‘try’ prefix means that if a function that isn’t failable later gets modified to be failable, every call site will now trigger a compile error due to the missing ‘try’ keyword. This means the programmer who made the change will have to go through the codebase and consider the possibility of failure and adjust the call site accordingly. This is a really good thing!

It also means that every third party API provider will *never* be able to change any method signature from failable to non-failable or vice-versa. That is a really bad thing! This concern is why Microsoft rightly chose to have *only* non-checked exceptions in C# (Java has both checked and non-checked).


(Don Wills) #17

It also means that every third party API provider will *never* be able to change any method signature from failable to non-failable or vice-versa. That is a really bad thing! This concern is why Microsoft rightly chose to have *only* non-checked exceptions in C# (Java has both checked and non-checked).

···

On Jan 6, 2016, at 1:15 PM, Jens Alfke <jens@mooseyard.com> wrote:

* The requirement of the ‘try’ prefix means that if a function that isn’t failable later gets modified to be failable, every call site will now trigger a compile error due to the missing ‘try’ keyword. This means the programmer who made the change will have to go through the codebase and consider the possibility of failure and adjust the call site accordingly. This is a really good thing!


(Jens Alfke) #18

API consistency is a good thing. A method that can fail is fundamentally different than the same method without failure — it’s comparable to adding another return value, or an ‘out’ parameter, both of which we would expect to be a breaking API change. Sneaking in unchecked exceptions is like saying “oh yeah, starting in version 3.5, calling this method might suddenly abort your flow of control and take you to back the nearest catch block, even though you didn’t think it could do that. I hope that’s not a problem.” (Reminds me of the way PHP introduces catastrophic API behavior changes under the hood in minor releases…)

If you do end up needing to add errors to an API method, you can do it by adding a new variant of the method that throws, deprecating the old version, and then removing the old one once clients have migrated.

—Jens

···

On Jan 6, 2016, at 1:12 PM, Don Wills <don.wills@portablesoftware.com> wrote:

It also means that every third party API provider will *never* be able to change any method signature from failable to non-failable or vice-versa. That is a really bad thing!


(Jens Alfke) #19

I disagree. Scripting languages are pretty universally dynamically-typed, interpreted, and have no visible compile/link stage. Swift isn’t like that at all. The clear ancestors are the C family (including Obj-C), Haskell (IIRC), and to a lesser degree Rust and Go. I don’t see any resemblance to Perl, Ruby, Python, etc.

I agree with the rest of what you’re saying, but it’s pretty obvious. The kinds of business you’re describing are conservative and just use what everyone else uses, and what every developer learns in school. 20 years ago they were probably using C or Pascal, 30 years ago it was probably COBOL. These are not early adopters.

Newer languages tend to fly under the radar for a while. There’s a growing use of Go, for example. (My employer, Couchbase, is using it in several shipping products.) Inside big tech companies like Facebook and Twitter there are all sorts of interesting languages being used internally, from Scala to Haskell. (Go is of course an obvious case of that.)

At this point Swift doesn’t even have a robust cross-platform standard library, so it’s way too early to start trying to sell it as a replacement for Java to enterprise coders. Right now Swift’s practical uses are for building iOS and Mac applications, period. But that’s going to change.

—Jens

···

On Jan 6, 2016, at 2:49 PM, Dru Satori <dru@druware.com> wrote:

It may use LLVM, but it is not a “C” style language, in fact, it feels more like a scripting language than many languages at this level.


(Loïc Lecrenier) #20

Oops, I just noticed (thanks Jen) that I replied to an off-topic comment. Sorry, Donald Pinckney :frowning:

Back on topic!

I love the playground. You should look into the XCPlayground framework to display graphics in the timeline instead of in-line, I think it would be nicer.
I see that you used pdf files for the formulas, and that didn’t render well on a dark background. It would be great if the markup language for playground supported mathematical notation. It is almost a necessity for using it in an educational settings.

Loïc

···

On Jan 6, 2016, at 6:58 PM, Loïc Lecrenier via swift-users <swift-users@swift.org> wrote:

Hi Don,

I don’t understand these complaints.

The String class is complicated, but it is not a disaster, it just needs more convenience methods. See: https://www.mikeash.com/pyblog/friday-qa-2015-11-06-why-is-swifts-string-api-so-hard.html for an explanation of the String API.

Optionals is an essential feature for writing safe code. I don’t see how it presents a giant spider web of interconnectedness. Plenty of languages have optionals (Rust, Haskell) and it has brought nothing but advantages.

Swift does not have primitives, but I consider that a plus: every type has access to the same features. It makes the language more consistent and more flexible. Also note that there is no performance cost to the way Swift represents Int. They are just as efficient as C’s int.
I also don’t understand what you mean by “unwrapping is required, sometimes explicit, sometimes implicit”.

I won’t comment on non-checked exceptions. But I’m not convinced this is a very valuable feature.

Maybe I’m misunderstanding what you mean by “package”, but isn't the Swift Package Manager a good solution for packages?
Namespaces also exist, although it is quite rudimentary. There is a proposal draft for “beefing up” import that tries to improve that.

Honestly, it seems like you haven’t given Swift a fair shot, and wanted to see a Java/C# clone instead.
It is also evolving very quickly, so I wouldn’t lose hope :slight_smile:

Regards,

Loïc

On Jan 6, 2016, at 6:34 PM, Don Wills via swift-users <swift-users@swift.org> wrote:

[soapbox]

Coming from the perspective of business applications market (Java and C#), I see major problems in moving to Swift. It's simple too different. The String class is a disaster. Optionals present a giant spider web of interconnectedness and syntax idiosyncrasy that does not provide any real advantage compared with Java/C#. The fact that Ints, etc. are not really primitives (unwrapping is required, sometimes explicit, sometimes implicit) is a major dislocation for those coming from all C-syntax-based languages. The lack of non-checked exceptions (that is exceptions not declared with a throws clause on the func def) is problem. The lack of packages and/or namespaces is another giant gaping hole.

I had high hopes when I first looked into Swift. Those hopes have been dashed, and I don't see anything in my limited view of the plans for Swift 3.0 that addresses any of these concerns or several others that I did not mention.

[/soapbox]

Don Wills

On Jan 6, 2016, at 10:15 AM, Dru Satori via swift-users <swift-users@swift.org> wrote:

There is a huge potential here. The weakness, today at least, is that with Swift 2.0, there remain some difficulties in terms of being dependent upon reaching out to Objective C to accomplish some tasks. Looking at what is coming with Swift 3.0, and the work done on the Linux port, I think there is a clear roadmap that makes many of these issues go away, but right now, today, I think it is a tough sell into the edu market.

On 1/6/16, 1:42 AM, "swift-users-bounces@swift.org on behalf of Donald Pinckney via swift-users" <swift-users-bounces@swift.org on behalf of swift-users@swift.org> wrote:

Hi all,
Personally, I love Swift, and I am curious to see if it will be used in educational settings, not necessarily even CS education. As something of an experiment to see how Swift could currently look in education, I coded a Swift playground (sorry, very Mac specific right now!) that is a rewriting of a lab activity we did in my 3rd quarter of physics. For those who are interested in educational aspects of Swift, and have a Mac to run this code, feel free to check out my attached playground, and give any sort of feedback, with respect to either the code or more philosophically where you think Swift could go with education.

Cheers,
Donald Pinckney

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users