[swift-users] "business applications market" flame

[Dru Satori]

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 at portablesoftware.com> wrote:

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