"language_fan" <somewhere@internet.com.invalid> wrote in message news:ha87kd$2j3d$1@digitalmars.com...
> On Sat, 03 Oct 2009 14:35:22 -0400, Jeremie Pelletier wrote:
>>
>> Think of the english languages, how many words does it have? I would hate to try and express my ideas if I had only 100 words to choose from. Some people do but we call them simple minded or uneducated :)
>
> Comparing spoken languages and formal languages used to program computers is rather far fetched. Even a small child recognizes more words than a complex programming language has keywords. There are programming languages with rather minimal set of core keywords and constructs. This makes them in no way more suitable for less intelligent people.

I think his point was that number of keywords isn't a particularly good measure of language complexity. To bring it back to programming languages, VB has keywords coming out the wazoo, but the only thing complex about VB is the complexity involved in trying to express high-level (or low-level) concepts that VB is just too *simple* to handle.

> And your
> stance of disagreeing with everyone here does not make you better than
> the rest of us, it is just irritating.
>

I think I missed the memo indicating that disagreeing with others had suddenly become a bad thing. ;)

> D is pretty verbose in many respects. There are some totally unnecessary words like 'body' in the grammar. Also things like foreach_reverse should just die. Even a novice programmer can write a meta-program to replace foreach_reverse without any runtime performance hit. Designing a crappy programming language is not hard. Usually the elegance arises from clever use of powerful, generic core structures.

Fair enough. *But*, I really think "elegantly simple" language design is double-edged sword. In my experience, and I think this is what Jeremie was alluding to, I've found that an "elegantly simple" language, no matter how well-chosen the primitives are, generally results in a problematic lack of expressiveness and a frequent sense of fighting against the language instead of merely using it.

For example, the most elegantly simple languages I've seen are Java (at least earlier versions, anyway), JavaScript, Smalltalk, Haskell, and maybe Forth. And I really do admire those languages from a theoretical perspective...but only in the same sense that I admire Brainfuck. I'd never want to actually use any of those languages for any real work simply because their "elegantly simple" designs lead to many cases where I'd have to (or have had to) fight against them to accomplish what I need. I guess it just comes down to "as simple as possible, *but no more*."

In a more complex language like D, I never feel like I need to try to keep the whole langauge in my head. I just need some subset at any particular time, and then when (and I do mean "when", not "if"), when I need something else, it's nice to know that it's there to use and that I won't have to try to cram it into the wrong tool for the job or constantly switch between an array of languages while trying to keep them all playing nice with each other.

It's like a professional handyman having the smallest possible possible toolbox with only the barest essentialls, versus a big super-toolbox that has all the *right* tools he might need. Just because it's there doesn't mean it has to be used, but if I were a handyman and had to remove a phillips-head screw, I'd want to be able to reach for a forward/reverse drill and an appropriately-sized phillips-head bit, and not have to pry it out with the bare minimum (the back of a hammer, or a sort-of-sized-similarly manual flathead screwdriver), and also not have to put one specialized mini-toolbax back and switch to a differently-specialized mini-toolbox for every different task.

On Sat, 03 Oct 2009 16:39:29 -0400, Justin Johansson wrote:

> People might remember that when I picked up D and joined this forum just some 3 or so weeks ago I made mention of being a Scala refugee.***  When asked what I didn't like about Scala I commented about there being too many language constructs.

Compared to D that is not even true. The Scala language spec lists 40 keywords + 10 additional reserved tokens. D 2.0 spec lists 106 keywords + a bit over 60 reserved tokens. In general there are no features in Scala that are not built around those keywords and tokens. The keywords and token are not more heavily overloaded than in D, on the contrary in my subjective opinion.

So how I see things is that the language core in Scala is about 75% smaller, faster to learn, and easier to reason about. I have to admit that the features often are more powerful than in D. You need to recognize concepts like contra/co/invariance, higher order functions and kinds, and algebra that is based on terms discussed in lambda calculus books.

