OSDev

Нет, почему же? Это надо понимать скорей так: Zealint понимает, что он не будет самостоятельно заниматься разработкой языка (и тем более написанием компилятора), т.к. не обладает соответствующими навыками и необходимым временем, но из этого не следует, что никто другой не создаст новый язык. Я прав, Zealint?


Ну почему же? Инструмент очень легко меняется под давлением проблем, которые он вызывает. Но люди не любят заменять одни проблемы другими, поэтому смена С++ на вашу любимую Джаву - не вариант .

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

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


Ха-ха! Про старые терминалы я не подумал, хотя обычно не упускаю этот момент. Что же, надо было написать неправильный ответ, чтобы получить правильный.


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

Проблема, о которой я говорил, так это несовместимость объектных файлов, получаемых каким-то компилятором с тем, что даёт выдаёт ассемблер. Например, я потратил какое-то время на то, чтобы объединить VS и ассемблер. В результате, объединить студию удалось только с vsyasm. Не буду утверждать, что приложил все усилия, но сам факт наличия проблемы, разрешающейся неочевидным для рядового программиста образом, огорчает. Хотя мне лично тоже больше нравится отдельные функции целиком писать на ASM. В VS уже давно запретили Inline-assembler.


Я имею в виду, как Вы заставите компилятор применить adc в нужном месте? Допустим, мы определяем класс class int72 { int32 l, h; int8 hh; }; Мы не хотим плодить кучу функций умножения и сложения с разным размером операндов и результатом int72, поэтому решили написать один оператор, который на входе и на выходе имеет дело с int72 (т. е. компилятор не получит подсказки в виде разных размерностей операндов и результата). Как может выглядеть реализация такого оператора на Вашем языке, чтобы компилятор сообразил, что нужен adc? Я вижу лишь один подходящий вариант: определить в языке оператор, скажем #, который для базовых типов (int32, int64) гарантированно превращается в adc, при этом не вносит между серией add / adc никаких других команд, сбрасывающих флаг переноса. Например (псевдокод):


Компилятор, увидев это, гарантирует, что менять порядок не будет и разбавлять чем-нибудь тоже.
Как же тогда обозначить аналог SBB? : )


Да и мне они кажутся слишком неестественными. Зато там есть идеи, которые заслуживают внимания. Те же лямбды, и вообще определение функции как объекта. Бывает удобным в C++.

Ну, я это и имел в виду, оптимизирующий компилятор. Как-то неоптимизирующий и в голову мне не приходил.


Да, я думаю, что придётся. Ведь раньше были перфокарты и не совсем просто было представить, что можно сделать текстовый редактор. Теперь текстовый редактор для целей программирования не очень-то многими используется, хотя я на протяжении многих лет писал все программы на всех языках в обычном редакторе Far, а кто-то для тех же целей использует vim. Я в нём вообще всё писал, даже письма, книги, диссертацию и т. д. Но, должен сказать, что был бы нормальный редактор кода для того же TeX, я бы им пользовался. Сейчас многие редакторы уже выглядят пристойно для набора программ в привычном смысле и вот, кто-то уже и не мыслит, что можно написать код в обычном MS-блокноте. А в ряде учреждений не знают ничего кроме MS-Word, и когда делаешь работу в TeX, принося им PDF, они не знают, что с ним делать. Тенденция такова, что обычный текстовый редактор постепенно заменяется необычным, а затем и вовсе уйдёт в прошлое, как перфокарты.

Может показаться, что всё плохо, ведь программу нельзя отредактировать другим редактором:

Но давайте посмотрим на вещи иначе. Если нет компилятора, то нельзя скомпилировать программу. Так отчего же мы будем сокрушаться, что у нас нет визуального редактора, чтобы её написать? В моём представлении компилятор и среда программирования должны идти вместе, хотя никто не будет запрещать создавать другие визуальные редакторы, подобно тому, как для одного и того же языка существуют различные IDE. Не совсем понятно, почему следует держаться за редакторы обычного plain-текста так сильно. Только потому что большинству это кажется удобным в силу привычки? У большинства вообще редко привычки бывают разумными. Это сложно, но вполне возможно изменить любые привычки любого человека. Главное, чтобы идея оказалась на самом деле лучше, а для этого нужно очень хорошо её продумать. Есть вещи, которые нужно перестать тащить за собой как мусор. Обычные текстовые редакторы и текстовые графические режимы вполне могут оказаться таким мусором, как и древние кодировки. Это я весьма категорично высказался, я понимаю, но раз высказался, значит есть личные причины.

Не совсем ясно, почему теряется переносимость. Винвовс поддерживает utf-8. Кроме того, бывают случаи, когда общество вынуждает пересмотреть ошибки прошлого.


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


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

Вы имеете в виду, не гнаться за utf-8? Подождать другую кодировку? Или подождать, пока эта устоится?


