Slashdot Mirror

Have you found one that does handle subprojects well? I use darcs for most everything nowadays, but I'm always open to new ideas.

A lot of this is due to the fact that most popular languages right now do not support concurrency very well. Most common languages are stateful, and state and concurrency are rather antithetical to one another. The solution is to gradually evolve toward languages that solve this either by forsaking state (Haskell, Erlang) or by using something like transaction memory for encapsulating state in a way that is easy to deal with (Haskell's STM, Fortress (I think), maybe some others).

Concurrency is not that hard to do well in the right setting.

And before anyone claims that Haskell and Erlang are impractical, there are many examples of "real world" programs written in them.

A few nice, and very useful ones are Yaws (for erlang) and Darcs (for Haskell). There are many others (even quake clones), which I won't bother listing, but people can find them easily if they look.

Regarding concurrency, and its ease of use in these languages, I'm taking a machine learning class at the moment where most of the problems are computationally intensive, and could stand for improvement by making use of multiple cores. I do all of my assignments in Haskell, and not only are my solutions often shorter than those of my classmates (and they often work fine the first time they compile), but it's usually trivial to allow my application to scale nicely to as many cores as I can throw at it. It's worth mentioning, by the way, that most algorithms given in these classes are given under the assumption that people are using imperative languages, and even then, it's still easy. It takes a while to learn how to approach problems differently without mutable state, yes, but it's not as hard as some people make it out to be. I think it has more to do with the fact that people just don't like to learn anything new unless they absolutely are forced to do so, which is a pity.

By the way, there is a nice presentation from Tim Sweeney on what he would like future programming languages to look like, and there's a lot in there about functional programming, concurrency, and expressive (re: dependent) types.

what CS problem that I might encounter in an upper-division CS course requires the use of Diff. Eq., Linear Algebra or Physics?

To pick just one example, the Kalman Filter, which is used for everything from radar tracking to helicopter stabilization, relies on linear algebra. And physics gives an excellent background in learning to apply mathematical modeling techniques to real-world phenomena. One of the best (or at least most interesting) distributed version control systems out there, Darcs, was written by a physicist, in the Haskell programming language (the latter of course being based on the lambda calculus, another seemingly esoteric subject which is so fundamental that it really ought to be taught in high school). Darcs is based on a physically-inspired theory of patches.

There's a problem here which was described by Paul Graham as "The Blub Paradox" (in Beating the Averages). Graham writes "But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up." It's not easy to correctly assess that which you do not (yet) understand.

The other side of the story is that you're totally right about coding being different from CS. The problem is that most HR/Business types don't know the difference.

I agree, this is a big part of the problem. This comes from the fact that everything about computers, and particularly software, is so relatively new. As alluded to elsewhere in the thread, you don't get HR people trying to hire mathematicians or even economists for accounting positions - they know better than that. They just don't know better than that, yet, when it comes to programming, particularly in "IT". And this confusion affects academic curricula, too - universities want to satisfy the commercial demand with subjects they already teach, and academic computer scientists don't want to turn themselves into a Java instructors any more than they absolutely have to.

It seems the best course of action is to expand software engineering programs to fill the void and make sure those are focused on turning out pratical, level-headed engineers who can solve a variety of problems but do not care to learn any more about math or physics than it takes to get an equation from a mathematician or physicist and implement it.

I think that'd be a start. However, I also think we'll eventually find that the tentacles of software are so diverse that "software engineering" is too broad a subject, and we'll end up with a "software school" analog to "medical school" or "law school", where a wide variety of subjects are taught, including theory, engineering, and other topics. I notice CMU has a "School of Computer Science already, and Northeastern has a College of Computer and Information Science, but most other institutions still treat CS and related disciplines as a "department".

what CS problem that I might encounter in an upper-division CS course requires the use of Diff. Eq., Linear Algebra or Physics?

To pick just one example, the Kalman Filter, which is used for everything from radar tracking to helicopter stabilization, relies on linear algebra. And physics gives an excellent background in learning to apply mathematical modeling techniques to real-world phenomena. One of the best (or at least most interesting) distributed version control systems out there, Darcs, was written by a physicist, in the Haskell programming language (the latter of course being based on the lambda calculus, another seemingly esoteric subject which is so fundamental that it really ought to be taught in high school). Darcs is based on a physically-inspired theory of patches.

There's a problem here which was described by Paul Graham as "The Blub Paradox" (in Beating the Averages). Graham writes "But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up." It's not easy to correctly assess that which you do not (yet) understand.

The other side of the story is that you're totally right about coding being different from CS. The problem is that most HR/Business types don't know the difference.

I agree, this is a big part of the problem. This comes from the fact that everything about computers, and particularly software, is so relatively new. As alluded to elsewhere in the thread, you don't get HR people trying to hire mathematicians or even economists for accounting positions - they know better than that. They just don't know better than that, yet, when it comes to programming, particularly in "IT". And this confusion affects academic curricula, too - universities want to satisfy the commercial demand with subjects they already teach, and academic computer scientists don't want to turn themselves into a Java instructors any more than they absolutely have to.

It seems the best course of action is to expand software engineering programs to fill the void and make sure those are focused on turning out pratical, level-headed engineers who can solve a variety of problems but do not care to learn any more about math or physics than it takes to get an equation from a mathematician or physicist and implement it.

I think that'd be a start. However, I also think we'll eventually find that the tentacles of software are so diverse that "software engineering" is too broad a subject, and we'll end up with a "software school" analog to "medical school" or "law school", where a wide variety of subjects are taught, including theory, engineering, and other topics. I notice CMU has a "School of Computer Science already, and Northeastern has a College of Computer and Information Science, but most other institutions still treat CS and related disciplines as a "department".

Does anyone have good/bad things to say about Darcs

It is written in a purely functional language. The stuff is rooted in a theory of patches.

Does this stuff actually work? Subversion seems like a reworking of CVS (minus the warts). Darcs seems like a different animal.

Does anyone have good/bad things to say about Darcs

It is written in a purely functional language. The stuff is rooted in a theory of patches.

Does this stuff actually work? Subversion seems like a reworking of CVS (minus the warts). Darcs seems like a different animal.

All those languages are very nice until you check the requirements. Let's see an example: darcs. Darcs is an SCM written in Haskell, which is pretty cool. So, in order to build darcs, you need a haskell compiler, which is written in haskell! GHC needs a bootstrapped compiler in order to be able to compile itself.

This same problem exists with java (see how the FreeBSD port pulls a linux-jdk to build the native version), modula3 and IIRC mono. As long as this problem exists those languages will never be that popular. It's true that you need a C compiler to build gcc, but cross compiling C is a mastered art, it's been done for years. Take a look at how you can build the whole NetBSD operating system even from Windows/cygwin and for a different target CPU.

Ugh, Arch is the ugliest distributed system out there. The Darcs guys are working on GIT compatability (linus participated in that linked thread); and I think that has a lot more promise than Arch.

The distributed tools are way more powerful than the centralized systems; so I think it's great to see the Darcs and Monotone groups both interested in the (probably much more performant) Git backend.

(PS: yeah, I know about Arch, but damn that thing's confusing. I'm guessing they borrowed the usability team from clearcase. If you like Arch, it's definately worth checking out Monotone or Darcs. (personally I lean to Darcs because of the cool language it's written in; but like monotone as well)

Might as well mention that it looks like Darcs is getting the git religion also.

Darcs, in particular, is very interesting for its technology. From what I've seen, darcs is currently more of a prototype of some very innovative ideas for SCM, and maybe a tool for smaller projects, rather than a useful tool for large projects, though it can be used.

A few people are looking at SCMs as an interesting technology area to do research in. We need those people, because they create the great new ideas that we want to use! Please research!

But most people are looking for a tool to use, today, to solve their problems in managing very large, complex systems. There are risks to using Darcs that way.

There are lots of such tools, including CVS, Subversion (SVN), GNU arch, Monotone, Aegis, CVSNT, Darcs, FastCST, OpenCM, Vesta, Superversion, Codeville, Bazaar, Arx, and Bazaar-NG.

Actually, Subversion uses a centralised system, which would not necessarily be the best choice for a group of developers used to decentralised control. Better choices would be GNU Arch or Darcs; however neither is really production ready at the moment, though Arch is getting there.

As a result, Linus may indeed end up going for Subversion, but through a lack of options rather than a personal preference

Subversion, of course.

Subversion, of course. What else is there? RCS? CVS?

"The better SCM initiative was established to encourage improved OSS/FS SCM systems, by discussing and comparing them. Among other things, see their comparison file. Zooko has written a short review of OSS/FS SCM tools. Shlomi Fish's OnLamp.com article compares various CM systems as does his Evolution of a Revision Control User. The arch folks have developed a comparison of arch with Subversion and CVS (obviously, they like arch). Another pro-arch discussion is Why the Future is Distributed. A pro-subversion discussion is available at Dispelling Subversion FUD. Slashdot had a discussion when Subversion 1.0 was announced. Kernel traffic posted a summary of a technical discussion about BitKeeper. Brad Appleton has collected lots of interesting SCM links. jemfinch has some interesting essays about SCMs (he uses the term VCS), including why he thinks the approach to branches used by Darcs, Arch, and Bazaar-ng is a poor one. A brief overview of SCM systems that can run on Linux is available."

There are lots of OSS/FS software configuration management (SCM) tools. CVS, Subversion (SVN), and GNU arch get lots of press, but there are many others such as Aegis, CVSNT, Darcs, FastCST, OpenCM, Vesta, Codeville, Bazaar and Bazaar-NG.

You might also take a peek at my paper Software Configuration Management (SCM) Security.

With Bitkeeper it's very easy for every organization - and even every developer - to have his own "fork" of the tree which acts as a "master repository" for others to create branches off of.

Darcs does this. http://abridgegame.org/darcs/

For example, within RedHat, they can have one (or many) child branches from Linus's branch (or any other developer's branches); and "reparent" the branches as needed to merge in the various pieces they need. Other employes' repositories may point to one inside RedHat; or they may point to Linus's; and of course they can "reparent" their repository to switch between the two as needed.

