Смысл первой части — дать представление о том, грубо говоря, между чем и чем мы выбираем, распарралеливая код.
Да, пользоваться надо готовым методом, но надо же понимать, в чём смысл его настроек, чтобы пользоваться им эффективно. Для этого и нужно иметь представление о том, как он может быть реализован.
Согласен. С непривычки «Практику ФП» с примерами на Haskell было непросто прорабатывать, и пришлось многое узнать, чтобы оно «пошло».
Ну, волна как нашла, так и схлынет, вместе со всеми поверхностно подошедшими товарищами. А те, кто смог подойти к вопросу более серьёзно, думаю, неплохо повысят свой профессиональный уровень.
F# пиарят знатно, не спорю. Но интерес к ФП как таковому, мне кажется, вещь очень правильная, для структурирования сознания.
В конце концов, именно благодаря возросшему интересу к ФП в сообществе в целом (в том числе и внутри команды MS) мы сейчас на C# пишем в гораздо более функциональном (и удобном) стиле, чем раньше.
Цепочки запросов LINQ; функции высшего порядка везде в FCL; Resharper норовит всё что можно объявить как readonly — это всё ведь следствия сближения mainstream languages с миром ФП.
Nemerle был очень классным примером тоже, многое из него вошло частью в современный C#, частью в F#.
Честно говоря, я слышал, что в F# есть весьма нативная поддержка параллельности, но не знаю подробностей, поэтому не могу сказать, лучше или нет)
Во всяком случае, познакомиться с тем, что F# умеет в этой сфере, я думаю, очень полезно.
А тут рассмотрены общие подходы, реализация на C# просто для удобства. А во второй части будет про библиотечные классы, и весьма вероятно, что реализация параллелизма в F# строится на них же.
А я кстати не вполне понимаю термин «серый». Ну для продажи в Танзании, и что? Мог же я его в Танзании купить, например, и сюда привезти? Что из этого плохого/незаконного вытекает? Можете пояснить?
Ну, к Гоге/не к Гоге, но куда-то ещё, это точно. Да я и сам бы это сделал, если бы только допустил мысль, что столько потеряю времени и нервов с ними. :) Знал бы где упасть, соломинку б подстелил, как говорится.
Как может дотнет-приложение «не мочь» взаимодействовать с другими языками? вы вообще хорошо знакомы с .net? любые .net-языки прозрачно взаимозаменяемы, а их море. в том числе и IronPython, и IronRuby.
«В общем, действительно, все работает как и обещает Гугл – скорость не зависит от масштаба, медленно в маленьком масштабе, медленно и в большом :-) Даже один запрос к чему-то, что требует работы с Datastore или несколько Memcached – занимает кучу времени. Ну а если вам нужно сделать несколько запросов на страницу – ваши шансы увидеть exception’ы по таймауту резко повышается. » — это по вашей ссылке.
Вы ничего толком не опровергли. GAE, да, „устойчиво медленно“ работает. А Azure — быстро. Мне кажется, стоит бороться с маниакальным желанием опустить MS невзирая на факты.
если почасовку предлагали, вопросов не имею. но всё равно отношение к ТЗ (в любом виде, может как набор карточек в стиле XP) должно быть ИМХО более уважительным :)
ну а раз почасовку вы не предлагаете, то Васям и остаётся требовать ТЗ, иначе они рискуют сверх этой 1000-ти проработать бесплатно неограниченное количество времени. И они совершенно в этом правы.
> Дальше, программисты — про них у меня историй на три поста хватит. Почти все поголовно требуют ТЗ, видимо, боятся брать на себя ответственность, хотя я и на пальцах умею все хорошо объяснять. При этом, некоторые предлагали сделать проект под ключ за неделю, другие мне за ту же неделю и ту же цену обещали сделать ТЗ. В итоге на ТЗ ушло больше месяца мозговых штурмов. Документ получился не столько детальным, сколько описывал хитрые подходы и концепции. Ну, думаю, теперь есть ТЗ, да не тут-то было — им, оказывается, чуть ли не до запятой надо расписать. Спасибо, думаю, но большую часть работы за Вас делать я не хочу.
> ___________________________________________________________
А вот тут вы не правы, серьёзно. ТЗ требуют не потому, что боятся ответственности (странная формулировка), а потому что это единственный критерий
1) оценки и 2) принятия работы.
Вот Вы сказали Васе: «напиши мне генератор договоров на WPF, за 1000 уе». Вася говорит, — «Ок!», и через день показывает Вам программу, где одно поле ввода «сумма» и одна кнопка — «сгенерировать». И всё, это формально уже — генератор договоров, причём на WPF, и Вася ждёт свою 1000 уе. Это одна крайняя ситуация. Тут проигрываете вы.
А вот вторая: проект идёт 3-й месяц, вы всё придумываете и придумываете улучшения, и посылаете их Васе. Общие трудозатраты давно уже вылезли за это 1000 у.е., но вы всё ещё считаете, что «генератор» ещё не совсем готов. Это вторая крайняя ситуация, и тут проигрывает Вася.
И выхода всего два (три):
1) ТЗ, описанное до каждой запятой
2) Почасовая оплата работы Васи
3) (смесь 1 и 2) гибкая (agile) разработка с разбиением проекта на много маленьких, каждый из которых отдельно оценивается, оплачивается, и для каждого минипроекта формулируются чёткие требования до запятой.
Да, пользоваться надо готовым методом, но надо же понимать, в чём смысл его настроек, чтобы пользоваться им эффективно. Для этого и нужно иметь представление о том, как он может быть реализован.
Ну, волна как нашла, так и схлынет, вместе со всеми поверхностно подошедшими товарищами. А те, кто смог подойти к вопросу более серьёзно, думаю, неплохо повысят свой профессиональный уровень.
В конце концов, именно благодаря возросшему интересу к ФП в сообществе в целом (в том числе и внутри команды MS) мы сейчас на C# пишем в гораздо более функциональном (и удобном) стиле, чем раньше.
Цепочки запросов LINQ; функции высшего порядка везде в FCL; Resharper норовит всё что можно объявить как readonly — это всё ведь следствия сближения mainstream languages с миром ФП.
Nemerle был очень классным примером тоже, многое из него вошло частью в современный C#, частью в F#.
Во всяком случае, познакомиться с тем, что F# умеет в этой сфере, я думаю, очень полезно.
А тут рассмотрены общие подходы, реализация на C# просто для удобства. А во второй части будет про библиотечные классы, и весьма вероятно, что реализация параллелизма в F# строится на них же.
Вообще всё-таки книга, я думаю, многовато там для статьи :)
не видит SD
не видит WiFi
через 2 минуты работы сообщает «Ой! Процесс system не отвечает»
и в довершение всего — перезагружается
Вы ничего толком не опровергли. GAE, да, „устойчиво медленно“ работает. А Azure — быстро. Мне кажется, стоит бороться с маниакальным желанием опустить MS невзирая на факты.
> ___________________________________________________________
А вот тут вы не правы, серьёзно. ТЗ требуют не потому, что боятся ответственности (странная формулировка), а потому что это единственный критерий
1) оценки и 2) принятия работы.
Вот Вы сказали Васе: «напиши мне генератор договоров на WPF, за 1000 уе». Вася говорит, — «Ок!», и через день показывает Вам программу, где одно поле ввода «сумма» и одна кнопка — «сгенерировать». И всё, это формально уже — генератор договоров, причём на WPF, и Вася ждёт свою 1000 уе. Это одна крайняя ситуация. Тут проигрываете вы.
А вот вторая: проект идёт 3-й месяц, вы всё придумываете и придумываете улучшения, и посылаете их Васе. Общие трудозатраты давно уже вылезли за это 1000 у.е., но вы всё ещё считаете, что «генератор» ещё не совсем готов. Это вторая крайняя ситуация, и тут проигрывает Вася.
И выхода всего два (три):
1) ТЗ, описанное до каждой запятой
2) Почасовая оплата работы Васи
3) (смесь 1 и 2) гибкая (agile) разработка с разбиением проекта на много маленьких, каждый из которых отдельно оценивается, оплачивается, и для каждого минипроекта формулируются чёткие требования до запятой.
можно было бы просто написать «наш стартап обречен на провал
очень толсто. не говоря уже о том, что глупо :)