Chatbots recommendation AI Developer Tools to assist in writing NeXT programs

[Rob Blessin Black Hole]

Hello NeXT Community:   I've been tinkering with Chatbot Artificial Intelligence to see if it offers good advice n programming as it is so fast wow , I hope you all find this useful so responses are canned but some of the tips are very cool.

Do you have a recommendation for AI  Programming tools assistant versed in NeXTSTEP Developer Tools and Openstep Developer Tools ?

Since NeXTSTEP and Openstep are relatively old technologies, many modern programming tools and environments may not be fully compatible with them. However, there are still some tools and resources that could be useful for an AI programming assistant versed in NeXTSTEP and Openstep:

    GNUstep: This is an open-source implementation of the Openstep specification, which allows developers to write NeXTSTEP/Openstep-style applications using modern programming languages like Objective-C and Swift. It provides a set of development tools and frameworks, and supports many platforms including Linux, Windows, and macOS.

    CodeRunner: This is a lightweight IDE for macOS that supports a variety of programming languages, including Objective-C, Swift, and C++. It could be useful for writing and testing code written in NeXTSTEP and Openstep, as well as newer technologies.

    OpenStep Enterprise: This is a commercial development environment that provides a range of tools for building NeXTSTEP/Openstep-style applications, including an IDE, object-oriented frameworks, and a graphical user interface builder. It was developed by a company called Stepstone, which was founded by former NeXT employees.

    Stack Overflow: This is a popular Q&A site for programmers, and has a dedicated community of developers who are knowledgeable about NeXTSTEP and Openstep. Your AI programming assistant could use it to ask for help with specific programming problems or to get advice on development best practices.

I hope these recommendations help your AI programming assistant with their work in NeXTSTEP and Openstep. Good luck!

[verdraith]

Alas, most of this advice is just plain wrong.

Here's why:

GNUstep: This is an open-source implementation of the Openstep specification, which allows developers to write NeXTSTEP/Openstep-style applications using modern programming languages like Objective-C and Swift. It provides a set of development tools and frameworks, and supports many platforms including Linux, Windows, and macOS.

At this point, we can consider GNUstep a superset of OPENSTEP, which is a superset of OpenStep.  GNUstep also has mixed compatibility with NEXTSTEP.  NEXTSTEP's appkit is in no way compatible with GNUstep's AppKit, and the port of Foundation to NEXTSTEP is a subset of that of OPENSTEP.

