Comments | sergeydmitriev: Новый подход к программированию

sergeydmitriev

Новый подход к программированию - интервью

Jul 08, 2004 11:48

Когда я был на JavaOne на прошлой неделе то дал интервью Джеку Хэррингтону - он автор книжки "Code Generation in Action", а также он поддерживает web-site посвященный генерации кода - http://www.codegeneration.netRead more... )

language_oriented_programming

Comments 41

dr_klm July 8 2004, 17:28:53 UTC

Поздравляю. Я смотрю, идея уже сильно трансформировалась... ;-)))

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

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

Но, как говорится, хозяин-барин... ;-))) Хотя, мне кажется, можно было-бы и эффективнее распорядиться ресурсами... ну ладно...

А вот пивка нам с Вами как нибудь можно было-бы и выпить... Оно, глядишь, может и кое что из моего кода (которого, как заявили в предыдущей записи, я написал мало) Вам могло-бы пригодиться... я даже подозреваю что... ;-)

К.Л.М.

sergeydmitriev July 8 2004, 19:33:16 UTC

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

dr_klm July 9 2004, 16:23:05 UTC

Поздравления совершенно искренние !

IDE для компиляторов-компиляторов... IDE для редакторов... реализованная сама в себе... Дык это-же Emacs ! ;-)) Любая программа развивается до тех пор, пока у нее не появляется функция чтения электронной почты (© Stallman, по-моему)... ;-))) Шучу, шучу...

Ну... в 17:00 это уже почти ужин... ;-) Но я тоже сова, понимаю... завтракаю в 12:30... YHM на адресе @intellij. Познакомимся, поговорим, разберемся...

Лично меня в последнее время вот эта штука (язык J) очень сильно зацепила.

К.Л.М.

sergeydmitriev July 11 2004, 20:12:34 UTC

Я почитал ваш постинг про язык J, и, похоже у нас с Вами существенное отличие в понимании того, что такое красивая программа или язык, а что нет.
При условии конечно что весь постинг не был шуткой. Впрочем, он оказался хорошим поводом продемонстрировать силу language-oriented подхода.

Итак, в моем понимании Ваш пример написанный на языке J выглядит абсолютно ужасно.

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

Давайте рассмотрим Ваш пример подробнее. Стоит задача - найти выпуклую оболочку для заданного множества точек на плоскости. По Вашим же словам:

Алгоритм этот заключается в том, чтобы

1. Отсортировать точки по углам, относительно самой левой из них (которая по определению принадлежит оболочке).
2. А потом, пройдя по образовавшемуся звездообразному контуру ( ... )

Thread 14

ait July 9 2004, 08:20:12 UTC

Хорошее интервью, Сергей. Спасибо.

И это только начало anonymous July 10 2004, 14:02:13 UTC

Сергей, я не нашел в твоём интервью достаточно важной детали. Я сейчас попытаюсь её изобразить. Начну с аналогии ( ... )

Re: И это только начало _qwerty July 13 2004, 21:00:43 UTC

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

Кодоненерация, напротив, весьма полезна для:
1. отладки
2. раскрутки
3. во избежание впадания в крайности

продолжение anonymous July 10 2004, 14:03:39 UTC

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

Re: продолжение _qwerty July 13 2004, 21:08:57 UTC

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

продолжение anonymous July 10 2004, 14:04:33 UTC

Итак, IDE как-бы становится нечего делать. Ан нет, есть что! Уже существуют разного рода верификаторы и аудиторы программ. Они проверяют её на нетривиальные ошибки - анализируя в целом. Конечно, запустить её, она весь проект компилирует, а потом анализирует, да ещё и делает достаточно сложный анализ - это от 5 минут на небольшом проекте до нескольких часов на приличного размера проекте. Что же мы имеем храня программу в виде дерева? Мы имеем возможность проводить именно этот, сложный, нетривиальный анализ всей программы в целом - и проводить его в реал-тайме. Немедленно. То есть, предположим, анализ уже проведён. Мы знаем о программе всё, в том числе и что от чего зависит. Теперь мы поменяли какой-то узел. Скажем, раньше был метод foo() { return ""; }, а стал foo() { return null; }. Мы поменяли узел "return" и сразу видим - возвращается null, а раньше был не-null. Мы знаем все места, где этот метод используется - и можем быстро (в фоне) проверить эти узлы - не выскочит ли там NullPointerException? Это достаточно примитивный пример, ( ... )

Re: продолжение _qwerty July 13 2004, 21:14:44 UTC

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