LINUX.ORG.RU

Существует ли язык высокого уровня, который устойчиво быстрее C?

 ,


0

1

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

Понятно что существует ассемблер, программу на котором можно сделать настолько быстрой, насколько это вообще возможно для данной машины за счёт контроля каждого байтика, но речь не о нём — я говорю о языке высокого уровня, который полностью абстрагируется от машины, так чтобы программа на нём могла быть скомпилирована на любой машине и для любой ОС.

Так вот, возможно ли сделать такой язык? Если да, то в каком направлении копать?

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

★★★★★
Ответ на: комментарий от monk

в браузере нет

Потому что ты можешь открыть сколько хочешь окон, в которых видеть страницы любого размера. Можно и по-другому: открыл 2-3 окна и тебе говорят «закончилась память». Или даже одну большую страницу не смог открыть.

den73 ★★★★★
()
Ответ на: комментарий от den73

Потому что ты можешь открыть сколько хочешь окон, в которых видеть страницы любого размера.

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

monk ★★★★★
()
Ответ на: комментарий от den73

Если посмотреть Википедию, то она трактует термин «утечка памяти» так же, как я его трактую.

Уте́чка па́мяти (англ. memory leak) — процесс неконтролируемого уменьшения объёма свободной оперативной или виртуальной памяти компьютера, связанный с ошибками в работающих программах, вовремя не освобождающих ненужные уже участки памяти. (c) Википедия

«процесс неконтролируемого уменьшения объёма свободной оперативной или виртуальной памяти компьютера» == «когда использование памяти программой в ходе использования постоянно растёт»

В том и дело, что без сборки мусора не всегда возможно избежать unchecked_deallocate.

В какой задаче нельзя?

monk ★★★★★
()
Ответ на: комментарий от den73

Так что если там GC что-то роняет, это ничего не доказывает.

Он роняет, так как для самого GC требуется память пропорциональная количеству собираемых элементов. Кстати, хотя бы в принципе, бывают GC с постоянным объёмом используемой памяти? Счётчик ссылок добавляет по счётчику на каждый объект, такой как в SBCL — строит множество удаляемых объектов в процессе сбора.

monk ★★★★★
()
Ответ на: комментарий от monk

(c) Википедия

Если почитать статью дальше, там расшифровано. Причём именно так, как это понимаю я. «Т.е. в 5-й строке невозможно ни получить доступ к первым 9 объектам, ни удалить их.» И далее - сборка мусора как способ избавиться от утечек памяти. Т.е., можно сказать, что в Википедии недостаточно чёткое определение, при том, что сама статья правильная. Просто больше мне сослаться было не на что.

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

Так и было в ДОСЕ. Код программы в оверлеях, файлы редактора в памяти. Потом появилась виртуальная память и программисты вздохнули свободно. Если же ты говоришь о надёжности, то какая разница, что у тебя закончится - место в памяти или место на диске? Надёжный в этом смысле браузер - это браузер, способный просматривать ограниченное количество страниц ограниченного размера.

Он роняет, так как для самого GC требуется память пропорциональная количеству собираемых элементов. Кстати, хотя бы в принципе, бывают GC с постоянным объёмом используемой памяти? Счётчик ссылок добавляет по счётчику на каждый объект, такой как в SBCL — строит множество удаляемых объектов в процессе сбора.

Просто нужно посчитать максимальный объём памяти, занимаемый в момент GC и соответственно ограничить выделение памяти. Скажем, есть у тебя гигабайт - запрещай дальнейшее выделение после 512 Мб.

В какой задаче нельзя?

Например, ты не сможешь реализовать Common Lisp. А любая достаточно сложная программа, как известно, содержит...

den73 ★★★★★
()
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от Aswed

Какой адепт, ты про что вообще?

Адепт секты свидетелей помойки.

Чтение рукописного текста например.

Задача не решенная в этом мире.

Распознавание глазами неразборчивого почерка - отличный пример нечеткой логики ИРЛ.

Не реализовано в этом мире. Без разницы какого текста - разборчивого или нет - любое распознавание строится на коэффициентах соответствия. Почему адепты называют вычисление и значение этих коэффициентов «нечёткой логикой» - мне не ведомо.

Это такое же сравнение с чётким шаблоном основанное на той же чёткой логике. Равно-не равно, либо вообще без какой-либо логики. Почему вдруг несколько чётких вдруг стало не чёткими?

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

Коэффициенты превращаются в логику отдельно и она всегда чёткая. максимум-равно, либо максимум-больше и прочее. Конкретные значения не имеют значения.

Нечёткая логика без возможности интерпретировать эти коэффициенты - не имеет смысла.

Давай попроще - поиск по шаблонам - не есть анализ текста. Хоть в анализ и входит поиск по тем же шаблонам - без интерпретации оно не имеет смысла, да и интерпретации должна быть на уровне ИИ - т.е. уметь выводить новое/сводить, ибо это основа анализа.

Точно так же и с логикой - без возможности к интерпретации логика не является логикой. Т.е. ты взял какую-то помойку и назвал её логикой.

Нечёткая логика возможно только на уровне человека, либо на уровне брехняматики. Но только на уровне брехняматики.

В целом брехняматика - это чистейшая шизофазия, вот адепты которые послушали вчера пару по брехне орут и обвиняют всегда всех в шизофазии, хотя сама брехня - каноничный пример. Есть правила брехняматики, соответствие с реальным миром которых никак не доказано, да и мало того - просто не работают. Этот вопрос решается с подмены арифметики и всяких отношений, которые являются проекцией реального мира - т.е. мир сам по себе исчисляем безо всякой арифметики. Любые процессы происходят сами по себе - а формулки это лишь их численное выражение, которое никакого отношения к реальному миру не имеет и не раскрывает процессы в полной мере.

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

Поэтому на уровне брехняматики может работать всё, что угодно - брехун может считать, что неопределённое значение коэффициента соответствия может как-то интрпретироваться, ни какие механизмы не описаны. Вместо этого уже в численных представлениях все неопределённости заменяются на константы и отношения, выведенные эмпирически - не логически.

Нет никаких даже намёков на существования каких-то даже минимальных описаний принципов по которым это хоть как-то могло бы работать - я уж не говорю о том, чтобы работало.

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

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

Опять амбёы пытаются меня ловить.

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

Ну и по умолчанию то, что я понимаю под задачами: Задачи обусловленные объективными потребностями биомусора в мире, т.е. не какой-нибудь анонизм на тему эксплуатация рабов и прочее. Именно объективно катирующиеся

Это только описание понимания, а дальше есть описание программиста:

anonymous
()
Ответ на: комментарий от Aswed

Есть конкретный набор требований, определяющих тебя как программист, в данном контексте, который может в понимание сути вещей.

Он должен понимать сути вещей в наборе, определённых контекстом. Т.е. тут ещё были определены понятия как а) оптимальный, но это выводится из «конкретных решений», ибо конкретные решения - единственно оптимальны. и т.д.

Ну и само собой определенна тема - это разработка решений уровня железяки и её управления.

Тут видишь-ли всплывает нюанс: Какие задачи должен решать программист, а какие нет.

Не важно - определяет его понятие «как», если мы говорит наборе конкретных задач.

Задач очень много от ИИ-подобных систем

Примитивное дерьмо. Не является конкретной задачей, а в конкретной её форме никакого отношения к ИИ не имеет, да и в любой другой так же.

и физических движков

Тоже примитивщина. Здесь цену играет качество реализации, а не факт. К программисту сама физика и матаппрат отношения не имеет, поэтому не надо мне тут кукарекать про них.

до операционных систем и компиляторов с оптимизациями.

То же примитивное дерьмо. Определяется качеством реализации - остальное не стоит ничего. Оптимизации - примитивное дерьмо, определяющиеся только человекачасами и уровнем лапши. - все оптимизации это финдреплейс.

Все они разные, требуют знания разных разделов математики и нет людей, которые все это делают одинаково хорошо.

Ничего ни одна задача не требует, кроме физики и то - там хватает уровня первого класса, да и точность настолько дерьмо, что такого уровня физику я могу написать на коленке чисто эмпирически.

Ещё раз - сложность определяется только реализацией. Остальное никого вне помойки не волнует.

Зато есть люди, которые сильны в своей области.

Нет, все области смежные. Для вменяемой реализации числодробилки нужны знания уровня «царя ОС» и умение в логику на уровне «царя конпеляторов».

