OSDev

Да, я и имел в виду самостоятельную реализацию info_level, но хотелось бы иметь в языке или в библиотеке этого языка нечто более удобное, чем #define, #ifdef и т. д. Причём желательно, как я уже говорил, организовать работу запущенной программы так, чтобы уровень вывода сообщений можно было менять в «горячем» режиме. Будет ли это сделано в виде команд интерпретатора или с помощью каких-то сторонних инструментов, которые посылают в программу нужные команды, это детали. Важно, чтобы можно было вставлять в код программы (в нужные места) команды, которые умели бы принимать сообщения извне и менять свои настройки.

Спасибо. Да, увы, во многих местах написано через «е», тогда как я стараюсь использовать «ё», где разрешают. Часто запрещают, и даже пример «страна передохнёт холода» мало кого убеждает.

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

Тут есть, как Вы верно намекаете, косвенная связь. Дело в том, что определённые особенности реализации библиотек могут довольно сильно зависеть от того, какие синтаксические конструкции предоставляет язык. Привожу пример: в C++ не было «лямбд», зато были извращения с разнообразными и трудночитаемыми указателями на функции, прописать полное определение которых можно было только в несколько строк. Теперь стало проще. Другой пример: раньше не было возможности вернуть из функции локальный объект без лишних операций создания копий, приходилось возвращать большие объекты по ссылкам, делая дополнительные параметры при вызове функции и прочие неестественные для современного стиля извращения. Теперь, когда появились R-value references, ситуация стала куда лучше. Так вот, я бы хотел, чтобы синтаксис был продуман настолько, чтобы не возникало подобных неудобств, заставляющих многие естественные для математика операции выполнять неестественным образом.

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

Тогда желательно, чтобы компилятор умел нормально объединяться с известными ассемблерами. Это далеко не всегда обеспечено. Ещё один вариант - так называемые intrinsics функции.

Как Вы видите свою идею для реализации, например, типа данных Int72? Даже если так, всё равно доступ к флагу переноса бывает нужным сам по себе, без ADC. Конечно ADC rax, 0 может выдать нам этот флаг, но уж больно это по-инвалидски. Тем более, это вынуждает использовать константу 0, которую а ассемблере как-то редко принято использовать в таком контексте, если только речь не идет об адресах и смещения или просто для красоты (когда идёт серия подряд add rax, [rdi + 0*4], add rax, [rdi + 1*4] и т. д.)


Хорошо, но я рассуждаю вот как. Есть жёсткие функциональные языки, однако они слабо повлияли на создание и популяризацию архитектуры ЭВМ, которая была бы чем-то похожа на такую парадигму. Напротив, популярные архитектуры скорее похожи на императивные языки. Эти языки развивались под действием этой архитектуры и вообще образа алгоритмического мышления в виде последовательности команд. Иными словами, раз у нас архитектура x86 или любая на неё концептуально похожая, то и язык должен быть уже императивным. Не вполне уверен, что декларативный язык (в т. ч. функциональный) будет хорошо ложиться на такую архитектуру, то есть нет смысла, например, сажать свинью в стойбище и, наоборот, коня в свинарник - им там будет «некомфортно». Хотя декларативная концепция может быть удобной для «чистых» математиков. Но у них есть Haskell, Miranda и у кого-то даже CL, их устраивает. А мне что-то неймётся.

К сожалению, не сильно ближе. Я привёл лишь пример с int128, в некоторых проектах мне нужен был тип int512 и int768, а также иногда нестандартные конструкции вроде int144. Кроме того, я пишу о проблеме более широко: у программиста нет доступа к некоторым инструкциям и данным процессора (например, к регистру флагов). Это мешает делать некоторую работу.


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

Кроме того, к OpenMP у меня множество претензий, связанных с ограничениями на циклы, которые он требует. Он неплохо работает с типичными циклами, но специально уродовать программу ради того, чтобы привести какой-нибудь цикл к типичному - этого не правильно. А параллелить на 400 ядер-то им вообще вредно : )

[ 7 ] :: Принцип однозначности языковых конструкций

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

В плохом, но лучшем (лично для меня) языке программирования C++ есть масса неоднозначностей. От простых до самых злодейских. Вот простая неоднозначность, которую можно было наблюдать лет 8 назад, хотя, возможно, она осталась в разных компиляторах и по сей день (я не пишу так больше). Это конструкции типа i = ( i ++ ) * ( ++ i ).

Можно привести ещё много примеров, и при множественном наследовании, и при перегрузке функций, и даже самый злостный пример (из книги Скотта Майерса «Эффективное использование STL», совет №6):

Можно подумать, что мы копируем числа из файла в список data, а на самом деле мы определяем функцию data, возвращающую список из целых чисел и принимающую два аргумента, второй из которых является безымянным указателем на функцию! А всё потому, что запись типа int а ( int ( ) ) интерпретируется как функция, принимающая указатель на функцию, возвращающую int, ведь разрешено не указывать явно имя указателя и опускать звёздочку при этом.

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

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

Ещё напоследок шутка, которая заставляет задуматься. Трудно создать язык, на котором совсем-совсем нельзя написать что-то совершенно дикое : )



[ Продолжение следует ]

Пожалуй это самое трудное. Современные языки на одном операторе к примеру "+" имеют до 8 различных операций.
Сложение указателей, конкатенация сток, сложение чисел, увеличение инкремента(в си++ аж левый и правый), оператор класса, в регулярках так означает от 1 до бесконечности. И тп.

и

Взаимоисключающие требования, однако.

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

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

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

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

Проблема многих языков, и, в частности, C/C++, не в том, что на них можно написать нечто совершенно дикое, а в том, что они поощряют такое написание или вообще делают его единственно возможным. Идеальный язык не должен запрещать совершенно дикую писанину, но он не должен её требовать для решения любых практических задач. Ну а кому хочется поизвращаться -- тот пускай извращается.

И как вы себе это представляете? К примеру есть в математики понятия "поля". Это класс чисел с определенными операторами "+", "-" и рядом свойств. Как реализовать такое в языке программирования? Да так что бы без извращений. Если не путаю то у Страуструп "верёвка достаточной длины, чтобы выстрелить себе в ногу" разбирается часть проблем при перегрузке операторов.

А как вы отнестись к тому чтобы запретить располагать в одном групповом блоке({}, begin end) более одного цикла последовательно? Вложенные при этом разрешены.
Запрещено

разрешено

разрешено

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

SII верно говорит, запрещать ничего нельзя, но нужно сделать язык таким, чтобы на нём было бы естественным писать естественно, а неестественным было бы писать неестественно : )


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

Нет, уважаемый SII, проблема C/C++ именно в том, что на них можно написать дикое. Именно поэтому это плохие языки. Было бы нельзя написать дикое -- были бы хорошие.

В соседней теме я описал пример-ловушку из своей практики, который наверняка станет предупреждением (warning) и вызовет остановку компиляции в строгом режиме, который будет включен по умолчанию (warnings as errors).


Это именно тот принцип, которому я стараюсь следовать.

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

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

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

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

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

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

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

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

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

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