GNUstep also allows newer Objective-C compilers and runtimes -- for example, Objective-C with garbage collection (Objective-C `2.0') instead of reference-counted autorelease pools (OPENSTEP), or NXZone malloc/free (NEXTSTEP).

Changes in the language brought about by Apple also mean that valid GNUstep code might not compile on OPENSTEP at all, e.g.:

Code Select Expand

@interface Person : NSObject {
@public
  NSString *name;
@private
  int age;
}

@property(copy) NSString *name;
@property(readonly) int age;

- (id)initWithAge:(int)age;
@end


CodeRunner: This is a lightweight IDE for macOS that supports a variety of programming languages, including Objective-C, Swift, and C++. It could be useful for writing and testing code written in NeXTSTEP and Openstep, as well as newer technologies.

I guess ChatGPT doesn't know that NEXTSTEP and OPENSTEP have capable editors already

OpenStep Enterprise: This is a commercial development environment that provides a range of tools for building NeXTSTEP/Openstep-style applications, including an IDE, object-oriented frameworks, and a graphical user interface builder. It was developed by a company called Stepstone, which was founded by former NeXT employees.

I... what?  Stepstone (the creators of Objective-C) predate NeXT.  It's partially right, but wrongly worded.  Some Stepstone employees went on to work for NeXT.  I'm also not sure what Stepstone had to do with OpenStep Enterprise.  Maybe an ex-NeXT employee can provide more context.

I'm also not sure how OpenStep Enterprise would help... as one could just as easily use OPENSTEP 4.2 for Mach.  Also, NIBs generated with OpenStep Enterprise won't work on NEXTSTEP (and also could have issues, due to NSInterfaceStyle, on OPENSTEP).

Stack Overflow: This is a popular Q&A site for programmers, and has a dedicated community of developers who are knowledgeable about NeXTSTEP and Openstep. Your AI programming assistant could use it to ask for help with specific programming problems or to get advice on development best practices.

Although technically correct, I'd imagine that most people on StackOverflow made the move from NeXT to Apple and now have 20 years worth of Cocoa/Core knowledge that has displaced their AppKit/Foundation knowledge.

Now, on to the real advice.

[verdraith]

I'm interpreting the question as "do you have any recommendations on how someone could potentially engineer a solution for either NEXTSTEP or OPENSTEP that implements a programming tool that can interface with AI systems such as ChatGPT in order to help programmers."

As with all engineering topics, the answer can be as complex as one wants it to be. So for brevity, I will not answer that question directly (yet) but rather present generalist advice that could hold true for any project for NeXT's platforms.

Nomenclature
OpenStep is an open specification.  OPENSTEP (full name "OPENSTEP for Mach") is an operating system.  OPENSTEP is a superset (an implementation with extras) of OpenStep.  OpenStep Enterprise and OpenStep for Solaris are subsets of OPENSTEP that implement OpenStep and the bare minimum of OPENSTEP (and even smaller parts of Mach) on Windows and Solaris.

Thank you, NeXT.  Should have just stuck with OpenStep and NEXTSTEP in my humble opinion.

Many an article has been written on NextStep vs NeXTstep vs NeXTSTEP vs NEXTSTEP, so I won't rehash all that here.

GNUstep started off as an implementation of NEXTSTEP's AppKit (written in C using Motif), then transformed into an implementation of OpenStep + Display PostScript, and morphed into an implementation of Cocoa.  It can be considered a superset of OpenStep now.

And to be completionist,
Yellow Box is an implementation of OpenStep that was designed to sit next to Blue Box and Red Box(?), running on a nifty beige or white box maybe.
Blue Box Macintosh 'classic' (read: QuickDraw, Carbon, etc).
Red Box(? not sure if this was ever a thing) was apparently a plan for a Windows environment that would have ran on Rhapsody.
For more details, see https://lowendmac.com/1997/red-box-blue-box-yellow-box/

Learning Objective-C
This is a bit of a lie.  Actually, it's a big lie.  You should understand that for all intents and purposes there are three languages at play here.  Objective-C, Objective-C + AppKit on NEXTSTEP (where you'll be using things like AppKit's `View` alongside `char *`) vs Objective-C + AppKit + Foundation on OpenStep (where you'll be using things like AppKit's `NSView' alongside Foundation's `NSString'.)

Actually, this is probably a bit waaaaay simplified to the absurd.  It's more like treating it as one language with two distinct toolkits that kinda look similar but work entirely different to each other.

The core of Objective-C is mostly the same across NEXTSTEP and OPENSTEP and OpenStep -- except where it isn't.

There are language changes between NEXTSTEP 1.x, 2.x, and 3.x.  NEXTSTEP 3.x mostly makes use of `Objective-C 2.0` (but not Apple's Objective-C 2.0... confused?  good, you will be.)

I would recommend not looking at any older code to start with.  You will see a lot of scary stuff -- structures embedded inside classes acting as instance variables yet containing hairy state in the form of bitfields, the use of `new` class methods to initialise said hairy state when instantiating objects... ugh.

The absolute best resources to start with would be:

• Simson Garfinkel's NeXTSTEP Programming: STEP ONE: Object-Oriented Applications.  PDF available at https://simson.net/ref/1993/NeXTSTEP3.0.pdf
• Alex Nghiem's NeXTSTEP Programming: Concepts and Applications.
  
• NeXT's introduction to Objective-C, available from your local NEXTSTEP 3.x installation's developer documentation.
• The cookbook (and various book sources) on the Nebula CD-ROMs

Once you have got to grips with Objective-C and AppKit on NEXTSTEP 3.x, migrating to Objective-C on OPENSTEP will be pretty easy -- you will already be used to using the `init`, `alloc`, and `free` instance methods.  You will already be used to actions, outlets, responders, selectors, delegates et al, and you will (hopefully) be aware of objc/List.h, objc/HashTable.h, and maybe objc/Storage.h

There are several resources available for OPENSTEP and OpenStep.  The best places to start with those would be the OPENSTEP developer documentation and, for understanding things like NSURL, Apple's early documentation (Yellow Box, Rhapsody, GNUstep, very early MacOS X).

There are some gotchas with this, though.  I will address those right....

[verdraith]

meow.



Platform compatibility
NEXTSTEP is binary forward-compatible with OPENSTEP (but not OpenStep Enterprise, OpenStep Solaris, Yellow Box/Rhapsody, or GNUstep).  OPENSTEP is binary forward-compatible with newer versions of OPENSTEP to an extent.  OPENSTEP is not binary backward-compatible with NEXTSTEP¹.  OpenStep is code forward-compatible with any other OpenStep -- to a point.  OpenStep is not fully code backwards-compatible with NEXTSTEP -- only a subset of OpenStep's Foundation is available to NEXTSTEP.

Binary means that a thing compiled on NEXTSTEP 3.3 will run on OPENSTEP 4.2.
Code means that a thing written for OPENSTEP 4.2 should compile on OpenStep Enterprise.

A portable application that requires the targeting of both NEXTSTEP and OPENSTEP must then be developed on NEXTSTEP.  Either using AppKit and C-style strings, or a portable String class, or NSString from the NEXTSTEP port of Foundation.  One must ensure that features from OPENSTEP, OpenStep Enterprise, Rhapsody, GNUstep et al are either left unused, or backported to NEXTSTEP (e.g. `NSURL`.)

One could make use of MiscString from MiscKit, but one would need to be aware that this would require the NEXTSTEP version of MiscKit to be compiled on OPENSTEP, as the OPENSTEP version of MiscKit removes MiscString in favour of Foundation's NSString.

If one makes use of the NEXTSTEP port of Foundation, one must be aware that--as stated--this is a subset of Foundation from OPENSTEP.  One must also be aware that by using the NEXTSTEP port of Foundation your code will not be portable to any system older than NEXTSTEP 3.3.

You will be doing your own memory management.  Be comfortable with malloc(3) and family.  Ideally, you'll also want to be comfortable with NXZone: `NXDefaultZone`, `allocFromZone`, and how to make `malloc`, `calloc`, `realloc`, and `free` make use of NXZone.

Language compatibility
I will keep this brief, as I do not intend to teach anyone Objective-C through this post alone, and this topic is large and full of pitfalls and icebergs and naughty traps with sharp pointy sticks and gnashing of teeth and loud wailing and tears of despair and sad puppies and broken dreams.

As such, read this last, after everything else, once you start bashing away at the keyboard in anger whilst writing code, lest it permanently scare you (and scar you) and make you regret trying to write code.

Objective-C in NEXTSTEP does not make use of reference-counting.  There are no autorelease pools (unless you use the NEXTSTEP port of Foundation), and there is no `retain`, `release`, or `autorelease` (again, unless you use the NEXTSTEP port of Foundation).

NEXTSTEP 3 makes use of `Objective-C 2.0' which is not the same as Apple's `Objective-C 2.0' (confused yet?).  Objective-C in 1.x and 2.x makes use of class methods named `new` that allocate and initialise new instances.  Objective-C in 3.x makes use of instance methods named `init` that invoke the super's `alloc` and then initialise the new instance.  The use of `new` can invoke the wrath of the compiler if you attempt to initialise member variables inside the class method.

Code Select Expand

Foo *inst = [Foo new];vs

Code Select Expand

Foo *inst = [[Foo alloc] init];
You will run into this a lot if you look at older code on, say, the Nebula CD-ROM.

You should prefer the alloc/init/free instance methods.  And you should make sure you free memory that is no longer required.  You should also sanity-check the results of `[super alloc]` and handle it being 'nil' properly.

Most old code also does no sanity-checking on the result of malloc, calloc, realloc etc.  Do not fall into that trap.  Test every allocated block of memory against NULL and handle the out-of-memory error accordingly.

Like K&R C, there are various default types that are inferred when not explicitly stated.
A function without an explicit return type is inferred to return a thing of type `id`.  An argument without an explicit type is inferred to be a thing of type `id`.  This is important as Interface Builder can fail at parsing your outlets and actions if you have explicit types.

OPENSTEP (and OpenStep) make use of `IBOutlet` and `IBAction` types... these are not in NEXTSTEP, and won't help you out should you do decide to add explicit types to your outlets and actions (don't do this, seriously.)

You should prefer using a proper String class rather than `const char *` or `char *` if you plan to make use of Objective-C's List or HashTable classes, as this will make your life easier when it comes to freeing them.

There are no member or method access specifiers in NEXTSTEP or OPENSTEP's Objective-C.  No `private`, no `public`.  There are also no property (setters, getters, readers, writers, editors, proofreaders) generators.  There are also no synthesisers, Yamaha, Roland, KORG, Moog or otherwise.

Objective-C follows the Smalltalk tradition of having the function name and argument names be the actual internal name of the function.

This is to say that this:

Code Select Expand

- (id)frobnicate:(int)identifier
        withName:(const char *)name;
would internally be known as

Code Select Expand

frobnicate:withName:

Argument names are optional.  Be on the lookout for functions like

Code Select Expand

- cellAt:(int)row:(int)col;
which internally would be

Code Select Expand

cellAt::

There is probably a lot more I could iterate here, but I feel those are the basic gotchas when moving to Objective-C `2.0' on NEXTSTEP from Objective-C + Foundation on an OpenStep implementation.

Footnotes
1. There might be a hack involving an OPENSTEP upgrade on top of NEXTSTEP, leaving the NEXTSTEP headers etc intact so that pure NEXTSTEP code could theoretically be compiled on OPENSTEP, and, as the Mach-O format is unchanged, boom, your OPENSTEP app (but not using any OpenStep framework) might possibly work.  I have no idea if this actually works or has ever been done.

[verdraith]

So what is this claptrap about Objective-C 2.0 and Objective-C 2.0?

In earlier versions of NEXTSTEP, you would see code that looks similar to

Code Select Expand

@interface Foo : View
{
  /* Scary stuff here */
}

+ newFrame:(const NXRect *)frame;

/* ... */
- alloc;
- free;

/* ... */
@end

And if you looked at the implementation, you might see something that looks like

Code Select Expand

+ newFrame:(const NXRect *)frame
{
    self = [super newFrame:frame];

    /* Whole load of state initialisation here */

    return self;
}
And you might think to yourself: "Aha, constructor method!"

You then might write code like that on NEXSTEP 3.3.  You'd write `blah = [Foo newFrame:someFrame]', Then GCC would shout at you for attempting to initialise member fields from a class method.

I call this "Objective-C 1.0" (I guess NeXT did, too).  There are other differences, but I don't know them all... yet 

If you look at similar code on NEXTSTEP 3.x, you might see stuff that looks like

Code Select Expand

@interface Foo : View
{
  /* Scary stuff here */
}

- initFrame:(const NXRect *)frame;

/* ... */
- alloc;
- free;

/* ... */
@end

And if you looked at the code, you might see stuff similar to:

Code Select Expand

- initFrame:(const NXRect *)frame
{
    self = [super initFrame:frame];

    /* Member initialisation code here. */

    return self;
}

The new paradigm (Objective-C 2.0, yay) would be `blah = [[Foo alloc] initFrame:someFrame];`

Apple's Objective-C 2.0 adds various language feature and runtime changes, most notably of which is garbage collection.

Apple's Objective-C 2.0 also adds member visibility (private vs public), property synthesis (so you don't need to write trivial setter/getter code), etc.

