Absolutely. Add fast as it was compiled to native binary as opposed to BASIC.

For high level code. For low level code on the Apple II we had the LISA assembler. It offered an IDE. It also parsed your code as you typed. So you would get an error message for a syntax error as you hit enter for the line.

Lisa becoming a Mac was retroactive. The original OS under Lisa was not Mac OS. Like Unix, Windows NT, and Mac OS X; Lisa OS had memory protection. The Mac would not get that for decades. Turning a Lisa into a Mac XL was a downgrade of sorts, one offset by more software available for it.

Only for those with $10K lying around. For the rest of us the Apple II was literally our development system for the Macintosh. We would add a 68K coprocessor card to the Apple II. Write our code in assembly on the coprocessor, test it the best we could. We learned that nice habit of separating functional code from the system code. :-)

Then when ready to test the system code we would download a binary to the Mac using a MS-Basic program that would read the serial port and "poke" the data into RAM, then jump to that poke'd code. Let's say debugging was primitive. Hex values in the corner of the screen. But it was doable, and so very very educational.

68K is still my favorite assembly language.

You still can. Apple computers (Macs) still let you load software from disc, from flash, from the net, etc. It's only mobile devices (iPhone, etc) that do not.

After Jobs 1.0 was fired from Apple, Woz helped with the Mac and slots were added to some models. Today, many of the things that once required slots and specialized adapters now use standardized interfaces likes usb or thunderbolt. Want to engineer your own device and connect, no problem, there is no shortage of support for such hacking via usb. See Adafruit or Sparkfun.

Once you needed a slot and a specialized adapter to add a drive. Now you can do that with USB.
Once you needed a slot and a specialized adapter to add a monitor. Now you can do that with Thunderbolt. Hell, you can add an eGPU graphics card via Thunderbolt. Jobs 1.0 was premature with abandoning slots, Jobs 2.0 still leaned against slots, but I recall some Macs with slots too during his 2nd reign. Maybe Jobs 2.0 was better described as a little too early rather than wrong like Jobs 1.0.

While significantly smaller it is still an interesting size from a business perspective. While people do not buy Macs to play games, people who have bought a Mac for some other reason may still want to play games on it. It’s the computer they have, they want to play games on it.

Basically not releasing a Mac version is leaving money on the table.

Not true at all. The simple truth faced by game developers is that people with "gaming rigs" with high end GPUs are not the norm. The game buying public is more likely to have a PC with a low-end CPU, little RAM, and a low-end integrated GPU (most likely Intel, AMD if very lucky). Such people are a large part of the gaming market, even low-end Macs are comparable to these.

Basically not releasing a game that supports modest PCs is leaving money on the table.

Apple actually supports Linux, not in the dual boot sense but in the virtualization sense.

macOS' Virtualization Framework has let people create console Linux VMs for a while now. With the recent release of macOS Ventura GUI Linux VMs are supported on Apple Silicon CPUs. With full GPU support, integration with the host macOS desktop for transferring files, etc.

Linux may be a second class citizen to Apple, not being allowed to dual boot, but it is not incomplete and behind when run from Apple's virtualization framework.

2007 MB, 2011 MBP, 2018 MBP ... I doubled the RAM in all, replaced HD with SSD in the 2011 MBP. They all made fine desktop replacements, with occasional mobile usage, until they stopped receiving OS updates. I figure getting 7 years is not a problem.

Admittedly I'm build small projects. Things that compile from scratch in under a minute.

Its almost like they had a plan. Boost M1 sales by skipping an upgrade cycle on Intel. ;-)

Not necessarily. Many commercial libraries offer both binary and source+binary licenses. A licensee gets access to the source code in the latter, however they may only distribute binaries to their customers. This allows them to have their own fork and control their destiny. At small companies I have successfully convinced management to buy the more expensive source licenses, and in both cases it saved our asses. If the bug was in a library would could fix and patch and deliver a fix to our customers at the same rapid pace as if the bug had been in our code, we were not dependent up the library vendor for a fix, at whatever their pace would be.

Admittedly this was not an environment where we had some crazy dependency tree. So doing a diff on the periodic updates of a few special purpose libraries did not take to long. The library providers were also commercial vendors, less likely to engage in hacktivism in the first place.

There are three options not two.
(1) FOSS license
(2) Commercial Source license
(3) Commercial Binary license

FOSS and Commercial Source licensing are nearly identical for direct licensees. A licensee has the source code to the application or library, they may make changes or additions, they may freely distribute binaries with their changes. The difference is largely that source code only goes one generation, to the direct licensee and not to their customers too.

So as a developer you have two options where you can verify source code and maintain a fork. In other words two paths that keep your future in your hands.

Maybe not. My graduate Computer Organization class focused on the Dec Alpha. A very impressive at the time RISC architecture that was to be (and eventually was) supported by Unix and Windows NT. The Unix and WIndows NT 4 boxes that emerged were quite impressive in their performance.

That said, a RISC-V dev board is among my collection. I'm sure it will have some niche but I would not bet against ARM. And certainly not Apple's incarnation of ARM, which sadly may not be seen outside of Apple products. I'm kind of curios with respect to how NVIDIA could enhance an ARM architecture.

I have friends who have use a mac, have android phones, and use google apps and services just fine.

He was talking about Linux suiting your needs. I was pointing out that one's needs for applications, utilities, tools, tools chains, etc are not necessarily tied to Linux. That one's needs are probably not tied to Linux, and that is why some people choose mac hardware. The real topic hear being mac hardware and the Apple Silicon CPUs in general.

There are two reasons.

(1) The software they need to run is *nix based, not Linux. Linux is just one of many *nix environment they can run. In addition to pretty much any software that Linux runs, macOS also offer access to the commercial applications that are not found under Linux. MS Office, Adobe Photoshop, etc.

(2) As a developer you can target the three major desktop OS environments, and the two major mobile OS environments, with a single Mac. macOS, *nix, and Windows on the desktop side. All running natively, directly on the hardware. At least for Intel. For Apple Silicon its just macOS and *nix for the moment. iOS and Android on the mobile side. Its pretty convenient to target these 5 environments natively.

Related to (2), you can also toss in various embedded environments. Again, vendor toolchains tend to be *nix not Linux.

No, FOSS GUI apps is referring to LibreOffice, Gimp, etc. Native support for both Linux and macOS.