Darcs can do this, although the mechanics may be slightly different. I'm not sure how easy it is to do, as I have never needed to do this.

Similarly, any company or group of developers can have similar structures.

Darcs does this, too.

Also; it's important to note that not everyone needs access to a "master repository"; and that indeed no-one needs access to a "master repository" except when they're merging with that master.

The same is true of Darcs. In fact, with Darcs, you don't even need access to the master repository to send changes to the master repositroy as merges can be sent, via email, to someone who has write access to the repository. Darcs even sends the email for you.

Bitkeeper works perfectly on my laptop in disconnected mode - and I have the full power of the source control system on my laptop even with no net access - I can create branches, merge branches, etc. If I'm traveling with someone else from the company I can merge my branches with his merely with a cable between the laptops - no connection to the home office is needed.

Wow! Darcs works perfectly in disconnected mode, too! I sense a pattern!

http://abridgegame.org/darcs/

Consider darcs. Darcs is free, open source software.

With Bitkeeper it's very easy for every organization - and even every developer - to have his own "fork" of the tree which acts as a "master repository" for others to create branches off of.

Darcs does this. http://abridgegame.org/darcs/

For example, within RedHat, they can have one (or many) child branches from Linus's branch (or any other developer's branches); and "reparent" the branches as needed to merge in the various pieces they need. Other employes' repositories may point to one inside RedHat; or they may point to Linus's; and of course they can "reparent" their repository to switch between the two as needed.

