Ada_Ru форум

Обсуждение языка Ада

Рекламная статья об Аде

Оставить новое сообщение

Сообщения

Sergey I. Rybin
Рекламная статья об Аде
2003-04-18 16:17:29

Разговоры о рекламной статье про Аду ходят давно. Я даже спрашивал в журнале "Открытые системы", интересно ли им. Сказали: "Давай, пиши!"

И вот пару недель назад меня прорвало. Статья написалась как "побочный эффект" подготовки лекций Адского спецкурса. Мне осталось дать ей пару дней отлежаться, чтобы вычистить мелочи, которые сразу по написании не заметны.

 

Одна беда - я выскочил за рамки, налагаемые "Открытыми системами". У них максимум - 34 килобайта в формате ASCII, у меня зашкалило за 45.

 

Итак, вопросы к почтеннейшей публике:

 

1. Я хотел бы, чтобы вы на это посмотрели, поругали, поправили.

Принимаются любые конструктивные идеи. Вплоть до соавторства, если написанное нуждается в хирургическом вмешательстве.

В каком виде лучше посылать (оно набрано в MS Word). В RTF?

 

2. Куда с подобной (рекламной по сути) статьей стоит сунуться -

уламывать "Открытые системы" пропустить большой текст? Заняться сокращением под их требования? Сунуться куда еще?

 

Надеюсь, что наведение глянца будет завершено за выходные.

И вот пару недель назад меня прорвало.

 

А почему Вас прорвало, а Вы мне об этом ничего не сказали? Мы ведь вроде собирались писать ее вместе?

 

Вася.

 

 

Vasiliy Fofanov wrote:

 

И вот пару недель назад меня прорвало.

 

А почему Вас прорвало, а Вы мне об этом ничего не сказали? Мы ведь вроде собирались писать ее вместе?

 

Процесс был неконтролируемым. Текст написался сам, абсолютно для меня неожиданно, практически без остановок и за один подход. Потом только мелочи выправлял и с Word-ом бодался. Если б не записал сразу, оно б просто пропало.

 

А тут - в полночь приступил, в полтретьего ночи по существу закончил.

Но, согласен, получилось нарушение давней договоренности :(

hi,

Vasiliy Fofanov wrote:

И вот пару недель назад меня прорвало.

>

А почему Вас прорвало, а Вы мне об этом ничего не сказали? Мы ведь вроде собирались писать ее вместе?

>

Вася.

дык теперь _две_ статьи будет :-)

Alex

hi,

"Sergey I. Rybin" wrote:

>

Итак, вопросы к почтеннейшей публике:

>

1. Я хотел бы, чтобы вы на это посмотрели, поругали, поправили. Принимаются любые конструктивные идеи. Вплоть до соавторства,

если написанное нуждается в хирургическом вмешательстве.

В каком виде лучше посылать (оно набрано в MS Word). В RTF?

жуть его знает,

мне под гиг DOC-ов M$_Word-овских конвертить

приходилось (правда аглицких)...

...а вообче, лучше в html

у меня это теперь любимый формат - читается где-угодно :)

Sergey I. Rybin wrote:

 

1. Я хотел бы, чтобы вы на это посмотрели, поругали, поправили.

Это мы запросто. Ломать - не строить.

 

Принимаются любые конструктивные идеи. Вплоть до соавторства, Тут у нас хуже (см. пункт первый)

 

если написанное нуждается в хирургическом вмешательстве.

В каком виде лучше посылать (оно набрано в MS Word). В RTF?

 

Наверное лучше в RTF. Так и безопаснее и переносимее.

 

2. Куда с подобной (рекламной по сути) статьей стоит сунуться -

уламывать "Открытые системы" пропустить большой текст? Заняться

сокращением под их требования? Сунуться куда еще?

 

Для начала неплохо просто поглядеть, а то может и бензопила пригодится :)

 

Кстати о бензопиле: а вариант серии из N статей в X*N последовательных изданиях журнала не обсуждался?

 

 

 

-- Vadim Godunko

Vasiliy Fofanov wrote:

 

