Re[16]: Языки общего назначения не имеют смысла! - Философия программирования

Здравствуйте, Ikemefula, Вы писали:

I>С нуля что ли ? Студенты пишут всё с _нуля_. то есть, твоя производительность не в 100 раз, а всего в 14 раз больше, чем у студента третьего курса

Что они пишут?
Они пишут кривой компилятор.
Который генерирует тормозной код с кучей ошибок.
Отладка, ИДЕ и оптимизации в эти две недели не входят. Доведение компилятора до промышленного качества тоже.
Добавь все это и получишь лет 5.

I>Смешно. Я хорошо представляю за какое время студенты осваивают регулярные выражения, sql и тд.
Это, смотря какие студенты.

I>>>>>Правильно. Только сложность там специфике бизнеса и совершенно необязательно код должен быть таким же сложным.
WH>>>>Каким сложным? Ты хоть знаешь что такое FizzBuzz?
I>>>Давно перестал опохмеляться ?
WH>>Кроме демагогии аргументы будут?
I>Ты сам начал

Что я начал? Это ты тут вещаешь, что FizzBuzz сложнее бизнеслогики.

I>>>Извини, с того времени у меня сменилось два компа и такой мусор я не храню.
WH>>Понятно. Фактов нет.
I>Когда были факты, вы все хором обвиняли людей в тупизне.
У тебя их никогда не было.

I>>>Мелочовочка. Единственная серьезная проблема у Микрософта это отказ от J# в 2008й вижле.
WH>>У мелкософта значит мелочевка, а в немерле конец света.
WH>>Двойные стандарты на марше.
I>Попробуй перечитать внимательно. Мелочовочка — это про твои ссылки. J# это "серьезная проблема". И да, это конец света, для J# разумеется. Мы вот в свое время вляпались, сейчас есть 10% важного кода который ни портировать, ни переписать за разумное время нельзя, потому переход на 4.0 откладывается уже целый год.
Причём тут J#?
Ты тут утверждал про какие-то фатальные проблемы с обратной совместимостью немерла.

I>>>Поздравляю тебя, соврамши "Народ сошёлся на том, что поломанные макросы не большая проблема." @ Wolfhound
WH>>Разговор шел про Н2!
I>Когда будет следующий релиз немерле ?
Спроси у Влада. Я немерлом не занимаюсь. Я туда влезаю, только если мне нужны фичи которых еще нет в компиляторе.

I>Хорошо, один из вариантов — такой же файлик, как и принимаем у юзера. Второй вариант — xml на старом дсл, нужен для обратной совместимости. Третий вариант еще не появился, это будет какой нибудь шустрый ОРМ, пока здесь препятствие наша вычислительная модель которая оптимизировалась под перформанс операций, а не персистанс.
Я ничего не понял.

WH>>Из твоих примеров я понял только то, что все можно свести к некому подобию реляционной модели.
I>Спасибо, капитан, скажи что нибудь менее очевидное.
Из той информации, что ты дал что-то еще вытащить очень трудно.

WH>>Описываем ограничения. Они автоматически проверятся и выведутся в лог.
WH>>Далее описываем процедуру импорта.
WH>>Опять же отдельно описываем ограничения на результирующую модель приложения.
WH>>Они так же будут автоматам проверятся при всех операциях с моделью приложения.
I>Покажи какая модель будет использоваться для этих четырех строчек и как будет выглядеть ДСЛ.

Примерно так: закладка NetworkElement, колонка SiteName указывает имя объекта-привязки это Site. По нему нужно найти объект SiteFitout или создать если такой отсутствует. Колонка Name содержит имя элемента, который принадлежит SiteFitout, если такой существует, то выдать мессагу и продолжить с новой строчки
Если нет, то создать новый, при этом свойства нового нужно вычислить по колонкам в файле. Где то нужно брать дефолтное, где то нужно брать нуль, где то нужно вычислять по содержимомум колонок или даже сгонять в модель за значением. "Сгонять в модель" == выполнить запрос по модели.

Из этого мало что понятно можно получить что-то типа такого

// Общая модель приложения
table SiteFitout
    field SiteName : String;
end

// Это ограничение на модель
// Проверяется при каждой транзакции
check uniq SiteFitout.SiteName
error $"$SiteName blablabla";

//========================
// Конкретный импорт
table SiteNames
    field SiteName : String;
end

import to SiteNames
    SiteName <- NetworkElement.SiteName
end

check uniq SiteNames.SiteName
error $"$SiteName blablabla";

check SiteNames.SiteName not in SiteFitout.SiteName
error $"$SiteName blablabla";

Чтобы написать остальное не хватает информации.

WH>>И кто же этот ДСЛ сделал? Уж не человек ли который FizzBuzz осилить не смог?
I>Его делал человек который фактически был архитектором, сарказм абсолютно неуместен.
Одно другому не мешает. Особенно если верить тебе что подавляющее большинство программистов не могут FizzBuzz.

WH>>Кстати можешь показать код на этом ДСЛ?
I>

I>Column="Node" 
I>Type="string"
I>ImportPath="ServiceEndA.Node"
I>ExportPath="ServiceEndA.Node.Site.Name"
I>ConvertImport="FindOrCreate(Root.NetworkStructure.ServiceLayer.Nodes, Site, FindObjByName(Root.SiteMap.Sites, ColumnValue, typeof(Site)), typeof(Node))"
I>

В ConvertImport код на C#?
Почему это все задается для одной колонки? У вас, что связанных колонок не бывает?

WH>>Мне даже ничего объяснять не пришлось. Они сами все поняли.
WH>>Хотя конечно они все могут написать FizzBuzz не приходя в сознание.
I>А ты не думал, что это и есть основная причина , что они "сами всё поняли" ?
Думал. И именно поэтому я и не работаю с теми, кто не может FizzBuzz.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, WolfHound, Вы писали:

I>>С когнитивной тз она сложнее, например потому что юзер не в курсе про то что такое солнце. Для него солнце это шарик на синем небе. шарик и небо ему понятны. А все остальное он не может пощупать. Соответсвенно гелиоцентричекую ты такому юзеру в голову не вобьёшь до тех пор, пока он не потрогает все руками.
WH>И как же мне это еще в детском саду объяснили то?

Ты принял на веру, а не как практически проверяемый тобой и значимый факт.
(См. отношение Ш.Холмса к астрономии по Конан-Дойлю.)
Фактически, это было постороннее знание, которое ты запомнил механически без осмысления.
Осмысление наступило бы только тогда, когда ты бы сам летал в космос или занялся программированием полёта космического аппарата.

WH>>>Нет. Годы я потратил на то чтобы перекопать мегатонны навоза и понять, как правильно делать.
I>>Ну то есть ты напрочь отрицаешь ценность практики ?

WH>Нет. Я говорю, что создание компиляторов на много проще чем принято думать.

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

