Как стать автором
Обновить

Комментарии 129

Андрей [styskin] Стыскин очень смешно любит Java :)
А мне наоборот показалось, что не смешно, а грустно. Буря чувств. Безумная и всеобъемлющая любовь, которой тебя лишает бессердечный Яндекс.
Да, да, точно — буря.
В детстве сильно тащился от Asm — но это так, для кругозора — писать на нем долго и сложно. Тогда приходилось писать на Бейсике (а он мне не сильно нравился). Паскаль не любил за бесчисленные begin-end.

В юности, на заре интернета писал на Perl — очень круто, но нечитаемо. Потом перешел на PHP — в эпоху, когда некоторые писали сайты на Delphi + BDE (то был ужас), php был хорошим, даже не языком — решением.

Сейчас Python. Понятный, очень читаемый, модульный, с огромной библиотекой и батарейками. Очень нравится. Ну и JavaScript, конечно — куда нынче без него.
Почему не Руби?
А почему не Go\Rust\D\Brainf*ck\Еще десяток других языков помимо Ruby? Странный вопрос задали.
Видимо потому, что ruby и python очень сравнимы.
И еще потому что перловики часто переходят на руби.
Я видел как успешные php-шники переходят на python
bobuk не любит ерланг, а следующий stolen уже любит )))
Странно что нет комментариев про Rust.
Хотя может и правда еще рано.
странно, что нет комментариев про Rust от bobuk он любит говорить за него в Radio-T, иногда :)
Так я о том же.
Может и правда рано, но я согласен со Степаном Кольцовым: в будущем все будут писать на Rust.
Вавинов и Кольцов говорят за Rust
Фразу

Данил занимается нашим WebDAV-сервером, о котором мы рассказывали и который был написан на Erlang.


я почему-то по инерции прочитал как

Данил занимается нашим WebDAV-сервером, о котором мы рассказывали и который был написан на языке от которого подташнивает bobuk-a.
Ни один джавист не упомянул скалу. Поразительно. :)
Тоже ожидал упоминания этого языка.
Я очень удивился когда сделал поиск и не нашел упоминания :-)
У нас уже почти готовый продукт написан, а с каждым днем все больше понимаем, насколько мало мы знакомы с бесконечными возможностями которые дает этот язык.
Многие апологеты Скалы в последнее время отчего-то переключились на Rust.
Это какие скалисты все же хипстеры. Т.е. они плюнули на всю инфраструктуру Java, со всеми ее 100500 библиотеками решений задач на каждый день, и переключились на Rust с 10 библиотеками на язык, который еще ни разу не продакшн. Смело.
Ни один джавист не упомянул Акку и Кложу!
Ну, акка не язык, а вот мой организм синтаксис кложи как и лиспа не может переварить.
Даже Хаскель симпатичнее смотрится. :)
Все-таки Clojure по подходу от Java далека и джависту с нуля в ней освоится не просто. Но это отличный способ лисперу прижиться в Java-мире :-).
Akka, из-за особенностей планировщика JVM, все-таки не заменяет Erlang, где планировщик знает об очередях сообщений и нет разрушающего присваивания. Все равно приходится избегать блокирующихся операций, помнить по пуле нитей. По этому и восторгов мало.

А почему джависты плохо воспринимают Scala я понять ни как не могу. Вроде все приемы работы из Java в Scala так же применимы, а часто и более удобны. Только из-за поддержки в IDE?
Поддержка в IDEA отличная. Работая полгода в режиме фултайм, я замечал только один косяк — в 1% случаев не показывает ошибки несоответствия типов.
Да, и с автоимпортами тупит и ошибается.
Да нормально мы ее воспринимаем. Только самым главным мотиватором для перехода на Scala были лямбды. А с 8й Java'ой такая необходимость отпала. Есть другие буонусы, но пока и так комфортно.
Я люблю Скалу, но 8я джава действительно решила главную проблему и проектов на скале сразу стало меньше.
А как же вывод типов? :) Я уже не могу представить, что перейдя на джаву буду вместо val писать черт знает сколько.
Слабоват в Scala вывод типов. В системах с подтипами полноценный вывод типов сделать невозможно.
Конечно, на безрыбии и рак рыба, но после Haskell описывать типы аргументов функций бывает лень ;-).
Меня в Scala привлекает поощрением иммутабельности, коллекциями, лучшим параметрическим полиморфизмом, и REPLом. Говорят, что современные IDE могут заменить REPL, но я ими не умею пользоваться.
Да, еще pattern matching. Когда программировал на Scheme, его отсутствие расстраивало. Правда, там были реализующие его библиотеки, но не хотелось тянуть в проект лишние зависимости.
Как-то так получилось, что питон обошел меня стороной когда я менял направление своей работы, но посмотрев это видео у меня почему-то зачесались руки начать на нём писать )
А еще, я не видел bobuk ни на фотках, ни в видео уже больше года. Он изменился в лучшею сторону. Похудел, как-то спокойнее стал, стареет, наверное.
Он замечательный, на нём можно заниматься увлекательнейшими вещами, имеющими отношения к теории языков программирования. И это как-то удивительным образом перпендикулярно производству какой-то осмысленной работы.