Всё это требует с т.з. прикладного уровня одних и тех же знаний и понимания. Теоретическая часть любой конкретной задачи в данном случае не важна - она существует отдельно.

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

Так кто же из них программист?

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

А что конкретно они делают - никого не интересует, если это задача обусловленная потребностями реального мира.

anonymous
()
Ответ на: комментарий от Aswed

ОС - программисты, ИИ и компиляторы - макаки за клавиатурой?

ИИ как задача и область - дерьмо убогое не имеющее к ИИ никого отношения. А сами задачи ничем не отличаются от иных.

Конпелятор в текущем его понимании у адептов - бесполезный мусор с т.з. реализации и вкладывания ресурсов - он не имеет смысла. Любой человек, который обладает мозгом - он не будет делать то, что не имеет смысла.

Точно так же, как не имеет смысла считать «физические движке» на калькуляторе секретарши, как замена железяки специализированно, так же не имеет смысла реализовывать вообще какую-то псевдо ИИ логику, как замена не железяки специализированной.

Задачи для «ии» - это задачи не по замене, а по уподоблению там, где идеал не может или не хочет в этом, а уровень самих задач примитивен.

Т.е. задача оптимизатора в конпеляторе - не имеет смысла - это примерно так же, как считать «физический движок» на калькуляторе. Это убожество не обладает даже миллардной долей способностей рядового человека к анализу.

А вот задачи распознавания, эмуляции поведения обезьяны - хоть и на сотни порядков слабее, но имеют реальный смысл. Т.е. задачи в помощь идеалу там, где он может не страдать хернёй. Все попытки его заменить - не имеют смысла.

Компиляторы - программисты, ОС и ИИ - макаки?

Ещё раз - этого не волнует.

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

Тут да - ничего не нужно. И поведение обусловлено обезьяной - зачем платить больше? Зачем делать больше, чем дядя сказал? Надо делать как можно меньше, даже если дядя сказал больше - пока жрать дают. Т.е. мотивация уровня - сделать поменьше - урвать побольше.

Это всё не поведение человека - это поведение примата. А то, что приматы оценивают факт человечности по биологическому признаку, хотя сознание априори определяет человека - это никому не интересно.

А уровень сознания определяет плодами его творчества, т.е. созданием нового. Т.е. то, что и лежит в основе разума - преобразование в новые формы как раз таки без шаблонов и чёткой логики.

При оценки адепта происходит такая же подмена понятия и нечёткой логикой называется не факт возможности интерпретировать нечёткие результаты, а само наличие нечётких результатов с последующий интпретацией на уровне табуретки.

anonymous
()
Ответ на: комментарий от anonymous

я смотрю, философов прибавилось на лоре

ACR
()

Такой язык есть. Lisp называется :-) В теории он лучше такого уродства, как C или цепепе. Но на практике он на задворках. :-) Ты учи C уже и не парься :-) Пока не познаешь КАК с помощью C создавать полезный софт, а не ненужное говно, так и будешь нешарящим слепцом, верящим в расчудесные «современные» (nowadays!!111) технологии :-)

anonymous
()
Ответ на: комментарий от SZT

Интеллект - это иллюзия. Он не сущность, а особенность человеческого восприятия. Зная механизм, можно прослыть крутым интеллектуалом (если есть нужда).

Поэтому его нельзя не познать целиком, ни создать в виде искуственной эмуляции.

barberry ★★
()
Ответ на: комментарий от barberry

Интеллект - это иллюзия.

Бугага :-) Помойка - реальность :-)

Он не сущность, а особенность человеческого восприятия.

Докажи :-)

Зная механизм, можно прослыть крутым интеллектуалом .

Якiiiiiii таiiiiii механiiiiiзмъ? :-)

(если есть нужда)

Глупо :-)

Поэтому его нельзя не познать целиком, ни создать в виде искуственной эмуляции.

Что это за астрал? :-) И поставь spell-чекер :-)

anonymous
()
Ответ на: комментарий от den73

Если почитать статью дальше, там расшифровано.

Это можно считать примером. В том смысле, что он не исключает других примеров утечки памяти.

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

Места на диске как правило намного больше. Хотя с определением надёжного браузера согласен.

