Говно без души.

Он слишком минималистичен, хотя для хелловордов самое то

Цитата

---

Я как-то наткнулся на статью Криса Касперски про саморасширяющиеся языки Forth и Lisp и меня зацепило.

---

Практически любой интерпретируемый язык можно сделать самомодифицирующимся.

Цитата

---

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

---

PostScript пробовали?

Цитата

---

есть ли среда, ещё более простая и удобная, чем BEE Lisp? (Вот только не надо про Emacs!)

---

Можете попробовать DrRacket. Хотя почему не emacs?

Цитата

---

И второй вопрос: у него есть проблемы с надёжностью?

---

Возможно, я BEE Lisp ломать не пытался Если вас не волнует производительность, тогда почему интересует надежность?

BeeLisp платный, свою стоимость он оправдывает тем, что может делать dll и exe файлы, и какими-то ещё волшебными плюшками. При этом стандартов он не поддерживает, то есть если даже ХюСе уже на CL не прокатывает, то BL и подавно.
Не зная лисп подстраивать себя под нечто ИМХО не стоит. Есть CL, есть Scheme, есть Racket, есть Clojure, у всех вышеперечисленных есть документация и книги. Говорить о преимуществах одного над другим не стоит, это скорее конфессии.

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

Вот несколько признаков, по которым можно априорно составить мнение (которое, разумеется, может оказаться ошибочным) о надёжности ПО:
1. Популярность проекта, выраженная в человекогодах. Чем старее проект, и чем больше людей им пользуются, тем меньше вероятность, что кто-то пропустил какой-то глюк. Но к нулю эту вероятность свести нельзя. Совсем недавно был найдет баг в интерпретаторе языка Unicon, который старше, чем сам этот язык. Дело в том, что Unicon - наследник Icon. И там нашли баг, который оставался незамеченным более 20 лет.

2. Кто разработчик? Одно дело - индивидуальный разработчик, вполне могущий оказаться студентом-говнокодером, и гигантская корпорация. Сюда же можно отнести такой признак, как опенсорсность, потому что любой мимопроходящий может исполнить роль тестера или корректора.

3. Чётко намеченные цели разработки и жёсткая стандартизация. Я видел проекты, которые развиваются по принципу "у Вовки есть игрушечный самосвал, а я чем хуже?" Как ни странно, я бы назвал этот признак самым главным. Если есть нацеленность на конкретную, пусть даже очень узкую, рыночную нишу, то рано или поздно люди из этой ниши заинтересуются, распробуют, и остальные два признака приложатся сами собой.

Цитата

---

Это сродни гаданию на кофейной гуще.

---

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

Цитата

---

Открываем учебник по теории вероятности и прорешиваем задачи на определение надёжности приборов.

---

С приборами все гораздо объективнее, чем с софтом. Ну, например, ты можешь определить степень надежности выбранного мною программного продукта? Или какой-нибудь библиотеки? Или какова вероятность отказа функции sleep в Racket, которая однажды привела к уязвимости моего фтп-сервера к атакам типа брутфорс.

Цитата

---

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

---

Это само собой разумеется.

Цитата

---

Есть нагрузочное тестирование, которое проводится (ну в общем то также, как и с приборами) в течение положенного времени.

---

Результат сильно зависит от количества и качества самих тестов.

Цитата

---

То, что создатели бесплатного ПО не заморачиваются на тестирование,- так у них времени нет на это.

---

И денег Для них(и меня в том числе) бесплатные бета-тестеры - мечта

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

Цитата

---

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

---

Да, но к "надежности" это не имеет никакого отношения. И кроме того требуется наличие конкурента(ов).

Цитата

---

Есть ещё боты, которые способны заменить тестеров и т.д.

---

Их еще нужно создать или купить, но так или иначе для них еще нужно подготовить тесты.

Цитата

---

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

---

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