... designed for visualizing and exploring software architecture and any other information space. SHriMP (Simple Hierarchical Multi-Perspective) is a domain-independent visualization technique designed to enhance how people browse and explore complex information spaces. Among the applications we are actively exploring is the exploration of large software programs, and the understanding of complex knowledge-bases (via the Protégé tool)."
Currently SHriMP runs both as a standalone application and, using the Creole plugin, inside Eclipse to augment its existing, extensive code browsing capabilities. There's also a plugin for Protégé, a Stanford project to build "an ontology editor and a knowledge-base editor" supporting new techologies such as OWL.
While Creole is currently Java-specific, SHriMP is a generic framework for code visualization.
Oslo (the capital of Norway, north of Denmark) introduced ad-financed bicycles last year. For 50 NOK ($8) per year -- roughly 2 cents a day -- you get access to the bikes, which are parked at dedicated bike stations around the city.
There are some annoying restrictions; once checked out, a bike must be returned within a couple of hours, and while you are not held responsible for any damage incurred to the bike, you are held economically liable if a bike is stolen, which means that you either have to carry a bike chain around with you, or always park the bike in the nearest station when, say, visiting a shop. Also, bikes may not be checked out between midnight at 6 AM.
The city of Trondheim has had a similar service for several years.
What's wrong with abstract base classes and inheritance?
Nothing -- if you use them correctly. In the case of Lucene, there is no clear separation between interface and implementation, and the implementation itself frequently violates good design principles such as separation of concerns and encapsulation. (The author of Lucene also seems ignorant of the fact that Java has an interface keyword. Pure abstract base classes have their place in MI languages like C++, of course.)
Unfortunately, the project never gained critical mass, so it was deemed best to close it (in August, 2004).
Wrong Commons. It's called Jakarta Commons and is alive and, despite a certain tendency to include crappy, hastily-thought-out and sloppily-designed implementations, generally considered well.
cglib, a library that lets you do metaclass programming efficiently in Java; it's similar to java.lang.reflect.Proxy, but more flexible and compiled to bytecode. Cglib is commonly used to create decorators -- for example, Hibernate uses it to generate proxies, to transparently track whether persistent objects have changed in memory and must be re-saved to the database -- but there are other uses, such as mimicking the mixin pattern.
Xalan for XSLT and XPath processing. Here's a tip: Never, ever use SAX for XML parsing of application-specific data structures. SAX is a nice low-level interface for building upon, but unless you're programmatically emitting a document from scratch, it's painful to use -- you always end up writing a stack-based content handler to keep nesting state. XPath makes parsing a breeze.
JGroups (formerly JavaGroups) is a protocol stack for building reliable, fairly efficient network communications based on, among other things, multicast IP. The entire stack is user-defineable, so you can pick and choose the level of reliability and which features you want (TCP support, pinging, group membership management etc.).
Lucene is a text-indexing engine. It's actually pretty crap, and does not scale very far (we're talking a few seconds for result sets of only a few thousand documents), and the code is pure spaghetti (abstract base classes! Inheritance!), but if you need a little indexing engine or some decent text tokenization classes, and your performance requirements are modest, it works well enough.
SableCC is a good BNF-based parser generator that generates type-safe parse trees that can navigated at runtime. Unlike the more well-known JavaCC, it's easy to get started, not least because the BNF-like grammar is so simple.
The reason I'm not taking you seriously is because you don't even seem to be aware of the arguments for and against dynamically types languages. I mean, you havn't even mentioned unit testing yet.
Please. I mentioned unit testing in my first reply, where I wrote:
The uncertainty involved in the dynamic typing/late binding model of such languages is compensated for through unit testing.
I also linked to an interview with Guido van Rossum where he talks about this very topic, so if you think I'm ignorant of the issues involved, you must be purposely ignoring what I'm writing. Thanks for trolling again.
This has already happened for languages like Eiffel where verification of object contracts is now automated. These methods are becoming available for Java too.
Sorry, but interface contracts have very little to do with static type checking.
A pre-condition is typically something like whether a value is within a range, or that an argument is not null, or an array has a certain length, or that an instance is of a certain class at runtime; not whether it's an integer or a string.
Design by contract, being unrelated to static type checking, is therefore a concept that is equally applicable to both statically- and dynamically-typed languages, the main difference being that in a dynamically typed language, the checks may only occur at runtime.
There is nothing preventing dynamically typed languages from doing automated type checking. This and this
make a good start. The latter is similar to Java 5.0's annotation system.
As for unit tests consisting of type checks, you will probably find that the overlap is larger than you think. Even if a method in Java returns a StringBuffer object, the Java interface can never explain what the contract is: whether it's allowed to return null, whether it always returns a different instance, what that object is supposed to contain.
You will find that in Python, for example, the checks are more or less the same; if the method returned Fnarg instead of the expected object, your test will fail -- unless Fnarg happens to behave like what you wanted, in which case everything is all right.
As for input, regardless of the type of language, throwing garbage at functions is always useful; with dynamically typed languages, you might just end up throwing a little more garbage.
Unit tests are supposed to be simple and quick to write. Languages like Python are known to support much more rapid development. Even if you add 20% more checks, you'll still come out on top. Ever worked with lists and maps in Java? They're not first-class objects, so they're a nightmare to manipulate. Such structures are extremely common in tests. (I have been writing Java and Python unit tests every day for four years, so I know where the differences are.)
(As an aside, if in your mention of Eiffel you're referring to design by contract, the concept was invented for Eiffel, so saying it's "now automated" is like saying the Eiffel tower is now made out of steel.)
So the fact that there are absolutely no static type checking tools for Javascript has no affect on its maintainability?
Yes. JavaScript is a poor language, but for other reasons than a lack of a static type system.
Get a grip sunsine.
You're obviously trolling. Present us with arguments supporting to the proposition that dynamic typing decreases maintainability, and we'll have a discussion. Until then, you're just spouting FUD.
I have already given ample explanations for my view, but here's a counter-argument to the specific case of typing: Static typing, unless implemented from the bottom up with Ocaml-style type inference (which leads to other interesting problems), adds more metadata to the program, which adds to the amount of text that must be typed, read, digested. Compare:
int a = 1;
with
a = 1
The intent, in both cases, is absolutely clear. The second syntax is simpler, shorter, and more readable.
Readability is a huge maintenance consideration. Ease of refactoring is another; if a should be changed to be short, much use of the variable needs to update to accomodate this change -- expressions, function calls, function prototypes and so on. This is why nascent IDEs such as Eclipse focus so much on automatic refactoring, because refactoring is a pain to do in statically-typed languages.
Every single language you've mentioned there are NOT maintainable. Why? Cause they're all interpreted dynamic languages. It's fun and all to write in these languages and get stuff done with them but as soon as you spot a bug you have a hell of a time to... blah blah... not suitable for production systems.
First, the term "interpreted dynamic language" is vague and misleading. Interpretation has nothing to do with code maintainability. (You can interpret C, and you can compile putatively interpreted languages such as Java and Python to native code; indeed Java has been natively compiled for years, and the fact that it is just-in-time compilation is irrelevant).
And what does "dynamic" mean? Do you mean a dynamically, as opposed to statically, typed language? Do you mean runtime introspection? Self-modification and metaprogramming? Runtime name resolution? What?
I suspect you mean a combination of these. Python, Perl, Ruby, JavaScript, PHP, Haskell, Lisp and OCaml have these features. C++ can be considered a "dynamic" language, as can Java, C#, etc. So why do you claim that these languages are not maintainable?
These newfangled languages are more rapid to develop in than lower-level languages. Maintenance is simpler because the languages are simpler, higher-level and more easily maintained. For example, the absence of a separate compile/link cycle means I can get from changing a source line to testing the source line quicker.
In many cases, reproducing or debugging a bug is simpler in, say, Python than in C, because the infrastructure itself is simpler. Pure Python, for example, does not have memory access violation errors; there's no way your Python code can read or write an invalid pointer, write beyond the end of a buffer and so on; a whole class of pointer errors, most of which have security repercussions, are annihilated by this feature. Similarly, Python uses exceptions, so nobody can forget to check and propagate a function's error return value.
More often than not, errors that surface in these languages are high-level problems, which is good, because those are simpler than the ones involving someone forgetting to call free() on an allocated buffer or accounting for overflow when shifting a bit mask.
The uncertainty involved in the dynamic typing/late binding model of such languages is compensated for through unit testing.
Oh, and JavaScript, a "dynamic language", is being used by Google in a production system, and Google is known to use Python and Ruby in their systems. I suggest you call them up and tell them their languages aren't suitable.
Is there an easy way to make Knoppix -- or some other live CD distribution -- spill the install over into a hard drive?
I would like to have a persistent home directory. I want the configuration to be persistent. I want to be able to install packages, because Knoppix does not cover all I need, but I want the packages managed by APT.
The persistent stuff could easily sit on a network share, although local hard drive would be preferable for latency reasons.
And I don't want to accomplish this using someone's alpha-quality "well, I made these, they seem to work for me" scripts.
A poster found in an obscure place in a tiny European country does not "mainstream" make...
Nice. Oslo is the capital of Norway. We are not some backwater nation; our population is arguably more tech-savvy than the US, especially with regard to Internet and cell phone usage (and to cite another interesting example, PayPal is essentially useless within this country, because everyone can send money to each others' accounts, online and elsewhere, and have been doing this since before the 'net).
Regardless of our technology, statistically Norway is as good a pulse to check as any European country, a microcosmos mirroring the world at large. The fact that Firefox is becoming mainstream in Norway is a sign that it's becoming mainstream everywhere. Regardless, the fact it's becoming mainstream here is interesting enough in itself.
putting phrases in like :
new general-purpose multi-paradigm
is going to lead me to believe that it was developed by an Executive, a consultant, or, worst of all, a corporate motivational speaker!
What's the problem? General-purpose isn't a buzzword, and multi-paradigm is a common way to describe languages that aren't restricted to just one style of programming, such as imperative programming, object-oriented programming, functional programming... just because paradigm is a fancy-pancy word does not mean it's meaningless. Whatever its merits/demerits, clearly Heron is a general-purpose, multi-paradigm language.
In related news, this poster is appearing all over Oslo, Norway. Spotting it the other day was one of those unwordly moments where you're seeing a little-known niche thing becoming mainstream. Then yesterday I had a meeting with the IT manager at a government agency; those guys have always been Internet Explorer users, and now Firefox was running on the guy's desktop. The fact that Firefox is actively competing with IE now is going to be good for the Internet.
You would use Zope as a dumb, albeit journaled and transactional, file storage, though the files themselves will be stored in an opaque (object database) format; in other words, the only way to access the files will be through WebDAV (or FTP, which Zope also supports).
Do you need to run a unique UNIX user account and have a special program to pop3 the patches?
No. The receiver end is you and your email program. You accept patches by piping the patch to "darcs apply". You reject patches by doing nothing (or replying with a rejection note). Writing a macro in Mutt og Emacs or whatever should be trivial.
How can you "cherry-pick" the patches
You pull selectively by patch name: "darcs -p regexp".
It's a big feature because it underlies Darcs' branching support. Darcs doesn't have a command to copy something within the repository; rather, you copy the entire repository.
3) Repository Permissions
Do you use them? Most people don't, as far as I know.
4) Ability to Work only on One Directory of the Repository (svn is much more flexible in this regard)
Your comment would still be correct if I changed every occurence of "darcs" with "arch" (except for the command lines, of course).
Not quite. Arch isn't simple to use.
So, what's the difference between Arch and Darcs?
From the perspective of a Darcs user:
Darcs is much simpler to use.
Darcs doesn't have branches, because every repository is conceptually a branch.
Darcs' patch format is just text (Arch uses a tarball).
Darcs has no notion of persistent file identity (which I consider a plus).
Darcs involves less typing; a repository is just a directory, or an SSH path, or an HTTP URL; compare that to Arch's tendonitis-inducing archive/patch/branch names:
lord@emf.net--2003-example/hello-world--mainline-- 0.1--patch-1.
(Yes, you will need to type this all the time on command lines.)
Arch has the concepts of archives -- every user first has to set up an archive into which you pull repositories. You then check out code from your archive, check it back in it. Very tedious. In Darcs, a repository is analogous to Arch's archive.
The archive concept also increases the number of commands Arch has support: in addition to the normal checkout, commit etc. commands, it must support a similar, orthogonal set of commands for manipulating archives, and it has to have all this glue for tying archives and repositories.
To Arch's defense, you don't need to know every command; some of them are fairly esoteric.
Try the Arch tutorial someday. It's an incredibly long and tedious tutorial, and by the end of it, you probably won't remember the command to set up a new archive.
Comparing Darcs and Arch feels a bit like comparing Python and Java (or, in terms of typing, Lisp and Dylan).
One of the nice things about subversion (recently converted user, very happy so far) is the support for multiple url formats and communications methods.
Darcs and Arch both have this. (Arch undoubtedly has the most extensive protocol support of any revision control system.)
Another notable thing (for windows users) is TortoiseSVN, (an explorer shell extension) which is just great.
Tortoise is quite nice indeed -- I used TortoiseCVS for years.
I can see how the distributed, multi-repo model of bitkeeper/darcs/arch is superior but svn looks good if you only need single-repo.
Need is just one aspect of the development process; right now CVS gives most people what they need, despite the cracks in the lacquer. Darcs doesn't just erase the cracks, but improves the process.
For example, I occasionally submit patches to certain open-source projects. The easiest way to do this is to check out the CVS repository, make my changes, and do "cvs diff -u" to get the patches in that format, which I tend post to some Bugzilla server or email to somebody. But I can't commit them. I don't mean to the master repository -- I mean locally. There's no way I can bundle my file patches in a changeset and keep its history. I'm basically managing a CVS working directory where my changes are never checked in.
With Darcs, I just do "darcs get" to get the master repository, make my changes, commit them locally. I can use "darcs send" to submit my changes to the project maintainer. Anyone else can grab my patches with "darcs get" or "darcs pull". I can be Alan Cox to some Linus without breaking my back over patch management.
Subversion runs through Apache/2, so if you've got ssl setup in Apache, you have SSL on your repository...
Sorry, but we were talking about simplicity here. Apache 2.0, SSL, authentication, WebDAV... Setting up a repository with what you suggest is more than one step -- it's usually a lot of steps, especially considering Subversion's external dependencies.
Setting up a Darcs repository consists of doing this:
$ darcs init
And Darcs works over SSH:
$ darcs get bob@example.com:/some/project
This gives you security (leveraging the public-key encryption system of OpenSSH) without having to set up Apache, SSL, virtual hosts, WebDAV or authentication.
You can also use Darcs read-only over HTTP (the following will check out the Darcs sources):
$ darcs get http://www.abridgegame.org/repos/darcs/
All that's required is a web server mapping the URL to your repository -- any one will do.
Let me summarize the "theory of patches": you reverse patches in the opposit order of applying them.
No. Darcs can, and will, apply patches out of order. From the Darcs manual:
The development of a simplified theory of patches is what originally motivated me to create darcs. This patch formalism means that darcs patches have a set of properties, which make possible manipulations that couldn't be done in other revision control systems. First, every patch is invertible. Secondly, sequential patches (i.e. patches that are created in sequence, one after the other) can be reordered, although this reordering can fail, which means the second patch is dependent on the first. Thirdly, patches which are in parallel (i.e. both patches were created by modifying identical trees) can be merged, and the result of a set of merges is independent of the order in which the merges are performed. This last property is critical to darcs' philosophy, as it means that a particular version of a source tree is fully defined by the list of patches that are in it, i.e. there is no issue regarding the order in which merges are performed.
A distributed version control system that required all patches to be applied in order would be painful indeed to use.
I have to agree with many other comments: the use of haskell eliminated it as a choice for me.
Slashdot Mirror
I was actually going to mention JQuery, but changed my mind. But some people might find it useful.
Currently SHriMP runs both as a standalone application and, using the Creole plugin, inside Eclipse to augment its existing, extensive code browsing capabilities. There's also a plugin for Protégé, a Stanford project to build "an ontology editor and a knowledge-base editor" supporting new techologies such as OWL.
While Creole is currently Java-specific, SHriMP is a generic framework for code visualization.
There are some annoying restrictions; once checked out, a bike must be returned within a couple of hours, and while you are not held responsible for any damage incurred to the bike, you are held economically liable if a bike is stolen, which means that you either have to carry a bike chain around with you, or always park the bike in the nearest station when, say, visiting a shop. Also, bikes may not be checked out between midnight at 6 AM.
The city of Trondheim has had a similar service for several years.
Postgre? It's called PostgreSQL.
And to answer your question, it is an acceptable RDBMS for a small business.
Nothing -- if you use them correctly. In the case of Lucene, there is no clear separation between interface and implementation, and the implementation itself frequently violates good design principles such as separation of concerns and encapsulation. (The author of Lucene also seems ignorant of the fact that Java has an interface keyword. Pure abstract base classes have their place in MI languages like C++, of course.)
Wrong Commons. It's called Jakarta Commons and is alive and, despite a certain tendency to include crappy, hastily-thought-out and sloppily-designed implementations, generally considered well.
Xalan for XSLT and XPath processing. Here's a tip: Never, ever use SAX for XML parsing of application-specific data structures. SAX is a nice low-level interface for building upon, but unless you're programmatically emitting a document from scratch, it's painful to use -- you always end up writing a stack-based content handler to keep nesting state. XPath makes parsing a breeze.
JGroups (formerly JavaGroups) is a protocol stack for building reliable, fairly efficient network communications based on, among other things, multicast IP. The entire stack is user-defineable, so you can pick and choose the level of reliability and which features you want (TCP support, pinging, group membership management etc.).
Lucene is a text-indexing engine. It's actually pretty crap, and does not scale very far (we're talking a few seconds for result sets of only a few thousand documents), and the code is pure spaghetti (abstract base classes! Inheritance!), but if you need a little indexing engine or some decent text tokenization classes, and your performance requirements are modest, it works well enough.
SableCC is a good BNF-based parser generator that generates type-safe parse trees that can navigated at runtime. Unlike the more well-known JavaCC, it's easy to get started, not least because the BNF-like grammar is so simple.
Doctors Without Borders.
Thanks, but that would be just like installing, say, Debian. No gains, really.
Please. I mentioned unit testing in my first reply, where I wrote:
I also linked to an interview with Guido van Rossum where he talks about this very topic, so if you think I'm ignorant of the issues involved, you must be purposely ignoring what I'm writing. Thanks for trolling again.
Sorry, but interface contracts have very little to do with static type checking.
A pre-condition is typically something like whether a value is within a range, or that an argument is not null, or an array has a certain length, or that an instance is of a certain class at runtime; not whether it's an integer or a string.
Design by contract, being unrelated to static type checking, is therefore a concept that is equally applicable to both statically- and dynamically-typed languages, the main difference being that in a dynamically typed language, the checks may only occur at runtime.
There is nothing preventing dynamically typed languages from doing automated type checking. This and this make a good start. The latter is similar to Java 5.0's annotation system.
As for unit tests consisting of type checks, you will probably find that the overlap is larger than you think. Even if a method in Java returns a StringBuffer object, the Java interface can never explain what the contract is: whether it's allowed to return null, whether it always returns a different instance, what that object is supposed to contain.
You will find that in Python, for example, the checks are more or less the same; if the method returned Fnarg instead of the expected object, your test will fail -- unless Fnarg happens to behave like what you wanted, in which case everything is all right. As for input, regardless of the type of language, throwing garbage at functions is always useful; with dynamically typed languages, you might just end up throwing a little more garbage.
Unit tests are supposed to be simple and quick to write. Languages like Python are known to support much more rapid development. Even if you add 20% more checks, you'll still come out on top. Ever worked with lists and maps in Java? They're not first-class objects, so they're a nightmare to manipulate. Such structures are extremely common in tests. (I have been writing Java and Python unit tests every day for four years, so I know where the differences are.)
(As an aside, if in your mention of Eiffel you're referring to design by contract, the concept was invented for Eiffel, so saying it's "now automated" is like saying the Eiffel tower is now made out of steel.)
- So the fact that there are absolutely no static type checking tools for Javascript has no affect on its maintainability?
Yes. JavaScript is a poor language, but for other reasons than a lack of a static type system.You're obviously trolling. Present us with arguments supporting to the proposition that dynamic typing decreases maintainability, and we'll have a discussion. Until then, you're just spouting FUD.
I have already given ample explanations for my view, but here's a counter-argument to the specific case of typing: Static typing, unless implemented from the bottom up with Ocaml-style type inference (which leads to other interesting problems), adds more metadata to the program, which adds to the amount of text that must be typed, read, digested. Compare:
withThe intent, in both cases, is absolutely clear. The second syntax is simpler, shorter, and more readable.Readability is a huge maintenance consideration. Ease of refactoring is another; if a should be changed to be short, much use of the variable needs to update to accomodate this change -- expressions, function calls, function prototypes and so on. This is why nascent IDEs such as Eclipse focus so much on automatic refactoring, because refactoring is a pain to do in statically-typed languages.
This is a myth, and has been proven false countless of times, such as by these guys, or these guys, or even these guys, or, God forbid, you may have heard of these guys.
First, the term "interpreted dynamic language" is vague and misleading. Interpretation has nothing to do with code maintainability. (You can interpret C, and you can compile putatively interpreted languages such as Java and Python to native code; indeed Java has been natively compiled for years, and the fact that it is just-in-time compilation is irrelevant).
And what does "dynamic" mean? Do you mean a dynamically, as opposed to statically, typed language? Do you mean runtime introspection? Self-modification and metaprogramming? Runtime name resolution? What? I suspect you mean a combination of these. Python, Perl, Ruby, JavaScript, PHP, Haskell, Lisp and OCaml have these features. C++ can be considered a "dynamic" language, as can Java, C#, etc. So why do you claim that these languages are not maintainable?
These newfangled languages are more rapid to develop in than lower-level languages. Maintenance is simpler because the languages are simpler, higher-level and more easily maintained. For example, the absence of a separate compile/link cycle means I can get from changing a source line to testing the source line quicker.
In many cases, reproducing or debugging a bug is simpler in, say, Python than in C, because the infrastructure itself is simpler. Pure Python, for example, does not have memory access violation errors; there's no way your Python code can read or write an invalid pointer, write beyond the end of a buffer and so on; a whole class of pointer errors, most of which have security repercussions, are annihilated by this feature. Similarly, Python uses exceptions, so nobody can forget to check and propagate a function's error return value.
More often than not, errors that surface in these languages are high-level problems, which is good, because those are simpler than the ones involving someone forgetting to call free() on an allocated buffer or accounting for overflow when shifting a bit mask.
The uncertainty involved in the dynamic typing/late binding model of such languages is compensated for through unit testing.
Oh, and JavaScript, a "dynamic language", is being used by Google in a production system, and Google is known to use Python and Ruby in their systems. I suggest you call them up and tell them their languages aren't suitable.
I would like to have a persistent home directory. I want the configuration to be persistent. I want to be able to install packages, because Knoppix does not cover all I need, but I want the packages managed by APT.
The persistent stuff could easily sit on a network share, although local hard drive would be preferable for latency reasons.
And I don't want to accomplish this using someone's alpha-quality "well, I made these, they seem to work for me" scripts.
Any pointers?
Nice. Oslo is the capital of Norway. We are not some backwater nation; our population is arguably more tech-savvy than the US, especially with regard to Internet and cell phone usage (and to cite another interesting example, PayPal is essentially useless within this country, because everyone can send money to each others' accounts, online and elsewhere, and have been doing this since before the 'net).
Regardless of our technology, statistically Norway is as good a pulse to check as any European country, a microcosmos mirroring the world at large. The fact that Firefox is becoming mainstream in Norway is a sign that it's becoming mainstream everywhere. Regardless, the fact it's becoming mainstream here is interesting enough in itself.
What's the problem? General-purpose isn't a buzzword, and multi-paradigm is a common way to describe languages that aren't restricted to just one style of programming, such as imperative programming, object-oriented programming, functional programming... just because paradigm is a fancy-pancy word does not mean it's meaningless. Whatever its merits/demerits, clearly Heron is a general-purpose, multi-paradigm language.
In related news, this poster is appearing all over Oslo, Norway. Spotting it the other day was one of those unwordly moments where you're seeing a little-known niche thing becoming mainstream. Then yesterday I had a meeting with the IT manager at a government agency; those guys have always been Internet Explorer users, and now Firefox was running on the guy's desktop. The fact that Firefox is actively competing with IE now is going to be good for the Internet.
It turns out that Polystyrene (aka styrofoam) is also a viable and cost-effective building material, currently being planned for deployment in Afghanistan by the Federation of American Scientists. According to this blog entry, "the New Harmony House (in New Harmony, Indiana) was built using this material as a demonstration, with impressive results (including the house using 50-70 percent less energy than a conventionally-constructed home)."
You would use Zope as a dumb, albeit journaled and transactional, file storage, though the files themselves will be stored in an opaque (object database) format; in other words, the only way to access the files will be through WebDAV (or FTP, which Zope also supports).
No. The receiver end is you and your email program. You accept patches by piping the patch to "darcs apply". You reject patches by doing nothing (or replying with a rejection note). Writing a macro in Mutt og Emacs or whatever should be trivial.
You pull selectively by patch name: "darcs -p regexp".
How does this affect users?
It's a big feature because it underlies Darcs' branching support. Darcs doesn't have a command to copy something within the repository; rather, you copy the entire repository.
Do you use them? Most people don't, as far as I know.
Agreed.
Agreed. They're coming.
Darcs is also CVS-ish.
Not quite. Arch isn't simple to use.
From the perspective of a Darcs user:
Darcs is much simpler to use.
Darcs doesn't have branches, because every repository is conceptually a branch.
Darcs' patch format is just text (Arch uses a tarball).
Darcs has no notion of persistent file identity (which I consider a plus).
Darcs involves less typing; a repository is just a directory, or an SSH path, or an HTTP URL; compare that to Arch's tendonitis-inducing archive/patch/branch names: lord@emf.net--2003-example/hello-world--mainline-- 0.1--patch-1.
(Yes, you will need to type this all the time on command lines.)
Arch has the concepts of archives -- every user first has to set up an archive into which you pull repositories. You then check out code from your archive, check it back in it. Very tedious. In Darcs, a repository is analogous to Arch's archive.
The archive concept also increases the number of commands Arch has support: in addition to the normal checkout, commit etc. commands, it must support a similar, orthogonal set of commands for manipulating archives, and it has to have all this glue for tying archives and repositories.
How many commands do Darcs and Arch have?
To Arch's defense, you don't need to know every command; some of them are fairly esoteric.
Try the Arch tutorial someday. It's an incredibly long and tedious tutorial, and by the end of it, you probably won't remember the command to set up a new archive.
Comparing Darcs and Arch feels a bit like comparing Python and Java (or, in terms of typing, Lisp and Dylan).
If you had tried to duplicate the other steps in my little tutorial, you would have seen why RCS doesn't cut it. RCS isn't a distributed system.
Darcs and Arch both have this. (Arch undoubtedly has the most extensive protocol support of any revision control system.)
Tortoise is quite nice indeed -- I used TortoiseCVS for years.
Need is just one aspect of the development process; right now CVS gives most people what they need, despite the cracks in the lacquer. Darcs doesn't just erase the cracks, but improves the process.
For example, I occasionally submit patches to certain open-source projects. The easiest way to do this is to check out the CVS repository, make my changes, and do "cvs diff -u" to get the patches in that format, which I tend post to some Bugzilla server or email to somebody. But I can't commit them. I don't mean to the master repository -- I mean locally. There's no way I can bundle my file patches in a changeset and keep its history. I'm basically managing a CVS working directory where my changes are never checked in.
With Darcs, I just do "darcs get" to get the master repository, make my changes, commit them locally. I can use "darcs send" to submit my changes to the project maintainer. Anyone else can grab my patches with "darcs get" or "darcs pull". I can be Alan Cox to some Linus without breaking my back over patch management.
Sorry, but we were talking about simplicity here. Apache 2.0, SSL, authentication, WebDAV... Setting up a repository with what you suggest is more than one step -- it's usually a lot of steps, especially considering Subversion's external dependencies.
Setting up a Darcs repository consists of doing this:
And Darcs works over SSH:
This gives you security (leveraging the public-key encryption system of OpenSSH) without having to set up Apache, SSL, virtual hosts, WebDAV or authentication.
You can also use Darcs read-only over HTTP (the following will check out the Darcs sources):
All that's required is a web server mapping the URL to your repository -- any one will do.
I'm sure Subversion works similarly, though.
No. Darcs can, and will, apply patches out of order. From the Darcs manual:
A distributed version control system that required all patches to be applied in order would be painful indeed to use.
Why? Are you a Subversion contributor?