View mode: basic / threaded / horizontal-split · Log in · Help
November 27, 2012
Re: Help!
On Monday, 26 November 2012 at 19:59:42 UTC, Walter Bright wrote:
> On 11/27/2012 5:52 AM, David Nadlinger wrote:
>> I agree, and if I remember previous discussions on the subject
>> correctly, it seems like only Walter is in favor of upholding 
>> the
>> current restrictions of "alias" parameters to symbols. I 
>> simply do not
>> see a point in pushing compiler implementation details on the 
>> user like
>> that – for the programmer, a type is a type is a type…
>>
>> Walter, do you have an example of a situation where the alias 
>> parameter
>> restriction would be beneficial?  (for the D code involved, I 
>> don't mean
>> the few lines of code avoided in the compiler)
>
> In any case, it will break a great deal of existing code to 
> change  that behavior.

Please stop repeating that "will break lots of code" mantra. D 
user base is very small and it doesn't grow *because* issues like 
the one discussed do not get fixed. When they are fixed people 
may start using the language. And *then* you would have to worry 
about backward compatibility. Look at the recent Manu's 
complaints and see what people who would really use the language 
have wanted from it for years.
November 27, 2012
Re: Help!
On Tuesday, 27 November 2012 at 18:10:51 UTC, Manu wrote:
> I feel this sentiment every day.
> I'm more than happy to receive breaking changes that make the 
> language
> tidier and more consistent. I'll happily take the time to keep 
> our codebase
> up to date.

I agree more than 100%. I've been struggling with inconsistency 
issues right from the get go, and it's very frustrating, esp when 
you see the brilliant potential that should be there but just 
quite isn't.

A suggested improvement written up here, solves at least some of 
it
http://forum.dlang.org/thread/xxenmxyshhscjhqjibkr@forum.dlang.org

--rt
November 27, 2012
Re: Help!
On 11/28/2012 5:25 AM, Max Samukha wrote:
> Please stop repeating that "will break lots of code" mantra. D user base
> is very small and it doesn't grow *because* issues like the one
> discussed do not get fixed. When they are fixed people may start using
> the language. And *then* you would have to worry about backward
> compatibility. Look at the recent Manu's complaints and see what people
> who would really use the language have wanted from it for years.

I understand what you're saying, but the counterpoint is we lost half 
the D community when D2 broke D1 code. We still have at least one major 
D1 user that still finds it impractical to upgrade to D2.

It is unbelievably frustrating for people to have their code break with 
each new release, have older projects all invalidated, with few willing 
to do the maintenance work to bring them back on line.
November 27, 2012
Re: Help!
On 11/28/2012 8:23 AM, Walter Bright wrote:
> It is unbelievably frustrating for people to have their code break with
> each new release, have older projects all invalidated, with few willing
> to do the maintenance work to bring them back on line.


Note the thread next to this one: "Errors compiling DSSS", and the 
advice to abandon it.
November 27, 2012
Re: Help!
On Tuesday, 27 November 2012 at 21:23:12 UTC, Walter Bright wrote:
>
> I understand what you're saying, but the counterpoint is we 
> lost half the D community when D2 broke D1 code. We still have 
> at least one major D1 user that still finds it impractical to 
> upgrade to D2.
>
> It is unbelievably frustrating for people to have their code 
> break with each new release, have older projects all 
> invalidated, with few willing to do the maintenance work to 
> bring them back on line.

It may not be my place to say, but the unwillingness to maintain 
the D1 code seems to go well past just breakage issues.

Anyway, I figure D at this time is attracting mostly "early 
adopters" who don't always mind the odd breakage here and there 
so long as it's for the greater good. Once the D base expands 
beyond the early adopter phase, change will become much more 
difficult than it is right now, so whatever is being done today 
better be done well before it's too late.

