В машине тьюринга нет никаких регитсров, там есть только бесконечная лента и алфавит
Регистры на ленте машины тьюринга/поста нужны для ограничения областей на ленте под операции, изначально их нет, они не обязательно нужны, но очень помогают не сойти с ума. А еще с их помощью можно написать компилятор, а не руками команды набирать)
Знаю людей, которые никогда такого не делали, но им есть на чем компилировать. Как так?
Да, можно писать на джаве под спринг, собирать все градлом, под капот ни одной абстракции не залезать. И быть легко заменимым
Неужели вас заставляли курсе на втором выделять на ленте регистры и память, писать операции над ними, а потом применять их ко входных данным на ленте? Думаю, нет. В основном потому, что:
Смысла в практическом программировании у такого ноль ровно
Без "такого" не будет практического программирования, потому что нечем будет компилировать, не на чем исполнять)
int* temp = gc_calloc(BIG_SIZE, sizeof(int));
for (...) {
// работаем с temp'ом
}
// начиная с этого момента массив больше не используется, является мусором в памяти
// сразу освобождаем, чтобы не насиловать сборщик
gc_free(temp);
Это будет не переменная, потому что ее нельзя будет переменить)
Или внезапно из сишки типа int32_t пропали.
Они существуют параллельно со встроенными типами данных для задач, в которых разрядность нужна явно (например, для сериализации). В остальных случаях рекомендуется использовать обычные типы данных, так как компилятор с их помощью будет генерировать более эффективный и независимый от платформы код
Про лямбды — дело в | |. И да, если язык позиционируется как замена, то он должен обеспечивать простой переход, а не изобретать велосипеды на каждом углу
Ох уж эти глупые доктора наук Ритчи и Керниган, а потом еще и Страуструпы всякие, нагородили таких вредные конструкций, что до сих пор разгребаем, но не разгребем
неплохо раскзаано, почему и неявные касты плохо, и тип впереди функции, и многое-многое другое
Конечно плохо. В идеале, программист должен иметь лишь одну кнопку, но нажатию которой будет писаться рабочий код — вот она, мечта любого энтерпрайза
Понятное дело, что дело привычки, больше раздражают причины для всего этого. Точнее, их отсутствие. Ничто не мешало сделать уже похожим на существующее без конфликтов в грамматике, но ведь нет
Имел ввиду, что gc может ждать, пока память станет свободной по его мнению, а может получить явный вызов по освобождению объекта "здесь и сейчас"
Дурно он влияет на производительность: большое число объектов отслеживать и обрабатывать сложно. Поэтому программист может ему помогать, делая такие вызовы на части объектов заранее
Только если для страуса в песочнице. Надо понимать, какой код переходит в какую последовательность инструкций, для этого даже есть удобное по. В идеале, надо уметь и на машину поста/тьюринга писать программы: необходимость писать даже регистры и операции над ними с нуля дает отличное понимание компьютерной архитектуры
Ансейф не имеет отношения к повышенному расходу памяти… Все считается в компайл тайм
Ансейф — нет, а умные указатели и система владения — имеют. Компилятор не программист, он не обладает способностью к аналитическому мышлению
какие зависания
Зависания как у не самой умной молодежи: соберутся в кучку с пивом, включают блютуз-колонку шумят, занимают место, отказываются уходить
Появление UB — это детерменированное поведение. Мы всегда знаем, где он есть, а где его нет, это четко прописано в спецификации. Просто не знаем заранее, какой из возможных результатов скомпилируется. Недетерменированные автоматы же на x86 никак не загнать
Главный плюс сборщиков мусора в языках с контролируемой памятью в том, что им можно явно дать комманду освобождения. Тогда они сами будут лишь утечки собирать, не сильно влияя на корректно работающий код
Всякие си с плюсами и даже корпоративной джавой уживаются как-то, хотя я не эксперт в этих вопросах
А можно пару примеров, что в синтаксическом новоязе Rust так сильно причиняет боль?
Все перечислять не буду, можно на примере самых основных. Для обозначения переменной нужно два ключевых слова let mut, аналогично его должны иметь модифицируемые параметры функций. Примитивы все имеют явную разрядность, которую приходится держать в голове (неявного каста тут нет), даже если это не нужно. Функции надо помечать ключевым словом, при этом все равно явно задавая возвращаемый тип. Каждый match (здешний switch) должен обрабатывать все возможные области значений, необходимо таскать с собой пустую строку дефолта _ => {}. При создании лямбд у разработчиков сломались клавиши скобок: let closure = |i: i32| -> i32 { i + 1 };. Возвращение значений из функций может быть явным и не- (просто последнее выражение без ;), но выражения уже не умеют в return. Из-за этого, кстати, код труднее не писать, но читать — без цветной пометки эти строчки на раз пропускаются, либо вводят в смущение. И, да, выражения теперь возвращают значения, поэтому в чужом коде можно ожидать конструкций из серии:
// "умная" инициализация
let mut x = if a {
// сотня строк кода
0
} else if b {
// снова куча логики
5
} else {
// еще две сотни
1
}
...
match x {
// и фиг его знает, на самом деле, куда он тут попадет
}
Это все только поверхостные мелочи. Но при каждом переходе между ним и другим языком бросаются в глаза. Что хуже, вместе выражаются в очень загруженный код (примеры есть тут в комментариях), в котором даже с умным парсером и подсветкой (они никак не подскажут значения x в коде выше, потому что тот не участвует в выражениях) без поллитры не всегда разобраться
Никто ведь не хотел бы программировать машину Тьюринга
Мы этим уже занимаемся. Наши физические компьютеры — ее модели, мы просто используем синтаксическую прослойку, которую разворачивают компиляторы, интерпретаторы и виртуальные машины
огораживая ~unsafe~ знаком ОСТОРОЖНО: СВАРКА
Эти знаки точно так же ставятся в любом другом языке. Всегда заранее известно, какие операции могут привести к какому результату, ЯП полностью детерменирован
Ну вот я считаю, что в программе не должно быть CVE с памятью вообще
На два стула сесть не выйдет. Если писать полностью без unsafe, то можно легко натолкнуться на повышенный расход памяти (эти умные указатели любят позависать). Глобально надо смотреть в сторону сборщиков мусора, позволяющих совмещать подходы. И тех же самых, что и для C/C++, динамических анализаторов типа valgrind
Вполне. От некоторого класса проблем. Чем серьезнее язык, тем больший этот класс.
Это защита из серии мягких углов. Да, маленького ребенка нельзя одного оставлять в помещении, нужны и заграждения, и надзор, и разъяснения, что в рот брать надо, а что нет. Но чем он становится старше, тем больше свободы мы ему даем: сначала доверем ему ПВА для апликации на уроке труда, позже паяльник, а потом и вовсе сварку. Потому что с опытом тот начинает понимать, что и как ему делать, используя полученные знания с большей эффективностью. Даже если неаккуратное использование и опасно для здоровья
Поэтому я не против разработки строгих и сколь угодно беопасных языков, сам могу на них писать даже. Но не нужно предлагать заменить опасную сварку по железу на безопасный пва по дереву. Да, иногда результат будет даже лучше. Но для остальных все еще имеет смысл одолжить аппарат и маску у соседа
Например, ассемблер неудобнее Си, а си неудобнее раста
А в чем измеряем? Явно не количеству слов и символов, необходимых для реализации одних и тех же действий — курс формальных языков создатели последнего не сильно любили
Лучше дать инструмент, который ...
Этот инструмент зовется "анализатор". Статический подвид входит в практически любой современный компилятор, иногда даже отдельным модулем. Благодаря этому, последним можно выставить обработку предупреждений анализатора как ошибок компиляции, чтобы "почти как в расте". Все уже придумано за нас)
Так не все делают по простой причине — часто нет времени вылизывать все дочиста, если код может работать и так. Хотя сейчас становится проще и редакторы учатся проводить анализ в процессе написания кода, чтобы можно было чинить по факту
Но на самом деле, 2/3 примеров не пройдут даже лексический анализ
Ну понятное дело, но и смена языка тоже не спасет)
Про помнить каждую переменную и количество объектов не понял, опять же, в чем именно си хуже любого другого языка. К слову, в нем нет NULL'ов, зато есть самые обычные нули
Что расстраиваться-то?
Как чего, падению квалификации. Софт-то кому-то писать надо, нам же его и использовать, если доживем
на мой взгляд, дело в человеке, а не в инструменте
Это и моя же позиция)
удобные и эффективные инструменты должны быть
Вот только почему нынешние неудобные? То есть, тот же раст на самом деле имеет кучу интересных фич, но зачем-то позиционируется многими как замена си со смущающей меня аргументацией. Так тяжело существовать параллельно, что ли?)
Это отличный пример, кстати, недавно как раз видел расследование аварии на взлетной полосе из-за одного пропущенного уточнения. Правда, софт для аналогичных задач все равно на языках с возможностью прострела ноги пишется
что делать с этим
В моем представлении, надо в первую очередь поднимать квалификацию, и свою, и чужую. А то так все просто разленятся и через 20 лет будут жаловаться на слишком свободный раст)
Регистры на ленте машины тьюринга/поста нужны для ограничения областей на ленте под операции, изначально их нет, они не обязательно нужны, но очень помогают не сойти с ума. А еще с их помощью можно написать компилятор, а не руками команды набирать)
Да, можно писать на джаве под спринг, собирать все градлом, под капот ни одной абстракции не залезать. И быть легко заменимым
Зависит от реализации, конечно, но обычно: в глобальной переменной будет храниться адрес на освобожденный участок в памяти, а обращение к ней — UB
Если без вызова — то будет висеть, так как завязан на глобальную переменную, куда ему деться
Неужели вас заставляли курсе на втором выделять на ленте регистры и память, писать операции над ними, а потом применять их ко входных данным на ленте? Думаю, нет. В основном потому, что:
Без "такого" не будет практического программирования, потому что нечем будет компилировать, не на чем исполнять)
Почему нет?
Это будет не переменная, потому что ее нельзя будет переменить)
Они существуют параллельно со встроенными типами данных для задач, в которых разрядность нужна явно (например, для сериализации). В остальных случаях рекомендуется использовать обычные типы данных, так как компилятор с их помощью будет генерировать более эффективный и независимый от платформы код
Про лямбды — дело в
| |. И да, если язык позиционируется как замена, то он должен обеспечивать простой переход, а не изобретать велосипеды на каждом углуОх уж эти глупые доктора наук Ритчи и Керниган, а потом еще и Страуструпы всякие, нагородили таких вредные конструкций, что до сих пор разгребаем, но не разгребем
Конечно плохо. В идеале, программист должен иметь лишь одну кнопку, но нажатию которой будет писаться рабочий код — вот она, мечта любого энтерпрайза
Понятное дело, что дело привычки, больше раздражают причины для всего этого. Точнее, их отсутствие. Ничто не мешало сделать уже похожим на существующее без конфликтов в грамматике, но ведь нет
Имел ввиду, что gc может ждать, пока память станет свободной по его мнению, а может получить явный вызов по освобождению объекта "здесь и сейчас"
Дурно он влияет на производительность: большое число объектов отслеживать и обрабатывать сложно. Поэтому программист может ему помогать, делая такие вызовы на части объектов заранее
Большое его подмножество и. Сложно найти неинициализированную переменную? Да ну нет. Знаковое переполнение? Да тоже просто. Нал поинтер? Куда проще
В общем случае найти их все вроде как нельзя, да, но тут никакой язык не спасет
Пока не вышло
Только если для страуса в песочнице. Надо понимать, какой код переходит в какую последовательность инструкций, для этого даже есть удобное по. В идеале, надо уметь и на машину поста/тьюринга писать программы: необходимость писать даже регистры и операции над ними с нуля дает отличное понимание компьютерной архитектуры
Ансейф — нет, а умные указатели и система владения — имеют. Компилятор не программист, он не обладает способностью к аналитическому мышлению
Зависания как у не самой умной молодежи: соберутся в кучку с пивом, включают блютуз-колонку шумят, занимают место, отказываются уходить
Появление UB — это детерменированное поведение. Мы всегда знаем, где он есть, а где его нет, это четко прописано в спецификации. Просто не знаем заранее, какой из возможных результатов скомпилируется. Недетерменированные автоматы же на x86 никак не загнать
Главный плюс сборщиков мусора в языках с контролируемой памятью в том, что им можно явно дать комманду освобождения. Тогда они сами будут лишь утечки собирать, не сильно влияя на корректно работающий код
Всякие си с плюсами и даже корпоративной джавой уживаются как-то, хотя я не эксперт в этих вопросах
Все перечислять не буду, можно на примере самых основных. Для обозначения переменной нужно два ключевых слова
let mut, аналогично его должны иметь модифицируемые параметры функций. Примитивы все имеют явную разрядность, которую приходится держать в голове (неявного каста тут нет), даже если это не нужно. Функции надо помечать ключевым словом, при этом все равно явно задавая возвращаемый тип. Каждыйmatch(здешнийswitch) должен обрабатывать все возможные области значений, необходимо таскать с собой пустую строку дефолта_ => {}. При создании лямбд у разработчиков сломались клавиши скобок:let closure = |i: i32| -> i32 { i + 1 };. Возвращение значений из функций может быть явным и не- (просто последнее выражение без;), но выражения уже не умеют вreturn. Из-за этого, кстати, код труднее не писать, но читать — без цветной пометки эти строчки на раз пропускаются, либо вводят в смущение. И, да, выражения теперь возвращают значения, поэтому в чужом коде можно ожидать конструкций из серии:Это все только поверхостные мелочи. Но при каждом переходе между ним и другим языком бросаются в глаза. Что хуже, вместе выражаются в очень загруженный код (примеры есть тут в комментариях), в котором даже с умным парсером и подсветкой (они никак не подскажут значения
xв коде выше, потому что тот не участвует в выражениях) без поллитры не всегда разобратьсяМы этим уже занимаемся. Наши физические компьютеры — ее модели, мы просто используем синтаксическую прослойку, которую разворачивают компиляторы, интерпретаторы и виртуальные машины
Эти знаки точно так же ставятся в любом другом языке. Всегда заранее известно, какие операции могут привести к какому результату, ЯП полностью детерменирован
На два стула сесть не выйдет. Если писать полностью без unsafe, то можно легко натолкнуться на повышенный расход памяти (эти умные указатели любят позависать). Глобально надо смотреть в сторону сборщиков мусора, позволяющих совмещать подходы. И тех же самых, что и для C/C++, динамических анализаторов типа valgrind
Это защита из серии мягких углов. Да, маленького ребенка нельзя одного оставлять в помещении, нужны и заграждения, и надзор, и разъяснения, что в рот брать надо, а что нет. Но чем он становится старше, тем больше свободы мы ему даем: сначала доверем ему ПВА для апликации на уроке труда, позже паяльник, а потом и вовсе сварку. Потому что с опытом тот начинает понимать, что и как ему делать, используя полученные знания с большей эффективностью. Даже если неаккуратное использование и опасно для здоровья
Поэтому я не против разработки строгих и сколь угодно беопасных языков, сам могу на них писать даже. Но не нужно предлагать заменить опасную сварку по железу на безопасный пва по дереву. Да, иногда результат будет даже лучше. Но для остальных все еще имеет смысл одолжить аппарат и маску у соседа
На самом деле, раньше сборку мусора писали как раз для C/C++
А в чем измеряем? Явно не количеству слов и символов, необходимых для реализации одних и тех же действий — курс формальных языков создатели последнего не сильно любили
Этот инструмент зовется "анализатор". Статический подвид входит в практически любой современный компилятор, иногда даже отдельным модулем. Благодаря этому, последним можно выставить обработку предупреждений анализатора как ошибок компиляции, чтобы "почти как в расте". Все уже придумано за нас)
Так не все делают по простой причине — часто нет времени вылизывать все дочиста, если код может работать и так. Хотя сейчас становится проще и редакторы учатся проводить анализ в процессе написания кода, чтобы можно было чинить по факту
Но на самом деле, 2/3 примеров не пройдут даже лексический анализ
Ну понятное дело, но и смена языка тоже не спасет)
Про помнить каждую переменную и количество объектов не понял, опять же, в чем именно си хуже любого другого языка. К слову, в нем нет NULL'ов, зато есть самые обычные нули
Как чего, падению квалификации. Софт-то кому-то писать надо, нам же его и использовать, если доживем
Это и моя же позиция)
Вот только почему нынешние неудобные? То есть, тот же раст на самом деле имеет кучу интересных фич, но зачем-то позиционируется многими как замена си со смущающей меня аргументацией. Так тяжело существовать параллельно, что ли?)
Это отличный пример, кстати, недавно как раз видел расследование аварии на взлетной полосе из-за одного пропущенного уточнения. Правда, софт для аналогичных задач все равно на языках с возможностью прострела ноги пишется
В моем представлении, надо в первую очередь поднимать квалификацию, и свою, и чужую. А то так все просто разленятся и через 20 лет будут жаловаться на слишком свободный раст)