Indeed, an option "Interpret this document as if it were of mime type..." would be tremendously useful in lots of other contexts. Especially in situations where some clever admin decided to send you source code as application/x-c-source or whatever, and I just want to read it in the browser, some way to tell it "this is text/plain, dammit!" would make the world a less annoying place.
The solution is called SoFiNet (from the Dutch "social-fiscal number", popularized as "sofinummer"; US citizens may just like refer to it as SSNet).
You should seriously consider finding another acronym before offering that in germany...
The idea is that you resolve people's PC's not by their Internet address, not by their domain names, but by the Social Security Number of their users. This is also ideal for applications like Instant Messaging, personal email, etc.
But I have several computers, and only one social security number. I have one server at a large hoster that handles web and mail for me, and a few desktops at home where I would want to use IM on.
Perhaps even more severe, many german students don't have their social security number yet, because you only get it when you need it, i.e. when you have you first job that is "Sozialversicherungpflichtig" (many students jobs are not). How would that be handled? (No flame intended, I seriously want to know)
We have that here in the US, but it's not used by actual people. It's used primarily by telemarketing scum to find your number and call you at dinner time to sell you crap you don't want.
Sounds a lot like DNS to me. Unless you've run your own mail server, you wouldn't believe how much spam you get at any plausible-sounding-name@whatever.domain.in.any.tld
Hell, my desktop FreeBSD box has half of RedHat 7.2 installed for linux compat, including rpm and other evils. I bet packaging is the least of his concerns.
Funny, someone with a remarkably similar, yet different name hacked something called WorldWideWeb.app on his NeXTStation some decades after the internet went gold. Coincidence? You decide!
There is a difference between running in a JVM and being able to interoperate with Java classes, just like you cannot automatically use C functions just because your language compiles to the same binary code. Not all of these languages allow you to use System.out.println, or create a JTree object, even if I admit after a second sight that more seem to allow this than I initially thought.
Re:For payback (not gnome?? what??)
on
Sun's Last Stand
·
· Score: 1
You can bet that usability, or even eye candy, is not the reason they chose Gnome over KDE - otherwise they would hardly still stay with CDE. My guess is that they simply find the idea that writers of commercial solaris software would have to pay license fees to another company distasteful.
(OK, that's enough to prove I'm a SmugLispWeenie, I guess...;-)
But they're basically just lists, that's all. So you have this wonderful flexibility, but the parse tree doesn't actually tell you very much about the program; you have to "parse the parse tree" to recognize higher-level constructs.
No. You can parse the parse tree to reason about or modify programs. You can as well use higher-level constructs, for example asking for the class of an object and manipulate it, the declared types of variables and functions, etc. The whole metaobject protocol is about giving you an object-oriented interface to your program internals, and the same style shows in various other places. Basically, a lot of what is lost at compile-time in most other languages is a live first-class object in Lisp - for a simple example, you can get the package of a symbol, see what other packages it imports, change its name, and make some symbols in it not being exported.
Moral: Lisp is very, very, very cool, but it has not already done everything every other language is doing. So yes, it may sound familiar from you Lisp book, but it's not the same.
Indeed. But Lisp is the only language so far that allowed adding new concepts in portable ways, without having to modify the underlying implementation. CLOS, the object system, is basically a bunch of functions and macros, and if you don't like its class/generic-function based approach, just load a package that implements a prototype-based one and use that. An implementation of Eiffel-style design by contract is about two screenful of code, adding final and abstract classes is less.
Are these additions "language-level constructs"?
Hard to tell. The syntax the programmer deals with is just as if it were, even if everything eventually gets expressed in lower-level terms. The distinction is just not meaningful in Lisp - there just is no hard barrier between the language designer and the user, Lisp users design their language all the time.
Maybe in another 10 or 20 years ALL programming languages will be as powerful as Lisp.
Actually, the other languages do make progress in that direction. Look, for example, at Python: It has objects, metaclasses, introspection, an interactive environment, functions as data (even if lambdas could've been done better), strong dynamic typing, runtime extensibility (albeit clumsy), not to mention small conveniences like keyword and rest args or docstrings.
I could imagine that, 10 or 20 years from now, it will also have the missing pieces, like fast compilers, a decent exception/condition system (I want restarts, dammit!) and an extensible syntax (i.e. proper macros), although the latter might be hard. It will then be as good as Common Lisp is at least scince it's become an ANSI standard in 1994.
I doubt that XML will be an issue at that time, however. At least right now it seems that current W3C activities make a lot of people look back to the ease and consistency of SGML.
Other than that, your code looks pretty darn much like your average C++ application. You can use the STL, ATL or just about any C++ library that is compatible with VC++.
But how many of these 165 languages are really integrated with Java, as opposed to merly using the same bytecode representation? I.e. how many of these languages allow you to use Java libraries, and use libraries written in them in Java? Looks way worse then.
That said,.NET is not as language-agnostic as MS would want you to believe. Basically, all languages can be ported to.NET as long as they are sufficiently similar to C#. Note that, for example, "Managed C++" is something very different from C++, and there are lots of rants on the web of people who tried to port languages like Scheme or even Python to it - it can work, but it might end up very inefficient, or with substantial changes to the language.
However, I don't think that this is really that bad - the idea of using libraries with different languages isn't that good in the first place, IMHO. A good library for Lisp would certainly look very different than a good VB library, with a very different interface. Tying yourself to language independence will lead to least-common-denominator quality code, not everybody is satisfied with that.
Wrong. Everybody who knows what Unix is knows the Open Group, because the Open Group defines what Unix is.
Of course, most people who think they know what Unix is have something like "something like Linux, but obsolete" in mind. These are probably the same people that couldn't write a half-way portable shell script if their life depended on it, because they wouldn't even know where to look for the relevant standards.
Apple saying that OS X is Unix-based is, of course, fully OK, and not the thing that is debated here. Just like it is OK to say that Linux is "Unix-like". That's not the point.
And you not having a clue may not be the best argument either, by the way.
Being "derived from Unix" is very different from being Unix. Windows XP is, in a way, derived from VMS, yet calling it "a VMS" is rubbish.
Basically, to be a Unix, you have to (a) implement the Single Unix Specification, and (b) to pay license fees to the Open Group. Neither Apple nor the FreeNixes pay license fees to the Open Group, pay for Single Unix conformance testing, or fully implement it (due to some parts being inconsistent or plain stupid), so they are not Unix. It's that simple. And, for all intents and purposes, it doesn't matter at all.
Oh, it's about static languages. Never mind.
Indeed, an option "Interpret this document as if it were of mime type ..." would be tremendously useful in lots of other contexts. Especially in situations where some clever admin decided to send you source code as application/x-c-source or whatever, and I just want to read it in the browser, some way to tell it "this is text/plain, dammit!" would make the world a less annoying place.
Huh? The author can always do that. He isn't bound by the license terms under which he allows others to use his work.
You should seriously consider finding another acronym before offering that in germany...
But I have several computers, and only one social security number. I have one server at a large hoster that handles web and mail for me, and a few desktops at home where I would want to use IM on.
Perhaps even more severe, many german students don't have their social security number yet, because you only get it when you need it, i.e. when you have you first job that is "Sozialversicherungpflichtig" (many students jobs are not). How would that be handled? (No flame intended, I seriously want to know)
Who said you can loose these games?
Hell, my desktop FreeBSD box has half of RedHat 7.2 installed for linux compat, including rpm and other evils. I bet packaging is the least of his concerns.
Funny, someone with a remarkably similar, yet different name hacked something called WorldWideWeb.app on his NeXTStation some decades after the internet went gold. Coincidence? You decide!
Catbert.
There is a difference between running in a JVM and being able to interoperate with Java classes, just like you cannot automatically use C functions just because your language compiles to the same binary code. Not all of these languages allow you to use System.out.println, or create a JTree object, even if I admit after a second sight that more seem to allow this than I initially thought.
You can bet that usability, or even eye candy, is not the reason they chose Gnome over KDE - otherwise they would hardly still stay with CDE. My guess is that they simply find the idea that writers of commercial solaris software would have to pay license fees to another company distasteful.
(OK, that's enough to prove I'm a SmugLispWeenie, I guess ... ;-)
No. You can parse the parse tree to reason about or modify programs. You can as well use higher-level constructs, for example asking for the class of an object and manipulate it, the declared types of variables and functions, etc. The whole metaobject protocol is about giving you an object-oriented interface to your program internals, and the same style shows in various other places. Basically, a lot of what is lost at compile-time in most other languages is a live first-class object in Lisp - for a simple example, you can get the package of a symbol, see what other packages it imports, change its name, and make some symbols in it not being exported. Indeed. But Lisp is the only language so far that allowed adding new concepts in portable ways, without having to modify the underlying implementation. CLOS, the object system, is basically a bunch of functions and macros, and if you don't like its class/generic-function based approach, just load a package that implements a prototype-based one and use that. An implementation of Eiffel-style design by contract is about two screenful of code, adding final and abstract classes is less.Are these additions "language-level constructs"? Hard to tell. The syntax the programmer deals with is just as if it were, even if everything eventually gets expressed in lower-level terms. The distinction is just not meaningful in Lisp - there just is no hard barrier between the language designer and the user, Lisp users design their language all the time.
I could imagine that, 10 or 20 years from now, it will also have the missing pieces, like fast compilers, a decent exception/condition system (I want restarts, dammit!) and an extensible syntax (i.e. proper macros), although the latter might be hard. It will then be as good as Common Lisp is at least scince it's become an ANSI standard in 1994.
I doubt that XML will be an issue at that time, however. At least right now it seems that current W3C activities make a lot of people look back to the ease and consistency of SGML.
(PROG ()
10 (PRINT "HELLO")
20 (GO 10))
That said, .NET is not as language-agnostic as MS would want you to believe. Basically, all languages can be ported to .NET as long as they are sufficiently similar to C#. Note that, for example, "Managed C++" is something very different from C++, and there are lots of rants on the web of people who tried to port languages like Scheme or even Python to it - it can work, but it might end up very inefficient, or with substantial changes to the language.
However, I don't think that this is really that bad - the idea of using libraries with different languages isn't that good in the first place, IMHO. A good library for Lisp would certainly look very different than a good VB library, with a very different interface. Tying yourself to language independence will lead to least-common-denominator quality code, not everybody is satisfied with that.
OK, that might addmittedly not be for the same audience as a 64-bit powerbook, but still... drool indeed!
Of course, most people who think they know what Unix is have something like "something like Linux, but obsolete" in mind. These are probably the same people that couldn't write a half-way portable shell script if their life depended on it, because they wouldn't even know where to look for the relevant standards.
Apple saying that OS X is Unix-based is, of course, fully OK, and not the thing that is debated here. Just like it is OK to say that Linux is "Unix-like". That's not the point.
And you not having a clue may not be the best argument either, by the way.
Basically, to be a Unix, you have to (a) implement the Single Unix Specification, and (b) to pay license fees to the Open Group. Neither Apple nor the FreeNixes pay license fees to the Open Group, pay for Single Unix conformance testing, or fully implement it (due to some parts being inconsistent or plain stupid), so they are not Unix. It's that simple. And, for all intents and purposes, it doesn't matter at all.