Darcs can do this, although the mechanics may be slightly different. I'm not sure how easy it is to do, as I have never needed to do this.

Similarly, any company or group of developers can have similar structures.

Darcs does this, too.

Also; it's important to note that not everyone needs access to a "master repository"; and that indeed no-one needs access to a "master repository" except when they're merging with that master.

The same is true of Darcs. In fact, with Darcs, you don't even need access to the master repository to send changes to the master repositroy as merges can be sent, via email, to someone who has write access to the repository. Darcs even sends the email for you.

Bitkeeper works perfectly on my laptop in disconnected mode - and I have the full power of the source control system on my laptop even with no net access - I can create branches, merge branches, etc. If I'm traveling with someone else from the company I can merge my branches with his merely with a cable between the laptops - no connection to the home office is needed.

Wow! Darcs works perfectly in disconnected mode, too! I sense a pattern!

http://abridgegame.org/darcs/

Consider darcs. Darcs is free, open source software.

Maybe you'd prefer a haskell implementation ? Darcs is decentralized, based on a "theory of patches" with roots in quantum mechanics.

Written in Haskell, darcs is used on many operating systems including Linux, MacOS X, FreeBSD, and Windows. Darcs includes a CGI script to browse your repository from the web.

Maybe you'd prefer a haskell implementation ? Darcs is decentralized, based on a "theory of patches" with roots in quantum mechanics.

