Python vs C#

Нет, я рассуждаю как человек, который не знает, куда берут джунов со знанием Scheme

Ну, откуда-то же к вам пришла идея, что есть такая штука «джун со знанием схемы». Тут явно подспудно предполагается, что овладевание языком программирование это: а) долгий и сложный процесс, который б) является «продающей фичей» на рынке труда. А это вот вообще нетривиальное утверждение, которое должно основываться на каком-то опыте. Я предположил С++, но если ошибся, извините, не специально.

Схема нужна, чтобы он научился программировать

Так он и спрашивал как ему научиться программировать. Если бы вопрос стоял: „как выучить С#“, я б, конечно, схему не советовал.

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

Я тред не читал, только ОП. А из него можно понять, что он предполагает решать задачи, связанные с тестированием. Если он где-то в треде высказал более основательные притязания, то я их не видел.

Со схемой носились только из-за SICP. Сейчас есть аналогичные учебники для более востребованных ЯП. Ну и зачем страдать скобкотой?

Чернорабочих всегда нужно больше, нежели инженеров. Однако уж тут каждый сам для себя должен решать, куда ему больше хочется: в мастера или на галеру веслом махать.

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

Тред не читал.

Советую брать жяву.

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

паскаль?(& c) + python

если при питоно обучении не «сол и мол с мягким знаком а тарелька и вилька без» с пояснить за имена и значения без этих «изменяемых» и не_изменяющих(кому чему проверка) переменных(лол)

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

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

в каво ни пюлинь всях инженюгр

а уж менеджеров али экспертов так каждый первый

https://youtu.be/Ur3kLHxG3Gc

CSnakes: Embed Python code in .NET - Talk Python Live Streams

если нужен юнити и онли винда то C#, нет то Python или С++.
Главное найди нужный ТЕБЕ проект и пиши его, хоть на чем. Так быстрее всё изучишь, освоишь.

А кто такой автоматизатор? Писатель автотестов? Тогда это будет зависеть от основного языка на проекте. Всё, что есть в питоне для автоматизации тестов, есть и в шарпе.

А можно то же самое только понятнее переписать, без нарочитых ошибок в словах хотя бы

Я вообще согласен с тем, что начинать надо с паскаля/си

Асм не надо, утонуть можно

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

Нормальная вещь, если нужно заиспользовать питоновскую библиотеку. Вопрос только в скорости interop.

c/асм ибо с - это некоторое общее пересечение стековых(но без вложенных процедур как в паскале(и «любом» алголе) -ака дисплеи) - самая «простая» учебная асм-машинка - без директив - чисто мнемоники 1,2,3 адресных - чисто как пример как бывает

либо паскаль(TP) с МEM встроенным array -который и есть вся оператива(ну нижний 1мб с +hma) - пиши - но не надо :)

т.е c это нормально когда есть понимание в какой асм оно транслируется т.е. всё как всегда - насколько модель которая в гойлове у программиста адекватна(по сути достаточна) для выделения баблоса :)

Тогда это будет зависеть от основного языка на проекте.

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

Тогда чем питон лучше для тестов?

Ничем.

В нормальных языках с нормальной инфраструктурой любой уровень тестов самодостаточен на самом себе.

Пример жявка. Есть либы на жявке для любого вида тестирования

Тогда чем питон лучше для тестов?

• Чебурашкам лучше то что попроще
• Автотесты это фактически скрипты, а не полноценные приложения. Python лучше для них подходит
• C# в среде автоматизаторов менее популярен, по этому и с работой на нём будет сложнее

Питон проще, шарп лучше.

у питона реализации(что CPython что Pypy) достаточно обозримы и написано что нет нужды быть инопланетянином что бы до железки было понятно что происходит

dotnet(netcore) движение в нужный пункт прибытия но уж лучше что бы python/vscode/linux(wsl) чем M$/M$/M$

Мне не важно какая там политота вокруг реализаций. Важно что технически как ЯП C# луче чем Python для всего кроме скриптов, прототипирования и датасаенса. Для них Python лучше.

С# больше ориентирован на корпоратов (просто смотрим на дерево имён) т.е шарпы отличная замена жабы которая «спрятала» oberon

автор Tubro среды с мгновенной компиляцией крут - однако шарп результат работы комитета ( просто смотрим как менялся центр тяжести по версиям да того же Рихтера разные издания)

