lint for D

[Markus Koskimies]

On Thu, 10 Jul 2008 04:56:15 -0400, bearophile wrote:

> I think that having a separate lint, a separate code commenting tool,
> and a separate unittest controller, may be better, because putting such
> things into the compiler makes the development of the compiler slower
> (because I think it's better for Walter to focus on just the compiler,
> reducing and focusing his work), and such tools become slower.

I partly agree; yes, the basic tool gives you basic features (like code 
commenting and unit testing), and when you run out of their capabilities, 
it is good to have more powerful alternatives available. It is of course 
not an option that one guy does it all; and I think that no one is 
suggesting that?

Just like you said, the D basic set scales down extremely well, and one 
of the reasons I really like D is that it is also suitable for making 
small programs fast. It's pretty much like a compiled Python :D

What about scaling up? In software development (both work & home), I 
could think about following things:

- Building; D compiler makes it easy to build the software from multiple 
files, but when the project grows, at some point there is probably need 
for makefiles and building scripts. That's why it's necessary that D 
compiler has command line interface, and ability just compile, not link.

- Testing; The larger and more complex is the project, the larger and 
more complex comes the testing. The language spec & coding practices can 
make this either easier or more difficult; the easier it is to extract 
piece of code to a test bench, the easier it is to set up test 
environment.

- Version control; Again, since D can compile projects from multiple 
files, it is enough for small projects and few people. But if the number 
of files and people grow, you start to think about svn.

- Documentation; Yes, Ddoc goes well, and at some point you may start to 
think doxygen.

- Refactoring; D is very similar to Python, that it goes far before 
people are starting to look for refactoring tools. I'm not sure if there 
are any viable alternatives except for Java. From the language point of 
view, I think that D has better abilities for large projects than java. 
Refactoring is of course not the job performed by compiler (I think that 
the compiler should never modify source code).

What I try to say, is that there are IMO two things; (1) the default 
tools provided by the compiler/linker release, and (2) the abilities to 
bind the compiler/linker to external tools.

> So I suggest to
> develop standard tools present in all D distributions, really easy and
> fast to use, with hooks from the compiler (so their syntax is good!)
> able to scale down, and developed/debugged by the community too.

Agreed.

> This
> is how Python works: built-in the std lib you find very easy to use
> tools for most purposes. But you often use external more powerful and
> less easy to use tools when you need something more refined.

Ah, Python is one of my favorite languages and partly just because of its 
built-in standard library :D