И вот пару недель назад меня прорвало.

 

А почему Вас прорвало, а Вы мне об этом ничего не сказали? Мы ведь вроде собирались писать ее вместе?

 

Вася.

 

дык теперь _две_ статьи будет :-)

 

И ето правельно, нужно много хороших рекламных статей !

Hello!

 

On Fri, 18 Apr 2003, Oleksandr Havva wrote:

 

Итак, вопросы к почтеннейшей публике:

 

1. Я хотел бы, чтобы вы на это посмотрели, поругали, поправили.

Принимаются любые конструктивные идеи. Вплоть до соавторства,

если написанное нуждается в хирургическом вмешательстве.

В каком виде лучше посылать (оно набрано в MS Word). В RTF?

 

жуть его знает,

мне под гиг DOC-ов M$_Word-овских конвертить

приходилось (правда аглицких)...

 

...а вообче, лучше в html

у меня это теперь любимый формат - читается где-угодно :)

 

Я, лично, вообще дома на машине ничего оффисного не держу, поэтому для меня недоступны ни Ms Word, ни RTF, хотя я же и писал о необходимости конвертнуть из Word'а в RTF. Word'вским же форматом не стоит пользоваться, поскольку он меняется от версии к версии, а RTF всё же стандартизован, стабилен и многоплатформен.

 

Sincerely yours Cyril Sazonov

Вот что получилось. Похоже, насчет рекламной статьи я погорячился. 16 страниц текста - это перебор в квадрате.

 

По сути, получилась ну очень развернутая аннотация (или ну

очень краткий конспект) того Адского спецкурса, что я читаю

на ВМиК МГУ.

Sergey I. Rybin wrote:

Вот что получилось. Похоже, насчет рекламной статьи я погорячился.

16 страниц текста - это перебор в квадрате.

 

По сути, получилась ну очень развернутая аннотация (или ну очень краткий конспект) того Адского спецкурса, что я читаю

на ВМиК МГУ.

 

Мдя... Рекламная статья явно не получилась. Но как небольшой экскурс - просто великолепно!

 

Единственное замечание касается "В начале 90-х годов, снова по инициативе и на средства МО США...". Если-бы в 1992 году стандарт не был пересмотрен, то просто перестал-бы существовать (таково правило для стандартов ISO/IEC - они имеют ограничение срока действия - пять лет). И если-бы не МО США, не исключено, что те же Boeing или Lockhead Martin (тогда может ещё IBM Federal Systems Department?) профинансировали эту процедуру.

 

 

-- Vadim Godunko

Мдя... Рекламная статья явно не получилась.

 