Python - это заведомо обозримое одним человеком если нужно инопланетное то mojo

Мне не важно какая там политота вокруг реализаций. Важно что технически как ЯП C# луче чем Python для всего кроме скриптов, прототипирования и датасаенса. Для них Python лучше.

не то чтобы я не был согласен, просто хочу уточнить точку зрения. Значит ли из ваших слов, что программы вроде gnome-terminal, do-release-upgrade и так далее стоило бы переписать на C#? Или вы весь подобный софт скопом относите к скриптам?

Терминал нынче наверное стоит уже переписывать на шарп. Раньше было нельзя, т.к. с гуи не в оффтопике были серьёзные проблемы. Сейчас их стало меньше, хотя пока остаются вроде подтекания памяти у авалонии из-за кривой её работы с GPU. А вот do-release-upgrade скриптота чистой воды, его хоть на баше делать можно, вообще то что оно есть это не очень хорошо, так быть в принципе не должно как у нас софт обновляется, но имеем что имеем в силу исторических причин, NixOS куда более правильно смотрит на данную проблематику (хотя и там цирк с конями как и во всём линуксе). Да даже андроид и то правильнее сделан, чем все наши линуксы. Про BSD и говорить не приходится, там всё тоже лучше и зоопарк с цирком обновлений меньше.

Python - это заведомо обозримое одним человеком

Смелое заявление. Обозримое в каком приближении? Полностью код какого-то CPython я в голове не могу проинтерпритировать и уверен что никто из людей не может. Сильный ИИ может и сможет, рептилоиды там тоже должны смочь. Но ни первого, ни второго, пока не наблюдается. А у людей проблемы с полным пониманием того что они пишут начинаются когда в проекте больше двух недель работы одного разработчика. Если бы их не было, то баги связанные с логикой в софте бы отсутствовали, но нет, они все на месте даже в хеллоуворлдах посложнее.

Стаффорд Бир/Мозг фирмы

Python рос через откровение сквозь Гвидо - Петерс(Тим)(кстати его уже разбанили?!)очень помог(ал и ает)

C# без предварительного умения в прог сложен в обучении ибо это более что ли промышленный(в плохом смысле) - в нём конечно меньше public static void - дак это больше от того что оно(CLR и прочая) сильнее осталось связано с (по)родительской компанией - да и скорость изменений C# явно быстрее жабия(ибо cobolу важна стабильность)

Python 0.9.1 это 21 письмо

С# 1996(Жаба - С# ~ 2001) это эко-система с собственным блэк джеком и вм - дальше больше

Жаль что Oberon :(

Очень сильное утверждение. Я бы даже поверил, шарпы то я не знаю, если бы ты так широко не размахнулся:-)

А чем именно шарпы лучше питона для всего остального, и почему в этих трех пунктах шарпы хуже? Магия какая то…

и почему в этих трех пунктах шарпы хуже

Скрипты - уровень абстракции не тот, да и рантайм тяжеловат. Хотя есть powershell, например (и под линукс в том числе, с недавних пор)

Прототипирование - хз.

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

По отзывам (сам не трогал) повершеллом пользоваться невозможно.

Про уровень абстракций не распарсил:-)

Скрипты - уровень абстракции не тот,

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

Ну и это тоже

Ну в питоне есть компиляция в байткод, фсе пропало!!!111:-)

Про уровень абстракций не распарсил:-)

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

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

Другой вариант - это встраиваемые скрипты, для выноса бизнес-логики за пределы приложения. Практический пример: в игре Legends of Runeterra (ККИ в сеттинге лиги легенд) - ядро игры на C#, а скрипты всех карт - на питоне, через IronPython. Дизайнерам так проще работать, потому что язык проще - меньше нюансов, и уровень абстракции выше. Впрочем, фактор компиляции здесь наверное тоже есть.

Что у нас еще подпадает под «скрипты»?

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

Зависит от сложности портянки. Если там просто последовательность вызова утилит с перенаправлениями вывода то их и надо писать на баше. Если там какой то сложный анализ и преобразовнаие данных, сложная логика - конечно на питоне оно будет гораздо проще. Что бы такое на баше сделать надо очень хорошо знать баш (гораздо лучше чем питон для решения задачи той же сложности) и смотреться оно все равно будет так себе.

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

«Указавший выше» указал как обычно бред.

