Я вот зашел на github, поискал проекты на форте, и в общем-то ничего осмысленного не нашел. По большей части все эти проекты типа "мама, я написал компилятор форта!" Что-то не складывается ощущение, что на этом можно какие-то реальные задачи решать. Ну то есть понятно, что теоретически можно, но почему-то на практике никто этого не делает - видимо, другие инструменты оказываются удобнее.

А так-то язык красивый. Но и LISP красивый, а APL и J - вообще божественны. Но реальные задачи на них никто не решает.

Полагаю, это связано с тем, что красота языка напрямую связана с его логичностью и математической стройностью. А практические задачи полны алогичного говна, когда на каждое правило сто исключений, причем все очень плохо формализуемы. Или того, что если во время выполнения длительных вычислений пользователь желает видеть progress bar, то приходится в красивый foldr map засовывать определение процента завершения операции. И в итоге решение уродливой по своей природе задачи на красивом языке выглядит еще хуже, чем если сразу на PHP делать.

(Reply to this) (Thread)

тащемта, делают, и дофига. во-первых, немеряно проприетарщины (именно поэтому свифт и vfx всё ещё продаются, а не самозакопались, например).

во-вторых — как раз специфика языка. нормальный фортер не очень понимает, что такое «проект на форте», зачем его куда-то выкладывать, и каким вообще образом это сделать.

в третьих, у этого фортера кастомный диалект, в отрыве от которого код бесполезен.

и в четвёртых, очень часто и «проекта» как такового в привычном виде нет, а есть логи репла и сгенерёная под задчу через SAVE система.

именно поэтому я и говорю, что стандартизаторы очень боятся писать на форте, и пытаются превратить его в «нормальный язык». а не получается — после такого превращения форт становится абсолютно уродливой бесполезной хуетой.

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

вот, возьмём json-процессор, который мне понадобился, чтобы утуповое полимероговнище разгребать. какой смысл его выкладывать куда-либо, когда он сделан под кокретную задачу? да, он очень быстрый, парзит многомегабайтные жсоны за десятки миллисекунд, умеет их иерархически покаывать с фолдингом, позволяет тестировать некоторые выборки (в том числе въебать кусок форт-кода и посмотреть результат, не выходя «наружу»). но там нет никакой магии, и я совершенно не собираюсь делать из него Универсальную Жысон Библиотеку. потому что у меня совершенно другая задача — которую я решаю по заветам Чака Мура: «не пишите больше и сложнее того, что вам нужно для решения конкретной задачи».

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

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

а так-то форт не то чтобы красивый… он никакой. это просто удобный ассемблер для стековой машины, который написан сам на себе, и не прячет никаких своих потрохов. просто бери и расширяй его в любом направлении, которое тебе сегодня понадобилось. сам по себе форт очень простой, и формы не имеет — именно это в нём чудесно.

(Reply to this) (Parent) (Thread)

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

(Reply to this) (Parent) (Thread)

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

оно, конечно, code reuse is highly overrated, но это тема совсем другого выступления. а здесь я исключительно о том, что люди, которые вроде бы претендуют на понимание форта, пытаются выкинуть из него Суть, и уже не первый десяток лет удивляются, почему в итоге получается никому не интересное говно.

(Reply to this) (Parent) (Thread)

> о чём я, собственно, и пишу.

Мой комментарий был не совсем по теме поста, а просто про Форт. Я не настолько силен в вопросе, чтобы оценить, насколько неправы стандартизаторы Форта.

> code reuse is highly overrated

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

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

(Reply to this) (Parent) (Thread)

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

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

(Reply to this) (Parent) (Thread)

Вот у меня несколько другой опыт. Когда мне в новой конкретной задаче нужно сделать что-то, что я уже делал в другой задаче, в 90% случаев проще написать с нуля (с использованием накопленного опыта, конечно). Еще в 10% случаев старый код все-таки используется, но после обработки напильником до неузнаваемости. Попытки превратить такой код в библиотеку всегда заканчивались тем, что для каждого проекта "библиотеку" все равно приходилось допиливать - ну или проще было написать с нуля.

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

(Reply to this) (Parent) (Thread)

>в 90% случаев проще написать с нуля (с использованием накопленного опыта,
>конечно). Еще в 10% случаев старый код все-таки используется, но после обработки
>напильником до неузнаваемости.
я примерно про это же. а потом может наступить момент, когда почти ничего переписывать не надо — и это будет библиотека.

