Walter Bright: >In my discussions with companies about adopting D, the major barrier that >comes up over and over isn't Tango vs Phobos, dmd being GPL, debugger support, >libraries, bugs, etc., although those are important. It's the IDE. They say >that the productivity gains of D's improvements are overbalanced by the loss >of productivity by moving away from an IDE.<
Welcome to more modern times Walter :-) You may have noticed that a small army of people in this newsgroup has told you the same things in the last years I've spent around here. In practice modern statically typed languages aren't designed to be used alone, they are designed to be used with an IDE. So what in the past was a "programming language" today is a "programming language + IDE". Probably there are ways to overdo this idea (like the idea of programming languages written in XML instead of nornal text), but D isn't risking to fall into this trap yet. >And what is it about an IDE that is so productive? Intellisense (Microsoft's >word for autocompletion).< The productivity of modern IDEs is a complex thing, it comes from several tuned features. Intellisense is just one of those parts. Have you tried to program 2-3 days with dotnet C#? If you try, you will see several interesting things you don't know about. Some form of reflection too helps IDEs, I think. The file you talk about will help refracting tools, I guess. In C# you have a syntax for sections of code that tells the IDE how to fold code, it's named: #region Some people don't like them, but they are common in C#: http://www.codinghorror.com/blog/archives/001147.html Attributes too are food for the IDEs, they add semantic information on the code, and IDEs love such information: @someattribute(data1, datas2, ...) > I'd never heard of JSON, but looking at it, it makes sense. I don't see > much point in supporting both. XML is very common, so most tools already support it or have ways to support it. So probably big IDEs are able to read XML files. So supporting XML is good. JSON is light, easy to parse, so if you want to write a simpler tool it can be good. I like JSON, it's quite common on the web and with dynamic languages. But JSON is less common in some situations, so some existing tools may not be already able to digest it. That's why supporting both looks like a good idea. The good thing is that I don't think will be hard to generate one when DMD is able to generate the other. If you really want to support only one of the two, then you have to look at the kind of generated data. XML is better for really complex structures, while JSON is enough if the data ha a low level of nesting. The tools designed to query very complex XML files are more advanced and common. What kind of data do you want to put in such files? The optional output to stdout of such data is good. Bye, bearophile
