View mode: basic / threaded / horizontal-split · Log in · Help
June 20, 2009
Re: The proper case for D.
superdan Wrote:

> Steve Teale Wrote:
> 
> > Can this group come up with a proper, sober (OK, I'm not)
> 
> den pretty please explain why anyone should give a flyin' fuck fer yer drunken rant.


And your response is why D is never going to be more than a beta compiler and interesting discussion piece between a small number of programmers.

If it wants to compete with the 'big boys' it needs an IDE, a GUI library that can compile and work, a debugger that understands D, a proper linker, packaged releases for linux, an installer for Windows, etc.

D2 is in danger of becoming a camel i.e. a horse designed by a committee...

Frank.
June 20, 2009
Re: The proper case for D.
Frank Rundell wrote:

> superdan Wrote:
> 
>> Steve Teale Wrote:
>> 
>> > Can this group come up with a proper, sober (OK, I'm not)
>> 
>> den pretty please explain why anyone should give a flyin' fuck fer yer
>> drunken rant.
> 
> 
> And your response is why D is never going to be more than a beta compiler
> and interesting discussion piece between a small number of programmers.
> 
> If it wants to compete with the 'big boys' it needs an IDE, a GUI library
> that can compile and work, a debugger that understands D, a proper linker,
> packaged releases for linux, an installer for Windows, etc.
> 
> D2 is in danger of becoming a camel i.e. a horse designed by a
> committee...
> 
> Frank.

?

As far as I know, the 'committee' consists of a gang of three, with Walter 
firmly at the driving seat, all working very hard to flesh out a language, 
create an innovative library and quality compiler. All the tools and 
libraries you mention are being created. In addition there's also LDC which 
is shaping up nicely. Not to say everything is already here, but that is a 
question of time and manpower, not direction.

What's up with all the negativity lately? Impatience?
June 20, 2009
Re: The proper case for D.
Lutger wrote:

...
> What's up with all the negativity lately? Impatience?

Or is everybody drunk, am I missing a party?
June 20, 2009
Re: The proper case for D.
>> D2 is in danger of becoming a camel i.e. a horse designed by a
>> committee...
>>
>> Frank.
> 
> ?
> 
> As far as I know, the 'committee' consists of a gang of three, with Walter 
> firmly at the driving seat, all working very hard to flesh out a language, 
> create an innovative library and quality compiler. All the tools and 
> libraries you mention are being created. In addition there's also LDC which 
> is shaping up nicely. Not to say everything is already here, but that is a 
> question of time and manpower, not direction.
> 
> What's up with all the negativity lately? Impatience?

Some people think D2 tries too much, and neglects the really important 
things at the same time. For example, D2 tries to solve the concurrency 
issue (which is a hot topic which makes D look good at sites like 
stackoverflow), while still relying on a 20 years old linker written in 
assembler.
June 20, 2009
Re: The proper case for D.
grauzone wrote:

>>> D2 is in danger of becoming a camel i.e. a horse designed by a
>>> committee...
>>>
>>> Frank.
>> 
>> ?
>> 
>> As far as I know, the 'committee' consists of a gang of three, with
>> Walter firmly at the driving seat, all working very hard to flesh out a
>> language, create an innovative library and quality compiler. All the
>> tools and libraries you mention are being created. In addition there's
>> also LDC which is shaping up nicely. Not to say everything is already
>> here, but that is a question of time and manpower, not direction.
>> 
>> What's up with all the negativity lately? Impatience?
> 
> Some people think D2 tries too much, and neglects the really important
> things at the same time. For example, D2 tries to solve the concurrency
> issue (which is a hot topic which makes D look good at sites like
> stackoverflow), while still relying on a 20 years old linker written in
> assembler.

So the better direction according to some is to stagnate language design for 
D2 so Walter Bright can reinvent the linker? So that years later when asked 
why D didn't do more for concurrency when it was needed, you'd have to 
reply: "well there wasn't any time to deal with such trivial issues, the 
language designer had to work on the toolchain."
June 20, 2009
Re: The proper case for D.
> So the better direction according to some is to stagnate language design for 
> D2 so Walter Bright can reinvent the linker? So that years later when asked 

No, but to use a real linker instead of that piece of crap.

> why D didn't do more for concurrency when it was needed, you'd have to 
> reply: "well there wasn't any time to deal with such trivial issues, the 
> language designer had to work on the toolchain."

Eh, you seriously think D2 would still be in use at that time? We will 
have D325858 which broke backwards compatibility for the 325858th time. 
This issue (multithreading) seriously could wait a bit longer. The most 
hilarious thing is that multithreading support in Phobos was incredibly 
buggy, and even today, basic multithreading primitives like condition 
variables are lacking from Phobos. Oh yeah, we got builtin mutexes so 
that we can say "D supports multithreading on the language level". Funny.
June 20, 2009
Re: The proper case for D.
grauzone wrote:
>> So the better direction according to some is to stagnate language 
>> design for D2 so Walter Bright can reinvent the linker? So that years 
>> later when asked 
> 
> No, but to use a real linker instead of that piece of crap.

With objconv, it might be possible to use a different linker on Windows. 
I'm considering doing so since Optlink won't work with the debug build 
of one of my libraries (it's 22MB), and it doesn't seem to discard any 
unreferenced library symbols, so the release build of my code is ~9.5MB, 
while it should be ~4.
June 20, 2009
Re: The proper case for D.
grauzone wrote:

>> So the better direction according to some is to stagnate language design
>> for D2 so Walter Bright can reinvent the linker? So that years later when
>> asked
> 
> No, but to use a real linker instead of that piece of crap.

And this real linker is going to magically appear from nowhere? 

>> why D didn't do more for concurrency when it was needed, you'd have to
>> reply: "well there wasn't any time to deal with such trivial issues, the
>> language designer had to work on the toolchain."
> 
> Eh, you seriously think D2 would still be in use at that time? We will
> have D325858 which broke backwards compatibility for the 325858th time.
> This issue (multithreading) seriously could wait a bit longer. The most
> hilarious thing is that multithreading support in Phobos was incredibly
> buggy, and even today, basic multithreading primitives like condition
> variables are lacking from Phobos. Oh yeah, we got builtin mutexes so
> that we can say "D supports multithreading on the language level". Funny.

D1 is stable and actively supported. Tango has the functionality. LDC has 
the linker and work is being done that other OS. Now, what is problem? 
Really I don't understand.

But ok, if you don't think of multithreading to be a big deal and find 
existing solutions perfectly adequate, generic programming a niche 
functionality and functional programming overrated, then the whole D2 deal 
certainly looks like a wasted effort better spend on writing a linker.
June 20, 2009
Re: The proper case for D.
== Quote from grauzone (none@example.net)'s article
> >> D2 is in danger of becoming a camel i.e. a horse designed by a
> >> committee...
> >>
> >> Frank.
> >
> > ?
> >
> > As far as I know, the 'committee' consists of a gang of three, with Walter
> > firmly at the driving seat, all working very hard to flesh out a language,
> > create an innovative library and quality compiler. All the tools and
> > libraries you mention are being created. In addition there's also LDC which
> > is shaping up nicely. Not to say everything is already here, but that is a
> > question of time and manpower, not direction.
> >
> > What's up with all the negativity lately? Impatience?
> Some people think D2 tries too much, and neglects the really important
> things at the same time. For example, D2 tries to solve the concurrency
> issue (which is a hot topic which makes D look good at sites like
> stackoverflow), while still relying on a 20 years old linker written in
> assembler.

But linkers are an implementation detail, threading is really central to what
you'd call "the language".  To me the most important thing for Walter is to get a
stable, well-thought out spec and a "good enough" reference/proof of concept
implementation of that spec out the door.  This means implementing all features
that are going to be implemented and fixing real showstopper bugs that severely
affect the usability of these features ASAP.  For most people, while having a less
than ideal toolchain is annoying, having a moving target is completely useless.
Furthermore, if D didn't bother with new features and was just a slightly better
C++/Java, the switching costs wouldn't be justified.

Another thing to take into account is that mistakes in the spec (and to some
extent the reference implementation is a de facto spec) are a lot more permanent
than bad toolchain implementaitons.  Creating a real top-of-the-line toolchain is
something that can be done after the spec is finalized and the features
implemented without breaking anything.  This includes improving the linker, fixing
bugs that don't fundamentally affect the usability of language features, improving
performance, etc.  It is also something that can be (and is being) done by the
community, i.e. people other than Walter.
June 21, 2009
Re: The proper case for D.
Robert Fraser wrote:
> I'm considering doing so since Optlink won't work with the debug build 
> of one of my libraries (it's 22MB),

Is this reported in bugzilla?

> and it doesn't seem to discard any 
> unreferenced library symbols, so the release build of my code is ~9.5MB, 
> while it should be ~4.

Optlink does not discard unreference symbols, it just doesn't pull them 
in from the library. If it did always pull in everything from the 
library, then the minimum D executable size will be the size of Phobos.

Since that isn't happening, something else is happening with your code. 
I bet that those unreferenced symbols *are* being referenced. You can 
determine this by using the librarian to remove those 'unreferenced' 
symbols from Phobos, and then link, and see if there are any unresolved 
symbol error messages.
« First   ‹ Prev
1 2 3
Top | Discussion index | About this forum | D home