>и вот тут получался хороший реюзабельный код. Потому что я понятия не имел, кто и
>для чего эту библиотеку будет использовать, и писал в полном отрыве от конкретной
>задачи.
и вот эта библиотека — она решала задачу: «получить реюзабельный код». в основном именно эту задачу все библиотеки и решают. к сожалению, на практике таких задач нет, а какую именно задачу библиотека будет решать — авторы не знают. поэтому получается или куча мелких кубиков, из которых собрать то, что нужно, подчас сложнее, чем сделать с нуля конкретно то, что надо; или прибитое гвоздями к идее автора о том, что же с библиотекой будут делать; или засыпаное хуками сверху донизу, и всё равно одного нужного хука там нет; или… ну, ты понял нить рассуждений.

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

(Reply to this) (Parent) (Thread)

> или прибитое гвоздями к идее автора о том, что же с библиотекой будут делать

Это уже не библиотека, а фреймворк.

> пока разберёшься, как от неё добиться того, что тебе надо — часто уже успел бы написать и отладить свой код с нуля. или они вообще делают слишком много/мало и не так.

Ну, нет. Чтобы написать свой libfftw надо разбираться с векторными инструкциями (и желательно - нескрльких архитектур процессора); чтобы написать свой libpcap, надо разбираться с внутренностями драйвера ethernet (под linux и windows); при реализации алгоритмов шифрования легко обосраться с безопасностью (впрочем, авторы openssl тоже обосрались), libpng, libjpeg и zlib можно и с нуля написать, но это точно не быстрее, чем разобраться с тем, как они работают. Sqlite - там вообще нескольким людям на несколько лет работы. Это то, что я за последний год использовал. Ничего из этого я не хотел бы переписать своими руками. Точнее - у меня есть опыт написание собственного fft и собственного разбора jpg - и я трезво оцениваю, насколько сделанное за день на коленке хуже, чем то, что писалось и отлаживалось годами коллективом людей, которые только этим и занимались.

(Reply to this) (Parent) (Thread)

ну вот я имею опыт с той же libpng, и считаю её уёбищем. я не знаю, какие задачи она должна решать — но задачи удобной работы с png она не решает вообще. как раз потому, что у неё в принципе такой цели не было, у неё была цель «реализовать стандарт». в итоге я или пинаю imlib2 (которая тоже не сахар, но намного удобней для простых целей), или вообще взял из гоззы minipng и глобально обработал напильником (потому что идиот; лучше бы с нуля написал).

с либжопег, по ходу, всё ещё хуже. но там вдобавок формат уёбищный, и dct, и мне лень как парзер пилить, так и dct, так что при необходимости возьму, наверное, её. или спизжу код из stb_image.

для fft мне хватало kissfft. ну, у меня не было задач, где скорость настолько критична. были бы — наверное, взял бы fftw.

это всё ещё к той тонкой границе между нежеланием запариваться неудобными библиотеками и маниакальным желанием всё написать с нуля самому. однако почти все эти библиотеки всё равно неудобны — именно за счёт их универсальности.

реально — супероптимизирование по скорости далеко не всегда важно. и библиотеки часто берут «на вырост», кстати. ту же sqlite: да камон, её часто тянут туда, где достаточно было бы наколенного балансированого дерева с простейшим mmap (если ни вообще тупо массива с линейным/двоичным поиском). а картинку часто можно imagemagic-ом конвертнуть в какую-нибудь pnm и читать результат из stdin. и ты пы.

(Reply to this) (Parent) (Thread)

> и библиотеки часто берут «на вырост», кстати. ту же sqlite: да камон, её часто тянут туда, где достаточно было бы наколенного балансированого дерева с простейшим mmap

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

(Reply to this) (Parent) (Thread)

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

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

(Reply to this) (Parent) (Thread)

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

(Reply to this) (Parent) (Thread)

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

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

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

(Reply to this) (Parent)

извини, анончик, бот перевозбудился.

>Какое-то странное выходит «не больше и не сложнее». Вот у меня есть конкретная задача: взять изображение в формате PNG и посчитать его свертку с двухмерной функцей. Как это решается на няшной сишичке? Я беру библиотеку libpng, которая читает PNG-файл, беру libfftw, которая считает преобразование Фурье, а затем пишу код, который нужен для решения конкретной задачи - и только его. А на Форте я должен написать собственный компилятор, собственный разбор PNG (а лучше и разбор FAT32 тоже самому написать), собственное преобразование Фурье - ну а потом уже решить конкретную задачу. Многовато и сложновато выходит.

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

