Ada_Ru форум

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

ada & fs. Страница 2

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

Сообщения

Aleksey Ulasevich wrote:

 

Похоже это больше связано с технической организацией форума. Я попробывал повторить вопрос и тут же получил ответ. )

Я все сообщения по почте получаю - может кто их по другому получает (в инете смотрит например) ?

 

Здесь такой косяк бывает :(

 

-- Vadim Godunko

 

Technoserv A/S

Rostov-on-Don, Russia

Hello Vadim,

 

Wednesday, August 3, 2005, 12:23:45 PM, you wrote:

 

Vladyslav Kozlovskyy wrote:

>>

>> !!! Ъстртш, тюярюс ъ ррчррсютчшърь, ш тхь, ътю шсяюыьчухт Рфу т сюыьшшх >> ярюхътрх:

>> Ъръ ты ррсютрхтх с сютэяьш, тысячрьш фрщыют, сюстртыяющшьш Трш >> ярюхът? Ъръ ты уярртыяхтхсь с этшь хючящсттюь? Ърышр эх хфхт? Ъръшх >> CASE, IDE срхфсттр ты шсяюыьчухтх эр фрэыщ ьюьхэт фыя тюую, чтюсы >> тхстш стющ ярюхът? Тхфхтх ыш Ты ярррыхэюх уррфшчхсъюх (UML) >> ярхфстртыхэшя ярюхътр?

>>

Шч тсхх IDE ышчэю я ярюсытры тюыьъю GPS. Эх сърцу, чтю юэ яыюх, эю эх сърцу ш юсрртэюую.

 

!!! Кстати, вопрос к разработчикам, и тем, кто использует Аду в больших проектах:

Как вы работаете с сотнями, тысячами файлов, составляющими Ваш

проект? Как вы управляетесь с этим хозяйством? Крыша не едет? Какие CASE, IDE средства вы используете на даный момент для того, чтобы вести свой проект? Ведете ли Вы параленое графическое (UML)

представления проекта?

 

Из всех IDE лично я пробывал только GPS. Не скажу, что он плох, но не скажу и обратного.

 

В большом проекте десятки тысяч файлов - обыденная реальность. От полного хаоса спасает только структурированность кода и аккуратное (интуитивно понятное всей коданде) назначение им имЈн. Никакой IDE справиться с такими объЈмами просто не в состоянии - ему не хватит никаких ресурсов.

 

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

 

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

Реально же UML мы используем, причЈм постоянно. Но не для отражения полного представления проекта, а, в первую очередь, для отражения межпрограммных взаимодействий.

 

>Eclipse и NetBeans вам в помощь. Берите исходники, смотрите, изучайте, >пишите. Возможно лет через пять напишете что-нибудь подобное для языка >АДА на языке АДА. Главное упор сделайте на саму философию архитектуры и >методологии, ибо они неразрывны друг от друга - без одной, невозможно >жить и другой.

 

Это реально для Ады и сейчас. Но вопрос в другом - деньги. Знаете сколько миллионов уже вложила IBM в Eclipse? А NetBeans что -

бесплатно появилась на свет? Если появится спонсор, желающий оплатить подобную разработку для Ады, я сам бы собрал команду 10-15 человек для создания Ада аналога wxWidgets и Eclipse.

 

А так, как я живу в Украине (в странах до 200$ (в действительности в моем городе программист получает в среднем 300-600$) :), то расходы на такой проект будет на порядок ниже чем в Америке или Европе.

 

Ну-с. Кто готов финансировать такой проект? :)

 

Представьте Ваш план, пожалуйста.

 

А что, есть желание финансировать? :)

 

 

--

Vadim Godunko

 

Technoserv A/S

Rostov-on-Don, Russia

 

 

--

Best regards,

Vladyslav

Пардон, ушло в непомянтой кодировке (ISO-8859-5)

 

This is a forwarded message

From: Vladyslav Kozlovskyy <dbdeveloper@...>

To: Vadim Godunko <ada_ru@yahoogroups.com>

Date: Wednesday, August 3, 2005, 6:57:26 PM

Subject: [ada_ru] О наболевшем.

 

===8<==============Original message text===============

Hello Vadim,

 

Wednesday, August 3, 2005, 12:23:45 PM, you wrote:

 

Vladyslav Kozlovskyy wrote:

!!! Кстати, вопрос к разработчикам, и тем, кто использует Аду в больших проектах:

Как вы работаете с сотнями, тысячами файлов, составляющими Ваш

проект? Как вы управляетесь с этим хозяйством? Крыша не едет? Какие CASE, IDE средства вы используете на даный момент для того, чтобы вести свой проект? Ведете ли Вы параленое графическое (UML)

представления проекта?

 

Из всех IDE лично я пробывал только GPS. Не скажу, что он плох, но не скажу и обратного.

Тяжеловат для Windows и местами глюковат (публичная версия gps-2.1.0-academic) А с дебагером я так и не разобрался.

 

Мне по душе AdaIDE Андрея Кузнецова. Отладчик там реализован просто супер! Удивляюсь, почему так нельзя было сделать в других IDE (gps, adagide, jgrasp)? Ее немного доработать - получится неплохая IDE, очень неплохая.

 

 

В большом проекте десятки тысяч файлов - обыденная реальность. От полного хаоса спасает только структурированность кода и аккуратное (интуитивно понятное всей команде) назначение им имён. Никакой IDE справиться с такими объёмами просто не в состоянии - ему не хватит никаких ресурсов.

Сомневаюсь. Когда 1G памяти на рабочих местах программистов становится обыденность, следить за 3_000 даже 50_000 пакетов не проблема. Да такой проект полностью в памяти помещается! :)

 

 

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

 

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

Кто мешает додумать недостающие схемы? UML не панацея, я привел UML, как пример собраной воедино и действующей коллекции графических

абстракций (просто имя раскрученное, вот и запомнилось :)

 

Реально же UML мы используем, причём постоянно. Но не для отражения полного представления проекта, а, в первую очередь, для отражения межпрограммных взаимодействий.

Резонно. А почему не используете Implementation Diagram? - по моему она разрабатывалась именно для Ады - для описания пакетов и их

взаимодействия. А class diagram разве не используете?

 

 

>Eclipse и NetBeans вам в помощь. Берите исходники, смотрите, изучайте, >пишите. Возможно лет через пять напишете что-нибудь подобное для языка >АДА на языке АДА. Главное упор сделайте на саму философию архитектуры и >методологии, ибо они неразрывны друг от друга - без одной, невозможно >жить и другой.

 

Это реально для Ады и сейчас. Но вопрос в другом - деньги. Знаете сколько миллионов уже вложила IBM в Eclipse? А NetBeans что -

бесплатно появилась на свет? Если появится спонсор, желающий оплатить подобную разработку для Ады, я сам бы собрал команду 10-15 человек для создания Ада аналога wxWidgets и Eclipse.

 

А так, как я живу в Украине (в странах до 200$ (в действительности в моем городе программист получает в среднем 300-600$) :), то расходы на такой проект будет на порядок ниже чем в Америке или Европе.

 

Ну-с. Кто готов финансировать такой проект? :)

 

Представьте Ваш план, пожалуйста.

 

А что, есть желание финансировать? :)

Тогда милости прошу в приватную переписку.

 

--

Vadim Godunko

 

Technoserv A/S

Rostov-on-Don, Russia

 

 

--

Best regards,

Vladyslav

Aleksey Ulasevich wrote:

 

Прошу меня простить - мало сплю и много кофе пью )

 

Я вижу (из названий подпрограмм) что во FLORIST есть все что мне нужно и все что мне может понадобиться в ближайшем будущем (и речь не только о чтении каталога).

 

Вопрос как я понимаю следующий "Как прочитать каталог с помощью Florist".

Ежели так, то ответит с ходу только тот кто писал с помощью Florist.

Ежели поставить вопрос проще "Как прочитать каталог" то я бы

порекомендовал 2 варианта.

 

Старый компилятор GNAT 3.15p - пакет GNAT.Directory_Operations

Новый компилятор GCC 4.0.x с включенной поддержкой Ада - пакет

Ada.Directory_Operations

Vladyslav Kozlovskyy wrote:

 

>!!! Кстати, вопрос к разработчикам, и тем, кто использует Аду в больших >проектах:

Как вы работаете с сотнями, тысячами файлов, составляющими Ваш

проект? Как вы управляетесь с этим хозяйством? Крыша не едет? Какие CASE, IDE средства вы используете на даный момент для того, чтобы вести свой проект? Ведете ли Вы параленое графическое (UML)

представления проекта?

 

 

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

вспомогательных CASE средствах.

Я не настаиваю на этом мнении потому что не делаю проекты в тысячи пакетов, у меня пакетов наверное десятки

но тем не менее, не нуждаюсь в case средствах.

On Wed, 03 Aug 2005 14:41:38 +0400, Aleksey Ulasevich <platinum@...> wrote:

 

Aleksey Ulasevich wrote:

 

 

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

ответа?

 

 

Похоже это больше связано с технической организацией форума. Я