Просто нужно посчитать максимальный объём памяти, занимаемый в момент GC и соответственно ограничить выделение памяти. Скажем, есть у тебя гигабайт - запрещай дальнейшее выделение после 512 Мб.

То есть, если утечка памяти за ожидаемое время работы программы не превысит 100% от используемой, то лучше GC не использовать. Какая разница память занята утечкой или зарезервирована для GC?

без сборки мусора не всегда возможно избежать unchecked_deallocate.

В какой задаче нельзя?

Например, ты не сможешь реализовать Common Lisp.

Большинство реализаций лиспов (и, вроде как, JVM) не используют unchecked_deallocate (т.е. free) совсем. Программа при запуске резервирует некоторое количество мегабайт и всё. GC работает внутри этого «динамического массива».

monk ★★★★★
()
Ответ на: комментарий от monk

Большинство реализаций лиспов (и, вроде как, JVM) не используют unchecked_deallocate (т.е. free) совсем. Программа при запуске резервирует некоторое количество мегабайт и всё.

Отсюда следует, что возникает небольшая проблемка на Линуксах, где работает OOM-killer — если рантаймом зарезервировано много мегабайт, то он может быть угрохан, если не предпринять дополнительных телодвижений :-)

anonymous
()
Ответ на: комментарий от anonymous

где работает OOM-killer — если рантаймом зарезервировано много мегабайт, то он может быть угрохан, если не предпринять дополнительных телодвижений

Я всегда думал, что OOM убивает только того, на ком закончилась память (кто последний запросил). А на самом деле — кто больше всех зарезервировал?

P.S. Прочитал алгоритм — действительно так.

monk ★★★★★
()
Ответ на: комментарий от monk

P.S. Прочитал алгоритм — действительно так.

PS2. А из этого уже следует, что SBCL более привлекателен, чем CCL, где резервируется на старте гигантский кусок памяти, уменьшить размер которого никак нельзя :-)

anonymous
()
Ответ на: комментарий от anonymous

А из этого уже следует, что SBCL более привлекателен, чем CCL, где резервируется на старте гигантский кусок памяти, уменьшить размер которого никак нельзя

/usr/bin/ccl
echo -17 > /proc/$!/oom_adj

И OOM больше не беспокоит

monk ★★★★★
()
Ответ на: комментарий от anonymous

Такой язык есть. Lisp называется :-)

Уже адепт выше выкатывал «проект на лиспе» - он оказался сишкой под видом коммонлиспа.

Вот когда ты мне выкатишь что-то, кроме хелворда и бесполезного дерьморантайма к твоему же лиспу - твой пердёж будет иметь смысл, а щас.

Максимум как используется лисп - это примитивная скриптуха уровня брайнфака и то на диалекте.

В теории он лучше такого уродства, как C или цепепе.

У нас есть лисп, который лучше. У нас есть ты - эксперт по лиспу. Но на лиспе у нас ничего нет. Вот ведь незадача, да?

Пока не познаешь КАК с помощью C создавать полезный софт, а не ненужное говно

Полезный софт в понятиях адептов - это любой дерьмо за которое дали еду. А еду дают за любое дерьмо, вопрос только в том - сколько.

так и будешь нешарящим слепцом, верящим в расчудесные «современные» (nowadays!!111) технологии :-)

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

А «современные» «технологии» - технолоии и современные только во влажных мечтах мусора.

anonymous
()
Ответ на: комментарий от monk

И OOM больше не беспокоит

А раком вставшая помойка тоже?

anonymous
()

Понятно что существует ассемблер, программу на котором можно сделать настолько быстрой, насколько это вообще возможно для данной машины за счёт контроля каждого байтика, но речь не о нём — я говорю о языке высокого уровня, который полностью абстрагируется от машины

полностью абстрагируется от машины

аа, ты про русский мат, что ли?

darkenshvein ★★★★★
()
Ответ на: комментарий от anonymous

Уже адепт выше выкатывал «проект на лиспе» - он оказался сишкой под видом коммонлиспа.

Я хз о каком ты «проекте на лиспе» под видом коммонлиспа от адепта ты гутаришь :-) А тред читать западло :-)

Вот когда ты мне выкатишь что-то

Зачем тебе что-то выкатывать? :-)

