Re: Need for Swift

[Charles Srstka via Cocoa-dev]

> On Oct 16, 2019, at 2:38 PM, Jean-Daniel via Cocoa-dev 
>  wrote:
> 
>> Le 16 oct. 2019 à 11:49, Stephane Sudre via Cocoa-dev 
>> mailto:cocoa-dev@lists.apple.com>> a écrit :
>> 
>> On Tue, Oct 15, 2019 at 2:26 PM Sandor Szatmari via Cocoa-dev
>> mailto:cocoa-dev@lists.apple.com>> wrote:
>> 
>>> But honestly, I don’t have enough Swift experience to know if you can write 
>>> bad Swift code.
>> 
>> I'm just reading Swift code here and there and it's my personal
>> opinion that 75% of the Swift code I read is bad code.
> 
> That matches my observation whatever the language is. 
> This is not something related to Swift. This is just how most developers 
> works.

+1

>> Why do Swift developers think it's mandatory to write code that is illegible?
>> Is Swift mainly used by freelances or consultants that will not have
>> to maintain the software?
> 
> Not more than other projects with language designed to be easy to use and 
> usable by as many people as possible.
> 
> You won’t find as much bad C++ and Rust code because the complexity of the 
> languages filter out casual developers.

And it’s certainly not as if there’s not a lot of terrible Objective-C code out 
there.

Charles

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Need for Swift

[Jean-Daniel via Cocoa-dev]

> Le 16 oct. 2019 à 11:49, Stephane Sudre via Cocoa-dev 
>  a écrit :
> 
> On Tue, Oct 15, 2019 at 2:26 PM Sandor Szatmari via Cocoa-dev
>  wrote:
> 
>> But honestly, I don’t have enough Swift experience to know if you can write 
>> bad Swift code.
> 
> I'm just reading Swift code here and there and it's my personal
> opinion that 75% of the Swift code I read is bad code.

That matches my observation whatever the language is. 
This is not something related to Swift. This is just how most developers works.

> Why do Swift developers think it's mandatory to write code that is illegible?
> Is Swift mainly used by freelances or consultants that will not have
> to maintain the software?

Not more than other projects with language designed to be easy to use and 
usable by as many people as possible.

You won’t find as much bad C++ and Rust code because the complexity of the 
languages filter out casual developers.





___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Need for Swift

[Alex Zavatone via Cocoa-dev]

> On Oct 16, 2019, at 4:49 AM, Stephane Sudre via Cocoa-dev 
>  wrote:
> 
> Why do Swift developers think it's mandatory to write code that is illegible?
> Is Swift mainly used by freelances or consultants that will not have
> to maintain the software?

The zest to do things in a way, “because it is Swifty”.  

That doesn’t mean that it is good.  And people insist that “because it is 
Swifty”, it must be the new best thing and clearly everyone else “just doesn’t 
understand the new way”.

It’s pretty arrogant, but that’s what I’ve seen as well.  People need to 
evaluate a new approach and based upon their experience, decide if it is a good 
thing.  Honestly, our developers want to rush to SwiftUI and embrace everything 
new without realizing that we still need to support users running iOS 10.  

Anyway, It’s an enthusiastic jump to adopt the new without considering what 
about it is wise to do.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Need for Swift

[Stephane Sudre via Cocoa-dev]

On Tue, Oct 15, 2019 at 2:26 PM Sandor Szatmari via Cocoa-dev
 wrote:

> But honestly, I don’t have enough Swift experience to know if you can write 
> bad Swift code.

I'm just reading Swift code here and there and it's my personal
opinion that 75% of the Swift code I read is bad code.

By bad code, I mean code suffering from the "only God and I know what
I'm doing" syndrome.

