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

T>Именно те же и встанут.
Ну как это они вдруг встанут в языке, где вообще нет мутабельных типов?
Как только мы отказываемся от идеи модифицировать состояние, проблема моментально решается. Можно "наследовать" прямоугольник от квадрата, добавляя ему ещё один параметр, а можно — квадрат от прямоугольника.
А если отказаться от наследования, переместив полиморфизм на другую сторону call site, то и сам вопрос "кого от кого" вообще исчезнет.
Вот так язык влияет на мышление.

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

T>>Именно те же и встанут.
S>Ну как это они вдруг встанут в языке, где вообще нет мутабельных типов?
S>Как только мы отказываемся от идеи модифицировать состояние, проблема моментально решается. Можно "наследовать" прямоугольник от квадрата, добавляя ему ещё один параметр, а можно — квадрат от прямоугольника.
S>А если отказаться от наследования, переместив полиморфизм на другую сторону call site, то и сам вопрос "кого от кого" вообще исчезнет.
S>Вот так язык влияет на мышление.

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

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

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

T>>100 человек не потому, что надо кода много писать, а потому, что количество требований и ограничений велико.

VD>Это чушь. 100 человек вообще не могут написать вменяемый софт.

100 человек естественно не пишут одну функцию.

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

Корпоративный софт именно так и написан.

Скажем сервисы современных контор гигантов так и пишутся и там не 100, а тысяча разработчиков это не предел.

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

S>Ну как это они вдруг встанут в языке, где вообще нет мутабельных типов?
S>Как только мы отказываемся от идеи модифицировать состояние, проблема моментально решается. Можно "наследовать" прямоугольник от квадрата, добавляя ему ещё один параметр, а можно — квадрат от прямоугольника.
S>А если отказаться от наследования, переместив полиморфизм на другую сторону call site, то и сам вопрос "кого от кого" вообще исчезнет.
S>Вот так язык влияет на мышление.

Берем наследование прямоугольника от квадрата на примере иммутабельного списка. Новый класс внезапно добавляет методом Add не один, а два элемента. Ну то есть исправно возвращает новый список, но у него уже не на один элемент больше, а на два. Всё, приехали — модификации состояния нет, а проблема "прямоугольник от квадрата" как была, так и осталась.

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

T>>Это не тот Nemerle-C# который не может скомпилировать BLT ? Аргумент не в пользу Peg, скажем так.

VD>Есть огромная разница между распарсить, и скомпилировать. Любой C# 4-код парсится без проблем.
VD>К тому же компиляция BLT проходит. Но в немерле есть некоторые косяки которые приводят к падению скомпилированного кода в рантайме.

Компиляция и парсинг никому, кроме гиков, не нужны, если код падает в рантайме.
P.S. Приходишь ты в лабаз и говоришь — дайте мне BMV X5 последний. Они тебе дают и говорят — есть огромная разница между выпуском авто и кручением руля. У нас авто выпускаются без проблем. Да и руль крутить можно. Но есть некоторые косяки, из за которых X5 ехать не может.

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

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

T>>>Это не тот Nemerle-C# который не может скомпилировать BLT ? Аргумент не в пользу Peg, скажем так.

VD>>Есть огромная разница между распарсить, и скомпилировать. Любой C# 4-код парсится без проблем.
VD>>К тому же компиляция BLT проходит. Но в немерле есть некоторые косяки которые приводят к падению скомпилированного кода в рантайме.

T>Компиляция и парсинг никому, кроме гиков, не нужны, если код падает в рантайме.
T>P.S. Приходишь ты в лабаз и говоришь — дайте мне BMV X5 последний. Они тебе дают и говорят — есть огромная разница между выпуском авто и кручением руля. У нас авто выпускаются без проблем. Да и руль крутить можно. Но есть некоторые косяки, из за которых X5 ехать не может.

Но ведь парсер и DSL выполняют свою задачу корректно, так что почему это аргумент не в пользу Peg, я

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

T>>Компиляция и парсинг никому, кроме гиков, не нужны, если код падает в рантайме.
T>>P.S. Приходишь ты в лабаз и говоришь — дайте мне BMV X5 последний. Они тебе дают и говорят — есть огромная разница между выпуском авто и кручением руля. У нас авто выпускаются без проблем. Да и руль крутить можно. Но есть некоторые косяки, из за которых X5 ехать не может.

I>Но ведь парсер и DSL выполняют свою задачу корректно, так что почему это аргумент не в пользу Peg, я

Речь то про тесты была изначально. Код не работает — значит тестов не было. Или в Немерле изобрели способ выполнять тесты вне рантайма ? Интересная техника, похоже, я чтото пропустил в этой жизни.

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

IT>Лучше прикинь другое. Для сапорта и мейнтененса никто не нужен, потому что сапорт и мейнтененс настолько тривиальны, что занимают от нуля до половины процента времени. У меня вообще хобби такое создавать решения не требующие саппорта. А если я уйду, то минимум год с моим кодом будет всё в порядке. В нём легко разберуться и легко начнут сапортить, пока не понавносят туда изменений, которые напрочь уничтожат всю вложенную туда простоту мейнтейнабилити и саппортобилити. И пофиг будут там МП и DSL или их там не будет.

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

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

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

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

В продуктовых шансов на ошибку быть не может, а денег вобщем хватает.

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

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

И вот здесь получается так, что мега-МП-ДСЛ создают сильные риски, которые сказываются на проекте.

В инфраструктурном, если ушел архитект, ну и хрен с ним, посидят на старой версии пока новый не подымет проект.

В продуктовом это фейл, цена которого равняется цене релиза.

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

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

Единсвенное решение — административное. Например всегда иметь дублеров и желательно не одного, а двух.

И выходит так, что мега-МП-ДСЛ само по себе не работает, ему нужен административный костыль. Опаньки !

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

I>>Но ведь парсер и DSL выполняют свою задачу корректно, так что почему это аргумент не в пользу Peg, я

T>Речь то про тесты была изначально. Код не работает — значит тестов не было. Или в Немерле изобрели способ выполнять тесты вне рантайма ? Интересная техника, похоже, я чтото пропустил в этой жизни.

Еще раз. Есть парсер-генератор, есть сгенерированный им парсер и есть компилятор. К первым двум претензий, в данном случае, нет.

Компилятор же покрыт тестами, сотнями тестов. Но это не спасает от ошибок, особенно учитывая различную семантику nemerle и C# в некоторых случаях. Компилятор C#, так же, гоняли на нескольких опенсорсных проектах, но BLT не типичный проект, сложность задач там зашкаливает, а помноженная на необходимость оптимизации она диктует довольно нестандартные решения. Тесты тут совершенно не в тему — ни один человек тестер подобные синтетические тесты написать не в состоянии, их можно получить только на реальном коде типа BLT.

Прежде чем делать безапелляционные заявления надо попытаться понять о чем идет речь. А то получается слышал звон...

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

T>Берем наследование прямоугольника от квадрата на примере иммутабельного списка. Новый класс внезапно добавляет методом Add не один, а два элемента. Ну то есть исправно возвращает новый список, но у него уже не на один элемент больше, а на два. Всё, приехали — модификации состояния нет, а проблема "прямоугольник от квадрата" как была, так и осталась.
Не вижу никакой проблемы. Сформулируйте её, пожалуйста, в этом примере.

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

D>То ж была такая ж мысль, пока писал. Но мысль была нечёткой, и я побоялся такие громкие заявы делать.

Ну на SQL местные противники DSL могут возразить, что это язык придуманный гениями по крутой теории.

А вот HQL это уже вольная вариация на тему SQL, придуманная вполне рядовыми программистами. Вобщем все ужасы DSL, которые тут описали присутствуют. И никто не увольняется, никто не плачет, что синтаксис ставит в тупик и лучше уж старый добрый SQL. Живет и альтернатив в Java мире ему практически нет. В .net же он легко убит другим, встроенным в язык, DSL, совмещающим возможности HQL и CriteriaAPI.

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

T>>Берем наследование прямоугольника от квадрата на примере иммутабельного списка. Новый класс внезапно добавляет методом Add не один, а два элемента. Ну то есть исправно возвращает новый список, но у него уже не на один элемент больше, а на два. Всё, приехали — модификации состояния нет, а проблема "прямоугольник от квадрата" как была, так и осталась.
S>Не вижу никакой проблемы. Сформулируйте её, пожалуйста, в этом примере.

Представь себе метод, который дополняет список новыми операциями, скажем, новые проводки. Нечто вроде кеша, операции добавляются в список. Поработал пользователь с программой, сделал пару проводок, скажем 5 по 100 долларов, а в саммари видит счет на 1000 и если он не заметит подвоха, то оплатит счет на вдвое большую сумму. Вот это и есть наследование прямоугольника от квадрата.

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

T>Представь себе метод, который дополняет список новыми операциями, скажем, новые проводки. Нечто вроде кеша, операции добавляются в список. Поработал пользователь с программой, сделал пару проводок, скажем 5 по 100 долларов, а в саммари видит счет на 1000 и если он не заметит подвоха, то оплатит счет на вдвое большую сумму. Вот это и есть наследование прямоугольника от квадрата.
По-прежнему не понимаю проблемы. То, о чём вы говорите, можно сделать вообще без наследования.

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