твой пердёж

Наслаждайся молча :-)

У нас есть лисп, который лучше. У нас есть ты - эксперт по лиспу. Но на лиспе у нас ничего нет. Вот ведь незадача, да?

Сказано же: «в теории» :-) Ещё фужер дерябни, сразу учитаешь :-)

Полезный софт в понятиях адептов - это любой дерьмо за которое дали еду. А еду дают за любое дерьмо, вопрос только в том - сколько.

Еду? А как же водочка? :-) Ну а ежели серьёзно, то полезный софт - это такой софт, который улучшает качество жизни населения :-) Остальное неважно :-)

anonymous
()
Ответ на: комментарий от monk

Большинство реализаций лиспов (и, вроде как, JVM) не используют unchecked_deallocate (т.е. free) совсем

Зато используют сборку мусора.

den73 ★★★★★
()
Ответ на: комментарий от monk

То есть, если утечка памяти за ожидаемое время работы программы не >превысит 100% от используемой, то лучше GC не использовать. Какая >разница память занята утечкой или зарезервирована для GC?

Ты как-то на ходу меняешь тему разговора. Тема вообще-то - быстрые языки высокого уровня быстрее С. Ты добавил требование надёжности - это резонно, в такой постановке мне обсуждать интереснее. Давай не будем переходить на вопрос критериев оценки потребления памяти, пока не решены предыдущие вопросы.

Утечка памяти (в моём смысле) - это дефект. А расход памяти на GC - это особенность. Если ты не можешь локализовать утечку, связанную с указателями, ты не можешь и дать гарантий по поводу масштабов этой утечки. Но это уже следующий вопрос, а мы с предыдущим не разобрались.

Ты заявлял, что Ада быстра и надёжнее С. Я опроверг её надёжность ссылками на документацию. Повторюсь: либо Ада со сборкой мусора (тогда будут проблемы с рилтаймом), либо Ада без сборки (тогда либо free и повреждение памяти, либо потеря общности).

Для себя я этот вопрос решил так (с твоей помощью): Ада со сборкой мусора эквивалентна Java и Lisp - в ней можно обойтись без unchecked_deallocate, но она будет лагать.

Ады без сборки мусора отличается от С/C++ по надёжности только количественно, но не качественно. В ней неизбежны проблемы с указателями, в т.ч. из-за free.

Т.е. Ада в любом случае не представляет нового слова в технике и нового класса языков. Она попадает в компанию либо к С++, либо к Java.

А интересен, конечно же, язык с надёжностью Java и скоростью C. Rust претендует стать таким языком.

Дальше, утечка памяти в моём смысле возможна в С++, Аде без сборки мусора и Rust, но невозможна в Lisp и Java.

Т.е. Rust в какой-то степени выпадает в отдельный класс - из всех зол в нём неизбежна только утечка памяти, остальное вроде как можно побороть. Ада же ничем особым не примечательна.

Давай всё же поставим здесь какой-то знак препинания. Ты согласен с этим или нет?

den73 ★★★★★
()
Ответ на: комментарий от den73

а язык D уже обсуждали?, высокоуровневые конструкции для школьников, статическая/динамическая типизация, орбатый коллектор можно включить а можно отключить, мечта а не язык, правдо компиляторов нету

ACR
()
Ответ на: комментарий от ACR

а язык D уже обсуждали?

Бугага :-)

anonymous
()
Ответ на: комментарий от ACR

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

наркоман чтоле?

anonymous
()
Ответ на: комментарий от monk

Я всегда думал, что OOM убивает только того, на ком закончилась память (кто последний запросил).

Можно и так настроить

annulen ★★★★★
()
Ответ на: комментарий от anonymous

Я хз о каком ты «проекте на лиспе» под видом коммонлиспа от адепта ты гутаришь :-) А тред читать западло :-)

Ну тот, где лисп с классами, циклами, массивами и переменными. Типичный лисп.

Зачем тебе что-то выкатывать? :-)

Не как - тыж кукарекаешь, что можешь - можешь выкатывай. Ведь что-то в мире должно подтверждать твою теорию, иначе она - твои влажные фантазии.

И основная твоя задача - эти подтверждения искать и собирать, ты должен их знать назубок. И выкатывать ты их должен сразу. Если этого не ты - ты брехло и трепло.

