Did you ever notice that, when you fire up a new XEmacs tetris, the shapes always come in the same order (The random number generator must be seeded with the same number everytime). Damn, I started to memorize half of the play until I realized that.
So, make sure you always hold down the 'n'-key for a while to make sure you'r not always playing the same game.
> The only thing XML will do if widely used for
> configuration files is make maintaining them
> harder for those who'd like to do that by using
> shell scripts or simple text editors.
> As a very basic example, using XML makes
> configuration files harder to grep.
Obviously, you would have some standard XML tools. There are, for example, grep-like tools for XML. In fact, I guess this will make maintaining the scripts easier, since such tool take the actual document structure into account.
Anyway, thank you for pointing out that XML is not the magic solution (can't say this too often). Though in this case it might help to simplify things as you would only need one set of tools to deal with all config files.
Your points are valid, but note also that objects in the JVM (and presumably.NET) are heavier than neccessary, thus making the allocation of new objects more costly. (The problem being that (higher-order) functions are often compiled to classes, which is clearly to heavyweight)
Quoting from Meeham,Joy:"Compiling Lazy Functional Programs to Java Bytecode":
Wakeling ascribed the poor performance of his compiler when compared to Hugs to the poor memory handling in the JVM, hypothesising that memory-allocation in Java is an order of magnitude more expensive than in Hugs. Functional programs will create and destroy objects on a more frequent basis than an imperative object-oriented one...
Anyway, it's good to see that these problems are addressed by someone at MSR. Hope it really finds its way to.NET.
> As far as I understand the issue is a performance one.
Yes, the problems seem similar to the attempts to compile functional languages (e.g. Haskell or ML) to the JVM.
Functional languages have a lot of very short lived objects (functions that are evaluated) without identity and local storage.
The JVM (and.NET) are designed primarily for object oriented langages having long(er) lived objects with identity and storage.
It's this mismatch that makes it hard to use functional languages *efficiently* with.NET.
Anywat, I really love to see the people at MS addressing this problem. But after all, GHC, *the* Haskell compiler is being developed at MS research.
> Just wanted to remind you that deciding at
> compile time if a given program will go wrong
> (division by zero, memory faults, infinite loops)
> or not is an undecidable problem
Good point, but nevertheless a type-checker can do a fair bit for you. That's why people programming in staticly typed languages, such as ML or Haskell, rarely ever (need to) use a debugger.
In my opinion we should let the machine do as much as possible.
> I generally don't like internal type-checking
> within a language, because it results in
> slowness, and some los of power
What they use here is static type checking at compile time. The type information is thrown away before running, since the type-checker has already proved that nothing bad can happen...
Hence, your program will rather be faster than slower.
> Shouldn't the word digit in this case be a trigit?
> Since the very word digit is prefaced with di which means two?
> I guess I could be wrong about that...
Yep, you are wrong:-) (Doesn't make sense for ordinary base-10 digits...)
The word digit comes from the latin digitus meaning finger.
Now, I don't want to know what trigitus means in latin...
> The truth is, the Brits didn't really fight for
> 30 years against the IRA. They just mucked
> around like the U.S. did against terrorism for
> the past 20 years.
So what should they have done? Bomb Ireland back to stone age?
You just don't get it, do you? It is plainly impossible to "eradicate terrorism". That is, unless you eradicate mankind. Oh wait...you'r about to take the first step...
> Perl, Python, TCL, Scheme, REBOL, and Lisp can't > "segfault" either
You missed the point. Obviously, C or C++ cannot segfault when run in an interpreter.
> a strong object-oriented type system which
> ensures that the vast majority of coding errors
> result in a type error (although it can take a
> little while to get used to Haskell's type system);
Yes, Haskell has a strong type system that finds many errors at compile-time. This is IMHO one of THE arguments why YOU(yes you) should use Haskell. It will make your programs better. But the type-system is not object-oriented. It uses type-classes to provide a way for overloading in the type-system. See this paper, for example.
BTW. Did you know that, because of this type system, Haskell programs cannot segfault.?
Slashdot Mirror
> Hire Google to overhaul the USPTO prior art database.
Or, hire Microsoft to wreck^H^H^H^H^H maintain the entire USPTO database.
Did you ever notice that, when you fire up a new XEmacs tetris, the shapes always come in the same order (The random number generator must be seeded with the same number everytime).
Damn, I started to memorize half of the play until I realized that.
So, make sure you always hold down the 'n'-key for a while to make sure you'r not always playing the same game.
>In my experience, you just can't hide the under-the-hood stuff
What about MacOS X?
Anyway, I guess it would be a good idea to put BeOS (the UI that is) on top of GNU/Linux. But who am I to tell anyone what to do?
> And where is that snobby professor now? "Dunno" you say? That's what I frickin thought.
:-)
I think it's Andrew Tanenbaum and he is Amsterdam now, as far as I can see on his homepage
``Repetition is a form of change''
Now, that's what I call an appropriate fortune entry . Or are these slogans hand-selected by a Swarm of Orange Mummies, after all?
> The only thing XML will do if widely used for
> configuration files is make maintaining them
> harder for those who'd like to do that by using
> shell scripts or simple text editors.
> As a very basic example, using XML makes
> configuration files harder to grep.
Obviously, you would have some standard XML tools. There are, for example, grep-like tools for XML. In fact, I guess this will make maintaining the scripts easier, since such tool take the actual document structure into account.
Anyway, thank you for pointing out that XML is not the magic solution (can't say this too often). Though in this case it might help to simplify things as you would only need one set of tools to deal with all config files.
Your points are valid, but note also that objects in the JVM (and presumably .NET) are heavier than neccessary, thus making the allocation of new objects more costly. (The problem being that (higher-order) functions are often compiled to classes, which is clearly to heavyweight)
...
.NET.
Quoting from Meeham,Joy:"Compiling Lazy Functional Programs to Java Bytecode":
Wakeling ascribed the poor performance of his compiler when compared to Hugs to the poor memory handling in the JVM, hypothesising that memory-allocation in Java is an order of magnitude more expensive than in Hugs. Functional programs will create and destroy objects on a more frequent basis than an imperative object-oriented one
Anyway, it's good to see that these problems are addressed by someone at MSR. Hope it really finds its way to
Too bad I can't anymore.
> As far as I understand the issue is a performance one.
.NET) are designed primarily for object oriented langages having long(er) lived objects with identity and storage.
.NET.
Yes, the problems seem similar to the attempts to compile functional languages (e.g. Haskell or ML) to the JVM.
Functional languages have a lot of very short lived objects (functions that are evaluated) without identity and local storage.
The JVM (and
It's this mismatch that makes it hard to use functional languages *efficiently* with
Anywat, I really love to see the people at MS addressing this problem. But after all, GHC, *the* Haskell compiler is being developed at MS research.
...you have just lost your most important having-worked-on-this-for-years file, which will obviously be lost forever.
> The site appears intact for now
/.ed.
Great, now it's
> Just wanted to remind you that deciding at
> compile time if a given program will go wrong
> (division by zero, memory faults, infinite loops)
> or not is an undecidable problem
Good point, but nevertheless a type-checker can do a fair bit for you. That's why people programming in staticly typed languages, such as ML or Haskell, rarely ever (need to) use a debugger.
In my opinion we should let the machine do as much as possible.
> I generally don't like internal type-checking
> within a language, because it results in
> slowness, and some los of power
What they use here is static type checking at compile time. The type information is thrown away before running, since the type-checker has already proved that nothing bad can happen...
Hence, your program will rather be faster than slower.
> Shouldn't the word digit in this case be a trigit? :-) (Doesn't make sense for ordinary base-10 digits...)
> Since the very word digit is prefaced with di which means two?
> I guess I could be wrong about that...
Yep, you are wrong
The word digit comes from the latin digitus meaning finger.
Now, I don't want to know what trigitus means in latin...
Maybe he is running his web-server under Linux in a VMWARE emulation in his emulated XP...
...it's about 149 597 870 kilometers away.
...for food.
For your information:
This comment is lame. It violates the postercomment compression filter.
> The truth is, the Brits didn't really fight for
> 30 years against the IRA. They just mucked
> around like the U.S. did against terrorism for
> the past 20 years.
So what should they have done? Bomb Ireland back to stone age?
You just don't get it, do you? It is plainly impossible to "eradicate terrorism". That is, unless you eradicate mankind. Oh wait...you'r about to take the first step...
MFC is like having sex while wearing 7 condoms.
...and they are on various fingers and toes, not where they are supposed to be.
...and all of them have small annoying holes.
> Perl, Python, TCL, Scheme, REBOL, and Lisp can't > "segfault" either
You missed the point. Obviously, C or C++ cannot segfault when run in an interpreter.
> a strong object-oriented type system which
> ensures that the vast majority of coding errors
> result in a type error (although it can take a
> little while to get used to Haskell's type system);
Yes, Haskell has a strong type system that finds many errors at compile-time. This is IMHO one of THE arguments why YOU(yes you) should use Haskell. It will make your programs better. But the type-system is not object-oriented. It uses type-classes to provide a way for overloading in the type-system. See this paper, for example.
BTW. Did you know that, because of this type system, Haskell programs cannot segfault.?
onqueror?
If only programming would be explained in terms of calculus, our programs would be so much better!
It was bought by Spiegel-Online, a german online news service.
The announcement is here (in German - try the babelfish version).
www.BoycottAdobe.com is made with GoLive!