My only suggestion is to re-think how a programming language can 
remain reasonably stable, yet at the same time evolve forward in 
significant ways over the long term. There must be plenty of 
real-world examples of this being done successfully that can be 
emulated with D.

If D is not allowed to change in significant ways, then it will 
slowly but surely become another C/C++, with "significant" 
updates once every 10 years or so which are mediocre and leave 
the root design defects in place.

--rt
November 28, 2012
Re: Help!
Walter Bright:

> It is unbelievably frustrating for people to have their code 
> break with each new release, have older projects all 
> invalidated, with few willing to do the maintenance work to 
> bring them back on line.

I am still converting some of my D1 code to D2, plus I have lot 
of D2 code. Since many months I have stopped downloading official 
dmd releases because the amount of breakages in my D2 code 
between a version and the successive one was too much large. DMD 
2.061 has so many changes and improvements that it will require 
several changes in everyone D2 code.

To avoid performing such large amount of changes I now compile 
dmd every two or three days, and I have scripts that compile all 
my D2 programs and report the breakages. This way I fix a small 
amount of breakages at a time in my D2 code, this is simpler.

Most of those breakages are caused by bug fixings that reveal 
bugs in my D2 code (example: since recently throwing constructors 
accepted a nothrow tag, and I have many more examples). But I am 
willing to perform this maintenance work because they improve my 
future D2 programming and code.

If we add to those bug-fixing-changes some breakage caused by 
design changes, this is not going to make my live significantly 
worse, it's just one more breakage among several others.

Bye,
bearophile
November 28, 2012
Re: Help!
On Tuesday, 27 November 2012 at 21:23:12 UTC, Walter Bright wrote:
> On 11/28/2012 5:25 AM, Max Samukha wrote:
>> Please stop repeating that "will break lots of code" mantra. D 
>> user base
>> is very small and it doesn't grow *because* issues like the one
>> discussed do not get fixed. When they are fixed people may 
>> start using
>> the language. And *then* you would have to worry about backward
>> compatibility. Look at the recent Manu's complaints and see 
>> what people
>> who would really use the language have wanted from it for 
>> years.
>
> I understand what you're saying, but the counterpoint is we 
> lost half the D community when D2 broke D1 code. We still have 
> at least one major D1 user that still finds it impractical to 
> upgrade to D2.
>

Should we talk about phobos and tango here ? I'm pretty sure you 
can attribute most of that departure from that event.

> It is unbelievably frustrating for people to have their code 
> break with each new release, have older projects all 
> invalidated, with few willing to do the maintenance work to 
> bring them back on line.

I have also bunch of code broken in the current release and find 
myself writing workaround for quirk in the language even for 
simple monomodule programs.

We have a project management issue here in the first place.
November 28, 2012
Re: Help!
On Tuesday, 27 November 2012 at 21:23:12 UTC, Walter Bright wrote:
> On 11/28/2012 5:25 AM, Max Samukha wrote:
>> Please stop repeating that "will break lots of code" mantra. D 
>> user base
>> is very small and it doesn't grow *because* issues like the one
>> discussed do not get fixed. When they are fixed people may 
>> start using
>> the language. And *then* you would have to worry about backward
>> compatibility. Look at the recent Manu's complaints and see 
>> what people
>> who would really use the language have wanted from it for 
>> years.
>
> I understand what you're saying, but the counterpoint is we 
> lost half the D community when D2 broke D1 code. We still have 
> at least one major D1 user that still finds it impractical to 
> upgrade to D2.

That was more than a breaking change. That was a massive paradigm 
shift. All the drama going on back then was rooted more in 
philosophical differences and the Phobos/Tango divide, than 
changes to the language. What's being discussed here is breakage 
on a much smaller scale.

I've always said that it's the little things in aggregate that 
make D such a wonderful language to work with. But the flipside 
of that is the little annoyances in aggregate can make it 
frustrating to work with. New users coming to a language often 
have little patience. IMO, their encountering these little 
annoyances before the good stuff takes hold is a far more 
pressing issue than a few minor breaking changes.

