Комментарии 73
Однозначно в «мемориз». Хотя и непривычно после С/С++, но обязательно посмотрю, что вырастет из этого языка.
P.S. Если уже и ключевые слова сделали более короткими, то почему mutable оставили как есть? Мне одному это режет глаза?
P.S. Если уже и ключевые слова сделали более короткими, то почему mutable оставили как есть? Мне одному это режет глаза?
Действительно, смотрится несколько громоздко. Мне пришли в голову сразу три причины:
1) не смогли придумать достаточно внятное сокращение. Вообще, кое-что показалось заимствованным из венгерской нотации, вероятно поэтому fn, u, i очевидны и прозрачны для многих. Аналогов же предмету обсуждения в ней нет, насколько мне известно. Кстати, я сам не смог подобрать кандидата на замену mutable.
2) оставили как меру против «злоупотребления» изменяемыми переменными, чтобы сделать их более заметными в коде.
3) просто руки не дошли.
1) не смогли придумать достаточно внятное сокращение. Вообще, кое-что показалось заимствованным из венгерской нотации, вероятно поэтому fn, u, i очевидны и прозрачны для многих. Аналогов же предмету обсуждения в ней нет, насколько мне известно. Кстати, я сам не смог подобрать кандидата на замену mutable.
2) оставили как меру против «злоупотребления» изменяемыми переменными, чтобы сделать их более заметными в коде.
3) просто руки не дошли.
кроме mutable ещё lambda. Очевидно же: mut и la.
Что-то тут не так. В первом же примере переменные
по умолчанию все переменные неизменяемые; для объявления изменяемых переменных используется ключевое слово mutable.
Что-то тут не так. В первом же примере переменные
return и i изменяются, хотя обе не mutable.
Ну что, прошло 6 (уже почти 7) лет. Как вы оцениваете то, что выросло?
Во многом похож на OCaml.
Как то не логично обьявлять переменную, а потом её тип. Привыкли что наоборот.
Тоже самое в функциях, привыкли вначале писал что функция возвращает, а уже потом функцию, тут наоборот.
А где классы? или я что то пропустил? Планируется ли какая UI библиотека?
Тоже самое в функциях, привыкли вначале писал что функция возвращает, а уже потом функцию, тут наоборот.
А где классы? или я что то пропустил? Планируется ли какая UI библиотека?
Да, непривычно. В наши мозги вбито: «Паскаль плохой, Си хороший». Нет, надо брать хорошие вещи из разных языков, и из всего этого сделать автомат Калашникова, надёжный, неубиенный и быстрый. Ведь и Михаил Тимофеевич не изобретал ни автоспуска, ни поворотного затвора…
И — фтопку ночные сборки: они должны существовать только чтобы проверить, что наваяли проггеры за день. Ну и для межпроцедурных оптимизаций. А перекомпиляция с «обычным» уровнем оптимизаций должна длиться не более минуты. Причин медленной компиляции Си до хрена, наобум припомню синтаксис LR(1) и хедеры.
И — фтопку ночные сборки: они должны существовать только чтобы проверить, что наваяли проггеры за день. Ну и для межпроцедурных оптимизаций. А перекомпиляция с «обычным» уровнем оптимизаций должна длиться не более минуты. Причин медленной компиляции Си до хрена, наобум припомню синтаксис LR(1) и хедеры.
Да просто это как то не логично, Ещё если они перенимали си подобный синтаскис зачем нагромоздили этим? std::io::println
неужели точки уже не в моде? std.io.println() куда удобней и привычней.
неужели точки уже не в моде? std.io.println() куда удобней и привычней.
C как раз по моему компилится быстрее чем С++, из-за ацких шаблонов в С++?
По-моему, и шаблоны можно ускорить, если продумать две вещи. 1) Как закэшировать результаты расшаблонивания (хорошо, но недостаточно сделано в C++11 с его
extern template). Всё это сделать легко, если отойти от хедеров, и сложно, если за них держаться. 2) Как хотя бы часть работы по расшаблониванию выполнять один раз при синтаксическом анализе модуля — а не каждый раз, когда потребовалось его расшаблонить.
Шаблоны в D ускорили за счет адекватного синтаксиса: заменили угловые скобки круглыми. Откуда не нужно тонн анализа, что это такое: сравнение, побитовый сдвиг или шаблонные скобки. Откуда быстрее компиляция.
Это, кстати, тоже важно. Забыл — а ведь именно в этом месте синтаксис C++ контекстно-зависимый.
Полезное замечание, спасибо. Я помнил, что грамматика С++ не везде контекстно-свободная, но не помнил в каких местах :)
А кстати, только ли в этом месте? Разве разный смысл даже круглых скобок — не контекстная зависимость, или я где-то не прав?
Синтаксис C++ контекстно-свободный. Если не согласны — приведите ссылку на авторитетный источник или продукцию грамматики языка, где присутствует контекстная зависимость.
Позвольте ответить на ваш комментарий, хоть он адресован и не мне.
В зависимости от того, что такое F эта конструкция может означать как объявление функции, так и определение переменной.
D E(F);В зависимости от того, что такое F эта конструкция может означать как объявление функции, так и определение переменной.
Разумеется может. В зависимости от того, в каком месте стоят скобки они могут означать вызов функции по аргументам, вызов конструктора или функтора, группировку, а в других языках — формирование кортежа, S-выражения, функции или чего угодно еще. Позвольте заметить, вы привели только тело продукции грамматики. Полностью она выглядела бы так:
N -> D E(F)
Это обычное правило обычной КС-грамматики. А как обработать активацию данной продукции, вывод нетерминала N — дело семантического анализатора (об этом упоминалось выше). Это не делает язык контекстно-зависимым. Все языки программирования (исключений мне не известно) являются контекстно-свободными, включая C++.
N -> D E(F)
Это обычное правило обычной КС-грамматики. А как обработать активацию данной продукции, вывод нетерминала N — дело семантического анализатора (об этом упоминалось выше). Это не делает язык контекстно-зависимым. Все языки программирования (исключений мне не известно) являются контекстно-свободными, включая C++.
Есть классы. Только упомянуты вскользь.
Напоминает попытку напихать фич Haskell в C++. Есть хорошие идеи, но в целом ничего особенного. Как-то аздражает ключевое слово «fn». Почему бы раз уж let ввели для переменных для функций не сделать его же? Странно.
Мне трудно понять по столь куцему описанию, почему они так решили. Но-по-моему, причины три. 1) Хотели быть поближе к LL(1). 2) Хотели не сразу заворачивать мозги «ездового пса» в функциональный стиль, а потихоньку: «А вот эту задачу можно решить ещё и так, в функциональном стиле!» 3) Хотели захватить всё целиком: и низкоуровневые дебри, в которых неплохо работал Паскаль и отлично — Си, и прикладные программы.
А мне кажется все было не так.
Как я вижу, сели прогеры в кружочек, взяли C++ и начали думать — что ж в крестах не так, и придумывать, как сделать так.
Убогий это подход. Язык надо делать с нуля а не допиливать существующие.
Может, я слишком резкий, но мне не нравится. Слишком похоже на «свой цпп с блэкджеком и сопутствующими».
Как я вижу, сели прогеры в кружочек, взяли C++ и начали думать — что ж в крестах не так, и придумывать, как сделать так.
Убогий это подход. Язык надо делать с нуля а не допиливать существующие.
Может, я слишком резкий, но мне не нравится. Слишком похоже на «свой цпп с блэкджеком и сопутствующими».
Нехорошо выразился, допиливать, конечно, надо, но не чужой язык. А новый надо делать с нуля.
Java? C#? Это, видимо, тоже попытки сделать C++ со шлюхами. Причём куда более консервативные.
По-моему, идеальный язык программирования должен быть пригоден как в роли учебного языка (пока Паскаль в этой роли непревзойдённый), так и для профессионального программирования. Ну и достаточно близким к существующим языкам профессионального программирования, из которых «короли» — естественно, PHP, C++, C#.
По-моему, идеальный язык программирования должен быть пригоден как в роли учебного языка (пока Паскаль в этой роли непревзойдённый), так и для профессионального программирования. Ну и достаточно близким к существующим языкам профессионального программирования, из которых «короли» — естественно, PHP, C++, C#.
Круто. Подумывал про собственный язык программирования, но явно мозгов не хватало, чтобы сделать как надо. Эти товарищи сделали всё, что я хотел, и даже лучше. Будем ждать.
Неужели из порядка 8000 языков программирования Вам не подошел ни один? )
Зачем ждать?! Примите участие! :)
github.com/graydon/rust
Это
1) бесценный опыт
2) фан
3) кусочек славы
=)
github.com/graydon/rust
Это
1) бесценный опыт
2) фан
3) кусочек славы
=)
По-моему очень похож на Go. И учитывая что Go все еще на раннем этапе развития, в будущее этого языка еще меньше верится. Ну и сложность языка на первый взгляд выше, чем у того же C. Хотя, разработчикам, конечно, удачи пожелать хочется.
Ну не знаю на сколько он похож на Go. У этих языков много общего, но у Go — очень простой синтаксис, никаких наворотов. Я бы сказал что Go — subset от Rust. В Rust такое чувство что засунули все, что нашли в других языках «интересненького», от D у меня такое же впечатление осталось.
Еще мне очень понравилась идея «все сокращать»: function -> fn, float64 -> f64, но она как-то не доведена до конца…
Еще мне очень понравилась идея «все сокращать»: function -> fn, float64 -> f64, но она как-то не доведена до конца…
Библиотеки что-то типа java (namespace is divided into modules: use std;). Но непонятно, можно ли дополнять namespace как cpp и функционал namespace из своего, не подключая его через use. И не нашёл в доке чего-то похожего на классы. Странный язык, непонятно «зачем он?».
Как я понимаю там нет сборки мусора? Интересная ниша для окучивания — тот же Go из-за присутствия GC на совсем низкий уровень не покатит.
Любопытно, что потихоньку поднимается волна «Сделать свой православный С++, только лучше». Вон уже как минимум 3 языка делаются для замены С++. Значит, он уже порядком надоел, и, кто знает, может его эра близка к упадку и закату.
А как его установить, и протестировать примеры?
Блин… ссылка сьелась…
github.com/graydon/rust/wiki/Getting-started
github.com/graydon/rust/wiki/Getting-started
> во многих случаях блоки кода могут рассматриваться как выражения.
Убивать. Или всегда выражения или никогда.
И такие же косяки в большинстве других решений. В общем, решили ввести в C++ блэкджек и шлюх, но здание возвели, а игроков и девиц завозить побоялись.
Убивать. Или всегда выражения или никогда.
И такие же косяки в большинстве других решений. В общем, решили ввести в C++ блэкджек и шлюх, но здание возвели, а игроков и девиц завозить побоялись.
Заразная болезнь Микрософта «фатальный недостаток — not invented here» переросла в пандемию.
Сначала Гугль, теперь вот Моцилла. Сколько можно изобретать велосипеды?
Неужели нельзя взять готовый язык, доработать, довести его до ума, без того, чтобы переписывать гигабайты готового кода?
Сначала Гугль, теперь вот Моцилла. Сколько можно изобретать велосипеды?
Неужели нельзя взять готовый язык, доработать, довести его до ума, без того, чтобы переписывать гигабайты готового кода?
А какой конкретно надо взять язык? И как можно так глубоко доработать, чтобы не потерять совместимость?
Чтобы не переписывать тонну кода, вполне достаточно бинарной совместимости.
Чтобы не переписывать тонну кода, вполне достаточно бинарной совместимости.
Как раз таки бинарная совместимость и тащит за собой кучу патентов и прочие проблемы.
А вот чистый синтаксис + дополнительные языковые примочки могли бы решить многие головные боли разработчика.
Взять хотя бы тот же Nemerle — вот что мешало делать навороты на базе C#? Людям надо было бы учить только дополнительные плюшки и использовать их в работе. Нет, кому-то надо было погладить своё эго, придумать очередной велосипед с квадратными колесами там, где уже и так всё отлично продумано и работает.
Мы наш мы новый мир построим — все знают чем это закончилось.
А вот чистый синтаксис + дополнительные языковые примочки могли бы решить многие головные боли разработчика.
Взять хотя бы тот же Nemerle — вот что мешало делать навороты на базе C#? Людям надо было бы учить только дополнительные плюшки и использовать их в работе. Нет, кому-то надо было погладить своё эго, придумать очередной велосипед с квадратными колесами там, где уже и так всё отлично продумано и работает.
Мы наш мы новый мир построим — все знают чем это закончилось.
А поясните, пожалуйста, каким образом бинарная совместимость тянет за собой патентные проблемы? Что-то в толк не возьму. Но согласен с jakobz: делать самостоятельный язык на базе другого нельзя. Это получится не самостоятельный язык, а язык + примочки. Кроме того, у всех языков разная философия, и ее уже не изменить.
Ну возьмем к примеру байткод на Гудроидах — Оракл сразу зубами вцепился…
А по второму вопросу — что мешает взять за базовый синтактис ту же яву или сишарп? Почему каждому начинающему велосипедисту хочется выдумывать свои аналоги var? Зачем курочить устоявшиуюся декларацию функций и порядок типов?
Чем
fn lt_42(x: int) -> bool
лучше чем
bool lt_42(int x)
?
Столько лишних закорючек — ни за что не поверю, что они вообще о удобстве для программиста задумывались.
А по второму вопросу — что мешает взять за базовый синтактис ту же яву или сишарп? Почему каждому начинающему велосипедисту хочется выдумывать свои аналоги var? Зачем курочить устоявшиуюся декларацию функций и порядок типов?
Чем
fn lt_42(x: int) -> bool
лучше чем
bool lt_42(int x)
?
Столько лишних закорючек — ни за что не поверю, что они вообще о удобстве для программиста задумывались.
Байткод — это не бинарник и к бинарной совместимости имеет весьма отдаленное отношение. Сам по себе он уже является технологией, форматом предварительно скомпилированного кода, если хотите. И байткод для Java принадлежит одной конкретной компании. С другой стороны формат исполняемого файла для любой ОС — тоже кому-то принадлежит (Microsoft, сообщество Linux), но пока MS никого не гнобит за его использование (даешь программ под Windows, — и чем больше, тем лучше). А вот за синтаксис тех же C# и Java в каком-то другом языке корпорация-владелец вполе может и покусать.
«Не бинарник» — имею в виду не исполняемый нативно бинарник. Потому что файл все-таки бинарный, а не какой-нибудь там текстовый.
По синтаксису: стрелка перед bool в вашем примере имеет под собой некое теоретическое обоснование. Дело в том, что в нескольких ML-подобных языках (Haskell, OCaml, F#) стрелка разделяет типы в типизации выражения. Пример:
max :: Int -> Int -> Int — Определение типа функции max
В математике есть понятие отношений, где также используется стрелка: R -> R (если я правильно помню матчасть).
По синтаксису: стрелка перед bool в вашем примере имеет под собой некое теоретическое обоснование. Дело в том, что в нескольких ML-подобных языках (Haskell, OCaml, F#) стрелка разделяет типы в типизации выражения. Пример:
max :: Int -> Int -> Int — Определение типа функции max
В математике есть понятие отношений, где также используется стрелка: R -> R (если я правильно помню матчасть).
let — стандартное ключевое слово для биндингов в куче языков.
декларация типа a -> b -> c -> d тоже стандарт.
а вот bool lt_42(int x) читается как «применить функцию bool к переменной lt_42 и значению выражения „применить функцию int к переменной x“ », что несколько сбивает с толка.
декларация типа a -> b -> c -> d тоже стандарт.
а вот bool lt_42(int x) читается как «применить функцию bool к переменной lt_42 и значению выражения „применить функцию int к переменной x“ », что несколько сбивает с толка.
Какой, например, готовый язык?
Вот с равнение Rust с уже готовым D
versusit.ru/rust-vs-d
versusit.ru/rust-vs-d
О, а вот эта концепция мне нравится, в отличие от Go. Typestate — вообще великолепная задумка, надо подумать, как его можно реализовать библиотекой на D :)
НЛО прилетело и опубликовало эту надпись здесь
Необычный велосипед…
Я заметил косяк или чего-то не понимаю?
В характерных чертах отмечена необходимость mutable для изменения переменной. Но пример факториала или кошки-собаки этого не отражают.
В характерных чертах отмечена необходимость mutable для изменения переменной. Но пример факториала или кошки-собаки этого не отражают.
Блин, зачем обязательно навязывать эти фигурные скобки? Ну почему нельзя сделать возможность использовать выравнивание?
Название языка «Ржавчина» — это намек на то чем он станет?
Что-то заявленное стремление к краткости не особо выполняется.
Синтаксис хаскеля для тех же самых вещей куда компактнее.
Синтаксис хаскеля для тех же самых вещей куда компактнее.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Обзор языка программирования Rust