Prototyping what Swift can look like in educational settings

Using Swift
21

I really don't understand optionals. This code fails with "Call can throw, but is not marked with try ..." on the program line: t1.mth("abc", s1);

class Test {
  private var s1 : String!

  func tst() {
    let t1 : Test1 = Test1()
    t1.mth("abc", s1)
  }
}

class Test1 {
  func mth(p1 : String, _ p2 : String) -> String {
    return p1
  }

  func mth(p1 : String, _ p2 : Any) throws -> String {
    return p1
  }
}

but the program compiles fine if I change the code in either of these two manners:

1. I define s1 as non-optional like this: private var s1 = "", or

2. I remove the second overloaded mth method (the one with "_ p2 : Any" as the second parameter and the throws clause)

Swift method lookup obviously chose the second mth func if it exists, but why?

22

Jens,

Pretty sure that we aren’t far apart here, but it is more a matter of perspective. I should preface this next bit by the statement that I was heavily invested in personally in getting Mono running on OS X, and today, I consider it a steaming pile of dung for OS X development because somewhere along the way, many of the business development things that needed to happen slipped by the way side.

The thing that I see about Swift is that right now, today, on Linux or OS X, if Swift is installed, I can open a terminal:

Touch hello.swift
vim hello.swift
i

print("Hello Swift");

Esc
:wq
swift hello.swift

And it runs, and behaves exactly like php, perl, ruby, etc. This makes it approachable like a scripting language. REPL and Playgrounds give it an interactivity that is reminiscent of Visual Basic, which sucked as language at it’s inception, but a very good case can be made, that Windows ascended to dominance over GEM, Mac and later the Amiga, entirely on the shoulders of Visual Basic and the Hobby Developers with it’s low barrier of entry. They cut their teeth on BASIC, and graduated to the GUI with VB.

From a technical perspective, Swift is much more C like, but at the same time, yes, it is a strongly typed language, but for the casual user, my example above:

let hello = "Hello Swift";

print("\(hello)");

Works exactly the same as:

let hello : String = "Hello Swift";

print("\(hello)”);

Removing that typing and the language is indistinguishable from many of the modern scripting languages.

···

From: Jens Alfke <jens@mooseyard.com<mailto:jens@mooseyard.com>>
Date: Wednesday, January 6, 2016 at 6:37 PM
To: Andy Satori <dru@druware.com<mailto:dru@druware.com>>
Cc: Don Wills <don.wills@portablesoftware.com<mailto:don.wills@portablesoftware.com>>, Donald Pinckney <djpinckney@ucdavis.edu<mailto:djpinckney@ucdavis.edu>>, "swift-users@swift.org<mailto:swift-users@swift.org>" <swift-users@swift.org<mailto:swift-users@swift.org>>
Subject: Re: [swift-users] "business applications market" flame

On Jan 6, 2016, at 2:49 PM, Dru Satori <dru@druware.com<mailto: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.

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

23

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?

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.

Absolutely and I think this is critical to successfully handling errors. In Java, there is compiler support for telling if a checked exception can happen at the call site (although you can’t tell just by looking at the line of code), but the callee can also throw a RuntimeException which is ignored by the compiler but can be caught if you want to catch it. This is a recipe for disaster much like propagating an Objective-C exception through a stack frame that is not exception safe. You cannot safely catch a RuntimeException because you do not know if functions higher up the chain properly cleaned up after themselves.

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.

+1 million for the “too much trouble” bit. I’ve even seen Java libraries where the rule was that all exceptions have to be RuntimeExceptions so that the caller doesn’t have to bother with error checking. It’s a disaster.

* 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!

You are preaching to the choir.

···

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

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

24

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

An API is a contract between the caller and callee. If you change it from non failable to failable, you are breaking the contract and likely introducing bugs into the code that calls it. As a consumer of your API, I absolutely do need to know if it has been changed to throw an error/exception just as much as I need to know if you add or remove parameters or change the return type.

The C# approach is brain dead in that, I have to assume every API can throw and put the error handling boiler plate in everywhere and the temptation is to ignore it. I think the Swift approach provides a much better balance.

···

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

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

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

25

You can do that with C too:

  touch hello.c
  vim hello.c
  i
  #include <stdio.h>
  int main() {printf(“Hello World!”); return 0;}
  Esc
  :wq
  cc hello.c && ./a.out

Does that make C a scripting language? :)

Having a REPL or playgrounds doesn’t really change what the language itself is; it just indicates good integration of the compiler into the development tools.