The same syndrome that you can find in software using Cocoa bindings.
The same software that is terrible to maintain, even more when you're
not the original author (and you're obviously not God).

Why do Swift developers think it's mandatory to write code that is illegible?
Is Swift mainly used by freelances or consultants that will not have
to maintain the software?
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Need for Swift

[Alex Zavatone via Cocoa-dev]

> On Oct 15, 2019, at 6:08 PM, Charles Srstka via Cocoa-dev 
>  wrote:
> 
> Seeing lots of `!` in production Swift is a code smell.
> 
> Charles

I wouldn’t call it a code smell.  It’s worse.  It’s actually asking for a crash 
if everything doesn’t work out perfectly and an expected result is nil.  And 
that’s exactly what will happen.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Need for Swift

[Greg Weston via Cocoa-dev]

> This discussion about Swift vs Objective-C is interesting, but I think it
> omits something important. Both those languages only build apps for Apple
> products.

This was probably “omitted” because it’s not actually true.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Need for Swift

[Jens Alfke via Cocoa-dev]

> On Oct 15, 2019, at 10:52 AM, Turtle Creek Software  
> wrote:
> 
> Diving down into C sounds like a reasonable option for a database library.  
> It does not sound good for a specialty app that does construction estimating 
> and accounting.

I don't see the difference, for the purposes of this discussion. Either way 
you'd have core code in C++ that you call into via a C API.

> Libraries just show Assembly when you step into them, no?  

No. Not if it's a static library; and not if it's a dynamic library you have 
symbols for, as you do if you built it.

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Need for Swift

[Charles Srstka via Cocoa-dev]

> On Oct 14, 2019, at 10:44 PM, Laurent Daudelin via Cocoa-dev 
>  wrote:
> 
> Are people supposed to know instinctively when you unwrap with “?” and when 
> you do with “!”?

It’s quite simple; you nearly always unwrap with `?`.

The tiny minority of the time that `!` is needed is when you *know* something 
will never be nil, because a guarantee is being made somewhere else that the 
Swift compiler can’t see. Most of the time, in practice, this is because you’re 
dealing with data included with your own application. This plist key will 
*always* be set… because it’s in a plist that I included in the application, 
and I know what’s in it. This outlet will always be connected, because it’s in 
a nib that I included in the app, and I *know* that I’ve always connected it. 
If I forget to connect that outlet, it’s a *bug*, and the app *should* crash.

The other time `!` can be useful is when you’re not writing code that’s meant 
for production, when you’re prototyping or just screwing around in a playground 
or the debugger, and you don’t really care about correctness.

Seeing lots of `!` in production Swift is a code smell.

Charles

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Need for Swift

[Alex Zavatone via Cocoa-dev]

Sent from my iPhone

> On Oct 15, 2019, at 7:25 AM, Sandor Szatmari  
> wrote:
> 
> Obj-C represents the freedom for me to write bad code if I need to…

Believe me, I have been living in the results of the bad code that Swift allows 
developers to create.  Debugging how a tap in a UITableViewCell actually gets 
back to the view controller took me a day to wade through the excessive 
spaghetti when target : action and a weak ref to the VC or object that handles 
the action is painfully easy and does not introduce excess unneeded hard to 
debug code.

Swift is not a cure-all. That’s for sure.



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Need for Swift

[Jean-Daniel via Cocoa-dev]

> Le 15 oct. 2019 à 04:43, Alex Zavatone via Cocoa-dev 
>  a écrit :
> 
> 
> 
>> On Oct 14, 2019, at 1:25 PM, Carl Hoefs via Cocoa-dev 
>>  wrote:
>> 
>> The group that likes Obj-C sees Swift as being "arbitrarily syntactical" 
>> with the syntax of the language getting in the way of programming. (There is 
>> a third group that likes both languages, but it is very small.)
> 
> I am in this group.  The syntax of Swift just feels so arbitrary and to look 
> deeper to solve more problems… if it weren’t for those compiler messages, it 
> would be a mess.  I, for one shuddered when I saw “if let x = y” being 
> something that people are expected to use and that damn, “you must unwrap 
> this optional”, simply ends up making things that were simple in Objective-C, 
> completely cumbersome in Swift.  

Nobody force you to use "if let ».

If you want to write error prone code like in Obj-C, just use optional 
chaining. This is exactly the same than dispatching message without checking 
for nil before and will works as you like to do in Obj-C.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Need for Swift

[Jeremy Hughes via Cocoa-dev]

> On 15 Oct 2019, at 18:27, Turtle Creek Software via Cocoa-dev 
>  wrote:
> 
> MVC is an excellent design paradigm.  The M and V layers were no problem at
> all to set up. The C started out easy, but ended up being a big problem.
> Quite a bit of the business logic is not just data, but fancy stuff that
> happens with the GUI. Fields that switch between % and $, table cells that
> change other table cells, etc. There is a lot of code in our C++
> RecordViewer classes to make that happen, and it didn't integrate easily
> with NSWindowControllers or NSViewControllers.  It often was faster to just
> redo the logic in Cocoa.  That took a lot of time. Much more rewriting than
> expected.

If the RecordViewer is a controller of some kind, could you not add it to a 
view controller, and let the view controller (an ObjC++ subclass of 
NSViewController) call the RecordViewer to make these changes?

It sounds like you actually made quite a bit of progress if you’ve already 
rewritten the View (V) layers, and the Model (M) layer is separate.

Jeremy

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Need for Swift

[Laurent Daudelin via Cocoa-dev]

2-3 programmer-years seems a lot to me already.

-Laurent.
-- 
Laurent Daudelin
laur...@nemesys-soft.com 
Skype: LaurentDaudelin  
Logiciels Némésys Software  
http://www.nemesys-soft.com/ 

> On Oct 15, 2019, at 13:27, Turtle Creek Software via Cocoa-dev 
>  wrote:
> 
> We did put 2 or 3 programmer-years into a Cocoa GUI.  Problem is, it
> appears that it will need 2 or 3 more.  There probably won't be enough Mac
> buyers left in 2 or 3 years to pay for that.
> 
> I agree that QT, wxWidget and Electron build crappy apps.  And some effort
> will always be required to interface between one's working code, and the
> GUI layer.  It's just a matter of making that effort small enough so one
> can bring a product to market fast enough and cheaply enough to get paid
> decently for the work.
> 
> MVC is an excellent design paradigm.  The M and V layers were no problem at
> all to set up. The C started out easy, but ended up being a big problem.
> Quite a bit of the business logic is not just data, but fancy stuff that
> happens with the GUI. Fields that switch between % and $, table cells that
> change other table cells, etc. There is a lot of code in our C++
> RecordViewer classes to make that happen, and it didn't integrate easily
> with NSWindowControllers or NSViewControllers.  It often was faster to just
> redo the logic in Cocoa.  That took a lot of time. Much more rewriting than
> expected.
> 
> Within source files, Objective-C++ is fantastic.  It really makes Cocoa
> coding easy for C++ programmers. We were surprised about how well it
> worked.  I probably didn't mention Obj-C++ because it became second nature
> so quickly.  If all parts of Cocoa were like that, we would have finished
> by now.
> 
> The basic language problem as I see it is in the headers.  Classes are
> either Obj-C or C++ and can't be both.  It turned out to be an enormous
> barrier that caused all sorts of pains.
> 
> Casey McDermott
> TurtleSoft.com
> 
> 
> 
> On Tue, Oct 15, 2019 at 12:20 PM Jens Alfke  wrote:
> 
>> 
>>> On Oct 15, 2019, at 6:59 AM, Turtle Creek Software via Cocoa-dev <
>> cocoa-dev@lists.apple.com> wrote:
>>> 
>>> TurtleSoft has a big investment in C++ source code that's full of
>>> construction business logic. Unfortunately, with the death of Carbon its
>>> future value is in doubt.
>> 
>> I know I’ve brought up Objective-C++ to you here before, but I’m not sure
>> you registered its existence, based on comments like this.
>> 
>> Any well-designed app keeps the data model and core business logic
>> separate from the UI. So having that logic in C++ is not a big problem.
>> 
>> As for the UI code, I’ve still never found a cross-platform UI framework
>> that creates decent apps. Qt is hideous, and Electron results in immensely
>> bloated websites-in-a-box. So to do a good job, you need to code the UI for
>> each platform anyway.
>> 
>> —Jens
>> 
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Need for Swift

[Alex Zavatone via Cocoa-dev]

Sent from my iPhone

> On Oct 15, 2019, at 10:37 AM, John Joyce via Cocoa-dev 
>  wrote:
> 
> 
> 
>> 
>> On Oct 15, 2019, at 22:58, Turtle Creek Software via Cocoa-dev 
>>  wrote:
>> 
>> Nobody
>> is every going to write a full CAD, project management or business
>> accounting app in either Swift or Obj-C.
>> 
>> TurtleSoft has a big investment in C++ source code that's full of
>> construction business logic. Unfortunately, with the death of Carbon its
>> future value is in doubt.
> If your code is worth complaining about this much, then move to Objective-C++ 
> and wire up a damn UI. That or Electron, wxWidgets or Qt or one of the 
> plethora of mostly abysmal cross platform GUI toolkits. 
> It’s getting old and it’s just a drag for everybody. 
> Carbon is dead and nobody was surprised by this but your company somehow. 
> Everybody else got the memo a decade ago. Spam this list less and go do some 
> coding. 

I think what the benefit could be is to see the problems he has and sharing 
options to address them - just as you did.

Is it possible to approach this on a module by module approach?

If he were to take your approach, how would you recommend he start?

Cheers.  Back to hell for me.
Alex Zavatone



> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com
> 
> This email sent to z...@mac.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Need for Swift

[Alex Zavatone via Cocoa-dev]

The push for server side Swift is interesting in that it embodies the 
philosophy of moving Swift to other platforms/arenas.

Sent from my iPhone

> On Oct 15, 2019, at 8:57 AM, Turtle Creek Software via Cocoa-dev 
>  wrote:
> 
> This discussion about Swift vs Objective-C is interesting, but I think it
> omits something important. Both those languages only build apps for Apple
> products.
> 
> It's not such a big deal for iOS. iPhones are dominant enough that people
> can write just for that. Phone/pad apps are also relatively small, so a
> rewrite for Android is not too difficult if you want to go cross-platform.
> 
> For PCs it's a different story. Mac has about 10% market share overall, but
> it varies. In our market, architects are about 20% Mac, engineers less than
> 1%, construction maybe 2%.  The apps are bigger and more complex.  Nobody
> is every going to write a full CAD, project management or business
> accounting app in either Swift or Obj-C.
> 
> TurtleSoft has a big investment in C++ source code that's full of
> construction business logic. Unfortunately, with the death of Carbon its
> future value is in doubt.
> 
> I just checked a half dozen sites that measure popularity of programming
> languages. The Stack Overflow survey seemed the best, since they directly
> asked folks what they use. For 2019, their top 5 app-development languages
> are Python, Java, C#, C++ and C in that order. 42% of respondents use
> Python, down to 20% for C. Interestingly, there is a huge gap after that.
> Their next most popular app-dev language is Go at 8.8%. Swift rated 6.6%
> and Objective-C was 4.8%. Then there is a long, long tail of other
> languages with a few % or less.
> 
> PYPL puts the top 5 in the same order. TIOBE index ranks them as Java, C,
> Python, C++, C#. Both those lists put Obj-C ahead of Swift, with the Apple
> languages well ahead of Go.
> 
> Popularity is important. Those top few languages are frequently-used for
> reasons. Many people and organizations are working to improve them. High
> schools and colleges teach them. They have a wide range of books and
> tutorials. Good libraries and open source projects. Lots of blogs and Stack
> Overflow answers. Job opportunities. Success breeds success.
> 
> I think it's fair to say that Python, Java and C++ deserve special respect
> because they dominate so much. Call them the "mainstream". I'm excluding C
> because it's more often used for low-level work, and C# because it's mostly
> limited to Microsoft's ecosystem.
> 
> The minor languages certainly have their fanatics. Some have corporate
> sponsors. I'm sure Apple has fantastically talented and dedicated engineers
> working on Swift and Objective C. Both have many good features. But they
> are minority languages. It has an impact. We bought every book in existence
> about Objective C and Swift. Read close to everything we could find online.
> Looked at every archived post on this list. Built all of Apple's example
> apps. It still wasn't enough to help us finish a Cocoa conversion in time.
> 
> Even worse, the future for Mac is starting to look like a required Swift
> front end to get new features (and maybe ARM compatibility). Using C++ at
> all means having Objective-C in the middle. It just gets too complicated.
> 
> Yesterday I checked up on a few other companies we know who have Mac
> software in the AEC market.  Most died off years ago. Two are now
> Windows-only. Three will have 64-bit apps "soon". So far, nobody is ready
> for Catalina yet.
> 
> Casey McDermott
> TurtleSoft.com
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com
> 
> This email sent to z...@mac.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Need for Swift

[Richard Charles via Cocoa-dev]

> On Oct 15, 2019, at 11:27 AM, Turtle Creek Software via Cocoa-dev 
>  wrote:
> 
> The basic language problem as I see it is in the headers.  Classes are
> either Obj-C or C++ and can't be both.  It turned out to be an enormous
> barrier that caused all sorts of pains.

>From older documentation.

"The class hierarchies are separate; a C++ class cannot inherit from an 
Objective-C class, and an Objective-C class cannot inherit from a C++ class."

This may or may not help. I use the following inline macro for C++ prototypes 
in dual purpose headers.

#ifdef __cplusplus
#define CPP(x) x
#else
#define CPP(x)
#endif

That way you can import or include the same header into a .m or .mm source file.

--Richard Charles

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Need for Swift

[Turtle Creek Software via Cocoa-dev]

>> For context: I work on a database library[1] implemented in C++ that
provides exactly such a C API

Diving down into C sounds like a reasonable option for a database library.
It does not sound good for a specialty app that does construction
estimating and accounting. Libraries just show Assembly when you step into
them, no?  We already have that problem with all of Cocoa. Having that
happen in our own code would be awful.

We don't need an API to link with the GUI, we need a tight, visible,
easy-to-debug direct connection. It's simple stuff like change a popup
value, and some other field needs to switch from % to $.  Maybe 5000 little
details like that.

Casey McDermott
TurtleSoft.com
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Need for Swift

[Turtle Creek Software via Cocoa-dev]

We did put 2 or 3 programmer-years into a Cocoa GUI.  Problem is, it
appears that it will need 2 or 3 more.  There probably won't be enough Mac
buyers left in 2 or 3 years to pay for that.

I agree that QT, wxWidget and Electron build crappy apps.  And some effort
will always be required to interface between one's working code, and the
GUI layer.  It's just a matter of making that effort small enough so one
can bring a product to market fast enough and cheaply enough to get paid
decently for the work.

MVC is an excellent design paradigm.  The M and V layers were no problem at
all to set up. The C started out easy, but ended up being a big problem.
Quite a bit of the business logic is not just data, but fancy stuff that
happens with the GUI. Fields that switch between % and $, table cells that
change other table cells, etc. There is a lot of code in our C++
RecordViewer classes to make that happen, and it didn't integrate easily
with NSWindowControllers or NSViewControllers.  It often was faster to just
redo the logic in Cocoa.  That took a lot of time. Much more rewriting than
expected.

Within source files, Objective-C++ is fantastic.  It really makes Cocoa
coding easy for C++ programmers. We were surprised about how well it
worked.  I probably didn't mention Obj-C++ because it became second nature
so quickly.  If all parts of Cocoa were like that, we would have finished
by now.

The basic language problem as I see it is in the headers.  Classes are
either Obj-C or C++ and can't be both.  It turned out to be an enormous
barrier that caused all sorts of pains.

Casey McDermott
TurtleSoft.com



On Tue, Oct 15, 2019 at 12:20 PM Jens Alfke  wrote:

>
> > On Oct 15, 2019, at 6:59 AM, Turtle Creek Software via Cocoa-dev <
> cocoa-dev@lists.apple.com> wrote:
> >
> > TurtleSoft has a big investment in C++ source code that's full of
> > construction business logic. Unfortunately, with the death of Carbon its
> > future value is in doubt.
>
> I know I’ve brought up Objective-C++ to you here before, but I’m not sure
> you registered its existence, based on comments like this.
>
> Any well-designed app keeps the data model and core business logic
> separate from the UI. So having that logic in C++ is not a big problem.
>
> As for the UI code, I’ve still never found a cross-platform UI framework
> that creates decent apps. Qt is hideous, and Electron results in immensely
> bloated websites-in-a-box. So to do a good job, you need to code the UI for
> each platform anyway.
>
> —Jens
>
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Need for Swift

[David Swofford via Cocoa-dev]

As another developer who procrastinated on converting the GUI for a large 
application away from Carbon, I have also found this discussion to be highly 
illuminating.  My excuse is that I'm an academic, and while the users of my 
software appreciate the GUI, the absolute last way I want to spend my time is 
working on than the details of a user interface.

One thing I'm curious about (and sorry if I missed this) is why there has not 
been more consideration of wxWidgets for C++ programmers who are reluctant to 
use Swift.  It seems like a reasonable option, but I'm worried that there might 
be major limitations that I am not aware of.  Does anyone have any thoughts on 
that?  FWIW, my interface consists mainly of menus, standard (but sometimes 
complicated) dialog boxes, and some fairly simple graphics.

Dave

> On Oct 15, 2019, at 12:40 PM, Richard Charles via Cocoa-dev 
>  wrote:
> 
> 
>> On Oct 15, 2019, at 7:57 AM, Turtle Creek Software via Cocoa-dev 
>>  wrote:
>> 
>> TurtleSoft has a big investment in C++ source code that's full of 
>> construction business logic. Unfortunately, with the death of Carbon its 
>> future value is in doubt.
> 
> 
> I have found your comments enlightening. So if I understand correctly you 
> have three choices for a native UI on the Mac.
> 
> 1. Objective-C which would integrate nicely with your C++ business logic 
> using Objective-C++. One problem is you have very little experience with the 
> Cocoa frameworks. Another problem is you are hesitant to pursue this path 
> fearful that down the road Apple may abandon Objective-C.
> 
> 2. Another option is Swift but it has zero integration with C++. So this is 
> really not a choice at all.
> 
> 3. A third option would be to combine all three. Keep your business logic in 
> C++ and combine with Objective-C using Objective-C++ and then bridge to 
> Swift. That does sound like a nightmare.
> 
> Looks like you are in a pickle.
> 
> --Richard Charles
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.apple.com_mailman_options_cocoa-2Ddev_david.swofford-2540duke.edu=DwICAg=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc=q9CtqHQcjZiZtFpsionQu3nC0V453lTN0qvjmHi8-sA=89ZZHqTjvwnltosPP-fSIU8CwWgqnfkzGvS8zhfWaC0=22Tni3QncvorxvONxLB0XYWf_lk5E51SLFfsjCHzO6o=
>  
> 
> This email sent to david.swoff...@duke.edu

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Need for Swift

[Paul Scott via Cocoa-dev]

> On Oct 15, 2019, at 9:40 AM, Richard Charles via Cocoa-dev 
>  wrote:
> 
> I have found your comments enlightening. So if I understand correctly you 
> have three choices for a native UI on the Mac.
> 
> 1. Objective-C which would integrate nicely with your C++ business logic 
> using Objective-C++. One problem is you have very little experience with the 
> Cocoa frameworks. Another problem is you are hesitant to pursue this path 
> fearful that down the road Apple may abandon Objective-C.
> 
> 2. Another option is Swift but it has zero integration with C++. So this is 
> really not a choice at all.

You can write a simple C or Objective-C wrapper to interface to C++, which 
itself is accessible from Swift.

> 
> 3. A third option would be to combine all three. Keep your business logic in 
> C++ and combine with Objective-C using Objective-C++ and then bridge to 
> Swift. That does sound like a nightmare.
> 
> 



smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Need for Swift

[David Brittain via Cocoa-dev]

Swift / C++ inter-op is being worked on. It's important to many (including
Apple I would guess)...