WH>Ты действительно думаешь, что все кто заходит в форму по немерле пишут компилятор немерла? Или тем более работают над Н2?
WH>Над Н2 сейчас работает ровно один человек. И еще один статьи пишет.

Хм... узок их круг, страшно далеки они от народа... и вы надеетесь чего-то достичь?

WH>Ох. В драконе когнитивная сложность тоже зашкаливает. Попробуй, объясни человеку что такое конфликт сдвиг/свертка.

Именно это достаточно тривиально. Вот многое другое — да, сложно.

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Ikemefula, Вы писали:

I>>С нуля что ли ? Студенты пишут всё с _нуля_. то есть, твоя производительность не в 100 раз, а всего в 14 раз больше, чем у студента третьего курса

WH>Что они пишут?
WH>Они пишут кривой компилятор.
WH>Который генерирует тормозной код с кучей ошибок.
WH>Отладка, ИДЕ и оптимизации в эти две недели не входят. Доведение компилятора до промышленного качества тоже.
WH>Добавь все это и получишь лет 5.

Вот если бы ты предложил рефакторинг кода на ДСЛ, то можно обойтись и без отладки, и даже без оптимизаций. "Промышленное" нужно для массового применения, т.е. когда компилер будет широко использоваться. Судя по тому, что на разных проектах используются и хорошо работают самопальные примитивные интерпретаторы-вычислителисовершенно не очевидно, что твое "промышленное" будет давать значительный профит.

Есть большая проблема — в случае с дсл нет инструментов автоматического рефакторинга, то есть нужно или суппортить все версии, или же писать миграционные скрипты или же колбасить код руками. то есть тупо управлять сложностью и понижать её любыми способами.
Но это еще пол-беды. Качественный ДСЛ требует хороший функциональный базис, то есть серьезную мат-подготовку. Например linq тянет серьезный мат-бекграунд.
В кратце это означает, что для создания такого ДСЛ тебе нужен Erik Meijer. Таких людей единицы, ну десятки, а проектов миллионы в год.

То есть, по факту, твой подход незначительно превосходит студенческую поделку и требует всего в ~10 раз меньше времени.

Теперь про актуальность того, что ты предлагаешь.

Даже много большей экономии недостаточно для перехода на ДСЛ для большинства проектов, тупо потому что программирование в них не является узким местом.
Будешь смеяться, узкое место в длинных проектах вообще и продуктовых софтверных продуктах в частности ни разу не программирование. Программирование является узким местом в небольших проектах, шароварах, R&D и узких задачах где нужно именно системное программирование и где высокая цена ошибка.

То есть это значит, что все такие оптимизации не дают значимого профита, зато вводят новые риски, как напрамер сильную зависимость от ЧФ которую ты упорно отрицаешь или же переход на полностью новый стек технологий, да-да.

I>>Смешно. Я хорошо представляю за какое время студенты осваивают регулярные выражения, sql и тд.
WH>Это, смотря какие студенты.

Какие есть и других не будет в принципе.

WH>>>Кроме демагогии аргументы будут?
I>>Ты сам начал

WH>Что я начал? Это ты тут вещаешь, что FizzBuzz сложнее бизнеслогики.

Для бизнеслогики необходимый минимум это
1. хорошие знания в бизнес специфике
2. минимальные навыки программирования == FizzBuzz
Отсюда неудивительно, что люди которые проводят годы в 1С(и подобной хрени) практически не умеют программировать.

I>>Попробуй перечитать внимательно. Мелочовочка — это про твои ссылки. J# это "серьезная проблема". И да, это конец света, для J# разумеется. Мы вот в свое время вляпались, сейчас есть 10% важного кода который ни портировать, ни переписать за разумное время нельзя, потому переход на 4.0 откладывается уже целый год.
WH>Причём тут J#?

Пример для сравнения, который показывает проблемы для бизнеса которые возникают если ктото забивает на совместимость, суппорт и тд и тд и тд.

WH>Ты тут утверждал про какие-то фатальные проблемы с обратной совместимостью немерла.

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

которую жалко тратить на такие пустяки.

I>>Хорошо, один из вариантов — такой же файлик, как и принимаем у юзера. Второй вариант — xml на старом дсл, нужен для обратной совместимости. Третий вариант еще не появился, это будет какой нибудь шустрый ОРМ, пока здесь препятствие наша вычислительная модель которая оптимизировалась под перформанс операций, а не персистанс.
WH>Я ничего не понял.

1. Модель персистится в такой же файлик, как и тот из которого она подымалась. Это я описал и вроде даже код сохранения привел.
2. Модель персистится в таблички (xml) с помощью старого дсл
3. Будет персист в БД, сейчас есть препятствие — вычислительная модель не подходит под ОРМ.

WH>>>Они так же будут автоматам проверятся при всех операциях с моделью приложения.
I>>Покажи какая модель будет использоваться для этих четырех строчек и как будет выглядеть ДСЛ.
WH>

WH>// Общая модель приложения
WH>table SiteFitout
WH>    field SiteName : String;
WH>end

WH>// Это ограничение на модель
WH>// Проверяется при каждой транзакции
WH>check uniq SiteFitout.SiteName
WH>error $"$SiteName blablabla";

WH>//========================
WH>// Конкретный импорт
WH>table SiteNames
WH>    field SiteName : String;
WH>end

WH>import to SiteNames
WH>    SiteName <- NetworkElement.SiteName
WH>end

WH>check uniq SiteNames.SiteName
WH>error $"$SiteName blablabla";

WH>check SiteNames.SiteName not in SiteFitout.SiteName
WH>error $"$SiteName blablabla";

WH>

WH>Чтобы написать остальное не хватает информации.

Реально check uniq должно уметь несколько сценариев, все я не могу перескахзать. Некоторые объекты уникальны глобально, некоторые в пределах какого то объекта модели, некоторые в пределах какого то источника не привязаного четко к конкретному объекту модели. Это зависит от того насколько сильная разница между двумя структурами.

В примере ниже ты видишь два Findxxx, реально их много больше. И проверка уникальности тож была реализована. Собтсвенно из за такой хрени все и встало колом. Нужно было или добавлять встроеную поддержку всех таких функций или давать способ описывать их в коде. Мы пошли по второму пути и получился тьюринг-полный язык.
В любом случае начинается хаос — девелопер должен на раз знать и понимать все CheckXXX и FindXXX (а также другие вещи) со всеми вырожденными случаями и оптимизациями.
С нашим подходм — изменения в одном месте не затрагивают другие места и это помогает решить многие проблемы связаные с отсутствие автоматического рефакторинга.
Теоретически, можно отрефакторить код, но это ручная работа => высокое количетсво ошибок.
ну и повторюсь, что бы предложить хороший функциональный базис нужны серьезная прокачка не девелоперских скилов, а математических. Например теория категорий и тд.