Увы! :(

 

Но как небольшой экскурс - просто великолепно!

 

И что с ним делать? И куда его приткнуть (да чтобы

прочитали!)

 

Единственное замечание касается "В начале 90-х годов, снова по

инициативе и на средства МО США...". Если-бы в 1992 году стандарт не был пересмотрен, то просто перестал-бы существовать (таково правило для стандартов ISO/IEC - они имеют ограничение срока действия - пять лет). И

 

А вот тут хотелось бы уточнить и разобраться. Я про _жесткое_ _формальное_ правило пересматривать стандарты на языки программирования раз в 5 лет просто не знал. В RM95 тоже вроде как нет ограничений на срок действия.

Где оно сказано, если сказано? Хотя в целом засечание правильное, и этот абзац надо переделать именно в таком духе. Особенно с учетом

вот этого:

 

В самом начале мелким тектом.

-----------------------

<<Если спросить российского специалиста по информационным технологиям: "Что такое Ада?", большинство лишь удивленно пожмет плечами, а кто-то, быть может, даже скажет, что Ада - это мертвый язык, когда-то придуманный Пентагоном для программирования систем вооружений, а ныне практически не используемый. На самом же деле Ада является вполне благополучным и активно применяемым в различных областях языком программирования, единственный недостаток которого в том, что российские программисты о нем практически ничего не знают.>>>

 

я бы сказал помягче, "мало что занают" или "немногие российские программисы хоть что-то про него знают", вон нас сколько

----------------

 

<< 3.5. Исключительные ситуации

 

Исключительная ситуация (исключение) - это такое событие, которое делает невозможным дальнейшее нормальное выполнение программы. При возникновении такой ситуации нормальное выполнение того процесса, в котором она возникла, и исключение распространяется вверх по динамической цепочке вложенных процессов>>

 

я бы сказал сразу, "вверх по цепочке вложенных вызовов программных модулей и операторов блока", процесс у большинства программистов

ассоциируется с выполняемой программой в целом

----------------------------

 

<<3.7. Настраиваемые модули

Настраиваемый модуль - это параметризированный шаблон процедуры, функции или пакета. В качестве параметров настраиваемого модуля могут выступать объекты и типы данных, подпрограммы и другие шаблоны.>>

 

А как это "другие шаблоны ?, или я не знаю, или ты ошибаешься.

 

<< Наличие среди формальных параметров

настройки производных типов позволяет в программах, написанных с

использованием объектно-ориентированного подхода, создавать шаблоны иерархий типов и моделировать множественное наследование.

Настраиваемая процедура не может быть вызвана, равно как и нельзя пользоваться типами, переменными и другими ресурсами, объявленными в настраиваемом пакете. Для этого шаблон необходимо сначала настроить (или конкретизировать), подставив вместо формальных объектов данных, типов и подпрограмм - фактические, а вместо формальных шаблонов - результаты их настройки>>

 

вообще то я ето представлял не как формальные шаблоны, а

нормальные объекты полученные путем настройки формальных шаблонов. Сами же шаблоны не могут быть параметрами шаблонов.

---------------------------

 

До конца еще не дочитал, надо бежать.

Sergey I. Rybin wrote:

 

Единственное замечание касается "В начале 90-х годов, снова по

инициативе и на средства МО США...". Если-бы в 1992 году стандарт не был

пересмотрен, то просто перестал-бы существовать (таково правило для

стандартов ISO/IEC - они имеют ограничение срока действия - пять лет). И

 

 

А вот тут хотелось бы уточнить и разобраться. Я про _жесткое_ _формальное_

правило пересматривать стандарты на языки программирования раз в 5 лет

просто не знал. В RM95 тоже вроде как нет ограничений на срок действия.

 

Где оно сказано, если сказано?

 

В этом отличие стандартов эксСССР и ISO. У нас стандарт действует пожизненно, пока не выйдет другой, его заменяющий. У ISO правило другое: стандарт действителен 5 лет со дня публикации. Если через 5 лет никто не затребовал его пересмотра, стандарт теряет силу. Это относится не только к языкам программирования, но к абсолютно всем стандартам этой организации.

 

В RM95 это писать никто и не думал. Правило, понятное дело, распространяется и на него.

 

А искать это стоит в описании стандартной процедуры принятия/действия/пересмотра стандартов где-то в районе:

 

http://www.iso.ch

 

Точнее, к сожалению, не помню :(

 

-- Vadim Godunko

Похоже я нашёл самый страшный недостаток. :)

 

А подписываться не учили? Или статья анонимная? :)

 

-- Vadim Godunko

В этом отличие стандартов эксСССР и ISO. У нас стандарт действует пожизненно, пока не выйдет другой, его заменяющий. У ISO правило другое: стандарт действителен 5 лет со дня публикации. Если через 5 лет никто не затребовал его пересмотра, стандарт теряет силу.

 

В принципе так, но срок по-моему гораздо больший. В противном случае это означает что с 1992 по 1995 год стандарта Ады не существовало. Аналогично, вот уж 3-ий год как мы опять существуем без стандарта, и если я что-то понимаю в вопросе, будем без него существовать еще года 3 минимум (принятия нового стандарта Ады раньше 2006 года я не ожидаю). Я думаю, что минимум лет 10 срок жизни стандарта, если не все 15.

 

С уважением,

Василий.

 

 

Vasiliy Fofanov wrote:

 