https://forums.swift.org/t/c-objective-c-interop/9989/2

https://mobile.twitter.com/jeremyphoward/status/1154974115893149696

On Tue, 15 Oct 2019 at 09:41, Richard Charles via Cocoa-dev <
cocoa-dev@lists.apple.com> wrote:

>
> > On Oct 15, 2019, at 7:57 AM, Turtle Creek Software via Cocoa-dev <
> cocoa-dev@lists.apple.com> wrote:
> >
> > TurtleSoft has a big investment in C++ source code that's full of
> construction business logic. Unfortunately, with the death of Carbon its
> future value is in doubt.
>
>
> I have found your comments enlightening. So if I understand correctly you
> have three choices for a native UI on the Mac.
>
> 1. Objective-C which would integrate nicely with your C++ business logic
> using Objective-C++. One problem is you have very little experience with
> the Cocoa frameworks. Another problem is you are hesitant to pursue this
> path fearful that down the road Apple may abandon Objective-C.
>
> 2. Another option is Swift but it has zero integration with C++. So this
> is really not a choice at all.
>
> 3. A third option would be to combine all three. Keep your business logic
> in C++ and combine with Objective-C using Objective-C++ and then bridge to
> Swift. That does sound like a nightmare.
>
> Looks like you are in a pickle.
>
> --Richard Charles
>
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/websites%40paperetto.com
>
> This email sent to websi...@paperetto.com
>


