Good question. I have no idea how difficult that would be. It would depend on how well-factored the disk access routines are from the other OS routines. You *can* reserve part of a Profile hard disk as a Pascal volume using a tool that comes with Apple Pasca, but I don't know if that's a file on a ProDOS volum, or how it works.
The MS-DOS p-system did apparently interoperable with the FAT filesystem, so it's possibly do-able?
Yeah, it would have to be an ARM-based Arduino, to use the Rust version. But there are several of those now, and they're not even necessarily more-expensive than the AVR versions.
Why in the world would you want a new interpreter for the Apple II? The one that exists is fine. And yes - people *have* done this before, mostly rather a long time ago. Building another version of the same thing isn't a bad thing, especially if it comes along with better documentation of the internals, in a way that's accessible to a modern audience.
Unsurprisingly, the 25-year-old project you refer to doesn't build on my system. And neither does the version Peter Miller updated way back in 2010. It's probably worth revisiting projects like this every decade or so.
Yes, with a caveat. Apple Pascal has some native 6502 routines as extensions to the standard UCSD Pascal. These will have to be translated, ideally to p-Code, and wired into something in the emulator. But I'd *like to* do that, once I have things up and running.
- Why does Swift have both a "var" keyword and a "let" keyword? One should be sufficient with the other being a default behavior. If a symbol is not declared "var" then just assume it is constant or visa versa. Furthermore, it may not be necessary to have either of the key words because (I think) in every case, the need for variability and mutation should be determinable by the compiler. Type is already being inferred by the compiler, and mutability could reasonably be considered an aspect of type.
Having to use a keyword to introduce a new symbol is a pretty critical reliability feature. If there's no keyword to say "I want to define a variable", then every typo creates a new variable, rather than a compiler error. Lots of scripting languages work this way, and it's hell on reliability.
- Why are Swift collection types like Data always mutable? What happened to the concept of immutable containers from Cocoa. [Yes, I know the "bridged" CF types are always mutable, but that was another bad decision IMHO.]
They're not. That's why you have "var" and "let" keywords. You use "let" for constants, and "var" for mutable objects.
- Swift is intended to be a "Systems Programming Language", is it not? Yet, there is no support for "volatile" variables needed to support fundamental "system" features like direct memory access from peripheral hardware.
"Systems programming" != "device driver development". Nothing above the driver level should be accessing hardware directly, so that's a feature that could likely wait until every other Swift use-case has been addressed.
- Having experienced frustration trying to port high performance graphics code from C/C++/Objective C to Swift, what's up with that? IMHO, Apple's sample code for using OpenGL/GLKit/Metal from Swift leaves the impression that Swift is unsuited to the style of "low level" programming needed/used by OpenGL/GLKit/Metal.
Not sure what the actual complaint is here. Can you give an example of something that's particularly difficult?
- Why not support "dynamic runtime features" like the ones provided by the Objective-C language and runtime? It's partly a trick question because Swift is remarkably "dynamic" through use of closures and other features, but why not go "all the way?"
Part of the goal of Swift is to use compiler "smarts" to generate performant code. You can't really do much in the way of optimizations for dynamic dispatch, so it's not the preferred method. The bindings are there to talk to Objective-C, but Swift-native code is expected to solve those problems another way.
- Finally, a trivial aesthetic critique: Why "var foo : typename" like Ada and Pascal (IIRC) instead of "var typename foo" like every language that inherited C style syntax? Is there an advantage to the Swift approach that I haven't seen, or was it just an aesthetic choice? Did the choice not produce some IMHO "silly" syntax for method declarations with named parameters?
As far as I know, it's purely aesthetic. It's worth noting that type declarations are optional fairly often in Swift, so perhaps it was a decision to try to make the appearance of types less "jarring" where they *do* need to show up.
Why does the boot process require random numbers, anyway?
They mention this in the article - one way to make a kernel harder to write an exploit for is to randomize the layout of memory somewhat, so system libraries, kernel tables, and the like are located in different places. Obviously if the "random" numbers are predictable, this makes those mitigation techniques less-useful.
But it's far more questionable whether he would welcome the iPhone 5C—almost certainly a low-margin device, despite its current-generation components and plastic body—taking a bite out of the more expensive, and presumably higher-margin iPhone 5S
Seriously? This guys thinks the margins on the iPhone 5c are *lower* than the 5s? In that case, why is everybody else complaining about how expensive the 5c is, and saying it should have been released at a $300 price point? If you believe that the 5c could be made & sold at $300 (and I do), then since it sells at $550, Apple *must* be making something like 40% margins on them. The 5s is $100 more, but I bet it's considerably more-expensive to make.
These are my favorite sketching / writing pens.
Read all about them here.
It's likely that the percentage of outsourced projects tracks the prevalence of security problems. Certainly, the government has a very high level of outsourced vs in-house development. I think that financial institutions also tend to largely outsource (especially customer-facing) development.
I'd be willing to put a reasonable amount of money at risk predicting that Apple will eventually ship something that's not an iPhone or iPad, which runs the full version of Mac OS X on the ARM architecture. Given how smooth (relatively speaking) the PPC-to-Intel transition went, it'd be a minor speed bump for most developers, not a major disaster. If you're already supporting PPC and Intel, then ARM is just a testing burden - you already need to code for big- and little-endian architectures, for example.
Given the Mac App Store, there's a lot less in the way of friction to just recompile something and put it out there, as opposed to trying to get boxes on retail shelves. Yes, third-party developers will complain, and so will users if they can't get whatever apps they depend on right away. Given that Macs already come with all the basics (email, web, music/video playback), probably 75% of typical users wouldn't even need to buy anything for an ARM Macbook Air to get plenty of use out of it.
If you're willing to include software that was developed, but not released, there are:
m68k (original NeXT hardware)
i386 (NEXTSTEP for Intel processors)
SPARC (NEXTSTEP for SPARC)
HPPA (NEXTSTEP for PA-RISC)
Motorola m88k (NeXT RISC Workstation - never released, but a working copy was at Apple when I worked there)
PowerPC (Mac OS X Server 1.0, later developed into Mac OS X)
Significant bits of NeXT software were also ported to Intel i860 and DEC Alpha, but not enough of the OS to actually qualify as a "NEXTSTEP port"
I'm not sure I'm understanding the question, here. Do you mean could it be included with Android? Absolutely - the license allows that, though I'm not sure what advantage shipping a version of Enyo with an Android distribution would be. It'd likely be out of date fairly rapidly.
If your question was more along the lines of "will Enyo apps run on Android", then the answer is it depends a bit on what version of Android - there are some significant bugs with some Android browsers That said, the intent is for Enyo 2.0 to be compatible with as many web browsers as possible.
He who has but four and spends five has no need for a wallet.