1. в питоне есть компиляция в байт-код.

$ cat 1.cpp 
//&>/dev/null;x="${0%.*}";[ ! "$x" -ot "$0" ]||(rm -f "$x";cc -o "$x" "$0")&&exec "$x" "$@"
#include <stdio.h>

int main(){
	printf("Hi FishHook!\n");
}
$ chmod a+x 1.cpp
$ ./1.cpp
Hi FishHook!

встраиваемые скрипты, для выноса бизнес-логики за пределы приложения.

Для таких целей есть ЯП получше, вроде lua, правда питон знает гораздо больше народу. ИМНО питон для встраивания слишком толстый и вообще это извращение. М.б. где то конечно есть лайт-версия питона для встраивания в плюсы, я не в курсе… было бы интересно (какая нить маленькая либа в сырцах что бы не тащить питонье вот это все).

Что у нас еще подпадает под «скрипты»?

Ну я использую питон как:

1. калькулятор в командной строке

2. что то для быстрой обработки данных, когда скорость работы неважна а важно быстро сделать что бы работало

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

4. верхний управляющий слой для HPC расчетов. Т.е. в питон биндится плюсовый код, вот это архитектура здорового человека.

5. CAS и кодогенерация, в т.ч. плюсового кода.

peregrine, в каком из этих пунктов шарпы лучше питона настолько что имеет смысл потратить время на их изучение?

Где я говорил, что питон не компилируется в байт-код? Я указал на то, что компиляция и интерпретация выполняются одним бинарём и для пользователя это один процесс исполнения скрипта, и никакой отдельный этап компиляции не нужен. Но ученый как обычно пердит в лужу, потому что о чем идет речь он не понимает, но у всех - видимо по старой профессорской привычки - ищет детские косяки и считает себя самым умным.

в питоне есть компиляция в байт-код.

Технически js тоже компилируется в байт-код, хоть он и на диск не сбрасывается.

Технически cs код тоже можно пускать напрямую.

Но вот есть некие устоявшиеся практики и ожидания по части жизненного цикла разработки, и «&>/dev/null;x=»${0%.*}" в cpp файлы никто не вставляет xD

Для таких целей есть ЯП получше, вроде lua,

Это спорно, уже как минимум потому, что «правда питон знает гораздо больше народу» - гуманитарные соображения в данном случае скорее всего выигрывают у технических мелочей. Другой популярный вариант для встраивания - js, несложно предположить почему.

Толщина серверной сборки часто не играет особой роли - в зависимости от размера проекта библиотека для скриптов на фоне всего остального может легко потеряться.

В конечном итоге почему они выбрали именно питон - нет информации, но наверное выбор был осознанный.

в каком из этих пунктов шарпы лучше питона настолько что имеет смысл потратить время на их изучение?

.net в целом ложится на п. 3 и 4. Пункт 2 - дело привычки, я все свои прототипы и мелкие программы пишу на шарпе, иногда js/ts. Если в текущем стеке все устраивает, то и дергаться нет смысла, разве что из любопытства и общеобразовательных целей?

Причем это работает в обе стороны и предметная область накладывает свои ограничения. Я когда-то делал плагины для САПРов (Solidworks, NX) - там на тот момент никакого питона не было, только C++ (с понятно какой эргономикой) и C# (в случае NX еще Java).

Толщина серверной сборки часто не играет особой роли - в зависимости от размера проекта библиотека для скриптов на фоне всего остального может легко потеряться.

Вопрос не в толщине а в геморрое сборки. У нас обычно код собирается на целевой платформе из сырцов, причем иногда с передачей сырцов «под роспись». В этом случае передавать питон это одно, а передавать что то легковесное это совсем другое. .net на целевых платформах просто нет, поставить то наверное можно, но напуркуа? Настоящих буйных мало…

почему они выбрали именно питон - нет информации, но наверное выбор был осознанный.

Из тех самых гуманистических соображений вестимо;-)

.net в целом ложится на п. 3 и 4.

По «написание достаточно сложных приложений» - в питоне из экзотичного мне нужно:

1. рефлексия. Взяли объект со стороны, покрутили, пробежались по всем аттрибутам, что то сделали.

2. __getattr__ — атрибута нет, но по запросу делается, в зависимости от контекста разное.

