Получаешь кучу неотловленных багов. Предыдущая система писалась 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# - это две большие разницы. ООП даёт инструменты для работы на верхних уровнях логики, чтобы не было необходимости читать каждую реализацию. Но это только инструменты, они сами по себе не работают. Нужно ими пользоваться.
А по каким критериям мне тогда можно отличать умных и опытных разработчиков вроде вас от обыкновенных интернет-пиздаболов?
Стоит ли мне верить на слово, что ваш компилятор в 5к строк оказался лучше компилятора на цпп в 10-15к строк (я ничего не перепутал?) и при этом написан всего одним человеком и быстрее?
Я вот что думаю. Есть такой инструмент - dBeaver. Там по осторожным прикидкам, не менее полумиллиона строк кода (лень считать, да). А у меня ormfactory - приложение того же класса с сопоставимой функциональностью, что и dbeaver. Могу ли я говорить, что шарп в десять раз компактнее джавы? Ой, у меня же 37к строк, значит в тринадцать с половиной.
Бред? Бред. Конечно, не могу. Тут каждый пункт "с натяжкой". Шарп "в целом по больнице" компактнее джавы, да. Возможно раза в полтора. Но не в разы.
С хаскелем также. С вашим примером также. Я готов поверить, что на больших проектах хаскель будет компактнее шарпа на процентов 10. 20 уже вряд ли. А потом я уже могу поговорить о том, что компактность ну вот ни разу не бесплатная. В данном случае компактность может легко привести к повышенным когнитивным расходам при работе с кодом. Что в данном случае лучше - я оставляю за рамками. Обычно ищут какую-то точку баланса исходя из своих обстоятельств. У Го баланс смещён в сторону недоверия разрабу, что явно выгодно при большой текучке.
Тем временем разговор скатился в говно и я даже не успеваю аргументировать каждую попытку манипуляции, не то, что даже добраться до реально полезной дискуссии. У вас нет необходимости пилить плинтуса вдоль, а про то, что циркулярка - это реально хороший инструмент и широко используется, вы не вспомнили. Я рад за вас. Но говорить надо по делу.
Ну как-бы атари не очень-то конкурировала со спектрумом. В той нише были Oric-1 и Atmos например. С тем же 6502 и без отдельного видеочипа, да. Только там с бюджетом тактов на экран ещё хуже.
Про видеочип согласен, он иногда вытягивает. Но только в скролле. Перерисовка экрана на 6502 - долго, мучительно, больно. Собственно, если не ошибаюсь, "элита" появилась только на atari st, которая на 68к. Совсем другой класс.
Так что я уверен, что такты сыграли свою роль. Спектрум просто быстрее может перерисовать графику на экране, может больше держать подвижных объектов. Собственно, характерная черта спектрумовских игр - переход от экрана к экрану вместо скролла. Вот так избавлялись от необходимости скроллить.
В демомейкинге бюджет тактов на кадр - это вот прямо очень важно было. И вот спектрум позволял делать 50fps анимации, правда с дикими ухищрениями, вроде использования push-команды (самый быстрый способ записать память - 11 тактов на слово, что давало 5,5 тактов на байт). Собственно, предгенерировали машкод, делали алгоритмы динамического вызова этих пушей, оставляли бюджет на музыку и вот получалась 50fps анимация на весь экран.
а 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 и что там элиту не выпустили.
Я про атари говорил. Сначала выпустили на спектруме, потом - на атари ст.
На любителя или нет - это очень сильно сокращает работу с экраном. При недостатке процессорной мощности того времени это было важно.
Окей, но плюс отсутствия видеочипа на спекки - его отсутствие.
А по каким критериям мне тогда можно отличать умных и опытных разработчиков вроде вас от обыкновенных интернет-пиздаболов?
Стоит ли мне верить на слово, что ваш компилятор в 5к строк оказался лучше компилятора на цпп в 10-15к строк (я ничего не перепутал?) и при этом написан всего одним человеком и быстрее?
Я вот что думаю. Есть такой инструмент - dBeaver. Там по осторожным прикидкам, не менее полумиллиона строк кода (лень считать, да). А у меня ormfactory - приложение того же класса с сопоставимой функциональностью, что и dbeaver. Могу ли я говорить, что шарп в десять раз компактнее джавы? Ой, у меня же 37к строк, значит в тринадцать с половиной.
Бред? Бред. Конечно, не могу. Тут каждый пункт "с натяжкой". Шарп "в целом по больнице" компактнее джавы, да. Возможно раза в полтора. Но не в разы.
С хаскелем также. С вашим примером также. Я готов поверить, что на больших проектах хаскель будет компактнее шарпа на процентов 10. 20 уже вряд ли. А потом я уже могу поговорить о том, что компактность ну вот ни разу не бесплатная. В данном случае компактность может легко привести к повышенным когнитивным расходам при работе с кодом. Что в данном случае лучше - я оставляю за рамками. Обычно ищут какую-то точку баланса исходя из своих обстоятельств. У Го баланс смещён в сторону недоверия разрабу, что явно выгодно при большой текучке.
Тем временем разговор скатился в говно и я даже не успеваю аргументировать каждую попытку манипуляции, не то, что даже добраться до реально полезной дискуссии. У вас нет необходимости пилить плинтуса вдоль, а про то, что циркулярка - это реально хороший инструмент и широко используется, вы не вспомнили. Я рад за вас. Но говорить надо по делу.
Ну как-бы атари не очень-то конкурировала со спектрумом. В той нише были Oric-1 и Atmos например. С тем же 6502 и без отдельного видеочипа, да. Только там с бюджетом тактов на экран ещё хуже.
Про видеочип согласен, он иногда вытягивает. Но только в скролле. Перерисовка экрана на 6502 - долго, мучительно, больно. Собственно, если не ошибаюсь, "элита" появилась только на atari st, которая на 68к. Совсем другой класс.
Так что я уверен, что такты сыграли свою роль. Спектрум просто быстрее может перерисовать графику на экране, может больше держать подвижных объектов. Собственно, характерная черта спектрумовских игр - переход от экрана к экрану вместо скролла. Вот так избавлялись от необходимости скроллить.
В демомейкинге бюджет тактов на кадр - это вот прямо очень важно было. И вот спектрум позволял делать 50fps анимации, правда с дикими ухищрениями, вроде использования push-команды (самый быстрый способ записать память - 11 тактов на слово, что давало 5,5 тактов на байт). Собственно, предгенерировали машкод, делали алгоритмы динамического вызова этих пушей, оставляли бюджет на музыку и вот получалась 50fps анимация на весь экран.