I>>Его делал человек который фактически был архитектором, сарказм абсолютно неуместен.
WH>Одно другому не мешает. Особенно если верить тебе что подавляющее большинство программистов не могут FizzBuzz.

Эти умения они демонстрируют на собеседовании, хотя уже имеют работу

WH>>>Кстати можешь показать код на этом ДСЛ?
I>>

I>>Column="Node" 
I>>Type="string"
I>>ImportPath="ServiceEndA.Node"
I>>ExportPath="ServiceEndA.Node.Site.Name"
I>>ConvertImport="FindOrCreate(Root.NetworkStructure.ServiceLayer.Nodes, Site, FindObjByName(Root.SiteMap.Sites, ColumnValue, typeof(Site)), typeof(Node))"
I>>

WH>В ConvertImport код на C#?

Это все дсл, только небошие оптимизации, например typeof, и я вижу что он ничем не хуже того что предложил ты, разница только в синтаксисе.
Оптимизации были нужны из за того, что вычислитель работает чз рефлексию. Он был написан еще на фреймворке 1.1.
Без оптимизаций будет так
ConvertImport="FindOrCreate(Root.NetworkStructure.ServiceLayer.Nodes, Site, FindObjByName(Root.SiteMap.Sites, ColumnValue))

Эквивалентный код на C#

FindOrCreate(Root.NetworkStructure.ServiceLayer.Nodes, (node)=>node.Site, FindObjBy(Root.SiteMap.Sites, (site)=>Site.Name == ColumnValue))

Можно кое что упростить, но есть вещи вроде FindByPosAnd, FindIf и тд и тд.

WH>Почему это все задается для одной колонки? У вас, что связанных колонок не бывает?

Бывает. Для них точно такой же код, только сама логика указана другая. Точно так же будет вызваться Findxxx и тд и тд.

I>>А ты не думал, что это и есть основная причина , что они "сами всё поняли" ?
WH>Думал. И именно поэтому я и не работаю с теми, кто не может FizzBuzz.

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

Здравствуйте, Ikemefula, Вы писали:

I>Вот если бы ты предложил рефакторинг кода на ДСЛ, то можно обойтись и без отладки, и даже без оптимизаций.
Так я и предложил.
Читай внимательней.
За один день можно сделать и компилятор с отладчиком и ИДЕ с рефакторингами.
Только для этого правильные инструменты нужны. Над чем я и работаю.

I>"Промышленное" нужно для массового применения, т.е. когда компилер будет широко использоваться.
Оно нужно всегда. Другое дело что на C# его достижение требует таких затрат что закачаешься.

I>Судя по тому, что на разных проектах используются и хорошо работают самопальные примитивные интерпретаторы-вычислителисовершенно
Это по тому что современными инструментами промышленного качества приемлемыми затратами не достичь.

I>не очевидно, что твое "промышленное" будет давать значительный профит.
Очевидно.

I>Есть большая проблема — в случае с дсл нет инструментов автоматического рефакторинга,
Так я тебе и говорю, что при наличии инструментов это получается почти автоматом.

I>Но это еще пол-беды. Качественный ДСЛ требует хороший функциональный базис, то есть серьезную мат-подготовку. Например linq тянет серьезный мат-бекграунд.
Может хватит считать программистов дураками?
linq может сделать любой толковый студент.

I>В кратце это означает, что для создания такого ДСЛ тебе нужен Erik Meijer.
Erik Meijer нужен чтобы пропихнуть linq в компилятор C#.

I>То есть, по факту, твой подход незначительно превосходит студенческую поделку и требует всего в ~10 раз меньше времени.
То есть по факту ты не читаешь того что тебе пишут.

I>Даже много большей экономии недостаточно для перехода на ДСЛ для большинства проектов, тупо потому что программирование в них не является узким местом.
И что же в них является узким местом?
Вот сколько проектов видел, везде все упиралось в тормознутость программистов.
Включая сугубо прикладные проекты.

I>>>Смешно. Я хорошо представляю за какое время студенты осваивают регулярные выражения, sql и тд.
WH>>Это, смотря какие студенты.
I>Какие есть и других не будет в принципе.
У меня в группе было 2 человека которые могли писать. На соседних специальностях было еще несколько человек.
Что там делали остальные я не знаю.
Может быть, тебе всегда попадаются остальные?
А те, кто может писать обходят твою контору стороной?

I> 2. минимальные навыки программирования == FizzBuzz
Ты мне тут пытаешься доказать что FizzBuzz не нужен.

WH>>Ты тут утверждал про какие-то фатальные проблемы с обратной совместимостью немерла.
I>Наверное я не правильно чего то сказал ну или где то не разобрался. Я взял код из статей, кое что попробовал, потом через какое то время в релизной версии немерла это отвалилось. Разбираться что к чему нет никакого желания, ибо тот же F# работает и не жужжит,
http://msdn.microsoft.com/en-us/library/hh416791%28v=vs.110%29.aspx
Может в немерле тоже что-то такое исправили?

I>а сами статьи вычитывать не вижу смысла, с другим языками это почему то не нужно, хватает и кода. Я так вообще все языки программирования выучил. Первая книга по ЯП которую я купил, это F# и основная причина в том,
Те прочитать статью про немерле слишком сложно, а купить целую книгу по F# нормально.
Опять двойные стандарты на марше.

I>что у меня дома нет компьютера
Оно заметно.

I>а блокнота мне жалко, он ручной работы и в ём хорошая, плотная, бескислотная бумага

которую жалко тратить на такие пустяки.
Чего?

I>Реально check uniq должно уметь несколько сценариев, все я не могу перескахзать.
А ты попробуй.

I>Некоторые объекты уникальны глобально, некоторые в пределах какого то объекта модели, некоторые в пределах какого то источника не привязаного четко к конкретному объекту модели. Это зависит от того насколько сильная разница между двумя структурами.
Хе-хе. Это не имеет никакого отношения к check uniq.
Вся разница в том, как формировать таблицу.

I>В любом случае начинается хаос — девелопер должен на раз знать и понимать все CheckXXX и FindXXX (а также другие вещи) со всеми вырожденными случаями и оптимизациями.
Это разработчик ДСЛ не должен разводить зоопарк.
Ибо он реально не нужен.
Ты еще не показал ничего такого, для чего реляционной алгебры бы не хватило.

I>С нашим подходм — изменения в одном месте не затрагивают другие места и это помогает решить многие проблемы связаные с отсутствие автоматического рефакторинга.
А это-то тут причем?
Какая разница добавить в язык новую конструкцию или новую функцию?
Да никакой.

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

I>Это все дсл, только небошие оптимизации, например typeof, и я вижу что он ничем не хуже того что предложил ты, разница только в синтаксисе.
I>Оптимизации были нужны из за того, что вычислитель работает чз рефлексию. Он был написан еще на фреймворке 1.1.
И это вместо того чтобы типизировать код. Найти кучу ошибок. И сгенерировать очень быстрый код?
Генерировать код можно было и на 1.0
Генератор железный. Он без проблем может нагенарировать все специализации генериков сам.

