LINUX.ORG.RU

Python vs C#

 ,


0

6

Подскажите, что на ваш взгляд проще для изучения новичку Python или C#? А может вообще С++ (Чтобы раз ввязался, то на перспективу)? Цель, можно так сказать в параллель: реализация методик в программе и для тестирования программ. Читал, что именно для тестирования подходит Phyton, но если его применять для программ, то с окнами целый геморрой, замучаешься их описывать. Но при этом вроде как и С# используют.


Ответ на: комментарий от Midael

Датасаенс - в большей степени исторически из за сложившейся экосистемы.

Нет, там не исторические причины, а то что надо быстро разнородные данные в разных задачах разово обрабатывать. Т.е. по факту прототипирование и пофиг что медленно работает - один раз написал за неделю ещё неделю/месяц скрипт пошуршал и готово. А на каких-то крестах ты будешь 2 месяца с байтами любовью заниматься и потом оно будет 6 дней работать вместо недели (диски то всё равно тут быстрее работать не могут). Вот и выходит что без питона неудобно такие задачи решать. Всё остальное оверкилл. А дальше нежелание 2 языка использовать (обработка и подготовка данных 90% и только 10% само обучение и валидация в плане работы челиков которые этим занимаются, машинное время может иначе быть т.к. куча алгоритмов где надо очень много и долго считать, но писать код на готовых фреймворках быстро) привело к появлению батареек для питона, благо алгоритмы базовые в ML одинаковые без особого разнообразия.

peregrine ★★★★★
()
Ответ на: комментарий от peregrine

Проверкой типов, большие программы на питоне имеют свойство крашится в рантайме

Не надо писать на питоне такие большие программы, он для этого банально не предназначен. Все равно что жаловаться - дескать микроскоп какой то хрупкий, на втором гвозде все линзы вхлам… И кстати (увы) в питон таки завезли аннотирование типов.

Ну и шарп даже без батареек быстрый, почти на уровне C++.

Нет.

Python очень не шустрый

Питон не используют для задач где важна скорость работы, питон используют для задач где важна скорость разработки.

GUI на шарпе тоже лучше

Это мне вообще малоинтересно, у меня сейчас ровно одно GUI приложение, оно на pyqt5 и часть связанная с гуем там самая простая.

AntonI ★★★★★
()
Ответ на: комментарий от AntonI

Питон не используют для задач где важна скорость работы

Когда нужна будет скорость работы, уже будет поздно.

И непонятно, чем современный шарп уступает питону в скорости разработки. Кроме ml не могу придумать областей, где бы стоило рассматривать питон.

amm
()
Ответ на: комментарий от amm

Когда нужна будет скорость работы, уже будет поздно.

Используйте правильную архитектуру и поздно не будет никогда.

И непонятно, чем современный шарп уступает питону в скорости разработки.

Приходится больше букофф писать?

Кроме ml не могу придумать областей, где бы стоило рассматривать питон.

А ML то чем вам всем так упёрся? Что там такого особенного что питон там лучше шарпов, а во всех остальных местах якобы хуже?!

Тут весь тред это мусолят. Скрипты, HPC (кодогенерация, CAS, управление расчетами), прототипирование и т.д. Везде где скорость некритична и проекты небольшие питон рулит.

AntonI ★★★★★
()
Последнее исправление: AntonI (всего исправлений: 2)
Ответ на: комментарий от AntonI

Используйте правильную архитектуру и поздно не будет никогда.

Как архитектура поможет разогнать питон? При прочих равных он все равно будет проигрывать по скорости.

Приходится больше букофф писать?

Закрой блокнот, открой нормальную ide ;) В шарпе сейчас практически и нет лишних букофф, все по делу.

А ML то чем вам всем так упёрся?

Тем что там питон, как оболочка, стандарт де-факто, любой начинающий в этом деле вынужден будет использовать питон.

Везде где скорость некритична и проекты небольшие питон рулит.

Где граница, когда нужно выбросить питон и взять что-то посерьёзнее?

amm
()
Ответ на: комментарий от amm

Как архитектура поможет разогнать питон? При прочих равных он все равно будет проигрывать по скорости.

Правильная архитектура позволит заранее не писать на питоне то что должно работать быстро.

В шарпе сейчас практически и нет лишних букофф, все по делу.

До-до.

Тем что там питон, как оболочка, стандарт де-факто, любой начинающий в этом деле вынужден будет использовать питон.

Вы путаете мокрое и соленое, ну ладно. Кроме ML есть еще области где питон де-факто стандарт интерфейса, например HPC.

Где граница, когда нужно выбросить питон и взять что-то посерьёзнее?

Зависит от области. Там где я работаю эта граница видна очень четко, там где заканчивается питон начинаются плюсы, и шарпам там просто нет места.

Ну почитайте уже тред, все написано раза по три, надоело повторяться.

AntonI ★★★★★
()
Ответ на: комментарий от AntonI

До-до.

Я рад, что ты это понимаешь :)

Кроме ML есть еще области где питон де-факто стандарт интерфейса, например HPC.

То есть кроме клея, что-либо писать на питоне не вариант.

Зависит от области. Там где я работаю эта граница видна очень четко, там где заканчивается питон начинаются плюсы, и шарпам там просто нет места.

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

amm
()
Ответ на: комментарий от amm

Я рад, что ты это понимаешь :)

У Вас сломался парсер сарказма. ЯП со статической типизацией априори будет проигрывать ЯП с утиной типизацией на небольших проектах в многословности и скорости разработки. Это элементарные вещи.

То есть кроме клея, что-либо писать на питоне не вариант.

То есть Вы так и не асилили прочитать тред. Python vs C# (комментарий)

Из озвученных там 5 пунктов к «клею» можно отнести только п4, да и то весьма условно - с тем же успехом можно считать «клеем» любой фронтенд.

зная, что для оптимизации придется падать в плюсы, надо задуматься, стоит ли его вообще рассматривать для начала проекта.

Простите, сколько раз мне придется повторить что все зависит от области, что бы Вы это поняли? High Performance Computing — высокопроизводительные вычисления, какие там к фигам C#/Ява?!!! Там много лет стандартом был фортран, сейчас там стандартом являются плюсы, фортран используется ограниченно и постепенно уходит со сцены. Питон там ДОПОЛНЯЕТ плюсы, причем многие вещи на питоне там оказываются делать гораздо проще и быстрее чем на плюсах. Никакие C# там нафик не уперлись именно в силу их универсальности - они сливают плюсам по скорости и сливают питону по гибкости и скорости разработки.

Для каждой задачи нужен свой инструмент. Узкоспециализированный инструмент ВСЕГДА лучше универсального инструмента в области своей специализации, это аксиома. Именно потому что C# универсальнее питона он и проигрывает питону в некоторых областях.

AntonI ★★★★★
()
Последнее исправление: AntonI (всего исправлений: 1)
Ответ на: комментарий от amm

все по делу.

ой всё

дело такое что реально весь C# буккипинг по делу

по сути вопрос в нотации (см https://en.wikipedia.org/wiki/Iverson_bracket и вокруг Айверсона и почему не так как а вот так как есть)

да даже датаклассы в питоне как желание уменьшать нужный по делу буккипинг

влюбление в инструмент эта же Пигмалионство

qulinxao3 ★★
()
Ответ на: комментарий от amm

Не понятно, почему люди до сих пор считают, что шарп только для винды. Новый dotnet уже скоро получит версию 9, а кроссплатформенный он с первых версий

Что же тут непонятного. Тут я вижу такие причины:

  1. Сам язык никому не нужен. Нужны библиотеки и IDE. С поддержкой библиотек в Linux у dotnet проблемы. Например, ни Windows.Forms, ни WPF, ни даже MAUI не поддерживается.
  2. Mono долго работал над репутацией. Его уже внесли в репозитории. Также внести MonoDevelop. А сейчас после фокусов Microsoft судьба непонятна. А MonoDevelop сто лет не поддерживается и уже не работает. Репутация первой реализации C# подпорчена. Кто же поверит второй?

Соответственно, сейчас dotnet особо не спешат вносить в дистрибутивы. Поэтому и Linux-разработчики относятся к нему с подозрением.

Kogrom
()
Ответ на: комментарий от AntonI

У Вас сломался парсер сарказма

Кто бы говорил :)

ЯП со статической типизацией априори будет проигрывать ЯП с утиной типизацией на небольших проектах в многословности и скорости разработки. Это элементарные вещи.

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

