OSDev

Для создания Си++ надо несколько десятков человеко лет. Компиляторы в одиночку не пишутся. И столько же надо для создания библиотек.
Такие вещи делаются коллективами и длиною 5-7 лет.

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


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


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


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


Да, согласен, только я бы увеличил срок лет на 10 хотя бы. А вообще, подобные вещи разрабатываются постоянно, без перерыва : )

Спасибо, тов. Zealint, за сносно агрессивный ответ
Но я со своей стороны не был нацелен на разнос в пух и прах ваших взглядов.


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

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

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

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

Кстати - фанаты С/С++ как раз часто относятся к категории понимающих, но привыкших и не желающих использовать что-то другое. Это точно, потому что по себе сужу

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


Ещё одна попытка решать за меня, что же нужно мне. Нет, я этого не заявляю.


Очень просто: Вы пытаетесь навести меня на следование каким-то классическим стратегиям и готовым решениям. Это неправильно. Следовать нужно тем стратегиям, которые приводят к правильному результату. Хотя это не отрицает использования готового при необходимости.

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

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

О да, сопротивление-то я и не учёл

Но что мешает воспринимать комментарии как просто чужое мнение ? Не предназначенное к немедленному исполнению.

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

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

Ого! Браво! Прям мои мысли.

[ 8 ] :: Отображение кода

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

Набирать текст можно по-разному. Наиболее привычным для программиста является вариант набора в одну моноширинную строку (или в две-три, когда 80 символов в строке мало). Например, формулу для чисел Фибоначчи он может набрать как-нибудь так (допустим, нет возможности и цели думать над задачей больше полутора секунд):

Это очень грустная для математика формула. Гораздо веселей она будет выглядеть как-нибудь так:



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

Есть сила привычки и ограниченный набор символов, которые удобно набирать с клавиатуры, а также всего 10 пальцев, два из которых стучат по пробелу. Поэтому трудно представить редактор, который позволил бы достаточно эффективно (по времени) набирать код вроде такого:



(разумеется, если чисто человеческие команды, как в строке 6, заменить на их эквивалент).

Лично мне больше нравится вот такая форма записи алгоритмов и форма кодирования как на картинках, а не такая, как, например, в C++, где логическое и - «&&», логическое или – «||», xor - «^», а остаток от деления – «%». Где логика? : ) Она явно осталась где-то в 80-х, поэтому лично от меня несколько ускользает.

Итак, я «за» то, чтобы кодировать можно было в более привычном для математика стиле, чтобы код программы был похож на то, что сейчас принято называть псевдокодом, а формулы были бы не однострочными, а в таком стиле, что на картинке выше. Однако очень может быть, что подобный способ кодирования окажется неэффективным. По себе могу сказать, что пишу код очень быстро, так как все символы языка C++ не требуют каких-то особых способов их ввода. А вот оператор типа «<--» (стрелка влево, или gets) вместо привычного присваивания уже может вынудить нажимать некую специальную комбинацию вместо одной кнопки «=».

С одной стороны (по моему мнению) программы, написанные в таком стиле, будут не только удобнее читать и понимать, но и проще делать их более компактными, так как богатый выбор возможностей набора формул и наличие разнообразных символов, например, utf-8, позволит сократить лексические извращения, которые появляются в результате необходимости всё набирать в одну строку. С другой стороны, это может замедлить процесс кодирования, однако тут есть и контраргумент: быстро писать в научных исследованиях требуется редко. Обычно это больше требуется на олимпиаде или при разработке ПО экстремальным методом, кроме того, рано или поздно можно будет научиться набирать подобный текст весьма быстро, если это всё-таки нужно. Когда я писал одну из своих книг, в конечном итоге научился набирать такие алгоритмы на псевдокоде в TeX довольно шустро. То есть если, скажем, разнообразные символы языка прикрепить к определённым сочетаниям клавиш, то скорость набора с опытом станет не ниже. Возьмите тот же vim, кто из профессионалов набора в нём не «ломал» поначалу пальцы? И ничего, не нарадуются этим инструментом, судя по подобным статьям.

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

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

Ожидаю бурю возражений, но спорить вряд ли буду, очень уж этот момент необычный : )

Самое важное в данном случае, это то, что вы называете "неудобствами" на самом деле является отсутствием соответствующих удобств, т.е. все эти лямбды и R-value references являются специально разработанными конструкциями и языковыми механизмами, которые привносят удобство. Соответственно, задача разработчика - придумать такие механизмы, которые облегчают работу программиста и математика. Поэтому я вижу смысл разработки языка в тщательном анализе и селекции существующих механизмов и в разработке новых.


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