Written in Haskell, darcs is used on many operating systems including Linux, MacOS X, FreeBSD, and Windows. Darcs includes a CGI script to browse your repository from the web.

There are so much real open alternatives like subversion, arch and (my personal favourite) darcs - just to name a few. Why bother with bitkeeper?

End-users will just click the "Download Latest version" and they'll get whatever the newest version is, without worrying about numbers.

End-users who actually care to update their kernel for some specific reason like needing the compatibility for a device driver or to fix a specific bug are indeed going to worry about the numbers. Yes, I'm talking about sysadmins, which I am one of, but I haven't been roped into doing developer type work with the kernel in years. I don't generally compile linux kernels or poke into the source, I just like the vendor to give me a clear picture of which kernel is from what date. This scheme might actually help since it seems likely to create more fine-grained selection points to backport patches from (which redhat will do as long as there's a support schedule for that kernel version). I still think the whole thing's silly and a date-based numbering scheme with a -CURRENT and -STABLE branch would serve linux far better, but there are some upsides to it. Oh dear, time to be accused of BSD zealotry again...

Personally, I think that something like darcs is ideal for something that takes so many patches as a kernel. Something like darcs, I have to stress -- not only is darcs not quite ready for prime time (it's memory hungry when there's a lot of diffs), having to replicate the entire VC tree using forward diffs from a baseline that's over a decade old is probably not ideal. It's also a little too confident in its patch merging scheme, and can get stuck in computationally undecideable traps instead of bailing and calling it a conflict. Still, it's a beautiful VC scheme. ... hmmm, I think I've rambled enough for one post :)

Maybe even arch.

Rule:

If you don't need to spend 5-10% of your development time to speed/size optimizing your program to make it useable, you are not using language/abstractions that is high level enough to your task.

Explanation:

If I use high level languge (say Haskell/OCaml/Clean/Common Lisp) and use all it's abstarction powers, program code will usually be 10-50% of the size compared to same program written in C/C++ (and Even Java). Now that X% (50-90%) of slack will take X% of development time and contain X% of the bugs. It will make the program much harder to change too. You can see that the 5-10% spent into optimization (you can even write the fast parts in C if you like) will pay.

If you don't belive, compare code of gnu-arch arch to darcs. Both are similar version control systems.

New DARCS URL. (Note: Points to same IP address as old URL.)

This sort of behavior is a little easier to cope with, using DARCS, which supports a more anarchic model of many people incestuously forking repositories, passing around patches, etc. Darcs doesn't force you to maintain a central repository or inflict a directory scheme, making it really very friendly for migrating existing projects into the system*.

After having both arch and svn meltdowns, I have moved my projects to darcs, and have been pretty happy with it, since -- I just wish Sourceforge supported it better.

