c++ это пожалуй один из немногих популярных языков, где поддерживаются практически все современные парадигмы программирования, и при этом - он компилируемый. Такими свойствами, управляемые языки не обладают
Как это не обладают? Шарп компилируемый и мультипарадигменный язык высокого уровня. И функциональная парадигма у него более развита, чем у c++. Да, у него нет темплейтов, зато есть рефлекшен.
Рантайм шарпа тоже шаред, если не селфконтейнить и не компилить в нейтив. Здесь уже вам самим выбирать, поставлять вашу версию с дистрибом или требовать её наличие на целевой машине. Другими способами эта дилема не решается.
Во вторых, в дотнете нет виртуальной машины. jit-компилятор есть, он используется, если не комплировалось с native aot. А дальше работает скомпилированный машинный код. Без виртуализации. Без ограниченной среды. Рантайм дальше это уже просто набор библиотек.
Получаешь кучу неотловленных багов. Предыдущая система писалась 3 года и я думаю, что все три года она обкатывалась. У вас за 8 месяцев сделан только функционал, без обкатки.
А ещё вы этим стеком неизбежно добавили все вот эти приколы плюсов вроде мемликов, UB и прочих out-of-range. Это прямо целый пласт ошибок, которых в шарпе просто нет в силу его management природы.
Я ни в чём не собираюсь вас убеждать. Просто наслаждайтесь выбором.
Шарп тоже компилируемый язык и даже весьма оптимизированный. Вот зачем в складской программе +20% (в лучшем случае) производительности гуя, если там всё равно в базу данных упрётся? Ну серьёзно?
А кто-нибудь подумал, за счёт чего эта производительность достигается? Вот эти все UB и отсутствие bound-check да, дают небольшой прирост. За счёт, внезапно UB и out-of-bound. Наслаждайтесь выбором, называется.
--SelfContained и у вас нет внешних зависимостей. -p:PublishAot=true - и у вас на выходе бинарник как в плюсах. dotnet add package Avalonia и у вас кроссплатформенный UI с синтаксисом WPF, с поддержкой Native AOT и работающий на любом линуксе, где есть гуй.
Не работает так. Чтобы попасть в "клуб трёх запятых" нужно рисковать и рисковать сильно. Это сейчас Баффет аккуратно работает с рисками. Потому что ну а зачем рисковать?
Так было не всегда. Напомню, в 40 лет у него было 100к. Прогрессию по годам прикиньте сами. И степень риска тоже. Мне самому лень считать, но уже на глаз видно, что риски там были и очень большие.
Баффет - это типичный пример survivorship bias. Он может точно также обосраться в прогнозах, как и все остальные. Просто ему до этого везло. А так как везло именно ему, то именно он имеет прозвище "Провидец из Омахи".
Не всё так просто, конечно. Старый хрен знал, что надо продаваться, когда рынок ликовал в январе этого года. Из всех миллиардеров он единственный был в прибыли, когда акции упали в марте. Но это уже опыт.
Я такой подход слышал. Называется "нужно просто одновременно аккуратно менять код и базу данных и не ошибаться". Только это не работает )
Работает code-first, работает db-first и ещё одна дичь, про которую я написал статью.
покрываю реализацию тестами, которые гарантируют, что я ничего не пропустил
Тесты точно также начинают врать при изменении структуры данных. Да и тесты не могут дать гарантию, что данные маппятся правильно. Особенно при добавлении новых. Потому что нет тестов, которые проверяли бы соответствие тестов структуре. Вот ORM может дать гарантию, а тесты - нет.
Ровно наоборот. Когда схема данных развивается и меняется, ORM автоматически подхватывает изменения в объектах и запросах. А когда всё сделано на сырых sql запросах - вперёд искать по всему проекту, где используются изменённые поля и менять. А самое подлое - то, что ещё не найдено падает в рантайме. Потому что sql запрос в кавычках всегда будет валидным для вашего яп. А в какой момент исполнение кода наткнётся на пропущенный кусок, где вы забыли user_id поменять на manager_id - никто не знает.
Для того, чтобы работать с ORM, надо знать SQL. Потому что ORM это не замена SQL.
А самое главное, в ваших примерах почему-то стыдливо пропущено раскладывание результата по полям объектов. Сравнивается запрос в sql синтаксисе, который надо ещё экранировать, отправить в заранее подготовленную команду, получить ридер и прочитать его в объекты с готовой конструкцией $users = UserTable::query().
А ведь ORM - это в первую очередь Object-Relational Mapper.
Эти исследования либо некорректны, либо врут, либо не существуют. В больших проектах код приходится чаще читать, чем писать. Буквально, на одну написанную строчку приходятся десятки, а то и сотни прочитанных строк. И чем больше проект - тем больше нужно читать, прежде чем что-то дописывать. А вот тут как раз все языки разные. У парадигм разные уровни абстракции.
Если брать целиком цикл "прочитать, подумать, дописать, отладить, написать тесты", то ни о каком равенстве речи быть не может. Тут даже c# и c# - это две большие разницы. ООП даёт инструменты для работы на верхних уровнях логики, чтобы не было необходимости читать каждую реализацию. Но это только инструменты, они сами по себе не работают. Нужно ими пользоваться.
Как это не обладают? Шарп компилируемый и мультипарадигменный язык высокого уровня. И функциональная парадигма у него более развита, чем у c++. Да, у него нет темплейтов, зато есть рефлекшен.
Рантайм шарпа тоже шаред, если не селфконтейнить и не компилить в нейтив. Здесь уже вам самим выбирать, поставлять вашу версию с дистрибом или требовать её наличие на целевой машине. Другими способами эта дилема не решается.
Во вторых, в дотнете нет виртуальной машины. jit-компилятор есть, он используется, если не комплировалось с native aot. А дальше работает скомпилированный машинный код. Без виртуализации. Без ограниченной среды. Рантайм дальше это уже просто набор библиотек.
а stdlib чем вам не рантайм?
вот только в дотнете нет виртуальной машины
Конечно содержит. А сборка на плюсах не содержит?
Получаешь кучу неотловленных багов. Предыдущая система писалась 3 года и я думаю, что все три года она обкатывалась. У вас за 8 месяцев сделан только функционал, без обкатки.
А ещё вы этим стеком неизбежно добавили все вот эти приколы плюсов вроде мемликов, UB и прочих out-of-range. Это прямо целый пласт ошибок, которых в шарпе просто нет в силу его management природы.
Я ни в чём не собираюсь вас убеждать. Просто наслаждайтесь выбором.
А зачем складской программе быстродействие c++?
Шарп тоже компилируемый язык и даже весьма оптимизированный. Вот зачем в складской программе +20% (в лучшем случае) производительности гуя, если там всё равно в базу данных упрётся? Ну серьёзно?
А кто-нибудь подумал, за счёт чего эта производительность достигается? Вот эти все UB и отсутствие bound-check да, дают небольшой прирост. За счёт, внезапно UB и out-of-bound. Наслаждайтесь выбором, называется.
--SelfContained и у вас нет внешних зависимостей. -p:PublishAot=true - и у вас на выходе бинарник как в плюсах.
dotnet add package Avaloniaи у вас кроссплатформенный UI с синтаксисом WPF, с поддержкой Native AOT и работающий на любом линуксе, где есть гуй.Afro hole sun
Won't you come
And wash away the rain?
Не работает так. Чтобы попасть в "клуб трёх запятых" нужно рисковать и рисковать сильно. Это сейчас Баффет аккуратно работает с рисками. Потому что ну а зачем рисковать?
Так было не всегда. Напомню, в 40 лет у него было 100к. Прогрессию по годам прикиньте сами. И степень риска тоже. Мне самому лень считать, но уже на глаз видно, что риски там были и очень большие.
Баффет - это типичный пример survivorship bias. Он может точно также обосраться в прогнозах, как и все остальные. Просто ему до этого везло. А так как везло именно ему, то именно он имеет прозвище "Провидец из Омахи".
Не всё так просто, конечно. Старый хрен знал, что надо продаваться, когда рынок ликовал в январе этого года. Из всех миллиардеров он единственный был в прибыли, когда акции упали в марте. Но это уже опыт.
Нейросети же не понимают время, а значит и ритм. Нейросети понимают только то, что есть в интернете и строят графы зависимостей слов от слов.
Они в принципе не способны отличить стих от прозы.
Нейросеть даже не знает, как слова произносятся. У неё нет слуха, для неё не существует звуков. Нет времени, нет длительности, нет октав, нет рифмы.
А так должно быть?
Я такой подход слышал. Называется "нужно просто одновременно аккуратно менять код и базу данных и не ошибаться". Только это не работает )
Работает code-first, работает db-first и ещё одна дичь, про которую я написал статью.
Тесты точно также начинают врать при изменении структуры данных. Да и тесты не могут дать гарантию, что данные маппятся правильно. Особенно при добавлении новых. Потому что нет тестов, которые проверяли бы соответствие тестов структуре. Вот ORM может дать гарантию, а тесты - нет.
Ровно наоборот. Когда схема данных развивается и меняется, ORM автоматически подхватывает изменения в объектах и запросах. А когда всё сделано на сырых sql запросах - вперёд искать по всему проекту, где используются изменённые поля и менять. А самое подлое - то, что ещё не найдено падает в рантайме. Потому что sql запрос в кавычках всегда будет валидным для вашего яп. А в какой момент исполнение кода наткнётся на пропущенный кусок, где вы забыли user_id поменять на manager_id - никто не знает.
Для того, чтобы работать с ORM, надо знать SQL. Потому что ORM это не замена SQL.
А самое главное, в ваших примерах почему-то стыдливо пропущено раскладывание результата по полям объектов. Сравнивается запрос в sql синтаксисе, который надо ещё экранировать, отправить в заранее подготовленную команду, получить ридер и прочитать его в объекты с готовой конструкцией $users = UserTable::query().
А ведь ORM - это в первую очередь Object-Relational Mapper.
Эти исследования либо некорректны, либо врут, либо не существуют. В больших проектах код приходится чаще читать, чем писать. Буквально, на одну написанную строчку приходятся десятки, а то и сотни прочитанных строк. И чем больше проект - тем больше нужно читать, прежде чем что-то дописывать. А вот тут как раз все языки разные. У парадигм разные уровни абстракции.
Если брать целиком цикл "прочитать, подумать, дописать, отладить, написать тесты", то ни о каком равенстве речи быть не может. Тут даже c# и c# - это две большие разницы. ООП даёт инструменты для работы на верхних уровнях логики, чтобы не было необходимости читать каждую реализацию. Но это только инструменты, они сами по себе не работают. Нужно ими пользоваться.
Речь о том, что данное утверждение было подтверждено только "собственным проектом", в мощь которого предлагается поверить на слово.
Мне ваши обороты не нравятся. Поэтому ещё минус в карму и мне вы больше не интересны.
Я начинаю понимать, почему у вас ноль кармы при двадцати плюсовых публикациях. Не надо так. Это очень агрессивно. Я и не утверждал, что
я прямо много знаю. Я знаю, что там 6502 и что там элиту не выпустили.
Я про атари говорил. Сначала выпустили на спектруме, потом - на атари ст.
На любителя или нет - это очень сильно сокращает работу с экраном. При недостатке процессорной мощности того времени это было важно.
Окей, но плюс отсутствия видеочипа на спекки - его отсутствие.