[swift-users] Prototyping what Swift can look like in educational settings

[Loïc Lecrenier]

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 :-)

Regards,

Loïc

> On Jan 6, 2016, at 6:34 PM, Don Wills via swift-users <swift-users at 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 at 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 at swift.org on behalf of Donald Pinckney via swift-users" <swift-users-bounces at swift.org on behalf of swift-users at 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 at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
>> 
> 
> _______________________________________________
> swift-users mailing list
> swift-users at swift.org
> https://lists.swift.org/mailman/listinfo/swift-users