О да :). Удивительные вещи в самом деле слишком часто оказываются ортогональны осмысленной работе :).
Нужно просто с ними однажды наиграться и начать работать уже. Хаскель для этого совершенно пригоден, что показывают успешно разрабатываемые на нем проекты.
Насколько я понимаю слова Андрея Плахова, они описывает особенность не Хаскеля, а самого Андрея Плахова. Я в некоторой степени тоже обладаю этой особенностью, и в своём комментарии я говорю не о Хаскеле, которого совершенно не знаю, а о себе. Это у меня удивительные вещи слишком часто ортогональны нормальной работе, и это мешает до некоторой степени.
Здесь он не прав.
Когда я занимался моделированием систем на кристалле, Haskell оказался самым удобным для этого языком. Мне кажется, что работа была вполне осмысленна.

В других областях Haskell тоже не особо хуже популярных языков (правда и не радикально лучше), только уровень вхождения слишком высокий.
Скажем так, снайпер и из золотого пистолета хорошо будет стрелять.
No offence against Haskell: habrahabr.ru/company/yandex/blog/230775/#comment_7809161

Я вообще не знаю Хаскель, но ортогональность интересных вещей нормальной работе замечал тоже.
И они. дома. вечерами. тайком. пишут на php…
Никто не любит C# :-(
Так можно сказать о php, а C# платформо-зависим. Его возможно любят в отделах раработки под win-платформы, а судя по конференциям все что можно — у них на linux работает.
А как вы оцениваете вероятность найти любителя C# в компании, разрабатывающей веб-сервисы под линуксом?
Я тоже пишу веб-сервисы под линуксом, но мне это не мешает в свободное время, клацать на C# :-)
Ну и что? Джон Скит любит C#, и является самым известным мировым спецом по нему, хотя работает Java разработчиком в Гугле.
Так какова вероятность найти в Яндексе Джона Скита?
Да, кстати, интересно, есть ли в Яндексе местные Джоны Скиты.
как ненулевую
Go, Ruby? Почему нет этих языков?
Go имеет фатальный недостаток применительно к Яндексу
тем не менее в Яндексе используют Go :)
Тем не менее, они с ним играются.

habrahabr.ru/post/227073/
Вячеслав Бахмутов из Яндекса рассказал про опыт использования Go в своей компании в облачной платформе Cocaine. «В Яндексе нет вакансий на gophers, берут питонистов, а потом говорят – будешь писать на Go»

UPD: ссылки у меня не оформляются, поэтому оставил так.
Потому что эти языки совсем недавно были игрушками для тех, кому хочется чего-то нового.

Ruby хоть и существует давно, но до популяризации его 37signals, для него было написано сравнительно мало reusable кода и нормальных библиотек. Скорость выполнения тоже была не впечатляющая. Из всех «преимуществ» только синтаксис, да и то это вопрос субъективный — кому-то нравится, кому-то нет.

Go еще новее и еще «сырее».

У меня подозрение, что Яндексоиды думают примерно так же, как наши разработчики: «Руби? Зачем, когда есть Python?» — не холивора ради, но в правильных компаниях думают не как поиграться с очередным языком, а как эффективно решить задачу любым подходящим инструментом.
Как-то молодо некоторые из них выглядят для того, чтобы программировать по 25-30 лет :)
НЛО прилетело и опубликовало эту надпись здесь
причем, если верить дате рождения в профиле хабра — получается что чуть ли не с 5 лет программируют :)