language_fan wrote:
> On Sat, 03 Oct 2009 16:39:29 -0400, Justin Johansson wrote:
> 
>> People might remember that when I picked up D and joined this forum just
>> some 3 or so weeks ago I made mention of being a Scala refugee.***  When
>> asked what I didn't like about Scala I commented about there being too
>> many language constructs.
> 
> Compared to D that is not even true. The Scala language spec lists 40 keywords + 10 additional reserved tokens. D 2.0 spec lists 106 keywords + a bit over 60 reserved tokens. In general there are no features in Scala that are not built around those keywords and tokens. The keywords and token are not more heavily overloaded than in D, on the contrary in my subjective opinion.
> 
> So how I see things is that the language core in Scala is about 75% smaller, faster to learn, and easier to reason about. I have to admit that the features often are more powerful than in D. You need to recognize concepts like contra/co/invariance, higher order functions and kinds, and algebra that is based on terms discussed in lambda calculus books.

I agree that a hemorrhage of keywords is of dubious value, and Walter has been much more generous with keywords than I would have ever liked.

Assuming you're not hanging out in this group just to feel smug: what steps do you think we could take to make D a better language than it currently is?


Andrei

language_fan wrote:

> On Sat, 03 Oct 2009 16:39:29 -0400, Justin Johansson wrote:
> 
>> People might remember that when I picked up D and joined this forum just some 3 or so weeks ago I made mention of being a Scala refugee.***  When asked what I didn't like about Scala I commented about there being too many language constructs.
> 
> Compared to D that is not even true. The Scala language spec lists 40 keywords + 10 additional reserved tokens. D 2.0 spec lists 106 keywords + a bit over 60 reserved tokens. In general there are no features in Scala that are not built around those keywords and tokens. The keywords and token are not more heavily overloaded than in D, on the contrary in my subjective opinion.
>
> So how I see things is that the language core in Scala is about 75% smaller, faster to learn, and easier to reason about. I have to admit that the features often are more powerful than in D. You need to recognize concepts like contra/co/invariance, higher order functions and kinds, and algebra that is based on terms discussed in lambda calculus books.

How do you think Scala is going to manage to be a popular alternative for Java by requiring its user to read books about lambda calculus?

The keyword metric is so flawed you just cannot base any argument around it.

Take for example the debug statement in D. It's very unorthogonal, basically just the same as version(debug). D is a syntax heavy language, but a lot of that come from such simplistic features. Heck, you could built a whole programming language with the number of tokens D reserves specially for stuff around floating point types! But they make the language only slightly more complicated by requiring the programmer to remember a few more words and meanings that don't interact so heavily with other features. Contrast this to say, the interaction because the C preprocessor and C++ template system or the various meanings of const in C++. Now that makes a language more *complex*.

If you want to measure the 'size' of a language (what does that mean by the way?) not all tokens should weigh equal.

I highly recommend this short and subjective article on the subject by Yukihiro Matsumoto: "Treating Code as an Essay" from the book Beautiful Code. Unfortunately I couldn't find it online.

Forget to qualify my reply: I don't know Scala so you might as well be right and I do not mean to say that D isn't a complex language.

On Sun, 04 Oct 2009 04:28:35 -0500, Andrei Alexandrescu wrote:

> language_fan wrote:
>> On Sat, 03 Oct 2009 16:39:29 -0400, Justin Johansson wrote:
>> 
>>> People might remember that when I picked up D and joined this forum just some 3 or so weeks ago I made mention of being a Scala refugee.***  When asked what I didn't like about Scala I commented about there being too many language constructs.
>> 
>> Compared to D that is not even true. The Scala language spec lists 40 keywords + 10 additional reserved tokens. D 2.0 spec lists 106 keywords + a bit over 60 reserved tokens. In general there are no features in Scala that are not built around those keywords and tokens. The keywords and token are not more heavily overloaded than in D, on the contrary in my subjective opinion.
>> 
>> So how I see things is that the language core in Scala is about 75% smaller, faster to learn, and easier to reason about. I have to admit that the features often are more powerful than in D. You need to recognize concepts like contra/co/invariance, higher order functions and kinds, and algebra that is based on terms discussed in lambda calculus books.
> 
> I agree that a hemorrhage of keywords is of dubious value, and Walter has been much more generous with keywords than I would have ever liked.
> 
> Assuming you're not hanging out in this group just to feel smug: what steps do you think we could take to make D a better language than it currently is?

