[swift-users] "business applications market" flame

[Jeremy Pereira]

> On 6 Jan 2016, at 18:30, Don Wills via swift-users <swift-users at swift.org> wrote:
> 
> Points well taken.
> 
>> On Jan 6, 2016, at 11:02 AM, Jens Alfke <jens at mooseyard.com> wrote:
>> 
>> 
> 
> 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. 


> 
> Don
> 
> _______________________________________________
> swift-users mailing list
> swift-users at swift.org
> https://lists.swift.org/mailman/listinfo/swift-users