I>Можно кое что упростить, но есть вещи вроде FindByPosAnd, FindIf и тд и тд.
Вот только они все выражаются через where.

I>Бывает. Для них точно такой же код, только сама логика указана другая. Точно так же будет вызваться Findxxx и тд и тд.
Продемонстрируй.
Хочу посмотреть, как вы колонки связываете.

I>В кратце, ты отстаиваешь идею сильной зависимости от высококлассных специалистов только не хочешь этого признавать.
Я отстаиваю идею о том, что прибыль могут генерировать только сильные.
Остальные одни убытки. Не считая распил-проектов.

I>Из теории риск-менеджмента известно, что риски берутся аккурат из таких вот сильных зависимостей.
I>То есть, это именно то с чем бизнес борется любыми способами, следовательно на большинстве проектов это в принципе неприемлемо, ибо основной приоритет это бизнес-специфика.
Бизнес не борется с рисками. Бизнес ими управляет.
И тут мы имеем вот что:
Твой вариант: Гарантированный срыв сроков. Куча багов. Раздутый до небес бюджет.
Мой вариант: Быстрое и качественное решение проблемы. Но придется повозиться с подбором персонала.

Хотя если я сейчас кину клич о разработке на ДСЛ, сбежится куча очень сильного народа.
Я гарантирую это.
Ибо всех их C# с жабой достали.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, WolfHound, Вы писали:

I>>Но это еще пол-беды. Качественный ДСЛ требует хороший функциональный базис, то есть серьезную мат-подготовку. Например linq тянет серьезный мат-бекграунд.
WH>Может хватит считать программистов дураками?
WH>linq может сделать любой толковый студент.
I>>В кратце это означает, что для создания такого ДСЛ тебе нужен Erik Meijer.
WH>Erik Meijer нужен чтобы пропихнуть linq в компилятор C#.

Ммм, а вот тут я бы разделил реализацию и придумывание самих принципов.

Реализация linq на нормальных языках не представляется мне сложной задачей вообще. Вот например http://habrahabr.ru/post/142632/ человек на коленке сделал разновидность для C++.

Если же говорить о продумывание принципов, то тут всё гораздо сложнее. Хотя например конкретно в случае linq его авторы тоже не особо потрудились, взяв всё нужное из sql. А вот уже за sql стоят вполне определённые наработки, которые продумывались явно не за пару минут.

Здравствуйте, WolfHound, Вы писали:

WH>Так я и предложил.
WH>Читай внимательней
WH>За один день можно сделать и компилятор с отладчиком и ИДЕ с рефакторингами.
WH>Только для этого правильные инструменты нужны. Над чем я и работаю.

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

I>>"Промышленное" нужно для массового применения, т.е. когда компилер будет широко использоваться.
WH>Оно нужно всегда. Другое дело что на C# его достижение требует таких затрат что закачаешься.

Не нужно и я объяснил почему — в мейнстриме узкое место ни разу не программисты.

I>>Судя по тому, что на разных проектах используются и хорошо работают самопальные примитивные интерпретаторы-вычислителисовершенно
WH>Это по тому что современными инструментами промышленного качества приемлемыми затратами не достичь.

Если работают в реальных проектах значит это уже промышленный эффект.

I>>не очевидно, что твое "промышленное" будет давать значительный профит.
WH>Очевидно.

Возможно только тебе одному.

I>>Есть большая проблема — в случае с дсл нет инструментов автоматического рефакторинга,
WH>Так я тебе и говорю, что при наличии инструментов это получается почти автоматом.

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

I>>Но это еще пол-беды. Качественный ДСЛ требует хороший функциональный базис, то есть серьезную мат-подготовку. Например linq тянет серьезный мат-бекграунд.
WH>Может хватит считать программистов дураками?
WH>linq может сделать любой толковый студент.

Написать любую из функций в linq может почти любой студент. А что бы предложить такую концепцию как Linq нужен Erik Meijer.

I>>В кратце это означает, что для создания такого ДСЛ тебе нужен Erik Meijer.
WH>Erik Meijer нужен чтобы пропихнуть linq в компилятор C#.

Ты хоть знаешь, что linq != query comprehension ? Первое даже без C# работает, а второе нужно много для чего и точно не является обязательным для linq.

I>>То есть, по факту, твой подход незначительно превосходит студенческую поделку и требует всего в ~10 раз меньше времени.
WH>То есть по факту ты не читаешь того что тебе пишут.

На себя посмотри. RX по твоему тоже любой студент напишет ? Почему же миллионы девелоперов ждали 15 лет пока это сделал Erik Meijer ?

I>>Даже много большей экономии недостаточно для перехода на ДСЛ для большинства проектов, тупо потому что программирование в них не является узким местом.
WH>И что же в них является узким местом?

В разных по разному, в некоторых тестирование, в некоторых маркетинг.

WH>Вот сколько проектов видел, везде все упиралось в тормознутость программистов.

WH>Включая сугубо прикладные проекты.
Я не знаю, что такое "сугубо прикладные проекты"

I>>Какие есть и других не будет в принципе.
WH>У меня в группе было 2 человека которые могли писать. На соседних специальностях было еще несколько человек.

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

WH>Что там делали остальные я не знаю.
WH>Может быть, тебе всегда попадаются остальные?

Мы и так отфильтровываем примерно 90% кандидатов и это уже является слишком большой проблемой. Если и дальше задирать планку, как ты предлагаешь, то мы вообще никого не найдем. Классные программисты которые не шарят в бизнес-специфике или не готовы её осваивать не нужны и задаром. Брать их чисто ради девелоперских задач смысла не имеет, в перспективе такие работают год-два и им становится скучно.

WH>А те, кто может писать обходят твою контору стороной?

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

I>> 2. минимальные навыки программирования == FizzBuzz
WH>Ты мне тут пытаешься доказать что FizzBuzz не нужен.

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

WH>>>Ты тут утверждал про какие-то фатальные проблемы с обратной совместимостью немерла.
I>>Наверное я не правильно чего то сказал ну или где то не разобрался. Я взял код из статей, кое что попробовал, потом через какое то время в релизной версии немерла это отвалилось. Разбираться что к чему нет никакого желания, ибо тот же F# работает и не жужжит,
WH>http://msdn.microsoft.com/en-us/library/hh416791%28v=vs.110%29.aspx
WH>Может в немерле тоже что-то такое исправили?

Я уже сказал, нет у меня желания разбираться в ваших проблемах.

I>>а сами статьи вычитывать не вижу смысла, с другим языками это почему то не нужно, хватает и кода. Я так вообще все языки программирования выучил. Первая книга по ЯП которую я купил, это F# и основная причина в том,
WH>Те прочитать статью про немерле слишком сложно, а купить целую книгу по F# нормально.
WH>Опять двойные стандарты на марше.

