Okay, so this could get hairy.  Still, I think it deserves to be considered, so I'm posting it here.  Walter, if you're reading this... thanks for encouraging me to try the newsgroup.  I hope you see this, because I think it could be very important in the long run.

What I'm proposing is that functions and such which have been well established should not require explicit importing of the module that contains them.

I'm not saying that "all" established functions, objects, members, and so on should be automatically imported, but rather that the ones which are used as if they are a needed part of the D language should be treated as a part of the language, but without having to be built into the language.

For example, if I use the writef function but fail to specifically import a module that contains a function by that name, the D compiler could choose a default module for me from a list and import it without being asked to.  If I do import a module that contains a writef function, then the default module would not have to be imported.  If I neither specify to import a module that contains a writef function nor use a writef function, then again... the default module for the writef function would not be imported... unless another function that I did use also specified the same default module and I didn't specify a different module to import containing a variation of that other function.

I bring this up, because I have frequently seen C and C++ programmers talk about certain functions as if they are a built in part of the C language... most likely because they usually start with an old source file that's evolved from something they wrote longer ago than they can remember, and the include statements that they need most often are already in it.

This concept could theoretically be further expanded to allow parts of a module to be imported, based on possible dependancies... but I digress.

The idea is to simply make it so that features which are considered for all practical purposes to be a needed part of the language could simply be used as if they are a built in part of the language, saving the newbie programmer a whole lot of trouble in learning to write a simple program.

As an example, I should be able to write a "Hello world" program as follows...

int main()
{
 writef("Hello world!);
 return 0;
}

and have it compile and run "as is" rather than having to specifically import a module containing the writef function.

If I want the program to open a dialog in Windows or just print in DOS, then I should be able to write it as...

int main()
{
version(Windows)
 MessageBoxA(null,"hello!","message_box",MB_OK);
else
 writef("Hello world!);
 return 0;
}

That is, if the MessageBoxA function were included in implicit import list.  I know I'm not nearly qualified to say which functions should be considered that well known or that important to the programming community as a whole, but I'm sure there are people programming in D who are... and I would like their input.

I've never liked C, and I like C++ even less.  As programming languages go, they are among my least liked, but anyone who programs is forced to put up with them because they are just that pervasive.   One of the things that I dislike most about them is that they tend to discourage people from learning to program.  In the D programming language, I see the potential to capture what is good in C and C++ while doing away with this "no newbies allowed" attitude.

Here's what I think a minimal "Hello world" program "should" look like in D...

write("Hello world");

Yep.. that's it.  A keyword that could be guessed in a few tries by someone who has never used the language, and the established D syntax, with an implied main function and an implied return value.

Think about it.  How many programs have you seen that have...
return 0;
}
...at the end?

If a module with no return value at the end is compiled and linked to run as a standalone program, the compiler-linker should be able to make the assumprion that 0 is to be returned when the "end" of the program is reached.

Also, if no main function is found in a module, but there is a list of statements not enclosed in anything... that list should be assumed to be the main function.

I might even go as far as to say that if someone tries to see what's in args[][1] in the main function without first specifying what "args" stands for, the compiler could probably make an assumption about that too... and if it's not obvious to someone reading this what that assumption should be, it would probably surprise most of the other people reading this... because there is a well known standard usage that probably every D programmer is familliar with.

Okay, so instead of "write" I could have used "writef" which is more established... but my point is, while it's nice to make the D language feel familliar to established programmers, I would think it equally important to make it easy for a new programmer to get started in.

Donald A. Kronos, PhD. - TechnoZeus

TechnoZeus wrote:

> I bring this up, because I have frequently seen C and C++ programmers
> talk about certain functions as if they are a built in part of the C
> language... most likely because they usually start with an old source
> file that's evolved from something they wrote longer ago than they
> can remember, and the include statements that they need most often
> are already in it.

It's sad when precompiled headers and compiler prefixes files
rots the brain like that :-) Seriously, the C and C++ standard
headers are pretty well defined ? #include <stdlib.h>, and friends.

In Java, that loads "code" very differently from what C/C++ does,
you can call upon a routine by just referencing to the full name :
i.e. "std.stdio.writefln", but that does not work as easy in D
(since the "import" is more than just a syntax convenience here)

