The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Выпуск Python-библиотеки для научных вычислений NumPy 1.22.0, opennews (??), 06-Янв-22, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


92. "Выпуск Python-библиотеки для научных вычислений NumPy 1.22.0"  +/
Сообщение от Аноним (30), 07-Янв-22, 20:34 
Никто и не говорит, что тот же питон универсален. Однако, это факт, что он универсален и удобен, особенно, с учётом интеграции нативного кода. Скорее, не везде применим из-за низкой производительности. Единственный недостаток питона. Этой низкой производительности достаточно всего лишь почти везде -- когда нагрузки возрастают, там можно и подумать о переписывании (благо, это не разрабатывать с нуля).

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

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

Ответить | Правка | Наверх | Cообщить модератору

93. "Выпуск Python-библиотеки для научных вычислений NumPy 1.22.0"  +/
Сообщение от ptr (ok), 07-Янв-22, 23:21 
> вот я-то умею на паскале писать, это лучше!

Соболезную, как экстрасенс Вы с треском провалились.
Я только чужой код на Pascal/Delphi поддерживал, сам предпочитая другие языки, включая, тот же Python. Но ограничивать свою деятельность исключительно последним мне никогда даже в голову не приходило. Иногда просто необходим C, причем вплоть до необходимости ассемблерных вставок, иногда быстрее написать на tcl/tk, есть задачи для которых лучше C# или Java, а в браузере проще использовать JS (или TS).
Всю жизнь я выбирал и выбираю инструмент, в зависимости от задачи, а не пытаюсь все задачи подряд решать одним "золотым молотком", как Вы.

Ответить | Правка | Наверх | Cообщить модератору

94. "Выпуск Python-библиотеки для научных вычислений NumPy 1.22.0"  +/
Сообщение от Аноним (30), 08-Янв-22, 00:32 
Золотой молоток это всегда хорошо. Чем быстрее получается хороший вылизанный код, и чем проще он в сопровождении, тем лучше. Всё зависит только от качества и актуальности батареек, на каком языке  разрабатывать вообще не принципиально (главное, чтобы не си с его бойлерплейтом и байтобством, можно плюсы взять), однако время, необходимое на разработку, это существенный параметр. Невозможно знать всё языки достаточно хорошо, придётся выбирать специализацию. Не навсегда, конечно. Те, кто вчера использовал перл, сегодня перешли на питон. Всерьёз сравнивать скриптоту с компилируемыми не могу, уж извините.
Ответить | Правка | Наверх | Cообщить модератору

95. "Выпуск Python-библиотеки для научных вычислений NumPy 1.22.0"  +/
Сообщение от ptr (ok), 08-Янв-22, 03:00 
> Золотой молоток это всегда хорошо.

Спасибо, что потвердили мои слова. Вообще-то "золотой молоток" есть антипаттерн проектирования, что признано значительным количеством специалистов, например, таких как Каплан или Маслоу.

Ответить | Правка | Наверх | Cообщить модератору

96. "Выпуск Python-библиотеки для научных вычислений NumPy 1.22.0"  +/
Сообщение от Аноним (30), 08-Янв-22, 03:47 
Вымышленные термины, они такие. В жизни не всё так просто. Если рассматривать с позиции затрат и вероятности получения хороших результатов, стесняться отдавать предпочтение технологиям, которые точно работают и которые дадут предсказуемый результат, было бы довольно не умно.
Ответить | Правка | Наверх | Cообщить модератору

97. "Выпуск Python-библиотеки для научных вычислений NumPy 1.22.0"  +/
Сообщение от ptr (ok), 08-Янв-22, 04:02 
Если Вы, конечно, работаете в шарашкиной конторе, в которой три разработчика, то выбора у Вас нет. Потому и защищаете свой антипаттерн.

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

В проектной деятельности так же существуют требования заказчика. Например, если заказчик по требованиям импортозамещения выбирает PostgreSQL, а проект требует разработки дополнительных копилируемых SQL функций, то как бы Вы не были против С, альтернативы тут Вы не обнаружете. А даже если можно обойтись не компилируемой функцией, то Python Вам не позволят использовать безопасники, так как безопасного Python для PostgreSQL в природе не существует.

Ответить | Правка | Наверх | Cообщить модератору

98. "Выпуск Python-библиотеки для научных вычислений NumPy 1.22.0"  +/
Сообщение от Аноним (30), 08-Янв-22, 05:12 
Ну вот, начинается. Уже нужны специальные разработчики с улицы, и, как обычно, чтобы вчера готово было. Большинство контор используют что-то одно. Или додиез, или пхп с жс, или даже один 1С. Набрать команду специалистов по коболу, мы гугл что ли? Не подъёмных проектов никогда никто не будет брать, для начала. А ещё, внезапно, не все пашут на галерах, есть компании со своими продуктами.
Ответить | Правка | Наверх | Cообщить модератору

99. "Выпуск Python-библиотеки для научных вычислений NumPy 1.22.0"  +/
Сообщение от ptr (ok), 08-Янв-22, 05:35 
> Большинство контор используют что-то одно.

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

Ну и как я уже писал Выше, Python ничем не поможет, если нужно написать CLR функцию для MS SQL или копилируемую функцию для PostgreSQL. А ведь IT ландшафт проекта не ограничивается только БД. Тут будет и kafka c Java, и фронтенд с JS, и многопоточные компилируемые веб-сервисы, и еще многое другое.

> Набрать команду специалистов по коболу

Зачем? Новый проект на COBOL писать сейчас бессмысленно. А моего опыта программирования на COBOL вполне достаточно было пока во всех случаях, когда поддержка COBOL требовалась.
При этом биндинга Python к COBOL я не знаю, поэтому, чтобы не писать новый код на COBOL, использовал C или, в крайнем случе, FORTRAN (с ним биндинг COBOL проще). Все же на них разработка ведется быстрее, чем на COBOL.

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

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру