Здравствуйте, netch80, Вы писали:
V>>Вирт, вестимо.
V>>Его язык "Паскаль" — это один в один Алгол, над которым он работал в кач-ве соавтора.
N>Нет, различий достаточно много. Начиная с синтаксиса. У Алгола он значительно кривее.
Сама суть языка, способ организации программы, способы объявления и реализации перечислимых множеств, составных типов, массивов, процедур и функций — всё идентично, считай.
Различия синтаксиса косметические, требуют от программиста максимум часа-другого привыкания и далее пошёл как по знакомому. ))
V>>Дык, он же, Вирт, разработал Модулу-2 на ~20 лет позже.
N>Путаешь. Паскаль — 1970.
Фактически он его разрабатывал с 68-го.
N>Модула-1 — 1975. Модула-2 — 1978. 20 лет там нет.
Да, десяток лет, конечно.
N>Вполне можно было уже вместо трубопоскакаля в 80-х сделать что-то более полезное.
Модулу-2, например.
Вполне возможно, что на момент начала разработки Турбо-Паскаля Модулы-2 еще не было.
И еще возможно, что Турбо-Паскаль не позиционировался изначально как "серьёзный" язык — не зря же взяли учебный Паскаль?
Выглядит так, что результат получился намного лучше, чем планировали изначально. ))
Реально крутую среду по тем временам сделали.
И Турбо-С затем — все сишники тех лет через него прошли.
N>cvsup был написан на Модуле-3 и был на каждой BSD до примерно 2003.
Ну...
Как появился Оберон, в курсе?
Вот так же и Модула-3.
Т.е., алголоподобные языки (Паскаль и Модулу-2) стали пытаться использовать для низкоуровневой и эффективной разработки.
И сразу всплыла необходимость доработки этих языков.
Вирт выкатил доработанный Паскаль/Модулу-2 — Оберон, с целью написания одноимённой операционной системы.
Ему пришлось сделать индексацию массивов только от 0-ля (убрав произвольную индексацию, в т.ч. индексацию перечислимыми типами), убрал тормознутые паскалевские множества и еще всякого почистил.
Ну и, ввел автоматическую сборку мусора у динамически-выделяемых объектов.
В любом случае, проблема этого семейства языков (включая Object Pascal) очевидна — отсутствие хорошей совместимости, при том, что языки одного семейства.
Т.е. каждая версия языка — это как другой язык, хотя для программиста зачастую — вид в профиль.
Причём, обеспечить совместимость можно было через механизм некоего obsolete, плюс ключи компиляции и прочее такое...
Но Вирт и Ко поставили во главу угла миниатюрность и эффективность компилятора, за что и поплатились "работой в стол".
И это самый важный урок из всей этой истории...
Реально, если бы приоритет совместимости был выше, если бы не вылизывали сам компилятор, а подержали им семейство диалектов, как это делают компиляторы С++ — история с этим семейством могла быть совсем иной.
Например, новые версии Фортрана, хотя резко почистили синтаксис (вернее, ввели более чистую альтернативу или сократили излишнюю многословность), запросто умеют компилять старый код.
Например, объявление переменной одновременно с её инициализацией значением — удобная фича, но старый вариант тоже прокатывает.
N>Проблема в том, что до 20-25 мы почти все такие школоло. Сейчас для таких есть питон и прочая. Тогда — не было.
ХЗ.
Нам, системщикам/железячникам, приходилось много упражняться на асме тогда, поэтому тонкости ЯВУ волновали не сильно.
У меня в обойме одновременно был Паскаль, Си, С++, Форт, VB/VBA, изредка Фортран (когда готовые расчёты уже есть, но надо чуть допилить), MatLab (это, в первую очередь, язык программирования, а не среда — бо писать расчётные утилиты на ём и консольные было удобно).
Не могу сказать, что были какие-то особые предпочтения в те года, бо плюсов и минусов везде хватало.
Банально брал, что удобнее.
Для парсинга и прочих DSL удобней был Форт (свой ASM-51 на нём как-то за рабочий день сделал, вместе с программой для закачки образа в эмулятор ПЗУ — ни на каком другом тогдашнем языке это принципиально было невозможно, да и сейчас тоже).
Для любых расчётных утилит ничего удобнее MatLaba (как языка) не существовало.
По-быстрому наваять формочки — да какой в опу Дельфи, на VB это было быстрее раз эдак в несколько, плюс проще интероп с плюсами, из-за скриптовой натуры языка в отладочном режиме, при том что скомпилированный код был неплохо оптимизирован, особенно в деле работы с COM-объектами, что это даже заметно эффективнее было, чем пользоваться в плюсах смарт-поинтерами для них же. А если не пользоваться — то ресурсы могут утечь, либо код превращается в бесконечную лапшу проверок. VB в этом смысле был идеален. Следующий раз такое же удобство показал уже njkmrj C#. ))
С++ стал относительно неплох лишь к концу 90-х, и совсем неплох в нулевые, когда куча компиляторов стали утрясаться в совместимости вокруг C++03.
Поэтому, мне и были несколько странны обнаруженные здесь споры о языках в первой половине нулевых, да еще нападки представителей одних лагерей на другие.
Барство всё это. Позволять себе перебирать — это уже роскошь. ))
Всегда надо брать наиболее удобный инструмент.
V>>Всего-то требовалось слегка почистить С++, убрать опасные конструкции из "первой линии доступа", сразу же сделать подмножество SafeD.
V>>Но ребята малость увлеклись и просрали полимеры, увы...
N>Всё равно они все отнимают ниши у C и C++. И это достаточно правильно.
D мог отобрать достаточно много и да, сишники-плюсовики были отнюдь не против.
Многие рассматривали этот язык достаточно серьёзно (я тоже тратил своё время).
Какие проблемы часть кода в сишно-плюсовых проектах писать на D, если всё прекрасно линкуется-стыкуется?
Но они реально переборщили, далеко отошли от первоначальной неплохой задумки.
Искренне жаль.
Там Герб Саттер (один из главных в комитете по плюсам) пытается переосмыслить проблематику СИ-подобных языков и выкатить более выразительную и безопасную версию С++.
Пока что у него получается интересней, чем D, хотя тоже отошёл достаточно далеко от плюсов.
Но! В отличие от D, отход происходит лишь в тех местах, где нельзя не уйти для достижения тех или иных кач-в (т.е., можно принять за эдакий синтаксический сахарок), в отличие от D, где местами откровенная вкусовщина авторов.
https://github.com/hsutter/cppfront
https://hsutter.github.io/cppfront/welcome/hello-world/
N>Я писал недавно — в двух последних проектах, где активно был C++, он там был просто не нужен. Оптимумом был бы Go, и разработка шла бы в разы быстрее и проще.
У Go свои бока, увы. ))
Но тоже неплохой нишевый язык для несложных сервисов, которые можно вложить в механику языка.
Это более грамотный взгляд на проблематику Erlang, который в своём дизайне перебрал малость наивности-академичности. ))
(Выпороть бы авторов Erlang за загубленную неплохую идею... детсадище, блин...)
N>Но кто-то наверху считал, что если это формально embedded (с ARM/64 и 4-8GB рамы, ага), то ничего кроме сей не катит.
N>И таких в индустрии вагоны с тележками.
ХЗ.
Если механика Go реально нужна, т.е. если на С++ в любом случае придётся аналогичную механику описывать, то согласен.
А если не нужна, то нафига тащить лишний рантайм?
Если требуется писать более "традиционный" код, то на плюсах можно накидать его быстрее, бо быстрее найдёшь всё готовое сегодня.
Ну и, плюсовые сборки со статическими либами (стандартными и третьесторонними) берут в образ лишь то, что реально используется.
Глядишь, и вместо 4 гиг рамы хватит 256 метров. ))
В крупных партиях это даёт ощутимый профит, ес-но.
