Я не для того месяцы нервов потратил на изучение слепой печати, что бы кривить позвоночник печатая со смещением из-за наличия нумблока.
У меня два вопроса. Как вам помогает слепая печать при наборе цифр? Я тоже умею в слепую печать, но цифры набирать на нампаде гораздо удобнее.
И почему бы не подвинуть ноутбук на пару сантиметров вправо? Я не очень разбираюсь в человеческой анатомии, не знаю, откуда позвоночник в руках, но это действие поможет отцентровать клавишу пробела относительно вашего тела.
Я не работаю в закрытом контуре. Но в году 13-14м работал над одним оборонзаказом. Там писалось на шарпе, всё сертифицировалось и использовалась сертифицированная постгря (с проверенными исходниками).
В широком смысле этого слова, конечно, почти все языки, включая c#, компилируемые.
Нет. Есть интерпретируемые языки. Их целый пласт.
компилируется в IL и дальше выполняется под управлением .net runtime
Нет. IL код не выполняется. Он промежуточный. Он даже так называется.
который сам JIT-компилирует и контролирует работу приложения.
JIT ничего не контролирует. Он компилятор.
И если пофантазировать
Фантазировать можно что угодно. Факт в том, что один и тот же промпт не даёт одного и того же результата. Также, как с мясной нейросетью, необходимо фиксировать алгоритмы обработки в чём-то однозначным, что компилируется всегда в одно и то же.
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.
У меня два вопроса. Как вам помогает слепая печать при наборе цифр? Я тоже умею в слепую печать, но цифры набирать на нампаде гораздо удобнее.
И почему бы не подвинуть ноутбук на пару сантиметров вправо? Я не очень разбираюсь в человеческой анатомии, не знаю, откуда позвоночник в руках, но это действие поможет отцентровать клавишу пробела относительно вашего тела.
Это не придирки к формулировкам, это ключевая особенность дотнета. IL код не выполняется. Он компилируется.
Не по мере надобности, а перед запуском приложения.
Как вы себе представляете машинный код под управлением рантайма? Рантайм это библиотеки и GC. Это ваш код вызывает рантайм.
Я не работаю в закрытом контуре. Но в году 13-14м работал над одним оборонзаказом. Там писалось на шарпе, всё сертифицировалось и использовалась сертифицированная постгря (с проверенными исходниками).
Нет. Есть интерпретируемые языки. Их целый пласт.
Нет. IL код не выполняется. Он промежуточный. Он даже так называется.
JIT ничего не контролирует. Он компилятор.
Фантазировать можно что угодно. Факт в том, что один и тот же промпт не даёт одного и того же результата. Также, как с мясной нейросетью, необходимо фиксировать алгоритмы обработки в чём-то однозначным, что компилируется всегда в одно и то же.
Как это не обладают? Шарп компилируемый и мультипарадигменный язык высокого уровня. И функциональная парадигма у него более развита, чем у 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.