Здравствуйте, bzig, Вы писали:
B>В Скале есть уже 10 лет — не сбежали Хорошо, что есть языки вроде Скалы и Котлина, там можно потренироваться на кошках и взять в Яву то, что действительно нужно и решает проблемы вместо их создания.
Скала -- она не для среднего ума, поэтому народ и не побежал. Я в ее сторону даже не смотрел. И зачем заводить своих кошек, если в шарпе перегрузке уже 20 лет скоро будет и еще никто не жаловался.
Да, а к пропертям и методам расширений претензий нет?
Здравствуйте, sergey2b, Вы писали:
S>web and бэкенд
S>переписать приложение которое я хорошо знаю с плюсов на web
А что именно в вебе придется делать? Перенести логику на C# это одно. А вот прикрутить к ней web UI может вылиться не на переход на C#, а плавание в чудесном мире JS.
Я бы посоветовал сначала понять, как ты будешь делать UI. Перевести бэкенд с С++ на C# скорее всего ты сможешь сходу и при этом разовьешься как разработчик. А вот понравится ли тебе ваять UI на Angular/React/Vue, это большой вопрос. Там совсем отдельный мир.
Кроме C# тебе нужно будет изучить:
1. HTTP, REST и как с ними работает ASP.NET. Это относительно просто, есть спеки и доки.
2. HTML, CSS, хотя бы азы верстки. Там много нюансов в которых можно утонуть. Есть готовые фреймворки, которые, впрочем, тоже нужно изучать.
3. JS и одну из библиотек для UI (я бы сразу отсоветовал angular, но это вкусовщина). Это вообще огромный мир и в целом, не очень некомфортный. Особенно для плюсовика.
Сможешь ли ты погрузиться сразу во все и довести проект до ума, уложившись в разумные сроки, не зная тебя, сказать сложно. Но если по последним трем пунктам нет сейчас опыта хотя бы на троечку — я бы не рискнул.
Момент упущен, а добавлять их сейчас — это как раз именно то создание проблем, которое я упоминал. Много фрэймворков завязано на рефлекшн и добавление новой сущности прокатится волной ошибок. А всё ради чего? Чтобы вместо "bean.setField(value)" писать "bean.field=value" ? Невелик выигрыш
A>и методам расширений претензий нет?
string.myMethod() vs myMethod(string) — вторая запись даже короче Сделают — ок. Не сделают — тоже ок.
Мелко, короче, это всё.
Как человеку 20 лет пишущему на Яве, после лямбд мне не хватает ровно двух вещей для счастья
value types — ну тут вроде уже всё на мази, вопрос времени только
dynamic tuples и tuples decomposition — планов нет пока, к сожалению. С другой стороны, var добавили, а значит дорога к dynamic tuples расчищена. А там глядишь и декомпозицию по пути прихватят.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, rameel, Вы писали:
KP>>>Я всегда считал, это те, кто не осилил ни С++ ни что-то из JVM–мира, ну то есть совсем уж конченые представители мира разработки
R>>
KP>Иш как плющит, если бы мог, то 5 минусов поставил бы, да?
тут минусы не годятся. для таких заявлений нужна кнопка "отлить в граните"
Здравствуйте, Тёмчик, Вы писали:
Тё>Здравствуйте, sergey2b, Вы писали:
S>>да первый пункт, владелец компании фанат виндов Тё> то C# давно труп, ибо MS на него забил болт, как перед тем на com и mfc.
Кто сказал, что С# труп? С# развивается, последняя его версия 7.3 (вышла в мае 2018).
Здравствуйте, bzig, Вы писали:
B>Момент упущен, а добавлять их сейчас — это как раз именно то создание проблем, которое я упоминал. Много фрэймворков завязано на рефлекшн и добавление новой сущности прокатится волной ошибок. А всё ради чего? Чтобы вместо "bean.setField(value)" писать "bean.field=value" ? Невелик выигрыш
Опять таки какие проблемы? Надо только немного сахара в язык добавить, да пометить методы get/set в class-файлах спец. аннотациями.
B>string.myMethod() vs myMethod(string) — вторая запись даже короче Сделают — ок. Не сделают — тоже ок.
А дальше? string.myMethod().myNextMethod() vs myNextMethod(myMethod(string)).
Здравствуйте, amironov79, Вы писали:
A>Здравствуйте, bzig, Вы писали:
B>>Момент упущен, а добавлять их сейчас — это как раз именно то создание проблем, которое я упоминал. Много фрэймворков завязано на рефлекшн и добавление новой сущности прокатится волной ошибок. А всё ради чего? Чтобы вместо "bean.setField(value)" писать "bean.field=value" ? Невелик выигрыш
A>Опять таки какие проблемы? Надо только немного сахара в язык добавить, да пометить методы get/set в class-файлах спец. аннотациями.
B>>string.myMethod() vs myMethod(string) — вторая запись даже короче Сделают — ок. Не сделают — тоже ок.
A>А дальше? string.myMethod().myNextMethod() vs myNextMethod(myMethod(string)).
Здравствуйте, bzig, Вы писали:
A>>А дальше? string.myMethod().myNextMethod() vs myNextMethod(myMethod(string)).
B>Ну неудобно, да. Но всё равно мелко
Ну с такой формулировкой можно к любой фиче языка подойти. Зачем тебе лямбды? Это же мелко: ты объяви функцию снаружи, заполни контекст, да выполняй себе на здоровье. Зачем тебе туплы? Это же тоже мелко: ты объяви класс, нагенери equals и hashCode, да работай с ним. В общем, можно договориться, что и сами классы не нужны, ooc.pdf -- навсегда.
A>Ну с такой формулировкой можно к любой фиче языка подойти. Зачем тебе лямбды? Это же мелко: ты объяви функцию снаружи, заполни контекст, да выполняй себе на здоровье. Зачем тебе туплы? Это же тоже мелко: ты объяви класс, нагенери equals и hashCode, да работай с ним. В общем, можно договориться, что и сами классы не нужны, ooc.pdf -- навсегда.
Всё, что ты перечислил, я использую ежедневно. А вот "method2(method1(value))" было на 99% коллекции, и с потоками необходимость в методах расширения для них отпала. Оставшийся 1% это далеко не ежедневные сценарии. Тоже самое и с арифметикой бигдецимал.
Value type — опять, считай, ежедневно использую коллекции long/int и прочее — куда без них в ентерпрайзе?
Tuples — не такая частая вещь, была бы на уровне extension methods, но в внедрением stream часто возникают сценарии, когда дополнительные значения появляются на одном этапе конвейера, используются на другом, а за пределами не нужны. Сейчас используюся самописные туплы, встроенные были бы приятнее. В конвейере, кстати, начиная с Явы10 уже можно подобие туплов использовать, см. http://rsdn.org/forum/java/7100710.flat
Здравствуйте, bzig, Вы писали:
B>Всё, что ты перечислил, я использую ежедневно. А вот "method2(method1(value))" было на 99% коллекции, и с потоками необходимость в методах расширения для них отпала. Оставшийся 1% это далеко не ежедневные сценарии. Тоже самое и с арифметикой бигдецимал.
В принципе по методам расширений я согласен. За рамками потоков применение у них достаточно ограничено. По пропертям тоже согласен, соглашений по get/set методам хватает. По бигдецимал не согласен, нужна доработка или замена. Иначе как удобно работать с произвольным number из баз данных?
B>Value type — опять, считай, ежедневно использую коллекции long/int и прочее — куда без них в ентерпрайзе?
Здесь не понял. Что за энтерпрайз такой, которому нужны value type? Добавь лучше процессоров и памяти.
B> В конвейере, кстати, начиная с Явы10 уже можно подобие туплов использовать, см. http://rsdn.org/forum/java/7100710.flat