не, ну я тоже в 5 лет программировал таймер на телевизоре, чтобы он через полчаса сам выключился, тем самым напугав бабушку :)
Тоже заметил. Мне например 25, как и у многих тут первая ЭВМ появилась довольно рано, допустим какой-то из клонов ZX Spectrum, где кроме как программировать ничего не оставалось. С тех пор так или иначе я связан с программированием. Получается, что я программирую 19 лет?
Получается, что да :) Я давала участникам опроса самим определить, когда они считают, что начали программировать. Но в основном у всех взяла самые ранние даты, если они не были категорически против вести с них отсчет. Реально в Яндексе много людей, которые лет с семи программируют.
У тебя не должно быть любимого языка программирования. Стать слишком близким с одним языком программирования — большая ошибка, чем недостаточное знание его. Не копируй других, действуй по ситуации. Плохо также для продукт-менеджеров и тимлидов испытывать к кому-то любовь или неприязнь. Тщательно изучи это.
Краткий пересказ: я хорошо знаю язык X, и немного приходится работать на языке Y. Поэтому X — люблю, Y — не люблю. Ещё я знаю perl, но в самом начале только и набирали perl-программистов. Сейчас переучиваюсь на другой язык Z, и т.к. я плохо знал perl, язык Z мне нравится больше (или т.к. я хорошо знал perl язык Z мне нравится меньше). И вообще язык это инструмент бла-бла-бла ко-ко-ко.
НЛО прилетело и опубликовало эту надпись здесь
Хороший программист может за 2 недели разобраться и начать писать на любом языке

Да ладно.
Ну начать писать, наверно, можно. А вот хорошо писать хорошие программы — …
Полгода-год в удачном коллективе.
за 2 недели реально узнать ключевые слова try-catch / try-except / etc. И дальше можно программировать в стиле Stackoverflow Driven Development.
Да ладно.
Ну начать писать, наверно, можно. А вот хорошо писать хорошие программы — …

Если программист опытный, то он быстро проведёт параллели между конструкциями/парадигмами нового и старого языков, и будет на 90% в курсе потенциальных граблей, на которые напарываются начинающие программисты.
Остаётся проблема велосипедов, но она обычно успешно решается на этапе ревью кода.
Плюс в случае Яндекса за соседними столами наверняка найдутся высококвалифицированные консультанты по нужному языку, готовые помочь в сложных случаях.
Я так и представляю программиста php, перепрыгнувшего на erlang. Всё-таки ЯП — это не естественные языки, бывает что они кардинально отличаются.
Как-то был на конфе и спросил у одного из докладчиков, – Какой язык программирования нужно знать, чтобы устроиться на работу в Яндексе? Сказали, – Python.
Программировал раньше на Перле — великолепный язык, который позволяет очень быстро выразить мысли в программу.
Сейчас программирую на C#, тоже доволен.
Подумал я, что любимый язык для меня тот, на котором я программирую на данном этапе жизни.
Вот говорят, что на Перле страшные программы. Так не пишите страшные программы, и их не будет. На перле можно написать так, что программа мало будет отличаться, например, от программы на PHP.
Скорее это на PHP можно написать так, что он не будет отличаться от перла (собственно этим и любят страдать «начинающие фрилансеры», скажем так) =)
НЛО прилетело и опубликовало эту надпись здесь
Не уверен, что это комплимент Перлу. Код на пхп обычно ужасен.
В любом случае, если на Перле можно писать страшно, это не означает, что нестрашно тупо не написать.
А Вы когда, извиняюсь, последний раз видели PHP в глаза? И чем, допустим вот это: github.com/laravel/framework/blob/master/src/Illuminate/Mail/Mailer.php отличается так сильно от шарпа или джавы (ну за исключением долларов и типизации).
Пол-года назад. Дали систему дистанционного обучения на базе какого-то открытого проекта, сказали исправить мелкий баг.(раскрытость пункта меню не всегда при переходах сохранялась). Глянул в код, пришел в ужас. Хорошо, что удалось спихнуть на коллег — они несколько месяцев с этим мучились.

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

PS К тому же я не считаю java (да и C#, хотя знаком с ним только теоретически) хорошим языком. Scala позволяет писать более краткий и выразительный код.
Все знакомые из Яндекса говорили, что там используются три языка — js, python и C++. Обнаружить столько поклонников Perl было неожиданно :-). Сам использую Perl для программ не длиннее 20 строк. А часто из одной строки, запускаемой из vim или с помощью perl -e. В этой области Perl не превзойден.

Еще очень радует интерес к Rust. Я тоже считаю, что за ним будущее.
А Haskell, по моему, недооценили. Когда его знаешь, для многих задач он оказывается неожиданно удобным языком.

Обнаружил у себя странный критерий — если язык требует для возврата значения писать return (или его аналог, хотя эффект слабее :-) ), он мне не симпатичен, а если не обязательно, то язык приятен. Пока исключение только одно — Паскаль :-).
Все знакомые из Яндекса говорили, что там используются три языка — js, python и C++

Это далеко не исчерпывающий список, конечно. Даже на скале проекты есть.
Наверно, мне так «везло». Были рубисты, пересевшие на питон и схемник, вспомнивший C++.
Любил да и люблю тайной любовью С++, хотя, по правде говоря, уже лет так 10 на нем ничего не писал. Одно время прототипировал на плюсах, но потом как-то все больше в С# подался, иногда балуясь Python, но любимым на данный момент является Java. Все свои проектики, особенно десктопные, делаю на Java. Думал подключать скалу, но после выхода Java8, пока сильной необходимости в Скале не вижу (в своих проектах), но как говорится «это только пока». Вот такие вот пироги.
Нда… Вроде «Rндекс», большая компания — не ожидал увидеть столько мракобесия — гик на гике с патологическим вывихом мозга и оттого странными предпочтениями в языках. Далдонят как мантру «скорость, С++» (при этом умудряются *овнокодить на Пестоне), а на дворе уже 21 век — не заметили, сердешные, что выжимать уже надо не байтами, а многопроцессорностью и времени на возню в С++ нет — писать надо быстро, масштабируемо и предсказуемо. То есть на C#. :) (люди повыше рангом — на Nemerle)
А в 21 веке хвалить Jaбу — это чистый пример «парадокса блаба» (гуглите).

Про С++ правильно сказали только одно: «Это плохой молоток, плохой нож, плохая ложка, плохая вилка, плохой штопор и так далее». ППКС.
Ну да, Яндекс-то весь на ноуте у Воложа на шкафу работает, какая там многопроцессорность :)
Ключевое слово — «С++», атавизм похуже перфокарт.
А вы представьте, что владеете компанией, для которой машинное время стоит в 10 раз дороже программистского. На чем будете писать?
Компиляторы C++ неторопливые. Придется какой-нибудь oberon выбрать…
Это что за машина такая? Золотой арифмометр, у которого ручку крутит Путин? Тогда да, бесценно. А так даже гугловские облака — дешевле грязи, о каком «дорогом машинном времени» речь?? Сейчас даже у стодолларового телефона 4(!!!) ядра!
Попробуйте себе представить, например, 100000 машин, выполняющих ваш код. Если мы не используем атавизмы, а пишем на каком-нибудь новом модном языке, это количество надо умножить примерно в 2—2.5 раза.А теперь считайте, во сколько вам обойдётся питание дополнительных 100к—150к машин, линии питания и охлаждения в датацентре (так и быть, будем для простоты считать, что нам не придётся строить 1-2 дополнительных датацентра), зарплата дополнительных инженеров, которые будут эти машины обслуживать, само обслуживание серверов — при таких количествах каждый день обязательно несколько машин выходят из строя.
Попробуйте прикинуть всё это с числами, тщательно всё просуммировать, сравнить с собственной зарплатой программиста, и если вдруг у вас получится, что программист обходится дороже, то, думаю, можете смело идти строить ЦОДы и организовывать свой AWS.
Вы когда нолики набирали, у вас палец застрял :)
1. Даже по официальным данным (которые яндексу имеет смысл завышать) у них всего 10,000 серверов. Очевидно, что не все из них даже в единой сети, а уж отдельно поиском занимается ограниченное к-во машин.
2. Не надо ничего умножать, всё гораздо проще: есть одна машина, которая тянет на 80%. Её хватает для задач, но для надёжности её масштабируют ещё.
То, что C# как «дробилка» слабже C++ — я полностью согласен, но «слабже» вовсе не означает двукратный проигрыш и аналогичное требуемое оборудование — там всё же не числа умножают, а делают поиск по текстам — совсем другая задача. Вполне жизненным может быть вариант, когда два С++ сервера загружены каждый на 20%, а три C# сервера — на 40% — это очень хорошие показатели, при которых стоимость разработки — точно ниже, а нагрузка — _приемлемая_ для их задач.
М-да.
Из всей статьи, Вы не смогли вынести главного — для своей цели, свой инструмент.
Странно, что вы вообще нашли в статье «цели» — или вы смело отождествили должности с тем, что конкретно пишут на упомянутых языках? Смело, но недостаточно, чтобы здесь умничать.

Кроме того, одно и то же можно написать на многих языках, вплоть до экзотических (тем же Рефалом спокойно обрабатываются тексты). Но если в мэйнстриме я увижу что-то рефалоподобное, этот проект умрёт для меня навсегда — потому что до некоторых яйцеголовых не доходит, что цель — одна, но путей и факторов оценки этих путей — много. «Скорость» — важное, но не самое главное в долгосрочных проектах — куда больше там важна устойчивость (тут С++ сливает на раз), сопровождаемость (вообще с С++ не подходи), лёгкость найма опытных разработчиков (а не клепателей классов по паттернам с неделей применения boost) и т.п. Будь у школоты побольше опыта, она б не фапала на свой С++ как Кихот на Дульсинею — в реальной жизни есть много чего, до чего они ещё не доросли — прощу уж им их штопаные минусы.
1) Умерьте свой пыл.

