For those comparing the cost of public transit to Uber don't forget to keep in mind that Uber is also subsidized by the government. They are not paying 100% of the cost of the roads and other infrastructure they use.
Nope. Gasoline taxes pay for roads. Vehicle registration taxes pay for even more services from the government. Income taxes on earnings pays for some things as well.
However city buses are tax subsidized. Why not boost the fare to actually cover the costs? Cities buses are driving on subsidized roads -- their fuel, vehicles, maintenance and marketing is tax subsidized. They even have special lanes built just for them -- paid for involuntary by people who are opposed to such things. Uber is paid for entirely by those that chose to pay for it, which is how it should be.
Why should I pay for city buses I won't ride? Why shouldn't the people riding the bus pay for it?
As for buses, it is a good thing if they are cheaper than cars. Encouraging public transport use is good for the environment, for people who cannot afford to own a car and also reduces congestion in the streets.
By your argument we should also have a sizeable congestion tax for driving a car during peak hours as well as a substantially larger gas tax.
There's no reason it can't come back. It requires a massive amount of programming work and possibly new hardware but it's definitely possible and people are already working towards it. It's actually quite possible to build upon it and even surpass it.
People are working on new Lisp-based systems (which is awesome!) But Symbolics systems will never come back, and it's unlikely that any of these systems will gain traction in a world where Unix dominates.
...Unless, of course, one of the popular embedded or mobile systems companies (Apple, etc.) Suddenly rewrote everything in lisp, and forced all 3rd-party devs to do the same, creating a massive market only reachable by Lisp programmers.
Apple did that once upon a time, while Steve Jobs wasn't there. In a 'perfect' world you would use an iPhone which runs a Lisp OS. Before the iPhone and before the Newton MessagePad, Apple had an ARM-based Newton-like machine with really really tiny hardware (roughly 20 Mhz ARM CPU, around 1 MB RAM, a few MB ROM) running a real Lisp OS and had it almost made a product. Almost...
It's not a problem, really, I just think it's a good idea to tell people if you're citing your own pages, in general. It's by no means awful to do so, but it's better to let people know, so they don't think that your claim is corroborated by an external source when it isn't.
If you think I have a problem with you, or something, I don't. So don't worry about it.
The source is well-known and long-time Lisper Mikel Evins who worked for Apple in various projects and also in these projects where Lisp-based operating systems were developed. Mikel has multiple times mentioning and describing this work. You even find it here on Hackernews, where he is a user. Just google for it. I see that he is even participating in this thread now.
Sorry for giving you grief over... everything, but I can't say I entirely regret it. I learned a lot that I wouldn't have otherwise, which is why I use HN in the first place.
Honestly, from the look of it, I'd like earlier versions of Dylan better than the language we ended up with. I never really liked the non-sexpr syntax. But that's just me.
The IDE was really written in CL? Huh. I'd have thought that they would have gone the self-hosting route.
The s-expression version of Dylan was my all-time favorite programming language. I've tried to be interested in the present version of Dylan, but it hasn't worked.
The first version of the OS for Newton was written in a language called Ralph (named for Ralph Ellison, the author of Invisible Man). Someone persuaded John Sculley that writing an OS in Lisp was a crazy idea, so he ordered Larry Tesler to redo it in C++. Larry asked a small group of us to see if we could find a role for Ralph on Newton. We probably took that mandate more broadly than Larry intended; we wrote another whole OS (except for the microkernel and the graphics kernel; we reused the the same ones that the C++ effort was using). It was probably the most intense and rewarding 18 months of my programming career. There were some really cool things that happened, and some really tragic ones.
Later it was decided that "Ralph" was not a good name for the language, and we chose "Dylan" in a process that yielded a few mildly funny stories.
Ralph was basically a subset of Scheme with a few special forms renamed, plus a subset of CLOS, plus a few additional extensions. All built-in Ralph datatypes were CLOS-style classes.
The native-code compiler was written in Macintosh Common Lisp. The development environment was an extended version of MCL called "Leibniz". Besides the usual MCL features, it additionally had a parallel set of tools--for example, in addition to the Lisp Listener, there was a Ralph Listener. Common Lisp code was compiled to native code and ran on the Mac's CPU. Ralph code was compiled to native code and ran on the Newton's CPU. At first the Newton motherboard was a big honking PC board jammed into a Nubus slot, so big that I had to leave the top off my Macintosh IIfx when it was installed. Later a ribbon cable connected the Nubus to a prototype Newton tablet-type device.
Making Ralph self-hosting on Newton would have been a lot more work, we would have had to live without a host of useful development features for a long time, and it would have required special target hardware with much more storage than Newton was intended to have. Using a cross-compiler written in Common Lisp neatly solved all those problems, plus it also gave us all of MCL's rather nice tools plus whatever extensions we chose to add.
Apple did do a bunch of stuff in Lisp around that time. For example, it did GATE, a knowledge-based automated testing system invented by Matt Maclaurin (I worked on that for a while), and SK8, the fabled "HyperCard on Steroids" invented by Ruben Kleiman (I worked on that for a while, too).
However, Lisp was never really a mainstream tool at Apple, except in certain groups in ATG (the Advanced Technology Group, which no longer exists). In fact, the only mainstream languages at Apple were, in rough chronological order, 6502 assembler, 68000 assembler, Pascal, C, C++, Objective-C, and now, of course, Swift. All kinds of languages were used here and there, but only the ones on the mainstream list had any great general acceptance.
Thanks for the tremendous amount of info. Now I get the lack of self-hosting.
Yeah, I'm a pretty big fan of Scheme, so I would have probably liked Ralph. We do actually have CLOS-type classes over in schemeland (although not everything is an object by default, of course) now, and by "subset of scheme," most people mean "no call/cc," which I likely wouldn't miss too much.
Ralph lacked call/cc, as you suggest. It did support upward continuations, or "exits", using a special form called bind-exit.
Scheme implementations of CLOS are much more common now than they were in 1992. The only ones I remember from around then are RScheme, Oaklisp, and of course Gregor Kiczales' tinyclos.
As far as language features, I still like Ralph the best of any language I've used, though there are things from newer languages I would want it to incorporate if it still existed today. But the actual usable language I like best today is Common Lisp.
There are a handful of other languages I like a lot--Scheme, Haskell, and ML are at the top of the list--but when I use them seriously, I miss Common Lisp. I don't miss any of them when I use Common Lisp.
I didn't miss Common Lisp or any other language when I was using Ralph.
BASIC was a product for Apple customers; as far as I know it was never a mainstream choice for writing system or application software at Apple. The first 6502 assembler I ever used was written in BASIC, but that was on a Commodore machine, not an Apple machine.
No, it's not just you. Most Lisper thought that way. But the target weren't Lisp developers, it were C++/Apple Pascal developers. Basically similar purposes which Java was designed for: general 'mainstream' application/OS developers from mobile systems upwards. Management did not think that an s-expression-based syntax would be a success with developers used to use Pascal, C and C++.
> The IDE was really written in CL? Huh. I'd have thought that they would have gone the self-hosting route.
The new language was emerging and targeting the new hardware platforms.
You can think of it that it was similar with the Playstation games from Naughty Dog - for example Crash Bandicoot. The platform for the software was the Game Object Oriented Lisp on Playstation and the development environment were desktop computers running and IDE based on Allegro Common Lisp.
The dev environment were Macs. The developers were often Lisper and Apple bought the technology and the people. Even the later product version development environment 'Newton Toolkit' was originally developed in Common Lisp.
There were stranger things then. I once saw a version of Microsoft Word for Macintosh on a developer CD, written in Common Lisp. It was a relatively sophisticated User Interface mockup. It looked like the real MS Word for Mac, but lacked much of the functionality. But when you looked at the application file on the bit level, you could see that it was a Macintosh Common Lisp runtime/image. It was written by or for Microsoft. Long ago.
I should probably look into Swift at some point, but I've never found the time, and I find languages like Rust, Go, Python, Ruby, JS, Haskell, CL, and Scheme far more compelling.
Jobs' Apple would never allow such a product. A user programmable machine for which people could release software without paying Apple a cut? Zero chance of that getting off the ground, for the same reason that Hypercard had to die.
If we limit our perspective to the duration of Jobs's lifetime, the Apple I, II, III, and the entire Macintosh line never required a tithe to Apple for releasing software. (You can argue about the cost of developer tools / the developer program for the Mac, but you'd be wrong, since (a) those were never profitable for Apple and (b) people could and did use third party development tools.)
HyperCard development floundered before Steve came back partly because of bad management decisions and partly because it required a total ground-up rewrite to bring it up to even 1988's graphic standards (it was obsolete pretty much as soon as it was released, thanks to the appearance of the Macintosh II, which supported larger screens and RGB color).
"Obsolete" is overstating it. You could do a lot with HyperCard. People did.
Apple management started talking about cutting it pretty much immediately. It didn't directly generate any revenue--Apple gave it away for free. It didn't fit into any familiar product category. It wasn't on anybody's list of must-have features. Basically, Apple management didn't understand what it was or why it existed.
Apple's programmers and other makers were an entirely different matter. They used it for all sorts of things. So did third-party developers. So did people who discovered how to make software through working with HyperCard. Projects sprouted in Apple that either extended HyperCard or implemented new software in the same spirit with expanded capabilities--but all those projects had the same problem as HyperCard: management didn't see what they were supposed to be for. Furthermore, the other projects didn't benefit from Apple management's promise to Bill Atkinson that HyperCard would be given away to Apple customers.
HyperCard's days were numbered from the beginning; that much is true. But to call it "obsolete" from the beginning misunderstands a lot.
Well, but you initially said that HyperCard "had to die", presumably because it was user-programmable. You seem to be implying that Apple had a conscious policy of opposing user programming.
That definitely was not the case at the time HyperCard was being developed. I know because I was there. I even worked on the HyperCard team for a while.
HyperCard's troubles had nothing to do with an Apple policy against user programmability, and everything to do with the fact that management couldn't figure out how to make it into a product that paid for itself.
If you want to argue that Apple has a policy against user programming now, well, maybe they do. I don't know. The last time I worked there was in the 1990s. But they didn't have any such policy when HyperCard was being shipped.
I run https://kabonky.com which does exactly that. It's more of a side project but if you find it useful and want a source it doesn't have just let me know and it's likely I'll be able to add it.
This is close to what I want, it would be nice if I could add any source, by URL, even if it means I have to go to the origin site and look for the RSS endpoint myself
