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

I>>Как называется эта абстракция и как быть если он реализована в другом языке иначе и называется иначе ?
S>Абстракция называется "вызов метода", "вызов процедуры", или "вызов функции". Она присутствует в нативном виде во всех императивных языках, начиная примерно с шестидесятых. Как именно она реализована, обычно мало кого интересует. Скажем, в JS вызов методов "внутри" устроен сильно не так, как в С++, тем не менее это совершенно не мешает читать JS-ный код, и проектировать систему с использованием JS.

А что нам даёт такое название ? Вот с обсервером понятно, с эвентом — понятно. С сигналом — тоже понятно. Теперь называем это функцией и что ?

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

I>>Совсем необязательно. Есть например всевозможные оптимизации, есть случаи с несколькими языками. Например в C# встроены итераторы. Открываем класс Enumerable и видим, что наравне с православными итераторами, если реализации паттерна в чистом виде. Опаньки !
S>Что вы называете "реализацией паттерна в чистом виде"?

Значит реализован именно паттерн итератор, а ен просто код который похож и на итератор и на обсервер и на что угодно.

I>>И второй момент — объясни, чем обсервер отличается от эвента. Например, что если есть некоторый язык, в котором есть та же фича, но называется как нибудь иначе, например — сигнал. Как с этим быть ?
S>Проектировать архитектуру в терминах сигналов.
S>Фича же может быть реализована по-разному. Скажем, в Delphi "евенты", которые были просто свойствами процедурного типа, не поддерживали множественность подписчиков. Это сильно повлияло на архитектуру DataSet и DataSource, которая занимает центральное место во всей VCL.
S>То есть поверх языковых средств был реализован отдельный паттерн для развязки подписчиков и публишеров. В C# нужды в этом паттерне нет, т.к. множественные подписчики работают из коробки.

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

I>>Что бы реализовать такой софт придется всунуть в пролог например весь православный ООП.
S>Не торопитесь с примером — я схожу за попкорном.

Уже всё сказано. Кроме как заимствованием парадигм эту задачу не решить.

I>>"решение" является частью паттерна, только решение не то, что нам надо, а скорее "мета-решение".
S>Конечно же это "мета-решение". Потому что "решение", которое нужно — это готовый код.
S>Когда у нас есть готовый код, мы не называем это "паттерном". Мы называем это "библиотекой", и даём её скачать бесплатно либо за деньги.

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

S>Посмотрите на то, как реализуется INotifyPropertyChanged — чистой воды копипаста. Поэтому решения — нет. Есть "мета решение" — "вызывайте PropertyChanged() из каждого сеттера". То есть мы знаем, как решить задачу, но не можем выразить это языковыми средствами. Ок, в новом фреймворке немножечко сократили копипасту при помощи нового атрибута и магии компилятора. Тем не менее, она всё ещё осталась, и никаких средств по избавлению от неё нету.
S>Поэтому мы по-прежнему имеем паттерн, а не решение.
S>Решением был бы макрос Nemerle или аннотация Java, которые бы заставляли компилятор автоматически генерировать копипасту за нас.
S>Тогда бы "Notify Property Changed Pattern" был бы не нужен.

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

I>>В данном случае я могу спокойно опираться на свой предыдущий опыт или отфильтровать сомнительные коктейли на стадии приготовления. Паттерны это не запрещают.
S>Ну, то есть мы имеем "знание паттернов", которое не мешает и не помогает в процессе решения задачи.

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

I>>Это все указано прямо в том справочнике
S>Что именно указано в справочнике?

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

I>>Значи всё еще хуже. Можно смело ожидать что большинство программистов их просто не поднимет в требуемый срок. WH например ратует за избавление индустрии от всех таких программистов
S>Нет. Он ратует за избавление индустрии от книг типа GoF. Вместо паттернов ентерпрайз приложений можно иметь RoR и профит.

Можно. Прогресс идет совсем в другом направлении.

I>>А что ты делал двадцать лет ? Писал примитивный императивный код и даже не пробовал ни асихронное программирование, ни функциональное, ни ООП?
S>Конечно же я пробовал ООП. Но большую часть времени из этих 20 лет никаких yield return в природе не существовало.

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

S>Зато как только появился iterator block, я сразу стал пользовать его направо и налево — скажем, для того, чтобы превратить обход дерева в обычный foreach. Потому что делать это стало легко и приятно:

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

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

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

S>>Конечно же я пробовал ООП. Но большую часть времени из этих 20 лет никаких yield return в природе не существовало.

I>Это можно эмулировать десятком способов, не было только языковой поддержки.
Можно взглянуть на хотя бы один способ эмуляции yield return без поддержки языка?

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


I>А что нам даёт такое название ? Вот с обсервером понятно, с эвентом — понятно. С сигналом — тоже понятно. Теперь называем это функцией и что ?
Название само по себе — ничего не даёт. Ни для обзёрвера, ни для эвента, ни для сигнала, ни для функции. Названия вообще ничего не дают — это символы. Чтобы они что-то давали, за названием должно быть описание.
Вот лично у вас вряд ли есть проблемы с пониманием, что такое "вызов функции".

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

класс Enumerable и видим, что наравне с православными итераторами, если реализации паттерна в чистом виде. Опаньки !
I>Значит реализован именно паттерн итератор, а ен просто код который похож и на итератор и на обсервер и на что угодно.
Я не понимаю, что вы называете "паттерном итератор". Где можно прочитать про этот паттерн?
Я не понимаю, что вы называете православными итераторами.

