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

то есть для тебя этого предложения достаточно чтоб поверить, что в руби нет синтаксического анализатора?

А что не так? Если ты вместо a.foo напишешь a.fo, это не синтаксическая ошибка, а именно опечатка. И пока исполнение не дойдет до нее, ты о ней не узнаешь.

Да я это знаю, я товарищу отвечал.

Если ты вместо + напишешь -, это не синтаксическая ошибка, а именно опечатка. И пока программа не начнёт выдавать ерунду, ты о ней не узнаешь.

fxd

Кое-кто не читал условия задачи.

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

Это не мой фикс говно, а твой сдохший детектор сарказма.

Кое-кто намекает на 9k раз изжеванный срач динамической vs статической типизации и утопичного контроля компилятором всего чего можно и чего нельзя.

Кое-кто намекает на 9k раз изжеванный срач динамической vs статической типизации

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

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

Если ты вместо a.foo напишешь a.fo

Думаем на тему динамической диспетчерезации. Делаем выводы.

Думаем на тему динамической диспетчерезации.

Зачем вы об этом думаете? В контексте вопроса и ответа, который вы комментируете, думать надо о синтаксических проверках.

О синтаксических проверках чего?

О синтаксических проверках чего?

Ответ выше по треду.

Да, питон — он такой. В руби, к счастью, нет такого.

В агде будет.

Ruby, like most other badly designed languages, does not require variables to be declared

Это не недостаток.

Однако, удобно, когда требуется указать первое использование переменной, например «my $a = 12;»

По остальным пунктам - согласен.

Наткнулся на текст http://pastebin.com/7nkj7u40 , который породил во мне желание никогда не изучать Ruby.

Спасибо, познавательно. Можно было бы и свалить на CL, но отсутствие батареек не радует.

Можно было бы и свалить на CL, но отсутствие батареек не радует.

Это каких? Интересно, что же есть на руби и нет на cl?

Это каких? Интересно, что же есть на руби и нет на cl?

Я в этом сугубо субъективен. Например, захотел вести блог и писать статьи в Org-Mode формате. Сделал связку jekyll + org-ruby, да еще и подсветка синтаксиса через pygments.rb. За время допила org-ruby, понял, какое УГ этот руби.

Лиспофицированый аналог jekill-a на cliki как ни странно есть.

Лиспофицированый аналог jekill-a

Имя, сестра, имя.

Hyde

Hyde

Хорошо пошутил. По issue трекеру замечательно видно, что пользуется этим один человек, который летом прошлого года (см. историю коммитов) делал свой велосипед, после чего забросил.

Вот почему, как только скажешь, что батареек для CL нет, так нет, чтобы доказать обратное. Приведут обязательно пример какой-нибудь какашки, что я еще больше убеждаюсь в своем тезисе.

За время допила org-ruby, понял, какое УГ этот руби.

А со стороны кажется красивым. Я под впечатлением от него в CL похожий синтаксис вызова методов сделал: https://github.com/Kalimehtar/message-oo (+ возможность иметь много методов с одинаковыми именами, но разным количеством агрументов).

Особенно доставляет этот ооп-стиль: length(x).

В нормальных языках методы принадлежат типу (или даже классу типов), а не объекту, что позволяет делать множественную диспетчеризацию. И синтаксис вызова более похож на указанный, чем на убогий x.length().

А со стороны кажется красивым.

Руби не консистентный, в то время как к CL сколько не прибавляй, он все равно остается лиспом.

В смысле надо не чтоб работало, а что бы батарейки.. :)

А какие это языки и чем убог такой вызов?

А какие это языки

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

чем убог такой вызов?

Ну, например, прибит к одной сущности, а если нужен метод, связывающий равноправные вещи: «x + y» / «x `add` y» vs «x.add(y)».

Ну так для ООП же логично прибивание метода к инстансу, по-моему, разве нет? (тут был обрывок мысли, не относящейся к делу) С иной записью непонятно, где что: например, z = x.add(y).add(p) - очевидно, какой метод какого объекта вызывается, а с z = add(x,y,p) (или add(add(x,y), p), если не вариадическое сложение) сказать сложнее. Хотя я не берусь утверждать, что лучше, мне наоборот интересно послушать, чего я, может, не так понимаю :)