> As an example, I should be able to write a "Hello world" program as
> follows...
> 
> int main() { writef("Hello world!); return 0; }
> 
> and have it compile and run "as is" rather than having to
> specifically import a module containing the writef function.

There are several other things in that program that could be simpler.

For instance, the EXIT_SUCCESS return value (a.k.a "0") could be implied by declaring the function as "void main()" (this does not work yet in D)

And you could have a "write" function that avoids learning that all %
characters must be written as %%, to avoid the exceptions at runtime ?

Perhaps even use the "ln" versions, to avoid learning that you escape
a newline character like "\n", when escaped in a string like that.

Thus:

import std.stdio;
void main()
{
  writeln("Hello, World!");
}

> I've never liked C, and I like C++ even less.  As programming
> languages go, they are among my least liked, but anyone who programs
> is forced to put up with them because they are just that pervasive.
> One of the things that I dislike most about them is that they tend to
> discourage people from learning to program.  In the D programming
> language, I see the potential to capture what is good in C and C++
> while doing away with this "no newbies allowed" attitude.

Oh, I'm not sure that D would be your new best friend either, then ?
I find that they do encourage people to learn, by *not* holding hands.

Although with a little better documentation, it shouldn't be *that*
scary for newcomers - just a bit complex as a first language to learn.

> Here's what I think a minimal "Hello world" program "should" look
> like in D...
> 
> write("Hello world");
> 
> Yep.. that's it.  A keyword that could be guessed in a few tries by
> someone who has never used the language, and the established D
> syntax, with an implied main function and an implied return value.

With all due respect, you might want to try another language...
There are several languages, where things like that are allowed.

Something with a little connection to DMD is DMDscript, for instance ?
It all depends on what you are trying to do... (probably not "say hi")

--anders

Thanks for the response.

Yes, that's the kind of stuff I'm talking about. The most commonly "needed" stuff that's not "built in" so that they can be used without having to import them explicitly.  Especially those that are already part of the Phobos runtime library.

There would be one disadvantage that I can think of.  Imigine this example: Someone writes a program that uses a function from std.c.stdio and later a D specific version of that function is added to std.stdio and set as the default for that function.  If the program was re-compiled, it would implicitly import the function from it's new default module and if that version was not backward compatible, it could break the program.

Of course, such a scenario would only happen if the programmer had "not" specified to import a specific module, in which case it would have been a broken program already the way things are right now... and fixing it would require nothing more than to add the import line.  Also, that scenario would only happen in cases where it was decided that replacing the old function with a new one that may break older programs was worth the trade-off... which I suspect would be likely to happen if the function was indeed well known and well established.

Yes, the import is more than just a syntax convenience, but in some cases it is actually an inconvenience.  There's no real reason a person should have to explicitly import a module to do simple common tasks like getting keyboard input, printing something to the screen, reading a file or directory, multithreading an application, extracting the extension from a filename, extracting a numeric value from a string, or generating a random number... and there's also no need to have all those functions "built into the compiler" when importing them works just fine.  Implicit importing should deliver the best of both worlds.

----

Actually, "void main()" does work in D, but I hadn't thought of that until after I had already posted my comments.  How-ever, it could still be simplified by allowing compilation without even declaring a main function.  Is it worth while?  I'm not sure... but I tend to think it would be.  Not because programmers would like to be able to save typing a couple of lines of text, but because it would help to facilitate new programmers learning the D language more independantly.

I like that... a write function that acts differently than the writef function... one that works perhaps more like the Print statement in most versions of BASIC, or like the write statement in Pascal.  Walter?  Care to comment on the possibility of something like a write and writeln statement being added as built-in functions?

Just a side thought: I wonder if a "write" function could be made platform and operating system independant somehow... and where it would write to in Windows if no output device or object was specified.

Yes, I know what you mean.  Since D is derived from C and in some ways from C++, it's to be expected that most of the people using it will be long standing C and C++ programmers... at first.  Keep in mind though, that most of the people who have been programming C or C++ for many years are not going to be all that anxious to learn yet another programming language.  Those who are already learning D are of course most likely the exception, but if D is to thrive in the long run it will be mostly due to it's popularity with people who are not too set in their ways with any one specific programming language when they encounter D for the first time.  That includes those of us who have never had a single favorite programming language as well as those who have never programmed at all.

As for me trying another language... I was writing my own assemblers and compilers well over 20 years ago, and I've written plenty of programs in straight hexadecimal machine language on various processors.  Yes, I would like it simpler for me... because it would make the experience of learning it that much more enjoyable, but that's not the "reason" that I would like to see it simplified.  I would like to see it simplified first because it would be better that way and I'm all for making it better, and second because it would mean that more people could learn the language who might not otherwise.

And yes, there are other languages where things like that are allowed... which proves that it can be done.  There's no reason that I can see why D should have to follow in the footsteps of C when it comes to the learning curve.  As I stated before, I see in the D language the potential to capture what is good in C and C++ while doing away with this "no newbies allowed" attitude that has plagues those two languages for far too long.  Everyone who programs ANY language was once a newbie at it, so we should give the newbies some respect because some of them will be programming circles around us some day.

TZ


"Anders F Björklund" <afb@algonet.se> wrote in message news:d3in7m$18f9$1@digitaldaemon.com...
>
> It's sad when precompiled headers and compiler prefixes files
> rots the brain like that :-) Seriously, the C and C++ standard
> headers are pretty well defined ? #include <stdlib.h>, and friends.
>
> In Java, that loads "code" very differently from what C/C++ does, you can call upon a routine by just referencing to the full name : i.e. "std.stdio.writefln", but that does not work as easy in D (since the "import" is more than just a syntax convenience here)
>
>
> There are several other things in that program that could be simpler.
>
> For instance, the EXIT_SUCCESS return value (a.k.a "0") could be implied
> by declaring the function as "void main()" (this does not work yet in D)
>
> And you could have a "write" function that avoids learning that all % characters must be written as %%, to avoid the exceptions at runtime ?
>
> Perhaps even use the "ln" versions, to avoid learning that you escape a newline character like "\n", when escaped in a string like that.
>
> Thus:
>
> import std.stdio;
> void main()
> {
>    writeln("Hello, World!");
> }
>
>
> Oh, I'm not sure that D would be your new best friend either, then ? I find that they do encourage people to learn, by *not* holding hands.
>
> Although with a little better documentation, it shouldn't be *that* scary for newcomers - just a bit complex as a first language to learn.
>
>
> With all due respect, you might want to try another language... There are several languages, where things like that are allowed.
>
> Something with a little connection to DMD is DMDscript, for instance ? It all depends on what you are trying to do... (probably not "say hi")
>
> --anders
>

TechnoZeus wrote:

> I like that... a write function that acts differently than the writef
> function... one that works perhaps more like the Print statement in
> most versions of BASIC, or like the write statement in Pascal.
> Walter?  Care to comment on the possibility of something like a write
> and writeln statement being added as built-in functions?

I've already written the write and writeln functions, and
they're working just fine. :-) (just waiting to get added)

It's actually writef without the formats. Nothing more,
and nothing less (not sure what BASIC and Pascal does ?)

> As for me trying another language... I was writing my own assemblers
> and compilers well over 20 years ago, and I've written plenty of
> programs in straight hexadecimal machine language on various
> processors.  Yes, I would like it simpler for me... because it would
> make the experience of learning it that much more enjoyable, but
> that's not the "reason" that I would like to see it simplified.  I
> would like to see it simplified first because it would be better that
> way and I'm all for making it better, and second because it would
> mean that more people could learn the language who might not
> otherwise.

Sounds good, as I didn't mean to scare anyone off from using D...
Nothing wrong with being new, as long as you're willing to learn.

Just that if you want a simple program, to do stuff like say "hi";
then there are more productive languages than using C, C++ or D.

I use Perl, others prefer Python... Ruby is a great language too.
Even a simple shell script would do. But I wouldn't touch .BAT :-)

--anders

Yes, I agree.  For one, any interpreted language is likely to be rather efficient for the development of very simple programs since there is no need for the compilation step, although I have also seen language implementations compile transparantly from the editor in the integrated development environment so that the programmer never had to even know it was compiled unless they wanted to distribute their program to someone who didn't have the IDE to run the source code from.

There's always a better way.  The trick is in finding it.  :)

TZ

"Anders F Björklund" <afb@algonet.se> wrote in message news:d3j5km$1lnu$1@digitaldaemon.com...
> TechnoZeus wrote:
>
> > I like that... a write function that acts differently than the writef function... one that works perhaps more like the Print statement in most versions of BASIC, or like the write statement in Pascal. Walter?  Care to comment on the possibility of something like a write and writeln statement being added as built-in functions?
>
> I've already written the write and writeln functions, and
> they're working just fine. :-) (just waiting to get added)
>
> It's actually writef without the formats. Nothing more,
> and nothing less (not sure what BASIC and Pascal does ?)
>
> > As for me trying another language... I was writing my own assemblers and compilers well over 20 years ago, and I've written plenty of programs in straight hexadecimal machine language on various processors.  Yes, I would like it simpler for me... because it would make the experience of learning it that much more enjoyable, but that's not the "reason" that I would like to see it simplified.  I would like to see it simplified first because it would be better that way and I'm all for making it better, and second because it would mean that more people could learn the language who might not otherwise.
>
> Sounds good, as I didn't mean to scare anyone off from using D... Nothing wrong with being new, as long as you're willing to learn.
>
> Just that if you want a simple program, to do stuff like say "hi"; then there are more productive languages than using C, C++ or D.
>
> I use Perl, others prefer Python... Ruby is a great language too. Even a simple shell script would do. But I wouldn't touch .BAT :-)
>
> --anders

TechnoZeus wrote:
> Yes, I agree.  For one, any interpreted language is likely to be
> rather efficient for the development of very simple programs since
> there is no need for the compilation step, although I have also seen
> language implementations compile transparantly from the editor in the
> integrated development environment so that the programmer never had
> to even know it was compiled unless they wanted to distribute their
> program to someone who didn't have the IDE to run the source code
> from.
> 
> There's always a better way.  The trick is in finding it.  :)

There's always dscript. (Not the same as DMDscript.)

It compiles transparently, so all you do is write the code and then run it. But it does not work on windows (yet).

Well, I still think D has real potential.  It's new... so give it some time.  Of course, the people standing behind it can make all the difference in the world.

Adding the ability for the compiler to look things up in an implied import table if they are not declared or imported explicitly wouldn't change any existing programs, and would make it a little easier for experienced programmers to write programs more quickly and a lot easier for newbies to learn the D programming language.

Adding the ability to have the compiler treat a missing main function declaration as an implication that the first line of the unenclosed code is the program's entry point and that reaching the end of the program returns 0, might require a little more integration between the ideas of compiling and linking, but again wouldn't change any existing programs, and would make it easy for someone learning the language to write very short practice programs to test their understanding of how the parts of it work.

Adding the ability to let the compiler recognize a program as being written for a specific environment and save the programmer the trouble of specifying such details as how to link it would still allow overriding of that default functionality, but would again make it easier for a beginner to learn.

Adding long filename support to the compiler and the ability to have it look in default relative paths for files that are commonly needed to compile and link a program wouldn't break any existing functionality, if done right, but would make the compiler that much easier to use... especially for beginners.

Adding a graphical user interface that allows the source code to be edited, and run with transparent compiling and linking for the operating system it's installed on, would make D as easy to use as an interpreted language, but without removing any of it's current advantages.  That same graphical interface could have menu options for compiling and linking to other platforms.

I see no down side to any of this, except the following:  None of it will happen without a lot of work going into it.

So, what it comes down to is a simple question of what's worth the effort it would take, and what isn't.  I think the key to it is colaboration, but can this be accomplished to a sufficient degree?

TZ

"Georg Wrede" <georg.wrede@nospam.org> wrote in message news:425E327E.9050403@nospam.org...
> TechnoZeus wrote:
> > Yes, I agree.  For one, any interpreted language is likely to be rather efficient for the development of very simple programs since there is no need for the compilation step, although I have also seen language implementations compile transparantly from the editor in the integrated development environment so that the programmer never had to even know it was compiled unless they wanted to distribute their program to someone who didn't have the IDE to run the source code from.
> >
> > There's always a better way.  The trick is in finding it.  :)
>
> There's always dscript. (Not the same as DMDscript.)
>
> It compiles transparently, so all you do is write the code and then run it. But it does not work on windows (yet).

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

TechnoZeus schrieb am Thu, 14 Apr 2005 04:31:09 -0500:
> Adding the ability to have the compiler treat a missing main function
> declaration as an implication that the first line of the unenclosed code
> is the program's entry point and that reaching the end of the program
> returns 0, might require a little more integration between the ideas of
> compiling and linking, but again wouldn't change any existing programs,
> and would make it easy for someone learning the language to write very short
> practice programs to test their understanding of how the parts of it work.

Consequence: Compiling would dependend on the order of the source files given - that's troublesome.

> Adding the ability to let the compiler recognize a program as being written for a specific environment and save the programmer the trouble of specifying such details as how to link it would still allow overriding of that default functionality, but would again make it easier for a beginner to learn.

An example please.

> Adding long filename support to the compiler
Just tested it and had no problems with a long(267 character) file name.

>  and the ability to have it look in default relative paths for files
> that are commonly needed to compile and link a program wouldn't break
> any existing functionality, if done right, but would make the compiler
> that much easier to use... especially for beginners.

Have a look at dmd/sc.ini dmd/dmd.conf.

> Adding a graphical user interface that allows the source code to be edited, and run with transparent compiling and linking for the operating system it's installed on, would make D as easy to use as an interpreted language, but without removing any of it's current advantages.

That the job of an IDE(editing) or of an VM(interpreted) not the compiler.
Ofcoure the VM(in the broad sence) could be integrated into the IDE and
closely interact with the compiler.

> That same graphical interface could have menu options for compiling and linking to other platforms.

Crosslinking is non-trivial. Adding crosscompiling to DMD should be fairly easy.

> I see no down side to any of this, except the following:  None of it will happen without a lot of work going into it.

I'm sure you know what I'm going to say:

1) analyse the situation, shortcommings, desires etc.
2) have a vision
2) analyse available capabilities/resource
3) set a target
4) aquire required capabilities/resource
...

