Ну вообще-то я рассказал о некоторых своих наблюдениях и нескольких путях использования Форта в его текущем виде. Ты же постоянно все сводишь к своему оптимизатору.

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

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



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

Вот ты как-то в качестве иллюстрации давал ссылку на проданный тобой продукт. Три продажи по 15 центов, на общую сумму 45 центов. За полтора года. Это нормально с учетом "развития системы микроплатежей" и прочего? Полтора года можно прожить на 45 центов?

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

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

Об оптимизаторе при том не говорилось(разве об инлайн-подстановках немного).
Реклама, одним словом, это была.

Только этого не достаточно, чтобы кодировать алгоритмы для реальных задач.

Инлайн, производительность... имхо - всё это технические проблемы, причём пути решения которых хотя-бы намечены. Лучше бы предложили идею, как увеличить производительность труда программиста - вот что актуально-то. А иначе Форт так и останется "языком для микроприменений".

Я над это проблемой уже давно голову ломаю, но 100% решения не вижу...

Полностью потдерживаю.

Я вижу, нужно только оформить в текст

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

Например, тестирование Форт-систем на синтетических тестах не бесполезно,

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


P.S. Согласен, что эффективность программного кода без сделанного прототипа
оценить трудно. Поэтому важно, иметь хоть в какой то степени
эффективный оптимизатор, чтобы были прикидочные результаты, а далее
по обстоятельствам.
Опровергнут или подтверждён миф о быстроте Форт программ
и в частности SPF - не знаю:)

Когда-то я пробовал такое делать, но потом обнаружил слабую коррелированность синтетических тестов с реальной ситуацией (данные не помещаются в кэше, а то и выгружены на диск, и все форты вдруг стали какими-то одинаковыми), и практически наплевательское отношение окружающих к колебаниям производительности конкретных программ. Если она одна такая, то с чем сравнивать-то? А если экран не моргает, то какая разница, сколько там fps? Ну а уж если ползет progress bar, то ясно, что надо подождать. Лишь бы не в разы медленнее.


Миф первый - программа на Форте никогда не угонится за программой на Си. Пример - программа на Форте с ассемблерной вставкой работает 2 минуты. Программа на Си (без ассемблерной вставки) - 15 (надеемся на оптимизацию).

Миф второй - без оптимизатора в Форте никуда. Этакий элемент компромисса - надо же быть чем-то на "большие" языки похожими. При этом до тех пор, пока оптимизатор не сможет сам принимать решения вида "заменим это на код в SSE над выровненными данными", будут только мелкие локальные улучшения. И почему вдруг у грамотного программиста, знающего ассемблер, должен вдруг наступать паралич при необходимости написать 10 строк руками, мне совершенно непонятно. Более того, то, что в коде Форта подлежит оптимизации, обычно играет очень несущественную роль в общем времени выполнения.

достаточно того, что наличие оптимизации влияет на психологию программистов

алгоритм одинаковый?

Ждём-с... Было бы весьма интересно услышать идеи...
Мне в голову приходила недавно мысля сделать некоторый Форт
"верхнего уровня", по сравнению с существующим стандартом.
Т.е. рассчитанным на мощные машины и не совместимый с
"низкоуровневым" Фортом. Там помимо кучи синтаксического сахара и
таких фишек, как большого числа стеков (для разного типа данных),
должны были бы быть стандартные строки, ООП, _стандартный_
функционал для инфиксной записи математических операций и т.д.
Но потом понял, что всё это, в лучшем случае, приблизит
производительность программиста к C++, но не более того -
т.к. никаких принципиальных прорывов не предвидится. Так что
толку в существовании такого ЯП нет совершенно...

Вот так вот.

Конечно. Просто в Си запись "естественно-математическая", и уж как скомпилировалось, так и заработало, а в Форте то же самое удалось вручную разложить в стеке сопроцессора.

А чего, по моему не плохая идея то, вот вам и типизация по фортовски! Типизация через стеки.

И куча слов, что и как скрещивать между собой:)

Зы: Немного посмотрел на J-язык, так там для управления большим количеством выразительных возможностей языка ввели суфиксы, префиксы, наречия ...
Например:
< меньше
<. меньшее
+/ 1 2 3 понимается как 1+2+3
$ имя даст размер объекта, а в применении другого контекста что то другое.
и куча ещё языковых изысков, которые сразу и не понимаещь:) даже как применять.