On 30/09/2010 19:31, bearophile wrote:
Bruno Medeiros:
I think that medium and large
scale projects are simply much more important and interesting than small
scale ones.
I am hoping this would become an *explicit* point of D design goals, if
it isn't already.
And I will campaign against (so to speak), people like you who think
small scale is more important. No personal animosity intended though.
Note: I am not stating that is is not possible to be good, even great,
at both things (small and medium/large scale).
This is an interesting topic of practical language design, it's a wide problem
and I can't have complete answers.
D2 design is mostly done, only small parts may be changed now, so those
campaigns probably can't change D2 design much.
I'm not so sure about that. Probably backwards-incompatible changes will
be very few, if any. But there can be backwards-compatible changes, or
changes to stuff that was not mentioned in TDPL. And there may be a D3
eventually (a long way down the road though)
But my main worry is not language changes, I actually think it's very
unlikely Walter and Andrei would do a language change that intentionally
would adversely affect medium/large scale programs in favor of small
scale programs.
My main issue is with the time and thinking resources that are expended
here in the NG when people argue for changes (or against other changes)
with the intention of favoring small-scall programs. If this were
explicit in the D design goals, it would help save us from these
discussions (which affect NG readers, not just posters).
The name of the Scala language means that it is meant to be a scalable
language, this means it is designed to be useful and usable for both large and
quite small programs.
Whoa wait. From my understanding, Scala is a "scalable language" in the
sense that it easy to add new language features, or something similar to
that.
But lets be clear, that's not what I'm talking about, and neither is
scalability of program data/inputs/performance.
I'm talking about scalability of source code, software components,
developers, teams, requirements, planning changes, project management
issues, etc..
A language like Ada is not a bad language. Programming practice shows that in
many situations the debug time is the larger percentage of the development of a
program. So minimizing debug time is usually a very good thing. Ada tries hard
to avoid many common bugs, much more than D (it has ranged integers, integer
overflows, it defines a portable floating point semantics (despite there is a
way to use the faster IEEE semantics), it forces to use clear interfaces
between modules (much more explicit ones than D ones), it never silently
changes variable types, its semantics is fully specified, there are very
precise Ada semantics specs, all Ada compilers must pass a very large test
suite, and so on and on). In practice the language is able to catch many bugs
before they happen.
So if you want to write a program in critical situations, like important
control systems, Ada is a language better than Perl, and probably better than D
too :-)
Yet, writing programs in Ada is not handy, if you need to write small programs
you need lot of boilerplate code that is useful only in larger programs. And
Ada is a Pascal-like language that many modern programmers don't know/like. Ada
looks designed for larger, low-bug-count, costly (and often well planned out
from the beginning, with no specs that change with time) programs, but it's not
handy to write small programs. Probably Ada is not the best language to write
web code that has to change all the time. Today Ada is not a dead language, but
it smells funny, it's not commonly used.
Certainly it's not just web code that can change all the time.
But I'm missing your point here, what does Ada have to do with this?
Andrei has expressed the desire to use D2 as a language to write script-like
programs too. I think in most cases a language like Python is better than D2 to
write small script-like programs, yet I agree with Andrei that it's good to try
to make D2 language fit to write small script-like programs too, because to
write such programs you need a very handy language, that catches/avoids many
simple common bugs quickly, gives you excellent error messages/stack traces,
and allows you to do common operations on web/text files/images/sounds/etc in
few lines of code. My theory is that later those qualities turn out to be
useful even in large programs. I think such qualities may help D avoid the Ada
fate.
The ability to write small programs with D is also useful to attract programmers to D,
because if in your language you need to write 30 lines long programs to write a
"hello world" on the screen then newcomers are likely to stop using that
language after their first try.
Designing a language that is both good for small and large programs is not easy, but it
is a worth goal. D module system must be debugged& finished& improved to
improve the usage of D for larger programs. Some features of the unittesting and design
by contract currently missing are very useful if you want to use D to write large
programs. If you want to write large programs reliability becomes an important concern,
so integer overflow tests and some system to avoid null-related bugs (not-nullable
types and more) become useful or very useful.
Bye,
bearophile
Yeah, I actually think D (or any other language under design) can be
quite good at both things. Maybe something like 90% of features that are
good for large-scale programs are also good for small-scale ones.
One of the earliest useful programs I wrote in D, was a two-page bash
shell script that I converted to D. Even though it was just abut two
pages, it was already hard to extend and debug. After converting it to
D, with the right shortcut methods and abstractions, the code actually
manage to be quite succint and comparable, I suspect, to code in Python
or Perl, or languages like that. (I say suspect because I don't actually
know much about Python or Perl, but I simply didn't see much language
changes that could have made my D more succint, barring crazy stuff like
dynamic scoping)
--
Bruno Medeiros - Software Engineer