-- 
David Brittain
da...@paperetto.com
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Need for Swift

[Jens Alfke via Cocoa-dev]

> On Oct 15, 2019, at 9:40 AM, Richard Charles via Cocoa-dev 
>  wrote:
> 
> 2. Another option is Swift but it has zero integration with C++. So this is 
> really not a choice at all.

Swift integrates with C. So you can declare C APIs to your C++ codebase, and 
call those from Swift. This does mean writing a lot of C++ wrapper code in the 
form of extern "C" functions that call your C++ methods. Which is admittedly 
extra work, but hardly rocket science.

For context: I work on a database library[1] implemented in C++ that provides 
exactly such a C API, which is then used by higher-layer frameworks written in 
Objective-C, Swift, Java, and C#. So I know this works and is not an 
unreasonable amount of work. Here [2] is an example source file if you want to 
see what it looks like. (Note that some of the boilerplate is to catch 
exceptions thrown by the C++ layer; if your C++ doesn't use exceptions, you 
don't need that.)

—Jens

[1]: https://github.com/couchbase/couchbase-lite-core
[2]: 
https://github.com/couchbase/couchbase-lite-core/blob/master/C/c4DocExpiration.cc
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Need for Swift

[Richard Charles via Cocoa-dev]

> On Oct 15, 2019, at 7:57 AM, Turtle Creek Software via Cocoa-dev 
>  wrote:
> 
> TurtleSoft has a big investment in C++ source code that's full of 
> construction business logic. Unfortunately, with the death of Carbon its 
> future value is in doubt.


I have found your comments enlightening. So if I understand correctly you have 
three choices for a native UI on the Mac.

1. Objective-C which would integrate nicely with your C++ business logic using 
Objective-C++. One problem is you have very little experience with the Cocoa 
frameworks. Another problem is you are hesitant to pursue this path fearful 
that down the road Apple may abandon Objective-C.

2. Another option is Swift but it has zero integration with C++. So this is 
really not a choice at all.

3. A third option would be to combine all three. Keep your business logic in 
C++ and combine with Objective-C using Objective-C++ and then bridge to Swift. 
That does sound like a nightmare.

Looks like you are in a pickle.

--Richard Charles

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Need for Swift

[Jeremy Hughes via Cocoa-dev]

Maybe it’s also worth noting that WebKit (the browser engine used by Safari) is 
written in C++

Safari’s UI is probably written in Obj-C(++) or a mixture of Obj-C(++) and 
Swift.

Jeremy

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Need for Swift

[Jens Alfke via Cocoa-dev]

> On Oct 15, 2019, at 6:59 AM, Turtle Creek Software via Cocoa-dev 
>  wrote:
> 
> TurtleSoft has a big investment in C++ source code that's full of
> construction business logic. Unfortunately, with the death of Carbon its
> future value is in doubt.

I know I’ve brought up Objective-C++ to you here before, but I’m not sure you 
registered its existence, based on comments like this.

Any well-designed app keeps the data model and core business logic separate 
from the UI. So having that logic in C++ is not a big problem.

As for the UI code, I’ve still never found a cross-platform UI framework that 
creates decent apps. Qt is hideous, and Electron results in immensely bloated 
websites-in-a-box. So to do a good job, you need to code the UI for each 
platform anyway.

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Need for Swift

[John Joyce via Cocoa-dev]

> 
> On Oct 15, 2019, at 22:58, Turtle Creek Software via Cocoa-dev 
>  wrote:
> 
> Nobody
> is every going to write a full CAD, project management or business
> accounting app in either Swift or Obj-C.
> 
> TurtleSoft has a big investment in C++ source code that's full of
> construction business logic. Unfortunately, with the death of Carbon its
> future value is in doubt.
If your code is worth complaining about this much, then move to Objective-C++ 
and wire up a damn UI. That or Electron, wxWidgets or Qt or one of the plethora 
of mostly abysmal cross platform GUI toolkits. 
It’s getting old and it’s just a drag for everybody. 
Carbon is dead and nobody was surprised by this but your company somehow. 
Everybody else got the memo a decade ago. Spam this list less and go do some 
coding. 


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Need for Swift

[Turtle Creek Software via Cocoa-dev]

This discussion about Swift vs Objective-C is interesting, but I think it
omits something important. Both those languages only build apps for Apple
products.

It's not such a big deal for iOS. iPhones are dominant enough that people
can write just for that. Phone/pad apps are also relatively small, so a
rewrite for Android is not too difficult if you want to go cross-platform.

For PCs it's a different story. Mac has about 10% market share overall, but
it varies. In our market, architects are about 20% Mac, engineers less than
1%, construction maybe 2%.  The apps are bigger and more complex.  Nobody
is every going to write a full CAD, project management or business
accounting app in either Swift or Obj-C.

TurtleSoft has a big investment in C++ source code that's full of
construction business logic. Unfortunately, with the death of Carbon its
future value is in doubt.

I just checked a half dozen sites that measure popularity of programming
languages. The Stack Overflow survey seemed the best, since they directly
asked folks what they use. For 2019, their top 5 app-development languages
are Python, Java, C#, C++ and C in that order. 42% of respondents use
Python, down to 20% for C. Interestingly, there is a huge gap after that.
Their next most popular app-dev language is Go at 8.8%. Swift rated 6.6%
and Objective-C was 4.8%. Then there is a long, long tail of other
languages with a few % or less.

PYPL puts the top 5 in the same order. TIOBE index ranks them as Java, C,
Python, C++, C#. Both those lists put Obj-C ahead of Swift, with the Apple
languages well ahead of Go.

Popularity is important. Those top few languages are frequently-used for
reasons. Many people and organizations are working to improve them. High
schools and colleges teach them. They have a wide range of books and
tutorials. Good libraries and open source projects. Lots of blogs and Stack
Overflow answers. Job opportunities. Success breeds success.

I think it's fair to say that Python, Java and C++ deserve special respect
because they dominate so much. Call them the "mainstream". I'm excluding C
because it's more often used for low-level work, and C# because it's mostly
limited to Microsoft's ecosystem.

The minor languages certainly have their fanatics. Some have corporate
sponsors. I'm sure Apple has fantastically talented and dedicated engineers
working on Swift and Objective C. Both have many good features. But they
are minority languages. It has an impact. We bought every book in existence
about Objective C and Swift. Read close to everything we could find online.
Looked at every archived post on this list. Built all of Apple's example
apps. It still wasn't enough to help us finish a Cocoa conversion in time.

Even worse, the future for Mac is starting to look like a required Swift
front end to get new features (and maybe ARM compatibility). Using C++ at
all means having Objective-C in the middle. It just gets too complicated.

Yesterday I checked up on a few other companies we know who have Mac
software in the AEC market.  Most died off years ago. Two are now
Windows-only. Three will have 64-bit apps "soon". So far, nobody is ready
for Catalina yet.

Casey McDermott
TurtleSoft.com
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Need for Swift

[Sandor Szatmari via Cocoa-dev]

I always felt that swift was introduced to allow the development ecosystem to 
grow and intended to be a language that eliminated some of the squishiness of 
Objective-C.  My opinion is that this was intended to make Apple’s job of code 
review and approval easier and more concrete (business case?).

I like what Swift promised, but it comes with a ton of syntactic baggage.  

Objective-C is simple, there is a low bar to pick it up and run.  But you need 
to adhere to mutually agreed ‘contracts’.  This takes an investment of time.  
And what is time? $$$  and still there’s no guarantee.

Swift is complicated and enforces all the contracts itself, syntactically.  
This was intended to yield good code without the need for ‘seasoning’ the 
developer.  As was aptly put, you need to get on board and learn everything 
upfront.

To me, the difference is philosophical… oohm  If Swift solves your problems the 
high bar to learn and the oppressive syntactical nature becomes a small price 
to pay.  It will be less philosophical when Apple stops releasing new feature 
support in Obj-C to force everyone over to Swift.  In my opinion this is the 
direction, we’ll see if we get there.  Apple loves the soft roll out.  Think 
about the recent Carbon/Cocoa discussion.

Obj-C represents the freedom for me to write bad code if I need to… this never 
happens, right?  But honestly, I don’t have enough Swift experience to know if 
you can write bad Swift code.

Anyways, I still prefer Obj-C.

Sandor

> On Oct 15, 2019, at 04:59, Alex Zavatone via Cocoa-dev 
>  wrote:
> 
> 
>> On Oct 15, 2019, at 1:37 AM, Quincey Morris via Cocoa-dev 
>> mailto:cocoa-dev@lists.apple.com>> wrote:
>> 
>> The really important thing about using Swift is that you *have to* learn to 
>> change the way you think about dealing with nil values. 
> 
> And it’s a fucking cumbersome pain in the ass.  Simply converting between 
> floats and integers that might be nil is an unwieldy pain in the ass.  
> 
> It’s a cumbersome and time wasting pain in the ass.  And I’ve been doing this 
> for well over a year too.  
> 
> Here’s the dangerous area.  What I have seen is that Swift lets you do stupid 
> shit in new and more complicated ways so that you need your most expensive 
> people to spend an extraordinary time debugging the problems created by your 
> most junior people.  Why?  Because they are doing things the new Swifty way, 
> that’s why?!  And because someone wrote an article and published it on the 
> Internet, so it must be a good idea!
> 
> Like my problems with VIPER.  Our team has (against my direction) protocol 
> backed every class within our implementation of the VIPER pattern creating 
> monstrous retain cycles so that EVERY one of our 120+ screens NEVER gets 
> released.  And with protocols and their strong variables backing every object 
> that confirms to them, it’s murder figuring which variables to turn weak in 
> the conforming classes and god forbid that the protocols are not class backed 
> or you’ll get yet another bizarre compile error.
> 
> Also, if everything is a class extension, then nothing is.  But at least it 
> makes nice little separator lines in the menus just like pragma mark - used 
> to in Objective-C.
> 
> Swift is one big steaming pile of suck.  It lets those who don’t know any 
> better think that they do and then with that hubris, go on and create very 
> Swifty nightmares.  Our iOS feature tests still rebooted the Mac or crashed 
> the user session back to login as of mid last week.  
> 
> You really need to feel the joy of debugging 3,410 retain cycles - in VIPER, 
> with many interdependent classes conforming to multiple protocols that all 
> have strong vars, sometimes with vars directly assigned to a protocol.
> 
> Yes, you read that right, 3,410 retain cycles.  I have freaking 24 node 
> cycles and enough chained multi node retain loops that they are organic 
> chemistry moledules.  Thankfully, I’m down to our last 300
> 
> Rant off.
> 
> Lovely pics of retain cycles for you all to enjoy.  These are the easy ones.
> 
> https://imgur.com/a/pC3p9A5
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/admin.szatmari.net%40gmail.com
> 
> This email sent to admin.szatmari@gmail.com
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Need for Swift

[Alex Zavatone via Cocoa-dev]

> On Oct 15, 2019, at 1:37 AM, Quincey Morris via Cocoa-dev 
> mailto:cocoa-dev@lists.apple.com>> wrote:
> 
> The really important thing about using Swift is that you *have to* learn to 
> change the way you think about dealing with nil values. 

And it’s a fucking cumbersome pain in the ass.  Simply converting between 
floats and integers that might be nil is an unwieldy pain in the ass.  

It’s a cumbersome and time wasting pain in the ass.  And I’ve been doing this 
for well over a year too.  

Here’s the dangerous area.  What I have seen is that Swift lets you do stupid 
shit in new and more complicated ways so that you need your most expensive 
people to spend an extraordinary time debugging the problems created by your 
most junior people.  Why?  Because they are doing things the new Swifty way, 
that’s why?!  And because someone wrote an article and published it on the 
Internet, so it must be a good idea!

Like my problems with VIPER.  Our team has (against my direction) protocol 
backed every class within our implementation of the VIPER pattern creating 
monstrous retain cycles so that EVERY one of our 120+ screens NEVER gets 
released.  And with protocols and their strong variables backing every object 
that confirms to them, it’s murder figuring which variables to turn weak in the 
conforming classes and god forbid that the protocols are not class backed or 
you’ll get yet another bizarre compile error.

Also, if everything is a class extension, then nothing is.  But at least it 
makes nice little separator lines in the menus just like pragma mark - used to 
in Objective-C.

Swift is one big steaming pile of suck.  It lets those who don’t know any 
better think that they do and then with that hubris, go on and create very 
Swifty nightmares.  Our iOS feature tests still rebooted the Mac or crashed the 
user session back to login as of mid last week.  

You really need to feel the joy of debugging 3,410 retain cycles - in VIPER, 
with many interdependent classes conforming to multiple protocols that all have 
strong vars, sometimes with vars directly assigned to a protocol.

Yes, you read that right, 3,410 retain cycles.  I have freaking 24 node cycles 
and enough chained multi node retain loops that they are organic chemistry 
moledules.  Thankfully, I’m down to our last 300

Rant off.

Lovely pics of retain cycles for you all to enjoy.  These are the easy ones.

https://imgur.com/a/pC3p9A5
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Need for Swift

[Quincey Morris via Cocoa-dev]

OK, apologies in advance for toes trodden on or sensibilities offended, but it 
sounds like it’s time for my anti-optional-whining rant. :)