2) Не понимаю, как
для своей цели, свой инструмент
противоречит
одно и то же можно написать на многих языках, вплоть до экзотических
? В статье явно и неявно упоминают (в очередной раз), что язык — это инструмент. Или Вы по диагонали прочли?
У Вас явно где-то жирный пункт по поводу C++. В Intel и NVIDIA точно дураки работают, раз делают это и это. Им срочно нужно донести, что
«С++», атавизм похуже перфокарт
. Я привел в пример только то, чем сам пользовался.

3)Я прекрасно понимаю программиста, который выбрал для разработки бизнес-приложения Java/C#. Я так же прекрасно понимаю программиста, который выбрал С/С++/Fortran для разработки приложения реального времени. И я не утверждаю, что менять местами нельзя. Инструмент — это не только язык, но и инфраструктура, связанная с ним. Так о чем Вы хотели поспорить?
С вами вообще никто не хотел спорить — после слов «Из всей статьи, Вы не смогли...» я слышу лишь пижонство. Нравится С++ — ради бога, могу подарить дискеты, чтобы хранить заголовочники. Мне больше нравится прогрессивный подход — использовать новейшие разработки, тем более, что они позволяют с лёгкостью заменить С++ во многих местах. Думаю, Тындекс — не исключение, С++ там — лишь исторически сложившийся факт.
«Имеющий уши да услышит, имеющий глаза да увидит». Вы, видимо, не имеете ни то, ни другое. За сим удаляюсь.
— Теперь выбери себе язык программирования. Ты почувствуешь его. Если и он выберет тебя, действуй быстро. У тебя одна попытка, %username%.
— А как понять, что он меня выбрал?
— Он захочет тебя убить.
Похоже, меня когда-то выбрал APL (в виде K). Но я от него убежал, наверно зря. Теперь жалеть буду. ;-)
Python, Java, Perl… Специфика Яндекса понятна, это в основном серверное и веб-программирование.
А вот кто сможет назвать язык для создания хороших десктопных Rich GUI приложений? C# понятно, а если без привязки к .NET? Чистый C++ не предлагать, слишком уж он низкоуровневый для написания нормальных прикладных вещей «для пользователя». Я бы предложил Delphi (из-за нелюбви к Delphi просьба не минусовать).
А Java со свингом не подходит почему? Ну или Qt…
D + куча ГУЁвых библиотек.
Создание rich GUI требует от платформы таких возможностей (сугубо имхо):
1. Большой выбор разнообразных готовых контролов
2. Возможность кастомизовать их (другая иконка у чекбокса, разноцветные строки в листбоксе)
3. Создавать свои контролы (например, дерево, элемент которого — выпадающий список).
4. Чтобы в итоге это все хорошо выглядело на разных разрешениях.
5. Чтобы в итоге это еще и быстро работало (т.е. желательно аппаратное ускорение графики).
6. Четкое отделение UI от кода (иначе они срастаются, и править становится тяжело).
7. Возможность делать современные эффекты и анимации.

Кроме WPF что позволяет хотя бы половину? Попробуйте на Qt сделать сложный контрол, сколько уйдет на это времени? Единственное что-то подобное WPF, что попадалось на глаза — это FireMonkey, но я об этой технологии почти ничего не знаю.
Четкое отделение UI от кода

И много вы в WPF «наотделяли»? Скажу вам по секрету, мания «отделять» — не самое важное в производстве программ. Хуже того — т.н. «логика» — это не только бизнес-правила, но и логика работы самих ГУЁв! Её вы куда собрались отделять? Более того — «логики» не существует самой по себе, она так или иначе завязана на бизнес-сущности. Так что всё это «отделение» — тупой баззворд, кто реально пишет программы, тот не гемороится сверх необходимого. Надо «покупателя» с методами — пожалуйста, но если в форме есть сотня методов для поддержки этой формы (и они, само собой, используют «покупателя») — я так их прямо и напишу.
Кратко, возможности WPF по написанию качественного UI — ни на грош не лучше WinForms, разве что в простейших случаях кастомайзятся полегче.

Чтобы в итоге это еще и быстро работало

Это такая шутка что ли? WPF — тормознутое чучело по сравнению с любым самым навороченным UI на WinForms.
Это тролинг такой?

1. Логика самих «гуёв» часто уходит в codebehind. Суть разделения не в «ui/код», а в «представление данных / обработка данных». Почитайте хотя бы Фаулера, что ли.

2. Логика завязана на бизнес-сущности, да. А в UI нет бизнес-сущностей, там только UI. Все правильно.

3. «Кто реально пишет программы». Ну я, и еще 500 моих коллег департамента исследований и разработки компании 2GIS реально пишем программы. И мы используем исключительно MVVM, вся логика во вьюмодели, весь ui в xaml, иногда немного в codeBehind. Мы все заблуждаемся по-вашему?

4. Про тормоза WPF — пруфлинк, пожалуйста, или демку. То что рендер WPF идет на видеокарте вы знаете? А что она быстрее считает графику, чем CPU, надо объяснять?

Основное преимущество WPF над WinForms (который даже рядом не поставить, это технологии разных технологических поколений) — это даже не кастомайз контролов, а связывание данных, позволяющее совершенно иначе (более гибко) строить архитектуру приложения.
Почему сразу троллинг? Вы настолько уверены в своей парадигме, что ничего другого понимать даже не пытаетесь?? Это называется самоуверенность, а я говорю абсолютно искренне. К слову, в моих приложениях тоже используется MVVM, но без фанатизма «чистоты». Если вы принципиально стоите на своих абстракциях, я даже не буду переубеждать — для себя я все выводы по MVVM уже сделал. А если интересно, вот вам задача поддых — как раз для ярых теоретиков: rsdn.ru слэш forum/dotnet.gui/5712828 — там как раз колом встала теория и ни WPF, ни MVVM не дают ответа. Точнее, ответы есть, но безобразные с т.з. нормальной логики.

> Про тормоза WPF — пруфлинк, пожалуйста

Вообще оборзели что ли от лени? Гугл перед носом, набери «WPF тормозит» и хоть упруфайся.

> Основное преимущество WPF… связывание данных, позволяющее совершенно иначе…

Ну то, что в XML засунули совершенно гетерогенный «язык связей» — да, но это ещё не делает технологию лучше. Если надо связать свойство item.Price с пргрессбаром.Progress — это можно делать и в WinForms, но когда идут сложные байндинги к шаблонам и подэлементам, там вообще хоть вешайся! «Лучшим» я это никак не могу назвать, скорее «универсально неудобным».
Пока что WinForms по простоте и сопровождаемости (ключевые факторы в мэйнстриме) даёт фору всяким WPF'ам, а уж про скорость и говорить нечего.
MVVM, или в общем случае разделение ответственности по классам/модулям/слоям с уменьшением их связности — это не моя парадигма, а фундаментальные основы объектно-ориентированного дизайна. Дело не только в том, что это общепринятое правило хорошего тона в разработке. Дело в том, что это работает. И вытекает из здравого смысла, из самых общий соображений, применимых в любой инженерной задаче. А то, что не нужно быть фанатиком, и не следовать концепции ради концепции — это любой адекватный человек понимает. Есть ряд вещей, которые сделать через MVVM довольно тяжко, и того просто не стоит. Беда в том, что эту довольно-таки капитанскую истину вы почему-то доказываете с бурей эмоций, обвиняя в самоуверенности — даже смешно становится.

wpf тормозит — вбил, и что? Если у кого-то кривые руки, это не проблема технологии. В наших продуктах ничего не тормозит.

Сопровождаемость WinForms? Представьте, что заказчик захотел часть функционала видеть в web-интерфейсе, а еще часть логики нужно связать с шиной данных. В WPF у одной модели может быть сколько угодно вьюмоделей, а у каждой из них — сколько угодно вьюх. Ваш код на WinForms будет проще (но дороже) переписать с нуля, коли «разделением» вы особо не занимаетесь.
Не надо мне рассказывать про «MVVM — это бла-бла...» — я уже написал, что тоже это использую. Игнорирование этого факта выявляет в вас просто «толкателя своего мнения», даже не читающего что ему пишут. Зачем тогда все эти рассыпания в собственной уверенности о непогрешимости WPF? К тому же, я уже дал «задачу поддых» — что, опять замылился разум в толкании своего WPF? Где решение?

И я опять вижу настойчивое бла-бла «WPF — это круто, потому что это MVVM». Это НИ РАЗУ не верно. WPF — гуёвая библиотека, MVVM — архитектура приложения. Причём можно делать MVVM с использованием WinForms (надеюсь, вас не шокировало? Вы устойчиво сидите?).

> wpf тормозит — вбил, и что? Если у кого-то кривые руки…

Ясно. «рашен программашен» — «у меня всё работает, а вы там хоть сдохните!».