Int72 - не вижу проблем. Умножения отбрасывают лишние разряды, сложения/вычитания добавляют перенос после операции с 64 битами к 8 битным операндам.
Тут дело вот в чём. С математической точки зрения, операция умножения всегда возвращает результат удвоенного размера. Сложение/вычитание всегда дают результат на один бит больше. То есть флаг переноса на самом деле не всегда является в полном смысле слова таким же признаком, как, например, признак нуля или знака. Это именно дополнительный значащий бит, поэтому в данной ситуации для компилятора важно это понимать. По поводу ADC RAX, 0, - конечно, выглядит это не очень красиво, но серьёзных неприятностей я в этом не вижу, тем более, что константы зачастую кодируются меньшим количеством бит, чем требует операнд. Ещё один момент заключается в том, что старший бит вряд ли часто потребуется извлекать отдельно. Чаще всего он будет использоваться именно в цепочках операций. Так что ничего неприятного/неэффективного в данной особенности я не вижу.


Я всегда выступал с резкой критикой функциональных языков.


Я бы сказал так:
1. Функциональщина вообще не даёт (и не может дать) никакого прироста в скорости работы программы. Ухудшить - легко.
2. Невозможно сделать аппаратную архитектуру, заточенную под ФП.
Так что об ФП в плане панацеи (или даже толчка) эффективности можно забыть.


Полностью согласен.


Компилятор с (объектно-ориентированного) языка (с автоматическим сбором мусора) COOL в архитектуру MIPS пишется одним человеком за 2-3 месяца. Проверено практикой.
Компилятор с языка С++ стандарта 2011 со всем toolchain пишется одним человеком в свободное от работы время за два года.
Собс-но, я не к тому, что это пара пустяков, но не стоит преувеличивать сложность создания рабочего компилятора даже по самым продвинутым стандартам. Основная сложность заключается в разработке оптимизации. Это - да, может отнять много человеко-лет.


Да, мне тоже сложно себе представить набор программ в таком виде. По крайней мере, про текстовые редакторы придётся забыть.


Сначала кажется, что использование UTF-8 облегчает эту задачу. Однако, если покопать, открывается куча подводных камней. ОС Windows заточена под использование кодировки Win-1251, поэтому переносимость сразу теряется. А разновидности виндовс - это подавляющий процент рынка, забить на него нельзя. Далее, символы в юникоде разные, есть, например, пробел, разные тире. Как отличать, что относится к идентификаторам? Современные стандарты С/С++ разрешают использование символов UTF-8 в именах идентификаторов, однако при этом используется куча дополнительных регламентирующих таблиц. Поскольку юникод активно развивается, эти таблицы наверняка будут меняться, а значит надо менять компилятор только из-за смены смысла какого-то символа. В результате пока что все современные компиляторы, поддерживающие юникод, на таблицы забили и я полагаю, у разработчиков при упоминании совместимости со стандартом в данной части начинается сильная мигрень.
В общем, это тот самый случай, когда за 30-40 лет накопился ком проблем, который пока не очень понятно, с какого конца раскручивать. Лично я пока что для себя решил так: национальные символы запрещены. Собс-но, это не означает, что они запрещены навсегда. Разрешить их использование потом - не проблема. А вот менять что-то в уже использующихся кодах - может превратиться в очередную головную боль и до ужаса кривые стандарты. Лучше перетерпеть лет 10 и не гнаться за прогрессом вместе с толпой, эта толпа может завести не туда.


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


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

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

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


Многие "функциональные приблуды" не имеют прямого отношения к идее ФП и могут быть реализованы в рамках императивного программирования (что и демонстрируют лямбды в С++).


Вот именно, выход один - создание нового, несовместимого с С/С++ языка.


Не существует языка, на котором нельзя написать дикое. Да и вряд ли сильно ограничивающий язык будет хорошим - он будет "бить по рукам" программиста на каждом операторе, в результате даже простые действия выльются в "многабукав". Всё же нужен определённый компромисс между жёсткостью и свободой.
Основная беда С/С++ заключается не в стимулировании написания дикости (хотя да, это есть, но лишь отчасти), а в многочисленных внутренних смысловых конфликтах, которые я бы охарактеризовал как непродуманность буквально во всём. Смешение целочисленных и булевого типа (и даже смешение целочисленного типа и указателей применительно к константе "0"), изначальное отсутствие стандартизации на размеры типов, смешение в одном операторе пре- и пост-инкрементов, принадлежность последнего else одному из предыдущих if, смысловая путаница в символах операторов вплоть до того, что нельзя нормально поделить на разыменование указателя, т.к. это будет начало комментария.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>