(* The one exception being DARCS's case insensitivity for file names. )

... like these: http://www.abridgegame.org/pipermail/darcs-users/2 004-November/004396.html

(Sorry, fscking slashdot tags...)

"I have to agree with many other comments: the use of haskell eliminated it as a choice for me. I use subversion instead, and still looking for a better vcs. I checked all the available free (and some non-free) systems and all of them have major warts."

Why did it being in Haskell eliminate it as a choice? What kind of anal reason is that? Surely it's irrelevant what language anything is written in, insetad what matters is how good the program is. Or do you eliminate Haskell-based apps because you are a doting user who commits bug fixes back to projects? I doubt it.

The theory of patches is also more complex than you make it out to be. You only describe one of the simpler facets of the theory.

• 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.

Why? Are you a Subversion contributor?

• 2. Next question, can Haskell be embedded inline in Perl code?

Not that I'm aware. However, all you need is an embeddable Haskell interpreter. I believe this is possible with Hugs, which has a "server interface", and possibly even with ghc (the native compiler that Darcs is compiled with). You'd probably have to write the C/Perl interface yourself.

• 3. Can the quantum theory of patches be implemented as a Perl module ...

Certainly.

• 4. Reading about the symmetry or lack of it, concepts of physics this is helping me think about an app of my own. I'd like to read more about this does anyone have links?

More than anything it's mathematics. But David Roundy, the author of Darcs, is a physicist, and may have some pointers for you.

• 5. Time to learn Haskell!! Great!

If you're a Perl hacker, you might be interested in this. Scary, eh?

There was a good post on this on the mailing list a while ago.

I like Subversion just fine as a "better CVS" but if you're looking for a better version control system altogether, I would look into distributed version control systems like arch, or if you're looking for something with a better learning curve, darcs is really cool, and is implemented in the glorious Haskell programming language.

Distributed systems like these have a lot of advantages over the CVS/SVN model.

If you wanted to use Arch, but it's too complex, then you should try darcs. It has fully-distributed operation, but you can get up and running in much less time. Commands have a closer resemblence to what you're used to in Subversion or CVS: "darcs record", "darcs revert", "darcs diff", etc.

The best thing about darcs is that every operation is local by default. Subversion does diffs locally; darcs does everything locally. You only need to wait on the network when you want to get something not on your machine, or when you want to share your work with others. Arch can be made to work this way, but it requires a bit of setup and a lot of understanding of advanced concepts: mirrored archives, revision libraries, etc. With darcs, fast is the default.

The main downside is that it's still pre-1.0, and so a bit less stable and documented than Subversion, though still reasonably good.

You want Darcs. http://abridgegame.org/darcs/.

Using it is as simple as:

darcs init <dir>

.. hack hack ..

darcs add <file>
darcs record

.. interactive questions about changes ..

Then you have the option of sending your changes to other repositories, since Darcs is distributed.
You can copy/upload them directly, pull them from the other side, or even email them.

And of course is decentralised like arch.

Darcs

Darcs wiki

Getting started with darcs in 5 steps

Ok, I admit I just want to get darcs mentioned here, but I really want to know what Tom (as well as Larry McVoy) thinks about darcs. In particular, whether the theory will stand up to real use and scale to large projects. I have a hunch that David Roundy has discovered much of what Larry McVoy said was a dozen PhD theses worth of research behind BitKeeper.

Ok, I admit I just want to get darcs mentioned here, but I really want to know what Tom (as well as Larry McVoy) thinks about darcs. In particular, whether the theory will stand up to real use and scale to large projects. I have a hunch that David Roundy has discovered much of what Larry McVoy said was a dozen PhD theses worth of research behind BitKeeper.

"So.. where's the killer open source RCS?"

It is called darcs:

http://abridgegame.org/darcs/

I don't know if Vesta is much of a contender. It looks like it's hard to adopt for projects that are not totally prepared to buy into its way of doing everything.

A more interesting new open project is Darcs: much simpler than BitKeeper or Arch, but nearly as powerful (at least for small-medium projects.)

I thought monotone, codeville, and darcs all used the distributed repository model as well as arch & bk. They may be a little further behind in terms of features or surrounding tools, but each one does have some interesting theory/philosophy of version control behind it.

And darcs is written in haskell, so it wins points for enjoying the soundness and showing once again that pure FP can be and is used in the "real world"...

I wouldn't discount any of them yet, but I agree that the subversion fanboys are pretty damn irritating, trying to get every project to switch away from CVS now, when it would clearly be better to wait and see how some of the more revolutionary free systems evolve.

However, anything is better than clearcase...

These vulnerabilities are a consequence of an architectural security flaw in both CVS and Subversion: they require an active server that talks a complex protocol to an unauthenticated client.

Whenever you allow an untrusted client to control code running on your server, there is a risk of a compromise.

The distributed version control systems Darcs and Arch show a better way. Read-only access requires only some read-only files published over HTTP. Since most projects already have a web site, this means there is no increase in the network services that need to be offered.

Once those files are downloaded, the anonymous user can get updates, make their own patches, branch -- all the facilities allowed by anonsvn/anoncvs and more.

What about Darcs? It seems to do the distributed-repository-merge-between-anything-danc e pretty good, too.

What about Darcs? We're using it for the Vexi project and it seems to be VERY good.

Larry used to like to joust with the would-be bitkeeper challengers. I'd like to know what he thinks of them today. My guess is that he still thinks arch is limited by its "diff&patch" foundation, but I wonder what he thinks about darcs", which has some novel algorithms for distributed revision control (I admit I don't understand them all, not being a physicist).

