Linux version 3.2.12-himp (buildmaster@hulk.build.redhat.com) (gcc version 6.41) #1 SMP Wed Nov 14 13:43:25 EST 2013
then we'll have something like:
4096 CPUs available, 131072 CPUs total Registering legacy COM port for serial console
Then the kernel will bring up the cores in question:
Total of 65536 processors activated (10299381.81 BogoMIPS). Processor redundancy driver claimed 32768 processors Warning: At least 32768 CPUs have failed the Heisenberg locality test
Finally, the panic itself will start with something like:
Oops: IRQ782 mapped to CPU 28311, already mapped to CPU 828 , check subspace coupling!!! swapper[4]: General Exception: Unmapped interrupt vector 0x8800, 48 [1] Pid: 4, CPU 6645, comm: swapper psr : 00001010085a6000 ifs : 800000046810cc18 ip : [a000000100008c40] Not tainted ip is at start_kernel_thread+0x0/0x40
Of course, we'll need bigger screen to display the whole series of stack traces (like 32768 processors trying to dump garbage on the console at the same time...) But apart from that, I don't think that multicore panics are going to be much of a problem.
This looks neat and very promising, but I don't think it's background free, is it? This is based on page 2, "The building blocks of the standard model and gravity are fields over a four dimensional base manifold. I think there remains an unanswered question regarding what "x" means in the equations. And you can derive some stuff trying to answer that question. Just 2 cents.
Meanwhile, from the source of the web site: <meta name="Generator" content="iWeb 1.1.2"/>. I thougth this had quite a familiar look, it looks quite a lot like the web site I made with iWeb myself... Except I did not remove the "made on a Mac" logo to please the zealots.
One big difference between UAC and "sudo" or the MacOSX security dialog is that UAC does not ask for a password. Minor convenience (well, probably serious convenience given how frequently UAC pops up today), but major risk. I can leave my Mac or Linux box to someone that does not know the password, without instantly making him / her an administrator on my machine. The same is not true with Vista + UAC.
In fact, approximating FP values for 3D code is so common that the 3DNow and SSE instruction sets contain instructions that approximate the square root and inverse square root to about half of single-precision floating point. That's also the only way to compute it on Itanium: you have to iterate using the floating-point reciprocal square root approximation instruction. There is no instruction giving you the final result.
Really? I remember playing 3D Starstrike, a real 3D wireframe Star Wars ripoff released in 1985. In 1986 we had Starstrike II, now in solid, flat lit 3D. Had to wait a few more years before texturing became viable. Most games of the time (practically all of them flight or space simulators) were displaying 3D on quarter or half screens. The games you refer to were no exception. As an aside, the 8-bit variants were generally displaying a single shaded object at a time, others being wireframe. Another trick was to display scaled sprites (most car racing games were doing that).
It may seem like a small thing today, but filling the screen with flat-shaded 3D graphics gave a much more immersive experience that had a serious "wow" factor at the time. I still remember the Infogrames guy staying in front of the computer playing my demo for maybe two hours straight, amazed at how fluid it was. Infogrames knew all about the games of the time, and they knew of nothing like it. Now, maybe there was a game they did not know about, I've always been curious.
Of course, two years later, everybody was doing it. Though the particular gameplay remains somewhat unique to this day, and good enough that my kids still ask me to play it from time to time, swithing away from today's ultra-realist 3D...
There are simply too many different possibilities for there to be one reasonable guess. You can use shifts and adds, but that's rarely faster than the hardware, and at that time pipelining usually wasn't very useful. Table lookups of various sorts were fairly common, frequently with some bit-masking or -shifting to keep the table size reasonable.
Well, that's why I gave the source code.
Anyway, the answer was: the engine was pre-computing 3 axis vectors. That required a few mulitplications. Then, it would add them to create vectors like 1Z, 2Z, 3Z, 1X, 2X, 3X. Finally, all objects were defined using displacements like 1X 2Z -1Y and so on. As a result, the final rendering was done with practically only additions. If memory serves me right, there were only about 6 multiplications per object. That trick, and a very optimized polygon-filling routine, allowed Alpha Waves to display about 10-20 frames per second full screen of 3D graphics on a 8MHz 16-bit CPU. As I wrote in the parent post, I believe it was the first game to ever do that (3D games at the time typically displayed quarter-frame graphics, or full-screen vector graphics).
How did it compute sine and cosines?
CORDIC?
Don't be silly! CORDIC is a floating-point algorithm.
The answer was that angles were represented using 256 units for a rotation, which allowed a byte indexing in a table (with an offseting by 64 to select between sin and cos). Each entry in the table was between +/-32767. Multiplying that by a 16-bit coordinate would give a 32-bit value. Shifting the value down 15 times was not an option, since the 68K did not have a barrel shifter, so that would have been slow. Instead, I used the "swap" instruction, that swapped the high and low half of a 32-bit word. So the computation multiplied by sin(x)/2, not by sin(x), and I had to correct for that. As a matter of fact, it was not even exactly sin(x), because 32767 / 65536 is not exactly 0.5...
Since you haven't even specified what hardware it was for, attempting to guess at the low-level hardware trick(s) you used would be pretty pointless.
I did give enough pointers to answer the question. Of course, that means you are curious enough to actually follow a link. The original source code was for Atari ST. The hardware trick I referred to was that there were 16 registers to change the color palette. Using an interrupt, I was changing the color palette in the middle of the screen, so that the "top" and the "bottom" half of the screen could show users that were in different rooms, because the "mood" of each room was given by a different color palette.
The palette-changing trick was relatively frequently used at the time. What made it useful for performance tuning was that you could change the screen border color on entry to a routine, and change it again on exit, and the height of the color band on the side of the screen would tell you how much time you spent in the routine.
I believe Alpha Waves was the first video game on personal computers with full-screen "real" 3D (i.e. not scaled sprites), and I also believe it was the first 3D game with two simultaneous players sharing a screen. Would anybody have data to confirm or infirm that?
"infirm" ? Do you mean "deny", perhaps?
Probably
It wasn't the first game on a personal computer with real 3D -- I wrote some real 3D code that ran on a C64 around 1982 or '83. OTOH, the "ran" there is an exaggeration -- "walked" would be closer, and "stumbled" would probably be the right word. The code was all right, but there's only so much you can do on an 8-bit, 1 MHz processor. A couple of us played it enough to say it worked, but that's about it. Oh, it would also depend a bit on what you're talking about as 3D -- this was wireframes only. I wrote some lighting code, but never used it except to cre
>> How did that engine avoid multiplications? > Creative bit shifts and additions?
That would still be multiplications by another name. And by the way, on a 68K, shifting left N bits took a time proportional to N.
>>How did it compute sine and cosines? > lookup tables?
Yeah, right. OK, there was a lookup table somewhere, that much is obvious. But I guess I should rephrase the question as: how do you compute a rotation efficiently using only integer arithmetic?
>> What low-level hardware trick did it use in two-player mode, and how could that be used for performance tuning? > Eh? need more info, or do I need to look at the links to understand the question
Of course, where would the reverse engineering fun be?
Back around 1990, I wrote a game called Alpha Waves (Preview). Back then, the problem was not using integers to approximate floating point math, it was avoiding integer multiplications, because those were expensive compared to additions. For those of you with a curious mind, you can take a look at http://cc3d.free.fr/cube.s for the original source code.
So here is a quizz, the first one answering wins the admiration of the crowd:
- How did that engine avoid multiplications?
- How did it compute sine and cosines?
- What low-level hardware trick did it use in two-player mode, and how could that be used for performance tuning?
I believe Alpha Waves was the first video game on personal computers with full-screen "real" 3D (i.e. not scaled sprites), and I also believe it was the first 3D game with two simultaneous players sharing a screen. Would anybody have data to confirm or infirm that?
And what about setting up counter-attacks after city-sized alien spaceships have destroyed our satellites and other means of communication? Of course, Independance Day is behind us, so we are safe for _this_ year...
From a concept-programming standpoint, LitWindow seems to be a sort of hacked-together meta-programming language for GUIs. The concepts are good, but the implementation is sorely limited by the language they use (C++).
For instance, their data adapter are the poor's man meta-program generating useful reflective data from a data structure. You actually need to duplicate the description of the data structure, precisely because this is not a _real_ meta-program, but only a clever hack using the C preprocessor...
Now, what if you had a real way to extend the language as you need it, rather than this crude hack? Wouldn't it be cool if the data adapters could be generated automagically?
That's quite simple. Your understanding of how calculators do it seems to be wrong. Nothing that I know of creates a derived equation and uses that. They use numerical methods that make use of the original equation to compute the derivative.
The HP-48 calculator or Mathematica both do the thing that "nothing you know of" does. We could also discuss why the numerical approach may be incorrect.
Well, if you want a pure OO maximum, rather than a Java maximum, then there would be a maximum method on a collection.
You obviously have not read my definition of a concept cast. A concept cast is when you cannot represent a concept, and use some alternate concept in its place. It's very insidious, and most people don't even realize when it happens.
In your case, you replaced the concept of maximum of N elements with the concept of a collection containing N elements. They are close, but not identical. As a result, semantic noise is introduced, for instance boxing and unboxing, or built-in memory management for lists (it depends on a particular implementation).
There is not enough innovation either in C# nor in Java, and what is there is often not implemented in the best possible way.
Generics (C# 2.0 already supports this)
Both Java and C# generic are quite limited, compared to C++ templates. And they are easier to use with expression reduction, since you can give them a nice-to-use form.
Enhanced For-Loop (the foreach construct in C# 1.0, duh!)
Autoboxing/Unboxing (C# 1.0 already has this, everything is an object, even the primitives - not really, but they do it so well...)
Autoboxing means you have boxing in the first place, which means your language doesn't support stack object. Nothing to be proud of. And _auto_boxing is only a form of implicit conversion. In XL, any implicit conversion can be implemented using expression reduction.
Typesafe Enums (again C# 1.0 already implemented this, but I think they've added a little bit more twist in Java, that its actually a better implementation)
Ooooh! Enums! Innovation!
Varargs (C# 1.0's params construct, ellipsis construct in C++)
Static Import (I don't know if C# 1.0 has this, or C#2.0, but C# has a construct for aliasing your imports - which is way cooler. Static Import, actually promotes bad coding habits IMHO)
Yes. (XL had import aliasing for a while, see examples above...)
Metadata/Annotations (this is C# 1.0's Attributes, Sun's upturned noses just gave it a fancier name - also, C#'s implementation is better and more intuitive)
What you really want is metaprogramming, to actually enhance the language as you go.
Reinventing a clone of python? XL has very little in common with Python, except the indent-based syntax. There's not much that Python can do that can't be done better with other languages. In other words, it's mostly syntactic sugar on well-known concepts. XL, on the other hand, introduces several powerful ideas, and does a few important things better than existing languages I know of.
Can you summarize in clear terms what the difference between concept programming and object-oriented design is?
There's very little in common, except for the fact that they are both software methodologies:-) From a CP point of view, OO is an approach which models a rather large range of concepts represented as "verb + noun", where verbs are represented as methods, and nouns as objects. For instance, "window.draw()". There are some concepts that OO has trouble with, because they have no easy "verb + noun" representation. For instance, computing a maximum the OO way is tricky. In Java, you'd typically resort to a non-OO static method for that. See http://mozart-dev.sourceforge.net/cp-vs-oo.html for a more detailed discussion.
Also, what exactly make XL a concept programming language? It looks somewhere between Haskell, Ruby, and a simple procedural language to me.
As to what makes XL a concept programming language, it's extensibility combined with readability. That it looks like a simple procedural language is by design. It would not be CP if it could not represent old concepts the usual way. It's under the hood that it's really different. And you see when you start manipulating non-standard concepts, for instance a simple plug-in allows you to manipulate symbolic differential forms in your source code. You can't do that as easily, if at all, with any of the languages you listed.
Concept programming is an approach to programming that I hope will yield improvements in quality. If your code is structured like what it represents, then it's easier to understand and maintain. This simple idea yields interesting metrics, and highlights issues that are a bit hard to spot otherwise.
Over time, I became convinced that a new language was actually necessary to implement concept programming correctly. It turns out that some of the tools developed for XL help many other things (like documentation, good interfaces, automated tools, etc).
Slashdot is a good way to attract readers... Why would it be OK to promote open-source software releases and not interesting non-open-source ones?
Well, now that I think about it, let me take the opportunity to talk about XL, the future of programming. XAML is so passe, you know. This Xamlon act is the proof that it's no longer interesting: there is an implementation that works.
No such problem with XL. It's a real, true to geek do-it-yourself futureware. Complete with almost-but-not-quite-working source code. So if you are unhappy about these folks talking about real stuff available today, why don't you stop ranting and contribute so that we can get back to talking about stuff that doesn't exist yet:-)
Meta-programming is much more powerful, with the ability to actually change the program, not just attach data to it. The XL programming language is designed around that idea. And open-source too. Hint: I'm always looking for contributors to help.
Yet another story about calculators. When HP launched the 10 series (HP10C, HP11C, HP12C, HP15C, HP16C), it started with a 1 year warranty. Then 2 years. Then 5 years. Then lifetime. And then, they started giving them away for free with practically every kind of high-end gear they sold. "Buy a cartridge of ink, and get an HP-15 for free", that was their marketing at the time.
Someone at HP told me that the reason was that HP always built a fixed percentage of additional machines for support. They'd never try to fix a calculator, they'd simply replace it. Except that the 10's never died. Ever. So the support stock started piling up... and up...
Well, again, I don't know if this is true. The following, however, I know is true, because this is personal experience. I once lost an HP-15C on a road while biking. I heard the noise, and went back to look for it. I didn't see it right away, and I ran right over it. It still works to that day.
My brother had an HP-28. He was working on some sort of fun, long-running math program, which he debugged while cleaning up something. Some slashdotters probably know the feeling. Well, he heads for lunch, and mistakenly pushes the running HP-28 in the water. Needless to say, he's rather alarmed when he comes back and sees the poor HP-28 underwater. But the calculator still ran fine, running the program happily. I don't know if that qualifies as watercooling... It turns out HP had made it totally waterproof.
OK, yet another story. I had a 48 later (you can still find a few programs I wrote out there). At one point, I noticed that you could switch the calculator on with the batteries out. It would run for a short moment (maybe 5-10 seconds max). So I decided to know how little electricity it used. It took me a 6-digit ampere-meter to figure out. Off the top of my head, it was in the 50 micro-amps range.
This can't be true. Didn't you hear that story of the HP support person getting a call from a customer with a broken PC.
Support rep: "OK, switch your PC on, and tell me what happens".
Customer: "There's smoke coming from the hole on the right side".
Support rep: "Hole? Which hole? This model doesn't have a hole on the right side"
Customer: "Well, it's broken now since it fell downstairs. That's why I called you".
Support rep: "Are you telling me that you are calling because your PC doesn't work after falling downstairs?"
Customer: "Yes"
Support rep: "I'm sorry, I'm afraid this is not covered by your support contract".
Customer: "What? Why not? My HP calculator fell a number of times, and it still works!"
I cannot voucher for the authenticity of this story. This might be an urban legend for all I know. But it exemplifies the kind of stories about HP we had in the good old times...
Slashdot Mirror
This looks neat and very promising, but I don't think it's background free, is it? This is based on page 2, "The building blocks of the standard
model and gravity are fields over a four dimensional base manifold. I think there remains an unanswered question regarding what "x" means in the equations. And you can derive some stuff trying to answer that question. Just 2 cents.
Hey, cool, Lubos doesn't like me either! I must be a genius :-)
Go away MacTroll...
/>. I thougth this had quite a familiar look, it looks quite a lot like the web site I made with iWeb myself... Except I did not remove the "made on a Mac" logo to please the zealots.
Meanwhile, from the source of the web site: <meta name="Generator" content="iWeb 1.1.2"
Was this a rethorical question?
One big difference between UAC and "sudo" or the MacOSX security dialog is that UAC does not ask for a password. Minor convenience (well, probably serious convenience given how frequently UAC pops up today), but major risk. I can leave my Mac or Linux box to someone that does not know the password, without instantly making him / her an administrator on my machine. The same is not true with Vista + UAC.
It may seem like a small thing today, but filling the screen with flat-shaded 3D graphics gave a much more immersive experience that had a serious "wow" factor at the time. I still remember the Infogrames guy staying in front of the computer playing my demo for maybe two hours straight, amazed at how fluid it was. Infogrames knew all about the games of the time, and they knew of nothing like it. Now, maybe there was a game they did not know about, I've always been curious.
Of course, two years later, everybody was doing it. Though the particular gameplay remains somewhat unique to this day, and good enough that my kids still ask me to play it from time to time, swithing away from today's ultra-realist 3D...
How did that engine avoid multiplications?
There are simply too many different possibilities for there to be one reasonable guess. You can use shifts and adds, but that's rarely faster than the hardware, and at that time pipelining usually wasn't very useful. Table lookups of various sorts were fairly common, frequently with some bit-masking or -shifting to keep the table size reasonable.
Well, that's why I gave the source code.
Anyway, the answer was: the engine was pre-computing 3 axis vectors. That required a few mulitplications. Then, it would add them to create vectors like 1Z, 2Z, 3Z, 1X, 2X, 3X. Finally, all objects were defined using displacements like 1X 2Z -1Y and so on. As a result, the final rendering was done with practically only additions. If memory serves me right, there were only about 6 multiplications per object. That trick, and a very optimized polygon-filling routine, allowed Alpha Waves to display about 10-20 frames per second full screen of 3D graphics on a 8MHz 16-bit CPU. As I wrote in the parent post, I believe it was the first game to ever do that (3D games at the time typically displayed quarter-frame graphics, or full-screen vector graphics).
How did it compute sine and cosines?
CORDIC?
Don't be silly! CORDIC is a floating-point algorithm.
The answer was that angles were represented using 256 units for a rotation, which allowed a byte indexing in a table (with an offseting by 64 to select between sin and cos). Each entry in the table was between +/-32767. Multiplying that by a 16-bit coordinate would give a 32-bit value. Shifting the value down 15 times was not an option, since the 68K did not have a barrel shifter, so that would have been slow. Instead, I used the "swap" instruction, that swapped the high and low half of a 32-bit word. So the computation multiplied by sin(x)/2, not by sin(x), and I had to correct for that. As a matter of fact, it was not even exactly sin(x), because 32767 / 65536 is not exactly 0.5...
Since you haven't even specified what hardware it was for, attempting to guess at the low-level hardware trick(s) you used would be pretty pointless.
I did give enough pointers to answer the question. Of course, that means you are curious enough to actually follow a link. The original source code was for Atari ST. The hardware trick I referred to was that there were 16 registers to change the color palette. Using an interrupt, I was changing the color palette in the middle of the screen, so that the "top" and the "bottom" half of the screen could show users that were in different rooms, because the "mood" of each room was given by a different color palette.
The palette-changing trick was relatively frequently used at the time. What made it useful for performance tuning was that you could change the screen border color on entry to a routine, and change it again on exit, and the height of the color band on the side of the screen would tell you how much time you spent in the routine.
I believe Alpha Waves was the first video game on personal computers with full-screen "real" 3D (i.e. not scaled sprites), and I also believe it was the first 3D game with two simultaneous players sharing a screen. Would anybody have data to confirm or infirm that?
"infirm" ? Do you mean "deny", perhaps?
Probably
It wasn't the first game on a personal computer with real 3D -- I wrote some real 3D code that ran on a C64 around 1982 or '83. OTOH, the "ran" there is an exaggeration -- "walked" would be closer, and "stumbled" would probably be the right word. The code was all right, but there's only so much you can do on an 8-bit, 1 MHz processor. A couple of us played it enough to say it worked, but that's about it.
Oh, it would also depend a bit on what you're talking about as 3D -- this was wireframes only. I wrote some lighting code, but never used it except to cre
>> How did that engine avoid multiplications?
> Creative bit shifts and additions?
That would still be multiplications by another name. And by the way, on a 68K, shifting left N bits took a time proportional to N.
>>How did it compute sine and cosines?
> lookup tables?
Yeah, right. OK, there was a lookup table somewhere, that much is obvious. But I guess I should rephrase the question as: how do you compute a rotation efficiently using only integer arithmetic?
>> What low-level hardware trick did it use in two-player mode, and how could that be used for performance tuning?
> Eh? need more info, or do I need to look at the links to understand the question
Of course, where would the reverse engineering fun be?
Hint: there is a C++ port on SourceForge.
Back around 1990, I wrote a game called Alpha Waves (Preview). Back then, the problem was not using integers to approximate floating point math, it was avoiding integer multiplications, because those were expensive compared to additions. For those of you with a curious mind, you can take a look at http://cc3d.free.fr/cube.s for the original source code.
So here is a quizz, the first one answering wins the admiration of the crowd:
- How did that engine avoid multiplications?
- How did it compute sine and cosines?
- What low-level hardware trick did it use in two-player mode, and how could that be used for performance tuning?
I believe Alpha Waves was the first video game on personal computers with full-screen "real" 3D (i.e. not scaled sprites), and I also believe it was the first 3D game with two simultaneous players sharing a screen. Would anybody have data to confirm or infirm that?
--
-- Physics for Dummies
And what about setting up counter-attacks after city-sized alien spaceships have destroyed our satellites and other means of communication? Of course, Independance Day is behind us, so we are safe for _this_ year...
From a concept-programming standpoint, LitWindow seems to be a sort of hacked-together meta-programming language for GUIs. The concepts are good, but the implementation is sorely limited by the language they use (C++).
For instance, their data adapter are the poor's man meta-program generating useful reflective data from a data structure. You actually need to duplicate the description of the data structure, precisely because this is not a _real_ meta-program, but only a clever hack using the C preprocessor...
Now, what if you had a real way to extend the language as you need it, rather than this crude hack? Wouldn't it be cool if the data adapters could be generated automagically?
The Virtual Virtual Machine is, if I understand correctly, a virtual machine to build virtual machines.
That's quite simple. Your understanding of how calculators do it seems to be wrong. Nothing that I know of creates a derived equation and uses that. They use numerical methods that make use of the original equation to compute the derivative.
The HP-48 calculator or Mathematica both do the thing that "nothing you know of" does. We could also discuss why the numerical approach may be incorrect.
Well, if you want a pure OO maximum, rather than a Java maximum, then there would be a maximum method on a collection.
You obviously have not read my definition of a concept cast. A concept cast is when you cannot represent a concept, and use some alternate concept in its place. It's very insidious, and most people don't even realize when it happens.
In your case, you replaced the concept of maximum of N elements with the concept of a collection containing N elements. They are close, but not identical. As a result, semantic noise is introduced, for instance boxing and unboxing, or built-in memory management for lists (it depends on a particular implementation).
There is not enough innovation either in C# nor in Java, and what is there is often not implemented in the best possible way.
Generics (C# 2.0 already supports this)
Both Java and C# generic are quite limited, compared to C++ templates. And they are easier to use with expression reduction, since you can give them a nice-to-use form.
Enhanced For-Loop (the foreach construct in C# 1.0, duh!)
It is much better if you can define your own for loops, as in XL.
Autoboxing/Unboxing (C# 1.0 already has this, everything is an object, even the primitives - not really, but they do it so well...)
Autoboxing means you have boxing in the first place, which means your language doesn't support stack object. Nothing to be proud of. And _auto_boxing is only a form of implicit conversion. In XL, any implicit conversion can be implemented using expression reduction.
Typesafe Enums (again C# 1.0 already implemented this, but I think they've added a little bit more twist in Java, that its actually a better implementation)
Ooooh! Enums! Innovation!
Varargs (C# 1.0's params construct, ellipsis construct in C++)
Still no type-safe, instantiation based varargs.
Static Import (I don't know if C# 1.0 has this, or C#2.0, but C# has a construct for aliasing your imports - which is way cooler. Static Import, actually promotes bad coding habits IMHO)
Yes. (XL had import aliasing for a while, see examples above...)
Metadata/Annotations (this is C# 1.0's Attributes, Sun's upturned noses just gave it a fancier name - also, C#'s implementation is better and more intuitive)
What you really want is metaprogramming, to actually enhance the language as you go.
Also, what exactly make XL a concept programming language? It looks somewhere between Haskell, Ruby, and a simple procedural language to me.
The old XL (in C++) is about 55000 lines of code. The new XL is about 22000 lines of code. Documentation is a fraction of my time.
Reinventing a clone of python? XL has very little in common with Python, except the indent-based syntax. There's not much that Python can do that can't be done better with other languages. In other words, it's mostly syntactic sugar on well-known concepts. XL, on the other hand, introduces several powerful ideas, and does a few important things better than existing languages I know of.
So I think it's worth doing.
Can you summarize in clear terms what the difference between concept programming and object-oriented design is?
:-) From a CP point of view, OO is an approach which models a rather large range of concepts represented as "verb + noun", where verbs are represented as methods, and nouns as objects. For instance, "window.draw()". There are some concepts that OO has trouble with, because they have no easy "verb + noun" representation. For instance, computing a maximum the OO way is tricky. In Java, you'd typically resort to a non-OO static method for that. See http://mozart-dev.sourceforge.net/cp-vs-oo.html for a more detailed discussion.
There's very little in common, except for the fact that they are both software methodologies
Also, what exactly make XL a concept programming language? It looks somewhere between Haskell, Ruby, and a simple procedural language to me.
As to what makes XL a concept programming language, it's extensibility combined with readability. That it looks like a simple procedural language is by design. It would not be CP if it could not represent old concepts the usual way. It's under the hood that it's really different. And you see when you start manipulating non-standard concepts, for instance a simple plug-in allows you to manipulate symbolic differential forms in your source code. You can't do that as easily, if at all, with any of the languages you listed.
Concept programming is an approach to programming that I hope will yield improvements in quality. If your code is structured like what it represents, then it's easier to understand and maintain. This simple idea yields interesting metrics, and highlights issues that are a bit hard to spot otherwise.
Over time, I became convinced that a new language was actually necessary to implement concept programming correctly. It turns out that some of the tools developed for XL help many other things (like documentation, good interfaces, automated tools, etc).
Slashdot is a good way to attract readers... Why would it be OK to promote open-source software releases and not interesting non-open-source ones?
:-)
Well, now that I think about it, let me take the opportunity to talk about XL, the future of programming. XAML is so passe, you know. This Xamlon act is the proof that it's no longer interesting: there is an implementation that works.
No such problem with XL. It's a real, true to geek do-it-yourself futureware. Complete with almost-but-not-quite-working source code. So if you are unhappy about these folks talking about real stuff available today, why don't you stop ranting and contribute so that we can get back to talking about stuff that doesn't exist yet
Meta-programming is much more powerful, with the ability to actually change the program, not just attach data to it. The XL programming language is designed around that idea. And open-source too. Hint: I'm always looking for contributors to help.
Yet another story about calculators. When HP launched the 10 series (HP10C, HP11C, HP12C, HP15C, HP16C), it started with a 1 year warranty. Then 2 years. Then 5 years. Then lifetime. And then, they started giving them away for free with practically every kind of high-end gear they sold. "Buy a cartridge of ink, and get an HP-15 for free", that was their marketing at the time.
Someone at HP told me that the reason was that HP always built a fixed percentage of additional machines for support. They'd never try to fix a calculator, they'd simply replace it. Except that the 10's never died. Ever. So the support stock started piling up... and up...
Well, again, I don't know if this is true. The following, however, I know is true, because this is personal experience. I once lost an HP-15C on a road while biking. I heard the noise, and went back to look for it. I didn't see it right away, and I ran right over it. It still works to that day.
My brother had an HP-28. He was working on some sort of fun, long-running math program, which he debugged while cleaning up something. Some slashdotters probably know the feeling. Well, he heads for lunch, and mistakenly pushes the running HP-28 in the water. Needless to say, he's rather alarmed when he comes back and sees the poor HP-28 underwater. But the calculator still ran fine, running the program happily. I don't know if that qualifies as watercooling... It turns out HP had made it totally waterproof.
OK, yet another story. I had a 48 later (you can still find a few programs I wrote out there). At one point, I noticed that you could switch the calculator on with the batteries out. It would run for a short moment (maybe 5-10 seconds max). So I decided to know how little electricity it used. It took me a 6-digit ampere-meter to figure out. Off the top of my head, it was in the 50 micro-amps range.
---
This can't be true. Didn't you hear that story of the HP support person getting a call from a customer with a broken PC.
Support rep: "OK, switch your PC on, and tell me what happens".
Customer: "There's smoke coming from the hole on the right side".
Support rep: "Hole? Which hole? This model doesn't have a hole on the right side"
Customer: "Well, it's broken now since it fell downstairs. That's why I called you".
Support rep: "Are you telling me that you are calling because your PC doesn't work after falling downstairs?"
Customer: "Yes"
Support rep: "I'm sorry, I'm afraid this is not covered by your support contract".
Customer: "What? Why not? My HP calculator fell a number of times, and it still works!"
I cannot voucher for the authenticity of this story. This might be an urban legend for all I know. But it exemplifies the kind of stories about HP we had in the good old times...