I've no idea what sort of commercial interests are using D in 
production, but I'd still confidently make the bet that a few 
breaking changes now (for issues that people find frustrating) 
would do more good than harm in the long run. Especially if they 
are introduced gradually and with time to understand their 
ramifications.
November 28, 2012
Re: Help!
On Wednesday, 28 November 2012 at 00:07:42 UTC, bearophile wrote:
> Walter Bright:
>
>> It is unbelievably frustrating for people to have their code 
>> break with each new release, have older projects all 
>> invalidated, with few willing to do the maintenance work to 
>> bring them back on line.
>
> I am still converting some of my D1 code to D2, plus I have lot 
> of D2 code. Since many months I have stopped downloading 
> official dmd releases because the amount of breakages in my D2 
> code between a version and the successive one was too much 
> large. DMD 2.061 has so many changes and improvements that it 
> will require several changes in everyone D2 code.
>
> To avoid performing such large amount of changes I now compile 
> dmd every two or three days, and I have scripts that compile 
> all my D2 programs and report the breakages. This way I fix a 
> small amount of breakages at a time in my D2 code, this is 
> simpler.
>
> Most of those breakages are caused by bug fixings that reveal 
> bugs in my D2 code (example: since recently throwing 
> constructors accepted a nothrow tag, and I have many more 
> examples). But I am willing to perform this maintenance work 
> because they improve my future D2 programming and code.
>
> If we add to those bug-fixing-changes some breakage caused by 
> design changes, this is not going to make my live significantly 
> worse, it's just one more breakage among several others.
>

Don't you think that this whole situation is due to adding 
feature after feature in an unstabilized mess ?

I mean, how the fact that a nothrow constructor can throw can be 
explained in another way (to use your example) ? A feature in 
that state should have reached any release, ever !
November 28, 2012
Re: Help!
Am 27.11.2012 18:47, schrieb Eldar Insafutdinov:
> On Monday, 26 November 2012 at 19:59:42 UTC, Walter Bright wrote:
>> On 11/27/2012 5:52 AM, David Nadlinger wrote:
>>> I agree, and if I remember previous discussions on the subject
>>> correctly, it seems like only Walter is in favor of upholding the
>>> current restrictions of "alias" parameters to symbols. I simply do not
>>> see a point in pushing compiler implementation details on the user like
>>> that – for the programmer, a type is a type is a type…
>>>
>>> Walter, do you have an example of a situation where the alias parameter
>>> restriction would be beneficial?  (for the D code involved, I don't mean
>>> the few lines of code avoided in the compiler)
>>
>> In any case, it will break a great deal of existing code to change  that behavior.
> 
> The discussed issue is one of those inconsistencies that make people struggle when using D. D's main
> selling point is rich meta programming. Others are rapidly catching up in the field of expressive
> native languages. If we set these early design decisions in stone, it means we will not be able to
> compete with them. And besides, are there many big proprietary D2 codebases that you afraid? I doubt
> there are. And Manu actually represents people who are willing to work on one, but are held off by
> these issues. Open source projects however will be easily fixable, and people using D will actually
> welcome these positive changes.

We do have a largish code base that is also gradually used commercially (200k+ lines of library
code, when including vibe.d plus any applications that are built on top of it). My former employee
now has a smaller code base along the lines of 80k+ LOC). So I guess such code bases are in fact a
reality.

... and still I very much prefer to have "good" breakage that cleans up the language. It's just
things that break code for nothing (most of the time bugs) that are really annoying.

And I fully agree, we should better collect warts of the language and fix them as early as possible.
This may set up a few people now, but will make all the future users of the language + a lot of the
current users much more happy.

Realistically, the current approach with one branch that is not supposed to get breaking changes,
but gets them anyway as soon as it _has to_, just extends the period of time in which things get
broken and also in which the language still has those issues.
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home