cracki wrote:
> Sean Kelly wrote:
>> Walter Bright wrote:
>>> I see:
>>>    1- x
>>> in the Lisp code, and have to mentally translate it to:
>>>    x - 1
>>> and not:
>>>    1 - x
>>>
>>> This just hurts my brain.
>> I thought Lisp used prefix notation, but the above syntax looks like
>> element composition.
>>
>>
>> Sean
> 
> 
> nah. reading s-expressions needs some getting used to. you're reading
> serialized tree structure there after all.
> 
> the "1-" is the name of a function. instead of writing
> 
> 	(1- x)
> 
> you could of couse define a function "subtract-one" that does the same
> and then write
> 
> 	(subtract-one x)
> 
> but that's not much more readable. you can of course write
> 
> 	(- x 1)
> 
> and any lisp compiler optimizes it.

Oh okay.  For some reason I was still thinking in terms of C symbol names.  I'm going to have to remember that position is really all that matters in Lisp :-)


Sean

Andrei Alexandrescu (See Website For Email) wrote:
> Bill Baxter wrote:
>> Andrei Alexandrescu (See Website For Email) wrote:
>>> Bill Baxter wrote:
>>>> Andrei Alexandrescu (See Website For Email) wrote:
>>>>
>>>>
>>>>> I'm actually mildly surprised. Lately there was some talk around here about supporting the day-to-day programmers and so on. I find looping a very day-to-day thing, and looping over 2+ things at least a few-days-to-few-days thing. There is a need for parallel iteration, if nothing else shown by the existence of a library that addresses exactly that - to the extent possible in a library that's not in the position to control syntax, scoping, and visibility. I was sure people will be on this one like white on rice. But Bjarne Stroustrup was right: nobody knows what most programmers do :o).
>>>>
>>>> Python and Ruby are hardly considered to be obtuse languages, or unfriendly to Joe coder, but both get by just fine without special case syntax for iterating over multiple collections, or for iterating in reverse.
>>>>    for x,y izip(foo,bar):
>>>>        do stuff
>>>>
>>>>    for x reversed(foo):
>>>>        do stuff
>>>>
>>>>    for x,y izip(reversed(foo),bar):
>>>>        do that with your proposal!
>>>
>>> foreach (x ; reverse_view(foo)) (y ; bar)
>>>   probably I could!
>>
>> foreach (x,y ; transpose_view(reverse_view(foo),bar)
>>   then why not this too?!
> 
> Because it doesn't keep bound variables together with the data. Perl has a way of initializing multiple variables that is unnerving:
> 
> my ($a, $b, $c) = (e1, e2, e3);
> 
> The long-distance relationships make it so irritating when ek are more than a couple of characters, I often give up and write:
> 
> my $a = e1;
> my $b = e2;
> my $c = e3;
> 
> even though I try to use vertical space sparingly.

You're of course welcome to your opinion, but multiple assignment exists in many languages.  So you're saying they're all wrong to have such a feature?

--bb

Nicolai Waniek wrote:
> The main problem I have with mixins/templates and so on is that it
> enables a programmer to change the "look and feel" of the language
> completely. What is bad about it? That if you're working in a team
> someone has a "great idea" and invents his own MyDSL. So what? Everyone
> else has to "learn" this new DSL. So they spend time on something they
> would've better spent on coding something else, or fixing bugs... I
> worked in a team of about 8 persons bugfixing a project with
> approximately 1.000.000 LoC. The former programmers just seemed to not
> know how to code (and we programmed using Delphi!!! a language most
> people like to tell you: "oh, that's a language that shows you how to
> work structured" - that's totally bullshit!).
> So on one hand, we had to improve the software as it was used by just
> too many companies to completely rewrite it - on the other hand we had
> to bugfix it with a syntax that even didn't look like Pascal. Now what?
> If we had someone "just for the sake of it" implementing something with
> his MyDSL, i would've probably killed him!

I hear you. I also find most uses C++ templates are put to to be incomprehensible - either from programmers showing off, or from working around the severe limitations of C++ templates.

Another big part of the problem is that templates are just hard to read and understand. If they were as easy to deal with as regular functions, then that difficulty would (I hope) melt away. This is what we're working towards.

I agree with you on another level - programmers showing off their understanding of the language by some need to use every feature of the language, MAKING SIMPLE THINGS COMPLICATED. To me, *real* programming skill is expressing complicated things in a simple manner.

One of my (unfavorite) examples of the making simple things complicated is the simple linked list concept:
	struct Foo
	{	Foo *next;
		...
	}
voila, a linked list. But nooo, for some reason (just for the sake of it? <g>), this has to be made complicated, with templates, macros, iterators, akk. There's a place for iterators, but they are overused.

My general feeling is that if one feels impelled to generate an incomprehensible tangle of templates:

1) one has found the wrong solution to the problem
2) there's a serious deficiency in the language (the C++ attempts to implement tuples is a canonical example).

