про руби (программистское)
Apr. 8th, 2007 12:20 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
avvaЯ хотел бы написать, что проблема, которая стоит перед языком Руби и его сообществом - преодолеть засилие радостных идиотов, fanboys, которые наполнили собой и засоряют сообщество. Но я не уверен, что это действительно проблема. Да, мне лично, и многим другим (как аутсайдерам с точки зрения Руби, подобно мне, так и опытным разработчикам в нем) это не нравится и отталкивает. Но, с другой стороны, весь этот шум в конечном счете ответственен за популярность этого языка, за его растущую известность, за mindshare в программистской среде.
Обычное дело - когда о чем-то очень громко говорят, выходит, что говорят в основном дураки. А что поделать, если хочется быть услышанным?
В последнее время мне попались два примера.
What's Wrong With Ruby - мнение человека, которому не очень понравился Руби. В статье он перечисляет, что ему не понравилось и что показалось перехваленным в обычных описаниях Руби. При этом он сохраняет вполне корректный и умеренный тон, и отдает должное языку в том, что ему понравилось. Интересная статья, несколько эклектичная и недостаточно подробная, но все равно интересная. Я, например, разделяю неприязнь автора к "cutesy introductory tutorials", и особенно к знаменитому в сообществе Руби Why's (Poignant) Guide. Это ужасная на мой взгляд книга, полная несмешных вымученных шуток и картинок, идиотской болтовни, и на редкость неудачных собственно объяснений и примеров того, что касается самого языка.
Однако дело не столько в самой статье, сколько в комментариях под ней, в которых тут же собралось стадо fanboys - идиотов, ругающих автора последними словами за то, что он посмел посягнуть на их культовый язык или на культовую фигуру _why (автора вышеупомянутой книги). Их немало в комментариях к самой статье, и еще больше - в комментариях к записи _why на эту тему (как обычно в его стиле, зубодробительно несмешной). Почитайте - эти комментарии говорят за себя. Нет, я не думаю, что они характеризуют все сообщество пользователей Руби. Но они характеризуют то стадо fanboys, которое его замусорило.
Мне попадалось мнение, что идиоты кочуют от одного популярного языка или технологии к другим, и многие из тех, что сейчас пишут и говорят благоглупости о Руби, раньше молились на Джаву, когда та была "cool". Может, в этом что-то есть. Но что в языке или технологии или сообществе, уже существующем, притягивает такие массы? Я не могу себе представить, например, такой поток ответов на статью, критикующую Перл, ни сейчас, ни пять лет назад, ни десять. Или Питон, или Хаскель, или Лисп.
Второй пример - статья "Why was Rails only possible with Ruby?" на сайте O'Reilly. Точнее, не статья, а рецензия книги о Руби и Rails. В ней самой, и в довольно интересно потоке комментариев под ней, поражает совершенное детская наивность тех, кто упрямо утверждает, что в Руби есть какие-то мистические свойства, которые делают создание системы типа Rails возможным только в Руби - и их неспособность назвать эти свойства: после того, как им снова и снова объясняют, что вот эти и вот эти и вот эти свойства Руби, которые они считают уникальными, на самом деле есть и тут и тут и тут, и системы, подобные Rails, на самом деле есть, и в чем-то более интересные (Seaside в Смоллтоке часто упоминается в последнее время - я не успел пока о нем подробнее прочитать), после всего этого им остается только лепет насчет "интуитивности" и каких-то мистических откровений, которые превращают Руби в идеальнейший из языков. Пользуясь словами того же _why, "We can no longer truthfully call it a computer language. It is coderspeak. It is the language of our thoughts". И вот такой интеллектуально беспомощный фанатизм тоже, увы, весьма распостранен в сообществе Руби, насколько я могу судить, когда с ним сталкиваюсь. Впрочем, опять-таки, действительно ли "увы"? Может, сообществу Руби это нравится, и такая форма агрессивного самопиара его вполне устраивает.
В завершение замечу только, что все же собираюсь в ближайшее время изучить Руби, хоть и не в ближайшие пару месяцев, наверное. И процитирую понравившееся из комментариев к второй статье, среди аргументов и обвинений поклонников Руби, Питона, Джавы, Перла и других языков:
"Can't we all at least agree to hate PHP? ;)"
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2007-04-09 07:59 am (UTC)no subject
Date: 2007-04-09 09:05 am (UTC)C++ нельзя назвать консистентным хотя бы потому, что первоначально он разрабатывался как ОО-довескок к С.
""
Не согласeн с подобной аргументацией. Напомню свои слова:
"миссия" C/C++ - "portable ассемблер", т.е. возможность достичь максимальной эффективности и контроля над тем как программа "крутится" в железе, не теряя при этом возможности реализовывать и поддерживать сколь угодно сложные алгоритмы.
Когда появилась нужда в ОО для реализации приложений (а когда появился С, сначала без этого обходились) добавили классы. Bполне консистентно с вышеуказанной миссией, и без лишних глупостей.
""
Чего только стоит использования модификатора static для синглетон методов/переменных.
""
Нормально. В С static означает данные видимые в файле (файл в С - ближайший аналог С++класса) существующие независимо от входа/выхода из функций файла.
В С++ классе static означает данные видимые в классе независимые от экземпляров. Можно и отдельное ключевое слово сделать, но это непринципиально т.к. коллизий со старым смыслом не возникает, и преимущество что нет лишних ключевых слов.
no subject
Date: 2007-04-09 10:10 am (UTC)"миссия" C/C++ - "portable ассемблер", т.е. возможность достичь максимальной эффективности и контроля над тем как программа "крутится" в железе, не теряя при этом возможности реализовывать и поддерживать сколь угодно сложные алгоритмы.
Использование выражения "C/C++" считаю не допустимым. Это _совсем_ разные языки. C действительно задумывался Керниганом и Ритчи как "portable ассемблер" и своей целью он справляется, как никто другой. C++ в "железных" задачах используется редко. Из ядер, более/менее распространённых операционных систем, на моей памяти только ядро BeOS написано на C++. И где сейчас BeOS?
Когда появилась нужда в ОО для реализации приложений (а когда появился С, сначала без этого обходились) добавили классы. Bполне консистентно с вышеуказанной миссией, и без лишних глупостей.
Что касается ОО для "железных" задач, то вполне хватает C. Я имею ввиду, что для использования концепций ОО не обязательно использовать ОО-язык программирования(см. linux). На мой взгляд, код на C является более поддерживаемым, чем на C++. Найти хорошего программиста на C++ является крайне сложной задачей. Стандарт на C++ документ непомерный. Для C хватает тонкой книги от K&R.
Нормально. В С static означает данные видимые в файле (файл в С - ближайший аналог С++класса) существующие независимо от входа/выхода из функций файла.
В С++ классе static означает данные видимые в классе независимые от экземпляров. Можно и отдельное ключевое слово сделать, но это непринципиально т.к. коллизий со старым смыслом не возникает, и преимущество что нет лишних ключевых слов.
Я и говорю, что много наследия тащиться из C, что не есть хорошо для языка который претендует на звание объектно-ориентированного.
Ткните меня в любой источник по теории ОО-программирования, где бы использовался термин static в любых вариациях?
no subject
Date: 2007-04-09 10:57 am (UTC)(Не в глобальное возражение) Увы, так только по задумке. На практике же у C++ слишком сильное наследие C, чтобы можно было от него избавиться так просто.
no subject
Date: 2007-04-09 11:12 am (UTC)Использование выражения "C/C++" считаю не допустимым. Это _совсем_ разные языки.
""
языки разные, но "миссия" у них одинаковая. Именно в этом, узком, смысле употреблено "C/C++".
""
C++ в "железных" задачах используется редко.
""
По собственному опыту, используется в очень "железных" задачах (embedded system) очень компетентными людьми.
""
Что касается ОО для "железных" задач, то вполне хватает C.
""
Есть реальные задачи где не хватает (сильно продвинутые алгоритмы, при этом нужна эффективность).
""
Я имею ввиду, что для использования концепций ОО не обязательно использовать ОО-язык программирования
""
Да. Я даже сталкивался с мнением, что С лучше подходит для ОО-программирования чем С++! (хотя я с этим и не согласен, но это не полная глупость).
""
На мой взгляд, код на C является более поддерживаемым, чем на C++. Найти хорошего программиста на C++ является крайне сложной задачей.
""
Да. С++ дает неквалифицированному программистy гораздо больше "возможностей" спороть фигню, но это еще не повод отказаться от него квалифицированным программистам там где он по делу.
""
Я и говорю, что много наследия тащиться из C, что не есть хорошо для языка который претендует на звание объектно-ориентированного.
""
Как я уже писал, основная цель (и консистентность) С++ - не идеал воплощения абстрактных концепций, а практически полезный инструмент (что включает и downcompatibility) позволяющий практически использовать ОО для практических приложений.
no subject
Date: 2007-04-09 11:56 am (UTC)Можно по подробней где? Я сам занимаюсь embedded systems(linux для storage и media серверов). Пока ничего системного на C++ не видел.
Есть реальные задачи где не хватает (сильно продвинутые алгоритмы, при этом нужна эффективность).
По-больше конкретики. Scheduling, к примеру, не сильно продвинутый алгоритм?
Да. Я даже сталкивался с мнением, что С лучше подходит для ОО-программирования чем С++! (хотя я с этим и не согласен, но это не полная глупость).
Ну, в случае linux, ОО там получается довольно красивое и стройное(смотри fs-подсистему, например).
Ссылочка в тему: http://nothings.org/computer/cpp.html
no subject
Date: 2007-04-09 12:05 pm (UTC)а оно есть.
а на Windows так просто практически всё "системное" пишут на крестах.
Члены суда
Date: 2007-04-09 12:22 pm (UTC)no subject
Date: 2007-04-10 08:16 am (UTC)про системноe на C++ вам уже ответили, я тоже полагаю что С++ заведомо не хуже, и часто лучше чем С для системных задач.
Ссылку вашу начал смотреть - пока выглядит как дешевое и глупое пижонство:
"Why C++ Sucks"(огромным фонтом!) -- не нравится мужику язык - ну и не использовал бы его и все дела. У него что зуд ?
"It was designed to have those features necessary to achieve popular success--not those features necessary to be a good programming language." -- Бессмысленно-абсурдная фраза. good programming language - это по определению язык, который много людей находят для себя полезным.
"The Big Mistake: C Compatibility" -- а старый софт стоящий десятки миллиардов долларов этот кoзел сам для всех бесплатно перепишет на языке своей мечты ?!
no subject
Date: 2007-04-10 10:01 am (UTC)Вопрос в том, как много людей считает язык полезным лишь потому, что они зомбированы маркетингом. Маркетинг не так часто, как хотелось бы, соотносится со здравым смыслом. Моё личное мнение: C-подобный синтаксис мало пригоден для ОО-языка.
"The Big Mistake: C Compatibility" -- а старый софт стоящий десятки миллиардов долларов этот кoзел сам для всех бесплатно перепишет на языке своей мечты ?!
Биндинги к C-библиотекам ещё никто не отменял.
no subject
Date: 2007-04-10 10:18 am (UTC)Умоляю Вас, ради сохранения у меня остатков веры в человечество, скажите что Вы так неудачно пошутили!
no subject
Date: 2007-04-10 10:28 am (UTC)Есть ещё dlopen().
P.S. Можно по-меньше пафоса?
no subject
Date: 2007-04-10 10:31 am (UTC)no subject
Date: 2007-04-10 10:35 am (UTC)no subject
Date: 2007-04-10 10:48 am (UTC)К примеру, интеграция языка класса того же Руби с Xlib представляют собой совсем не такую тривиальную задачу что бы от нее можно было отмахиваться как от не заслуживающей внимания.
Но это еще полбеды. Настоящая беда начинается в тот момент когда системе состоящей из двух языков обнаруживаются ошибки: дебаггеры, позволяющие отлаживать одновременно два языка встречаются очень редко, почти никогда, и программист, выбравший композитное решение, остается с отладкой методом пристального взгляда и отладочной печати. Как в 60-х годах прошлого века.
no subject
Date: 2007-04-10 11:20 am (UTC)Согласен. Для этого и придумали SWIG. Хотя результат и не очень красивый. Лучше рукими, хотя и дольше.
Хорошо если надо создавать переходный уровень к сишным функциям, параметры и возвращаемые данные которых отображаются на конструкции языка тривиальным образом - как отображаются сишные целые числа на целые числа, сложнее когда надо отображать сишные строчки на строчки иного языка, совсем плохо когда надо отображать сишные структуры на объекты иного языка и обратно, и, наконец, задача создания переходного уровня становится окончательно непростой в случае когда сишная библиотека манипулирует структурами со сложно взаимосвязами, как по данным так и по времени сушествования.
Про другие языки не скажу, но все проблемы, что Вы описали, в Ruby решены достаточно элегантно:
http://svn.ruby-lang.org/repos/ruby/trunk/README.EXT
К примеру, интеграция языка класса того же Руби с Xlib представляют собой совсем не такую тривиальную задачу что бы от нее можно было отмахиваться как от не заслуживающей внимания.
Нашёл несколько не очень свежих проектов на эту тему:
http://www.moriq.com/ruby/xlib/index.html
http://ruby-xlib-wrap.sourceforge.net/
Т.е задача решаема. Можете ещё посмотреть на ruby-gnome2 - http://ruby-gnome2.sourceforge.jp
no subject
Date: 2007-04-10 11:31 am (UTC)no subject
Date: 2007-04-10 10:22 am (UTC)Если С++ так неэффективен, пусть мужик откроет свою фирму, программирует в ней на языке своей мечты, своей эффективностью забьет всех остальных, инвестирует свою огромную прибыль в пере-зомбирование людей ... зачем сопли жевать на своей страничке ?!
no subject
Date: 2007-04-10 10:43 am (UTC)а зачем вообще переписывать старый и работающий софт на чём-либо.
по моему опыту (а я не настолько молод и глуп, чтобы иметь какие-либо иллюзии по поводу универсальности своего опыта, но тем не менее), "миграция" работающих проектов с C на кресты, к примеру, ничем хорошим не кончается. потому что в какой-то момент один из ведущих программистов прочитывает книшку про паттерны и наступает кромешный пиздец, в котором больше никто и никогда не разберётся.
no subject
Date: 2007-04-10 10:54 am (UTC)Как известно, от любви сходит с ума не тот чья любовь сильнее, а тот чья психика и без того расшатана.
Так и с дизайн паттернами,
Кстати разрушительная сила шаблонов дизайна, сколько я понимаю, мало зависит от языка программирования.
no subject
Date: 2007-04-10 10:56 am (UTC)это в общем верно, но большинство тех шаблонов в некоторых языках просто нафиг не нужно.
no subject
Date: 2007-04-10 04:06 pm (UTC)no subject
Date: 2007-04-10 04:02 pm (UTC)1. C есть действительно _везде_. C++ - по крайней мере качественный - не везде, насколько я знаю.
2. C гораздо более предсказуем - т.е. по коду на C, если не злоупотреблять препроцессором (который вообще-то совершенно другой язык) можно достаточно легко предсказать, что будет делать процессор. На C++ это труднее.
3. Соответственно, на C++ легче создать код, который будет делать страшные глупости.
4. Оттуда же в C++ гораздо больше магии - т.е. труднее знать, как именно поведет себя данный кусок кода.
5. C++ банально сложнее - концептуально. Что сильно мешает многим перейти с C на C++ - формально они переходят, а на самом деле так на C и пишут, только что синтаксис другой. Что в сочетании с предыдущими пунктами и в применении к системному программированию может приводить в довольно неприятным результатам, когда система тормозит, жрет память и никто не понимает, почему.