Parallel Common-Lisp with at least 64 processors? - lisp

Pascal Costanza <pc@p-cos.net> writes:

> Jon Harrop wrote:
>
>> For example, this single pattern in OCaml:
>> | (2|3|5 as x), (3|5|7 as y) -> x + y
>> has the obvious translation into Lisp (following Pascal's lead) as:
>> (defmethod f ((x (eql 2)) (y (eql 3))) (+ x y))
>> (defmethod f ((x (eql 2)) (y (eql 5))) (+ x y))
>> (defmethod f ((x (eql 2)) (y (eql 7))) (+ x y))
>> (defmethod f ((x (eql 3)) (y (eql 3))) (+ x y))
>> (defmethod f ((x (eql 3)) (y (eql 5))) (+ x y))
>> (defmethod f ((x (eql 3)) (y (eql 7))) (+ x y))
>> (defmethod f ((x (eql 5)) (y (eql 3))) (+ x y))
>> (defmethod f ((x (eql 5)) (y (eql 5))) (+ x y))
>> (defmethod f ((x (eql 5)) (y (eql 7))) (+ x y))
>
> LOL

Well ok. Indeed, lisp has no native pattern matcher. But it has
something better: smooth and easy meta-programming.


> From http://www.research.att.com/~bs/bs_faq.html#compare :
>
> "Several reviewers asked me to compare C++ to other languages. This I
> have decided against doing. Thereby, I have reaffirmed a long-standing
> and strongly held view: Language comparisons are rarely meaningful and
> even less often fair. A good comparison of major programming languages
> requires more effort than most people are willing to spend, experience
> in a wide range of application areas, a rigid maintenance of a
> detached and impartial point of view, and a sense of fairness. I do
> not have the time, and as the designer of C++, my impartiality would
> never be fully credible.
>
> I also worry about a phenomenon I have repeatedly observed in honest
> attempts at language comparisons. The authors try hard to be
> impartial, but are hopelessly biased by focusing on a single
> application, a single style of programming, or a single culture among
> programmers. Worse, when one language is significantly better known
> than others, a subtle shift in perspective occurs: Flaws in the
> well-known language are deemed minor and simple workarounds are
> presented, whereas similar flaws in other languages are deemed
> fundamental. Often, the workarounds commonly used in the
> less-well-known languages are simply unknown to the people doing the
> comparison or deemed unsatisfactory because they would be unworkable
> in the more familiar language.
>
> Similarly, information about the well-known language tends to be
> completely up-to-date, whereas for the less-known language, the
> authors rely on several-year-old information. For languages that are
> worth comparing, a comparison of language X as defined three years ago
> vs. language Y as it appears in the latest experimental implementation
> is neither fair nor informative. Thus, I restrict my comments about
> languages other than C++ to generalities and to very specific
> comments."

Well not OK. There are languages that are worse than others, and C++
is amongst them. Of course, there's no need to discuss hours whether
C++ is worser than brainfuck¹ or vice-versa, but any programmer can
make up his own classification easily.


> Enough said.



¹) said after a day fighting with templates to implement something
done in two lines of lisp.

--
__Pascal Bourguignon__

Kenny wrote:
> Sohail Somani wrote:
>> Also this guys story intrigued me to no end:
>>
>> http://james.fabpedigree.com/mathmen.htm#Ramanujan
>
> Yes, that was pretty cool. Sad ending.

Turing too. Maybe you should just have a picture of a lot of people and
let them choose along with a bio of each guy.

Pascal J. Bourguignon wrote:
> Well ok. Indeed, lisp has no native pattern matcher. But it has
> something better: smooth and easy meta-programming.

Mathematica has both pattern matching and easy metaprogramming. Could a next
generation Lisp also bundle both?

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u

Jon Harrop wrote:
> Pascal J. Bourguignon wrote:
>> Well ok. Indeed, lisp has no native pattern matcher. But it has
>> something better: smooth and easy meta-programming.
>
> Mathematica has both pattern matching and easy metaprogramming. Could a next
> generation Lisp also bundle both?
>

What are your thoughts on Qi?

kt

Kenny wrote:
> Jon Harrop wrote:
>> Pascal J. Bourguignon wrote:
>>> Well ok. Indeed, lisp has no native pattern matcher. But it has
>>> something better: smooth and easy meta-programming.
>>
>> Mathematica has both pattern matching and easy metaprogramming. Could a
>> next generation Lisp also bundle both?
>
> What are your thoughts on Qi?

From a purely technical perspective, Qi looks like an interesting
development that tries to combine the best of the statically typed FPLs
with the best of the dynamic ones.