> So, what it comes down to is a simple question of what's worth the effort it would take, and what isn't.  I think the key to it is colaboration, but can this be accomplished to a sufficient degree?

If you dont start a project or join an existing to fulfill your vision you wont reach your target.

In case you lack the capabilities I'm sure there peoples you could encourage and/or bribe into helping you.

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFCXkKK3w+/yD4P9tIRAvNjAJ9xlakIFwarrYVwPqEzVelMlPfAEQCgjfxE
VLHYBcpd3ujKkzWeg73bXDI=
=i/0B
-----END PGP SIGNATURE-----

> I would like to see it simplified first because it would be better that
> way and I'm all for making it better, and second because it would
> mean that more people could learn the language who might not
> otherwise.

Not to sound arrogant or anything... but people that could learn the language better with an implied main function are just the people we don't want programming in the first place.

There, someone finally said it :-P.  I, for one, am tired of looking at code written by bad programmers.  Dumbening (thanks Lisa Simpson) languages up is not going to help make better coders - just more bad/mediocre ones.

It's almost akin to saying "lets remove all prepositions from English to make it easier for dumber kids to speak it."  What does this do to the overall quality of the English language (as if it was ever that great to begin with)?  The result:  we're all talking like morons.

I'm not harping on you personally, TZ, and I of course mean you no offense.  I apologize if I did offend you.