The really important thing about using Swift is that you *have to* learn to 
change the way you think about dealing with nil values. It’s not quite 
literally true (but it’s close) that in Obj-C you want to defer dealing with 
nil values *as long as possible*, while in Swift you want to deal with nil 
values *immediately*.

Putting this another way, the rule you should live and breathe is, “Don’t let 
optionals propagate through your code.”

There are some exceptions to this principle. For example, if you’re parsing a 
name string for first, middle and last name, and the middle name is optional, 
you might well choose to carry the middle name forward as `String?` (an 
optional string). But you should typically start by writing your code as if 
there are no optionals, and eliminate/resolve them as they appear.

For example, it’s a really bad idea to write code like this:

let url = URL(string: “some string”)
/* … things involving `url?` … */

It’s much better to deal with the optional right away. For example:

let url = URL(string: “some string”)! // no more optional, when your 
URL string is known good

Or, if your string can be genuinely an invalid URL string:

guard let url = URL(string: “some string”) else { /* deal with the 
error condition and … */; return } // or break or whatever

Not only does it take practice to remember to do things this way round, but 
also I *guarantee* you that it will throw your tried and trusted Obj-C code 
design patterns into chaos. You must, I’m afraid, suffer through this, long 
enough until your brain “flips” and starts pouring out code that is Swift-like 
in Swift, not Obj-C-like in Swift.

