Я еще ни разу не видел Линукса с приличными шрифтами и удобными графическими приложениями. Все, что делается из консоли — божественно. Многое, что за её пределами — дерьмо (начиная со шрифтов, которые полнейшее дерьмо пока у меня экран не 200 ppi, в всего 98). Я работаю на макбуке и через ssh управляю дебиановскими серверами. Вполне доволен таким симбиозом.
Такие извращения мне пока не нужны. Нормального ECMAScript достаточно, в общем-то. А сиплюсы нужны для Зашибенных Штук. Типа Half-Life =) Лишь бы был доступ не только к API флешплеера, но и к аппаратным ускорителям.
"Теперь дело за пользователем. Он определяет рабочие области: область заголовка, область текста, область полосы навигации и т.д. [...]
Таким образом не пользователю придется подстраиваться под возможности системы управления, а наоборот, система управления «поймет», что хочет от нее пользователь."
Как мне нравятся эти разговоры про "статическая типизация" => "features" =) Эта стрелочка существует лишь из-за того, что кому-то лень чуть-чуть больше подумать и сделать такую же для динамического языка. Потому что есть, как минимум, соглашения, согласно которым 99% кода анализируются машиной без проблем.
Во-вторых, все крутые штуки, какие придуманы в IDEA, — это жуткая rocket science, отвлеченная от существа решаемой задачи. Я программировал на Си, плюсах, джаве, руби в простом текстовом редакторе SciTE с подсветкой лексики (сейчас - TextMate). Рефакторинг делал руками и лишь иногда нужно было сделать автозамену по нескольким файлам с регэкспами. Но необходимости в дотошных пунктах типа replace && with || никогда не было.
Не говоря уже о том, что в рубийном приложении кода меньше на порядок, что этот самый ручной рефакторинг существенно облегчает.
Disclaimer: идеальный интерфейс к структурированному текстовому процессору по моему мнению — Wolfram Mathematica, а не Latex-системы, MS Word, Apple Pages, MatLab или Mathcad. Если вы считаете по-другому, то можно и не спорить: это дело личной гигиены, чем себе мозги забивать =)
1) У меня есть код, который нужно было написать с нуля и который совершенно точно на руби пишется за 10 минут в 50 строк, а на Си - несколько часов и и длинно. Я его написал на руби чтобы было с чем работать до поры до времени, да и скорость не криминально низкая для тестов. Но парсер XML я писать руками не буду. И если выбирать между тем, какую либу прикручивать, я лучше потрачу 10 минут на то, чтоб написать минимально необходимый интерфейс к сишной либе, чем брать чисто руби-реализацию. Потому что тормоза буду чувствовать уже на тестах.
2) На распространенность мне вообще-то наплевать =) Совета спросить есть у кого, а сама связка вполне работоспособна. Зачем мне коммунити, если и так классно работает?
3) Про тесты это вы хорошо мысль разъяснили. Согласен с такой мотивацией, хотя это уже не чисто инженерная проблема (но тоже важная).
> ну то есть конечно не совсем без проблем - но работает
Я ни за что бы не стал пользоваться xml-парсером на чистом руби, если его элементарно можно прикрутить на Си без ущерба удобству разработки и деплоя. Если бы речь шла о ПХП, куда что-то кустомное прикрутить - нужно компилятор пересобирать, то я бы еще пять раз подумал.
Отсюда вывод: Руби на MRI - это не просто руби, а руби+Си, что существенно изменяет мое мнение о тестах. Возможности рубина отличаются от пхп в большей степени качественно, а не количественно, поэтому объективные численные тесты провести будет очень тяжело. Да и нужно ли? У нас например, те, кто любят пхп пишет на пхп, а кто любит руби - пишет на руби. Конечный результат все равно доставляет удовольствие всей команде и юзерам. А как к нему прийти - у каждого свой подход.
Если оба языка не годятся для определенной задачи (обход Б-дерева, например), но один делает ее чуть быстрее — это не показатель. Показателей, вообще-то, два. Первый: один из языков можно использовать для задачи Икс, а второй - нельзя. Тут относительные отличия не так важны. Второй показатель: оба языка годятся для задачи Игрек и тут важны относительные значения.
Сравнивать руби и пхп имеет смысл, например, на пересечении/объединении массивов. Т.к. на больших нагрузках на сайт (когда серверов БД 5 штук, а бекендов с монгрелами/апачами - 100) иногда имеет смысл часть операций над данными вынести из БД в бекенды. Скажем, не делать LEFT JOIN, а двумя запросами получить списки айдишников и пересечь их в скрипте. Потому что бекендов в 20 раз больше, чем БД. А вот бинарные деревья пока БД обходит быстрее (в тех случаях, когда они нужны), так что скриптам такой тест не нужен.
" то вызовы будут в C'шной версии идти через таблицу - и скорость будет та же!"
Верно.
"который любители C никогда в жизни не породят - но это не проблема языка..."
— В Руби открытые классы? Как же так?! Мне поломают код мои коллеги, ааа!!
Уточню: для меня Джава-платформа вместо Си — это как винда вместо линукса на сервере. Т.е. что-то работающее и популярное, но со своими правилами, отклоняющимися от классических и повсеместно признанных. Понятно, что те, кто работает с Джавой много и долго, таких проблем не испытывает. Но если это не так, то выпрыгивание из ПХП/Руби в Си, на мой взгляд, более перспективно, чем в Джаву (в плане гибкости).
Про AST все правильно. Далеко не уедешь. Про JVM тоже все правильно. Некоторые считают, что Си++ более медленный, чем Си. Что за бред? Не используйте виртуальные методы и скорость будет как и в Си.
А про Си vs. Асм вообще смешно бывает. Некоторые не в курсе, что Си, грубо говоря, — макросы для Асма: любой си-код можно в уме перевести в машинные коды и убедиться, что на асме в 99% случаев вы написали бы те же самые команды.
medium boobs
large boobs
EXTRA LARGE BOOBS, GOOGLE, PLEEEEASE!!!
Таким образом не пользователю придется подстраиваться под возможности системы управления, а наоборот, система управления «поймет», что хочет от нее пользователь."
Не понял "каким образом" система "поймет".
Во-вторых, все крутые штуки, какие придуманы в IDEA, — это жуткая rocket science, отвлеченная от существа решаемой задачи. Я программировал на Си, плюсах, джаве, руби в простом текстовом редакторе SciTE с подсветкой лексики (сейчас - TextMate). Рефакторинг делал руками и лишь иногда нужно было сделать автозамену по нескольким файлам с регэкспами. Но необходимости в дотошных пунктах типа replace && with || никогда не было.
Не говоря уже о том, что в рубийном приложении кода меньше на порядок, что этот самый ручной рефакторинг существенно облегчает.
Disclaimer: идеальный интерфейс к структурированному текстовому процессору по моему мнению — Wolfram Mathematica, а не Latex-системы, MS Word, Apple Pages, MatLab или Mathcad. Если вы считаете по-другому, то можно и не спорить: это дело личной гигиены, чем себе мозги забивать =)
2) На распространенность мне вообще-то наплевать =) Совета спросить есть у кого, а сама связка вполне работоспособна. Зачем мне коммунити, если и так классно работает?
3) Про тесты это вы хорошо мысль разъяснили. Согласен с такой мотивацией, хотя это уже не чисто инженерная проблема (но тоже важная).
Я ни за что бы не стал пользоваться xml-парсером на чистом руби, если его элементарно можно прикрутить на Си без ущерба удобству разработки и деплоя. Если бы речь шла о ПХП, куда что-то кустомное прикрутить - нужно компилятор пересобирать, то я бы еще пять раз подумал.
Отсюда вывод: Руби на MRI - это не просто руби, а руби+Си, что существенно изменяет мое мнение о тестах. Возможности рубина отличаются от пхп в большей степени качественно, а не количественно, поэтому объективные численные тесты провести будет очень тяжело. Да и нужно ли? У нас например, те, кто любят пхп пишет на пхп, а кто любит руби - пишет на руби. Конечный результат все равно доставляет удовольствие всей команде и юзерам. А как к нему прийти - у каждого свой подход.
Сравнивать руби и пхп имеет смысл, например, на пересечении/объединении массивов. Т.к. на больших нагрузках на сайт (когда серверов БД 5 штук, а бекендов с монгрелами/апачами - 100) иногда имеет смысл часть операций над данными вынести из БД в бекенды. Скажем, не делать LEFT JOIN, а двумя запросами получить списки айдишников и пересечь их в скрипте. Потому что бекендов в 20 раз больше, чем БД. А вот бинарные деревья пока БД обходит быстрее (в тех случаях, когда они нужны), так что скриптам такой тест не нужен.
Верно.
"который любители C никогда в жизни не породят - но это не проблема языка..."
— В Руби открытые классы? Как же так?! Мне поломают код мои коллеги, ааа!!
А про Си vs. Асм вообще смешно бывает. Некоторые не в курсе, что Си, грубо говоря, — макросы для Асма: любой си-код можно в уме перевести в машинные коды и убедиться, что на асме в 99% случаев вы написали бы те же самые команды.