Обновить
10
0

Пользователь

Отправить сообщение
Вы не чувствуете семантической разницы между «полностью дискредитирует» и «ваш пример дискредитирует»?
Вот, кстати, вывести с помощью ГА самый короткий код на Брейнфаке, который выводил бы «Hello, World!», было бы намного интереснее и поучительней.
Использование внутренних DSL — это вообще в мире CAD традиция возрастом в минимум лет 30. Не уверен, что найдется много CAD-ов, устроенных иначе.
На данный момент самый крутой результат — это полноценная (на молекулярном уровне выполненная, конечно же, не атомарном) модель одной очень простой бактерии. Так что, технология в принципе уже существует. Только вот такие вычислительные мощности, которые нужны для чего-то хоть немного более сложного, будут не ранее чем лет через двадцать.
По поводу пункта 4 немного не согласен. Надо написать две-три грязные итерации, после чего уже сесть, подумать, и грамотно всё спроектировать, зная уже про все подводные камни. Последняя, чистовая итерация будет уже правильной и красивой. Только надо помнить, что каждую новую итерацию надо писать с нуля, нельзя заимствовать ничего из предыдущих.
Повторяю вопрос — как один частный корявый пример может дискредитировать идею вообще?
А данный пример — это тоже поиск экстремума фитнес-функции. Только вот он единственный и известный заранее, что делает весь пример бесполезным.
Почему это один некорректный пример «полностью дискредитирует» давно себя отлично зарекомендовавшую идею?

При правильно подобранной фитнес-функции ГА работают очень неплохо, иногда им просто нет альтернативы.
У любого языка область применимости очень ограничена. Но знакомство с Фортом пллезно каждому, мозги неплохо прочищает.
Лисп не из той оперы. В Лиспе есть скобки, а RPN как раз позволяет от скобок избавиться.
Судя по такому восторженному рассказу про RPN, вам наверняка должен понравиться язык Форт.
> В общем, каждая страница, которая содержит больше Javascript, чем содержимого, должна быть отправлена в мусорное ведро.

Точно! google.com — в ведро! maps.google.com — в ведро! gmail.com — в ведро!
И, кстати, 10 лет назад озабоченных выжиманием производительности было ничуть не больше чем сейчас. Так что ваши выводы просто смешны.
Глупости говорите.

Тормозят програмы вовсе не от того, что программисты не озабочены поголовно выдавливанием всего что можно из железа. Любит народ примитивизировать всё.
Посмотрите мой последний пост в ненормальном программировании, там пример такого смешивания clr и llvm.
Как зачем? Если надо генерить код, зависящий от unmanaged библиотек, то как бы вариантов и нет.
Это как это?

Нельзя с CLR сделать небольших размеров standalone executable. Нельзя сделать callback, эффективно вызываемый из unmanaged. Нельзя без очень жесткого оверхеда вызывать unmanaged функции. P/Invoke — тот еще тормоз, да и calli не лучше.

Смотря каких случаев. LLVM — для unmanaged, CLR — для всего, что managed. Так что оптимальный вариант — смешивать их, а не пытаться на одном дела то, что лучше получается у другого.
LLVM существенно ниже уровнем, чем CLR. Так что нельзя даже сравнивать, у них абсолютно непересекающиеся применения.
Это ваше исключительно частное мнение. Не стоит считать, что хоть немного заметное в общей массе количество программистов его разделяет.

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность