Disclaimer: I've used Smalltalk for about a year, but haven't used Cocoa that much (except for toy projects). Here's my take:
You can think of Smalltalk as a simplified Objective-C, say a "script" version (even though the evolution happened in the opposite order). So, there are no types in your code; there's no reference counting garbage collection to worry about, no header files - no files at all in fact. There are no protocols, no categories or poseAs: (although the latter two aren't really needed, since you can simply replace the class in the image or add to it). The equivalent of writing a category on NSObject, say, is just to add methods to the Object class. forwardInvocation, sure, Smalltalk has doesNotUnderstand:.
One of the nicest features of Smalltalk, which I really miss in Objective-C, is blocks. You can put any code in brackets and have it be sent as an argument to a function. Blocks can take arguments, so they can be used for iteration (collection do: [:each | each doSomething]) - or for storing actions, which Objective-C usually does with selectors (i.e. when you're doing something in IB). And there's no compilation; you interact with and change your code and objects while they're running. That's probably the best performance enhancement there is.
There is a version of Objective-C with blocks, called POC (http://www.ibiblio.org/pub/Linux/devel/lang/objc/ !INDEX.html). I don't know how (or if) it's compatible with Apple's compiler though.
Programming Cocoa in Smalltalk would absolutely rock. For applications that aren't hugely performance-sensitive, it would be far superior to things like REALbasic. The GUI frameworks of the versions of Smalltalk I've used (VisualWorks and Squeak) tend to be a bit rough around the edges; whereas NeXT stuff has been more carefully designed and evolved. Apparently there are some nicer frameworks for VisualAge Smalltalk, but I've never used them.
Part of my problem is, after using Smalltalk, a lot like using the Mac, it's really hard to go back to something else. You just start to notice how complicated, inelegant, downright SLOW developing in another language is. Having to keep all your data structures in your head, guessing how they'll respond to something while you're writing code, is such a pain - when in Smalltalk, you just send the objects messages, see what happens, and when you have something that works, just put it in your code! (Granted this is not unique to Smalltalk, you can do it in any language with the appropriate runtime support, it's just that with Smalltalk it's all there to start with.)
Maybe if/when IBM makes a split keyboard I'll consider it, but I can't use anything less than an IBM keyboard with those oh-so-wonderful keys. I think I get at least
another 20% speed just because of the key feel.
IBM did make a split, adjustable keyboard. I'm typing on it now. It's Part # 13H6689, the one I'm using was manufactured in September 1995. Standard PS/2, with that great IBM feel, and an adjustable split.
Might be able to pick up one used. It's substantially relieved my hand pain, when other weirder keyboards (e.g. Kinesis) didn't. --
Oh, and I've never used it since! It doesn't understand Perl too well;)
CodeWarrior 5 has Perl scripting support on Windows and Mac (dunno about Solaris/Linux).
(Yes, I know this isn't what you were asking about.:-) For most of my projects, it's been the reverse - I've done them in CodeWarrior on a Mac rather than the university's official [pick command-line tool] on Solaris. The number of people who sit and wait for javac to run on an Ultra1 amazes me (jikes, anyone?)... not to mention those who don't use makefiles and other convenience methods, but retype the same commands OVER and OVER again. For me, I hate messing with them, so I just use an IDE for most tasks and plug scripting in when I need it (Perl, AppleScript, etc.) --
i personally think the $5000 and theimac should go to whoever manages to finally come out with some HFS+ support for linux/BSD.:P
*shrug* HFS+ filesystem support is opensource, in Darwin now, that's about as much help as I think people should need. --
Re:My 2.something cents CDN
on
MacOS X DP3
·
· Score: 1
Unfortunately, it's not enough like NeXTstep---there's a fair list of things which NeXT users will be giving up...
In small part, I agree. As a 14-year Mac user, it seems the designers of OS X don't quite grok some basic interface concepts that Mac users take for granted. Reading various NeXT users' posts on mailing lists, it appears that a lot of really cool NeXT features were broken by designers who didn't understand them either.
So, I wonder, if the designers have little Mac experience, and little NeXT experience, no wonder OS X is so confused!
I haven't used OS X DP3, I'm not under NDA for that; what I have used is Mac OS X Server, and Mac OS 8/9.
So, to respond:
no top-level print, hide or quit
The Application menu (the one at the top left corner of the screen, that has the current application's icon on it) contains hide and quit commands. Print is really better document-centric, rather than application-centric; it stays in the File menu.
no built-in faxing and file saving at the print panel - under OPENSTEP I never have to waste time picking printers from the chooser or control strip, or going in to page setup to set the destination to file
The traditional Mac OS has had this in various incarnations. QuickDraw GX was the best; you could switch from any one printer to any other from the Print dialog box, and the Print dialog box was nonmodal, and contained collapsed and expanded versions, printing plugins that would work with multiple drivers (anyone remember Pierce Print Tools?), and lots of really cool stuff.
Unfortunately, GX is dead. Apple has tried to do the best they can by improving the traditional LaserWriter 8.x driver. There's now a popup menu for Printer/File (and in earlier versions, Fax for PostScript fax printers), and a popup menu to change between PostScript printers without having to go to the Chooser/Control Strip/Finder.
In OS X, there will be a 'save as file' - both to PostScript and PDF directly from any application.
no rich set of clients for Services
Services will be accessible from Cocoa apps, and will continue to exist in OS X. I don't know about Carbon; it's probably like most Cocoa features, you can get em from Carbon if you use a Mach-O executable format (and give up running on classic Mac OS), but not if you use PEF/CFM packaging.
no Shelf
Well, you do have the Desktop. I sure hope there's a decent analog to popup folders though; the Dock wastes a lot of screen space.
Pantone color libraries---the latter was especially nice since all NeXT apps use the same color panel
The Mac OS has supported a standardized Color Picker since the very first color Mac. The Color Picker 2.0 and later support plugin pickers, such as the very cool crayon picker. ColorSync comes with a Pantone picker... so I don't think you'll be losing this. I don't know if there will be any integration between the (modal) color picker dialogs and the NeXT style drag&drop color panel for Cocoa apps.
save status in window close button---the greyed out proxies don't show up in a torn-off window menu
Not to mention that a black dot in the middle of that red lozenge would look stupid.:-) It'd be perfectly possible to display window proxy icons, including grayed-out ones, in the window menu, and I think it's more useful. Even NeXT used window proxies, such as for file icons in Project Builder.
Anyway, I really hope all the stuff in DP3 gets cleaned up - right now the interface looks like they just assigned a whole lot of people to port whatever was there to OS X, and not really do any designing or rethinking. They seem to have kept the Network control panel exactly as is in OS X Server - a bad design if I've ever seen one.
The derivation of "corolla" is as a diminutive form of corona. I am guessing this is its most likely origin (since the Corolla was a smaller car than the Toyota Corona that once was sold).
Main Entry: co*rol*la Etymology: New Latin, from Latin, diminutive of corona
My vote for worst Toyota car name is a rebranded Holden that I've only seen in Australia: Toyota Lexcen. Ugh.
About the "Ford Excessive": There was an humorous article in the New York Times a while ago, in which a whole series of Fords increasing in size, with complementary names beginning with E, were suggested. Excessive and Extravagance were two I remember. I just did a search of their archives, it appears to be from March 6, 1999, titled "Big Wheels", though I'm certainly not paying $2.50 to find out. --
Of course it sucks. It does help sometimes though. I installed sshd and cygwin on our NT boxen, which makes things somewhat usable from remotely. I haven't been able to get anything fullscreen to work though (don't know if it's possible; when I need an editor, I usually just share the appropriate directories and smbmount them from a linux box, then edit the files with my favorite editor). --
1. I'm not a Mac user, and don't care for the Symantec interface. Maybe there's no correlation between their Mac work and their interface, but I found their interface inconvenient. Other users with different habits will have the opposite opinion.
Definitely not related.:-) I'm a Mac user and I like JBuilder the best of the Windows Java IDEs (except for the editor...). Symantec's interface is just not very productively arranged.
Cafe crashes a lot more than the other two you mention, for me. It also doesn't deal well with large projects, even on a 256MB 450MHz PII with plenty of disk space.
VisualAge requires I import a lot of the external classes I use, which bloats the repository; the GUI designer creates literally hundreds of classes for a reasonably complex layout, making it virtually unusable; and it also has zero integration with external version control.
JBuilder's code browser is nice, visual designer the best of a bad bunch, and it's pretty fast if you ignore the memory usage.
CodeWarrior's editor is pretty decent and the class browser, diff tool, and build support rock, but its debugger isn't anywhere as nice as JBuilder's, and it has no visual interface designer. I'll be interested to see the Java RAD stuff and improved debugger in Pro5. So for now I write mostly in CodeWarrior, except if I'm doing a lot of AWT/Swing stuff in which case I use JBuilder, and debug in JBuilder. Not the best... sigh. --
Slashdot Mirror
Disclaimer: I've used Smalltalk for about a year, but haven't used Cocoa that much (except for toy projects). Here's my take:
:each | each doSomething]) - or for storing actions, which Objective-C usually does with selectors (i.e. when you're doing something in IB). And there's no compilation; you interact with and change your code and objects while they're running. That's probably the best performance enhancement there is.
/ !INDEX.html). I don't know how (or if) it's compatible with Apple's compiler though.
:-(
You can think of Smalltalk as a simplified Objective-C, say a "script" version (even though the evolution happened in the opposite order). So, there are no types in your code; there's no reference counting garbage collection to worry about, no header files - no files at all in fact. There are no protocols, no categories or poseAs: (although the latter two aren't really needed, since you can simply replace the class in the image or add to it). The equivalent of writing a category on NSObject, say, is just to add methods to the Object class. forwardInvocation, sure, Smalltalk has doesNotUnderstand:.
One of the nicest features of Smalltalk, which I really miss in Objective-C, is blocks. You can put any code in brackets and have it be sent as an argument to a function. Blocks can take arguments, so they can be used for iteration (collection do: [
There is a version of Objective-C with blocks, called POC (http://www.ibiblio.org/pub/Linux/devel/lang/objc
Programming Cocoa in Smalltalk would absolutely rock. For applications that aren't hugely performance-sensitive, it would be far superior to things like REALbasic. The GUI frameworks of the versions of Smalltalk I've used (VisualWorks and Squeak) tend to be a bit rough around the edges; whereas NeXT stuff has been more carefully designed and evolved. Apparently there are some nicer frameworks for VisualAge Smalltalk, but I've never used them.
Part of my problem is, after using Smalltalk, a lot like using the Mac, it's really hard to go back to something else. You just start to notice how complicated, inelegant, downright SLOW developing in another language is. Having to keep all your data structures in your head, guessing how they'll respond to something while you're writing code, is such a pain - when in Smalltalk, you just send the objects messages, see what happens, and when you have something that works, just put it in your code! (Granted this is not unique to Smalltalk, you can do it in any language with the appropriate runtime support, it's just that with Smalltalk it's all there to start with.)
And sorry, I've never used CLOS or OCAML
--
IBM did make a split, adjustable keyboard. I'm typing on it now. It's Part # 13H6689, the one I'm using was manufactured in September 1995. Standard PS/2, with that great IBM feel, and an adjustable split.
Might be able to pick up one used. It's substantially relieved my hand pain, when other weirder keyboards (e.g. Kinesis) didn't.
--
CodeWarrior 5 has Perl scripting support on Windows and Mac (dunno about Solaris/Linux).
(Yes, I know this isn't what you were asking about. :-) For most of my projects, it's been the reverse - I've done them in CodeWarrior on a Mac rather than the university's official [pick command-line tool] on Solaris. The number of people who sit and wait for javac to run on an Ultra1 amazes me (jikes, anyone?)... not to mention those who don't use makefiles and other convenience methods, but retype the same commands OVER and OVER again. For me, I hate messing with them, so I just use an IDE for most tasks and plug scripting in when I need it (Perl, AppleScript, etc.)
--
Newton OS? It's the most consistently usable, reasonably widespread commercial OS I've used.
There were many aspects that contributed to its death, but "lack of ease of use" sure wasn't one of them.
(Very) early efforts to port the Newton to free software is available at www.gnuton.com.
--
I can't normally run DVD player because i have macsbug installed and rebooting just for that seems kind of silly
The nice guys at Bare Bones came up with a fix... "DVD Player Helper" which you can download from http://www.barebones.com/free/free.html .
Apple does have a perfectly working MPEG-2 decoder in the Apple DVD player, but that won't run files off the hard drive
It's not perfect, but there is a software MPEG-2 player available for the Mac available at: http://fred.elma.fr/Soft_DVD/Soft_DVD.ht ml.
i personally think the $5000 and theimac should go to whoever manages to finally come out with some HFS+ support for linux/BSD. :P
*shrug* HFS+ filesystem support is opensource, in Darwin now, that's about as much help as I think people should need.
--
In small part, I agree. As a 14-year Mac user, it seems the designers of OS X don't quite grok some basic interface concepts that Mac users take for granted. Reading various NeXT users' posts on mailing lists, it appears that a lot of really cool NeXT features were broken by designers who didn't understand them either.
So, I wonder, if the designers have little Mac experience, and little NeXT experience, no wonder OS X is so confused!
I haven't used OS X DP3, I'm not under NDA for that; what I have used is Mac OS X Server, and Mac OS 8/9.
So, to respond:
no top-level print, hide or quit
no built-in faxing and file saving at the print panel - under OPENSTEP I never have to waste time picking printers from the chooser or control strip, or going in to page setup to set the destination to file no rich set of clients for Services no Shelf Pantone color libraries---the latter was especially nice since all NeXT apps use the same color panel save status in window close button---the greyed out proxies don't show up in a torn-off window menu Anyway, I really hope all the stuff in DP3 gets cleaned up - right now the interface looks like they just assigned a whole lot of people to port whatever was there to OS X, and not really do any designing or rethinking. They seem to have kept the Network control panel exactly as is in OS X Server - a bad design if I've ever seen one.Here's hoping...
--
Main Entry: co*rol*la
Etymology: New Latin, from Latin, diminutive of corona
My vote for worst Toyota car name is a rebranded Holden that I've only seen in Australia: Toyota Lexcen. Ugh.
About the "Ford Excessive": There was an humorous article in the New York Times a while ago, in which a whole series of Fords increasing in size, with complementary names beginning with E, were suggested. Excessive and Extravagance were two I remember. I just did a search of their archives, it appears to be from March 6, 1999, titled "Big Wheels", though I'm certainly not paying $2.50 to find out.
--
Of course it sucks. It does help sometimes though. I installed sshd and cygwin on our NT boxen, which makes things somewhat usable from remotely. I haven't been able to get anything fullscreen to work though (don't know if it's possible; when I need an editor, I usually just share the appropriate directories and smbmount them from a linux box, then edit the files with my favorite editor).
--
Definitely not related. :-) I'm a Mac user and I like JBuilder the best of the Windows Java IDEs (except for the editor...). Symantec's interface is just not very productively arranged.
Cafe crashes a lot more than the other two you mention, for me. It also doesn't deal well with large projects, even on a 256MB 450MHz PII with plenty of disk space.
VisualAge requires I import a lot of the external classes I use, which bloats the repository; the GUI designer creates literally hundreds of classes for a reasonably complex layout, making it virtually unusable; and it also has zero integration with external version control.
JBuilder's code browser is nice, visual designer the best of a bad bunch, and it's pretty fast if you ignore the memory usage.
CodeWarrior's editor is pretty decent and the class browser, diff tool, and build support rock, but its debugger isn't anywhere as nice as JBuilder's, and it has no visual interface designer. I'll be interested to see the Java RAD stuff and improved debugger in Pro5. So for now I write mostly in CodeWarrior, except if I'm doing a lot of AWT/Swing stuff in which case I use JBuilder, and debug in JBuilder. Not the best... sigh.
--