From an overall perspective, I think Qi was always doomed to failure due to
market issues. Specifically, it is dwarfed by statically-typed FPLs like
OCaml and F# on one side and dynamic languages like Lisp and Erlang on the
other side. All of these competitors have far more tutorial information out
there, far better tools, far more libraries and are far more mature. Qi
would have to offer something amazing just to become visible but it
doesn't.

Right now, I think multicore computing is widely recognised to be of
critical importance. So languages that can stake a claim on parallelism are
seeing a lot of lime light. Erlang is an obvious example of a programming
language seeing a lot of hype because of this (although it is almost
entirely unfounded).

Despite the early warnings about multicore computing, the open source world
has managed to start off wrong-footed in this context: with a complete lack
of multicore-capable tools except for the JVM which essentially only has
sucky languages available for it because it lacks basic common-language
features like tail calls.

I think Microsoft have positioned themselves extremely well in this respect,
by making the .NET platform multicore capable and multi programming
language capable and then adding their Task Parallel Library to make
multicore computing easy through the use of higher order functions (!).
This is one of the main reasons why we are now placing our bets on F# as a
company. If the open source world created anything competitive then we
would certainly diversify but, to be honest, I think we've reached a point
in history where foundations like decent language implementations cannot
feasibly be written by the open source community.

So my advice to budding language developers trying to develop a useful
language is to target the JVM instead of building upon Lisp. Unfortunately,
that will not really be feasible for functional languages until Sun finally
get around to implementing tail calls. The second best option would be to
build upon LLVM and write your own concurrent GC but I believe that is
prohibitively difficult. If you're happy to restrict yourself to Windows
then target the CLR but, of course, you'll be going head to head with F#.

Now that I think about it, the pattern matching and the metaprogramming in
Mathematica are very much secondary to the graphical development
environment. So perhaps there is no merit in trying to build a language
combining such features anyway.

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u

Kenny <kentilton@gmail.com> writes:

> Ok, so I am sitting here looking at this killer Algebra application
> now that I just gave it a wicked makeover and I need medals for the
> kids, gold, silver, and bronze depending on how they do one each
> mission (you know, quiz). So I need to know the three greatest
> mathematicians, or something like that.
>
> Candidates?

As a mathematician, I'd say:


1. Gauss

2. Archimedes

3. Newton.


I think most mathematicians would buy into that. I'd be quite
surprised if any of them did not think Gauss was the undisputed #1.


/Jon

--
'j' - a n t h o n y at romeo/charley/november com

Jon Harrop wrote:
> Kenny wrote:
>> Jon Harrop wrote:
>>> Pascal J. Bourguignon wrote:
>>>> Well ok. Indeed, lisp has no native pattern matcher. But it has
>>>> something better: smooth and easy meta-programming.
>>> Mathematica has both pattern matching and easy metaprogramming. Could a
>>> next generation Lisp also bundle both?
>> What are your thoughts on Qi?
>
> From a purely technical perspective, Qi looks like an interesting
> development that tries to combine the best of the statically typed FPLs
> with the best of the dynamic ones.
>
> From an overall perspective, I think Qi was always doomed to failure due to
> market issues. Specifically, it is dwarfed by statically-typed FPLs like
> OCaml and F# on one side and dynamic languages like Lisp and Erlang on the
> other side. All of these competitors have far more tutorial information out
> there, far better tools, far more libraries and are far more mature. Qi
> would have to offer something amazing just to become visible but it
> doesn't.

Oh. I thought it did the pattern thing. And that that was
vital/crucial/amazing. Confused.

>
> Right now, I think multicore computing is widely recognised to be of
> critical importance. So languages that can stake a claim on parallelism are
> seeing a lot of lime light. Erlang is an obvious example of a programming
> language seeing a lot of hype because of this (although it is almost
> entirely unfounded).
>
> Despite the early warnings about multicore computing, the open source world
> has managed to start off wrong-footed in this context: with a complete lack
> of multicore-capable tools except for the JVM which essentially only has
> sucky languages available for it because it lacks basic common-language
> features like tail calls.
>
> I think Microsoft have positioned themselves extremely well in this respect,
> by making the .NET platform multicore capable and multi programming
> language capable and then adding their Task Parallel Library to make
> multicore computing easy through the use of higher order functions (!).
> This is one of the main reasons why we are now placing our bets on F# as a
> company.

Isn't .net proprietary? I do not think any serious technologist is
interested in running only on Windows.

It might be a good decision for a business but not one is in an oddball
fringe area like pattern-matching static FPL in which case one
desperately needs to be portable just to reach the only market you have:
nerds.