Из озвученных там 5 пунктов к «клею» можно отнести только п4, да и то весьма условно - с тем же успехом можно считать «клеем» любой фронтенд.

По мне так все пять пунктов клей, так как в той или иной степени используют компоненты, реализованные на других языках.

Простите, сколько раз мне придется повторить что все зависит от области, что бы Вы это поняли? High Performance Computing…

Так изначальный вопрос был питон vs шарп, а не питон и плюсы vs шарп. Про HPC вообще ни слова не было.

amm
()
Ответ на: комментарий от amm

вся многословность окупится при отладке.

Зависит от размеров и особенностей проекта. Вы почему то считаете что все проекты одинаковые, это не так.

По мне так все пять пунктов клей, так как в той или иной степени используют компоненты, реализованные на других языках.

Вы точно прочитали все 5 пунктов и поняли что там написано? Какие то компоненты используют только п3 (ограниченно) и п4.

Так изначальный вопрос был питон vs шарп

Чей вопрос?! Нормальные люди используют ЯП для решения каких то конкретных задач, я свой круг задач обрисовал сразу. Вы же начали говорить в общем и весьма абстрактно - «шарп лучше питона везде кроме ML». Ничего что в ML питон только как верхний управляющий слой идет а под капотом там все что угодно крутится? Но Вас это не смущает, зато шаг в сторону и сразу началось - а плюсы мы не рассматриваем.

В общем здесь играем, здесь не играем, здесь рыбу заворачивали.

AntonI ★★★★★
()
Ответ на: комментарий от Kogrom

Сам язык никому не нужен. Нужны библиотеки и IDE.

С библиотеками и ide у dotnet всё в порядке.

С поддержкой библиотек в Linux у dotnet проблемы. Например, ни Windows.Forms, ни WPF, ни даже MAUI не поддерживается.

Кому нужен десктоп в эпоху веба? Ну если очень нужен, то есть Avalonia. А что с десктопом у питона? Тоже не шибко популярен.

Mono…

Его уже давно закопали, и ты отпусти :)

Кто же поверит второй?

Как я понимаю, надо верить третьей? :)

Соответственно, сейчас dotnet особо не спешат вносить в дистрибутивы

В эпоху докера это не нужно.

amm
()
Ответ на: комментарий от Kogrom

А еще иконка микрософта это буэ, кэмэл стайл в наименованиях тоже буэ. Два буэ для одного ЯП который требует установки какой то мутной среды и прочих странных телодвижений это многовато;-)

AntonI ★★★★★
()
Ответ на: комментарий от amm

Мдя… Ваша беда — проецирование особенностей решаемых Вами задач на весь мир. Не надо так делать, мир он очень разнообразный.

AntonI ★★★★★
()
Ответ на: комментарий от AntonI

[facepalm.jpg] Человек не отличает camelCase от PascalCase, при это считает это важным, а рассуждает об удобстве языков. Ладно про типизацию не все знаешь, но нэйминг же это элементарщина.

amm
()
Ответ на: комментарий от amm

Андрей, Вы точно программист? У Вас с логикой вообще как? А с умением читать и понимать написанное?

Вы приходите с утверждением «шарпы лучше питона везде кроме ML».

Я привожу контрпример - «питон лучше шарпов например в HPC».

В отличие от Вас я не говорю что «питон лучше шарпов везде кроме виндовс/b2b/ловли покемонов», я говорю ТОЛЬКО за свою полянку в которой я что то понимаю. Но я могу предположить, что питон будет лучше шарпов еще много где в ситуациях, похожих на те что бывают на моей полянке.

Вы видите принципиальную разницу между Вашей и моей позицией?

AntonI ★★★★★
()
Ответ на: комментарий от AntonI

Вы видите принципиальную разницу между Вашей и моей позицией?

Не вижу: я согласен, что для HPC было бы глупо использовать шарп, так как не найдешь потом общий язык с коллегами. Но если говорить об языке для новичка, то шарп во всех аспектах лучше.

amm
()
Ответ на: комментарий от amm

Вы много учили новичков?

если говорить об языке для новичка, то шарп во всех аспектах лучше.

опять вот этот вселенский размах «во всех аспектах»… список всех аспектов и почему оно лучше.

