Здравствуйте, netch80, Вы писали:
N>Я под рефакторингом подразумеваю все варианты преобразований с сохранением функциональности, не обязательно автоматом, поэтому мне такой праведный гнев просто неуместен.
Не обязательно. Есть вокруг до фига преисполненных энтузиазма идиотов, которые это и без автомата делают. Поубивал бы.
N> Но если бы был автомат — то применил бы и автомат. А почему так сразу "тонны" кода? Обычно, мне кажется, меняются только определённые места, и не делается незапрошенных прогонок по всему коду.
Например, изменение имени какого либо класса или метода, используемого во множестве модулей.
N>Знаешь, есть такая поговорка: дай дураку нефритовый стебель в руки, он и его сломает
А дураков слишком много. Лучше им стеблей не давать.
N>Тут больша виновата команда, что не одернула его.
Не положено в таких местах начальство одергивать.
N> Потому что рефакторинг допустим и нужен, но только тогда, когда не предполагается таких вот мержей втихую в одном месте без корреляции с остальными.
Рефакторинг допустим только тогда, когда вообще никаких merge-ей не предполагается в принципе. Когда все тысячи разработчиков дружно гадят в один общий trunk. Ну прямо таки идеал организации разработки, не находите?
N>А ещё больше виновата контора в целом — что не контролирует процесс.
Процесс-то как раз устоявшийся за десятилетия, отлаженный как часы. И никакого рефакторинга не предполагающий по определению. Конечно же, на ошибках учиться надо, это их вина, что после первого такого евангелиста не вкличили в интервью вопросы об отношении к рефакторингу.
O>> Что характерно, к приходу следующего евангелиста (уже в другую команду, их много, опытом делиться не научились как следует) история повторяется.
N>Так виноват ли молоток, что им закручивают винты? Может, таки с людьми надо разобраться?
Надо, надо. Надо энтузиастов рефакторинга сажать в клетки и размножаться не давать.
N>Вы как-то очень странно относитесь именно к средствам. Вот Вам в качестве обратного примера — sendmail. Там явно сидят Ваши сторонники — 30 лет развития без единого рефакторинга.
Там с самого начала была идиотская архитектура. Не очень хороший пример.
N> Может, надо всё-таки начать думать о том, что иногда надо и менять структуру, даже если кому-то придётся адаптироваться?
Иногда. С частотой глобальных катаклизмов. С тотальным code freeze и тому подобными жесткими мерами. А не как адепты этой религии пропагандируют, что мол "когда тебе нечем заняться, порефакторь-ка чего нибудь".
Здравствуйте, Ikemefula, Вы писали:
VD>>Создание других рефакторингов можно будет резко упростить.
I>То есть, я пишу ДСЛ и я же должен буду рефакторинги писать ? Кушайте сами.
Или ты, или кто-то еще. Например, тот кто твой ДСЛ использует. Задача создания рефакторингов упростится. Ее сможет решать любой вменяемый программист.
VD>>Сейчас даже в самых современных средствах рефакторинга создание нового рефакторинга (плагина) выливается в жуткий императивный код манипулирующий деревьями. VD>>Только перевод этого дела на квази-цитирование уже упростит жизнь во много раз.
I>Ну то есть тихо ненавязчиво переложить разработку среды на того кто возьмется за ДСЛ :)))
На того кому нужно, или на того кому поручат. И не среды, а мелких кусочков кода описывающих рефакторинги. Типа найти такой паттерн, заменить на такое.
Так как языки теперь можно будет поставлять в виде библиотек (даже самые мелкие ДСЛ-и), то компании которые выпускают компоненты смогут выпускать и свои языки. Вот они то уж точно смогут обеспечить блэкджек и шлюх.
Твой скепсис просто умиляет. Сейчас люди клепают ДСЛ-и которые вообще не имеют средств рефакторинга. Никаких! Мы же предлагаем дать им комплексное решение.
Сделать некоторые виды рефакторинга автоматом физически невозможно. Но можно упростить их создание сделав, тем самым, их создание доступным массам.
I>Все не знаю. Наибольшее влияние на бизнес оказывает менеджмет. Далее — маркетинг. Уже потом инженеры, дизайнеры и тд, из которых часть админов, часть безопасников, часть тестировщиков, аналитиков и тд.
Это такой защитный гон. Типа разработка ПО — это пустяки. "Фигня война! Главное — маневры!".
Маркетологи могут работать совершенно независимо от разработчиков. Они из другой "вселенной". И по их вине крайне редко заваливаются сроки или выпускается некачественный продукт. А вот по вине программистов — постоянно!
Так что если тебе хочется поговорить о маркетинге или управлении, то иди на соответствующие форумы. А этот форум посвящено разработке ПО.
I>Это самый лучший расклад. Все остальные еще хуже. Например берем знакомую тебе полиграфию. Доход от печатной продукции. Программинг всего лишь обслуживающая система. Опаньки !
Какую из систем? Ты видел как сейчас печатают малотиражную продукцию? Ее печатают на автоматизированных комплексах. Эдакий мега-принтер. Там ПО решает чуть меньше чем все вопросы. А его сложность весьма высока.
Вопросы организации заказов решаются финансовыми системами мало чем отличающимися от аналогичных на других видах предприятиях. Обычно это банальный 1Эс. Максимум с небольшими доработками.
I>>>Если работают в реальных проектах значит это уже промышленный эффект. VD>>От бедности, в 60-ых в проектах отлично работало кодирование в машкодах. Что это доказывает?
I>Доказывает, что для тех потребностей хватало машинных кодов и никто не умер от недостатка немерле.
От отсутствия компьютеров в 30-ых годах тоже никто не умер.
В общем, не моли чепуху. Потребности всегда больше чем возможности. И уровень инструментов будет постоянно расти чтобы обеспечить расширение круга задач и уровня их сложности.
Ты договорился до полного абсурда. Следующим шагом, видимо, будет апелляция к тому что на свете живут вообще глухие и слепые люди, и им Немерл не нужен.
I>Ты сам то подумай, Лисп уже был, а писали и в машинных кодах, потом на асме, потом на фортранах-коболах, потом на си.
Лисп был, есть и будет пока не появятся более мощные инструменты. За последние 5 лет появилось несколько его разновидностей. Это не говоря о матерых Комон Лиспе и Схеме, которые похоронили уже не один язык.
Проблема в том, что Лисп требует ломки сознания и динамически типизирован. В динамическом мире есть как минимум две альтернативы Лиспу — Питон и Руби. Их мэйнстрим принимает куда охотнее. В них тоже есть метапрограммирование, но другого рода. А гибкость достигается за счет динамики. В статически же типизированном мире ничего подобного нет.
I>История Лиспа тебя ничему не научила ? Сочувствую.
Научила. Сродства должны быть доступны простым смертным. Не идиотам, но и не тем не многим кто ради возможностей может сломать свое сознание и начать думать по другому.
Боюсь, что Лисп как раз и стал косвенным "доказательством" проблемности языкового подхода. Испортил общественное мнение, так сказать. К тому же он сильно опередил свое время. Но то что он жив, не смотря на свой странный вид, говорит о том, что он появился не спроста.
VD>>Он тебе раз 10 повторил — опора на вменяемые кадры. Для использования ДСЛ нужно просто быть вменяемым программистом. Для их разработку нужно к тому же быть вменяемым архитектором ПО.
I>Не ясно, что такое вменяемые и где их брать, как готовить.
Это тоже уже обсуждалось. Невменяемые программисты могут писать только говнокод. А вменяемых программистов очень много, если не сказать — большинство.
I>Для бизнеса очень хорошо брать людей "на вырост", то есть, чем моложе, тем лучше. Чему их готовить ? Сразу монады хаскеля вливать в головы ?
Да бери на вырост. Тут никакой разницы с обычным подходом нет. Сколько можно одно и то же повторять?
VD>>Второй — это вопрос образования и пиара. Было бы замечательно, если бы наши вузы перестали убивать новые поколения программистов, а начали бы обучать тем самым методикам. В том числе и методикам разработки и эксплуатации ДСЛ-ей при разработке ПО.
I>Ну так вы с Wolfhoundon молчите, как партизаны, и не говорите кто же такой вменяемый программист.
Тебе уже сто раз ответили. Я уже было хотел сказать тебе что это ты (в том числе), но то как ты упорно отстаиваешь явно неверную позицию останавливает меня :).
Вообще прикольно, что каждый считает себя вменяемым программистом, а все вокруг него идиоты. Прям как на этом рисунки:
I> А между тем бизнес-специфика выражается чуть ли не линейным кодом, максимум круд, где сложность в написании запроса, для чего уже есть все необходимые инструменты.
Сам то в это веришь? Если так, то зачем все эти форумы, книги, средства разработки? И почему весь нужный софт еще не написан, а сроки разработки постоянно срываются?
VD>>Главная проблема Лиспа — отсутствие синтаксиса. По сути программисту предлагается писать в АСТ. Причем АСТ выраженном в виде списков. Читаемость такого кода довольно низка.
I>Вижу, есть сдвиги — всего пару лет назад ты чуть не с пеной кидался на людей у кого были такие же аргументы :))
Ты что-то путаешь. Ссылку в студию, плиз.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, oldjackal, Вы писали:
N>>Тут больша виновата команда, что не одернула его. O> Не положено в таких местах начальство одергивать.
ORLY? Тогда не надо вообще ни на один метод грешить, потому что в таких условиях ни один метод не будет нормально работать. Прежде чем вообще хоть что-то использовать и разрабатывать, надо создать рабочую среду, при которой любой метод будет применяться адекватно ситуации, а не наобум.
А так сейчас у тебя будет ненависть ко всему, что модно, только потому, что оно модно. Но ведь метод не виноват, что он стал модным именно сейчас?
N>>Вы как-то очень странно относитесь именно к средствам. Вот Вам в качестве обратного примера — sendmail. Там явно сидят Ваши сторонники — 30 лет развития без единого рефакторинга. O> Там с самого начала была идиотская архитектура. Не очень хороший пример.
Именно что поэтому очень хороший пример! У чего угодно может быть изначально идиотская архитектура (а в 99% случаев и будет), потому что
было написано в качестве доказательства концепции, наскоро
оторвалось от чего-то, имеющего изначально существенно другую идею (как sendmail появился как межузловой транспорт для локального /bin/mail)
концепция нормально выкристаллизовалась только в пятой версии, до того никто не представлял себе её в нужном виде (почитай-ка труды основателей, например, дифференциального исчисления. только в оригинале...)
и после этого, если ставится цель не потратить грант или распилить бюджет, а именно сделать как следует, минимально и управляемо ломая уже существующее — именно рефакторинг и нужен. И, между прочим, это не только в программировании.
N>> Но если бы был автомат — то применил бы и автомат. А почему так сразу "тонны" кода? Обычно, мне кажется, меняются только определённые места, и не делается незапрошенных прогонок по всему коду. O> Например, изменение имени какого либо класса или метода, используемого во множестве модулей.
Если публичный API — да, плохо. Тогда придумывают какую-то совместимость, переходные меры.
А если внутренний — страдающих мало, или же и так надо было переделывать, потому что архитектура была ужасная.
N>> Потому что рефакторинг допустим и нужен, но только тогда, когда не предполагается таких вот мержей втихую в одном месте без корреляции с остальными. O> Рефакторинг допустим только тогда, когда вообще никаких merge-ей не предполагается в принципе. Когда все тысячи разработчиков дружно гадят в один общий trunk. Ну прямо таки идеал организации разработки, не находите?
Не нахожу. На практике или есть адекватное разделение структуры, и тогда большинство этих преобразований не влияют на "тысячи разработчиков", или его нет, тогда его и так надо было делать, и внешняя необходимость только подтолкнула процессы.
N>>А ещё больше виновата контора в целом — что не контролирует процесс. O> Процесс-то как раз устоявшийся за десятилетия, отлаженный как часы. И никакого рефакторинга не предполагающий по определению. Конечно же, на ошибках учиться надо, это их вина, что после первого такого евангелиста не вкличили в интервью вопросы об отношении к рефакторингу.
А также — что радикальные меры не были отменены и применены, если и нужно, то в месяц по чайной ложке.
Итого — просто плохая контора. Бывает, тут вокруг таких на рупь десяток.
O> Надо, надо. Надо энтузиастов рефакторинга сажать в клетки и размножаться не давать.
Я бы лично сажал в клетки тех, кто оценивает инструмент по последствиям неадекватных применений в заведомо неадекватных местах. Ничего личного.
Здравствуйте, oldjackal, Вы писали:
O> Ручками, аккуратно, вдумчиво, страдая и мучаясь. Потому как если это будет слишком легко делать, этим будут злоупотреблять.
Я не согласен.
O> Вот-вот, я не представляю, какая вообще польза от таких может быть. Ни разу живьем их в реальной работе не видел (а видел очень много всякого), какие-то они мифические, все про них пишут, и никто показать не может.
Тебе повезло.
Я видел.
Убить был готов.
O> Хотя вру, видел однажды последствия их работы. Индийский аутсорсинг. За ними, понятное дело, потом полностью с нуля все переписывали, так что экономическая выгода крайне сомнительна.
Во-во. Только Ikemefula это не понимает.
WH>>А если нужны качественные сообщения об ошибках. O> Какие с этим проблемы? Ассертов в макре расставить, и все.
Не только. Нужно еще нормальные сообщения от парсера.
Как бы ты не старался, но тебе меня не убедить в том, что синтаксис не нужен.
WH>>Предметно-ориентированные системы типов. O> С системами типов никаких проблем нет, если есть Пролог.
Только писать много. И понять, как работает не просто.
WH>>Вывод типов, понимающий перегрузки. O> Опять же, с Прологом не проблема.
Не все так просто. Ибо если делать в лоб, то тебя комбинаторные взрывы прикончат.
O> Не убежден в ценности IDE для DSL-ей. Много там у нас IDE, поддерживающих SQL? Не особо. И никто не жалуется.
Ты удивишься. http://www.jetbrains.com/idea/img/injection_before_after.gif
O>Много IDE для навороченных DSL-ей в разного рода CAD-ах? Для того же автокада, для инструментов Cadence? Ничего нет, и народ не жалуется, пишут миллионы строк кода на DSL без всяких IDE.
у них просто выбора нет.
Ибо создание ИДЕ при использовании современных инструментов это очень дорого.
А если бы IDE получалась сама. А такие вещи как автодополнение и некоторые рефакторинги можно генерировать полностью автоматически.
То это все было бы.
Даже были бы те рефакторинги которые бы пришлось писать руками ибо на правильных ДСЛ это десятки строк на рефакторинг.
O> IDE нужны для работы с гигантскими фреймворками, для жаба-ынтырпрайза всякого. То есть для того, что с массовым введением DSL станет просто ненужным.
Категорически не согласен.
O> А не надо усложнять. Как по мне, так большинству DSL и синтаксиса-то никакого не надо (но понимаю прекрасно, что лисперу по этому пункту со всеми остальными никогда не договориться). Тем, кому надо, часто больше подходит графическое представление (а тут для нас уже Microsoft расстаралась).
Графическое представление не работает чуть менее чем всегда.
Вон тот же AndrewVK пытался делать графические ДСЛ.
На маленьких задачах все было отлично.
Как только задача разрастается. Понять, что там происходит, становилось невозможно.
Единственный известный мне, графический язык которой имеет шансы, не скатится в говно на задачах больше чем hello world это ДРАКОН.
O> Как и подавляющее большинство очень популярных и очень жизненных языков. Кто жизненнее — популярнейшие Python, Javascript, Ruby, Perl, Shell-ы всякие или
Вопрос в том среди кого они популярны.
Я их даже в руки не возьму. Кроме однострочников Shell ибо выбора нет. Пока.
O>мертвый Haskell
Я думаю, он как минимум не менее живой чем лисп.
И вообще поосторожней с заявлениями о том что хаскель мертв http://lurkmore.to/%D0%A4%D0%B0%D0%B9%D0%BB:Z150_03.jpg
O>и унылая ынтырпрайзная Java? Не такой уж и простой вопрос.
В больших конторах более популярны статически типизированные языки.
WH>>Одно это уже делает его оторванным по самые не балуйся. O> Я в эту типизированную религию не верю,
А я статическую типизация каждый день использую.
Очень удобно, когда компилятор ошибки ловит.
O>вверх и вниз по лямбда-кубу налазился в свое время, понял, что тлен это все и суета.
Матанистые системы типов действительно суета.
Ведь все эти навороты используются только для того чтобы выразить некие прикладные ограничения. И получается это всё равно через жопу.
Здравствуйте, WolfHound, Вы писали:
VD>>>Создание других рефакторингов можно будет резко упростить. I>>То есть, я пишу ДСЛ и я же должен буду рефакторинги писать ? Кушайте сами. WH>Если написание рефакторинга займет десяток строк то в чем проблема?
Ну вот покажи, как абзац текста убрать в пяток функций
I>>Это самый лучший расклад. Все остальные еще хуже. Например берем знакомую тебе полиграфию. Доход от печатной продукции. Программинг всего лишь обслуживающая система. Опаньки ! WH>А сколько та же контора использует софта, который пишется конторой, которая только софт и пилит?
Копейки.
I>>Ты сам то подумай, Лисп уже был, а писали и в машинных кодах, потом на асме, потом на фортранах-коболах, потом на си. I>>История Лиспа тебя ничему не научила ? Сочувствую. WH>Ох. Лисп динамически типизированное тормизилово. WH>А в те годы каждый такт был на счету. Ибо стоил на несколько порядков дороже, чем сейчас.
Не было никогда на счету всяких тактов, задачи были другими.
WH>А что касается мета-программирования то посмотри, сколько шума вокруг Ruby on Rails. WH>25 700 000 результатов в гугле. WH>А ведь это ДСЛ.
Ну вот один руби нужен. А зоопарк дсл да в одном проекте — нет, не нужен.
Здравствуйте, VladD2, Вы писали:
I>>То есть, я пишу ДСЛ и я же должен буду рефакторинги писать ? Кушайте сами.
VD>Или ты, или кто-то еще. Например, тот кто твой ДСЛ использует. Задача создания рефакторингов упростится. Ее сможет решать любой вменяемый программист.
Не ясно, кто такой "вменяемый программист"
VD>Твой скепсис просто умиляет. Сейчас люди клепают ДСЛ-и которые вообще не имеют средств рефакторинга. Никаких! Мы же предлагаем дать им комплексное решение.
Ну так давай, кто ж мешает ?
VD>Сделать некоторые виды рефакторинга автоматом физически невозможно. Но можно упростить их создание сделав, тем самым, их создание доступным массам.
I>>Все не знаю. Наибольшее влияние на бизнес оказывает менеджмет. Далее — маркетинг. Уже потом инженеры, дизайнеры и тд, из которых часть админов, часть безопасников, часть тестировщиков, аналитиков и тд.
VD>Это такой защитный гон. Типа разработка ПО — это пустяки. "Фигня война! Главное — маневры!".
Это факты.
VD>Маркетологи могут работать совершенно независимо от разработчиков. Они из другой "вселенной". И по их вине крайне редко заваливаются сроки или выпускается некачественный продукт. А вот по вине программистов — постоянно!
Цена ошибки разработчка это сорваный срок. Цена ошибки маркетолога это проценты в доле рынка а следовательно заработок конторы. Цена ошибки менеджмента == цена бизнеса.
Мне что, объяснить, что важнее из этих трех вещей ?
VD>Так что если тебе хочется поговорить о маркетинге или управлении, то иди на соответствующие форумы. А этот форум посвящено разработке ПО.
Ты предлагаешь решения для бизнеса и при этом знать нехочешь ничего про этот бизнес. ТАк не выйдет.
I>>Это самый лучший расклад. Все остальные еще хуже. Например берем знакомую тебе полиграфию. Доход от печатной продукции. Программинг всего лишь обслуживающая система. Опаньки !
VD>Какую из систем? Ты видел как сейчас печатают малотиражную продукцию?
Неужели в Visual Studio ?
>Ее печатают на автоматизированных комплексах. Эдакий мега-принтер. Там ПО решает чуть меньше чем все вопросы. А его сложность весьма высока.
Ну и менеджмент-маркетинг конечно же ничего не решает. Ага
VD>Вопросы организации заказов решаются финансовыми системами мало чем отличающимися от аналогичных на других видах предприятиях. Обычно это банальный 1Эс. Максимум с небольшими доработками.
Ну решаются, что с того ? Менеджмет и маркетинг всё равно бОльшее влияние имеют, примерно на порядок а то и больше.
VD>Ты договорился до полного абсурда. Следующим шагом, видимо, будет апелляция к тому что на свете живут вообще глухие и слепые люди, и им Немерл не нужен.
Я указываю про особенности бизнеса и прошу раскрыть формулу "вменяемый разработчик" а тебе мерещится "Немерл не нужен"
По моему это к доктору
VD>Проблема в том, что Лисп требует ломки сознания и динамически типизирован. В динамическом мире есть как минимум две альтернативы Лиспу — Питон и Руби. Их мэйнстрим принимает куда охотнее. В них тоже есть метапрограммирование, но другого рода. А гибкость достигается за счет динамики. В статически же типизированном мире ничего подобного нет.
Не требует они никакой ломки. Как только ты раскроешь формулу "вменяемый разработчик" все станет очевидно.
VD>Научила. Сродства должны быть доступны простым смертным. Не идиотам, но и не тем не многим кто ради возможностей может сломать свое сознание и начать думать по другому.
Похоже, не научила.
I>>Не ясно, что такое вменяемые и где их брать, как готовить. VD>Это тоже уже обсуждалось. Невменяемые программисты могут писать только говнокод. А вменяемых программистов очень много, если не сказать — большинство.
Ну да и потому вы оба 80-90% предлагаете вообще выгнать из индустрии ?
I>>Для бизнеса очень хорошо брать людей "на вырост", то есть, чем моложе, тем лучше. Чему их готовить ? Сразу монады хаскеля вливать в головы ? VD>Да бери на вырост. Тут никакой разницы с обычным подходом нет. Сколько можно одно и то же повторять?
Конечно нет. Только не ясно, какие знания и умения требуются на входе и сколько времени их нужно прокачивать.
VD>Вообще прикольно, что каждый считает себя вменяемым программистом, а все вокруг него идиоты. Прям как на этом рисунки: VD>
Это про вас c WH.
I>> А между тем бизнес-специфика выражается чуть ли не линейным кодом, максимум круд, где сложность в написании запроса, для чего уже есть все необходимые инструменты.
VD>Сам то в это веришь? Если так, то зачем все эти форумы, книги, средства разработки? И почему весь нужный софт еще не написан, а сроки разработки постоянно срываются?
Потому что код не является узким местом в большинстве проектов.
I>>Вижу, есть сдвиги — всего пару лет назад ты чуть не с пеной кидался на людей у кого были такие же аргументы
VD>Ты что-то путаешь. Ссылку в студию, плиз.
Пофикси поиск сначала. Щас в одном топике нельзя ничего найти, не то что на всем сайте
Здравствуйте, Ikemefula, Вы писали:
I>Цена ошибки разработчка это сорваный срок. Цена ошибки маркетолога это проценты в доле рынка а следовательно заработок конторы. Цена ошибки менеджмента == цена бизнеса.
Да. Согласен. Не выполненная работа, сделанная в неприемлемое время или с ненадлежащим качеством — это ни разу не проблема. В мире все ради управления и маркетинга. Без них прожить нельзя. Без остального — легко.
Тут, конечно, не поспорить.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ikemefula, Вы писали:
I>Цена ошибки разработчка это сорваный срок. Цена ошибки маркетолога это проценты в доле рынка а следовательно заработок конторы. Цена ошибки менеджмента == цена бизнеса.
I>Ну решаются, что с того ? Менеджмет и маркетинг всё равно бОльшее влияние имеют, примерно на порядок а то и больше.
Уважаемый, у тебя все перевернуто с ног на голову. Это не производство ради макретинга и менеджмента, а макретинг и менеджмент для производства.
Что будут "маркетировать" маркетологи, если не будет продукта или он будет не качественным? А что это за управление такое, которое привело к ситуации когда программисты заняты хрен знает чем, а маретологи пиарят воздух?
Мы точно о софтовой конторе речь ведем, а не об МММ?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, oldjackal, Вы писали:
VD>>Плюс Лисп — это динамически типизированный язык. И в мир статики он вписывается крайне хреново.
O> Это не обязательное свойство Лиспа, он может быть как угодно типизированным (см. Shen, бывший Qi).
Посмотрел Shen. Shen мне понравился. Паттерн-матчинг, удобные лямбды, встроенный пролог, континюэшоны — это все красиво.
Но он такой же динамически типизированный как и все остальные живые варианты Лиспа. То что нем можно врубить опцию (tc +) еще не делает его полноценным статически-типизированным языком. Все проблемы динамики в нем присутствуют.
Кроме того у него куча других проблем.
Начнем с того, что его толком еще и не сделали. Стабильного релиза для Винды нет. Мои эксперименты быстро привели к появления AV.
Далее это обертка над другими лиспами. Так что реально его возможности упираются в возможности базовой лисп-платформы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Он тебе раз 10 повторил — опора на вменяемые кадры. Для использования ДСЛ нужно просто быть вменяемым программистом. Для их разработку нужно к тому же быть вменяемым архитектором ПО.
Тут где-то рядом Wolfhound, вроде, говорил, что для разработки ДСЛя особо мозгов не надо. Вы уже договоритесь, а
M>>Тут где-то рядом Wolfhound, вроде, говорил, что для разработки ДСЛя особо мозгов не надо. Вы уже договоритесь, а VD>Ты откровенно извращаешь его слова. Он говорил, что для этого не надо быть особо одаренным.
Может быть и извратил, но точно не откровенно. Ща, правда, совсем лень искать. В отпуске я
Здравствуйте, oldjackal, Вы писали:
O> IDE нужны для работы с гигантскими фреймворками, для жаба-ынтырпрайза всякого. То есть для того, что с массовым введением DSL станет просто ненужным.
Ты не верно оцениваешь ресурсы. Человеческие (умственные) ресурсы константы. Однако человеческие потребности беспредельны.
Если мы переводим разработку на массовое использование ДСЛ-ей, то у нас неизбежно поднимется производительность труда программистов. Но она приведет не к облегчению их жизни, а к усложнению задач и/или к увеличению их объемов.
В результате, мы получим такие объемы кода на ДСЛ-ях и такую их взаимосвязанность, что проблемы проявятся на новом уровне. Так что потребность в качественных инструментах работы с ДСЛ-ями — это всего лишь вопрос времени.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Грамотно ограниченный ДСЛ позволит использовать людей со слабой квалификацией и ограниченными возможностями. Фрэймворки и библиотеки такого же эффекта не дадут.
Зависит от языка, фреймворков и библиотек. RoR и Django вполне себе позволяют использовать людей со слабой квалификацией и ограниченными возможностями. При том, что RoR — это, по сути, DSL, а Django — нет.
Здравствуйте, Mamut, Вы писали:
M>Зависит от языка, фреймворков и библиотек. RoR и Django вполне себе позволяют использовать людей со слабой квалификацией и ограниченными возможностями. При том, что RoR — это, по сути, DSL, а Django — нет.
А можно показать типичный код на Django?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Mamut, Вы писали:
M>Зависит от языка, фреймворков и библиотек. RoR и Django вполне себе позволяют использовать людей со слабой квалификацией и ограниченными возможностями. При том, что RoR — это, по сути, DSL, а Django — нет.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Mamut, Вы писали:
M>>Зависит от языка, фреймворков и библиотек. RoR и Django вполне себе позволяют использовать людей со слабой квалификацией и ограниченными возможностями. При том, что RoR — это, по сути, DSL, а Django — нет.
VD>Вот это он?
VD>И это не ДСЛ?
Здравствуйте, Mamut, Вы писали:
M>Это вюуха с шаблонизатором для HTML'я,
И это не ДСЛ? Вообще, удивительно как можно уходить от столь прямого вопроса.
M> а есть и вполне себе контроллеры и модели, написанные на Python'е. Но особой квалификации и там уже не требуется: https://docs.djangoproject.com/en/1.4/intro/overview/
Ничего, что это — вызов библиотечной функции? Не помню, кто тут говорил (может и не ты), что библиотеками ДСЛ не заменить
VD>Короче, ты явно однобоко смотришь на код.
Однобоко смотришь ты, но тебе можно простить, ты Джанго не знаешь.
В Джанго, по сути, есть ровно один DSL — это Django Template Language для вьюх. Но ведь вьюхами дело не заканчивается, так ведь
Вролне себе декларативно-ДСЛеподобное описание модели/ORM'а, которое легко и просто разворачивается в
>>> from datetime import datetime
>>> a = Article(pub_date=datetime.now(), headline='Django is cool',
... content='Yeah.', reporter=r)
>>> a.save()
# Now the article is in the database.
>>> Article.objects.all()
[<Article: Django is cool>]
и прочую толпу методов При этом это как бы совсем не DSL, а просто ООП, но для использования мозгов не требуется вообще:
и т.п. Так оно еще и ленивое (то есть выполняется общий конечный запрос, а не по запросу на каждый вызов метода).
Ну и контроллер ко всему этому, где основное-то и происходит. Что-то типа
def vote(request, poll_id):
p = get_object_or_404(Poll, pk=poll_id)
try:
selected_choice = p.choice_set.get(pk=request.POST['choice'])
except (KeyError, Choice.DoesNotExist):
# Redisplay the poll voting form.return render_to_response('polls/detail.html', {
'poll': p,
'error_message': "You didn't select a choice.",
}, context_instance=RequestContext(request))
else:
selected_choice.votes += 1
selected_choice.save()
# Always return an HttpResponseRedirect after successfully dealing
# with POST data. This prevents data from being posted twice if a
# user hits the Back button.return HttpResponseRedirect(reverse('polls.views.results', args=(p.id,)))
К чему я это? А, к этому:
VD>Грамотно ограниченный ДСЛ позволит использовать людей со слабой квалификацией и ограниченными возможностями. Фрэймворки и библиотеки такого же эффекта не дадут.
Зависит от языка, фреймворков и библиотек. RoR и Django вполне себе позволяют использовать людей со слабой квалификацией и ограниченными возможностями. При том, что RoR — это, по сути, DSL, а Django — нет.
Повторюсь, в Django из действительно DSL — только Template Language. И его роль я не хочу нисколько не преуменьшить — вещь крутая, и особой квалификации тоже не требует. Но и сам фреймворк дает вполне такой же эффект, как и гипотетические DSLи
