> On Jan 6, 2016, at 10:30 AM, Don Wills <don.wi...@portablesoftware.com> wrote:
>
> 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
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
