bearophile wrote:
> Andrei Alexandrescu:
> 
>>> For now I suggest you to aim to be just about as fast as Python
>>> in this task :-) Beating Python significantly on this task is
>>> probably not easy.
>> Why?
> 
> Because it's a core functionality for Python so devs probably have
> optimized it well, it's written in C, and in this case there is very
> little interpreter overhead.

Then we can do whatever they've done. It's not like they're using APIs nobody heard of.

It seems such a comparison of file I/O speed becomes in fact a comparison of garbage collectors. That's fine, but in that case the notion that D offers the possibility to avoid allocation should come back to the table.


Andrei

On 08/08/2010 14:31, dsimcha wrote:
> I disagree completely.  D is clearly designed from the "simple things should be
> simple and complicated things should be possible" point of view.  If it doesn't
> work well for these kinds of short scripts then we've failed at making simple
> things simple and we're just like every other crappy "large scale, industrial
> strength" language like Java and C++ that's great for megaprojects but makes
> simple things complicated.

dsimcha wrote:
"I hate Java and every programming language where a readable hello world takes more than 3 SLOC"

That may be your preference, but other people here in the community, me at least, very much want D to be a "large scale, industrial strength" language that's great for megaprojects. 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).


-- 
Bruno Medeiros - Software Engineer

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.

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.

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.

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

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

Bruno Medeiros:

> From my understanding, Scala is a "scalable language" in the sense
> that it easy to add new language features, or something similar to that.

I see. You may be right.


> But I'm missing your point here, what does Ada have to do with this?

Ada has essentially died for several reasons, but in my opinion one of them is the amount of code you have to write to do even small things. If you design a language that is not handy to write small programs, you have a higher risk of seeing your language die.


> but I simply didn't see much language changes that could have made my D more succint,

Making a language more succint is easy, you may take a look at J or K languages. The hard thing is to design a succint language that is also readable and not bug-prone.

Python has some features that make the code longer, like the obligatory "self." before class instance names and the optional usage of argument names at the calling point make the code longer. The ternary operator too in Python is longer, as the "and" operator, etc. Such things improve readability, etc.

Several Python features help shorten the code, like sequence unpacking syntax and multiple return values:

>>> def foo():
...   return 1, 2
...
>>> a, b = foo()
>>> a
1
>>> b
2


List comprehensions help shorten the code, but I think they also reduce bug count a bit and allow you to think about your code at a bit higher level:

>>> xs = [2,3,4,5,6,7,8,9,10,11,12,13]
>>> ps = [x * x for x in xs if x % 2]
>>> ps
[9, 25, 49, 81, 121, 169]


Python has some other features that help shorten the code, like the significant leading white space that avoids some bugs, avoids brace style wars, and removes both some noise and closing brace code lines.


> barring crazy stuff like dynamic scoping)

I don't know what dynamic scoping is, do you mean that crazy nice thing named dynamic typing? :-)

Bye,
bearophile

On 10/01/2010 01:54 PM, bearophile wrote:
> Bruno Medeiros:
>
>>  From my understanding, Scala is a "scalable language" in the sense
>> that it easy to add new language features, or something similar to that.
>
> I see. You may be right.
>
>
>> But I'm missing your point here, what does Ada have to do with this?
>
> Ada has essentially died for several reasons, but in my opinion one of them is the amount of code you have to write to do even small things. If you design a language that is not handy to write small programs, you have a higher risk of seeing your language die.
>
>
>> but I simply didn't see much language
>> changes that could have made my D more succint,
>
> Making a language more succint is easy, you may take a look at J or K languages. The hard thing is to design a succint language that is also readable and not bug-prone.
>
> Python has some features that make the code longer, like the obligatory "self." before class instance names and the optional usage of argument names at the calling point make the code longer. The ternary operator too in Python is longer, as the "and" operator, etc. Such things improve readability, etc.
>
> Several Python features help shorten the code, like sequence unpacking syntax and multiple return values:
>
>>>> def foo():
> ...   return 1, 2
> ...
>>>> a, b = foo()
>>>> a
> 1
>>>> b
> 2
>
>
> List comprehensions help shorten the code, but I think they also reduce bug count a bit and allow you to think about your code at a bit higher level:
>
>>>> xs = [2,3,4,5,6,7,8,9,10,11,12,13]
>>>> ps = [x * x for x in xs if x % 2]
>>>> ps
> [9, 25, 49, 81, 121, 169]
>
>
> Python has some other features that help shorten the code, like the significant leading white space that avoids some bugs, avoids brace style wars, and removes both some noise and closing brace code lines.
>
>
>> barring crazy stuff like dynamic scoping)
>
> I don't know what dynamic scoping is, do you mean that crazy nice thing named dynamic typing? :-)
>
> Bye,
> bearophile

No, dynamic scoping is the crazy thing. Perl code:

#!/usr/bin/perl

$x = 1;

sub p {
    print "$x\n"
}
sub a {
    local $x = 2;
    p;
}
p;
a;
p

results in:


pp ~/perl% perl wat.pl
1
2
1

Crazy. :-)

On 01/10/2010 12:54, bearophile wrote:
> Bruno Medeiros:
>
>>  From my understanding, Scala is a "scalable language" in the sense
>> that it easy to add new language features, or something similar to that.
>
> I see. You may be right.
>
>
>> But I'm missing your point here, what does Ada have to do with this?
>
> Ada has essentially died for several reasons, but in my opinion one of them is the amount of code you have to write to do even small things. If you design a language that is not handy to write small programs, you have a higher risk of seeing your language die.
>
>

There are a lot of things in a language that, if they make it harder to write small programs, they will also make it harder for larger programs. (sometimes even much harder)
I'm no expert in ADA, and there are many things that will affect the success of the language, so I can't comment in detail. But from a cursory look at the language, it looks terribly terse. That "begin" "end <name of block>" syntax is awful. I already think just "begin" "end" syntax is bad, but also having to repeat the name of block/function/procedure/loop at the "end", that's awful. Is it trying to compete with "XML" ? :p


>> but I simply didn't see much language
>> changes that could have made my D more succint,
>
> Making a language more succint is easy, you may take a look at J or K languages. The hard thing is to design a succint language that is also readable and not bug-prone.
>

Indeed, I agree. And that was the spirit of that original comment:
First of all, I meant succinct not only in character and line count but also syntactical and semantic constructs. And succinct without changes that would impact a lot the readability or safety of the code. (as mentioned in "barring crazy stuff like dynamic scoping")

>> barring crazy stuff like dynamic scoping)
>
> I don't know what dynamic scoping is, do you mean that crazy nice thing named dynamic typing? :-)
>

Like Pete explained, it's indeed exactly "dynamic scoping" that I meant.

-- 
Bruno Medeiros - Software Engineer