<?xml version="1.0" encoding="koi8-r"?>
<rss version="0.91">
<channel>
    <title>OpenForum RSS: Выпуск Python-библиотеки для научных вычислений NumPy 1.22.0</title>
    <link>https://www.solaris.opennet.ru/openforum/vsluhforumID3/126361.html</link>
    <description>Доступен релиз Python-библиотеки для научных вычислений NumPy 1.22, ориентированной на работу с многомерными массивами и матрицами, а также предоставляющей большую коллекцию функций с реализацией различных алгоритмов, связанных с использованием матриц. NumPy является одной из наиболее востребованных библиотек, применяемых для научных  расчётов. Код проекта написан на языке Python с применением оптимизаций на языке Си и распространяется под лицензией BSD...&lt;br&gt;&lt;br&gt;Подробнее: https://www.opennet.ru/opennews/art.shtml?num=56463&lt;br&gt;</description>

<item>
    <title>Выпуск Python-библиотеки для научных вычислений NumPy 1.22.0 (ptr)</title>
    <link>https://www.solaris.opennet.ru/openforum/vsluhforumID3/126361.html#99</link>
    <pubDate>Sat, 08 Jan 2022 02:35:17 GMT</pubDate>
    <description>&amp;gt; Большинство контор используют что-то одно.&lt;br&gt;&lt;br&gt;Да, но разные конторы - разное. Странно, что Вы это не знаете. И если контора не специализируется в разработке и внедрения ПО, то предпочитает обходится недорогими специалистами только в рамках поддержки имеющихся решений. Привлекая системных интеграторов для внедрения новых, развития существующих и для поддержки уже внедренных решений.&lt;br&gt;&lt;br&gt;Ну и как я уже писал Выше, Python ничем не поможет, если нужно написать CLR функцию для MS SQL или копилируемую функцию для PostgreSQL. А ведь IT ландшафт проекта не ограничивается только БД. Тут будет и kafka c Java, и фронтенд с JS, и многопоточные компилируемые веб-сервисы, и еще многое другое.&lt;br&gt;&lt;br&gt;&amp;gt; Набрать команду специалистов по коболу&lt;br&gt;&lt;br&gt;Зачем? Новый проект на COBOL писать сейчас бессмысленно. А моего опыта программирования на COBOL вполне достаточно было пока во всех случаях, когда поддержка COBOL требовалась.&lt;br&gt;При этом биндинга Python к COBOL я не знаю, поэтому, чтобы не писать новый код на COBOL, использовал C или, в кр</description>
</item>

<item>
    <title>Выпуск Python-библиотеки для научных вычислений NumPy 1.22.0 (Аноним)</title>
    <link>https://www.solaris.opennet.ru/openforum/vsluhforumID3/126361.html#98</link>
    <pubDate>Sat, 08 Jan 2022 02:12:36 GMT</pubDate>
    <description>Ну вот, начинается. Уже нужны специальные разработчики с улицы, и, как обычно, чтобы вчера готово было. Большинство контор используют что-то одно. Или додиез, или пхп с жс, или даже один 1С. Набрать команду специалистов по коболу, мы гугл что ли? Не подъёмных проектов никогда никто не будет брать, для начала. А ещё, внезапно, не все пашут на галерах, есть компании со своими продуктами.&lt;br&gt;</description>
</item>

<item>
    <title>Выпуск Python-библиотеки для научных вычислений NumPy 1.22.0 (ptr)</title>
    <link>https://www.solaris.opennet.ru/openforum/vsluhforumID3/126361.html#97</link>
    <pubDate>Sat, 08 Jan 2022 01:02:24 GMT</pubDate>
    <description>Если Вы, конечно, работаете в шарашкиной конторе, в которой три разработчика, то выбора у Вас нет. Потому и защищаете свой антипаттерн.&lt;br&gt;&lt;br&gt;А в нормальных системных интеграторах не составляет проблем подобрать в проектную команду специалистов, уже имеющих компетенцию в выбранных инструментальных средствах. Или даже оплатить обучение специалистов, если выбрано относительно новое инструментальное средство.&lt;br&gt;&lt;br&gt;В проектной деятельности так же существуют требования заказчика. Например, если заказчик по требованиям импортозамещения выбирает PostgreSQL, а проект требует разработки дополнительных копилируемых SQL функций, то как бы Вы не были против С, альтернативы тут Вы не обнаружете. А даже если можно обойтись не компилируемой функцией, то Python Вам не позволят использовать безопасники, так как безопасного Python для PostgreSQL в природе не существует.&lt;br&gt;</description>
</item>

<item>
    <title>Выпуск Python-библиотеки для научных вычислений NumPy 1.22.0 (Аноним)</title>
    <link>https://www.solaris.opennet.ru/openforum/vsluhforumID3/126361.html#96</link>
    <pubDate>Sat, 08 Jan 2022 00:47:37 GMT</pubDate>
    <description>Вымышленные термины, они такие. В жизни не всё так просто. Если рассматривать с позиции затрат и вероятности получения хороших результатов, стесняться отдавать предпочтение технологиям, которые точно работают и которые дадут предсказуемый результат, было бы довольно не умно.&lt;br&gt;</description>