3. делается своя иерархия классов с перегруженными операциями (обычно BaseOp, UnaryOp, BinaryOP + что то по необходимости), дальше произвольное выражение eval-ом конвертится в AST из этих классов и с ним уже что то происходит. Занимает 50…300 строк зависимости от навороченности, 300 строк полный фарш с поддержкой векторов, конвертацией выражений в tex и еще всяким. 50 строк это генератор кода для узкозаточенной плюсовой байт-машины. Через модуль ast это делать гораздо неудобнее и дольше, пробовал. Сколько это займет на шарпах?;-)

верхний управляющий слой для HPC расчетов

Здесь, кроме отсутствия .net на целевых машинах, вступает тот самый гуманистический фактор. Питон знают все, шарпы (у нас) не знает никто.

Кое кто из коллег в другом городе писал че то HPC на шарпах, мы на него смотрели странно. Связка плюсы(CUDA)-питон на нашей полянке с запасом закрывает все мыслимые потребности именно потому что питон с плюсами диаметрально противоположные ЯП. Куда тут втыкивать еще ЯП я не вижу…

Я бы кстати ушел с питона, очень меня бесит как разработчики ломают обратную совместимость и куда вообще питон движется. Но увы - держит кодовая база и то что питон знают все…

компиляция и интерпретация выполняются одним бинарём и для пользователя это один процесс исполнения скрипта, и никакой отдельный этап компиляции не нужен.

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

Вопрос не в толщине а в геморрое сборки...

Есть разные варианты развертывания. Навскидку:

1) Из исходников на целевой машине - нужен SDK на целевой машине. При сборке он скачает все зависимости и все соберет сам. SDK включает в себя рантайм.

2) Portable сборка - собранное приложение + зависимости. Для запуска нужен рантайм (рантайм только запускает, но компилировать не умеет)

3) Self-contained сборка - то же что 2, но с рантаймом в комплекте. Размер будет большой, что-то можно под-trimm-ить, но все же

3.5) В последних версиях есть возможность компиляции в натив (Native AOT), что должно быть компактнее, но там есть свои ограничения

4) Контейнеры

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

В общем случае проблем нет. Даже библиотеки, которые завязаны на натив, (типа ClearScript, который требует нативную сборку V8), обычно предоставляют готовые сборки - включил в проект Nuget референс и поехал.

рефлексия

Есть. У МС правда случился FaaS головного мозга и в погоне за Native AOT сборками они рантайм рефлексию стараются постепенно заменять кодогенерацией в compile-time.

__getattr__

Я слабо знаком с питоном и из документации вроде как понял, что это, но зачем - уже нет. Судя по всему нет - перехвата вызовов из коробки нет (пока). Есть какие-то 3rd party решения для AOP, но надо четко понимать юзкейс. Ну и то, что код с вызовами несуществующих методов попросту не соберется (статическая типизация).

произвольное выражение eval-ом конвертится в AST из этих классов и с ним уже что то происходит...

Expression trees?.

Я думаю, что в целом привычные питоновские подходы в лоб работать не будут.

.net на целевых платформах просто нет, поставить то наверное можно, но напуркуа? Настоящих буйных мало…

Так я смело могу сказать, что надо знать область.
Хороший инструмент под хорошие задачи. Когда закопался в Go, то пришло понимание, как сейчас пишут и почему в тех или иных случаях Dotnet необходим. Data-Oriented vs OOP/DDD? Никак нет! Серьёзные решения требуют Polyglot architectures и Mix of paradigms. И только упорыши будут сложную бизнес логику делать не на Dotnet. Даже взглянуть на GC в Dotnet и Golang.

К чему это я? Инструмент знать надо! А у вас с архитектурой плохо или ты накатываешь незнанием. И это печалит. Строишь из себя специалиста, а на деле - недофизик и недопрограммер.

В твою защиту могу сказать, что я тоже таким был, накидывал (так как не имел знаний) на JS/TS, смеялся с OOP, приунывал с FP, когда мир рушил мои влажные мечты о красивом коде, называл сишников пердунами и так далее. Но ведь ты же уже взрослый, тебя дети читают, а ты такое накатываешь! Айайай!

нужен SDK на целевой машине. При сборке он скачает все зависимости

Если найдет коннект наружу;-)

Ну и отдельный вопрос - как это будет дружить например с MPI. Вопрос риторический, не точно не буду пробовать.

__getattr__

