"А вот Фокс (Python), он в законе вор или так приблатнённый? Я что-то не пойму...."

[Dmitry67]

Индусы не понимают как это работает внутри
Для них программирование это как магический ритуал, слова произнес, что-то получилось, а почему непонятно. Воистину глаголю, ни один муж не войдет в программисткий рай, не познав static char BUF[256];

[Oleg-NY]

Не согласен. Из моего опыта, код "индусов" коряв именно снаружи, глядя со стороны системы, а не изнутри (с точки зрения сомого компьютера). То, что вам не нравится, кмк, это скорее из области оптимизации и эффективности изолированных алгоритмов. Да, конечно, когда они пишут LINQ выражение, которое работает в сто раз медленнее, чем соответствующий custom SQL, то они скорее всего не понимают имплементации. Однако это не 100% их вина, а скорее корявость отображения LINQ в конкретную RDBMS Engine, что не дает программисту достаточного уровня абстрагированности.

[flip_flop]

Кузены программисты, родные, и дались вам ваши индусы "Каждый заслуживает своих индусов" ( © моё)

По дискуссии высокая абстракция супротив железа: согласен с обоими. Нужно и то и другое, наверное надо начинать с высоты птичьего полёта, но заканчивать С и ассемблером вплоть до железа на уровне транзисторов Кстати, питон тут годиться вполне - и специализированные сверхвысокие фреймворки для определённых областей (DSL) и Cython + ABI для эффективности. Недавно, кстати, вышел Intel Python distribution (free, Numpy/SciPy/.../[много чего]) для ускорения, рекомендую.

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

[f_evgeny]

Конечно помогает, а еще и ассемблер не мешало бы знать, чтобы понимать что оптимально, а что нет, не полагаясь на оптимизацию.
Да только это нам с вами, после стольких лет и возможности развиваться вместе с самими компьютерами по сути.
Другое дело - наши дети, которых запросто можно "запороть" этой низкоуровневой ерундой, по сути мало что дающей в архитектурном плане (ну если только вы не фокусируете их специально в embedded). По-мне так изначально надо дать как можно более высокоуровневые понятия в программировании, где паттерны имеют большее значение, чем операционные системы и где структуры данных и алгоритным более важны, чем конкретные языки и процессоры.

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

[Oleg-NY]

Да и пусть себе открывают, если только это не хардкодед connection string везде. Первое можно легко оптимизировать, а за последнее надо "убивать" на месте.

[Dmitry67]

Да и пусть себе открывают, если только это не хардкодед connection string везде. Первое можно легко оптимизировать, а за последнее надо "убивать" на месте.

Ага
А потом они блокируют сами себя

[f_evgeny]

Да и пусть себе открывают

Ну вот это да! Берите свои слова обратно!
- Рано или поздно при таком подходе они откроют это дело в цикле, где за день наоткрывают 10^N коннекшенов.
- Я тут одну штуку оптимизировал, только на консолидации соединений сэкономил 400 мс CPU на одно обращение. А это много, очень много.

[Oleg-NY]

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

[f_evgeny]

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

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

[Oleg-NY]

Я не про Питон тут уже... я в нем ни в зуб ногой пока. Я вообще, про "открытие" соединения как абстрактной операции, результатом которой обычно является объект и не важно в каком оно виде потом хранится, используется и уничтожается. Все дело в параметрах. Если они в такой оперции присутствуют явно, то у вас нет другого выхода как физически открыть новое соединение. Если все правильно обернуто, то за вас фреймворк позаботится, чтобы не было 10^N соединений. Это не говоря уже про то, что само соединение или способ его получения может быть данностью, но это уже из области Inversion of Control. Я вообще не то что хардкод, но любой non-IOC ready код рассматриваю как халтуру.

[f_evgeny]

