Комментарии 129
Андрей [styskin] Стыскин очень смешно любит Java :)
В детстве сильно тащился от Asm — но это так, для кругозора — писать на нем долго и сложно. Тогда приходилось писать на Бейсике (а он мне не сильно нравился). Паскаль не любил за бесчисленные begin-end.
В юности, на заре интернета писал на Perl — очень круто, но нечитаемо. Потом перешел на PHP — в эпоху, когда некоторые писали сайты на Delphi + BDE (то был ужас), php был хорошим, даже не языком — решением.
Сейчас Python. Понятный, очень читаемый, модульный, с огромной библиотекой и батарейками. Очень нравится. Ну и JavaScript, конечно — куда нынче без него.
В юности, на заре интернета писал на Perl — очень круто, но нечитаемо. Потом перешел на PHP — в эпоху, когда некоторые писали сайты на Delphi + BDE (то был ужас), php был хорошим, даже не языком — решением.
Сейчас Python. Понятный, очень читаемый, модульный, с огромной библиотекой и батарейками. Очень нравится. Ну и JavaScript, конечно — куда нынче без него.
Ни один джавист не упомянул скалу. Поразительно. :)
Тоже ожидал упоминания этого языка.
Многие апологеты Скалы в последнее время отчего-то переключились на Rust.
Ни один джавист не упомянул Акку и Кложу!
Ну, акка не язык, а вот мой организм синтаксис кложи как и лиспа не может переварить.
Даже Хаскель симпатичнее смотрится. :)
Даже Хаскель симпатичнее смотрится. :)
Все-таки Clojure по подходу от Java далека и джависту с нуля в ней освоится не просто. Но это отличный способ лисперу прижиться в Java-мире :-).
Akka, из-за особенностей планировщика JVM, все-таки не заменяет Erlang, где планировщик знает об очередях сообщений и нет разрушающего присваивания. Все равно приходится избегать блокирующихся операций, помнить по пуле нитей. По этому и восторгов мало.
А почему джависты плохо воспринимают Scala я понять ни как не могу. Вроде все приемы работы из Java в Scala так же применимы, а часто и более удобны. Только из-за поддержки в IDE?
Akka, из-за особенностей планировщика JVM, все-таки не заменяет Erlang, где планировщик знает об очередях сообщений и нет разрушающего присваивания. Все равно приходится избегать блокирующихся операций, помнить по пуле нитей. По этому и восторгов мало.
А почему джависты плохо воспринимают Scala я понять ни как не могу. Вроде все приемы работы из Java в Scala так же применимы, а часто и более удобны. Только из-за поддержки в IDE?
Поддержка в IDEA отличная. Работая полгода в режиме фултайм, я замечал только один косяк — в 1% случаев не показывает ошибки несоответствия типов.
Да, и с автоимпортами тупит и ошибается.
Да, и с автоимпортами тупит и ошибается.
Да нормально мы ее воспринимаем. Только самым главным мотиватором для перехода на Scala были лямбды. А с 8й Java'ой такая необходимость отпала. Есть другие буонусы, но пока и так комфортно.
Я люблю Скалу, но 8я джава действительно решила главную проблему и проектов на скале сразу стало меньше.
Я люблю Скалу, но 8я джава действительно решила главную проблему и проектов на скале сразу стало меньше.
А как же вывод типов? :) Я уже не могу представить, что перейдя на джаву буду вместо val писать черт знает сколько.
Слабоват в Scala вывод типов. В системах с подтипами полноценный вывод типов сделать невозможно.
Конечно, на безрыбии и рак рыба, но после Haskell описывать типы аргументов функций бывает лень ;-).
Конечно, на безрыбии и рак рыба, но после Haskell описывать типы аргументов функций бывает лень ;-).
Мне подсказали решение на джаве:
projectlombok.org/features/val.html
github.com/peichhorn/lombok-pg/wiki
projectlombok.org/features/val.html
github.com/peichhorn/lombok-pg/wiki
Меня в Scala привлекает поощрением иммутабельности, коллекциями, лучшим параметрическим полиморфизмом, и REPLом. Говорят, что современные IDE могут заменить REPL, но я ими не умею пользоваться.
Да, еще pattern matching. Когда программировал на Scheme, его отсутствие расстраивало. Правда, там были реализующие его библиотеки, но не хотелось тянуть в проект лишние зависимости.
Как-то так получилось, что питон обошел меня стороной когда я менял направление своей работы, но посмотрев это видео у меня почему-то зачесались руки начать на нём писать )
А еще, я не видел bobuk ни на фотках, ни в видео уже больше года. Он изменился в лучшею сторону. Похудел, как-то спокойнее стал, стареет, наверное.
А еще, я не видел bobuk ни на фотках, ни в видео уже больше года. Он изменился в лучшею сторону. Похудел, как-то спокойнее стал, стареет, наверное.
Он замечательный, на нём можно заниматься увлекательнейшими вещами, имеющими отношения к теории языков программирования. И это как-то удивительным образом перпендикулярно производству какой-то осмысленной работы.
О да :). Удивительные вещи в самом деле слишком часто оказываются ортогональны осмысленной работе :).
О да :). Удивительные вещи в самом деле слишком часто оказываются ортогональны осмысленной работе :).
Нужно просто с ними однажды наиграться и начать работать уже. Хаскель для этого совершенно пригоден, что показывают успешно разрабатываемые на нем проекты.
Насколько я понимаю слова Андрея Плахова, они описывает особенность не Хаскеля, а самого Андрея Плахова. Я в некоторой степени тоже обладаю этой особенностью, и в своём комментарии я говорю не о Хаскеле, которого совершенно не знаю, а о себе. Это у меня удивительные вещи слишком часто ортогональны нормальной работе, и это мешает до некоторой степени.
Здесь он не прав.
Когда я занимался моделированием систем на кристалле, Haskell оказался самым удобным для этого языком. Мне кажется, что работа была вполне осмысленна.
В других областях Haskell тоже не особо хуже популярных языков (правда и не радикально лучше), только уровень вхождения слишком высокий.
Когда я занимался моделированием систем на кристалле, Haskell оказался самым удобным для этого языком. Мне кажется, что работа была вполне осмысленна.
В других областях Haskell тоже не особо хуже популярных языков (правда и не радикально лучше), только уровень вхождения слишком высокий.
Скажем так, снайпер и из золотого пистолета хорошо будет стрелять.
No offence against Haskell: habrahabr.ru/company/yandex/blog/230775/#comment_7809161
Я вообще не знаю Хаскель, но ортогональность интересных вещей нормальной работе замечал тоже.
Я вообще не знаю Хаскель, но ортогональность интересных вещей нормальной работе замечал тоже.
И они. дома. вечерами. тайком. пишут на php…
Никто не любит C# :-(
Так можно сказать о php, а C# платформо-зависим. Его возможно любят в отделах раработки под win-платформы, а судя по конференциям все что можно — у них на linux работает.
А как вы оцениваете вероятность найти любителя C# в компании, разрабатывающей веб-сервисы под линуксом?
Go, Ruby? Почему нет этих языков?
Go имеет фатальный недостаток применительно к Яндексу
тем не менее в Яндексе используют Go :)
Тем не менее, они с ним играются.
habrahabr.ru/post/227073/
Вячеслав Бахмутов из Яндекса рассказал про опыт использования Go в своей компании в облачной платформе Cocaine. «В Яндексе нет вакансий на gophers, берут питонистов, а потом говорят – будешь писать на Go»
UPD: ссылки у меня не оформляются, поэтому оставил так.
habrahabr.ru/post/227073/
Вячеслав Бахмутов из Яндекса рассказал про опыт использования Go в своей компании в облачной платформе Cocaine. «В Яндексе нет вакансий на gophers, берут питонистов, а потом говорят – будешь писать на Go»
UPD: ссылки у меня не оформляются, поэтому оставил так.
Потому что эти языки совсем недавно были игрушками для тех, кому хочется чего-то нового.
Ruby хоть и существует давно, но до популяризации его 37signals, для него было написано сравнительно мало reusable кода и нормальных библиотек. Скорость выполнения тоже была не впечатляющая. Из всех «преимуществ» только синтаксис, да и то это вопрос субъективный — кому-то нравится, кому-то нет.
Go еще новее и еще «сырее».
У меня подозрение, что Яндексоиды думают примерно так же, как наши разработчики: «Руби? Зачем, когда есть Python?» — не холивора ради, но в правильных компаниях думают не как поиграться с очередным языком, а как эффективно решить задачу любым подходящим инструментом.
Ruby хоть и существует давно, но до популяризации его 37signals, для него было написано сравнительно мало reusable кода и нормальных библиотек. Скорость выполнения тоже была не впечатляющая. Из всех «преимуществ» только синтаксис, да и то это вопрос субъективный — кому-то нравится, кому-то нет.
Go еще новее и еще «сырее».
У меня подозрение, что Яндексоиды думают примерно так же, как наши разработчики: «Руби? Зачем, когда есть Python?» — не холивора ради, но в правильных компаниях думают не как поиграться с очередным языком, а как эффективно решить задачу любым подходящим инструментом.
Как-то молодо некоторые из них выглядят для того, чтобы программировать по 25-30 лет :)
НЛО прилетело и опубликовало эту надпись здесь
причем, если верить дате рождения в профиле хабра — получается что чуть ли не с 5 лет программируют :)
не, ну я тоже в 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% в курсе потенциальных граблей, на которые напарываются начинающие программисты.
Остаётся проблема велосипедов, но она обычно успешно решается на этапе ревью кода.
Плюс в случае Яндекса за соседними столами наверняка найдутся высококвалифицированные консультанты по нужному языку, готовые помочь в сложных случаях.
habrastorage.org/files/bc0/341/c7e/bc0341c7ec274bd8a95aafa60ceb9f88.PNG
Извините, теги не работают :(
Извините, теги не работают :(
Как-то был на конфе и спросил у одного из докладчиков, – Какой язык программирования нужно знать, чтобы устроиться на работу в Яндексе? Сказали, – Python.
Программировал раньше на Перле — великолепный язык, который позволяет очень быстро выразить мысли в программу.
Сейчас программирую на C#, тоже доволен.
Подумал я, что любимый язык для меня тот, на котором я программирую на данном этапе жизни.
Сейчас программирую на C#, тоже доволен.
Подумал я, что любимый язык для меня тот, на котором я программирую на данном этапе жизни.
Вот говорят, что на Перле страшные программы. Так не пишите страшные программы, и их не будет. На перле можно написать так, что программа мало будет отличаться, например, от программы на PHP.
Скорее это на PHP можно написать так, что он не будет отличаться от перла (собственно этим и любят страдать «начинающие фрилансеры», скажем так) =)
НЛО прилетело и опубликовало эту надпись здесь
Не уверен, что это комплимент Перлу. Код на пхп обычно ужасен.
Я имею в виду синтаксические конструкции
В любом случае, если на Перле можно писать страшно, это не означает, что нестрашно тупо не написать.
А Вы когда, извиняюсь, последний раз видели PHP в глаза? И чем, допустим вот это: github.com/laravel/framework/blob/master/src/Illuminate/Mail/Mailer.php отличается так сильно от шарпа или джавы (ну за исключением долларов и типизации).
Пол-года назад. Дали систему дистанционного обучения на базе какого-то открытого проекта, сказали исправить мелкий баг.(раскрытость пункта меню не всегда при переходах сохранялась). Глянул в код, пришел в ужас. Хорошо, что удалось спихнуть на коллег — они несколько месяцев с этим мучились.
Писать «как на java» можно, но тогда можно и писать на java, пользуясь всей ее экосистемой с библиотеками, средствами сборки и тп. Возможность за счет самодисциплины или жесткого контроля написать относительно хороший код есть везде. И она не компенсирует легкость, с которой пишется плохой код и изначально кривую экосистему.
PS К тому же я не считаю java (да и C#, хотя знаком с ним только теоретически) хорошим языком. Scala позволяет писать более краткий и выразительный код.
Писать «как на java» можно, но тогда можно и писать на java, пользуясь всей ее экосистемой с библиотеками, средствами сборки и тп. Возможность за счет самодисциплины или жесткого контроля написать относительно хороший код есть везде. И она не компенсирует легкость, с которой пишется плохой код и изначально кривую экосистему.
PS К тому же я не считаю java (да и C#, хотя знаком с ним только теоретически) хорошим языком. Scala позволяет писать более краткий и выразительный код.
Все знакомые из Яндекса говорили, что там используются три языка — js, python и C++. Обнаружить столько поклонников Perl было неожиданно :-). Сам использую Perl для программ не длиннее 20 строк. А часто из одной строки, запускаемой из vim или с помощью perl -e. В этой области Perl не превзойден.
Еще очень радует интерес к Rust. Я тоже считаю, что за ним будущее.
А Haskell, по моему, недооценили. Когда его знаешь, для многих задач он оказывается неожиданно удобным языком.
Обнаружил у себя странный критерий — если язык требует для возврата значения писать return (или его аналог, хотя эффект слабее :-) ), он мне не симпатичен, а если не обязательно, то язык приятен. Пока исключение только одно — Паскаль :-).
Еще очень радует интерес к Rust. Я тоже считаю, что за ним будущее.
А Haskell, по моему, недооценили. Когда его знаешь, для многих задач он оказывается неожиданно удобным языком.
Обнаружил у себя странный критерий — если язык требует для возврата значения писать return (или его аналог, хотя эффект слабее :-) ), он мне не симпатичен, а если не обязательно, то язык приятен. Пока исключение только одно — Паскаль :-).
Любил да и люблю тайной любовью С++, хотя, по правде говоря, уже лет так 10 на нем ничего не писал. Одно время прототипировал на плюсах, но потом как-то все больше в С# подался, иногда балуясь Python, но любимым на данный момент является Java. Все свои проектики, особенно десктопные, делаю на Java. Думал подключать скалу, но после выхода Java8, пока сильной необходимости в Скале не вижу (в своих проектах), но как говорится «это только пока». Вот такие вот пироги.
Нда… Вроде «Rндекс», большая компания — не ожидал увидеть столько мракобесия — гик на гике с патологическим вывихом мозга и оттого странными предпочтениями в языках. Далдонят как мантру «скорость, С++» (при этом умудряются *овнокодить на Пестоне), а на дворе уже 21 век — не заметили, сердешные, что выжимать уже надо не байтами, а многопроцессорностью и времени на возню в С++ нет — писать надо быстро, масштабируемо и предсказуемо. То есть на C#. :) (люди повыше рангом — на Nemerle)
А в 21 веке хвалить Jaбу — это чистый пример «парадокса блаба» (гуглите).
Про С++ правильно сказали только одно: «Это плохой молоток, плохой нож, плохая ложка, плохая вилка, плохой штопор и так далее». ППКС.
А в 21 веке хвалить Jaбу — это чистый пример «парадокса блаба» (гуглите).
Про С++ правильно сказали только одно: «Это плохой молоток, плохой нож, плохая ложка, плохая вилка, плохой штопор и так далее». ППКС.
Ну да, Яндекс-то весь на ноуте у Воложа на шкафу работает, какая там многопроцессорность :)
Ключевое слово — «С++», атавизм похуже перфокарт.
А вы представьте, что владеете компанией, для которой машинное время стоит в 10 раз дороже программистского. На чем будете писать?
Компиляторы C++ неторопливые. Придется какой-нибудь oberon выбрать…
Это что за машина такая? Золотой арифмометр, у которого ручку крутит Путин? Тогда да, бесценно. А так даже гугловские облака — дешевле грязи, о каком «дорогом машинном времени» речь?? Сейчас даже у стодолларового телефона 4(!!!) ядра!
Попробуйте себе представить, например, 100000 машин, выполняющих ваш код. Если мы не используем атавизмы, а пишем на каком-нибудь новом модном языке, это количество надо умножить примерно в 2—2.5 раза.А теперь считайте, во сколько вам обойдётся питание дополнительных 100к—150к машин, линии питания и охлаждения в датацентре (так и быть, будем для простоты считать, что нам не придётся строить 1-2 дополнительных датацентра), зарплата дополнительных инженеров, которые будут эти машины обслуживать, само обслуживание серверов — при таких количествах каждый день обязательно несколько машин выходят из строя.
Попробуйте прикинуть всё это с числами, тщательно всё просуммировать, сравнить с собственной зарплатой программиста, и если вдруг у вас получится, что программист обходится дороже, то, думаю, можете смело идти строить ЦОДы и организовывать свой AWS.
Попробуйте прикинуть всё это с числами, тщательно всё просуммировать, сравнить с собственной зарплатой программиста, и если вдруг у вас получится, что программист обходится дороже, то, думаю, можете смело идти строить ЦОДы и организовывать свой AWS.
Вы когда нолики набирали, у вас палец застрял :)
1. Даже по официальным данным (которые яндексу имеет смысл завышать) у них всего 10,000 серверов. Очевидно, что не все из них даже в единой сети, а уж отдельно поиском занимается ограниченное к-во машин.
2. Не надо ничего умножать, всё гораздо проще: есть одна машина, которая тянет на 80%. Её хватает для задач, но для надёжности её масштабируют ещё.
То, что C# как «дробилка» слабже C++ — я полностью согласен, но «слабже» вовсе не означает двукратный проигрыш и аналогичное требуемое оборудование — там всё же не числа умножают, а делают поиск по текстам — совсем другая задача. Вполне жизненным может быть вариант, когда два С++ сервера загружены каждый на 20%, а три C# сервера — на 40% — это очень хорошие показатели, при которых стоимость разработки — точно ниже, а нагрузка — _приемлемая_ для их задач.
1. Даже по официальным данным (которые яндексу имеет смысл завышать) у них всего 10,000 серверов. Очевидно, что не все из них даже в единой сети, а уж отдельно поиском занимается ограниченное к-во машин.
2. Не надо ничего умножать, всё гораздо проще: есть одна машина, которая тянет на 80%. Её хватает для задач, но для надёжности её масштабируют ещё.
То, что C# как «дробилка» слабже C++ — я полностью согласен, но «слабже» вовсе не означает двукратный проигрыш и аналогичное требуемое оборудование — там всё же не числа умножают, а делают поиск по текстам — совсем другая задача. Вполне жизненным может быть вариант, когда два С++ сервера загружены каждый на 20%, а три C# сервера — на 40% — это очень хорошие показатели, при которых стоимость разработки — точно ниже, а нагрузка — _приемлемая_ для их задач.
Из всей статьи, Вы не смогли вынести главного — для своей цели, свой инструмент.
Странно, что вы вообще нашли в статье «цели» — или вы смело отождествили должности с тем, что конкретно пишут на упомянутых языках? Смело, но недостаточно, чтобы здесь умничать.
Кроме того, одно и то же можно написать на многих языках, вплоть до экзотических (тем же Рефалом спокойно обрабатываются тексты). Но если в мэйнстриме я увижу что-то рефалоподобное, этот проект умрёт для меня навсегда — потому что до некоторых яйцеголовых не доходит, что цель — одна, но путей и факторов оценки этих путей — много. «Скорость» — важное, но не самое главное в долгосрочных проектах — куда больше там важна устойчивость (тут С++ сливает на раз), сопровождаемость (вообще с С++ не подходи), лёгкость найма опытных разработчиков (а не клепателей классов по паттернам с неделей применения boost) и т.п. Будь у школоты побольше опыта, она б не фапала на свой С++ как Кихот на Дульсинею — в реальной жизни есть много чего, до чего они ещё не доросли — прощу уж им их штопаные минусы.
Кроме того, одно и то же можно написать на многих языках, вплоть до экзотических (тем же Рефалом спокойно обрабатываются тексты). Но если в мэйнстриме я увижу что-то рефалоподобное, этот проект умрёт для меня навсегда — потому что до некоторых яйцеголовых не доходит, что цель — одна, но путей и факторов оценки этих путей — много. «Скорость» — важное, но не самое главное в долгосрочных проектах — куда больше там важна устойчивость (тут С++ сливает на раз), сопровождаемость (вообще с С++ не подходи), лёгкость найма опытных разработчиков (а не клепателей классов по паттернам с неделей применения boost) и т.п. Будь у школоты побольше опыта, она б не фапала на свой С++ как Кихот на Дульсинею — в реальной жизни есть много чего, до чего они ещё не доросли — прощу уж им их штопаные минусы.
1) Умерьте свой пыл.
2) Не понимаю, как
У Вас явно где-то жирный пункт по поводу C++. В Intel и NVIDIA точно дураки работают, раз делают это и это. Им срочно нужно донести, что
3)Я прекрасно понимаю программиста, который выбрал для разработки бизнес-приложения Java/C#. Я так же прекрасно понимаю программиста, который выбрал С/С++/Fortran для разработки приложения реального времени. И я не утверждаю, что менять местами нельзя. Инструмент — это не только язык, но и инфраструктура, связанная с ним. Так о чем Вы хотели поспорить?
2) Не понимаю, как
для своей цели, свой инструментпротиворечит
одно и то же можно написать на многих языках, вплоть до экзотических? В статье явно и неявно упоминают (в очередной раз), что язык — это инструмент. Или Вы по диагонали прочли?
У Вас явно где-то жирный пункт по поводу C++. В Intel и NVIDIA точно дураки работают, раз делают это и это. Им срочно нужно донести, что
«С++», атавизм похуже перфокарт. Я привел в пример только то, чем сам пользовался.
3)Я прекрасно понимаю программиста, который выбрал для разработки бизнес-приложения Java/C#. Я так же прекрасно понимаю программиста, который выбрал С/С++/Fortran для разработки приложения реального времени. И я не утверждаю, что менять местами нельзя. Инструмент — это не только язык, но и инфраструктура, связанная с ним. Так о чем Вы хотели поспорить?
С вами вообще никто не хотел спорить — после слов «Из всей статьи, Вы не смогли...» я слышу лишь пижонство. Нравится С++ — ради бога, могу подарить дискеты, чтобы хранить заголовочники. Мне больше нравится прогрессивный подход — использовать новейшие разработки, тем более, что они позволяют с лёгкостью заменить С++ во многих местах. Думаю, Тындекс — не исключение, С++ там — лишь исторически сложившийся факт.
— Теперь выбери себе язык программирования. Ты почувствуешь его. Если и он выберет тебя, действуй быстро. У тебя одна попытка, %username%.
— А как понять, что он меня выбрал?
— Он захочет тебя убить.
— А как понять, что он меня выбрал?
— Он захочет тебя убить.
Python, Java, Perl… Специфика Яндекса понятна, это в основном серверное и веб-программирование.
А вот кто сможет назвать язык для создания хороших десктопных Rich GUI приложений? C# понятно, а если без привязки к .NET? Чистый C++ не предлагать, слишком уж он низкоуровневый для написания нормальных прикладных вещей «для пользователя». Я бы предложил Delphi (из-за нелюбви к Delphi просьба не минусовать).
А вот кто сможет назвать язык для создания хороших десктопных Rich GUI приложений? C# понятно, а если без привязки к .NET? Чистый C++ не предлагать, слишком уж он низкоуровневый для написания нормальных прикладных вещей «для пользователя». Я бы предложил Delphi (из-за нелюбви к Delphi просьба не минусовать).
А Java со свингом не подходит почему? Ну или Qt…
D + куча ГУЁвых библиотек.
Создание rich GUI требует от платформы таких возможностей (сугубо имхо):
1. Большой выбор разнообразных готовых контролов
2. Возможность кастомизовать их (другая иконка у чекбокса, разноцветные строки в листбоксе)
3. Создавать свои контролы (например, дерево, элемент которого — выпадающий список).
4. Чтобы в итоге это все хорошо выглядело на разных разрешениях.
5. Чтобы в итоге это еще и быстро работало (т.е. желательно аппаратное ускорение графики).
6. Четкое отделение UI от кода (иначе они срастаются, и править становится тяжело).
7. Возможность делать современные эффекты и анимации.
Кроме WPF что позволяет хотя бы половину? Попробуйте на Qt сделать сложный контрол, сколько уйдет на это времени? Единственное что-то подобное WPF, что попадалось на глаза — это FireMonkey, но я об этой технологии почти ничего не знаю.
1. Большой выбор разнообразных готовых контролов
2. Возможность кастомизовать их (другая иконка у чекбокса, разноцветные строки в листбоксе)
3. Создавать свои контролы (например, дерево, элемент которого — выпадающий список).
4. Чтобы в итоге это все хорошо выглядело на разных разрешениях.
5. Чтобы в итоге это еще и быстро работало (т.е. желательно аппаратное ускорение графики).
6. Четкое отделение UI от кода (иначе они срастаются, и править становится тяжело).
7. Возможность делать современные эффекты и анимации.
Кроме WPF что позволяет хотя бы половину? Попробуйте на Qt сделать сложный контрол, сколько уйдет на это времени? Единственное что-то подобное WPF, что попадалось на глаза — это FireMonkey, но я об этой технологии почти ничего не знаю.
Четкое отделение UI от кода
И много вы в WPF «наотделяли»? Скажу вам по секрету, мания «отделять» — не самое важное в производстве программ. Хуже того — т.н. «логика» — это не только бизнес-правила, но и логика работы самих ГУЁв! Её вы куда собрались отделять? Более того — «логики» не существует самой по себе, она так или иначе завязана на бизнес-сущности. Так что всё это «отделение» — тупой баззворд, кто реально пишет программы, тот не гемороится сверх необходимого. Надо «покупателя» с методами — пожалуйста, но если в форме есть сотня методов для поддержки этой формы (и они, само собой, используют «покупателя») — я так их прямо и напишу.
Кратко, возможности WPF по написанию качественного UI — ни на грош не лучше WinForms, разве что в простейших случаях кастомайзятся полегче.
Чтобы в итоге это еще и быстро работало
Это такая шутка что ли? WPF — тормознутое чучело по сравнению с любым самым навороченным UI на WinForms.
И много вы в 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 (который даже рядом не поставить, это технологии разных технологических поколений) — это даже не кастомайз контролов, а связывание данных, позволяющее совершенно иначе (более гибко) строить архитектуру приложения.
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'ам, а уж про скорость и говорить нечего.
> Про тормоза WPF — пруфлинк, пожалуйста
Вообще оборзели что ли от лени? Гугл перед носом, набери «WPF тормозит» и хоть упруфайся.
> Основное преимущество WPF… связывание данных, позволяющее совершенно иначе…
Ну то, что в XML засунули совершенно гетерогенный «язык связей» — да, но это ещё не делает технологию лучше. Если надо связать свойство item.Price с пргрессбаром.Progress — это можно делать и в WinForms, но когда идут сложные байндинги к шаблонам и подэлементам, там вообще хоть вешайся! «Лучшим» я это никак не могу назвать, скорее «универсально неудобным».
Пока что WinForms по простоте и сопровождаемости (ключевые факторы в мэйнстриме) даёт фору всяким WPF'ам, а уж про скорость и говорить нечего.
MVVM, или в общем случае разделение ответственности по классам/модулям/слоям с уменьшением их связности — это не моя парадигма, а фундаментальные основы объектно-ориентированного дизайна. Дело не только в том, что это общепринятое правило хорошего тона в разработке. Дело в том, что это работает. И вытекает из здравого смысла, из самых общий соображений, применимых в любой инженерной задаче. А то, что не нужно быть фанатиком, и не следовать концепции ради концепции — это любой адекватный человек понимает. Есть ряд вещей, которые сделать через MVVM довольно тяжко, и того просто не стоит. Беда в том, что эту довольно-таки капитанскую истину вы почему-то доказываете с бурей эмоций, обвиняя в самоуверенности — даже смешно становится.
wpf тормозит — вбил, и что? Если у кого-то кривые руки, это не проблема технологии. В наших продуктах ничего не тормозит.
Сопровождаемость WinForms? Представьте, что заказчик захотел часть функционала видеть в web-интерфейсе, а еще часть логики нужно связать с шиной данных. В WPF у одной модели может быть сколько угодно вьюмоделей, а у каждой из них — сколько угодно вьюх. Ваш код на WinForms будет проще (но дороже) переписать с нуля, коли «разделением» вы особо не занимаетесь.
wpf тормозит — вбил, и что? Если у кого-то кривые руки, это не проблема технологии. В наших продуктах ничего не тормозит.
Сопровождаемость WinForms? Представьте, что заказчик захотел часть функционала видеть в web-интерфейсе, а еще часть логики нужно связать с шиной данных. В WPF у одной модели может быть сколько угодно вьюмоделей, а у каждой из них — сколько угодно вьюх. Ваш код на WinForms будет проще (но дороже) переписать с нуля, коли «разделением» вы особо не занимаетесь.
Не надо мне рассказывать про «MVVM — это бла-бла...» — я уже написал, что тоже это использую. Игнорирование этого факта выявляет в вас просто «толкателя своего мнения», даже не читающего что ему пишут. Зачем тогда все эти рассыпания в собственной уверенности о непогрешимости WPF? К тому же, я уже дал «задачу поддых» — что, опять замылился разум в толкании своего WPF? Где решение?
И я опять вижу настойчивое бла-бла «WPF — это круто, потому что это MVVM». Это НИ РАЗУ не верно. WPF — гуёвая библиотека, MVVM — архитектура приложения. Причём можно делать MVVM с использованием WinForms (надеюсь, вас не шокировало? Вы устойчиво сидите?).
> wpf тормозит — вбил, и что? Если у кого-то кривые руки…
Ясно. «рашен программашен» — «у меня всё работает, а вы там хоть сдохните!».
> Представьте, что заказчик захотел часть функционала видеть в web-интерфейсе…
Уже ответил. WinForms позволяет точно так же писать с применением MVVM. Я лишь подчёркиваю, что не всё так идеально — «наотделять» много ума не надо, но есть куча именно гуёвой логики, которую «отделить» — целый геморой, задачу выше я уже предложил.
И я опять вижу настойчивое бла-бла «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)
Решается очень просто. В команде родительской вьюмодели создаем дочернюю вьюмодель, передавая в нее все необходимые данные (иногда — просто ссылку на себя), и вызываем сервис, который по вьюмодели автоматом строит вью. Это умеет делать 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, если нужно — играться с памятью на низком уровне. Несбыточная мечта?
Несколько десятилетий активного развития IT-сфера так и не дали нам удобный «швейцарский нож» с острыми лезвиями. Мы пишем на С++ из-за его высокой производительности — но ругаемся на его низкую безопасность, все более тяжелый синтаксис, и низкую скорость разработки на нем. Язык C# — по мне так выразителен как поэзия, за создание WPF Майкрософту можно простить все прошлые грехи — но нет кросс-платформенности. Питон лаконичен, но обладает недостатками, присущими всем языкам с динамической типизацией.
Какой-то заколдованный круг. Я хочу писать на языке с понятным (не Haskell, Rust и пр.) синтаксисом (как C# например), чтобы он был кросс-платформенным, позволял за счет своих стандартных библиотек создавать rich GUI, если нужно — играться с памятью на низком уровне. Несбыточная мечта?
Ну и за что минусы?)
Основа синтаксиса Rust та же, что и в C# — это C-подобные языки.
А чем не понятен синтаксис Haskell? Синткасис простой, с минимумом конструкций, без лишней пунктуации, ориентированный на человека. Семантику понять может быть сложно, но синтаксис.
Хотя сталкивался с ерлангистом, которые жаловался, что отсутствие скобок и запятых делает его непонятным для инженеров-электонщиков — мы тогда спорили, на чем модели микропроцессора писать :-).
А чем не понятен синтаксис Haskell? Синткасис простой, с минимумом конструкций, без лишней пунктуации, ориентированный на человека. Семантику понять может быть сложно, но синтаксис.
Хотя сталкивался с ерлангистом, которые жаловался, что отсутствие скобок и запятых делает его непонятным для инженеров-электонщиков — мы тогда спорили, на чем модели микропроцессора писать :-).
Есть такая фраза: язык — это форма мышления. Думаю, что синтаксис как таковой там не сложный, трудность в том, чтобы перестать мыслить в ОО или процедурном стиле, и видеть решение задачи чисто в функциональном подходе. С ходу сложновато, нужна практика, а ее получить сложно: не вижу проекта, для реализации которого идеально подошел бы функциональный язык, а писать хелло-ворлды не хочется.
Я предположу, что Вы считаете синтаксис непонятным только потому, что недостаточно изучили его или работали с ним.
Думаю, когда Вы только начинали программировать, Вы были в ужасе от синтаксиса C#/C или с чего начинали.
Я вот точно помню — был в шоке и ничего не мог понять в C в программе HelloWorld.
Думаю, когда Вы только начинали программировать, Вы были в ужасе от синтаксиса C#/C или с чего начинали.
Я вот точно помню — был в шоке и ничего не мог понять в C в программе HelloWorld.
Думаю, Вы правы, есть такой момент. Может и не только этот. Заголовок функции в любом С-подобном языке лаконичен донельзя:
в отличии от упомянутых ранее языков нет стрелочек, слова fn и т.п. Для человека хотя бы немного знающего английский, этот код — фактически, выражение намерения на естественном языке (вычислить целочисленный факториал). Из каких-то дополнительных элементов (кроме названий) — только круглые скобки. Связь которых с передачей значения чему-либо всем интуитивно понятна за счет вшитой школьной алгеброй f(x).
int CalcFactorial(int number)
в отличии от упомянутых ранее языков нет стрелочек, слова fn и т.п. Для человека хотя бы немного знающего английский, этот код — фактически, выражение намерения на естественном языке (вычислить целочисленный факториал). Из каких-то дополнительных элементов (кроме названий) — только круглые скобки. Связь которых с передачей значения чему-либо всем интуитивно понятна за счет вшитой школьной алгеброй f(x).
Правда, чем непонятен синтаксис Rust? Типичный синтаксис в стиле C++, синтаксис лямбд, говорят, взят из Ruby. И как раз всё как Вы хотите — безопасный код бесплатно (время жизни и обращение к переменным проверяются на этапе компиляции и в рантайме не тратят ничего), при этом разрешено делать unsafe{} блоки, в которых можно стрелять себе в ногу. Полная кроссплатформенность, кто-то на нём даже загрузчики писал, сейчас coreutils активно разрабатывают.
С GUI, и другими библиотеками пока хуже, но у них как раз появился сейчас менеджер пакетов а-ля npm, и дальше ситуация будет улучшаться.
С GUI, и другими библиотеками пока хуже, но у них как раз появился сейчас менеджер пакетов а-ля npm, и дальше ситуация будет улучшаться.
Про синтаксис ответил комментом выше. А вообще, Вы же понимаете, что для реальной профессиональной разработки
язык != синтаксис языка
язык = синтаксис языка + стандартная библиотека + внешние библиотеки + среда разработки + комьюнити и пр.
Сложно представить, сколько MS вложил в разработку платформы .net. И GUI — для меня это как раз лакмусовая бумажка зрелости платформы. Мне попадались интересные языки, и интерес угасал сразу после ответа на вопрос «а как тут сделать хороший GUI».
Дай Бог, что Rust в этом плане разовьется. Но ведь несколько лет назад то же самое пророчили языку D… А по факту уже годами получается, что нормально делать приложения, с современным UI, можно (с разной степенью удобности) на WPF, Qt и Java, и все(
язык != синтаксис языка
язык = синтаксис языка + стандартная библиотека + внешние библиотеки + среда разработки + комьюнити и пр.
Сложно представить, сколько 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.
Собственно, паскальщикам наверняка будет гораздо привычнее и очевиднее синтаксис Rust.
Народ, вы странные. Конструкции эквипенисуальные. Это как в школьные годы спорить, что лучше — begin/end или {/} (умолчим о том, что фигурные скобки таки победили :-) ).
У меня одна надежда — что дикий Столлман покусает Майкрософт, и дотнет со всеми потрохами окажется в полноценном опенсорсе (а не как сейчас — частично приоткрытый дотнет и закрытый рантайм). Компиляторы шарпа и басика уже там, так что чудеса случаются… Будет опенсорс — будут полноценные порты, а не костыли с подпорками, не будет религиозной неприязни, и вообще мир станет лучше.
Пока что из всех чудес это наиболее реалистичное, потому что МС позарез нужны мобилки, и кросс-платформенность внезапно становится выгодна.
Остальные чудеса совсем далеко: C++ не станет красивым и безопасным языком (давайте добавим 101-й способ прятать указатели — и всё станет зашибись, ну правда?), Java не станет мощным и универсальным языком (свойства? операторы? генераторы? ...указатели?), JavaFX не станет конкурентом WPF (CSS — наше всё), IDE для динамических языков не научатся читать мысли (свойство может быть, может не быть, но я тебе никогда не скажу), Haskel не станет понятным для простых смертных (а значит, непростым смертным не увидеть его на реальных проектах)…
Пока что из всех чудес это наиболее реалистичное, потому что МС позарез нужны мобилки, и кросс-платформенность внезапно становится выгодна.
Остальные чудеса совсем далеко: C++ не станет красивым и безопасным языком (давайте добавим 101-й способ прятать указатели — и всё станет зашибись, ну правда?), Java не станет мощным и универсальным языком (свойства? операторы? генераторы? ...указатели?), JavaFX не станет конкурентом WPF (CSS — наше всё), IDE для динамических языков не научатся читать мысли (свойство может быть, может не быть, но я тебе никогда не скажу), Haskel не станет понятным для простых смертных (а значит, непростым смертным не увидеть его на реальных проектах)…
Автору — спасибо, что не поленились столько людей опросить. Получилась довольно взвешенная картина, и даже холиварить особо не хочется, хотя тема ещё та! :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Какой язык программирования больше всего любят в Яндексе? И всегда ли любовь взаимна