Я сервис по обработке геоданных пишу на нем

Ребят, кто-нить юзает dlang в продакшене?

Это просто интерес или перед тобой выбор стоит?

Исключительно интерес

"Причина всех проблем с типами данных родом из пятидесятых годов, когда компьютеры были ламповыми. Чем больше ламп, тем больше требуется энергии и косвенных затрат (например, тем быстрее выгорают лампы). Кроме того, задействовать дополнительную память было действительно страшно. У машины могла быть только пара килобайт. К примеру, память Atari 2600 была всего 128 байтов. И поэтому не хотелось выделять 64 бита на то, что могло бы быть представлено 4 битами. И кто-то догадался в целях экономии использовать дополнительную арифметику. Догадка была действительно великолепной. Но, спустя 50 лет, мы должны спросить себя — почему мы все еще делаем это? Аналогичная ситуация сохраняется на других языках. Например, в Java у вас есть byte, char, short, int, long, flot, double и т.п. Каждый раз, когда вам нужно создать параметр, переменную или элемент, вы должны спросить себя, к какому типу будет относится новая структура. Значение сэкономленной при этом памяти настолько мало, что говорить о нем нет смысла. Нет никакой пользы в том, чтобы сделать правильный выбор. Фактически время, которое вы потратили на размышления, стоит бесконечно больше, чем сэкономленный ресурс. Но если вы ошибетесь, все перестанет работать, и тесты это не выявят. Это плохо." Есть мнение что современные системы типов — зло т.к. сильно осложняют разработку. Вот к примеру объявил я переменную как int т.к. не думал, что из БД может ID прилететь больше чем вмещает в себя int и все упало. Мое мнение. Современному языку хватило бы трех целочисленных типов. int - целое float - число с плавающей точкой bool - булевое Это позволило бы значительно ускорить разработку и сократить количество ошибок. Во всяком случае на Питон без типов наверно сотни тысяч человек пишут и живут как-то..)) Ваше мнение?

знаковость типа - контракт с разработчиком. это дополнительная инфа, которая полезна и для человека и для компилера. Даже всякие checkedInt делают, который диапазоны проверяет. Так что типизация должна развиваться и уточнятся, а не отменяться.

В какую сторону развиваться? Пока я вижу только что количество тех же целочисленных типов только растет и в итоге вместо "прилетит ли число" нужно думать еще какое число может прилететь и что делать если прилетит число которое не влезет в размерность

"Причина всех проблем с типами данных родом из пятидесятых годов, когда компьютеры были ламповыми. Чем больше ламп, тем больше требуется энергии и косвенных затрат (например, тем быстрее выгорают лампы). Кроме того, задействовать дополнительную память было действительно страшно. У машины могла быть только пара килобайт. К примеру, память Atari 2600 была всего 128 байтов. И поэтому не хотелось выделять 64 бита на то, что могло бы быть представлено 4 битами. И кто-то догадался в целях экономии использовать дополнительную арифметику. Догадка была действительно великолепной. Но, спустя 50 лет, мы должны спросить себя — почему мы все еще делаем это? Аналогичная ситуация сохраняется на других языках. Например, в Java у вас есть byte, char, short, int, long, flot, double и т.п. Каждый раз, когда вам нужно создать параметр, переменную или элемент, вы должны спросить себя, к какому типу будет относится новая структура. Значение сэкономленной при этом памяти настолько мало, что говорить о нем нет смысла. Нет никакой пользы в том, чтобы сделать правильный выбор. Фактически время, которое вы потратили на размышления, стоит бесконечно больше, чем сэкономленный ресурс. Но если вы ошибетесь, все перестанет работать, и тесты это не выявят. Это плохо." Есть мнение что современные системы типов — зло т.к. сильно осложняют разработку. Вот к примеру объявил я переменную как int т.к. не думал, что из БД может ID прилететь больше чем вмещает в себя int и все упало. Мое мнение. Современному языку хватило бы трех целочисленных типов. int - целое float - число с плавающей точкой bool - булевое Это позволило бы значительно ускорить разработку и сократить количество ошибок. Во всяком случае на Питон без типов наверно сотни тысяч человек пишут и живут как-то..)) Ваше мнение?

Полная чушь)

это прям как похапе)

там int всегда знаковый и размер его зависит от разрядности системы

в сторону уточнения контракта. Если бы CheckedInt не стоил бы столь дорого, я бы использовал его везде. В идеале программист должен указывать диапазон допустимых значений, а компилер проверять, что всё точно влезет. Как пример, парсинг инта из строки. Уже сейчас есть набор типов на 8, 16, 32, 64 бита и функция может проверять размер числа и для каждого типа знать допустимые значения. Поэтому переполнение никогда не возможно - вылетит эксепшен, вернётся ошибка и тд и тп.

и вот как-то раз мне пришлось делать простейший конгруэнтный генератор псевдослучайных чисел на похапе, проклял все на свете)