Hopefully things are now less confusing.


For the record, I am not sure when NeXT made the move from 1.0 to 2.0.  I suspect for NEXTSTEP 2.0, but I haven't written any code for that yet, so I'm not 100% sure.  Either way, some example code will look confusing and potentially refuse to compile because of these changes.

I also have no idea why Apple didn't use `3.0` as the version number, given that there were people at Apple working on Objective-C who were also at NeXT doing the same thing.

[Nitro]

• Simson Garfinkel's NeXTSTEP Programming: STEP ONE: Object-Oriented Applications.  PDF available at https://simson.net/ref/1993/NeXTSTEP3.0.pdf
• Alex Nghiem's NeXTSTEP Programming: Concepts and Applications.
  
• NeXT's introduction to Objective-C, available from your local NEXTSTEP 3.x installation's developer documentation.
• The cookbook (and various book sources) on the Nebula CD-ROMs

Thanks for sharing all of this knowledge. I've seen Simson Garfinkel's NeXTSTEP Programming PDF and it's quite comprehensive. I just recently learned that he wrote some of the CD-ROM code for NeXT.

https://github.com/johnsonjh/NeXTMach/blob/master/cdrom-3/CDROM.util/cfs.util.c#L7

[Rob Blessin Black Hole]

Hello Verdraith: Who needs Chatbot AI when we have Verdraith lol running circles around it Thanks you for all the knowledge ! It is kind of fun seeing Chatbots high speed holyier than thou knowledge purge aka cocky freshman get schooled by the real GURU V lol best regards Rob Blessin  The greater question is how will Chatbot GPT take in or handle correct or updated information , this will probably get interesting as hords of trolls will probably start taking runs at it to see if the can manipulate responses.   An glaring example was the 100 billion dollar hit google took when Chatbot gpt had an incorrect response , the trading bots picked up on the chatter  and then started dumping google stock .  So it would kind of be like a mass misinformation campaign by say Robinhood traders to see if they can trick the trading bots to action  through feeding chatbot incorrect information leading to chaos , run for your lives lol the trading bots are screwing your 401K.

