Why the @ in @safe? & UDAs

Rob T alanb at ucora.com
Tue Nov 12 10:19:20 PST 2013


I don't disagree with what you are saying, however I think it is 
healthy to always question the status quo and continue to try and 
find innovative ways to destroy established thinking that 
otherwise limits what can and cannot be done.

Currently, the most acceptable methods discussed in here of 
moving forward and getting rid of old inadequate concepts, seems 
to be through very carefully considered deprecation and the 
implementing of automated methods for updating old code to 
conform to newer and better standards.

We do have deprecation, but so far I have not seen methods of 
automated updates so maybe that's something worth considering 
down the road.

I do have some experience with automating updates of old code. 
Certain databases I've worked on required updates, and the only 
foolproof method of doing it was to automate the process as much 
as possible, and I've had very good success doing it that way. 
Manually updating code is very stressful and error prone, no one 
wants to do it, but if you can click on a button and have the 
code updated for you without concern that it will fail miserably 
or cause weird side effects, upgrades become a good thing instead 
of a bad thing.

--rt

On Monday, 11 November 2013 at 00:13:34 UTC, Jonathan M Davis 
wrote:
> On Monday, November 11, 2013 00:39:04 Rob T wrote:
>> On Sunday, 10 November 2013 at 23:08:11 UTC, Nick wrote:
>> > The alternative is to slowly build up a menagerie of quirks
>> > that put us on the same path as C++.
>> 
>> It seems that a buildup of quirks is underway as is evidenced 
>> by
>> this discussion. The other solution is to at some point place a
>> freeze on D2 with bug support only and move on to D3 with at
>> least the worse of the known baggage removed. There are of 
>> course
>> disadvantages and dangers with doing that, but it is an option.
>> 
>> Ultimately if we try and keep everyone happy, at some point no
>> one will be happy, so I think it's worth trying to find good
>> solutions to enable the language to evolve in ways that can 
>> leave
>> baggage from the past behind.
>
> I think that it's naive to think that any serious language will 
> avoid building
> up quirks and rough corners over time. You never get a language 
> completely
> right (assuming that's even possible), and you only have so 
> long after you
> create it to tweak stuff before it has to be more or less set 
> in stone for it
> to be useable in the real world. Some stuff can be tweaked over 
> time even after
> you're "stable," but you have to be very careful about it in 
> order to minimize
> if not outright eliminate breakage. And the longer that a 
> language is around,
> the more unwieldy it's going to get. Either it doesn't innovate 
> at all and
> avoids building up more quirks, or it innovates and ends up 
> with quirks as it
> adds and adjusts stuff after the fact.
>
> Eventually, the baggage from those quirks will be big enough 
> that if you want
> to get rid of them, you'll be forced to either create a new 
> language or to
> create a new version of the language which breaks backwards 
> compatiibiity,
> which tends to be little different from just creating a new 
> language. I really
> don't think that there's any way around that. D doesn't have 
> all of the
> baggage of C and C++, because it's a new language which breaks 
> compatibility
> with them, but it's building up its own quirks and mistakes and 
> will continue
> to do so. We should do our best to minimize that, but I really 
> don't think
> that there's any way avoid it completely.
>
> Languages _need_ to be more or less set in stone in order to be 
> useable in the
> real world, and if you set them in stone, then you're going to 
> end up with
> quirks and baggage when you add onto them later. That's just 
> the way it is,
> and I think that anyone who thinks that D can avoid the same 
> fate as C++ in
> that regard is being naive. Some day, there will be a D++, or a 
> D3, or an E,
> or whatever for the same reason that we created D instead of 
> continuing to use
> C++ and for the same reason that the python developers created 
> python 3. But
> that's a _long_ way off. First, we have to make D2 work, and 
> part of that means
> living with at least some of the mistakes that we've made and 
> quirks that the
> language has acquired. And honestly, many of those are 
> tradeoffs that I don't
> think that anyone has a good solution for at this point anyway. 
> So, even if
> someone went and created D3 right now, I don't think that it 
> would be
> appreciably better than D2 (in some regards maybe, but not 
> enough to be worth
> the split that that would cause to the code and to the 
> community).
>
> - Jonathan M Davis



More information about the Digitalmars-d mailing list