для HPC было бы глупо использовать шарп, так как не найдешь потом общий язык с коллегами.

Не только поэтому, это причина важная но не единственная. Другие причины я тут озвучивал неоднократно. в т.ч. и Вам.

Знаете Андрей, если Вы хронически игнорируете аргументы оппонента и не в состоянии воспринимать чужие точки зрения, то мне наверное не о чем с Вами больше говорить. Всего хорошего.

AntonI ★★★★★
()
Последнее исправление: AntonI (всего исправлений: 2)
Ответ на: комментарий от amm

С библиотеками и ide у dotnet всё в порядке.

В Windows. Иначе бы эти IDE были названы. Я, например, могу согласиться, что C# по скорости разработки может сравниться с Питоном, но только при использовании Visual Studio. Без этой IDE всё будет не так весело.

Кому нужен десктоп в эпоху веба?

Эпоха веба уже прошла. Сейчас эпоха приложений для смартфона. Тем не менее большинство офисных работников по прежнему пользуются десктопными приложениями для работы.

У питона с GUI всё в порядке. Хочешь стабильности - выбирай Tkinter. Хочешь удобство (и приключений) - выбирай pyQt.

Mono. Его уже давно закопали

У него были какие-то существенные недостатки? Нет. Закопали потому что у него была какая-то независимость от MS.

Как я понимаю, надо верить третьей? :)

Не вижу логики. Если кто-то обманул один раз, то ему не верят и во второй, и в третий. Репутацию долго восстанавливать.

Вообще, можно представить людей, которые используют C# на Linux. Это могут быть какие-то эксцентричные чудаки. Или это могут быть программисты, у которых большая кодовая база на C# и им работодатель внезапно велел переходить на какую-нибудь Астру. В таком случае люди могут пойти на риск, конечно.

Kogrom
()
Ответ на: комментарий от Kogrom

Я вообще не очень понимаю заходов «Для успешной работы на этом ЯП нужна такая то IDE». Если ЯП без IDE неудобен в работе то это в принципе неудобный ЯП.

Это какое то аццкое смешение понятий и подмена понятий. Давайте тогда уже скажем что для успешной работы на этом ЯП нужна такая то железяка с такой то осью и таким то цветом корпуса установленная в такой то конторе в такой то стране…

AntonI ★★★★★
()
Ответ на: комментарий от AntonI

по первому абзацу:

тот же Smalltalk без среды «невозможен»

«+10» лет ренесанса паскаля благадоря феномену Turbo Pascal

да даже ставшее теперь общем местом автодополнение - без которого программирование использующие развесистые деревья имён превращаяется в боль пока испытуемый не становится «экспертом» в именах используемой «библиотеки»

познавательно как исследование «структурных» редакторов (пик начало 80-ых)(тот же АВС проявление веры в эффективность жёсткого редактора ограничивающего пользователя в вариантах допустимого ввода) показало границы излишней специализации

однако всё равно большинство современных нотаций менее удобны без подключения(тем или иным способом) автодополнения

и дело не только в поощерении профанства не знающих окружения без подсказки - дело ещё и в поощерении автодополнением развесистости в именах ( что очень в жабе заметно)

будь меньше автодополнения

J/APL над unicode-алфавитом были более массовыми

qulinxao3 ★★
()
Ответ на: комментарий от qulinxao3

Про smalltalk ничего не скажу (только слышал), про среду - ну вот есть labview или метапрог. Я бы не стал говорить что это прямо вот афигенные ЯП, это очень нишевые вещи.

Про автодополнение - я вот как то без него живу;-) Все эти «кнопка ручки люка башни танка на плацу», да еще в кэмэл-стайле, у меня вызывают острое желание развидеть и бежать. Это IMHO антипаттерн, тут не в написание проблема а в чтении… когда авточтение таких портянок придумают с трансляцией образов прымо в мосг, тогда можно будет говорить;-)

AntonI ★★★★★
()
Ответ на: комментарий от Kogrom

но только при использовании Visual Studio

Есть rider для тех, кому нужно удобно, есть vscode для тех, кому нужно бесплатно. Для питона ide тоже нужно, без него далеко не уедешь.

Сейчас эпоха приложений для смартфона.