хотя что такого сложного в разборе пнг — я не знаю. равно как и в простом fft. в зависимости от настроения — я бы, может, и написал с нуля.

впрочем, кто тебе, опять же, запрещает использовать из форта libpng и libfftw — я не знаю. это вполне может подпадать под «не пишите больше и сложнее». я вот для гуёв не стал писать прямую работу с протоколом X11 (хотя это и не так сложно), а спокойно дёргаю Xlib.

(Reply to this) (Parent) (Thread)

> ну так не бери форт, никто же не заставляет

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

> равно как и в простом fft. в зависимости от настроения — я бы, может, и написал с нуля.

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

(Reply to this) (Parent) (Thread)

дык дёргай библиотеки, никаких проблем же. есть трудноописываемый словами, но через некоторое время ощущаемый «нутром» баланс между «ищем библиотеку для leftpad» и «пишем заново с нуля вообще всё». все форты, живущие поверх ОС, имеют возможность дёргать динамические библиотеки (если в ОС они есть).

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

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

лично мне — очень удобно, потому что я софт примерно так и «выращиваю». форт меня освобождает от кучи синтаксического мусора. вдобавок — жестко пресекает попытки делать говнокод: если я начинаю путаться в том, что у меня на стеке, то это значит, что я пишу говнокод, надо факторить.

(Reply to this) (Parent) (Thread)

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

Это я как раз хорошо понимаю - в LISPе и J (да и, наверное, в любом функциональном языке, у которого есть интерпретатор с REPLом) все точно так же: добавляешь слово за словом, и в каждом новом слове все больше и больше магии. Ощущения божественные, конечно.

(Reply to this) (Parent) (Thread)

да. примерно поэтому я ставлю более-менее в один ряд форт, лисп, смолтолк и прочие подобные. у многих из них ещё и внутренняя механика парзера и компилятора не запрятана под семь слоёв бетона, так что по дороге ещё и DSL сам собой получается.

правда, это часто вступает в жестокую войну с привычками из «тяжёлых» компилируемых языков. то хочется по привычке сделать слово на пол-экрана, то написать дофига кода сразу, то ещё фигня какая. я вообще лет на 10+ форт забросил, потому что он адски конфликтовал с «нормальными практиками программирования». если бы не решил оживить dsForth для спекки — возможно, и не вернулся бы. в итоге сначала впилил кривожопый форт в кросс-асм для z80, чтобы обрабатывать фортом код на форте, лол, а потом решил весь асм на форте переделать. по дороге вспомнил, что программировать — это, оказывается, удовольствие и от процесса в том числе. и, как полагается, обнаружил у существующих форт-систем Фатальный Недостаток.

(Reply to this) (Parent)

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

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

(Reply to this) (Parent) (Thread)

>Как встроенный язык с REPL самое то же.
вряд ли. тебе это или кастрировать до упора, или как ты собрался контролировать? даже если посадить глубоко в вм — одна ошибка, и твой скрипт засыпал всю память вм рандомным мусором. а если так нельзя — то какой это нахуй форт тогда…

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

(Reply to this) (Parent) (Thread)

> одна ошибка, и твой скрипт засыпал всю память вм рандомным мусором.
Как говорится, "и чо?". Прибью клиент и запущу заново, это его нормальное поведение: как раз недавно очередной казус был, когда при раскрытии определённой структуры всё намертво висло. А там просто в настройках отображения не то свойство прописали, клиент выстреливал парой сотен окошек с сообщением об ошибке, отчего всё пухло и дохло.

>динамически произвольные методы вызывать
Через рефлексию тащем-та никаких проблем кроме скорости.
Засада начинается, когда у объекта методов add штук пять разных.

(Reply to this) (Parent) (Thread)

>Как говорится, "и чо?".
ну, просто это не совсем то, чего обычно ожидают от скриптов.

>Засада начинается, когда у объекта методов add штук пять разных.
ну так если их по сигнатурам можно различить — то так и различать. со стороны форта каждому по уникальному алиасу раздать просто.

(Reply to this) (Parent)