...and using a struct where it really doesn't belong is a "trick."
Re:Rule 1 of Efficient Lisp: Lisp is not functiona
on
Common Lisp: Inside Sabre
·
· Score: 3, Interesting
Uh... Scheme isn't a toy. It doesn't have the super-expansive libraries of Common Lisp, but it's used in real world applications all the time. Hell, a month or so back, Transmeta posted to comp.lang.lisp, looking for someone to continue working on some huge Scheme app that they used for design.
> Tail-recursion is nice, but macros like LOOP
> with the extended syntax are quite powerful. I
> would say that Common Lisp is better at iteration than
> most other languages.
I totally agree. The LOOP macro isn't just a way to do for, while, and foreach like we find in most primitive languages- LOOP is an entire language in and of itself. Immensely powerful.
Contrary to what most C people think, performance is very dependent on what you're doing and how it was designed. I've seen some benchmarks where a well designed compiled Common Lisp program beat out a well designed FORTRAN program for heavy duty number munching. I wish I could find that bleeding link again!
It's called LispOS. Unfortunately, an open source LispOS is quite vaporware. In the meantime, have a look at Squeak Smalltalk , which supports all the features of a modern-day Lisp and then some, with the exception of real macros. Squeak itself is basically an operating system that is hosted by a number of other OSes, including Mac OS 9/X, Windows, Linux, and a bazillion others. In addition to that, Squeak runs bare on a x86.
To an extreme extent. But the level of partially source-level compatible is not conveniently quantifiable. If you knew anything Cocoa, OpenStep, and GNUstep, that statement would make a lot more sense.:)
I think pliant (the language) did what you're talking about. Also, my project, DynaPad , which strives to create a dynamic and consistent PDA operating environment may use Linux as it's kernel, mostly to cannabilize drivers. The nature of Squeak is such that it can be run on top of any OS, but the Linux kernel may be a convenient base. It's completely unlike a Unix environment.
But those NeXTish interfaces are nothing but cheap, inconsistent, hodgepodge jobs. They aren't like NeXT anymore than GTK+ with a shitty Aqua theme is Mac OS X. At this point, GNUstep doesn't have as many apps as Xt, Athena, GNOME/GTK+ or KDE/QT have. This distro is striving to give the *STEP experience, not provide just another crappy and bloated skinned desktop.
Objective-C++ doesn't allow you to use C++ syntax to program in Obj-C, nor does it allow you to use the Objective-C runtime and syntax to instantiate and send messages to C++ objects, nor does it allow you to use C++ to instantiate and send messages to Objective-C classes and objects.
What it does allow you to do is mix Objective-C and C++ in the same source file, using C++ syntax to deal with C++ classes and objects, and the Obj-C runtime/syntax to deal with Obj-C classes and objects. They're still quite seperated. However, I don't imagine it would be hard to have an automated conversion process going. The only real blocking point on that one is the static and opaque nature of C++, where Objective-C is dynamic and reflective enough to allow such tricks.
Too true. A NeXT look without the consistency or feel (no matter your skin, GTK+ apps always end up inconsistent!) is like putting lipstick on Bugs Bunny to make a beautiful woman. However, GNUsteps goal isn't just to implement the OpenStep API. It's also to create a usable set of applications that mimic the look, feel, and huge usability of the NeXT environment.
NeXTSTEP: Not the hardware, but the original OS made by NeXT. Versions 0.3 - 3.3.
The NeXT cube, NeXT Turbo Cube, NeXT Station, NeXT Color Station, NeXT Turbo Station, and NeXT Color Turbo Station are the names of the computers NeXT sold.
OpenStep: The OpenStep API was a bit different than the original NeXTSTEP API. The "open" part of the moniker denotes that it was an open API spec, and OpenStep followed this spec. This allows for other implementations to happen, like GNUstep or OpenStep for Solaris. Versions 4.0 - 4.2.
Yes, I did say OpenStep for Solaris. There was also an OpenStep Enterprise for Windows. OpenStep for Solaris allowed you to run an OpenStep environment and related apps on top of X11, rather like GNUstep does. It ran it's own OpenStep window manager, but still allowed vanilla X apps.
OSE for Win32 was the OpenStep API for Windows, allowing one to develop and run OpenStep apps on Windows. While it didn't change the shell/wm like in OS/Solaris, you could run OpenStep apps remotely, including the Dock and WorkSpace.app- which was pretty cool to see. The widgets were given a bit more of a Windows look.
Rhapsody: Wasn't dropped entirely, as you say. The original Rhapsody vision was dropped, but Rhapsody was released as Mac OS X Server 1.x. Mac OS X Server 2.0 is based on Mac OS X 10.0, however.
Did they release that finally? From what I've read, it's pretty cool. I've been dying to have a look at it. AppleScript is way too verbose, trying too hard to be like English for my tastes. But if it will let me hack together quick GUIs and script Cocoa objects, it'll be more than what I could want!
Another great thing about AS is that it supports SOAP pretty slicklike. With the intrinsic SOAP support, I could throw together a GUI and some other AS functions, and call the more intensive logic of the app written in another language that supports SOAP.
Apple's GCC support ObjC++, meaning you can mix Objective-C and C++ code in the same application. However, you cannot call/instantiate Objective-C classes, objects, and methods from C++, just have both languages in the same sources.
I for one am glad Apple stuck with ObjC. It's good to see that at least one company has the balls to choose what is good rather than what is popular. I was scared for a little while- Apple made WO5 Java only, and I'm glad they didn't pull that on Mac OS X as well.
As far as other languages, you can program OS X in a bunch of them. Quite a few languages have Carbon bindings, and there's no reason you couldn't write a binding for you favorite language- Carbon is just C. If you're already using another language, you don't really need a binding to Cocoa, rather than Carbon.
I agree. I got a big kit from the ADC about Mac OS X development (it's good to be the president of your local ACM chapter [yO! Uni of MN Duluth!]), which contained Learning Cocoa.
Not sure why anyone would spend the almost $40 cover price for this book- seemed to have the same content as the Learning Objective-C PDF that Apple has on their site!
At least I got a few posters with the class hierarchy on them.:)
Objective-C adds very little actual syntax to C, whereas C++ adds a whole bunch. C++ is the kludge to end all kludges, Objective-C does is far better. Have you ever done a project in Objective-C, or are you just another slashkiddie talking out his ass?
Slashdot Mirror
...and using a struct where it really doesn't belong is a "trick."
Uh... Scheme isn't a toy. It doesn't have the super-expansive libraries of Common Lisp, but it's used in real world applications all the time. Hell, a month or so back, Transmeta posted to comp.lang.lisp, looking for someone to continue working on some huge Scheme app that they used for design.
> Tail-recursion is nice, but macros like LOOP
> with the extended syntax are quite powerful. I
> would say that Common Lisp is better at iteration than
> most other languages.
I totally agree. The LOOP macro isn't just a way to do for, while, and foreach like we find in most primitive languages- LOOP is an entire language in and of itself. Immensely powerful.
Contrary to what most C people think, performance is very dependent on what you're doing and how it was designed. I've seen some benchmarks where a well designed compiled Common Lisp program beat out a well designed FORTRAN program for heavy duty number munching. I wish I could find that bleeding link again!
OS X does *not* use DPS. NeXTSTEP, OpenStep, Rhapsody, and Mac OS X Server 1.x used DPS, but Mac OS X uses Quartz, which is more-or-less Display PDF.
It's called LispOS. Unfortunately, an open source LispOS is quite vaporware. In the meantime, have a look at Squeak Smalltalk , which supports all the features of a modern-day Lisp and then some, with the exception of real macros. Squeak itself is basically an operating system that is hosted by a number of other OSes, including Mac OS 9/X, Windows, Linux, and a bazillion others. In addition to that, Squeak runs bare on a x86.
To an extreme extent. But the level of partially source-level compatible is not conveniently quantifiable. If you knew anything Cocoa, OpenStep, and GNUstep, that statement would make a lot more sense. :)
And having a three-letter acronym starting with a "K" as your handle, you'd think it has something to do with that KKK organization.
I think pliant (the language) did what you're talking about. Also, my project, DynaPad , which strives to create a dynamic and consistent PDA operating environment may use Linux as it's kernel, mostly to cannabilize drivers. The nature of Squeak is such that it can be run on top of any OS, but the Linux kernel may be a convenient base. It's completely unlike a Unix environment.
Man, why not replace it with Rhapsody DR2? A bit slicker than DR1.
But those NeXTish interfaces are nothing but cheap, inconsistent, hodgepodge jobs. They aren't like NeXT anymore than GTK+ with a shitty Aqua theme is Mac OS X. At this point, GNUstep doesn't have as many apps as Xt, Athena, GNOME/GTK+ or KDE/QT have. This distro is striving to give the *STEP experience, not provide just another crappy and bloated skinned desktop.
I run my Mac without fans, without risking meltdown or *underclocking* it! Wow, what well designed technology can do these days!
Objective-C++ doesn't allow you to use C++ syntax to program in Obj-C, nor does it allow you to use the Objective-C runtime and syntax to instantiate and send messages to C++ objects, nor does it allow you to use C++ to instantiate and send messages to Objective-C classes and objects.
What it does allow you to do is mix Objective-C and C++ in the same source file, using C++ syntax to deal with C++ classes and objects, and the Obj-C runtime/syntax to deal with Obj-C classes and objects. They're still quite seperated. However, I don't imagine it would be hard to have an automated conversion process going. The only real blocking point on that one is the static and opaque nature of C++, where Objective-C is dynamic and reflective enough to allow such tricks.
What is BEoS? Is that like mAX OHSeX?
Hell, you can stil get the older iMacs new from Apple for $799!
Too true. A NeXT look without the consistency or feel (no matter your skin, GTK+ apps always end up inconsistent!) is like putting lipstick on Bugs Bunny to make a beautiful woman. However, GNUsteps goal isn't just to implement the OpenStep API. It's also to create a usable set of applications that mimic the look, feel, and huge usability of the NeXT environment.
Close... but not quite.
NeXTSTEP: Not the hardware, but the original OS made by NeXT. Versions 0.3 - 3.3.
The NeXT cube, NeXT Turbo Cube, NeXT Station, NeXT Color Station, NeXT Turbo Station, and NeXT Color Turbo Station are the names of the computers NeXT sold.
OpenStep: The OpenStep API was a bit different than the original NeXTSTEP API. The "open" part of the moniker denotes that it was an open API spec, and OpenStep followed this spec. This allows for other implementations to happen, like GNUstep or OpenStep for Solaris. Versions 4.0 - 4.2.
Yes, I did say OpenStep for Solaris. There was also an OpenStep Enterprise for Windows. OpenStep for Solaris allowed you to run an OpenStep environment and related apps on top of X11, rather like GNUstep does. It ran it's own OpenStep window manager, but still allowed vanilla X apps.
OSE for Win32 was the OpenStep API for Windows, allowing one to develop and run OpenStep apps on Windows. While it didn't change the shell/wm like in OS/Solaris, you could run OpenStep apps remotely, including the Dock and WorkSpace.app- which was pretty cool to see. The widgets were given a bit more of a Windows look.
Rhapsody: Wasn't dropped entirely, as you say. The original Rhapsody vision was dropped, but Rhapsody was released as Mac OS X Server 1.x. Mac OS X Server 2.0 is based on Mac OS X 10.0, however.
Midwest ACM recognize!@$! ;)
Did they release that finally? From what I've read, it's pretty cool. I've been dying to have a look at it. AppleScript is way too verbose, trying too hard to be like English for my tastes. But if it will let me hack together quick GUIs and script Cocoa objects, it'll be more than what I could want!
Another great thing about AS is that it supports SOAP pretty slicklike. With the intrinsic SOAP support, I could throw together a GUI and some other AS functions, and call the more intensive logic of the app written in another language that supports SOAP.
Is there still active work being done on this? I've been wanting this since my NeXTSTEP days!
Amen! I curse the day Bjarne was born, unleashing the mass of retards which attack us!
I'm not talking about that MacLisp. Apple developed a Lisp IDE that eventually became Macintosh Common Lisp (MCL), a kickass CL environment.
http://www.digitool.com
Apple's GCC support ObjC++, meaning you can mix Objective-C and C++ code in the same application. However, you cannot call/instantiate Objective-C classes, objects, and methods from C++, just have both languages in the same sources.
I for one am glad Apple stuck with ObjC. It's good to see that at least one company has the balls to choose what is good rather than what is popular. I was scared for a little while- Apple made WO5 Java only, and I'm glad they didn't pull that on Mac OS X as well.
As far as other languages, you can program OS X in a bunch of them. Quite a few languages have Carbon bindings, and there's no reason you couldn't write a binding for you favorite language- Carbon is just C. If you're already using another language, you don't really need a binding to Cocoa, rather than Carbon.
Python, and F-Script both have Cocoa bridges.
I agree. I got a big kit from the ADC about Mac OS X development (it's good to be the president of your local ACM chapter [yO! Uni of MN Duluth!]), which contained Learning Cocoa.
:)
Not sure why anyone would spend the almost $40 cover price for this book- seemed to have the same content as the Learning Objective-C PDF that Apple has on their site!
At least I got a few posters with the class hierarchy on them.
Objective-C adds very little actual syntax to C, whereas C++ adds a whole bunch. C++ is the kludge to end all kludges, Objective-C does is far better. Have you ever done a project in Objective-C, or are you just another slashkiddie talking out his ass?