Ты как то хронически делаешь вывод по фрагментарной информации. Книгу я купил потому, что F# мне понравился. Про Nemerle я уже писал, что ничего не имею против языка но без макров. Макры кушайте сами.

I>>а блокнота мне жалко, он ручной работы и в ём хорошая, плотная, бескислотная бумага

которую жалко тратить на такие пустяки.
WH>Чего?

Эту строчку надо понимать буквально.

I>>Реально check uniq должно уметь несколько сценариев, все я не могу перескахзать.
WH>А ты попробуй.

А чего пробовать, нам нужен набор абстракций, вроде монад хаскеля а не набор слов вроде check uniq или набор селекторов-фильтров

I>>Некоторые объекты уникальны глобально, некоторые в пределах какого то объекта модели, некоторые в пределах какого то источника не привязаного четко к конкретному объекту модели. Это зависит от того насколько сильная разница между двумя структурами.
WH>Хе-хе. Это не имеет никакого отношения к check uniq.

Я говорю о том, что твой check uniq ни разу не решение, это уже пройденый этап, нужны абстрации.

WH>Вся разница в том, как формировать таблицу.

Формировать таблицу проще простого, вопрос в том, как упростить всю логику, а в ней самое проблемное место это уникальность объектов и всякие выборки-инстанцирование-связывание. Вот здесь и нужно решение.

I>>В любом случае начинается хаос — девелопер должен на раз знать и понимать все CheckXXX и FindXXX (а также другие вещи) со всеми вырожденными случаями и оптимизациями.
WH>Это разработчик ДСЛ не должен разводить зоопарк.

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

WH>Ибо он реально не нужен.
WH>Ты еще не показал ничего такого, для чего реляционной алгебры бы не хватило.

Нужно высокоуровневое средство которое будет явно привязано к нашей модели
1 если можно зарегить в ней например объект Node, то точно точно так же можно зарегить любой похожий объект.
2 много типов регятся своим уникальным способом и это очевидно
3 много разных констреинтов

I>>С нашим подходм — изменения в одном месте не затрагивают другие места и это помогает решить многие проблемы связаные с отсутствие автоматического рефакторинга.
WH>А это-то тут причем?
WH>Какая разница добавить в язык новую конструкцию или новую функцию?
WH>Да никакой.

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

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

Если здравый смыс включает в себя теорию категорий то я полностью согласен.

I>>Это все дсл, только небошие оптимизации, например typeof, и я вижу что он ничем не хуже того что предложил ты, разница только в синтаксисе.
I>>Оптимизации были нужны из за того, что вычислитель работает чз рефлексию. Он был написан еще на фреймворке 1.1.
WH>И это вместо того чтобы типизировать код. Найти кучу ошибок. И сгенерировать очень быстрый код?
WH>Генерировать код можно было и на 1.0
WH>Генератор железный. Он без проблем может нагенарировать все специализации генериков сам.

Это мелочевка, так, пятно пыли на плаще могучего Хорезма

I>>Можно кое что упростить, но есть вещи вроде FindByPosAnd, FindIf и тд и тд.
WH>Вот только они все выражаются через where.

where дает ровно тот же результат, только вместо FindXXX будет один Where + пачки предопределенных предикатов. Всё, приехали.

I>>Бывает. Для них точно такой же код, только сама логика указана другая. Точно так же будет вызваться Findxxx и тд и тд.
WH>Продемонстрируй.
WH>Хочу посмотреть, как вы колонки связываете.

Все связывания это вызов встроеной функции, т.к. они все разные. Логика каждой написана в C# или на том же ДСЛ.

I>>В кратце, ты отстаиваешь идею сильной зависимости от высококлассных специалистов только не хочешь этого признавать.
WH>Я отстаиваю идею о том, что прибыль могут генерировать только сильные.
WH>Остальные одни убытки. Не считая распил-проектов.

I>>Из теории риск-менеджмента известно, что риски берутся аккурат из таких вот сильных зависимостей.
I>>То есть, это именно то с чем бизнес борется любыми способами, следовательно на большинстве проектов это в принципе неприемлемо, ибо основной приоритет это бизнес-специфика.
WH>Бизнес не борется с рисками. Бизнес ими управляет.

Это одно и то же.

WH>И тут мы имеем вот что:
WH>Твой вариант: Гарантированный срыв сроков. Куча багов. Раздутый до небес бюджет.

И потому контора нумер один в своем сегменте ? Браво !

WH>Мой вариант: Быстрое и качественное решение проблемы. Но придется повозиться с подбором персонала.

То есть, все таки зависимость от ЧФ есть и есть связаные с ней риске ? Тебе не кажется, что все студенты первого курса искаропки должны уметь на раз как минимум монады хаскеля ?

WH>Хотя если я сейчас кину клич о разработке на ДСЛ, сбежится куча очень сильного народа.

Конечно. Лисперы до сих пор так и ищут. Это ничего не доказывает.

Здравствуйте, WolfHound, Вы писали:

WH>Хотя если я сейчас кину клич о разработке на ДСЛ, сбежится куча очень сильного народа.
WH>Я гарантирую это.
WH>Ибо всех их C# с жабой достали.

+1

Только если вдруг ситуация изменится и ДСЛ-и начнут использовать повсеместно, то проблема с кадрами возникнет снова. К сожалению количество мозга на земле величина постоянна, а количество людей увеличивается.

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

Здравствуйте, alex_public, Вы писали:

_>Ммм, а вот тут я бы разделил реализацию и придумывание самих принципов.

Там единственный принцип — использование функций высшего порядка. 90% функций использованных в линке были были известны со времен царя гороха (использовались в раннем ML). Почти все они являются абстрагированием тех или иных видов циклов.

Все что было превнесено в linq с точки зрения ФВП — это join. И то он получился на редкость кривым.

_>Реализация linq на нормальных языках не представляется мне сложной задачей вообще. Вот например http://habrahabr.ru/post/142632/ человек на коленке сделал разновидность для C++.

Мил человек. В линке одна из самых важных составляющих — это возможность автоматически преобразовать код в его AST. Так вот это на С++ делать запаришся, так как язык убог неимоверно.

Да и ФВП повторены крайне хренов. И виноват в этом не автор библиотеки, а Страуструп и ко. Уровень синтаксического шума зашкаливает. Если взять пример по сложнее, то он превратится в кашу. И это еще с использованием С++11. На старом С++ (которым насиловали мозг более 10 лет) и это повторить не удастся. Получится полный урод.

Ну, и библиотека пока что еще только игрушка нет selectMany, join, ThenBy, ... Хотя это конечно это просто объем работы.

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