I would concentrate on combining and generalizing the core constructs and types to cut down language complexity. Starting from basic algebraic facts, D lacks built-in first class sum and product types. Higher order type operators also feel like a hack. The level of orthogonality is often very poor -- this is the result of the uncontrolled language evolution. D was not designed to be very orthogonal in these respects. Practical languages are rarely built with types in mind. Same applies to rationale behind built-in meta-properties of types and free function like constructs.

Even though templates and string mixins provide some kind of macro facility, I would like to offer something more Scheme like, with Template Haskell like flavor. String mixins are powerful, but unfortunately they do not provide any kind of meta-level type system. As a result the compile errors on the wrong abstraction level. It also fails at capturing symbol references in a nicely scoped manner. Andrei, I remember you also suggested all kinds of macro systems, but the discussion died ages ago.

In OOP I have found Scala and some prototype based OOP languages to behave in the most elegant way. You should read the OOP articles by Odersky. For instance, try to find a solution to the Node-Edge subtyping problem in D. Experiment with traits to see how powerful they are. Try to find justifications for the lack of genuine new features of Scala (self types, etc.).

I cannot foretell how changing the low level abstractions changes the overall look and feel. Probably some constructs become unnecessary, others will remain. I do not have the skills to build a full language that works optimally in all possible ways.

The keyword comparison was a bit unfair. I find it acceptable for a lower level language to have a bit more keywords since there are many hardware capabilities that need to have a mapping on the language level.

On Sun, 04 Oct 2009 11:51:13 +0200, Lutger wrote:

> How do you think Scala is going to manage to be a popular alternative for Java by requiring its user to read books about lambda calculus?

It's not necessary. Often removing extra semicolons and changing the form '<type> <value>' to '<value> : <type>' suffices. Especially when porting Java code.

> The keyword metric is so flawed you just cannot base any argument around it.

I admitted that later. Some of the keywords have a strong justification behind them. Others feel irritatingly unnecessary.

Imagine if D had keywords goto_unknown, goto_forward and goto_backward, and goto_here (which is rewritten as while(true) {} by the compiler), based on how the program counter will change. Jumps to addresses with a lower program counter value use goto_backward, vice versa for goto_forward. Situations where the pc value is runtime determined would have to use goto_unknown. D 2.0 would also have construct 'goto dynamic (addr);' which would behave identically to 'goto_unknown addr;'. Now some of you might see a pattern here and would try to combine the various gotos into a single keyword. I am talking about similar situation, but my focus is on a higher level.

> I highly recommend this short and subjective article on the subject by Yukihiro Matsumoto: "Treating Code as an Essay" from the book Beautiful Code. Unfortunately I couldn't find it online.

Thanks. Added to my todo list.

language_fan wrote:
> On Sun, 04 Oct 2009 04:28:35 -0500, Andrei Alexandrescu wrote:
> 
>> language_fan wrote:
>>> On Sat, 03 Oct 2009 16:39:29 -0400, Justin Johansson wrote:
>>>
>>>> People might remember that when I picked up D and joined this forum
>>>> just some 3 or so weeks ago I made mention of being a Scala
>>>> refugee.***  When asked what I didn't like about Scala I commented
>>>> about there being too many language constructs.
>>> Compared to D that is not even true. The Scala language spec lists 40
>>> keywords + 10 additional reserved tokens. D 2.0 spec lists 106 keywords
>>> + a bit over 60 reserved tokens. In general there are no features in
>>> Scala that are not built around those keywords and tokens. The keywords
>>> and token are not more heavily overloaded than in D, on the contrary in
>>> my subjective opinion.
>>>
>>> So how I see things is that the language core in Scala is about 75%
>>> smaller, faster to learn, and easier to reason about. I have to admit
>>> that the features often are more powerful than in D. You need to
>>> recognize concepts like contra/co/invariance, higher order functions
>>> and kinds, and algebra that is based on terms discussed in lambda
>>> calculus books.
>> I agree that a hemorrhage of keywords is of dubious value, and Walter
>> has been much more generous with keywords than I would have ever liked.
>>
>> Assuming you're not hanging out in this group just to feel smug: what
>> steps do you think we could take to make D a better language than it
>> currently is?
> 
> I would concentrate on combining and generalizing the core constructs and types to cut down language complexity. Starting from basic algebraic facts, D lacks built-in first class sum and product types. Higher order type operators also feel like a hack. The level of orthogonality is often very poor -- this is the result of the uncontrolled language evolution. D was not designed to be very orthogonal in these respects. Practical languages are rarely built with types in mind. Same applies to rationale behind built-in meta-properties of types and free function like constructs.
> 
> Even though templates and string mixins provide some kind of macro facility, I would like to offer something more Scheme like, with Template Haskell like flavor. String mixins are powerful, but unfortunately they do not provide any kind of meta-level type system. As a result the compile errors on the wrong abstraction level. It also fails at capturing symbol references in a nicely scoped manner. Andrei, I remember you also suggested all kinds of macro systems, but the discussion died ages ago.