Regards,
James Dunne

I hate to tell you this, but "everyone" learns better that way.

There are many differences in people's learning styles, but one thing that all biological brains I have ever encountered have in common with all forms of artificial intellegence I have ever looked into is that they all learn to recognize and understand something with more accuracy in a shorter time if that "something" is less obscured.

If you don't believe me, try teaching yourself machine language on a processor that you've never worked with by reading hexadecimal dumps of programs.  I've done it, and I can tell you from experience it's not easy... but more importantly, it's impossible to be sure you've actually understood any of it correctly until you start testing your understanding in actual programs of your own.

Furthermore, the accuracy of any theories that you can't isolate and test separately will permanently remain dependant on your understanding of the parts that you couldn't isolate them from.  Therefore, if it's impossible to isolate one part from another part, if you are wrong about one you will likely be wrong about the other also and never even know it.  Sure, you can write "working" code that way... but there's a big difference between successful morphology of a working program into another working program and actual understanding of how the programming language works.

As for your reference to English, if happens to be a disaster of a language... but that's a whole other topic.  More to the point, there are many fluent speakers of English who still use the word "unthaw" to mean "thaw" and "borrow" to mean "loan" because they have never isolated those words and learned to understand them outside of the context in which they are used to encountering them.

The word "inflammable" used to be printed on cans for petroleum feuls such as gasoline, but they don't do that anymore because too many people thought it meant "won't burn" when the intended definition was "flammable" which is confusing enough in itself since it makes one wonder what happened to the "-in" prefix, but the confusion doesn't stop there.  "inflammable" also means "easily inflamed" and "inflamed" can mean either set on fire or having "inflammation" which in turn more often means "swelling" than "burning" but again, depends on the context.