попробывал повторить вопрос и тут же получил ответ. )

Я все сообщения по почте получаю - может кто их по другому получает (в

инете смотрит например) ?

 

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

в несколько раз меньше :) Правда пока на gmail переходить не собираюсь :)

 

(кому надо ящик на gmail пишите - гиг на халяву + поиск, идеальная вещь

для подписки на всякий спам - можно даже не читать, а потом поискать

если что вдруг понадобилось ;} )

 

 

PS. Конечно здесь иногда можно получить ответ типа RM95 3.6 (11), но это

 

 

^^^^^^^^^^^^ - вполне нормальный ответ ))))))

 

Погоди, это пока траффик маленький :)

 

По мере роста траффика спецы обычно разбегаются, остальные начинают

понимать что быстрее читать через поисковик (при этом естессно никто

вопросы читать не будет :} )

 

(это я намекаю на то что проблемы надо начинать решать еще до того

как они появятся :) )

 

Vladimir

-- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

On Tue, 02 Aug 2005 19:16:47 +0400, Aleksey Ulasevich <platinum@...> wrote:

 

Прошу меня простить - мало сплю и много кофе пью )

 

Я вижу (из названий подпрограмм) что во FLORIST есть все что мне нужно и все что

мне может понадобиться в ближайшем будущем (и речь не только о чтении каталога).

Но я не могу им воспользоваться из-за отсутвия документации.

 

 

Кстати, вот насчет документации для open source это тоже интересный вопрос...

 

Все-же лучшая дока где точно есть про все фичи и без ошибок - это сам исходник!

(тем более для языка с хорошо читаемым исходником)

А вот для чего делают такие пухлые доки не понимаю - в них же из-за ожирения

невозможно ничего найти полезного! Да и времени тратиться куча - лучше бы

на че-нить полезное потратили...

 

В общем есть предложение составить что-то вроде списка рекомендаций

по составлению документации для open source. Идея такая - дока не должна

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

и наоборот, хорошо описывать то чего нет в исходнике - например,

история, планы развития, разные размышления на тему алгоритмов и тп

ну и описания параметров, смысл которых не очевиден(хотя это тоже

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

 

У кого какие мысли?

 

Vladimir

-- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

teplouhov@... wrote:

 

Все-же лучшая дока где точно есть про все фичи и без ошибок - это сам исходник!

(тем более для языка с хорошо читаемым исходником)

А вот для чего делают такие пухлые доки не понимаю - в них же из-за ожирения

невозможно ничего найти полезного! Да и времени тратиться куча - лучше бы

на че-нить полезное потратили...

 

Извините, но очень хочется узнать, с какими по размеру проектами Вам приходилось иметь дело?

 

-- Vadim Godunko

 

Technoserv A/S

Rostov-on-Don, Russia

On Mon, 08 Aug 2005 01:44:56 +0700, Dmitriy Anisimkov <anisimkov@...> wrote:

 

Vladyslav Kozlovskyy wrote:

 

!!! Кстати, вопрос к разработчикам, и тем, кто использует Аду в больших

проектах:

Как вы работаете с сотнями, тысячами файлов, составляющими Ваш

проект? Как вы управляетесь с этим хозяйством? Крыша не едет? Какие

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

вести свой проект? Ведете ли Вы параленое графическое (UML)

представления проекта?

 

 

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

вспомогательных CASE средствах.

Я не настаиваю на этом мнении потому что не делаю проекты в тысячи

пакетов, у меня пакетов наверное десятки

но тем не менее, не нуждаюсь в case средствах.

 

 

Кстати, насчет графики :)_

 

Электрические схемы это достаточно графическое представление? ;)

Дак вот, рекомендую посмотреть на чем делаются БОЛЬШИЕ схемы,

ну тоесть не просто схема там телевизора из десятка ламп или ИМС

и размером с м2, а схемы чипов на миллионы транзистров и тп...

(наверно на opencores.org можно найти че-нить на VHDL и тп)

Спорим что если не знаете что это такое то подумаете что это

программа на чем-то вроде паскаля? :)_ Намек понятен?

 

То-же самое и на стыке редактора схем и разводилки плат - данные

передаются в виде нетлиста, тоесть сама граф схема программе

разводки плат нафиг не нужна, более того, ее часто и вообще

не рисуют даже сами разработчики - проще сразу писать на языке

описания схем...

 

В общем с графикой так - она удобней и применима только для

НЕБОЛЬШИХ кусков схем, которые влазят примерно на экран, точнее

в поле зрения глаза, ну мож чуть-чуть больше. А вот дальше все,

