Комментарии 53
После 13-и лет (!) ковыряния в одном языке (PHP тут не при чем, хотя и показатель) человек вдруг увидел другой мир. Мои поздравления, теперь можно развиваться дальше.
В опроснике не хватает самого главного пункта — «Я изучаю новое постоянно. Без этого я мертв, как ИТ профессионал.»
Именно, не «модные штуки», а просто «жизненно важное».
В опроснике не хватает самого главного пункта — «Я изучаю новое постоянно. Без этого я мертв, как ИТ профессионал.»
Именно, не «модные штуки», а просто «жизненно важное».
Вроде статья почти без картинок, а вы всё равно на что-то отвлеклись.
В начале:
>Я всегда изучал новые инструменты (будь это демоны, утилиты, библиотеки, языки или сервисы)
И в конце:
>Выходить из своей зоны комфорта — изучая новый язык — ключ к объединению всех наших технологий; именно воспринимая и обсуждая идеи с другими сообществами, мы улучшаем свой навык решения проблем — с использованием лучших решений, и лучших инструментов. Так что выбирайтесь на встречи или конференции, слушайте подкасты и читайте статьи про другие языки, даже если вы не заинтересованы в использовании этих языков.
В начале:
>Я всегда изучал новые инструменты (будь это демоны, утилиты, библиотеки, языки или сервисы)
И в конце:
>Выходить из своей зоны комфорта — изучая новый язык — ключ к объединению всех наших технологий; именно воспринимая и обсуждая идеи с другими сообществами, мы улучшаем свой навык решения проблем — с использованием лучших решений, и лучших инструментов. Так что выбирайтесь на встречи или конференции, слушайте подкасты и читайте статьи про другие языки, даже если вы не заинтересованы в использовании этих языков.
Ну, если быть чуть более точным, во втором абзаце автор упоминает, что после пары лет ковыряния PHP он решил открыть для себя дивный новый мир с ColdFusion, Java, Javascript, etc. Другое дело, что PHP является его основным языком последние 13 лет.
Автор пишет «Все таки, тринадцать лет с языком — это долгий срок». И судя по статье ознакомиться, например, с экосистемой Java достаточно глубоко ему не удалось.
Нет, я ничего не имею против откровений «смотрите, при описании класса выполняется код с self», понимание это очень даже здорово и правильно. Даже если оно случается после стольких лет.
Просто на мой субъективный взгляд, те принципы, которые используются в большинстве популярных языков программирования, не плохо было бы осваивать в первые год-два актавной работы. Иначе это анабиоз какой-то.
Нет, я ничего не имею против откровений «смотрите, при описании класса выполняется код с self», понимание это очень даже здорово и правильно. Даже если оно случается после стольких лет.
Просто на мой субъективный взгляд, те принципы, которые используются в большинстве популярных языков программирования, не плохо было бы осваивать в первые год-два актавной работы. Иначе это анабиоз какой-то.
В точку! Но изучение чего-то нового без конкретной задачи по крайней мере для меня тяжеловато. Ну прочитаешь умную книжку, а без практики всё забудется. Стараюсь сначала придумать что-нибудь интересненькое, а потом это реализовать на новом для себя языке/фреймворке, прям как автор. А потом ещё выложить на github, чтоб можно было подсматривать.
Согласен с вами в вопросе работы с конкретными задачами. Лично мне часто становиться лень придумывать себе задания (хотя у меня всегда есть пара любимых алгоритмов), а познакомиться с языком или технологией очень часто хочеться здесь и сейчас.
Для себя нашел, пусть и не лучший вариант для изучения языка, но отличный способ знакомства и понимания его идеологии, а так же возможности небольшой практический опыт получить, не устанавливая кучу левого софта на машину или несколько разных машин, если пытаться заниматься и дома и на работе и еще в куче мест — тут хоть и не большой выбор технологий, но для некоторого знакомства вполне хватает. Думаю подобных проектов десятки, мне еще по душе эта площадка, но она платная.
Для себя нашел, пусть и не лучший вариант для изучения языка, но отличный способ знакомства и понимания его идеологии, а так же возможности небольшой практический опыт получить, не устанавливая кучу левого софта на машину или несколько разных машин, если пытаться заниматься и дома и на работе и еще в куче мест — тут хоть и не большой выбор технологий, но для некоторого знакомства вполне хватает. Думаю подобных проектов десятки, мне еще по душе эта площадка, но она платная.
После 13-и лет (!) ковыряния в одном языке (PHP тут не при чем, хотя и показатель) человек вдруг увидел другой мир. Мои поздравления, теперь можно развиваться дальше.
Боюсь представить, как вы оцените первоклассных специалистов, которые 20 лет на с++ пишут. Скажете, что они не развиваются?
За 13 лет php прошёл долгий путь развития, и всё сообщество вслед за ним.
99% опытных пхпшников серьёзно пробовали и питон, и руби. И у всех, кого знаю, реакция как у автора статьи: «Означает ли это, что я перехожу на Ruby/Rails? Вряд ли. PHP все еще мой любимчик»
От статьи двоякое ощущение: с одной стороны, общая мысль правильная, изучайте то, что есть вокруг, не зацикливайтесь на одном инструменте.
С другой, примеры выбранные автором ниразу не мотивируют:
— Выбор РоР для проекта не обоснован и не раскрывает преимуществ РоР перед PHP.
— Пример кода сбивает с толку, т.к. совершенно нечитабельно то, что происходит (с точки зрения синтаксиса PHPшника). Возможность писать не так как обычно могла бы быть плюсом к ФП, но не здесь.
Радость от использования готовых гемов — аналогично когда человек вешает джумлу, у него получается сделать стандартные штуки типа регистрации или отправки сообщения и он со штанами полными радости кричит: «о дааа, теперь я знаю похапэ и могу о нем рассказывать неофитам»!
Лично я чувствую дискомфорт, когда я не понимаю как что-то работает. Потому что когда понадобится сделать что-то нестандартное, всё джедайство сразу сдуется.
С другой, примеры выбранные автором ниразу не мотивируют:
— Выбор РоР для проекта не обоснован и не раскрывает преимуществ РоР перед PHP.
— Пример кода сбивает с толку, т.к. совершенно нечитабельно то, что происходит (с точки зрения синтаксиса PHPшника). Возможность писать не так как обычно могла бы быть плюсом к ФП, но не здесь.
даже не зная как реализовать загрузку файлов в Ruby/Rails, я смог решить поставленную задачу
Радость от использования готовых гемов — аналогично когда человек вешает джумлу, у него получается сделать стандартные штуки типа регистрации или отправки сообщения и он со штанами полными радости кричит: «о дааа, теперь я знаю похапэ и могу о нем рассказывать неофитам»!
Лично я чувствую дискомфорт, когда я не понимаю как что-то работает. Потому что когда понадобится сделать что-то нестандартное, всё джедайство сразу сдуется.
RoR привлекает как раз читабельностью, ИМХО. Примеры очевидны, для англоязычной аудитории. Чем плох нативный язык?
Оратор < Запись:: Базовая
принадлежит: пользователю
имеет_много: предположений
хеши? Они не плохие в руби.
Много сахара. Rails way действительно надо понимать, а руби знать — разве с другими языками\фреймворками по другому?
>> РоР перед PHP
Ror c фреймворком на php лучше сравнивать, а php — c ruby.
Оратор < Запись:: Базовая
принадлежит: пользователю
имеет_много: предположений
хеши? Они не плохие в руби.
Много сахара. Rails way действительно надо понимать, а руби знать — разве с другими языками\фреймворками по другому?
>> РоР перед PHP
Ror c фреймворком на php лучше сравнивать, а php — c ruby.
У меня неплохой английский — не стоит из руби делать 1С ;) Про непонятность говорится в тексте:
Сахара действительно много, и это неплохо. Литературная читабельность на высоте, но непонятно, что происходит: где объявляется, что вызывается и почему вызвается не там, где привычно это видеть (внутри конструктора например). Просто это не тот пример синтаксиса, который я хотел бы увидеть. Плюс обычно такие примеры снабжаются комментариями построчно. Но цель автора была произвести вау-эффект на туземцев. Удалось, ага.
Да, в целом, это более корректная постановка вопроса.
Но вопрос сейчас не именно в сравнении, а почему автор решил делать этот проект на рельсах. Должен быть повод для выбора именно этой технологии, какие то явные плюсы, которые позволяют сделать что-то лучше, быстрее, правильнее.
Странно переходить с PHP на Ruby и писать потом (условно) hello-world-блог, т.к. преимуществ явных от этого не получится.
Что тут странно, так это то, что эти методы (которые, вообще говоря, наследованы) вызываются в процессе определения класса.
Сахара действительно много, и это неплохо. Литературная читабельность на высоте, но непонятно, что происходит: где объявляется, что вызывается и почему вызвается не там, где привычно это видеть (внутри конструктора например). Просто это не тот пример синтаксиса, который я хотел бы увидеть. Плюс обычно такие примеры снабжаются комментариями построчно. Но цель автора была произвести вау-эффект на туземцев. Удалось, ага.
Ror c фреймворком на php лучше сравнивать, а php — c ruby.
Да, в целом, это более корректная постановка вопроса.
Но вопрос сейчас не именно в сравнении, а почему автор решил делать этот проект на рельсах. Должен быть повод для выбора именно этой технологии, какие то явные плюсы, которые позволяют сделать что-то лучше, быстрее, правильнее.
Странно переходить с PHP на Ruby и писать потом (условно) hello-world-блог, т.к. преимуществ явных от этого не получится.
> где объявляется
примерно в ActiveRecord::Base от которого наследуемся.
> что вызывается
вызывается метод, что он делает есть в документации. там же и исходники метода.
> почему вызвается не там, где привычно это видеть
почему не там? в руби можно вызывать методы где угодно. можно было бы сделать и в конструкторе, но зачем если так проще?
примерно в ActiveRecord::Base от которого наследуемся.
> что вызывается
вызывается метод, что он делает есть в документации. там же и исходники метода.
> почему вызвается не там, где привычно это видеть
почему не там? в руби можно вызывать методы где угодно. можно было бы сделать и в конструкторе, но зачем если так проще?
Я когда с PHP перешел на Python (после года активного программирования на первом) — был поражен открывшимся возможностями нового для меня языка, вот честно, наповал поражен! Мне кажется, нельзя просто взять и выбрать для себя язык на все времена. Всегда есть вариант, что Вы найдете то, что Вам нужно там, где даже не думали искать.
А можно топ список вещей, которыми были поражены? :) Я понимаю восторг от перехода на компилируемые, строготипизированные языки, языки с другой парадигмой или экзотическим синтаксисом, но разницу между python и php я не заметил (конечно же, не считая продуманности и лучшей архитектуры первого).
О, мой Бог! Конечно! Первое, что мне очень понравилось — это очаровательный синтаксис. Он такой прекрасный, что может даже сойти за псевдокод (чего только стоят инлайновые конструкции). Потом мне очень понравилась объектная система, наследоваться стало проще, а само наследование оказалось прозрачным. Затем следует прекрасно расширяемый полиморфизм. Python задуман, чтобы отвечать принципу Утиной Типизации. Следом идет наличие байт-кода (без комментариев). Потом шествует огромное комьюнити с широкой документацией любых модулей. Далее идет конечно модульность (опять же без комментариев). Да много там всего… Повторюсь, я год писал на пыхе — ну вообще она ни в какие сравнения не идет с пайтоном. Простите меня, за такой холивар.
Не стал бы я относить утиную типизацию к плюсам языка.
>> Потом мне очень понравилась объектная система, наследоваться стало проще, а само наследование оказалось прозрачным
Я может конечно Питон не так хорошо помню, но чем же, скажите на милось, различаются объектные системы пхп и питона?
>> Затем следует прекрасно расширяемый полиморфизм.
Подробнее можете? Я не очень понимаю, что вы этим хотели сказать.
>> Следом идет наличие байт-кода (без комментариев).
Это вы про *.pyc, которые после первого запуска формируются? По секрету, в рхр тоже есть байткод, но для его хэширования нужно использовать отдельные модули: APC, eAccelerator
>> принципу Утиной Типизации
Самое ужасное, как мне кажется, что может быть, это когда два объекта одного класса имеют разный набор методов и пр. Удобно? Вполне возможно. Поддерживаемо через 6-12 месяцев? Сомневаюсь.
>> Потом шествует огромное комьюнити с широкой документацией любых модулей.
Ага, а PHP со своей докой и бОльшим сообществом нервно курит в сторонке ;)
Я может конечно Питон не так хорошо помню, но чем же, скажите на милось, различаются объектные системы пхп и питона?
>> Затем следует прекрасно расширяемый полиморфизм.
Подробнее можете? Я не очень понимаю, что вы этим хотели сказать.
>> Следом идет наличие байт-кода (без комментариев).
Это вы про *.pyc, которые после первого запуска формируются? По секрету, в рхр тоже есть байткод, но для его хэширования нужно использовать отдельные модули: APC, eAccelerator
>> принципу Утиной Типизации
Самое ужасное, как мне кажется, что может быть, это когда два объекта одного класса имеют разный набор методов и пр. Удобно? Вполне возможно. Поддерживаемо через 6-12 месяцев? Сомневаюсь.
>> Потом шествует огромное комьюнити с широкой документацией любых модулей.
Ага, а PHP со своей докой и бОльшим сообществом нервно курит в сторонке ;)
>>принципу Утиной Типизации
Самое ужасное, как мне кажется, что может быть, это когда два объекта одного класса имеют разный набор методов и пр. Удобно? Вполне возможно. Поддерживаемо через 6-12 месяцев? Сомневаюсь.
Непонятно причем здесь два объекта одного класса и разный набор методов. Та утиная типизация, о которой я знаю, выражается в следующем предложении: "Если объект ходит как утка, и крякает как утка, значит он — утка."
Т.е. мы судим по объекту на основании поведения объекта (поддерживаемым методам), а не по его генеалогическому древу (наследование класса/реализация интерфейса). Т.е. если у объекта есть метод
[], мы можем работать с ним, как с массивом, хотя это совсем необязательно массив. В целом утиная типизация это скорее соглашение, и следовать этому соглашению можно как при написании кода на PHP, так и на Python или Ruby. Другое дело, что одни языки больше располагают к этому, а другие — меньше.«Не очень хорошо помню»? т.е. Вы знали Питон? и потом начали пыхать? Вот Вам отличия модели Питона ссылка. Ваши доводы абсолютно профанские. Чего только стоит то, что на Пайтоне можно реализовать любую системную программу, параллельные вычисления, веб. А на пыхе что? Только сайты(ики). На счет байт-кода в пхп — это пляски с бубном. А пляски — ничего хорошего, по сравнению с нативной поддержкой. На счет поддержки через полгода: нет ничего лучше, чем не задумываться какого типа должны быть аргументы — просто итератор какой-то, например. Ошибка TypeError теперь будет свидетельствовать о реальном несоответствии типов, а не то что я передал «111» вместо 111(пример такой). А на счет последнего — зрз с его укуренной документацией, непонятным методом обзывания функций и огромным комьюнити школоразработчиков сайтов вот уж и правда курят в стороне. А что курят-то?
В PHP по умолчанию как раз утиная типизация, выражение $obj->method() будет проверять наличие meyhod() непосредственно при исполнении и не требует объявления $obj как экземпляра какого-то класса или реализации интерфейса — есть метод, значит можем его вызвать (а иногда можем и если его нет)… Плюс на уровне синтаксиса поддерживается (не всегда хорошо) поведение «кастомных» объектов как «скаляров» (если объект имплементирует каккой-то из predefined interfaces, то сни можно обращаться как соответствующей сущностью)
Невероятно прекрасная на фоне PHP модель данных.
Шикарная на фоне PHP модульность.
Нормальные замыкания, декораторы, элементы ФП.
Классы как first class object, метаклассы, дескрипторы.
Человеческий синтаксис в конце концов.
По-моему, этого уже достаточно, чтобы один раз попробовав Python пожелать никогда не возвращаться к PHP.
Шикарная на фоне PHP модульность.
Нормальные замыкания, декораторы, элементы ФП.
Классы как first class object, метаклассы, дескрипторы.
Человеческий синтаксис в конце концов.
По-моему, этого уже достаточно, чтобы один раз попробовав Python пожелать никогда не возвращаться к PHP.
Какие же замыкания тогда в PHP если вам python этим понравился?
А в тот момент их не было вообще. А в нынешних я считаю костылем указание замыкаемых переменных. Кстати, а ПХП переменные затягивает в замыкание по ссылке или по значению?
Да, замыкания в Питоне не идеал, но это было мое первое с ними знакомство — простительно, думаю.
Да, замыкания в Питоне не идеал, но это было мое первое с ними знакомство — простительно, думаю.
Ну, костыль не костыль, но Вы уверены, что Вам всегда нужно таскать в замыкание весь контекст? А если нужно, то возможно Вы что-то делаете не так?
Ну, и к тому же, один из пунктов философии Python, если мне не изменяет память — «Явное лучше, чем неявное» ;)
Ну, и к тому же, один из пунктов философии Python, если мне не изменяет память — «Явное лучше, чем неявное» ;)
А вы уверены, что там весь контекст захватывается? Я вот думаю, что только referenced переменные. См. repl.it/Ivl
Кстати, а ПХП переменные затягивает в замыкание по ссылке или по значению?
Как передадите. По умолчанию — по значению. Если с амперсандом — то по ссылке.
НЛО прилетело и опубликовало эту надпись здесь
Не путайте язык с произведением.
НЛО прилетело и опубликовало эту надпись здесь
Да, я сейчас делаю проект на Джанго. У меня нет аргументов в ползу Рельс. У меня вообще нет никакого отношения к рельсам, ибо не знаю их at all. А про язык и произведение нужно понимать в общелитературном ключе.
Немного работал и с тем, и с другим, RoR нравится больше. Но это именно «нравится». Кому-то нравится «магия», а кому-то «явное лучше неявного».
НЛО прилетело и опубликовало эту надпись здесь
Ага ::)
Лол) Ctrl-клик перенесет вас к источнику магии, то бишь к исходникам
На самом деле, это светлая магия.
В джанго всё явно, но многое пришлось делать ручками. Я когда открыл для себя RoR, то прифигел от концепции гемов и легкости их установки и настройки. А после какого-то момента понял, что и магии то нету, а продуманность соглашений и ускорение работы разработчика.
В джанго всё явно, но многое пришлось делать ручками. Я когда открыл для себя RoR, то прифигел от концепции гемов и легкости их установки и настройки. А после какого-то момента понял, что и магии то нету, а продуманность соглашений и ускорение работы разработчика.
Paperclip это конечно гуд, но есть хорошая альтернатива Сarrierwave github.com/jnicklas/carrierwave. S3, Google Storage, кроп изображений + возможность перехода с paperclip.
можно программно определять классы
Так динамический язык же.
Python:
TestClass = type('TestClass', (object,), dict(value = 1, get_value = lambda self: self.value))
print TestClass().get_value()
или
def init(self, value):
self.value = value
String = type('String', (object,), {})
String.__init__ = init
String.reverse = lambda self: self.value[::-1]
print String('Hello, world!').reverse()
del String.reverse # remove method definition
Конечно, следует предпочитать явное определение типа его динамическому аналогу.
Я уверен, что для PHP есть уже готовая библиотека для работы с OAuth (ищем на гитхабе).
Код в примере немногословен, да, но я тоже самое могу сделать на PHP. Лучше бы была показана реализация любой стандартной вещи, например CRUD.
В статье вижу только восторг автора, каких-то ключевых особенностей Ruby/RoR в статье я не заметил (кроме синтаксиса).
Код в примере немногословен, да, но я тоже самое могу сделать на PHP. Лучше бы была показана реализация любой стандартной вещи, например CRUD.
В статье вижу только восторг автора, каких-то ключевых особенностей Ruby/RoR в статье я не заметил (кроме синтаксиса).
Я знаю PHP. Не просто знаю, а действительно знаю. Не только синтаксис, или идиомы и особенности, но еще и почему — почему что-то работает именно так как оно работает, понимаете, под капотом.
Почему str_split, но strlen и parse_str?
Ключевая мысль статьи — у ruby много правильных гемов. Если PHP обладал бы единственным фреймворком (я знаю, что у ruby он не один, но 99% используют RoR) на который все ориентировались и писали бы библиотеки под него, да еще и стандартизировали их, то в чем разница? Представьте если всё PHP сообщество вдруг пересядет скажем на yii2 и начнет писать extensions только под него, что из этого выйдет, у кого х** окажется длинней, сайты быстрей, а разработка короче?
хорошо сказано)
Вы забываете о том, что гемы в руби можно использовать не только с рельсами, так что ваша пэхепешная аналогия здесь не совсем к месту. Я могу писать консольную утилиту на руби и спокойно подключить к ней пару-тройку необходимых гемов. Сможете ли вы к стороннему PHP-скрипту подключить библиотеку от yii2 даже если их будет миллион?
Также, Вы очень сильно заблуждаетесь относительно процентов использования RoR в применении к руби-программистам. Для некоторых задач используется Sinatra и ему подобные фреймворки, а для других – (omg, кто бы мог подумать!) вообще не используются веб-фреймворки.
У Вас, как и у многих людей в этом треде, проблема с пониманием того, что такое руби и что такое рельсы. Я не упрекаю Вас в этом, прошу лишь разобраться в вопросе более подробно, если хотите давать кому-нибудь объективные рекомендации по этому поводу.
Также, Вы очень сильно заблуждаетесь относительно процентов использования RoR в применении к руби-программистам. Для некоторых задач используется Sinatra и ему подобные фреймворки, а для других – (omg, кто бы мог подумать!) вообще не используются веб-фреймворки.
У Вас, как и у многих людей в этом треде, проблема с пониманием того, что такое руби и что такое рельсы. Я не упрекаю Вас в этом, прошу лишь разобраться в вопросе более подробно, если хотите давать кому-нибудь объективные рекомендации по этому поводу.
Сможете ли вы к стороннему PHP-скрипту подключить библиотеку от yii2 даже если их будет миллион?
Насчёт Yii не скажу, но PEAR существует наверное столько же сколько сам PHP. Плюс за последнее время набирает популярность composer (более близкий по идеологии к gem) и там не составит труда подключить что угодно к чему угодно. Если кто-то позаботился о пакете в паблике, то и зависимости разрулятся. Если нет то зависимости нужно будет прописать ручками если в, например, гит-репе нужный модуль без зависимостей.
И с чего вы взяли, что у меня проблемы с пониманием что такое ruby и рельсы? Вот у вас точно проблемы с пониманием PHP, но вам это не мешает давать «кому-нибудь объективные рекомендации». У ruby так же немало гемов, которые ориентированы исключительно на рельсы, а другие независимые — у PHP так же, и большая проблема PHP это огромнейшее кол-во разрозненных решений, которые между собой могут не интегрироваться, а есть такие которые могут интегрироваться почти всегда (вам выше уже ответили). И omg, кто бы мог подумать, что у PHP огромное кол-во проектов, которые не используют фрейморки. Сейчас руби быстро набирает популярность и в его сообществе так же появится большая каша из кода несовместимого между собой — подождите и у вас все будет.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Изучая Rails (ну, и Ruby)