В этом отличие стандартов эксСССР и ISO. У нас стандарт действует пожизненно, пока не выйдет другой, его заменяющий. У ISO правило другое: стандарт действителен 5 лет со дня публикации. Если через 5 лет никто не затребовал его пересмотра, стандарт теряет силу.

 

В принципе так, но срок по-моему гораздо больший. В противном случае это означает что с 1992 по 1995 год стандарта Ады не существовало. Аналогично, вот уж 3-ий год как мы опять существуем без стандарта, и если я что-то понимаю в вопросе, будем без него существовать еще года 3 минимум (принятия нового стандарта Ады раньше 2006 года я не ожидаю). Я думаю, что минимум лет 10 срок жизни стандарта, если не все 15.

 

Вот и мне так казалось. Несколько лет назад (на SIGAda 2000, по-моему) был доклад о проекте пересмотра Адского стандарта. Основная идея докладчика была примерно такая: вообще-то положено, учитывая 10-летний цикл пересмотра информационных стандартов, но нужды особой нет, совершенно не к спеху, да и менять нечего, разве что прагмы добавить да библиотеки расширить.

Vasiliy Fofanov wrote:

В этом отличие стандартов эксСССР и ISO. У нас стандарт действует

пожизненно, пока не выйдет другой, его заменяющий. У ISO правило другое: стандарт действителен 5 лет со дня публикации. Если через 5 лет никто не затребовал его пересмотра, стандарт теряет силу.

 

 

В принципе так, но срок по-моему гораздо больший. В противном случае это

означает что с 1992 по 1995 год стандарта Ады не существовало. Аналогично,

вот уж 3-ий год как мы опять существуем без стандарта, и если я что-то

понимаю в вопросе, будем без него существовать еще года 3 минимум (принятия

нового стандарта Ады раньше 2006 года я не ожидаю). Я думаю, что минимум

лет 10 срок жизни стандарта, если не все 15.

 

Позвольте не согласиться. RM95 как ISO/IEC 8652:1995 официально уже не действителен. С сентября 2000 года и до момента принятия нового стандарта его заменяет документ ISO/IEC 8652:1995:TC1:2000.

 

Протокол не определяет какой период времени отводится на доработку/пересмотр стандарта. Действует только правило, согласно которого каждые 5 лет пересмотра должна выходить какая-нибудь писулька, утверждающая, что тема не потеряла своей актуальности.

 

На период с 1992 по 1995 годы должна быть некоторая бумажка, продлившая срок действия стандарта ISO 8652:1987 до 2002 года. Позднее она потеряла силу в связи с выходом ISO/IEC 8652:1995. К сожалению, найти её данные не удалось - с сайта уже удалены столь давние документы. :(

 

 

-- Vadim Godunko

Sergey I. Rybin wrote:

 

Vasiliy Fofanov wrote:

 

В этом отличие стандартов эксСССР и ISO. У нас стандарт действует

пожизненно, пока не выйдет другой, его заменяющий. У ISO правило другое:

стандарт действителен 5 лет со дня публикации. Если через 5 лет никто не

затребовал его пересмотра, стандарт теряет силу.

 

В принципе так, но срок по-моему гораздо больший. В противном случае это

означает что с 1992 по 1995 год стандарта Ады не существовало. Аналогично,

вот уж 3-ий год как мы опять существуем без стандарта, и если я что-то

понимаю в вопросе, будем без него существовать еще года 3 минимум (принятия

нового стандарта Ады раньше 2006 года я не ожидаю). Я думаю, что минимум

лет 10 срок жизни стандарта, если не все 15.

 

 

Вот и мне так казалось. Несколько лет назад (на SIGAda 2000, по-моему) был

доклад о проекте пересмотра Адского стандарта. Основная идея докладчика была

примерно такая: вообще-то положено, учитывая 10-летний цикл пересмотра

информационных стандартов, но нужды особой нет, совершенно не к спеху,

да и менять нечего, разве что прагмы добавить да библиотеки расширить.

 

10-ти летний цикл это и есть 5+5. 5 действует стандарт, 5 его модифицируют. Это только стандарты на допуска и посадки сразу переутверждают (и слава богу!). :)

 