облом, если схема достаточно большая, то на бумаге найти куда

идет какой провод графически практически на возможно(кстати

и на граф схеме сразу начинают уже давать названия

проводникам/узлам схемы, иногда в виде номеров, иногда

это длинные символьные названия вроде процедур в языке),

удобней пользоваться электронной схемой и искать поиском

куда что идет (нормальные редакторы схем умеют искать и/или

подсвечивать проводник или весь узел).

 

Vladimir

-- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

On Mon, 08 Aug 2005 10:31:18 +0400, Vadim Godunko <godunko@...> wrote:

 

teplouhov@... wrote:

 

Все-же лучшая дока где точно есть про все фичи и без ошибок - это сам

исходник!

(тем более для языка с хорошо читаемым исходником)

А вот для чего делают такие пухлые доки не понимаю - в них же из-за

ожирения

невозможно ничего найти полезного! Да и времени тратиться куча - лучше бы

на че-нить полезное потратили...

 

Извините, но очень хочется узнать, с какими по размеру проектами Вам

приходилось иметь дело?

 

Дело не в размере, а во времени, которое приходится тратить не известно

на что, на поиски по бесполезной документации, например :)

 

Тоесть даже на мелком проекте в несколько строк уходит куча времени

на разборки с библиотеками, ключами компилятора и тд и тп. Я считаю

что для продуктов которые претендуют на звание "готовый продукт"

это несколько не правильно...

 

 

Вот зачем загромождать доку тем, что есть и так в исходнике и гораздо

понятнее и точнее? Даже каких-то программ понаписали чтобы доку можно было

генерировать - такое ощущение что пишут так будто ее потом читать все

равно никто не будет, а платят за килобайты ;) Зачем там этот обкусанный хлам,

если есть полный исходник??? (ладно там в не опенсорсных это надо,

но тут-то какой смысл на это тратить и время программиста, и пользователя?)

 

Все осложняется еще и тем, что инфу боле-мене серьезного уровня(по смыслу)

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

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

и включать туда только то чего нет в других местах. (кстати тут наверно

половина вопросов про то что должно быть в доке)

 

Vladimir

-- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

teplouhov@... wrote:

 

Дело не в размере, а во времени, которое приходится тратить не известно на что, на поиски по бесполезной документации, например :)

 

Полезность/сесполезность поиска в документации напрямую зависит только от её качества, в частности - структурированности.

 

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

 

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

 

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

Типичный пример - GNU AutoTools. Сколько знаний надо иметь дабы

правильно им пользоваться? С обоих сторон, как с точки зрения

программиста, так и с точки зрения пользователя?

 

Как правило такие затраты не окупаются именно на мелких проектах, и с лихвой окупаются на крупных.

 

PS. Мы начинали свой проект пол года назад просто с типового набора макросов и нескольких позаимствованных из PolyORB макроопределений и вспомогательных подпрограмм. С тех пор у нас появилось шесть новых собственноручно разработанных макросов и пару скриптов, один скрипт и один макрос уже перекочевали в проект PolyORB, и вернулись обратно в значительно усовершенствованном варианте.

 

Вот сейчас мы уже готовы профинансировать доработку AutoMake для

поддержки Ada как одного из "родных" языков...

 

 

Вот зачем загромождать доку тем, что есть и так в исходнике и гораздо понятнее и точнее? Даже каких-то программ понаписали чтобы доку можно было генерировать - такое ощущение что пишут так будто ее потом читать все равно никто не будет, а платят за килобайты ;) Зачем там этот обкусанный хлам,

если есть полный исходник??? (ладно там в не опенсорсных это надо, но тут-то какой смысл на это тратить и время программиста, и пользователя?)

Генерация такой документации обычно является следствием требований заказчика. Или желания показать как хорошо у проекта обстаят дела с документацией. Естественно, её никто не читает...

 

Все осложняется еще и тем, что инфу боле-мене серьезного уровня(по смыслу) поиском по ключевым словам найти почти не возможно, тоесть инфу в доке стоило бы просмотреть всю, так что объем доки следует минимизировать и включать туда только то чего нет в других местах. (кстати тут наверно половина вопросов про то что должно быть в доке)

 

А что должно быть в документации - необходимо стотреть в соответствующих стандартах. Например, наиболее простым являются наши ГОСТы 19 и 24 групп. Нет смыска пересказывать, их можно свободно найти в InterNet.

Как эквивалент - стандарты Министерства обороны США, если правильно помню, 2167 и 498.

 

Можно найти и стандарты ISO.

 

 

--

Vadim Godunko

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

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