Наслаждайся молча :-)

Зачем? Если проще определить тебя как мусор и ты побежишь плакаться мамочки, либо будешь лизать жопу и делать вид, что ничего не было - типичный второй вариант.

Сказано же: «в теории» :-) Ещё фужер дерябни, сразу учитаешь :-)

Про теорию я тебе уже выше описал. Никаких подтверждений твой теории нет, а сама она обсирается только от вида меня.

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

Еду? А как же водочка? :-) Ну а ежели серьёзно, то полезный софт - это такой софт, который улучшает качество жизни населения :-) Остальное неважно :-)

Такого софта в районе нуля. Само существование лиспа противоречит твой описанию, так же как и его адепты.

Я уже писал - что такое лисп и брехняматика. Существует ли язык высокого уровня, который устойчиво быстрее C? (комментарий) - вот тут.

Лисп и брехняматика - это то, что противоречит развитию человека как такового, даже в примитивном «научном» познании мира. Это брехня способствует только деградации и убогости и не несёт никакой пользы наслению.

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

Ибо он настолько убогий, что не способен ни на что. Если адепты совсем выродятся в обезьян, то как же мы будем жить? Поэтому любой подход и язык должен содержать в себе хотя-бы что-то, что связывает его как-то с реальным миром. Тут же связи нет - место ему на помойке, даже в мире обезьян.

anonymous
()
Ответ на: комментарий от den73

либо Ада без сборки (тогда либо free и повреждение памяти, либо потеря общности).

Ещё раз повторюсь: очень большой класс задач на Ада решается без динамической памяти (а значит и без free).

Ады без сборки мусора отличается от С/C++ по надёжности только количественно, но не качественно.

Большая часть ошибок ввода (опечаток, приводящих к синтаксически корректной неверной программе), возможных в C/C++, в Ада устранены. Работа с массивами и строками намного безопасней. Если же ты исключительно про программы, активно работающие с динамической памятью, то тогда согласен.

Т.е. Ада в любом случае не представляет нового слова в технике и нового класса языков. Она попадает в компанию либо к С++, либо к Java.

Согласен.

А интересен, конечно же, язык с надёжностью Java и скоростью C. Rust претендует стать таким языком.

Ещё Haskell есть. Подстановка и специализация позволяют компилятору делать очень эффективные программы.

Т.е. Rust в какой-то степени выпадает в отдельный класс - из всех зол в нём неизбежна только утечка памяти, остальное вроде как можно побороть. Ада же ничем особым не примечательна.

Какие ещё «из всех зол» неустранимы в Ада, но устранены в Rust?

monk ★★★★★
()
Ответ на: комментарий от ACR

ну на уровне пользовательских типов

Речь об opDispatch или всё-таки о чём-то другом?

DarkEld3r ★★★★★
()

rust? в некоторых задачах erlang?

anonymous
()
Ответ на: комментарий от monk

опечаток, приводящих к синтаксически корректной неверной программе

Можешь перечислить те, про которые gcc не умеет warnings выдавать?

anonymous
()
Ответ на: комментарий от anonymous

Ну тот, где лисп с классами, циклами, массивами и переменными. Типичный лисп.

Про Лисп с классами понятно :-) О каком «проекте на лиспе» речь? :-)

Не как - тыж кукарекаешь, что можешь - можешь выкатывай. Ведь что-то в мире должно подтверждать твою теорию, иначе она - твои влажные фантазии.

Та даже один маленький фактик, что в Лиспе на каждый чих не надо неделями надрачивать очередной уродливый тормозной парсер уже делает Лисп лучше, чем ублюдочный Ц или выродок цепепе :-)

Зачем? Если проще определить тебя как мусор и ты побежишь плакаться мамочки, либо будешь лизать жопу и делать вид, что ничего не было - типичный второй вариант.

Так а кто тебе мешает? :-) Определяй давай :-) Но кто ты есть вообще, чтобы твоё мнениешко имело значение? :-)

Про теорию я тебе уже выше описал. Никаких подтверждений твой теории нет, а сама она обсирается только от вида меня.

Ну так сходи в салон красоты, приведи себя в порядок :-)

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

Должен? :-) Кому я должен чего? :-) Бугага :-)

