Comments 26
Будем ждать когда автор забросит этот язык и создаст новый, года через два.
Разъясняю на всякий случай: автор разработал первый язык cine, написал об этом на хабр пару лет назад. Было много комментов типа: а зачем еще N+1 язык? И через несколько месяцев забросил его c такими словами:
Подумав я понял, что бессмысленно продолжать это безумие. И решил писать новый язык с нуля. Прошу прощения за то, что отнял время у всех тех кто уже начал изучать язык. Через некоторое время я удалю этот блог и git аккаунт.
Привет! Я думал что я один такой сумасшедший. Я вот дольше тружусь. Больше 25 лет. Правда я и задачу себе поставил покруче. Создать новый процессор, под него систему и язык. Уж очень мне не нравится классическая архитектура. Прочитал внимательно обе статьи. Вопросов и замечаний и тем для пообщаться масса. Но, главный вопрос -" А есть ли смысл в оптимизации?". Неужто принципиально насколько быстрее/медленнее что-то выполнится? Если задача решается в приемлемое для пользователя время, то и бог с ним. Мне кажется важнее стоимость создания и сопровождение созданного программистом. А это время и сложность перехода от постановки задачи, до формулирования в терминах (языке) доступном для компьютера. Ну, и сопровождение. В смысле редактирования, отладка, изменение функционала при изменении ТЗ. И почти Булгаковское удовлетвори все хотелки заказчика в будущем. Вообщем, пиши. С удовольствием пообщаюсь. Достойный труд всегда уважаю.
Привет!
Привет!
Я думал что я один такой сумасшедший.
После первой статьи мне писало много людей и по всей видимости - нас не мало.
Я вот дольше тружусь. Больше 25 лет. Правда я и задачу себе поставил покруче. Создать новый процессор, под него систему и язык. Уж очень мне не нравится классическая архитектура.
Если всё делать не тяп-ляп, то мне кажется, что может не хватить жизни одного человека, что-бы всё это закончить.
" А есть ли смысл в оптимизации?". Неужто принципиально насколько быстрее/медленнее что-то выполнится? Если задача решается в приемлемое для пользователя время, то и бог с ним.
Так я об этом и написал в этой статье. Вот цитата из статьи:
Когда я начинал создавать языки, мне было 19 лет и в этом возрасте мне хотелось, что бы всё было "быстрее, выше, сильнее", хотя я давно вышел из этого возраста, почему то в процессе создания языков, я всё ещё ориентировался на то, что приложения должны иметь крайне высокую производительность. Сейчас же я считаю, что приложения должны иметь достаточную для решаемых задач производительность, а в языке должна быть возможность оптимизации кода, если его производительность оказалась недостаточной.
Оптимизации про которые я написал в статье, это всего лишь демонстрация того, что если производительность программы вышла за рамки приемлемого, то в языке присутствую средства, чтобы это исправить.
Если всё делать не тяп-ляп, то мне кажется, что может не хватить жизни одного человека, что-бы всё это закончить.
Так и не хватает. Хотя концептуально уже все есть. Но, на классической архитектуре работают миллиарды людей. И наработана куча методов и приемов. Хоть семи пядей во лбу все невозможно придумать.
а в языке должна быть возможность оптимизации кода, если его производительность оказалась недостаточной.
В классической архитектуре да. Я не особенно парюсь по этому поводу. Во-первых, я оставляю возможности для оптимизации самого процессора. Все предусмотреть не возможно. Пусть допиливают уже когда все стабильно заработает. Во-вторых, я больше надеюсь на распараллеливание. У меня можно в динамическом режиме добавлять сколько угодно процессоров, и, возможно, шин. А для того применения что я уже готов реально предложить вполне достаточно и существующих процессоров.
можно в динамическом режиме добавлять сколько угодно процессоров
Под Мультиклет подходит.
Под Мультиклет подходит.
Не знаком за подробности. Можно пообщаться.
Судя по Википедии тоже автоматика, космос. И для ИИ отлично подходит.
На Хабре много интересного про него писали, гляньте.
Посмотрел. Интересно. Но, влияние классической архитектуры сильное. Практически тоже самое. У меня совсем другой принцип. Начнем с того что 4 вида адресации. И память на в виде массива, а множество концептов (объектов) единой структуры. Можно представить как граф с вершинами концептами, и ветвями-переходами подписками (адресация). Напоминает нейро сеть. Ну, и так же выполняется. Можно рассматривать вершины как перцептроны, а ветви-адресации как синапсы со значениями –параметрами в качестве значений. Классическая архитектура провоцирует написание программ «в длину». Предлагаемая архитектура предполагает формировать иерархическую систему, и заставляет мыслить более структурно. Как показывает практика, к этому надо привыкать Т.е. и команды и данные имеют единый формат и выполнение начинается с адресации.
1.Работа машины заключается в адресации концепта, инициирующие процессы, реализующие его внутренний функционал, и формирующий адресацию к внешним концептам, если они оформили эту адресацию в виде подписки на событие интересующее внешний концепт. Т.е. Инициация взаимодействия в руках внешнего концепта, с применением механизма подписок. При этом сам концепт сохраняет свою структуру и свой собственный функционал (иммутабельность).
2.Взаимодействие с концептом облегчается единой структурой и полной информацией о себе. Т.е. концепт полностью содержит в себе имена, хелпы, типы атрибутов и свой состав. Потому легко визуализируется при необходимости организовать с ним взаимодействие.
3.Т.е. Организация протокола и управления универсальна. Концепт представляет собой прозрачный «черный» ящик, о котором можно получить полную информацию и организовать взаимодействие.
4.При такой структуре легко организуется иерархическая структура, где верхний уровень использует функционал концептов нижнего уровня, сам при этом генерируя внешнее представления являясь концептом.
Само по себе трудолюбие и настойчивость достойна уважения.
Вот только любое занятие ради самого занятия это высокотехнологическое самоудовлетворение (не подумайте ничего плохого, я тоже язык программирования разрабатываю :-) ). Просто мне кажется, что цель следует определять более четко. Не "еще один язык программирования из десяти тысяч уже существующих", а "самый быстрый", "самый понятный" и т.д.
Причем это нужно с первую очередь для себя самого, что бы понимать, а в правильном ли направлении ты движешься. Иначе может получиться, что будешь ходить кругами и переписывать годами, но к цели так и не придешь. Конечно, если целью является не сама дорога.
Согласен. Кстати, цель она ж и подсказывает. И выбор становится понятным. А то аргумент "мне так понравилось" не убедительно звучит. Для чего морока с типами? Ну, и многое другое. Не зная цели не понятно стоит добавлять фишку какую-то или она лишняя. Ну, и заценить выбор нельзя со стороны. Автор, оно, конечно, автор. А все-таки соотносить надо с целью.
Вот только любое занятие ради самого занятия это высокотехнологическое самоудовлетворение
Хорошо, что я таким не занимаюсь. Ведь цель, была обозначена в первой статье, а именно "меня не устраивали другие языки, я не смирился и начал создавать свой".
Т.е. вы верите, что удобный или идеальный для вас язык существует где-то в вашей личности, в вашем мозге? Надо лишь отсекать от гранита лишнее, и образ освободится из камня?
А если идеала нет — что будете делать? И сколько времени вы себе готовы дать? Неужели всю свою жизнь? Или постоянно ставите себе дедлайны и срываете сроки?
Какой процент из своих хотелок вы уже смогли удовлетворить за эти годы? Есть хотя бы половина, или ещё кучу идей проверить предстоит?
Т.е. вы верите, что удобный или идеальный для вас язык существует где-то в вашей личности, в вашем мозге? Надо лишь отсекать от гранита лишнее, и образ освободится из камня?
Нет. Я занимаюсь программированием вот уже 20 лет и за это время я перепробовал множество языков, парадигм и подходов в программировании и прекрасно знаю, что мне подходит, а что нет. Из всех языков которые мне нравятся, но к созданию которых я не имею отношения - Haskell. Программирование я использую для реализации своих идей, а Haskell очень не практичен для реализации многих из них и получается так, что Haskell как язык мне нравиться, но он всё равно мне не подходит. Поскольку из всех известных мне языков мне нравится только Haskell, но он мне не подходит, я начал создавать свой язык. Если рассматривать язык как комбинацию из различных идей, то мне от языка нужно было наличие некоторых идей, а вот остальные идеи в языки мне приходовалось подбирать. Когда я заканчивал с подбором идей, мне нужно было решать как их грамотно реализовать. Ничего общего с отсечением от гранита.
А если идеала нет — что будете делать?
Цитата из моей статьи:
Когда проектируешь язык программирования, всё время приходится идти на компромиссы
Я не знаю как вы представляете себе идеал, но в моём представлении, в идеале нет компромиссов. Я и не думал делать идеал.
И сколько времени вы себе готовы дать? Неужели всю свою жизнь?
Я закончил. Язык был готов уже в мае, месяц с небольшим я его использовал, чтобы убедиться, что этот язык мне подходит. Конечно есть ещё над чем работать, но в целом, это то, чего я хотел. Новый язык я уже точно делать не буду.
Какой процент из своих хотелок вы уже смогли удовлетворить за эти годы? Есть хотя бы половина, или ещё кучу идей проверить предстоит?
Больше половины есть, в процентном соотношении не могу сказать. Но я язык создавал в том числе и для того, чтобы реализовывать другие свои проекты, например у меня есть идея нового алгоритма сжатия изображений, я хочу создать модуль для Shar, который реализует этот алгоритм, но по хорошему, мне нужны некоторые фичи из следующей версии языка, а вот для реализации компилятора Shar, мне хватило уже существующих возможностей. Поэтому для работы, не обязательно наличие всех возможностей, которые я задумал.
Почему в ленте КДПВ показывается, а в самой статье — нет? Что за чудеса?
Сижу на старой версии Хабра.
За типы хочу сказать. Я тоже за сильную типизацию, но статическая типизация меня не устраивает. У меня динамические вызовы и проверка параметров должна выполняться на лету. Я подумал что добавлять пользовательские типы можно непосредственно в имена. Допустим если мы хотим, как в языке ADA, создать пользовательский тип яблоки и тип ящики то определить их, допустим как байт, а в имя добавить какую-то букву со знаком что б случайно не сложить ящики с яблоками. Или не перепутать параметры в функции! По моему красивая идея. Идентификаторы начинающиеся с $А это яблоки, а $B это ящики)) И, проверка на типы это одно, а участвовать в выражениях это хрена!
Поздравляю, вы изобрели Венгерскую нотацию
Соглашение об именах старо как само программирование. Я еще помню метки в ассемблерах м1, м2 и в VB6 там элементы управления должны иметь первые три буквы соглашения. Тут идея серьезней за расширение определения типа и влияние на формирование кода. Но, пока я писал я еще круче идею продумываю. В двух словах расширение типов, возможно, имеют свои отличия для взаимодействия с другими .. скажем так, понятиями. Может и их подвязать..
Сейчас же я считаю, что приложения должны иметь достаточную для решаемых задач производительность
Надеюсь, как можно скорее дойдёте до того, что важнее всего — читаемость кода, и что свой перфекционизм надо давить и это вполне возможно.
Начнёте даже получать извращённое удовольствие от того, что делаете что-то неидеально ради результата.
оптимизация честная
Даже SIMD не использовался?
Под вашим текстом Хабр предлагает вакансию Разработчик компилятора и интерпретатора
Хватайте её скорее… ну и давите в себе перфекционизм. Это — восьмой смертный грех.
Надеюсь, как можно скорее дойдёте до того, что важнее всего — читаемость кода
Надеюсь, как можно скорее дойдёте до того, что то "что важнее всего" является субъективным и что никакой объективной важности, к которой люди со временем приходят - нет.
Я лично считаю читаемость неотъемлемым атрибутом языка и даже забраковал один из своих языков по причине его плохой читаемости.
перфекционизм надо давить и это вполне возможно.
Я не являюсь перфекционистом и мой язык, как и любой другой - не совершенен.
Даже SIMD не использовался?
Используется, но я считаю SIMD честной оптимизацией, ведь расчёты производятся те-же, но несколько вычислений за раз.
Под вашим текстом Хабр предлагает вакансию Разработчик компилятора и интерпретатора
Во первых им нужен Senior, а значит и опыт в промышленной разработке, не говоря о том, что я создавал свои компиляторы без знания того, как это принято делать у других.
Ну так язык этот нужен чтобы законспектировать некоторую часть человеческой деятельности и потом повторять её нажатием одной кнопки. Вам хочется удобства в процессе описания этой деятельности, начните хотя бы с того чтобы использовать родной язык а не английский, и уберите всё лишнее, возможность определения бинарных операторов на уровне языка счастья не добавит, слишком запутано получиться, а вот вызов функций уже попроще, порядок выполнения виден, хоть и кажется иногда избыточным. Ну и ещё, иногда приятнее самому что-то делать в жизни, чем отдавать эту возможность другим, в том числе и машинам.
В комментах что к прошлой статье, что к этой много вопросов к пользе создания своего языка.
А с каких пор это требование? Кайфово человеку чем-то заниматься - классно! Пусть занимается. Никто же не предлагает вам начать на нём писать или, прости господи, внедрять его как ГосПрогЯзык.
Злые вы, господа :)
Почему я прекратил разработку своего старого языка программирования и создал новый