PS. Знающие люди с нетерпением ждали сентября 2000, когда ISO постановила, что Ada будет жить. А сколько споров было по этому поводу.

 

 

-- Vadim Godunko

Позвольте не согласиться. RM95 как ISO/IEC 8652:1995 официально уже не С сентября 2000 года и до момента принятия нового

стандарта его заменяет документ ISO/IEC 8652:1995:TC1:2000.

 

Спасибо, не знал.

 

С уважением,

Василий.

1. Я хотел бы, чтобы вы на это посмотрели, поругали, поправили.

 

В контексте вышесказанного позволю себе высказать некоторые идеи. С точки зрения простого читателя статьи.

 

Сразу оговорюсь, статья хорошая. Я ее собираюсь запостить почитать нашим программистам на фирме, если автор позволит автора. Всё нижесказанное относится

не столько к этой статье, сколько вообще к идее рекламы языка Ады на exUSSR.

Рассматривая, напимер, эту статью в контексте рекламы языка Ада, думаю она лишена

самых необходимых для этого пунктов.

 

Первый вопрос - аудитория. Программисты или руководители проектов. В любом случае, я бы озаглавил ее чем то вроде "Почему мой следующий проект надо писать на Аде?". Немного навязчиво? Зато конкретно. И заставляет задуматься. Да и прочтут гарантировано.

 

Проблема "недостаточного распространения Ады" берет свое начало как раз в тот

момент, когда очередной руководитель проекта (в мире бизнеса) или программист (сам по себе) делает выбор языка для нового проекта. И выбирает не Аду.

 

Ответ на вопрос почему - это целое рыночное исследование. Именно рыночное. К конструкциям и свойствам языка это не имеет отношения, ибо язык выбирает или не выбирает рынок.

 

Могу поделиться двумя интересными мнениями по этому поводу. Последний раз я дискутировал на эту тему в Team Ada с каким-то руководителем проекта из Петербурга. К сожалению не могу найти у себя письмо, но где-то на ACM есть архив рассылки. Его мнение в отношении Ады было предельно конкретно - проектирование программы на языке Ада занимает больше времени, чем на C++, и должно производится с большей тщательностью, что мы не можем себе позволить (он говорил о своей фирме) так как обычно у нас нет даже строгой постановки задачи. Все что мы можем себе позволить - это поскорее сделать работающий продукт, а потом уже понять, чего же от нас собственно хотели.

 

Гораздо раньше, я натыкался на исследование, что-то вроде "почему Ada не входит в число N языков, на которых сейчас разрабатываются программы в Великобритании" (ссылки, к сожалению не помню, может быть пробегало в той же Team Ada). Там все причины перечислены в соответствии со статистикой, собранной у реальных фирм-производителей ПО. Первой и главной реальной причиной было названо отсутствие или плохая поддержка сторонних библиотек для конкретных применений. При этом, это говорили люди, имеющие более 5-10 лет профессиональной работы на Аде. В одной из фирм их оказалось более половины - 2/3. И всё равно новые проекты в этой фирме делаются на C++/Java.

Так вот, я не согласен что все так однозначно. Что не существует ниш или целых областей,

где бы применение Ады не было бы эффективно с рыночной точки зрения. Если вы можете

доказать, что применение определенной технологии дает существенный выигрыш (в $), то

рекламные лозунги вроде "C# - новая супер технология" идут гулять стороной.

Представьте себе, ну скажем, руководителя, перед которым поставлена конкретная задача и выделен определенный бюджет для ее реализации (программист-энтузиаст - это тот же project manager, только, по сути, самостоятельный). По каким критериям он делает выбор средств

программирования, если постановка задачи не оговаривает этого.

Мне кажется, важны следующие пункты:

 

1. Риск неудачи проекта. На сколько велика вероятность оказаться в ситуации, когда никто не знает, что делать и как выйти из тупика, а время на решение проблемы ограниченно. Когда-то я оказался в подобной ситуации, налетев на баг в GNAT незадолго до сдачи дипломного проекта. Отправился на ВЦ к друзьям (интернет тогда был доступен не многим) и скачал последнюю версию компилятора. Баг не был пофикшен. В итоге я потерял пару-тройку дней, так как после неудачных попыток апдейта пришлось делать серьезный редизайн уже написанной программы.

 

