[prev] [thread] [next] [lurker] [Date index for 2005/04/23]
> Java could have been a contender, but it was crippled by targeting a > "portable" virtual machine, and by having a standard library designed by > brain-damaged monkeys on crack who threw around memory like it was free, ... and yet decided that late binding was horribly hard and ineffecient despite the fact that Smalltalk was doing it on a Z80 in 1978 and MacLisp was doing it and generating better code than Fortran in 1976. So you have all the inifficiencies of an interpreted language, all the overhead of a high level memory structure, and all the frustration of pre-object-oriented early-bound strongly-typed languages. Which is why they... > couldn't manage a damn standard, common, operation without > allocating, and destroying, half a dozen objects, ... because they have to create wrapper layers to hide the types of objects in other objects, so they get all the inefficiency of a naive implementation of late binding because there's no way for the compiler to figure out that all these things HAVE TO BE the same primitive type and it can replace a bunch of wrapper calls with an assert and raw machine code. > > I'd love to hear what you consider to be a good, high-level language, > > especially something that is compilable. I'm not saying there aren't > > any -- LISP, Scheme, and Haskell come to mind, and I've heard people > > mumble that Objective-C could be good (but again, C?) -- Modula or concurrent Euclid seem to be good intermediate-between-C-and-C++ level languages. Aleph is allegedly pretty nice, and has been used as the basis of a pretty good OS, but I've never used it. > >> 3. The implementation language is tightly bound into the API. Components > >> communicate through APIs that are written in terms of C++ classes and > >> objects. This means that any other language is going to be a second class > >> citizen to a far greater extent than in an OS like UNIX. Cocoa does this > >> too, though the late binding in Objective C mitigates it there. > > Is there any way around this problem while still using an OO language? Sure. You give each object a method with a name like "marshall" that it uses to spit out an appropriately packed (and documented) version of itself (which when you're operating in the same protection domain turns out to be a pointer to itself) and sets a flag that says it's read-only until it gets itself back from the other end, as well as a method with a name like "clone" that returns an appropriately packed copy of itself that can be passed out and discarded at the other end. Then you define the system calls in terms of marshalled objects that can be constructed without having to actually have that object in the first place. They don't actually have to be the same as the object the real object would generate, so long as you can efficiently build the object on the other side of the protection boundary. And of course if there's no protection boundary the system call turns into a library call to the routine to unpack the object, and then a method call. This can be made very efficient. > C++ carefully makes this as hard as possible, by refusing to standardise > the ABI. That's why you create the "dumb" packed form that can be passed around between implementations that have different ABIs. The real problem with all this is that in practice nobody bothers to implement a marshalling operating other than "convert to an XML string". > Whee. Because you couldn't, you know, have an application written by > someone who didn't understand threads, and crash because of this, or > block, because their "calculation" thread excluded the "display" thread > while it did something stupid for five minutes. I haven't done that. No, not me. Well, not TOO often. > That would be because designing software is hard, and GUI software is > double-hard. It requires all sorts of concurrency and asynchronous > activity, which most people do not understand in the slightest. That's why I like writing the GUI part in scripting languages that abstract the GUI away from the code that does the heavy lifting. Inefficient? Well, a little, you may need to run 50 or 100 instructions to parse a simple string when the fellow hits a menu... but remember you're ALSO making about a dozen protection boundary crossings and doing print-quality antialiased rendering of 20 short text strings and a 6-frame translucency fade to actually bring the menu up... > >> A lot of them are, yes. Garage Band documents, applications, plugins, rich > >> text documents. > > Yuck yuck yuck. Quadruple-yuck; I'd hate to explain that one to my mom. > > "Okay, so open the file up, and get the file from inside it." > > "...<thump>" Um, what? Your mom doesn't need to do any such thing. She double-clicks on the bundle and garageband opens and she only deals with Garageband. When you look inside the bundle you select "see bundle contents", and you can't tell if what you're looking at are files and directories or a virtual file system mounted automagically on the file when you selected that menu. > Seriously, if you want to talk your mom through hacking inside a > document, rather than just opening the damn thing by entering Garage > Band and selecting Open, or whatever, your would is pain anyhow. Right, it's like trying to talk your mom through HEXEDIT. > >> No, that's an app. It happens to be implemented as multiple files in a > >> common directory, but that's an application. It's no more of an > >> abstraction than a file. > > No, it's not an app. I can CD into the directory, find the actual > > executable, and run that manually. OK, now drag the code part of the app out of the folder it's in, and run it. It doesn't work. Why? because it can't find its resources. Now go to a Classic app that does the same thing with file metadata (the finder info and resource fork), and strip the metadata out, and run it. Same result. The only difference between the two models is that I can take that bundle, copy it to a BeOS system, edit the image files that make up the icons and buttons, toss it over to a Linux system, use "vi" on the plist, send it over to Windows, copy in a new copy of the code I've just downloaded from my Google mailbox, and then bring it back to Mac OS X... JUST USING THE STANDARD OS TOOLS ON EACH OS... and it'll run... WITH the changes made on the other systems. For the Classic app I have to archive it into a packed form that no standard apps on any system other than Mac OS knows how to work with, and use HEXEDIT or equivalent to tweak the bitmaps and resources, and ... no, you don't, because only rocket scientists who are happy doing things like "adb -w /dev/kmem" 5 minutes before a demo to the CEO are going to think that's easy. And they both look exactly the same to your mother.There's stuff above here
Generated at 01:00 on 03 May 2005 by mariachi 0.52