Здравствуйте, Klapaucius, Вы писали:
K>Я думаю это потому, что тем, кто выдает требования электронщикам, противоречивые требования просто не по карману. Иначе микроэлектронщики сталкивались с такими же требованиями так же часто. Из этого, по-моему, скорее можно сделать вывод о том, что микроэлектроника — более сложная отрасль. Но не обязательно.
Характер работы электронщика практически идентичен характеру работы дизайнеров/архитекторов софтовых проектов, разве что над немножко другой понятийной базой, но сложность ничуть не выше. А учитывая постановку процесса и гораздо бОльшую детерминированность — даже где-то чуть легче, ибо не надо столько сил тратить на борьбу с неорганизованными программистами.
Ну и плюс в трудоемкости на отладку и доводку забита приличная доля от общей, что немного развязывает руки и позволяет позволять себе неплохие решения... в отличие от "любых подходящих" в софте.
В общем, обстановка поспокойнее.
-----------------
ИМХО, тут обсуждать-то нечего. В электронике из нефункциональных требований оптимизируют в первую очередь себестоимость конечного продукта, а в софте оптимизируют лишь стоимость разработки. В итоге, электронщик разработал систему, а потом вылизывает её до идеальной, а софтовый архитектор, даже если нечаянно разработал идеальную систему, потом её сильно гробит до уровня "абы как", чтобы вложиться в выделенные ресурсы.
Вот это и есть самое главное различие, остальное — ерунда.
Здравствуйте, FR, Вы писали:
FR>Мне все же интересно что ты там нового и потрясающего увидел, выше ты писал:
FR>
FR>Лично мне башню оторвало надолго серии, где показывали что такое на самом деле LINQ, что такое монады и как они тут рулят, как оно оборачивается в Rx, какие есть области применения. Я тут заобщался с Эриком Мейером (мега-дядька!) он утверждает и показывает, что Rx на самом деле решает проблему сложности параллельного программирования — я это хотел тут выложить и обсудить, просто руки еще не дошли.
FR>как руки дойдут, дай пожалуйста ссылку сюда.
Я уже ответил на этот вопрос:
Я здесь вижу главным то, что Rx это именно язык запросов поверх push based collections, которые являются дуальными к обычным pull based collections. Просто это получается чертовски удобно. И именно этого я не вижу в ваших примерах.
Как только такой объединяющий концепт есть — то все асинхронное программирование можно видеть как нити различных данных/событий, которые можно связывать запросами, порождать новые и раставлять обработчики. Причем это интегрируется к существующему коду на раз-два как раз из-за дуальности коллекций. Вот именно это я называю новым концептом.
Если есть какие-то детали, которые мы могли бы обсудить предметно — welcome. Ссылки дать не могу, потому что мы это обсуждали с Эриком Мейером в личной беседе. Также надо понимать, что здесь я излагаю свое понимание, которое может отличаться от его личного мнения.
По общей теме Rx видео тут выкладывали неоднократно уже.
Здравствуйте, Sinclair, Вы писали:
Кэр>>По общей теме Rx видео тут выкладывали неоднократно уже. S>Довольно интересно про Rx писал Барт.
Барт чувак грамотный бесспорно. Но вот про асинхронное программирование в целом — я там много мыслей не увидел (но и просмотрел я записи сейчас по диагонали и в сэмплы, которые он выкладывал, не заглядывал). Впрочем могу постараться спросить его во вторник, и мнением Эрика поинтересоваться заодно Тоха, у тебя есть какие-нибудь конкретные соображения, возражения на счет возможностей использования Rx в качестве главного движка параллельных вычислений?
Кэр>Барт чувак грамотный бесспорно. Но вот про асинхронное программирование в целом — я там много мыслей не увидел (но и просмотрел я записи сейчас по диагонали и в сэмплы, которые он выкладывал, не заглядывал). Впрочем могу постараться спросить его во вторник, и мнением Эрика поинтересоваться заодно Тоха, у тебя есть какие-нибудь конкретные соображения, возражения на счет возможностей использования Rx в качестве главного движка параллельных вычислений?
Неа. Я ж теперь от этого далёк, как декабристы от народа. Мой инструмент нынче — PowerPoint, тудыть его в качель!
Rx меня в своё время поразил как адекватный ответ всем этим ужасным message pump-ам. В том смысле, что в пору моей юности постоянно бесило то, что безалаберные разработчики компонентов предлагали мало готовых евентов. А чтобы сконструировать свой банальный дабл-клик, нужно повеситься на несколько евентов сразу, да грамотно обработать всякие последовательности. Я, конечно, со временем понял, что всё сводится к построению конечного автомата, но один хрен логика оставалась размазана по чёрт-те-чему.
Rx для меня стал воплощением идеи лёгкого построения "композитных" событий и конечного автомата, который для них нужен.
Ну, то есть вместо того, чтобы проверять в MOUSE_UP "не записал ли я тут по соседству координаты и время предыдущего MOUSE_DOWN", я беру и описываю композит из двух евентов подряд, сравнивая их между собой. Вроде бы был такой как раз пример в ранних упоминаниях Rx. Должно быть, это поможет выпиливать всякие забавные кунштюки типа мышиных жестов.
С одной стороны, всё это как-то мелко. С другой стороны, я столько видел глюков в самописаных реализациях тройных кликов и прочих мелочей, что кажется даже такая штука будет уже полезна.
А про параллельность я пока ещё сам не вкурил, кто тут async и кого тут await. Вот, знаю классическую неразрешимую задачу: превратить pull stream в push stream. Простейший пример: есть web service, задача которого — принимать некий XML и как-то его внутри себя переваривать. XML большой, приезжает из сети, есссно, пакетами. Паузы между пакетами — бесконечно велики (с точки зрения CPU). Все классические парсеры XML — активны, "дайте мне поток, уж я из него повычитаю всё". Но это означает, что поток, рискнувший позвать парсер, не вернёт управление до окончания вычитывания. То есть, натравив его напрямую на сокет, мы получим красавицу, спящую большую часть времени.
Традиционное асинхронное решение — зачитать XML целиком в память, и только в конце позвать парсер. Оно мне не нравится:
1. Возрастают потребности в памяти. Я в течение очень долгого времени вынужден удерживать мегабайты в хипе. Реактивный парсер позволил бы мне на ходу избавляться от шлака, разбирая поток. (А, в перспективе, и сразу избавляться от более ненужных DOM-объектов, сразу скармливая себя в, скажем, XSLT)
2. Если мне передают мусор, я об этом не узнаю до окончания передачи. Реактивный парсер бы увидел ошибку, отправил 400 Bad Request и закрыл соединение сразу.
В общем-то, понятно, что вообще все традиционные парсеры построены в активном стиле. Написать реактивный парсер вручную — я, пожалуй, сразу и не возьмусь.
Умение автоматически превращать активный парсер в реактивный было бы очень круто. Rx как раз стоит где-то вокруг этого.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Кэр, Вы писали:
Кэр>>Барт чувак грамотный бесспорно. Но вот про асинхронное программирование в целом — я там много мыслей не увидел (но и просмотрел я записи сейчас по диагонали и в сэмплы, которые он выкладывал, не заглядывал). Впрочем могу постараться спросить его во вторник, и мнением Эрика поинтересоваться заодно Тоха, у тебя есть какие-нибудь конкретные соображения, возражения на счет возможностей использования Rx в качестве главного движка параллельных вычислений? S>Неа. Я ж теперь от этого далёк, как декабристы от народа. Мой инструмент нынче — PowerPoint, тудыть его в качель!
Тоже вещь полезная! Лишь бы не единственная
S>Rx меня в своё время поразил как адекватный ответ всем этим ужасным message pump-ам. В том смысле, что в пору моей юности постоянно бесило то, что безалаберные разработчики компонентов предлагали мало готовых евентов. А чтобы сконструировать свой банальный дабл-клик, нужно повеситься на несколько евентов сразу, да грамотно обработать всякие последовательности. Я, конечно, со временем понял, что всё сводится к построению конечного автомата, но один хрен логика оставалась размазана по чёрт-те-чему.
S>Rx для меня стал воплощением идеи лёгкого построения "композитных" событий и конечного автомата, который для них нужен. S>Ну, то есть вместо того, чтобы проверять в MOUSE_UP "не записал ли я тут по соседству координаты и время предыдущего MOUSE_DOWN", я беру и описываю композит из двух евентов подряд, сравнивая их между собой. Вроде бы был такой как раз пример в ранних упоминаниях Rx. Должно быть, это поможет выпиливать всякие забавные кунштюки типа мышиных жестов.
Именно. Тот же drag&drop — это просто один запрос, который зипует последовательность координат движения мышкой после нажатия левой кнопки в последовательность перемещений, которые можно применить к какому-нибудь объекту. И подписавшись уже на последовательность перемещения объекта — получаем нативный drag&drop. К которому очень легко прикрутить эффекты типа "а вот когда мы еще плывем над этой областью — начни подсвечивать перетаскиваемый объект". Это просто дополнительный клауз для квери над событиями.
S>С одной стороны, всё это как-то мелко. С другой стороны, я столько видел глюков в самописаных реализациях тройных кликов и прочих мелочей, что кажется даже такая штука будет уже полезна.
Для UI эта штука должна быть просто незаменима. Но это далеко не все, как мне сейчас кажется.
S>В общем-то, понятно, что вообще все традиционные парсеры построены в активном стиле. Написать реактивный парсер вручную — я, пожалуй, сразу и не возьмусь. S>Умение автоматически превращать активный парсер в реактивный было бы очень круто. Rx как раз стоит где-то вокруг этого.
Автоматического превращения тут никто не обещает. Но новый код писать в таком стиле получается довольно просто — посмотри вот это видео, где он показывает вызов удаленного сервиса для dictionary lookup странички: http://live.visitmix.com/MIX10/Sessions/FTL01
Плюс новый код интегрировать к старому получается очень легко (и это очень важно!) за счет того, что IEnumerable превратить в IObservable и обратно — очень легко и просто. Так что можно просто в какой-то момент продолжить писать продукт с помощью Rx запросов и обработчиков.
Здравствуйте, Sinclair, Вы писали:
S>Умение автоматически превращать активный парсер в реактивный было бы очень круто. Rx как раз стоит где-то вокруг этого.
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, Visor2004, Вы писали: V>>Бабло побеждает зло. Надо по ситуации использовать то, что дает максимальный профит.
MS>Не согласен. Надо использовать то, что дает максимальный кайф. Профит != кайф. Иногда бывают совпадения, что и профит и кайф, но редко.
Это только если хобби совпадает с работой, и можно смириться с небольшими потерями в профите ради кайфа в реальной жизни так редко бывает, обычно только в начале карьеры.
Здравствуйте, Visor2004, Вы писали:
V>Это только если хобби совпадает с работой, и можно смириться с небольшими потерями в профите ради кайфа в реальной жизни так редко бывает, обычно только в начале карьеры.
Отсюда вывод — надо менять карьеру и все время оставаться в состоянии "в начале карьеры".
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
FR>Когда нужно программисты тоже понимают цену ошибок и разрабатывают с минимизацией ошибок, вот только строка такого кода стоит FR>на порядок дороже и строк этих (учитывая тесты и переписывание) приходится писать намного больше.
Английские железные дороги тянулись ровно и прямо через холмистый английский ландшафт благодаря щедрому использованию насыпей, выемок и прекрасных каменных и чугунных виадуков. Вся эта инженерная роскошь определялась наличием средств и рабочих рук, которыми в изобилии располагала викторианская Англия. Совершенно другие условия были в Америке: расстояния были гигантскими, капиталы скудными, зарплата даже неквалифицированных рабочих весьма велика, множество дилетантов, квалифицированные мастера европейского типа были чрезвычайно редки.
Кроме того, американские путейцы, подобно своим коллегам — судостроителям, готовы были в такой мере рисковать жизнью и собственностью людей, что у британских инженеров от одной мысли об этом волосы под котелками встали бы дыбом. И это при том, что британских инженеров тех времен отнюдь нельзя назвать особенно осторожными, сегодня мы скорее назвали бы их опрометчивыми. Американцы XIX в. привыкли жить в состоянии постоянной опасности, но за это они должны благодарить скорее своих инженеров, чем бандитов или индейцев.
в реальной жизни так редко бывает, обычно только в начале карьеры.
