eXod
Идея интересная. Но твой язык уж больно напоминает идею связать Алгол и Джава. Только я думаю, что идея в идеальном виде трудно осуществима. А если ее упростить, то рентабельность создания такой системы снижается.

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

офтопик.
Дурацкий вопрос сколько, какие кросс платформенных ОС вы знаете кроме, Unix и Win?

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

2 Pavia,
соглачен, что трудно и это один из основных минусов и, с другой стороны, один из плюсов - "толкает" вперёд.=)
Доступ конечно будет к чистому асму, а иначе как без него?=) По началу весь код будет транслироваться в асм(естественно кроме асм вставок=) ). и перед финальной компиляцие можно будет что-то подредактировать.
хотя асм вставки как-то не очень подходит... ибо весь язык задумывается как надстройка над асмом(хотя по сути все языки и так надстройка=) ). Хм... тяжело обьяснать человеческим языком многие вещи... попробую нарисовать блок-схему алгоритма работы компилятора.
Если тебе не жалко, то можешь поделиться опытом в разработке языка?
оффтоп.
хм... ну готов предположить, что ещё QNX, а так же некторые специфичные системы(в силу узкого применения мы о них просто не знаем).
По поводу библиотек. Может я до конца не понимаю... Но вроде примерно так и сделано в современных ОС. Хотя может я понимаю "библиотеки" немного не так. Тогда с радостью выслушаю твои мысли!
Мне конечно видится немного по другому решение этой проблемы... Но ведь в споре рождается истина!=))
Просто библиотеки придётся писать, а тут просто перекомпилировать. Думаю что большой разницы в скорости работы не будет(хотя может я и ошибаюсь), зато разница в скорости разработки и поддержке кода будет.

eXod

Ладно. Ландно. Подолью ещё маслица в костёрчик.

Вот пример того, про что я говорю.

Допустим мы пишем работу с диском.
Как бы её можно было бы представить?

Вот я бы например представил в виде такого скрипта.
Слева - находится адресация - цилидр, номер головки, сектор.

Запись данных выглядела бы так:

2:4:1::=<=::$data1;
2:4:2::=<=::$data2;
2:4:3::=<=::$data3;
2:4:4::=<=::$data4;
2:4:5::=<=::$data5;

Ну а добавив понятие цикла, это можно было бы отразить по иному.

кхм... спасибо за маслице!=))))
постораемся гореть ярко!=)))
Обшую идею вроде начинаю понимать... и мне она даже нравиЦа!
_______________
офф
скрипты - это хорошо, пока дело не доходит до интерпретируемого кода, где они в скорости проигрывают. так что скриптофилософия, но исполняемая!=)

eXod

Будем считать - что скрипт - это обрезанный ЯВУ.

В данном случае (примере выше) считалось, что скрипт - это особенные условия и правила, а циклы и так далее - это ЯВУ, который не связан с этим скриптом.

Скрипт интерпретируется НО компилятором :) В некотором смысле этого слова.

Вообщем я и так уже тут много наговорил лишнего..

2 Edmond, ну почему же лишнего?=) очень даже не лишнего!=)))
Ценные весчи, которые я обязательно использую при проектировании компилятора!

eXod
Отсутствие как такового синтаксиса - это очень хорошо, я тоже сейчас пишу язык и вижу это как одно из преимуществ.
Скорость иполнения сейчас, это не основное, как мне это не по душе! Современные процессоры слишком быстро набирают скорость и это было одной из причин из-за чего появились скрипты, интерпритаторы, ЯВУ, суперкомпиляторы и т.д. И поэтому это преимущество не особо большое по сравнению с временными затратами на создание описанного тобой, а они колосальны! Сколько библиотек, драйверов устройств и т.п..
Язык должен давать быструю разработку.
Компилируемые скрипты - это вещь, но слишком много библиотек нужно написать, чтобы они стали непосредственным преимуществом.

2 Avalonec, из современного оборудования ещё очень много не выжато, так что компилируемые языки ещё не отжыли своё!=)
Теперь немного слов о языке(URAN вот такое название в голову пришло=) ).
Немного про этап компляции. Ну собственно технология "свободный синтаксис"... есть два варианта реализации, за счёт конфиг файлов и за счёт нейронных сетей(НС). Почему мне больше нравица второй? собственно первый этап компиляции представляет собой исчисление предикатов. А именно с этим НС очень давно начали хорошо справлятся!=)Зачем тогда плодить конфиг файлы, если НС сама будет разбирать синтаксис. А с возможностями обобщения и предсказания(а так же функций памяти) у НС мы получаем мошный механихм компиляции! и приходим ко второй основной технологии - "Интеллектуальная Оптимизация". С этого места чуть по подробнее...
Первый этап. Специально обученная НС делает первый проход. собственно компилирует(исчисляет предикаты) в промежуточное представление.(кстати, оно известно только НС и для нас не несёт никакого смысла). На этом этапе возможны исправления большинства синтаксических и некоторых пренципиальных ошибок. Далее код, откомпилированный во внутреннее представление, передаётся второй НС, которая уже обучена производить жёсткую оптимизацию и выдавать всё в опкодах!=) На этом этапе производится принципиальная оптимизация.(ну например разворачивание некоторых циклов, замена call на jmp, там где это возможно и т.п.). Итак мы получили уже откомпилированный и оптимизырованный код. Третьий этап. низкоуровневая оптимизация. Выполняется генетическими алгоритмами.(они как раз для подобного рода задач и созданы(задач оптимизации)).
Плюсы такой схемы работы - исправление многих ошибок(начиная от пропущенной ";" и кончая ошибками в написании самих алгоритмов), мощная интеллектуальная оптимизация на всех уровнях. А при использовании скриптофилософии получаем просто незабываемую весч!=) Естественно НС многомодульны, чтоб их каждый раз не переобучать при введении новых инструкций в процессор. И для каждой платформы можно сделать отдельную НС которая и будет заниматься компиляцией(именно по этому там их и две работает - одна не привязана к платформе, а вторая как бы является драйвером). Ваше мнение, господа?

