GitHub опубликовал отчёт с анализом статистики за 2024 год. Основные тенденции:...Подробнее: https://www.opennet.me/opennews/art.shtml?num=62166
А как же Rust?
У раста сложности с асинхронными генераторами 10+ год. Единственный конкурент питону это додиез, как по мне.
Какие могут быть сложности с тем чего нет?
Сложности с добавлением базовой функциональности любого современного языка при наличии ощутимого спроса. Вот такие.
Асинхронный генератор - это не база языка.
У питона тоже реализация асинхронности упоротая, по сравнению с JS, тем не менее, он JS обогнал в этом рейтинге немного.
Так пробоема JS с утечкой памяти и невозможностью отсанавливать асинхронщину в JS
Это по дизайну невозможно. Не знаю как в Python, но в JS еще и исключение случайное
(случайный дятел) приводит к падению всей цивилизации.
> и невозможностью отсанавливать асинхронщину в JSА зачем? Достаточно это иметь в виду. Питон понятное дело не может позволить себе быть настолько же асинхронным как JS, т.к. JS был асинхронным сразу, а в питоне это появилось поздно, поэтому там приходится сохранять обратную совместимость, получается костыльно.
> Не знаю как в Python, но в JS еще и исключение случайное (случайный дятел) приводит к падению всей цивилизации.Это везде так, ну разве что кроме баша и тому подобного. В баше можно опционально такой режим включить чтобы при ошибках дальнейшее выполнение прекращалось.
> Единственный конкурент питону это додиез, как по мне.Интересно послушать, в чём пейфон может конкурировать с c#? 😁😂😁
В жоре памяти, например. По остальным параметрам питон понятно превосходит значительно.
ок, ясно. Ты пейфон-девелопер?
Что это вообще такое?
Про Rust там отдельно написано, но без конкретных цифр:Rust continues to gain popularity for its safety, performance, and productivity. Originally intended to serve as a safer alternative to C and C++, Rust has exploded in popularity and adoption, with top applications, such as Microsoft Windows, using Rust to rewrite core libraries with its memory-safe code.
safety
safer alternative
its memory-safe codeхалва, халва, халва... ммм как сладко
Ну короче, он как Godot engine и Линукс на десктопе - всё продолжает и продолжает набирать популярность. Но этот процесс длится вечно, так и не достигая назначенной цели.
Rust - это для программистов. Как, впрочем, и JavaScript. В статье речь о питоне
> В статье речь о питонеПейфон это для курсов программирование на пейфоне за 1 неделю из грязи в наносеки
"А как же Rust?"Ответ: никак.
Ответ: никак для программистов на Питоне и Джаваскрипте.Поправил.
Ответ: никак, для программистов на других языках, кроме Раст.Поправил.
Продолжают боротся с оскорбительными константами https://github.com/rust-lang/rust/pull/92469
*ться. быстрофиис
Понятно, делом заняты.
Мда, просто мерзко
Скучаю по тем временам, когда программисты писали программы, а не занимались придумыванием и пропихиванием повесточных языков
И когда был master вместо main
Школьники начали учиться программировать
питон - это современный паскаль (это пройдет)
разве от sql-иньекций не должны orm'ы спасать?
кто сейчас руками шлет запросы?
Дофига много и где так делают. И дофига много решений сделать такой код безопасным.Выйди из SEO-студий на пхп уже, в реальные проекты, разочек хотя бы. Ок? Спасибо.
>и дофига многокак ж так вышло, что дофига пока только уязвимостей этого класса в , можно сказать, мировой статистике?
так идите и расскажите несчастным кодерам на гитхабе о них.
>SEO-студий на пхпчто это?
учавствовала в паре проектов на .NET - везде был EEF.
за ручную посылку в приличных местах по лапам бьют.
как минимум, непортабельно.
И сколько раз это портабельночть пригодилась? А теперь сравни это с гемором, который орм-ки создают, чтобы запрос правильно составить.
>геморомдля тех, кто привык задачи в лоб решать, плевав на все и вся, усложняя себе жизнь? ну или для тех, у кого в языке это через пень-колоду.. другого обьяснения придумать не могу. в cs все вполне прилично.
>сколькоидите и посмотрите в статичтике, скольким проектам "orm-ки" помогли бы не допрыгаться с иньекций.
> за ручную посылку в приличных местах по лапам бьют.Слышали когда-нибудь про Озон, Авито, Вайлдберис, Яндекс, Мэйл.ру, ВК, МТС, экосистему Сбера? Так вот, у всех из этого списка сейчас главный язык - Go. В котором нет ни одной приличной ORM. Поэтому там всё пишут ручками (я в несколько из списка собеседовался, а в одном работал). Тейк про непортабельность смешной. Во-первых сейчас с postgres уходить просто некуда, во-вторых несовместимость серьёзных сервисов не проявляется в примитивных крудах (или чинится исправлением одного-двух слов в запросе).
Странно. А я аж две ОРМ знаю приличные и пользую обе. Миграции, запросы, хуки, многопоточность, транзакции -- очень доволен. А может и ещё что-то есть. Ты точно с моей планеты?
> Странно. А я аж две ОРМ знаю приличные и пользую обе. Миграции,
> запросы, хуки, многопоточность, транзакции -- очень доволен. А может и ещё
> что-то есть. Ты точно с моей планеты?Давайте названия в студию. Я надеюсь там не будет gorm, pq, sqlc, squrrel и прочих НЕ orm.
> разве от sql-иньекций не должны orm'ы спасать?Как бы должны, но кто ж пользуется ORM? Чтобы пользоваться ORM, тебе мало знать SQL, надо ещё этот ORM знать и понимать, что на нём нужно написать, чтобы получить именно такой SQL запрос, который тебе нужен. Такие вещи усложняют разработку и сопровождение в разы.
> кто сейчас руками шлет запросы?
Любой, кому приходится писать менее тривиальные запросы, чем SELECT * FROM mytable;. SQL -- это язык выборки данных, он позволяет очень сложные вещи сочинять, которые потом субд может быстро выполнять, часто это настолько быстро, что руками обогнать субд не удастся, особенно если ты пишешь на каком-нибудь интерпретируемом язычке типа php/python со сборкой мусора и динамической типизацией. Но даже на компилируемом языке возникнут проблемы с тем, чтобы простыми запросами к sql и постобработкой полученных данных обогнать один большой и кучерявый запрос sql, который выдаёт именно те данные, которые тебе нужны. А теперь попробуй сочинить и отладить большой кучерявый sql запрос через посредство какой-нибудь ORM.
ORM -- это классический пример leaky abstraction. Вроде как и абстракция над SQL, но она дырявая и изо всех её щелей лезет SQL, и не понимая всех нюансов SQL, в том числе и специфичных для данной реализации SQL, ты не сможешь ею пользоваться. Такая абстракция не упрощает, а усложняет работу, потому что помимо SQL, ты должен ещё знать особенности ORM и продираться через них.
При этом, SQL имеет встроенные механизмы, позволяющие обходить sql-инъекции, он называется prepared statements. Все внешние данные, которые идут в запрос, передаются отдельно и биндятся на переменные, значения которых sql потом использует.
Я не знаю, как людям до сих пор удаётся наступать на грабли sql-injection, но подозреваю, что это либо язычки с API, где сконкатенировать sql-запрос проще, чем подсунуть в prepared-statement значения, либо люди которые изучали SQL по туториалам из прошлого века.
прикольно, не знала.
но..
> это классический пример leaky abstractionman EF
не надо васянореализации использовать.
Какое классное профессиональное, грамотное раскрытие темы! 5++!
Мог лишь подтвердить все вышесказанное про ORM и запросы. Если у вас проект с кучей объектов и таблиц, ну хотя бы больше ста таблиц, ORM будет лишь запутывать дело, если одна две, три ну десять может быть да - чтбы быстро сделать сдать и забыть - на фрилансер орг каком то.
Студенты и джуниоры часто неправильно понимают что такое рутина и пытаются пропихнуть нечто такое вот, быстро и на соплях что бы. Потом оказывается, что да, и запросы генерятся неоптимизированные, и еще что то надо сделать помимо хитрое и заковыристое, и справочники какие то на 10 000 000 записей вдруг появляются для полей, и вот уже вместе с ORM надо испольовать параллельно какие то механизмы и все превращается в кашу -тыкву-.
sql-инъекции - ну в грамотно спроектированной системе их и не будет, так как база будет скрыта за кучей промежуточных слоев и обработчиками бизнес-логики, на иньекции попадаются люди которые прямо из строки запроса что то впрямую передают в строчки запросов в базу, это давно учебные примеры в книжьках по архитектуре и базам, лет 20 как уже если не больше.
>Если у вас проект с кучей объектов и таблиц, ну хотя бы больше ста таблиц, ORM будет лишь запутывать дело, если одна две, три ну десять может быть да - чтбы быстро сделать сдать и забыть - на фрилансер орг каком то.Если у вас сто таблиц, то ORM вам тем более нужен, чтобы не вспоминать где что лежит и как какая таблица называется. То, что с ORM можно сделать вводя одну единственную строку, без ORM придётся делать постоянно перепрыгивая между кодом и схемой данных.
>Потом оказывается, что да, и запросы генерятся неоптимизированные, и еще что то надо сделать помимо хитрое и заковыристоеРади нескольких отдельных случаев вы добавляете себе рутину во всём остальном. Десяток insert-ов можно и через ORM сделать, вы всё равно это не заметите.
Ну здрасьте. Если у вас сто таблиц, в ORM вам придётся помнить сто классов впридачу. А если интересует ещё и производительность, то придётся именно что попрыгать. Но имел я дело с поделием тех, кого не интересовало. Тормознутая мерзость. Да, по итогу они свалили свои проблемы на нас (мы это поделие эксплуатировали).
>в ORM вам придётся помнить сто классов впридачуЗачем помнить сто классов? Вот есть у вас актёр, снимающийся в фильмах. Обращаетесь к свойствам актёра, и IDE вам уже показывает, что актёр снимается в фильмах. Прямо во время набора кода, никуда не переключаясь. Для того, чтобы аналогичного эффекта достичь на sql, вам нужно будет переключится с окна редактора кода на бд, и либо копатся в графическом представлении, либо выгружать схему бд в файл, и далее в нём поиском искать все упоминания актёра. При этом, не важно, как реализована связь - один ко многим или многие ко многим, ORM самостоятельно это определит и получит нужные данные
>А если интересует ещё и производительность, то придётся именно что попрыгатьВопрос производительности всплывает в отдельных пограничных случаях. В большинстве базовых случаев ничего дополнительно делать не нужно.
>Да, по итогу они свалили свои проблемы на нас (мы это поделие эксплуатировали)Опять пользователи рассуждают о программистах. Тормозить может по миллиону причин, приличную часть из которых можно воспроизвести и без ORM. Например, вместо массовой вставки вставлять по одной строке за раз.
За упоминание слов "производительность" и "оптимизация" я избиваю разрабов до потери сознания. Пока нет продукта, который зарабатывает деньги -- нет предмета оптимизации. А когда продукт начал зарабатывать деньги -- оказывается оптимизировать надо единственный запрос из сотни методом алгоритмической оптимизации. Потому что запрос писал рукожопый разраб. И алгоритмическая оптимизация лишь подтверждает эффективность ОРМ.
так нет же.
зайдите на msdn, посмотрите примеры использования EF.
я его, почти не зная sql, использовала. проблем не было.
"почти не зная sql" - ну т.е. сравнивать не с чем, синдром утенка ))Цитата с msdn (да, не поленился, нашел, почитал):
Знания базового сервера базы данных на промежуточном уровне или выше необходимы для проектирования, отладки, профилирования и переноса данных в рабочих приложениях с высокой производительностью. Например, знание первичных и внешних ключей, ограничений, индексов, нормализации, инструкций DML и DDL, типов данных, профилирования и т. д.
Как без конкатенации обходится, если запросы динамические нужны? Где поля select, фильтры where и поля сортировки подставляются по необходимости и prepared statements на них не напасёшься. Либо писать свой велосипед, который будет заниматься конкатенацией, подстановкой переменных и экранированием. Поэтому для стартапа проще взять готовый orm и написать на языке database.table1.where(p => p.field1 == "value").select(x => x.name).orderBy(x => x.name).take(5) чем писать свой велосипед и не заботиться ни о чём.
> Поэтому для стартапа проще взять готовый orm и написать на языке database.table1.where(p => p.field1 == "value").select(x => x.name).orderBy(x => x.name).take(5) чем писать свой велосипед и не заботиться ни о чём.То, что ты сейчас показываешь -- это не ORM, это как раз какая-то обёртка над prepared statement'ами, которая позволяет не тонуть в вопросительных знаках плейсхолдеров, когда их реально много. ORM, да будет тебе известно, это аббревиатура, которая раскрывается как Object Relational Mapping, и это про подход, когда ты начинаешь создавать объекты, и эти объекты, как бы, сами знают как им в СУБД надо записываться и как оттуда читаться. Mapping -- это отображение, а Object Relational нам говорит о том, что это отображение объектов на реляции. То, что ты показал, это просто SQL, но в другом синтаксисе который изоморфен синтаксису SQL. У тебя там нет никакого отображения объектов на реляции.
Дальше можно конечно поспорить, будет ли лучше вот этот "fluid" синтаксис чем SQL в кавычках с именованными аргументами, в стиле:
query("SELECT :name FROM :table WHERE :field == :value ORDER BY :name TAKE 5")
.bind(":name", x.name)
.bind(":field", "value")
.bind(":table", table1)
.execute();Но это, я думаю, будет примерно бессмысленным спором, потому что выбор конкретного способа зависит от возможностей языка. clsql делает это как-то так (если я за давностью лет не забыл это):
(select [name] :from [table1] :where [= field "value"] :order-by [name] :take 5)
clsql это тоже ORM, но не потому что у него есть макрос select, а потому что у него есть целый язык для описания структуры базы данных со всеми реляциями, и потом clsql может генерить довольно сложные запросы со всякими join'ами и прочими вещами, изо всех сил пытаясь создать иллюзию, что работать с базой данных можно так же, как с обычными объектами в памяти. Понятно, что из этого ничего не выходит, но если издалека посмотреть на специально подобранные примеры, то может показаться, что это работает.
Нет это orm потому что table1 это set<myModel1> это класс/структура и когда пишешь x.field1 тебе ide подсказывает названия полей, в варианте с "select ..." ide тебе ничего не подскажет, так как не знает какие поля в таблице, да и вообще имя таблицы ещё даже на написано. И этот подход с orm выберет большинство, потому что он удобнее. В вариантах bind и что-то в кавычках никакая ide тебе не подскажет не то что имя, а даже тип необходимой переменной. Когда ты пишешь "x.field1 == " ide понимает что хочет строку, потому что в модели задано "public string field1;".
В реальной же системе запросы не фиксированные про что я и говорю. Юзер галочку тыкнул и в запрос надо подставить "AND field2 == 2", другую галочку тыкнул и нужно в select подставить ", sum(field2) as amount". Как это будет работать если у тебя запрос фиксированной структуры.
А про велосипеды я тебе говорю такого уровня:
filter = dbHelper.equals("field1", "value1").and(equals("field2", 2))
sort = dbHelper.orderBy.asc("field1")
projection = dbHelper.projection("field1", as("sum(field2)", "amount"))
querySql = dbHelper.select(projection).from("table1").where(filter).sort(sort)
db.execute(querySql)
И в этом случае оно позволит составь запрос с разной структурой на лету в зависимости от галочек и решить проблему инъекций. Только если какое-нибудь поле переименуют или удалят, то тебе нужно будет обойти все запросы и изменить их. В случае с orm проект просто не сбилдится и покажет ошибку "x.field1 поле не найдено".
> Нет это orm потому что table1 это set<myModel1> это класс/структура и когда пишешь x.field1 тебе ide подсказывает названия полей, в варианте с "select ..."Но это же не то, что ты написал. Пример написанный тобою выше, это не ORM, это SQL в другом синтаксисе. Просто ты используешь реализацию альтернативного синтаксиса SQL взятую из ORM.
> В реальной же системе запросы не фиксированные про что я и говорю. Юзер галочку тыкнул и в запрос надо подставить "AND field2 == 2", другую галочку тыкнул и нужно в select подставить ", sum(field2) as amount". Как это будет работать если у тебя запрос фиксированной структуры.
Где ты увидел про "фиксированную структуру" в моих словах? Ты споришь сам с собой, голоса в голове заели? prepared statements это не про "фиксированную структуру", а про то, что значения аргументов надо не экранировать, а передавать по отдельному каналу, чтобы вопрос экранирования даже не вставал бы.
Тебе следует глаза разуть и для расширения кругозора посмотреть по сторонам, какие альтернативы для ORM бывают, и научиться видеть, что есть SQL и что есть ORM. То что в ORM есть альтернативный синтаксис для SQL, не делает этот альтернативный синтаксис объектно реляционным отображением, так же как возможность использовать SQL c ORM не делает ORM из SQL. Если я запилю к текстовому редактору поддержку SQL, укажу ей где лежат стейтменты CREATE TABLE и ALTER TABLE, и научу её подсказывать мне имена полей, когда я SQL запросы в строках пишу, превратится ли такой SQL в ORM?
Глупый вопрос, так ведь? Конечно же не превратится. Потому что ORM это не про поддержку текстовым редактором, это когда ты можешь написать что-то в стиле:
for msg in User::get_by_name("Joe Пупкен").messages {
println!("{msg}");
}Твоя ORM так умеет (вероятно с другими именами методов и ещё какими несущественными модификациями), но если ты этим не пользуешься, обходясь альтернативным синтаксисом SQL, а возможности ORM только для всплывающих подсказок используешь, то я б сказал, что ты тянешь в свой проект депенданс, который гораздо больше и сложнее, чем тебе реально требуется.
> db.execute(querySql)
Оффтоп, но вот по одной этой строчке я готов спорить, что ты пользуешься какой-то ORM, которую запилили в прошлом веке, когда никто не знал, как ORM будут использовать, и при этом никто не понимал, что такое ООП, и как его надо использовать (впрочем, я вижу ещё dbHelper, и я готов спорить, что это из ActiveRecord, что какбэ подтверждает моё мнение о моральной устарелости твоей ORM). Ведь если бы порядок аргументов для execute был бы другой: querySql.execute(db), то затем можно было бы делать вещи типа
let result = Query::select(something)
.where(something_else)
.bind(var, value)
.execute(db)
.map(|row| do_something_with(row));не создавая тысяч промежуточных переменных, и не вкладывая код в код рекурсивно, как это в лиспе принято.
Начнём с того что ORM это object<->relation mapping. Именно маппинг отличает orm от не orm.
В твоём случае если бы это был orm метод выглядел бы так .execute<myModel1>(db). Без этого бы не orm возвращала что-то вроде RowCollection состоящий из object[]. В orm не надо писать свой маппер do_something_with(row), потому что orm и есть маппер табличного результата на тип в коде. Я лишь говорю про то что любой программист предпочтёт orm с подсказками, чем писать куски sql в строках, которые потом не отрефакторишь.
Не знаю про какие альтернативные orm ты говоришь. Я сейчас взглянул на несколько в go, rust, python, php, java, c# и везде есть это синсаксис с методами .filter(table1::name.eq("bob")) или .where('name =', 'bob') отличается только названия методов и используется ли лямбда, статик функция или строка. Разве только в mongo-like запрос похож на json .find({"filter": {"name": {$eq: "bob"}}}).
Prepared statement часто является барьером для оптимизаций плана запроса, потому что без реальных значений бд не может предложить оптимальный план. А то что ты пишешь bind(:name, "value") это лишь умная интерполяция строк.
> В твоём случае если бы это был orm метод выглядел бы так .execute<myModel1>(db).Я думаю, что и без ORM он бы выглядел так, потому что иначе компилятор не знает, какой тип возвращать. Без указания типа будет работать только с динамической типизацией, и да, это не будет никаким ORM'ом, потому что результатом будут сырые строки, которые не будут отмаплены ни на какие типы.
Но простите меня великодушно, это пример придуманный от балды, и это не является ключевой его фишкой. Я хотел лишь указать на разницу в порядке аргументов execute в древних обёртках над SQL и современных.
Занятно, что суть моего этого аддендума ты полностью упустил, вопрос к которому эта суть подводила ты проигнорировал, и вместо этого решил поговорить со своими тараканами.
> Я сейчас взглянул на несколько в go, rust, python, php, java, c# и везде есть это синсаксис с методами .filter(table1::name.eq("bob")) или .where('name =', 'bob') отличается только названия методов и используется ли лямбда, статик функция или строка.
Сколько раз повторять надо? Это всё билдеры запросов. Они используются везде по причинам озвученным тобою выше: конкатенировать строки руками всем западло, и не все запросы фиксированы статически.
> Не знаю про какие альтернативные orm ты говоришь.
Ну я может неудачно выразился. Под "посмотреть" я имею в виду не страничку про ORM википедии пролистать, а взять и написать какой-нибудь хеллоуворлд, по возможности опираясь на бест практисес для выбранного языка/орм. Но, знаешь, я подумал немного, и у меня есть другой совет: "забей". Если ты пользуешься ORM и другие опции тебе неинтересны, пользуйся ORM и дальше. Изучение того, что неинтересно с целью расширения кругозора -- это тяжкий труд. Нужен какой-то интерес растущий изнутри, я отсюда снаружи тебе его дать не смогу. Так что забей.
> Prepared statement часто является барьером для оптимизаций плана запроса, потому что без реальных значений бд не может предложить оптимальный план.
Ссылку в студию. Для меня это заявление выглядит подозрительным. Я не знаток как там внутри реализованы sql, но из самых общих соображений, получается что движку SQL религия запрещает столкнувшись с prepared statement'ом откладывать составление плана запроса до тех пор, пока он не получит значения аргументов. jit компиляторы вполне справляются с тем, чтобы перекомпилировать функции, если они замечают паттерны использования этих функций, которые позволяют дополнительные оптимизации, а SQL что хуже? Поэтому встают естественные вопросы, типа что это за религия, все ли движки SQL эту религию исповедуют, не грешат ли некоторые, отходя от заповедей религии, и тп.
Помимо этого, было бы очень интересно посмотреть на реальные примеры, когда prepared statement'ы делают вещи медленнее. Такие религиозные фанатизмы надо знать и понимать, и поэтому я буду премного благодарен, если ты предоставишь ссылку.
>Где поля select, фильтры where и поля сортировки подставляются по необходимости и prepared statements на них не напасёшьсяА ну вот и представитель рода слабых программистов, который не может в execute (или как там в вашем стеке запрос исполняется) массив значений кинуть. Я писал обертки, которые биндили даже по именам и с типом (на пхп), т.е. вообще муха не пролетит. Еще во времена, когда никаких ларавелов не было. И вся машинерия была в районе пары сот строк, не сложно было.
>проще взять готовый orm и написать на языке database.table1.where(p => p.field1 == "value").select(x => x.name).orderBy(x => x.name).take(5) чем писать свой велосипед
Не надо путать ORM и билдеры, для начала.
По факту джуны и поверх ORM пишут омерзительное нечто, будто напрямую из 2005 года черпая самые уродливые формы. Особенно когда нужен фильтр по подстроке или по дате от-до - о дааа, тут раздолье. Причем, это не пхп, другой язык, вроде зрелый ORM (golang gorm). Выгода есть только для совсем уж сунь-вынь вещей, чтобы сразу коллекции получать (без билдеров нормальных джуны пишут уродливый биндинг моделек в каждой ручке уникальный и копирования из структуры в структуру на ровном месте).
С другой стороны, какой-то сложный запрос поверх ORM написать сложнее, чем на чистом SQL. Иногда получается двойная работа - пишешь сначала SQL, потом переводишь на эту императивщину. Иногда получается чистенькие билдеры написать, иногда нет (с агрегированными данными обычно нет). В результате по всему проектам куча черных ящиков с запросами в полэкрана. Понятно, что параметры биндятся, но это все равно обнуляет плюсы от использования ORM - при изменении моделей придется проверять и переписывать весь этот код.
Скорее бы уже ИИ всех нас заменил. Сил нет это терпеть.
Я не спорю что orm часто выдаёт не оптимальные запросы и сложный вложенный запрос проще и быстрее будет написать на голом sql. Да и кучу возможностей вроде cte и оконных функций orm не умеют. Да именно программисты ленивые и им проще прикрутить уже написанную навороченную orm с большой кучей примеров в документации, чем писать самому велосипед очередной билдер.
>А ну вот и представитель рода слабых программистов, который не может в execute (или как там в вашем стеке запрос исполняется) массив значений кинуть.Задача программиста не в набирании символов, как машинистка, а в том, чтобы писать код без лишних багов и строк.
>Я писал обертки, которые биндили даже по именам и с типом (на пхп), т.е. вообще муха не пролетит. Еще во времена, когда никаких ларавелов не было. И вся машинерия была в районе пары сот строк, не сложно было.Отлично, вы начали изобретать построитель запросов, возможно даже добрались до орма. Только вот зачем, если как вы утверждаете, что орм не нужен?
>Особенно когда нужен фильтр по подстроке или по дате от-до - о дааа, тут раздольеХорошая задача для орма, особенно если подстрока берётся из связей
>Любой, кому приходится писать менее тривиальные запросы, чем SELECT * FROM mytable;Только вот тривиальных запросов на порядки больше. Писать одни только select и insert быстро надоедает.
>Но даже на компилируемом языке возникнут проблемы с тем, чтобы простыми запросами к sql и постобработкой полученных данных обогнать один большой и кучерявый запрос sql, который выдаёт именно те данные, которые тебе нужны. А теперь попробуй сочинить и отладить большой кучерявый sql запрос через посредство какой-нибудь ORM.Как раз для таких случаев есть возможность выполнить сырой запрос, или внедрить неболькой кусочек в построитель.
>в том числе и специфичных для данной реализации SQL, ты не сможешь ею пользоватьсяАга, только в реальных проектах куча проблем чинится простым переходом с mysql/mariabd на postgres.
>Все внешние данные, которые идут в запрос, передаются отдельно и биндятся на переменные, значения которых sql потом использует.У вас какой-то особенный путь использования sql. Я, например, неоднократно писал фильтры, когда если переменная в запросе есть, то нужно добавить условие, если переменной нет - то условие не нужно. Таким образом, сам по себе запрос генерируется в рантайме. Конечно, можно вручную конкатенировать sql код, но гораздо быстрее взять ORM.
>что это либо язычки с API, где сконкатенировать sql-запрос прощеКакой мейнстримный язык позволяет работать с sql как с типизированной сущностью, а не просто с строкой?
>чем подсунуть в prepared-statement значенияВам для начала, нужно получить sql из которого это скомпилированное выражение будет вычислятся.
Вы путаете мокрое с зелёным.
От SQL-инъекций спасает валидация ввода. Она реализована в популярных библиотеках. ORM решает (пытается решать) другую задачу, но, зачастую, базируется на популярынх библиотеках, в которых реализована валидация ввода. Таким образом, заслуги ORM в защите от SQL-инъекций нет.В принципе, ORM - дрянь.
Вы тоже путаете. Валидация ввода не решение sql-инъекций. А вот ORM (или просто использование prepared statement) как раз таки решение.
И что вы собрались валидировать? По вашему строка "Жанна д'Арк" - это невалидная строка?
> разве от sql-иньекций не должны orm'ы спасать?
> кто сейчас руками шлет запросы?На самом деле ORM изначально были созданы в мире java (Hibernate) и потом в дотнете (NHibernate, EF) как библиотеки для написания репозиториев. Идея "Repository" описана в "голубой библии" Domain Driven Design Эванса (обычно пишут DDD), где автор описал работающие в моменте подходы к написанию поддерживаемого кода больших проектов, год это был кажется 1999.
Там среди прочих описывается "Aggregate", как совокупность классов/entity, которые совместно отвечают за свой общий state. Упрощенно все выглядит следующим образом: при появлении любого запроса, управление получает service/command handler, который знает как инстанцировать агрегат с помошью репозитория, передать ему управление, далее репозиторий сохраняет изменившийся state агрегата. И вот для реализации репозитория стали появляться ORM, цель которых была в том, чтобы получив ID одного из entity принадлежащего конкретному агрегату, загрузить весь или необходимую часть агрегата, а после того, как агрегат отработает (и возможно сменит свое состояние), детектировать измененную часть и сгенерить SQL для сохранения этой самой ИЗМЕНИВШЕЙСЯ ЧАСТИ (т.е. в общем случае SQL может генериться разный при сохранении одного и того же агрегата).
Еще раз, возможность работать в качестве тупого SQL builder всего навсего побочный эффект, основная задача того же EF - это инстанцировать/сохраниять по ID целые группы зависимых классов.
Другое дело, что куча недоучек с синдромом Даннинга-Крюгера начинают рассуждать "о неосиляторах SQL", о "leaked abstraction" и т.д., не понимая в принципе почему и зачем все это было сделано.
Не знаю, кто был первым, но Hibernate создан в 2001-м, если верить википедии https://en.wikipedia.org/wiki/Hibernate_(framework)TOPLink был до. https://en.wikipedia.org/wiki/Oracle_TopLink
Toplink was originally developed by The Object People in Smalltalk. It was ported to Java in 1996-1998 and called "TopLink for Java".
На Smalltalk что тогдашний ORM, TOPLink, что нынешний, GLORP, выглядит куда выразительнее и привлекательнее всех этих Hibernate. Тем не менее, даже там проблемы, именно из-за сути ORM как такового.
Одна из проблем - изменение данных в базе. ORM хочет их сперва получить, чтобы обновить. UPDATE ... WHERE ... он не может.
Вторая - реально сложные запросы. Нет, GLORP что-то может делать даже со вложенными запросами (и транслировать их в SQL), но далеко не любыми. А ещё их надо отлаживать, и иногда даже хинты ставить внутрь.
Кстати, для долгоиграющих запросов прямая подстановка параметров вовнутрь запроса именно что требуется. Чтобы оптимизатору SQL-запросов было легче пользоваться статистикой внутри БД. Разница в скорости выполнения запроса может быть огромной.
Rust не видён. Не удивлён.Если не разделять js и type script, то петон не обогнал.
>Rust не видён. Не удивлён.А чему тут удивляться? Разве ж программистов на Питоне и Джаваскрипте заботит производительность там, или качество? Тяп, ляп и в продакшн.
Где ты там в Раст качество увидел?
с растом проходит только тяп... потом ляп сделать не получается и до продакшена не доходит.
Нельзя разделять. Почти все кто пишет на JS, также пишут и на TS. Нужно брать максимальное.
> По числу участниковКто такие участники? С Contributors мягко говоря цифры не совпадают
Ты должен верить Майкрософту.
Абсолютно предсказуемо. Единственный адекватный скриптовый язык для десктопных приложений. (А JS - единственный адекватный скриптовый язык для встраивания в другие приложения)
у тебя десять ошибок в слове Lua
Луа уже лет 10 как на помойке. Её место занял питон, который тоже не торт. Потом - начал просачиваться жс
Не забудь об этом разрабам Роблокса рассказать, а то они не знают про это))
Ну так Луа только для игровых скриптов и годится. Я сильно сомневаюсь, что в Роблоксе на Луа работает что-то кроме пользовательских миров.
>За год зафиксирована утечка через репозитории 39 млн ключей, токенов и прочих секретных данных, забытых разработчиками в коде. Наиболее распространённым типом уязвимостей стали проблемы, связанные с подстановкой кода (например, подстановка SQL-запросов).При этом GitHub продолжает делать доступными удалённые коммиты, в том числе через сеть форков.
Будто бы что-то плохое. Вон винамп подчистил историю коммитов, а вдруг тебе нужен оригинальный проприетарный код? Ты хочешь сделать вид, что ничего не было, но так не получится. Любой твой косяк с утечками приводит к последствиям, нельзя делать вид, что ничего не было.
Это легко объясняется тем что питон единственный нормальный язык.
Для кого? Инопланетян?
Для всех и инопланетян и иноагентов и осьминогов.
Но среди головоногих, Кальмарам C++ нравится.
Интропретаторы уже нормальными стали.
> Это легко объясняется тем что питон единственный нормальный язык.Если все юниверы скармливают студентам питон как первый язык, то совсем не удивительно что он подрос, но в "нормальных языках" все же не делают каk в 2.7 vs 3+
Как раз нет. Просто сейчас стало очень удобно отбирать программистов. Если человек говорит, что для него Питон - основной ЯП, значит говорить больше не о чем и лучше искать другого. А так, был питон нишевым, так им и остаётся. В сущности, кроме хайпа в ML нигде больше не отметился. Да и там сомнителен.
Самый популярный язык? Давайте всех учить? Научат детей плохому, а они потом ОС на Python и js пишут, ога.
Кто о чём, а ты как всегда про Phantom OS.
> Самый популярный язык? Давайте всех учить? Научат детей плохому, а они потом ОС на Python и js пишут, ога.Не важно на чём писать, важно как именно. Выбор языка второстепенен.
Если человек не рубит в математике, не знает теорию программирования, то и кодерок из него никакой в любом языке, даже после сеанса с коучем.
>Выбор языка второстепененНеужели? Застал ещё времена, когда запросы к базе данных в виде циклов на Clipper писали. Подходит ко мне как-то начальник. Говорит, надо написать отчёт. Даёт пару дней, спрашивает справлюсь ли. Я говорю, подождите, пожалуйста, через 5-10 минут будет готово. И создаю запрос на SQL.
>Если человек не рубит в математике, не знает теорию программирования, то и кодерок из него никакойОчевидные вещи говоришь. Вот только не заставляй отдельно учить математику 5 лет, и сократи занятия по теории программирования. Школьного курса хватит, ну а векторам и матрицам можно отдельно выучить, остальная высшая математика не нужна.
>остальная высшая математика не нужнаСмотря где, опять же. Прогнозы погоды банальные. Посмотрим, как у вас это получится без диф. уравнений.
>Смотря где, опять же. Прогнозы погоды банальные. Посмотрим, как у вас это получится без диф. уравнений.OK! Давай, чтобы зря не мучать людей отделим тех, кто будет устраиваться на Прогноз погоды и введём курс диф. уравнений. Остальных оставь в покое ага.
Интересно было бы посмотреть на тебя, когда б ты писал программу для бух. учёта, без малейших представлений о экономических теориях и процессах.
>Интересно было бы посмотреть на тебя, когда б ты писал программу для бух. учётаК сожалению не увидишь, рынок монополизирован 1C и Парусом.
>без малейших представлений о экономических теориях и процессах.
Речь шла о "ненужных дебрях математики", ловко ты так перепрыгнул на экономику. Очевидно, что чтобы создавать Battlefild надо знать историю 2-х Мировых войн и Военное дело.
Кто следующий умник?
Вы там для Госплана замахиваетесь писать, что ли? В 90-е бухучёт многие сами для себя писали, арифметики простой хватало.
>Не важно на чём писать, важно как именно. Выбор языка второстепенен.Выбор языка первостепенен. В одном языке nullptr - это UB, а в другом - ошибка компиляции. В одном языке нужны титанические усилия, и всё равно будет undefined is not a function, в другом - это приниципиально невозможно. Есть хороши и плохие языки.
>Если человек не рубит в математике, не знает теорию программирования, то и кодерок из него никакой в любом языке, даже после сеанса с коучем.Вот позаканчивают свои ВУЗы, и пишут на сях с UB. А всё потому, что голова у них всякой ерундой забита, начиная от философии, истории и физики, и заканчивая какими-нибудь дифференциальными уравнениями. Зато вот как не устроить UB с nullptr они не знают.
Ну это о качестве вузов говорит разве что.
Совершенно верно. ВУЗ прикрывается тем, что учит учится, что бы это не значило, вот студенты и учатся чему попало. Кто философии, кто истории, хотя в итоге по професии им ни тот ни другой предмет не нужен. А профильные предметы проходят бегло и в спешке, чтобы студент ни в коем случае от ерунды не отвлекался.
>Научат детей плохому, а они потом ОС на Python и js пишут, ога.Фабрис Беллар вон успешно написал эмулятор x86 на JS.
Но зачем? Банальный ответ "потому что может" знаю.
>Научат детей плохому, а они потом ОС на Python и js пишут, ога.Где-то я это слышал, хм ... Слушай, ты только не советуй писать на Обероне или Паскале, ага?!
ChatGPT и прочие LLM скоро устроят положительную обратную связь.
Пока им не дают нормального материала для обучения и инструмента для проверки на ошибки - нет. Но как только, то - да, мало не покажется.Важным будет у кого квантовые компьютеры. И инженеры, способные в это.
> у кого квантовые компьютерыОдин из трех пузырей, на которых стоят современные IT. Какой лопнет первым?
Но-но! Квантовые компьютеры очень важны для учёных, т.е. для людей, занимающихся реально полезным делом. Квантовые компьютеры не только для криптографии применяют, но и для моделирования химических реакций. А вот это уже бенефиты и для медицины, и для промышленности.
Так они уже устроили, вон питон вырвался временно на первое место, а нелюбимые чатгопотятами языки выдвигаются на девятый план.
Бpехня, javascript не сместить, он в каждом вебсайте. А питон где, у 3-х калек, занимающихся ИИ?
И казалось бы - отчего бы и нет, что может пойти не так.
Но Питон последнее время явно приводили в порядок и улучшали.
"Почему-то".Может потому, что инструмент хороший для своих задач.
>Может потому, что инструмент хороший для своих задач.best second language для ЛЮБОЙ задачи, что рейтинг и подчеркивает
Не для любой, всё-таки. Некоторые, например, почему-то Lua предпочитают. Другие - shell.
Гораздо логичнее делать весь проект на взрослом языке, чем тащить в него ещё и питон, в котором на каждый вопрос придётся отдельно открывать мануал
33 года вроде достаточно взрослый уже. Впрочем, в этой стране в то время кроме плюсцов и паскаля никто и не знал ни о чём другом. А теперь вот внезапно вылупились в реальный мир.
>Но Питон последнее время явно приводили в порядок и улучшали.
>Может потому, что инструмент хороший для своих задач.Не особо хороший. Параллелизм нормальный отсутствует. Взаимодействие с ОС не всегда на высоте, некоторые библиотеки специальные пишут, потому что стандартная не справляется.
Контроль качества кода никак не поддерживается встроенными средствами, выкручиваться приходится за счёт стилистики (type annotation).
Каких-то конструкций добавили лишних в последние версии, без которых прекрасно жилось ранее, излишне усложняя язык.
Перегрузка операторов - зло (ИМХО).Ну и набившее оскомину программирование отступами, когда тривиальный copy/paste работает через раз.
А ещё очень, очень медленный. Только за счёт библиотек на Си и выкручиваются.
>Но Питон последнее время явно приводили в порядок и улучшали.Что там можно улучшать? Типизации нормальной нет, gil до сих пор есть, емнип лямбды до сих пор только однострочные.
Скриптота же. Плюс веб.
youtube и instagram на питоне.
омайга! теперь понятно почему интефейс ютуба иногда подтормаживает.
открой в браузере тулзы разработчика и покажи нам, где там питон
Я думал гитхаб в китае заблокирован.
Это было бы: мухи против мёда. А Китай зело умён. Вангую, что лазейки к образованию и информации о технологиях оставляет, заботясь о кадрах для развития и о развитии.
> заботясь о кадрах для развития и о развитииЕсли так, нужно заблокировать ГХ навсегда. Как и остальные ресурсы МС, впрочем.
Постоянных разработчиков в GitHub уже 100 миллионов. GitHub может конкурировать с Коммунистической партией Китая (КПК). Согласно Википедии, по состоянию на 31 декабря 2022 года, КПК насчитывала 98,041 миллиона членов и 4,936 млн низовых организаций партии, что делало её крупнейшей партией на планете.
В огороде бузина а в киеве дядька.
А может это КПК и попросила всех партийных зарегистрироваться?На миллиардной попытке сервер Пентагона согласился, что у него пароль МаоЦзэдун
>КПК насчитывала 98,041 миллиона членов и 4,936 млн низовых организаций партии, что делало её крупнейшей партией на планете.Неизвестно, сколько из 98,041 миллиона бритых членов и волосатых членов. Средний размер члена партии КПК тоже неизвестно.
>4,936 млн низовых организаций партии
Ого! 4 млн. борделей?!
Больше впечатляет, что bash - C обогнал...
не впечетляет
и даже не то, что он С обогнал...Просто напомню, как Одмины системД проповедовали, что они как выучат 1000 ключей INI-файлов, дак выгонят дидов с их скриптотой и никому оно и не нужно будет...
Более 10 лет прошло... а вот оно как...
Откройте тот же самый NixOS, с systemd внутри, и посчитайте количество всяких обвязок на perl и bash. У вас будет юнит файл, и пара-тойка bash файлов на него. Зато скриптов стиле SysV вы там не найдёте.
заметь, я про SysV не писал...
Ну так дидов уже изгнали.
на си банально меньше кода нужно по сравнению с js, чтобы сделать одно и то же
Ну конечно. То-то Сишники в каждой программе велосипеды изобретают, типа dictionary или чего-то похожего.
Достаточно представить, как на сишке будет выглядеть аналог "str2 = str1.trim()" и прочие манипуляции со строками.
Больше кода, чем на си, нужно разве что на ассемблере (от которого си, впрочем, недалеко и ушёл).
> (от которого си, впрочем, недалеко и ушёл).Далеко. У него началось раздвоение личности во время первого стандарта.
С одной стороны, он славился как portable assembler низкоуровневой работой с железом.
С другой стороны, тогда в него добавили понятие UB и оптимизации, ведущие к UB при попытках слишком низко залезть на стандартном C (например, стандартный C не позволяет написать свой malloc).
> С другой стороны, тогда в него добавили понятие UB и оптимизации, ведущие
> к UB при попытках слишком низко залезть на стандартном C (например,
> стандартный C не позволяет написать свой malloc).Это еще почему? Операциями с указателями то - без особых проблем. Но фактическое выделение памяти кроме простейших случаев типа бутлоадера с примитивным аллокатором - ос делает, и тут все же придется узнать про ее сисколы и как оно там памятью управляло.
> Это еще почему?Э-э-э, потому что пример в скобках относится к предложению, в котором он находится: "оптимизации, ведущие к UB".
Функция-аллокатор возвращает void*, мы к нему обращаемся через MyType*, но слишком умный компилятор может разузнать, с чего начинается цепочка ???*->void*->MyType* и заметить нарушение strict aliasing rule в ???->MyType (тип ??? может алиаситься только с самим собой, с char и с чем-то там ещё, иначе behavior is undefined).
Наверное, он может решить, что ??? это __freelist или MyRecentlyFreedType. А UB в худшем случае компилятор может расценить как невозможное событие и скомпилировать в ничто.
Если эти предположения кажутся чепухой, замечу, что clang++ способен[1] при виде бесконечного цикла удалить его нафиг и вызывать вместо него какую-нибудь функцию (смысла в этом нет, но стандарт разрешает). И что существует __attribute__ ((malloc)).
> ос делает, и тут все же придется узнать про ее сисколы
"слишком низко залезть на стандартном C", никакой ОС нет, мы и есть ОС.
самофикс:> И что существует *нестандартный* __attribute__ ((malloc)).
> По числу разработчиков, которые первый раз приняли участие в разработке открытых проектов, лидируют проекты... java2bedrock.shЭто какая-то ошибка или что? У этого скрипта 4 контрибьютора и последний коммит год назад.
это реклама майнкрафта, который принадлежит майкрософту
> Это какая-то ошибка или что? У этого скрипта 4 контрибьютора и последний
> коммит год назад.Welcome to Microsoft (R) Trash (tm) rating! Enjoy your time!
Всё меньшему количеству людей надо добавлять анимацию на веб-страницы.
Ой, я не доверяю этой рекламе. Статистика эта - чистый маркетинг компании Microsoft. Очень печально, очень что так можно манипулировать людьми.
Есть масса языков объективно лучше Python, но публика зачем-то настойчиво к нему тянется. Скорость выполнения приложений, написанных на Python, — вообще позор. Удивительно.
Ну а на чём лучше писать, на PHP? Так на питоне приятней.Ну и если пилить что-то по фану, так лучше как раз на языке, хорошо пригодным для создания прототипов, написать прототип/mvp, а когда будет очевидно что идея взлетела, можно нанять мaкaк чтобы переписали на Java/Rust или что там сейчас котируется среди з-тов.
>Ну а на чём лучше писать, на PHP?Да хотя бы на php.
>Ну и если пилить что-то по фану, так лучше как раз на языке, хорошо пригодным для создания прототиповВ чём эта пригодность заключается? В том, что даже небольшой рефакторинг - это куча неотловленных багов? Или в том, что указания типов игнорируются питоном?
x: str = 1
print(x)
> Ну а на чём лучше писать, на PHP? Так на питоне приятней.Сложно назвать языки, на которых было бы противнее писать, чем на питоне. Для веба - однозначно JS/TS. Просто чтобы фронт/бак были на одном и том же. TS по сложности - блондинка за вечер разберётся. Зато читаемость куда лучше Питона.
А вот питону сложно найти применение. Ни в каком случае, прототип, которые написали на чём-то более современном, чем Питон, на Питон переписывать никто не будет. Ни в случае Julia для математики / ML, ни в случае Rust, Java, Kotlin и пр. То есть, Питон - чисто школьно/студенческий язык без полезного применения в проде.
>Сложно назвать языки, на которых было бы противнее писать, чем на питоне.Легко, на самом деле: ksh, Perl.
>А вот питону сложно найти применение.
Хотя я и не большой любитель Питона, статистика говорит об обратном.
> Хотя я и не большой любитель Питона, статистика говорит об обратном.Статистика по использованию языков в вебе говорит о том, что востребованность питона - 1.3 процента. И вряд ли будет больше....
https://w3techs.com/technologies/overview/programming_language
Кроме как в вебе, программирования нет.
Статистику в прочих областях собрать сильно сложнее. И, тем не менее, питону нет места в программировании за пределами учебных заведений и некоторых исследовательских проектов.
Ну тогда эта ваша статистика, как аргумент, ничего не стоит. Соответственно, и утверждение остаётся на уровне ИМХО.
Кстати, по той же ссылке у сишечки 0,003%.
Вопросы задавайте абоненту "Прохожий (??)". Откуда у него другая статистика.
1c
> Просто чтобы фронт/бак были на одном и том же.Бессмысленное требование. Если проект большой, то один фиг над бэком и фронтом будут работать разные команды. Если это из надежды что в перспективе можно будет отдать пилить бэк фронтовику, ой, я вас умоляю, им это не интересно. По факту наоборот зачастую фронт приходится подпиливать бэкендщикам самостоятельно, когда надо какую-то логику на фронте реализовать/исправить. Ну а бэкендщикам обычно пофиг, не фулстак бэкендщиков не бывает, кто дорос до мидла хотя бы.
Нет, лучше идти за мейнстримом создания искусственного интеллекта СГА. Приспособленцы найдут 1000 и 1 оправдание почему это лучше. Тьфу!
Не, ну понимаю если бы были объективные причины, тогда он был бы и раньше более популярен, но идти постоянно за деньгами - как осел за морковкой.
> Есть масса языков объективно лучше PythonИ эти языки годятся для mvp? Имеют библиотеки для чего хочешь? Их знает каждая собака? Заносите же их в студию. Мы все хотим на них посмотреть.
>Имеют библиотеки для чего хочешь?А на питоне эти библиотеки из воздуха взялись?
>Их знает каждая собака?Питон все с рождения знают?
Популярность питона - самоподдерживающаяся ценность. Влили в него деньги, вот он и популярен. Никаких других плюсов, кроме огромного количества влитых денег у питона нет.
>>Имеют библиотеки для чего хочешь?
> А на питоне эти библиотеки из воздуха взялись?Эмм. Не важно. Важно, что они есть. Почит под любую задачу.
>>Их знает каждая собака?
> Питон все с рождения знают?Вероятность, если взять человека до 18 лет и он знает питон выше, чем любой другой язык.
> Популярность питона - самоподдерживающаяся ценность. Влили в него деньги, вот он и
> популярен. Никаких других плюсов, кроме огромного количества влитых денег у питона
> нет.Это не обсуждается. Обсуждается почему он популярен. А плюсы я описал в 3 вопросах выше. Если есть такой же ЯП, то прошу предоставить.
>Это не обсуждается. Обсуждается почему он популярен.Так это и есть причина. Вначале в язык влили деньги, потом на эти деньги его начали рекламировать и писать под него библиотеки, вот он и стал популярным. Гугл влил деньги в питон - питон популярен. Гугл влил деньги в голанг - голанг популярен. Гугл не влил деньги в паскаль - паскаль не популярен. В самом питоне/голанге нет ничего, что бы его возносило над другими языками, кроме влияния гугла и других богатых корпораций.
>Вероятность, если взять человека до 18 лет и он знает питон выше, чем любой другой язык.Почему я должен ориентироваться на тех, кому нет 18?
>Эмм. Не важно. Важно, что они есть. Почит под любую задачу.Важно то, что если библиотеки писать, то они будут, под любой язык. И язык нужно выбирать по фичам, философии, и пригодности для какой-то цели, а не потому, что его расхайпили
>>Это не обсуждается. Обсуждается почему он популярен.
> Гугл не влил деньги в паскаль - паскаль не популярен.Наследники Паскаля, такие как Ада и Оберон, во некоторых областях, где требуется надежность, ой как популярны.
>>Вероятность, если взять человека до 18 лет и он знает питон выше, чем любой другой язык.
> Почему я должен ориентироваться на тех, кому нет 18?Зачем тогда задавать глупый вопрос про знание яп с рождения?
>>Эмм. Не важно. Важно, что они есть. Почит под любую задачу.
> Важно то, что если библиотеки писать, то они будут, под любой язык.
> И язык нужно выбирать по фичам, философии, и пригодности для какой-то
> цели, а не потому, что его расхайпилиЕще раз скажу, что речь не о том, что можно. Речь об уже установленных вещах.
>Зачем тогда задавать глупый вопрос про знание яп с рождения?Затем, что огромное количество людей старше 18 тоже программируют. И им всё равно, какой там язык первым преподают в школе.
>Гугл влил деньги в питон - питон популярен. Гугл влил деньги в голанг - голанг популярен.Гугл влил деньги в дарт и дарт не популярен.
> Влили в него деньги1) кто и
2) почему и зачем?
Тот же Nim.
Синтаксис — и блондинка разберётся. Скорость выполнения как у Си-приложений.
> Тот же Nim.
> Синтаксис — и блондинка разберётся. Скорость выполнения как у Си-приложений.Важен не только синтаксис, но и семантика, а она у Nim явно сложнее. С популярностью у него явно проблемы.
>Важен не только синтаксис, но и семантика, а она у Nim явно сложнееНельзя вечно бегать от сложности. Есть Rust/Haskell/Ocaml/любой другой язык из ML семейства. Там компилятор активно помогает программисту, активно указывает на ошибки. И есть всякие нимы и питоны, где компилятор/интерпретатор простой, но и программист наедине со своими и чужими ошибками.
>>Важен не только синтаксис, но и семантика, а она у Nim явно сложнее
> Там компилятор активно помогает программисту, активно указывает на ошибки.Зачем это все в mvp? Надо быстренько накидать и запустить, посмотреть как работает, подправить и так по кругу. Опять таки Ocaml и ML узкоспециализированные инструменты. Надо GUI нормальный для задачи, например? Его нет. А rust к ML достаточно издалека относится.
>Зачем это все в mvp?Нет ничего постояннее временных решений. Практика показывает, что после того, как mpv достиг какого-то результата, никто не выкидывает этот питон к чёртовой бабушке, наоборот, этот питон лезет из всех щелей, даже там, где он объективно не нужен. А потом ставишь условый mint mate, а там меню на python написано. Это что за mpv такой, что из релиза в релиз кочует?
>Надо быстренько накидать и запустить, посмотреть как работает, подправить и так по кругу.Хиндли-Милнер в помощь, благодаря нему код с статической типизацией содержит в себе меньше аннотаций типов, чем python с динамической
>Надо GUI нормальный для задачи, например?Биндинги для Qt, Gtk, Tk и прочего есть почти для любого языка.
>А rust к ML достаточно издалека относится.Rust ML + афинные типы + си подобный синтаксис.
> А потом ставишь условый mint mate, а там меню на python написано. Это что за mpv такой, что из релиза в релиз кочует?Кто тебе сказал, что это mvp? И в чем проблема с питоном в этом месте? Например, конфигуратор для compiz тоже на питоне. С этим нет никаких проблем.
>И в чем проблема с питоном в этом месте? Например, конфигуратор для compiz тоже на питоне.Проблема в том, что из-за питона(и не только) софт разбухает. А питона становится очень много, так как на нём пытаются писать буквально всё. Быстрый jit для питона пока ещё не осилили, но даже если и осилят, то по потреблению оперативной памяти питон никогда не приблизится к компилируемым языкам из-за динамической типизации.
>>И в чем проблема с питоном в этом месте? Например, конфигуратор для compiz тоже на питоне.
> Проблема в том, что из-за питона(и не только) софт разбухает. А питона
> становится очень много, так как на нём пытаются писать буквально всё.Никто не пытается в том же mate писать все на нем. Просто написали конфигуратор.
> Быстрый jit для питона пока ещё не осилили
pypy
Но в случае с биндингами для gtk он не поможет никак.
> Хиндли-Милнер в помощь, благодаря нему код с статической типизацией содержит в себе меньше аннотаций типов, чем python с динамическойОй, похоже ты об этом в википедии только прочитал. Тебе сами окамлисты скажут, что часто лучше явно указывать типы. Также раст, который ты как рас приводил в пример, как раз таки требует явных деклараций типов в сигнатурах для улучшения читабельности. А локальный вывод типов сейчас везде почти есть, в том числе и в mypy и pyright.
>Тебе сами окамлисты скажут, что часто лучше явно указывать типыНи разу не видел, чтобы в окамле указывались все типы везде, как например, в ранних версиях java, где Борщ борщ = new Борщ();. Иногда указывают на top level, но это по желанию.
>Также раст, который ты как рас приводил в пример, как раз таки требует явных деклараций типов в сигнатурах для улучшения читабельностиВ расте это обязательно на top level, в замыканиях - нет.
>А локальный вывод типов сейчас везде почти есть, в том числе и в mypy и pyright.Да, да, конечно. Вот есть код
val map : ('a -> 'b) -> 'a list -> 'b list
Окамл может вывести тип этой функции полностью, только на основе её тела. В питоне сложности начнутся уже на 'a -> 'b, тем более на том, чтобы связать первый аргумент со вторым.
>>Тебе сами окамлисты скажут, что часто лучше явно указывать типы
> Ни разу не видел, чтобы в окамле указывались все типы везде, как
> например, в ранних версиях java, где Борщ борщ = new Борщ();.
> Иногда указывают на top level, но это по желанию.
>>Также раст, который ты как рас приводил в пример, как раз таки требует явных деклараций типов в сигнатурах для улучшения читабельности
> В расте это обязательно на top level, в замыканиях - нет.pyright тоже выводит типы для лямбд.
>>А локальный вывод типов сейчас везде почти есть, в том числе и в mypy и pyright.
> Да, да, конечно. Вот есть код
> val map : ('a -> 'b) -> 'a list -> 'b list
> Окамл может вывести тип этой функции полностью, только на основе её тела.
> В питоне сложности начнутся уже на 'a -> 'b, тем более
> на том, чтобы связать первый аргумент со вторым.Я говорил, про типы переменных внутри функций. Что ты мне пытаешься доказать? Питон или раст отказались от автовывода в сигнатурах и считают это ок. Не вижу проблем, чтобы тип указать. На ревью проще.
>pyright тоже выводит типы для лямбд.Да, да, конечно. Если язык не проектировался под это изначально, то у вас либо вывод типов не будет работать в любых нетривиальных случаях, либо будет многострочный ужас, которым пользоваться невозможно. Это уже не говоря про то, что ocaml - на 100% статически типизирован уже в момент компиляции, а в питоне - только если в проекте есть эта утилита, и её не забыли вызвать перед коммитом. Во время выполнения аннотации игнорируются, что делает питон ещё хуже чем тот же php, где это будет ошибкой времени выполнения
>Питон или раст отказались от автовывода в сигнатурах и считают это ок. Не вижу проблем, чтобы тип указать.И тем не менее, писать код на окамле проще, за счёт вывода типов, по сравнению с растом. А вот питон мало того, что переобулся в воздухе, введя типизацию, так ещё и сделал её бесполезной и многословной.
>а в питоне - только если в проекте есть эта утилита, и её не забыли вызвать перед коммитомИ при этом всё равно достичь 100% типизации в питоне будет проблематично, если вообще возможно
>>а в питоне - только если в проекте есть эта утилита, и её не забыли вызвать перед коммитом
> И при этом всё равно достичь 100% типизации в питоне будет проблематично,
> если вообще возможноЭто странная самоцель. Главная цель, чтобы софт работал и просто было вносить изменения. Можно вообще просто файл с декларациями для модуля без них написать и спокойно пользоваться.
А так включаешь опцию в mypy, чтобы были ошибки, если тип не объявлен и добавляешь типы, чтобы было 100%.
> Во время выполнения аннотации игнорируютсяОни доступны. Если хочется, то можно проверять. Например, так делает pydantic.
> в питоне - только если в проекте есть эта утилита, и её не забыли вызвать перед коммитомНе надо забывать. А еще лучше комитить через пул реквесты с CI. Так можно в любом компилируемом языке забыть прогнать тесты. Так что не аргумент.
> А вот питон мало того, что переобулся в воздухе, введя типизацию,Он как был динамически типизированным, так и остается. Аннотации были введены в певрую очередь как альтернатива документации для типов.
> так ещё и сделал её бесполезной
Что значит бесполезной? Все больше проектов ее использует и успешно. Если бы она была бесполезной, то не использовали бы.
> и многословной.
Такая же как в других мейнстримовых языках. Тем более ее дальше улучшают, например, в плане синтаксиса указания аргументов шаблонов.
> Биндинги для Qt, Gtk, Tk и прочего есть почти для любого языка.Ну сырые биндинги может и есть. Ты давай покажи мне реальный пример на окамле гуя окромя ризонмл в браузере. Этот язык применяется либо для разработки прототипов компиляторов и пруверов. Все. Ну есть ещё контора одна, которая использует в трейдинга. Это узкоспециализированный язык.
Для питона просто куча примеров в том же десктопное линуксе.
>Ну сырые биндинги может и естьА у питона что, кроме сырых биндингов?
>Ты давай покажи мне реальный пример на окамле гуя окромя ризонмл в браузереНапример, Onivim 2. Это без учёта всяких электронов.
>Это узкоспециализированный язык.Это полноценный тьюринг полный язык, этого достаточно.
>>Ну сырые биндинги может и есть
> А у питона что, кроме сырых биндингов?У питона они не сырые. Пользуют в проде их. Покажи мне нормальное приложение на rust-qt или rust-gtk.
>>Ты давай покажи мне реальный пример на окамле гуя окромя ризонмл в браузере
> Например, Onivim 2. Это без учёта всяких электронов.Ты его использовал? Что oni, что revery околомертвые проекты.
>>Это узкоспециализированный язык.
> Это полноценный тьюринг полный язык, этого достаточно.Ну тогда ты и на брейнфаке можешь писать. Или даже на машине Тьюринга. Возьми многоленточную, чтобы не мучаться. Хотя вот знаешь, почему ты вспоминаешь Тьюринга, а не Черча у меня вопрос. Вроде за ML топишь. Не настоящий сварщик?
> Rust ML + афинные типы + си подобный синтаксис.Угу, а Питон наследник лиспа
на вскидку, 2/3 новых питон приложений -- это дёрнуть методы какого-нибудь pytorcha (или на чем там сейчас AI пишут, http-запросы к апи чата гопоты ?), от питона тут скорость не требуется вообще.
> на вскидку, 2/3 новых питон приложений -- это дёрнуть методы какого-нибудь pytorcha
> (или на чем там сейчас AI пишут, http-запросы к апи чата
> гопоты ?), от питона тут скорость не требуется вообще.И чсх через пару лет про 2/3 этого барахла никто и не вспомнит.
Ага, а на сишечке-то (к примеру) сплошь бриллианты, под стеклом хранить для истории.
Приложения — это не ШЕДЕВРЫ какие-нибудь (хотя, безусловно, таковыми быть могут), они для того, чтобы решать задачи.
> Ага, а на сишечке-то (к примеру) сплошь бриллианты, под стеклом хранить для
> истории.У меня таки есть коллекция своих "бриллиантов". Например кот Рида Соломона который бегает даже на маленьком мк, даже на атмеге голимой. Или очень маленькие и аккуратные декомпрессоры. Так что даже на системе с склерозом вместо памяти - работает.
Но, конечно, эти бриллианты не на питоне. На питоне такое будет бессмысленно и беспощадно.
> Приложения — это не ШЕДЕВРЫ какие-нибудь (хотя, безусловно, таковыми быть могут),
> они для того, чтобы решать задачи.С учетом периода полураспада - это в основном 1-разовые страдания фигней.
Никакого "объективно" не существует в принципе. Все субъективно, включая отношение к языкам программирования.
- Сетевой эффект. Публика тянется, потому уже притянулось много.- А раньше что публику натянуло? Например, стандартная библиотека ("batteries included") и сторонние тоже - матлабоподражающим либам по 20-30 лет.
- А в 90-е почему они пошли переписывать эти ваши матлабы не на X, а на питоне? Потому что язык оказался в достаточной степени подходящим, без заскоков, без узкой специализации. Комплексные числа на уровне языка и всё такое. Какая-то книжка из 90-х с отрывком про "почему питон": https://books.google.ru/books?id=sN0J6dNnrkkC&pg=SA23-PA8
> А в 90-е почему они пошли переписывать эти ваши матлабы не на X, а на питоне? Потому что язык оказался в достаточной степени подходящим, без заскоков, без узкой специализации. Комплексные числа на уровне языка и всё такое.У того же лиспа с числовыми типами еще лучше. А он гораздо раньше 90-х появился.
Придётся пожертвовать синтаксисом гомоиконичности((((((((И ради чего?
- Лисп был на волне ИИ-хайпа, но к середине 90-х она закончилась.
- Годные идеи из функциональщины тогда стали тянуть в императивные языки.
- С перегрузкой дела обстоят плохо, бесплатноматлаба не получится, вместо a*b в Common Lisp'овых матричных либах пишут так: "clem::mat-mult a b", "magicl:mult a b". На вопрос о "перегрузке" плюса на stackoverflow рассуждают как о странном упражнении: https://stackoverflow.com/questions/25152029/override-overlo...
fixed: Придётся пожертвовать синтаксисом *ради* гомоиконичности))))))))
На питон бросились переписывать математику ближе к середине 10-х. До этого научные сотрудники жили в Java и R. В 90-х и 2000-х писать математику на питоне - это был удел уж совсем отщепенцев. А после середины 10-х самые продвинутые перешли на Julia. А удобным питон провозгласили уже в 20-х годах под тему машинного обучения и нейросетей. Не то, чтобы он был лучше других или удобнее в этих областях, но кому-то очень надо пустить отрасль под откос и забыть об эффективности работы программистов и исполнения программ.
> До этого научные сотрудники жили в JavaА по ночам надевали пиджаки и тайно от тебя писали банковское ПО.
- Идея языка-клея нормально себя показывает
- NumPy в том или ином виде существует 20-30 лет
- MATLAB продолжает жить, как и необходимость в бесплатной замене ему
- У Julia прав на существование точно меньше, чем у питона. NIH-синдром и провал заявленной цели ("solve the two language problem").
> На питон бросились переписывать математику ближе к середине 10-х. До этого научные
> сотрудники жили в Java и R. В 90-х и 2000-х писать
> математику на питоне - это был удел уж совсем отщепенцев. А
> после середины 10-х самые продвинутые перешли на Julia.Какие-то может пруфы предоставлены будут?
Корректно: ИИ сместил JavaScript с позиции самого популярного языка на GitHub.
У Microsoft JScript, а у Google - Node. У кого JavaScript и у кого GitHub рассказывать нужно?
> У Microsoft JScript, а у Google - Node. У кого JavaScript и
> у кого GitHub рассказывать нужно?Нужно. Пожалуйста, расскажите.
А раньше такой новости не было. Просто выгодно стало. Можете минусовать и дальше, рассказывая и оправдывая свои бредни.
> А раньше такой новости не было. Просто выгодно стало. Можете минусовать и
> дальше, рассказывая и оправдывая свои бредни.Лично я ничего не минусую. В последнее время только зритель, который пытает не отрываться от общества.
Ну, гитхаб не показатель. Надеюсь они там не учитывали кучу мусорных форков проектов, кучу мусорных проектов и кучу всяких хелловордлов?
> не учитывали кучу мусорных форков проектов, кучу мусорных проектов и кучу всяких хелловордловТо, что Вы перечислили, хотя бы к программированию относится. Но на ГХ еще не то есть. Например, попадались разбор куска какой-нибудь [псевдо]научной статьи или страница из документации не поймешь к чему. К программированию вообще не имеющие отношения. Благодаря, видимо, МС ресурс превращен в большую помойку.
> ресурс превращен в большую помойку.А с этим нет никаких проблем, никто не заставляет всё подряд там смотреть, это всего лишь сервис, можешь пользоваться, можешь не пользоваться, все счастливы. Интернет тоже большая помойка, просто ходим только туда, где хорошо (ну, контингентом, лишённым свободы выбирать куда ходить, можно пренебречь).
> ну, контингентом, лишённым свободы выбирать куда ходить, можно пренебречьУгу, ясно. Расскажите что вы за свободку, но только для себя
А то как же. А так же кучу домашних заданий, куросовых, тестовых заданий и прочего и прочего
Не знаю чего все в этом питоне нашли
Даже javascript выглядит лучше, у него хотя-бы используются старые добрые фигурные скобочки, есть явное объявление переменных (var/let) и нет мерзкой зависимости от отступов и табов/пробелов.
> Не знаю чего все в этом питоне нашлиДеньги на желающих изучить. Поскольку из каждой кофеварки звучит "учите питон", народ реально начинает думать, что это кому-то надо. Несёт деньги на курсы. Поднимает рейтинг блоггеров. Потом пытается искать работу на нём. Если не получается, то просто всем вокруг рекламирует как это круто... Пирамида...
>есть явное объявление переменных (var/let)Нет. Если let не указывать, переменная всё равно создастся.
>>есть явное объявление переменных (var/let)
> Нет. Если let не указывать, переменная всё равно создастся.Это не strict mode в <= es5. В strict mode (а модули его используют) будет ошибка.
Более склонного к багам языка как JavaScript еще поискать. Рожденный ползать - летать не может.Python хоть более менее может выдавать ошибки (правда во время выполнения, но современные IDE подсвечивают ошибки еще при написании). Python сразу заставляет мыслить структурами данных и развивать мозги, а не простыми переменными и массивами.
Не скажу, что Python идеален, но по сравнению с JavaScript намного лучше.
Хотя я предпочитаю компилируемые языки. Хотя... Python 3.15 обещают компилируемым.
> Более склонного к багам языка как JavaScript еще поискать. Рожденный ползать -
> летать не может.
> Python хоть более менее может выдавать ошибки (правда во время выполнения, но
> современные IDE подсвечивают ошибки еще при написании).Использую mypy или pyright и будет выдавать до.
> Python сразу заставляет мыслить структурами данных и развивать мозги, а не простыми переменными и массивами.
Кто тебе мешает мыслить также в js? Там также есть Map и Set и разные структуры данных в npm.
> Хотя я предпочитаю компилируемые языки. Хотя... Python 3.15 обещают компилируемым.
Шта?
> Шта?JabaScript coder detected. Почитай https://www.opennet.me/opennews/art.shtml?num=62009 и сделай интреполяцию на следующие версии (дополнительно можешь использовать знания о Mojo, конечно, если они у тебя есть)
Как джит сделает его компилируемым? Путаешь AOT с JIT? Штош. Садись, два. Ну если так рассуждать, то он с самого начала компилируемый в байт код виртуальной машины.Причём тут mojo? Зачем ты скачешь с пятого на десятое, это вообще другой яп.
Согласен, не всем дано смотреть на шаг вперед, не всем. Например, тебе.
Сколько времени питонисты грезят о том, что вот-вот питон как начнёт работать быстро, да как всех порвёт? Лет десять? Лет двадцать? С самого появления питона? Да за это время уже можно было питоноподелки переписать на условный go/rust/ocaml/ещё какой-нибудь вариант и горя не знать.
> Более склонного к багам языка как JavaScript еще поискать.python есть. Они там вообще ошибки не чинят, а сразу с нуля переписывают
> Даже javascript выглядит лучше, у него хотя-бы используются старые добрые
> фигурные скобочки, есть явное объявление переменных (var/let) и нет мерзкой
> зависимости от отступов и табов/пробелов.У них много общего
1) Low entry barrier.
2) Програмеры под стать, их вечно хочется придушить, за завалы тормозного глючного гуано.
3) Динамическая типизация и отсутствие статического анализа + недостаточная аннотация намерений кодера означают что большую часть ошибок вы получите в рантайме.
4) И при том зачастую - не там где они реально произошли.
5) Поскольку програмер едва понимал что делает, счастливой ему отладки в этом случае.
6) Хотя обычно оказывается что это был write only код и програмер предпочел сказать неудачнику "чини сам!".
7) Неудачник посмотрев в жесткое спагетти решил что ему проще, нахрен, с ноля переписать.
8) По этой причине период полураспада редко превышает 2 года.Ну вот как-то так. Война остроконечников с тупоконечниками получается.
> Не знаю чего все в этом питоне нашлиЭто такой любопытный эффект. Пэйфон стал популярен благодаря огромному количеству курсов по пэйфону, которые открывали из-за популярности... Короче, загадка про яйцо и курицу.
Но в итоге имеем что имеем. Огромное количество бездарных дебилов, которые "вкатились в айти" и пишут на пейфоне. Ужас, аж самому страшно
но ведь javascript, typescript и java это одно и то же, зачем разделили?
> но ведь javascript, typescript и java это одно и то же, зачем
> разделили?Скорее всего тоже самое, что и в биткоин хардфорк. Иначе говоря, был только биткоин, внесли существенные изменения в блокчейн и сеть разделилась. Одну оставили для биткоин, а со второй что-то надо делать. Получился форк по независящим от разработчиков причинам.
Хардфорк — это, простыми словами, способ внедрения фундаментальных изменений в архитектуру протокола блокчейна. Термин произошел от слова «fork», что в переводе с английского означает «разветвление» или «вилка».
Вот вот 40 лет ума нет
Примерно как C, C++ и C#, да.
JavaScript ближе к Java
ЯП - это как автомобиль, кто за рулем, так и поедет. Точка.
Но нужно ведь решить, что лучше — самосвал, малолитражка или автобус!
Время JavaScript пришло к концу, прошло время Великого Python!
Запомни чувак! Вердикт даёт TIOBE.
> прошло время Великого Python!Ага! Только GitHub совсем не показатель популярности языка. Там куча Pet проектов.
А с вакансиями совсем грустно. Почему-то мало кто из работодателей желает платить за Пайтон.
> Ага! Только GitHub совсем не показатель популярности языка. Там куча Pet проектов.
> А с вакансиями совсем грустно. Почему-то мало кто из работодателей желает платить за Пайтон.Ты хотел чтобы платили за low entry barrier хреновину для написания макетов? Когда чатгоп генерит код не сильно хуже? Ага, заплатят. За подписку на чатгопы и копилоты.
GitHub нельзя верить. Какой-нибудь usememos с 30к звёзд обгоняет легендарный DokuWiki.
> с 30к звёздНе твои, вот ты и бесишься.
Китай скоро вылетит из списка. Они активно переходят на гитхаб от Хуавей.