Я не про Питон тут уже... я в нем ни в зуб ногой пока. Я вообще, про "открытие" соединения как абстрактной операции, результатом которой обычно является объект и не важно в каком оно виде потом хранится, используется и уничтожается. Все дело в параметрах. Если они в такой оперции присутствуют явно, то у вас нет другого выхода как физически открыть новое соединение. Если все правильно обернуто, то за вас фреймворк позаботится, чтобы не было 10^N соединений. Это не говоря уже про то, что само соединение или способ его получения может быть данностью, но это уже из области Inversion of Control. Я вообще не то что хардкод, но любой non-IOC ready код рассматриваю как халтуру.

Вы джавист?

[Oleg-NY]

Ни в одном глазу! ))

[f_evgeny]

Ни в одном глазу! ))

А какой тогда бэкграунд?
Мне показалось судя по терминологии. Неужели Си два креста? Или даже ПХП? Они там всего сейчас понатащили отовсюду.

[Oleg-NY]

Бэкграунд у меня вообще радиотехнический. Просто начитался тут разного... ))
С, С++ вперемешку с ассемблером это само собой, но в смысле managed - .NET только.

[Oleg-NY]

А вот еще... Как Python в сравнении с Ruby или Ruby on Rails (хз чем последние два отличаются, но почему-то сразу хочется выпить... ?
В вики написано, что типа Ruby должен быть более объектно-ориентированным?

[Palych]

Фигня все эти руби с питонами. Настоящие пацаны юзают Rust

[flip_flop]

Фигня все эти руби с питонами. Настоящие пацаны юзают Rust

Фигня все эти руби с питонами. И Rust тоже фигня. Настоящие пацаны юзают исключительно FORTRAN

Rust - очень интересный и подаюший надежду язык, но всё же сравнивать компилируемый статический язык с интерпретируемыми динамическими языками - несколько неправомерно.

[Oleg-NY]

А в чем неправомерность? Что там, что здесь - свой рантайм и вся разница в том, доводится ли трансляция до псевдокода, либо до машинного кода. Теоретически последнее возможно в обоих случаях. Нет?

[f_evgeny]

А в чем неправомерность? Что там, что здесь - свой рантайм и вся разница в том, доводится ли трансляция до псевдокода, либо до машинного кода. Теоретически последнее возможно в обоих случаях. Нет?

ИМХО, главная разница - динамическая/статическая типизация.

[flip_flop]

А в чем неправомерность? Что там, что здесь - свой рантайм и вся разница в том, доводится ли трансляция до псевдокода, либо до машинного кода. Теоретически последнее возможно в обоих случаях. Нет?

ИМХО, главная разница - динамическая/статическая типизация.

Согласен.

[Oleg-NY]

Ну допустим, но ведь это всего-лишь вопрос синтаксиса языка, а не семантики. Внутренне, имплементация может быть и скорее всего очень похожей. То, что тип переменной не объявлен явно, не означает, что она будет одной и той же, если её тип изменится - это всего-лишь имя, а значит в компилированном виде вы не сможете сказать какой была изначальная типизация, динамическая или статическая...
Я конечно же не намекаю на "var" в c# так как там скорее "неявная типизация" и вы скорее всего имели ввиду не это.

[Palych]

А я бы компилируемость/интерпретируемость поперёд поставил.
Современные компилируемые языки обычно удобно в качестве DSL, чтобы встраивать из в системы типа Gimp, и проч.
т.е. они могут манипулировать каким-нибудь контекстом.
А большинство компилируемых языков, даже Java в конце концов манипулируют памятью...

[blanko27]

Фигня все эти руби с питонами. Настоящие пацаны юзают Rust

Фигня все эти руби с питонами. И Rust тоже фигня. Настоящие пацаны юзают исключительно FORTRAN

[Palych]

Кто там спрашивал почему мало SSD покупают?
Они с бабочками несовместимы!

[perasperaadastra]

Ответ принимается как полностью исчерпывающий. Это был последний нерешенный вопрос. Теперь можно закрывать интернет как выполнивший свою предназначение.