=KRoN=>Профессионалу же навязывать что-то - снижать его эффективность.
Отнюдь нет. Особенно если речь идет о групповом программировании.
=KRoN=>Да и вообще, люблю я писать:=KRoN=>#define K +273.15=KRoN=>T = 25 K;=KRoN=>При программировании всякой химии здорово упрощает восприятие многих формул и т.п.
Вот-вот, по-мелочи-то удобно, но для большого проекта, с кучей определений в конце концов только запутывает...
=KRoN=>И это тот, кто ратует за однозначность и строгие рамки??=KRoN=>Ну-ка, что тут написано:=KRoN=>1001b=KRoN=>123d=KRoN=>Ась?
Вот за это я РС-шный ассемблер жутко не люблю, как и его мнемоники.
То ли дело на ZX: #C350
=KRoN=>Хотя Паскалевский $ мне нравится, всё же, больше
Ну вот
В Фортране-90 (насчет 77 не помню) еще универсальнее: #9C40 - в 16-ричной системе, а, скажем, 12#68AB - в 12-ричной.
MABP>Если хочешь чего этакого учудить - приложи дополнительные усилия, что есть подтверждение сознательности твоих действий. В управлении самолетом примерно аналогичная система - чем дальше тянешь ручку, тем большее усилие надо приложить.=KRoN=>Не совсем так.=KRoN=>И - есть Су-27, а есть МиГ-29.
Как это не совсем так? Триммер имеешь в виду что ли? И при чем
здесь Су-27 и МиГ-29?
=KRoN=>Представь, если электрика не станут допускать до распределительного щитка, говоря, что, мол, убить током может...
А что, не может? К щитку надо допускать
в крайнем случае, только при острой необходимости, с вывешиванием таблички "Осторожно, не включать, работают люди!". А необходимости такой становится все меньше и меньше. Уже вырастает целое поколение, не знающее, что это такое...
А то часто слишком профи любят копаться в этом щитке, когда достаточно розетку пошевелить. И убивает порой ни за что...
В конце концов посмотри, в какую сторону двигаются современные языки: C++ -> Java; Pascal -> Modula -> Oberon etc.
=KRoN=>И вообще, типы данных - это пережиток тех времён, когда char процессором считался быстрее, чем int, а float был вообще безумным тормозом... В идеале останутся типы number, string и pointer, а ещё через какое-то время один общий тип, как сейчас в Perl/PHP/JavaScript.
Ну, тенденция к этому, конечно, есть, но совсем до такого не дойдет. Всегда (в обозримом будущем) будут области, которым объективно не хватает вычислительной мощности и которым понадобится оптимальный по быстродействию/памяти тип. Аэродинамика, термодинамика, метеорология...
Да, чуть не забыл:
=KRoN=>Тебе не кажется странным, что реализаций Паскаля больше там, где больше любителей, а не профессионалов? PC + DOS/Win - вот и 99% использования Паскаля. Много ли пишут на Паскале для Unix? Много ли на нём написано военного софта? А как с уже заезженной тут темой микроконтроллеров?
Именно, странным кажется. Должно быть как минимум поровну
Я уже выражал свое мнение, что преобладание С[++] - коньюнктурное, надуманное. Просто поставлена уже машина производства и обучения, а переучиваться действительно зачастую невыгодно. А то давно бы уж на что-нибудь более прогрессивное перешли. Так же как распространенность Windows не осначает ее совершенства, так распространенность Си не означает его превосходства в техническом плане.
Что до 99%... А как тебе MacOS? Написана на ThinkPascal. А уж насколько лучше виндов, имел возможность убедиться.
Военный софт... Посмотри, на чем борт Гриппена запрограммирован
Для микроконтроллеров пишут и на Паскале; средств, используемых для такого программирования, достаточно в обоих языках. Да и наши вообще как-то на Asm'е в основном...
Наконец, теперь уже я задаю вопрос, не странно ли, что большинство наиболее продвинутых и красивых (классических!) языков - производные Паскаля? Модула, Ада, Оберон...
MABP>...когда я лет 6 назад занимался 51ми однокристалками...
ВЕ51? О, коллега
(на тот момент
) Я, правда, для них только на асме писал.
=KRoN=>Паскаль заметно старше C/C++ И то, что более молодой язык вытеснил старца с насиженного места тоже говорит о многом. И ОС ориентированные на Си появились не рантше самого Си.
Он не с насиженного места вытеснил. Паскаль и тогда в основном пребывал в академической среде. Вообще программной индустрии-то особой не было. Да и технические средства не позволяли тогда слишком абстрагироваться от железа...
=KRoN=>Справедливости ради стоит отметить, что с выходом ANSI-стандарта C++ военные в Штатах как-то дружно начали переходить на C++.
ТОЛЬКО лишь потому (я убежден), что Си-программисты дешевле, поскольку их больше.
=KRoN=>Ну, на Су-27 ручку можно и ослабить.=KRoN=>Только редко делают...
Откуда данные?
Если в принципе, у любого самолета с необратимой схемой можно. НО есть ОТТ ВВС, и там строго прописан минимальный градиент усилия на ручке. Нужно ли напоминать, чем грозит малое усилие?
=KRoN=>Жду, вот, пока Сай-2 в России появится...
Задолбаются частоту покупать...
=KRoN=>На счёт лингвиста - не знаю, а вот как химик скажу, что справочник - куда как приятнее
Ну, бывает, конечно, я сам такой. Но я, если не понятно, утрирую слегка
=KRoN=>Ну, спрофилируем задачу - какая машина лучше для БВБ?
Не скажу однозначно и тебя предостерегу.
=KRoN=>>>Профессионал будет писать красиво, наглядно и надёжно и на ассемблере...Zeus>>Да, но с разными затратами.=KRoN=>Не-а.=KRoN=>При крамотном подходе и хорошем знании матчасти можно писать весьма доходчивые программы на масме. И даже объектные
Блин. Кто б сомневался. Но одно дело - наглядно и надежно написать на ассемблере, а другое - на Паскале.
=KRoN=>Ещё раз приведу пример - "две молекулы вдорода взаимодействуя с одной молекулой кислорода дают в результате реакции две молекулы воды". Извини, если бы на таком языке писалась бы химия... Не представляю уровень нынешнего развития цивилизации, каким бы он был...
Неадекватный пример. Во всяком случае, не про Си/Паскаль. Чуть ниже разъясню.
=KRoN=>Не вижу разницы. Более компактная запись при однозначной идентификации предпочтительнее, чем более развёрнутая. Человеческий мозг способен одновременно воспринимать 7 ± 2 токена. И чем больше в них удасться вложить, тем проще работать с задачей. Естественно, до тех пор, пока токены однозначно идентифицируются. Кстати, поэтому пресловутая запись i++; (для того, кто её усвоил) опознаётся быстрее, чем inc(i); В случае короткого имени переменной, правда i:=i+1; тоже идентифицируется хорошо, но только потому, что это уже усвоенный токен. Для длинных имён переменных вариант с присваиванием уже начинает проигрывать...
А, понял, в чем твое заблуждение. Не надо путать "токен" с символом. Для человека (знающего язык) не слишком длинное слово воспринимается как раз как один "токен", и с этой точки зрения что begin, что { - одно и то же. Только чисто символьные конструкции не слишком естественны для человека, и при большом нагромождении требуют части внимания на идентификацию. Слова перепутать сложнее (ну, скажем, begin с end, чего не скажешь о { и } ). Все это милисекунды, конечно, но чем навороченнее, чем больше подряд идет разных значков, тем заметнее это явление.
Далее, "чем больше в них удастся вложить"... Так вот эти самые 7±2 - это не лексические, а семантические единицы, сущности, и вложить в них больше нельзя (на самом деле тут несколько сложнее, но если примеры различаются не на порядки, как у тебя с химией, то приблизительно верно).
=KRoN=>Если ты под фортовской логикой понимаешь только обратную польскую запись, то ты форт как раз поверхностно знаешь
А я и не претендую. Только представляю. И, разумеется, не только по калькулятору ZX.
=KRoN=>Идеология форта в методологии декомпозиции задачи на подзадачи. Расчленение всей программы на субмодули, каждый из которых легко воспринимается одним взглядом, целиком. И тестирование/отладка каждого такого модуля по отдельности.
Это не только его идеология. Скорее, всего (относительно) современного программирования, причем безотносительно к конкретному языку.
=KRoN=>...так Форт идёт дальше и негативно относится к функциям и подпрограммам на экраны размером.
Интересно, в чем это проявляется?
=KRoN=>О, проясняется. Тогда понятно, почему тебе близок Delphi
Delphi - да (хотя не только - из-за VCL самой по себе тоже). Но почему Паскаль - еще не понятно
=KRoN=>Си и Си++ - всё же несколько разные вещи =KRoN=>Даже более разные, чем виртовский Паскаль и Delphi
По-моему, примерно в равной мере. Точнее, если вместо Delphi написать Object Pascal, а иначе неадекватное сравнение получается.
=KRoN=>>LD A,B
[...]
=KRoN=>>или
[...]
=KRoN=>>MOV A,BZeus>>О!! Совершенно однозначно, первое! Разумеется.=KRoN=>Вот ты и попался! =KRoN=>Первая запись гораздо менее однозначная и допускает больше ошибок =KRoN=>LD (BC),(DE), скажем
Это ты попался. Во-1, вторая запись допускает не меньше ошибок: MOV A,123. Во-2, все равно каждая из них ловится еще при ассемблировании, так что не проблема. Ну и в-3, об адекватности примера еще можно спорить, но ИМХО первая запись ближе к паскалевской, чем вторая (по идеологии), а Си наоборот (один только пример - с указателем полей, "." и "->"; Паскаль обходится в обоих случаях точкой, и ничего).
Кстати, мнемоники эти не от ZX и CP/M зависят. Это официальные спецификации Zilog и Intel соответственно. Вообще, интеловские мнемоники мне всегда уродскими казались.
=KRoN=>Кстати, вылетело из головы - в Delphi ввели цикл с произвольным аргументом, или как и в Паскале остался только целочисленный с шагом 1?
Ну, как сказать... while он и в африке while, можно что угодно забацать... А в for допустим только ±1 (во всяком случае в Delphi 4), и это правильно.
Напоследок
очень рекомендую всем почитать небольшое интервью с умным человеком, как бы вы не относились к нему:
Никлаус Вирт о культуре разработки ПО.