</item>

<item>
    <title>Выпуск Python-библиотеки для научных вычислений NumPy 1.22.0 (ptr)</title>
    <link>https://www.solaris.opennet.ru/openforum/vsluhforumID3/126361.html#95</link>
    <pubDate>Sat, 08 Jan 2022 00:00:28 GMT</pubDate>
    <description>&amp;gt; Золотой молоток это всегда хорошо.&lt;br&gt;&lt;br&gt;Спасибо, что потвердили мои слова. Вообще-то &quot;золотой молоток&quot; есть антипаттерн проектирования, что признано значительным количеством специалистов, например, таких как Каплан или Маслоу.&lt;br&gt;</description>
</item>

<item>
    <title>Выпуск Python-библиотеки для научных вычислений NumPy 1.22.0 (Аноним)</title>
    <link>https://www.solaris.opennet.ru/openforum/vsluhforumID3/126361.html#94</link>
    <pubDate>Fri, 07 Jan 2022 21:32:48 GMT</pubDate>
    <description>Золотой молоток это всегда хорошо. Чем быстрее получается хороший вылизанный код, и чем проще он в сопровождении, тем лучше. Всё зависит только от качества и актуальности батареек, на каком языке  разрабатывать вообще не принципиально (главное, чтобы не си с его бойлерплейтом и байтобством, можно плюсы взять), однако время, необходимое на разработку, это существенный параметр. Невозможно знать всё языки достаточно хорошо, придётся выбирать специализацию. Не навсегда, конечно. Те, кто вчера использовал перл, сегодня перешли на питон. Всерьёз сравнивать скриптоту с компилируемыми не могу, уж извините.&lt;br&gt;</description>
</item>

<item>
    <title>Выпуск Python-библиотеки для научных вычислений NumPy 1.22.0 (ptr)</title>
    <link>https://www.solaris.opennet.ru/openforum/vsluhforumID3/126361.html#93</link>
    <pubDate>Fri, 07 Jan 2022 20:21:07 GMT</pubDate>
    <description>&amp;gt; вот я-то умею на паскале писать, это лучше!&lt;br&gt;&lt;br&gt;Соболезную, как экстрасенс Вы с треском провалились.&lt;br&gt;Я только чужой код на Pascal/Delphi поддерживал, сам предпочитая другие языки, включая, тот же Python. Но ограничивать свою деятельность исключительно последним мне никогда даже в голову не приходило. Иногда просто необходим C, причем вплоть до необходимости ассемблерных вставок, иногда быстрее написать на tcl/tk, есть задачи для которых лучше C# или Java, а в браузере проще использовать JS (или TS).&lt;br&gt;Всю жизнь я выбирал и выбираю инструмент, в зависимости от задачи, а не пытаюсь все задачи подряд решать одним &quot;золотым молотком&quot;, как Вы.&lt;br&gt;</description>
</item>

<item>
    <title>Выпуск Python-библиотеки для научных вычислений NumPy 1.22.0 (Аноним)</title>
    <link>https://www.solaris.opennet.ru/openforum/vsluhforumID3/126361.html#92</link>
    <pubDate>Fri, 07 Jan 2022 17:34:59 GMT</pubDate>
    <description>Никто и не говорит, что тот же питон универсален. Однако, это факт, что он универсален и удобен, особенно, с учётом интеграции нативного кода. Скорее, не везде применим из-за низкой производительности. Единственный недостаток питона. Этой низкой производительности достаточно всего лишь почти везде -- когда нагрузки возрастают, там можно и подумать о переписывании (благо, это не разрабатывать с нуля). &lt;br&gt;&lt;br&gt;Я вполне могу представить себе профессиональных питон-программистов, точно так же, как и профессиональных жс-программистов. Им просто нет необходимости выходить за рамки интерпретируемой шляпы, скорее всего, они способны на это при должном уровне квалификации. Язык, на котором писать, вообще не главное.&lt;br&gt;&lt;br&gt;Вот что действительно непонятно, так это то, о чём ты рассуждаешь, будто успокаиваешь себя в стиле &quot;вот я-то умею на паскале писать, это лучше!&quot;, при этом сложность этих паскаль-приложений будет на много порядков ниже (даже если отбросить все эти тысячи слоёв абстракций, абстракции далеко не всегда плохо ко</description>
</item>

<item>
    <title>Выпуск Python-библиотеки для научных вычислений NumPy 1.22.0 (ptr)</title>
    <link>https://www.solaris.opennet.ru/openforum/vsluhforumID3/126361.html#91</link>
    <pubDate>Fri, 07 Jan 2022 13:49:09 GMT</pubDate>
    <description>Вот она истина в одной фразе. Python оптимален для тех, для кого разработка не является основным видом профессиональной деятельности. Потому фраза &quot;профессиональный программист на Python&quot; меня и вводит в ступор.&lt;br&gt;</description>
</item>

</channel>
</rss>