Back in the 80's, C programmers discovered they could turn C code into Pascal with:
	#define BEGIN {
	#define END }
and went to town with that. It was belatedly discovered that this was a terrible idea. People can abuse mixins and DSLs in D, there's not much I can do to prevent it other than hope that soon a general consensus will emerge that overuse of it is also a bad idea.

Java went a different route, by disallowing all that stuff completely, but they inevitably threw the good out with the bad. Now, those features are, one by one, being added to Java anyway.

P.S. I've tried pretty hard to design operator overloading in D to prevent the abuses of it often seen in C++. I'm cautiously optimistic in this being successful.

janderson wrote:
> 
> What about using it for files that you are going to load at runtime otherwise? XML ect...?
> 
> -Joel

Loading the file belongs to runtime. Well, if it would take 10 minutes to load the file instead of 1 second if it was "loaded during compilation", that would be an argument for something like that - but I guess this won't be the case in most projects.

With your example: If you define something like that for compile time, it won't make it possible to change this dynamically, e.g. with a configuration file. If you write a super-D-duper library that loads file xyz and converts it to zyx, you won't want to sell the code (if it's not open source) so this possibility won't even fit to your business...

So, if "a" stands for "easy to learn, easy to use, fixed language" and "b" for "hard to learn because of dynamic language extension" you might get something like this for "not using mixins and that kind of stuff":

a [---|-----------] b

and the following, if you use them:

a [----------|----] b

Well I have to admit that there are some real good and well thought-out examples on how to reasonably use the new language features, but there will be more examples on how to _not_ use them. and the latter ones will be the ones with which we will have to struggle - and I don't want to struggle when programming, it usually is a joy! (and that's why I don't want to code in C++).

I'm really happy that you share my thoughts :o)

Let's hope that nobody will "over use" the new language features. As I
said (often enough) before, I really like the well though-out examples
on how to use the (new) features I don't really like (and I even
would've done some things the same way), but I fear the examples that
will drive me insane ;)

Nicolai Waniek wrote:
> Let's hope that nobody will "over use" the new language features.

They will over use them. Overusing them is a part of the process of learning how to program. I remember a professional race car driver telling me once that if the driver didn't walk back to the pits now and then carrying just the steering wheel, he wasn't pushing the limits hard enough.

But if he did it too often, he'd get fired <g>.

> As I
> said (often enough) before, I really like the well though-out examples
> on how to use the (new) features I don't really like (and I even
> would've done some things the same way), but I fear the examples that
> will drive me insane ;)

I think the best we can do is keep coming up with examples showing the right way to use them - lead by example.

And we should keep on frowning on attempts to use overloaded << for I/O purposes <g>.

Nicolai Waniek wrote:
> janderson wrote:
>> What about using it for files that you are going to load at runtime
>> otherwise? XML ect...?
>>
>> -Joel
> 
> Loading the file belongs to runtime. Well, if it would take 10 minutes
> to load the file instead of 1 second if it was "loaded during
> compilation", that would be an argument for something like that - but I
> guess this won't be the case in most projects.
> 
> With your example: If you define something like that for compile time,
> it won't make it possible to change this dynamically, e.g. with a
> configuration file. 

Maybe that's exactly the point.  You want configuration files that are easy to work with for developers, but you do not want end-users mucking with them.  Or small scripts that are part of a game engine.  You may want them loaded at runtime during development for easy modification, but when you ship your game you may prefer to have that script code embedded in the .exe where users can't muck with it.

Another case is where you want to have an all-in-one .exe with a tidy install.  If you have external configuration files then you have to worry about finding them at runtime and handling the case when you can't find them for whatever reason.  Easier to just embed and be done with it.

I don't think loading data files is a one-size-fits-all issue. Sometimes it makes sense to embed.

