utx00

you may want to take a look at http://www.kernel.org/pub/software/scm/git/docs/git-submodul.... mercurial lacks this as of now.

this is the best post ever. you can move to a non-competitive place. somewhere in the south maybe. you won't have to work long days, or even a lot.

good luck on your "travels".

booya!

but that is (one of) the point of the index. that you can build of to a clean changeset to commit. hg mq is easier i think.

i prefer hg too.

cheap local branching: there's bookmarks, there's named branches, and there is mq. one of the cool things about mq is that the patch queues can themselves be an hg repo. so if you're using a patch queue like you would the git index, you can 'push' that state somewhere else as way of backup. can one do that with the git-index? (if you rsync your tree, get ready to rsync huge pack files everytime they change .. see below)

everything is local: this is the exact same thing on git and hg. hg incoming means check another repo for incoming changesets. ergo it needs to contact that repo which need not be remote.

git is fast: we have our source tree in hg and git. ~10k files plus binary stuff. no one notices any difference. on windows, hg is faster.

git is small: maybe so. but you have to remember, (and perhaps understand) about git-repack and friends. hg, is like a self-cleaning oven in this regard.

staging area: if one needs such a thing, there are mercurial queues. if you dont, it's not in your way.

distributed: yes. hg is distributed. that's why it has commands like incoming.

any workflow: same thing in both.

github: http://www.bitbucket.org/

easy to learn: git is easier to learn than mercurial?

ok, now here's what i don't like about git:

storage: it's annoying to have to setup git-repacks jobs for each repo, but that's fine. the real killer for us is that it kills our incremental backup strategy. every time you repack you create a new pack file (in our case huge) and you have to back it up again. in mercurial you can back up the files that changed.

bundles: git now has them but they started in mercurial. i'm putting this down because there seems to be this perception that all the cool stuff happens first in git.

index: fine after you're a pro, but we have had accidents. learning curve is a bit strict with git.

documentation: better in hg. much better actually.

git has gone through a lot of interface changes. is cogito still in use? and then they broke renaming at one point. i'm sure these things are fixed, but we've had no such issues in hg thus far.

in the end they both rock, but i prefer hg.

<sarcastic> sounds like fun </sarcastic>

Unlike Qi I, Qi II allows you to embed sequent rules within functions, evaluating them to closures. These rule closures are type checked and are permeable to having their variables lexically bound from outside the scope of the rule itself. These devices enable the student of computational logic to effortlessly code complex logical systems of all descriptions. Thus the rule

let PTerm/X (replace-by X Term P)

PTerm/X, (all X P) >> Q;

____________________

(all X P) >> Q;

allows universally quantified assumptions to be instantiated to new premises. This rule can be embedded into a Qi II function called all-left which does precisely this job. The rule is turned into a closure by the rule function which is then applied to the problem (list of sequents).

(define all-left

{term --> [sequent] --> [sequent]}

Term S -> ((rule let PTerm/X (replace-by X Term P)

PTerm/X, (all X P) >> Q;

____________________

(all X P) >> Q;) S))

thanks. i stopped using it about a year ago because it was getting really slow. maybe i should have another looksie.

ah thanks. is there a limit?

i'm just trying to bookmark this article so that it appears under my comments. if anyone can suggest a better way (and bookmarking on the browser is not good enough, as i move around computers all day)

bmk

could one even hold on?!

too difficult

no

still files as in "we're looking at something else"?

bookmark

do you know if its possible to find emulators? or even the machines themselves?

thanks!

not what i meant, but i like the sentiment.

ha! thanks man (or gal)

does anyone know if there is one like this written in common lisp?

that's interesting. in the original german! you're braver than me.

i think DSL's are good for the same points you bring up. i am more concerned with the DSL ability to express a problem/solution. the DSL itself of course necessitates different expertise. just like there a lots of python users, but only a few people who work on the python core. or for that matter linux users vs the linux kernel team.

sure. but i only put forward the 'expand your intuition" argument as a rebuttal to your "models of understanding". i am saying though that the very same concepts that gave rise to lisp, also make it more powerful in practice. "in the field" as they say. but it takes a little practice to get there.

yes, lisp won't ever be more popular. just like "30 Rock" won't ever be more popular than "the office"

sorry, i meant explicitly to a computer.

some of the ideas i need to express in order to make a living are not so easily expressed in python:

http://news.ycombinator.com/item?id=343738

yes, but you have the ability to tailor the language and create constructs to deal with your problems more concisely.

i learned lisp before C. i always found C to be very obtuse and arbitrary. for example:

1. why can't i define a function inside a function and then return it, why can't i define a function based on some conditional?

2. macros that are just text expansions are useless (well not useless but in comparison to lisp macros!)

3. no way to embed a mini language. or way, but too difficult. in lisp you don't even have to think about it. (a little query language, or a little configuration language, or a language to do gene annotations based on certain protein sequences that non-computer people can write in :)

4. you have to compile and use a debugger. in lisp you can change and run things as you write them.

5. recursion is unequivocally expensive.

6. can't write new iteration constructs (or you can by passing function pointers but it's limited and ugly)

7. no anonymous functions! c'mon!

etc etc

so the fact that lisp doesn't map into a preconceived model of understanding has very little practical significance ... C, by all measures, is less powerful and wouldn't allow me to do my work with reasonable amount of effort. neither would python btw. as i maintain a domain specific language that would have been very difficult to write in some other language.

they are different domains of expression. so that should not come as surprise. maybe one day when computers are super powerful. for now "code is data and we write in the same data structures the compiler understands" seem like the bigger win. that of course means a lisp of some sort.

on the surface. yes. which one do you consider more powerful as a tool for expressing ideas?

But who's to say your experience with a given subject domain does not expand your intuition and creates new models of understanding?

btw, if object is not null is closer to (nil? object) than to (list '1 '2 'foo)

lisp may not be simpler, it is more powerful. it is a distillation of the ideas that gave rise to computer languages.

please explain.

Danielle Steele vs. Jane Austen ... or something.

are the axioms of non-euclidean geometry obvious? what about special relativity?