← Новости vpri.org -- итоги первого года проекта STEPS
Обсуждение
Читать и комментировать в ЖЖ ↗
13 пунктов выглядят мощно. Это уже существующее или мечты?
Комментарий
Читайте отчет. Это принципы, они в мозгах существуют, причем по многу лет. Просто в проекте STEPS эти принципы проводятся последовательно (или параллельно ;)
Комментарий
Не думал, что кто то еще пытается опримизировать размер кода.
Я даже знаю когда игрушки разливали на 2 диска, вместо одного... для солидности и повышения цены.
Комментарий
Я английский хоть и понимаю, но не на столько хорошо, что бы свободно читать техническую литературу. Меня, как конечно пользователя (программиста), интересует на сколько эффективно я смогу решать задачу с помощью инструмента. Если фраза "Universal graphic primitives" мне видится самодостаточной вещью, которую можно просто использовать по частям, то фразы типа "Universal end-use object" и "Set of support for all meanings", звучит как "подключи тяжёлую библиотеку, потрать на её настройку массу времени и тогда оно будет работать так же, как если бы ты написал узкоспециализированный объект специально для конкретной задачи".
Комментарий
Я все-таки советую не фантазировать, а читать.
Комментарий
вот что странно. если не брать в расчёт славное прошлое участников проекта (того же Алана Кея, например), то сам проект пока не дал ни новых идей, ни _качественно_ новых имплементаций старых.
прорыв в programming language design и software architecture будет. но я ставлю не на них.
Комментарий
Мне как раз кажется, что проект дал именно что имплементацию нескольких старых идей. Там реальный прорыв в combined lambda object. И Ometa весьма интересная разработка. И много чего еще интересного (реализация того же TCP/IP стека в 200 строк).
Если вы ставите не на них, то на кого?
Комментарий
Некоторые до сих пор стараются прочитать и понять код. В этом случае размер - критичен. Потом опять же - этот код потом модифицировать придется. А для этого - прочитать и понять.
Комментарий
у меня всё это в списке любимых тем последние лет пять. есть и свой подход к системе типов, позволяющей свободно использовать преимущества и OOP, и FP техник. и к практически-декларативной реализации парсинга бинарных потоков на этой системе (нативно, без добавления внутреннего DSL).
и это лучше, чем STEPS. поэтому ставлю в первую очередь на себя. даже при отсутствии тех грантов и инвестиций - я на своём месте и верю в свои возможности.
помимо этого. самое интересное, что находил за последнее время, как правило относилось к локальным проектам (как крупных компаний, так и отдельных разработчиков), ориентированным на одну цель или нишу. в плане наиболее важных research я ставлю на них.
http://metalua.blogspot.com/ - один из таких проектов. без сверхновых идей. лучшая на данный момент реализация metaprogramming средствами самого языка. на порядок выше по качеству и удобству не только классической лисповской линии, но и реализаций в сегодняшних языках программирования (макросы Nemerle, etc). не ждал такого от "незаметного" проекта и был приятно удивлён.
что же касается production, то наиболее привлекательные результаты по развитию языков программирования сейчас показывают Microsoft, с языками платформы .Net, и Python community, при поддержке Google. по части IDE/framework - более специфично, Smalltalk-линия и Java-линия пересекаются слабо и очень завязаны на семантику низлежащих языков и соответствующую психологию.
Комментарий
Только недавно по вашей ссылке скачивал презентацию, где покаано на графиках, как это все стмительно ускоряется и при этом дешевеет...
Так зачем тратить массу дорогостоящего времени на написание компактных кодов, если память стоит копейки и дальше будет только дешеветь?
Они оценили, сколько памяти высвободится в мировом масштабе? Так ее пользователи все равно загадят - скинув на диск пару фильмов, которые потом забудут посмотреть...
Комментарий
Спасибо за vpri.org - про scalable_scripting_ пропустил. Рад, что статья новая.
Соотношение понятий: "ЯП", "код", "читабильность кода","длина кода" меняется с изменением технологий программирования.
Случай, когда машина будет программировать машину, а человек будет пытаться разобраться в такой программе, не лежит только в плоскости "человеческих" языков, как было до сих пор.
Комментарий
Lua здесь засветился. Приятно.
Комментарий
Там другие аргументы: если система (вся!) занимает 400 страниц текста, то ее можно понять (понять -- это ведь в принципе для одного человека действие ;)
Память и аппаратура тут не при чем. Хотя они и грозятся скорость вычислений в 1000 раз увеличить на последовательных операциях за счет изменения аппаратной архитектуры...
Комментарий
Обязательно смотреть реализацию морфика на джаваскрипте. Там есть, кстати, ссылка на фильм -- очень убеждает (http://research.sun.com/projects/lively/).
Комментарий
"лучше, чем STEPS" -- в каком смысле лучше? Вы сможете написать систему не в 20тыс.LOC, а в 5? Грузануть в нее не десяток пробных языков, а сотню -- и каждый будет описан не парой сотен строк, а пятьюдесятью?
Или у вас какое-то своё понимание "лучше"?
Метапрограммирование, конечно, не сегодня придумано. Проектов в этой области всегда было много. Интересно, по каким критериям вы отбираете интересные.
Комментарий
Ну вот у нас система на 400 страницах, ее поняли 200 человек, творчески доработали, и теперь у нас 200 систем, каждая на 450-500 страницах... :-) И что дальше?
Комментарий
Пока что впечатление от реализации неоднозначное. Написано забавно (надо, и обязательно буду, копаться подробнее), но работает (в тех местах, где работает, а работает не во всех своих местах), прошу прощения, почти что режиме пошаговой стратегии. Первое впечатление -- опять за компактность и/или понятность кода заплатили скоростью. Причём щедро так заплатили. На этот раз довольно необычным способом.
Комментарий
это должно настораживать Настоящий Пацан Программист априори написанное не им недостойным внимания. Комментариев он тоже не пишет, поскольку его код и так гениален:)
Комментарий
"лучше" - скорость написания, лёгкость чтения, отлаживаемость. меньший или сходный объём. да, это возможно.
кроме того, "описывать сотню языков" нет смысла, их будет не так много. при хорошем дизайне базового языка в большинстве случаев даже syntax extension не понадобится, domain-specific функционал удобно поместится в библиотеку. не-текстовые представления тоже могут использовать общие базовые определения. dependency graph в Autodesk Maya отличается от схемы в модульном софтсинте не столько семантикой, сколько стилем view.
у меня такое видение. своё видение. как и видение ошибок дизайна многих увлекательных языков/видов - Lisp, Smalltalk, Haskell, ... - ошибок не в computer science, а именно в психологии, из-за которых они так и не стали достаточно привлекательны для пользователя.
когда-нибудь различные сегодняшние проекты "взлетят" до уровня использования в commercial applications. посмотрим. сравним.
что касается интересных проектов - они дают что-то новое в копилку знаний и представлений о теме. metalua представляет хорошую спецификацию мета-уровней и новый красивый синтаксис их разделения в рамках одного и того же ЯП. OMeta - не даёт ничего, только пробуждает воспоминание о Parsec (http://legacy.cs.uu.nl/daan/parsec.html), который несколько лет назад был очень интересным экспириенсом для ознакомления.
Комментарий
Lua минималистичен. изначально почти ничего не может, но, например, система классов с динамической перезагрузкой кода/зависимостей там делается очень просто, даже без внешних мета-средств.