On the other hand, that doesn't mean you need import to do it.  You can always write an external tool too 'stringify' a data file.  In fact that's exactly what I did: http://www.dsource.org/projects/luigi/browser/trunk/luigi/wrapres.d

The new import makes much (but not all) of the functionality of that converter unnecessary.

--bb

Bill Baxter wrote:
> 
> Maybe that's exactly the point.  You want configuration files that are easy to work with for developers, but you do not want end-users mucking with them.  Or small scripts that are part of a game engine.  You may want them loaded at runtime during development for easy modification, but when you ship your game you may prefer to have that script code embedded in the .exe where users can't muck with it.
> 
> Another case is where you want to have an all-in-one .exe with a tidy install.  If you have external configuration files then you have to worry about finding them at runtime and handling the case when you can't find them for whatever reason.  Easier to just embed and be done with it.
> 
> I don't think loading data files is a one-size-fits-all issue. Sometimes it makes sense to embed.
> 
> On the other hand, that doesn't mean you need import to do it.  You can always write an external tool too 'stringify' a data file.  In fact that's exactly what I did: http://www.dsource.org/projects/luigi/browser/trunk/luigi/wrapres.d
> 
> The new import makes much (but not all) of the functionality of that
> converter unnecessary.
> 
> --bb


You could use ressource files linked to your EXE, so you wouldn't have to search for a file. You may even add your DLLs to your EXE and unwrap them at runtime ;)

I think as long as you use the language features in a sane way, it's ok. Just don't over-use them.

Walter Bright wrote:
> Nicolai Waniek wrote:
>> Let's hope that nobody will "over use" the new language features.
> 
> They will over use them. Overusing them is a part of the process of learning how to program. I remember a professional race car driver telling me once that if the driver didn't walk back to the pits now and then carrying just the steering wheel, he wasn't pushing the limits hard enough.
> 
> But if he did it too often, he'd get fired <g>.
> 
>> As I
>> said (often enough) before, I really like the well though-out examples
>> on how to use the (new) features I don't really like (and I even
>> would've done some things the same way), but I fear the examples that
>> will drive me insane ;)
> 
> I think the best we can do is keep coming up with examples showing the right way to use them - lead by example.
> 
> And we should keep on frowning on attempts to use overloaded << for I/O purposes <g>.

I think Lisp is a pretty good example here.  With all those reader macros etc you can really transform the language completely.  But (from what I gather) Lispers as a community have declared that to be bad style unless there's /really/ no other way to accomplish the desired goal.

(Regular (non-reader) lisp macro's can also be used to transform the language and define DSLs -- but there my impression is it's more like Henry Ford's "you can have any color you like, as long as it's black". With Lisp macros it's "you can create any DSL you like, as long as it still looks like fingernail clippings in oatmeal".)

--bb

Nicolai Waniek wrote:
> Bill Baxter wrote:
>> Maybe that's exactly the point.  You want configuration files that are
>> easy to work with for developers, but you do not want end-users mucking
>> with them.  Or small scripts that are part of a game engine.  You may
>> want them loaded at runtime during development for easy modification,
>> but when you ship your game you may prefer to have that script code
>> embedded in the .exe where users can't muck with it.
>>
>> Another case is where you want to have an all-in-one .exe with a tidy
>> install.  If you have external configuration files then you have to
>> worry about finding them at runtime and handling the case when you can't
>> find them for whatever reason.  Easier to just embed and be done with it.
>>
>> I don't think loading data files is a one-size-fits-all issue. Sometimes
>> it makes sense to embed.
>>
>> On the other hand, that doesn't mean you need import to do it.  You can
>> always write an external tool too 'stringify' a data file.  In fact
>> that's exactly what I did:
>> http://www.dsource.org/projects/luigi/browser/trunk/luigi/wrapres.d
>>
>> The new import makes much (but not all) of the functionality of that
>> converter unnecessary.
>>
>> --bb
> 
> 
> You could use ressource files linked to your EXE, so you wouldn't have
> to search for a file. 

Bleh.  Not cross-platform.

> You may even add your DLLs to your EXE and unwrap
> them at runtime ;)

Not sure what you mean by that.  But how am I going to create the DLL in the first place?  Anyway, anything involving dynamic libraries opens up the platform-specific can of worms.

> I think as long as you use the language features in a sane way, it's ok.
> Just don't over-use them.

Ok, I won't.  But I may end up in the pits carrying only my steering wheel a few times on the way to figuring out what "over-use" means.  ;-)

--bb