FORTH vs компилятор бейсика vs C++/Pascal/остальное

[andrews]

Я Оберона не касаюсь. Просто больших проектов у меня нет, а на экзотике проще выехать. Это как в боксе. Легковесов дополна и скольких надо побить прежде чем до финала доберешься. А если ты полутяж, то пару боев и ты уже в финале. Сделай что-то из ряда вон и тебя отметят. А на некоммерческих проектах, чем меньше трудозатраты и чем проще за тобой последовать - тем привлекательней для других.

- - - Добавлено - - -

А на Форте если надо сделать прогу посложнее HelloWorld, уже надо дописывать компилятор, заодно и интерпретатор

да Вы ж сами и показывали, как на Форте ПЗУ Zx Spectrum-а использовать. Мне понравилось.

[Oleg N. Cher]

andrews, к Вам претензий нет)

Но важное уточнение: Оберон хороший язык для разработки больших и сложных систем. Юзать его для ретро это я сгоряча придумал ;-)

[andrews]

Ну если с нормальным IDE, эмулятором и отладчиком и справочной системой на десктопе, то почему бы и нет? Главное примеров побольше и автоматизации. Чтобы первые простенькие проекты можно было сделать максимум за полчаса-час. "Большую и сложную систему" без мотивации(финансирования) вряд ли кто-то станет делать. Разве что у человека денег девать некуда. И нужно после себя что-то оставить. Впрочем я могу ошибаться. Я не социалист и не альтруист ведь.

[Oleg N. Cher]

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

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

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

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

[zx_gamer]

Вот это странно, что C++ тоже медленнее FORTH. Или он тут наоборот, среди тех немногих, которые не вошли в группу "превосходит почти все существующие языки программирования"?

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

Вот например как на С создать строку (на куче)?
char* string_name = malloc(sizeof(char)*LENGTH);
if(!string_name) {
perror("Malloc error");
exit(1);
}

А как это сделать на С++?

std::string string_name;

При ручном управлении памятью (на С) вы просто выделите память, при использовании контейнера std::string (в С++) вы вызовите конструктор класса, который выделит память. У этого контейнера есть методы, которые позволяют "дописать" что-то к строке. (это метод operator+), позволяют узнать длину строки и т.д. и т.п.
Безусловно, это удобно, но это несет накладные расходы, потому что при "добавлении" чего-то к строке у вас вызовется реаллокатор памяти.

Конечно, вы можете писать на С++ как на С. Но какой смысл тогда использовать С++?

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

[Lethargeek]

Ну, потому, что передача данных через стек - это основной способ передачи параметров между "словами" форта.

у кого основной, а у кого и нет, ты никак не въедешь, что в форте нет жёстких ограничений
никто же не запрещает, например, передавать между процедурами только ссылки на объект (ОДИН тип)
никто не запрещает навернуть парсер, чтобы пропускал только безопасный код, а небезопасный сам генерировал

- - - Добавлено - - -

Я Форт стараюсь критиковать объективно, имея опыт работы и на Обероне, и на Форте.

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

Впрочем, замечание про ретро может говорить о том, что ты прозреваешь))

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

Ууу, это надо после школы или ВУЗа лет так 20 не иметь дела с актуальным программированием вообще, но при этом и Паскаль не забыть. Много ли таких "начинающих"?

[Advertiser]

[inozemcew]

никто же не запрещает, например, передавать между процедурами только ссылки на объект (ОДИН тип)

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

Что делать со стандартными "словами" форта, коих дофига и все они "небезопасные"? Писать обертки на каждое? Что делать с теми "словами", что сами парсят ввод на этапе компиляции, ведь никакой вложенности для таких вещей не предусмотрено? Их как оборачивать?

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

никто не запрещает навернуть парсер

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

Ну и для 8ми битных машинок все эти попытки добавить в форт фичи из нормальных языков - это как приварить к велосипеду кабину от самосвала.

[Lethargeek]

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

и опять "раз я не представляю как того добиться, ЗНАЧИТ НЕЛЬЗЯ"
так, по имени в стек их может положить сама процедура (а точнее, код этапа компиляции, формирующий код этапа выполнения в словаре)
если уже в стеке, значит, это передача по ссылке, которая и в традиционных языках не гарантирует безопасности
но можно запилить рантаймовые проверки, даже в сам объект их встраивать при желании

Что делать со стандартными "словами" форта, коих дофига и все они "небезопасные"?

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

Писать обертки на каждое? Что делать с теми "словами", что сами парсят ввод на этапе компиляции, ведь никакой вложенности для таких вещей не предусмотрено? Их как оборачивать?

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

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

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

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

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

Ну и для 8ми битных машинок все эти попытки добавить в форт фичи из нормальных языков - это как приварить к велосипеду кабину от самосвала.

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

[Oleg N. Cher]

у кого основной, а у кого и нет, ты никак не въедешь, что в форте нет жёстких ограничений

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

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

Хаха, "навернуть". Можно навернуть, а можно и не навернуть. Скорее всего, не навернут. Поленятся. Зачем наворачивать что-то безопасное поверх языка, в котором половина оперируемых словами значений на стеке это адреса?

Вот уж блин теоретик. Я тоже в чём-то люблю подход Форта. Но я даже не готов сформулировать, в чём именно. Мне нравится одна биологическая аналогия: дождевой червь очень гибкий, но не может стоять вертикально. У человека и близко нет той же гибкости, но он за счёт грамотного устроения костей может многое такое, на что неспособен червь. Это и есть разумная жёсткость, которая просто необходима в программировании. Оберон даёт грамотные абстракции: модуль, ссылка, процедура со строгой проверкой типов параметров. На Форте всё это надо изобретать. Абстракции Форта не человеческие, а машинные.

Так что Вирт известен в программировании тем, что определил чёткий базовый минимум именно человеко-ориентированных абстракций, удобных для программирования. Он вывел основу, базис. А Мур просто хитро запрограммировал телескоп на компе с минимумом ОЗУ

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

Так что здесь меня поймут те, кто разрабатывал крупные проекты на Java и C#, но Оберон более близко к железу и без виртуальных машин. Это чистый натив. Даже если сборщик мусора не нужен - отключи да и всё.

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

Категорически не согласен. От проверок, которые предлагает язык, откажется только мамкин кулхацкер, гордый своими подвигами в отладке. Даже при разработке для слабенького контроллера проверки экономят много времени и сил, а потом легко отрубаются. Надёжный Оберон не отрицает небезопасной работы с железом и даже предусматривает для этого специальный псевдомодуль SYSTEM, в котором сосредоточены все опасные средства. Зато если ими не пользоваться - количество узких мест сильно сокращается. Не полностью, но очень значительно. Мы легко спускаемся из Оберона на низкий уровень. Это из C# или Java не так просто сделать, ибо не натив и всё равно тянет виртуальную машину. А на Обероне легко.

Впрочем, замечание про ретро может говорить о том, что ты прозреваешь))

Я знаю, что на ретро проверки неэффективны, а чтобы выдавить из машинки всё - надо работать только на асме, притом с трюками. Но чтобы выжать из железа всё - тут даже Форт будет не так уж и хорош.

Ууу, это надо после школы или ВУЗа лет так 20 не иметь дела с актуальным программированием вообще, но при этом и Паскаль не забыть. Много ли таких "начинающих"?

Паскаль это основа, там есть всё, чтобы программировать. И, в то же время, он достаточно прост.

[Smalovsky]

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