To me, what defines a scripting language is a forgiving syntax that lets you bang stuff out fast without worrying about types, and super high level libraries for doing file and text manipulation and running other processes. By contrast, even if I had a C REPL and playgrounds, it would still be a pain to use C to process a directory full of text files and transform their contents and pass that to another tool. Whereas I could do it in minutes with Ruby or bash.

—Jens

···

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

The thing that I see about Swift is that right now, today, on Linux or OS X, if Swift is installed, I can open a terminal:

Touch hello.swift
vim hello.swift
i
print("Hello Swift");
Esc
:wq
swift hello.swift

26

I really don't understand optionals. This code fails with "Call can throw, but is not marked with try ..." on the program line: t1.mth("abc", s1);

class Test {
  private var s1 : String!

  func tst() {
    let t1 : Test1 = Test1()
    t1.mth("abc", s1)
  }
}

class Test1 {
  func mth(p1 : String, _ p2 : String) -> String {
    return p1
  }

  func mth(p1 : String, _ p2 : Any) throws -> String {
    return p1
  }
}

but the program compiles fine if I change the code in either of these two manners:

1. I define s1 as non-optional like this: private var s1 = "", or

2. I remove the second overloaded mth method (the one with "_ p2 : Any" as the second parameter and the throws clause)

Swift method lookup obviously chose the second mth func if it exists, but why?

Seems like a bug to me. I'd expect overload resolution to favor the (String, String) overload over the Any overload even if using an implicitly-unwrapped optional like this.

-Joe

···

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

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

27

With regard to bullet 3, playgrounds vastly improve performance when you move code into Sources: http://ericasadun.com/2015/03/16/swift-vroom-vroom-fast-playgrounds/ (but then you can't see the code or tweak it *in* the playground)

-- Erica

···

On Jan 6, 2016, at 2:52 PM, Donald Pinckney <djpinckney@ucdavis.edu> wrote:

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

28

Swift method lookup obviously chose the second mth func if it exists, but why?

From the behavior here, it looks like the compiler is first looking for a matching method, then if it can’t find one it unwraps the optional parameter and looks for a match again. So in this case it immediately finds a match (the second mth) and doesn’t try unwrapping the String! parameter.

I have no idea whether that’s correct/intentional behavior, or a bug. I do know that function overloading can create weird situations in any language that supports it (notably C++), so I’m not surprised that there are some edge cases in Swift too.

I really don't understand optionals.

Well, think of the declaration of s1 as being
  private var s1 : Optional<String>
which is what it actually is under the hood. That makes it pretty clear that the 2nd mth method is the one that will get called. The confusion comes in when you also consider that the compiler will implicitly deref an Optional<String> to String if it’s been declared using “!”, in which case the first mth can be called. Now it’s sort of ambiguous which is preferable.

—Jens

···

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

29

Thank you for sharing the playground Donald! Great stuff!

···

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

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
>
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

30

I would argue that the language syntax is forgiving though, as my follow examples demonstrated.

The funny thing, is that your point about minutes versus hours is the very reason BASIC came to be ( easier math language ). But I think to a degree, we are discussing semantics. It seems we agree on the principle, that Swift is good, but it isn’t there as general purpose business dev language. :)

···

From: Jens Alfke <jens@mooseyard.com<mailto:jens@mooseyard.com>>
Date: Wednesday, January 6, 2016 at 7:40 PM
To: Andy Satori <dru@druware.com<mailto:dru@druware.com>>
Cc: Don Wills <don.wills@portablesoftware.com<mailto:don.wills@portablesoftware.com>>, Donald Pinckney <djpinckney@ucdavis.edu<mailto:djpinckney@ucdavis.edu>>, "swift-users@swift.org<mailto:swift-users@swift.org>" <swift-users@swift.org<mailto:swift-users@swift.org>>
Subject: Re: [swift-users] "business applications market" flame

On Jan 6, 2016, at 4:27 PM, Dru Satori <dru@druware.com<mailto:dru@druware.com>> wrote:

The thing that I see about Swift is that right now, today, on Linux or OS X, if Swift is installed, I can open a terminal:

Touch hello.swift
vim hello.swift
i
print("Hello Swift");
Esc
:wq
swift hello.swift

You can do that with C too:

touch hello.c
vim hello.c
i
#include <stdio.h>
int main() {printf(“Hello World!”); return 0;}
Esc
:wq
cc hello.c && ./a.out

Does that make C a scripting language? :)

Having a REPL or playgrounds doesn’t really change what the language itself is; it just indicates good integration of the compiler into the development tools.

