Distributed RVS, Darcs, tech love

[Xah Lee]

When i first heard about distributed revision control system about 2
years ago, i heard of Darcs, which is written in Haskell. I was hugely
excited, thinking about the functional programing i love, and the no-
side effect pure system i idolize, and the technology of human animal
i rapture in daily.

I have no serious actual need to use a revision system (RVS) in recent
years, so i never really tried Darcs (nor using any RVS). I just
thought the new-fangled distributed tech in combination of Haskell was
great.

About few months ago, i was updating a 6-year old page i wrote on unix
tools: ( http://xahlee.org/UnixResource_dir/usoft.html ) and i was
trying to update myself on the current state of art of revision
systems. I read Wikipedia this passage:

http://en.wikipedia.org/wiki/Darcs

« Darcs currently has a number of significant bugs (see e.g. [1]). The
most severe of them is "the Conflict bug" - an exponential blowup in
time needed to perform conflict resolution during merges, reaching
into the hours and days for "large" repositories. A redesign of the
repository format and wide-ranging changes in the codebase are planned
in order to fix this bug, and work on this is planned to start in
Spring 2007 [2]. »

This somewhat bursted my bubble, as there always was some doubt in the
back of my mind about just how Darcs is not just a fantasy-ware
trumpeted by a bunch of functional tech geekers. (i heard of Darcs in
irc emacs and haskell channels, who are often student and hobbiests
programers)

Also, in my light research, it was to my surprise, that Darcs is not
the only distributed systems, and perhaps not the first one neither,
contrary to my impressions. In fact, today there are quite a LOT
distributed revision systems, actually as a norm. When one looks into
these, such as Git ( http://en.wikipedia.org/wiki/Git_(software) ) one
finds that some of them are already in practical industrial use for
large projects, as opposed to Darcs's academic/hobbist kind of
community.

In addition to these findings, one additional that greatly pissed me
off entirely about Darcs, is the intro of the author (David Roundy)'s
essay about his (questionable-sounding) “theory of patches†used in
Darcs. ( http://darcs.net/manual/node8.html#Patch )

Here's the 2 passages:

«I think a little background on the author is in order. I am a
physicist, and think like a physicist. The proofs and theorems given
here are what I would call ``physicist'' proofs and theorems, which is
to say that while the proofs may not be rigorous, they are practical,
and the theorems are intended to give physical insight. It would be
great to have a mathematician work on this, but I am not a
mathematician, and don't care for math.»

«From the beginning of this theory, which originated as the result of
a series of email discussions with Tom Lord, I have looked at patches
as being analogous to the operators of quantum mechanics. I include in
this appendix footnotes explaining the theory of patches in terms of
the theory of quantum mechanics. I know that for most people this
won't help at all, but many of my friends (and as I write this all
three of darcs' users) are physicists, and this will be helpful to
them. To non-physicists, perhaps it will provide some insight into how
at least this physicist thinks.»

I love math. I respect Math. I'm nothing but a menial servant to
Mathematics. Who the **** is this David guy, who proclaims that he's
no mathematician, then proceed to tell us he dosen't fucking care
about math? Then, he went on about HIS personal fucking zeal for
physics, in particular injecting the highly quacky “quantum mechanicsâ€
with impunity.

Xah
(e-mail address removed)
∑ http://xahlee.org/

 

[Byung-Hee HWANG]

When i first heard about distributed revision control system about 2
years ago, i heard of Darcs, which is written in Haskell. I was hugely
excited, thinking about the functional programing i love, and the no-
side effect pure system i idolize, and the technology of human animal
i rapture in daily.

I have no serious actual need to use a revision system (RVS) in recent
years, so i never really tried Darcs (nor using any RVS). I just
thought the new-fangled distributed tech in combination of Haskell was
great.

About few months ago, i was updating a 6-year old page i wrote on unix
tools: ( http://xahlee.org/UnixResource_dir/usoft.html ) and i was
trying to update myself on the current state of art of revision
systems. I read Wikipedia this passage:

http://en.wikipedia.org/wiki/Darcs

« Darcs currently has a number of significant bugs (see e.g. [1]). The
most severe of them is "the Conflict bug" - an exponential blowup in
time needed to perform conflict resolution during merges, reaching
into the hours and days for "large" repositories. A redesign of the
repository format and wide-ranging changes in the codebase are planned
in order to fix this bug, and work on this is planned to start in
Spring 2007 [2]. »

This somewhat bursted my bubble, as there always was some doubt in the
back of my mind about just how Darcs is not just a fantasy-ware
trumpeted by a bunch of functional tech geekers. (i heard of Darcs in
irc emacs and haskell channels, who are often student and hobbiests
programers)

Also, in my light research, it was to my surprise, that Darcs is not
the only distributed systems, and perhaps not the first one neither,
contrary to my impressions. In fact, today there are quite a LOT
distributed revision systems, actually as a norm. When one looks into
these, such as Git ( http://en.wikipedia.org/wiki/Git_(software) ) one
finds that some of them are already in practical industrial use for
large projects, as opposed to Darcs's academic/hobbist kind of
community.

In addition to these findings, one additional that greatly pissed me
off entirely about Darcs, is the intro of the author (David Roundy)'s
essay about his (questionable-sounding) “theory of patches†used in
Darcs. ( http://darcs.net/manual/node8.html#Patch )

Here's the 2 passages:

«I think a little background on the author is in order. I am a
physicist, and think like a physicist. The proofs and theorems given
here are what I would call ``physicist'' proofs and theorems, which is
to say that while the proofs may not be rigorous, they are practical,
and the theorems are intended to give physical insight. It would be
great to have a mathematician work on this, but I am not a
mathematician, and don't care for math.»

«From the beginning of this theory, which originated as the result of
a series of email discussions with Tom Lord, I have looked at patches
as being analogous to the operators of quantum mechanics. I include in
this appendix footnotes explaining the theory of patches in terms of
the theory of quantum mechanics. I know that for most people this
won't help at all, but many of my friends (and as I write this all
three of darcs' users) are physicists, and this will be helpful to
them. To non-physicists, perhaps it will provide some insight into how
at least this physicist thinks.»

I love math. I respect Math. I'm nothing but a menial servant to
Mathematics. Who the **** is this David guy, who proclaims that he's
no mathematician, then proceed to tell us he dosen't fucking care
about math? Then, he went on about HIS personal fucking zeal for
physics, in particular injecting the highly quacky “quantum mechanicsâ€
with impunity.

I'm gonna like your writings with all respect. Actually your writings
has the quiet force. See you often ;;

--
Byung-Hee HWANG <[email protected]> * আমি তোমাকে ভালোবাসি
InZealBomb, Kyungpook National University, KOREA

"OK. Then I have to kill him."
-- Michael Corleone, "Chapter 11", page 146

 

[j.oke]

yes-and-no.

 

[llothar]

I love math. I respect Math. I'm nothing but a menial servant to
Mathematics.

Programming and use cases are not maths. Many mathematics are
the worst programmers i've seen because they want to solve things and
much more often you just need heuristics. Once they are into exact
world they loose there capability to see the factor of relevance in
algorithms.

And they almost never match the mental model that the average
user has about a problem.

 

[Daniel Pitts]

Programming and use cases are not maths. Many mathematics are
the worst programmers i've seen because they want to solve things and
much more often you just need heuristics. Once they are into exact
world they loose there capability to see the factor of relevance in
algorithms.

And they almost never match the mental model that the average
user has about a problem.

I read somewhere that for large primes, using Fermat's Little Theorem
test is *good enough* for engineers because the chances of it being
wrong are less likely than a cosmic particle hitting your CPU at the
exact instant to cause a failure of the same sort. This is the
primary difference between engineers and mathematicians.

 

[Benjamin A'Lee]

]

Inflammatory and irrelevant. Why not ask questions about Darcs on the
Darcs list, or are you worried that there may be too many people there
who can tell you what a load of rubbish you're talking?

Ben

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHGq0JEUZDNrttL6ARAiZvAKCpTZviJZE4CTObM2U9J/CyBex9ugCfUVxf
pbGsLnqIqV6DjhmAQPaZlp4=
=14Lq
-----END PGP SIGNATURE-----

 

[George Neuner]

I read somewhere that for large primes, using Fermat's Little Theorem
test is *good enough* for engineers because the chances of it being
wrong are less likely than a cosmic particle hitting your CPU at the
exact instant to cause a failure of the same sort. This is the
primary difference between engineers and mathematicians.

An attractive person of the opposite sex stands on the other side of
the room. You are told that your approach must be made in a series of
discrete steps during which you may close half the remaining distance
between yourself and the other person.

Mathematician: "But I'll never get there!"

Engineer: "I'll get close enough."

 

[Lew]

An attractive person of the opposite sex stands on the other side of
the room. You are told that your approach must be made in a series of
discrete steps during which you may close half the remaining distance
between yourself and the other person.

Mathematician: "But I'll never get there!"

Engineer: "I'll get close enough."

Mechanician (to the researcher): Hey, you look pretty good. What's your sign?

 

[Timofei Shatrov]

Programming and use cases are not maths. Many mathematics are
the worst programmers i've seen because they want to solve things and
much more often you just need heuristics. Once they are into exact
world they loose there capability to see the factor of relevance in
algorithms.

And they almost never match the mental model that the average
user has about a problem.

I'm, not sure that I'm getting your point, but are you trying to argue that
_not_ knowing mathemathics makes you a better programmer? Or maybe that learning
math is useless to a programmer? This must be the most ignorant post I've seen
this week. The *best* programmers I've seen actually had mathematic education.
The programmers who don't know math are the ones who end up on DailyWTF.

 

[llothar]

I'm, not sure that I'm getting your point, but are you trying to argue that

_not_ knowing mathemathics makes you a better programmer?

No but it doesn't help you very much either. They are just different
skills.

Or maybe that learning math is useless to a programmer?

No and at least the mathematical idea of building a universe on a
basic set
of axioms is pretty exciting for a programmer. But it's the idea not
the real
wisdom (I never had to use any serious maths in my 25 years of
programming)
that you need as a programmer

This must be the most ignorant post I've seen
this week. The *best* programmers I've seen actually had mathematic education.

Depends. I would call Knuth as one of the worst programmers. Look at
his total
failures on literature programming. Software Engineering is something
very
different. Having a dead - i mean end of development line software
like TeX - and
then trying to base a theory about software engineering (which is
based on changes)
is so absolutely stupid ...

 

[Lew]

Depends. I would call Knuth as one of the worst programmers. Look at
his total
failures on literature programming. Software Engineering is something

Umm, the term is "literate" programmer and there is evidence that it is not a
"failure".

very
different. Having a dead - i mean end of development line software
like TeX - and

Based on what do you call it "dead end". It's used, it's outlasted many other
flashes in the pan, it does what its users require. You will need evidence
for such a claim.

then trying to base a theory about software engineering (which is
based on changes)

"base a theory" on what? There's a clause missing here.

is so absolutely stupid ...

Is that a technical evaluation? It looks like random inflammatory comments
without basis in logic or evidence. Can stupidity be absolute? What is the
metric of stupidity?

How would you disprove that assertion? Oh, wait, there wasn't an assertion.
The sentence was incomplete. What are you asserting?

A theory based on what, exactly, is "so absolutely stupid"?

 

[Guest]

Based on what do you call it "dead end". It's used, it's outlasted many
other flashes in the pan, it does what its users require. You will need
evidence for such a claim.

According to wikipedia the last version is from december 2002.

That level of activity could be considered dead.

It would for almost any other software. Tex has some
"absolute" over it, so I am not sure normal software
practices apply.

But you could argue based on that.

Arne

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

No but it doesn't help you very much either. They are just different
skills.

Many things within programming have a foundation in mathematics
and mathematical logic.

No and at least the mathematical idea of building a universe on a
basic set
of axioms is pretty exciting for a programmer. But it's the idea not
the real
wisdom (I never had to use any serious maths in my 25 years of
programming)
that you need as a programmer

Depends obvious a bot on what you consider serious math.

Expression evaluation, floating point characteristics, relational
database theory, simulation, optimum location, encryption etc.
are all based on mathematics of different levels.

Depends. I would call Knuth as one of the worst programmers. Look at
his total
failures on literature programming. Software Engineering is something
very
different.

I think you will find it very difficult to write a piece of code
that are not heavily influenced by Knuth.

Arne

 

[OMouse]

For the love of the Perl, Python, Lisp, Java and functional
programmers, please just give an abstract of what you've written and
link to it?

-Rudolf

 

[Lew]

According to wikipedia the last version is from december 2002.

That level of activity could be considered dead.

It would for almost any other software. Tex has some
"absolute" over it, so I am not sure normal software
practices apply.

But you could argue based on that.

No, you present good evidence that TeX is a dead end. It still doesn't

Plenty of brilliant programmers have written software that is no longer used
(except in legacy use cases). Good software, too. I suppose what I was
reacting to was the notion that TeX was a dead end at the time Knuth came up
with it, and that that somehow invalidated the accomplishment of coming up
with TeX.

The fact that it is still in use even five years after cessation of
development does mitigate the "dead end" assessment at least potentially.

 

[Lew]

For the love of the Perl, Python, Lisp, Java and functional
programmers, please just give an abstract of what you've written and
link to it?

I expect you'll be ignored on that. Xah Lee reposts and reposts these essays
from years agone. I don't even read his posts, just the responses.

 

[llothar]

That level of activity could be considered dead.

For me at least 2% of the total line count should be changed
to call it non dead.

I don't say it it not used anymore for users it might be
not dead but this is not the point under discussion here.

 

[llothar]

Depends obvious a bot on what you consider serious math.

Expression evaluation, floating point characteristics, relational
database theory, simulation, optimum location, encryption etc.
are all based on mathematics of different levels.

Thats not i call serious maths. You just need a very little
understanding
here for all this concepts. A "extended high school degress" should be
well
enough (based on our education system in Germany - don't know how much
math
you do in a US high schoool). A little bit set theory and of course
boolean
algebra (on a very low level but unfortunately not teached in school).

But where do you need the way to prove mathematical theorems and this
is what
i call as serious math. You don't need to prove anything you just need
to
use it. (In 95% of all programming, except some embedded programming
with
DSP's or numeric.)

I think you will find it very difficult to write a piece of code
that are not heavily influenced by Knuth.

Well programming in the small like sort algorithms for sure. But not
for his great discoveries but for one of the first man who was paid
for this by this university employee.

But in the field of software enginering as i said before he
completely
failed. And for me programming is just another word for software
engineering these days.

 

[Lew]

For me at least 2% of the total line count should be changed
to call it non dead.

I don't say it it not used anymore for users it might be
not dead but this is not the point under discussion here.

No, there are two points - not whether Tex is "dead", but whether it's a "dead
end" (which do you mean?), and whether in any way that says anything about
Knuth's ability as a programmer.

Evidence is that TeX development is dead. There is not yet firm evidence that
Tex is a "dead end" (or even what that means), and there has been none (nor, I
expect, is there any) that any of that reflects on Knuth's skill as a programmer.

The switch from asserting "dead end" to asserting "dead" is sort of an
interesting rhetorical device. Just pick one or the other, or if you prefer,
assert both, but please be clear. Should we just accept that you meant, "less
than 2% of total line count changed"? Per year? Per century? What if the
code is perfect and has no need of change? Is it (a) dead (end)?

(Who uses line count as a metric of anything any more?)

 

[Lew]

Well programming in the small like sort algorithms for sure. But not
for his great discoveries but for one of the first man who was paid
for this by this university employee.

What a curious thesis.

But in the field of software enginering as i said before he
completely
failed.

As you said, but for which you provided absolutely no evidence, and the
counter evidence that Arne provided is that he has not "completely" failed for
any useful value of "failed". Statements of absolute only need one
counterexample. /The Art of Programming/ is arguably the most significant
contribution to the field of software engineering. By any reasonable
assessment, on the basis of that one work alone Knuth was a success.

Your rhetorical tack of unfounded assertions and inflammatory
characterizations, not to say complete disregard for the reality of the
situation, do not make a cogent case, much less a convincing one.

I am afraid that your conclusion is quite mistaken. Knuth is, if anything, a
huge success in the field of software engineering, whether you rate it as
making a contribution to the art, or as being paid to perform the art.