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

[bugmaker]

Цитата:

Ассемблер, следуя этой логике, тоже не может устареть.

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

Цитата:

характерности их присутствия в современном языке

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

Цитата:

Например, того, как развивались механизмы распределения памяти -- common в Фортране, controlled в PL/1, malloc() в С, new в С++, и сборка мусора сейчас.

new() прекрасно соседствует в Java с GC и может при желании в С++. Вообще, специальный оператор для выделения памяти формально не нужен если дизайн языка предполагает GC. Для языка высокого уровня это не что иное как атавизм, и не суть важно, как он выглядит.

Цитата:

в ряде отношений VB был революционным решением, фактически установившим новый стандарт...

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

Цитата:

Поясняю. Когда Вы задаете через IDE аттрибуты кнопки, Вы фактически конфигурируете программный объект времени выполнения программы.

Всё равно недогнал

Цитата:

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

"- Это какие-то неправильные пчёлы, и они дают неправильный мёд! - Винни, это же мухи!" (С) какого-то классика. Все возможные конструкции описаны в спецификации языка. Все особые случаи и неоднозначности, такие как if () if () {} else {} или непоределённости типа i=i++ в С тоже описаны. В программировании нету места двоякому пониманию программ и нечленораздельному бормотанию компилятора. Если я ошибаюсь, хотелось бы поглядеть на конкретный пример.

Цитата:

дальше не доказательно

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

Цитата:

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

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

Цитата:

Я же по душевной простоте предпочитаю

личные предпочтения aka необъективность - это тот самый локомотив, который тянет предлииинный состав с проблемами.

Цитата:

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

Не понимаю, зачем притягивать за уши какой-то определённый подход? Если для какой-то задачи нужен например ООП- да ладно, пускай будет. Но ведь не для любой задачи и не наикривейшая реализация, как в том же С++, или того хуже в С#, что мы имеем повсеместно на настоящий момент?

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

Цитата:

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

Я намеренно лишил цитату автора, поскольку взял ее лишь как характерную.

Что значит "устарел"? И что значит -- язык Ассемблера?

Начнем со второго. Желающим говорить о программировании на Ассемблере рекомендую тряхнуть стариной, достать с полки (вероятнее всего -- библиотечной) "OS/370 -- Принципы работы", Джермейна, "Логическое программирование в системе 360" (да, да, это ассемблер, а совсем не Пролог). Почитать описание языка. Методы управления размещением кода программы и данных. Макропрограммирование. Система IO для ассемблера. Правила межмодульных связей. Найти набор макрокоманд структурного ассемблера. Продолжать можно до бесконечности.

То, что мы обычно видим сейчас, это, как правило, не язык ассемблера. Это -- набор мнемоник для удобочитаемой записи команд (и не случайно у многих сложилось превратное представление о взаимно-однозначном соответствии мнемоник и команд процессора. Такового исторически не было, и не случайно -- автор говорит move, а уж это дело ассемблера -- какую команду выбрать, регистровую али иную). masm не поставляется более (кстати, я не знаю ни одного ассемблера x86, дающего доступ к полному набору команд. Был вынужден делать 16ричные вставки в ассемблер!). На "ассемблере" делаются вставки в программы, и мы уже дожили до того, когда в ядре встроенной операционной системы (300-400 тысяч строк) имеется пара сотен (не поручусь, может, и полторасто) строк вставок. Там, где они нужны. Там, где без них нельзя. Но -- настолько незначительный процент, что даже неинтересно вспоминать... Ушло в прошлое (и, надеюсь, никогда не вернется) серьезное макропрограммирование на ассемблере. (Не напоминайте мне про препроцессор С. Лучшие черты макрогренерации не в нем, а в generics.) Никто не будет в здравом уме и трезвой памяти писать на ассеблере UI -- пока особо острая нехватка ресурсов не заставит. Приведу еще один пример: знаете ли Вы, где опубликован интерфейс (соглашения о связях, правила оформления вызова) ядра Windows из ассемблера? Примеры таковых? А COM интерфейсы? И это то, что я называю словом устарел. То, что для решения прошлых типовых задач ассемблера сейчас есть лучшие языки.

А вставки будут жить. Также, как и примеры того, как написав на ассемблере, мы получаем в 3 раза более быструю программу. И, никто не спорит -- критический цикл может быть нужно переписать. Но не разрабатывать всю программу на этом языке. (А вот Borland Pascal обходился и без них. Нужно -- пиши inline код, в шестнадцатеричном виде.)

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

bugmaker писал(а):

личные предпочтения aka необъективность - это тот самый локомотив, который тянет предлииинный состав с проблемами.

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

[bugmaker]

Цитата:

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

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

Цитата:

Я, по крайней мере, отдаю себе отчет (и не скрываю от публики), что это лишь мое мнение.

Ну тогда ладно, прекращаю дискуссию. Ибо аргументы и доводы можно пообсуждать, а мнение - совершенно бессмысленно.

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

bugmaker писал(а):

"- Это какие-то неправильные пчёлы, и они дают неправильный мёд! - Винни, это же мухи!"

О понимании компилятором и человеком. Я поясню на утрированном примере. Предположим, в программе написано

if (a < b < c) {
...
}

Всяк математик знает, как это читается -- три величины $a, b, c$ упорядочены по возрастанию. Между тем в программировании этот конструкт зависит от языка. В языках ветки C он интерпретируется как $(a < b) < c$, в некоторых других -- по человечески.

Теперь предположим некто написал этот код. (В оптимальном случае, Вы увидели этот код при поиске бага в программе, работающей в Вашем банке последние 15 лет. И 14 лет 11 месяцев спустя увольнения автора кода.) Вы не знаете, что себе думал автор. Хорошо, если у Вас грамматика языка в голове, а ну как нет? Теперь первый же вопрос: какого типа результат этого выражения, и какими должны быть типы операндов? Бежать читать стадарт?!? Отличная идея! Только вот он не всегда корректно и не всегда полностью реализован (а ведь иногда и с расширениями, которые противоречат более позднему стандарту). А разработчик компилятора реализованную грамматику приложить поленился, <...>. Ну и что будем делать дальше? Логичнее всего -- ткнуть грызуном в код, и спросить комп -- а как выглядит дерево разбора данного места... Иначе -- догадывайся, что было у компилятора на уме, причем вслепую.

Пример намеренно упрощен, чтобы была понятна идея. Данный синтаксис более или менее тривиален, и странен только для математиков, (хотя в VB и С++ $a = b = c$ выдаст весьма разные результаты.) Опять же, пока путаница возникала при переносе текста между языками. Но существуют и случаи запутанного синтаксиса в пределах одного языка.

[bugmaker]

Цитата:

Бежать читать стадарт?!? Отличная идея! Только вот он не всегда корректно и не всегда полностью реализован

Предположим, что мы прочитали стандарт (мы ведь не хотим делать прогу левой пяткой с завязанными глазами, а потом компилить пока не скомилится, а потом повторять пока не пройдёт тестов, не так ли?), и не нашли чёткого определения нашей ситуации. Пусть это будет выражение i += i++ + ++i;

Цитата:

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

Предположим, такая штука у нас есть. Она дала нам ответ, и он нас устроил. Прога вышла в релиз, и ей усиленно пользуются. Через 15 лет кто-то решил добавить мелкую, но нужную и полезную фичу, никак не относящуюся к этому участку кода. Перекомпилировав, с удивлением обнаруживаем, что всё поломалось и ничего не работает... В новой версии компилера это выражение ведёт себя совершенно по другому! И это не баг компилера, потому что компилер соответсвует стандарту, а в стандарте указано, что в данной ситуации поведение не определено. Долго думаем, и приходим к выводу: мыш не является полноценным заменителем головного мозга. Нет ни одной причины творить сомнительный код. Любое выражение на любом языке можно привести к приемлемому и соответствующему стандарту виду. Предупреждения, выводимые в случае, если есть неопределённые стандартом вещи, уже есть.

bugmaker@buggy:~/devel/tmp$ cat und.c
#include <stdio.h>