Это относится не только к самому компилятору, но и к сторонним библиотекам. В подобную ситуацию попал швецкий проект роботов-футболистов, завязанный на AdaBROKER (реализация CORBA под Ada). Они оказались в ситуации, когда команда более чем из 10 игроков отказывалась двигаться. Причиной оказалась константа 10, зашитая глубоко в реализации брокера, о которой сами разработчики забыли. Подобных примеров можно привести множество

(и не только на Аде), но при реализации проекта на новом языке важно знать состояние/стабильность существующего окружения. Надо знать, за какие проекты можно браться, а за какие нет.

 

Мне кажется, полезной будет информация о текущем состоянии GNAT (как public так и коммерческой версии), корпорации ACT, success stories. Далее. Перечень библиотек. Начиная от Бучевых компонент. Их стабильность. Success strories.

 

Важно не показать: "у Ады все нормально" или "у Ады все плохо" а набросать картину того, что действительно нормально, а что действительно плохо. Важно показать те применения, которые уже отработаны, заселены

и успешно эксплуатируются. Метро - это сильно, но сомневаюсь что группе программистов, взявшихся что-то делать будут доступны те средства разработки,

библиотеки и уровень поддержки, который был у разработчиков системы управления

метро.

Пока не будет ощущения твердой почвы никто не будет использовать технологию. А такого ощущения не будет без объективной картины. Я уверен, что некоторые нишевые применения без риска могут использовать GNAT и соответствующее окружение.

Надо показать какие.

 

2. Наличие необходимых библиотек.

Один раз я взялся писать программу на Перле только потому, что в библиотеке есть функция разбора html-таблицы.

 

Надо показать, чем может гордится Ада-мир.

Я думаю, стоит рассказать об AWS. Это более чем библиотека. Это технология. Это нишевое решение, когда выбор GNAT и AWS может оказаться эффективнее, чем любое другое средство.

 

3. А какие альтернативы?

Этот вопрос будет ставиться всегда, при выборе любого языка. Ответ на него зависит

от ниш. Нельзя сравнивать, скажем, всегда с C++. Если речь идет о разработке системы

электронной торговли, то надо рассматривать PHP vs AWS. Если параллельные вычисления -

POSIX Threads vs Ada Tasking. Если распределенные системы - Annex E & Jgnat & Abroca (AdaBROKER)

vs Java & C# & CORBA for C++. Я вижу во многих случаях сильные преимущества Ады.

Самый яркий и, вероятно, распространенный на практике пример,

демонстрирующий

"ультимативность" решения на Аде - это параллельные вычисления. Когда я с кем-то

спорю о преимуществах Ады, здесь мой оппонент обычно умолкает и о чем-то всерьез задумывается.

 

4. Архитектурные решение.

Так уж выходит, что все четко поделено. Есть языки (их немного) которые претендуют на универсальность (C/C++, например). Другие - сильны в своей области.

С Адой так вышло, что она не стала универсальной в силу не такой мощной поддержки,

как C или Java, и имеет слишком много хороших черт, чтобы стать "нишевым решением" (для

тех же встроенных систем). По сути язык универсальный. По поддержке - далеко нет.

Секрет успешного применения Ады заключается, на мой взгляд, в успешном сочетании

Ады с другими языками в рамках одной системе. При этом Ада-часть почти всегда

является сосредоточением "серверной логики". Я бы не рекомендовал Аду для построения

интерфейса пользователя всем. Но как язык, на котором пишутся сервера распределенной системы

- однозначно.

 

Для "сопряжений" у нас есть такие средства:

1) естественное (на уровне стандарта) сопряжение с C и Fortran;

2) возможность использовать C++ классы (GNAT) - правда немного ограниченная, но

реально работающая с парой-тройкой-семеркой сторонних классов на программу;

3) AdaSockets ;

4) CORBA <-> Annex E, Jgnat.;