Сейчас дети в два-три года пользуются телефоном лучше, чем я, опытный пользователь ПК : ) Не думаю, что они будут испытывать какие-то сложности с графическим редактором, а скорее будут криво смотреть на текстовой как на пережиток прошлого, о котором они даже ничего толком не знают. Так я смотрю на перфокарты, например, на БЭСМ-6 тоже так смотрю. Даже на своих преподавателей, которые всего-то лет на 5-10 меня старше я вынужден смотреть как на людей, безнадёжно отставших от методологии разработки высокопроизводительных программ, я очень рад, что мне удалось без большой крови работать в своём стиле, а не в их. Хотя «подраться» пришлось.


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

Clang - 6 лет писался до того как стал проходить все тесты на стандарт 11 года.
"Редкая профессия разработка компилятора" - год на запуск но тесты тоже смогли пройти только через 5-7 лет работы.
Если судить по истории GCC, то даже в нем новый фишки стандартов появляются через год-два.

Так что идеально правильный компилятор это вам не хухры мухры.
Но простой вариант даже с ООП написать не сложно можно в течение нескольких месяцев если под напрячься. Что касается оптимизации, то можно LLVM использовать. А можно и свой вариант сделать.

А можно взять готовое и начать переделывать.
По поводу книги дракона. Как по мне она устарела.
И есть огромное желание её переписать.
Почти не уделяется вопрос структурам, данных. Мало уделяется вопросам разбора выражений.
И другие вопросы тоже не сильно. А вот ненужной болтологии много.

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

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

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

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

Да, действительно, такая проблема есть. Я вижу выход в поддержке ассемблера тем же компилятором, т.е. один и тот же компилятор работает как с ЯВУ, так и с ассемблером. Либо по максимуму поддерживать форматы объектных файлов.


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

Использование дополнительных операторов типа # специально для переносов только запутает программиста и усложнит код.


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


Есть стандарт на язык программирования, поэтому я могу использовать любой компилятор, который худо-бедно ему соответствует. Например, я часто пишу программы, которые одинаково компилируются и работают в VS, GCC, CLang, а если без плюсов, то и TCC. Поэтому вопрос стоит рассматривать не как "если нет компилятора, то нельзя скомпилировать программу", а как "один компилятор можно заменить другим". Точно так же, обычный текст можно редактировать любым plain-text редактором. А визуальную среду имеет смысл рассматривать только в том случае, если будет существовать некий стандарт, в рамках которого я смогу выбирать разные продукты. Стандарт на визуальное программирование мне представить сложно, хотя я и не отрицаю его возможность.


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


Могут, но не сейчас, а только в отдалённом будущем.


Виндовс не поддерживает UTF-8. Оно поддерживает UTF-16, а это совсем не то же самое. Да, верно, ошибки прошлого, и виндовс со своей UCS, трансформировавшейся в UTF-16 и есть такая ошибка, но очень прочно застрявшая на рынке.


"Какие-то" - это и есть применение таблиц, ограничивающих использование разных символов. До жути кривое решение.


Вот именно, - это одна из типичных граблей при использовании национальных символов.


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


В данном случае я рассматриваю именно редактор VIM. Не проблема выучить что-то новое, но только при условии, что это "новое" имеет интуитивно понятный интерфейс. 20-30 лет тому назад ничего не было кроме редакторов EMACS и VIM и компилятора cc, поэтому можно было потратить месяц на освоение. Но сейчас продуктов - море, и новый продукт типа VIM просто не приживётся даже в среде детей возрастом два-три года , потому что есть гораздо более дружелюбные редакторы.

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

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

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

Плохо искали Всё что вам нужно лежит в C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\x86_amd64
ml64.exe - Ассемблер
cl.exe - Компилятор С++
link.exe - Сборщик

Конечно GCC C++ с его ассемблерными вставками будет лучше, нет издержек на внешние вызовы.
Я поэкспериментировал ещё с той программой Cycles.12.cpp, так в Linux с GCC 4.9.2 она выполняется всего за 2 секунды (Cycles.14b.cpp за 3сек).
Использовал дистрибутив http://cdimage.ubuntu.com/daily-live/current
Ещё меня порадовало то, что вычисления в виртуалке VmWare 10 идут с такой же скоростью, как на реальной аппаратуре.

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


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


Я смотрю на такие вещи иначе. Блокнот - это тот же визуализатор ноликов и единичек.

Честно говоря, не понял, как это должно работать. Потерялся 1 байт ещё. Как компилятор сообразит, что тут adc? – он сделает то, что тут написано, усложнив процедуру сложения.

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

В Вашем решении предлагается избавиться от национальных символов. Это не то же самое? Можно ли выделить в UTF-8 символы, которые уже точно будут стоять на своих местах?

Значит нужно придумать достаточно дружелюбный редактор (и стандарт). Не может же быть, чтобы plain-text остался в программировании навсегда.

Как вариант, который был предложен тов. эмбрион’ом, можно совместить текст и визуальное оформление, оставив выбор за пользователем.

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