It actually took me about a year, back in the Swift 2 days, to figure out that 
I needed to write Swift like Swift, not like Obj-C, and a year or two to get 
comfortable with that. But I was slow and stupid: it shouldn’t really need to 
take that long. It just takes a willingness to spend time writing and rewriting 
sections of code until you get to that “Aha!” moment. That’s when you will 
become a Swift fan.

There’s nothing truly wrong with Obj-C as a language, and there’s no need to 
diss it in order to appreciate Swift. But the two have different coding 
patterns, and if you want to use Swift professionally you will need to learn 
and practice its natural coding patterns. (If you don’t, that’s fine too!)

People have been offering opinions all day of what Swift is like, compared to 
other languages. One point that doesn’t get mentioned is that Swift was 
intended to fill the hole where (so to speak) Obj-C 3.0 or 4.0 would go. A lot 
of its syntax and philosophy is intended to do what we did comfortably in 
Obj-C, but with more efficiency in the task of actual code writing. It’s 
evolved away from Obj-C in some fairly weird ways, but I’ll happily defend my 
belief that it *is* a more efficient way to write code.

I loved Obj-C for 15 years (or so). Now I write Swift almost exclusively.

/end rant

> On Oct 14, 2019, at 20:44 , Laurent Daudelin via Cocoa-dev 
>  wrote:
> 
> I’ve been wondering the same thing. I thought that maybe because I was biased 
> toward Obj-C. But if it wasn’t for the editor, damn, I don’t know how many 
> times I would have to go back to unwrap one of those optionals. Are people 
> supposed to know instinctively when you unwrap with “?” and when you do with 
> “!”? I’m not there yet, even though I’ve been doing almost a year of Swift so 
> far...

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Need for Swift

[Laurent Daudelin via Cocoa-dev]

I’ve been wondering the same thing. I thought that maybe because I was biased 
toward Obj-C. But if it wasn’t for the editor, damn, I don’t know how many 
times I would have to go back to unwrap one of those optionals. Are people 
supposed to know instinctively when you unwrap with “?” and when you do with 
“!”? I’m not there yet, even though I’ve been doing almost a year of Swift so 
far...

-Laurent.
-- 
Laurent Daudelin
laur...@nemesys-soft.com 
Skype: LaurentDaudelin  
Logiciels Némésys Software  
http://www.nemesys-soft.com/ 

> On Oct 14, 2019, at 22:43, Alex Zavatone via Cocoa-dev 
>  wrote:
> 
> 
> 
>> On Oct 14, 2019, at 1:25 PM, Carl Hoefs via Cocoa-dev 
>>  wrote:
>> 
>> The group that likes Obj-C sees Swift as being "arbitrarily syntactical" 
>> with the syntax of the language getting in the way of programming. (There is 
>> a third group that likes both languages, but it is very small.)
> 
> I am in this group.  The syntax of Swift just feels so arbitrary and to look 
> deeper to solve more problems… if it weren’t for those compiler messages, it 
> would be a mess.  I, for one shuddered when I saw “if let x = y” being 
> something that people are expected to use and that damn, “you must unwrap 
> this optional”, simply ends up making things that were simple in Objective-C, 
> completely cumbersome in Swift.  
> 
> And this “everything is an extension”?  That is hell.  I love classes 
> adopting protocols where the class definition of the variable must be weak, 
> because you can’t do it in the protocol and oh, whar?  This proticol needs to 
> be class backed?  
> 
> So much clunk to do what we could already do with ease.
> 
> But then again, my team is using VIPER and in none of the code reviews did 
> the lead call in to question that every var was strong.  And they wonder why 
> we had 3410 memory leaks.
> 
> I’m not yet a fan.
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/laurent%40nemesys-soft.com
> 
> This email sent to laur...@nemesys-soft.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Need for Swift

[Pier Bover via Cocoa-dev]

>
> I, for one shuddered when I saw “if let x = y” being something that people
> are expected to use and that damn, “you must unwrap this optional”, simply
> ends up making things that were simple in Objective-C, completely
> cumbersome in Swift.
>

Totally agree... I've only used Swift on one project and those optionals
are quite annoying.

Swift looks nice when reading simple examples but once you start using the
Apple frameworks the head scratching is strong.

On Mon, Oct 14, 2019 at 9:43 PM Alex Zavatone via Cocoa-dev <
cocoa-dev@lists.apple.com> wrote:

>
>
> > On Oct 14, 2019, at 1:25 PM, Carl Hoefs via Cocoa-dev <
> cocoa-dev@lists.apple.com> wrote:
> >
> > The group that likes Obj-C sees Swift as being "arbitrarily syntactical"
> with the syntax of the language getting in the way of programming. (There
> is a third group that likes both languages, but it is very small.)
>
> I am in this group.  The syntax of Swift just feels so arbitrary and to
> look deeper to solve more problems… if it weren’t for those compiler
> messages, it would be a mess.  I, for one shuddered when I saw “if let x =
> y” being something that people are expected to use and that damn, “you must
> unwrap this optional”, simply ends up making things that were simple in
> Objective-C, completely cumbersome in Swift.
>
> And this “everything is an extension”?  That is hell.  I love classes
> adopting protocols where the class definition of the variable must be weak,
> because you can’t do it in the protocol and oh, whar?  This proticol needs
> to be class backed?
>
> So much clunk to do what we could already do with ease.
>
> But then again, my team is using VIPER and in none of the code reviews did
> the lead call in to question that every var was strong.  And they wonder
> why we had 3410 memory leaks.
>
> I’m not yet a fan.
>
>
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/pierbover11%40gmail.com
>
> This email sent to pierbove...@gmail.com
>
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Need for Swift

[Alex Zavatone via Cocoa-dev]

> On Oct 14, 2019, at 1:25 PM, Carl Hoefs via Cocoa-dev 
>  wrote:
> 
> The group that likes Obj-C sees Swift as being "arbitrarily syntactical" with 
> the syntax of the language getting in the way of programming. (There is a 
> third group that likes both languages, but it is very small.)

I am in this group.  The syntax of Swift just feels so arbitrary and to look 
deeper to solve more problems… if it weren’t for those compiler messages, it 
would be a mess.  I, for one shuddered when I saw “if let x = y” being 
something that people are expected to use and that damn, “you must unwrap this 
optional”, simply ends up making things that were simple in Objective-C, 
completely cumbersome in Swift.  

And this “everything is an extension”?  That is hell.  I love classes adopting 
protocols where the class definition of the variable must be weak, because you 
can’t do it in the protocol and oh, whar?  This proticol needs to be class 
backed?  

So much clunk to do what we could already do with ease.

But then again, my team is using VIPER and in none of the code reviews did the 
lead call in to question that every var was strong.  And they wonder why we had 
3410 memory leaks.