[verdraith]

To be fair, mate, ChatGPT shows great promise.

As far as I understand, ChatGPT no longer learns.  It was `pre-trained' before going live.

It will get things wrong from time to time, as its responses are quick summaries of information it gleaned from multiple sources.  It doesn't actually know the truth, it only knows what it knows -- this is true of most AI projects of this nature.

For example, the Stepstone comment.  Some Stepstone employees went over to NeXT to work on the GCC Objective-C backend, and then became ex-NeXT employees when they moved over to Apple to work on GCC and then Clang.  So if we twist semantics and do some awkward mental gymnastics, Stepstone did have ex-NeXT employees.

Re trolling, I think the most interesting thing anyone can do is get ChatGPT to talk to itself
https://www.reddit.com/r/OpenAI/comments/zk8521/ah_yes_chatgpt_is_having_a_conversation_with/

One of the listed 'problems' with ChatGPT is the fact that it will give incorrect and/or nonsensical answers.  It's been trained to answer rather than be cautious.

ChatGPT sometimes writes plausible-sounding but incorrect or nonsensical answers. Fixing this issue is challenging, as: (1) during RL training, there's currently no source of truth; (2) training the model to be more cautious causes it to decline questions that it can answer correctly; and (3) supervised training misleads the model because the ideal answer depends on what the model knows, rather than what the human demonstrator knows.

As a tool for engineers, ChatGPT shows some real promise.  There are some caveats, however.

Context.  ChatGPT really needs to know context when attempting to solve engineering problems.  I.e. asking it to write OPENSTEP drivers.  It would need to have sources for DriverKit, and a specific brief on what it's task ought to be, else it runs the risk of producing something very incorrect (and possibly using Apple's DriverKit and/or IOKit.)

A colleague here at work asked it to write a module for our soft-real-time parsing engine, and it created something entirely different because 'parsing' means many things.  He then realised that if he was specific with his requirement and gave ChatGPT access to our source code, it could potentially write our software for us.

Personally, I'm interested to see how Google's bot fares.  Part of me would also love to see Bard conversing with ChatGPT.

If Bard can pass the Turing test (no reason why it shouldn't, LaMBDA already has), then there's absolutely no reason why Bard conversing with ChatGPT (which has also passed the Turing test) wouldn't look like your average Facebook conversation.  Well, more like Reddit conversation.  I doubt Bard/ChatGPT would devolve to conversations about makeup, food, and/or relationship problems.  Or maybe it would.  Oh man, SKYNET!

https://mpost.io/chatgpt-passes-the-turing-test/