Re[10]: стоит ли переходить на С#
От: amironov79  
Дата: 11.12.18 04:44
Оценка:
Здравствуйте, bzig, Вы писали:

B>В Скале есть уже 10 лет — не сбежали Хорошо, что есть языки вроде Скалы и Котлина, там можно потренироваться на кошках и взять в Яву то, что действительно нужно и решает проблемы вместо их создания.


Скала -- она не для среднего ума, поэтому народ и не побежал. Я в ее сторону даже не смотрел. И зачем заводить своих кошек, если в шарпе перегрузке уже 20 лет скоро будет и еще никто не жаловался.

Да, а к пропертям и методам расширений претензий нет?
Re[3]: стоит ли переходить на С#
От: Ziaw Россия  
Дата: 11.12.18 05:13
Оценка:
Здравствуйте, 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, но это вкусовщина). Это вообще огромный мир и в целом, не очень некомфортный. Особенно для плюсовика.

Сможешь ли ты погрузиться сразу во все и довести проект до ума, уложившись в разумные сроки, не зная тебя, сказать сложно. Но если по последним трем пунктам нет сейчас опыта хотя бы на троечку — я бы не рискнул.
Re[11]: стоит ли переходить на С#
От: bzig  
Дата: 11.12.18 13:38
Оценка: -1
A>Да, а к пропертям

Момент упущен, а добавлять их сейчас — это как раз именно то создание проблем, которое я упоминал. Много фрэймворков завязано на рефлекшн и добавление новой сущности прокатится волной ошибок. А всё ради чего? Чтобы вместо "bean.setField(value)" писать "bean.field=value" ? Невелик выигрыш

A>и методам расширений претензий нет?


string.myMethod() vs myMethod(string) — вторая запись даже короче Сделают — ок. Не сделают — тоже ок.

Мелко, короче, это всё.

Как человеку 20 лет пишущему на Яве, после лямбд мне не хватает ровно двух вещей для счастья

value types — ну тут вроде уже всё на мази, вопрос времени только
dynamic tuples и tuples decomposition — планов нет пока, к сожалению. С другой стороны, var добавили, а значит дорога к dynamic tuples расчищена. А там глядишь и декомпозицию по пути прихватят.
Re[6]: стоит ли переходить на С#
От: MaxRos  
Дата: 11.12.18 15:32
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP>Здравствуйте, rameel, Вы писали:


KP>>>Я всегда считал, это те, кто не осилил ни С++ ни что-то из JVM–мира, ну то есть совсем уж конченые представители мира разработки


R>>


KP>Иш как плющит, если бы мог, то 5 минусов поставил бы, да?


тут минусы не годятся. для таких заявлений нужна кнопка "отлить в граните"
Re[4]: стоит ли переходить на С#
От: Egorio Россия  
Дата: 11.12.18 15:55
Оценка:
Здравствуйте, Тёмчик, Вы писали:

Тё>Здравствуйте, sergey2b, Вы писали:


S>>да первый пункт, владелец компании фанат виндов

Тё> то C# давно труп, ибо MS на него забил болт, как перед тем на com и mfc.

Кто сказал, что С# труп? С# развивается, последняя его версия 7.3 (вышла в мае 2018).
Re[12]: стоит ли переходить на С#
От: amironov79  
Дата: 12.12.18 04:32
Оценка:
Здравствуйте, bzig, Вы писали:

B>Момент упущен, а добавлять их сейчас — это как раз именно то создание проблем, которое я упоминал. Много фрэймворков завязано на рефлекшн и добавление новой сущности прокатится волной ошибок. А всё ради чего? Чтобы вместо "bean.setField(value)" писать "bean.field=value" ? Невелик выигрыш


Опять таки какие проблемы? Надо только немного сахара в язык добавить, да пометить методы get/set в class-файлах спец. аннотациями.

B>string.myMethod() vs myMethod(string) — вторая запись даже короче Сделают — ок. Не сделают — тоже ок.


А дальше? string.myMethod().myNextMethod() vs myNextMethod(myMethod(string)).
Re[13]: стоит ли переходить на С#
От: bzig  
Дата: 12.12.18 13:31
Оценка:
Здравствуйте, 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)).


Ну неудобно, да. Но всё равно мелко
Re[14]: стоит ли переходить на С#
От: amironov79  
Дата: 13.12.18 07:19
Оценка:
Здравствуйте, bzig, Вы писали:

A>>А дальше? string.myMethod().myNextMethod() vs myNextMethod(myMethod(string)).


B>Ну неудобно, да. Но всё равно мелко


Ну с такой формулировкой можно к любой фиче языка подойти. Зачем тебе лямбды? Это же мелко: ты объяви функцию снаружи, заполни контекст, да выполняй себе на здоровье. Зачем тебе туплы? Это же тоже мелко: ты объяви класс, нагенери equals и hashCode, да работай с ним. В общем, можно договориться, что и сами классы не нужны, ooc.pdf -- навсегда.
Re[15]: стоит ли переходить на С#
От: bzig  
Дата: 13.12.18 14:22
Оценка:
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
Дата: 02.04.18
Re[16]: стоит ли переходить на С#
От: amironov79  
Дата: 14.12.18 05:07
Оценка:
Здравствуйте, 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
Автор: bzig
Дата: 02.04.18


Интересно, но мне совсем недавно только 8-ую яву подвезли, о 10-ой и не мечтаю. До этого вообще 1.4 была, но слава Retrotranslator, писал для 6-ой.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.