вроде как понял, что это, но зачем - уже нет.

Много зачем. Например в произвольном выражении от юзера могут быть какие то переменные которых нет, и это штатная ситуация - в зависимости от контекста такая переменная либо имеет значение None, либо просто трактуется как Var с таким вот именем для вывода.

Expression trees?.

Вопрос не в том как это разобрать, вопрос в том как с ним потом работать. Visitor писать довольно геморройно выходит…

Спасибо!;-)

Инструмент знать надо!

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

я тоже таким был

Вы таким и остались. Давеча помнится RTTI предлагали в теме по compile-time рефлексию в плюсах (при том что в RTTI — Run Time… ), весь тред засрали своими набросами. Заканчивайте уже свою клоунаду.

а вдруг я с тобой переписывался год с другого акка? А вдруг я знаю?

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

Звучит решаемо, может быть через ExpandoObject/DynamicObject, может быть более стандартными средствами (dynamic это такая мутная территория). Скорее всего решение будет иметь другую архитектуру.

Вопрос не в том как это разобрать, вопрос в том как с ним потом работать

Там есть примеры как с этим деревом работать, как по нему ходить и т.п. МСовская ORM (EF/EF Core) таким образом из Linq выражений генерирует sql код нужного диалекта, так что как минимум представление AST и трансляция покрывается. Парсинг это уже другой вопрос...

Я верю что это можно сделать;-)

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

Ну и главное - для перехода на другой ЯП нужны какие то веские аргументы. Будет потрачено X времени на изучение ЯП, Y времени на переписывание кодовой базы, но в итоге будет сэкономлено Z времени за счет нереальных плюшек этого ЯП, и Z>X+Y. Вот для перевода некоторых наших задач с плюсов на питон это неравенство выполняется с большим запасом - все таки на питоне скорость разработки на порядок выше чем на плюсах.

А таких аргументов в пользу шарпов я не вижу, кроме того мне очень субьективно не нравится то что делает MS;-(

При этом гипотетический вопрос ухода с питона в голове все таки сидит…

mojo

Чем С# так плох?

Я не говорил, что он плох (хоть и к такому мнению я тоже склоняюсь, но это не имеет значения в данном случае), если что. Я говорил, что он плох в качестве первого языка. И я, вроде, объяснил, чем. Тем, что людей, начинающих с C# или Java потом хрен научишь программировать на других — задача становится сложнее, чем научить того, кто не знает ни одного языка вообще.. Просто вот по опыту так. Почему именно так происходит, можно долго рассуждать, но есть наблюдаемый факт. Могу предположить, что будучи выученными первыми, они устаканивают в мозгу какие-то конкретные шаблоны проектирования, и человеку после этого сложно воспринимать их отсутствие или наличие других. Возможно, это как-то связано с тем, что там ООП прибито гвоздями и является почти что обязательным (хоть и некоторые фишки из функциональщины тоже потом завезли, но таким новичкам это не помогает). Но это домыслы о причинах, важнее сам факт, что на практике [почему-то] так получается, что c мозгом человека, начавшего с C# или Java что-то такое происходит, что мешает потом осваивать другие языки и особенно другие парадигмы. Ни с каими из других языков в качестве первого я подобного не замечал.

Проверкой типов, большие программы на питоне имеют свойство крашится в рантайме без каких-то особых признаков того что они упадут при таких же вложениях работы программиста C# крашится меньше, т.к. там проверок от компилятора куда больше и типизация способствует. Ну и шарп даже без батареек быстрый, почти на уровне C++. Python очень не шустрый, потом многопоточных проблем в шарпе нет там и с асинхронщиной и с многопотоком и с многопроцессом всё хорошо, питону туда ещё расти и расти, глядишь к 4 питону это исправят но не раньше, потому как либы надо тоже переделывать, а то тупое отключение gil даст некорректную работу кода который был корректен. GUI на шарпе тоже лучше, в оффтопике вообще всё шикарно с ним, в онтопике на самом деле avalonia всё равно лучше pyqt всяких на голову. Qt из крестов в онтопике получше будет т.к. багов меньше (с питона биндинги не во все фичи умеют Qt, например тему оформления попробуй прикрутить чтоб какой-нибудь лаунчер сделать который будет окно без стандартного обрамления рисовать - прямоугольник по центру с полем ввода и какими-нибудь стилями на выбор юзера).