На Ruby что-то пишут?

Вывод: руби - это религия.

Делать глобальный вывод по позиции одного индивида - истинно научный подход.

А на деле, язык для людей, а не для машины.

Главное что бы интерпритатор справлялся.

Писать на нем - одно удовольствие.

Воистину так.

Но есть какое-то ощущение игрушечности языка, что совсем невдомек: как на нем писать что-то серьезное? Чисто для фана - однозначно да.

А что серьёзного вы уже пытались на нём делать?
И вообще что вы подразумиваете под «серьёзный» проект? С примерами, пожалуйста.
И еще, для авторитетности утвержденией - чего большого вы уже реализовали за свой опыт (можно без доказательств, поверю на слово).

ЗЫ: на работе, в продакшене (как нынче модно говорить) я использую только баш и руби. Разгребают весьма не детские нагрузки (main ruby, ofc). Я доволен. Единственное чего мне не хватает, как уже было дело тут писал, это фичи которую я зрел в лиспе, когда на «горячую» можно править работающий код (иногда очень дорого рестартовать весь «демон»).

А что серьёзного вы уже пытались на нём делать?

org-ruby, можно глянуть мой вклад (vonavi)

И еще, для авторитетности утвержденией - чего большого вы уже реализовали за свой опыт

Я говорю об ощущениях о его игрушечности. Если таких у вас не возникает - замечательно. Для меня вершина динамических языков - CL, вот по сравнению с ним руби выглядит игрушкой в руках ребенка, и не консистентный.

действительно, зачем нужны статические проверки? статическая типизация не дает никаких преимуществ в написании кода, наоборот, порой необходимо городить кучу ООП и шаблонов для простых вещей

но _прекрасно_ их отлавливают

Свежо сие преданье, а верится весьма с трудом.

а не надо верить, тут не обитель культа Великого Макарона

возьми да и проверь

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

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

Язык действительно выглядит несколько усложнённым. Особенно на фоне Питона, где те же самые возможности реализованы при помощи маленького числа синтаксических конструкций.

Точно, а потом не забыть написать тестики выполнения тестиков, ведь так классно писать лишний код просто так, для развлечения.

Особенно приятно тестировать программы у которых четкого типа входных и выходных данных просто нет: ведь можно реализовать собственный маленький тайпчекер в каждой функции! Столько ненаписанного кода ждет профессионального программиста, ух.

Примеры, примеры давай.

Puppet, mcollective, capistrano

ты либо слишком толст, либо слишком глуп. уходи. на сим откланяюсь

Непонятно зачем ты вообще вылез из своего динамического петушатника, умник. Удачи!

Модульные тесты не для отлова опечаток, но прекрасно их отлавливают. Посему проблема высосана из пальца.

А, у нас в треде юный падаван, у которого модульные тесты с 100% покрытием... круто, чо.

Си действительно выглядит несколько усложнённым. Особенно на фоне ассемблера, где те же самые возможности реализованы при помощи маленького числа синтаксических конструкций.

fat fix

Для меня вершина динамических языков - CL, вот по сравнению с ним руби выглядит игрушкой в руках ребенка, и не консистентный.

У меня ощущения полностью обратные. Ruby — это прежде всего эргономика в написании и чтении кода. Как известно, код в первую очередь нужен для чтения человеком, и лишь иногда — для исполнения машиной.

В то время как CL — это академическая игрушка, не пригодная для массового применения.

Хотя гомоиконности и макросов иногда действительно не хватает в языке.

В то время как CL — это академическая игрушка

Только у него в отличае от .. есть пара приличных компиляторов. Был бы ruby|python|и.т.п чем то вроде баша, ни на что не претендующего, но ведб нет оно «неакадемическое».

Для таких задач как веб-приложения, различные скрипты автоматизации, простые GUI-обёртки и т.п. его производительности более чем достаточно.

Тем более, что транслятор ruby более производителен, чем php.

А писать молотилку чисел ни один здравомыслящий человек не будет ни на ruby, ни на CL.

А у тех туева хуча разношёрстных веб-фреймворков и толпы фанатов.

