Re: Apple to open source Swift later this year with support for iOS, OS X, and Linux

[Dr. H. Nikolaus Schaller]

Am 08.06.2015 um 23:29 schrieb Lars Sonchocky-Helldorf 
<lars.sonchocky.helldorf@gmail.com>:

> 
> Am 08.06.2015 um 22:29 schrieb Dr. H. Nikolaus Schaller:
> 
>> Am 08.06.2015 um 21:13 schrieb Lars Sonchocky-Helldorf 
>> <lars.sonchocky.helldorf@gmail.com>:
>> 
>>> In case you don't know already …
>>> 
>>> http://appleinsider.com/articles/15/06/08/apple-to-open-source-swift-later-this-year-with-support-for-ios-os-x-and-linux
>>> 
>> 
>> Interesting move,
>> 
>> But I doubt that Gregory’s efforts for Phoenix were the driving factor as 
>> someone
>> wrote on Twitter…
>> 
>> Anyways, I still prefer Objective-C 1.0 for its expressive power and 
>> readability (Obj-C 2.0 is
>> IMHO a little less readable for me and SWIFT even more).
>> 
>> But, the language itself is becoming less and less important since the 
>> frameworks (${somethingKit)
>> are the key to an OS. And OS X / iOS is getting more and more every year.
>> 
>> Well, I know what I am talking about. Not yet in the public until now. I 
>> have rewritten some of
>> the important frameworks of QuantumSTEP in PHP.
>> 
>> PHP????
>> Are you kidding???
>> 
>> No. As said, the language isn’t that important. The architecture of the 
>> ${something}Kit is.
>> 
>> And I am using it to make my Web Pages now. Writing .app bundles using the 
>> same high level
>> abstraction of NSView, NSUserDefaults, NSBundle, NSFileManager, etc. Using 
>> the same logic as a
>> desktop .app. No need to fiddle around with <div> and <span> etc. Just once 
>> to get the AppKit.php
>> working. And theming is done by some CSS.
>> 
>> The NSGraphicsContext has become a NSHTMLGraphicsContext and it generates 
>> HTML to control
>> the remote display server (commonly known as “Browser”). Instead of Display 
>> Postscript or
>> Cairo or X11-Protocol.
>> 
>> Yes, there are some tricks (and limitations) to squeeze HTTP&HTML into the 
>> Foundation/AppKit
>> metaphor but it works astonishingly well and the key benefit is to keep the 
>> code for .app bundles
>> small.
> 
> Well, I don't get this one. What you're doing is sort of reinventing 
> WebObjects (GNUstepWeb) using PHP. And then there is http://phocoa.com/ 

I know both. But from my perspective *they* are reinventing new classes (“HTML 
wrappers”) and
do not simply use the existing and mature NS* class hierarchy.

I am just *implementing* the NS* classes in PHP - and adding a HTML backend 
because my display
server speaks HTML (and CSS + JavaScript) and not X11.

This is a very different paradigm from App development perspective.

Without that, someone has to learn (simplified picture):
* NS* classes - for Desktop interaction
* UI* and NS* classes - for Mobile interaction
* WO* and EO* classes - for Web interaction

to always achieve the same thing: add a user interface to some business logic 
and data storage.

In my approach one just has to learn:
* NS* classes - for any (remote) display

> 
> But in a way I am not surprised. You're Dr. Schaller, well known for 
> inventing stuff for yourself … ;)

Well, I am inventing new paradigms (design patterns) and thereby questioning 
existing ones…

I never understood why Apple introduced the UIKit instead of augmenting AppKit 
where necessary and
appropriate. Well, without that they could not argue that they are making 
progress by harmonizing AppKit
and UIKit more and more :)

BR,
Nikolaus

> 
> 
> 
>> 
>> Some code can be found here:
>> 
>>      
>> http://git.goldelico.com/?p=mySTEP.git;a=blob;f=AppKit/Sources/AppKit.php;hb=HEAD
>> 
>> So back to the topic: SWIFT will attract more developers to the MacOS / iOS 
>> ecosystem. But detract
>> some from GNUstep (unless GNUstep gets SWIFT bindings). Since people like to 
>> express themselves
>> in their favorite language. And use common building blocks. Like LEGO is 
>> worldwide but the user manual
>> is translated into many mother languages…
>> 
>> BR,
>> Nikolaus
> 
> cheers,
> 
>       Lars