I killed over a year porting my Algebra software from the Mac to the PC
only to discover that (back then) PC users only ran software they could
"borrow" from work. The PC (95% market share) became 20% of my sales.
Not worth that year when I could have rolled out a second title.

You may want to move your chips off 13 onto red or black.

kt

> > If you mean something more complicated as "pattern matching", you need to
> > say precisely what you mean.
> From: Jon Harrop <j...@ffconsultancy.com>
> I was referring to ML-style pattern matching (including dynamic
> dispatch over nested algebraic data types) as seen in F#, OCaml,
> Haskell and SML.

What you said there is meaningful only to somebody who already
knows that particular part of ML or F# or OCaml or Haskell or SML
at a deep level of understanding.

To the rest of us, including myself, you seem to be evading
answering the question, and to me you appear to be somebody who
doesn't understand any of that at a deep level yourself and that's
why you refuse to say what you mean but instead make vague
references to the way it's done in various other languages. To
prove you *do* actually understand what you're talking about,
please peruse the documentation for those five languages, searching
for succinct explanations of what you're talking about, then
copy&paste the relevant text into this thread with citation of
precisely where you found the original text. If you don't find any
suitable explanation in the online documentation for *any* of those
five languages, perhaps you can find sufficient semi-explanations
that you can modify the wording to be suitable to post here.

> Most of the functionality of the symbolic simplifier I cited is
> encoded in the pattern matching:
> let rec ( +: ) f g = match f, g with
> | `Int n, `Int m -> `Int (n +/ m)
> | `Int (Int 0), e | e, `Int (Int 0) -> e
> | f, `Add(g, h) -> f +: g +: h
> | f, g -> `Add(f, g)

I've never programmed in whatever language that's supposed to be,
and don't even recognize the language. If you wrote in French or
Tagalog I'd have a better chance of at least guessing what language
it's supposed to be. Please try to communicate basic ideas, such as
what the heck you mean by "pattern matching", in ordinary English
that we can all understand. *After* you've explained the basic idea
well enough that we understand, *then* you can start showing code
examples from various languages with explanations of how the code
relates to the understanding of basic principles we already have.

> All three functions ... The values they are matching are
> algebraic datatypes and integers in this case.

What are "algebraic datatypes"? Is this what you mean?
<http://en.wikipedia.org/wiki/Algebraic_data_types>
In computer programming, an algebraic data type is a datatype each of
whose values is data from other datatypes wrapped in one of the
constructors of the datatype. Any wrapped datum is an argument to the
constructor. In contrast to other datatypes, the constructor is not
executed and the only way to operate on the data is to unwrap the
constructor using pattern matching.
OK, I've gotta play (deceased) George Carlin here: If you never
execute the constructor, so that it never actually constructs
anything, then isn't it a bit of an oxymoron to call it a
"constructor"? And if it's never executed, how would you know it's
a real constructor, and not just a fake that wouldn't do anything
if you were to execute it? Is it like purchasing a shrink-wrapped
software product with a warning that opening the shrink wrap voids
the warantee, and in fact a disclaimer that opening the shrink wrap
causes a self-destruct mechanism to be triggered whereby the CD-ROM
is immediately erased? Or is it like an instruction tape in
Mission Impossible, where you can carry it around unopened as long
as you want, and believe strongly that it's really an instruction
tape, but as soon as you open it you can listen to it just once to
verify it really *was* a instruction tape before it self-destructs?
Thus you can verify once, in a destructive way, that yes Virginia
it really and truly *was* an instruction tape, or a constructor?

If you can never test that the thingy really is a constructor, can
I give you something that I claim is a constructor, even though I'm
lying, it's just a symbol, or even an integer, with no special
properties, no utility whatsoever, and you are required to trust me
that it really is a constructor, and you are forbidden to ever
check if it really is a constructor? Is it like the monsters in
children's bedrooms, or mummies in Abbott&Costello movies, which
disappear whenever the parents or Abbott show up respectively?

> Run ocaml ...

% whereis ocaml
ocaml:
(rest of what you say is moot here)

On Mon, 23 Jun 2008 09:33:42 +0200, Edi Weitz <spamtrap@agharta.de> said:

| On Sun, 22 Jun 2008 21:11:16 -0400, Kenny <kentilton@gmail.com> wrote:
|...
|| need to know the three greatest
|| mathematicians, or something like that.
||
|| Candidates?

| http://en.wikipedia.org/wiki/Carl_Friedrich_Gauss

Yet another proof that he is among the worthiest is this
"traditional" definition of mathematician by induction:

1. Gauss is a mathematician.
2. X is a mathematician if declared one by a mathematician.
3. There are no other mathematicians.

---Vassil.


--
Peius melius est. ---Ricardus Gabriel.