> Представьте, что заказчик захотел часть функционала видеть в web-интерфейсе…

Уже ответил. WinForms позволяет точно так же писать с применением MVVM. Я лишь подчёркиваю, что не всё так идеально — «наотделять» много ума не надо, но есть куча именно гуёвой логики, которую «отделить» — целый геморой, задачу выше я уже предложил.
В общем спорить больше не собираюсь, отвечу только на ваш вопрос. Посмотрел «задачу поддых». Поверьте, это совершенно не проблема, а типичная ситуация в MVVM. Проблемой она становится тогда, когда люди неправильно применяют WPF, фактически нарушая MVVM. А именно: во вьюмодели родительского окна, в команде, НЕЛЬЗЯ создавать вьюшку дочернего. Вьюмодели не знаю о вьюхах! Они должны знать только друг о друге. И вьюхи друг о друге, но не о вьюмоделях.

Решается очень просто. В команде родительской вьюмодели создаем дочернюю вьюмодель, передавая в нее все необходимые данные (иногда — просто ссылку на себя), и вызываем сервис, который по вьюмодели автоматом строит вью. Это умеет делать Catel, MVVM-фреймворк последнего поколения.

Мой видеоурок на эту тему: http://www.youtube.com/watch?v=qAktu1eGGa8
И код из видео: https://github.com/TimeCoder/DotNet/blob/master/src/BooksLibrary/ViewModels/MainViewModel.cs (строка 88)

НЛО прилетело и опубликовало эту надпись здесь
Печальная картина, друзья.
Несколько десятилетий активного развития IT-сфера так и не дали нам удобный «швейцарский нож» с острыми лезвиями. Мы пишем на С++ из-за его высокой производительности — но ругаемся на его низкую безопасность, все более тяжелый синтаксис, и низкую скорость разработки на нем. Язык C# — по мне так выразителен как поэзия, за создание WPF Майкрософту можно простить все прошлые грехи — но нет кросс-платформенности. Питон лаконичен, но обладает недостатками, присущими всем языкам с динамической типизацией.

Какой-то заколдованный круг. Я хочу писать на языке с понятным (не Haskell, Rust и пр.) синтаксисом (как C# например), чтобы он был кросс-платформенным, позволял за счет своих стандартных библиотек создавать rich GUI, если нужно — играться с памятью на низком уровне. Несбыточная мечта?
Ну и за что минусы?)
Основа синтаксиса Rust та же, что и в C# — это C-подобные языки.
А чем не понятен синтаксис Haskell? Синткасис простой, с минимумом конструкций, без лишней пунктуации, ориентированный на человека. Семантику понять может быть сложно, но синтаксис.
Хотя сталкивался с ерлангистом, которые жаловался, что отсутствие скобок и запятых делает его непонятным для инженеров-электонщиков — мы тогда спорили, на чем модели микропроцессора писать :-).
Есть такая фраза: язык — это форма мышления. Думаю, что синтаксис как таковой там не сложный, трудность в том, чтобы перестать мыслить в ОО или процедурном стиле, и видеть решение задачи чисто в функциональном подходе. С ходу сложновато, нужна практика, а ее получить сложно: не вижу проекта, для реализации которого идеально подошел бы функциональный язык, а писать хелло-ворлды не хочется.
Я предположу, что Вы считаете синтаксис непонятным только потому, что недостаточно изучили его или работали с ним.
Думаю, когда Вы только начинали программировать, Вы были в ужасе от синтаксиса C#/C или с чего начинали.
Я вот точно помню — был в шоке и ничего не мог понять в C в программе HelloWorld.
Думаю, Вы правы, есть такой момент. Может и не только этот. Заголовок функции в любом С-подобном языке лаконичен донельзя:
int CalcFactorial(int number)
в отличии от упомянутых ранее языков нет стрелочек, слова fn и т.п. Для человека хотя бы немного знающего английский, этот код — фактически, выражение намерения на естественном языке (вычислить целочисленный факториал). Из каких-то дополнительных элементов (кроме названий) — только круглые скобки. Связь которых с передачей значения чему-либо всем интуитивно понятна за счет вшитой школьной алгеброй f(x).
лаконичен донельзя:
int CalcFactorial(int number)


В Питоне ещё лаконичнее :)
Правда, чем непонятен синтаксис Rust? Типичный синтаксис в стиле C++, синтаксис лямбд, говорят, взят из Ruby. И как раз всё как Вы хотите — безопасный код бесплатно (время жизни и обращение к переменным проверяются на этапе компиляции и в рантайме не тратят ничего), при этом разрешено делать unsafe{} блоки, в которых можно стрелять себе в ногу. Полная кроссплатформенность, кто-то на нём даже загрузчики писал, сейчас coreutils активно разрабатывают.

