Слышал, что при написании программ на C++ количество допущенных ошибок на порядок больше, чем при написании их же в "АДА", стоимость выше на 60% и т.п. (см. http://www.adaic.com/whyada/ada-vs-c/cada_art.html).

Насколько буквально это понимать и почему C++ более распространён чем АДА? Переходим на АДА???

Можно ли разработать ещё более экономичные языки?

Здравствуйте, FDSC, Вы писали:

FDS>Слышал, что при написании программ на C++ количество допущенных ошибок на порядок больше, чем при написании их же в "АДА", стоимость выше на 60% и т.п. (см. http://www.adaic.com/whyada/ada-vs-c/cada_art.html).

FDS>Насколько буквально это понимать и почему C++ более распространён чем АДА? Переходим на АДА???

FDS>Можно ли разработать ещё более экономичные языки?

Признаюсь, доку не читал. Но подозреваю, что ошибки всё-таки делает программист, а не язык Код на Ада может быть в среднем менее "ошибочным" хотя бы потому, что на Ada пишут гораздо меньше, чем на C++, Ada-спецов меньше и, как следствие, они качественнее

Какие бы приёмы не применялись для уменьшения количества ошибок на стадии разработки, всё равно их количество обратно пропорционально квалификации программиста, а не некоему "коэффициенту безошибочности языка".

Здравствуйте, Oyster, Вы писали:

O>Какие бы приёмы не применялись для уменьшения количества ошибок на стадии разработки, всё равно их количество обратно пропорционально квалификации программиста, а не некоему "коэффициенту безошибочности языка".

1. По статистике (честно говоря, незнаю как это получается) количество ошибок не зависит от квалификации программиста (не помню откуда, могу поискать).

2.Речб идёт о сравнении аналогичных проектов. Вплоть до версий одного и того же проекта на C++ и Ада, при этом количество C-кода то же больше при той же функциональности. Разработка ведётся примерно одинаковыми командами, как по квалификации (что, впрочем, можно подвергнуть сомнению), так и по количеству программистов.

3. Квалифицированный программист, который совершает в 10 раз меньше ошибок (см. пункт 1) стоит, наверное, во столько же раз дороже. Как же по поводу уменьшения стоимости разработки на Ада?

FDSC wrote:

> Слышал, что при написании программ на C++ количество допущенных ошибок
> на порядок больше, чем при написании их же в "АДА", стоимость выше на
> 60% и т.п. (см. http://www.adaic.com/whyada/ada-vs-c/cada_art.html).

Там с Адой сравнивается не _С++_, а С. Это КРАЙНЕ разные языки, так что
такая статистика неудивительна.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

C>FDSC wrote:

>> Слышал, что при написании программ на C++ количество допущенных ошибок
>> на порядок больше, чем при написании их же в "АДА", стоимость выше на
>> 60% и т.п. (см. http://www.adaic.com/whyada/ada-vs-c/cada_art.html).

C>Там с Адой сравнивается не _С++_, а С. Это КРАЙНЕ разные языки, так что
C>такая статистика неудивительна.

Прочитай по внимательней, там есть раздел по исследованиям по C++. Говорят, что C++ не исправил ошибок в C.

FDS>Здравствуйте, Cyberax.


Кстати, речь ведь не только о C++ и есть ещё много других статей по сравнению языков (привести сей-час честно говоря не могу).

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

Я собственно больше хотел узнать мнения "почему так" и "как сделать ещё лучше", может если все начнут на Аде программировать станут более квалифицированными? Написать новый компилятор для C++ или, вообще, придумать другой язык... Чтоб ошибок в 100 раз меньше было, ведь от средства разработки то же многое зависит.

Здравствуйте, FDSC, Вы писали:

FDS>http://www.adaic.com/whyada/ada-vs-c/cada_art.html.
Прочитал. КГ/АМ.

Порадовало следующее:
Coding standards for C have been aimed at avoiding the known problems with the C language. A partial list is:

· dangling "else"s
Это что ли "if( condition ) { block } else"?
Это в каком наркотическом бреду такое может стать ТАКОЙ проблемой,
что надо специально этот случай оговаривать в стандарте кодирования ?

· use of "=" for "==", especially in conditional statements
Гы Новички от этого страдают. Но компиляторы как правило на такое
ругаются ворнингами. А программеров что игнорируют ворнинги — кастрировать
без права обжалования.

· use of "/=" for "!="
Гм... А в каком это языке "не равно" пишется как "/="?

· overuse of macros
Да, это грех. Полностью согласен.

· use of "cute programming" that sacrifices comprehension for brevity
...Вообще-то это дело вкуса...

· use of integer for pointer
Ну, это возможно только в С, но не в C++

Вот еще:

Will C++ Change The Picture?
Some may look at this study and conclude that C++ will tame C's problems.

Our early experience does not support that conclusion.

Bug rates in C++ are running higher even than C, although we have no where near the ideal comparison platform that we have had with VADS for C and Ada. We do not yet have a large mix of people programming in both C++ and Ada for similar difficulty programs and with history as released products. Our theoretical views of our C++ problems indicate that C++ may allow "run-away inheritance", where many very similar classes are created from a substrate without care to design a smaller number of re-usable classes without many variants; also, existing C++ programs have not yet made good use of templates and so have become cluttered with "container classes" and attendant conversions; finally, so much of C++ goes unseen, hidden behind the notational convenience of the language, that the code can become difficult to understand and navigate. We have had long experience with Object Oriented Software, and believe that OO approaches can yield great benefit if tools can fully support the OO process, and if inheritance complexity can be minimized.

Мое резюме: Ребята, возможно, неплохо знают Аду, но знают C очень поверхностно.
С++ они не знают совершенно. Короче, еще одно сборище адвокатов пытающихся давать советы космического масштаба и космичексой же глупости. Фтопку.

Здравствуйте, FDSC, Вы писали:

FDS>Здравствуйте, Oyster, Вы писали:

O>>Какие бы приёмы не применялись для уменьшения количества ошибок на стадии разработки, всё равно их количество обратно пропорционально квалификации программиста, а не некоему "коэффициенту безошибочности языка".

FDS>1. По статистике (честно говоря, незнаю как это получается) количество ошибок не зависит от квалификации программиста (не помню откуда, могу поискать).

Великая страна Индия всеми силами опровергает данный постулат

FDS>2.Речб идёт о сравнении аналогичных проектов. Вплоть до версий одного и того же проекта на C++ и Ада, при этом количество C-кода то же больше при той же функциональности. Разработка ведётся примерно одинаковыми командами, как по квалификации (что, впрочем, можно подвергнуть сомнению), так и по количеству программистов.

Ну, во-первых, не C++, а C

Автор: Cyberax
Дата: 13.06.05

(т.е. статистика собиралась именно по C vs Ada). А во-вторых, можно ли говорить об объективности и достаточном количестве статистических данных в пределах одного проекта?

FDS>3. Квалифицированный программист, который совершает в 10 раз меньше ошибок (см. пункт 1) стоит, наверное, во столько же раз дороже. Как же по поводу уменьшения стоимости разработки на Ада?

Предполагаю, что чем распространённее язык, тем больше вероятность нарваться на неквалифицированного программиста. В контексте нашей страны (пост-СССР) такие языки, как Ада, Форт или Оберон не очень широко распространены, поэтому часто люди используют их из любви к искусству, а не только из-за требований тимлида, что влечёт за собой более высокую квалификацию таких людей "за те же деньги"


Потом, если уж такой разговор зашёл, то почему именно Ada vs C? Могу заявить, что разрабатывать на C# (или, скажем, на Java) сейчас дешевле и надёжнее, чем на C (за C++ не скажу). Так почему Ада? Переходим на C#. Или на Оберон — он вообще "синтаксически минимален"


PS: в общем-то, я к тому, что серебрянной пули нет...

Здравствуйте, 0xDEADBEEF, Вы писали:

...

Эти ребята очень неплохо знают C++, просто 1995 статья написана. Я уже немного раньше сказал, что речь идёт не только о C++ и Аде и есть множество различных мнений по этому вопросу.
Мне, кажется, что от языка всё-таки очень много зависит; я хотел бы узнать мнение других не только по поводу Ады, это просто как пример. Ада и С++ даже не вынесены в заголовок...

Здравствуйте, Oyster, Вы писали:

O>Здравствуйте, FDSC, Вы писали:

FDS>>Здравствуйте, Oyster, Вы писали:

O>Потом, если уж такой разговор зашёл, то почему именно Ada vs C? Могу заявить, что разрабатывать на C# (или, скажем, на Java) сейчас дешевле и надёжнее, чем на C (за C++ не скажу). Так почему Ада? Переходим на C#. Или на Оберон — он вообще "синтаксически минимален"


O>PS: в общем-то, я к тому, что серебрянной пули нет...

Я предлагаю сравнивать любые языки и даже среды программирования. Ада была как пример. Что такое "Оберон" я вообще не знаю (по моему что-то очень старое...).

Я не вижу, чем managed С++ хуже C#. (Впрочем, у меня немного практики программирования под .NET). По поводу Java я уже тут где-то написал, что технология не предназначена для работы в системах управления ответственными объектами в режиме реального времени.

FDSC wrote:

>>> Слышал, что при написании программ на C++ количество допущенных ошибок
>>> на порядок больше, чем при написании их же в "АДА", стоимость выше на
>>> 60% и т.п. (см. http://www.adaic.com/whyada/ada-vs-c/cada_art.html).
> C>Там с Адой сравнивается не _С++_, а С. Это КРАЙНЕ разные языки, так что
> C>такая статистика неудивительна.
> Прочитай по внимательней, там есть раздел по исследованиям по C++.
> Говорят, что C++ не исправил ошибок в C.

Совсем странно:
================
Bug rates in C++ are running higher even than C, although we have no
where near the ideal comparison platform that we have had with VADS for
C and Ada. We do not yet have a large mix of people programming in both
C++ and Ada for similar difficulty programs and with history as released
products. Our theoretical views of our C++ problems indicate that C++
may allow "run-away inheritance", where many very similar classes are
created from a substrate without care to design a smaller number of
re-usable classes without many variants; also, existing C++ programs
have not yet made good use of templates and so have become cluttered
with "container classes" and attendant conversions; finally, so much of
C++ goes unseen, hidden behind the notational convenience of the
language, that the code can become difficult to understand and navigate.
We have had long experience with Object Oriented Software, and believe
that OO approaches can yield great benefit if tools can fully support
the OO process, and if inheritance complexity can be minimized.
================
Скорее всего они:
1. Использовали малоопытных С++ников.
2. Использовали древнюю (даже для 1994г.) версию С++.
3. Пункты 2 и 1 вместе взятые.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

C>Скорее всего они:
C>1. Использовали малоопытных С++ников.
C>2. Использовали древнюю (даже для 1994г.) версию С++.
C>3. Пункты 2 и 1 вместе взятые.

Да, по поводу IDE они что-то странное написали. А вообще фрагмент, по моему, правильный, по поводу ООП и C++. Может я это .. не понимаю в программировании на C++ чего-то??? (я сам прогр. Delphi / assembler, C++ только правлю и дополняю, и то не очень часто).

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

Здравствуйте, FDSC, Вы писали:

[... skipped ...]

O>>PS: в общем-то, я к тому, что серебрянной пули нет...

FDS>Я предлагаю сравнивать любые языки и даже среды программирования. Ада была как пример. Что такое "Оберон" я вообще не знаю (по моему что-то очень старое...).

Не такое уж и старое. Оберон — это наследник Паскаля (и Модулы-2, соответственно).

А в чём смысл сравнивания? Найти наиболее экономный язык? Дык это невозможно — всё зависит от задачи. Для обычного индустриального кода одни требования, для систем реального времени — совсем другие. Императивные языки как правило быстры, зато функциональные — лаконичны. В общем, повторюсь — нет серебрянной пули. Нет и всё тут.

FDS>Я не вижу, чем managed С++ хуже C#. (Впрочем, у меня немного практики программирования под .NET). По поводу Java я уже тут где-то написал, что технология не предназначена для работы в системах управления ответственными объектами в режиме реального времени.

Так Java вроде и не для систем реального времени предназначалась imho. Основная задумка была в кросспратформенности. Ну и в мегафичах вроде "всё есть объект", "всегда есть GC" и т.д.

А насчёт Managed C++ — да ничем он не лучше C#. И вообще, наиболее эффективный .NET-код можно написать только на IL Но мне лично не нравится уродский синтаксис MC++ (C++ фактически приклеили пару новых ног, чтобы он смог бегать по новой платформе).

Здравствуйте, Oyster, Вы писали:

[... skipped ...]

O>А насчёт Managed C++ — да ничем он не хуже C#. И вообще, наиболее эффективный .NET-код можно написать только на IL Но мне лично не нравится уродский синтаксис MC++ (C++ фактически приклеили пару новых ног, чтобы он смог бегать по новой платформе).

Вечно тороплюсь и опечатываюсь

Здравствуйте, Oyster.

По поводу многоножки-C++ согласен.

Вы писали:

O>Здравствуйте, FDSC, Вы писали:

O>[... skipped ...]

O>>>PS: в общем-то, я к тому, что серебрянной пули нет...

FDS>>Я предлагаю сравнивать любые языки и даже среды программирования. Ада была как пример. Что такое "Оберон" я вообще не знаю (по моему что-то очень старое...).

O>Не такое уж и старое. Оберон — это наследник Паскаля (и Модулы-2, соответственно).

Извини, я не знал.

O>А в чём смысл сравнивания? Найти наиболее экономный язык? Дык это невозможно — всё зависит от задачи. Для обычного индустриального кода одни требования, для систем реального времени — совсем другие. Императивные языки как правило быстры, зато функциональные — лаконичны. В общем, повторюсь — нет серебрянной пули. Нет и всё тут.

Насчёт задачи, я в плане того, что Java не Ag пуля. Согласен.

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

Смысл сравнения найти новую идею и улучшить текущие языки. У них ведь нет, например, поддержки автоматической проверки ошибок — приходится писать ещё и языки, которые декларируют правила написания кода, а затем код на таких языках используют системы проверки — не удобно, да и системы проверки не так уж и распространены.

Здравствуйте, FDSC, Вы писали:

[... skipped ...]

FDS>Насчёт задачи, я в плане того, что Java не Ag пуля. Согласен.

FDS>Я не предлагаю искать с.п. Ведь удачный при проектировании языка подход может быть применён к языкам других отраслей.

FDS>Смысл сравнения найти новую идею и улучшить текущие языки. У них ведь нет, например, поддержки автоматической проверки ошибок — приходится писать ещё и языки, которые декларируют правила написания кода, а затем код на таких языках используют системы проверки — не удобно, да и системы проверки не так уж и распространены.

Эволюция языков и так происходит. Посмотри на широко применяемые индустриальные языки (C++, Java, C#) — и увидишь то, что прижилось. Излишне нагружать язык "синтаксическим сахаром" (для проверок валидности на этапе компиляции, например) тоже не есть хорошо (потому как листинги становятся более ... запутанными, что ли, и продуктивность программиста падает), поэтому в индустриальных языках прижились только действительно необходимые фичи.

Что же касательно уменьшения стоимости разработки — так работы ведутся (причём ведутся постоянно). Неизвестно только, что попадёт в индустриальные языки следующего поколения. Тем не менее, можно поюзать Google и найти несколько интересностей: например, Spec#

Автор: Курилка
Дата: 04.05.05

(это касательно compile-time assert) или Comega (асинхронные методы, элементы ФП, ...).

PS: сорри что оба примера из .NET — что знал...

DEA>· use of "/=" for "!="
DEA> Гм... А в каком это языке "не равно" пишется как "/="?

Как минимум в Erlang.

Здравствуйте, FDSC, Вы писали:

FDS>Эти ребята очень неплохо знают C++,
FDS>просто 1995 статья написана.
Обоснуй! Из статьи видно полностью противоположное.

Раз:

We do not yet have a large mix of people programming in both C++ and Ada for similar difficulty programs and with history as released products

Сами признаются что опыта — йок.

Два:

Our theoretical views of our C++ problems indicate that C++ may allow "run-away inheritance", where many very similar classes are created from a substrate without care to design a smaller number of re-usable classes without many variants;

Жалобы на то что C++ "много позволяет". Если им мама в детсве не вбила в бошку что не все что позволено можно делать... Клиника.

Три:

existing C++ programs have not yet made good use of templates and so have become cluttered with "container classes" and attendant conversions;

Звиздеж чистейшей воды. Я юзал шаблоны (BIDS) в Borland C++ 3.1 начиная с 1992-го года. В 1994-м вышел HP STL.

Четыре (всем рыдать):

finally, so much of C++ goes unseen, hidden behind the notational convenience of the language, that the code can become difficult to understand and navigate.

А это вообще перл: жалуются что на C++ трудно программировать потому что на нем удобно писать! Что из-за этого трудно разобраться в коде!

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

FDS>Мне, кажется, что от языка всё-таки очень много зависит;
Зависит.
Но данная статья нерепрезентативна тк в одном из сравниваемых языков (C) авторы явно некомпетентны — их "стандарт кодирования" для C — явный билет на газенваген.

Мне кажется старались перенести модель программирования ADA на C и у них это не получилось. Крайне бы удивился случись наоборот.

Здравствуйте, Oyster, Вы писали:

O>Что же касательно уменьшения стоимости разработки — так работы ведутся (причём ведутся постоянно). Неизвестно только, что попадёт в индустриальные языки следующего поколения. Тем не менее, можно поюзать Google и найти несколько интересностей: например, Spec#

Автор: Курилка
Дата: 04.05.05

(это касательно compile-time assert) или Comega (асинхронные методы, элементы ФП, ...).

За ссылки спасибо.
По поводу работ: они ещё сто лет будут вестись: фирмам, у которых есть свои компиляторы не выгодно их принципиально менять, разрабатываются в основном примочки.

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


Я говорю в том числе и об этом: может быть стоит вообще сделать компилятор, что бы в зависимости от надобности можно было видеть сам алгоритм, контроль ошибок, отладочные проверки и т.п. (по моему что-то подобное уже даже на этом форуме обсуждалось).

Мне интересны мнения не профессиональных исследователей, а того, кто на форуме. По моему они лучше могут понимать что надо делать.

Здравствуйте, FDSC, Вы писали:

FDS>Слышал, что при написании программ на C++ количество допущенных ошибок на порядок больше, чем при написании их же в "АДА", стоимость выше на 60% и т.п. (см. http://www.adaic.com/whyada/ada-vs-c/cada_art.html).

FDS>Насколько буквально это понимать и почему C++ более распространён чем АДА? Переходим на АДА???

FDS>Можно ли разработать ещё более экономичные языки?

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

FDSC wrote:

> C>Скорее всего они:
> C>1. Использовали малоопытных С++ников.
> C>2. Использовали древнюю (даже для 1994г.) версию С++.
> C>3. Пункты 2 и 1 вместе взятые.
> Да, по поводу IDE они что-то странное написали. А вообще фрагмент, по
> моему, правильный, по поводу ООП и C++. Может я это .. не понимаю в
> программировании на C++ чего-то??? (я сам прогр. Delphi / assembler,
> C++ только правлю и дополняю, и то не очень часто).

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

Претензии к библиотеке контейнеров — тоже к себе пусть предъявляют.
Сейчас есть стандартная STL.

> В любом случае я предлагаю сравнивать любые языки (хоть алгол-60).

Смысла нет.

--
С уважением,
Alex Besogonov (alexy@izh.com)

FDS> Мне интересны мнения не профессиональных исследователей, а того, кто на форуме. По моему они лучше могут понимать что надо делать.

Почему? Мне кажется, что большинство живёт так: дали камень, значит нужно чуток камень заполировать, чтоб ровная поверхность была, и гвозди камнем можно было забивать; дали молоток — забивают молотком; дали пневматический молоток — круто, работает пневмомолотком. Но я сомневаюсь, что этот гвоздезабиватель способен придумать (а это именно то, чего ты хочеш) обычный молоток, я уже молчу о пневмо. Максимум это заполировать камень.

Здравствуйте, 0xDEADBEEF, Вы писали:

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

Я например, кодга с C# знакомился, никак не мог отвыкнуть от привычек проектирования на Delphi. Принципы очень похожие, а реализация разная. В частности, слишком много надо вложенных классов в C# делать и нельзя — вложенные функции. Так я на Delphi в итоге и остался (C# по работе не нужен). (это я на жизнь жалуюсь).

Здравствуйте, Andrei N.Sobchuck, Вы писали:

FDS>> Мне интересны мнения не профессиональных исследователей, а того, кто на форуме. По моему они лучше могут понимать что надо делать.

ANS>Почему? Мне кажется, что большинство живёт так: дали камень, значит нужно чуток камень заполировать, чтоб ровная поверхность была, и гвозди камнем можно было забивать; дали молоток — забивают молотком; дали пневматический молоток — круто, работает пневмомолотком. Но я сомневаюсь, что этот гвоздезабиватель способен придумать (а это именно то, чего ты хочеш) обычный молоток, я уже молчу о пневмо. Максимум это заполировать камень.

Это уже философия не программирования. Вообще, пока по таким принципам большинство будет жить плохо нам будет.

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

Здравствуйте, Andrei N.Sobchuck, Вы писали:

FDS>> Мне интересны мнения не профессиональных исследователей, а того, кто на форуме. По моему они лучше могут понимать что надо делать.

ANS>Почему? Мне кажется, что большинство живёт так: дали камень, значит нужно чуток камень заполировать, чтоб ровная поверхность была, и гвозди камнем можно было забивать; дали молоток — забивают молотком; дали пневматический молоток — круто, работает пневмомолотком. Но я сомневаюсь, что этот гвоздезабиватель способен придумать (а это именно то, чего ты хочеш) обычный молоток, я уже молчу о пневмо. Максимум это заполировать камень.

А может, большинство не хочет изобретать молотовелосипед?

Здравствуйте, ukshish, Вы писали:

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

Ада довольно распространённый язык, в своих сферах.

Я как раз и хочу получить мнение коллег по поводу статистической информации. У меня в фирме всё просто — интерфейс Delphi, микроконтроллер — assembler, и можно не думать. Просто захотелось своё написать (ну, так в течении ближайших 20 лет ).

Здравствуйте, Cyberax, Вы писали:

C>FDSC wrote:

>> C>Скорее всего они:
>> C>1. Использовали малоопытных С++ников.
>> C>2. Использовали древнюю (даже для 1994г.) версию С++.
>> C>3. Пункты 2 и 1 вместе взятые.
>> Да, по поводу IDE они что-то странное написали. А вообще фрагмент, по
>> моему, правильный, по поводу ООП и C++. Может я это .. не понимаю в
>> программировании на C++ чего-то??? (я сам прогр. Delphi / assembler,
>> C++ только правлю и дополняю, и то не очень часто).

C>В чем в С++ проблема с runaway inheritance я не понимаю (вообще в первый
C>раз такой термин слышу), больше похоже, что их местные программисты
C>чего-то не так задизайнили.

C>Претензии к библиотеке контейнеров — тоже к себе пусть предъявляют.
C>Сейчас есть стандартная STL.

>> В любом случае я предлагаю сравнивать любые языки (хоть алгол-60).

C>Смысла нет.

Не понял по чему. Потому что мы — не разработчики компиляторов?? Давай станем

FDSC wrote:

> C>Претензии к библиотеке контейнеров — тоже к себе пусть предъявляют.
> C>Сейчас есть стандартная STL.
>>> В любом случае я предлагаю сравнивать любые языки (хоть алгол-60).
> C>Смысла нет.
> Не понял по чему. Потому что мы — не разработчики компиляторов?? Давай
> станем

Какие проблемы? Берешь GCC и пишешь к нему фронтенд для своего языка.
Получится компилируемый в маш. коды язык. Я так делал, кстати, без
особых трудностей.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

C>Какие проблемы? Берешь GCC и пишешь к нему фронтенд для своего языка.
C>Получится компилируемый в маш. коды язык. Я так делал, кстати, без
C>особых трудностей.


Извини, что такое GCC?
Сначало надо знать, что этой за зверь — свой язык, а потом уже писать что-то. Я уже 3 года со знакомыми программистами общаюсь, у каждого своё мнение по поводу удобств языков и IDE.

Потом, очень много требуется именно от IDE — по крайней мере разделение (действительно разделение, а не как сейчас) архитектуры, кода, обработки ошибок, проверок отладки. Система должна воспринимать недопустимую последовательность вызовов методов (например, деструктор раньше конструктора) и т.п.
Может это смешно делать, кодга половину всего этого сделала Microsoft (пусть даже не всё для других), но мне надоело писать на том, что не нравится, а MS никогда нормальный компилятор с моей точки зрения не выпустит. Можно конечно в NASA устроиться... .

Здравствуйте, FDSC, Вы писали:

FDS>Здравствуйте, Andrei N.Sobchuck, Вы писали:

FDS>>> Мне интересны мнения не профессиональных исследователей, а того, кто на форуме. По моему они лучше могут понимать что надо делать.

ANS>>Почему? Мне кажется, что большинство живёт так: дали камень, значит нужно чуток камень заполировать, чтоб ровная поверхность была, и гвозди камнем можно было забивать; дали молоток — забивают молотком; дали пневматический молоток — круто, работает пневмомолотком. Но я сомневаюсь, что этот гвоздезабиватель способен придумать (а это именно то, чего ты хочеш) обычный молоток, я уже молчу о пневмо. Максимум это заполировать камень.

FDS>Это уже философия не программирования.

Группа соответсвует

FDS>Вообще, пока по таким принципам большинство будет жить плохо нам будет.

Инноваций то очень мало в языках программирования. О чем это говорит?

FDS>Нужно проявлять активность. По моему опыту, пользователь всё-таки очень много полезных вещей знает. Очень много, только вынуть из него тяжело.

Это легко проверить. Вот ты пользователь компиляторы. Возьми и расскажи чего бы ты хотел /улучшить/.

Здравствуйте, Oyster, Вы писали:

O>А может, большинство не хочет изобретать молотовелосипед?
Чтобы появился 'ферари', нужно было чтобы кто-то изобрёл мотовелосипед, а история-таки предпочитает двигаться по спирали.

FDSC wrote:

> C>Какие проблемы? Берешь GCC и пишешь к нему фронтенд для своего языка.
> C>Получится компилируемый в маш. коды язык. Я так делал, кстати, без
> C>особых трудностей.
> Извини, что такое GCC?

GNU Compiler Collection (http://www.gcc.org/).

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

Кхм. Это должен быть не IDE, а язык.

> Может это смешно делать, кодга половину всего этого сделала Microsoft
> (пусть даже не всё для других), но мне надоело писать на том, что не
> нравится, а MS никогда нормальный компилятор с моей точки зрения не
> выпустит. Можно конечно в NASA устроиться... .

MS C++ 7.1 и MS C++ 8.0 — вполне приличные компиляторы.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Andrei N.Sobchuck, Вы писали:


ANS>Это легко проверить. Вот ты пользователь компиляторы. Возьми и расскажи чего бы ты хотел /улучшить/.

Отвечаю.

1. IDE снабжается системой создания автоматизированных заглушек для ещё ненаписанного кода. Это возможно:
1.1. Программист делает пометки несозданных функций в созданном коде — компилятор автоматически делает шаблон (это легко, можно сделать и как надстройку)
1.2. Компилятор рассматривает код, находя функции, выход которых не является корректным (т.е. объект разрушаеся или не создаётся, или т.п.). Далее идёт создание пустых шаблонов объектов, исходя из формальной безошибочности работы следующих функций.

2. IDE снабжается возможностью проектирования процесса разработки ПО: т.е. помагает программисту выявить последовательность разработки методов и классов приложения с учётом применения итеративной разработки.

3. IDE позволяет задавать граф возможных и запретных последовательностей вызовов методов (инциализация -> применение, create -> Init -> загрузка из сети данных пользователя -> .. но не наоборот ). Идёт контроль за обнулением инициализированных полей. Поля объекта можно делать константными в пределах блока кода (или наоборот, изменяемыми)

4. IDE реализует сам код, как граф. Названия методов даются как справочная информация для программиста, могут меняться автоматически. Различные участки графа кода могут быть использованы вне пределов функции, наподобие шаблонов С (только при этом речь идёт не о безразлии к классам, а о общем порядке следования команд в алгоритме для однотипных объектов). Например, метод-шаблон, позволяющий работать со всеми элементами некоторого сложного объекта-коллекции по очереди без явных циклов и т.п. (т.е. задаётся код работы с элементом и говорится, что выполнять для всех элементов, однако объект может быть любой сложности [какое-нибудь ВВ-дерево]). (не уверен, что могу сделать)

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

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

6. Библиотеки позволяют работать с приватными методами и полями в отдельных заявленных функциях других классов (а не во всём классе). (см. так же 3).

7. Компилятор позволяет работать низкоуровнево без использования ассемблера и с гарантией совместимости низкого кода с высоким (речь идёт об ограничении применения регистров CPU и т.п. в пределах работы низкого кода. Ограничениях для компилятора, а не для программиста).

Главное, это 4 и 5. Если я конечно смог правильно объяснить, что хочу. Это не всё. Что вспомнил.

Здравствуйте, Cyberax, Вы писали:


C>MS C++ 7.1 и MS C++ 8.0 — вполне приличные компиляторы.

Смотря для каких целей. Между прочим, Microsoft, NASA и т.п. не используют такие компиляторы, или используют их с существенными надстройками.

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

FDSC wrote:

> C>MS C++ 7.1 и MS C++ 8.0 — вполне приличные компиляторы.
> Смотря для каких целей. Между прочим, Microsoft, NASA и т.п. не
> используют такие компиляторы, или используют их с существенными
> надстройками.

Ха. Вы думаете Microsoft не использует собственный компилятор?

А в NASA используют GCC, или родной VxWorks'овский.

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

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

--
С уважением,
Alex Besogonov (alexy@izh.com)

FDSC wrote:

> ANS>Это легко проверить. Вот ты пользователь компиляторы. Возьми и
> расскажи чего бы ты хотел /улучшить/.
> /*Отвечаю.*/
> 1. IDE снабжается системой создания автоматизированных заглушек для
> ещё ненаписанного кода. Это возможно:
> 1.1. Программист делает пометки несозданных функций в созданном коде —
> компилятор автоматически делает шаблон (это легко, можно сделать и как
> надстройку)

Смотри IDEA (http://www.intellij.com/) или Eclipse
(http://www.eclipse.org) — там это есть уже много лет.

> 1.2. Компилятор рассматривает код, находя функции, выход которых не
> является корректным (т.е. объект разрушаеся или не создаётся, или
> т.п.). Далее идёт создание пустых шаблонов объектов, исходя из
> формальной безошибочности работы следующих функций.

Бессмысленно. Просто нужно разработать нормальную семантику
использования объектов (как в С++) или использовать GC и не иметь таких
проблем вообще.

> 2. IDE снабжается возможностью проектирования процесса разработки ПО:
> т.е. помагает программисту выявить последовательность разработки
> методов и классов приложения с учётом применения итеративной разработки.

Рефакторинг в IDEA, Eclipse, Reshaper.

> 3. IDE позволяет задавать граф возможных и запретных
> последовательностей вызовов методов (инциализация -> применение,
> create -> Init -> загрузка из сети данных пользователя -> .. но не
> наоборот ). Идёт контроль за обнулением инициализированных полей. Поля
> объекта можно делать константными в пределах блока кода (или наоборот,
> изменяемыми)

Нафиг такое не нужно, так как это принципиально невозможно проверить в
общем случае и, вдобавок, обходится грамотным проектированием.

> 4. IDE реализует сам код, как граф. Названия методов даются как
> справочная информация для программиста, могут меняться автоматически.

Было такое в Together и Rational Rose — успешно провалилось как
неудобное и неюзабельное решение.

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

Это в область DSL — сейчас она развивается достаточно активно.

> 6. Библиотеки позволяют работать с приватными методами и полями в
> отдельных заявленных функциях других классов (а не во всём классе).
> (см. так же 3).

А смысл?

> 7. Компилятор позволяет работать низкоуровнево без использования
> ассемблера и с гарантией совместимости низкого кода с высоким (речь
> идёт об ограничении применения регистров CPU и т.п. в пределах работы
> низкого кода. Ограничениях для компилятора, а не для программиста).

А нафиг??

Вообще, рекомендую выучить пару-тройку языков (например: С++, Java и
OCaml) — многие вопросы отпадут сами.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, FDSC, Вы писали:

FDS>Слышал, что при написании программ на C++ количество допущенных ошибок на порядок больше, чем при написании их же в "АДА", стоимость выше на 60% и т.п. (см. http://www.adaic.com/whyada/ada-vs-c/cada_art.html).

Ада давно устарела. Ява, Шарп, Васик (и другие управляемые языки), а так же некоторые типизированные функциональные языки обеспечивают не меньшую чем в Аде защиту при этом являсь полноценными и современными ООЯ.

С++ действительно приводит к большему числу ошибок в силу дизайна языка и требовкний совместимости с С. Тут этот вопрос обсуждался много араз.

FDS>Насколько буквально это понимать

Буквально и понимать. С++ имеет море возможностей приводящих к скрытию ошибок и к ошибкам второго порядка (наложенным... портишь память в одном месте, а программа падает в другом).

FDS> и почему C++ более распространён чем АДА? Переходим на АДА???

Ада это мертворожденное дитя. Она может и более надежна, но это откровенно тяжеловестный и неудобный язык программирования. С++ же является приемником С и на него переходила целая толпа С-шников которые хотели получить ОО-возможности.

FDS>Можно ли разработать ещё более экономичные языки?

А причем тут экономичность? Речь же шала о надежности и безопастности. Да и экономить можно разные. Можно экономить память, можно время программиста, а можно количество символов в исходном файле.

Если говорить о надежности, но управляемые языки и функциональные статически типизированные языки обладают довольно высокими показателями защищенности. При разработке на том же шарпе тратишь на отладку на порядок меньше времени чем программируя на С++.

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

Здравствуйте, FDSC, Вы писали:

FDS>1. По статистике (честно говоря, незнаю как это получается) количество ошибок не зависит от квалификации программиста (не помню откуда, могу поискать).

Чтобы понять, что это миф не нужно смотреть статистических сборников. Достаточно поглядеть на код написанный более опытным программистом и начинающим юнцом. Уверяю тебя, что не вооруженным взглядом будет видно, что юнец ошибается в сотни раз чаще и ошибки его в сотни раз банальнее.

Ошибки бывают разные. Бывают по невнимательности. И тут тоже у разных людей все по разному. Один более уситчев и делает меньше ошибок... Бывают просчеты дизайна. Тут (если вообще горректно говорить об умении программиста) все вообще зависит от опыта. Ну, и логические ошибки чаще появляются у менее опытных прграммистов.

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

FDS>3. Квалифицированный программист, который совершает в 10 раз меньше ошибок (см. пункт 1) стоит, наверное, во столько же раз дороже. Как же по поводу уменьшения стоимости разработки на Ада?

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

Здравствуйте, 0xDEADBEEF, Вы писали:

DEA>Здравствуйте, FDSC, Вы писали:

FDS>>http://www.adaic.com/whyada/ada-vs-c/cada_art.html.
DEA>Прочитал. КГ/АМ.

Здравствуйте, Cyberax, Вы писали:

C>FDSC wrote:

>> C>MS C++ 7.1 и MS C++ 8.0 — вполне приличные компиляторы.
>> Смотря для каких целей. Между прочим, Microsoft, NASA и т.п. не
>> используют такие компиляторы, или используют их с существенными
>> надстройками.

C>Ха. Вы думаете Microsoft не использует собственный компилятор?
Я сказал не использует, или с надстройками.

C>А в NASA используют GCC, или родной VxWorks'овский.
Откуда такие сведения?
В NASA вообще на данный момент используют автоматическую генерацию кода (90-97% автоматически).

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

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

Под компилятором в данном случае я подразумевал не только IDE, но и весь пакет программ Visual Studio или Delphi Studio.

Здравствуйте, Cyberax, Вы писали:

C>FDSC wrote:

>> ANS>Это легко проверить. Вот ты пользователь компиляторы. Возьми и
>> расскажи чего бы ты хотел /улучшить/.
>> /*Отвечаю.*/
>> 1. IDE снабжается системой создания автоматизированных заглушек для
>> ещё ненаписанного кода. Это возможно:
>> 1.1. Программист делает пометки несозданных функций в созданном коде —
>> компилятор автоматически делает шаблон (это легко, можно сделать и как
>> надстройку)

C>Смотри IDEA (http://www.intellij.com/) или Eclipse
C>(http://www.eclipse.org) — там это есть уже много лет.

насчёт IDEA не знаю, а то что легко я и написал из-за Eclipse.

---

>> 1.2. Компилятор рассматривает код, находя функции, выход которых не
>> является корректным (т.е. объект разрушаеся или не создаётся, или
>> т.п.). Далее идёт создание пустых шаблонов объектов, исходя из
>> формальной безошибочности работы следующих функций.

C>Бессмысленно. Просто нужно разработать нормальную семантику
C>использования объектов (как в С++) или использовать GC и не иметь таких
C>проблем вообще.

Не понял. Причём тут семантика? Имеются ввиду незаконченные функции и частичная отладка всего проекта без них.

---

>> 2. IDE снабжается возможностью проектирования процесса разработки ПО:
>> т.е. помагает программисту выявить последовательность разработки
>> методов и классов приложения с учётом применения итеративной разработки.

C>Рефакторинг в IDEA, Eclipse, Reshaper.

Жаль, не знаю. Спасибо, посмотрю (меня этому не учили, немного не та область).

---

>> 3. IDE позволяет задавать граф возможных и запретных
>> последовательностей вызовов методов (инциализация -> применение,
>> create -> Init -> загрузка из сети данных пользователя -> .. но не
>> наоборот ). Идёт контроль за обнулением инициализированных полей. Поля
>> объекта можно делать константными в пределах блока кода (или наоборот,
>> изменяемыми)

C>Нафиг такое не нужно, так как это принципиально невозможно проверить в
C>общем случае и, вдобавок, обходится грамотным проектированием.

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

Что значит "обходится грамотным проектированием"? Создавать полные графы естественно не нужно.
Часто встречаю ошибки типа: пользователь не инициализировал переменную и пытается с ней работать, связывается с микроконтроллером и пошёл (и не только это). Много проблем возникает из-за этого. А самому проверять нудно и трудно. Вот уж "обходится грамотным проектированием", наоборот, проектировать и проверять легче.

---

>> 4. IDE реализует сам код, как граф. Названия методов даются как
>> справочная информация для программиста, могут меняться автоматически.

C>Было такое в Together и Rational Rose — успешно провалилось как
C>неудобное и неюзабельное решение.

Не знаю Together, но в Rational Rose такого не было никогда. RR не позволял писать полномасштабный код как граф, среда вообще предназначена для UML-проектирования.

Между прочим, лично знаю людей, которые используют эти продукты.

Кстати, я ещё писал: "Код отбражается как граф, дерево или ещё что-нибудь удобное". А как же давнишние '+', позволяющие свернуть функции в MS VS.

Кстати в этом направлении сейчас есть движение — в частности, для UML-спроектированного приложения создаётся шаблон кода. Я, в том числе, и это имел ввиду.

---

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

C>Это в область DSL — сейчас она развивается достаточно активно.

Где почитать, подскажи!!!

---

>> 6. Библиотеки позволяют работать с приватными методами и полями в
>> отдельных заявленных функциях других классов (а не во всём классе).
>> (см. так же 3).

C>А смысл?

Смысл простой. В Delphi, например, вообще нельзя работать из другого класса с private-членами. Protected — только в текущем модуле. Допустим я хочу поправить (дополнить) чужой класс (в любом языке), зачем мне делать доступными приватные члены для всех методов, когда мне нужен, возможно, только один? Зря возможность ошибочного вызова делать.

---

>> 7. Компилятор позволяет работать низкоуровнево без использования
>> ассемблера и с гарантией совместимости низкого кода с высоким (речь
>> идёт об ограничении применения регистров CPU и т.п. в пределах работы
>> низкого кода. Ограничениях для компилятора, а не для программиста).

C>А нафиг??

Мне, например, надобилось.

Привожу примеры:
Один алгорит с 7 вложенными циклами Delphi компилирует так, что переписанный на asm работает в 7,5 раза быстрей, но при смене проекта всё заново писать приходиться. Муторно.

В RSDN непомню кто, писал про обёртку для вызова функций из внешний DLL. Для этого он написал 13 классов-шаблонов C++ — по одной на количество аргументов. Я видел решение его задачи на Delphi 2-мя функциями (с использованием asm). По моему так гораздо лучше.

C>Вообще, рекомендую выучить пару-тройку языков (например: С++, Java и
C>OCaml) — многие вопросы отпадут сами.

Я знаю нормально Dlephi, C++, assembler. Кстати, Java не так уж и отличается от C++ (программировал я на ней чуть-чуть, правда Eclipse сильно отличается от того, что мне приходилось видеть).

OCaml — никогда не слышал!!! Что это?

Выходит, Вас устраивают существующие компиляторы?

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, FDSC, Вы писали:

VD>Ада давно устарела. Ява, Шарп, Васик (и другие управляемые языки), а так же некоторые типизированные функциональные языки обеспечивают не меньшую чем в Аде защиту при этом являсь полноценными и современными ООЯ.

Не согласен. Приложения для систем управления на ней часто пишут. Защита, хорошо, а по поводу поддрежки многопоточности?
Кстати, что бы не быть голословным: Ада используется фирмой BEA.

---

VD>Буквально и понимать. С++ имеет море возможностей приводящих к скрытию ошибок и к ошибкам второго порядка (наложенным... портишь память в одном месте, а программа падает в другом).

Спасибо, понял.

FDS>> и почему C++ более распространён чем АДА? Переходим на АДА???

VD>Ада это мертворожденное дитя. Она может и более надежна, но это откровенно тяжеловестный и неудобный язык программирования. С++ же является приемником С и на него переходила целая толпа С-шников которые хотели получить ОО-возможности.

Незнаю, вообще, Ада-программисты говорят, что она хорошо читается. Хотя я думая иначе. Наверное это зависит от опыта программирования на Ада.

---

FDS>>Можно ли разработать ещё более экономичные языки?

VD>А причем тут экономичность? Речь же шала о надежности и безопастности. Да и экономить можно разные. Можно экономить память, можно время программиста, а можно количество символов в исходном файле.

Речь шла не только о надёжности, но и о времени и стоимости проектирования.

VD>Если говорить о надежности, то управляемые языки и функциональные статически типизированные языки обладают довольно высокими показателями защищенности. При разработке на том же шарпе тратишь на отладку на порядок меньше времени чем программируя на С++.

Видимо, это зависит от квалификации. Я слышал и другие мнения.

---

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

Об этом много пишут в учебниках, однако я таких ошибок никогда не встречал (видать простые программы были). По моему ошибки обычно больше логического характера возникают. Очень спорный вопрос.
Вообще, я пытался провести статистику ошибок у себя и некоторых знакомых и пришёл к выводу, что константность, приватность и контроль за преобразованием типов сами по себе исключают довольно малое количество ошибок (по крайней мере в Delhi, в С++ думаю ситуация такая же).

VD>С одной стороны ЯП проектируется так чтобы не допускать ошибок (до запуска программы на исполнение).

А можно допустить ошибки без запуска программы?? Синтаксические что-ли? Я не понял, поясните пожалуйста.

Простите, если несколько узко образован.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, FDSC, Вы писали:

FDS>>1. По статистике (честно говоря, незнаю как это получается) количество ошибок не зависит от квалификации программиста (не помню откуда, могу поискать).

VD>Чтобы понять, что это миф не нужно смотреть статистических сборников. Достаточно поглядеть на код написанный более опытным программистом и начинающим юнцом. Уверяю тебя, что не вооруженным взглядом будет видно, что юнец ошибается в сотни раз чаще и ошибки его в сотни раз банальнее.

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

VD>Ошибки бывают разные. Бывают по невнимательности. И тут тоже у разных людей все по разному. Один более уситчев и делает меньше ошибок... Бывают просчеты дизайна. Тут (если вообще горректно говорить об умении программиста) все вообще зависит от опыта. Ну, и логические ошибки чаще появляются у менее опытных прграммистов.

VD>В общем, там где опытный программист пару раз ошибется не опытный просто завалит проект.

Я думаю это связано больше с ошибками проектирования и уверенностью в себе.

FDS>>3. Квалифицированный программист, который совершает в 10 раз меньше ошибок (см. пункт 1) стоит, наверное, во столько же раз дороже. Как же по поводу уменьшения стоимости разработки на Ада?

VD>Проблема в том, что нельзя взять миллион обезьян и заставить написать их сложный софт. К тому же есть очень отвественные задачи в которых стоимость ошибки очень велика. Тут защищенные языки и рантаймы позволяют понизить вероятность ошибки и, стало быть, снизить риски и стоимость.

Ну, получается, что если Ада такая нечитаемая и вообще, мертворождённая, то программисты должны стоить дорого и проект то же. Я и спрашиваю: как так?

VD>Кстати, одна ошибка на той самой Аде привела к потере ракетоносителя со спутником на борту.

Всяко бывает.
По моему мы несколько ушли от темы.

Здравствуйте, FDSC, Вы писали:

FDS>В общем-то да. Кстати, по этой же статистике, ошибки опытных программистов труднее искать. В любом случае статистика действительно очень странная.

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

FDS>Я думаю это связано больше с ошибками проектирования и уверенностью в себе.

Возможно. Весма возможно.

FDS>Ну, получается, что если Ада такая нечитаемая и вообще, мертворождённая, то программисты должны стоить дорого и проект то же. Я и спрашиваю: как так?

Ада и стоит не мало. На столько не мало, что по сравнению с менее одиозными языками вроде Шарпа или Явы еще бабушка на двое скажет что дешевле. Но по сравнению с С++ кое что есть. Все же Ада позволяет с высокой долей увереннсоти говорить о корректности. А С++ — это надежда на крутость программиста и вера в проведение.

VD>>Кстати, одна ошибка на той самой Аде привела к потере ракетоносителя со спутником на борту.

FDS>Всяко бывает.
FDS>По моему мы несколько ушли от темы.

Да, нет. Это все к вопросу о цене ошибки. Если одна ошибка стоит миллионы долларов. То применение С++ в таких проектах — это по хлеще чем топка помещений ассигнациями.

Здравствуйте, FDSC, Вы писали:

FDS>Не согласен. Приложения для систем управления на ней часто пишут.

Часто? А где статистика?

FDS> Защита, хорошо, а по поводу поддрежки многопоточности?

Тут безусловно рулят функциональные языки. А Ада нервно курит. Причем по бональным соображениям. В ФЯ легко достигается неблокирующий режим работы. Так что контролировать нечего. А учитывая отсуствие побочных эффектов у функций распараллеливание становится намного более простой задачей.

FDS>Кстати, что бы не быть голословным: Ада используется фирмой BEA.

Это что тукседо пишут?

FDS>Незнаю, вообще, Ада-программисты говорят, что она хорошо читается. Хотя я думая иначе. Наверное это зависит от опыта программирования на Ада.

Ада не является полноценным ООЯ. По сему полноценное программирование в ней затруднено. Обобщенное программирование в ней тоже не сахар. В общем, защищенность в ней конечно на уровне. Но в остльном — это продукт концелярского мышления.

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

FDS>Речь шла не только о надёжности, но и о времени и стоимости проектирования.

Э... Что толку от времени проектирования если ты заранее обречен играть в угадайку в отношении надежности? Ада была разработана как надежный язык. В ней куча защит и т.п. Но скорость проектирования... тут она пожалуй не лучший выбор. В общем, выбор Ады — это выбор брони. Да ехать будешь не быстро, но доедишь в целости (с большой долей вероятности). А писать однозначно лучше на более современных языках.

VD>>Если говорить о надежности, то управляемые языки и функциональные статически типизированные языки обладают довольно высокими показателями защищенности. При разработке на том же шарпе тратишь на отладку на порядок меньше времени чем программируя на С++.

FDS>Видимо, это зависит от квалификации. Я слышал и другие мнения.

Все в этой жизни зависит от квалификации. А мнений бывает очень много. Причем большинство из них диамитрально-противоположенные.

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

Ну, если ты не встречал такие ошибки, то с вероятностью в 99% ты просто имешь малый опыт. Ну, или ты крут как вареные яйца. У тех же парней из МС или тех что делают Линуксы и т.п. подобных проблем хоть отбавляй. От банальных AV, до переполнений буферов. В общем игра в усидчивость на гигабайтах кода.

FDS>Вообще, я пытался провести статистику ошибок у себя и некоторых знакомых и пришёл к выводу, что константность, приватность и контроль за преобразованием типов сами по себе исключают довольно малое количество ошибок (по крайней мере в Delhi, в С++ думаю ситуация такая же).

Интересно было бы посмотреть на эту статистику. Я так просто пользуюсь контролем типов как железным щитом. Любой серьезный рефакторинг в конце концов заканчивается подправкой ошбок компиляции которые на 90% выливаются в ошибки связанные с типами. Более того. Стараюсь проектировать все так, чтобы ошибки как можно чаще выливались в ошибки типов ловимые компилятором.

VD>>С одной стороны ЯП проектируется так чтобы не допускать ошибок (до запуска программы на исполнение).

FDS>А можно допустить ошибки без запуска программы??

Легко. Чем больше контроль компилятора. И чем более грамотно проектируется ПО, тем больше ошибок вылавливается еще до стадии отладки.

FDS> Синтаксические что-ли? Я не понял, поясните пожалуйста.

Синтаксис, семантика. Это очень не мало. Если ты умешь грамотно формулировать мысли, то семантический контроль позволяет отлавливать очень много ошибок.

Прстой пример из недавнего опыта. Представь себе редактор у которого есть представление данных в документе, и представление данных во View. И там, и там хронятся строки. Но в первом случае они хранятся просто так, а во втором перенесенными на страницу. Так вот если хранить их как строка/символ в строке в обоих случаях и не разделять тиы, то ошибочно посунув вместо индекса перенесенной линии индекс линии из документа ты будешь долго ловить ошибку в отладчие. Если же ввести понятие виртуальных и реальных координат, то контроль за правильностью действий возмет на себя компилятор. Другими словами грамотное проектирование переносит отвественность за качество на безошибочный компилятор. Так что даже на не супер идельном ЯП можно существенно улучшить защищенность программы, а стало быть уменьшить время затрачиваемое на отладку, и ускорить поизводство ПО. А есди сам язык и рантайм помогают тебе держать типы в целости и сохранности, твоя задача существенно упрощается.

Здравствуйте, FDSC, Вы писали:

FDS>Извини, что такое GCC?

GCC — это С++-компилятор созданный на базе открытого фронтэнда ГНУ.

FDS>Сначало надо знать, что этой за зверь — свой язык, а потом уже писать что-то. Я уже 3 года со знакомыми программистами общаюсь, у каждого своё мнение по поводу удобств языков и IDE.

Извини, но похоже ты пересидел с Дельфи. Тебе нужно изучить мир за пределами Борланда. IDE это всего лишь инструмент. И Борланд на сегодны далеко не законодатель мод.

FDS>Потом, очень много требуется именно от IDE — по крайней мере разделение (действительно разделение, а не как сейчас) архитектуры, кода, обработки ошибок, проверок отладки.

А как сейчас где?

FDS> Система должна воспринимать недопустимую последовательность вызовов методов (например, деструктор раньше конструктора) и т.п.

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

FDS>Может это смешно делать, кодга половину всего этого сделала Microsoft (пусть даже не всё для других), но мне надоело писать на том, что не нравится, а MS никогда нормальный компилятор с моей точки зрения не выпустит. Можно конечно в NASA устроиться... .

Нда. Ты еще и пары компиляторов МС не видел, а уже судишь и столь котигорично. Поверь на слово. МС один из лидеров в компиляторостроении. Есть конечно и другие лидеры. У них есть достойные продукты. Но компиляторы МС — это очень и очень достойные родукты.

Здравствуйте, FDSC, Вы писали:

C>>MS C++ 7.1 и MS C++ 8.0 — вполне приличные компиляторы.

FDS>Смотря для каких целей. Между прочим, Microsoft, NASA и т.п. не используют такие компиляторы, или используют их с существенными надстройками.

Да? Ну, насса использует черта лысого. С ним отдельно. А на чем по-твоему пишутся продукты МС? И какие-такие надстройки используют в МС?

FDS>Компиляторы приличные, да вот нехватает их возможностей. (см. выше написал сообщение с заголовком "Предложения по улучшению"). Не приятно на них программировать (если конечно сроки поставлены и начинаешь нервничать).

Ты бы луче ссылку дал.

Здравствуйте, FDSC, Вы писали:

FDS>Под компилятором в данном случае я подразумевал не только IDE, но и весь пакет программ Visual Studio или Delphi Studio.

Завязывай ты с Дельфи. А то не равен час под компилятором начнешь понимать редактор кода и комплит-ворд.

FDSC wrote:

> C>Ха. Вы думаете Microsoft не использует собственный компилятор?
> Я сказал не использует, или с *надстройками*.

Не используют они никаких настроек. Вся Винда сейчас у них компилируется
на VC7.1, старые версии Винды (до XP SP2) компилируются на VC6.

> C>А в NASA используют GCC, или родной VxWorks'овский.
> Откуда такие сведения?

http://www.windriver.com/ Кроме того, сами насовцы достаточно много
писали о Роверах и спутниках.

> В NASA вообще на данный момент используют автоматическую генерацию
> кода (90-97% автоматически).

С чего бы это? Чтобы код генерировать нужно иметь:
1. Генератор
2. Шаблоны

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

> C>Часть возможностей просто не нужна для нормального языка, а другая
> часть
> C>должна быть в IDE, а не компиляторе.
> Под компилятором в данном случае я подразумевал не только IDE, но и
> весь пакет программ Visual Studio или Delphi Studio.

А, ну понятно — наследие Delphi. Нужно различать: язык, компилятор с
данного языка и IDE для данного языка.

--
С уважением,
Alex Besogonov (alexy@izh.com)

FDSC wrote:

> VD>Ада давно устарела. Ява, Шарп, Васик (и другие управляемые языки),
> а так же некоторые типизированные функциональные языки обеспечивают не
> меньшую чем в Аде защиту при этом являсь полноценными и современными ООЯ.
> Не согласен. Приложения для систем управления на ней часто пишут.
> Защита, хорошо, а по поводу поддрежки *многопоточности*?

Давно уже есть везде. А что в этом такого суперэкзотичного?

Есть еще и специализированые решения для очень многопоточных приложений:
ACE (Adaptive Communication Environment), язык Erlang и т.п.

> Кстати, что бы не быть голословным: Ада используется фирмой BEA.

BEA сейчас в основном продает WebLogic, написаный на Java.

> VD>С одной стороны ЯП проектируется так чтобы не допускать ошибок (до
> запуска программы на исполнение).
> А можно допустить ошибки без запуска программы?? Синтаксические
> что-ли? Я не понял, поясните пожалуйста.

Естественно Все ошибки в программе закладываются во время ее
написания. Задача компилятора — помочь их выловить еще на этапе компиляции.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

>> 4. IDE реализует сам код, как граф. Названия методов даются как
>> справочная информация для программиста, могут меняться автоматически.

C>Было такое в Together и Rational Rose — успешно провалилось как
C>неудобное и неюзабельное решение.

очень интересно. а можно подробнее?

FDSC wrote:

>>> 1.2. Компилятор рассматривает код, находя функции, выход которых не
>>> является корректным (т.е. объект разрушаеся или не создаётся, или
>>> т.п.). Далее идёт создание пустых шаблонов объектов, исходя из
>>> формальной безошибочности работы следующих функций.
> C>Бессмысленно. Просто нужно разработать нормальную семантику
> C>использования объектов (как в С++) или использовать GC и не иметь таких
> C>проблем вообще.
> Не понял. Причём тут семантика? Имеются ввиду незаконченные функции и
> частичная отладка всего проекта без них.

Это я про деструкторы — в нормальных языках они вызываются почти всегда
автоматически, а в других языках деструкторов нет вообще. Простейшие
ошибки типа _возможного_ обращения по нулевому указателю давно умеют
отслеживать статические верефикаторы в C#/Java.

>>> 3. IDE позволяет задавать граф возможных и запретных
>>> последовательностей вызовов методов (инциализация -> применение,
>>> create -> Init -> загрузка из сети данных пользователя -> .. но не
>>> наоборот ). Идёт контроль за обнулением инициализированных полей. Поля
>>> объекта можно делать константными в пределах блока кода (или наоборот,
>>> изменяемыми)
> C>Нафиг такое не нужно, так как это принципиально невозможно проверить в
> C>общем случае и, вдобавок, обходится грамотным проектированием.
> Не понял, что нельзя проверить в общем случае?

Что последовательность вызовов будет нужно.

> Если речь идёт о действиях внешних субъектов, то система всё равно
> должна блокировать вызовы запрещённых методов, какие-бы эти действия
> не были. А если порядок вызовов методов нельзя предусмотреть заранее,
> значит нужно их реализовывать соответствующим образом; тогда их и
> проверять не надо и в граф заносить то же.

Принципиально нельзя построить статический граф вызовов методов с
временными метками (могу даже доказательство привести).

> Что значит "обходится грамотным проектированием"? Создавать полные
> графы естественно не нужно.
> Часто встречаю ошибки типа: пользователь не инициализировал переменную
> и пытается с ней работать, связывается с микроконтроллером и пошёл (и
> не только это). Много проблем возникает из-за этого. А самому
> проверять нудно и трудно. Вот уж "обходится грамотным
> проектированием", наоборот, проектировать и проверять легче.

Смотри С++, а именно идиому RAII — Resource Acquisition Is
Initialization и smart pointer'ы. То есть для работы с микроконтроллером
нужно взять на него хэндл, в конструкторе которого производится нужная
предварительная инициализация.

> C>Было такое в Together и Rational Rose — успешно провалилось как
> C>неудобное и неюзабельное решение.
> Не знаю Together, но в Rational Rose такого не было никогда. RR не
> позволял писать полномасштабный код как граф, среда вообще
> предназначена для UML-проектирования.

Позволяет, причем в RR можно писать полностью весь код. Году в 2000 я
пробовал применить это на практике сначала на RR, потом на Together.
Результат такой — уж проще руками все писать.

> Кстати в этом направлении сейчас есть движение — в частности, для
> UML-спроектированного приложения создаётся шаблон кода. Я, в том
> числе, и это имел ввиду.

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

> C>Это в область DSL — сейчас она развивается достаточно активно.
> Где почитать, подскажи!!!

Отсюда http://en.wikipedia.org/wiki/Domain-specific_language и по ссылкам.

> C>А смысл?
> Смысл простой. В Delphi, например, вообще нельзя работать из другого
> класса с private-членами. Protected — только в текущем модуле.
> Допустим я хочу поправить (дополнить) чужой класс (в любом языке),
> зачем мне делать доступными приватные члены для всех методов, когда
> мне нужен, возможно, только один? Зря возможность ошибочного вызова
> делать.

В С++ есть механизм friend'ов, который позволяет открыть приватные члены
для избранных классов или функций. Хотя необходимость использования
такого механизма показывает на неправильное проектирование — другой
класс не должен лезть в приватные данные класса.

> C>А нафиг??
> Мне, например, надобилось.
> Привожу примеры:
> Один алгорит с 7 вложенными циклами Delphi компилирует так, что
> переписанный на asm работает в 7,5 раза быстрей, но при смене проекта
> всё заново писать приходиться. Муторно.

И что? Выносите ассемблер в отдельные файлы, компилируйте отдельным
ассемблером, а потом линкуйте в проект.

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

> В RSDN непомню кто, писал про обёртку для вызова функций из внешний
> DLL. Для этого он написал 13 классов-шаблонов C++ — по одной на
> количество аргументов. Я видел решение его задачи на Delphi 2-мя
> функциями (с использованием asm). По моему так гораздо лучше.

В С++ можно вызывать функции из DLL без всяких "оберток". Скорее всего
требовалось что-то другое (типа делегатов или хука).

> C>Вообще, рекомендую выучить пару-тройку языков (например: С++, Java и
> C>OCaml) — многие вопросы отпадут сами.
> Я знаю нормально Dlephi, C++, assembler. Кстати, Java не так уж и
> отличается от C++ (программировал я на ней чуть-чуть, правда Eclipse
> сильно отличается от того, что мне приходилось видеть).
> OCaml — никогда не слышал!!! Что это?

Функциональный язык, достаточно популярный: http://www.ocaml.org

> Выходит, Вас устраивают существующие компиляторы?

Да. Естественно, место для улучшений есть, но ничего принципиально
нового не хочется.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Дарней wrote:

>>> 4. IDE реализует сам код, как граф. Названия методов даются как
>>> справочная информация для программиста, могут меняться автоматически.
> C>Было такое в Together и Rational Rose — успешно провалилось как
> C>неудобное и неюзабельное решение.
> очень интересно. а можно подробнее?

А чего особого? Рисовалась диаграмма классов, к методам делались
аннотации в виде их кода (можно еще было их генерировать из диаграммы
состояний). Работало все криво и неудобно.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, VladD2, Вы писали:

VD>Завязывай ты с Дельфи. А то не равен час под компилятором начнешь понимать редактор кода и комплит-ворд.

Не могу, работа такая

Может, посветуете что-нибудь то же (для изучения).

Здравствуйте, VladD2, Вы писали:


VD>Извини, но похоже ты пересидел с Дельфи. Тебе нужно изучить мир за пределами Борланда. IDE это всего лишь инструмент. И Борланд на сегодны далеко не законодатель мод.

Согласен. Только не знаю, кто законодатель.

FDS>>Потом, очень много требуется именно от IDE — по крайней мере разделение (действительно разделение, а не как сейчас) архитектуры, кода, обработки ошибок, проверок отладки.

VD>А как сейчас где?

Не понял. Не видел ещё кода (и не слышал, наверное по неопытности), где совершенно отдельно хранится сам код и проверки ошибок к нему. По поводу средств проверок, согласен, хранятся отдельно.

FDS>> Система должна воспринимать недопустимую последовательность вызовов методов (например, деструктор раньше конструктора) и т.п.

VD>Открою тебе сикрет. В передовых на сегодня технологиях уже давно отказываются от самого понятия деструктора. А ручной вызов уже давно считается чем-то не приличным.

Если по поводу .NET — заню. Это был только пример. Не встречал ошибок, где деструктор вызывается перед конструктором.

VD>Нда. Ты еще и пары компиляторов МС не видел, а уже судишь и столь котигорично. Поверь на слово. МС один из лидеров в компиляторостроении. Есть конечно и другие лидеры. У них есть достойные продукты. Но компиляторы МС — это очень и очень достойные родукты.

Как раз два компилятора я видел: MS VS 6 Standard Architect и MS VS .NET 2003 EA.
Причём на 6-ой пришлось попрограммиовать. .NET конечно гораздо лучше.

Вы меня убедили... я ничего не знаю

>
>>В RSDN непомню кто, писал про обёртку для вызова функций из внешний
>>DLL. Для этого он написал 13 классов-шаблонов C++ — по одной на
>>количество аргументов. Я видел решение его задачи на Delphi 2-мя
>>функциями (с использованием asm). По моему так гораздо лучше.
>
>
> В С++ можно вызывать функции из DLL без всяких "оберток". Скорее всего
> требовалось что-то другое (типа делегатов или хука).
>
Кажется, всё было именно простейшей обёрткой для функции, динамически
находимой по названию.

Здравствуйте, Cyberax, Вы писали:

C>http://www.windriver.com/ Кроме того, сами насовцы достаточно много
C>писали о Роверах и спутниках.

>> В NASA вообще на данный момент используют автоматическую генерацию
>> кода (90-97% автоматически).

C>С чего бы это? Чтобы код генерировать нужно иметь:
C>1. Генератор
C>2. Шаблоны

C>Отладка обоих может быть намного дороже написания кода вручную.

Уже есть. Прочитал перевод статьи "NASA's Mission Reliable", Patrik Regan, Scott Hamilton, IEEE Computer, jan 2004. Впрочем, они не из NASA. Ссылку дать не могу .

C>А, ну понятно — наследие Delphi. Нужно различать: язык, компилятор с
C>данного языка и IDE для данного языка.

Различаю, этому меня точно учили. Это была терминологическая неточность, виноват, исправлюсь. Однако написать слово "компилятор" несколько проще, чем объяснять, что имеешь в виду целый пакет программ разработки (который не входит в IDE). В любом случае — уже не по теме.

Лучше предложи что-нибудь своё — а я отыграюсь .

Здравствуйте, Cyberax, Вы писали:


C>А чего особого? Рисовалась диаграмма классов, к методам делались
C>аннотации в виде их кода (можно еще было их генерировать из диаграммы
C>состояний). Работало все криво и неудобно.

Это не то, о чём я говорил. Работает это действительно не самым лучшим образом, но скорее от неудачной реализации.

FDSC wrote:

> C>Отладка обоих может быть намного дороже написания кода вручную.
> Уже есть. Прочитал перевод статьи "NASA's Mission Reliable", Patri*c*k
> Regan, Scott Hamilton, IEEE Computer, jan 2004. Впрочем, они не из
> NASA. Ссылку дать не могу .

Вот она: http://www.computer.org/computer/homepage/0104/Regan/

Они используют не генерацию, а автоматическое выделение модели кода, с
последующей формальной верефикацией:

This application proved a few important claims for the technology,
including that it could extract models from source code automatically.

> C>А, ну понятно — наследие Delphi. Нужно различать: язык, компилятор с
> C>данного языка и IDE для данного языка.
> Различаю, этому меня точно учили. Это была терминологическая
> неточность, виноват, исправлюсь. Однако написать слово "компилятор"
> несколько проще, чем объяснять, что имеешь в виду целый пакет программ
> разработки (который не входит в IDE). В любом случае — уже не по теме.

Однако, это очень большая разница. Тут большинство под словом
"компилятор" все же понимают именно компилятор в отдельности, а среду
разработки+компилятор называют IDE.

> Лучше предложи что-нибудь своё — а я отыграюсь .

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

--
С уважением,
Alex Besogonov (alexy@izh.com)

FDSC wrote:

> C>А чего особого? Рисовалась диаграмма классов, к методам делались
> C>аннотации в виде их кода (можно еще было их генерировать из диаграммы
> C>состояний). Работало все криво и неудобно.
> Это не то, о чём я говорил. Работает это действительно не самым лучшим
> образом, но скорее от неудачной реализации.

За 10 лет развития UML так ничего удачного и не предложили, так что
можно про этот подход забыть. Кстати, до UMLя тоже были попытки
графического представления программ (с тем же результатом).

--
С уважением,
Alex Besogonov (alexy@izh.com)

raskin wrote:

>> В С++ можно вызывать функции из DLL без всяких "оберток". Скорее всего
>> требовалось что-то другое (типа делегатов или хука).
> Кажется, всё было именно простейшей обёрткой для функции, динамически
> находимой по названию.

А шаблоны были взяты из Loki, скорее всего. Тогда ничего удивительного —
в С++ нету динамческой диспетчеризации, а в Дельфи она есть.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, FDSC, Вы писали:

FDS>>Не согласен. Приложения для систем управления на ней часто пишут.

VD>Часто? А где статистика?

Нет статистики. Привожу примеры: система управления поездами линии метро Парижского метрополитена; автоматизированная станция документальной связи Мин. Обороны РФ; ПО спускаемого аппарата Beagle 2 европейской станции Mars Express.

FDS>> Защита, хорошо, а по поводу поддрежки многопоточности?

VD>Тут безусловно рулят функциональные языки. А Ада нервно курит. Причем по бональным соображениям. В ФЯ легко достигается неблокирующий режим работы. Так что контролировать нечего. А учитывая отсуствие побочных эффектов у функций распараллеливание становится намного более простой задачей.



FDS>>Кстати, что бы не быть голословным: Ада используется фирмой BEA.

VD>Это что, тукседо пишут?

Ошибся с названием фирмы. BAE. Виноват.

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

VD>Ну, если ты не встречал такие ошибки, то с вероятностью в 99% ты просто имешь малый опыт. Ну, или ты крут как вареные яйца. У тех же парней из МС или тех что делают Линуксы и т.п. подобных проблем хоть отбавляй. От банальных AV, до переполнений буферов. В общем игра в усидчивость на гигабайтах кода.

С вероятностью 0.99 я программирую в другой области (ну, опыт, в общем, то же не очень). По поводу переполнений буферов: по моему это как раз к логическим ошибкам на этапе алгоритмизации, и очень серьёзным. AV — это Access Violation? Туда же.



FDS>>Вообще, я пытался провести статистику ошибок у себя и некоторых знакомых и пришёл к выводу, что константность, приватность и контроль за преобразованием типов сами по себе исключают довольно малое количество ошибок (по крайней мере в Delhi, в С++ думаю ситуация такая же).

VD>Интересно было бы посмотреть на эту статистику. Я — так просто пользуюсь контролем типов как железным щитом. Любой серьезный рефакторинг в конце концов заканчивается подправкой ошбок компиляции которые на 90% выливаются в ошибки связанные с типами. Более того. Стараюсь проектировать все так, чтобы ошибки как можно чаще выливались в ошибки типов, ловимые компилятором.

Я только пытался её провести (статистику). Такая чушь получилась, если честно, не хочеться показывать, обсмеёте.
По поводу ошибок с типами — я стараюсь проектировать всё так, что бы преобразований типов не было вообще (с Вашей точки зения это, я думаю, неправильно).

Интересно, как я отловлю с помощью преобразования типов ошибку в коде построения сетевого графика, или в численном интегрировании краевой задачи (долго, помню, с ней мучился)? Нет уж, тут сидеть скорее над комментариями надо — чтоб без всяких верификаций несоответствие кода мат. алгоритму было понятно. И вообще, чтоб было понятно какому алгоритму.

VD>Синтаксис, семантика. Это очень не мало. Если ты умешь грамотно формулировать мысли, то семантический контроль позволяет отлавливать очень много ошибок.

Согласен, особенно Warnings помогают, процентов 50 ошибок отлавливают, причём довольно трудно находимых. Однако не все ошибки.

Ещё чуть-чуть и Вы от меня мокрого места не оставите. Предложите своё. Посмеюсь.

Здравствуйте, Cyberax, Вы писали:

C>За 10 лет развития UML так ничего удачного и не предложили, так что
C>можно про этот подход забыть. Кстати, до UMLя тоже были попытки
C>графического представления программ (с тем же результатом).

Не согласен.

FDS>Здравствуйте, VladD2, Вы писали:


VD>>Тут безусловно рулят функциональные языки. А Ада нервно курит. Причем по бональным соображениям. В ФЯ легко достигается неблокирующий режим работы. Так что контролировать нечего. А учитывая отсуствие побочных эффектов у функций распараллеливание становится намного более простой задачей.

www.embedded.com/story/OEG20021211S0034
Взял остюда пример. По моему Ада вообще не курит. Курят Яву.

Listing 1 An Ada multitasking program

1 with Ada.Text_IO;
2 procedure Tasking_Example is
3 Finished : Boolean := False;
4 pragma Atomic(Finished);
5
6 task Outputter; -- task specification
7
8 task body Outputter is -- task body
9 Count : Integer := 1;
10 begin
11 while not Finished loop
12 Ada.Text_IO.Put_Line(Integer'Image(Count));
13 Count := Count + 1;
14 delay 1.0; -- one second
15 end loop;
16 Ada.Text_IO.Put_Line("Terminating");
17 end Outputter;
18
19 begin
20 delay 20.0; -- twenty seconds
21 Finished := True;
22 end Tasking_Example;

Ладно, убедили: Аду на свалку, мне — подучить языки.

Но своё то можно предложить. Как улучшить языки, почему C# лучше C++ (это к VladD2) и т.п.

Считаю, что дальнейшее сравнительное обсуждение конкретных языков Ада и C++ не приведёт ни к чему. Просто тут Аду некому защищать (профессионально), надо адвоката.

FDSC wrote:

> VD>Часто? А где статистика?
> Нет статистики. Привожу примеры: система управления поездами линии
> метро Парижского метрополитена; автоматизированная станция
> документальной связи Мин. Обороны РФ; ПО спускаемого аппарата Beagle 2
> европейской станции Mars Express.

Beagle 2 лучше было не приводить в пример.

--
С уважением,
Alex Besogonov (alexy@izh.com)

FDSC wrote:

> VD>>Тут безусловно рулят функциональные языки. А Ада нервно курит.
> Причем по бональным соображениям. В ФЯ легко достигается неблокирующий
> режим работы. Так что контролировать нечего. А учитывая отсуствие
> побочных эффектов у функций распараллеливание становится намного более
> простой задачей.
> www.embedded.com/story/OEG20021211S0034
> <http://www.embedded.com/story/OEG20021211S0034&gt;
> Взял остюда пример. По моему Ада вообще не курит. Курят Яву.
> Listing 1 An Ada multitasking program

Обычная многотредовая программа, на С++/C#/Java будет выглядеть примерно
так же (с точностью до синтаксиса). _Абсолютно_ другой подход к
многопоточности можно посмотреть в языке Erlang
(http://en.wikipedia.org/Erlang):

Pid = spawn(Mod, Func, Args)     % execute function Func as new thread

Pid ! a_message      % send message to the thread (asynchronously)

receive       % receive message sent to this thread
  a_message -> do_something
end.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

C>За 10 лет развития UML так ничего удачного и не предложили, так что
C>можно про этот подход забыть. Кстати, до UMLя тоже были попытки
C>графического представления программ (с тем же результатом).

Ну это ты зря. Текущие проблемы — это только проблемы кривых реализаций

Здравствуйте, VladD2, Вы писали:

VD>Интересно было бы посмотреть на эту статистику. Я так просто пользуюсь контролем типов как железным щитом. Любой серьезный рефакторинг в конце концов заканчивается подправкой ошбок компиляции которые на 90% выливаются в ошибки связанные с типами. Более того. Стараюсь проектировать все так, чтобы ошибки как можно чаще выливались в ошибки типов ловимые компилятором.

Кстати, при знакомстве со SmallTalk меня больше всего вырубило, что его авторы считают этот механизм ненужным. Там всё на этапе исполнения проверяется.

VD> И там, и там хронятся строки. Но в первом случае они хранятся просто так, а во втором перенесенными на страницу. Так вот если хранить их как строка/символ в строке в обоих случаях и не разделять тиы, то ошибочно посунув вместо индекса перенесенной линии индекс линии из документа ты будешь долго ловить ошибку в отладчие. Если же ввести понятие виртуальных и реальных координат, то контроль за правильностью действий возмет на себя компилятор.

Во-во. Влад, может быть ты знаешь языки, в которых можно без написания множества строк кода сказать: "у меня будет тип НомерСимволаВСтроке, ведёт себя совсем как int, только это совсем другой тип и использовать один вместо другого нельзя"? В горячо мною любимом C++ для этого надо определить класс и все операции вручную. В Java не лучше. Но хоть где-нибудь-то можно?!

Здравствуйте, tarkil, Вы писали:

T>Во-во. Влад, может быть ты знаешь языки, в которых можно без написания множества строк кода сказать: "у меня будет тип НомерСимволаВСтроке, ведёт себя совсем как int, только это совсем другой тип и использовать один вместо другого нельзя"? В горячо мною любимом C++ для этого надо определить класс и все операции вручную. В Java не лучше. Но хоть где-нибудь-то можно?!
В Аде можно

tarkil wrote:
> Здравствуйте, VladD2, Вы писали:
>
> VD>Интересно было бы посмотреть на эту статистику. Я так просто пользуюсь контролем типов как железным щитом. Любой серьезный рефакторинг в конце концов заканчивается подправкой ошбок компиляции которые на 90% выливаются в ошибки связанные с типами. Более того. Стараюсь проектировать все так, чтобы ошибки как можно чаще выливались в ошибки типов ловимые компилятором.
>
> Кстати, при знакомстве со SmallTalk меня больше всего вырубило, что его авторы считают этот механизм ненужным. Там всё на этапе исполнения проверяется.
>
> VD> И там, и там хронятся строки. Но в первом случае они хранятся просто так, а во втором перенесенными на страницу. Так вот если хранить их как строка/символ в строке в обоих случаях и не разделять тиы, то ошибочно посунув вместо индекса перенесенной линии индекс линии из документа ты будешь долго ловить ошибку в отладчие. Если же ввести понятие виртуальных и реальных координат, то контроль за правильностью действий возмет на себя компилятор.
>
> Во-во. Влад, может быть ты знаешь языки, в которых можно без написания множества строк кода сказать: "у меня будет тип НомерСимволаВСтроке, ведёт себя совсем как int, только это совсем другой тип и использовать один вместо другого нельзя"? В горячо мною любимом C++ для этого надо определить класс и все операции вручную. В Java не лучше. Но хоть где-нибудь-то можно?!

Вопрос не мне, но всё же: чем не паскалевский древний

type MyType=type OldGoodType;

Для Integer — пойдёт на ура, насколько я помню.
Может быть у fpc это можно заставить корректно работать с объектами

Здравствуйте, FDSC, Вы писали:

FDS>Может, посветуете что-нибудь то же (для изучения).

Набор стандартный. Для расширения кругозора хорошо изучить:
1. Дотнет/Яву (а лучше обе технологии).
2. Какой-нибудь функциональный язык.
3. С++. Если не доводить его изучение до форм религии, очень помогает.

Здравствуйте, Cyberax, Вы писали:

C>Не используют они никаких настроек. Вся Винда сейчас у них компилируется
C>на VC7.1, старые версии Винды (до XP SP2) компилируются на VC6.

Сдается мне, что на VC6 компилировалась NT 4. А винды компилируются на чем попалао (например, на исследовательских версиях компиляторов). Ну, а релизы винды компилируются на текущем релизе VC. Хотя тут я ничего утверждать не могу. Это только догадки.

Здравствуйте, FDSC, Вы писали:

FDS>Различаю, этому меня точно учили. Это была терминологическая неточность, виноват, исправлюсь. Однако написать слово "компилятор" несколько проще, чем объяснять, что имеешь в виду целый пакет программ разработки (который не входит в IDE). В любом случае — уже не по теме.

Ну, почему же? Как раз очень даже по теме. Ты видимо интуитивно вышел на верную тему.

Для контроля качества нужно применять некие средства анализа. Эти средства неминуемо потребуют наличия парсера. А парсер — это компонент одинаково необходимый как в компиляторе, так и в любых дополнительных средствах вроде IDE или анализаторе кода. Просто ты для себя смешал эти понятия, а они на самом деле имеют иерархическое отношение.

Здравствуйте, FDSC, Вы писали:

FDS>Здравствуйте, VladD2, Вы писали:


VD>>Извини, но похоже ты пересидел с Дельфи. Тебе нужно изучить мир за пределами Борланда. IDE это всего лишь инструмент. И Борланд на сегодны далеко не законодатель мод.

FDS>Согласен. Только не знаю, кто законодатель.

На сегодня законодатель IDEA. Дальше как не смешно идет MS и Эклипс. И уже потом Борланд. Первенство МС и т.п. еще обсуждается, но IDEA пока что лидер в желотой майке. У конторы ее выпускающей есть отличное расширение для MS VS — ReSharper. С ним VS 2003 становится просто гипер-средой.

Вот кстати, что мало распространено в мире Борланад — это рефакторинг. Надыбай ReSharper или IDEA-ю и попробуй повозиться с ним. Напиши маленький прокт...

По-моему, рефакторинг является очень мощьным средством повышения качества кода и увеличения скорости разработки (при грамотном применении, коенчно).

FDS>>>Потом, очень много требуется именно от IDE — по крайней мере разделение (действительно разделение, а не как сейчас) архитектуры, кода, обработки ошибок, проверок отладки.

VD>>А как сейчас где?

FDS>Не понял.

Ну, ты говоришь "действительно разделение, а не как сейчас". Вот и интересно про что ты ведешь речь? Где это "как сейчас"?

FDS> Не видел ещё кода (и не слышал, наверное по неопытности), где совершенно отдельно хранится сам код и проверки ошибок к нему.

Странно. Даже дельфи имееть структурированную обработку исключений. А языки типа Efil имеют так же пред- и пост-условия, ну, и другие фишки. Есть так же плагины для C# превросящие декларативный контроль ошибок в этот язык.

Ну, и главное... все это не имеет никакого отношения к IDE. Подобноый контроль делается компиляторами. Конечно можно встроить его в IDE, но это будет частный случай.

FDS>Если по поводу .NET — заню. Это был только пример. Не встречал ошибок, где деструктор вызывается перед конструктором.

Значит ты еще не все встречал. встречал когда конструктор вызывался дважды, а деструктор раз десять, и все это для одного экземпляра. В общем, С++ рулит адназначна.

Здравствуйте, FDSC, Вы писали:

FDS>Ошибся с названием фирмы. BAE. Виноват.

А. Ну, первая несколько известнее и как раз все время Яву испоьзует.

FDS>С вероятностью 0.99 я программирую в другой области (ну, опыт, в общем, то же не очень). По поводу переполнений буферов: по моему это как раз к логическим ошибкам на этапе алгоритмизации, и очень серьёзным. AV — это Access Violation? Туда же.

К логическим? Т.е. если я где-то неверно тип привел, то это логическая ошибка? Ну, да, допустим, что для С++ это можно назвать логической ошибкой. Но как обяснить тот факт, что на Яве или C# (в безопастном режиме) таких ошибок вообще невозможно сделать? Вообще!

FDS>Я только пытался её провести (статистику). Такая чушь получилась, если честно, не хочеться показывать, обсмеёте.

Не, ну, все же интересно...

FDS>По поводу ошибок с типами — я стараюсь проектировать всё так, что бы преобразований типов не было вообще (с Вашей точки зения это, я думаю, неправильно).

Не почему же. Это похвальное стремление. Малость максималистское, но все же. Есть все же безопасные приведения типов. Например int -> long или chat -> int. Ну, или любые понижения типов (down cast). При этом гарантированно проблем с типами не будет. Языки типа Явы и Шарпа делают такие приведения автоматически (не требуя явного на то указания). Причем даже если имеет место приведение типов оно контролируется в рантайме. Так что код в котором имеет место ошибка типов никогда не сможет повредить память и привести к появлению ошибок второго порядка (которые ой как не просто выловить).

FDS>Интересно, как я отловлю с помощью преобразования типов ошибку в коде построения сетевого графика, или в численном интегрировании краевой задачи (долго, помню, с ней мучился)?

Контроль типов — это заслуга языка и рантайма. Плюс от программиста требуется проектирование нацеленное на перекладывание контроля типов на компилятор. А задачи то тут в общем-то не причем.

FDS> Нет уж, тут сидеть скорее над комментариями надо — чтоб без всяких верификаций несоответствие кода мат. алгоритму было понятно. И вообще, чтоб было понятно какому алгоритму.

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

FDS>Согласен, особенно Warnings помогают, процентов 50 ошибок отлавливают, причём довольно трудно находимых. Однако не все ошибки.

Все это было бы слишком просто.

FDS>Ещё чуть-чуть и Вы от меня мокрого места не оставите. Предложите своё. Посмеюсь.

Ну, что я могу предложить? Разве что вот это http://rsdn.ru/projects/rsharp/article/rsharp_mag.xml. Может будет интересно...

Здравствуйте, VladD2, Вы писали:

VD>Значит ты еще не все встречал. встречал когда конструктор вызывался дважды, а деструктор раз десять, и все это для одного экземпляра. В общем, С++ рулит адназначна.
Я такое встречал только в багландовском компиляторе, а он известен тем что в нем очень много ошибок.
Короче не надо говорить про С++ то чего нет.

Здравствуйте, Трурль, Вы писали:

Т>В Аде можно

Рыба вобла! А пример кода можно?

Здравствуйте, raskin, Вы писали:

R>

R>type MyType=type OldGoodType;
R>

Ага, действительно есть такая буква. Забыл.

tarkil wrote:

> VD> И там, и там хронятся строки. Но в первом случае они хранятся
> просто так, а во втором перенесенными на страницу. Так вот если
> хранить их как строка/символ в строке в обоих случаях и не разделять
> тиы, то ошибочно посунув вместо индекса перенесенной линии индекс
> линии из документа ты будешь долго ловить ошибку в отладчие. Если же
> ввести понятие виртуальных и реальных координат, то контроль за
> правильностью действий возмет на себя компилятор.
> Во-во. Влад, может быть ты знаешь языки, в которых можно без написания
> множества строк кода сказать: "у меня будет тип НомерСимволаВСтроке,
> ведёт себя совсем как int, только это совсем другой тип и использовать
> один вместо другого нельзя"? В горячо мною любимом C++ для этого надо
> определить класс и все операции вручную. В Java не лучше. Но хоть
> где-нибудь-то можно?!

В С++ пишешь:
typedef boost::strong_typedef<int> NumberOfSymbolInString;

Все, и не надо ничего больше писать

--
С уважением,
Alex Besogonov (alexy@izh.com)

VladD2 wrote:

> C>Не используют они никаких настроек. Вся Винда сейчас у них
> компилируется
> C>на VC7.1, старые версии Винды (до XP SP2) компилируются на VC6.
> Сдается мне, что на VC6 компилировалась NT 4. А винды компилируются на
> чем попалао (например, на исследовательских версиях компиляторов). Ну,
> а релизы винды компилируются на текущем релизе VC. Хотя тут я ничего
> утверждать не могу. Это только догадки.

Релизы всех виндов до SP2 компилируются VC6 — это можно посмотреть в
отладочных символах ядра.

С XP SP2 начали пользоваться для компиляции ядра VC7.1 у которого другой
формат отладочных символов. Все пользователи VC6 побежали жаловаться в
МС и в VC8 формат снова изменили на VC6-compatible и пообещали
перекомпилить Винду

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, raskin, Вы писали:

R>Для Integer — пойдёт на ура, насколько я помню.
Вот только, если определить

type MyType=Integer;

то MyType становится неотличим от Integer и можно использовать один вместо другого.

Здравствуйте, tarkil, Вы писали:

T>Здравствуйте, Трурль, Вы писали:

Т>>В Аде можно

T>Рыба вобла! А пример кода можно?

type MyType is INTEGER;

Здравствуйте, FDSC, Вы писали:

FDS>Ладно, убедили: Аду на свалку, мне — подучить языки.

FDS>Но своё то можно предложить. Как улучшить языки, почему C# лучше C++ (это к VladD2) и т.п.

FDS>Считаю, что дальнейшее сравнительное обсуждение конкретных языков Ада и C++ не приведёт ни к чему. Просто тут Аду некому защищать (профессионально), надо адвоката.

Не надо . Здесь все элементарно просто. В статье, что ты привел, речь идет не о С++, а о С. Разница огромна, и дело не в том, что в С++ есть слово "класс". С++ — строготипизирован. А С — нет. Более того. Ошибка типизации в С, которую так легко допустить, мало того что не ловится компилятором, так она еще и приводит к повреждению памяти, что увеличивает цену исправления дефектов и увеличивает время обнаружения и исправления дефектов — в рантайме вовсе не обязательно будет креш.

Ада — не просто строготипизирован, но параноидально типизирован. Этот язые разработан с целью максимально увеличить количество ошибок, вылавливаемых на этапе компиляции. Вплоть до того, что Ада накладывает ограничения на использование некоторых сочетаний символов в идентификаторах, по причине того, что на некоторых терминалах их можно перепутать с другими. Например, запрещено двойное подчеркивание, если я правильно помню. Ада применяется в задачах, где цена одной ошибки может быть очень высока — например, системы управления пусками ракет.

Так чего вы хотите? Сравнили нетипизированный С (считай, ассемблер) с параноидальной Адой, выяснили, что плотность ошибок на выходе у последней меньше (кстати, всего в полтора раза). Ну да. Так и должно быть. У С++ плотность ошибок тоже будет меньше чем в С.

Здравствуйте, tarkil, Вы писали:

T>Во-во. Влад, может быть ты знаешь языки, в которых можно без написания множества строк кода сказать: "у меня будет тип НомерСимволаВСтроке, ведёт себя совсем как int, только это совсем другой тип и использовать один вместо другого нельзя"? В горячо мною любимом C++ для этого надо определить класс и все операции вручную. В Java не лучше. Но хоть где-нибудь-то можно?!

struct PositionInString{int Value;};

Оно?

Здравствуйте, FDSC, Вы писали:

FDS> Что такое "Оберон" я вообще не знаю (по моему что-то очень старое...).

Язык программирования созданный Никлаусом Виртом и Юргом Гуткнехтом параллельно с создание операционной системы тоже носящей имя Оберон. Потомок от языков Pascal/Modula. (Имеет сборку мусора, модульную структуру, допускает высокоэффективную компиляцию даже без специальных ухищрений разработчиков компиляторов, а уж с ухищрениями — вообще улёт.)

Породил целое семейство языков — Обероны:

Pascal (1970) -->-- Modula 2 (1979) -->-- Oberon (1987) -->-- Oberon 2 (1992) -->-- Component Pascal (1997), Active Oberon (2000), Zonnon (2005)
+ многие другие


Скоро в России школьников будут учить языку Component Pascal вместо устаревшего Turbo Pascal.

Сергей Губанов wrote:

> Скоро в России школьников будут учить языку Component Pascal
> <http://www.inr.ac.ru/%7Einfo21/&gt; вместо устаревшего Turbo Pascal.

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

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax.

Вся "винда" проверяется с помощью систем автоматической проверки (существует два поколения таких систем). Это очень серьёзно. Если бы у меня такие были (желательно, бесплатно), я бы сейчас не нервничал.

Здравствуйте, VladD2, Вы писали:

FDS>>>>Потом, очень много требуется именно от IDE — по крайней мере разделение (действительно разделение, а не как сейчас) архитектуры, кода, обработки ошибок, проверок отладки.

...

VD>Ну, ты говоришь "действительно разделение, а не как сейчас". Вот и интересно про что ты ведешь речь? Где это "как сейчас"?

FDS>> Не видел ещё кода (и не слышал, наверное по неопытности), где совершенно отдельно хранится сам код и проверки ошибок к нему.

VD>Странно. Даже дельфи имееть структурированную обработку исключений. А языки типа Efil имеют так же пред- и пост-условия, ну, и другие фишки. Есть так же плагины для C# превросящие декларативный контроль ошибок в этот язык.

Слышал.
Я говорю про то, что контроль ошибок как код можно было бы скрыть когда надо, а когда надо — показать, причём в соответствующем контексте, скрывая ненужные алгоритмические подробности.
Насколько я знаю, в настоящее время, код пост- и предусловий существует отдельно, а исключения — прямо в коде (ну, конечно, это лучше, чем if IORESULT <> 0, но ненамного).



FDS>>Если по поводу .NET — заню. Это был только пример. Не встречал ошибок, где деструктор вызывается перед конструктором.

VD>Значит ты еще не все встречал. встречал когда конструктор вызывался дважды, а деструктор раз десять, и все это для одного экземпляра. В общем, С++ рулит адназначна.

Я встречал, когда конструктор вызывается 1 раз, а деструктор — 100 000 раз (буквально, в мае). Но чтоб деструктор впереди конструктора.....

Здравствуйте, VladD2, Вы писали:

VD>К логическим? Т.е. если я где-то неверно тип привел, то это логическая ошибка? Ну, да, допустим, что для С++ это можно назвать логической ошибкой. Но как обяснить тот факт, что на Яве или C# (в безопастном режиме) таких ошибок вообще невозможно сделать? Вообще!

К сожалению я мало программировал на C#. По моему, там вообще приведение типов используется "в принципе" осторожнее.
Вообще, я скажу, проектирование программы на C++ и C# просто абсолютно разные вещи. Я когда учил C# голову чуть не сломал.

FDS>>Я только пытался её провести (статистику). Такая чушь получилась, если честно, не хочеться показывать, обсмеёте.

VD>Не, ну, все же интересно...

Привожу, что от неё осталось (кстати, это в основном были интерфейсные приложения), ошибки в порядке убывания значимости:
0. Разнообразные ошибки.

1. Ошибки при отладке, от усталости и при внесении изменений (после цикла при добавлении команд забыты скобки; функция закомментирована при отладке и забыта; функция делает не то, что написано в названии; дважды вызвана очистка памяти; вызвана не та функция очистки памяти (это и к п. 5); функция очистки памяти вызвана для каждого элемента массива, хотя должна была только для всего массива; функция вообще не документирована и потеряна и т.п.) (у всех и всегда, по количеству ошибок, около половины от всех (включая п. 0))

2. Отсутствие доказанного математического алгоритма вплоть до процесса отладки. Полное незнание предметной области. Непонимание предметной сущности объекта. Путаница в порядках следования индексов свойств-массивов и правилах их перестановки.
Сюда же: неполная проработка проблемы перед кодированием: обычно ведёт к конфликтным ситуациям с объектами, зависанию приложения в бесконечном цикле или другим "экспрессивным" ошибкам. (очень часто)

3. Слшком сильная иерархичность доступа к объектам => запутанный код. Слишком сильное разделение на
приложения на слои. Наличие централизованного хранилища информации, не привязанного ни к одному физическому представлению (ввод пользователя, диск, обработка, вывод пользователя), что вводило лишние преобразования объектов в программу.
(тотально у всех программистов — непрофильных выпускников с опытом менее 1-3 года (за редким искл.), или профильных с опытом менее 1 — 1,5 года (у всех, видимо отличные в фирму не идут — идут куда получше))

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

5. Неправильные вызовы функций из других библиотек (несогласование типов и методов выделения памяти), забытые stdcall и pascal (удивительно, даже у довольно опытных программистов).
Сюда же: неправильные преобразования типов в межмодульных связях. Т.е., например, в одном модуле загружается однобайтовое значение в 4-байтовый стек, старшие байты не инициализированы. Другой модуль читает все 4-байта. (редко)


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

Я об этом и говорю. Но стремиться нужно к полной автоматизации кодирования (интересно, меня тогда уволят? Я ведь кодировщик, типичный).
Со сборщиками мусора я в C# то же намучился, но кажется понял — легко и удобно, но очень убого. Уж тогда бы сразу на аппаратном уровне сделали. Мне, как assembler-программисту, пусть и микроконтроллеров, жутко на это смотреть.

Кстати, до сих пор не могу понять, почему компилятор не может сам контролировать выделение памяти, особенно, когда на этапе компиляции уже всё понятно. А если не понятно, опять же компилятор может вставить код — счётчик ссылок (другое дело — такой код уже сложно сделать в общем случае, нужен анализ копирования с копии и т.п. Но ведь это возможно).

Здравствуйте, Gaperton.

Я просил не спорить больше об Ада и С++.

Здравствуйте, Cyberax, Вы писали:


C>Beagle 2 лучше было не приводить в пример.


Так и знал...

Здравствуйте, Cyberax, Вы писали:

C>FDSC wrote:

>>>> 1.2. Компилятор рассматривает код, находя функции, выход которых не
>>>> является корректным (т.е. объект разрушаеся или не создаётся, или
>>>> т.п.). Далее идёт создание пустых шаблонов объектов, исходя из
>>>> формальной безошибочности работы следующих функций.
>> C>Бессмысленно. Просто нужно разработать нормальную семантику
>> C>использования объектов (как в С++) или использовать GC и не иметь таких
>> C>проблем вообще.
>> Не понял. Причём тут семантика? Имеются ввиду незаконченные функции и
>> частичная отладка всего проекта без них.

C>Это я про деструкторы — в нормальных языках они вызываются почти всегда
C>автоматически, а в других языках деструкторов нет вообще. Простейшие
C>ошибки типа _возможного_ обращения по нулевому указателю давно умеют
C>отслеживать статические верефикаторы в C#/Java.

Тут про деструкторы ни слова.

>>>> 3. IDE позволяет задавать граф возможных и запретных
>>>> последовательностей вызовов методов (инциализация -> применение,
>>>> create -> Init -> загрузка из сети данных пользователя -> .. но не
>>>> наоборот ). Идёт контроль за обнулением инициализированных полей. Поля
>>>> объекта можно делать константными в пределах блока кода (или наоборот,
>>>> изменяемыми)
>> C>Нафиг такое не нужно, так как это принципиально невозможно проверить в
>> C>общем случае и, вдобавок, обходится грамотным проектированием.
>> Не понял, что нельзя проверить в общем случае?

C>Что последовательность вызовов будет нужно.

Чушь.

>> Если речь идёт о действиях внешних субъектов, то система всё равно
>> должна блокировать вызовы запрещённых методов, какие-бы эти действия
>> не были. А если порядок вызовов методов нельзя предусмотреть заранее,
>> значит нужно их реализовывать соответствующим образом; тогда их и
>> проверять не надо и в граф заносить то же.

C>Принципиально нельзя построить статический граф вызовов методов с
C>временными метками (могу даже доказательство привести).

Никто и не предлагает его строить.

>> Что значит "обходится грамотным проектированием"? Создавать полные
>> графы естественно не нужно.
>> Часто встречаю ошибки типа: пользователь не инициализировал переменную
>> и пытается с ней работать, связывается с микроконтроллером и пошёл (и
>> не только это). Много проблем возникает из-за этого. А самому
>> проверять нудно и трудно. Вот уж "обходится грамотным
>> проектированием", наоборот, проектировать и проверять легче.

C>Смотри С++, а именно идиому RAII — Resource Acquisition Is
C>Initialization и smart pointer'ы. То есть для работы с микроконтроллером
C>нужно взять на него хэндл, в конструкторе которого производится нужная
C>предварительная инициализация.

Неправильно понял. Привожу пример:
Уже есть предварителбная инициализация.
Пользователь устанавливает в программе диапазон измерений АЦП — 10 В, ЦАП — 5 В.
Далее он замыкает АЦП на ЦАП и хочет проверить, всё ли правильно. Естественно нет. Никакая инициализация тут просто так не поможет. "Умные указатели" тут вообще не причём.
Программа должна обрабатывать эту ошибку пользователя, а такиз вариантов масса.


>> C>А смысл?
>> Смысл простой. В Delphi, например, вообще нельзя работать из другого
>> класса с private-членами. Protected — только в текущем модуле.
>> Допустим я хочу поправить (дополнить) чужой класс (в любом языке),
>> зачем мне делать доступными приватные члены для всех методов, когда
>> мне нужен, возможно, только один? Зря возможность ошибочного вызова
>> делать.

C>В С++ есть механизм friend'ов, который позволяет открыть приватные члены
C>для избранных классов или функций. Хотя необходимость использования
C>такого механизма показывает на неправильное проектирование — другой
C>класс не должен лезть в приватные данные класса.

Представь, что класс, в который ты хочешь лезть неправильно спроектировали. Собственно ты правильно понял.

>> C>А нафиг??
>> Мне, например, надобилось.
>> Привожу примеры:
>> Один алгорит с 7 вложенными циклами Delphi компилирует так, что
>> переписанный на asm работает в 7,5 раза быстрей, но при смене проекта
>> всё заново писать приходиться. Муторно.

C>И что? Выносите ассемблер в отдельные файлы, компилируйте отдельным
C>ассемблером, а потом линкуйте в проект.

И что? Всё так же останется. Ещё и компилировать отдельно придётся.

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


"Хаки" в приложении работают на любой системе, совместимой с Intel x86.
Ничего себе небольшие — час или 15 минут!

FDSC wrote:

> Вся "винда" проверяется с помощью систем автоматической проверки
> (существует два поколения таких систем). Это очень серьёзно. Если бы у
> меня такие были (желательно, бесплатно), я бы сейчас не нервничал.

Эта система называется 'lint' И толку от нее ~0.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:
C>В чем в С++ проблема с runaway inheritance я не понимаю (вообще в первый раз такой термин слышу), больше похоже, что их местные программисты чего-то не так задизайнили.
Именно об этом они и говорят. По их наблюдениям, "местные программисты" любят наследоваться только от известных им классов поближе к всеобщему корню, наколбашивая десятки братьев-близнецов вместо выделения общей функциональности и минимизации copy/paste кода. Кроме того, те же программисты слабо владеют шаблонами, потому любят плодить свои личные контейнеры вместо параметризации stl.
Впечатление такое, что парни сфотографировали хаос — разработку без проектирования, где никто не следит за reuse, и порождение классов выполняется как в голову ударит. Конечно никто не станет рисовать красивые иерархии — класс соседа по качеству на порядок ниже, чем библиотечный, так что проще отнаследоваться от корня и скопировать 90% поведения, чем унаследоваться от соседа (особенно если он private и protected разбрасывает аки Воробъянинов бублики). А раз за разработку своих контейнеров никто по рукам не ударит — будет велосипедалить очереди и стеки (благо основное, чему их научили на пятидневных курсах — это именно очереди и стеки на С++, а вовсе не паттерны проектирования бизнес-классов). Потом, припертый к стенке, он начнет кричать про критическую неприменимость stl для его целей, мотивируя то неясными багами в методе reserve, то чиста своим заточенным мемори менеджером...

Здравствуйте, FDSC, Вы писали:

FDS>Я встречал, когда конструктор вызывается 1 раз, а деструктор — 100 000 раз (буквально, в мае). Но чтоб деструктор впереди конструктора.....

Да сколько угодно. Вон, в форуме Delphi регулярно предлагают конструктор поместить внутрь try, а free — в finally вот тебе и деструктор без конструктора...

FDSC wrote:

> Неправильно понял. Привожу пример:
> Уже есть предварителбная инициализация.
> Пользователь устанавливает в программе диапазон измерений АЦП — 10 В,
> ЦАП — 5 В.
> Далее он замыкает АЦП на ЦАП и хочет проверить, всё ли правильно.
> Естественно нет. Никакая инициализация тут просто так не поможет.
> "Умные указатели" тут вообще не причём.
> Программа должна обрабатывать эту ошибку пользователя, а такиз
> вариантов масса.

Ну и в чем тут компилятор поможет? Чистая логическая ошибка времени
исполнения.

> C>И что? Выносите ассемблер в отдельные файлы, компилируйте отдельным
> C>ассемблером, а потом линкуйте в проект.
> И что? Всё так же останется. Ещё и компилировать отдельно придётся.

Два случая:
1. Ассемблера мало — так вынесите его в отдельный файл и нечего ради
этого уродовать язык.
2. Ассемблера много — точно надо выносить в отдельный файл.

> C>Не понимаю я, зачем в язые нужно вводить низкоуровневые хаки, которые
> C>вдобавок лишат его кроссплатформенности (которая часто гораздо важнее
> C>небольших выигрышей в производительности).
> "Хаки" в приложении работают на любой системе, совместимой с Intel x86.

А если у меня PPC? Или Amd64 или Itanium?

> Ничего себе небольшие — час или 15 минут!

Крайне редкий случай — обычно выигрыш в десятки процентов.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

C>FDSC wrote:

>> Неправильно понял. Привожу пример:
>> Уже есть предварителбная инициализация.
>> Пользователь устанавливает в программе диапазон измерений АЦП — 10 В,
>> ЦАП — 5 В.
>> Далее он замыкает АЦП на ЦАП и хочет проверить, всё ли правильно.
>> Естественно нет. Никакая инициализация тут просто так не поможет.
>> "Умные указатели" тут вообще не причём.
>> Программа должна обрабатывать эту ошибку пользователя, а такиз
>> вариантов масса.

C>Ну и в чем тут компилятор поможет? Чистая логическая ошибка времени
C>исполнения.

Логических ошибок времени исполнения не бывает. Компилятор должен указать мне, что такая возможность у пользователя есть, иначе мне придётся искать её самому (это тяжело, правда).

>> C>И что? Выносите ассемблер в отдельные файлы, компилируйте отдельным
>> C>ассемблером, а потом линкуйте в проект.
>> И что? Всё так же останется. Ещё и компилировать отдельно придётся.

C>Два случая:
C>1. Ассемблера мало — так вынесите его в отдельный файл и нечего ради
C>этого уродовать язык.
C>2. Ассемблера много — точно надо выносить в отдельный файл.

Тут прикол в том, что я рад бы от него вообще избавиться. Assembler никогда не стоит выносить в отдельный файл. Если ассемблера много — лучше сразу всё на нём написать с использованием внешних модулей (я так делал).

>> C>Не понимаю я, зачем в язые нужно вводить низкоуровневые хаки, которые
>> C>вдобавок лишат его кроссплатформенности (которая часто гораздо важнее
>> C>небольших выигрышей в производительности).
>> "Хаки" в приложении работают на любой системе, совместимой с Intel x86.

C>А если у меня PPC? Или Amd64 или Itanium?

Amd64 то же совместимый с Intel x86. С Itamium наши пользователи никогда не работают. Да и Delph то же.
В этом и прикол, нужно, что бы можно было оптимизировать код не уродуя его и прямо в нём.

>> Ничего себе небольшие — час или 15 минут!

C>Крайне редкий случай — обычно выигрыш в десятки процентов.

В некотрых приложениях сплошь и рядом (всё равно редко, но очень значительно). Особенно в Delphi.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, FDSC, Вы писали:

FDS>>Я встречал, когда конструктор вызывается 1 раз, а деструктор — 100 000 раз (буквально, в мае). Но чтоб деструктор впереди конструктора.....

S>Да сколько угодно. Вон, в форуме Delphi регулярно предлагают конструктор поместить внутрь try, а free — в finally вот тебе и деструктор без конструктора...

Класс..

Здравствуйте, FDSC, Вы писали:

FDS>А вообще фрагмент, по моему, правильный, по поводу ООП и C++. Может я это .. не понимаю в программировании на C++ чего-то??? (я сам прогр. Delphi / assembler, C++ только правлю и дополняю, и то не очень часто).

Ну вот и ещё один полез что-то доказывать вне области собственных знаний...

Здравствуйте, tarkil, Вы писали:
T>Во-во. Влад, может быть ты знаешь языки, в которых можно без написания множества строк кода сказать: "у меня будет тип НомерСимволаВСтроке, ведёт себя совсем как int, только это совсем другой тип и использовать один вместо другого нельзя"? В горячо мною любимом C++ для этого надо определить класс и все операции вручную. В Java не лучше. Но хоть где-нибудь-то можно?!
Delphi. Начиная, если не путаю, с 4 не то 5.

type MyInt = type int

Здравствуйте, Трурль, Вы писали:

Т>Здравствуйте, raskin, Вы писали:

R>>Для Integer — пойдёт на ура, насколько я помню.
Т>Вот только, если определить
Т>

type MyType=Integer;

Т>то MyType становится неотличим от Integer и можно использовать один вместо другого.

Верно, но только если опустить второй type:

type MyType= type Integer;

FDSC wrote:

> C>Ну и в чем тут компилятор поможет? Чистая логическая ошибка времени
> C>исполнения.
> Логических ошибок времени исполнения не бывает. Компилятор должен
> указать мне, что такая возможность у пользователя есть, иначе мне
> придётся искать её самому (это тяжело, правда).

Это невозможно в принципе в общем случае, а лишь в некоторых частных
случаях и со знанием семантики приложения.

> C>Два случая:
> C>1. Ассемблера мало — так вынесите его в отдельный файл и нечего ради
> C>этого уродовать язык.
> C>2. Ассемблера много — точно надо выносить в отдельный файл.
> Тут прикол в том, что я рад бы от него вообще избавиться.

А зачем? Пусть себе живет там, где он нужен.

> C>А если у меня PPC? Или Amd64 или Itanium?
> Amd64 то же совместимый с Intel x86.

С большими (и влияющими на производительность) оговорками.

> С Itamium наши пользователи никогда не работают. Да и Delph то же.

Ну вот, сами себя ограничиваете.

> В этом и прикол, нужно, что бы можно было оптимизировать код не уродуя
> его и прямо в нём.

Тогда надо смотреть язык С — в нем есть почти все для низкоуровневой
оптимизации.

>>> Ничего себе небольшие — час или 15 минут!
> C>Крайне редкий случай — обычно выигрыш в десятки процентов.
> В некотрых приложениях сплошь и рядом (всё равно редко, но очень
> значительно). Особенно в Delphi.

Ну так давно пора ее выбросить.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

C>FDSC wrote:

>> Вся "винда" проверяется с помощью систем автоматической проверки
>> (существует два поколения таких систем). Это очень серьёзно. Если бы у
>> меня такие были (желательно, бесплатно), я бы сейчас не нервничал.

C>Эта система называется 'lint' И толку от нее ~0.



Нет. Первое поколение: PREfix и PREfast.
Второе поколение: Slam, ESP и Vault.

Здравствуйте, Cyberax, Вы писали:

C>FDSC wrote:

>> C>Ну и в чем тут компилятор поможет? Чистая логическая ошибка времени
>> C>исполнения.
>> Логических ошибок времени исполнения не бывает. Компилятор должен
>> указать мне, что такая возможность у пользователя есть, иначе мне
>> придётся искать её самому (это тяжело, правда).

C>Это невозможно в принципе в общем случае, а лишь в некоторых частных
C>случаях и со знанием семантики приложения.

Дело в том, что компилятор можно вполне научить распознавать нужные ситуации. Знания семантики тут не требуется. Ему нужно только распознать возможные ситуации, а программист сам сделает всё остальное

По ассемблеру не согласен, но разумного ничего сказать не могу (да и не я решаю: выбрасывать Delphi или нет).

Здравствуйте, FDSC, Вы писали:

FDS>Я встречал, когда конструктор вызывается 1 раз, а деструктор — 100 000 раз (буквально, в мае). Но чтоб деструктор впереди конструктора.....
Вот только в С++ с этим проблем нет. Ибо деструкторы автоматические те за их вызовами следит компилятор.

Здравствуйте, Дарней, Вы писали:

>>> 4. IDE реализует сам код, как граф. Названия методов даются как
>>> справочная информация для программиста, могут меняться автоматически.

C>>Было такое в Together и Rational Rose — успешно провалилось как
C>>неудобное и неюзабельное решение.

Д>очень интересно. а можно подробнее?

Изменять имена методов может любая утилита рефакторинга. Тут ЮМЛ-и и на фиг не уперлись.