S>По-прежнему не понимаю проблемы. То, о чём вы говорите, можно сделать вообще без наследования.

Что именно не понятно, как код заточеный под контракт, может свалиться если контракт нарушается ? Можно вообще все писать без ооп, фп а обходиться одним процедурным программированием на ассемблере. Это ни о чем не говорит.

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

T>>Представь себе метод, который дополняет список новыми операциями, скажем, новые проводки. Нечто вроде кеша, операции добавляются в список. Поработал пользователь с программой, сделал пару проводок, скажем 5 по 100 долларов, а в саммари видит счет на 1000 и если он не заметит подвоха, то оплатит счет на вдвое большую сумму. Вот это и есть наследование прямоугольника от квадрата.
S>По-прежнему не понимаю проблемы. То, о чём вы говорите, можно сделать вообще без наследования.

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

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

T>Контракт можно нарушить не используя никакого наследования. Мне вот непонятно, почему вдруг нарушение контракта возможно только в ООП или наследовании
Потому, что проблема с наследованием квадрата от прямоугольника — это проблема с наследованием. Получить проблему с наследованием можно только в случае наличия наследования. Ваш К.О.
Более подробно: проблема квадрат/прямоугольник сводится к тому, что задавшись требованиями к мутабельности, невозможно построить их контракты таким образом, чтобы один был частным случаем другого. Понимаете? Не в том проблема, что можно написать плохую реализацию, а в том, что невозможно написать хорошую.

Как только мы отказываемся от мутабельности, сразу всё становится хорошо — исчезают противоречивые требования.

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

Здравствуйте, Ikemefula, Вы писали:
I>Что именно не понятно, как код заточеный под контракт, может свалиться если контракт нарушается ?
Непонятно, почему вы подменяете одну проблему другой.
I>Можно вообще все писать без ооп, фп а обходиться одним процедурным программированием на ассемблере. Это ни о чем не говорит.
Можно. Это породит другие проблемы. Чтобы их конструктивно обсуждать, желательно в них хоть немного разобраться.
Вы, судя по вашим комментариям, вообще не в курсе, в чём состоит "проблема наследования прямоугольников и квадратов".
И вообще, в некотором смысле вообще все проблемы в программировании происходят от нарушения контрактов.
То есть, такая классификация проблем нам совершенно бесполезна — она относит все проблемы в один класс, и не позволит сравнить удобство или выразительную мощь разных языковых решений.
Именно поэтому нужно понимать, чем одни проблемы отличаются от других, и какие меры предотвращают определённые типы проблем.

В частности, проблемы с наследованием возникают только там, где есть наследование. Проблемы с некорректными указателями возникают там, где есть указатели. Проблемы с NullReference возникают только там, где есть null references.
Ваш К.О.

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

M>Только вот у некоторых пропонентов DSLей зашорены глаза: мол, DSLи и понятны сразу, и документированы сразу, и инструментарий есть и вообще, это панацея от всего (можно почитать предыдущие топики на эти же темы). Что, естественно, далеко не так.

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

Хотя, возможно, я не прав и просто не знаю куда посмотреть.

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

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

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

Вообще можно смотреть на форт, как на модель такого супер-макро-языка и сразу же думать о сильных и слабых сторонах подхода...

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

S>То есть, такая классификация проблем нам совершенно бесполезна — она относит все проблемы в один класс, и не позволит сравнить удобство или выразительную мощь разных языковых решений.

Что бы сравнить удобство и выразительную мощь, необходимо в том числе решить типичные задачи в одной области с помощью средтств совершенно из другой области.

Почему то "открыть дверь" предлагают решить только в ООП, и никто не захотел показать решение той же задачи в функциональном.

Как уже предлагалось — напиши грамотный мега-uber-рич-эдит на хаскеле или F# и что бы без ооп, да так, что бы его можно было кинуть на форму одной кнопкой и юзать так же, как и любой другой рич эдит.

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

Если не нравится рич-эдит, посмотри в те задачи, которые типично решаются с помощью С++, например видео или звук.

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

Если получится — вот тогда можно говорить что "будут совсем другие проблемы ". А не получится — пеняй на себя

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

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

H>Ну ты все-таки соизмеряй масштабы примеров. Если предметная область оказалось настолько суровой, что потребовалось наколбасить крутой DSL уровня SQL, то и библиотека классов с аналогичным функционалом должна быть некислого размера.

Ну и что, что некислого размера? Библиотеку помнить наизусть необязательно, бо современные IDE некисло помогают пользоваться библиотекой. Но пользоваться каким-то новым синтаксисом другого языка еще ни одна IDE не помогала. Синтаксис языка надо знать самому, увы.