А я не спорю. Я просто говорю, что из двух вариантов: WebForms vs. PHP(Perl/Python/Ruby)+XSLT ручками я выберу первый вариант. Это в случае, если выбора нету. Если есть выбор, заюзаю что-то более удачное (если из предложенного выбора есть что-то более удачное). Вариант с ручной генерацией — ещё большее унылое говно, чем всё остальное (разве что, ручная генерация HTML-я на брейнфаке).
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Причем английский — тут просто пример. Даже когда я говорю по-русски, я неизбежно соотношу изначальную мысль с тем, насколько она адекватно она будет звучать будучи сказанной, насколько правильно она будет понята. И судя по всему не всегда удачно
Вот-вот. Не нужно путать владение языком и мысли, которые ты хочешь выразить.
ГВ>>Да нет как раз... Любой стиль, ИМХО, хорош к своему месту. Структурный (процедурный) — в своих случаях, ОО — в своих, FP — в своих.
ВВ>Стиль хорош к месту — бесспорно. Но мне интересен "стиль" не в рамках решения конкретной задачи, а в рамках описания устройства системы в целом.
Так любая система — есть решение какой-то задачи. Если принять это во внимание, то вот это твоё рассуждение:
ВВ>Все новвоведения в тот же C# в итоге не дают мне новых средств, которые позволили бы мне выразить устройство системы иначе, чем бы я делал это в самой первой версии. Мне интересно использовать ФП — да и не обязательно ФП, любую новую для мейнстрима концепцию — не для того, чтобы решать задачи, возникающие в результате того, что основая структура была писана с использованием привычных средств, а для того, чтобы получить принципиально иные средства для описания этой самой основной структуры, в результате которого отдельные задачи — те самые, для которых сейчас так хорошо подходит ФП — могут не появиться вовсе или же появиться совсем в другом качестве.
...получается построенным на глубоком внутреннем противоречии, которое вызвано неверной исходной посылкой.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ВВ>>Причем английский — тут просто пример. Даже когда я говорю по-русски, я неизбежно соотношу изначальную мысль с тем, насколько она адекватно она будет звучать будучи сказанной, насколько правильно она будет понята. И судя по всему не всегда удачно ГВ>Вот-вот. Не нужно путать владение языком и мысли, которые ты хочешь выразить.
Наверное, можно не учитывать сам факт существования неформализуемого мышления, когда речь идет не о высоких материях, а о программировании?
ГВ>>>Да нет как раз... Любой стиль, ИМХО, хорош к своему месту. Структурный (процедурный) — в своих случаях, ОО — в своих, FP — в своих. ВВ>>Стиль хорош к месту — бесспорно. Но мне интересен "стиль" не в рамках решения конкретной задачи, а в рамках описания устройства системы в целом. ГВ>Так любая система — есть решение какой-то задачи. Если принять это во внимание, то вот это твоё рассуждение ...получается построенным на глубоком внутреннем противоречии, которое вызвано неверной исходной посылкой.
А в чем противоречие, можешь сказать? Или просто нашел способ прицепиться к формулировке? "Описание устройства системы целом" — вполне себе "какая-то" задача. И по качеству она несколько отличается, скажем, от задачи написания конкретного алгоритма. И вот в ее рамках соединение ФП и ООП не дает чего-то существенно нового.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>>>Причем английский — тут просто пример. Даже когда я говорю по-русски, я неизбежно соотношу изначальную мысль с тем, насколько она адекватно она будет звучать будучи сказанной, насколько правильно она будет понята. И судя по всему не всегда удачно ГВ>>Вот-вот. Не нужно путать владение языком и мысли, которые ты хочешь выразить.
ВВ>Наверное, можно не учитывать сам факт существования неформализуемого мышления, когда речь идет не о высоких материях, а о программировании?
Интересно, для чего? Чтобы доказать, что язык программирования определяющим образом влияет на мышление программиста?
ГВ>>>>Да нет как раз... Любой стиль, ИМХО, хорош к своему месту. Структурный (процедурный) — в своих случаях, ОО — в своих, FP — в своих. ВВ>>>Стиль хорош к месту — бесспорно. Но мне интересен "стиль" не в рамках решения конкретной задачи, а в рамках описания устройства системы в целом. ГВ>>Так любая система — есть решение какой-то задачи. Если принять это во внимание, то вот это твоё рассуждение ...получается построенным на глубоком внутреннем противоречии, которое вызвано неверной исходной посылкой.
ВВ>А в чем противоречие, можешь сказать?
В том и противоречие, что ты говоришь о системе, но пытаешься рассматривать её изолированно от задачи, ради которой система создана. Во всяком случае, мне показалось именно так.
Тут вот какой прикол, на самом деле. Явления имеют такую причинно-следственную связь (в формулировках):
Проблема --> Задача --> Система
Если мы начнём рассуждать о способах описания систем (новизне, преимуществах, недостатках), то будем рассуждать ни о чём, поскольку в это обсуждение нужно непременно внести описание задач и проблем, которые решаются обсуждаемыми системами. Тогда обсуждение будет конечным и имеющим тенденцию к порождению некоего позитивного результата.
Так вот, новые способы описания систем могут появиться только при появлении новых задач. Кардинально новые способы возникнут после формулировок кардинально новых задач. Я не пытаюсь сказать, что таких задач не может появиться, заметь.
ВВ>Или просто нашел способ прицепиться к формулировке?
Туманная у тебя формулировка, мягко говоря. Было бы сформулировано яснее, вот и не "прицепился" бы. И ещё, чтобы уж быть совсем честным, остался после неё какой-то карамельный привкус. У меня такое бывает, когда я натыкаюсь на залакированную чепух... "глубокое заблуждение автора", я хотел сказать. Это к вопросу о мышлении, кстати.
ВВ>"Описание устройства системы целом" — вполне себе "какая-то" задача. И по качеству она несколько отличается, скажем, от задачи написания конкретного алгоритма. И вот в ее рамках соединение ФП и ООП не дает чего-то существенно нового.
Ну раскрой тогда, будь добр, что такое "описание устройства системы в целом". Я понимаю, что речь идёт о программной системе, но всё же. И ещё — чем оно отличается от описания алгоритма? Я могу додумать сам, но хочу услышать формулировку от тебя.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Воронков Василий, Вы писали:
ВВ>"Описание устройства системы целом" — вполне себе "какая-то" задача. И по качеству она несколько отличается, скажем, от задачи написания конкретного алгоритма. И вот в ее рамках соединение ФП и ООП не дает чего-то существенно нового.
Как это ни странно, но такое соединение даёт некие новые возможности: таким выразительным инструментарием можно несколько проще реализовать задачи, для решения которых хорошо подходит FP и ООП.
Обрати внимание, что иной раз шкала "проще-сложнее" интерпретируется как "нельзя-можно".
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
ГВ>Обрати внимание, что иной раз шкала "проще-сложнее" интерпретируется как "нельзя-можно".
"можно-нельзя", разумеется.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ВВ>>Наверное, можно не учитывать сам факт существования неформализуемого мышления, когда речь идет не о высоких материях, а о программировании? ГВ>Интересно, для чего? Чтобы доказать, что язык программирования определяющим образом влияет на мышление программиста?
Если вопрос о том, что там конкретно влияет на мышление программиста был поднят в связи с каким-либо из моих постов, то можешь считать я забираю свои слова назад
Язык программирования влияет на результат, так сказать, мышления программиста. А то, что там творится в голове программиста тема глубоко нетехническая и, мне кажется, не стоит ее тут развивать
ГВ>В том и противоречие, что ты говоришь о системе, но пытаешься рассматривать её изолированно от задачи, ради которой система создана. Во всяком случае, мне показалось именно так.
Я пытаюсь рассматривать ее изолированно от конкретных технических задач — а как же иначе? Чтобы появились конкретные задачи, вся система должна быть сначала описана в бизнес-терминах, а затем, в качестве результата анализа бизнес требований, в технических терминах. В зависимости от того, что нам будет представляено в качестве бизнес-функций и, в зависимости, от того, какие решения будут выбраны при техническом анализе, и возникнет наш спектр собственно технических задач.
Скажем, использование чистых функций для распараллеливания логики — не заложено в задачу изначально, а является следствием той архитектуры, которую мы выбрали, которая предлагает использовать параллельные вычисления для решения какой-либо из бизнес-задач, а чистые функции в данном случае — средство, облегчающее реализацию оных.
ГВ>Тут вот какой прикол, на самом деле. Явления имеют такую причинно-следственную связь (в формулировках): ГВ>
Проблема --> Задача --> Система
Правильно. При этом проблема как и задача формулируются в бизнес-терминах. Система — описание решения в технических терминах. Или лучше сказать постановка задач в технических терминах.
Рядовой разработчик вовлекается в проект как раз на той стадии, когда система описана. Соответственно, перед ним уже ставятся технические задачи.
Но первоначально таких задач нет. Есть задача отконвертировать бизнес-описание в архитектуру.
ГВ>Так вот, новые способы описания систем могут появиться только при появлении новых задач.
С этим я не согласен. С точки зрения бизнеса задачи как правило не меняются. В общем-то сейчас мы решаем те же бизнес-задачи что и десять лет назад. По большей части по кр. мере.
ГВ>Кардинально новые способы возникнут после формулировок кардинально новых задач.
А вот тут уже зависит от нас — как мы будем формулировать технические задачи. Для того, чтобы их сформулировать, нужен язык, который, с одной стороны, близок к бизнес-терминах, с другой — может одновременно служить техническим описанием устройства системы.
На настоящий момент — это язык ООП, обладающий, так сказать, рядом характерных особенностей. И наши технические проблемы возникают не потому, как может показаться, что бизнес что-то захотел, а потому что мы сами так "отконвертировали" эти хотения.
Мне было бы интересно рассмотреть какое-нибудь принципиально иное средство описания.
ГВ>Ну раскрой тогда, будь добр, что такое "описание устройства системы в целом". Я понимаю, что речь идёт о программной системе, но всё же. И ещё — чем оно отличается от описания алгоритма? Я могу додумать сам, но хочу услышать формулировку от тебя.
Описание устройства системы — ответ на бизнес-требования к системе.
Описание алгоритма — ответ на технические требования к системе.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Как это ни странно, но такое соединение даёт некие новые возможности: таким выразительным инструментарием можно несколько проще реализовать задачи, для решения которых хорошо подходит FP и ООП.
Да, честно говоря, мне неинтересно проще ли можно реализовать задачу или сложнее. Мне интересно
— а можно ли было избежать вообще появления данной технической задачи?
— не появилась ли эта задача вследствие ошибки дизайна?
и пр.
ГВ>Обрати внимание, что иной раз шкала "проще-сложнее" интерпретируется как "нельзя-можно".
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Я пытаюсь рассматривать ее изолированно от конкретных технических задач — а как же иначе? Чтобы появились конкретные задачи, вся система должна быть сначала описана в бизнес-терминах, а затем, в качестве результата анализа бизнес требований, в технических терминах. В зависимости от того, что нам будет представляено в качестве бизнес-функций и, в зависимости, от того, какие решения будут выбраны при техническом анализе, и возникнет наш спектр собственно технических задач. ВВ>Скажем, использование чистых функций для распараллеливания логики — не заложено в задачу изначально, а является следствием той архитектуры, которую мы выбрали, которая предлагает использовать параллельные вычисления для решения какой-либо из бизнес-задач, а чистые функции в данном случае — средство, облегчающее реализацию оных.
Понятно. Но всё равно здесь теряется один важный фактор. Например, прежде, чем чистые функции будут явно использованы для распараллеливания обработки, эта самая задача параллельной обработки возникает, так скажем, на уровне проблемы, которую желательно разрешить. Пусть даже в виде интереса кого-то из разработчиков. Я думаю, тебя не удивит, что задача распараллеливания ставится очень давно. То есть это не "неожиданно открывшиеся возможности", а плод долгой и целенаправленной исследовательской, в частности, работы. Другое дело, что сейчас это вбрасывается, как нечто "принципиально новое", раскрывающее "новые горизонты", так и тому есть сугубо прагматическая причина — упёрлись в физические ограничения по повышению производительности процессора. ИМХО, это и есть ключевая проблема.
И ещё, такое рассмотрение системы (изолированно от технических задач) ставит тебя на скользкий путь, подверженный очень сильному влиянию спекуляций. Собственно, вся новейшая история ООП тому примером. В нашей работе опасно ставить лошадь позади телеги и пытаться найти в такой перестановке новые возможности — лошадь будет прыгать гораздо дальше и гораздо веселее, чем когда она запряжена, а телега не будет изнашиваться и скрипеть. Вот только она так и будет стоять на месте, под аккомпанемент весёлого ржания. Между прочим, именно это мы и наблюдаем вокруг.
ГВ>>Тут вот какой прикол, на самом деле. Явления имеют такую причинно-следственную связь (в формулировках): ГВ>>
Проблема --> Задача --> Система
ВВ>Правильно. При этом проблема как и задача формулируются в бизнес-терминах. Система — описание решения в технических терминах. Или лучше сказать постановка задач в технических терминах. ВВ>Рядовой разработчик вовлекается в проект как раз на той стадии, когда система описана. Соответственно, перед ним уже ставятся технические задачи.
Ага... Как я понимаю, как раз то самый "рядовой разработчик" и интересен тебе в первую очередь. Я прав?
ВВ>Но первоначально таких задач нет. Есть задача отконвертировать бизнес-описание в архитектуру.
Не забегай вперёд. Архитектура — суть вспомогательное явление. Если можно было бы без неё обойтись — обошлись бы и не вспомнили.
ГВ>>Так вот, новые способы описания систем могут появиться только при появлении новых задач. ВВ>С этим я не согласен. С точки зрения бизнеса задачи как правило не меняются. В общем-то сейчас мы решаем те же бизнес-задачи что и десять лет назад. По большей части по кр. мере.
Десять? Я бы сказал — сорок-пятьдесят.
ГВ>>Кардинально новые способы возникнут после формулировок кардинально новых задач.
ВВ>А вот тут уже зависит от нас — как мы будем формулировать технические задачи. Для того, чтобы их сформулировать, нужен язык, который, с одной стороны, близок к бизнес-терминах, с другой — может одновременно служить техническим описанием устройства системы.
Таких языков есть. Сложности обычно начинаются с того момента, когда дело доходит до точной формализации требований. Например, всё хорошо, пока у нас есть два отвлечённых описания, скажем, событий и ожидаемой реакции системы. Всё становится очень плохо, когда нужно "разобраться", что происходит в случае каких-то ошибок, и всё становится ещё хуже, когда эти два описания нужно привести к взаимно непротиворечивому виду.
С другой стороны, если вдруг те же описания появились в а) полном и б) непротиворечивом виде, то кодирование (построение системы) становится тривиальным занятием.
ВВ>На настоящий момент — это язык ООП, обладающий, так сказать, рядом характерных особенностей. И наши технические проблемы возникают не потому, как может показаться, что бизнес что-то захотел, а потому что мы сами так "отконвертировали" эти хотения.
Вот тут ты, ИМХО, ошибаешься. На настоящий момент язык описания бизнес-задач ближе всего к вариациям SADT (группа стандартов IDEF, например), то есть, проще говоря — квадратики и стрелочки. По совместительству, такая нотация близка к "языку" описания семантических сетей (атрибутированные сущности и т.п.), и по ещё более дальнему совместительству — к ООП, как к таковому. Применение других формализмов в этом контексте, безусловно, возможно, но к нему просто нечасто прибегают.
Так вот, принципиально новые языки описания системы, ИМХО, могут возникнуть только при условии, что изменится язык, которым описывают бизнес-задачи. Повторюсь, я допускаю такую возможность, хотя склонен считать, что это произойдёт не раньше, чем, ммм... соберётся рако-щучий фестиваль на Лысой Горе по фигурному свисту.
ВВ>Мне было бы интересно рассмотреть какое-нибудь принципиально иное средство описания.
Спору нет, было бы интересно. Но главная засада заключена в том, что любое описание (на данный момент) должно сочетать метафоры действий, условий, сущностей и ресурсов. С технической же точки зрения решение сводится к выбору структуры, оптимальной в смысле использования человеческих и машинных ресурсов.
ВВ>Описание устройства системы — ответ на бизнес-требования к системе. ВВ>Описание алгоритма — ответ на технические требования к системе.
Ясно.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Воронков Василий, Вы писали:
ГВ>>Как это ни странно, но такое соединение даёт некие новые возможности: таким выразительным инструментарием можно несколько проще реализовать задачи, для решения которых хорошо подходит FP и ООП.
ВВ>Да, честно говоря, мне неинтересно проще ли можно реализовать задачу или сложнее. Мне интересно ВВ>- а можно ли было избежать вообще появления данной технической задачи?
Это прямое следствие сложнее-проще.
ВВ>- не появилась ли эта задача вследствие ошибки дизайна?
Дык. "Ошибки дизайна" появляются как раз в результате изменения требований к системе. "Абсолютно правильного" дизайна не бывает.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Понятно. Но всё равно здесь теряется один важный фактор. Например, прежде, чем чистые функции будут явно использованы для распараллеливания обработки, эта самая задача параллельной обработки возникает, так скажем, на уровне проблемы, которую желательно разрешить. Пусть даже в виде интереса кого-то из разработчиков. Я думаю, тебя не удивит, что задача распараллеливания ставится очень давно. То есть это не "неожиданно открывшиеся возможности", а плод долгой и целенаправленной исследовательской, в частности, работы. Другое дело, что сейчас это вбрасывается, как нечто "принципиально новое", раскрывающее "новые горизонты", так и тому есть сугубо прагматическая причина — упёрлись в физические ограничения по повышению производительности процессора. ИМХО, это и есть ключевая проблема.
ГВ>И ещё, такое рассмотрение системы (изолированно от технических задач) ставит тебя на скользкий путь, подверженный очень сильному влиянию спекуляций. Собственно, вся новейшая история ООП тому примером. В нашей работе опасно ставить лошадь позади телеги и пытаться найти в такой перестановке новые возможности —
Гм, по-моему это ты все перевернул. Каким образом лошадь позади телеги оказалась? Технических задач нет изначально, есть бизнес-задачи. Как бы ни рассматривал программную систему, на самой первой стадии она все равно будет в каком-то смысле "изолирована" от технических задач, ибо последние еще не поставлены. Требование, скажем, извещать пользователя по емейлу об изменении статус заказа — это чистое бизнес-требования. При этом нет некоего "стандартного набора технических задач", в которое это требование переводится. В одном случае этом будет один набор задач, в другом — совершенной другой, а третьем случае вообще окажется, что с текущей инфраструктурой это нереализуемо.
Но всему это предшествует понимание системы в бизнес-терминах и ее перевод в технические термины. Причем чем ближе тот же ОО язык к бизнесу, тем проще осуществлять этот перевод. Т.е. у меня есть сущность "Заказ", обладающая некоторым поведением и пр. Есть такое понятие как Статус, есть процесс Изменение Статуса и так далее. Вот, у нас уже и классы какие-то на бумажке нарисованы.
А техническая задача... Ну в итоге все может закончиться тем, что триггер какой-нибудь надо будет дописать При этом нет никакой связи между "известить пользователя об изменении статуса" и "переписать триггер" — эту связь мы сами придумываем.
ВВ>>Правильно. При этом проблема как и задача формулируются в бизнес-терминах. Система — описание решения в технических терминах. Или лучше сказать постановка задач в технических терминах. ВВ>>Рядовой разработчик вовлекается в проект как раз на той стадии, когда система описана. Соответственно, перед ним уже ставятся технические задачи. ГВ>Ага... Как я понимаю, как раз то самый "рядовой разработчик" и интересен тебе в первую очередь. Я прав?
Ну, честно говоря, не совсем. Разработчик — не очень. Не в рамках данной темы. Ежу понятно, что "рядовой разработчик" получит кучу наикрутейших инструментов, когда перейдет, скажем, на Немерле.
Вот только если сами его задачи сформулированы неверно — это, к сожалению, не поможет.
ВВ>>Но первоначально таких задач нет. Есть задача отконвертировать бизнес-описание в архитектуру. ГВ>Не забегай вперёд. Архитектура — суть вспомогательное явление. Если можно было бы без неё обойтись — обошлись бы и не вспомнили.
Мне кажется, ты все время забегаешь вперед
В том-то и дело, что без нее обойтись нельзя. Не нравится термин "архитектура" замени его на "техническое планирование". Это так или иначе есть. И это есть наш способ интерпретации бизнес-задачи — применительно к существующей системе, к срокам, людям, возможностям и пр.
ГВ>>>Так вот, новые способы описания систем могут появиться только при появлении новых задач. ВВ>>С этим я не согласен. С точки зрения бизнеса задачи как правило не меняются. В общем-то сейчас мы решаем те же бизнес-задачи что и десять лет назад. По большей части по кр. мере. ГВ>Десять? Я бы сказал — сорок-пятьдесят.
Я так долго не живу
ГВ>>>Кардинально новые способы возникнут после формулировок кардинально новых задач. ВВ>>А вот тут уже зависит от нас — как мы будем формулировать технические задачи. Для того, чтобы их сформулировать, нужен язык, который, с одной стороны, близок к бизнес-терминах, с другой — может одновременно служить техническим описанием устройства системы. ГВ>Таких языков есть.
Разумеется. Кто ж спорит с этим.
ГВ>Сложности обычно начинаются с того момента, когда дело доходит до точной формализации требований. Например, всё хорошо, пока у нас есть два отвлечённых описания, скажем, событий и ожидаемой реакции системы. Всё становится очень плохо, когда нужно "разобраться", что происходит в случае каких-то ошибок, и всё становится ещё хуже, когда эти два описания нужно привести к взаимно непротиворечивому виду. ГВ>С другой стороны, если вдруг те же описания появились в а) полном и б) непротиворечивом виде, то кодирование (построение системы) становится тривиальным занятием.
Непротиворечивость собственно бизнес-требований не означает то, что они могут однозначно переведены в технические задачи. Как это ни печально.
ВВ>>На настоящий момент — это язык ООП, обладающий, так сказать, рядом характерных особенностей. И наши технические проблемы возникают не потому, как может показаться, что бизнес что-то захотел, а потому что мы сами так "отконвертировали" эти хотения.
ГВ>Вот тут ты, ИМХО, ошибаешься. На настоящий момент язык описания бизнес-задач ближе всего к вариациям SADT (группа стандартов IDEF, например), то есть, проще говоря — квадратики и стрелочки. По совместительству, такая нотация близка к "языку" описания семантических сетей (атрибутированные сущности и т.п.), и по ещё более дальнему совместительству — к ООП, как к таковому. Применение других формализмов в этом контексте, безусловно, возможно, но к нему просто нечасто прибегают.
Я не самом деле не про язык описания бизнес-задач, это немного другое. Я именно про тот, скажем так, "набор терминов", в котором мы уже начинаем описывать технические задачи — на основе анализа бизнес-задач. И тут-то начинается самое веселье. До этого нет никакой задачи распараллеливания чего-то там, тут она появляется. Т.е. мы имеет такую схему (весьма тривиальную же на самом деле):
Бизнес-задачи --> Технические задачи
И вот тут ИМХО (Имею Мнение Хрен Оспоришь ) то, что мы используем при проектировании — ООП там или не ООП — начинает играть весьма весомую роль при определении набора задач.
ГВ>Так вот, принципиально новые языки описания системы, ИМХО, могут возникнуть только при условии, что изменится язык, которым описывают бизнес-задачи. Повторюсь, я допускаю такую возможность, хотя склонен считать, что это произойдёт не раньше, чем, ммм... соберётся рако-щучий фестиваль на Лысой Горе по фигурному свисту.
ВВ>>Мне было бы интересно рассмотреть какое-нибудь принципиально иное средство описания. ГВ>Спору нет, было бы интересно. Но главная засада заключена в том, что любое описание (на данный момент) должно сочетать метафоры действий, условий, сущностей и ресурсов. С технической же точки зрения решение сводится к выбору структуры, оптимальной в смысле использования человеческих и машинных ресурсов.
Описание системы в терминах ООП как взаимосвязи классов, обладающих поведением, состоянием и пр. — это уже техническое описание, и оно-то как раз и загонит тебя в рамки, когда будут приниматься технические решения уже на более низком уровне.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравый смысл говорит, что при суммировании строк надо идти по строкам, а при суммировании столбцов — по столбцам. И с точки зрения абстракций — то же самое (суммирование вектора-строки или вектора-столбца). А на реальной машине, где есть кэш процессора и виртуальная память, оказывается, что проходить надо всегда по строкам. Хотя какая при этом абстракция получается — черт разберет.
Просто во-первых, представление должно быть адекватно преимущественному способу обхода. А во-вторых, что в общем-то следует из во-первых, абстрагируясь от способа обхода нужно абстрагироваться и от способа представления.
... << RSDN@Home 1.2.0 alpha 4 rev. 1110>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Со всем этим можно было бы согласиться, если бы процессор мог непосредственно выполнять код на Хаскеле/C#... Тогда я бы снял свои возражения. А пока что, что там не делай, а закончится все mov, add, jmp и т.д. И вот это есть абсолютный теоретический предел при данном алгоритме, если его идеально эффективно запрограммировать. Улучшить можно, только если алгоритм поменять (или доступ к данным ускорить или распараллелить и т.д.).
Вы рассматриваете ассемблер на котором человеку программировать достаточно легко. Поинтересуйтесь программированием цифровых сигнальных процессоров TMS. Там распараллеливание по конвейерам выполняется вручную (архитектура VLIW).
Мне удавалось бороться с C++ компилятором при одновременном выполнении двух итераций цикла. Дальше просто швах. А у него получается до 8 параллельных итераций.
Так что, заявления о ручной ассемблерной оптимизации прокатывают только для морально устаревшей системы команд x86.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну и ну! Не вдаваясь в суть этого утверждения ( а оно совсем не верно, но объяснять почему просто нет времени), могу лишь сделать вывод — программист на асме глупый, а вот компилятор — умный, он видимо, такое делать не будет. Остается лишь ответить на вопрос, умные ли те, кто писал этот компилятор.
Компилятор, это инструмент, который позволяет автоматизировать рутинные действия по генерации машинного кода из исходной задачи. Возможности компилятора в этом плане намного выше возможностей человека, которые ограничены в силу его физиологии. Например, сможете ли вы держать в памяти, скажем 200 или 300 переменных состояния. Нет? А компилятор может. Очень многое также зависит от особенностей конкретного процессора. Есть процессоры, система команд которых не преспособлена для написания программ человеком. Он просто не сможет тупо перебрать такое количество вариантов.
При этом нет никакой связи между "известить пользователя об изменении статуса" и "переписать триггер" — эту связь мы сами придумываем.
