I'm sure any developer must learn to use appropriate tools to solve tasks most effectively. I regularly study new tools searching of some fresh ideas of improving the development process. Hovewer, the problem is that there are whole areas of tasks that have very poor tooling stuck in some 1980s.
One of such areas is file differencing and merging. I've compared several free and paid diff-merge tools and none of them is even good, not to mention the ideal. For example, Beyond Compare is poor at handling moved text blocks. CodeCompare understands moves, even though it uses syntax analysis hints, but its UX and merge mode doesn't fit to developer's needs at all. WinDiff is free and copes with moves, but it is extremely inconvinient in use and knows nothing of 3-way merge. From these and other tools in the area I prefer KDiff3, the only disadvantages of which are average UX and inability to understand block moves.
But the real freak among all these tools is the Semantic Designs Smart Differencer.
The tool is intended to be used by developers. I've downloaded an evaluation copy of the 'C# 4.0 Smart Differencer'. It occured to be a crazy tool.
One of such areas is file differencing and merging. I've compared several free and paid diff-merge tools and none of them is even good, not to mention the ideal. For example, Beyond Compare is poor at handling moved text blocks. CodeCompare understands moves, even though it uses syntax analysis hints, but its UX and merge mode doesn't fit to developer's needs at all. WinDiff is free and copes with moves, but it is extremely inconvinient in use and knows nothing of 3-way merge. From these and other tools in the area I prefer KDiff3, the only disadvantages of which are average UX and inability to understand block moves.
But the real freak among all these tools is the Semantic Designs Smart Differencer.
The tool is intended to be used by developers. I've downloaded an evaluation copy of the 'C# 4.0 Smart Differencer'. It occured to be a crazy tool.
- There is no public link for a free trial or evaluation. They force you to register and send a temporary download link.
- Each package works only against a specific language and version. So, if you have a c# 4.0 version, then no c++ or java, forget about it.
- It has no GUI at all! It's the 2011, but those guys seem to live in the 1970.
- It is installed as a bunch of strange '.p0b' files and '.cmd' batch files. I was a bit scared to see these creatures.
- It doesn't work after installation: the batch says that a 'DMS' environment variable is not set up propperly. What does their installer do? Why do I have to set the variables myself? Ok, lets help this poor being and do its work.
- It cannot determine the language, and the parameters are not very easy to type in: for c# 4.0 I had to write 'CSharp~CSharp4_0'. I couldn't just write CSharp - it said I don't have such a package. I haven't checked, but I believe I couldn't write 'c#' or a short 'CSharp4_0'.
- It simply doesn't work at all. I'd fed it with a c# source code file of some 1-2 hundred LOC which had been successfully compiled before, and the tool bursted with tons of error messages saying my files have invalid syntax instead of producing even a naive diff output. The producers must be crazy. I don't want another c# compiler which doesn't work. I have the VS for this. I need a diff tool that works even if my source code cannot be compiled because of some errors in merge or whatever.
- It costs 250$, period. Most paid diff-merge tools cost 50$ and work with any languages plus binary files and other bonuses. But Semantic Designs wants 250$ for a freaky outdated tool targeted against a single language and version only which does not even work!
These are the reasons of my decision to make an attempt to fix the situation. What will it result in? We'll see.
Hi. I'm with Semantic Designs. Thanks for the candid review of our C# Smart Differencer. (Ouch!)
ReplyDeleteI'd like to start a dialog with you regarding this.
You should probably assume that we intend for this tool to work. I'm surprised you are having this much trouble with it. Sorry for problems. We'd like to understand them and resolve them to your satisfaction.
First, the DMS environment variable. Changes to environment variables by installers are not seen in one DOS command shell live at the time of installation. Windows 7 made this worse; installed environment variables aren't seen until you logout and log back in. (Thank you MS for breaking existing installers). If you logout/in, is the problem still present? Can we see the complaint? (support@semanticdesigns.com)
Our parsers are normally pretty good; they've seen huge numbers of C# code and we check them against Microsoft's published documentation. Of course, that documentation does not match exactly what they do. Can we see the file that gave you bad time, please? I agree the tool would be nicer if it handled arbitrarily malformed source, but that wasn't its design goal. We've had the thought, and this is version 1.0 :-}
The funny files it installs... the tool is implemented in a parallel programming language. .exe files are lousy at parallelism. This probably doesn't matter to you, but this tool is part of a much bigger family of tools where this does matter. But there's no reason to be "scared" of them; they're just code.
Regarding "C#" versus CSharp~CSharp4_0: the funny names come from that larger tool context. Our tools process a lot of a languages and dialects, and we have to be able to distinguish them because we use full, compiler-front-end style parsers. C#4.0 is different than 3,2 and 1.2. We needed a way to name language category and dialect, that worked for many languages, which our scheme does. Yes, it makes the phrasing here a bit clumsy, but is is very general and works in the larger context. We've always assumed that "DMSSmartDifferencer" was long enough to annoy people worse than the dialect name. And we could have chosen a much shorter name but this makes it really clear what this tool is. As a practical matter, we expect most people to build, once, a tiny .CMD script that makes the tool easy to invoke for them; a few lines of script code would let you invoke in however you like so we didn't see this a big stumbling block. We thought about building such a script ourselves and delivering with the product, but surely our customers would have opinions about how to specify/optimize the specific steps they wanted so that didn't seem like it would be helpful.
Yes, you are right, it can't determine the language automatically. The only way to really distinguish C#4 from C#1.2 is run full parsers for each. Similarly for C#, Java, C++, JavaScript, ... In an ideal world, we'd have one tool that determined the language automatically and always did that correctly, and then ran the language-specific diff tool. The world isn't ideal, there's far too many languages to do that correctly. You may believe this is easy but it is not, if you want to do what our tool really does, which is compare syntax trees. You might be able to build a tool that compares *text* using a hueristic guess as to language (as some other tools you mention may have done) but you won't get really good diff answers then as you already observed. After you've tried to build your own diff tools this will become a lot clearer.
...
...
ReplyDeleteWe agree a GUI would be useful. We have done this for our COBOL version (see the website), as that customer base gave us plenty of motivation. We have not done this yet for the rest of the diff tools because as a small company we have lots of things to do which unfortunately have higher priority. And the customers that asked for these tools initially were happy with "batch" tools; they wanted a better "diff" tool.
Regarding the price: these aren't easy tools to build compared to the run-of-the mill competitors which all do just text-diff in various forms. (You're about to find out). The question should not be "what does it cost", but rather, "how much time does it save you in the long run". We think a minimal, structure oriented diff will save people many hours even if it doesn't have a GUI yet. If you only use it once, you're right, it isn't worth the price. But then most tools are worth the price if used only once.
You haven't even had the pleasure of using it once. We'd like to make sure that you can at least do that.
Ira Baxer, CTO
Semantic Designs
Hi, thanks for the reply.
ReplyDeleteI’ll start with some facts addressing your reply.
1. The environment variables.
When I opened the environment variables settings form, there already were several SD-related variables (e.g. DMS_Domain). So, some variables were there, but the main was absent, and I added it manually.
2. Parsing errors.
OK, I’ve found that I’d tested the tool on sources that correspond to c# 4.5 (these were some results of playing with Async CTP). I would definitely have understood the fact if the SD had given a summary of syntax errors it had found. But the screen was filled by some reports on its attempts to fix the errors saying nothing to me.
I guess now that the main use case of the tool is somewhat different. Perhaps, it's designed to be a part of an automated system or a bigger productivity tool solving specific problems. Maybe I'm wrong, but I'm judging by the differences between the tool and other diff/merge tools for developers (listed here). Maybe the tool is awesome for those use cases, I can’t tell.
But the "SmartDifferencer" (SD) was advised as a developer's Diff/Merge tool in a couple of places. So I expected the SD to solve typical problems like working with several languages at once (by the way, ASP.NET files may have a mix of HTML, JavaScript, CSS, C# and VB code) and executing 3-way merge. In fact, existing tools like BeyondCompare or CodeCompare are rather good and I expected similar functionality.
ReplyDeleteHere is why SmartDifferencer does not fit my needs:
1. It cannot work with mixed-language files, can it? If it can’t, it’s useless for me, since an ASP.NET file might have a mix of HTML, CSS, JavaScript, C#, VB and other languages at once. If I need a diff on such a file, I need to have a single command that handles everything.
2. It costs. In my current solution there are files in 4 versions of C#, HTML, CSS, JavaScript, SQL. I need diffs on all of them. Pay $2000? Are you kidding? I don’t have that many troubles with diffs.
3. It cannot work with files that are syntactically wrong. Well, developers may eventually commit files with errors. Say, wrong merges. It’s not good, but it happens. If the tool cannot work in such a situation, I don’t need it.
4. The tool works only with two files. But what if I extract some logic to a superclass (which lives in another file)? My experience shows that this is the main cause of problems when merging. If the tool cannot handle this, there's not much sence in smart syntax diffs.
5. The tool is definitely targeted against machine reading: no GUI, verbose command line syntax, etc. I need to analyze the diffs. I don't need them if I can't analyze them.
6. I need a tool that installs and works. Your installer doesn’t work, but who cares? Windows 7 has been in the wild for 2 years already, so it’s your problem that the installer doesn’t work. Other tools work out of the box.
7. I don't care how hard it is to implement the tool. It's developers' headache, not users. Well, as a developer, I do admit that your task is really by order of magnitude more difficult than the task of BeyondCompare and others. But as a user, I don't care.
...
Now, the conclusion
ReplyDeleteI must apologize. The 7-th item in my original post's list is wrong. The tool works. The problem is that it's not very human-friendly, which coupled together with the installation obstacles made me irritated and made me think it doesn't.
The main problem then is that the SD is simply from another segment than tools like KDiff3, WinDiff, BeyondCompare, CodeCompare, etc. If you generally like one of these tools and look for slight improvements, you are not likely to enjoy using the SmartDifferencer.
And I don't understand why the Semantic Designs tries to compete with these tools, suggests its product as developer's diff/merge tool. I doubt this may lead to anything other than misunderstandings like mine.