Comments 20
Спасибо! Когда, по вашему мнению (субъективно), perl6 будет stable и им реально можно будет пользоваться?
На мой взгляд, где-то через год. По крайней мере я на это надеюсь )
Потом ещё где-то годик на то чтобы вирт машина стала распрастраненной и чтобы появилось достаточное количество программистов пишущих на шестом перле :)
Потом ещё где-то годик на то чтобы вирт машина стала распрастраненной и чтобы появилось достаточное количество программистов пишущих на шестом перле :)
Есть теория, что разработка этого языка — процесс намеренно бесконечный.
То есть это разработка языка ради разработки.
Сейчас мало хорошего языка. Напомню, что perl5 сам по себе отличный язык.
Сейчас нужны мощные фреймворки, которые ускоряют разработку, внося ещё один уровень абстракции.
Мы знаем, что сегодня в других языках в этом вопросе шагнули дальше, чем в perl5.
Возвращаясь к perl6, и скорости его разработки.
Посмотрите историю релизов компиляторов, и поймёте, что это — медленно.
Хотите «разработку ради разработки» — используйте.
Хотите создавать готовые проекты, которые можно запустить, используйте то, что есть сегодня.
Ответ на ваш вопрос: очень не скоро.
То есть это разработка языка ради разработки.
Сейчас мало хорошего языка. Напомню, что perl5 сам по себе отличный язык.
Сейчас нужны мощные фреймворки, которые ускоряют разработку, внося ещё один уровень абстракции.
Мы знаем, что сегодня в других языках в этом вопросе шагнули дальше, чем в perl5.
Возвращаясь к perl6, и скорости его разработки.
Посмотрите историю релизов компиляторов, и поймёте, что это — медленно.
Хотите «разработку ради разработки» — используйте.
Хотите создавать готовые проекты, которые можно запустить, используйте то, что есть сегодня.
Ответ на ваш вопрос: очень не скоро.
Поправьте если ошибаюсь, но разве уже не описан весь синтаксис языка? На сколько я знаю, сама спецификация языка уже продумана, и осталось лишь подогнать существующие компиляторы до соответствия с нею?
На счёт скорости — да, не быстро. Но, например python3 делали 8 лет.
В случае с perl6 делали не только язык но и новую виртуальную машину (универсальную), так же при дизайне языка задумывались о всём том коде который уже написан на perl5, и не только о совместимости но и о идеологии perl.
Ну и наверное не всё шло(идёт) гладко. Жаль что не известно точно что именно там происходит и в чём проблемы.
В случае с perl6 делали не только язык но и новую виртуальную машину (универсальную), так же при дизайне языка задумывались о всём том коде который уже написан на perl5, и не только о совместимости но и о идеологии perl.
Ну и наверное не всё шло(идёт) гладко. Жаль что не известно точно что именно там происходит и в чём проблемы.
В perl5 как в языке, так и модулями есть все соврменные мейнстримовые фичи для разработки, абстракции и т.д. Универсальность и мультипарадигменоость языка это позволяет. Можете хоть java-style код писать.
На счет затянутости разработки 6-й версии. Разработка любой нвоой версии дает толчок к обсуждению новых фич и постепенному внедрению последних в предыдущие версии. perl5 стал релизиться часто и с каждым новым релизом добавляются фичи из обсуждаемого perl6.
perl6 уже можно использовать сейчас. Но он не production ready. Так же есть большой простор для портирования модулей из perl5 и написания новых модулей. Все это очень полезно людям, кто хочет делать что-то полезное для сообщества.
На счет затянутости разработки 6-й версии. Разработка любой нвоой версии дает толчок к обсуждению новых фич и постепенному внедрению последних в предыдущие версии. perl5 стал релизиться часто и с каждым новым релизом добавляются фичи из обсуждаемого perl6.
perl6 уже можно использовать сейчас. Но он не production ready. Так же есть большой простор для портирования модулей из perl5 и написания новых модулей. Все это очень полезно людям, кто хочет делать что-то полезное для сообщества.
В perl5 как в языке, так и модулями есть все соврменные мейнстримовые фичи для разработки, абстракции и т.д. Универсальность и мультипарадигменоость языка это позволяет. Можете хоть java-style код писать.
В сфере веб разработки эти фичи серьёзно уступают аналогам из других языков, это не вызывает спор? Дело не «писать в стиле», дело в разработке бизнес процессов, а не налаживании инфраструктуры проекта.
perl5 стал релизиться часто и с каждым новым релизом добавляются фичи из обсуждаемого perl6
Это здорово, и действительно радует. Одни только решенные траблы с utf8 вызывают восторг
perl6 уже можно использовать сейчас. Но он не production ready.
Это значит, что использовать его нельзя, неготов он. Можно заниматься разработкой инструментов для разработки, а можно делать проекты, которыми пользуются простые пользователи. Кому что.
Как Rails программист могу сказать про веб фреймворки.
ИМХО Rails хорошо подходят если нужно:
— быстро делать вебсайты в стиле web 2.0
— главное скорость разработки а не стабильность.
— много программитсов, которые незваисимо друг от друга пилят проект, каждый в своём стиле
— апгрейдить проект под новый ruby и рельсы каждые пару лет — это ок.
в остальных случаях «веб разработки» нужно разбираться — может лучше обойтись без MVC.
ИМХО Rails хорошо подходят если нужно:
— быстро делать вебсайты в стиле web 2.0
— главное скорость разработки а не стабильность.
— много программитсов, которые незваисимо друг от друга пилят проект, каждый в своём стиле
— апгрейдить проект под новый ruby и рельсы каждые пару лет — это ок.
в остальных случаях «веб разработки» нужно разбираться — может лучше обойтись без MVC.
В сфере веб разработки эти фичи серьёзно уступают аналогам из других языков, это не вызывает спор? Дело не «писать в стиле», дело в разработке бизнес процессов, а не налаживании инфраструктуры проекта.
А можно раскрыть тему преимуществ других языков? Например, в сравнении Mojolicious/Rails/Django. На рельсах баловался — каких-то глобальных преимуществ перед Mojo/Dancer не увидел, может не туда смотрел.
А можно раскрыть тему преимуществ других языков? Например, в сравнении Mojolicious/Rails/Django. На рельсах баловался — каких-то глобальных преимуществ перед Mojo/Dancer не увидел, может не туда смотрел.
Есть люди, которые умеют «продавать» продукт, а есть, которые не умеют, при одинаковом наборе слов.
Это я к тому, что сейчас я не пытаюсь никого убедить, плохо это получается.
Итак, мы в Ленте.Ру достаточно долго писали всё на perl5. Я сам вырос на этом языке. Сейчас мы пишем новую версию на рельсах. Старый движок не использовал попсовых фреймоврков, был самописным, тогда это было удобнее, ввиду таких факторов как наследственность, количество разработчиков, скорость интеграции и поддержка. Но далее встал вопрос, на чём вести разработку, имея возможность писать движок с нуля, параллельно работающей версии. Изучали, смотрели, пробовали. Mojo несколько похож на Sinatra из мира ruby. На Django особо не смотрели, не хотелось переходить на python, были свои причины. Между perl и ruby выбирали по критерию: скорость разработки, развитость фреймоврка в виде обновляемости и сообщества, количество сторонних готовых современных решений.
Получается, что для команды, где роли backend/frontend разработчиков строго разделены, поддержать перечисленные условия проще на ruby. Просто посмотрите за сколько шагов вы сможете развернуть приложение на сервере со стандартным набором. Что вам надо от приложения? Миграции, веб сервер, орм, шаблонизатор, удобный для верстальщиков, работа с ассетами (js/css/img), консольные утилиты, деплой на серверы, системы тестирования и прочее. В Mojo всё это из коробки и оно удобное?
От чего я плюсь в ruby, так это скорость работы приложения. После perl для меня это АД. Загружается долго, исполняется не так быстро как хотелось бы. Но даже это перекрывается той скоростью разработки и уровнем интеграции работы backend и frontend программистов. А скорость работы решается масштабированием — получается дешевле.
В perl есть аналоги haml/sass/compass/coffee, но они либо уступают в реализации, либо их интеграция требует допиливания. Это не идеальные инструменты, в них есть косяки которые меня раздражают, но они позволяют быстро и понятно разрабатывать продукт, не отвлекаясь на настройку приложения.
Много пишут(писали) про «богатый внутренний мир», то есть cpan, где есть решения на всё. Только обратите внимание, как он обновляется, мне например грустно от этого.
И контрольный про perl6. Если не готов язык, когда напишут такие библиотеки? Текущие рельсы ведь тоже на месте не стоят, и плюшки там всё интереснее и интереснее. Больше автоматизма в работе разработчика — это важно. Многие ведь используют IDE, а не блокнот. Так и с языком — от него и его библиотек(!!!) ждут современного уровня.
Perl хороший язык, но веб разработку на нём сегодня вести дорого.
Это я к тому, что сейчас я не пытаюсь никого убедить, плохо это получается.
Итак, мы в Ленте.Ру достаточно долго писали всё на perl5. Я сам вырос на этом языке. Сейчас мы пишем новую версию на рельсах. Старый движок не использовал попсовых фреймоврков, был самописным, тогда это было удобнее, ввиду таких факторов как наследственность, количество разработчиков, скорость интеграции и поддержка. Но далее встал вопрос, на чём вести разработку, имея возможность писать движок с нуля, параллельно работающей версии. Изучали, смотрели, пробовали. Mojo несколько похож на Sinatra из мира ruby. На Django особо не смотрели, не хотелось переходить на python, были свои причины. Между perl и ruby выбирали по критерию: скорость разработки, развитость фреймоврка в виде обновляемости и сообщества, количество сторонних готовых современных решений.
Получается, что для команды, где роли backend/frontend разработчиков строго разделены, поддержать перечисленные условия проще на ruby. Просто посмотрите за сколько шагов вы сможете развернуть приложение на сервере со стандартным набором. Что вам надо от приложения? Миграции, веб сервер, орм, шаблонизатор, удобный для верстальщиков, работа с ассетами (js/css/img), консольные утилиты, деплой на серверы, системы тестирования и прочее. В Mojo всё это из коробки и оно удобное?
От чего я плюсь в ruby, так это скорость работы приложения. После perl для меня это АД. Загружается долго, исполняется не так быстро как хотелось бы. Но даже это перекрывается той скоростью разработки и уровнем интеграции работы backend и frontend программистов. А скорость работы решается масштабированием — получается дешевле.
В perl есть аналоги haml/sass/compass/coffee, но они либо уступают в реализации, либо их интеграция требует допиливания. Это не идеальные инструменты, в них есть косяки которые меня раздражают, но они позволяют быстро и понятно разрабатывать продукт, не отвлекаясь на настройку приложения.
Много пишут(писали) про «богатый внутренний мир», то есть cpan, где есть решения на всё. Только обратите внимание, как он обновляется, мне например грустно от этого.
И контрольный про perl6. Если не готов язык, когда напишут такие библиотеки? Текущие рельсы ведь тоже на месте не стоят, и плюшки там всё интереснее и интереснее. Больше автоматизма в работе разработчика — это важно. Многие ведь используют IDE, а не блокнот. Так и с языком — от него и его библиотек(!!!) ждут современного уровня.
Perl хороший язык, но веб разработку на нём сегодня вести дорого.
Просто посмотрите за сколько шагов вы сможете развернуть приложение на сервере со стандартным набором. Что вам надо от приложения? Миграции, веб сервер, орм, шаблонизатор, удобный для верстальщиков, работа с ассетами (js/css/img), консольные утилиты, деплой на серверы, системы тестирования и прочее. В Mojo всё это из коробки и оно удобное?
Миграции в рельсах завязаны на собственный ORM. Мы, например, ORM не используем.
Вебсервер — в один Mojo встроено 3 разных типа веб серверов + Starman + Twiggy.
Шаблонизаторов кучи на любой вкус. Конкретезируйте что вы понимаете под удобством для верстальщика, пожалуйста? В том же Mojo встроенный ep вполне себе удобен для всех верстальщиков с которыми я работал. И всякие TT и иже с ним никто не отменял.
Работа с ассетами? Во фреймворке? Что Вы под этим подразумеваете? Про консольные утилиты тот же вопрос.
Деплой на сервера — Git, Capistrano и прочее прочее, причем тут язык и фреймворк?
Системы тестирования аналогично, при том что в perl и Mojo тесты идут из коробки.
Видимо тут прослеживается различие в подходах. Вам удобнее заточить процесс разработки под инструменты. Мне же удобнее взять разные инструменты и скомбинировать окружение которое будет работать с максимальной отдачей.
Миграции в рельсах завязаны на собственный ORM. Мы, например, ORM не используем.
Вебсервер — в один Mojo встроено 3 разных типа веб серверов + Starman + Twiggy.
Шаблонизаторов кучи на любой вкус. Конкретезируйте что вы понимаете под удобством для верстальщика, пожалуйста? В том же Mojo встроенный ep вполне себе удобен для всех верстальщиков с которыми я работал. И всякие TT и иже с ним никто не отменял.
Работа с ассетами? Во фреймворке? Что Вы под этим подразумеваете? Про консольные утилиты тот же вопрос.
Деплой на сервера — Git, Capistrano и прочее прочее, причем тут язык и фреймворк?
Системы тестирования аналогично, при том что в perl и Mojo тесты идут из коробки.
Видимо тут прослеживается различие в подходах. Вам удобнее заточить процесс разработки под инструменты. Мне же удобнее взять разные инструменты и скомбинировать окружение которое будет работать с максимальной отдачей.
1) А представьте что было бы если бы проект был написан не на Perl, а на Ruby 1.8, Rails 2 + куча гемов для Rails 2.
Счас бы точно так же всё пришлось переписывать с нуля, или латать дыры.
2) Простота настройки и скорость разрабоки в начале, могут выйти боком потом.
В Rails по моему оптыту — если действовать по принципу быстро подключать готовую библиотеку и никогда не изобретать «велосипеды», то потом гораздо больше времени уйдёть чтобы это поддерживать, чем на написание этих «велосипедов». Если сайт сложный — нужно часто писать велосипеды, гемами нужно пользоваться с умом, избегать использования их без существенного повода.
Ничего просто так не даётся.
Ленту.ру можно небось вообще на wordpress сделать, а потом плагины писать — вот уж точно будет высокая скорость разработки вначале.
Счас бы точно так же всё пришлось переписывать с нуля, или латать дыры.
2) Простота настройки и скорость разрабоки в начале, могут выйти боком потом.
В Rails по моему оптыту — если действовать по принципу быстро подключать готовую библиотеку и никогда не изобретать «велосипеды», то потом гораздо больше времени уйдёть чтобы это поддерживать, чем на написание этих «велосипедов». Если сайт сложный — нужно часто писать велосипеды, гемами нужно пользоваться с умом, избегать использования их без существенного повода.
Ничего просто так не даётся.
Ленту.ру можно небось вообще на wordpress сделать, а потом плагины писать — вот уж точно будет высокая скорость разработки вначале.
В сфере веб разработки эти фичи серьёзно уступают аналогам из других языков, это не вызывает спор?
Единственной фичи которой нет в перле, это кучи юных фанатов, которые кричат на каждом углу какие рельсы хорошие :)
Это значит, что использовать его нельзя, неготов он. Можно заниматься разработкой инструментов для разработки, а можно делать проекты, которыми пользуются простые пользователи. Кому что.
разработка инструментов разработки — тоже нужная штука. Многим это доставляет большой фан. Иначе не было бы фреймворков, рельс и т.д.
Единственной фичи которой нет в перле, это кучи юных фанатов, которые кричат на каждом углу какие рельсы хорошие :)
Это значит, что использовать его нельзя, неготов он. Можно заниматься разработкой инструментов для разработки, а можно делать проекты, которыми пользуются простые пользователи. Кому что.
разработка инструментов разработки — тоже нужная штука. Многим это доставляет большой фан. Иначе не было бы фреймворков, рельс и т.д.
В сфере веб разработки эти фичи серьёзно уступают аналогам из других языков, это не вызывает спор?
Ну как говорится, примеры в студию.
Я вот вижу, что последнее время инфраструктура разработки перла развивается семимильными шагами, и не в послуднюю очередь за счет портирования инструментов из мира Ruby/Python
Пример написал выше. То, что она развивается, это хорошо, правда, но не достаточно. Вы хотите увидеть два приложения, делающих одно и тоже, реализованных в двух языках — увы, нет такого. Вы вот можете сказать, что у перла есть в противовес тем утилитам из мира руби?
Сорри примера не вижу. Кстати я о perl5.
Каким именно утилитам?
Например, Rack портирован, => PSGI/Plack, и соотвественно инфраструктурой он оброс уже достаточно, сейчас идет работа над Carton, это аналог Bundler'a
Да никто и не ждёт полной копии, просто нужны новые инструменты, которые решают задачи или улучшают текущие решения, и они появляются, и это не может не радовать.
Каким именно утилитам?
Например, Rack портирован, => PSGI/Plack, и соотвественно инфраструктурой он оброс уже достаточно, сейчас идет работа над Carton, это аналог Bundler'a
Да никто и не ждёт полной копии, просто нужны новые инструменты, которые решают задачи или улучшают текущие решения, и они появляются, и это не может не радовать.
Sign up to leave a comment.
Perl6 — Ввод-вывод, модули