== Quote from Walter Bright (newshou...@digitalmars.com)'s article > Leandro Lucarella wrote: > > For me the problem with D is dependency control. You don't know what > > symbol come from which module. Yes, I know you can do explicit > > dependencies in D with static and selective imports, the same you can do > > the inverse in other languages with the import module.*-like syntax, but > > I think D got the default wrong, I prefer explicit by default. > It's a reasonable point of view, but the motivating thing for me here is > making > it easy for people to write quick&dirty programs.
I truly appreciate D's stance that both quick and dirty code and more heavily engineered code need to be supported. My biggest gripe about languages like Java is that they force so much "proper style" on me that I can't just "make it work" before I "make it right". I love how, using D, I can go from a quick and dirty prototype to a "real" program/library without having to switch languages and completely rewrite every function. In bioinformatics research, we do TONS of prototyping/small scripts and only a small fraction of these prototypes are fleshed out into serious programs. I suspect there are other fields like this, where you just want a quick prototype up front, but it may or may not be converted into a proper program depending on how the prototype works. Being able to do both in the same language is just an outstanding feature. Second, being able to write quick/dirty programs lowers the barrier to entry for trying out the language. My first few D programs, back when D was a mere curiosity for me, were things like programs that counted the amount of times each DNA nucleotide occurred in a sequence. Of course this is trivial, but if the language treated me like a naughty child instead of a consenting adult, I would likely not have stuck with it. Third, often only part of a program needs to be well-engineered (the core algorithms that will likely be around awhile) and the rest is just some quick and dirty glue to feed data to the core algorithms, and will likely change in relatively short order. The well-factored core algorithms plus quick and dirty glue style is very often how I program in practice.