I couldn't agree more, string mixins often feel like a hack in D and you lose all semantics informations an IDE can use to generate intellisense for example.

> In OOP I have found Scala and some prototype based OOP languages to behave in the most elegant way. You should read the OOP articles by Odersky. For instance, try to find a solution to the Node-Edge subtyping problem in D. Experiment with traits to see how powerful they are. Try to find justifications for the lack of genuine new features of Scala (self types, etc.).

Aren't prototype based objects only possible with a VM? I mean the prototype can be extended at anytime throughout the execution. It also adds a level of indirection since the objects don't hold a direct reference to the vtable, they hold a reference to the prototype which contains the dynamic vtable and string identifiers are used to resolve calls to the proper method since vtable indices aren't known at compile time.

Prototype based OOP is a great model, but I don't think it can be implemented in compiled languages like D.

language_fan wrote:
> On Sun, 04 Oct 2009 11:51:13 +0200, Lutger wrote:
> 
>> How do you think Scala is going to manage to be a popular alternative
>> for Java by requiring its user to read books about lambda calculus?
> 
> It's not necessary. Often removing extra semicolons and changing the form '<type> <value>' to '<value> : <type>' suffices. Especially when porting Java code.

>> The keyword metric is so flawed you just cannot base any argument around
>> it.
> 
> I admitted that later. Some of the keywords have a strong justification behind them. Others feel irritatingly unnecessary.

I would rather have many different specialized keywords than a few keywords with many different meanings. Its *much* easier to remember a large set of simple words than a small set of complex words.

> Imagine if D had keywords goto_unknown, goto_forward and goto_backward, and goto_here (which is rewritten as while(true) {} by the compiler), based on how the program counter will change. Jumps to addresses with a lower program counter value use goto_backward, vice versa for goto_forward. Situations where the pc value is runtime determined would have to use goto_unknown. D 2.0 would also have construct 'goto dynamic
> (addr);' which would behave identically to 'goto_unknown addr;'. Now some of you might see a pattern here and would try to combine the various gotos into a single keyword. I am talking about similar situation, but my focus is on a higher level.

I can't make sense out of this example, since there's only one possible goto with current hardware, and even VMs don't care where you jump at.

I think you meant to say that we can generalize keywords and let the compiler decide what we meant to do. And that is not always a good thing, sometimes you want your keyword to be verbose to other programmers too, for example the recent discussion about casts which stated D should have support for explicit static, dynamic and reinterpret casts just like C++.

