Re[17]: [PDC, Don Syme] Type providers
От: hi_octane Беларусь  
Дата: 01.11.10 20:06
Оценка: 186 (4) +1
T>Если библиотека стандартизована, то её тоже придется поддерживать всегда, ибо без неё не будут компилироваться программы. В чем разница?
T>Что тебе дает факт "неподключения" библиотеки? В чем profit?

Профит в том что кому-то нужны одни фичи, кому-то другие, а в язык идёт то что по оценке фокус-группы будет полезно 80% широких народных масс. А 20% тех умников чьи потребности выше понимания фокус-группы или обходятся МС слишком дорого — в пролёте из года в год. Вот живой пример: у нас потоки поднимаются и мрут тоннами, часто нужен ReaderWriterLock, на C# — это блоки try/finally и куча хрени на каждый чих:
try
{
   _lock.AcquireReaderLock(Timeout.Infinite);
   ...
}
finally
{
   _lock.ReleaseReaderLock();
}


А на Nemerle я тупо скопипастил из сорцов компилятора макрос lock, чуть поправил и включил его в _свой_ солюшн. Получилась красивая и удобная штука:
readlock(this)
{
...
}

writelock(this)
{
...
}


Объяснять что это ключевое слово делает под капотом — даже не понадобилось, просто показал людям что такое появилось и все стали пользовать. Удобно — однозначно лучше чем каждый раз огораживать try/finally. Но нужна ли всем и каждому в языке такая конструкция — вряд-ли. Станут в MC её вводить в язык если даже на connect мы всей конторой зафлэшмобим? Тоже вряд-ли. Тем более что с выходом фреймворка 3.5 мы например решили обновить макру на ReaderWriterLockSlim, а кто-то другой может не дожидаясь на interlocked замутит что-то своё, а кто-то третий захочет ещё таймаут задавать.

Более того, даже в нашем проекте эта фича нужна далеко не каждому. Кому нужна тот делает using нужного неймспейса, и пользует. И таких фич которые упрощают работу в каждом проекте может найтись тонна, но если каждый чих каждого индуса на планете делать частью языка, причём доступной всем, всегда и везде, то тупо ключевых слов на всех не хватит .

Вот поэтому у МС руки так связаны — им каждое ключевое слово, каждая фича облегчающая жизнь людям — ноша на всю карму. Даже замена ReaderWriterLock на ReaderWriterLockSlim — это уже проблема — характеристики то у них разные, правила реентерабильности, и т.п. и кому-то может эта замена всё испортит. А в расширяемом языке — добавляются библиотеки, старые библиотеки заменяются на новые. Кто-то использует старый lock через using Std.Concurrency, кто-то делает using StdNew.Concurrency и использует с тем же синтаксисом уже новый, а кто-то вытаскивает себе что-то супер-новое из модного блога, и забивает на все Std.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.