_>Если же говорить о продумывание принципов, то тут всё гораздо сложнее. Хотя например конкретно в случае linq его авторы тоже не особо потрудились, взяв всё нужное из sql. А вот уже за sql стоят вполне определённые наработки, которые продумывались явно не за пару минут.

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

То что линк похож на язык — это следствие применения так называемого "свободного интерфейса" (fluent interface). Свободный интерфейс — это один из способов реализовать встроенный ДСЛ в языке который на большее неспособен. Заключается он в протаскивании контекста "через точку", т.е. в записи выражения ДСЛ-я в виде последовательности вызовов методов в ООЯ. Именно потому что используется ДЧСЛ, кстати, разница между синтаксисом линка и линк-паттерном (свободным интерфейсом) не такая уж убийственная (правда на более сложных запросах она становится критической).

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

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

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

Здравствуйте, Ikemefula, Вы писали:

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

Несомненно!

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

Создание других рефакторингов можно будет резко упростить.

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

I>>>"Промышленное" нужно для массового применения, т.е. когда компилер будет широко использоваться.
WH>>Оно нужно всегда. Другое дело что на C# его достижение требует таких затрат что закачаешься.

I>Не нужно и я объяснил почему — в мейнстриме узкое место ни разу не программисты.

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

I>>>Судя по тому, что на разных проектах используются и хорошо работают самопальные примитивные интерпретаторы-вычислителисовершенно
WH>>Это по тому что современными инструментами промышленного качества приемлемыми затратами не достичь.

I>Если работают в реальных проектах значит это уже промышленный эффект.

От бедности, в 60-ых в проектах отлично работало кодирование в машкодах. Что это доказывает?

I>То есть, все таки зависимость от ЧФ есть и есть связаные с ней риске ? Тебе не кажется, что все студенты первого курса искаропки должны уметь на раз как минимум монады хаскеля ?

Он тебе раз 10 повторил — опора на вменяемые кадры. Для использования ДСЛ нужно просто быть вменяемым программистом. Для их разработку нужно к тому же быть вменяемым архитектором ПО.

Сейчас это не так, потому что у людей в руках каменные молотки. Причем без инструкции по эксплуатации (внятных методик).

Первое (вопрос наличия инстурментов) — это вопрос реализации. Это большой объем очень сложной работы. Ее средние программисты сделать не смогут — 100%.
Второй — это вопрос образования и пиара. Было бы замечательно, если бы наши вузы перестали убивать новые поколения программистов, а начали бы обучать тем самым методикам. В том числе и методикам разработки и эксплуатации ДСЛ-ей при разработке ПО.

WH>>Хотя если я сейчас кину клич о разработке на ДСЛ, сбежится куча очень сильного народа.

I>Конечно. Лисперы до сих пор так и ищут. Это ничего не доказывает.

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

Главная проблема Лиспа — отсутствие синтаксиса. По сути программисту предлагается писать в АСТ. Причем АСТ выраженном в виде списков. Читаемость такого кода довольно низка.

Плюс Лисп — это динамически типизированный язык. И в мир статики он вписывается крайне хреново.

Если же создать инструмент который предоставлял бы легкий путь создания языковых расширений и внешних ДСЛ-ей для типизированного мира, причем с блэкджеком и шлюхами (т.е. с поддержкой IDE, отладки, и т.п.), то в сочетании с внятными методиками это могло бы изменить положение дел. Ведь то же ФП просочилось в мэйнстрим! Даже С++ обзавелся подобием лямбд.

Здравствуйте, VladD2, Вы писали:

VD>Там единственный принцип — использование функций высшего порядка. 90% функций использованных в линке были были известны со времен царя гороха (использовались в раннем ML). Почти все они являются абстрагированием тех или иных видов циклов.

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

Для обработки последовательностей данных эту задачу когда-то решили авторы sql.

VD>Мил человек. В линке одна из самых важных составляющих — это возможность автоматически преобразовать код в его AST. Так вот это на С++ делать запаришся, так как язык убог неимоверно.

Эта особенность как раз всю кривизну и привносит, причём при отсутствие реальной необходимости.

В C++ это вполне можно привнести, но тогда потеряются преимущества полноценной статической типизации — не надо такого.

VD>Ну, и библиотека пока что еще только игрушка нет selectMany, join, ThenBy, ... Хотя это конечно это просто объем работы.

Вообще то там уже есть возможности которых нет и в самом .net linq. А уж если говорить о скорости, то... )))

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

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

Далее, вообще то все эти известные идиомы давно были ещё в древнем C++. Все нужные функции есть в том же stl. Там есть map, fold, filter и т.п, только под другими именами.

