Bruno Medeiros wrote:
> I disagree. I've seen these arguments over and over, that Java takes a lot of code to write the simplest things, that Java is verbose (consider the Kingdom of Nouns article/rant), etc.. It is true that Java is like that, but I disagree that it is a bad thing. The design of the Java language is optimized for large programs, not for small ones.
> 
> Sure, Java's hello world is one the largest compared to other languages, but should we rate languages based on simple code like hello world's? That's not quite correct. It's like bemoaning D or similar languages because a shell scripting language allows writing a hello world with much less code. It does, but shell scripting does scale well for larger projects.
> 
> I've been reading and coding a lot of Java recently (as part of a Descent related Eclipse IDE project), and frankly the more I do it, the more I like Java, despite some standing flaws(*). I've been reading and trying to understand a lot of the Eclipse Platform's and JDT's source code, and I'm able to do that fairly well, in good part because the way one writes Java code is both very verbose and very standard. There are no strange or kinky features that obfuscate the code. No MyDSL's for each developer in the team. If Eclipse and JDT were written in C++ (or even in D!) I wonder if my job wouldn't be much more difficult.

I entirely agree with this feeling. I also don't mind reading Java, but IMHO the features of the language that make it nice and readable are not verboseness or obsession with objects. Let's not forget that Java has a very well thought-out type system with no holes (barring the array covariance that is now assuaged by generic). This means that all Java code is free of a certain category of errors - guess which: the most intractable. This alone has determined a ton of researchers to focus on Java, and further improve it (e.g. threading, generics, optimizers, analyzers...). The language has gotten threading absolutely right - it's the envy of all other imperative languages, barring probably Ada. Java also has the exact features needed for component development (GC, reflection). All these contribute to Java code being writable and readable without a lot of effort, and make up for its minuses.

So I disagree that Java should be seen as a hack pushed by a marketing muscle. (That would be Basic, and look at what happened to it :o)). It's a good language developed on a sound basis, and it's that that makes it reasonable to work with. But that shouldn't mean that things can be largely improved; D is slated to have the sound basis and also have things that put it way ahead from other languages.



Andrei

janderson wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> janderson wrote:
>>> Andrei Alexandrescu (See Website For Email) wrote:
>>>> janderson wrote:
>>>>> Note: I'm not arguing that meta-programming should be higher priority then say reflection.  I'm just arguing that its just an extension to what programmers do on a day-to-day basis.
>>>>
>>>> But metaprogramming *gives* reflection (as even you and others discussed recently). The half-assed way to do reflection is to have the language implementer sit down and define the run-time reflection mechanism. The full-assed way is to define compile-time reflection, to then allow people to define and refine run-time reflection mechanisms as libraries, in addition to many other useful libraries! It's like in the fish vs. fishing parable.
>>>
>>> I agree but its like the stl vectors.  I'm unsure weather it just is easier to have that kinda thing in the language because it already has much of that information. 
>>
>> The information being there is all the more reason to make it available during compilation, for reflection and many other purposes, e.g. PyD being one of them.
>>
>>> Also to write a reflection program that doesn't require wrapping each and every call you'd need to write a fully fledged compiler which may become out of sync with the compiler.   I'm undecided on this matter.
>>
>> Not sure I understand. All that will be needed to make Widget available is:
>>
>> mixin Manifest!(Widget);
>>
>> I don't see where the syncing problem occurs.
> 
> This is wrapping each class.  What if the the code was hidden in a library or something.  How would you get a such information?  Also wrapping each class is not as neat as a complete code analysis could be (which is possible in mixin, just very difficult and slow).
> 
> Syncing problems could still occur if Walter decides to make some change in the language syntax.

I find it reasonable to require one line per exposed class. This is even easier than writing a manifest file.


Andrei

Andrei Alexandrescu (See Website For Email) wrote:
> janderson wrote:
>> Andrei Alexandrescu (See Website For Email) wrote:
>>> janderson wrote:
>>>> Andrei Alexandrescu (See Website For Email) wrote:
>>>>> janderson wrote:
>>>>>> Note: I'm not arguing that meta-programming should be higher priority then say reflection.  I'm just arguing that its just an extension to what programmers do on a day-to-day basis.
>>>>>
>>>>> But metaprogramming *gives* reflection (as even you and others discussed recently). The half-assed way to do reflection is to have the language implementer sit down and define the run-time reflection mechanism. The full-assed way is to define compile-time reflection, to then allow people to define and refine run-time reflection mechanisms as libraries, in addition to many other useful libraries! It's like in the fish vs. fishing parable.
>>>>
>>>> I agree but its like the stl vectors.  I'm unsure weather it just is easier to have that kinda thing in the language because it already has much of that information. 
>>>
>>> The information being there is all the more reason to make it available during compilation, for reflection and many other purposes, e.g. PyD being one of them.
>>>
>>>> Also to write a reflection program that doesn't require wrapping each and every call you'd need to write a fully fledged compiler which may become out of sync with the compiler.   I'm undecided on this matter.
>>>
>>> Not sure I understand. All that will be needed to make Widget available is:
>>>
>>> mixin Manifest!(Widget);
>>>
>>> I don't see where the syncing problem occurs.
>>
>> This is wrapping each class.  What if the the code was hidden in a library or something.  How would you get a such information?  Also wrapping each class is not as neat as a complete code analysis could be (which is possible in mixin, just very difficult and slow).
>>
>> Syncing problems could still occur if Walter decides to make some change in the language syntax.
> 
> I find it reasonable to require one line per exposed class. This is even easier than writing a manifest file.
> 
> 
> Andrei

Very true however I think it could be written in a way that is easier. I'm on the fence with this on.

-Joel

Walter Bright wrote:
> kris wrote:
>  > Thus; shouting from the rooftops that D is all about meta-code, and DSL
>  > up-the-wazzoo, may well provoke a backlash from the very people who
>  > should be embracing the language. I'd imagine Andrei would vehemently
>  > disagree, but so what? The people who will ultimately be responsible for
>  > "allowing" D through the door don't care about fads or technical
>  > superiority; they care about costs. And the overwhelming cost in
>  > software development today, for the type of companies noted above, is
>  > maintenance. For them, software dev is already complex enough. In all
>  > the places I've worked or consulted, in mutiple countries, and since the
>  > time before Zortech C, pedestrian-code := maintainable-code := less
>  > overall cost.
> 
> Some comments:
> 
> 1) D has no marketing budget. It isn't backed by a major corporation. Therefore, it needs something else to catch peoples' attention. Mundane features aren't going to do it.
> 
> 2) I know Java is wildly successful. But Java ain't the language for me - because it takes too much code to do the simplest things. It isn't straightforward clarifying code, either, it looks like a lot of irrelevant bother. I'm getting older and I just don't want to spend the *time* to write all that stuff. My fingertips get sore <g>. I wouldn't use Java if it was twice as fast as any other language for that reason. I wouldn't use Java if it was twice as popular as it is now for that reason.
> 
> 3) Less code == more productivity, less bugs. I don't mean gratuitously less code, I mean less code in the sense that one can write directly what one means, rather than a lot of tedious bother. For example, if I want to visit each element in an array:
> 
>     foreach(v; e)
>     {...}
> 
> is more direct than:
> 
>     for (size_t i = 0; i < sizeof(e)/sizeof(e[0]); i++)
>     { T v = e[i];
>      ... }
> 
> 
> 4) The more experience I have, the more it seems that the language that got a lot right is ... Lisp. But Lisp did one thing terribly, terribly wrong - the syntax. The Lisp experts who can get past that seem to be amazingly productive with Lisp. The rest of us will remain envious of what Lisp can do, but will never use it.
> 
> 5) Lisp gets things right, according to what I've read from heavy Lisp users, by being a language that can be modified on the fly to suit the task at hand, in other words, by having a customizable language one can achieve dramatic productivity gains.

Agreed with all of the above.

> 6) If I think about it a certain way, it looks like what C++ Boost is doing is a desperate attempt to add Lisp-like features. By desperate I mean that C++'s core feature set is just inadequate to the task. For example, look at all the effort Boost has gone through to do a barely functioning implementation of tuples. Put tuples into the language properly, and all that nasty stuff just falls away like a roofer peeling off the old shingles.

Boost's lambda functions are another good example of a useful idea with a horrific implementation.

> 7) A lot of companies have outlawed C++ templates, and for good reason. I believe that is not because templates are inherently bad. I think that C++ templates are a deeply flawed because they were ***never designed for the purpose to which they were put***.
>
> 8) I've never been able to create usable C++ templates. Notice that the DMD front end (in C++) doesn't use a single template. I know how they work (in intimate detail) but I still can't use them.

I have no problem with C++ templates, but the syntax is such that I don't consider them appropriate for a lot of the uses to which they're being put.  Also, in many ways, C++ templates feel like a hack.  The need to sprinkle such code with "template" and "typename" qualifiers just so the compiler knows what it's parsing sends up a huge red flag that something is wrong.

> 9) But I see what C++ templates can do. So to me, the problem is to design templates in such a way that they are as simple to write as ordinary functions. *Then*, what templates can do can be accessible and maintainable. It's like cars - they used to be very difficult to drive, but now anyone can hop in, turn the key, and go.

Yup.  It may be that the D community is more technically adept than the C++ community on average simply because of the type of people new languages tend to attract, but I've seen a lot of interesting template code around here.

> 10) Your points about pedestrian code are well taken. D needs to do pedestrian code very, very well. But that isn't enough because lots of languages do pedestrian code well enough.
> 
> 11) Today's way-out feature is tomorrow's pedestrian code. I'm old enough to remember when "structured code", i.e. while, for, switch instead of goto, was the way-out feature (70's). Then, OOP was all the rage (80's), now that's a major yawner. STL was then the way-out fad (90's), now that's pedestrian too. Now it's metaprogramming (00's), and I bet by 2015 that'll be ho-hum too, and it's D that's going to do it.

True enough.  And it may end up being only hindsight that shows where the approach tends to break down, much like happened with OO.

> 12) Take a look at what Kirk McDonald is doing with Pyd. He needs all this stuff to make it slicker than oil on ground steel. He's on the bleeding edge of stuff D needs to *make* pedestrian.

I'll admit it's nice to see examples that truly require compile-time facilities to be at all feasible.


Sean

Michiel wrote:
>> The C++ version is even *worse* than the C one (for wordiness bother):
>>
>>  for (std::vector<T>::const_iterator i = e.begin(); i != e.end(); i++)
>>  {  T v = *i;
>>  ... }
>>
>> I mean I know the reasons for every bit of the syntax there, and in
>> isolation they make sense, but put it all together and it seems to go
>> backwards.
> 
> Hehe, sure. But that's like the worst possible way to do it. :)
> 
> * Most people make the std namespace public. Or at least the std::vector part.

No, that's the worst possible way to do it :-)

> Of course, the D foreach loop is still much neater (and I love it). But only if
> you really want to visit all elements of an array in a row. However, if you want
> to walk through two AA's at the same time (comparing keys and values, for
> example), how do you do that in D? Maybe there is a way I haven't found yet (I've
> only been working with D for a few weeks), but it looks to me like much more
> bother than with C++ iterators.

For what it's worth (probably not much), C++ does have a for_each template.  The problem is that it doesn't accept arbitrary code like the D foreach does, which gave rise to Boost's lambda library.


Sean

Andrei Alexandrescu (See Website For Email) wrote:
> Bill Baxter wrote:
>> Walter Bright wrote:
>>> kris wrote:
>>
>>>>> 5) Lisp gets things right, according to what I've read from heavy Lisp users, by being a language that can be modified on the fly to suit the task at hand, in other words, by having a customizable language one can achieve dramatic productivity gains.
>>>>
>>>> Yet, Lisp will always remain a niche language. You have to wonder why.
>>>
>>> I'm pretty sure it's the syntax.
>>
>> And the recursion.
>> People just don't naturally think recursively.
>>
>> And the lack of mutable data structures.
>> OCaml tried to fix that, but OCaml's probably always going to be niche as well (see first point).
> 
> LISP does have mutation. 

Ok. My bad.

> Besides, many people naturally think recursively, 

The statement was about why LISP is never going to be wildly popular. There may very well be "many" people who naturally think recursively, but if they're not a majority then that's a hurdle to LISP becoming popular.

> and many problems (e.g. parsing) can be easiest thought of that way.

Sure.  However, you can write recursive algorithms in most any procedural language to handle those naturally recursive tasks when they come up.   With Lisp or <my-favorite-functional-language> you're pretty much /forced/ to look at everything recursively.  And I think that makes joe coder nervous, thus presenting a major hurdle to any functional language ever becoming truly popular.

My point is just that I don't think syntax is the *only* thing that's prevented lisp from becoming wildly popular.  If that were the case then the answer would be to simply create a different syntax for Lisp. (Actually, according to someone's comment here http://discuss.fogcreek.com/newyork/default.asp?cmd=show&ixPost=1998 it's been done and it's called Dylan, another not-wildly popular language).  So I think the problem is more fundamental.

--bb

Walter Bright wrote:
> kris wrote:
> 
>> Walter Bright wrote:
>>
>>> 3) Less code == more productivity, less bugs. I don't mean gratuitously less code, I mean less code in the sense that one can write directly what one means, rather than a lot of tedious bother. For example, if I want to visit each element in an array:
>>>
>>>     foreach(v; e)
>>>     {...}
>>>
>>> is more direct than:
>>>
>>>     for (size_t i = 0; i < sizeof(e)/sizeof(e[0]); i++)
>>>     { T v = e[i];
>>>      ... }
>>>
>>
>> Yep, that's great! One of the reasons I like D so much, along with array slicing.
> 
> 
> The C++ version is even *worse* than the C one (for wordiness bother):
> 
>     for (std::vector<T>::const_iterator i = e.begin(); i != e.end(); i++)
>     {  T v = *i;
>     ... }
> 
> I mean I know the reasons for every bit of the syntax there, and in isolation they make sense, but put it all together and it seems to go backwards.

Not so hard to argue that example is actually C--  :)


> 
> 
>>> 5) Lisp gets things right, according to what I've read from heavy Lisp users, by being a language that can be modified on the fly to suit the task at hand, in other words, by having a customizable language one can achieve dramatic productivity gains.
>>
>>
>> Yet, Lisp will always remain a niche language. You have to wonder why.
> 
> 
> I'm pretty sure it's the syntax.

Interestingly, I used to have lunch with one of the original designers. My understanding was that's not how it was viewed from the 'inside'.


> 
> 
>>> 7) A lot of companies have outlawed C++ templates, and for good reason. I believe that is not because templates are inherently bad. I think that C++ templates are a deeply flawed because they were ***never designed for the purpose to which they were put***.
>>
>>
>> Agreed. But the issue is not about how badly they're flawed. Instead, it's the non-standard "language" problem. The MyDSL problem :)
> 
> 
> I disagree with that. When you write a program using classes and functions, you *are* creating your own language. Classes are your custom types, and functions are your custom operators.

So, the heart of the matter; the one that causes C++ Templates to be outlawed; is perhaps it's /potential/ for abuse? More on this later ...

> 
> 
>>> 8) I've never been able to create usable C++ templates. Notice that the DMD front end (in C++) doesn't use a single template. I know how they work (in intimate detail) but I still can't use them.
>>
>>
>> Same here.
> 
> 
> But I have been able to create usable D templates <g>.

Me too.


> 
> 
>> I also look at some D templates for ages, and still can't figure out just how they work. Don Clugston is known around here as the Template Ninja -- the very name itself shouts out "Here Dwell Demons!" :-D
> 
> 
> The very fact that Don's called the Template Ninja is a problem - after all, there is no "function ninja", no "typedef ninja", no "+ ninja". It's a sign that templates are still not easy enough to use.

Glad that you recognize the latent concern.

> 
> It's like Paul Mensonidas being recognized as the "World's Leading Expert on the C Preprocessor." Obviously, something is seriously wrong with the preprocessor if there's an ecological niche for a world's leading expert on it. (By the way, Paul is a very nice fellow and has been kind enough to help me iron out several subtle bugs in the DMC++ preprocessor. As long as we're saddled with that preprocessor spec, I'm glad there is a Paul to help!)
> 

Right :)


> 
>>> 12) Take a look at what Kirk McDonald is doing with Pyd. He needs all this stuff to make it slicker than oil on ground steel. He's on the bleeding edge of stuff D needs to *make* pedestrian.
>>
>>
>> Certainly :)
>>
>> What Kirk has been doing (much awesometude there) is one of those things that fit into the "narrow focus" or "speciality" field that /can/ benefit in some manner. But it's a black-box. When it works, nobody will fuss with the insides unless they /really/ have to. That's not how most commerical software is done today, regardless of all the efforts to make it more like circuit-design.
> 
> 
> Even if D fails to make metaprogramming easy for average joe coders to use, if it still can be used by experts to create useful black box code like Pyd, then it is worthwhile. After all, even though trig functions are very hard to write, they are easily used by joe coders as black box components without any problems.


I think this is where you've perhaps been missing my point? Let me try an example -- hrm -- you're into cars, right?

Ok ... I have a sleek and powerful car; rebuilt from the ground up. Dyno's at around 650ft/lbs & 625bhp at the wheels, with full boost at ~half the rpm range.  This is something that can get you into serious trouble rather quickly, if you fail to treat it with utmost respect. Because of this, I have a little switch in the glovebox: it changes the fuel-map, the timing map, and drops max-boost from 30psi to 7psi. I call it the "valet switch" -- it's used for that purpose and for inclement weather.

Going back to the original point about pedestrian-code, costs and so on: these shops who outlaw C++ templates have to, in effect, "police" their own codebase. That's no easy task. So here's a suggestion that you may be able to do something with ...

If you were to enable a "valet switch" in the compiler, it wouldn't be so hard to present that as an outright /benefit/ for dev-shops <g>. In other words, the dev-shop would have a means to enforce whatever policy they choose, while the compiler acts as the arbitrator. "Mainstream code has to compile with the valet switch" sort of thing.

Of course, the trick would be to find a reasonable tripping point where the abuse-potential starts to require some serious respect; like the vehicle noted above. However, it could be done; perhaps with a 'level'? I understand you're not crazy about switches and so on, but please consider it ... it could potentially be responsible for alleviating adoption fears. That's a pretty darned powerful switch.

I hope this clarifies that I'm not pushing for less goodies; I'm pushing for responsible usage of them. Enabling that would surely garner D some respect from those people ultimately responsible for "letting" it through the door.

- Kris

Bill Baxter wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> Bill Baxter wrote:
>>> Walter Bright wrote:
>>>> kris wrote:
>>>
>>>>>> 5) Lisp gets things right, according to what I've read from heavy Lisp users, by being a language that can be modified on the fly to suit the task at hand, in other words, by having a customizable language one can achieve dramatic productivity gains.
>>>>>
>>>>> Yet, Lisp will always remain a niche language. You have to wonder why.
>>>>
>>>> I'm pretty sure it's the syntax.
>>>
>>> And the recursion.
>>> People just don't naturally think recursively.
>>>
>>> And the lack of mutable data structures.
>>> OCaml tried to fix that, but OCaml's probably always going to be niche as well (see first point).
>>
>> LISP does have mutation. 
> 
> Ok. My bad.
> 
>> Besides, many people naturally think recursively, 
> 
> The statement was about why LISP is never going to be wildly popular. There may very well be "many" people who naturally think recursively, but if they're not a majority then that's a hurdle to LISP becoming popular.
> 
>> and many problems (e.g. parsing) can be easiest thought of that way.
> 
> Sure.  However, you can write recursive algorithms in most any procedural language to handle those naturally recursive tasks when they come up.   With Lisp or <my-favorite-functional-language> you're pretty much /forced/ to look at everything recursively.  And I think that makes joe coder nervous, thus presenting a major hurdle to any functional language ever becoming truly popular.
> 
> My point is just that I don't think syntax is the *only* thing that's prevented lisp from becoming wildly popular.  If that were the case then the answer would be to simply create a different syntax for Lisp. (Actually, according to someone's comment here http://discuss.fogcreek.com/newyork/default.asp?cmd=show&ixPost=1998 it's been done and it's called Dylan, another not-wildly popular language).  So I think the problem is more fundamental.

I think the bottom line is, languages succeed and fail for the most mysterious reasons; engaging in speculation is a certain time vortex. When it comes about LISP in particular, the most amazing thing to me is not why it didn't catch up in the industry, but why it's so amazingly fresh today after 46 years. Some concepts pioneered by LISP that people have laughed at are now increasingly considered "obviously good" (GC, lambdas, higher-order functions, closures, continuations), while others, I agree with Paul Graham, are starting to blip on the community-at-large radar only now after so many years. Those are the macros.


Andrei

kris wrote:
> 
> Of course, the trick would be to find a reasonable tripping point where the abuse-potential starts to require some serious respect; like the vehicle noted above. However, it could be done; perhaps with a 'level'? I understand you're not crazy about switches and so on, but please consider it ... it could potentially be responsible for alleviating adoption fears. That's a pretty darned powerful switch.

I think this is a very good idea, and if some reasonable means of implementing it could be found then it might actually aid D's adopting in conservative circles without prohibiting powerful meta features from being added.

What fuels my concern is that because the new mixin/import features are so general, it is as easy to envision horrors rivaling the worst of C macro code as it is to envision elegant and practical applications.  I suppose this is why I've been kind of hoping an alternate solution would present itself :-)  I think the general idea is fantastic, but these are the first features in D that I might actually be inclined to prohibit in certain development environments.  The potential for abuse undermines a lot of what appeals to be about D: elegance, clarity, etc.  At the same time, I'm excited about the direction in which things are progressing.


Sean

kris wrote:
> Of course, the trick would be to find a reasonable tripping point where the abuse-potential starts to require some serious respect; like the vehicle noted above. However, it could be done; perhaps with a 'level'? I understand you're not crazy about switches and so on, but please consider it ... it could potentially be responsible for alleviating adoption fears. That's a pretty darned powerful switch.

I don't believe such a switch belongs in the compiler itself. I think it belongs in a 3rd party tool, where it can be customized to match the coding standards of the organization.

That's why D is designed to be easy to parse - it makes it practical to build such custom tools.