I>Обсервер можно спокойно использовать когда есть и эвенты, и сигналы и даже самопальные реализации. Вот в чем его фокус как паттерна.
Что вы называете "использовать обзёрвер"? Пока что я вижу только одно использование (в рамках C#) — одни люди педалят самопальные реализации, другие потом их вычищают, заменяя на event.
Мне такое использование не кажется сколь нибудь практичным.

I>Уже всё сказано. Кроме как заимствованием парадигм эту задачу не решить.
Да ну прекратите же вы плести ерунду. На всякий случай напомню, что все тьюринг-полные языки вычислительно эквивалентны.
Это, в частности, означает, что любую задачу можно решить на любом таком языке.

I>Ты называл и продолжаешь называть неустранимую копипасту, т.е. код, паттерном. Следовательно ты или путаешь понятия или для тебя код и есть паттерн.
Нет. Копипаста — это не код, это явление. Это ситуация, когда программист вынужден копипастить. А код — это результат применения паттерна.

I>Каким словом назвать этот механизм, что бы другому человеку было понятно, как это использовать ? Снова "функция" ?
Всё зависит от того, как именно я буду решать эту задачу. Например, я могу иметь notifying property. С вот таким синтаксисом:

public notifying int Size { get; set;}

А ещё я могу иметь просто язык разметки классов, определённый так, чтобы вообще все свойства сразу были notifying:

model class Person
{
  string FirstName;
  string LastName;
  string readonly Name = string.Join(" ", FirstName, LastName); 
}

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

I>Ну упрячешь ты реализацию в язык, что с того ? Откуда другой человек узнает, что эта мулька годится для биндинга ? И почему ему вообще должно прийти в голову решение с биндингом ?
Ну, вот каким-то же образом в Delphi люди догадывались, для чего использовать property? Надо полагать, узнавали из документации.

I>Если ты бармен — то это не нужно. Если ты просто хочешь сделать десяток коктейлей, паттерны сэкономят тебе несколько лет подготовки.
Паттерны — нет. Сэкономят решения. Например, http://www.ozon.ru/context/detail/id/5885959/
I>Можно. Прогресс идет совсем в другом направлении.
Да? А мне как раз казалось, что прогресс в 21 веке всё-таки сдвинулся с мёртвой точки. До этого 10 лет считалось, что всё уже реализовано, а дефицит полезных абстракций можно восполнить при помощи "паттернов". А потом пришёл C#, в каждый релиз которого добавляли больше фич, чем в джаву за десятилетие, и народ начал думать "а может, и правда хватит издеваться над программистами?"

I>Это можно эмулировать десятком способов, не было только языковой поддержки. Например в winapi есть такая вещь, как файберы — очень интересная штукенция.
Покажите мне, как эмулировать Enumerable.TakeWhile на файберах. Его устройство в терминах yield return мне понятно.

I>То есть, ты основательно наигрался, прежде чем изобрести конкретную короутину ?
Конечно. Я отлично понимал, как работает yield return. Безо всяких "паттернов".

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

I>>Значит реализован именно паттерн итератор, а ен просто код который похож и на итератор и на обсервер и на что угодно.
S>Я не понимаю, что вы называете "паттерном итератор". Где можно прочитать про этот паттерн?
S>Я не понимаю, что вы называете православными итераторами.

В данном случае это паттерн итератор описан в GoF. Православный итератор — это именно ООП , как в GoF, а не с модными словами вроде yield return.

I>>Обсервер можно спокойно использовать когда есть и эвенты, и сигналы и даже самопальные реализации. Вот в чем его фокус как паттерна.
S>Что вы называете "использовать обзёрвер"? Пока что я вижу только одно использование (в рамках C#) — одни люди педалят самопальные реализации, другие потом их вычищают, заменяя на event.

Использовать это прежде всего оперировать им в разговоре с самим собой или с кем то еще для поиска и принятия решения.

I>>Уже всё сказано. Кроме как заимствованием парадигм эту задачу не решить.
S>Да ну прекратите же вы плести ерунду. На всякий случай напомню, что все тьюринг-полные языки вычислительно эквивалентны.
S>Это, в частности, означает, что любую задачу можно решить на любом таком языке.

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

I>>Ты называл и продолжаешь называть неустранимую копипасту, т.е. код, паттерном. Следовательно ты или путаешь понятия или для тебя код и есть паттерн.
S>Нет. Копипаста — это не код, это явление. Это ситуация, когда программист вынужден копипастить. А код — это результат применения паттерна.

Ладно, годная отмазка

I>>Каким словом назвать этот механизм, что бы другому человеку было понятно, как это использовать ? Снова "функция" ?
S>Всё зависит от того, как именно я буду решать эту задачу. Например, я могу иметь notifying property. С вот таким синтаксисом:
S>

S>public notifying int Size { get; set;} 
S>

А где же тогда абстракции ? Не лучше ли паттерны и рассматривать как универсальный язык ?

S>А ещё я могу иметь просто язык разметки классов, определённый так, чтобы вообще все свойства сразу были notifying:
S>

S>model class Person
S>{
S>  string FirstName;
S>  string LastName;
S>  string readonly Name = string.Join(" ", FirstName, LastName); 
S>}
S>

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

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

I>>Ну упрячешь ты реализацию в язык, что с того ? Откуда другой человек узнает, что эта мулька годится для биндинга ? И почему ему вообще должно прийти в голову решение с биндингом ?
S>Ну, вот каким-то же образом в Delphi люди догадывались, для чего использовать property? Надо полагать, узнавали из документации.

А непосвященному надо знать толкьо NotifyPropertyChanged что бы знать как юзать эту мульку, и даже документация не нужна.

I>>Если ты бармен — то это не нужно. Если ты просто хочешь сделать десяток коктейлей, паттерны сэкономят тебе несколько лет подготовки.
S>Паттерны — нет. Сэкономят решения. Например, http://www.ozon.ru/context/detail/id/5885959/

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

I>>Можно. Прогресс идет совсем в другом направлении.
S>Да? А мне как раз казалось, что прогресс в 21 веке всё-таки сдвинулся с мёртвой точки. До этого 10 лет считалось, что всё уже реализовано, а дефицит полезных абстракций можно восполнить при помощи "паттернов". А потом пришёл C#, в каждый релиз которого добавляли больше фич, чем в джаву за десятилетие, и народ начал думать "а может, и правда хватит издеваться над программистами?"

Так сам подумай что это значит. Люди голосуют за джаву в которой фичи появляются очень медленно. А ты с WH предлагаешь навводить поддержки всего и вся в ЯП.

I>>Это можно эмулировать десятком способов, не было только языковой поддержки. Например в winapi есть такая вещь, как файберы — очень интересная штукенция.
S> Покажите мне, как эмулировать Enumerable.TakeWhile на файберах. Его устройство в терминах yield return мне понятно.

Я про твою асинхронную короутину. Файбер точно так же можно остановить в любой точне и с неё потом продолжить.

>>То есть, ты основательно наигрался, прежде чем изобрести конкретную короутину ?
S>Конечно. Я отлично понимал, как работает yield return. Безо всяких "паттернов".

А мне непонятно было это слово и когда первый раз увидел его, залез внутрь, глянул что там итератор построеный на автомате и все свойства узнал прямо из этой модели. позже, когда я узнал про coroutines, я сразу подумал про этот самый yield return. На тот момент у меня было намного меньше, чем 20 лет опыта.

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

I>>А что нам даёт такое название ? Вот с обсервером понятно, с эвентом — понятно. С сигналом — тоже понятно. Теперь называем это функцией и что ?
S>Название само по себе — ничего не даёт. Ни для обзёрвера, ни для эвента, ни для сигнала, ни для функции. Названия вообще ничего не дают — это символы. Чтобы они что-то давали, за названием должно быть описание.

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

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

I>>Это можно эмулировать десятком способов, не было только языковой поддержки.
S>Можно взглянуть на хотя бы один способ эмуляции yield return без поддержки языка?

Файберы.

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

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

I>>>Это можно эмулировать десятком способов, не было только языковой поддержки.
S>>Можно взглянуть на хотя бы один способ эмуляции yield return без поддержки языка?

I>Файберы.
Что Файберы? Т.е. эмуляции yield return я не увижу, я правильно понял? И видимо должен удовлетвориться словом Файберы и пойти прикручивать их к C#-у?

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

I>>>>Это можно эмулировать десятком способов, не было только языковой поддержки.
S>>>Можно взглянуть на хотя бы один способ эмуляции yield return без поддержки языка?

I>>Файберы.
S>Что Файберы? Т.е. эмуляции yield return я не увижу, я правильно понял? И видимо должен удовлетвориться словом Файберы и пойти прикручивать их к C#-у?

До свидания.

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

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

I>До свидания.
Пока

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

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

__>>паттерны это естественные конструкции, которые возникают по мере разработки архитектуры
WH>Не правильно.
WH>Ибо что такое паттерн? Паттерн это повторяющийся код. Копипаста как она есть.
WH>Паттерны возникают там, где не достаточно выразительности языка программирования, на котором решается задача.
WH>Ну, или разработчик не умеет пользоваться языком, на котором он пишет. Но этот случай не интересен.
WH>Соответственно если у нас первый случай то единственный способ бороться с паттернами это взять язык, который поддерживает сущности предметной области. К сожалению, для чуть менее чем всех предметных областей таких языков нет.
WH>Вот и приходится людям жрать кактус. Ибо далеко не всем хватает смелости сделать свой язык для того чтобы решить задачу.

я смотрю что многие программисты зажрзнались со своими дотнетами, джавами, и прочими пхп.
многие забыли (а кто-то и не знает), что кроме задач где есть "предметная область" с абстрактрыми сущностями типа документов, проводок и т.п.,
есть задачи где есть "конкретные сущности" типа "10К соединений", "макс. 20 мс задержка", "всего 128К памяти в контроллере".
никакой ваш замечательный ДСЛ не учтет, что одни данные надо выделить на стеке, другие в хипе, одни с выравниванием 8 потому что надо быстро, другие — с выравниваним 1, потому что их много,
одни — в списке, чтобы указатель не менялся, другие в векторе — чтобы кеш проца работал.

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

но вот что интересно, domain и DSL там нет, а архитектура и паттерны проектирования есть.

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

A>я смотрю что многие программисты зажрзнались со своими дотнетами, джавами, и прочими пхп.
A>многие забыли (а кто-то и не знает), что кроме задач где есть "предметная область" с абстрактрыми сущностями типа документов, проводок и т.п.,
Во-во. И лезут со своими паттернами вместо того чтобы сделать ДСЛ и оперировать данными сущностями.

A>есть задачи где есть "конкретные сущности" типа "10К соединений", "макс. 20 мс задержка", "всего 128К памяти в контроллере".
A>никакой ваш замечательный ДСЛ не учтет, что одни данные надо выделить на стеке, другие в хипе, одни с выравниванием 8 потому что надо быстро, другие — с выравниваним 1, потому что их много,
A>одни — в списке, чтобы указатель не менялся, другие в векторе — чтобы кеш проца работал.
Вот как раз ДСЛ это учтет очень хорошо.
Я не могу обогнать свои ДСЛ рукописным кодом. Ибо они такие оптимизации проворачивают, что руками их не сделать.

A>есть много программ, на которых держится наш мир (сервера в интернете, прошивки в мобильнике), где нет того что можно назвать "предметной областью" и сделать ДСЛ.
Есть. То что ты её не видишь это от того что ты не умеешь её находить.

A>но вот что интересно, domain и DSL там нет, а архитектура и паттерны проектирования есть.
Это от того что у разработчиков знаний не хватает.

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

A>я смотрю что многие программисты зажрзнались со своими дотнетами, джавами, и прочими пхп.
A>многие забыли (а кто-то и не знает), что кроме задач где есть "предметная область" с абстрактрыми сущностями типа документов, проводок и т.п.,
A>есть задачи где есть "конкретные сущности" типа "10К соединений", "макс. 20 мс задержка", "всего 128К памяти в контроллере".
A>никакой ваш замечательный ДСЛ не учтет, что одни данные надо выделить на стеке, другие в хипе, одни с выравниванием 8 потому что надо быстро, другие — с выравниваним 1, потому что их много,
A>одни — в списке, чтобы указатель не менялся, другие в векторе — чтобы кеш проца работал.

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

A>но вот что интересно, domain и DSL там нет, а архитектура и паттерны проектирования есть.

И ты тоже не понял главного: предметная область есть и здесь, в её терминах и нужно решать задачу. Если в нашем распоряжении много ресурсов — компилятор DSL сгенерирует код, использующий эти ресурсы. Если ресурсов мало — компилятор DSL сгенерирует код, эффективно работающий в 128 кб памяти, использующий только стек и т. п. При этом исходный код на самом DSL остаётся без изменений! Это по сути аналогично тому, как исходный код на C и C++ компилируется под разные платформы/ОСи.
Ещё раз: архитектур мало (мобильная, настольная, серверная, что-то ещё), программ под эти архитектуры много (тысячи их!). Что легче: переписывать эти тысячи программ под каждую архитектуру (имея при этом один компилятор) или иметь несколько компиляторов (DSL), учитывающих особенности этих архитектур (не меняя при этом тысячи исходников)?

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

A>>я смотрю что многие программисты зажрзнались со своими дотнетами, джавами, и прочими пхп.
A>>многие забыли (а кто-то и не знает), что кроме задач где есть "предметная область" с абстрактрыми сущностями типа документов, проводок и т.п.,
WH>Во-во. И лезут со своими паттернами вместо того чтобы сделать ДСЛ и оперировать данными сущностями.

Нет на каждый проект по человеку вроде Эрика Мейера, пичалька.

A>>есть много программ, на которых держится наш мир (сервера в интернете, прошивки в мобильнике), где нет того что можно назвать "предметной областью" и сделать ДСЛ.
WH>Есть. То что ты её не видишь это от того что ты не умеешь её находить.

"вместо того чтобы сделать ДСЛ и оперировать данными сущностями"

A>>но вот что интересно, domain и DSL там нет, а архитектура и паттерны проектирования есть.
WH>Это от того что у разработчиков знаний не хватает.

Правильно. И построение ДСЛ как минимум повышает минимальную планку по знаниям.

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

K>Ещё раз: архитектур мало (мобильная, настольная, серверная, что-то ещё), программ под эти архитектуры много (тысячи их!). Что легче: переписывать эти тысячи программ под каждую архитектуру (имея при этом один компилятор) или иметь несколько компиляторов (DSL), учитывающих особенности этих архитектур (не меняя при этом тысячи исходников)?

Подождём лет 5, посмотрим что выйдет из N2. Я думаю что ДСЛ в том виде, в котором предлаегает WH есть утопия в чистом виде, потому что построить сам язык, то есть именно язык, даже не говоря про компилятор, нужно обладать просто гигантским опытом и знаниями. Тенденции на рынке труда показывают, что таких людей в среднем становится все меньше и меньше.
По моему нужно изыскивать решения для приведения энергичного кода в ленивый. Если такой инструмент появится, то для программистов достаточно будет той небольшой базы императивного программирования которую дают в вузах.

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

WH>>Это от того что у разработчиков знаний не хватает.
I>Правильно. И построение ДСЛ как минимум повышает минимальную планку по знаниям.
Построение ДСЛ это работа архитектора. Я уже раз пятьсот это говорил. И, конечно же, если посадить за нее джуниора ничего хорошего не получится. Точно так же как ничего хорошего не получится, если дать джуниору дизайнить проект даже на жалкие 10-20 тысяч строк. Даже если джуниор талантливый. Есго всеравно учить надо.
Зато если посадить джуниора, писать на ДСЛ результат будет намного лучше, чем на языке общего назначения, даже если за ним будет присматривать архитектор. Ибо автомат присмотрит намного лучше, чем один архитектор за десятком другим джуниоров.

Я вообще не понимаю твое стремление инженерную работу поручить неучам. Ты хотел быть жить в доме или ходить по мосту, спроектированном неучем? Думаю, что нет. Так почему ты считаешь что неучи могут проектировать программы?

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

I>Подождём лет 5, посмотрим что выйдет из N2. Я думаю что ДСЛ в том виде, в котором предлаегает WH есть утопия в чистом виде, потому что построить сам язык, то есть именно язык, даже не говоря про компилятор, нужно обладать просто гигантским опытом и знаниями. Тенденции на рынке труда показывают, что таких людей в среднем становится все меньше и меньше.
Создание архитектуры задача значительно более сложная.
Ибо тебе не только нужно создать язык. Сущности и взаимодействия предметной области задают семантику языка. А их тебе нужно будет определить в любом случае. Синтаксис задача тривиальная.
Но и натянуть его на другой. С другими сущностями, которые взаимодействуют иначе. Причем так чтобы код не скатился в говно. А это задача очень сложная. Я бы даже сказал что это самая сложная задача при создании архитектуры.
Написать компилятор проще. С Н2 это будет очень просто. А все по тому, что нам не нужно беспокоится о том, что генерируемый код будет говном. Главное чтобы правильно работал. Иногда чтобы быстро работал. Кстати быстрый код обычно скатывается в говно. Да ты и сам это знаешь

Автор: Ikemefula
Дата: 24.08.12

.

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

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

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

Превращение энергичного в ленивый упрощает реализацию многих вещей. Например можно забыть про APM и прочую ересь.
Например ViewModel это как раз костыль из за отсутствия хороших возможностей такого вот преобразования.

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

WH>Построение ДСЛ это работа архитектора. Я уже раз пятьсот это говорил. И, конечно же, если посадить за нее джуниора ничего хорошего не получится. Точно так же как ничего хорошего не получится, если дать джуниору дизайнить проект даже на жалкие 10-20 тысяч строк. Даже если джуниор талантливый. Есго всеравно учить надо.

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

WH>Я вообще не понимаю твое стремление инженерную работу поручить неучам. Ты хотел быть жить в доме или ходить по мосту, спроектированном неучем? Думаю, что нет. Так почему ты считаешь что неучи могут проектировать программы?

Я предпочитаю работать с тем, кто есть на рынке труда а не ждать чудес. Неучи — ты сам это слово употребил — успешно сдают проекты безо всяких ДСЛ и немерлов. Странно, да ? Они, представь, пишут код с "паттернами" в самом что ни есть императивном духе ООП.