В идеале компилирующийся код не должен содержать ошибок - всё должен проверить компилятор. Пока это недостижимо и слишком многословно, но rust, D, C++ быстро движутся в эту сторону

и контракты типов и их размеры - одна маленькая частичка

Grigirii ну вот в случае с БД. Получается проще лепить тип с запасом т.к. нет гарантии что завтра его размерность не вырастет. Думаю такая ситуация не единична.

это по факту изменение схемы БД, она всегда требует обновления использующего кода

на самом деле, как миниму на архитектуре x86 обилие целочисленных типов обусловлено разрядностью операндов, над которыми способен выполнять операции процессор)

и не забывай, что для производительности это может быть чертовски важно

если язык претендует на близость к железу, он без этих типов не обойдется

Если я не ошибаюсь в Dart есть тип типа "Num" — типа число и еще какие-то типы общего плана

сейчас AVX ограничен общим размером операндов. Если юзать 64 бита против 32, то можно сделать вдвое меньше операций за такт

а экономии места при объявлении byte вместо int в современных программах не будет, потому что все равно память съестся выравниванием)

а экономии места при объявлении byte вместо int в современных программах не будет, потому что все равно память съестся выравниванием)

нет, если это важно

нет, если это важно

ну тут в большинстве случаев дело компромисса: либо память, либо скорость)

если используется передача данных по сети, серийному порту, между цп и видеокартой: везде это важно и значительно экономит место

если не вообще делает возможным передачу

мы же сейчас говорим не про передачу данных между периферией, а про расположение переменных в памяти)

а как они по твоему будут располагаться в памяти, если ты выровняешь по 1 байту их?

там не будет никаких пробелов

ключевое тут: если выровняешь)

изображения, видео, там тоже важен размер типа данных

ключевое это то что подход "всегда использовать long" бред

и существует огромное количество случаев, где это делать нельзя

а если нет, то в большинстве случаев все, что меньше dword в x86 и мешьше qword в amt64, выровняется по dword и qword соответственно

и?

только из-за оптимизации скорости доступа

именно)

о чем я и говорил)

а я говорю об изначальном утверждении, которое Дмитрий привёл

типа время затраченное на выбор типа не окупается

обилие целочисленных типов обусловлено не экономией памяти, а тем, что с такими типами операндов работает процессор, и в языках, близких к железу, без этого не обойтись)

по идее, можно строго для себя решить, что пока ты работаешь с базами данных, клепаешь сайтики и всякие консольные утилиты, используй только подмножество целочисленных типов (int или long, например), и проблема будет решена)

а как только приходится гонять данные по серийным портам или, не дай бог, по isa шине какой-нибудь, используй весь набор)

а как только приходится гонять данные по серийным портам или, не дай бог, по isa шине какой-нибудь, используй весь набор)

вот я сейчас по такой теме работаю

а раньше больше обработка была

и никогда не задавался вопросом "а нужны ли мне типы разные"

потому что они нужны

без них никуда

только сайтики и бд

ну обычно такие вопросы возникают у людей, которые не сталкивались тесно с железом и считают программирование исключительно математической дисциплиной)

Ну весь фронтэнд такой...

Мнение из соседнего окна: "Плюс типизация даже на уровне int, bool, float сильно снижает скорость “хакерского” программирования, или “прототипного”, как я его называю - когда ты ещё точно не знаешь какие будут параметры, что будет возвращаться, ты просто пишешь код тоже самое со структурами данных Мне кажется невозможно быстро набросать прототип кода если приходится думать о HasMap, HashSet, LinkedArray и т.п. по сути всё что для этого нужно - обычный массив и ассоциативный и всё - можно напрототипировать очень быстро, а качество кода подтянуть через несколько итераций (а лучше с ноля переписать нормально, разнести на функции и тп)"

тогда идеальный язык для прототипирования - это похапе 7)

я иногда кромольными делами занимаюсь и использую его как замену bash-скриптам, если нужно сделать что-то более менее сложное)

с rdmd действительно больше времени татится на разработку, но количество потенциальных ошибок обычно гораздо меньше

Мнение из соседнего окна: "Плюс типизация даже на уровне int, bool, float сильно снижает скорость “хакерского” программирования, или “прототипного”, как я его называю - когда ты ещё точно не знаешь какие будут параметры, что будет возвращаться, ты просто пишешь код тоже самое со структурами данных Мне кажется невозможно быстро набросать прототип кода если приходится думать о HasMap, HashSet, LinkedArray и т.п. по сути всё что для этого нужно - обычный массив и ассоциативный и всё - можно напрототипировать очень быстро, а качество кода подтянуть через несколько итераций (а лучше с ноля переписать нормально, разнести на функции и тп)"

при прототипировании и набросках должен быть базовый набор, который позволяет что-то сделать + нужно хорошо знать чем отличаются те или иные контейнеры, тогда не будет таких вопросов стоять

