Язык программирования Алмаз , или коротко язык A

[prografix]

Сделал сайт для описания языка Almaz
Пока там только описание лексем.
Что касается языка D, то впечатление от него у меня такое же, как и после знакомства с Java и C# - это ухудшенный вариант С++. В каких-то деталях я могу согласится, что это лучше, чем было, но в целом считаю язык стал хуже. Понятно, что это дело субъективное. Главное, что мне не нравится - это то, что меняется сама идеалогия языка. Когда я читаю Строуструпа ( а я много чего у него читал ), то мне всё понятно и в большинстве случаев я с ним согласен. А тут его доводы игнорируются.

[Kutushut]

Цитата prografix @ 16.07.05, 09:19

описание лексем

Что-то туманное описание какое-то. Не проще было взять из стандарта С++ ?

Цитата prografix @ 16.07.05, 09:19

Главное, что мне не нравится - это то, что меняется сама идеалогия языка.

Идеология. ИМХО для человека, создающего свой язык, многовато ошибок в постах...

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

[amk]

Почитал язык D, не вижу существенной разницы с возможностями C++. Многие из новых особенностей легко реализуются библиотеками и классами. Везде ссылки на реализацию особенностей в библиотеках, а не самом языке (похоже автор забыл (или не понял), что основой идеологии C++ является по возможности как раз миниммальное ядро языка), кое-что планируется включить в обновлённый стандарт (в основном в библиотеки), кое-что не особо и нужно, исключённые особенности и так без нужды не используются. Некоторые новые улучшения, вроде static if, реализуются во многих компиляторах уже лет двадцать.

[prografix]

Для начала я собираюсь реализовать небольшое подмножество языка ( без указателей, массивов, структур и т.д.).
Вот некоторые отличия от С++:
1) Названия арифметических типов содержат к-во бит ( int8, uint16, float32, ...)
2) Только явное преобразование типов
3) В условных операторах используется только логический тип
4) Переменная во внутреннем блоке не может иметь имя, такое же как и во внешнем
5) Отсутствие восьмиричных констант ( типа 0654 )
На сайте добавлен раздел Описание транслятора с исходниками для Visual C++ 6.0

[Kutushut]

prografix
Пока все фичи укладываются в стандарт С++ с примененным стандартом кодирования
2 и 3 - дело хорошее. Но кто мешает это делать в рамках обычного языка? Разве что совесть программиста. С остальным в принципе то же самое. Насчет 5 - не понял, а чем они мешают?

[prografix]

Цитата Kutushut @ 25.07.05, 12:14

prografix
Пока все фичи укладываются в стандарт С++ с примененным стандартом кодирования
2 и 3 - дело хорошее. Но кто мешает это делать в рамках обычного языка? Разве что совесть программиста. С остальным в принципе то же самое.

В С++ можно написать так, а можно иначе, а здесь иначе не получится.

Цитата Kutushut @ 25.07.05, 12:14

Насчет 5 - не понял, а чем они мешают?

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

[Kutushut]

Цитата prografix @ 26.07.05, 09:13

В С++ можно написать так, а можно иначе, а здесь иначе не получится.

Хорошо, не эти так другие проблемы вылезут. Исключительно имхо - нельзя сделать язык, на котором любой кодер, знакомый с синтаксисом, будет писать без ошибок.
Ты лучше придумай то, что дейстительно _нельзя_ сделать средствами С++ (или это требует _очень_ больших затрат) - тогда язык действительно будет чем-то новым.

Цитата prografix @ 26.07.05, 09:13

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

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

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

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

[downGRADE]

prografix
ИМХО: Бесполезным делом занялся, убрать разнообразие из существующего языка, для упрощения транслятора/программирования, не есть креатив.
Нет вдохновляющей новизной идеи... в .NET'е исходники собираются в управляемый код, который оптимизируется под конкретное железо платформой... в ASP.NET'е исходник транслируется в библиотеку, из которой и собирается нужный процесс, по мере надобности.
Держи проблему: будешь обдумавать новый язык, учти необходимость run-time программирования... если концепция надёжности языка будет противоречить этой возможности, то свой язык пишешь самому себе.

[Flex Ferrum]

Цитата prografix @ 26.07.05, 09:13

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

"Ты суслика видешь? Нет? И я не вижу. А он есть." (с) чья-то подпись. prografix, поверь, в С++ есть проблемы по-серьезнее чем те, которые ты описал. Ну и, в общем, согласен с Kutushut'ом. Лучше, например, реши проблему удобного сокрытия деталей реализации классов (то, что обычно идет в private-секции). А то, чем занят ты сейчас - "не будем прогибаться под изменчевый мир, пусть лучше он прогнется под нас." (с) А. Макаревич.

Добавлено 27.07.05, 07:37

Цитата prografix @ 25.07.05, 12:03

1) Названия арифметических типов содержат к-во бит ( int8, uint16, float32, ...)

А если какой-то из типов не представим на целевой платформе? Что будешь делать? Тем более что размер типа int неслучайно равен машинному слову на целевой платформе, ибо операции с данными такого размера наиболее быстры. Судя по всему тебе никогда не приходилось оптимизировать программы по производительности, и ты слабо себе представляешь - как размер данных влияет на скорость вычислений.

Цитата prografix @ 25.07.05, 12:03

2) Только явное преобразование типов

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

// Где-то есть функция:
void foo(const std::string& str)
{
//...
}
//...
//...
// В другом месте ты можешь спокойно написать:
foo("Some string");
// потому что std::string поддерживат неявное преобразование из const char*.

Если все преобразования делать явными, то тебе придется писать:

foo(std::string("Some string"));

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

Цитата prografix @ 25.07.05, 12:03

3) В условных операторах используется только логический тип

Нахрена, позволь спросить?

Цитата prografix @ 25.07.05, 12:03

4) Переменная во внутреннем блоке не может иметь имя, такое же как и во внешнем

Уууу... Батенька, да вы не совсем хорошо понимаете правила использования имен в С++, а также их областей видимости.

Цитата prografix @ 25.07.05, 12:03

5) Отсутствие восьмиричных констант ( типа 0654 )

"Не нравиться - не ешь".

[prografix]

Я всё же считаю, что восьмеричные числа в языке не нужны, а вот двоичные пригодятся. Сейчас посмотрел - в D они тоже есть ( типа 0b11011011 )

[downGRADE]

Цитата prografix @ 27.07.05, 12:08

Я всё же считаю, что восьмеричные числа в языке не нужны, а вот двоичные пригодятся. Сейчас посмотрел - в D они тоже есть ( типа 0b11011011 )

Восьмеричные цифры достались от процессоров с сисемой команд PDP... там восем регистров адресовались тройками бит...

[Axis]

когда-то сам писал свой первый скриптовый язык(точнее первую версию), хотел сделать более удобный, делал интерпритатором, оказалось, что удобнее не делать строго заданные типы переменных, с другой стороны мне не нравится скорость работы. В итоге эту версию я развивать не стал, а стал делать компилятор, сейчас он существует в light версии (скорость на уровне c). За основу я взял c, c++ и некоторые свои решения, придумывать думаю не имеет смысла. Хочу сказать одно, что написать действительно язык программирования высокого уровня сможет программист с высоким знанием, при этом ему это не нужно, так как знаний хватает оптимизировать написание программы на с/c++, что написание своего языка программирования не рационально, исключение составляют скриптовые языки.

[Rikkie]

Мы вообще по другому прикалывались. Работаем с буржуинами. Перевели плюсы (т.е. C++) на русский с помощью макросов. Коды ессно макросами и оформили. Отсылаем буржуям исходники - у них в итоге всякие зюки вылазят. И самое главное, все компилится Они потом долго матюгались. Даже русские слова слышались Жертвы русского национализма...

[Artega]

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

[Ho Im]

Rikkie, можешь показать пример такого чуда? :)