Re: Future of Cocoa #2

2019-12-12 Thread Charles Srstka via Cocoa-dev
> On Dec 10, 2019, at 5:57 PM, Turtle Creek Software via Cocoa-dev 
>  wrote:
> 
> Xojo is new to me, but it appears more a SwiftUI than a Cocoa substitute.

Xojo is just the new name for RealBASIC, which has been around forever.

It wouldn’t be my first choice.

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

2019-10-15 Thread 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

2019-10-14 Thread 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

2019-10-14 Thread 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

2019-10-16 Thread 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: Thoughts on Cocoa

2019-10-10 Thread Charles Srstka via Cocoa-dev
> On Oct 4, 2019, at 4:51 AM, Jeremy Hughes via Cocoa-dev 
>  wrote:
> 
> Hi Jens,
> 
>> On 3 Oct 2019, at 20:04, Jens Alfke via Cocoa-dev > > wrote:
>> 
>> The people I hear complaining about this are those who, like you, didn't 
>> move to Cocoa. Carbon was a _temporary_ transition API*. 
> 
> It wasn’t clear to us (outside Apple) that Carbon was a temporary API until 
> 2007, when Apple suddenly abandoned 64-bit Carbon.

Yes, they marketed Carbon as a first-class citizen, promoted as “the basis for 
all life,” and even rewrote the Finder and Dock—which already had Cocoa 
implementations from NeXT—in Carbon just to prove that they were serious about 
it.

That last detail made a lot of people nervous about *Cocoa’s* future. There was 
a real possibility that it could have gone the way of OpenDoc or GX and joined 
the large graveyard of supposedly superior Apple technologies, whereas Carbon 
was the only framework being used by all the big clients that Apple couldn’t 
survive without, and for those first few years, it seemed to get a lot more 
development attention (Cocoa didn’t even support proper drag and drop until 
Jaguar).

I still remember reading this thread, and feeling nervous about it:

https://lists.apple.com/archives/cocoa-dev//2002/Jan/msg01366.html

The common assumption among the more level-headed at the time was that Cocoa 
was going to be gradually rewritten to sit on top of Carbon, with Carbon 
sticking around as the lower-level, closer-to-the-metal API. They actually did 
partially do this—for example, I think that the menu system is still Carbon 
under the hood.

In retrospect, it seems clear that the real issue driving things was that Apple 
in 2001 did not have the clout that they had in 2007. Apple was in a rather 
precarious position at the time, and was in no position to dictate terms to its 
large vendors like Adobe and Microsoft on whom it depended for its survival. If 
we had known the success that Apple would subsequently reach, we might have 
been able to predict that Carbon would eventually be phased out, but to those 
living in the moment, there was no guarantee that that would happen, or even 
that Apple would still be around after all this time (indeed, if the 
inevitability of this *had* been obvious, I would have loaded up on stock). 
Hindsight is easy.

None of that makes it surprising that Carbon is gone in 2019, though (sadly, as 
I’m going to miss a lot of the game library that’s being wiped out by this).

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: Thoughts on Cocoa

2019-10-11 Thread Charles Srstka via Cocoa-dev
> On Oct 11, 2019, at 12:44 AM, Jens Alfke  wrote:
> 
> 
>> On Oct 10, 2019, at 6:18 PM, Richard Charles via Cocoa-dev 
>>  wrote:
>> 
>> Just a guess but perhaps management had an awakening when they found the 
>> time and effort expended to write the next even better version of Finder in 
>> Carbon was substantially more difficult and costly that the prior Cocoa 
>> version.
> 
> The only Cocoa—>Carbon Finder transition I know of was before 10.0 shipped. 
> The development versions had a NeXT file manager with a Mac UI skin, but 
> before release that was replaced with a Carbon-ized port of (a subset of) the 
> MacOS 9 Finder. That Finder lived on for a few years before being replaced by 
> a new rewritten Cocoa version.
> 
> —Jens

The NeXT/Rhapsody file manager was what I was referring to.

As for the 10.0 Finder, I’m sure it shared code with the OS 9 finder, but it 
was an essentially new app based on PowerPlant (which the OS 9 Finder, to the 
best of my knowledge, was not). It did not feel much like the OS 9 Finder, and 
it was missing a lot of basic functionality that the OS 9 Finder had had, much 
of which was gradually reintroduced over the years. The Cocoa rewrite of the 
Finder did not appear until Snow Leopard was released in 2009. Notably, the 
Finder was still Carbon when Apple suddenly out of nowhere (again, from the 
perspective of an outsider) dropped the previously promised 64-bit Carbon 
support in 2007.

As for the Dock, there was no OS 9 analogue to that at all, so the only 
conclusion can be that it was rewritten in Carbon from the ground up, when a 
Cocoa one had been previously available. This is difficult to explain other 
than as a statement of confidence in Carbon.

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: Thoughts on Cocoa

2019-10-12 Thread Charles Srstka via Cocoa-dev
> On Oct 11, 2019, at 5:29 PM, tblenko--- via Cocoa-dev 
>  wrote:
> 
> Me, I still don’t understand why, given the long history of support at 
> Apple/NeXT for C++

…what?

> and the maturity of the compilers available, there is any need for Swift. But 
> there it is. Or, there they are. Perhaps this is the way the younger 
> generation overtthrows the older? Or not, but I’m pretty sure there is no 
> compelling business argument for it.


Holy hell, Swift isn’t perfect, but I’d rather use it over C++ a thousand times 
over.

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

2019-10-12 Thread 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

2019-10-12 Thread 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