Re: Some GNUstep discussions in other forums

[Andreas Fink]

> On 27 Dec 2018, at 12:56, H. Nikolaus Schaller <hns@goldelico.com> wrote:
> 
> Hi David,
> 
>> Am 27.12.2018 um 12:15 schrieb David Chisnall <gnustep@theravensnest.org>:
>> 
>> On 26/12/2018 16:08, Patryk Laurent wrote:
>>> Hi David,
>>>> a language (which is somewhat dated even in its latest incarnation). 
>>> I would love to know your thoughts with respect to that point, if you'd 
>>> care to share (off list if you'd prefer). Or might you have a talk/article 
>>> you could point me to?
>> 
>> A programming language is intended as a compromise between the abstract 
>> algorithms in the programmer's head and the concrete hardware on which it 
>> runs.  Ideally, it should be easy to map in both directions: from the human, 
>> to the programming language, and then to the target hardware. Roughly 
>> speaking, high-level language is one that optimises for the 
>> human-to-programming-language translation, a low-level language is one that 
>> optimises for the programming-language-to-machine translation.
>> 
>> Objective-C is a good late '80s programming language.  It has an abstract 
>> machine that is very close to late '80s hardware: flat memory, a single 
>> processor.
> 
> Really? First of all even the good old 680x0 did have a coprocessor concept 
> and multitasking support. AFAIR it was even multiprocessor capable but I am 
> not sure if there were machines built with several processors.
> 

I would count the 68k family as a early '80 processor. The Motorola 68000 
series did have mathematical coprocessors as second chip (68020) or built in 
(68030 and above) but thats just like a floating point unit option externally 
attached (similar to the 80286+80287 if I remember correctly). I'm not aware of 
any multiprocessor system built on 68k with the exception of some Nubus 
daugther card which run their own 68k processor to do specific IO tasks to 
assist the main processor. However thats not really Multiprocessing in the 
sense of SMp. Multitasking is a question of the operating system, not the 
hardware (although hardware support such as virtual memory etc can help there a 
lot).

Personally  I have not seen any Objective-C code ever being run on 68000 
series. On the Macintosh it started with MacOS X (which was around 2000) and 
that was a couple of years after the mac transited from 680000 to PowerPC. 
(wich was in 1994).



> And ObjC has NSThread and there are Distributed Objects which are very old 
> but powerful concepts. If DO is used properly you have a single set of 
> communicating objects which can be spread over multiple processors, machines, 
> even distant internet nodes...
> 
> Unfortunately Apple almost abandoned the concept and did not take care much 
> about binary compatibility and an open protocol specification (GNUstep DO are 
> not compatible to OS X DO). Therefore it is rarely used.


I disagree here. This is up to the application to make use of it and is used a 
lot behinds the scenes as well. For example if you do HTTP client requests, you 
have background threads dealing with it.
My own applications have dozens if not 100's of threads sometimes. But it takes 
careful planning and synchronisation. Otherwise you manipulate data from two 
places and the like which gives you very funny crashes. Even though you might 
not see NSThread directly, you might see a lot of stuff built on top of it.


> This isn't the world that we're currently living in.  Computers have 
> multiple, heterogeneous, processors.  My ancient phone (Moto G, first 
> generation) has four ARM cores, some GPU cores, and a bunch of specialised 
> accelerators.  It has a fairly simple memory hierarchy, but my laptop and 
> desktop both have 3 layers of caches between the CPU cores and main memory 
> and have private DRAM attached to the GPU.
>> 
>> A modern language has to expose an abstract machine that's similar to this.
> 
> Hm. What do you mean with this? IMHO a modern (high level) language should 
> not expose but hide all this heterogenity and 3 layers of cache if they exist 
> in physical HW.
> 
> Usually you don't program for four ARM cores and a specific number of GPU 
> cores and accelerators. You rather expect that your high-level (application) 
> program (game, physics simulator, CAD, word processor, web browser, video 
> editor, ...) is compiled in a way that it magically makes best use of what is 
> available.
> 
> Of course, ObjC is not ideal for implementing system level libraries or even 
> a kernel.

I do agree. ObjC's automatisms would get into the way for hardcore kernel 
stuff. However if you look at a microkernel architecture such as Minix where 
even things like filesystems are implemented in userspace, ObjC can do a lot of 
this stuff.