I’m not yet a fan.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Need for Swift

[Charles Srstka via Cocoa-dev]

> On Oct 14, 2019, at 7:21 PM, Jens Alfke  wrote:
> 
>> On Oct 14, 2019, at 5:02 PM, Charles Srstka > > wrote:
>> 
>> Swift, on the other hand, can actually *be* a scripting language if you want 
>> it to; put #!/usr/bin/env swift at the top of a source file, give it execute 
>> permissions, and voilà, it’ll run just like a script.
> 
> *Anything* can be a scripting language in that sense, in Unix. I could write 
> a two-line script called "run_c" containing*:
>   #! /bin/bash
>   cc "$1" -o /tmp/a.out && /tmp/a.out
> and put it somewhere in my path; then I can put "#! /usr/bin/env/run_c" at 
> the top of any C source file and run it as a script.
> 
> To me, "scripting language" strongly implies a CLI, plus dynamic typing, and 
> no boilerplate (so I can write one-line programs.)
> 
> —Jens
> 
> * Typed in Mail. Should work, but I haven't tested it.

Yeah, but Swift actually has first-party support for it, unlike that rather 
hacky solution. Its syntactical similarity to scripting languages was also a 
big part of the promotional materials that Swift launched with (see: 
https://www.apple.com/ne/newsroom/2015/12/03Apple-Releases-Swift-as-Open-Source/
 

 - "Introduced in 2014, Swift is the fastest growing programming language in 
history and combines the performance and efficiency of compiled languages with 
the simplicity and interactivity of popular scripting languages.”) It seems 
clear that the intention is to blur the lines a bit, although 
implementation-wise Swift is certainly very much on the compiled, static-typed 
side of the fence.*

Charles

* Unless, of course, you put `dynamic` on everything, on an Apple platform. 
Then, you’re basically writing Objective-C with a different syntax.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Need for Swift

[Jens Alfke via Cocoa-dev]

> On Oct 14, 2019, at 5:02 PM, Charles Srstka  wrote:
> 
> Swift, on the other hand, can actually *be* a scripting language if you want 
> it to; put #!/usr/bin/env swift at the top of a source file, give it execute 
> permissions, and voilà, it’ll run just like a script.

*Anything* can be a scripting language in that sense, in Unix. I could write a 
two-line script called "run_c" containing*:
#! /bin/bash
cc "$1" -o /tmp/a.out && /tmp/a.out
and put it somewhere in my path; then I can put "#! /usr/bin/env/run_c" at the 
top of any C source file and run it as a script.

To me, "scripting language" strongly implies a CLI, plus dynamic typing, and no 
boilerplate (so I can write one-line programs.)

—Jens

* Typed in Mail. Should work, but I haven't tested it.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Need for Swift

[Charles Srstka via Cocoa-dev]

> On Oct 14, 2019, at 2:30 PM, Jens Alfke  wrote:
> 
>> On Oct 14, 2019, at 11:25 AM, Carl Hoefs via Cocoa-dev 
>> mailto:cocoa-dev@lists.apple.com>> wrote:
>> 
>> I see Computer Science students here falling into two groups. The group that 
>> likes Swift generally likes scripting languages, Python, and the like.
> 
> Whoa, I completely disagree. Objective-C is much, much closer to scripting 
> languages than Swift, with all of its dynamic features:
> 
> * It has the 'id' type that represents any type of object
> * you can send a message to an arbitrary object whether or not its class 
> declares it
> * you can intercept unhandled messages and do arbitrary things to handle them
> * you can add, remove or override methods at runtime
> * you can even create classes at runtime
> 
> Swift is very strongly-typed and less dynamic: it's very strict and nit-picky 
> about types, protocol conformance, etc. Much more like C++.
> 
> Are you lumping Swift in with scripting languages simply because its 
> method-call syntax is more normal looking? Or because compiler type inference 
> sometimes allows you to omit variable types?

It’s kind of a funny dichotomy; Swift is a strictly typed language under the 
hood, but it *looks* like a scripting language on the surface, what with its 
type inference, JavaScript-looking-like “let” and “var” declarations, implicit 
closure parameters, and whatnot. Objective-C, on the other hand, is like one 
step down from Ruby on the dynamism scale under the hood, but on the surface it 
looks like a statically-typed language, thanks to the mandatory types on every 
variable declaration, even if the type is just ‘id’—although it usually isn’t, 
since in common practice we specify object types even though it’s not strictly 
necessary, and some of them can be kind of obnoxious (hello, block syntax).

Swift, on the other hand, can actually *be* a scripting language if you want it 
to; put #!/usr/bin/env swift at the top of a source file, give it execute 
permissions, and voilà, it’ll run just like a script.

>> (There is a third group that likes both languages, but it is very small.)
> 
> Most experienced iOS/Mac developers I know like both.


I’d agree with that.

Charles

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Need for Swift

[Jens Alfke via Cocoa-dev]

> On Oct 14, 2019, at 11:25 AM, Carl Hoefs via Cocoa-dev 
>  wrote:
> 
> I see Computer Science students here falling into two groups. The group that 
> likes Swift generally likes scripting languages, Python, and the like.

Whoa, I completely disagree. Objective-C is much, much closer to scripting 
languages than Swift, with all of its dynamic features:

* It has the 'id' type that represents any type of object
* you can send a message to an arbitrary object whether or not its class 
declares it
* you can intercept unhandled messages and do arbitrary things to handle them
* you can add, remove or override methods at runtime
* you can even create classes at runtime

Swift is very strongly-typed and less dynamic: it's very strict and nit-picky 
about types, protocol conformance, etc. Much more like C++.

Are you lumping Swift in with scripting languages simply because its 
method-call syntax is more normal looking? Or because compiler type inference 
sometimes allows you to omit variable types?

> (There is a third group that likes both languages, but it is very small.)

Most experienced iOS/Mac developers I know like both.

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Need for Swift

[Carl Hoefs via Cocoa-dev]

> On Oct 12, 2019, at 9:24 AM, Charles Srstka via Cocoa-dev 
>  wrote:
> 
>> On Oct 12, 2019, at 10:55 AM, Pier Bover via Cocoa-dev 
>>  wrote:
>> 
>> Yeah I think Apple saw Obj-C as a barrier for developer adoption. I don't
>> think that's too far from the truth considering the emphasis on teaching
>> Swift to young devs, Playgrounds, the marketing about teenagers making
>> their first app, etc.
>> 
>> Swift has its quirks but most people around me prefer it over Obj-C too,
>> even experienced devs. From StackOverflow trends and other metrics as soon
>> as Swift was announced the popularity of Obj-C declined steadily even when
>> it was clear Swift was still not ready for production:
>> 
>>  - https://www.tiobe.com/tiobe-index/objective-c/ 
>> 
>>  - https://insights.stackoverflow.com/trends?tags=objective-c 
>> 
> Swift’s first few versions were awful, but the community has been very 
> responsive in responding to developer feedback and what we have now is really 
> quite a nice language, possibly the nicest I’ve used. The string nil checks, 
> in particular, are something I’ve become a believer in, especially when 
> spending a bunch of time trying to debug an issue while writing projects in 
> other languages that turns out to be a nil showing up somewhere where we 
> didn’t expect it.
> 
> The main quibble I have with it is the Objective-C bridge, which contains 
> much more magic than I’d prefer, and of course certain legacy issues that 
> come along with having to use the Objective-C frameworks (hello, autorelease 
> pools). When writing cross-platform code on Linux or something, these 
> complaints are of course moot. I hope they release a Windows version at some 
> point; I’d really like to see Swift gain more acceptance as a general-purpose 
> programming language.



With respect to Swift/Obj-C preference, I think it may ultimately come down to 
a mindset issue.

