Справедливости ради, чтобы 1 неадекват не создавал негативное мнение о языке в целом, скажу, что Nemerle — весьма интересный язык с хорошим выводом типов, с полноценным pattern matching, макросами аля LISP и ещё кучей полезных фич. В общем по идеологии он гораздо ближе к функциональному программированию, но при этом синтаксис напоминает C#. Этакий гибрид C# и F# + нормальные макросы.
К сожалению, язык этот за 10 лет существования не взлетел, потому что
1) Пиар за пределами RSDN у него был практически на нуле
2) Для многих программистов хватило функциональных возможностей, которые встроили в C#. Ну а для тех, кому хотелось больше функциональщины под .NET, взлетел F#
Будет ли у Nemerle второй шанс? Зависит от JetBrains, именно на них работают основные мейнтейнеры языка.
P.S. На самом деле, даже странно почему популярность Nemerle настолько близка к нулю… Я ожидал, что ситуация получше. Но не видно ни одного активного OpenSource-проекта на этом языке, если не считать проектов того самого Влада.
То, что Вы об их существовании знаете, в этом ничего удивительного нет. А вот то, что Вы пропустили момент, когда о них говорили, как о перспективных (это было лет 8-10 назад) — это странно.
Язык устоялся буквально год-два назад.
Во, теперь понятно… привет из 2009 года.
быдлятник в байтах.
Это Вы видимо про себя. На вопросы по существу отвечать научитесь, потом понтоваться будете.
Ну, полный список я Вам вряд ли предоставлю. Но для примера в Ruby есть def_delegator для этого, некоторые используют delegate из ActiveSupport, хотя это уже ближе к кодогенерации.
Кстати, аналогичную кодогенерацию можно устроить в любом языке где есть compile-time макросы. Rust, Crystal, Nim, etc. к вашим услугам. В Crystal такое есть из коробки, про остальных точно не знаю. Но сделать аналог весьма просто.
В функциональных языках делегация тоже хорошо поддерживается, только там она осуществляется от модуля к модулю, например defdelegate в Elixir.
Вы из какого года к нам прибыли? Я про Nemerle в прошлый раз слышал лет 8 назад. Влад и компания, конечно, молодцы и тогда этот проект выглядел весьма интересно. Но, имхо, после выхода C# 3.0 и включения F# в дефолтную поставку VS 2008 интерес к Nemerle стал стремительно затухать.
Про D я уже выше спрашивал, какой фактор сможет обеспечить рост популярности 15-летнему языку?
Эти споры относились на 90% к разработке десктоп приложений, а не WEB.
Ахах, это да, на тему того, что ASP.NET — неюзабельная хрень, практически все были единодушно согласны. Но спустя годы сделали порт Rails, назвали ASP.NET MVC и ничего, стало можно и под веб на C# комфортно разработку вести. Так что это ещё и исторический пример того, как реальная хрень может быть замещена чем-то путным в рамках одной и той же платформы.
Использовать WPF для десктопных приложений сейчас решаются не многие.
А, кстати, почему? Боятся ограничить себя рамками Windows?
Я как-то давно отошёл от разработки десктопных приложений, поэтому не в курсе. Вообще Qt с .NET — это интересное сочетание, почему тогда не GTK или wxWidgets?
Конкуренты есть у всех. К тому же у массовости есть и обратная сторона: средний уровень сообщества падает от массового притока новичков в программировании. Что, по факту, имеет ряд негативных последствий для профессиональных программистов, начиная от необходимости учить/руководить чуть ли не чаще, чем программировать, и заканчивая замедлением темпов индексации зарплат.
Формулировка то расплывчатая. Но налоговая не расстроится, если вы будете 13%, а не 6% ей отчислять… Так что не волнуйтесь, в суд она на вас из-за этого подавать не будет )))
Вообще если это один заказ на продолжительное время, то физ.лицо тоже может вполне официально работать по договору подряда… Просто это невыгодно, потому что придётся 13% платить, а не 6%. Да ещё и в фонды из этих 13% никаких отчислений не будет.
А разве на PayPal сейчас не принудительная автоматическая конвертация в рубли? Реально лучше налог спокойно заплатить чем примерно такой же процент при конвертации потерять. Тем более, что 1 из 6% идёт напрямую в ПФР.
Язык — это тоже инструмент и ещё там смайлик был.
А вообще да, о количестве игр под мобилки я как-то не подумал, вот что значит наиграться в компьютерные игры ещё до появления смартфонов )))
В комментах выше считали кол-во репозиториев на Github, у Rust — чуть больше 5 тыс.
У Swift — порядка 38 тыс. У Objective-C — около 150 тыс. Так что Rust если и выбивается из списка, то пока не сильно. А Swift заслуженно записан во второй эшелон.
Понимаете, если программировать только на C#, то это всё может выглядеть круто. Но по факту это просто заимствование идей из других языков. C#, начиная с 3-й версии, начал путь в функциональщину. Это классно, но совсем не ново.
Ну, добавили сначала простенький вывод типов (var) и лямбды, потом открыли возможность тип привязывать к данным, а не к переменным, а переменные ребиндить (dynamic) и возможность асинхронно код вызывать (async/await), ах да, ещё интерполяцию строк )))
Я не говорю что в этом есть что-то плохое, наоборот, мне нравится C# и направление, в котором он развивается тоже. Просто, если по-честному, ничего такого грандиозного в этом развитии нет со времён появления LINQ. Язык стабилен и просто обрастает мелкими приятными плюшками. Всё здорово.
После шестой версии, например, C# 5 воспринимается многословным и неудобным.
Ахах, это Вы просто F# не пробовали, вот где лаконичность.
И какие тогда по вашему изменения тянут на изменение мажорной версии?
Настолько глобальные, что нарушают обратную совместимость.
Точнее сказать продавали комплектом. Бесплатно скачать компилятор и стандартную библиотеку(VCL) возможности не было, насколько я помню. Для того же C++ такая возможность была.
Я Scheme тоже отношу к LISP-семейству, как и все остальные диалекты.
Я немного знаком с CL и мне кажется очень похоже в плане макросов с Elixir. Да, в CL для гигиеничности нужно использовать gensym, а в Elixir для нарушения гигиеничности var!.. Т.е. в этом плане поведение по умолчанию отличается, но в остальном… те же quote(`), unquote(,), unquote_splicing(@,), те же манипуляции с AST при необходимости.
Со Scheme я не настолько знаком, чтобы всерьёз о нём рассуждать, но Racket, на мой взгляд, выглядит очень круто.
Что касается границ гибкости макросов Elixir, они пролегают по территории довольно редкой для практического применения, например, Вы не можете расширять синтаксис языка произвольным образом, т.к. разрешенный набор небуквенных символов ограничен. Если хотите принципиально кастомный синтаксис, то придётся оборачивать весь код, который будет его использовать, в один вызов макроса, внутри которого можно будет преобразовывать AST как угодно. Но это, в принципе, не велика проблема, т.к. для таких преобразований есть очень удобные средства типа Macro.prewalk/3.
А вот единственным принципиальным ограничением, в которое я однажды упёрся, было то, что в общем случае невозможно внутрь quote подставить кусочек сырого AST (кому интересно, могу в личку скинуть подробное описание этого случая). Это вытекает из двойственного представления кода, тогда как в LISP кроме AST другой записи кода нет. Но это реально очень экзотические случаи.
P.S. Вообще тема интересная, надо Rust и Racket поглубже копнуть )
С тем, что ErlangVM — не язык, и приписывать преимущества виртуальной машины тридцатилетнего возраста эликсиру — довольно странно.
Разумеется, преимущества BEAM — это не заслуга Elixir, но ведь он позволяет ими пользоваться. А таких языков не так уж и много, я осведомлён только об Erlang, Elixir и LFE. Вот и получается, что отличительными особенностями этих 3 языков являются преимущества BEAM :-)
Это из той же серии, что отличительные черты Kotlin — это преимущества JVM и возможность использовать Java-библиотеки. У Rust и Crystal — возможность легко подключать сишные либы. А у Elm — встраиваться в существующие JS-проекты.
И это понятно, никому сейчас не нужен язык-бука, который тупо проигнорит текущее состояние отрасли и будет делать абсолютно всё с нуля. Сложность заключается в выборе наиболее крутых достижений прошлого, их гармоничном комбинировании и дальнейшем развитии. Elixir в этом плане сделал ставку на возможности BEAM, интероперабельность с Erlang, макросы LISP и синтаксис Ruby. На мой взгляд, первые 2 пункта выполнены на отлично. Остальные 2 взяты за ориентир, но видимо не являлись самоцелью. Поэтому синтаксис только отдалённо похож на Ruby, а макросы местами не дотягивают до гибкости LISP, но при этом являются наиболее мощными из всех известных мне языков не из LISP-семейства.
Справедливости ради, чтобы 1 неадекват не создавал негативное мнение о языке в целом, скажу, что Nemerle — весьма интересный язык с хорошим выводом типов, с полноценным pattern matching, макросами аля LISP и ещё кучей полезных фич. В общем по идеологии он гораздо ближе к функциональному программированию, но при этом синтаксис напоминает C#. Этакий гибрид C# и F# + нормальные макросы.
К сожалению, язык этот за 10 лет существования не взлетел, потому что
1) Пиар за пределами RSDN у него был практически на нуле
2) Для многих программистов хватило функциональных возможностей, которые встроили в C#. Ну а для тех, кому хотелось больше функциональщины под .NET, взлетел F#
Будет ли у Nemerle второй шанс? Зависит от JetBrains, именно на них работают основные мейнтейнеры языка.
P.S. На самом деле, даже странно почему популярность Nemerle настолько близка к нулю… Я ожидал, что ситуация получше. Но не видно ни одного активного OpenSource-проекта на этом языке, если не считать проектов того самого Влада.
То, что Вы об их существовании знаете, в этом ничего удивительного нет. А вот то, что Вы пропустили момент, когда о них говорили, как о перспективных (это было лет 8-10 назад) — это странно.
Во, теперь понятно… привет из 2009 года.
Это Вы видимо про себя. На вопросы по существу отвечать научитесь, потом понтоваться будете.
Ну, полный список я Вам вряд ли предоставлю. Но для примера в Ruby есть def_delegator для этого, некоторые используют delegate из ActiveSupport, хотя это уже ближе к кодогенерации.
Кстати, аналогичную кодогенерацию можно устроить в любом языке где есть compile-time макросы. Rust, Crystal, Nim, etc. к вашим услугам. В Crystal такое есть из коробки, про остальных точно не знаю. Но сделать аналог весьма просто.
В функциональных языках делегация тоже хорошо поддерживается, только там она осуществляется от модуля к модулю, например defdelegate в Elixir.
Вы из какого года к нам прибыли? Я про Nemerle в прошлый раз слышал лет 8 назад. Влад и компания, конечно, молодцы и тогда этот проект выглядел весьма интересно. Но, имхо, после выхода C# 3.0 и включения F# в дефолтную поставку VS 2008 интерес к Nemerle стал стремительно затухать.
Про D я уже выше спрашивал, какой фактор сможет обеспечить рост популярности 15-летнему языку?
Ахах, это да, на тему того, что ASP.NET — неюзабельная хрень, практически все были единодушно согласны. Но спустя годы сделали порт Rails, назвали ASP.NET MVC и ничего, стало можно и под веб на C# комфортно разработку вести. Так что это ещё и исторический пример того, как реальная хрень может быть замещена чем-то путным в рамках одной и той же платформы.
А, кстати, почему? Боятся ограничить себя рамками Windows?
Я как-то давно отошёл от разработки десктопных приложений, поэтому не в курсе. Вообще Qt с .NET — это интересное сочетание, почему тогда не GTK или wxWidgets?
Конкуренты есть у всех. К тому же у массовости есть и обратная сторона: средний уровень сообщества падает от массового притока новичков в программировании. Что, по факту, имеет ряд негативных последствий для профессиональных программистов, начиная от необходимости учить/руководить чуть ли не чаще, чем программировать, и заканчивая замедлением темпов индексации зарплат.
Во некоторых языках разработчики позаботились о нормальной поддержке делегирования, и оно делается одной строкой, без какого-либо бойлерплейта.
Формулировка то расплывчатая. Но налоговая не расстроится, если вы будете 13%, а не 6% ей отчислять… Так что не волнуйтесь, в суд она на вас из-за этого подавать не будет )))
Вообще если это один заказ на продолжительное время, то физ.лицо тоже может вполне официально работать по договору подряда… Просто это невыгодно, потому что придётся 13% платить, а не 6%. Да ещё и в фонды из этих 13% никаких отчислений не будет.
А разве на PayPal сейчас не принудительная автоматическая конвертация в рубли? Реально лучше налог спокойно заплатить чем примерно такой же процент при конвертации потерять. Тем более, что 1 из 6% идёт напрямую в ПФР.
С чего бы это? У меня уже 3-й такой.
А вообще да, о количестве игр под мобилки я как-то не подумал, вот что значит наиграться в компьютерные игры ещё до появления смартфонов )))
У Swift — порядка 38 тыс. У Objective-C — около 150 тыс. Так что Rust если и выбивается из списка, то пока не сильно. А Swift заслуженно записан во второй эшелон.
Ну, добавили сначала простенький вывод типов (var) и лямбды, потом открыли возможность тип привязывать к данным, а не к переменным, а переменные ребиндить (dynamic) и возможность асинхронно код вызывать (async/await), ах да, ещё интерполяцию строк )))
Я не говорю что в этом есть что-то плохое, наоборот, мне нравится C# и направление, в котором он развивается тоже. Просто, если по-честному, ничего такого грандиозного в этом развитии нет со времён появления LINQ. Язык стабилен и просто обрастает мелкими приятными плюшками. Всё здорово.
Ахах, это Вы просто F# не пробовали, вот где лаконичность.
Настолько глобальные, что нарушают обратную совместимость.
Я немного знаком с CL и мне кажется очень похоже в плане макросов с Elixir. Да, в CL для гигиеничности нужно использовать gensym, а в Elixir для нарушения гигиеничности var!.. Т.е. в этом плане поведение по умолчанию отличается, но в остальном… те же quote(`), unquote(,), unquote_splicing(@,), те же манипуляции с AST при необходимости.
Со Scheme я не настолько знаком, чтобы всерьёз о нём рассуждать, но Racket, на мой взгляд, выглядит очень круто.
Что касается границ гибкости макросов Elixir, они пролегают по территории довольно редкой для практического применения, например, Вы не можете расширять синтаксис языка произвольным образом, т.к. разрешенный набор небуквенных символов ограничен. Если хотите принципиально кастомный синтаксис, то придётся оборачивать весь код, который будет его использовать, в один вызов макроса, внутри которого можно будет преобразовывать AST как угодно. Но это, в принципе, не велика проблема, т.к. для таких преобразований есть очень удобные средства типа
Macro.prewalk/3.А вот единственным принципиальным ограничением, в которое я однажды упёрся, было то, что в общем случае невозможно внутрь quote подставить кусочек сырого AST (кому интересно, могу в личку скинуть подробное описание этого случая). Это вытекает из двойственного представления кода, тогда как в LISP кроме AST другой записи кода нет. Но это реально очень экзотические случаи.
P.S. Вообще тема интересная, надо Rust и Racket поглубже копнуть )
Разумеется, преимущества BEAM — это не заслуга Elixir, но ведь он позволяет ими пользоваться. А таких языков не так уж и много, я осведомлён только об Erlang, Elixir и LFE. Вот и получается, что отличительными особенностями этих 3 языков являются преимущества BEAM :-)
Это из той же серии, что отличительные черты Kotlin — это преимущества JVM и возможность использовать Java-библиотеки. У Rust и Crystal — возможность легко подключать сишные либы. А у Elm — встраиваться в существующие JS-проекты.
И это понятно, никому сейчас не нужен язык-бука, который тупо проигнорит текущее состояние отрасли и будет делать абсолютно всё с нуля. Сложность заключается в выборе наиболее крутых достижений прошлого, их гармоничном комбинировании и дальнейшем развитии. Elixir в этом плане сделал ставку на возможности BEAM, интероперабельность с Erlang, макросы LISP и синтаксис Ruby. На мой взгляд, первые 2 пункта выполнены на отлично. Остальные 2 взяты за ориентир, но видимо не являлись самоцелью. Поэтому синтаксис только отдалённо похож на Ruby, а макросы местами не дотягивают до гибкости LISP, но при этом являются наиболее мощными из всех известных мне языков не из LISP-семейства.