Часто используемых где?) При разработке внутреннего софта компаний, реализующего бизнес-процессы (т.е. Enterprise). Да, где-то WinForms, но все больше WPF (кроме США, у них WPF почему-то не любят). Mono — не очень популярен, имхо. Вы много видели популярных (не внутрекорпоративных) программ на C#? Игры, и другие высокопроизводительные приложения (CAD, обработка видео и пр.) еще как-то понятно почему (и то в умелых руках C# может работать резво). Но берем что угодно другое: редакторы, файловые менеджеры, мессенджеры, почтовые клиенты, утилитки всякие, переводчики, и прочие няшки — все это практически всегда C++ или Delphi. Почему?
Нативная разработка, надеюсь, постепенно уйдет в прошлое. В том смысле, что можно выбрать себе язык + фреймворк, и писать под все платформы. Примерно как сейчас С++ Qt, и с некоторой натяжкой web.
Хороший пример, подтверждающий, что .net (и WPF в частности) — удобная штука. Для меня остается загадкой только одно: почему применение C# до сих пор ограничено практически только одним Enterprise…
В общем спорить больше не собираюсь, отвечу только на ваш вопрос. Посмотрел «задачу поддых». Поверьте, это совершенно не проблема, а типичная ситуация в MVVM. Проблемой она становится тогда, когда люди неправильно применяют WPF, фактически нарушая MVVM. А именно: во вьюмодели родительского окна, в команде, НЕЛЬЗЯ создавать вьюшку дочернего. Вьюмодели не знаю о вьюхах! Они должны знать только друг о друге. И вьюхи друг о друге, но не о вьюмоделях.
Решается очень просто. В команде родительской вьюмодели создаем дочернюю вьюмодель, передавая в нее все необходимые данные (иногда — просто ссылку на себя), и вызываем сервис, который по вьюмодели автоматом строит вью. Это умеет делать Catel, MVVM-фреймворк последнего поколения.
MVVM, или в общем случае разделение ответственности по классам/модулям/слоям с уменьшением их связности — это не моя парадигма, а фундаментальные основы объектно-ориентированного дизайна. Дело не только в том, что это общепринятое правило хорошего тона в разработке. Дело в том, что это работает. И вытекает из здравого смысла, из самых общий соображений, применимых в любой инженерной задаче. А то, что не нужно быть фанатиком, и не следовать концепции ради концепции — это любой адекватный человек понимает. Есть ряд вещей, которые сделать через MVVM довольно тяжко, и того просто не стоит. Беда в том, что эту довольно-таки капитанскую истину вы почему-то доказываете с бурей эмоций, обвиняя в самоуверенности — даже смешно становится.
wpf тормозит — вбил, и что? Если у кого-то кривые руки, это не проблема технологии. В наших продуктах ничего не тормозит.
Сопровождаемость WinForms? Представьте, что заказчик захотел часть функционала видеть в web-интерфейсе, а еще часть логики нужно связать с шиной данных. В WPF у одной модели может быть сколько угодно вьюмоделей, а у каждой из них — сколько угодно вьюх. Ваш код на WinForms будет проще (но дороже) переписать с нуля, коли «разделением» вы особо не занимаетесь.
1. Логика самих «гуёв» часто уходит в codebehind. Суть разделения не в «ui/код», а в «представление данных / обработка данных». Почитайте хотя бы Фаулера, что ли.
2. Логика завязана на бизнес-сущности, да. А в UI нет бизнес-сущностей, там только UI. Все правильно.
3. «Кто реально пишет программы». Ну я, и еще 500 моих коллег департамента исследований и разработки компании 2GIS реально пишем программы. И мы используем исключительно MVVM, вся логика во вьюмодели, весь ui в xaml, иногда немного в codeBehind. Мы все заблуждаемся по-вашему?
4. Про тормоза WPF — пруфлинк, пожалуйста, или демку. То что рендер WPF идет на видеокарте вы знаете? А что она быстрее считает графику, чем CPU, надо объяснять?
Основное преимущество WPF над WinForms (который даже рядом не поставить, это технологии разных технологических поколений) — это даже не кастомайз контролов, а связывание данных, позволяющее совершенно иначе (более гибко) строить архитектуру приложения.
Понятно. Видимо, группа #2 сделала свои выводы по телу функции, так что если говорить про сам заголовок, то есть только группа #1) Возможно, нужно поднять планку: технари, но не программисты.
за эталон берёте C#, который, как и Java, весьма многословен и неочевиден
Думаю, тут уже вопрос вкуса. Для меня код C# — самое понятное, что только можно придумать, кто-то от него плюется. Ну и я не отказываюсь от своих слов про синтаксис. Нам бы взять человека, вообще не знакомого с программированием, и показать, что понятнее: fn factor(n: int) -> int
или int factor(int n)
Про синтаксис ответил комментом выше. А вообще, Вы же понимаете, что для реальной профессиональной разработки
язык != синтаксис языка
язык = синтаксис языка + стандартная библиотека + внешние библиотеки + среда разработки + комьюнити и пр.
Сложно представить, сколько MS вложил в разработку платформы .net. И GUI — для меня это как раз лакмусовая бумажка зрелости платформы. Мне попадались интересные языки, и интерес угасал сразу после ответа на вопрос «а как тут сделать хороший GUI».
Дай Бог, что Rust в этом плане разовьется. Но ведь несколько лет назад то же самое пророчили языку D… А по факту уже годами получается, что нормально делать приложения, с современным UI, можно (с разной степенью удобности) на WPF, Qt и Java, и все(
Думаю, Вы правы, есть такой момент. Может и не только этот. Заголовок функции в любом С-подобном языке лаконичен донельзя: int CalcFactorial(int number)
в отличии от упомянутых ранее языков нет стрелочек, слова fn и т.п. Для человека хотя бы немного знающего английский, этот код — фактически, выражение намерения на естественном языке (вычислить целочисленный факториал). Из каких-то дополнительных элементов (кроме названий) — только круглые скобки. Связь которых с передачей значения чему-либо всем интуитивно понятна за счет вшитой школьной алгеброй f(x).
Есть такая фраза: язык — это форма мышления. Думаю, что синтаксис как таковой там не сложный, трудность в том, чтобы перестать мыслить в ОО или процедурном стиле, и видеть решение задачи чисто в функциональном подходе. С ходу сложновато, нужна практика, а ее получить сложно: не вижу проекта, для реализации которого идеально подошел бы функциональный язык, а писать хелло-ворлды не хочется.
Создание rich GUI требует от платформы таких возможностей (сугубо имхо):
1. Большой выбор разнообразных готовых контролов
2. Возможность кастомизовать их (другая иконка у чекбокса, разноцветные строки в листбоксе)
3. Создавать свои контролы (например, дерево, элемент которого — выпадающий список).
4. Чтобы в итоге это все хорошо выглядело на разных разрешениях.
5. Чтобы в итоге это еще и быстро работало (т.е. желательно аппаратное ускорение графики).
6. Четкое отделение UI от кода (иначе они срастаются, и править становится тяжело).
7. Возможность делать современные эффекты и анимации.
Кроме WPF что позволяет хотя бы половину? Попробуйте на Qt сделать сложный контрол, сколько уйдет на это времени? Единственное что-то подобное WPF, что попадалось на глаза — это FireMonkey, но я об этой технологии почти ничего не знаю.
Печальная картина, друзья.
Несколько десятилетий активного развития IT-сфера так и не дали нам удобный «швейцарский нож» с острыми лезвиями. Мы пишем на С++ из-за его высокой производительности — но ругаемся на его низкую безопасность, все более тяжелый синтаксис, и низкую скорость разработки на нем. Язык C# — по мне так выразителен как поэзия, за создание WPF Майкрософту можно простить все прошлые грехи — но нет кросс-платформенности. Питон лаконичен, но обладает недостатками, присущими всем языкам с динамической типизацией.
Какой-то заколдованный круг. Я хочу писать на языке с понятным (не Haskell, Rust и пр.) синтаксисом (как C# например), чтобы он был кросс-платформенным, позволял за счет своих стандартных библиотек создавать rich GUI, если нужно — играться с памятью на низком уровне. Несбыточная мечта?
В этом комментарии я описал «попсовое» преподнесение парадокса близнецов, дающее неправильное понимание СТО, и вызывающие вопросы (которые у меня и возникли).
Ну в принципе да, поскольку от них я не смог добиться того, что услышал в некоторых комментариях здесь (Вашем в том числе). Просто и понято. Думаю, что эти объяснения оказались полезными не только мне, но и другим читателям статьи (не участвующим в обсуждении). Сумма человеческого разума увеличилась, правда, ценою моей кармы и заминусованных комментариев. Ну да ладно. Спасибо за ссылки.
Обычно ПБ описывают в популярной литературе так: второй брат (летящий на звездолете) стареет медленнее из-за замедления времени, вызванного околосветовой скоростью движения корабля. В общем-то и все. Ни слова о том, что пока корабль движется без ускорения эти системы отсчета равноправны, и замедление времени симметрично: с точки зрения корабля на Земле время замедлено, с точки зрения Земли — наоборот, на корабле. Как я понимаю, разница (в итоге приводящая к тому, что при встрече брат-космонавт будет все-таки старее) возникает из-за ускорения, т.к. кораблю сначала нужно разогнаться, потом затормозить.
Мне не понятно только одно. Вычисляя степень «сдвига во времени» мы будем оперировать длительностью полета (например, 10 лет корабль летел с 0.999С), а ускорение в этом расчете не участвует (хотя именно оно и вносит асимметрию). Кораблю нужен год на ускорение, год на торможение, допустим. А между ними он либо год, либо 10, либо 50 лет будет лететь — ведь будет разная степень «сдвига» в итоге.
Решается очень просто. В команде родительской вьюмодели создаем дочернюю вьюмодель, передавая в нее все необходимые данные (иногда — просто ссылку на себя), и вызываем сервис, который по вьюмодели автоматом строит вью. Это умеет делать Catel, MVVM-фреймворк последнего поколения.
Мой видеоурок на эту тему: http://www.youtube.com/watch?v=qAktu1eGGa8
И код из видео: https://github.com/TimeCoder/DotNet/blob/master/src/BooksLibrary/ViewModels/MainViewModel.cs (строка 88)
wpf тормозит — вбил, и что? Если у кого-то кривые руки, это не проблема технологии. В наших продуктах ничего не тормозит.
Сопровождаемость WinForms? Представьте, что заказчик захотел часть функционала видеть в web-интерфейсе, а еще часть логики нужно связать с шиной данных. В WPF у одной модели может быть сколько угодно вьюмоделей, а у каждой из них — сколько угодно вьюх. Ваш код на WinForms будет проще (но дороже) переписать с нуля, коли «разделением» вы особо не занимаетесь.
1. Логика самих «гуёв» часто уходит в codebehind. Суть разделения не в «ui/код», а в «представление данных / обработка данных». Почитайте хотя бы Фаулера, что ли.
2. Логика завязана на бизнес-сущности, да. А в UI нет бизнес-сущностей, там только UI. Все правильно.
3. «Кто реально пишет программы». Ну я, и еще 500 моих коллег департамента исследований и разработки компании 2GIS реально пишем программы. И мы используем исключительно MVVM, вся логика во вьюмодели, весь ui в xaml, иногда немного в codeBehind. Мы все заблуждаемся по-вашему?
4. Про тормоза WPF — пруфлинк, пожалуйста, или демку. То что рендер WPF идет на видеокарте вы знаете? А что она быстрее считает графику, чем CPU, надо объяснять?
Основное преимущество WPF над WinForms (который даже рядом не поставить, это технологии разных технологических поколений) — это даже не кастомайз контролов, а связывание данных, позволяющее совершенно иначе (более гибко) строить архитектуру приложения.
fn factor(n: int) -> intили
int factor(int n)язык != синтаксис языка
язык = синтаксис языка + стандартная библиотека + внешние библиотеки + среда разработки + комьюнити и пр.
Сложно представить, сколько MS вложил в разработку платформы .net. И GUI — для меня это как раз лакмусовая бумажка зрелости платформы. Мне попадались интересные языки, и интерес угасал сразу после ответа на вопрос «а как тут сделать хороший GUI».
Дай Бог, что Rust в этом плане разовьется. Но ведь несколько лет назад то же самое пророчили языку D… А по факту уже годами получается, что нормально делать приложения, с современным UI, можно (с разной степенью удобности) на WPF, Qt и Java, и все(
int CalcFactorial(int number)в отличии от упомянутых ранее языков нет стрелочек, слова fn и т.п. Для человека хотя бы немного знающего английский, этот код — фактически, выражение намерения на естественном языке (вычислить целочисленный факториал). Из каких-то дополнительных элементов (кроме названий) — только круглые скобки. Связь которых с передачей значения чему-либо всем интуитивно понятна за счет вшитой школьной алгеброй f(x).
1. Большой выбор разнообразных готовых контролов
2. Возможность кастомизовать их (другая иконка у чекбокса, разноцветные строки в листбоксе)
3. Создавать свои контролы (например, дерево, элемент которого — выпадающий список).
4. Чтобы в итоге это все хорошо выглядело на разных разрешениях.
5. Чтобы в итоге это еще и быстро работало (т.е. желательно аппаратное ускорение графики).
6. Четкое отделение UI от кода (иначе они срастаются, и править становится тяжело).
7. Возможность делать современные эффекты и анимации.
Кроме WPF что позволяет хотя бы половину? Попробуйте на Qt сделать сложный контрол, сколько уйдет на это времени? Единственное что-то подобное WPF, что попадалось на глаза — это FireMonkey, но я об этой технологии почти ничего не знаю.
Несколько десятилетий активного развития IT-сфера так и не дали нам удобный «швейцарский нож» с острыми лезвиями. Мы пишем на С++ из-за его высокой производительности — но ругаемся на его низкую безопасность, все более тяжелый синтаксис, и низкую скорость разработки на нем. Язык C# — по мне так выразителен как поэзия, за создание WPF Майкрософту можно простить все прошлые грехи — но нет кросс-платформенности. Питон лаконичен, но обладает недостатками, присущими всем языкам с динамической типизацией.
Какой-то заколдованный круг. Я хочу писать на языке с понятным (не Haskell, Rust и пр.) синтаксисом (как C# например), чтобы он был кросс-платформенным, позволял за счет своих стандартных библиотек создавать rich GUI, если нужно — играться с памятью на низком уровне. Несбыточная мечта?
Мне не понятно только одно. Вычисляя степень «сдвига во времени» мы будем оперировать длительностью полета (например, 10 лет корабль летел с 0.999С), а ускорение в этом расчете не участвует (хотя именно оно и вносит асимметрию). Кораблю нужен год на ускорение, год на торможение, допустим. А между ними он либо год, либо 10, либо 50 лет будет лететь — ведь будет разная степень «сдвига» в итоге.