Автор же этого решения просто привнёс понравившийся ему linq (или лучше говорить sql?

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

Кстати, можно тут http://habrahabr.ru/post/142657/ посмотреть подробнее. Особенно был интересен пункт про производительность. Надо было бы ему посоветовать ещё провести сравнительные тесты с linq вариантом.)))

VD>Но таки да, на проектирование ДСЛ-я неизбежно уходят силы. Создать хреновый ДСЛ так же легко как создать хреновую библиотеку. Но это же верно для всего что делает программист. Создать говнокод намного проще чем хорошую реализацию.

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

VD>Применение ДСЛ-ей хорошо хотя бы тем, что заставляет задумываться (прорабатывать) над моделью вычислений решаемой задачи и над лингвистическими идиомами используемыми при описании решений.

Удобных инструментов для этого не видно. Кстати, я тут попробовал перебрать в памяти... Пожалуй местом с максимальной концентрацией dsl'ей является как ни странно Boost.

Здравствуйте, VladD2, Вы писали:

VD>Некоторые виды рефакторинга можно сделать доступными из коробки. Например, рефакторинги переименования разных символов будут доступны сразу, так как единственное что для них нужно — это использование единого механизма управления символами и связывания имен (таблицы символов).

Рефакторинг — зло. Чем скорее человечество забудет это гнусное слово, тем лучше.

VD>Сейчас даже в самых современных средствах рефакторинга создание нового рефакторинга (плагина) выливается в жуткий императивный код манипулирующий деревьями.
VD>Только перевод этого дела на квази-цитирование уже упростит жизнь во много раз.

Только не это! И сейчас-то уже спасу нет от рефакторинга, а если его еще и проще делать будет, то совсем беда.

VD>Он тебе раз 10 повторил — опора на вменяемые кадры. Для использования ДСЛ нужно просто быть вменяемым программистом. Для их разработку нужно к тому же быть вменяемым архитектором ПО.

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

VD>Сейчас это не так, потому что у людей в руках каменные молотки. Причем без инструкции по эксплуатации (внятных методик).

Даже существующих инструментов достаточно. Чего нет, так это книг с баззвордами и агрессивных евангелистов (как у TDD или у того же мерзопакостного, ненавистного рефакторинга).

VD>Первое (вопрос наличия инстурментов) — это вопрос реализации. Это большой объем очень сложной работы. Ее средние программисты сделать не смогут — 100%.

Могут, ничего там сложного нет в большинстве случаев.

VD>Второй — это вопрос образования и пиара. Было бы замечательно, если бы наши вузы перестали убивать новые поколения программистов, а начали бы обучать тем самым методикам. В том числе и методикам разработки и эксплуатации ДСЛ-ей при разработке ПО.

Наши ВУЗы даже ООП учить пока не научились, куда уж им через поколения перескакивать.

VD>Лисп сложен для рядового пользователя и оторван от жизни.

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

VD>Главная проблема Лиспа — отсутствие синтаксиса.

Это не проблема, это преимущество. Синтаксис языкам вредит, отвлекает от сути.

VD> По сути программисту предлагается писать в АСТ. Причем АСТ выраженном в виде списков. Читаемость такого кода довольно низка.

Только первые десять минут знакомства с языком. Потом все просто и естественно.

VD>Плюс Лисп — это динамически типизированный язык. И в мир статики он вписывается крайне хреново.

Это не обязательное свойство Лиспа, он может быть как угодно типизированным (см. Shen, бывший Qi).

Здравствуйте, oldjackal, Вы писали:

O> Рефакторинг — зло. Чем скорее человечество забудет это гнусное слово, тем лучше.
И что вместо него?
Вот поменялись у нас требования.
В существующий код они не вписываются.
Что дальше?

O> Я бы сказал, для разработки DSL нужно куда как меньше интеллекта чем для современных чрезмерно переусложненных ООП-методологий. Так что людей в индустрии, способных с этим справиться, уже и так предостаточно.
+1000
Правда Ikemefula хочет работать с теми, для кого FizzBuzz проблема...
А они вообще ничего не могут.

VD>>Сейчас это не так, потому что у людей в руках каменные молотки. Причем без инструкции по эксплуатации (внятных методик).
O> Даже существующих инструментов достаточно.
Не достаточно. Трудозатраты слишком велики.

O>Чего нет, так это книг с баззвордами и агрессивных евангелистов (как у TDD или у того же мерзопакостного, ненавистного рефакторинга).
Это да.

VD>>Первое (вопрос наличия инстурментов) — это вопрос реализации. Это большой объем очень сложной работы. Ее средние программисты сделать не смогут — 100%.
O> Могут, ничего там сложного нет в большинстве случаев.
Это, смотря на каком уровне делать.
Если на том уровне что ты тут показывал, то там все просто.
А если нужны качественные сообщения об ошибках.
Предметно-ориентированные системы типов.
Вывод типов, понимающий перегрузки.
ИДЕ и коробки.
...
То тут все совсем не просто.

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

Кстати ты обещал продемонстрировать невообразимую крутизну макросов, которые генерируют другие макросы.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, oldjackal, Вы писали:

VD>>Некоторые виды рефакторинга можно сделать доступными из коробки. Например, рефакторинги переименования разных символов будут доступны сразу, так как единственное что для них нужно — это использование единого механизма управления символами и связывания имен (таблицы символов).
O> Рефакторинг — зло. Чем скорее человечество забудет это гнусное слово, тем лучше.

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

Здравствуйте, netch80, Вы писали:

O>> Рефакторинг — зло. Чем скорее человечество забудет это гнусное слово, тем лучше.

N>Оч-чень интересно.
N>Есть этому обоснование?

Есть, даже два: product branches и merge. Неоднократно уже наблюдал такую картину — приходит в проект новый team lead, весь из себя с горящими глазами, баззвордами во все стороны так и швыряется. И начинает его команда рефакторить фанатично все, что под руку подвернется. Причем, работает эта команда над какой-то одной частью функциональности, а в компании еще пятьдесят других команд, и код для всех общий. И только тогда, когда строго по регламенту, через месяц, все product branch-и в trunk сливают, до несчастных доходит, что за урод этот евангелист, и куда его надо послать.

Что характерно, к приходу следующего евангелиста (уже в другую команду, их много, опытом делиться не научились как следует) история повторяется.

И это в ынтырпрайзе. В open source же все еще хуже. Приползает очередной такой юный фанатик Фаулера, правдами и неправдами получивший право коммита, и начинает радостно рефакторить (ради самого рефакторинга, без каких либо к тому показаний). Потом сотни или даже тысячи людей, работающие над своими патчами и регулярно rebase-ящие свои репозитории до trunk-а этого фанатика и его матушку склоняют на десятках разных языков и с разной степентю цинизма. Хорошо это?

N>Вы можете предложить другой метод изменения структуры программы в нужную сторону с сохранением всей известной функциональности?

Переписывать. По-старинке. Аккуратно, вдумчиво, ручками, с полным осознанием ответственности за последствия. Без всяких там автоматизированных тулзов, которые разом тонны кода перелопачивают.

I>>Не нужно и я объяснил почему — в мейнстриме узкое место ни разу не программисты.

VD>Очень приятно увидеть человека знающий все проблемы мэйнстрима (а это, кстати, не одно и то же с миллионом мух?).

Все не знаю. Наибольшее влияние на бизнес оказывает менеджмет. Далее — маркетинг. Уже потом инженеры, дизайнеры и тд, из которых часть админов, часть безопасников, часть тестировщиков, аналитиков и тд.

Это самый лучший расклад. Все остальные еще хуже. Например берем знакомую тебе полиграфию. Доход от печатной продукции. Программинг всего лишь обслуживающая система. Опаньки !

I>>Если работают в реальных проектах значит это уже промышленный эффект.
VD>От бедности, в 60-ых в проектах отлично работало кодирование в машкодах. Что это доказывает?

Доказывает, что для тех потребностей хватало машинных кодов и никто не умер от недостатка немерле.
Ты сам то подумай, Лисп уже был, а писали и в машинных кодах, потом на асме, потом на фортранах-коболах, потом на си.
История Лиспа тебя ничему не научила ? Сочувствую.

I>>То есть, все таки зависимость от ЧФ есть и есть связаные с ней риске ? Тебе не кажется, что все студенты первого курса искаропки должны уметь на раз как минимум монады хаскеля ?

VD>Он тебе раз 10 повторил — опора на вменяемые кадры. Для использования ДСЛ нужно просто быть вменяемым программистом. Для их разработку нужно к тому же быть вменяемым архитектором ПО.

Не ясно, что такое вменяемые и где их брать, как готовить. Для бизнеса очень хорошо брать людей "на вырост", то есть, чем моложе, тем лучше. Чему их готовить ? Сразу монады хаскеля вливать в головы ?

VD>Второй — это вопрос образования и пиара. Было бы замечательно, если бы наши вузы перестали убивать новые поколения программистов, а начали бы обучать тем самым
методикам. В том числе и методикам разработки и эксплуатации ДСЛ-ей при разработке ПО.

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

VD>Главная проблема Лиспа — отсутствие синтаксиса. По сути программисту предлагается писать в АСТ. Причем АСТ выраженном в виде списков. Читаемость такого кода довольно низка.

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

Здравствуйте, oldjackal, Вы писали:

N>>Вы можете предложить другой метод изменения структуры программы в нужную сторону с сохранением всей известной функциональности?

O> Переписывать. По-старинке. Аккуратно, вдумчиво, ручками, с полным осознанием ответственности за последствия. Без всяких там автоматизированных тулзов, которые разом тонны кода перелопачивают.

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

O> Есть, даже два: product branches и merge. Неоднократно уже наблюдал такую картину — приходит в проект новый team lead, весь из себя с горящими глазами, баззвордами во все стороны так и швыряется. И начинает его команда рефакторить фанатично все, что под руку подвернется. Причем, работает эта команда над какой-то одной частью функциональности, а в компании еще пятьдесят других команд, и код для всех общий. И только тогда, когда строго по регламенту, через месяц, все product branch-и в trunk сливают, до несчастных доходит, что за урод этот евангелист, и куда его надо послать.

Знаешь, есть такая поговорка: дай дураку нефритовый стебель в руки, он и его сломает

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

O> Что характерно, к приходу следующего евангелиста (уже в другую команду, их много, опытом делиться не научились как следует) история повторяется.

Так виноват ли молоток, что им закручивают винты? Может, таки с людьми надо разобраться?

O> И это в ынтырпрайзе. В open source же все еще хуже. Приползает очередной такой юный фанатик Фаулера, правдами и неправдами получивший право коммита, и начинает радостно рефакторить (ради самого рефакторинга, без каких либо к тому показаний). Потом сотни или даже тысячи людей, работающие над своими патчами и регулярно rebase-ящие свои репозитории до trunk-а этого фанатика и его матушку склоняют на десятках разных языков и с разной степентю цинизма. Хорошо это?

Нет, не хорошо. Но см. выше.

Вы как-то очень странно относитесь именно к средствам. Вот Вам в качестве обратного примера — sendmail. Там явно сидят Ваши сторонники — 30 лет развития без единого рефакторинга. Почитайте код, например, getrequests(), sendall(), dropenvelope(), затем залезьте в alias.c. (Приготовьте противорвотное, пригодится.) Если бы были шнобелевские премии для кодеров, давно бы уже автор этого кода имел всю грудь в орденах. Может, надо всё-таки начать думать о том, что иногда надо и менять структуру, даже если кому-то придётся адаптироваться?

Здравствуйте, WolfHound, Вы писали:

O>> Рефакторинг — зло. Чем скорее человечество забудет это гнусное слово, тем лучше.
WH>И что вместо него?

Ручками, аккуратно, вдумчиво, страдая и мучаясь. Потому как если это будет слишком легко делать, этим будут злоупотреблять.

WH>Вот поменялись у нас требования.
WH>В существующий код они не вписываются.
WH>Что дальше?

Переписывать. Без фанатизма. Без постоянного переименовывания всего подряд.

WH>Правда Ikemefula хочет работать с теми, для кого FizzBuzz проблема...
WH>А они вообще ничего не могут.

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

Хотя вру, видел однажды последствия их работы. Индийский аутсорсинг. За ними, понятное дело, потом полностью с нуля все переписывали, так что экономическая выгода крайне сомнительна.

VD>>>Сейчас это не так, потому что у людей в руках каменные молотки. Причем без инструкции по эксплуатации (внятных методик).
O>> Даже существующих инструментов достаточно.
WH>Не достаточно. Трудозатраты слишком велики.

По сравнению с альтернативой (делать все без DSL) — не так уж и велики.

VD>>>Первое (вопрос наличия инстурментов) — это вопрос реализации. Это большой объем очень сложной работы. Ее средние программисты сделать не смогут — 100%.
O>> Могут, ничего там сложного нет в большинстве случаев.
WH>Это, смотря на каком уровне делать.
WH>Если на том уровне что ты тут показывал, то там все просто.

Обычно уровень нужен вообще тупейший. То, что на Лиспе делается макрой в десяток строк кода. Более сложные DSL крайне редко встречаются. DSL очень легко получаются комбинацией элементов уже ранее написанных DSL, так что каждый новый получается проще предыдущего.

WH>А если нужны качественные сообщения об ошибках.

Какие с этим проблемы? Ассертов в макре расставить, и все.

WH>Предметно-ориентированные системы типов.

С системами типов никаких проблем нет, если есть Пролог.

WH>Вывод типов, понимающий перегрузки.

Опять же, с Прологом не проблема.

WH>ИДЕ и коробки.

Не убежден в ценности IDE для DSL-ей. Много там у нас IDE, поддерживающих SQL? Не особо. И никто не жалуется. Много IDE для навороченных DSL-ей в разного рода CAD-ах? Для того же автокада, для инструментов Cadence? Ничего нет, и народ не жалуется, пишут миллионы строк кода на DSL без всяких IDE.

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

WH>...
WH>То тут все совсем не просто.

А не надо усложнять. Как по мне, так большинству DSL и синтаксиса-то никакого не надо (но понимаю прекрасно, что лисперу по этому пункту со всеми остальными никогда не договориться). Тем, кому надо, часто больше подходит графическое представление (а тут для нас уже Microsoft расстаралась).

O>> Он не сложен, он всего лишь непривычен для тех, кого испортили другими языками. Насчет оторванности от жизни тоже не замечал.
WH>Он динамически типизирован.

Как и подавляющее большинство очень популярных и очень жизненных языков. Кто жизненнее — популярнейшие Python, Javascript, Ruby, Perl, Shell-ы всякие или мертвый Haskell и унылая ынтырпрайзная Java? Не такой уж и простой вопрос.

WH>Одно это уже делает его оторванным по самые не балуйся.

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

WH>Кстати ты обещал продемонстрировать невообразимую крутизну макросов, которые генерируют другие макросы.

Да, помню. Времени постоянно не хватает. В ближайшее время нарисую пример.

	От:	WolfHound
	Дата:	27.04.12 15:57
	Оценка:

От:	netch80	http://netch80.dreamwidth.org/
Дата:	30.04.12 10:55
Оценка:

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	30.04.12 11:40
Оценка:

	От:	WolfHound
	Дата:	30.04.12 14:18
	Оценка:

	От:	alex_public
	Дата:	30.04.12 15:14
	Оценка:

От:	VladD2	www.nemerle.org
Дата:	30.04.12 21:42
Оценка:

	От:	oldjackal
	Дата:	01.05.12 16:29
	Оценка:

	От:	oldjackal
	Дата:	02.05.12 09:02
	Оценка:

	От:	oldjackal
	Дата:	02.05.12 10:01
	Оценка:

	От:	oldjackal
	Дата:	02.05.12 10:16
	Оценка: