dsimcha, el 3 de agosto a las 02:34 me escribiste: > == Quote from Walter Bright ([email protected])'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.
I agree completely, I hate Java and every programming language where a readable hello world takes more than 3 SLOC. But I insist I'm talking about defaults. If D would accept an import module.* syntax, you could still do quick&dirty without much hassle, but make the dirtyness explicit. The argument about having technical problems to implement this model seems like a good reason (but I guess it should be doable though, at some point you have to know all the symbols that are present in a source file, and where they came from). -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- <original> [Penis Uptime: 2days 13hrs 59mins 35secs] <Yapa> viagra? :) <original> yea, 20 pills