To me, what defines a scripting language is a forgiving syntax that lets you bang stuff out fast without worrying about types, and super high level libraries for doing file and text manipulation and running other processes. By contrast, even if I had a C REPL and playgrounds, it would still be a pain to use C to process a directory full of text files and transform their contents and pass that to another tool. Whereas I could do it in minutes with Ruby or bash.

—Jens

31

IMO, Java has it right - let the API designer decide which approach to take.

One more time: Swift does not have exceptions at all (checked or not). You are comparing apples and oranges here, based on a surface similarity in syntax (keywords like “try” and “catch”), which indicates you haven’t paid attention to what the actual semantics are. If you want to make credible arguments about error handling, you’ll need a better understanding of it.

I note that Go — a language you profess to like a lot — has no exceptions either, and its error handling support is much more primitive and clumsy to use than Swift’s. (I say this having spent about a man-year coding in Go.)

The Swift designers attitude of "we know best, do it the way we tell you" will not play well with many programmers.

Go is pretty much the ultimate in that philosophy — Rob Pike and others are very up-front that they know what features are best and they will decide the right way to do things and if you disagree you are wrong. (Pike’s blog post about error handling from about a year ago is a great example of this arrogance.) I see the Swift developers being a lot more open about this, instituting a very open process for proposing and debating changes.

—Jens

···

On Jan 7, 2016, at 8:37 AM, Don Wills via swift-users <swift-users@swift.org> wrote:

32

Not this singer. Given the antipathy from posters here to unchecked exceptions, it seems amazing to me that C# has been successful at all, since unchecked exceptions are the only type available. IMO, Java has it right - let the API designer decide which approach to take. The Swift designers attitude of "we know best, do it the way we tell you" will not play well with many programmers. An example of that coming in Swift 3 is the removal of pre and post increment and decrement operators. And yes, C++ is a horrible language. I'm with Linus on that.

···

On Jan 7, 2016, at 2:45 AM, Jeremy Pereira <jeremy.j.pereira@googlemail.com> wrote:

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

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?

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.

Absolutely and I think this is critical to successfully handling errors. In Java, there is compiler support for telling if a checked exception can happen at the call site (although you can’t tell just by looking at the line of code), but the callee can also throw a RuntimeException which is ignored by the compiler but can be caught if you want to catch it. This is a recipe for disaster much like propagating an Objective-C exception through a stack frame that is not exception safe. You cannot safely catch a RuntimeException because you do not know if functions higher up the chain properly cleaned up after themselves.

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.

+1 million for the “too much trouble” bit. I’ve even seen Java libraries where the rule was that all exceptions have to be RuntimeExceptions so that the caller doesn’t have to bother with error checking. It’s a disaster.

* 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!

You are preaching to the choir.

33

Yes, I recognize that the "my way or the highway" attitude is issue among many language designers today. But, IMO, the dictators at Go made a few better decisions.

···

On Jan 7, 2016, at 10:13 AM, Jens Alfke <jens@mooseyard.com> wrote:

On Jan 7, 2016, at 8:37 AM, Don Wills via swift-users <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:

IMO, Java has it right - let the API designer decide which approach to take.

One more time: Swift does not have exceptions at all (checked or not). You are comparing apples and oranges here, based on a surface similarity in syntax (keywords like “try” and “catch”), which indicates you haven’t paid attention to what the actual semantics are. If you want to make credible arguments about error handling, you’ll need a better understanding of it.

I note that Go — a language you profess to like a lot — has no exceptions either, and its error handling support is much more primitive and clumsy to use than Swift’s. (I say this having spent about a man-year coding in Go.)

The Swift designers attitude of "we know best, do it the way we tell you" will not play well with many programmers.

Go is pretty much the ultimate in that philosophy — Rob Pike and others are very up-front that they know what features are best and they will decide the right way to do things and if you disagree you are wrong. (Pike’s blog post about error handling from about a year ago is a great example of this arrogance.) I see the Swift developers being a lot more open about this, instituting a very open process for proposing and debating changes.

—Jens

34

IMO, Java has it right - let the API designer decide which approach to take.

That's a frankly laughable misreading of the Java story. The Java story is that they wanted everyone to use checked exceptions, but the users loathed them so much that they found hacks to get around the checked exception system, from subclassing `RuntimeException` or `Error` to labeling everything `throws Exception`. This is hardly a shining model of good language design.

···

--
Brent Royal-Gordon
Architechies

35

So far it seems to me that Swift is a powerful "c" type language that can also be used in a script-like way. Definitely a win.

Hopefully as version 3 gets closer there will have emerged some useful pure swift modules for DB access (Oracle, SQL Server/MongoDB etc) as well as other middleware. I'm expecting that IBM will have some good involvement here.