Правильно, в ясте нужно другие проблемы решать и юзабилити в том числе, а они переписывают, только почему зузевцы потом обижаются на популярность убунты?

Увы, не юный. И да, покрытие около 95%

покрытие около 95%

Ну то есть даже опечатки вполне могут остаться, и это ценой... сколько процентов от кода составляют тесты?

Столько ненаписанного кода ждет профессионального программиста, ух.

Так писать код это же очень интересно! Не будешь же ты целый день кататься на велосипеде и фотографировать на зеркалку.

Непокрытые 5% это как правило нетестируемые куски на стыке фреймворка и собственного кода, поэтому шанс пропустить опечатки ничтожно мал. И да, тесты это около половины кода, TDD же. В этом нет ничего плохого. Мне же не надо рассказывать зачем нужно писать тесты?

Непокрытые 5% это как правило нетестируемые куски на стыке фреймворка и собственного кода, поэтому шанс пропустить опечатки ничтожно мал

Знаменитые последние слова.

да, тесты это около половины кода

Недешево.

Мне же не надо рассказывать зачем нужно писать тесты?

Нет. Но так же не надо рассказывать о «ничтожных шансах пропустить ошибку» и «высосанных из пальца» проблемах динамической типизации.

А у тех туева хуча разношёрстных веб-фреймворков и толпы фанатов.

А это не критерий. То что на tcl и perl-е перстали, в массе, писать веб не делет их академичискими.

Недешево.

Вам шашечкидешево или ехатьнадежно? Мы же не индусы все таки.

Нет. Но так же не надо рассказывать о «ничтожных шансах пропустить ошибку» и «высосанных из пальца» проблемах динамической типизации.

Никаких проблем нет, стоит всего лишь попробовать и убедиться.

У меня primary skill как раз язык со статической типизацией, и я не имею никаких проблем с динамической. Использую примерно 60/40.

Вам шашечкидешево или ехатьнадежно?

Мне чтобы программа была свободна от обнаружимых опечаток. Вся. И от ошибок, связанных с типами - тоже вся.

У меня primary skill как раз язык со статической типизацией

Интересно. И какие это языки?

я не имею никаких проблем с динамической

Есть много способов «не иметь проблем с динамической типизацией» - например, обмазываться тестами, никогда ничего не рефакторить, а так же просто врать (себе или другим - неважно).

Почему не консистентный?

Мне чтобы программа была свободна от обнаружимых опечаток. Вся.

От всех опечаток не спасет даже статическая типизация

Интересно. И какие это языки?

С#, по динамическим javascript и ruby

Есть много способов «не иметь проблем с динамической типизацией» - например, обмазываться тестами, никогда ничего не рефакторить, а так же просто врать (себе или другим - неважно).

Обмазываться тестами нужно в любом случае, иначе как только система станет больше хелловорда, начнется адъ и израиль

Мне чтобы программа была свободна от обнаружимых опечаток. Вся. И от ошибок, связанных с типами - тоже вся.

Любая оттранслированная программа по определению свободна от ошибок, связанных со (статическими) типами.

Мне чтобы программа была свободна от обнаружимых опечаток. Вся.

От всех опечаток не спасет даже статическая типизация

Поэтому я сказал «обнаружимых опечаток». Т.е. тех, которые вылезут в рантайме на интерпретаторе.

У меня primary skill как раз язык со статической типизацией

Интересно. И какие это языки?

С#

Не то. Вот хаскелист/окамльщик/агдист(если такие есть) с таки отношением к динамической типизации - это было бы прикольно.

Обмазываться тестами нужно в любом случае

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

Любая оттранслированная программа по определению свободна от ошибок, связанных со (статическими) типами.

Дадада, а динамически типизированные языки - это статически типизированные языки, в которых все объекты имеют один и тот же тип.

Вот видишь, к чему приводит логика, если начать с кривой посылки.

Вот видишь, к чему приводит логика, если начать с кривой посылки.

В роли кривой посылки что именно - «оттранслированная программа по определению свободна от ошибок, связанных со (статическими) типами»? Если ты едином статическом типе, то там безупречная логика (на авторство которой я, кстати, не претендую).