I see Computer Science students here falling into two groups. The group that 
likes Swift generally likes scripting languages, Python, and the like. The 
group that likes Obj-C sees Swift as being "arbitrarily syntactical" with the 
syntax of the language getting in the way of programming. (There is a third 
group that likes both languages, but it is very small.)

I can understand where both camps are coming from. A psychologist explained 
this difference in orientation as one of "convergent vs divergent" thinking, 
and most people are mostly one way or the other.

-Carl
 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Need for Swift

[Charles Srstka via Cocoa-dev]

> On Oct 12, 2019, at 11:24 AM, Charles Srstka  wrote:
> 
> The string nil checks, in particular,

This was meant to be “The strict nil checks.” Ah, the joy of mailing lists, 
where there’s no edit feature.

Charles

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Need for Swift

[Charles Srstka via Cocoa-dev]

> On Oct 12, 2019, at 10:55 AM, Pier Bover via Cocoa-dev 
>  wrote:
> 
> Yeah I think Apple saw Obj-C as a barrier for developer adoption. I don't
> think that's too far from the truth considering the emphasis on teaching
> Swift to young devs, Playgrounds, the marketing about teenagers making
> their first app, etc.
> 
> Swift has its quirks but most people around me prefer it over Obj-C too,
> even experienced devs. From StackOverflow trends and other metrics as soon
> as Swift was announced the popularity of Obj-C declined steadily even when
> it was clear Swift was still not ready for production:
> 
>   - https://www.tiobe.com/tiobe-index/objective-c/ 
> 
>   - https://insights.stackoverflow.com/trends?tags=objective-c 
> 
Swift’s first few versions were awful, but the community has been very 
responsive in responding to developer feedback and what we have now is really 
quite a nice language, possibly the nicest I’ve used. The string nil checks, in 
particular, are something I’ve become a believer in, especially when spending a 
bunch of time trying to debug an issue while writing projects in other 
languages that turns out to be a nil showing up somewhere where we didn’t 
expect it.

The main quibble I have with it is the Objective-C bridge, which contains much 
more magic than I’d prefer, and of course certain legacy issues that come along 
with having to use the Objective-C frameworks (hello, autorelease pools). When 
writing cross-platform code on Linux or something, these complaints are of 
course moot. I hope they release a Windows version at some point; I’d really 
like to see Swift gain more acceptance as a general-purpose programming 
language.

Charles

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Need for Swift

[Pier Bover via Cocoa-dev]

Yeah I think Apple saw Obj-C as a barrier for developer adoption. I don't
think that's too far from the truth considering the emphasis on teaching
Swift to young devs, Playgrounds, the marketing about teenagers making
their first app, etc.

Swift has its quirks but most people around me prefer it over Obj-C too,
even experienced devs. From StackOverflow trends and other metrics as soon
as Swift was announced the popularity of Obj-C declined steadily even when
it was clear Swift was still not ready for production:

   - https://www.tiobe.com/tiobe-index/objective-c/
   - https://insights.stackoverflow.com/trends?tags=objective-c


On Sat, Oct 12, 2019 at 10:05 AM Laurent Daudelin via Cocoa-dev <
cocoa-dev@lists.apple.com> wrote:

> I think Swift came out for the Apple’s desire to make it even more
> appealing to develop for its platforms. I don’t know over the years how
> many times I’ve heard people bitching about Objective-C and its “weird”
> syntax. People couldn’t get over it. Swift makes it easy for all the
> throngs of Java developer to feel right back at home...
>
> -Laurent.
> --
> Laurent Daudelin
>   laur...@nemesys-soft.com  laur...@nemesys-soft.com>
> Skype: LaurentDaudelin
> Logiciels Némésys Software
>   http://www.nemesys-soft.com/ 
>
> > On Oct 12, 2019, at 07:35, Richard Charles via Cocoa-dev <
> cocoa-dev@lists.apple.com> wrote:
> >
> >
> >> On Oct 11, 2019, at 9:09 PM, Kirk Kerekes via Cocoa-dev <
> cocoa-dev@lists.apple.com> wrote:
> >>
> >> It is my inference that Swift arose out of a perceived need for a
> language that strongly inhibited bad/lazy/sloppy programming practices, and
> yet looked “normal”.
> >
> > Here is my take. I think Swift came from the mind of Chris Lattner who
> showed it to management and they loved the idea. It was made possible by
> the power and flexibility of the LLVM compiler.
> >
> > --Richard Charles
> >
> > ___
> >
> > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> >
> > Please do not post admin requests or moderator comments to the list.
> > Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> >
> > Help/Unsubscribe/Update your Subscription:
> >
> https://lists.apple.com/mailman/options/cocoa-dev/laurent%40nemesys-soft.com
> >
> > This email sent to laur...@nemesys-soft.com
>
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/pierbover11%40gmail.com
>
> This email sent to pierbove...@gmail.com
>
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Need for Swift

[Laurent Daudelin via Cocoa-dev]

I think Swift came out for the Apple’s desire to make it even more appealing to 
develop for its platforms. I don’t know over the years how many times I’ve 
heard people bitching about Objective-C and its “weird” syntax. People couldn’t 
get over it. Swift makes it easy for all the throngs of Java developer to feel 
right back at home...

-Laurent.
-- 
Laurent Daudelin
laur...@nemesys-soft.com 
Skype: LaurentDaudelin  
Logiciels Némésys Software  
http://www.nemesys-soft.com/ 

> On Oct 12, 2019, at 07:35, Richard Charles via Cocoa-dev 
>  wrote:
> 
> 
>> On Oct 11, 2019, at 9:09 PM, Kirk Kerekes via Cocoa-dev 
>>  wrote:
>> 
>> It is my inference that Swift arose out of a perceived need for a language 
>> that strongly inhibited bad/lazy/sloppy programming practices, and yet 
>> looked “normal”.
> 
> Here is my take. I think Swift came from the mind of Chris Lattner who showed 
> it to management and they loved the idea. It was made possible by the power 
> and flexibility of the LLVM compiler.
> 
> --Richard Charles
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/laurent%40nemesys-soft.com
> 
> This email sent to laur...@nemesys-soft.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Need for Swift

[Richard Charles via Cocoa-dev]

> On Oct 11, 2019, at 9:09 PM, Kirk Kerekes via Cocoa-dev 
>  wrote:
> 
> It is my inference that Swift arose out of a perceived need for a language 
> that strongly inhibited bad/lazy/sloppy programming practices, and yet looked 
> “normal”.

Here is my take. I think Swift came from the mind of Chris Lattner who showed 
it to management and they loved the idea. It was made possible by the power and 
flexibility of the LLVM compiler.

--Richard Charles

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Need for Swift

[Jens Alfke via Cocoa-dev]

> On Oct 11, 2019, at 8:10 PM, Kirk Kerekes via Cocoa-dev 
>  wrote:
> 
> I further infer that the perceived need arose due to the confluence of 
> aggravation over publicity over security bugs and the desire to develop 
> autonomous vehicle software. 

I don’t think so. Language people don’t develop languages for narrow reasons 
like that, and business people don’t respond to such issues by calling for a 
new programming language.

Swift has been in development since 2010, and what drove it, the people who 
originated say, was the need to go past the limits of what could be added to 
Objective-C.

> What they have ended up is a kind of disciplined, compiling Python — not 
> really a bad concept, given the goals.

I see Swift and Python as extremely different languages. Python is very 
dynamic, Swift is very static. Swift is a lot closer to Scala, C#, Go, and Rust.

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Need for Swift

[Alex Zavatone via Cocoa-dev]

> On Oct 11, 2019, at 10:09 PM, Kirk Kerekes via Cocoa-dev 
>  wrote:
> 
> I would not want to be at the mercy of a vehicle piloted by C++. 

In the immortal words that I have in an email from John Carmack, “Failure in 
brakes.dll."
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com