Я читал, и даже применял. Из третьего тома содрал сбалансированное дерево поиска (которое, кстати, потом долго мне служило верой и правдой в виде сишной библиотечки), из второго — генератор случайных чисел, тоже очень надо было. И, кстати, в этом же томе очень интересные философские рассуждения о природе случайности, очень советую.
Не написавший, а пишущий. В этом нет ничего удивительного. Так же зачастую мы начинаем писать программу на языке, которого не знаем. К тому же Эккель, как человек, написавший «Философию Java» вполне достоин доверия.
Да, я читал, но мне что-то не понравилось. Он и сам признается, что Питон пока не очень хорошо знает. По Яве книжку замечательно написал, слов нет. Будем ждать то же самое по Питону.
Ну, давайте сравним. Там цена $9.50, т. е. примерно 250 рублей, у вас 449.
Итак, что же мы имеем за эту минимальную цену?
Диск: у вас 3Гб, там 10Гб
Сайты: у вас 2, там неограничено
Тестовый период: у вас семь дней, там 60 дней
Базы данных: у вас 2, там неограничено
Трафик: у вас неограничен, там 600Гб (что в общем-то вполне достаточно для большинства сайтов).
Память приложений: там четко 80Мб, вы говорите что-то невнятное.
Прибавьте к тому, что по цене меньшей чем у вас (14.50 против 18 баксов) диск 20Гб, трафик 1200Гб, память приложений 120Мб.
Плюс там такие возможности, кот. у вас, вроде бы, вообще нет нет, типа возможности компиляции и установки любых программ, что для не-нативных питоновских библиотек жизненно необходимо. Ну и размещение данных на одном из крупнейших дата-центров в Кремниевой долине.
Дороговато, в сравнении с импортными хостингами. Сравните, например, с webfaction.com. За что платить-то? Неужели только за русский язык техподдержки? Тем паче, что с российским суппортом я уже знаком, спасибо. Конечно, конечно, у вас совсем не так будет.
— Считаю, что я достаточно вежлив. Тем не менее, сомневаюсь, что он прочитал эту книжку, либо не умеет делать выводов. Все свойства языка там достаточно обоснованы. Например, он с самого начала разрабатывался, чтобы быть совместимым с миллионами строк уже написанного кода.
— Разумеется, я не имел в виду эффективность разработки. Хотя упомянутая выше совместимость со старым кодом позволяет в какой-то степени решать и эту задачу.
При том что есть множество языков, облегчающих разработку (здесь и мой любимец — Python), существуют (и всегда будут существовать) области и задачи, где важна и даже критична эффективность (по скорости, памяти и другим ресурсам). В конце концов, у вас же нет дома топовых промышленных серверов. Или есть? Делать апгрейд каждые полгода у меня, например, нет средств. И в телефон Core 2 Quad с даже пассивным охлаждением никак не засунешь, а как хотелось бы иметь там нормальную IP-телефонию и GPS навигатор.
— Про Haskel, Ocaml и лисп мне не говорите. На некоторых задачах они действительно удобнее, но до универсальности C++ им далеко. Посмотрите, хотя бы, как в ФП решается проблема ввода-вывода, это же ужас! Вообще я на ФП-языки смотрю с надеждой, что в них удастся, наконец достичь оптимального сочетания универсальности, эффективности и простоты, но пока это направление в зачаточном состоянии.
Общий вывод из дискуссии: разработать универсально гибкий, эффективный и одновременно простой язык — очень сложная задача, которая пока она не решена, и будет ли решена — неизвестно. А пока давайте будем уважать и те языки, которые решают проблему человеческого ресурса, и те, которые решают проблему ресурса машинного.
У С++ есть четкая философия, почитайте хотя бы Страуструпа «Дизайн и эволюция С++» (знаю, не читали и читать не будете).
Java — ни в коем случае не пример для сравнения с C++, который по эффективности пока недостижим. Покажите мне язык, который по эффективности был сравним с С++ и имел бы существенно меньше недостатков? Что касается final в Java, я честно говоря не думаю, что он в реализации чем-то отличается от не-virtual в С++. Это такой же метод класса, а не объекта. Согласен, легче ошибиться не написав virtual, чем зря написав final, хотя это дело привычки, как == и =. Если же вы примете во внимание заточенность С++ под быстродействие, вы поймете, почему было сделано именно так.
Конструкторы в паре с деструкторами — это способ инициализации/разрушения объектов со своей философией. Тот способ, который предлагает Java тоже не лишен недостатков (взять хотя бы проблемы с освобождением ресурсов не-памяти).
А StyleGuide — вынужденная мера, поскольку настоящих спецов по C++ — единицы, остальные только думают, что его знают, поэтому городят на нем черт знает что и поругивают его от беспомощности.
Я думал, здесь не дети собрались. Если я ошибаюсь в этом, то вы конечно правы. А если здесь взрослые думающие люди, то рассказ о полиморфизме в обязательном контексте ООП вводит их в заблуждение.
Что касается C++ — вы неправильно понимаете его философию. Шаблоны дают высокую эффективность в сочетании с невероятной гибкостью и контролем типов времени компиляции. Именно ради этой высокоуровневой эффективности C++ до сих пор жив, и не собирается уступать место С#/Java, у которых совсем другие задачи. Вместе с тем шаблоны прекрасно дополняют механизмы наследования и виртуальных функций, как это лет 9 назад описал в своей замечательной книге Александреску. Если вам не нужна эффективность, или просто не хватает… чего-то… чтобы разобраться в сложности C++ — это не повод говорить об его убогости.
И не надо так агрессивно реагировать на критику, что вы все здесь на хабре какие-то неуверенные в себе, как подростки. Как напишу что-нибудь кроме хвалебного отзыва, сразу карма вниз летит. Мне наплевать на нее конечно, но как-то несерьезно это.
Вы совершаете обычную ошибку, привязывая понятие полиморфизма к ООП. Почитайте хотя бы английскую википедию. Там вы увидите, что определение полиморфизма очень простое: это свойство языка программирования, при котором один и тот же кусок кода может быть выполнен для переменных разных типов. Классический пример не объектно-ориентированного полиморфизма, например, в C++ — шаблоны и перегрузка функций (и операторов).
Браво! Это и есть ваш уровень аргументации? О чем тут еще говорить? Статейку вашу обязательно почитаю! В распечатанном виде с последующим использованием по прямому назначению :)
референс = ссылка
инстанс = экземпляр
актуальный = действительный
Итак, что же мы имеем за эту минимальную цену?
Диск: у вас 3Гб, там 10Гб
Сайты: у вас 2, там неограничено
Тестовый период: у вас семь дней, там 60 дней
Базы данных: у вас 2, там неограничено
Трафик: у вас неограничен, там 600Гб (что в общем-то вполне достаточно для большинства сайтов).
Память приложений: там четко 80Мб, вы говорите что-то невнятное.
Прибавьте к тому, что по цене меньшей чем у вас (14.50 против 18 баксов) диск 20Гб, трафик 1200Гб, память приложений 120Мб.
Плюс там такие возможности, кот. у вас, вроде бы, вообще нет нет, типа возможности компиляции и установки любых программ, что для не-нативных питоновских библиотек жизненно необходимо. Ну и размещение данных на одном из крупнейших дата-центров в Кремниевой долине.
Я разницу вижу. А вы?
— Разумеется, я не имел в виду эффективность разработки. Хотя упомянутая выше совместимость со старым кодом позволяет в какой-то степени решать и эту задачу.
При том что есть множество языков, облегчающих разработку (здесь и мой любимец — Python), существуют (и всегда будут существовать) области и задачи, где важна и даже критична эффективность (по скорости, памяти и другим ресурсам). В конце концов, у вас же нет дома топовых промышленных серверов. Или есть? Делать апгрейд каждые полгода у меня, например, нет средств. И в телефон Core 2 Quad с даже пассивным охлаждением никак не засунешь, а как хотелось бы иметь там нормальную IP-телефонию и GPS навигатор.
— Про Haskel, Ocaml и лисп мне не говорите. На некоторых задачах они действительно удобнее, но до универсальности C++ им далеко. Посмотрите, хотя бы, как в ФП решается проблема ввода-вывода, это же ужас! Вообще я на ФП-языки смотрю с надеждой, что в них удастся, наконец достичь оптимального сочетания универсальности, эффективности и простоты, но пока это направление в зачаточном состоянии.
Общий вывод из дискуссии: разработать универсально гибкий, эффективный и одновременно простой язык — очень сложная задача, которая пока она не решена, и будет ли решена — неизвестно. А пока давайте будем уважать и те языки, которые решают проблему человеческого ресурса, и те, которые решают проблему ресурса машинного.
Java — ни в коем случае не пример для сравнения с C++, который по эффективности пока недостижим. Покажите мне язык, который по эффективности был сравним с С++ и имел бы существенно меньше недостатков? Что касается final в Java, я честно говоря не думаю, что он в реализации чем-то отличается от не-virtual в С++. Это такой же метод класса, а не объекта. Согласен, легче ошибиться не написав virtual, чем зря написав final, хотя это дело привычки, как == и =. Если же вы примете во внимание заточенность С++ под быстродействие, вы поймете, почему было сделано именно так.
Конструкторы в паре с деструкторами — это способ инициализации/разрушения объектов со своей философией. Тот способ, который предлагает Java тоже не лишен недостатков (взять хотя бы проблемы с освобождением ресурсов не-памяти).
А StyleGuide — вынужденная мера, поскольку настоящих спецов по C++ — единицы, остальные только думают, что его знают, поэтому городят на нем черт знает что и поругивают его от беспомощности.
Что касается C++ — вы неправильно понимаете его философию. Шаблоны дают высокую эффективность в сочетании с невероятной гибкостью и контролем типов времени компиляции. Именно ради этой высокоуровневой эффективности C++ до сих пор жив, и не собирается уступать место С#/Java, у которых совсем другие задачи. Вместе с тем шаблоны прекрасно дополняют механизмы наследования и виртуальных функций, как это лет 9 назад описал в своей замечательной книге Александреску. Если вам не нужна эффективность, или просто не хватает… чего-то… чтобы разобраться в сложности C++ — это не повод говорить об его убогости.
И не надо так агрессивно реагировать на критику, что вы все здесь на хабре какие-то неуверенные в себе, как подростки. Как напишу что-нибудь кроме хвалебного отзыва, сразу карма вниз летит. Мне наплевать на нее конечно, но как-то несерьезно это.