I once suggested to Microsoft that they add a choice between tiling windows horizontally or vertically, which they promptly added... but with the ambiguous wording of "horizontal tile" and "vertical tile" where the word "tile" could be interpreted as either a verb or a noun, and the direction of the tiling would be different for one interpretation than the other.  I pointed this out, and they decided to fix it.

I suggested that they use "portrait tile" and "landscape tile" which were well known already in many industries and non-ambiguous, but also mentioned the option of "horizontal tiles" and "vertical tiles" which matched what was the current functionality at that time, would be the easiest change to make, and was unambiguous and more accurate (since nobody really tiles a single item anyway), and of course the option of changing them to "tile horizontally" and "tile vertically" which would specify that "tile" was being used as a verb, since adverbs aren't used to modify nouns... but also pointed out that this change would be the least desireable, since it would require swapping the then current functionality and hence the existing keyboard shortcuts.

Well, they chose to go with the my "last choice" and not to swap the two, so now we have a "Tile Windows Horizontally" option that tiles windows vertically, and a "Tile Windows Vertically" function that tiles windows horizontally.  I did attempt to address this issue, but I was told that they had a big meeting in which a top executive which the employee I was speaking with felt it would be in his interest not to actually mention by name, had decided that "horizontally" meant top to bottom, and "vertically" meant left to right.