Larry used to like to joust with the would-be bitkeeper challengers. I'd like to know what he thinks of them today. My guess is that he still thinks arch is limited by its "diff&patch" foundation, but I wonder what he thinks about darcs", which has some novel algorithms for distributed revision control (I admit I don't understand them all, not being a physicist).

How about Darcs?

I was just recently looking to move away from CVS for my personal projects. I'm not always home, and I wanted to have copies of my repositories on at least my laptop and desktop.

At first, I was leaning towards trying out GNU Arch. But I really wanted something that had a working win32 client. So I took a look at Darcs.

I'm very happy with it so far. It is extremely easy to set up and use (but I haven't seen any gui frontends if that's the kind of thing you want). It is also very easy to keep multiple repositries in sync.

I've read that it can be slow for large projects. I don't remember reading the definition of large, but none of my repositories qualify :).

You might also want to check out this comparison or this comparison of revision control systems.

Another nifty thing good revision control systems can do (well, some of them -- Subversion, for instance, lacks this) is distributed operation. For instance, this means you can make a branch of someone else's code stored on your own server,

You'll find a lot of corporate developers out there who reject the very idea of concurrent version control; they want a system where you have to lock a file to be able to edit it (like RCS). They want to be able to see, easily, who's working on what at any given time. They don't want to resolve conflicts -- they want to avoid them in the first place. Concurrent version control is a "bad idea" to them, and the idea of distributed repositories makes them shudder.

Now, I disagree with the lock-to-use philosophy; I know, from experience, that it causes more problems and frustration than it solves. However, the central repository architecture does have a number of benefits, not least of which is cheap copies, which leads to intuitive and elegant tags and branches.

I use darcs for my open source projects, but Subversion at work. They both have strengths arising from their unique architectures that are conducive to different development models.

As I've said before, elsewhere, Subversion is an excellent, robust tool for environments where centralized servers are desired (read: corporate environments). It is not (currently) the ideal tool for projects such as Linux, which is highly branched and has numerous servers that cross-pollinate each other. darcs, and arch, are better tools for projects such as these, although they tend to lack much of the elegance of the Subversion design.

Furthermore, I'm going to nebulously claim that darcs is better than arch. When in Rome...

The formal Theory of Patches is just a page of incoherent mumbo-jumbo using fancy words and phrases, and that with little understanding. The so-called "definitions" and "theorems" are ambigious, incomplete and in general incomprehensive. For a starter :

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.

This is an approach often taken by experimental physicists, and is often reasonable, it is an entirable wrong approach for modelling application of patches! This is evident by his statement that "The theory of patches is independent of the data which the patches manipulate".

An approach based upon Graph Theory (which he can read about in any book on Discrete Mathematics) would be much more fruitful. He could even pick up how to make definitions, theorems and proofs by reading the book by Grimaldi.

It would be great to have a mathematician work on this, but I am not a mathematician, and don't care for math.

It clearly shows! And if he doesn't care for math, why does he base his so-called theory on "theory of quantum mechanics"? He happily refers to the mathematics of Operator Theory, and "applies" it. Yuck!

It goes on and on. The guy can't possibly have passed freshman year.

It's worth a look, if only for the ideas.

It's worth a look, if only for the ideas.