language_fan wrote:
> On Sun, 04 Oct 2009 04:28:35 -0500, Andrei Alexandrescu wrote:
> 
>> language_fan wrote:
>>> On Sat, 03 Oct 2009 16:39:29 -0400, Justin Johansson wrote:
>>>
>>>> People might remember that when I picked up D and joined this forum
>>>> just some 3 or so weeks ago I made mention of being a Scala
>>>> refugee.***  When asked what I didn't like about Scala I commented
>>>> about there being too many language constructs.
>>> Compared to D that is not even true. The Scala language spec lists 40
>>> keywords + 10 additional reserved tokens. D 2.0 spec lists 106 keywords
>>> + a bit over 60 reserved tokens. In general there are no features in
>>> Scala that are not built around those keywords and tokens. The keywords
>>> and token are not more heavily overloaded than in D, on the contrary in
>>> my subjective opinion.
>>>
>>> So how I see things is that the language core in Scala is about 75%
>>> smaller, faster to learn, and easier to reason about. I have to admit
>>> that the features often are more powerful than in D. You need to
>>> recognize concepts like contra/co/invariance, higher order functions
>>> and kinds, and algebra that is based on terms discussed in lambda
>>> calculus books.
>> I agree that a hemorrhage of keywords is of dubious value, and Walter
>> has been much more generous with keywords than I would have ever liked.
>>
>> Assuming you're not hanging out in this group just to feel smug: what
>> steps do you think we could take to make D a better language than it
>> currently is?
> 
> I would concentrate on combining and generalizing the core constructs and types to cut down language complexity. Starting from basic algebraic facts, D lacks built-in first class sum and product types. Higher order type operators also feel like a hack. The level of orthogonality is often very poor -- this is the result of the uncontrolled language evolution. D was not designed to be very orthogonal in these respects. Practical languages are rarely built with types in mind. Same applies to rationale behind built-in meta-properties of types and free function like constructs.

Well this is a bit vague to act on. So, you say D lacks built-in first-class sum and product types. Yet Tuple is a product type. In spite of appearances, it's a built-in type, just that it has no literal. I don't see that a deal breaker. Then I fail to find fault for Algebraic (in std.variant) as a sum type. I need to add visitation to it, but other than that I don't think Algebraic is worse than a built-in type.

I agree that the language is unorthogonal but realistically there isn't a lot we can do about that now.

> Even though templates and string mixins provide some kind of macro facility, I would like to offer something more Scheme like, with Template Haskell like flavor. String mixins are powerful, but unfortunately they do not provide any kind of meta-level type system. As a result the compile errors on the wrong abstraction level. It also fails at capturing symbol references in a nicely scoped manner. Andrei, I remember you also suggested all kinds of macro systems, but the discussion died ages ago.

It hasn't died. We just concluded that it would take many months to define and implement a decent macro system. We also had a ton of other things to do, so we decided macros have to wait.

> In OOP I have found Scala and some prototype based OOP languages to behave in the most elegant way. You should read the OOP articles by Odersky. For instance, try to find a solution to the Node-Edge subtyping problem in D. Experiment with traits to see how powerful they are. Try to find justifications for the lack of genuine new features of Scala (self types, etc.).

I am very familiar with much of Odersky's work and have a lot of respect for it. But then Walter created D and has brought his world view in D, not someone else's. We can't go like, hey, let's wheelbarrow whatever's good in language X into D. That's why I specifically asked "what steps we need to take" hoping for much more detail and aim at integration than "Scala is good".

Regarding the Node-Edge subtyping problem, I'd appreciate a link. The first relevant result returned by Google is your own post :o). Is this relevant?

http://www.jot.fm/issues/issue_2008_06/article3.pdf

> I cannot foretell how changing the low level abstractions changes the overall look and feel. Probably some constructs become unnecessary, others will remain. I do not have the skills to build a full language that works optimally in all possible ways.

I guess you're in good company - nobody quite does.

> The keyword comparison was a bit unfair. I find it acceptable for a lower level language to have a bit more keywords since there are many hardware capabilities that need to have a mapping on the language level.

I don't know. I agree that D's relative abundance of keywords doesn't seem to be a huge problem in practice, but I also think we shouldn't add many more lest a phase shift of sorts occurs. And then just like you I prefer orthogonality, and abundance of keywords is abundance of magic and exceptions. I'd prefer "classinfo" to be an identifier like any other and obey the same rules that every symbol in its scope does. I'm very happy that Tomasz Stachowiak revealed to me that in-situ class allocation can be elegantly defined as a library facility. I don't care for foreach_reverse because foreach (e; retro(r)) actually does better. The popping of "length" in scope inside slice bounds is about the most distasteful hack there is, which gives the "length" keyword an almost-keyword status. And so on...


Andrei