С GUI, и другими библиотеками пока хуже, но у них как раз появился сейчас менеджер пакетов а-ля npm, и дальше ситуация будет улучшаться.
Про синтаксис ответил комментом выше. А вообще, Вы же понимаете, что для реальной профессиональной разработки
язык != синтаксис языка
язык = синтаксис языка + стандартная библиотека + внешние библиотеки + среда разработки + комьюнити и пр.

Сложно представить, сколько MS вложил в разработку платформы .net. И GUI — для меня это как раз лакмусовая бумажка зрелости платформы. Мне попадались интересные языки, и интерес угасал сразу после ответа на вопрос «а как тут сделать хороший GUI».

Дай Бог, что Rust в этом плане разовьется. Но ведь несколько лет назад то же самое пророчили языку D… А по факту уже годами получается, что нормально делать приложения, с современным UI, можно (с разной степенью удобности) на WPF, Qt и Java, и все(
Ну, Вы жаловались на непонятный синтаксис, поэтому именно про него я и отвечал) И тем страннее выглядит в вышеупомянутом комментарии отсылка к лаконичности C по сравнению с Rust, когда Вы комментарием выше за эталон берёте C#, который, как и Java, весьма многословен и неочевиден.
за эталон берёте C#, который, как и Java, весьма многословен и неочевиден
Думаю, тут уже вопрос вкуса. Для меня код C# — самое понятное, что только можно придумать, кто-то от него плюется. Ну и я не отказываюсь от своих слов про синтаксис. Нам бы взять человека, вообще не знакомого с программированием, и показать, что понятнее:
fn factor(n: int) -> int
или
int factor(int n)
Опросил несколько незнакомых с программированием гуманитариев (в примере добавлял ещё тело { return 1 }). Ответы разделились на две группы:
  • обе конструкции одинаково непонятны;
  • кажется, и там, и там какая-то функция, возвращающая 1

Так что разницы, имхо, никакой.
Понятно. Видимо, группа #2 сделала свои выводы по телу функции, так что если говорить про сам заголовок, то есть только группа #1) Возможно, нужно поднять планку: технари, но не программисты.
Боюсь, таких найти не получится) Технари все учат тот или иной язык, либо просто в рамках программы, либо в силу необходимости (на нашем химфаке почти каждый знал что-то из списка pascal/perl/c/fortran), соответственно, опрос просто сводится к вопросу, какой синтаксис ближе к изученному технарём языку.

Собственно, паскальщикам наверняка будет гораздо привычнее и очевиднее синтаксис Rust.
Народ, вы странные. Конструкции эквипенисуальные. Это как в школьные годы спорить, что лучше — begin/end или {/} (умолчим о том, что фигурные скобки таки победили :-) ).
Я как раз и не спорю)
У меня одна надежда — что дикий Столлман покусает Майкрософт, и дотнет со всеми потрохами окажется в полноценном опенсорсе (а не как сейчас — частично приоткрытый дотнет и закрытый рантайм). Компиляторы шарпа и басика уже там, так что чудеса случаются… Будет опенсорс — будут полноценные порты, а не костыли с подпорками, не будет религиозной неприязни, и вообще мир станет лучше.

Пока что из всех чудес это наиболее реалистичное, потому что МС позарез нужны мобилки, и кросс-платформенность внезапно становится выгодна.

Остальные чудеса совсем далеко: C++ не станет красивым и безопасным языком (давайте добавим 101-й способ прятать указатели — и всё станет зашибись, ну правда?), Java не станет мощным и универсальным языком (свойства? операторы? генераторы? ...указатели?), JavaFX не станет конкурентом WPF (CSS — наше всё), IDE для динамических языков не научатся читать мысли (свойство может быть, может не быть, но я тебе никогда не скажу), Haskel не станет понятным для простых смертных (а значит, непростым смертным не увидеть его на реальных проектах)…
Присоединяюсь. Мое видение ситуации слово в слово совпадает с вашим.
Автору — спасибо, что не поленились столько людей опросить. Получилась довольно взвешенная картина, и даже холиварить особо не хочется, хотя тема ещё та! :)
Спасибо! На самом деле, я переживаю, что наоборот — не все мнения высказаны. Хотя понимаю, что когда их сотни, собирать их сложнее.
Сколько комментов, и никто не написал, что для Zalina отведено слишком мало времени в ролике :)
Ну вот освою наконец-то циклы на Питоне и буду отводить себе больше времени))
Зарегистрируйтесь на Хабре , чтобы оставить комментарий