5) AWS.

 

Вот, пожалуй, основные вопросы потенциального "покупателя" (раз уж речь зашал о рекламе). Мне кажется, ответы на них смогут поднять авторитет этого языка. На это должна быть направлена реалама.

 

Но это, вероятно, будет уже другая статья.

 

--

Сергей Лодягин

Sergei Lodyagin wrote:

 

В общем я полностью согласен...

 

 

1. Риск неудачи проекта. На сколько велика вероятность оказаться в ситуации,

когда никто не знает, что делать и как выйти из тупика, а время на решение

проблемы ограниченно. Когда-то я оказался в подобной ситуации, налетев

на баг в GNAT незадолго до сдачи дипломного проекта. Отправился на ВЦ

к друзьям (интернет тогда был доступен не многим) и скачал последнюю

версию компилятора. Баг не был пофикшен. В итоге я потерял пару-тройку дней,

так как после неудачных попыток апдейта пришлось делать серьезный редизайн

уже написанной программы.

 

Это относится не только к самому компилятору, но и к сторонним библиотекам.

В подобную ситуацию попал швецкий проект роботов-футболистов, завязанный

на AdaBROKER (реализация CORBA под Ada). Они оказались в ситуации, когда

команда более чем из 10 игроков отказывалась двигаться. Причиной оказалась

константа 10, зашитая глубоко в реализации брокера, о которой сами

разработчики забыли. Подобных примеров можно привести множество

(и не только на Аде), но при реализации проекта на новом языке важно знать

состояние/стабильность существующего окружения. Надо знать, за какие проекты

можно браться, а за какие нет.

 

Если у Вас нет _полной_ коммерческой поддержки, то браться ни за что нельзя. Даже при отезженной и отработанной GNAT технологии за последнюю неделю я нашел 7 (семь!) ошибок к компиляторе, утилитах, документации. Но это не значит, что всё плохо, поскольку почти пятилетний опыт использования публичной версии привел к обнаружению всего раза в два большего количества ошибок.

 

 

2. Наличие необходимых библиотек.

Один раз я взялся писать программу на Перле только потому, что в библиотеке

есть функция разбора html-таблицы.

 

Надо показать, чем может гордится Ада-мир.

 

Вот тут всё выглядит весьма интересно. Приведу цитату, она выглядит следующим образом:

 

"Classified Classified Classified Classified Classified Classified Classified Classified Classified Classified Classified Classified Classified Classified Classified Classified Classified Classified Classified Classified Classified Classified Classified Classified Classified Classified Classified Classified Classified Classified Classified Classified Classified Classified Classified Classified Classified Classified Classified Classified Classified Classified"

 

и т.д.

 

 

Для "сопряжений" у нас есть такие средства:

1) естественное (на уровне стандарта) сопряжение с C и Fortran;

2) возможность использовать C++ классы (GNAT) - правда немного ограниченная,

но

реально работающая с парой-тройкой-семеркой сторонних классов на программу;

3) AdaSockets ;

4) CORBA <-> Annex E, Jgnat.;

5) AWS.

 

Не забудьте Florist (Ada <-> POSIX)

 

 

Но это, вероятно, будет уже другая статья.

 

А теперь сделаю оригинальное заявление. По моему мнению основная причина нераспространенности Ады - нежелание использующих её людей привлекать к себе внимание. Аде не нужна рекламная шумиха, ибо она медленно и верно используется в _крупных_, _долгоживущих_ проектах. Никто _не_ _заинтересован_ в её расширении или изменении, в той степени, которая требуется для _современных_ языков программирования.

 

Здесь наблюдается полная демократия: если хочешь быть с нами - будь, объясним и поможем. Но если ты не принимаешь _наши_ правила игры, то тебе с нами не попути.

 

А понимание правил игры либо заложено в ДНК, либо приходит с опытом. А опыт приходит слишком позно (если вообще приходит).

 

 

-- Vadim Godunko

Новое сообщение:
Страницы: 1 2 3

Чтобы оставить новое сообщение необходимо Зарегистрироваться и Войти