В этой нише ни тот, ни другой язык не игроки. Хотя попытки были.

Tkinter

Смишно))

Закопали потому что у него была какая-то независимость от MS.

Какая независимость была у mono? Майки его купили с потрохами, и закрыли только тогда, когда сделали кроссплатформенный dotnet, чтобы не распыляться на поддержку двух реализаций.

Не вижу логики. Если кто-то обманул один раз, то ему не верят и во второй, и в третий. Репутацию долго восстанавливать.

«Третья версия» это про питон :) У шарпа с репутацией как раз всё хорошо: современный sdk без проблем собирает программы двадцатилетней давности. За всё время могу вспомнить только одно ломающее изменение в языке – поменяли замыкание переменной в foreach.

Вообще, можно представить людей, которые используют C# на Linux

Представь себе, такие есть) https://developers.redhat.com/products/dotnet/getting-started

amm
()
Ответ на: комментарий от AntonI

Какой редактор ты используешь? Если заменишь его на ed, ты сохранишь свою продуктивность?

amm
()
Ответ на: комментарий от amm

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

И я о том же. Они поступили как всегда корпорации поступают. А затем они решат, что не нужно распыляться на поддержку версии для Linux. Что их остановит?

современный sdk без проблем собирает программы двадцатилетней давности

Если использовать Windows. Если говорим про Linux, то тот же mono как-то поддерживал Windows.Forms, например, а кроссплатформенный dotnet - не поддерживает.

Представь себе, такие есть)

Ну дружит Red Hat с Microsoft, почему бы двум корпорациям не дружить. Microsoft много с кем дружил, с Нокией, с Гитхабом, с Моно. Умеют.

Kogrom
()
Ответ на: комментарий от AntonI

когда dsl(тот или иной набор язык и библиотек проблемной области) знаком то автодополнение менее значимо

но тут но:

стоимость готовки чела погружённого в «окружение» явно больше чем кидаем «легкообучаемого» с автодополнением на перевес

есть ещё эффект положительной обратной: наличие автодополнения способствует удлинению имён - и при этом не особо способствует сокращению нажатий(т/е подбор имён чтобы дерево было сильноветвящимся за счёт использования почти всего алфавита в первом символе имени(английский достаточно богат для подбора синонимов))

qulinxao3 ★★
()
Ответ на: комментарий от qulinxao3

наличие автодополнения способствует удлинению имён

да, но читать это как?;-)

Хотя у меня профдеформация, у нас самые сложные части кода это численные схемы, в длинных именах это выглядит жутко.

А если там какая то бизнес логика в стиле «если нажата кнопка ручки двери второго заместителя старшего дворника то первому помощнику младшего делопроизводителя необходимо достать красную папку из шестого шкафа» то самое оно наверное…

AntonI ★★★★★
()
Последнее исправление: AntonI (всего исправлений: 1)
Ответ на: комментарий от Kogrom

А затем они решат, что не нужно распыляться на поддержку версии для Linux. Что их остановит?

А что остановит Гвидо, или кто там сейчас, «улучшить» питон в версии 4 так, что придется все переписывать. Сейчас как раз поднимается тема с выпиливанием gil, думаешь все гладко пройдет?

Если использовать Windows. Если говорим про Linux, то тот же mono как-то поддерживал Windows.Forms, например, а кроссплатформенный dotnet - не поддерживает.

Потому что в линуксах винформс никому не нужен. Если же брать легаси приложения, то на виндах там все в порядке. Если хочешь мигрировать на линуксы и маки, то визуальную часть придется переписывать, другого никто не обещал.

amm
()
Ответ на: комментарий от bread

сам то читал SICP? Где и в каком языке есть синтаксическая абстракция и на примере самого языка можно легко реализовать компилятор этого языка в виртуальную машину на самом же языке?

lovesan ★★
()

Вообще чтобы научиться программировать, надо брать SICP, HtDP итд, и там схема конечно, но это вторично, т.е. вообще язык.

Выучить любой язык когда понимаешь как всё это устроено - дело пары недель от силы, потом будешь потихоньку грабли доучивать.

Программирование вообще не про языки, и не про библиотеки даже. Надо понимать довольно глубокие концепции и уметь строить в голове сложные абстрактные процессы. Да, научиться этому это не 1 день и не месяц.