хаскелист/окамльщик/агдист

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

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

это не большая цена за высокую скорость и простоту разработки

Вангую скорое появление в треде слов «утиная» и «Хинди-Милнер».

если хаскелиста еще можно каким то чудом сыскать, то вторые из разряда фантастики

Эфшарпер подошел бы.

это не большая цена за высокую скорость и простоту разработки

...если разработка завершается на версии 1.0, потому что написать заново будет проще, чем существенно переделать.

Ага, а потом разборки «утиная может быть статической» против «утиная по определению динамическая».

При правильной архитектуре переделывать будет довольно просто, выкидываем один компонент, добавляем другой. man Inversion of Control

При правильной архитектуре

Ну началось... «А если переделывать сложно, значит, архитектура неправильная!!1 Да и вообще, чо ты с первого раза не написал идеально - лох, штоле?». И даже если архитектура хорошая, _полная_ проверка программы - очень полезный инструмент.

Ну началось... «А если переделывать сложно, значит, архитектура неправильная!!1 Да и вообще, чо ты с первого раза не написал идеально - лох, штоле?»

Я не имею в виду изначально спроектировать все модули и компоненты. Достаточно придерживаться базовых принципов типа SOLID и GRASP, и переделывать и исправлять будет достаточно легко, независимо от типизации. А если нагородить кучу ненужных связей, всевозможных паттернов по гофу не понимая зачем они нужны и кода, то не спасет уже ничего.

И даже если архитектура хорошая, _полная_ проверка программы - очень полезный инструмент.

А с этим же никто и не спорит.

Для таких задач как веб-приложения, различные скрипты автоматизации, простые GUI-обёртки и т.п. его производительности более чем достаточно.

То есть круг задач заранее ограничен не предметной областью а транслятором. Который в свою очередь не допилят потому что круг задач ограничен :) И эти люди обвиняют в академичности. Беспредметно причем.

То есть круг задач заранее ограничен не предметной областью а транслятором.

Внезапно, всегда так было и всегда так будет. И в CL, и в сишечке, и в любом языке. Trade-off скорость разработки <-> скорость выполнения никуда не денется.

Но полагаться на тесты в поиске ошибок, которые должен искать компилятор - это разновидность ада и израиля.

Городить огород из «фбабрик фабрик» и прочих «паттернов высшего порядка» из-за ограничений системы (типов|классов) - не меньший «ад и израиль».

А теперь сделай еще один шаг и объясни чем

Trade-off скорость разработки <-> скорость

делает относительно тормнозной ruby пригодным и неакадемичным, раз уж ты CL таким не признаешь.

А при чем тут тормозной? Это как раз ты уводишь разговор в сторону: я про скорость выполнения вообще ничего не говорил, когда сравнивал ruby и cl.

Ты завёл пластинку про скорость, ты объясняй.

Городить огород из «фбабрик фабрик» и прочих «паттернов высшего порядка»

...можно и в динамически типизированном языке

>Городить огород из «фбабрик фабрик» и прочих «паттернов высшего порядка»

...можно и в динамически типизированном языке

понятно, что с хрустальным... эээ... инструментом надо вести себя соответствующим образом. Но в статике зачастую без этого ПВП никак

как раз ты уводишь разговор в сторону: я про скорость выполнения вообще ничего не говорил, когда сравнивал ruby и cl.

Ты не сравнивал, а голословно заявил про академичность CL. На что просто напрашивается тычок в сторону того факта, что CL сильно быстрее в многих (если не во всех) случаях при прочих равыных c ruby(динамика, gc и прочее). И если при сравнении C и ruby, еще можно что-то говорить про скорость разработки, то при сравнении ruby и СL это уже сложнее и будет очевидно ruby технологически не дотягивает. И из-за такого технологического отставания живет в порочном круге маленькте програмы -> не сильно умный транслятор -> будем писать маленькие програмы потому что транслятор хреновый. Итого, критиковать CL за академичность попутно доказывая высокую практичность ruby крайне странно.

Выдохнул. Пошел писать библиотеки для лиспа.