January 25, 2005
>>> Or, maybe a smaller version of D (D--? ;) )
>> Lets call it "Dmin".
> If we really want to be clever, we could call it "d".

This got me thinking about language names in general. And how the requisites around a new language have changed in the past two decades.

((Please everybody, I'm not critisicing D here. This is just thoughts about languages to be.))   :-)

In the old days, a language name like C was cool. It was easy to remember, short, and at the time to-the-point, considering its origins. It was easy to spot on book covers and backs, mainly because you could print it with a huge font.

Today such a name would be awkward and a hindrance to a rapid spread of know-how about it. Why? Well, today information about a language is sought on the net, and a name that is inconvenient to search for should be avoided. Ideally, a name should give you "all" the pertinent hits, and "no" false hits.

Bad examples would be all one-character names (a A B 1 0 Z = :, etc.). Good examples (I hope) are zoobyboo, GungkFoo, JavaScript, KoffeeWrite, and so on. (We all know the name JavaScript is a bit dishonest, but it still is an excellent example here.)

To help search engines differentiate between posted code and discussion about the language, there should be a source code convention. Pascal used to have (a redundant) compulsory line at the very beginning

program <program name here>

Carrying this idea forward, we could have the compiler enforce that the language name appear at the very start. Add to this the major and minor version of the language, and we're pretty well off.

KoffeeWrite 2.5: myprog.kw
blabla blabla
blabla
blabla blabla blabla

What exactly is done with the version number depends. If the language is a compiled language, then the compiler might enforce and check that the number is acceptable. Say, the difference between v2.5 and v2.4 is only bug fixes, then 2.4 code would be accepted as-is. Otherwise, any time there is a compile time error, the compiler would remind you about a possible version problem. If we are ambitious, any newer compiler would accept old code and compile it in "compatibility mode".

"Everybody" uses an IDE in the future, and it would write the first line for you.

Well, version numbers or not, starting a new language today needs a more professional attitude, way beyond just having a good syntax and a bug free reference implementation. It's like with cars: in 1910 it was enough that you took a barn door and slapped 4 wheels on it, and an engine. Today, a new car goes through research and development and marketing study -- even before anyone even considers making a clay model, let alone a prototype.

If you want success for the language, you have to be diligent, right from the start. Philip Morris spent millions to find out the exact shade of red to use on packs of Marlboro cigarrettes.

With the number of programming languages growing exponentially (at least in the immediately foreseeable future), the scene is like a car market where everyone has a self-made "best car in the world", but nobody ever hired a salesman or a marketing company.

The choice of name is arguably more important than any one of the thousands of single language and design decisions.
January 26, 2005
"Georg Wrede" <georg.wrede@nospam.org> wrote in message news:41F61D6E.5090507@nospam.org...
> The choice of name is arguably more important than any one of the thousands of single language and design decisions.

I agree. I understand the issue with googling "D", but calling D "D" has been effective in interesting the kinds of programmers who would be interested in a reengineering of C++. It started out as a nickname, but it soon became obvious that "D" was the right name for the language.


January 26, 2005
Hi!

> - Games, games, games.  We've seen some inital offerings from the far east in the form of Warning Forever and Torus Trooper; both of which are great games. Its amazing what SDL bindings and a nose for fast code can accomplish (both of the above play nicely on my 400Mhz P2).

I'm currently learning to code games with D, but with Allegro. This is one of my dreams:) I've never found before a language so nice to the programmer, and still fast and...

> To that end, I've put off replacing my
> existing machine (the "400Mhz Franken-vunder-box") as the
> code-compile-test loop is lightning fast compared to the competition; Its
> *very* usable at this speed.

Yes, this is absolutely wonderful :) I have a P3 500 and compilation is near
real time:)) It looks like an interpreted language:))

Byez!!!

Carotinho

January 26, 2005
Carotinho wrote:
> Yes, this is absolutely wonderful :) I have a P3 500 and compilation is near
> real time:)) It looks like an interpreted language:))

Yeah... but that's why D is evil. Most programmers love long compile times. Why ? Check this out: http://www.flipcode.com/cgi-bin/fcarticles.cgi?show=63877
We definitely need something like this in D...
January 26, 2005
"Carotinho" <carotinobg@yahoo.it> wrote in message news:ct6ov6$l0$1@digitaldaemon.com...
> > To that end, I've put off replacing my
> > existing machine (the "400Mhz Franken-vunder-box") as the
> > code-compile-test loop is lightning fast compared to the competition;
Its
> > *very* usable at this speed.
>
> Yes, this is absolutely wonderful :) I have a P3 500 and compilation is
near
> real time:)) It looks like an interpreted language:))

That's one of the reasons I use an old machine to do development on. It motivates me to keep it running fast.


January 26, 2005
h3r3tic wrote:

>> Yes, this is absolutely wonderful :) I have a P3 500 and compilation is near real time:)) It looks like an interpreted language:))
> 
> Yeah... but that's why D is evil. Most programmers love long compile times.

It also varies a lot between project size and D compiler,
for instance Mango takes quite a while to compile with GDC...

ccache and Make makes most C compilations quite speedy as well.
(http://ccache.samba.org/)

--anders
January 26, 2005
"Anders F Björklund" <afb@algonet.se> wrote in message news:ct7k6s$12f7$1@digitaldaemon.com...
> It also varies a lot between project size and D compiler, for instance Mango takes quite a while to compile with GDC...

There was a bug in the compiler I fixed in .110 or .111 that resulted in some very slow compiles for complex projects. Some compiles speeded up by a factor of a thousand or more <g>.


January 26, 2005
Walter wrote:

>>It also varies a lot between project size and D compiler,
>>for instance Mango takes quite a while to compile with GDC...
> 
> There was a bug in the compiler I fixed in .110 or .111 that resulted in
> some very slow compiles for complex projects. Some compiles speeded up by a
> factor of a thousand or more <g>.

Well,
speed isn't the most important problem - as it fails...
http://www.digitalmars.com/drn-bin/wwwnews?D.gnu/981

Currently it also has to give all the sources as
input to the dmd tool, instead of just compiling
the changed sources (some kind of dependency thing?)

--anders
January 26, 2005
Walter wrote:
> "Georg Wrede" <georg.wrede@nospam.org> wrote in message
> news:41F61D6E.5090507@nospam.org...
> 
>>The choice of name is arguably more important than any one of the
>>thousands of single language and design decisions.
> 
> 
> I agree. I understand the issue with googling "D", but calling D "D" has
> been effective in interesting the kinds of programmers who would be
> interested in a reengineering of C++. It started out as a nickname, but it
> soon became obvious that "D" was the right name for the language.

Right. Every rule has its exceptions, and D definitely is one. Considering the target audience of D and the origins of D, one could hardly come up with a more suitable name! Also, the kind of guys we want here have to be literate enough to search successfully for single-letter stuff on the net.

Besides, we want to make D so good that an E never will appear. :-)
January 26, 2005
Andy Friesen wrote:
<snip>
> If we really want to be clever, we could call it "d".

Hmm ... how would that name be pronounced?

And what would its filename extension be?  .D?

Of course, it could spark confusion on file systems that aren't even case-retentive.  But at least MS-DOS and Windows 3.x and below are 16-bit systems, and so the ambiguity is gone (at least as long as you're coding/compiling for the local platform).

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.