А кто херак-херак и на каком-нибудь говноязыке только и умеет говно клепать, так у таких вон скоро ЗП с ЗП дворника сравняется, ну в Москве точно, по крайней мере. Смысл тогда идти в разработку? Плюс, в IT кризис вообще, бюджеты режутся и васянов-говнокодеров в нормальные компании уже стараются не брать

lovesan ★★
()
Ответ на: комментарий от Kogrom

С поддержкой библиотек в Linux у dotnet проблемы.

Они завязаны на винду и ЧИСТО виндовые фичи, вот те либы что ты перечислил. Сделай сначала под линукс интегрированный графический стек, Direct3D+Direct2D+DirectWrite, мультимедиа со всем этим интегрированное и так далее. Потом, OLE/COM для интеропа со всем десктопом, начиная с оболочки, и все остальное. А там может сама MS подтянется и сделает тебе WPF.

Есть Avalonia, но вообще в линуксе и так с GUI огромные проблемы, у любой платформы.

все остальное работает без проблем, начиная там с веб-фреймворков типа Asp .Net и заканчивая каким-нибудь NPOI для работы с документами офиса

lovesan ★★
()
Ответ на: комментарий от Kogrom

но только при использовании Visual Studio

Студия это эталонная IDE вообще. В линуксомирке нету и близкого аналога ни для чего вообще. Но люди вон Rider-ом справляются и даже vscode.

Вообще, можно представить людей, которые используют C# на Linux.

Любой веб на дотнете запускается щас на линуксе.

lovesan ★★
()
Ответ на: комментарий от qulinxao3

тут люди разговаривают на уровне что лучше C# или Питон, господи, какие DSL, им развиваться до лиспа как зимбабве до космической программы

lovesan ★★
()
Ответ на: комментарий от lovesan

у эффективного SICPиHtDP для начального обучения программированию очень познавательная область истинности

в целом и точечных пар достаточно но зачем-то пользуются стороними кавычками(регистрами) парных символов

всё упирается вообще а какая доля людей может в символы( у Саватеева модель этажей математики)

qulinxao3 ★★
()
Ответ на: комментарий от qulinxao3

«парадокс» что число это и абстракция(некоторое переменная последовательность букв на как правило дуальном алфавите) и некоторая конкретность интерпретации

теже структуры данных популяризовались не от хорошей жизни см кризис программирования в 1968 у альянса :)

qulinxao3 ★★
()
Ответ на: комментарий от qulinxao3

мейнстрим весь в зимбабве, никогда в нем лисп не был еще, только постепенно мелочи из лиспов тырят, начиная там с GC

lovesan ★★
()
Ответ на: комментарий от lovesan

тут люди разговаривают на уровне что лучше C# или Питон, господи, какие DSL,

Ну Вы же решили для себя что шарпы лучше лиспа, а то что питон лучше шарпов в целом ряде задач как бэ общеизвестно. Следовательно питон лучше лиспа;-)

им развиваться до лиспа как зимбабве до космической программы

Вам бы хотя бы с шарпов до лиспа назад развиться, про питон я уж не говорю. Но ведь для этого Вам придется перестать смотреть научпоповские подкасты и начать думать о программировании а не об устройстве вселенной…

AntonI ★★★★★
()
Ответ на: комментарий от lovesan

сори за дидактизм

здесь(выше) dsl это любая актуальная наличная среда в которой имяряк делает дело и поэтому(так это ремесло а не исследование(розыск истина ага)) бегло без постоянной кооперации со справочными источниками точает болванку в продукт

автодополнение и есть сокращение пути в справку

qulinxao3 ★★
()
Ответ на: комментарий от amm

А что остановит Гвидо, или кто там сейчас, «улучшить» питон в версии 4 так, что придется все переписывать.

Могу предположить, что Гвидо много лет уже мечтает создать 4-ый Питон, полностью несовместимый с 3-м. Потому что эволюционные изменения уже не радуют - ему надо революционные. Но корпорации, у которых много завязано именно на 3-й, ему не дают. Думаю со временем этот 4-й Питон всё-таки выйдет. Однако, он традиционно будет с полноценной поддержкой Linux.

Ещё есть нюанс, касающийся России. Астры и даже Альты традиционно включают какие-то сильно устаревшие версии Питона. В Альте сейчас вроде бы до 3.9 доросли, а в Астре ещё более старая версия. Так что до нас все эти изменения дойдут нескоро.

Потому что в линуксах винформс никому не нужен.

Соответственно, из-за этого C# теряет нишу GUI в линуксе. Авалония от нонеймов не в счёт. Если я уж беру продукт от MS, то тогда дайте мне полноценную поддержку от MS, а сырую не библиотечку от левых людей.

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

Если уж всё равно переписывать, то зачем же под платформу, где никто ничего не обещает? А лучше вообще не мигрировать. Какой в этом смысл, если всё равно зависишь от MS?

Kogrom
()
Последнее исправление: Kogrom (всего исправлений: 1)
Ответ на: комментарий от lovesan

Они завязаны на винду и ЧИСТО виндовые фичи, вот те либы что ты перечислил.

Это ерунда, опровергнутая практикой. В моно была поддержка Windows.Forms, а Авалония является клоном WPF. Microsoft бы потянула поддержку этих библиотек с незначительными ограничениями, если бы захотела.

Kogrom
()
Ответ на: комментарий от lovesan

сам то читал SICP?

Читал, но забросил. Букварь отягощенный лишпом, ничего особенного. На любом современном языке можно все это разжевать (кроме может быть дрочи с компиляцией в самого себя). Да и сами академики заменили схему дубовейшим питоном, и нормально всё у них.

bread
()
Ответ на: комментарий от lovesan

Студия это эталонная IDE вообще. В линуксомирке нету и близкого аналога ни для чего вообще.

Опенсорс не подразумевает создание таких продуктов. Для этого надо скоординированная работа множества людей. Это не сделать на некоммерческой основе.

Соответственно, и языки в опенсорсе должны меньше полагаться на такие IDE. Синтаксис должен быть менее ООП-шным. А GUI библиотеки, например, не должны предполагать редактор форм.

Kogrom
()
Ответ на: комментарий от Kogrom

Но корпорации, у которых много завязано именно на 3-й, ему не дают.

Подожди, дай запишу: у питона хорошие корпорации, у шарпа плохие. :))

Если уж всё равно переписывать, то зачем же под платформу, где никто ничего не обещает?

То что они обещали, они поддерживают: net framework даже не имеет даты eol, под виндовс он будет еще долго, а под линукс его и не было никогда.

amm
()
Ответ на: комментарий от amm

у питона хорошие корпорации, у шарпа плохие

Найди разницу: в случае дотнета корпорация не даёт разрабатывать ПО себе в убыток, а в случае питона корпорации не дают разрабатывать ПО себе в убыток. То есть они делают то же самое. Дело не в добре и зле.

net framework … под линукс его и не было никогда

Понятно. Обсудим тогда .NET (Core). По информации с сайта Red Hat: «Developers can use .NET to build cross-platform cloud and console applications that run on Linux and Windows. … .NET supports building console and web applications for Windows, Linux, and macOS.»

Для консольных приложений ставить .NET как-то чересчур жирно. А для остального в Линуксе всегда были Java и PHP. Тут C# должен ещё отвоевать нишу. В любом случае, тут целью является очень небольшая группа программистов.

Kogrom
()
Ответ на: комментарий от Kogrom

Для консольных приложений ставить .NET как-то чересчур жирно. А для остального в Линуксе всегда были Java и PHP. Тут C# должен ещё отвоевать нишу. В любом случае, тут целью является очень небольшая группа программистов.

Да, приходится отвоевывать. Сейчас у него для этого все есть: Native AOT, source generators, и рантайм можно не тянуть, статически собранный бинарь будет весить несколько мегабайт.

amm
()
Ответ на: комментарий от bread

Ты вообще видимо не понял что там написано, или не читал вообще.

В том числе питоновскую «версию». Там нихрена больше никаких основ не дается, там дается - а вот херак-херак «import govno.govna» и поехали

lovesan ★★
()
Последнее исправление: lovesan (всего исправлений: 1)
Ответ на: комментарий от Kogrom

Ты видимо не представляешь себе что такое WPF и даже Winforms.

Никто тебе это делать за просто так не будет. Оно кстати в опенсорсе - иди делай сам.

lovesan ★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.