I agree - I think voice interaction needs to be at a much higher level than "Scroll Down" or "Next Workspace". I'd like something like "Open XMMS, XChat, Mozilla and Emacs on workspace 1,2,3 and 4" in addition to keyboard and mouse. A combination of both would be quite cool actually, because I could choose the most appropriate interface. Typing a letter using speech recognition, but coding with the keyboard - Surfing with the mouse, but also interacting by voice like "New tabs: freshmeat, slashdot and userfriendly".
No it doesn't. Take a look at Symbolics Genera, which is (was) the operating system of the Symbolics Lisp machines. It deviates massively from the UNIX-notion of files and character streams for everything.
You can have all those features and many more if you use a commercial Lisp implementation (the free ones have no decent IDE or GUI yet).
If you have a serious budget, take a look at Allegro Common Lisp. The other choice would be LispWorks, which is a little cheaper and without run-time fees.
They both have an excellent IDE and come with Interface Builders using CLIM, meaning your apps run under Windows, Macintosh and Unix (Motif) without a big hassle using native widgets.
Some people say Aspect Oriented Programming (AOP) comes naturally after OOP. Instead of dividing everything into classes/objects, you divide into 'concerns' and, using some formerly specified engine, weave those together to produce your code. It looks very promising, but it's 'research in progress'.
The problem lies in the CLS: Common Language Specification..NET libraries and applications can be written in a colorful mix of languages and must be able to interoperate. Interfaces tend to look a little bit differently in functional languages than in imperative ones. If I use feature X of my preferred language in my library, which isn't available in your preferred language, you won't be able to use the library how it's supposed to be used. Herein lies the difficulty: making those inter-language operations as painless as possible. It's a hard problem and while going to a lowest common denominator is surely a possibility, it surely will alienate the users of say functional languages.
Don't get too excited about this "any.NET enabled language" being able to drive GNOME. If you think about it, the number of possible languages is pretty dim (mostly C#). Why that? Because.NET must handle common interfaces across those languages. If I use a more exotic language with features not found in others (like multiple dispatch, funky lambda-lists or closures in Common Lisp) I don't think I'll be able to export Interfaces using these features. As those happen to be 'natural' to these languages, I'd have to limit myself in how I can write my applications/libraries.
I dunno, but people consider it a problem here; especially youngsters, who after drinking at a disco, end up hugging the next tree.
This shows in the laws: you may have 0.5 per mill alcohol in your blood and after that you get punished.. badly (don't let this fool you: if you have an accident and you were under this limit then you are in deep trouble). A friend of mine lost his drivers license for 2 years + 2000eur charges. Not too shabby if you ask me (he had 1.65 per mill).
Haha, I never saw this from that angle. Yes, I think it's a valid (albeit a little funny) point, but you assume that you've got a rogue coder on your team.
Let's face it: security holes are bugs, and good tests and documentation help spot them earlier. Obfuscating your code intentionally won't make your life easier:)
The article is surely right about their comment about the throw-away mentality with assignment. But there are exceptions: at my University there is a so called "Software Engineering" degree, where the emphasis is on good code with good documentation and many test-cases. Correct code only amounts to 50% of the final mark; the other half comes from documentation, comments, testcases and how well you followed the style-guide. I quite like it, because the assumption is that basically all software in todays world simply sucks.
Umph.. have you ever been in an arcade? Joysticks with knobs tend to be the rarity there. They're _much_ to delicate to handle the bashing and smashing usually found in an arcade. I cannot imagine playing say Virtua Fighter or Samurai Shodown with a knobbed joystick. I'd destroy them in no time:)
And just WHY do you need to care about how your structures are laid out in memory? Or how the calling conventions look like? Isn't the point of a high level language (which C doesn't seem to be) to abstract away such details from the programmer?
You've got a point there if you're talking about device driver development or truly performance critical code (like the rendering core in a 3d game). But WHY would I need to fiddle with such things when I'm writing a web-browser? An IRC client? A CGI script?
I certainly don't want to mess with those implementation-specific details. If those were abstracted properly away, you wouldn't need such clutches like configure.
I was always under the impression that a vendor supplied compiler would almost always out-perform a generic cross-compiler, which is available on much more other platforms. GCC is all fine and dandy, but it's it shines in other aspects than pure optimization and fast code (they may be faster on some architectures than the vendor supplied compiler, but that's not my point). The produced code x86 was always sub-optimal. Because of that, projects like pgcc exist(ed).
Lisp doesn't need to be slow at all. You're thinking of the old 70's Lisp, which was usually interpreted and ran slowly. Today's Lisp implementations can also be compiled in addition interpreted, which results in a big performance boost (lagging only slightly behind C, but faster then Java). Commercial Lisps capable of compiling are for example Allegro CL and LispWorks.
This isn't limited to the commercial ones: CMUCL and SBCL do also compile to native code. The compilers are optimizing (you can choose between variying degrees of Speed, Safety, Debugability and Compile Speed) and you can even enter Assembler code or disassemble single expressions.
Sophos Anti-Virus warns about a new virus, which infects other files as a macromedia flash movie
and executes self-generated programs. The parasite, baptized "SWF/LFM-926", reaches computers as
SWF-file, and after being run, infects other Flash movies while displaying the message
"Loading Flash-Movie...". The virus exploits the scriptability of Macromedia Flash to generate a
file V.COM, which gets executed afterwards without confirmation.
Sophos says that the virus wasn't yet spotted "in the wild" and therefore spreading. Nevertheless,
the manufacturer of Antivirus software warns about the potential danger which lurks in the
Flash format. The Sophos website provides detailed information about the parasite.
GUID doesn't mean "Global User ID" but "Globally Unique IDentifier" and is used to identify unique things like Classes, Devices and such. They can be used to identify specific things, but they weren't made for that. sheesh, not everything's there to invade your privacy..
I did that, but it locked up HARD. That's because the code from the ports drm-kmod and the ports xf86 had some mismatch. This should probably work with XF86 4.2.0. Take a look here. The maintainer confirmed it too.
I've tried FreeBSD for 3 months. So I'm only talking about things, that I've personally encountered. I've emailed the drm-kmod maintainer regarding DRI support with a G400 and got the response, that you currently need CVS XF86. I've asked about the rear channel on -QUESTIONS, and got the response, that it isn't supported.
I wasn't bashing FreeBSD as a whole and just pointed out some flaws. There is enough stuff that FreeBSD got 'right', but after my experience with it, I find these "Linux is crap" unjustified.
But of course: because it isn't supported in FreeBSD it OBVIOUSLY isn't needed and unimportant. Who in their right mind would use them anyway, right? Must be some Linux weenies who should use Windows anyway.
Sure, but what if you have a G400 and want 3D acceleration? Bad luck, it (currently) doesn't work without CVS XF86.
What if you want to hear something on your rear speakers with an emu10k1? Bad luck, it isn't supported.
In fact, the drivers for "desktop" hardware like soundcards, 3d accelerators and such are HORRIBLE in FreeBSD when comparing with Linux. FreeBSD may be the better server OS, but it surely is an inferior desktop OS.
So please stop with this "awww.. Linux is sooo shitty when compared to the almighty FreeBSD" crap.
And why exactly would you want so set the mouse position? I don't want any program to control my cursor, because it can get VERY confusing and annoying. Playing with the input device of the user is a major UI sin if you ask me.
I'd say thats the reason, why Apple didn't include such functionality into the API.
Slashdot Mirror
I agree - I think voice interaction needs to be at a much higher level than "Scroll Down" or "Next Workspace". I'd like something like "Open XMMS, XChat, Mozilla and Emacs on workspace 1,2,3 and 4" in addition to keyboard and mouse. A combination of both would be quite cool actually, because I could choose the most appropriate interface. Typing a letter using speech recognition, but coding with the keyboard - Surfing with the mouse, but also interacting by voice like "New tabs: freshmeat, slashdot and userfriendly".
No it doesn't. Take a look at Symbolics Genera, which is (was) the operating system of the Symbolics Lisp machines. It deviates massively from the UNIX-notion of files and character streams for everything.
You can have all those features and many more if you use a commercial Lisp implementation (the free ones have no decent IDE or GUI yet).
If you have a serious budget, take a look at Allegro Common Lisp. The other choice would be LispWorks, which is a little cheaper and without run-time fees.
They both have an excellent IDE and come with Interface Builders using CLIM, meaning your apps run under Windows, Macintosh and Unix (Motif) without a big hassle using native widgets.
Some people say Aspect Oriented Programming (AOP) comes naturally after OOP. Instead of dividing everything into classes/objects, you divide into 'concerns' and, using some formerly specified engine, weave those together to produce your code. It looks very promising, but it's 'research in progress'.
The problem lies in the CLS: Common Language Specification. .NET libraries and applications can be written in a colorful mix of languages and must be able to interoperate. Interfaces tend to look a little bit differently in functional languages than in imperative ones. If I use feature X of my preferred language in my library, which isn't available in your preferred language, you won't be able to use the library how it's supposed to be used. Herein lies the difficulty: making those inter-language operations as painless as possible. It's a hard problem and while going to a lowest common denominator is surely a possibility, it surely will alienate the users of say functional languages.
Don't get too excited about this "any .NET enabled language" being able to drive GNOME. If you think about it, the number of possible languages is pretty dim (mostly C#). Why that? Because .NET must handle common interfaces across those languages. If I use a more exotic language with features not found in others (like multiple dispatch, funky lambda-lists or closures in Common Lisp) I don't think I'll be able to export Interfaces using these features. As those happen to be 'natural' to these languages, I'd have to limit myself in how I can write my applications/libraries.
.NET is far from being the perfect solution.
I dunno, but people consider it a problem here; especially youngsters, who after drinking at a disco, end up hugging the next tree.
This shows in the laws: you may have 0.5 per mill alcohol in your blood and after that you get punished.. badly (don't let this fool you: if you have an accident and you were under this limit then you are in deep trouble). A friend of mine lost his drivers license for 2 years + 2000eur charges. Not too shabby if you ask me (he had 1.65 per mill).
Haha, I never saw this from that angle. Yes, I think it's a valid (albeit a little funny) point, but you assume that you've got a rogue coder on your team. :)
Let's face it: security holes are bugs, and good tests and documentation help spot them earlier. Obfuscating your code intentionally won't make your life easier
The article is surely right about their comment about the throw-away mentality with assignment. But there are exceptions: at my University there is a so called "Software Engineering" degree, where the emphasis is on good code with good documentation and many test-cases. Correct code only amounts to 50% of the final mark; the other half comes from documentation, comments, testcases and how well you followed the style-guide. I quite like it, because the assumption is that basically all software in todays world simply sucks.
Try Sonya Keene's book: Object Oriented Programming in Common Lisp. It's a VERY good resource for CLOS programming.
arrgh forget it.. i mistranslated "knob" to "knopf" in german which means "button". duh, you're right of course. sorry
Umph.. have you ever been in an arcade? Joysticks with knobs tend to be the rarity there. They're _much_ to delicate to handle the bashing and smashing usually found in an arcade. I cannot imagine playing say Virtua Fighter or Samurai Shodown with a knobbed joystick. I'd destroy them in no time :)
And just WHY do you need to care about how your structures are laid out in memory? Or how the calling conventions look like? Isn't the point of a high level language (which C doesn't seem to be) to abstract away such details from the programmer?
You've got a point there if you're talking about device driver development or truly performance critical code (like the rendering core in a 3d game). But WHY would I need to fiddle with such things when I'm writing a web-browser? An IRC client? A CGI script?
I certainly don't want to mess with those implementation-specific details. If those were abstracted properly away, you wouldn't need such clutches like configure.
I was always under the impression that a vendor supplied compiler would almost always out-perform a generic cross-compiler, which is available on much more other platforms. GCC is all fine and dandy, but it's it shines in other aspects than pure optimization and fast code (they may be faster on some architectures than the vendor supplied compiler, but that's not my point). The produced code x86 was always sub-optimal. Because of that, projects like pgcc exist(ed).
and your point is?
Lisp doesn't need to be slow at all. You're thinking of the old 70's Lisp, which was usually interpreted and ran slowly. Today's Lisp implementations can also be compiled in addition interpreted, which results in a big performance boost (lagging only slightly behind C, but faster then Java). Commercial Lisps capable of compiling are for example Allegro CL and LispWorks.
This isn't limited to the commercial ones: CMUCL and SBCL do also compile to native code. The compilers are optimizing (you can choose between variying degrees of Speed, Safety, Debugability and Compile Speed) and you can even enter Assembler code or disassemble single expressions.
Sophos Anti-Virus warns about a new virus, which infects other files as a macromedia flash movie
and executes self-generated programs. The parasite, baptized "SWF/LFM-926", reaches computers as
SWF-file, and after being run, infects other Flash movies while displaying the message
"Loading Flash-Movie...". The virus exploits the scriptability of Macromedia Flash to generate a
file V.COM, which gets executed afterwards without confirmation.
Sophos says that the virus wasn't yet spotted "in the wild" and therefore spreading. Nevertheless,
the manufacturer of Antivirus software warns about the potential danger which lurks in the
Flash format. The Sophos website provides detailed information about the parasite.
GUID doesn't mean "Global User ID" but "Globally Unique IDentifier" and is used to identify unique things like Classes, Devices and such. They can be used to identify specific things, but they weren't made for that. sheesh, not everything's there to invade your privacy..
I did that, but it locked up HARD. That's because the code from the ports drm-kmod and the ports xf86 had some mismatch. This should probably work with XF86 4.2.0. Take a look here. The maintainer confirmed it too.
I've tried FreeBSD for 3 months. So I'm only talking about things, that I've personally encountered. I've emailed the drm-kmod maintainer regarding DRI support with a G400 and got the response, that you currently need CVS XF86. I've asked about the rear channel on -QUESTIONS, and got the response, that it isn't supported.
I wasn't bashing FreeBSD as a whole and just pointed out some flaws. There is enough stuff that FreeBSD got 'right', but after my experience with it, I find these "Linux is crap" unjustified.
But of course: because it isn't supported in FreeBSD it OBVIOUSLY isn't needed and unimportant. Who in their right mind would use them anyway, right? Must be some Linux weenies who should use Windows anyway.
Sure, but what if you have a G400 and want 3D acceleration? Bad luck, it (currently) doesn't work without CVS XF86.
What if you want to hear something on your rear speakers with an emu10k1? Bad luck, it isn't supported.
In fact, the drivers for "desktop" hardware like soundcards, 3d accelerators and such are HORRIBLE in FreeBSD when comparing with Linux. FreeBSD may be the better server OS, but it surely is an inferior desktop OS.
So please stop with this "awww.. Linux is sooo shitty when compared to the almighty FreeBSD" crap.
But - Prove that the compiler/interpreter has no such flaws and by induction all programs written with it are free from such flaws.
Because OS X inherited from NeXTSTEP and that in turn used Objective C. Why fix what ain't broken?
And why exactly would you want so set the mouse position? I don't want any program to control my cursor, because it can get VERY confusing and annoying. Playing with the input device of the user is a major UI sin if you ask me.
I'd say thats the reason, why Apple didn't include such functionality into the API.