Я уже писал - что такое лисп и брехняматика. Существует ли язык высокого уровня, который устойчиво быстрее C?... - вот тут.

Так там вода одна :-) Это пример «брехняматики»? :-)

Это брехня способствует только деградации и убогости и не несёт никакой пользы наслению.

Согласен :-) Брехня она да, способствует деградации... :-)

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

Не только :-) Польза ещё и в просветлении :-) А что польза для тебя? :-)

anonymous
()
Ответ на: комментарий от anonymous

Можешь перечислить те, про которые gcc не умеет warnings выдавать?

Ну вот, например,

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int a[4];

int test_a(int x)
{
  int i;
  for(i = 0; i<=4; i++) // выход за границы массива
    if(a[i] == x) return 1;
  return 0;
}


int main() {
  char *s = malloc(5);
  int i = 1;
  int j = i == 1; // здесь опечатка, должно быть i = j = 1;
  scanf("%s", s); // здесь переполнение строки
  printf("%i\n", j);
  printf("%i\n", test_a(1));
  printf("%lu\n", strlen(s));
}

gcc -Wall компилирует молча. gcc (Debian 5.3.1-4)

monk ★★★★★
()
Последнее исправление: monk (всего исправлений: 1)
Ответ на: комментарий от monk

Более того, после gcc -O3 в objdump -S видно

0000000000400640 <test_a>:
  400640:       b8 01 00 00 00          mov    $0x1,%eax
  400645:       c3                      retq
  400646:       66 2e 0f 1f 84 00 00    nopw   %cs:0x0(%rax,%rax,1)
  40064d:       00 00 00

То есть UB используется для того, чтобы всегда возвращать 1. Вне зависимости от содержимого массива и проверяемого числа

monk ★★★★★
()
Ответ на: комментарий от anonymous

Про Лисп с классами понятно :-) О каком «проекте на лиспе» речь? :-)

http://method-combination.net/lisp/ironclad/

А так - на любом, которые сложнее хелворда.

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

Чё?

уже делает Лисп лучше, чем ублюдочный Ц или выродок цепепе :-)

То, дерьмо, что подразумевает под лиспом балаболка не имеет никакого отношения к реальности. То дерьмо не пригодно ни для чего - даже хелворд на нём не напишешь.

Любой диалект лиспа, который хоть как-то юзабелен - ничем от цпп не отличается.

Так там вода одна :-) Это пример «брехняматики»? :-)

Ну давай, мразь, выкатывай мне основание для определения это как «вода» - я жду.

Согласен :-) Брехня она да, способствует деградации... :-)

Ты типа решил сослить и сменить тактику? Не фортануло в одном стиле - решил в другом?

Не только :-) Польза ещё и в просветлении :-) А что польза для тебя? :-)

Ты адепт лиспа - да, ты убогая мразь - да. Комментарии излишни. Тут даже ничего больше и не надо. Сам лиспоадепт живой пример того самого просветленного - типичный блаженный.

anonymous
()
Ответ на: комментарий от monk

Большая часть ошибок ввода (опечаток, приводящих к синтаксически корректной неверной программе), возможных в C/C++, в Ада устранены.

for(i = 0; i<=4; i++) // выход за границы массива

Это не опечатка

int j = i == 1; // здесь опечатка, должно быть i = j = 1;

Это не опечатка. Я понимаю там можно как-то объяснить недопечатку, что бы из == появилась =, но никак == вместо = объяснить нельзя.

scanf(«%s», s); // здесь переполнение строки

Это рантайм и никакого отношения к си не имеет. Да и к опечатке так же.

Ты можешь в нормальные примеры, либо адепты ады на это не способны?

Работа с массивами и строками намного безопасней. Если же ты исключительно про программы, активно работающие с динамической памятью, то тогда согласен.

Подробней об этом, с примерами.

anonymous
()
Ответ на: комментарий от monk

То есть UB используется для того, чтобы всегда возвращать 1. Вне зависимости от содержимого массива и проверяемого числа

И, что из этого следует? Как он должно работать?

anonymous
()
Ответ на: комментарий от anonymous

http://method-combination.net/lisp/ironclad/