eXod
есть два варианта реализации, ...и за счёт нейронных сетей(НС)
хех, сильно ты загнул :)
любой, кто пытался научить нейросеть на более сложное, чем отличать белое от черного меня поймет :)
нейросети не ложатся на эту задачу чисто теоретически - они предназначены на поиск скрытых закономерностей (которых кстати может и не быть, но обученная нейросеть все равно выдаст чего-то в этом случае ;)).
строго формализованная грамматика языка к таковым не относится.

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

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

2 MAX, уже не первый год лазю в эту область и пока ничего... а какраз для формального языка, который очень схож с исчисление предикатов(по сути компиляция - это и есть исч. пред.) и НС с обратными связями во всю как раз для этого и пользуют!=)
А вот насчёт скорости компиляции я согласен не быстро... но ведь лучше один раз небыстро откомпилировать, чем потом много раз выполнять небыстрый код!=)
_________
так что я про НС заговорил не с дилетантской точки зрения... просто наверно уже больше полугода их вообще ни касался... а тут вот и применение очередное им нашёл.

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

„[/quote]
eXod
[quote]А именно с этим НС очень давно начали хорошо справлятся!=)“

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

Разбор синтаксиса - это не столь СЛОЖНОЕ занятие, чтобы ПАРУЧАТь его НЕЙРОННЫМ СЕТЯМ!!!

Этап парсинга - это самый лёгкий этап.

А вот на оптимизацию НС - хочеться посмотреть :))
Не видел, не видел...

Третьий этап. низкоуровневая оптимизация. Выполняется генетическими алгоритмами.(они как раз для подобного рода задач и созданы(задач оптимизации)).

Боюсь вы очень плохо понимаете, что говорите.
:))
У вас ничего не выйдет. Генетические алгоритмы не способны взять в разработку современную схему CPU - они обладают СЛИШКОМ большим множеством случаев.

Ваш компилятор в лучшем случае скомпилирует программу через 200 млн лет :)

А в хужшем - никогда.

Тема X синтаксиса - относится не к сложнейшим, а просто к тем, для решения которых требуется НОВЫЙ ПОДХОД, который в современном программировании начисто отсутствует.

И НС - тут кажется слабым решением.

Ищите другое :)

2 Xandr, собственно я изначально предполагал, что программы будут распостранятся в исходниках!=) хотя многим это и не понравиться...(тогда подойдёт распостранение именно промежуточного кода, которые ещё не привязан к платформе, а размер там не намного больше будет(если вообще не меньше)).
2 Edmond, с синтаксисом я коннечно согласен, не обязательно поручать... но с другой стороны, пусть текст будет уже приведён ко внутреннему представлению, это упростит второй этап компиляции. да и потом она же может иправлять мелкие огрехи(типа пропушенных точек с запятой).
По поводу геналг. Именно по этому их и надо ограничить!=) вот тут я не говорил, что будет один обобщённый алгоритм, тут для каждой платформы своя модификация...=) текст программы(опкоды/асм) разбивается на блоки(!, а то действительо лет двести...) и эти блоки уже проходят оптимизацию...
собственно дальше наверно говорить особо не очем, пока не будет хоть каких-то результатов. Надо попробовать реализовать!=) хотя бы хоть что-то, а дальше уже на основе этого и разговаривать. Поэтому... попробую реализовать отдельные части, а там видно будет!=)

А не пора ли решить проблему "спора о синтаксисе" кардинально? Avalonec уже предложил здесь идею языка без синтаксиса (интересно, что под этим имелось ввиду; "язык должен давать быструю разработку" - это намек на RAD?) - и я с идеей убить синтаксис полностью согласен. В общем, идея такая: программы нужно не писать, а рисовать. CASE-средствами и может быть даже в многомерном пространстве (2-3 традиционных измерения+возможность уйти "вглубь" любого программного модуля). На халяву получим два бонуса: такой подход поощряет идеологически правильное высокоструктурированное и модульное программирование и, кроме того, можно превратить программирование в форму изобразительного искусства :-)

Нечто подобное уже есть, причём даже наше российское. Это конечно скорее продвинутый планировшик задач,но возможности у него... большие!=) ссылку не помню=(
Но всё же мне не очень нравица идея отказа от синтаксиса и полный переход на "графические" разработки. Ибо программирование сравнимо с написанием стихов/книг. И самые талантлевые программисты как раз с гуманитарным образованием!=) Да, как бы это странно не звучало, но так оно и есть=)