Всё очень относительно… сейчас плата, умещающаяся на ладони, может быть в разы мощнее персонального компьютера 10-летней давности.
Тут скорее надо определиться с восприятием, что такое эмбед? Это ограниченные ресурсы или ограниченный размер… Если второе, то ресурсов хватит практически на любой современный ЯП.
Вот интересно, кстати, почему? Очевидно, что сейчас в мире уже гораздо больше embedded систем, чем программистов, способных написать для них безопасный код на C.
По факту хвостовая рекурсия раскрывается в тот же ассемблерный код, что и обычный цикл.
А в комментарии, видимо, имеется в виду проблема, когда стек заканчивается. Рекурсия, использующая стек, обычно применяется в императивных языках, т.к. там может не быть tail-call optimization. Ну либо в крайне редком подмножестве алгоритмов, где без древовидной рекурсии вообще никак не обойтись.
Индекс TIOBE строится на основе количества запросов к поисковикам. Т.е., строго говоря, он не имеет корреляции с распространённостью языка или с количеством кода на нём написанном.
Какая связь между DDD и применением разных ЯП в одном проекте?
Насколько я понимаю, если кусочек проекта может быть скомпилирован или задеплоен независимо от основного проекта, то это уже микросервис.
как по мне, так C# берет часть фишек из функциональных языков, и зачастую это делает код более читаемым и менее многословным. Но везде нужно знать меру, конечно
Недавно обсуждали в комментах, что C# давно уже движется в сторону забытого нынче Nemerle… высока вероятность, что где-нибудь через 3-4 версии у них будет паритет по фичам и примерно одинаковый синтаксис.
Так я не вижу здесь противоречия. Если автор Nim считал бы С идеальным ЯП, то он не стал бы делать свой язык. Получается, что ему нравятся компиляторы C, но не нравится C как язык.
Хайп сбило решение не включать его в Rails по умолчанию. Впрочем, CoffeeScript в любом случае сыграл весомую роль в популяризации идеи транспиляции в JS. Сейчас уже этих транспилеров столько, что всех и не упомнишь…
Ну, я не очень в теме как выстроен процесс разработки Go. Но со стороны это выглядит примерно так: "Мы тут накосячили с архитектурой языка так, что даже сами не можем придумать решение, но у нас Open Source, так что давайте теперь как-нибудь силами сообщества вопрос порешайте, а мы рассмотрим ваши предложения, может быть.."
Один из признаков того, что язык программирования имеет успех, – появление новых языков на его основе. Известным примером является JavaScript.
Имхо, появление транспилеров — это признак того, что на исходном языке писать жутко неудобно/неприятно/etc., но какие-то другие факторы принуждают к этому. И JavaScript — яркий тому пример.
Своеобразный лайфхак — писать на приятном языке, а генерацию кода на неприятном языке поручить транспилеру. Разве есть другие причины писать транспилер?
А можно остывающие данные автоматически по каким-то критериям скидывать в vinyl?
И что в принципе посоветуете почитать на тему совместного использования memtx и vinyl?
К тому же к Nemerle будет сложно в разумные сроки прикрутить поддержу IDE
Интеграция с VisualStudio у Nemerle вполне приличная ещё со времён VS 2008. Так что проблема явно не в этом.
Вообще .NET CLR — весьма авторитарная среда, по сравнению с тем же JVM. Я не знаю ни одного языка, который бы взлетел для неё кроме тех, чью разработку активно курирует Microsoft. Даже из тех разработок, которые они поддерживали, типа IronPython, IronRuby и прочие Iron*, ни одна не взлетела.
Насколько я понял, вопрос был не про то, что на выходе, а про детали процесса компиляции… остаётся ли делегирование самостоятельной сущностью после синтаксического анализа или преобразуется в эквивалент набора методов на уровне AST?
Правда, непонятно, какая разница в плане практического применения? По таким критериям языки можно делить если только из теоретического интереса, тем более что реализация компилятора может меняться от версии к версии.
Всё очень относительно… сейчас плата, умещающаяся на ладони, может быть в разы мощнее персонального компьютера 10-летней давности.
Тут скорее надо определиться с восприятием, что такое эмбед? Это ограниченные ресурсы или ограниченный размер… Если второе, то ресурсов хватит практически на любой современный ЯП.
Вот интересно, кстати, почему? Очевидно, что сейчас в мире уже гораздо больше embedded систем, чем программистов, способных написать для них безопасный код на C.
По факту хвостовая рекурсия раскрывается в тот же ассемблерный код, что и обычный цикл.
А в комментарии, видимо, имеется в виду проблема, когда стек заканчивается. Рекурсия, использующая стек, обычно применяется в императивных языках, т.к. там может не быть tail-call optimization. Ну либо в крайне редком подмножестве алгоритмов, где без древовидной рекурсии вообще никак не обойтись.
В этом плане да, согласен.
Спасибо, кэп.
В комментарии, на который Вы в начале ветки ответили, обратного и не утверждалось )))
Индекс TIOBE строится на основе количества запросов к поисковикам. Т.е., строго говоря, он не имеет корреляции с распространённостью языка или с количеством кода на нём написанном.
Для научных расчётов я бы ещё обратил внимание на Julia, IDE для неё тоже есть весьма приличная.
Справедливости ради, база данных далеко не всегда является узким местом.
Какая связь между DDD и применением разных ЯП в одном проекте?
Насколько я понимаю, если кусочек проекта может быть скомпилирован или задеплоен независимо от основного проекта, то это уже микросервис.
Недавно обсуждали в комментах, что C# давно уже движется в сторону забытого нынче Nemerle… высока вероятность, что где-нибудь через 3-4 версии у них будет паритет по фичам и примерно одинаковый синтаксис.
Так я не вижу здесь противоречия. Если автор Nim считал бы С идеальным ЯП, то он не стал бы делать свой язык. Получается, что ему нравятся компиляторы C, но не нравится C как язык.
Хайп сбило решение не включать его в Rails по умолчанию. Впрочем, CoffeeScript в любом случае сыграл весомую роль в популяризации идеи транспиляции в JS. Сейчас уже этих транспилеров столько, что всех и не упомнишь…
CoffeeScript, точнее большинство его фич, уже в ES6.
Ну, я не очень в теме как выстроен процесс разработки Go. Но со стороны это выглядит примерно так: "Мы тут накосячили с архитектурой языка так, что даже сами не можем придумать решение, но у нас Open Source, так что давайте теперь как-нибудь силами сообщества вопрос порешайте, а мы рассмотрим ваши предложения, может быть.."
Имхо, появление транспилеров — это признак того, что на исходном языке писать жутко неудобно/неприятно/etc., но какие-то другие факторы принуждают к этому. И JavaScript — яркий тому пример.
Своеобразный лайфхак — писать на приятном языке, а генерацию кода на неприятном языке поручить транспилеру. Разве есть другие причины писать транспилер?
Хм, интересная позиция… Разве команда разработчиков не в состоянии разработать решение, которое её же и устроит?
А можно остывающие данные автоматически по каким-то критериям скидывать в vinyl?
И что в принципе посоветуете почитать на тему совместного использования memtx и vinyl?
Его 3 раза об этом спрашивали, но он так толком и не ответил… Видимо, в их кейсе не учитывается остывание данных.
Интеграция с VisualStudio у Nemerle вполне приличная ещё со времён VS 2008. Так что проблема явно не в этом.
Вообще .NET CLR — весьма авторитарная среда, по сравнению с тем же JVM. Я не знаю ни одного языка, который бы взлетел для неё кроме тех, чью разработку активно курирует Microsoft. Даже из тех разработок, которые они поддерживали, типа IronPython, IronRuby и прочие Iron*, ни одна не взлетела.
Насколько я понял, вопрос был не про то, что на выходе, а про детали процесса компиляции… остаётся ли делегирование самостоятельной сущностью после синтаксического анализа или преобразуется в эквивалент набора методов на уровне AST?
Правда, непонятно, какая разница в плане практического применения? По таким критериям языки можно делить если только из теоретического интереса, тем более что реализация компилятора может меняться от версии к версии.