Ах, так это же Лисп. В отличии от унылых недоязыков, типа C, в которых даже такая тривиальная вещь, как JIT, с горем пополам и через анальное отверстие реализовано в GCC 5 как экспериментальная библиотечка, может выглядеть и как C, и как JavaScript, и даже как цепепе, если кому-то такой бред придёт в голову :-) Бугага :-)

Любой диалект лиспа, который хоть как-то юзабелен - ничем от цпп не отличается.

Отличается хотя бы тем, что в цепепе с его уродливым уродством уродств под названием «шаблоны» можно вывихнуть мозг, а строчку во время компиляции так и не сгенерить :-) Хотя бы тем отличается, что не надо надрачивать организацию хедеров и файлов реализаций, не надо следовать ODR-правилу, чтобы программа компилировалась быстрее, а исходники бы соответствовали «правилам хорошего тона для задротов». :-) Ну что уж там говорить то :-)

я жду.

Не дождёшься :-)

ы типа решил сослить и сменить тактику? Не фортануло в одном стиле - решил в другом?
Ты адепт лиспа - да, ты убогая мразь - да. Комментарии излишни. Тут даже ничего больше и не надо. Сам лиспоадепт живой пример того самого просветленного - типичный блаженный.

Беседа удалась :-)

anonymous
()
Ответ на: комментарий от anonymous

Ололошки. Ты что, на полном серьезе пытаешься секту свидетелей ИИ в чем-то убедить? Если так, то тебе бы и самому к доктору сходить надо. Здоровые люди с прокаженными не общаются.

anonymous
()
Ответ на: комментарий от monk

gcc -Wall компилирует молча

А это что такое?

foo.c: In function 'main':
foo.c:23:3: error: format '%lu' expects argument of type 'long unsigned int', bu
t argument 2 has type 'size_t' [-Werror=format]
foo.c:24:1: error: control reaches end of non-void function [-Werror=return-type
]

for(i = 0; i<=4; i++) // выход за границы массива

Да, здесь gcc стоило вы выдавать warning.

int j = i == 1; // здесь опечатка, должно быть i = j = 1;

Компилятор — не экстрасенс же. Ты бы ещё

    if(i <= j) { // здесь опечатка, должно быть i < j;

написал.

scanf(«%s», s); // здесь переполнение строки

Как уже сказали, рантайм.

anonymous
()
Ответ на: комментарий от unt1tled

Недавно научился, -Wmisleading-indentation.

anonymous
()
Ответ на: комментарий от anonymous

format '%lu' expects argument of type 'long unsigned int', bu

t argument 2 has type 'size_t'

На моём компьютере эти типы одинаковой длины. Хотя, может, у тебя gcc поновее.

Компилятор — не экстрасенс же

Как уже сказали, рантайм.

Я приводил примеры тех ошибок, что на Аде синтаксически невозможны. Gcc — один из лучших компиляторов C и C++, но синтаксис (и семантика) самих языков делают программирование на них едва ли не более опасным, чем на ассемблере.

monk ★★★★★
()
Ответ на: комментарий от anonymous

И, что из этого следует? Как он должно работать?

Хотя бы правдоподобно.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int a[4];

int test_a(int x)
{
  int i;
  for(i = 0; i<=4; i++) // выход за границы массива
    if(a[i] == x) return 1;
  return 0;
}

int main() {
  a[0] = 0;
  a[1] = 0;
  a[2] = 0;
  a[3] = 0;
  printf("%i\n", test_a(1));
  printf("%i\n", test_a(2));
}

выводит две единицы. То есть, a[4] одновременно равно и 1 и 2.

monk ★★★★★
()
Ответ на: комментарий от anonymous

Это рантайм и никакого отношения к си не имеет.

Этот рантайм — стандартная библиотека Си.

Подробней об этом, с примерами.

Я же тебе уже написал: Text_IO.Get_Line гораздо безопасней, чем gets, scanf. Нормальные массивы не позволяют читать/писать за их пределами, а также не позволяют указателю случайно попасть в массив не того типа.

Вот ещё про строки красивый глюк:

char *chomp(char *s)
{
    s[strlen(s)-2] = 0;
    return s;
}

int main()
{
   printf("%s", chomp("Test"));
}

Тоже никаких предупреждений при компиляции. А при запуске умирает :-)

monk ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.