да и к тому же есть вообще auto и шаблоны

если уж совсем пофигу какой тип

А про то что отчет с нуля начинается кто что думает?) Есть мнение что можно было бы нормально жить если бы все от единицы считалось)

Тем более в Delphi (кажется) и Julia именно так и сделано

подозреваю, это как-то связано с адресацией сегмент:смещение)

А про то что отчет с нуля начинается кто что думает?) Есть мнение что можно было бы нормально жить если бы все от единицы считалось)

очевидно, что так думают люди слабо знакомые с математикой

мнение: поправки на уровне смещения и тд можно было делать на уровне компилятора про математику: Julia создана математиками для математиков

хотя там тоже отчет не всегда с 0 начинается

А про то что отчет с нуля начинается кто что думает?) Есть мнение что можно было бы нормально жить если бы все от единицы считалось)

А в чём разница вообще? Единственная неудобность в отсчете с 0, так это то, что где-то отсчёт с 1. Просто когда пишешь в матлабе или октаве прототип, а потом надо переписать на нормальном языке неудобно вспоминать где 0, а где 1. Был бы единый стандарт, что везде начинаем с 0, или везде с 1 и проблем бы вообще никаких не было бы.

ну вот тут вся и фишка, что людям удобнее с 1 считать и язык программирования должен это учитывать

ага, а кто будет учить процессор сравнивать с 1, а не с 0? Куча алгоритмов и оптимизаций стоится на этом самом ноле. Тривиальная работа итераторов ломается, их разность перестанет быть разностью указателей, да и много таких следствий. Всё решаемо, но зачем, если и так всё хорошо работает?

Я не понял, если тот чел написал что всем хватило бы только трех типов для написания программ, то что мешает ему начать писать его программы только с тремя типами то? Вот выложил бы исходник и сказал бы "посмотрите как здорово получается"

ERROR: S client not available

Не, про три типа хватит всем это моя идея. Тот вообще без типов предлагает жить)

Ну ок ок, где его исходники?

Я из языков с подобной типизацией только Dart видел, хотя там точно не помню какие типы еще есть

Я предлагаю всем жить счастливо и богато, давайте так и сделаем? Кто согласен? =)

Grigirii просто получается отсчет с нуля нужен исключительно для системных языков. Опять таки все что уровнем чуть выше (типа Delphi) и уже можно смело с единицы считать

И каждый раз, когда программист переключается с одного языка на другой должен иметь привычку переключаться с одного отсчета на другой

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

грубо говоря foo[i] там равнозначно foo+i

ну а дальше это просто опыт предков - начинать считать с нуля)

А если бы [i] означало i-1 то все было бы здорово

и программистам пришлось бы держать это в голове)

тут, опять же, надо помнить, что эпоха расцвета си пришлась на время, когда программирование было тесно связано с железом. и C-style часто изобилует смешением синтаксиса массивов с синтаксисом указателей

да дело не только в указателях. арифметика с нолём гораздо более удобная по сравнению с 1. Срез с [i, j] пуст если i == j, можно оперировать вличиной j-i. Точно так же удобна итерация по i < length против i <= length. Это такие области, которые и так непросты, а 1 всё усложняет

да дело не только в указателях. арифметика с нолём гораздо более удобная по сравнению с 1. Срез с [i, j] пуст если i == j, можно оперировать вличиной j-i. Точно так же удобна итерация по i < length против i <= length. Это такие области, которые и так непросты, а 1 всё усложняет

а упрощает только тем, кто не может посчитать где 7ой элемент в массиве

Кстати, вопрос. А никто логических косяков в следующем коде не видит? Он у меня строго при обработке второго элемента в цикле падает:

Первый норм, а во втором сразу в catch

проблема уходит если закомментить строку auto answer

Оказалось, что auto result = cmd_nearesPointOnRoad.executeQuery(); обязателньно нужно закрывать

Кстати, а в чем может быть причина и как бороться. У меня следующий цикл не обрабатывает прерывание по ctrl+с на Windows:

подозреваю что дело с continue

а он должен?)

а разве нет? это же типа сигнал что приложению унжно убиться

в Windows, насколько помню, для этого есть SetConsoleCtrlHandler

в юниксах, да, шлется сигнал процессу

просто остальные приложения убиваютя нормально, но вот после добавления подобного цикла все перестало работать

честно, давно ничего консольного для винды не писал, но, насколько помню, программы с бесконечными циклами по ctrl+c в винде не завершаются, для этого обработчик с флагом нужно делать через SetConsoleCtrlHandler

а в D дополнительно не забыть переменную-флаг объявить как __gshared

Просто когда у меня continue было в блоке catch то все работало

Кстати, а сколько времени writeln занимает? Оно же блокирующее. Пока не напишется код дальше не идет, верно?

верно