So, you may wonder how someone can come to such nonsensical conclusions... or perhaps you're one of the many people who agrees with that notion.  I wouldn't know... but I can tell you where it came from...

Back when televisions still had tubes in them that controlled various functions and occasionally needed to be replaced, if the horizontal oscillation tube went bad, the television would display a vertical line, because the cathode ray no longer scanned horizontally.  Technicians called this a "horizontal collapse" or in more common terms, simpy a horizontal problem.  They would tell customers who reported a single white line from the top of the TV screen to the bottom, "that's your horizontal" and for likewise would tell those who reported a single white line from left to right "that's your vertical" usually with no further explanation.  As a result, many people who were previously unfamilliar with these terms, including a lot of children growing up when televisions were new and broke down a lot, learned the meanings of "horizontal" and "vertical" wrong because they learned them in context without the opportunity to isolate them.

Maybe "you" don't want people who like to learn things thoroughly and accurately to join the D programming community, but I highly doubt that you speak for everyone in that regard.  I know you don't speak for me.

"James Dunne" <jdunne4@bradley.edu> wrote in message news:d3lm5v$q76$1@digitaldaemon.com...
> > I would like to see it simplified first because it would be better that
> > way and I'm all for making it better, and second because it would
> > mean that more people could learn the language who might not
> > otherwise.
>
> Not to sound arrogant or anything... but people that could learn the language better with an implied main function are just the people we don't want programming in the first place.
>
> There, someone finally said it :-P.  I, for one, am tired of looking at code written by bad programmers.  Dumbening (thanks Lisa Simpson) languages up is not going to help make better coders - just more bad/mediocre ones.
>
> It's almost akin to saying "lets remove all prepositions from English to make it easier for dumber kids to speak it."  What does this do to the overall quality of the English language (as if it was ever that great to begin with)?  The result:  we're all talking like morons.
>
> I'm not harping on you personally, TZ, and I of course mean you no offense.  I apologize if I did offend you.
>
> Regards,
> James Dunne