On Wed, 30 Jan 2013 17:19:22 +0100, you wrote:
Вы не хотите оформить это в виде содержательного полноценного предложения, и прислать это нам на report@ ? Для Ады 2012 понятно что поезд ушел, но для Ады 2020 почему бы и нет.
Вдосыл - собственно, и другие ваши мысли по поводу возможных направлений развития языка будут очень полезны. Ваше мнение, что язык часто
эволюционирует только за счет заплаток, разделяю не я один. Вообще я всегда читаю ваши сообщения с большим интересом, скажу даже больше что ваши сообщения представляют для меня самую большую привлекательность ada_ru. Но у них есть один крупнейший недостаток - они на русском :) Я был бы рад если бы они были дошли до других сотрудников AdaCore.
Спасибо на добром слове и согласии.
Прежде чем формулировать предложения по изменению языка, должно быть понимание того, чего мы собственно хотим достичь. Такое понимание было для Ады 83 и 95. Сформировано оно может быть только путем широкого обсуждения.
Сейчас этого понимания и близко нет. Более того, те языковые проблемы, которые вижу я, как программист, не считаются таковыми вообще. А это этап еще более ранний, чем целеполагание. Т.е. до предложений дистанция "огромного размера".
Проблемы (shortlist)
1. Инициализация и финализация. Для всех типов, для компонент-задач, для class-wide типов. Безопасная по наследованию = не может быть переписана, только расширена, безопасная для access-дискриминантов.
2. Множественное наследование вместо ублюдочных Ява-интерфейсов.
3. Классы всех типов.
4. Multiple dispatch, статически верифицируемый и сопутствующие вопросы с видимостью.
5. Делегация.
6. Контракты исключений.
7. Интеграция SPARK-а.
8. Наследование интерфейсов от конкретных типов.
9. Встроенные контейнерные типы определенные как интерфейсы. Например массив должен иметь интерфейс который можно реализовать используя любой тип.
10. Супертипы (для существующих типов, через 8)
Многие мелкие вопросы решаются через главные. Например, бардак со строчными типами и миллионом библиотечных пакетов ввода-вывода элементарно
разрешается через 3,8,9,(10).
А другие люди видят другие цели. Например, поддержка functional programming и т.п., - цели, которые я считаю злом. И пока не будет сформировано "общественное мнение" бесполезно даже думать о конкретике.
P.S. Если кто-то готов тиснуть куда-нибудь (куда?) статейку, я готов поучаствовать. Хотя боюсь, сегодня никто ничего длиннее ленты новостей и беллетристики не читает. Я, например.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
On 01/31/2013 02:03 PM, Dmitry A. Kazakov wrote:
Многие мелкие вопросы решаются через главные. Например, бардак со строчными типами и миллионом библиотечных пакетов ввода-вывода элементарно разрешается через 3,8,9,(10).
Насколько я помню и Ваша и моя точки зрения были посланы лесом с
обоснованием "нам есть чем заниматься и без этого".
Ситуация с развитием языка видится мне совершенно тупиковой, извините коллеги. :-(
Dmitry A. Kazakov wrote:
Прежде чем формулировать предложения по изменению языка, должно быть
понимание того, чего мы собственно хотим достичь. Такое понимание было для
Ады 83 и 95. Сформировано оно может быть только путем широкого обсуждения.
Согласен. Но не стоит ждать сколь-нибудь серьезного широкого обсуждения.
По двум причинам:
- практически всем - пофиг;
- нет (и не будет) эффективной организации, которая бы организовала и провела
бы это обсуждение, как оно было для Ады 83/95;
Сейчас этого понимания и близко нет. Более того, те языковые проблемы,
которые вижу я, как программист, не считаются таковыми вообще. А это этап
еще более ранний, чем целеполагание. Т.е. до предложений дистанция
"огромного размера".
Тоже согласен.
Проблемы (shortlist)
1. Инициализация и финализация. Для всех типов, для компонент-задач, для
class-wide типов. Безопасная по наследованию = не может быть переписана,
только расширена, безопасная для access-дискриминантов.
2. Множественное наследование вместо ублюдочных Ява-интерфейсов.
3. Классы всех типов.
4. Multiple dispatch, статически верифицируемый и сопутствующие вопросы с
видимостью.
5. Делегация.
6. Контракты исключений.
7. Интеграция SPARK-а.
8. Наследование интерфейсов от конкретных типов.
9. Встроенные контейнерные типы определенные как интерфейсы. Например
массив должен иметь интерфейс который можно реализовать используя любой
тип.
10. Супертипы (для существующих типов, через 8)
Вот тут - не согласен. Язык уже необозрим и непознаваем. Аду 83 я знал практически
наизусть, в 95-й легко ориентировался и сразу находил ответ практически на любой
вопрос. В 2005 начал конкретно плавать. Уверенно ориентироваться в 2012 и не пытаюсь,
заранее готов к тому, что многие вопросы копать придется долго и нудно. Если еще и
предлагаемое добавить... Караул! Моя колокольня - не столько программисткая (но и она
присутствует по полной программе), сколько точка зрения разработчика инструментов,
которые *обязаны* уметь обрабатывать *весь* язык.
Многие мелкие вопросы решаются через главные. Например, бардак со строчными
типами и миллионом библиотечных пакетов ввода-вывода элементарно
разрешается через 3,8,9,(10).
А вот тут мы подходим к реальной проблеме. Из соображений совместимости язык
вынужден не только сохранять решения, принятые в конце 70-х годов, но и основывать
на них новые решения. В результате часто получается, мягко говоря, фигня. Ярчайший
пример - кошмарная реализация принципов ООП на теговых типах - когда синтаксис и
семантика того, что в ООП называется классом, размазаны по коду.
Отсюда вопрос - насколько хорошо поддается созданный почти 50 лет назад язык
дальнейшей модернизации. Мой ответ более чем пессимистический. Уже столько костылей
наставлено вокруг базовых решений 83-й Ады, что куда ни глянь - картина Сальвадора Дали.
Теоретически, если делать по уму, стоит пересмотреть язык по полной программе, с
учетом осознанных на данный момент ошибок и осознанных на данный момент потребностей.
В частности, систему типов точно стоит пересмотреть (а не латать!), а это есть
фундамент вообще всего.
Практически такой возможности нет и не будет. Обратная совместимомть, недостаток
ресурсов, недооцененность в современном обществе труда программиста и прочих
computers scientists and software engineers.
Что делать в этой ситуации... Черт его знает! Я бы воздерживался от любых нововведений
до тех пор, пока не припрет конкретно с ножом к горлу. Поскольку уже перебор, а
все нововведения будут делаться с обеспечением обратной совместимости, и, значит,
обрастать костылями с рождения.
Проблемы (shortlist)
Я перенаправлю пока хотя бы этот список для нашего внутреннего "кружка по интересам". Только пара уточняющих вопросов предварительно -
2. Множественное наследование вместо ублюдочных Ява-интерфейсов.
В каком виде вы это рассматриваете?
6. Контракты исключений.
Не совсем понял что имеется здесь в виду.
8. Наследование интерфейсов от конкретных типов.
10. Супертипы (для существующих типов, через 8)
И вот это, не могли бы вы развить?
А другие люди видят другие цели.
Ну, это нормально :)
Например, поддержка functional programming
и т.п., - цели, которые я считаю злом. И пока не будет сформировано "общественное мнение" бесполезно даже думать о конкретике.
Ну значит давайте пытаться его формировать :) Немножко времени до Ады 2020 есть.
P.S. Если кто-то готов тиснуть куда-нибудь (куда?) статейку, я готов поучаствовать.
Куда - зависит от формата. Если вы готовы подробно и обстоятельно развить положения вашего списка - то можно идти хоть вплоть до доклада на Ada-Europe (и публикации в LNCS соответственно).
ВФ
А вот тут мы подходим к реальной проблеме. Из соображений совместимости язык вынужден не только сохранять решения, принятые в конце 70-х годов, но и основывать
на них новые решения. В результате часто получается, мягко говоря, фигня. Ярчайший
пример - кошмарная реализация принципов ООП на теговых типах - когда синтаксис и
семантика того, что в ООП называется классом, размазаны по коду.
Во-первых, реализация принципов ООП в Аде - как раз демонстрация того, что основывать новые решения на старых язык совершенно не обязан. Появилось новое понятие "tagged derivation", которое существенно отличается по семантике от "simple derivation". В том числе в направлении *ограничения* функциональности, типа невозможности объявления общего примитива для нескольких тэговых типов, невозможности отключения примитивов при наследовании и т.п.
Во-вторых - а что там собственно размазано и где? Областью определения тегового типа является область объявления, в котором он находится (как правило конечно спецификация пакета), плюс вполне очевидные правила "заморозки". Аналогом этого являются фигурные скобки вокруг объявления класса в С++. Совершенно не вижу у этих фигурных скобок никаких преимуществ кроме недостатков! Адовский подход мне кажется куда гибче и предпочтительнее, особенно с добавлением контроля перегрузки примитивов через overriding.
ВФ
2. Множественное наследование вместо ублюдочных Ява-интерфейсов.
Видел в С++ виртуальное и статическое наследование. Это же жуть!? Не ужели иметь это лучше, чем иметь интерфейсы?
--
Maxim Reznik
Видел в С++ виртуальное и статическое наследование. Это же жуть!? Не ужели иметь это лучше, чем иметь интерфейсы?
>
Лучше посмотрите не Эйфель.
Теоретически, если делать по уму, стоит пересмотреть язык по полной программе, с
учетом осознанных на данный момент ошибок и осознанных на данный момент потребностей.
В частности, систему типов точно стоит пересмотреть (а не латать!), а это есть
фундамент вообще всего.
>
Практически такой возможности нет и не будет. Обратная совместимомть, недостаток
ресурсов, недооцененность в современном обществе труда программиста и прочих
computers scientists and software engineers.
>
Эмм.. А почему собственно? Откуда такой вывод? Гугл создает свой язык (Go и Dart) и довольно успешно его продвигает, Мозилла создает свой язык (Rust), да даже Digital Mars свой язык делает (D), JetBrains создают свой Kotlin.
Все эти языки новые, пересмотренные и без легаси-мусора. У всех есть свои преимущества (например Rust много безопасней чем та же java например - там никогда не будет разименования нуль-указателя/ссылки).
У AdaCore (да и вообще Ада-сообщества) меньше ресурсов чем у Digital Mars и JetBrains?
31.01.2013 17:38, Sergey I. Rybin пишет:
А вот тут мы подходим к реальной проблеме. Из соображений совместимости язык
вынужден не только сохранять решения, принятые в конце 70-х годов, но и основывать
на них новые решения. В результате часто получается, мягко говоря, фигня. Ярчайший
пример - кошмарная реализация принципов ООП на теговых типах - когда синтаксис и
семантика того, что в ООП называется классом, размазаны по коду.
Отсюда вопрос - насколько хорошо поддается созданный почти 50 лет назад язык
дальнейшей модернизации. Мой ответ более чем пессимистический. Уже столько костылей
наставлено вокруг базовых решений 83-й Ады, что куда ни глянь - картина Сальвадора Дали.
GNAT уже сейчас умеет одним компилятором один юнит обрабатывать как Ada 2005, другой как Ada 2012, третий как Ada 95, хотя в стандарте про такое взаимодействие не сказано.
Было бы неплохо, если бы аналогично GNAT научился смежному с Адой языку, а потом для этого языка другие, не связанные с Адой компиляторы бы появились.
Turbo Pascal - C
Delphi - Objective C
Ada - C++
??? - D
-- If you want to get to the top, you have to start at the bottom
Ну, сейчас мне представляется кроме D еще интересным Rust и Go как минимум.
2013/1/31 Иван Левашев <[email protected]>
31.01.2013 18:59, Maxim Reznik пишет:
2. Множественное наследование вместо ублюдочных Ява-интерфейсов.
Видел в С++ виртуальное и статическое наследование. Это же жуть!? Не
ужели иметь это лучше, чем иметь интерфейсы?
Множественное наследование в C++ — не образец. Есть CLOS. Есть SOM.
-- If you want to get to the top, you have to start at the bottom
On Thu, 31 Jan 2013 11:56:47 +0100, you wrote:
2. Множественное наследование вместо ублюдочных Ява-интерфейсов.
В каком виде вы это рассматриваете?
Наследование операций и представления, с (важно!) разрешением конфликтов программистом.
Методы подлежат обсуждению.
Важно, что модель добавления должна быть поддержана. Например, дважды наследуя из элемента связного списка, я хочу получить элемент двух списков, а не одного.
6. Контракты исключений.
Не совсем понял что имеется здесь в виду.
Консервативная проверка того, что возбуждает операция. Включая
Storage_Error и Program_Error.
8. Наследование интерфейсов от конкретных типов.
10. Супертипы (для существующих типов, через 8)
И вот это, не могли бы вы развить?
Наследование интерфейса это только операции но не компоненты (если они не операции getter/setter). Типичный случай - access T наследующий все операции T - прозрачный указатель, ссылка:
type Reference is new T'Interface with private;
private
type Reference is access T and T'Interface;
... -- реализация операций Т через делегацию
Супертип - экспорт операций. В контексте, где он видим его операции принимают аргументы подтипа. Требуется для создания общего предка для уже существующих типов.
(Само собой разумеется, что оба механизма работают через преобразование типа, т.е. by-value)
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
On Thu, 31 Jan 2013 14:38:22 +0400, you wrote:
Dmitry A. Kazakov wrote:
Прежде чем формулировать предложения по изменению языка, должно быть понимание того, чего мы собственно хотим достичь. Такое понимание было для Ады 83 и 95. Сформировано оно может быть только путем широкого обсуждения.
Согласен. Но не стоит ждать сколь-нибудь серьезного широкого обсуждения. По двум причинам:
- практически всем - пофиг;
- нет (и не будет) эффективной организации, которая бы организовала и провела бы это обсуждение, как оно было для Ады 83/95;
Я и не жду.
Вот тут - не согласен. Язык уже необозрим и непознаваем. Аду 83 я знал практически
наизусть, в 95-й легко ориентировался и сразу находил ответ практически на любой
вопрос. В 2005 начал конкретно плавать. Уверенно ориентироваться в 2012 и не пытаюсь,
заранее готов к тому, что многие вопросы копать придется долго и нудно. Если еще и
предлагаемое добавить... Караул! Моя колокольня - не столько программисткая (но и она
присутствует по полной программе), сколько точка зрения разработчика инструментов,
которые *обязаны* уметь обрабатывать *весь* язык.
А вот это и есть одна из главных задач всей программы - радикальное упрощение языка за счет выделения более фундаментальных механизмов системы типов, и выражения существующего бардака в новых терминах. Как теория великого объединения в физике.
Я в это верю.
Многие мелкие вопросы решаются через главные. Например, бардак со строчными типами и миллионом библиотечных пакетов ввода-вывода элементарно разрешается через 3,8,9,(10).
А вот тут мы подходим к реальной проблеме. Из соображений совместимости язык вынужден не только сохранять решения, принятые в конце 70-х годов, но и основывать
на них новые решения.
Потому - см. выше.
В результате часто получается, мягко говоря, фигня. Ярчайший
пример - кошмарная реализация принципов ООП на теговых типах - когда синтаксис и
семантика того, что в ООП называется классом, размазаны по коду.
Это спорный вопрос. В частности "размазывание" принципиально необходимо для операций примитивных для нескольких типов сразу. Я это хочу, и даже очень.
Теоретически, если делать по уму, стоит пересмотреть язык по полной программе, с
учетом осознанных на данный момент ошибок и осознанных на данный момент потребностей.
В частности, систему типов точно стоит пересмотреть (а не латать!), а это есть фундамент вообще всего.
Безусловно.
Практически такой возможности нет и не будет. Обратная совместимомть, недостаток
ресурсов, недооцененность в современном обществе труда программиста и прочих computers scientists and software engineers.
См. выше. Я считаю, что решения Ады 83 и 95 были принципиально верны и могут быть выражены в новых терминах. Что должно обеспечить полную совместимость.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
On 01/31/2013 05:06 PM, Иван Левашев wrote:
Есть SOM.
Это вполне обычное наследование через интерфейсы а-ля Java. Насколько я понял имелось в виду множественное наследование классов. По моему мнению вот тут сейчас как раз хорошо всё сделано. Множественное - интерфейсам, простое - классам. Хочешь и сесть и съесть - комбинируй эти два вида.
Чтобы оставить новое сообщение необходимо Зарегистрироваться и Войти