ООП -> наследование. Наследование = зло. Ком говна, который накатывается всё больше с каждым наследником, превращая продукт в карточный домик, который рассыпается при достаточно небольшом изменении требований к функционалу. Потому что наследовании в 95% случаев просто не нужно, оно не применимо к задаче, но его суют куда ни попадя.

ООП переоценено.

Ну так для ООП же логично прибивание метода к инстансу, по-моему, разве нет?

Да, если опп в узком смысле (в широком можно понимать как «позднее связывание» / «динамическую диспетчеризацию» - тут и erlang включают). Но суть в том, что изначально было:

В нормальных языках методы принадлежат типу (или даже классу типов), а не объекту

То есть, это не в _контексте ооп_, а «логичное прибивание» - в контексте. Конструктивно ли так возражать?)

z = x.add(y).add(p) - очевидно, какой метод какого объекта вызывается

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

Например: классовая ф-ия может иметь тип «a», пример minBound в хаскеле (minBound :: Char - это '\NUL', minBound :: Bool - это False). В ооп придется дополнительно плясать, создавая biulder, afaiu.

первый аругмент «объект»

Добавлю, что первый и ключевой, иначе мой пример про add - совсем не подходит).

То есть, правильнее (логичнее? красивее? производительнее? «нормальноязычнее»?) делать что-то в стиле Fixnum.add (a, b)?

То есть, правильнее (логичнее? красивее? производительнее? «нормальноязычнее»?)

1) Перечитать подветку; 2) Осознать что тот был не мой коммент; 3) Мной был приведен пример, когда классовые ф-ий более близки предметной области: же add, или более общи: вызов без аргументов; 4) ???; 5) profit

То есть я не знаю, что имелось ввиду оригинально, аргументровал за 3) - иногда более «логичны». Красивее - на любителя. Производительнее - не понятно с чем сравнивать (на заметку: диспетчеризация на типах возможна в compile-time). «Нормальнее» - не могу судить.

иногда более «логичны»

+ общность

У говнаря-лиспера баттхерт от того, что его говнолисп используют полтора человека в мире, тогда как более кривую рубю используют ажно десять человек? Маргиналы такие маргиналы!

Да годный язык... для замены перла.

rails http://www.opscode.com/chef/ https://puppetlabs.com/ http://adhearsion.com/ http://cukes.info/

Он же динамически-типизированный и, вообще, скриптовый — на нем только говно на выброс пишут в основном. Даже Лисп из него никакой.

Начните уже писать модульные тесты, жизнь станег легче

Начните уже писать модульные тесты

Модульные тесты для отлова опечаток - это сильный ход. Но в любом случае, мы не можем начать их писать, потому что давно уже пишем.

Да, и еще проверки в коде на типы принимаемых значений, на то, что они в нужном диапазоне....

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

Особенно на гуй и многопоточные приложения люблю писать модульные тесты. ЕВПОЧЯ.

Отличная идея, лол. Вот еще одна - начните уже писать свою реализацию тайп-чекера в тестах, жизнь станет легче.

Особо одаренные ребята пишут декораторы к функциям в питоне, которые проверяют тип аргументов и возвращаемого значения.

Благодаря Ruby принесено много нового в веб-разработку.

Можно сказать в каком-то смысле убийца php и perl, как языков для веб-разработки.

Но увы со своими недостатками и главный это ресурсы сервера.

Но для меня оно не критично - личный домашний сервер.

Сам язык Ruby наверно лучшее что можно было ожидать после php и perl.

Но появился Ruby слишком поздно, тогда когда и функциональные языки смогли дотянуться до веб-разработки (по ссылке незаслуженно охаивается Haskell, видимо автор наглицкого текста не осилил ничего кроме списков на Lisp).

Lisp тоже годный язык но для своих задач (CADы разные).

А по ссылке бред относительно производительности, который к тому и не актуален, особенно если прикрутить к сайту на базе nginx+passenger парочку memcached и dalli

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

Проверку на диапазон в любом случае надо делать в интерфейсном коде.

Руби хорош для прототипа, но и приложения, где скорость не критична, на нем делать одно удовольствие, быстро и легко

1. руби замечателен (на комментарии и доводы сторонних людей мне будет пофиг, потому заведомо можно предупредить о бессмысленности ответа на это) 2. если он тебе не по душе - не используй его

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

Действительно, зачем нужны статические проверки, если их можно самому написать ручками вместо компилятора?