int main (int argc, char * argv []) {
        int i = 0;

        i += i++ + ++i;
        printf ("%i\n", i);

        return 0;
}
bugmaker@buggy:~/devel/tmp$ gcc -Wall und.c
und.c: In function `main':
und.c:6: warning: operation on `i' may be undefined
und.c:6: warning: operation on `i' may be undefined
bugmaker@buggy:~/devel/tmp$ gcc -v
Reading specs from /usr/lib/gcc-lib/i486-slackware-linux/3.3.6/specs
Configured with: ../gcc-3.3.6/configure --prefix=/usr --enable-shared --enable-threads=posix --enable-__cxa_atexi
Thread model: posix
gcc version 3.3.6
bugmaker@buggy:~/devel/tmp$  

Цитата:

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

Есть ли реальные случаи оправданного использования таких "расширений"?

Цитата:

Всяк математик знает, как это читается -- три величины $a, b, c$ упорядочены по возрастанию.

В математике - свой язык, в программировании - свой. Цели и задачи у них существенно разные, нет никаких причин поэтому тащить синтаксис из математики в программирование. Не очень хорошая идея, поручать написание программы тому, кто не знает в точности, что и зачем он пишет. Кстати, в c++ ситуация более забавна: результат будет зависеть и от перегрузки операторов. Так что, на такие вещи влияет в основном дизайн языка. Сравним же:

[1]> (< 1 2 3)
T
[2]> (< 1 2 0)
NIL
[3]> (< 1 0 3)
NIL
[4]> (< 0 1 3)
T
[5]> (setq a 1)
1
[6]> (setq b 2)
2
[7]> (setq c (= a b))
NIL
[8]> (setq c (setq a b))
2

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

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

bugmaker писал(а):

Есть ли реальные случаи оправданного использования таких "расширений"?

Есть, есть. Но, кроме того, автор компилятора Вас не спрашивал, добавлять их или нет.

bugmaker писал(а):

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

Вольно ж Вам выбирать себе кумиров. Я отнюдь не влюблен в традиционные языки, но выбираю язык под проект. Боюсь, что мне еще долгонько искать DO-178B сертифицированный Lisp или Ocalm. Равно как и удобную в обращении систему программирования бизнес-приложений для оных. (Пожалуйста, не нужно говорить, чтио они для других задач. Если для других, то вопрос -- а что для этих? Почему все занимаются ОО -- неужели в MS (да и в Sun, IBM, FSF наконец) не нашлось ни одного умного человека, знающего Lisp? Скажу по секрету, есть там такие, которые знают. Просто не удобно решать эти задачи функционально, вот и не кочевряжутся.)

Из опыта: стандарт читает исчезающее меньшинство программистов (более того, не все авторы компиляторов / библиотек ). Обычные люди довольствуются учебником, курсом. Многие и не в состояниии прочитать стандарт, даже когда это им нужно. Поскольку стандарт обычно весьма сложный и насыщенный документ. Любопытно, что не у всех языков есть стандарты. В каком году появился ANSI-шный Common Lisp? В 1994? Как же мы, бедные, жили 36 лет? А на Pascal стандарт-то есть? Что читати будем? Вирт (в приватных дискурсиях) на подобные вопросы отвечал примерно "а мне пофиг, любому здравомыслящему человеку должно быть понятно" или "Стандарт не нужен для учебного процесса. Если индустрии нужен стандарт, пусть она и занимается стандартизацией".

bugmaker писал(а):

Она дала нам ответ, и он нас устроил. <...> В новой версии компилера это выражение ведёт себя совершенно по другому!

Дерево разбора -- однозначно. Порядок выполнения неопределен, и хорошая система может и на это указать. Но во многих случаях (особенно в С++, я не беру языки с вырожденным синтаксисом вроде Lisp и Forth) даже дерево могло бы помочь понять, что "мы не в туда".

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

bugmaker писал(а):

[1]> (< 1 2 3) 

Можно столь же компактный и наглядный пример для $ a = b \leqslant c = d < e $? Любят лисповцы однородные выражения, но жизнь богаче, чем множество ассоциативных функций.

[bugmaker]

Есть, есть.

Можно привести примеры?

Цитата:

автор компилятора Вас не спрашивал, добавлять их или нет

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

Цитата:

Можно столь же компактный и наглядный пример для $ a = b \leqslant c = d < e $?

Пользуйтесь на здоровье:

[1]> (defun cmp (x) (if (= 1 (length  x)) t (and (eval (list (second x) (first x) (third x))) (cmp (rest (rest x))))))
CMP
[2]> (cmp '(2 = 2 <= 4 = 4 < 5 < 6))
T
[3]> (cmp '(2 = 2 <= 4 = 4 < 5 < 3))
NIL
[4]> 

Работает для произвольного числа аргументов и операторов. Как и в прошлом случае, прошу продемонстрировать аналогичную функциональность на DO-178B сертифицированном бейсике.

Цитата:

Вольно ж Вам выбирать себе кумиров

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

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

bugmaker писал(а):

Можно привести примеры?

Извольте. Расширения С++ для использования специализированных возможностей DSP процессоров.

Другим примером является расширение Borland'ом Pascal'я при включении в Delphi. Вместо корявых макросов MFC Borland честно сделал расширение языка.

Да, кстати -- когда нет синтаксиса (вырожденный синтаксис), нет и проблемы расширений. Кажется, чемпионом все-таки является не Lisp, а Forth, где можно на лету подменить executor. Вот там-то полная свобода написания програм. Правда, не функциональных, посему его отринем с негодованием.

bugmaker писал(а):

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

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

bugmaker писал(а):

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

Пожалуйста, пример на Python:

eval("a = b <= c = d < e < f")

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

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

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

P.S. А культуре спора меня не обучали -- неуч я и невежда. Что, наверное, чуствуется.

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

bugmaker писал(а):

нет никаких причин поэтому тащить синтаксис из математики в программирование.

Есть, и очень серьезные. Во-первых, язык математики формировался и шлифовался столетиями (если не тысячелетиями), и, наверное, достаточно естествененн для человека. Лучше уж комп пусть к нам приспосабливается, чем мы к компу. Во-вторых, язык математики знаком гораздо большему числу людей, чем (надо признать) достаточно искуственный синтаксис языков программирования 50-70 годов. Тогда еще было много экспериментов и мало опыта. Да и ресурсы поджимали.... В-третьих, и это быть может, главное -- как только мы говорим о формализованном, доказательном программировании, так сразу мы говорим о математической логике и математике вообще. Поэтому логично иметь общий язык, поелико возможно.

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

Мне кажется, Вы склонны рассматривать достоинства и недостатки языков несколько абстрактно, в отрыве от их (языков) пользователей. Между тем нетрудно замеить сходство ЯП с естественными языками: как realia определяют развитие языков человеческого общения, так realia программирования определяют эволюцию ЯП. Один из этих факторов в программировании -- программисты. Мы можем их поносить сколько хотим, мечтать, чтобы они все были грамотными, опытными и бессребрениками, но на практике -- это обычные люди. Со всеми достоинствами и недостатками.

Я имею очень острые зубы и на Java, и на C#, -- но по жизни хорошо понимаю выбор их разработчиков. Они хотели сделать популярные языки программирования, и для этого ЯП должны были казаться знакомыми, привычными. Что они и делали, заимствуя весьма архаичный синтаксис из C. С точки зрения развития ЯП -- полная ахинея. С точки зрения разработчиков -- абсолютно правильный ход. Они делали массовые, а не экспериментальные языки.

[bugmaker]

Цитата:

Извольте. Расширения С++ для использования специализированных возможностей DSP процессоров.

DSP это что? Digital Singnal Processing видимо? Можно конкретый пример использования, когда без "расширений" ну совсем никак, или хотя бы экономия труда при их использовании превышала трудозатраты из-за тотальной переделки вследствие изменений в стандарте.

Цитата:

Другим примером является расширение Borland'ом Pascal'я при включении в Delphi. Вместо корявых макросов MFC Borland честно сделал расширение языка.

А зачем? Более-менее грамотный дизайн ООП библиотеки для конкретно построения интерфейса можно посмотреть в Qt. Достаточно хорошо совместимо со стандартом и должный функционал вполне обеспечивается без всяких вывертов. В случае с Delphi мы имеем фуллхаус из никем кроме них неподдерживаемых "расширений", а это дополнительная нагрузка при обучении, и, к настоящему моменту, кучю кода, для которого не будет ни латания существующих компилеров, ни создания новых для других платформ. Что взамен?

Цитата:

Forth, где можно на лету подменить executor. Вот там-то полная свобода написания програм.

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

Цитата:

Правда, не функциональных, посему его отринем с негодованием.

Common Lisp - НЕ функциональный, если что. Только некоторые диалекты лиспа таковы.

Цитата:

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

Ну кто заставляет использовать несоответствующеи стандарту компиляторы со всеми их "расширениями"???

Цитата:

Пожалуйста, пример на Python:

В свою очередь позволю себе несколько покапризничать. Я применил в своём примере только базовые операторы языка. Здесь же применена специальная возможность для подобных случаев. Очевидно, что рано или поздно для решения какой-нибудь практической задачи не найдётся уже готовой сущности в языке. Посему, чтобы прояснить вопрос о гибкости самого языка, прошу продемонстрировать решение, не примегая к специализированной eval, а обойтись также базовыми функциями.

Цитата:

Заметьте однако, что Вы перешли к инфиксной записи от префиксной предыдущего примера

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

Цитата:

А DO-178 Вы напрасно пинаете

Где я его пинаю ? ИМХО его упоминание здесь несколько неуместно. Хотя, по очевидным причинам, любой диалект лиспа намного легче было бы сертифицировать, ибо и компилятор лиспа проще и лисп-код намного легче доказать на правильность чем тот же питон-код например. Но это совершенно отдельная тема.

Цитата:

То, что Вы о ней не знаете

Единственное, что я о ней не знаю, это в каком контексте она здесь вообще упоминается.

Цитата:

P.S. А культуре спора меня не обучали -- неуч я и невежда. Что, наверное, чуствуется.

Очень жаль. Чувствуется природное дарование. Немного обучения - и Вам смело можно доверять выпуск газеты в Кентукки.

Цитата:

Во-первых, язык математики формировался и шлифовался столетиями (если не тысячелетиями), и, наверное, достаточно естествененн для человека.

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

Цитата:

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

Записывают свою речь иероглифами 2/3 населения Земли. Я передумал. Всё пишем иероглифами.

Цитата:

Поэтому логично иметь общий язык, поелико возможно.

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

Цитата:

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

Ещё бы! В этом треде мы вроде бы обсуждаем языки программирования, а не их разнесчастных пользователей?

Цитата:

весьма архаичный синтаксис из C. С точки зрения развития ЯП -- полная ахинея.

ИМХО для процедурного программирования С-подобный синтаксис оптимален, достаточно лаконичен и читаем. Лучшего для этой цели не могу представить. Буду благодарен, если мне разъяснят, в чём моё заблуждение.

Цитата:

Со всеми достоинствами и недостатками.

Понятно, есть кто-то, кто наживается на недостатках других, вводя их в заблуждение. Но зачем делать вид, что это хорошо и правильно? Тоже показательный пример из соседнего треда: "мы делали проект, выбрав для его реализации наименее подходящий язык. Теперь производители компилятора этого языка благополучно забили на него, и мы собираемся продолжать проект на другом, ещё менее подходящем инструментарии, который, совершенно очевидно, тоже издохнет через пару лет как и его предшественник." Вместо того, чтобы сократить себе работу на порядки (!), сделать более качественный продукт, будут продолжать do it again and again and again. Конечно, вполне определённым кругам это просто выгодно, но зачем итти у них на поводу?

[Comga]

bugmaker

[e2e4]

Ув. незванный гость, совершенно с вами согласен по вопросам практики применения ассемблера, но вот это:

Цитата:

То, что мы обычно видим сейчас, это, как правило, не язык ассемблера. Это -- набор мнемоник для удобочитаемой записи команд (и не случайно у многих сложилось превратное представление о взаимно-однозначном соответствии мнемоник и команд процессора. Такового исторически не было, и не случайно -- автор говорит move, а уж это дело ассемблера -- какую команду выбрать, регистровую али иную). masm не поставляется более (кстати, я не знаю ни одного ассемблера x86, дающего доступ к полному набору команд. Был вынужден делать 16ричные вставки в ассемблер!).

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

bugmaker писал(а):

DSP это что? Digital Singnal Processing видимо? Можно конкретый пример использования, когда без "расширений" ну совсем никак, или хотя бы экономия труда при их использовании превышала трудозатраты из-за тотальной переделки вследствие изменений в стандарте.

И не только DSP-процессоров, но и обычных микроконтроллеров. Извольте:
IAR C++ для ATmel 8-бит микроконтроллеров:
#pragma vector=ADC_vect
static __interrupt void foo(void)
{
}
Объявление функции-прерывания, с созданием ссылки на нее в таблице векторов прерывания. Операция вызова функции-прерывании иная, нежели чем вызов обычной функции, как, не используюя уродливые конструкции на ассемблере, написать правильные calling conventions для этой функции, кроме как использовать ключевое слово interrupt?
Этот пример - еще и пример изменения стандартов, созданных локально в одном компиляторе - дело в том, что IAR C использовал совсем другую конструкцию объявления функции-прерывания, что привело к несовместимости программ, написанных под него, при компиляции под IAR C++. К счастью, ручками это поправить было не так сложно, вызвало просто раздражение.
Тот же IAR C++:
__eeprom - спецификатор переменной, засовывает переменную в eeprom память.
Texas Instruments Code Composer C2000:
ioport keyword enables access to the I/O port space of the TM320C2x/C2xx/C5x devices.
interrupt - опять объявляем функцию-прерывание.

и т.д. и т.п.

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

bugmaker писал(а):

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

Не могли бы вы назвать эту нишу?

Цитата:

Ну кто заставляет использовать несоответствующеи стандарту компиляторы со всеми их "расширениями"???

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

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

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

e2e4 писал(а):

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

Ну, чтобы не было сомнений, система команд устареть не может. (Я хотел было написать 16ричные коды, но потом спохватился, вспомнив про 8ричные. И сообразив, что они-то устарели, и сейчас (в новых архитектурах) почти не используются.) Каждый производитель процессора выпускает руководство, которым пользуются единицы -- разработчики компиляторов, аппаратуры и эксперты-программисты, выжимающие последние такты из процессора. И в этом руководстве производитель дает командам мнемоники.

Мнемоники, тем не менее, уже на этом уровне часто соответствуют не одной, а нескольким командам. Чтобы не быть голословным -- в Intel 80486, "OR" -- 9 (14, считая 32битный префикс) кодов операций, "MOV" -- 14 (20).

Теперь о "команде". Понятие команды как единицы организации вычислений в последнее время все более размывается. В мотороловских руководствах заметная часть посвящена диаграммам наложения команд при исполнении. Современные технологии (конвейеры всех мастей,...) усугубляют ситуацию (когда прерывание об ошибке приходит спустя несколько комманд -- skidding), а VLIW доводит до абсурда.

Для процессора почти всегда есть программа-ассемблер транслирующая свой входной язык (ассемблер) в объектный код. В старые добрые времена ЯВУ частенько транслировался в ассемблер, и последний, помимо трансляции мнемоник частично оптимизировал порождение компилятора.Сейчас все это ушло в прошлое, и ассемблер, если и порождается, то как иллюстрация для программиста (или средство отладки компилятора); порожденный же код часто нельзя компилировать. Исключение иногда составляют кросс-компиляторы, разработчики которых экономят время на написании генератора объектоного кода за счет проирыша (иногда весьма заметного) во времени компиляции.

Тем не менее, даже при наличии ассемблера, никто не пишет на нем программы сколь-нибудь заметного размера. Обычным является языковое вступление -- небольшая программа, являющаяся интрефейсом между операционной и языковой средой; критические фрагменты библиотеки; иногда низкоуровневая работа с оборудованием. Вот и все. В результате язык упростился до предела, став по сути методом мнемонической записи комманд. А ведь когда-то на ассемблере писались целиком приложения (например, обслуживание клиентов в банке в среде TPF). Разумеется, в те времена ассемблер был богаче как язык.

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

Все вместе вышесказанное подводит меня к мысли об устаревании ассемблера, исчезновении его как языка из магистрального программирования. Немалый процент программистов вокруг нас живут не зная системы своего команд процессора. (В старые добрые времена, когда 386 был дорогим, 286 -- рабочей машиной (4 на отдел из 30 человек), одна из программисток на вопрос, какой у мужа компьютер дома 16битный или 32битный ответила -- не знаю, там какие-то цифры 486 . Так вот и живем.)

В заключение -- мне кажется, что С и С++ сегодня ожидает судьба ассемблера. Нет, они не исчезнут сразу ("COBOL мертв!" раздается последние 40 лет). Пара любопытных ссылок: TIOBE Programming Community Index for July 2006 (ассемблеры упоминаются, но таблицы не вошли) и Comparison of programming languages.

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

e2e4 писал(а):

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

Возражение двояко: (1) Документированному коду операции обычно (об этом далее) соответствует мнемоника в ассемблере (на то он и документированный). А что делать, если некая команда не документирована, но абсолютно необходима? И какой-нибудь Intel в соответствующем месте библиотеки хладнокровно пишет цепочку байтов?

(2) Приведу пример -- в Borland C++ в какой-то момент inline assembler не поддерживал 32-битные команды (вполне документированные), и префикс приходилось вставлять от руки. Ассемблер может и просто отставать -- вышел новый процессор, который еще не поддерживается ассемблером, но уже надо использовать. Но может быть и так, как с AAD в x86 -- команда документирована в типовом случае использования, но порцессорно богаче. А производитель ассемблера следует простейшему случаю, сужая возможности программиста.