-Dave

···

On Jan 6, 2016, at 7:45 PM, Dru Satori via swift-users <swift-users@swift.org> wrote:

I would argue that the language syntax is forgiving though, as my follow examples demonstrated.

The funny thing, is that your point about minutes versus hours is the very reason BASIC came to be ( easier math language ). But I think to a degree, we are discussing semantics. It seems we agree on the principle, that Swift is good, but it isn’t there as general purpose business dev language. :)

From: Jens Alfke <jens@mooseyard.com>
Date: Wednesday, January 6, 2016 at 7:40 PM
To: Andy Satori <dru@druware.com>
Cc: Don Wills <don.wills@portablesoftware.com>, Donald Pinckney <djpinckney@ucdavis.edu>, "swift-users@swift.org" <swift-users@swift.org>
Subject: Re: [swift-users] "business applications market" flame

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

The thing that I see about Swift is that right now, today, on Linux or OS X, if Swift is installed, I can open a terminal:

Touch hello.swift
vim hello.swift
i
print("Hello Swift");
Esc
:wq
swift hello.swift

You can do that with C too:

touch hello.c
vim hello.c
i
#include <stdio.h>
int main() {printf(“Hello World!”); return 0;}
Esc
:wq
cc hello.c && ./a.out

Does that make C a scripting language? :)

Having a REPL or playgrounds doesn’t really change what the language itself is; it just indicates good integration of the compiler into the development tools.

To me, what defines a scripting language is a forgiving syntax that lets you bang stuff out fast without worrying about types, and super high level libraries for doing file and text manipulation and running other processes. By contrast, even if I had a C REPL and playgrounds, it would still be a pain to use C to process a directory full of text files and transform their contents and pass that to another tool. Whereas I could do it in minutes with Ruby or bash.

—Jens

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

36

Oh, on OS X, swift works fine with PostgreSQL and ODBC datasources via Obj-C frameworks, that isn’t the challenge.

I’ve started porting both of those frameworks to Swift already. There are some ‘challenges’ that are slowing that process down, and even more so, there are some decisions to be made with regards to exception handling and optionals that I am still feeling my way through.

What I’m doing is using those frameworks as a base and building one for TDS databases (Sybase/MSSQL) from the ground up. It is time consuming, and honestly, I’ve made no decision on if I’ll make the code available (as I’ll have a bit of time invested in it, and as a rule DB libraries don’t generate revenue, but sure do generate support requests!)

···

From: Dave Fenton <sirdavidfenton@gmail.com<mailto:sirdavidfenton@gmail.com>>
Date: Wednesday, January 6, 2016 at 7:59 PM
To: Andy Satori <dru@druware.com<mailto:dru@druware.com>>
Cc: Jens Alfke <jens@mooseyard.com<mailto:jens@mooseyard.com>>, "swift-users@swift.org<mailto:swift-users@swift.org>" <swift-users@swift.org<mailto:swift-users@swift.org>>
Subject: Re: [swift-users] "business applications market" flame

So far it seems to me that Swift is a powerful "c" type language that can also be used in a script-like way. Definitely a win.

Hopefully as version 3 gets closer there will have emerged some useful pure swift modules for DB access (Oracle, SQL Server/MongoDB etc) as well as other middleware. I'm expecting that IBM will have some good involvement here.

-Dave

On Jan 6, 2016, at 7:45 PM, Dru Satori via swift-users <swift-users@swift.org<mailto:swift-users@swift.org>> wrote:

I would argue that the language syntax is forgiving though, as my follow examples demonstrated.

The funny thing, is that your point about minutes versus hours is the very reason BASIC came to be ( easier math language ). But I think to a degree, we are discussing semantics. It seems we agree on the principle, that Swift is good, but it isn’t there as general purpose business dev language. :)

From: Jens Alfke <jens@mooseyard.com<mailto:jens@mooseyard.com>>
Date: Wednesday, January 6, 2016 at 7:40 PM
To: Andy Satori <dru@druware.com<mailto:dru@druware.com>>
Cc: Don Wills <don.wills@portablesoftware.com<mailto:don.wills@portablesoftware.com>>, Donald Pinckney <djpinckney@ucdavis.edu<mailto:djpinckney@ucdavis.edu>>, "swift-users@swift.org<mailto:swift-users@swift.org>" <swift-users@swift.org<mailto:swift-users@swift.org>>
Subject: Re: [swift-users] "business applications market" flame

On Jan 6, 2016, at 4:27 PM, Dru Satori <dru@druware.com<mailto:dru@druware.com>> wrote:

The thing that I see about Swift is that right now, today, on Linux or OS X, if Swift is installed, I can open a terminal:

Touch hello.swift
vim hello.swift
i
print("Hello Swift");
Esc
:wq
swift hello.swift

You can do that with C too:

touch hello.c
vim hello.c
i
#include <stdio.h>
int main() {printf(“Hello World!”); return 0;}
Esc
:wq
cc hello.c && ./a.out

Does that make C a scripting language? :)

Having a REPL or playgrounds doesn’t really change what the language itself is; it just indicates good integration of the compiler into the development tools.

To me, what defines a scripting language is a forgiving syntax that lets you bang stuff out fast without worrying about types, and super high level libraries for doing file and text manipulation and running other processes. By contrast, even if I had a C REPL and playgrounds, it would still be a pain to use C to process a directory full of text files and transform their contents and pass that to another tool. Whereas I could do it in minutes with Ruby or bash.

—Jens

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

37

+1. Been there, done that :)

Another factor is that in the Java (and C++) environment, nearly anything can fail, since ‘new’ can throw an OutOfMemoryError*, and programmer mistakes like out-of-range array indexes or failed type-casts are treated as theoretically-recoverable exceptions. Therefore nearly any nontrivial method can potentially throw, so having unchecked exceptions is a requirement or else all of those methods would have to be labeled as ‘throws’.

This is in contrast with Swift (and Go) where errors are higher-level — things like I/O errors — while assertion failures will unconditionally abort. This makes program logic a lot easier to follow, since the jumps caused by exceptions are notoriously unintuitive (being a form of invisible goto.)

—Jens

* This was reasonable in the 1990s, but makes little sense in the OSs most of us code for today, on which malloc() will pretty much never return NULL. (Embedded OSs are an exception.)

···

On Jan 7, 2016, at 12:27 PM, Brent Royal-Gordon via swift-users <swift-users@swift.org> wrote:

IMO, Java has it right - let the API designer decide which approach to take.

That's a frankly laughable misreading of the Java story. The Java story is that they wanted everyone to use checked exceptions, but the users loathed them so much that they found hacks to get around the checked exception system

38

I think it’s a bug.

This (in which s1 is explicitly unwrapped instead of implicitly unwrapped)

class Test {
    private var s1 : String?

    func tst() {
        let t1 : Test1 = Test1()
        t1.mth("abc", s1!)
    }
}

compiles just fine and should be equivalent to Don’s original code in which s1 is optional but implicitly unwrapped.

I think you should raise a bug, Don.

···

On 7 Jan 2016, at 04:53, Jens Alfke via swift-users <swift-users@swift.org> wrote:

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

Swift method lookup obviously chose the second mth func if it exists, but why?

From the behavior here, it looks like the compiler is first looking for a matching method, then if it can’t find one it unwraps the optional parameter and looks for a match again. So in this case it immediately finds a match (the second mth) and doesn’t try unwrapping the String! parameter.

I have no idea whether that’s correct/intentional behavior, or a bug. I do know that function overloading can create weird situations in any language that supports it (notably C++), so I’m not surprised that there are some edge cases in Swift too.

I really don't understand optionals.

Well, think of the declaration of s1 as being
  private var s1 : Optional<String>
which is what it actually is under the hood. That makes it pretty clear that the 2nd mth method is the one that will get called. The confusion comes in when you also consider that the compiler will implicitly deref an Optional<String> to String if it’s been declared using “!”, in which case the first mth can be called. Now it’s sort of ambiguous which is preferable.

—Jens

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

39

It would be interesting to see how far Swift’s syntax can be pushed to create a cleaner syntax for queries. I’m thinking of C#’s LINQ, which is really sweet. Some LINQ stuff can be replicated in Swift, I believe, but there are parts of it that rely on a super-powerful C# feature where a function can receive a parameter in the form of a parse tree of the expression. (Sort of like LISP macros.)

—Jens

···

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

Oh, on OS X, swift works fine with PostgreSQL and ODBC datasources via Obj-C frameworks, that isn’t the challenge.

40

It would be interesting to see how far Swift’s syntax can be pushed to create a cleaner syntax for queries. I’m thinking of C#’s LINQ, which is really sweet. Some LINQ stuff can be replicated in Swift, I believe, but there are parts of it that rely on a super-powerful C# feature where a function can receive a parameter in the form of a parse tree of the expression. (Sort of like LISP macros.)

Back in the Swift 1 days, I experimented with writing NSPredicates in Swift: <https://github.com/brentdax/PrediKit&gt;

···

--
Brent Royal-Gordon
Architechies