Разные языки. Преимущества и недостатки

[незваный гость]

Sanyok писал(а):

Мое мнение по данной теме: следует различать языки программирования и среды программирования.
ИМХО, все или многое, о чем шел разговор (C#, VB6, Delphi, MATLAB и т.п) есть не языки программирования, а среды разработки программ.

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

Ну и что? Кто сказал, что язык разработки програм должен быть основан на тексте? Исторические причины (и то, что emacs другого не понимает) мы отброим как не существенные. А тогда возникает вопрос: как формально описывать полу-текстовый, полу-графический язык. Ответ: пока не научились (нет Бэкуса-Наура и Холмски для графических языков). И гибридные языки остаются недокументированными, их задвигают в разряд реализаций, сред и т.п. На мой взгляд, подход не конструктивен и не продуктивен. Но существующая ситуация, когда всякий гибридный язык имеет ровно одну реализацию еще более удручающая. Всяк ее пинает, не делая ничего лучшего (любопытно, что те кто делает, например, разработчики компиляторов, обычно не пинают. Видимо знают, сколько пота идет на ломоть хлеба). Отсутствие стандарта на гибридный язык очевидным образом на руку монополистам. И у них, опять же очевидно, нет ни малейшей потребности в стандартизации языка. А мы говорим о средах .

Сказанное не в укор рядовому разработчику, ему платят деньги отнюдь не за разработку компиляторов и сред. Более того, можно всерьез схлопотать по шапке, если отклоняться от бизнеса фирмы. Гораздо интереснее, что делают университеты и исследовательские центры? Где наш ответ Чемберлену (Микрософту, Сану, АТТ наконец)? Почему бизнес может, а наука — нет? Воспоминания, какими мы были гордыми и передовыми 20 лет тому назад? Ими сыт не будешь, жизнь на месте не стоит, а есть надо каждый день. Активность бизнеса — явный индикатор того, где у людей есть потребность. Иначе они платить не будут. (Существует, конечно, определенное количество людей с нездоровым блеском в глазах при словосочетании «новая версия крутейшего забугорного продукта». Но я еще не встретил ни одной компании с подобным увлечением. Компании, как правило, весьма консервативны.)

[Sanyok]

Цитата:

Я знаю один хороший сайт (http://google.ru), по ссылкам оттуда всё это можно найти. Например вот: http://libre.act-europe.fr/GtkAda/main.html
http://www.adatcl.com/
Полный комплект документации прилагается.

Я оценил Ваш юмор (насчет "ссылок с хорошнго сайта" ) По воле тягостного рока мне приходится писать проги и работать в Win9x, а я не слышал, что бы какая-нить версия GtkAda нормально там фурыкала. За ссылку по AdaTcl спасибо, благодарен, посмотрим что за зверь.

[Yuri Gendelman]

Прошу прощения за задержку с ответом.

bugmaker писал(а):

Цитата:

Мой ответ - на VB6, который заточен под такие задачи.

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

Попробую еще раз. VB был первой, во всяком случае – первой массовой, системой визуального программирования. VB сделал популярными такие понятия, как property, визуальные компоненты, компонентное программирование. .NET – это новая платформа. Именно с этим связаны трудности перехода с VB6 на VB.NET, основные различия между ними – не языковые, а платформенные.

bugmaker писал(а):

Цитата:

Вы сказали, что OCaml, по Вашему мнению, самый мощный язык.

Вероятно Вы имеете в виду это моё высказывание отсюда: http://dxdy.ru/viewtopic.php?t=3586&start=15
...

Да. Я именно это имел в виду. Это ведь Ваши слова:
"Язык - судя по многим данным наиболее оптимален на сегодняшний момент Ocaml. Не могу поделиться личными впечатлениями о нём, я с ним не работал."?
Я Вам и ответил в той же ветке, что дальнейшее изучение Вашего мнения о языках программирования мало интересно. В чем и убедился.

bugmaker писал(а):

Цитата:

Называть его довольно распространенным я бы не стал. Это очень специфический язык...

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

Не доверяйте первому впечатлению. И добавьте в список: Erlang - 8.

bugmaker писал(а):

Цитата:

Я то имел в виду промышленное программирование. А Вы, похоже, - выполнение курсовика.

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

Все второкурсники так считают..

bugmaker писал(а):

Цитата:

Я то имел в виду промышленное программирование. А Вы, похоже, - выполнение курсовика.

А что, в промышленном программировании спецификацию читать нужно меньше или совсем необязательно? Мы тут по старинке...

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

bugmaker писал(а):

Цитата:

А хорош он или плох теоретически - это другой вопрос.

Я совершенно уверен что например наркота "фактически используется" намного большим количеством народу. И что? Не будем рассматривать вопрос о плохости или хорошести, а сразу начнём принимать?

Других аргументов не осталось. Похоже, беседу пора сворачивать.

[Yuri Gendelman]

незваный гость писал(а):

Ну и что? Кто сказал, что язык разработки програм должен быть основан на тексте?
. . .
А тогда возникает вопрос: как формально описывать полу-текстовый, полу-графический язык. Ответ: пока не научились (нет Бэкуса-Наура и Холмски для графических языков).

И гибридные языки остаются недокументированными, их задвигают в разряд реализаций, сред и т.п. На мой взгляд, подход не конструктивен и не продуктивен.

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

По-моему GUI вполне описывается тестовыми файлами: .rc (VC), .frm (VB), .resx (.NET; фактически это XML). В Delphi формы хранятся в двоичных файлах, но могут быть экспортированы/импортированы в/из .txt.
А вот то, что желателен стандарт визуального представления GUI – это очень верное замечание. При переходе из среды в среду приходится все делать заново. Формально стандарт существует: UIL (User Interface Language) является частью стандарта на Motif. Но даже в Unix/Linux он не очень распространен.

[незваный гость]

Yuri Gendelman писал(а):

По-моему GUI вполне описывается тестовыми файлами: .rc (VC), .frm (VB), .resx (.NET; фактически это XML). В Delphi формы хранятся в двоичных файлах, но могут быть экспортированы/импортированы в/из .txt.

Вы меня не совсем правильно поняли. То, о чем Вы говорите суть внутреннее представление программы. Оно может быть двоичным или текстовым — это не важно. Важно, что разрабатывая программу, автор оперирует некоторыми графическими объектами наряду с текстовыми. В крайней форме это может быть Borland's ObjectVision. В менее экстремальной — ObjectTime Developer (разработка встроенных систем, основанная на UML) или VB (грфическая разработка интерфейса). Важно, что какую-то часть программы автор видит всегда только графически. Тоже самое происходит и в VB — заметная часть текста скрыта от программиста либо редактором форм, либо диалогами. 9 из 10 программистов на VB† просто не подозревают, что редактируемый ими текст уже «прошел цензуру» среды. Фактически язык VB включает определенное количество графики и правила манипулирования ею.

Yuri Gendelman писал(а):

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

Я говорим о более слабой потребности. О том, что нужен даже не стандарт, а хотя бы метод описания графических элементов языка. В чем-то это аналогично грамматикам Бэкуса-Наура. У нас нет грамматик графических элементов. Мы можем «легко» описать текстовую часть VB или ObjectVision, но не графическую.

Впрочем, описывать GUI тоже надо. UML (и «три кореш໇) претендуют (по крайней мере, претендовали) на решение всех проблем проектирования софта, при этом ухитрившись даже не коснуться GUI. Грош им цена после этого в очень многих проектах.

------
† как и остальные 80% статистики, эта цифра придумана по ходу текста. Впрочем, включая и 80% предыдущего предложения.

‡ (off-top) а как бы Вы перевели “three amigos”?

[Sanyok]

незваный гость писал(а):

Я говорим о более слабой потребности. О том, что нужен даже не стандарт, а хотя бы метод описания графических элементов языка. В чем-то это аналогично грамматикам Бэкуса-Наура. У нас нет грамматик графических элементов. Мы можем «легко» описать текстовую часть VB или ObjectVision, но не графическую.

Выделение мое.

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

[bugmaker]

Yuri Gendelman
Ещё раз, прошу обосновать Ваше на мой взгляд в высшей степени лживое утверждение, якобы происходящее из этой цитаты, что я выразил моё мнение о мощности языка OCaml а не мнение о наличии в окружающей среде многих фактов относительно его оптимальности.

[Cube]

имхо, достоинства языка определяются наличием удобных конструкций для формирования тех или иных структур данных и конструкций для обработки этих структур. Для обработки записей с разными там указателями удобней c/pascal, для списков python/perl/lisp, небольшую матрицу, наверное, удобней обсчитать в matlab, а несложное выражение из алгебры - где-нибудь в maple. Ну и т. д.

Цитата:

промышленное программирование

Это что такое ?

[незваный гость]

Cube писал(а):

Цитата:

промышленное программирование

Это что такое ?

Это программирование как инженерная деятельность: сроки и бюджеты, контракты и общение с заказчиками и субподрядчиками, распределение работы и обязанностей, документирование всего процесса (от выработки требований до тестировния и пользовательской документации), многолетнее сопровождение в режиме «тлеющей разработки» и т.п. Может быть, одной из наиболее характерных черт является программирование административной группой людей (именно группой, и именно группой, не свободной в выборе участников/руководителей), поскольку определяет многие аспекты дальнейшего.

[незваный гость]

Sanyok писал(а):

Что Вы подразумеваете под "графическими элементами языка"?
…
и прочая и прочая, что я называю для себя элементами графического пользовательского интерфейса (элементами GUI Laughing )

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

Например, ObjectTime (не путать с ObjectVision) задает логику программы используя диаграммы UML (в частности, диаграммы состояний). В этом случае заметная часть «кода» выглядит как чертеж. Это, кстати, наводит на размышление: инженеров не удивляет, что конструкция прибора задается графически, в виде чертежа. Более того, существуют колосальные пакеты делающие по «рисунку» разводку платы, и т.п. Никому и в голову не придет делать это иначе. А программы мы упорно описываем строго текстово. Другой пример — “round trip engineering”, когда структура программы разрабатывается на UML, а код — на С++ или Java. При этом программные средства поддерживают синхронизацию модели и кода. При этом, разумеется, соответсвующие языковые механизмы (классы и т.п.) оказываются избыточными: все, что было нужно сказать, уже сказано в модели.

Так или иначе, но графическое представление той или иной функциональности програм используется все шире. (Я приведу еще один пример. Вирт в своих книжках по Pascal и Modula-2 использует графическую нотацию для грамматики, на мой взгляд, более удобную, чем Б.-Н. Единственный недостаток — я до сих пор ищу способ генерировать такие диаграммы. Ну или хотя бы пакет их рисования в Visio. А грамматика является одной из наиболее удобных форм представления parser'а для нисходящего разбора.) Но я еще ни разу не видел описания языка как комбинации текста и формализованных диаграм. Может быть, именно потому, что мы (в отличии от инженеров с их чертежами) не научились формально описывать свои чертежи?

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

[bugmaker]

Графическое представление далеко не всегда удобно. Иногда оно помогает на начальных этапах, как например графики функций и геометрические чертежи в учебниках по математике/геометрии для начальных классов. Полистайте учебник по матанализу, много ли там "картинок"? В программировании в большинстве случаев оно особенно неудобно. Попытки создания графических были неоднократно, prograph например. Все они не удались по объективным причинам. Абстрактные соотношения практически не поддаются изображению графически. Попробуйте изобразить графически ну например нахождение всех перестановок из соседнего треда. Автоматизировать процесс создания программ, как это делается в текстовой форме, макросами и функциями высших порядков, очевидно, не удастся. В конечном итоге визуальное программирование по приведённым причинам неспособно решить сложные задачи принципиально, а в простых делах, как например создание интерфейса, намного усложняет разработку.

[незваный гость]

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

[Егор]

Для каких задач C++ лучше подходит, чем другие языки программирования?

P. S. Подозреваю, что на C++ написаны почти все движки больших компьютерных игр.

[Yuri Gendelman]

bugmaker писал(а):

Yuri Gendelman
Ещё раз, прошу обосновать Ваше на мой взгляд в высшей степени лживое утверждение, якобы происходящее из этой цитаты, что я выразил моё мнение о мощности языка OCaml а не мнение о наличии в окружающей среде многих фактов относительно его оптимальности.

Видите ли, Вы пока еще не настолько великий писатель, чтобы учить Вас наизусть. Так что Ваше уточнение очень к месту. Значит на самом деле Вы не считаете OCaml самым мощным? А считаете его всего лишь изменившим окружающую среду настолько, что в ней появилось много "фактов относительно его оптимальности"? Да-а, так исказить Ваше столь четко и ясно выраженное мнение!
А сам по себе OCaml - вполне нормальный функциональный язык. Из практических приложений OCaml я встречал только системы доказательства теорем - HOL, Coq. Что немало, хотя и не много. Среди функциональных языков чаще упоминаются Lisp, Haskell и Scheme.

[незваный гость]

Yuri Gendelman
А-я-яй!
bugmaker писал(а):

Цитата:

Язык - судя по многим данным наиболее оптимален на сегодняшний момент OCaml. Не могу поделиться личными впечатлениями о нём, я с ним не работал.

Где Вы тут нашли указания на то, что этот оптимальный не-мощный (немощный? — простите, у меня плохо с орфографий, забыл, как писать правильно) язык изменил окружающую среду (а тем более, остальные дни недели)? О каких-таких фактах Вы говорите? Более позднее сообщение и вовсе ничего не говорит об OCalm'е, фактах и средах. Оно содержит лишь (слабо обоснованное) утверждение о том, что среды, факты и OCalm были связаны в предыдущем высказывании автора.
Судите сами:

bugmaker писал(а):

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

(курсив мой — нг). Главное, ключевое слово тут — «выразил», причем именно в прошедшем времени.

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