Ruby VS PHP

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

2 года работаю PHP программистом в большой компании. Есть предложение перейти в одну маленькую и перспективную компанию, которая пишет только на Ruby. По уровню ЗП не сильно проигрываю. Но поскольку компания маленькая, то есть возможность большего карьерного роста, чего нету в текущей.
Ruby пока только начинаю изучать. Как язык он мне не очень нравится. Ну не читается для меня код на нем, как на той же джаве даже.
Еще меня смущает, что если перейду на RoR, то выбор вакансий у нас в стране не очень велик. Тоесть, если прийдется в отдаленном будущем искать другую работу, то по сравнению с ПХП, выбор будет у меня мизерный.
Вот хочу взвесить все за и против, чтобы прийнять правильное решение.
Читал на форумах разное типа, что у Руби нет большого будущего.
Вместе с тем читал, что рейт у руби программистов значительно выше, чем у пхпшников.
Кто что думает, господа?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Найкращі коментарі пропустити

Руби — мертворождённый язык, для хипстеров и стартапов, без перспектив в Украине. Вы хипстер, пишущий стартап?

Хотите поднимать сотни бабла на похапэ — учите пхп-фпм, нжинксы, перконы + стек их по, ораклы, no-sql’ы, сфинксы с люценами, зенды\yii\симфони, шаблоны проектирования, методы хранения структур данных, ооп + иные парадигмы, методы оптимизации всего, чего можно наоптимизировать, бенчмаркинг, профайлинг (бд, код, qa), линуксы уровня аппер убунтиум, глубокое понимание работы %RDBMS-name% и пхп, php.net в конце концов штудируйте, там много чего интересного, читайте хабр. За год средней напряженности межушного нерва достигнете высокооплачиваемых высот. Этого хватит со скромностью на $2500, наклеите синиорско-лидские лычки — и на 3к вытянете. Дальше — больше: теория алгоритмов, масштабирование, облака, кластера, репликации, хадупы-редьюсы — и будете красавчиком на расхват у рекрутёров. Для увеличения ЧСВ и привлекательности у забугорных работодателей пройдите сертификацию ZCE — на таких программистов у западных рекрутёров перманентный стояк, вдруг решите покупать трактор?

А с руби будет Ад и Израиль, везущий вас в бездну уныния. По рельсам, да.

Здравствуйте. Меня зовут Вячеслав, мне 22 года и я пхп программист. Я сижу на пхп с 18 лет.

Первый раз я попробовал пхп с другом. Мы сидели, обсуждали веб-технологии и тут он сказал, что недавно пробовал пхп. Он предложил попробовать мне. Поначалу я не согласился, ведь это пхп, я слышал много плохих слухов про него, слышал, что он вызывает зависимость. Но друг настаивал, говорил, что в жизни нужно попробовать все и я сдался. Он предложил бесплатный скрипт, выводящий «Hello world!». Он казался совсем безобидным, но как потом оказалось, я уже не мог остановиться.

Уже очень скоро благодаря пхп я попробовал свою первую cms. Это сейчас я понимаю, насколько опасным был этот шаг, но тогда я ничего не понимал, и мне это нравилось. Я не заметил, как после первой испробованной cms, мне уже захотелось написать свою. Дальше было только хуже. Я уже рискнул попробовать кое что потяжелее. Я решил попробовать свой первый фреймворк. Это было прекрасно. Но это была дорога в никуда.

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

Я попал в этот капкан пхп и теперь не могу самостоятельно избавиться от этого, моя жизнь сломана. Если бы мог вернуться в то время, я бы все исправил, и никогда не купился на эту уловку.

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
вот кстати в соседнее ветке испанец ищет пшп-ников.

так что имело бы смысл пообщаться, в среднем испанец будет платить поболее, чем средний местный аутсоурсер

он не программистов ищет, а технических партнёров. не факт, что вообще платить будут

Всё же, что бы там ниже не писали — руби шняга, а вот пхп реально тянет веб-индустрию к светлому будущему. Как никак, овер трёх четвертей сайтов в мире на нём крутятся, куда там рорам с питонами и точками.

а половину рынка СНГ захватили ВАЗ и ДЕУ ланосы.

они тоже двигают индустрию к светлому будущему?

а половину рынка СНГ захватили ВАЗ и ДЕУ ланосы.
гм. рынок снг и рынок веба , мне кажется у вас аналогия неверна.
вот если бы на вазах и деу ездили бы олигархи — тогда да
я о том, что аргумент, что пхп захватил рынок , - это не аргумент..
по аналогии с авто, каждый продукт (пхп, руби, питон) расчитан на свой сегмент программистов.
с другой стороны, двигают рынок не большинство (средних и ниже среднего) программистов, а двигают индустрию ТОП 5-10% специалистов.

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

а решает тут каждый сам — или выбрать популярный продукт или нишевый.

и в том и в том случае есть свои преимущества — где-то было обсуждение на ДОУ..

с другой стороны, двигают рынок не большинство (средних и ниже среднего) программистов, а двигают индустрию ТОП 5-10% специалистов.

так из-за такого рынка веба среди этого топа — две трети пшпников , вот они и двигают веб

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

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

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

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

так из-за такого рынка веба среди этого топа — две трети пшпников , вот они и двигают веб

с чего ты взял?

так это — людей\ресурсов просто больше

При всей сомнительности аргумента в джаве народу в разы больше. И всяких двигателей веба в виде gwt, jsf тоже хватает.

При всей сомнительности аргумента в джаве народу в разы больше.

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

иначе java сайтов было бы много больше

В мобайле Ок, но после 2008(появление андроида) года например ТИОБЕ индекс не вырос для джавы, что говорит о том что мобильных разработчиков не так уж много на фоне общего числа.
Сайтов достаточно, но ты прав, бложеков на вордпрессе и хелловорлдов на друпале в интернете намного больше чем сайтов на джава, которые в среднем намного сложнее типического похапэ бложека.

А вот если из похапэ вычистить манкипатчеров то там практически ничего и не остаснется.

Очевидно, с жабой тоже самое

Не спорю, хотя что бы быть джава манкипатчером нужно знать поболее чем в случае похапэ. Но возвращаясь к вопросам инноваций в области разработки под веб, для джавы их очень много, первые взрослые использования ОРМ и МВЦ для веба были в джаве, всякие приватные облака у АйБиЭма уже есть много лет, опять же всякие новые попытки девелопить под веб вроде gwt & jsf, а похапэшники что придумали кроме копипаста с других платформ?

Медиавики с вордпрессом?;)

В джаве все это уже было и было достаточно крутым, просто денег много стоило.

просто денег много стоило.

воот. похоже ты понял суть.

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

Домохозяйка ниасилит настроить пых пых и апач, она пойдет заведет себе бложик на блогере, который (сюрприз) работает на джаве

это была ирония. я же не зря слово домохозяйка взял в скобки

Какая разница? Смирись, джава — это прогресс, а пыхпых это унылый копипаст и мусорные сайтеги.

Смирись, джава — это прогресс

ага-ага. существование Scala, Groovy, Cython, Clojure ... как бы говорят, что не все так хорошо в java королевстве

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

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

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

притом если в java только спринг и гибернейт,

О, сразу видно эксперта в джаве. Spring и хайбернейт это как бы не веб фреймворки, а веб фреймворков туева куча с совершенно разными подходами, и всякие асинхронные вариации вокруг netty вроде плея, и класический мвц вроде spring mvc, и портальные подходы как в liferay, и компоненты как в jsf, gwt, vaadin, zk, и толстые клиенты с своей vm как javafx, а пыхпыхеры уже 12 лет как копипастят мвц из джавы.

я про ormы если что.

фреймворков пшп-ных не просто много, а очень много и толстых и худых и средних

я про ormы если что.

Ну так может стоило бы вначале погуглить про джавовские ОРМы прежде чем позорится?

фреймворков пшп-ных не просто много, а очень много и толстых и худых и средних

И все являются вариациями вокруг содраного с джавы мвц.

И все являются вариациями вокруг содраного с джавы мвц.

талан — в java досих пор руками привязывают контроллеры к путям, я такого не видел в пшп

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

давай, посмотрим на пятую ветку.
5.3 — замыкания, анонимные функции, namespace, позднее связывание
5.4 — threats
5.5 — coroutines → генераторы, yield
о, да, минорные изменения.

или речь о конкретных фреймворках?

давай, посмотрим на пятую ветку.
5.3 — замыкания, анонимные функции, namespace, позднее связывание
5.4 — threats
5.5 — coroutines → генераторы, yield
о, да, минорные изменения.

или речь о конкретных фреймворках?

И где инновации? Все — унылый копипаст

удивите нас, расскажите что в java не унылый копипаст ?

а ну да. dynamic в будущем jvvm :)

а ну да. dynamic в будущем jvvm :)

invokedynamic? Так он уже в релизной. Если нет то уточните что имели в виду.

расскажите что в java не унылый копипаст ?

Из будущего:
— Условно «лямбды», так как они отличаются от похожих фишек в других языках (они более ООП чем ФП)
— дефендер методы. Существенно отличаются от примесей, или шарповой недореализации хотя она больше похожа на руби (возможно сравнение с шарпом немного не туда).

Из того что есть, первое что приходит в голову — дженерики (существенно отличаются от шаблонов).

P.S. Не исключено что подобное уже где-то было. Если да, то ссылки в студию.

UPD.
— джавадоки
— Возможно, аннотации и их реализация

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

invokedynamic? Так он уже в релизной. Если нет то уточните что имели в виду.

ну чет такое. я в java не особо, краем уха слышал про какую-то штуку которая ускорит динамические языки типа groovy

P.S. Не исключено что подобное уже где-то было.

не то что не исключено, а точно было

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

ибо фактически «конвертируют» интерфейсы в абстрактные классы

Нет, так как они не имеют состояния. Дефендеры — это способ «привязки» алгоритмов (инкапсуляции и в некотором роде полиморфизма), а не наследования.

Чисто субъективно, дефендеры лучше (более строгие) примесей (но это очень спорно).

P.S. Не исключено что подобное уже где-то было.

не то что не исключено, а точно было

Вы вторую часть потеряли:

Если да, то ссылки в студию.

Суть в том что я сходу не смог вспомнить где такое было. Если вы знаете то укажите, пожалуйста.

Если нет, то сойдемсо на том что джава мега-крута :)

Нет, так как они не имеют состояния.

изначально интерфейсы не несли в себе имплементации. теперь несут (пусть и через костыль) . я считаю что это отход от классического ооп.

Вы вторую часть потеряли:

Если да, то ссылки в студию.

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

думаю сами найдете историю лямбд и генериков

Созданы под влиянием, тут я не спорю. Но вот «реализация» отличается довольно концептуально:

дженерики (существенно отличаются от шаблонов).

«лямбды», так как они отличаются от похожих фишек в других языках (они более ООП чем ФП)

==========

изначально интерфейсы не несли в себе имплементации.

Тут очень тонкий момент. Что понимать под «реализацией»?
Если говорить про интерфейс как про «протокол», то в джаве — это уже давно не правда, так как интерфейс может содержать константы.
Спорить на уровне концепции, можно без конца.
Более конструктивный момент:
Что в этом хорошего?

Что в этом плохого? (куда более важный момент)

вот «реализация» отличается довольно концептуально

ну в пшп тоже концептуальные отличия есть.

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

Что в этом хорошего?

Что в этом плохого? (куда более важный момент)

эт без разницы.

я больше про то, что java такая же копипаста как и php

ну в пшп тоже концептуальные отличия есть.

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

Это не концептуальное отличие, это особенность реализации, как то что в джаве в заыкания можно передавать только финал-ссылку. В то время как лямбды в джаве — это реализация инфраструктуры для некоторого подмножества сущностей — функциональных интерфейсов. У лямбд в джугих языках могут быть дополнительные методы (определенные пользователем)? Их можно вызывать?

я больше про то, что java такая же копипаста как и php

Я привел 6 пунктов «нововведений». Вы так и не показали чем хоть один (строго говоря надо все 6) из них является копипастом. Да вы указали на некоторые спорные (возможно ошибки реализаци) моменты в реализации, но это не делает их копипастом.

угу, когда дело касается java, то это уникальная реализация (пусть и спорная), а когда php — унылый копипаст

угу, когда дело касается java, то это уникальная реализация (пусть и спорная), а когда php — унылый копипаст

Больше фактов, меньше фантазии.

Дефендеры — это способ «привязки» алгоритмов (инкапсуляции и в некотором роде полиморфизма), а не наследования.

Чисто субъективно, дефендеры лучше (более строгие) примесей (но это очень спорно).

как по мне так это просто добавление в java возможности множественного наследования, но не напрямую (ведь фанаты уже давно наизусть разучили — «множественное наследование єто плохо») а через костыли

вообще прикольный факт — фактически java стартовала как некая противоположность тому же с++ ... но почти сразу начались неудобства — и понеслось ... генерики, дефендеры, динамика, осталось добавить препроцессор

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

Угу почти сразу, через 10 и 15 лет :)

А динамика то как с ЦПП связана?

осталось добавить препроцессор

А он вроде как был в джаве МЕ (не уверен, так как не использовал никогда)

Все же предлагаю вернуться к теме «плагиата». Чем дженерики и дефендеры являются «копипастом»? Или «джавовские лямбды»?

Я не отрицаю что они строились на более старых идеях, но при этом они имеют концептуальные нововведения.

удивите нас, расскажите что в java не унылый копипаст ?

а ну да. dynamic в будущем jvvm :)

В джвм инноваций вагон и маленькая тележка. Но речь ведь не об этом, а о том что в джава экосистеме есть куча проектов, которые щупают новые подходы, а потом все лучшее сливается в джаву, как спринг и хибернейт например, а похапэ — просто унылый копипаст.

выглядит так, что вы просто не в курсе о проектах под пшп, которые «щупают» новые подходы

ну и по spring/hibernate — что именно они придумали ? кроме того, что просто скопипастили чужие идеи в отдельные сборки ?

ыглядит так, что вы просто не в курсе о проектах под пшп, которые «щупают» новые подходы

Та не щупают, не умеют, копипаст надежнее

ну и по spring/hibernate — что именно они придумали ?

spring — депенденци инжекшн фреймворк(до него фреймворков особо не было), хибернейт — орм с человеческим лицом, первым был иджб, а хибернейт его очеловечил, а потом уже похапэшники неумело скопипастили

, а потом уже похапэшники неумело скопипастили

я вот знаю несколько видов орм в пшп — от полностью динамического построения (нужно только имя таблицы указать), до декларативного в коде (в виде задания структуры средствами языка), до кодо-генерации (из специального описания).

так вот, какой именно «вид» был неумело скопирован ?

похапешники сделали веб єкономику такой какая она есть — без пшп гугль бы досих пор парсил бы три корпоративных сайта

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

Ну и энтерпрайз сайтов далеко не три.

есть такое понятие «стоимость выхода на рынок», пшп эту стоимость снизил в разы, уже не надо было нанимать толпу PhD — студент мог за вечер наваять (поставить) то, что несло денежку

С чего ты взял что пыхпых снизил в разы?

так вроде даже в єтой ветке обсуждалось, что в пшп куча дешевой работы

Это не значит что дешевые кодерки осилят что-то лучше профи и конечный ценник будет дешевле в разы

дешевые — не осилят, но часть из них со временем станет дорогими, это ж только java девы рождаются синьерами :)

Так как это что-то там снижает?

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

с java это будет требовать больше времени (денег)

Ну вот если задача развернуть друпал то да, друпал на джаве не развернуть. А всякие другие сайтеги вполне заливаются на GAE/heroku/openswift/jelastic парой команд/кликов мышкой.

угу. только если чет не пойдет,или плагин какой понадобиться — так и станет уныло.

всетаки чем более популярная вещь — тем проще найти помощь и поддержку

Та нет, толпа капрокодеров бардак и настрогает. Я предпочту продукт написанный несколькими хакерами.

Я предпочту продукт написанный несколькими хакерами.

а вот и фиг, они заняты — на форуме флудят

Потому что в коде мало ошибок и они все остальное успевают вовремя

в жабо-мире быдлокодеров не меньше, чем в пшп-мире

Ну вот если задача развернуть друпал

Дык вот то-то и оно: PHP предложил рынку бесплатные конструкторы сайтов, что позволило клепать сайты-визитки, блоги, электронные магазины и т.п. типовые решения задешево буквально силами вчерашних студентов. Ни Java, ни .NET на тот момент предложить ничего аналогичного не могли.

С другой стороны, Ruby on Rails обязаны своей популярностью именно тем, что предлагали решения именно для той ниши, где, с одной стороны, Drupal и аналогичным решениям на PHP уже не хватало гибкости, а с другой — enterprise решения были бы слишком громоздкими.

Чисто технически, PHP было что предложить и здесь, но он уже успел снискать себе славу «быдлокодерского» языка, в то время как для Руби умные дядьки-маркетологи создали эдакий элитарно-хипстерский ореол.

И что? Всякие конструкторы были и на джава но за деньги. В контексте продвижения технологий вопрос денег иррелевантен.

ну рейтинг TIOBE какой-то странный. ну вообще странный. почитайте на каких данных он строится.

ну и Джава для энтерпрайса в основном.

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

если же смотреть по линкедину — то «java web» ниже «php» , а еще ведь нужно вычесть интранетчиков

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

А чем плох корпоративый софт? Куча плюшек которыми сейчас так гордятся пэхопэшники вроде web mvc и orm сделали корпоративные писатели.

мне кажется, что в энтерпрайс софте ормы менее востребованы, чем в сайтах однодневках

Непонятно как это относится к топику, но тебе очень неправильно кажется.

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

к слову mvc уже сто лет и если верить википедии — то впервые этот архитектурный шаблон использовался в смолтолке и если я ничего не путаю — то это не очень то и Энтерпрайз язык. скорее академический

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

Куча какой то ерунды

к слову mvc уже сто лет и если верить википедии — то впервые этот архитектурный шаблон использовался в смолтолке и если я ничего не путаю — то это не очень то и Энтерпрайз язык. скорее академический

Да, я не случайно написал «веб мвц», этот паттерн для веба был популяризирован джавой

сделали да — но и где тот смолток ?

тот же пшп вынес этот мвц в массы, сделал его обычной вещью

сделали да — но и где тот смолток ?

тот же пшп вынес этот мвц в массы, сделал его обычной вещью

Полная ерунда, мвц в массы вынесла джава в виде фреймворков вроде struts-a, а уже потом пыхпыхеры начали все это дело копипастить, я наблюдал этот процесс вначале 2000-ых.

Занадто часто бачив людей, які навчившись писать «hello world», if, пару циклів і підключення до БД на PHP, бігли в іншу мову програмування з словами «Я вивчив пхп!». Ніфіга вони не вивчили раз так.

А взагалі не треба нікого слухати — треба стати ПРОФЕСІОНАЛОМ в вибраній сфері. А професіоналам платять добре.

даже страшно подумать ма что ты намекал когда писал это

руби не нишевый язык. и если вы делаете свой продукт — то вы можете выбирать инструмент. если вы наемный работник — то выбирать инструмент не приходится

Я ось на PHP вже 5 років відписав і нікуди не збираюся.
Ця мова дає мені можливість реалізувати практично що-завгодно.
Але тим не менше, я вважаю, що PHP я знаю вже чудово і хочу розширить свій арсенал інструментів, як девелопера, і тому хочу вивчити ще щось.
І зараз підучую Java трішки. Ще мене цікавий Python. Рубі мені залишив дуже неприємний осад своїм синтаксисом... (ну це може мені ...)

А автору постави вище — а може раз ви міняєте роботу, то подивіться просто більш оплачувані вакансії на php з можливістю росту?

Не знаю, где лучше написать вопрос...

А что насчёт Groovy? Живёт, перспективы имеет?...

я бы только на него сильно не ориентировался бы

Само собой. Вообще, я специализируюсь на Java.
Подумываю, не взять ли второй язык про запас. Perl я тоже когда-то знал, и вот думаю, есть ли смысл вспоминать?.. Он ведь «медленно, но верно» загибается, и уже давно.

Подумываю про PHP, Ruby или Python.

NoSQL — это да.
У меня тут уже кое-какие планы определились. А по поводу Ruby — это пока только на уровне идеи, «а не взять ли ещё и это».

Но пока не горит.

Ага, и заиметь сертификаты «oracle database 11g administrator certified master» c «MCSM»: борода, задумчивый взгляд и красный феррари прилагаются :)

Я юзал для скриптования и мелких дсля, мне понравилось, ибо джава, и ничего особо нового там учить не нужно :-)

Напомнило холивар MFC vs VCL :)

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

Вобще программисту нужно постоянно знакомиться с различными языками и технологиями. Так программист развивается. Даже если пойдешь в новый стартам и попрограммируешь в нем на Ruby, хуже не будет. Разберешься с новым языком, технологиями и подходами. А если стартап не взлетит, то в твоем резюме будет уже 2 языка, что увеличит твои шансы в поиске нормальной работы.
В целом ruby как язык более целостный. Но PHP успел захватить довольно большую нишу и PHP-ники будут нужны еще долго. Крутые php-ники получают хорошие деньги, и раз уж ты уже 2 года на php пишешь, то тебе проще будет дойти до статуса ПХП-сеньора оставшись в PHP. Возможно стоило бы остаться в PHP но поискать другую перспективную компанию.

Сам пишу на php лет 10, чувствую себя нормально, хотя PHP и надоел. Но если и буду уходить — то в erlang, clojure или анализ данных (R, мат-статистика и тп), но никак не ruby

ru.xored.com/...12/12/02/scala к недавнему спору о Scala. Автор не полностью, но в правильном русле описывает Scala. Особенно полезно для тех. кто считает Scala синтаксическим сахаром к Java.

ну скала в вебе несколько уныла
play которая в 2012 году приказывает ручками привязывать урлы к методам контроллера
да шаблонизатор lift (с некоторым предустановленным обвесом, но без mvc ) ...
и это кстати не только скалы касается , в хаскеле таже проблема — фреймворки пишут люди умные, но от веба несколько отстраненные ... т.е. есть набор неких удобств, которые реализуются там средним фреймворком на пшп (и наверное рор) :
— convention over configuration (в том числе и путями по дефолту)

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

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

А еще есть ГВТ. У меня правда никогда руки не доходили потестить насколько вменяемо порт для скалы реализован.

я гвт смотрел несколько лет назад, это все-таки нечто другое — одностраничник с десктопным стилем разработки.
в принципе ничего так , хотя и медленноват в разработке — всетаки из java комплить в javascript ... в таком же духе есть еще вариант www.webtoolkit.eu/jwt

там еще и graceful degradation из коробки

хотя и медленноват в разработке — всетаки из java комплить в javascript

Хоть мы уже и выяснили, что вы сторонник динамической типизации и вима. Всеже, я прям должен :-) сказать, что наличе нормального статичски типезированного языка и на сервер и клиент сайде со всеми ИДЕ плюшками и нормальным дебагом делает меня значительно производительней, что привышает время потраченное на компиляцию. Хотя должен признать что компиляция там таки чертовски медленная (+ есть пачка своих раздражающих ишшюсов).

нормальным дебагом делает меня значительно производительней

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

хотя да, первое, что я сделал когда связался в пшп — поставил дебагер, ибо не всегда понимал как управление попадает в ту или другую функцию

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

замечу, что дебаг это всегда удар по производительности разработки (слишком высоки затраты времени)

Замечу, что совсем не всегда. Это скорей субъективные очучения конкретного человека. Мне, например, в модуле где логика аккурат размыта по сотням различных классов, всегда быстрее найти точку бага через дебаг, чем пытаться проглотить за раз все эти класы. В мелких пых скриптах на < 2к строчек дебаг действительно не нужен, логгинга хватает.

гы. я понял(вспомнил) одну вещь, которая как-раз порождает подобное требование (reality_hacker понравилось бы)

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

— соответственно, и функция вызывается из миллиона мест, с разными параметрами(классы то разные)

в результате — компилятор побежден — функция компилируется как статическая, но реально круг замкнулся, и ситуация таже, что и с динамическими языками — понять без дебагера (либо других методов восстановления callstack) что именно передается в функцию — невозможно , как и понять side-effects

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

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

это как с гуглем — проще ведь нагуглить что-то чем идти от сайта к сайту и статьи к статье «ручками»

— в результате получаем функцию(ии), которая(ые) как параметр принимает ну там итератор, но при этом итератор реализован в миллионе классов

— соответственно, и функция вызывается из миллиона мест, с разными параметрами(классы то разные)

в результате — компилятор побежден — функция компилируется как статическая, но реально круг замкнулся, и ситуация таже, что и с динамическими языками — понять без дебагера (либо других методов восстановления callstack) что именно передается в функцию — невозможно , как и понять side-effects

Я плохо понимаю причино-логический вывод. Ибо функция которая принимает итератор, блжад таки принимает итератор :-). И в статически типизированном языке вы не моете скомпилить код, который пытаеться вызвать эту функцию передав в неё строку, инт, или слона. Вот и все отличие между динамикой и статикой. И вызвать одну и туже функцию вы можете милион раз как в статически типизированном так и в динамически типизированном языке — не вижу связи.

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

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

Ибо функция которая принимает итератор, блжад таки принимает итератор :-)

но физически «за интерфейсом» лежат разные классы, с разными side effects и прочее. т.е. смотря на эту функцию , ты не можешь сказать что же происходит вне ее, разве что зайдя внутрь частной имплементации того же итератора

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

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

тут таже проблема что и с гуглем — если вы спросите чет общее, то и результат будет бесполезным.

но в большинстве случаев существуют некоторые, скажем так «теги» которые скорее всего встретятся в нужном месте и не встретятся везде — имена полей\таблиц в базе, текст ошибки, слово из dsl , кусок из разметки — css стиль, id и т.д.

но физически «за интерфейсом» лежат разные классы, с разными side effects и прочее. т.е. смотря на эту функцию , ты не можешь сказать что же происходит вне ее, разве что зайдя внутрь частной имплементации того же итератора

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

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

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

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

Тобиш вы этот весь код написали сами, и в комманде вы не работаете ?

компилятор строго укажет место где ты забыл это зделать

на тестах свалится

а иде с рефакторингом и вовсе поможет автоматизировать процесс.

гм. отловит все места где вызывается функция с параметром типа итератор и перекодирует вызовы на списки ?

чет сильно умно

А дебаг со стек трейсом еще и облегчает это в разы.

так я не спорю

Передаваймый итератор можна слепить патчингом по кускам в разных местах — итд. Ни компилятор, ни ИДЕ , ни дебаг — ничего не помежет разобратся.

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

Это значит что вы имеете очень хорошее текущее представление, о том что ваша функция делает, и кто и зачем к ней может обращатся

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

подход тот же, что с гуглем — правильно составленный запрос приведет к искомому , зная контекст (в данном случае как написаны программы) это относительно легко разрешить

Тобиш вы этот весь код написали сами, и в комманде вы не работаете ?

это без разницы, даже свой код через полгода забывается.

тем более регулярно лажу по чужому коду (в последнее время для развития — языки, фремворки), так что оно норм и на полностью «чужом» коде

на тестах свалится

Это надо, для начала, еще и тесты иметь, которые все покрывают.

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

Это депендс на язык вашего чейс. Вот джава — дубовая как угол дома, не развернешся — будеш писать в очень ограниченном пространстве возможностей. За это я ёё и люблю. Скала — прямая противоположность, можна написать одно и тоже множеством различных способов.

это без разницы, даже свой код через полгода забывается.

тем более регулярно лажу по чужому коду (в последнее время для развития — языки, фремворки), так что оно норм и на полностью «чужом» коде

Фреимворки и чужие примерчики, восновном штука небольшая. Вот большие ынтырпрайз аппы, писанные индусами и джунорами — вот там можна рассудок подуранить :-)

Скала — прямая противоположность, можна написать одно и тоже множеством различных способов.

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

Вот большие ынтырпрайз аппы, писанные индусами и джунорами — вот там можна рассудок подуранить :-)

ну не знаю, недавно вот лазил по исходникам eclipse (даже не скачивая, тупа через viewcvs ) - то что искал, нашел

хотя и медленноват в разработке — всетаки из java комплить в javascript

возможно это потому что ты не открыл для себя development mode

возможно потому что под apps engine он не работал ? я не помню просто

Та нет, должно все работать, апп енжин это сервер сайд, а development mode это клиент.

та я не помню, год 2008 где-то

Та с самого начала он был, + в 2008-м джавы на ГАЕ не было.

play которая в 2012 году приказывает ручками привязывать урлы к методам контроллера
этот спорный недостаток обходится 10-ю строками кода

этот спорный недостаток обходится 10-ю строками кода

воот ! вот почему собственно я и возмутился.

почему не сделать по дефолту — ведь єто же удобно !

Вторая версия плея повернута на строгости проверки ошибок, если ты неправильно задал рутины то они просто не скомпилятся, тоже относится и для шаблонов. Максимум проверок в момент компиляции, и они этим гордятся, а в подходе который ты предлагаешь залажать проще простого.

а в подходе который ты предлагаешь залажать проще простого.

как можно налажать в подходе когда по дефолту каждый класс контроллера — это урл первого уровня, а метод — второго ?

как раз с ручным редактированием (спасибо что не хмл) налажать много легче

Например ты открываешь все потроха системы, даешь фактически вем доступ ко всем методам контроллеров.

Второй момент производительность, в плее роут это скомпилленый класс, т.е. никаких рефлекшнов не происходит, все работает максимально быстро.

Например ты открываешь все потроха системы, даешь фактически вем доступ ко всем методам контроллеров.

гм. єто собственно и есть convention over configuration — очень удобно когда все паблик методы контроллеров открыты

эт если мы работаем в mvc

Второй момент производительность, в плее роут это скомпилленый класс, т.е. никаких рефлекшнов не происходит, все работает максимально быстро.

так сгенерите єтот класс маппинга во время билда , или java world уже отверг идеи «code generation» ?

гм. єто собственно и есть convention over configuration — очень удобно когда все паблик методы контроллеров открыты

эт если мы работаем в mvc

Спасибо, я в курсе как это называется, но баланс между фичами выбран именно таким

так сгенерите єтот класс маппинга во время билда , или java world уже отверг идеи «code generation» ?

Кроме удобства это и еще один костыль усложняющий систему. В плей в новой версии да, отказались. В предыдущей было много кодогенерации.

то-есть контроллер там есть, представление он возвращает, данные тоже есть. почему же mvc нет?

о-есть контроллер там есть, представление он возвращает, данные тоже есть. почему же mvc нет?

в лифт ? ну там есть view и model , model заодно может выполнять роль некоего контроллера

в пшп такие вещи называют шаблонизаторами — smarty,twig и многие другие

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

в плей более-менее классическое mvc

В Lift используется View-First паттерн. У этого подхода есть как свои плюсы, так и минусы. Мне лично Lift не нравится, тем что там дофига DSL, чем богата Scala, но если привыкнуть очень продуктивный Framework.

С play все ок, как и сказал reality_hacker. Мне лично такой подход больше нравится, но каждому свое, как говорится.

но каждому свое

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

очень часто решение, которое неплохо выглядит в хелловорде, в реальной жизни превращается в хелл

я не хардкор пхп программер, но пару-тройку лет на нем писал. и как-то не задумывался о таких вещах глубоко. но сегодня еще раз перечитал. me.veekun.com/...-of-bad-design

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

Ну я бы не сказал, что stand-alone. Обычно нужны знания либо конкретной платформы (Drupal, Wordpress, Magento и иже с ними), либо — знания Веб-фреймворков (Symfony, Yii и т.п.)

но сегодня еще раз перечитал. me.veekun.com/....-of-bad-design

неплохая коллекция особенностей.

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

Волка бояться, в лес не ходить. Возьми себе за привычку изучать всё и вся, и будет тебе счастье! Никогда не нужно останавливаться на чем то одном. Чем больше ты знаешь, тем более ты востребован и как следствие, тем больше ты заработаешь.

вы подозреваете или владеете информацией?

стереотипы такие стереотипы

повторюсь: стереотипы такие стереотипы. вы хотите общую картину зарплат получить по средним зарплатам пхп программиста (вакансий тысячи) в сравнении со средней зарплатой рубиста (вакансий единицы, в лучшем случае десятки).

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

какое будущее? вы чего? уже лет пять уже говорят, что еще чуть-чуть подождать и рельсы будут мейнстримом. нет никакого будущего.

так ведь и сложные не пишут.

а что гитхаб?

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

А со временем рельсы я думаю подымутся и потеснят ПХП, пусть может и не сильно.

ну это ведь не новая технология. с чего ей подниматься именно сейчас?

начнем с того, что сложные сайты и не отдадут индусам.

Просто для сложных сайтов будут выбирать Руби и рельсы. Если начинать делать с нуля.

если стартап — скорее уж выберут то что проще и где легче найти прогеров (разве что денег немеряно — тогда выбор дело специфичное). ведь не известно — выстрелит или нет.

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

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

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

не. я смотрел и остальные, но они не прошли.

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

Андрей, я уже задавал риторический вопрос ниже. Но повторюсь:

почему www.java.net с почти миллионной аудиторией java-разработчиков писан на друпале под пхп?

дешевле, проще и быстрее... как в макдональдс, не успел зайти, тебя уже обслужили — вильна касса!

а не грязюку разгребать:)

угу. выбери руби , нанеси в него грязюку

гм. вижу туже дискуссию что и тут. никакой конкретики

а в чем отличие от пшп ?

1. Крутость самого языка. думаю, тут можно вообще отдельно говорить.

«крутость» — гм. это субъективно. все языки «крутые» для фанов этих языков.

2. Дизайн — принципы самого фреймворка рельсов. прекрасная эталонная реализация MVC плюс несколько еще дополнительных красивых решений.

эталонный mvc ? странное понятие, я видел\пользовал разные mvc фреймворки, (в php и не только) — легковесные и тяжелые, заточенные под разные задачи и имеющие свою «целевую» аудиторию, со своими плюшками и ценой за них. я бы не назвал ни один из них серебрянной пулей.

кстати, просто интересно, знаете ли вы какие-нить проблемы присущие именно mfc ?

3. прекрасный маппинг на БД (ActiveRecord).

уу, сколько крови у меня этот ActiveRecord попил

4. Целостность архитектуры и системы в целом.

а можно подробнее ? а то может под целостностью вы понимаете безальтернативность

Честно сказать, так сразу не отвечу (не знаю):)

ну самая поверхностная — это очень активное использование памяти — стандартная работа web mfc — собрали все данные из источников, сгенерили по ним результат.
в момент генерации обычно и данные и результат одновременно сидят в памяти

что вызывает определенные проблемы при масштабировании.

Плюс мне не нравится писать SQL — запросы:)

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

конечно, если задача не требует joins/unions/grouping и прочих достаточно обыденных вещей — то activeRecord вроде как ок.

Плюс мне не нравится писать SQL — запросы

ORM-щик штоле? :)

Потерянное поколение :) Вот в мои то времена, sql-запросы писали в блокнотике, отлаживали в консольном клиенте, тюнили в эксплейне...

Ага, и усы как у Будённого. Неожиданные выводы вы сделали, видимо, далеко от народа сидите, от простых рабочих PHP-шников — там и по сей день такое практикуется :)

А вы сами — то на чем кодите?

Пишу стартапы на руби.

Ну я сам помню свой первый проект реализовывал на голом JDBC — стыдно вспомнить вообще

Зря вы так, мне приходилось не один раз «ускорять» гoвно-проЭкты, написанные упоротыми питонерастами или жабашниками с маппингом головного мозга, когда от количества насованных моделей голова шла кругом, и всё люто тормозило. Каэшн, в энтерпрайзе проблемы решаются путём добавления сервера в кластер, а в сервер — оперативы, я помню, но когда запрос данных через ORM выполняется 8 секунд, а «обычным» sql-запросом — 0.01 секунд, это вдохновляет (и приносит неплохой материальный доход).

А ещё из-за этого засилья абасракций над базами данных никто не качает скиллы по работе с БД: тру-синиоры из Лидеров Рынка С Пятью Летами Работы В Сфере Разработки срезаются ещё на вопросах о структуре индексов, самые продвинутые даже когда то слышали про кластерные, но что это такое — сказать не могут. Что уж говорить о просьбе написать запрос на бумажке, по готовой схеме, с чётко сформулированными требованиями? А уж познания про оптимизацию таких запросов, по такой обширной и дискуссионной теме: «ну, запущу профайлер в %RDBMS_name_GUI_tool% и буду что то делать и куда то тыкать мышкой». А ведь ещё есть 100500 важных вопросов по сабжу, о которых уже и спрашивать не хочется — и так всё понятно.

Вот, как то так и живём, за державу очень обидно.

Вы набрасываете

Вы тоже :)

То вы ругаете Руби, то пишите на нем

Я вам больше скажу: несмотря на то, что я ругаю руби, пхп, питон, сишарп и даже местами Святую Корову Аутсорса — приходится ногда пописывать на всём этом. Из последних достижений: веб-сервер на джаве с крестами и терминальный клиент к нему на пхп (только не спрашивайте, зачем это было нужно). Годно? :)

Так да, знания БД важны 100%. Только реляционные БД уже не нужны — NoSQL наше все!

Я вам отвечу годной копипастой:

«NoSQL исторически появился раньше SQL-а, собственно весь ынтырпрайз до 70-х им в жопу и долбился. Потом британский ученый изобрёл теорию РБД, появление которой привело к немедленному выметанию всего этого ёбaнoго хаоса с рынка, стандартизации и тотальному овладиванию SQL-а в рекордно короткие сроки. Побочным эффектом стало то, что всякое быдло начало пихать SQL туда, где он не очень-то и нужен, и очень, блядb, страдать, от того, что их гостевухи стали долго загружаться. Потом кто-то сделал фундаментальное открытие — оказывается хранить профили пользователей гостевухи в хешь-таблице в памяти и доставать их оттуда по имени гораздо быстрее, чем реализовывать EAV поверх РБД. После этого переворота в мозгах гостевушников они приняли радостно сверкать новым базвордом по своим блогам и хабро-хабрикам, радуясь, что им в очередной раз удалось повернуть стрелку прогресса вспять и укусить себя за жопу.»

По поводу ненужности реляционных баз данных и «nosql наше всё» — это вы слишком толсто, я с трудом остановил приступ баттхёрта.

Кстати, по-секрету говоря, некоторые реляционные БД могут работать в режиме «ключ-значение» без использования SQL с весьма эпическими (в лучшую сторону) показателями в производительности ;)

Синьор непознаваем

Опознаваем, меня уже спалили два раза :)

Вот не верю

Вы так говорите, словно тут что то экстра-сложное или времязатратное. Прикиньте, как джава-синиор, сколько бы времени ушло у вас на реализацию простого (простого!) многопоточного веб-сервера для для отдачи статики, и сишного «модуля» для генерации «динамики»? А консольного клиента к нему? Естесственно, это всё не для коммерции, а так, джаст фор фан, так что делаем поправку на отсутствие расширяемости, устойчивости и так далее. TCP и сокеты — они везде TCP и сокеты, так что склеить это всё в кучу проблемы тоже не составит.

Если плотно засесть — то за пару дней, а если не плотно — так по вечерам за недельку и напишется. Так что, не понимаю вашего удивления.

дома дергаю руби чисто по тому, что нравится

А я дома в танчики играю.

BerkeleyDB

Не только :)

Все равно вы остаетесь загадочной личностью на доу ИМХО:)

Ой та ладно, тут андефайнед-анонимусов полно.

На руби — только стартапы, попрошу заметить! Это важно: в стартапах можно писать низкокачественный write-only гoвнокод, без проектирования, архитектурных изысков и TDD, используя schemaless nosql решения :))) Ах да, на руби классно прогается по инди-рок нонейм коллективов.

вы гений!

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

Ок я искренне за вас рад

^__^

А еще я помню вы джунов по пальцам линейкой бьете:)

Да, бывает. К сожалению, временно отстранён от джунов :( Приходиться развлекать себя рубикодопейсанием.

Чего ж вы тогда так ругаете руби? А потом оказывается, что пишете на нем? Мне это непонятно, если только это не очередной наброс — я стараюсь не писать на том, что меня раздражает, так в свое время ушел от НЕТа:)

Надо знать, что ругаешь, иначе вбросы получаются унылыми. Вот, как то набросил неплохо по питону, так с prom.ua-шники набижали во главе с СЕО и стали рассказывать, кто тут мушкетёр, а кто нет. Такая вот польза от интерпретируемых языков :)

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

Ну как — то все равно смутно верится

Да, я тоже не верю во многие вещи, например, в сборщик мусора в четвёртом дотнете, когда у 20-летних миддлов программа начинает отжирать непомерно памяти, когда как бы и не должна, с разными результатами в debug и release. Вот так и верь всем подряд :)

Ладно, поверю вам на слово:) Слово 23 — х летнего синьора железно:)

(*^_^*)

NoSQL исторически появился раньше SQL-а, собственно весь ынтырпрайз до 70-х им в жопу и долбился

И как, базы данных 70-ых хорошо горизонтально масштабировались?

А вы предпочитаете пассив или актив? Я про M в MVC, если что :)

Вот-вот, об этом я и говорил: ORM строгать умеем, а про тонкости не знаем :)

Ладно, не удалась шутка. Я о том, что модель в эмвэцэ может быть двух канонических типов, означенных в комментарии выше.

/me записывает в днявочку

сегодня 23-х летний сениор жог. я всхохотамши

1. Крутость самого языка. думаю, тут можно вообще отдельно говорить.

крутость как аргумент в пользу крутости чего-то — это как-то по-детски.

— Грузины круче, чем армяне.
— Чем?

— Чем армяне.

2. Дизайн — принципы самого фреймворка рельсов. прекрасная эталонная реализация MVC плюс несколько еще дополнительных красивых решений.

эталонная — это потому, что вы так решили? то же самое касается и маппинга бд.

я уже писал выше и повторюсь еще раз. MVC не подходит современному вебу. У вас есть рестфул апи, который отдает контент и клиент, который всё клеит

Крутость языка — понятие эстетическое, а полноценные MVC и ORM фреймворки в PHP существуют и ИМХО не уступают аналогам из других языков.

Другое дело, что Drupal написан в процедурном стиле, ну так Drupal’ом же мир PHP разработки не ограничивается.

Это я понял. Вопрос — кто считает, что рор — эталон мвц?

Т.е источник типа «одна бабка сказала»?

Если бы это комьюнити провело какое-то объективное сравнение RoR и какого-то из MVC фреймворков на PHP — тогда было бы о чем говорить. А так — «каждый кулик свое болото хвалит».

у руби есть рор, у питона — джанго (не, ну есть еще конечно), а у пшп — десяток самых популярных, все с мвц, но — разных , под разные задачи.

так я называю двух чуваков уважаемых — Энди Хант и Дейв Томас

Что любопытно, быстрое гугление никаких достижений этого самого Энди Ханта на поприще именно программирования не обнаружило. Его участие в Agile Alliance, конечно, заслуживает уважение, но вот только за какие заслуги его туда приняли — пока выяснить не удалось.

По Дейву Томасу картина более понятна: он, к моменту написания книги, уже лет 10 как педалил на Ruby (по его собственным словам в интервью), да и книгу на тему программирования на Ruby написал. Понятное дело, что ему выгодно пиарить именно этот язык.

Фаулер где-то сказал что у рор — эталонное mvc?

а руби сайт куда проще вообще начать писать на пхп

я тоже серьезно говорю. Технологии прямые конкуренты. Зачем владельцу бизнеса выбирать руби вместо пхп? конкурентных преимуществ минимум, зато найти разработчиков сложно и каждый второй джуниор считает себя звездой мирового масштаба просто потому что он выбрал великолепный руби, а не говёный пхп

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

современный веб такой, что mvc на сервере уже никому не нужно.

не думаю, что в в первом миллионе сайтов алексы много визиток

современный веб такой, что mvc на сервере уже никому не нужно.

Чего-чего?...

mvc на сервере уже никому не нужно.

не. без mvc там уныло

ага. руби тут тоже бесполезен из за своей природы.
всетаки stateless и stateful миры сложно скрещивать.

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

для удобства. можно и на си cgi писать ... но как-то неудобно

какое удобство? представление всё на клиенте.

Качество кода

зависит все-же от качества разработчиков и тестов, язык тут врядли помощник, разве что пайтон — красиво отформатированный код и глючит красиво :)

масштабируемость

масштабируемость у пшп такая же

сопровождаемость.

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

красота кода это очень субьективно. для меня руби выглядит как делфи

а вот си и сиподобные вещи, правильно оформленные, для меня выглядят как песня

Не могу понять почему на ruby человек будет стараться, а на php не будет. Процесс старания как-то регламентируется языком?

Сам язык подталкивает к г-но коду

Руби конечно получше для неокрепшего ума будущего поколения, но он не далеко от PHP ушел. Хаос из концепций. А потом никто не знает откуда руки ноги растут. Ruby on Rails то лучший? Он хороший, спору нет, но для формошлепства.

Руби практически далек от SmallTalk. array.each do |x| print x end — это вообще чистый объективный код, ага. :) В матчасти вы не разбираетесь. :)

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

Антон Белецкий уже подтроллил.

ИМХО
Перед изучением Scala — стоит изучить для вправления мозгов в правильном направлении — OCaml
перед изучением C++ и Ruby — Smalltalk

перед изучением Haskell — Lisp и Prolog

Успех Java в том что можно обойтись «бейсиком», и быть вполне неплохим программистом — полезным и себе и другим.

математика — тут ни при чем.

Код — это речь программиста. Конечно, если речь корява, то может пьяный, а может и мысли у него такие.

Но когда есть мысль — ты научишься ее выражать даже на китайском.

Перед изучением Scala можно SICP прочесть, а Prolog то почему до Haskell? До Haskell можно почитать одну из кучи книг из серии Introduction to Functional Programming.

Scala да хорошо идет если ты уже знаешь что-то из функционального программинга, а учить функциональное программирование с нее очень тяжело, он уже Андрей(читал или нет сомневатся не будем) обозвал ее синтаксическим сахаром к Java, боюсь если относится к ней с таким подходом — толку будет мало.

а Prolog то почему до Haskell?

Личные впечатления.

Попробую объяснить.

Prolog — как более старый язык, соответствует старой парадигме минимализма синтаксиса, простоты. Таков LISP, M (MUMPS), C, Modula-2 и.... Java. Мода да, изменилась, минимализм уходит в прошлое, и ЯП становятся богатыми и на синтаксический сахар, и на мультипарадигменные штучки. Что — сбивает с освоения — концепций.

Prolog — пожалуй самый — декларативный язык. Провернет мозг — не меньше чем Haskell — но без утопания в деталях и фичах языка Синтаксическая суть Prolog’а — не сложней чем у LISP. Читабельность немного выше, потому что там не списки — а деревья. ну и конечно — способ «возврата значения», или «связывания». Программы на Prolog можно и читать и писать — императивно. Но когда ты врубаешься в пролого-мышление, то иногда возникает ощущение что программа вообще «не выполняется» — а как-то вот написал, и программа и есть результат — сразу! Выполняться ей как бы и «незачем» :) Она как бы вся целиком — иммутабельна и чистая функция. Отучает от мышления в «конечных автоматах»

Конечно, нужно продвинуться в нем чуть дальше обычных лаб где логические задачки про «волка, козла и капусту» нужно реализовывать. Они как раз и не показатель, потому что самые удобные для Prolog.
Или — сразу их игнорировать, а брать более реальные примеры.
И еще Prolog очень продвинет в «SQLмышлении» :)

И главное — в ФП мышлении. Оно — декларативно, даже если функциональный ЯП так устроен что кодируем в императивном стиле.

Ещё есть Perl.

Правда, перспективы его как-то непонятны.

livejournal на нем крутится. хотя и падает регулярно

Пациент скорее мертв чем жив

Perl — хорош для парсинга, был.

Если вести разговор о копипастах, то грех не упомянуть:

Алсо, Пых может поломать жизнь не хуже любой дури, поэтому слушай, мой юный друг. Да, Пых — самый короткий и быстрый путь к баблу. Но если ты решил связать свою жизнь с программированием, то совет один: даже и не думай о Пыхе, иначе через пару лет будешь рвать волосы на жопе.
PHP (вместе с Pascal) — самые низкооплачиваемые языки программирования. Сколько бы книг ты ни прочитал, сколько бы мегабайт кода ни написал, ты никогда не будешь получать больше, чем Java-быдлокодер средней криворукости. «На Яве пишут Корпорации», а на Пыхе...
Порог выхода такой же низкий, как и порог входа: если у программиста на полноценных языках с возрастом есть шанс стать ценным высокооплачиваемым специалистом, то у похапе-олдфага такой возможности нет просто ввиду убогости и примитивности решаемых задач, его спокойно можно выгнать на улицу взяв взамен школьника, который обучится всем премудростям похапе-быдлокоддинга за пару месяцев потребляя при этом в три раза меньше доширака.
Возможно, сейчас тебе кажется, что делать сайты — достойное и интересное занятие, но если ты хоть немного программист, через пару лет такой работы ты просто завоешь от того, насколько это унылая и далекая от программирования деятельность.
Большинство проектов кроме того, что по сути своей убоги, представляют из себя чудовищный говнокод на кривых самодельных говнофреймворках и говноCMS (потому как сам язык не только не заставляет писать правильно, но и фактически подталкивает к производству быдловелосипедов). Как следствие такой работы — необратимое поражение мозга и окончательная потеря квалификации. Чему также способствует работа в коллективе невероятно тупых похапешников, постоянные оскорбления и обвинения (просто потому, что умный человек PHP не выберет).
Некоторые начинают работать на PHP с надеждой потом перейти на что нибудь другое. Но это тоже большая ошибка: во-первых, теряется драгоценное время для старта (наверное, самое важное и ценное в и без того короткой профессиональной жизни программиста), а во-вторых, PHP-опыт никому не нужен и нормальные программисты справедливо смотрят на него как на говно. «PHP» — клеймо быдлокодера на лбу и крест на карьере профессионального программиста, если ты пошёл по этому пути, назад дороги уже не будет. Единственное исключение — устроится похапешником на многопрофильную фирму, где тебя каким-то чудом заметят и предложат перейти на полноценную технологию, но это невероятная удача.

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

PHP погубил очень много потенциально хороших программистов просто благодаря легкости изучения на начальных этапах. Он затягивает как наркотик, с ним очень легко и приятно начать, вот только когда приходит понимание принципиальных недостатков как самого языка, как и (что гораздо более важно) его убогой ниши — часто оказывается уже слишком поздно что-то менять. Так что учись программировать, думай о будущем и обходи PHP стороной. Потому что с PHP у тебя нет будущего — это путь в никуда.

Олег, я ошибаюсь или www.java.net собран на drupal?

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

Не глядел в гугл, но почему то уверен, что люди который писали www.java.net (как и фейсбук и т п) знают не только ПХП.
И что начинали они не с него.

выходит, что пхп просто отличный инструмент

...для разработки несложных веб страничек.

чего же в пшп не хватает для разработки сложных страничек ?

энфорсить типы давно уже можно , хинтинг и strong типы в помощь
но чем это поможет сложным страничкам ?

наоборот код читабельннее, без лишний конверсий типов, тем более что веб текстовый по сути

хинтинг и strong типы в помощь

Тем не менее в мире куча кода которые это не используют.

Статическая типизация дает возможность построить удобные ИДЕ с рефакторингом, code completion и навигацией, а так же устраняет кучу ошибок в compile time.

наоборот код читабельннее, без лишний конверсий типов, тем более что веб текстовый по сути

если есть хорошее выведение типов(как в скале) то код будет тайким же читабельным.

Тем не менее в мире куча кода которые это не используют.

язык предоставляет возможности, этого достаточно

Статическая типизация дает возможность построить удобные ИДЕ с рефакторингом, code completion и навигацией

я давно пользуюсь vim (в котором разве что рефакторинга нет, нужно прикручивать внешний) поэтому не помню, но слышал что ide как-то выводят типы и для динамических языков , та что там — тот же hiphop мордокнижный выводит типы и компилит в нативные

а так же устраняет кучу ошибок в compile time.

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

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

если есть хорошее выведение типов(как в скале) то код будет тайким же читабельным.

т.е. усложняя компилятор всеравно получаем пшп ? в чем профит ?

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

Ну лутше ошибки в компиль тайме, чем свалинг в продакшене ;-)

угу. только какие ошибки он отлавливает ?
ты хотел присвоить строку инту и забыл типы привести, ага, пошел, добавил конверсию.

только время потерял на набивку лишнего текста

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

средняя функция на любом языке вначале проверяет входные данные и состояние.

Тока на пых-пыхе эти проверки нужно руками писать, и ошибки ловят они в продакшне а не во время компиляции.

Ну и возвращаясь в реальным мир, у тя на проекте во всех функциях такие проверки стоят?

Тока на пых-пыхе эти проверки нужно руками писать, и ошибки ловят они в продакшне а не во время компиляции.

ну-ка нука, поподробнее, какой же это чудо язык поддерживает отлавливание не пустых коллекций, или там null ну или то что state обьекта нетакой ?

Ну и возвращаясь в реальным мир, у тя на проекте во всех функциях такие проверки стоят?

там где надо стоят. обычно на «входе» в систему , эт когда либы писал (эт на с++ больше) так в каждой

ну пустая коллекция в си шарпе — это всё-таки коллекция. проверка на налл — это как мыть руки перед едой

воот и я про то же, статическая типизация тут бесполезна

кстати в пшп type hinting позволяет разрешать или запрещать null , вроде бы мелочь ...

а ваш основной язык программирования какой? с какого языка вы начинали?

последние года три — пшп, до него лет 7 си\с++, до этого был делфи. это то что коммерческое.

кстати в пшп type hinting позволяет разрешать или запрещать null , вроде бы мелочь

То, как это сделано в пхп для null — это, скорее, не тайп хинтинг, а исключение при использовании тайп хинтинга для дефолтных значений, что уже выглядит дико и коряво.

выглядит дико и коряво.

а начинать каждую функцию с конструкций

if(param == null) {
throw new NullParameterException();
}
не дико и не коряво ?

:)

Какую то глупость вы написали :) Проще написать function (MyAmazingClass $var) — и пхп (и IDE) сделает всё за вас. Если вам необходимо в такую функцию передавать объект || null — то у вас проблемы с дизайном.

то у вас проблемы с дизайном.

неет. ну можно конечно пустые коллекции, например передавать , но иногда это ненужно , проще null

Ну вот, вы сами ответили на свой вопрос :)

Зачем null, если можно создать пустую коллекцию? Тогда и дизайн не выглядит коряво, и лишних проверок в коде (А нулл ли это, или таки коллекция?) можно будет избежать: необходимо будет лишь учитывать варианты «пустая коллекция» и «непустая коллекция», в вашем же случае — ещё и делать проверку, является ли «это» коллекцией. Таким образом, например, можно будет без опасений и лишнего кода итерировать объект, и не опасаться, что какой-нибудь foreach в какой то жопе отвалится c «инвалид аргумент супплаед» :)

тут все от конкретной функциональности зависит.

null и пустая коллекция могут иметь различное значение для функции... даже просто сгенерить ексепшн со своим текстом

ну-ка нука, поподробнее, какой же это чудо язык поддерживает отлавливание не пустых коллекций, или там null ну или то что state обьекта нетакой ?

пустые колекции и нулы это отдельный топик к статической динамической типизации отношение не имеющий.

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

там где надо стоят. обычно на «входе» в систему , эт когда либы писал (эт на с++ больше) так в каждой

НУ вот это работает для вышеуказанных простых страночек. На сложных пртоектах с большим поголовьем людей у тебя после входа в систему еще есть 100500 компонентов которые друг друга вызывают.

пустые колекции и нулы это отдельный топик к статической динамической типизации отношение не имеющий.

очень имеет, потому что такие ошибки чаще случаются, чем ошибки присваивания разных типов

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

вот честно, за три года такой ошибки не встретил, тем более на продакшине

в основном вариации NullPointer и аналогов , от которых статическая типизация не спасет

Это потому что ты тратишь время на то что бы прочитать в доке или полазить по коду что бы выяснить, какой же тип возвращается из метода, с статической типизацией в ИДЕ это все подсвечивается без лишних телодвижений.

НУ вот это работает для вышеуказанных простых страночек. На сложных пртоектах с большим поголовьем людей у тебя после входа в систему еще есть 100500 компонентов которые друг друга вызывают.

если чет вызывается из 100500 компонентов, это уже «вход» и там без проверок никак

Я не говорил что что-то вызывается из 100500 компонентов, я говорил что компоненты вызывают друг друга

ну-ка нука, поподробнее, какой же это чудо язык поддерживает отлавливание не пустых коллекций, или там null ну или то что state обьекта нетакой ?

Spec# например. Там есть контракт NotNull:

public void DoSomething(List<int>! list) { ... }

воот и я про тоже. топовые языки такого не делают

Spec# - надстройка над топовым шарпом, сохраняющая обратную совместимость. Не сложнее использования любой левой библиотеки.

ну я могу сказать что assert єто надстройка над топовым пшп, значительным образом решающая проблему ошибок :)

Времени потерял — аж одну комбинацию клавиш в иде нажать.

Зато по коду четко видно — что куда присваивается, и какая конверсия происходит. А не так, что в продакшене чето кудато сваливается, потомучто инт — не инт вовсе, потомучто гдето ранее неожиданная конверсия произошла.

З.Ы здесь редко встретиш защитнегов динамической слабой типизации.

а какие плюсы дает динамическая сильная типизация?

Она не даст отбалды присвоить стринг инту, и вывалится именно в этом месте, а не черти где потом.

вы опасный программист ! вы от балды код пишете !

А не так, что в продакшене чето кудато сваливается, потомучто инт — не инт вовсе, потомучто гдето ранее неожиданная конверсия произошла.

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

З.Ы здесь редко встретиш защитнегов динамической слабой типизации.

скорее развеивающий мифы о том что статическая типизация несет некий сакральный смысл, а не просто указание компилятору, как именно хранить данные

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

это потому что ошибки типизации уже выявлены и исправлены на этапе компиляции ;-) Остались только ошибки логики. А при использовании динамического языка — все ошибки на месте.

у среднего прогера ошибок типизации (от балды стринг инту присвоил) — 0.0001 . это одна из редчайших ошибок

Это если вы с нуля код пишете, то конечно да. (правда всеравно надо следить, чтобы синтаксическую ошибку не зделать, но то другое...). А вот если вам надо чейто Г-код (а любой чужой код, субъективно таким является) подправить, то тут «ох» нюансы начинаются. Или у вас, у пхпшников, принято все всегда снуля переписовать? :-)

Это если вы с нуля код пишете, то конечно да. (правда всеравно надо следить, чтобы синтаксическую ошибку не зделать, но то другое...).

если у вас «в голове» нет встроенного компилятора то да, но в таком случае никакие иде вам не помешают написать бред

А вот если вам надо чейто Г-код (а любой чужой код, субъективно таким является) подправить, то тут «ох» нюансы начинаются.

по моему опыту проблем особых нет, по крайней мере в пшп.

в той же java часты функции вида f(Interface1 a, Interface2 b) в таком случае да, без типов было бы уныло

скорее развеивающий мифы о том что статическая типизация несет некий сакральный смысл, а не просто указание компилятору, как именно хранить данные

Оно то может на самом деле и просто указания компилятору (который еще и проверки делает). Но на больших системах, когда смотришь чей-то код, и не понимаешь что там за тип, что за входные переменные — это увеличивает геморность поддержки и количество ошибок на порядок

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

по опыту , если код написан нормально, то параметры обычно с именами типа items, count, name и т.д.

так что сразу понимаешь что имелось ввиду

время потерял на набивку лишнего текста

Это наименьшая из возможных проблем в работе программиста.

вот и я о том же. зачем тратить время на угождение компилятора, если его можно потратить на что-то еще

Лучше день потерять, потом за 5 минут долететь ©

Я о том, что чуть более громоздкий синтаксис — это не проблема вообще, если он позволяет писать код с очевидным смыслом. И если есть строгая типизация.

более громоздкий синтаксис — это не проблема вообще

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

ну и избыточность, которая появилась по необходимости (ну не было желания у разработчиков компиляторов усложнять себе жизнь type inference, но хотелось получить достойную скорость выполнения) появился некий карго-культ , который теперь живет своей жизнью , при том, что все последние разработки языков программирования уходят от этого так или иначе

язык предоставляет возможности, этого достаточно

Как оказывается недостаточно. Десятки тысяч обезьянок педалят код не используя указатели типов. Вот ты сам используешь их везде?

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

Это все даже теоретически невозможно реализовать, потому что в ИДЕ/вим не знает что конкретно может лежать в переменной.

а что там — тот же hiphop мордокнижный выводит типы и компилит в нативные

О как по твоему хип-хоп решает вышеописанную проблему?

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

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

зачем ручками что-то приводить туда сюда? откуда ты это взял?

т.е. усложняя компилятор всеравно получаем пшп ? в чем профит ?

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

не используя указатели типов. Вот ты сам используешь их везде?

только там где это действительно нужно

Это все даже теоретически невозможно реализовать, потому что в ИДЕ/вим не знает что конкретно может лежать в переменной.

О как по твоему хип-хоп решает вышеописанную проблему?

та лана, а как скала\груви и с++ последний узнают ?

также и остальные, ничего сверхъестественного тут нет

зачем ручками что-то приводить туда сюда? откуда ты это взял?

ну умный фреймворк сам конвертнет, если его попросить ... но есть ли в этом смысл

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

невозможно обеспечить и лаконичность и читабельность одновременно. на выхлопе будет либо криптотекст либо си

с плюшками статической типизации описанными мной выше.

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

та лана, а как скала\груви и с++ последний узнают ?

также и остальные, ничего сверхъестественного тут нет

Очевидно груви эту проблему не решает, а скала груви джава и прочие решают с помощью статической типизации

ну умный фреймворк сам конвертнет, если его попросить ... но есть ли в этом смысл

Какой фреймворк? Можешь привети конкретнуй пример?

невозможно обеспечить и лаконичность и читабельность одновременно. на выхлопе будет либо криптотекст либо си

Ок, пых пых локаничный или читабельный?

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

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

Ну и я кроме проверок еще кучу плюшек вроде назвал, которые для меня крайне критичны.

Очевидно груви эту проблему не решает, а скала груви джава и прочие решают с помощью статической типизации

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

Какой фреймворк? Можешь привети конкретнуй пример?

та вроде веб фреймворки статических языков (дотнет, java, c++) позволяют получить не просто string а уже приведенный к чему-то int там например :)

Ок, пых пых локаничный или читабельный?

читабельный, как и си

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

Ну и я кроме проверок еще кучу плюшек вроде назвал, которые для меня крайне критичны.

я не заметил плюшек, присущих только статически типизированным языкам

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

Как это не указал, указал, на то и статическая типизация

та вроде веб фреймворки статических языков (дотнет, java, c++) позволяют получить не просто string а уже приведенный к чему-то int там например :)

Ок, какое это имеет отношение к статической/динамоческой типизации?

читабельный, как и си

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

я не заметил плюшек, присущих только статически типизированным языкам

Еще раз: рефакторинг, code completion, браузинг кода(когда наводишь курсорчиком на переменную и говоришь отправь ка меня на место где определен класс типа этой переменной), всего этого для скриптовых языков нету, и принципиально не возможно, ну и скорость к слову.

Как это не указал, указал, на то и статическая типизация

про такую штуку слыхали ?

en.wikipedia.org/.../Type_inference

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

каких ?

Еще раз: рефакторинг, code completion, браузинг кода(когда наводишь курсорчиком на переменную и говоришь отправь ка меня на место где определен класс типа этой переменной), всего этого для скриптовых языков нету, и принципиально не возможно, ну и скорость к слову.

кто вам сказал что это невозможно ? еще три года назад в это все в эклипсе было под пшп

под vim это сделано несколько по другому, он просто разбивает текст на «слова» и «абзацы» и предоставляет возможность легко прыгать по ним

про такую штуку слыхали ?

en.wikipedia.org/.../Type_inference

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

каких ?

Уже перечислил раз пять.

кто вам сказал что это невозможно ? еще три года назад в это все в эклипсе было под пшп

В каком эклипсе? В ПДТ ничего такого не было. В зенд студии есть несколько ограниченных вариантов, типа переименовать локальную переменную или экстрактнуть метод. Автокомплита для кода или навигации как в моем примере не наблюдается.

под vim это сделано несколько по другому, он просто разбивает текст на «слова» и «абзацы» и предоставляет возможность легко прыгать по ним

Это конечно же несопоставимый уровень удобства

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

что тип может выводиться и парсером иде

Уже перечислил раз пять.

это не плюшки статически типизированного языка, это плюшки иде , они доступны и в динамических языках

В каком эклипсе? В ПДТ ничего такого не было. В зенд студии есть несколько ограниченных вариантов, типа переименовать локальную переменную или экстрактнуть метод. Автокомплита для кода или навигации как в моем примере не наблюдается.

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

Это конечно же несопоставимый уровень удобства

для меня лично оказалось удобнее

что тип может выводиться и парсером иде

Да, это все работает для статической типизации, для динамической нет, т.к. не из чего выводить, тебе пришла переменная в метод, нет никакого знания о том какого она типа.

это плюшки иде , они доступны и в динамических языках

Исключительно в каком то сказочном эклипсе который ты только один видел

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

Ну так поделись травой в каком таком эклипсе ты это видел?

для меня лично оказалось удобнее

Ну да, ты ж в нормальной ИДЕ не программил

Да, это все работает для статической типизации, для динамической нет, т.к. не из чего выводить, тебе пришла переменная в метод, нет никакого знания о том какого она типа.

та ну. она же пришла из другого метода ... иде может глянуть

я так помню эклипс (да и студия) парсят весь проект, а не один файл\функцию

А там куча других проблем появляется
— в вызывающем методе в вызов опускается другая переменная тип которой тоже не так что бы известен
— есть вызов a.m©, непонятно это вызов твоего класса или какого то другого класса с таким же именем метода, и т.д.
— в некоторых язычках типа питона методы и переменные в обьекты можно вообще в рантайме добавлять, так что вообще ховайся

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

вот нагуглил

www.jetbrains.com/...gent_PHP_Editor

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

впринципе затыков немного — там где информация о типе не доступна вообще, типа содержимого коллекции возвращенной из вызова экстеншна, eval динамического кода и «вход» данных от пользователя, ну и страшный вариант когда переменная может принимать разные типы :)

все остальное можно выковырнуть хорошим парсером

— в вызывающем методе в вызов опускается другая переменная тип которой тоже не так что бы известен

ну так идти по дереву вызовов, рано или поздно объявление найдется

— есть вызов a.m©, непонятно это вызов твоего класса или какого то другого класса с таким же именем метода, и т.д.

шо за ам ?

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

— в некоторых язычках типа питона методы и переменные в обьекты можно вообще в рантайме добавлять, так что вообще ховайся

там по ссылке один из примеров как раз про это

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

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

ну так идти по дереву вызовов, рано или поздно объявление найдется

Ну вот реалистично такое или нет меня как раз и интересует и берут сомнения

шо за ам ?

это парсер поел, имелось в виду a.m( c )

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

ну да, и все как обычно упирается в узнать тип переменной

там по ссылке один из примеров как раз про это

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

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

мелочное замечание
это же примеры и там видно что они выкусывают поля динамически добавленные в другом методе

раз они могут такое выкусить, то неважно где функция находится

Ну вот реалистично такое или нет меня как раз и интересует и берут сомнения

ити по дереву вызовов — гм. у меня вим ходит вверх и вниз , так он как бы древний-древний

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

ну да, и все как обычно упирается в узнать тип переменной

тю, ну если c++ как-то узнает, и хаскель как-то узнает, и всякие го, то какая проблема узнать ? головняк разве что парсер написать

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

так ли уж часты такие случаи, что бы это стало непроходимой проблемой ?

как по мне — то в большинстве случаев оно будет работать прекрасно, а те частные ... ну не судьба

мелочное замечание
это же примеры и там видно что они выкусывают поля динамически добавленные в другом методе

раз они могут такое выкусить, то неважно где функция находится

та нет не мелочное. оно распознает только методы добавленные в конструкторе. Если функция добавлена в другом месте, то уже не работает. Специально скачал пхпсторм и проверил.

ити по дереву вызовов — гм. у меня вим ходит вверх и вниз , так он как бы древний-древний

Ну вот твой метод вызывается из 20 других мест, куда там твой вим в этом случае ходит?

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

отож бо й воно

тю, ну если c++ как-то узнает, и хаскель как-то узнает, и всякие го, то какая проблема узнать ? головняк разве что парсер написат

правильно, потому что ц++ и хаскель статически типизированы, и в любом месте есть информация о том какого типа переменная

А пыхпых нет

так ли уж часты такие случаи, что бы это стало непроходимой проблемой ?

Думаю таких случаев большинство

та нет не мелочное. оно распознает только методы добавленные в конструкторе. Если функция добавлена в другом месте, то уже не работает. Специально скачал пхпсторм и проверил.

ну идеала нет. да

Ну вот твой метод вызывается из 20 других мест, куда там твой вим в этом случае ходит?

он выдает список мест откуда происходит вызов, дальше сам решаешь

правильно, потому что ц++ и хаскель статически типизированы, и в любом месте есть информация о том какого типа переменная

А пыхпых нет

гм.

в хаскеле типы выводятся во время компиляции. там не надо писать все время int/string и т.д (хотя и считается правилом хорошего тона)

Думаю таких случаев большинство

мне опыт подсказывает обратное

он выдает список мест откуда происходит вызов, дальше сам решаешь

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

м.

в хаскеле типы выводятся во время компиляции. там не надо писать все время int/string и т.д (хотя и считается правилом хорошего тона)

Хаскель это обратный пример, т.к. крутостью ИДЕ тоже не блещет.

мне опыт подсказывает обратное

Какой опыт? Ты же в виме без плюшек програмишь?

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

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

т.е. получить тип переменной y созданной в методах x1, x2, x3 не составляет труда

Какой опыт? Ты же в виме без плюшек програмишь?

ну на виме я два года только.

впринципе я года полтора возился с c# , т.е. code completion точный видел, не сказал бы что он вот так необходим, разве что по началу, потом скорость набивки кода получается быстрее без него, если конечно названия функций\методов не по 30 символов

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

т.е. получить тип переменной y созданной в методах x1, x2, x3 не составляет труда

Думаю что компиллер не строит синтаксическое дерево прям всего проекта, а только дерево текущей функции и сигнатуры классов и методов(без разбора внутренностей), аналогично с code completion.

ну на виме я два года только.

впринципе я года полтора возился с c# , т.е. code completion точный видел, не сказал бы что он вот так необходим, разве что по началу, потом скорость набивки кода получается быстрее без него, если конечно названия функций\методов не по 30 символов

А я вот свитчаюсь постоянно между джавой и питоном, и разница крайне разительна, и не только в code completion, но и рефакторинге, и браузинге кода(примеры я приводил)

Думаю что компиллер не строит синтаксическое дерево прям всего проекта, а только дерево текущей функции и сигнатуры классов и методов(без разбора внутренностей), аналогично с code completion.

строит все, иначе он не сможет работать нормально ни по скорости ни по качеству

А я вот свитчаюсь постоянно между джавой и питоном, и разница крайне разительна, и не только в code completion, но и рефакторинге, и браузинге кода(примеры я приводил)

обычная проблема, ты пытаешься свои паттерны перенести в другой язык\среду, а не найти\изучить подходящие.
когда-то я не понимал, почему в опен-соурсе нет нормальной иде, при том что кодят ведь и много и сложные большие системы, толпой народа... каак ?
потом появился тот же еклипс — новодел, но ! написанный джавистами ... что, никому больше не надо ?

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

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

tags обеспечивают быстрое code-completion, пусть и в простом виде

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

точнее понятно — для начинающих прогеров, потому что vim/emacs/консоль это очень сложно, далеко не каждый осилит

строит все, иначе он не сможет работать нормально ни по скорости ни по качеству

Он строит, но инкрементально, т.е. никогда в памяти все не держит, разобрал функцию, сгенерировал код, и забыл. А в твоем подходе нужно это дерево все время пересчитывать на каждое изменение, что бы выводить типы переменных. Ну и у тебя вообще какие то пруфлинки есть что где то то о чем ты говоришь реализовано? Скажи где, я проверю.

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

потом появился тот же еклипс — новодел, но !

шота мне подсказывает что эклипс появился задолго до всяких *tags.

точнее понятно — для начинающих прогеров, потому что vim/emacs/консоль это очень сложно, далеко не каждый осилит

это все бла-бла

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

Он строит, но инкрементально, т.е. никогда в памяти все не держит, разобрал функцию, сгенерировал код, и забыл. А в твоем подходе нужно это дерево все время пересчитывать на каждое изменение, что бы выводить типы переменных. Ну и у тебя вообще какие то пруфлинки есть что где то то о чем ты говоришь реализовано? Скажи где, я проверю.

каждый раз парсить — никакого проца не хватит, кеширование ? слышали такое
описание тут
wiki.eclipse.org/...re_Architecture
глубже
dev.eclipse.org/...hnology_Project

там ast и его сохранение

шота мне подсказывает что эклипс появился задолго до всяких *tags.

твое шота тебя подвело.
1982

кстати, прикол, чувак который ctags сделал потом работал в сане, писал джаву :)

это все бла-бла

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

я вот немного поглядел исходники dltk — я понимаю о чем ты. в языке где названия классов длиной в строку без code completion делать нечего.

каждый раз парсить — никакого проца не хватит, кеширование ? слышали такое
описание тут
wiki.eclipse.org/...re_Architecture
глубже
dev.eclipse.org/...hnology_Project

там ast и его сохранение

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

я вот немного поглядел исходники dltk — я понимаю о чем ты. в языке где названия классов длиной в строку без code completion делать нечего.

это все лирика, можно именовать и так и эдак, но суть сказанного мной выше не меняется

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

я привел конкретный пример — haskel.
но я по свободе проверю бинс\еклипс. как там оно,

но судя по исходникам єклипс лезет в индексы, которые содержат ast внутренности каждого метода — вплоть до циклов и т.д.

было бы глупо иметь данные и не использовать их :)

ну и просто если бы я писал code completion — я бы так и делал.

это все лирика, можно именовать и так и эдак, но суть сказанного мной выше не меняется

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

я привел конкретный пример — haskel.

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

которые содержат ast внутренности каждого метода — вплоть до циклов и т.д.

откуда ты такое взял?

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

это отличие больших проектов и маленьких.

Мне тяжело понять как в большом проекте можно помнить все методы всех классов, что бы необходимость в auto completion отпала.

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

глянул

откуда ты такое взял?

исходники посмотрел

это отличие больших проектов и маленьких.

Мне тяжело понять как в большом проекте можно помнить все методы всех классов, что бы необходимость в auto completion отпала.

если ты их не помнишь название — перепрыгиваешь в исходник класса(открываешь область доки) и прыгаешь по сигнатурам (либо «быстро ищешь»)
если примерно помнишь название — tags based code completion тебе помогает
длинный список параметров — перехожу на метод, копирую от туда.

т.е. по сути это как бы продвинутый code completion — когда кроме сигнатуры и иногда доки, ты можешь посмотреть также и код, при том что все заточено под то, что бы делать минимум телодвижений

глянул

исходники посмотрел

не поделишься линками где ты такое увидел?
если ты их не помнишь название — перепрыгиваешь в исходник класса(открываешь область доки) и прыгаешь по сигнатурам (либо «быстро ищешь»)
если примерно помнишь название — tags based code completion тебе помогает

длинный список параметров — перехожу на метод, копирую от туда.

вроде ты еще не нашел инструмента который тебе подсвечивает тип переменной в пыхпыхе, т.е. тебе нужно еще пройтись по цепочке вызовов метода и совершенно без всякой гарантии на успех попытаться найти какое значение забрасывается в переменную.
То о чем ты пишешь я уже упоминал, это удар по твоей продуктивности, т.к. code completion позволяет джава программисту сделать все это за пол секунды без лишних телодвижений.

И это только code completion, а еще есть рефакторинг, и подсветка ошибок в коде(пыхпыхшторм подсвечивает далеко не все)

не поделишься линками где ты такое увидел?

по хаскелю — www.google.com/... type inference
по pde — я линк на исходники давал, dltk

если не хочется пачкаться руками в java код, просто проверьте в любой иде — возможность получения иерархии вызовов (я проверял, работает) и собственно вычисление типа переменной (вы подтвердили, работает), почему они не складывают 1+1 — я не знаю, наверное java кодеры, которые пишут storm\pde — ленивцы

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

я подтвердил, не нашел, думал что сделали... увы

То о чем ты пишешь я уже упоминал, это удар по твоей продуктивности,

ты путаешь sloc и производительность,
я ж не кодю по спецификации присланной старшими товарищами, я решаю проблемы — сверху до низу, от юзабилити до оптимизации запросов к бд.

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

т.к. code completion позволяет джава программисту сделать все это за пол секунды без лишних телодвижений.

И это только code completion, а еще есть рефакторинг, и подсветка ошибок в коде(пыхпыхшторм подсвечивает далеко не все)

когда я был молодым начинающим программистом — я тоже так думал, особенно когда в году 97 запустил vim и не понял, каак на этом пишут программы ? тем более у меня под рукой было делфи, которая по сути (за счет lr синтаксиса и rtti) имела тот же набор фич, что и нынешняя java, как минимум, code completion там работало аж бегом.

так что раньше я бы не понял как эта пикающая и портящая все фигня (vim) может быть удобна.
и я вас очень понимаю

но сейчас лично мне удобнее vim

по хаскелю — www.google.com... type inference

я непонимаю как эта линка пролевает свет на устройство хаскель компиллера

по pde — я линк на исходники давал, dltk
если не хочется пачкаться руками в java код

я вот как раз посмотрел код, там есть модель ast, и вот всякие арифметические преобразования, циклы и ифы там не увидел, может ты увидел? Потому и спрашиваю

возможность получения иерархии вызовов (я проверял, работает) и собственно вычисление типа переменной (вы подтвердили, работает), почему они не складывают 1+1 — я не знаю, наверное java кодеры, которые пишут storm\pde — ленивцы

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

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

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

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

когда я был молодым начинающим программистом — я тоже так думал, особенно когда в году 97 запустил vim и не понял, каак на этом пишут программы ? тем более у меня под рукой было делфи, которая по сути (за счет lr синтаксиса и rtti) имела тот же набор фич, что и нынешняя java, как минимум, code completion там работало аж бегом.
так что раньше я бы не понял как эта пикающая и портящая все фигня (vim) может быть удобна.
и я вас очень понимаю

но сейчас лично мне удобнее vim

опять же, это все лирика неумоляющая полезность плюшек ИДЕ.

я непонимаю как эта линка пролевает свет на устройство хаскель компиллера

ну там описывается как он резолвит типы при взгляде сверху, как это имплементировано — хз. проще исходники скачать

я вот как раз посмотрел код, там есть модель ast, и вот всякие арифметические преобразования, циклы и ифы там не увидел, может ты увидел? Потому и спрашиваю

dev.eclipse.org/...t=Tools_Project

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

если во время парсинга эту инфу закешировать/заиндексировать , то вся сложность — просто пройти по списку.

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

так я за всех и не утверждаю :)

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

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

ну там описывается как он резолвит типы при взгляде сверху, как это имплементировано — хз. проще исходники скачать

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

dev.eclipse.org/...t=Tools_Project

Ok, я смотрел только core dtl, а это внутренности пхп плагина. Но эклипс же от них абстрагирован, и юзать не может?

если во время парсинга эту инфу закешировать/заиндексировать , то вся сложность — просто пройти по списку.

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

Ну и вообще в чем смысл этого теоретического спора если выяснили уже что такое никто и никогда не реализовывал?

таки да, не работает.

т.е. все данные есть — стек вызовов, информация о переменных, но вместе не сложили... бездельники

Странно, у меня в NetBeans подобный переход получается, ну и если в phpdock-блоке переменные описывать -имеем ещё больший профит (для функций, методов и классов).

да по-моему сейчас много сложных страничек — это client side, за которым стоит рестфул апи

ну фейсбук и конактик совсем простенькие.

а вот твиттер очень сложный и при этом работает как часы

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

си\с++ - тут конечно здорово — продукты, железяки... но рынок тут мал, ибо почти не аутсоурсят

унылый корпоративный софт

какой софт не унылый?

какой софт не унылый?

ну если продукт, да еще популярный. то вроде и ничего так

Оце почитаєш таке і задумаєшся, а потім зайдеш в розділ вакансій і заспокоївся=))

Початківців як і раніше наймають за копійки, але якщо вже є 3-4 роки досвіду — все в ажурі, жити будем=)

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

Есть ложь, большая ложь и статистика. И есть еще извращения статистики. Фриланс-статистика показывает, что таки да — на руби средняя оплата за заказ в 2 раза выше, но заказов — на порядок меньше. Простонародно говоря, это означает — если безумно крут, то руби д.б. денежнее, если хотя бы просто крут — то уже пых на коне.

Я бы вам посоветовал для начала определиться чего вы лично для себя хотите. Карьерного роста и не важно на каком языке, стабильной работы в крупной компании, иметь много вакансий в Украине по направлению где вы хорошо разбираетесь, возможность писать на форумах что Руби это круто а ПХП это недоязык или другие варианты. Это самое главное.

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

Как обстоит дела с руби и фрилансом я не в курсе.

Здравствуйте. Меня зовут Вячеслав, мне 22 года и я пхп программист. Я сижу на пхп с 18 лет.

Первый раз я попробовал пхп с другом. Мы сидели, обсуждали веб-технологии и тут он сказал, что недавно пробовал пхп. Он предложил попробовать мне. Поначалу я не согласился, ведь это пхп, я слышал много плохих слухов про него, слышал, что он вызывает зависимость. Но друг настаивал, говорил, что в жизни нужно попробовать все и я сдался. Он предложил бесплатный скрипт, выводящий «Hello world!». Он казался совсем безобидным, но как потом оказалось, я уже не мог остановиться.

Уже очень скоро благодаря пхп я попробовал свою первую cms. Это сейчас я понимаю, насколько опасным был этот шаг, но тогда я ничего не понимал, и мне это нравилось. Я не заметил, как после первой испробованной cms, мне уже захотелось написать свою. Дальше было только хуже. Я уже рискнул попробовать кое что потяжелее. Я решил попробовать свой первый фреймворк. Это было прекрасно. Но это была дорога в никуда.

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

Я попал в этот капкан пхп и теперь не могу самостоятельно избавиться от этого, моя жизнь сломана. Если бы мог вернуться в то время, я бы все исправил, и никогда не купился на эту уловку.

я бы все исправил, и никогда не купился на эту уловку

И выбрал бы что-то потяжелее?

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

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

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

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

И почему тогда он еще не в мейнстриме ?

Руби как раз самый, что ни на есть мейнстим. Практически все что есть вокруг или Руби (capistrano, chef, puppet, knife) или слизано с Руби (Ruby on Rails, ActiveRecords, Db Migration)

так а сам руби то чего не в мейнстриме?

Покажите мне хоть 1 большой проект где внутри не используется Руби ? Не это ли менстрим. Делать формы и сайты визиток != делать продукт.

вы троллите или серьезно? :) любой продукт ibm, google, oracle, microsoft, <companyname> возможно за небольшими исключениями

Как ни удивительно но гугл, фейсбук и imb используют puppet :)

ну продукт написанный на руби вовсе ведь не равно руби?

с таким же успехом бейсик с дельфи сейчас самый мейнстрим.

Бейсик как раз и не используется вместе с дельфи т/к/ что ? Для них нет инструментов :) ни деплоя ни сборки ни тестирования — что фактически означает фейл в поддержке любого более менее крупного проекта.

ну не смотря на то, что у руби есть это всё крупных проектов практически нет

Уточню: 78% крупных проектов на PHP, 20% на ASP.net, 4% на JAVA и только 0.5% на Ruby.

Это откуда такая информация?

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

Там результаты какого то опроса с непонятным количеством участников

Где там такое написанно?

Прям в названии: W3Techs — World Wide Web Technology Surveys

Как бы то ни было, статистические данные с Алексы.

Какие данные? Там написано что они пускают к голосованию только сайты из alexa top миллион, на этом данные вроде заканчиваются.

вабщета там написано что они сканят первый миллион из топа алексы
правды для они не все корректно считают, вот по моей работе они язык не смогли определить, хотя все остальные данные вроде ок

так что к пшп надо добавить еще один сайт.

там survey как исследование, а не как опрос. почитайте внимательнее методологию исследования.

Гитхаб, пивотал например и больше ничего не слышал

ну есть адепты, но это исключение из правил

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

Навскидку:

zendesk (я тут работаю), платформа для обработки заявок в саппорт — нагрузка на продакшен колеблется между 30-70 тысяч запросов в минуту
shopify, решение для интернет-магазина — 40000 интернет магазинов его клиенты.

groupon, basecamp и github до кучи.

Понятно, что на сишарпе и джаве хайлоад проектов больше, но говорить о том, что на руби ничего серьезного нет — это уже года три, а то и пять, как моветон.

zendesk (я тут работаю), платформа для обработки заявок в саппорт — нагрузка на продакшен колеблется между 30-70 тысяч запросов в секунду

Заливай кому нибудь другому

В минуту, сорри, ошибся.

imgur.com/2iDFL — эта фотка тебя переубедит?

Ваша картинка ниочем не говорит. Разве что о состоянии колоны к которой прикреплен монитор.

Откуда я знаю что это трафик на руби фронтенд? На самом деле зенддеск постил статистику годик назад, там было 10млн запросов в день, что уже совсем не бигдил

Для них нет инструментов :)

О мертвых или хорошо или ничего

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

Да сколько угодно. Высоконагруженный энтерпрайз на джаве чем не пример. А вместо руби можно пайтон юзать, он менее тормозит чем руби

Проблемы не в языке, а в голове. У питона свой GIT есть.

Мнимая проиводительность языка никак не связана с проиводительностью приложения, писать хорошо или плохо можно на любом языке.

У питона свой GIT есть.

О, профессионализм попер.

Проблемы не в языке, а в голове. Мнимая проиводительность языка никак не связана с проиводительностью приложения, писать хорошо или плохо можно на любом языке.

Да неужели, а что же твитер с руби то слез а фейсбук зачем то hiphop пилит и активно плюсы юзает? У них тоже проблемы в голове?

1 Твитер пока еще не слез — но пытается пойти дальше.
2. facebook зажат в своей же архитектуре. При 1000+ серверов + 5% проиводитльности = экономия в 50 серверов.

Все определаяется деньгами — в данный момент для компаний это экономически выгодно. Но перед тем как дорасти до этого этапа нужно пройти этапы роста и становления продукта и тут как раз находиться 90% всех.

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

Twitter давно server-side перевел на Scala, RoR — только фронт-енд обслуживает.

Твитер пока еще не слез

Как оно в прошлом живется?

Реализацию паттерна ActiveRecord пытаются слизать все кому не лень, указывая на изначальный истоник, то как это сделано и работает в Ruby on Rails.

да всё это здорово, однако это не отменяет того факта, что руби даже для веба не мейнстрим

Я же не спорю что спрос на формошлепство больше. Мы говрим о менстриме в разрезе «разработки ПО». А тут собственно с/с++, java(closure), ruby. И наличие множества инстурументов на Руби, только подтверждение вышеописаного факта.

ну не стоит руби ставить в один ряд с жавой и с++

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

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

Скорее Ruby это платформа из которой можно многому научиться и после этого использовать подходы в других языках если нужно.
Как всегда логика ленейна:
за знание php платят — X
за знание ruby — Y
За знание обоих обычно X*Y :)

Знать больше — это всегда в +.

какая-то у вас дикая арифметика.

исходя из того, что миддл пхп и руби в среднем 2000 по вашему выходит, что знание и того и другого принесет зарплату в 4 000 000

Гениально. К твоему сведению Фаулер придумал ActiveRecord в своей книжке в 2003-ем, а РоР вышел в 2004-ом.

Руби не родина слонов случайно?

Перед тем как писать, иногда стоит читать :)
Читать отсюда "

Реализацию паттерна ActiveRecord

"

Давай по пунктам? Кто эти «все кому не лень»? Почему ты считаешь что эти «все кому не лень» пытаются слизать паттетн именно с руби?

Ок, есть ссылки на какие то noname фреймворки, это и есть твои «все кому ни лень»? А теперь не потрудишься ли ответить на мой вопрос с чего ты взял что эти noname фреймворку слизали activerecords именно с RoR?

1. Прекратите тыкать.
2. Иногда стоит все же открыть сслыку

screencast.com/t/Sac7eLaEdw

1. Прекратите тыкать.
2. Иногда стоит все же открыть сслыку

screencast.com/t/Sac7eLaEdw

1. Абайдешься.

2. Там по делу только первая ссылка, остальные твои выстрелы в молоко.

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

Это все мелочи. Самое веселое начинается когда источников данных появляется больше чем один или пытаешься выделить сервисный слой. Active Record itself применим только для крайне небольших проектов, чють крупнее и все бенефиты заканчиваются на том что код модели содержит 1000+ строк кода и это уже проблема.

Да я люблю Руюи. но это не мешает мне знать и другие языки. Руби красив сам по себе. На сегодняшний день это практически едиственный полностью объектный язык программирования в котором объектом явлется все + конечно красота замыканий, блоков, миксинов, динамического monkey patching есть нужно пофиксить системную библиотеку мммм.

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

а Вы попробуйте написать что-то посложней «Привет Мир» ) и ответ тут-же прийдет

Да тому шо всі подивились на плюшки, які дає Ruby та RoR зокрема і зрозуміли шо далі жити так неможна. Зібрались з думками і почали клепати свої велосипеди, шоб і собі було так зручно. Тільки от не виходить так органічно як в Ruby зробити.
Як мову програмування, Ruby можна проігнорувати. Як платформу для розробки — неварто. Якісна екосистема, розвинені інструменти — ось головні переваги Ruby (поряд з тим шо і мова програмування як на мій погляд дуже потужна).

Тим не менше в PHP не все так погано. Останнім часом PHP як мова швидко еволюціонує, вбирає в себе кращі рішення з інших областей (функції вищого порядку, анонімні функції, замикання, traits, unicode...). Тим часом платформа також не стоїть на місці — Composer, куча якісних фреймворків (Yii, Symfony...), утиліт тестування, тощо. І неважливо, шо це все з’явилось в когось іншого, важливо шо це працюю тут і зараз.

Так шо основні причини: небажання (і недоцільність з економічної сторони) переходити на іншу платформу і поява тих же засобів в рідній екосистемі. Еволюція одним словом.

— От тебя попахивает оптимизмом! Ты что, радовался жизни?

— Мамочка, это не я, на меня надышали!

Вообще я в свое время читал из кучи источников что ПХП — вообще жуткий отстой, и что начинающему программисту вообще не стоит за него браться.

Поэтому нужно мыслить и проверять, а не доверяться тому, что говорят/пишут. Тоже самое работает и в бизнесе.

Уже бы Scala изучал, больше было бы толку, как для Java программиста и сама Скала более православная чем руби.

Для джава программистов есть груви с грельсами, который почти руби с рельсами, только джава ;-)
Скала, всеже из другой оперы.

В чем его монстроидальность? Scala адекватный язык, с хорошей методологией, в то время как Ruby профанская подделка под такие языки как Scala.

Видно, что вы в матчасти не особо сильны. Scala — полноценный функциональный язык, который согласуется с теорией функциональных языков. К тому же в Scala ООП, который хорошо согласуется с его функциональной частью, при этом в Scala синтаксис близок к императивным языкам, что бы не сильно запутать переходящих с Java программистов.

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

PS «слабый» конечно не очень удачное слово.

После этой фразы с вами разговаривать неочем. :) Вы хоть Scala в глаза видели, кроме как на википедии? Судя по всему нет.

ну если читал, то скажи, чего нету в Scala, что есть в Haskell?

ты плохо гуглил. Есть монады в скала. Слушай, если ты споришь на тему используй нормальную терминологию, что значит система типов мощнее? Я незнаю такого термина. :) Наличие ленивости по умолчанию не делает один язык более функциональным чем другой, так же как и различия между типизацией.

Пожалуй единственный пока твой аргумент — это о чистоте, которая в Scala да, больше зависит от самодисциплины программиста. Но синтаксис Scala позволяет писать настолько же чистые программы, как на Haskell.

Монады — это теоретическая концепция. Если бы ты доку действительно читал, то знал бы, что в Scala ключевых слов мало, все реализовано библиотеками, так что теперь говорить, что это бедный язык? Тогда можно сказать, что Ruby — это Cишная библиотека, языка по сути нету. ;)

тоесть руби, как раз богат синтаксическим сахаром.

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

ну да, у дальтоников и нормальных людей разные взгляд на цвет. ;)

Да, интересно было бы послушать что там не так с ФП

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

я конечно не специалист и могу ошибаться, но разве ООП хоть как-то ложится на функциональную парадигму?

Скала какраз и есть сферическая имплементация «ООП ложащегося на функциональную парадигму».

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

ну практически противоположность

В ООП у обьекта состояние не обязательно мутабельное.

то-есть объект просто как обвёртка для аргументов функции и отсутствие методов?

стоит ли игра свеч?

Обертка с всеми прелестями ООП, инкапсуляцией наследованое, полиморфизмом, поведением, и т.д. Однозначно стоит.

Ну стейт то в любом случае вам нужен, иначе ваша программа практически бесполезна ;-)

ну именно по-этому функциональное программирование — нишевая парадигма

Scala не pure-functional язык. Так же есть интересные штуки в скала как case class, которые только дополняют функциональную парадигму. ООП не конкурирующая парадигма к функциональной, а паралельная, они очень хорошо вместе сосуществуют.

Influenced by Eiffel, Erlang, Haskell,[3] Java, Lisp,[4] Pizza,[5] Standard ML, OCaml, Scheme, Smalltalk

простая вырезка из вики говорит о том, что влияния руби он не испытал.

А если быть откровенным — просто джава с нахлобучками и синтаксическим сахаром

Really ?

В чем схожесть собственно? Поставь Scala .net будет схожесть C#. Будет тебе нахлобучка на C#. Просто разработчики скала приняли верное решение использовать популярный кросс-платформенный JVM, и также сделать врапперы над проверенными временем библиотеками, а это большой парк программистов и библиотек, что дает плюс в копилку языка, ведь язык относительно молодой.

Принципы и языковые конструкции совершенно разные. Если ты этого не понимаешь это как раз говорит о том, что ты доки в глаза не видел, а если и видел то ничего с них не понял.

Например, в Scala все объект, даже функции.

Ну со времен С++ ООП парадигма в мейнстриме одна и таже, за исключением жс.

Да ладно, в Objective-C совсем другое ООП

Просто разработчики скала приняли верное решение использовать популярный кросс-платформенный JVM

Вообще то Скалу сделали и под Джаву, и под ДотНет.

Я это отметил, но дотНет пока не финальный, насколько я знаю.

С такимже успехом С++ -кучка нахлабучек над С )))

Ну или Сам руби — нахлабучка над самим пэхэпе.

а если jruby vs jphp vs java vs scala vs jc++ ? )))

ты так говоришь, что если перейдешь на руби, то забудешь пхп и если что больше не найдешь по нему вакансию :). 2 технологии знать лучше, чем одну. В чем логика твоего страха?

да? railsforzombies.org

(если что, курс очень неплохой)

Еще меня смущает, что если перейду на RoR, то выбор вакансий у нас в стране не очень велик.

не скажу, як по всій Україні, але у Львові майже половина фірм має таку вакансію. Стукайте))

Вместе с тем читал, что рейт у руби программистов значительно выше, чем у пхпшников

Можливо, але середньостатистичний початковий, надалі — вирівнюється.

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

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

Я сменил PHP на Ruby три года назад исключительно из-за симпатии к синтаксису.

На Украинских сайтах действительно вакансий маловато но наша работа (к счастью) географически не ограничена. Если Вы будете хорошо знать руби — работы у Вас будет достаточно.

Вы имеете ввиду фриланс? Почему тогда там работы достаточно, а в местных конторах нет?

Никогда не интересовался этим вопросом. Возможно потому что фрилансеры дешевле

Да в любом случае знание дополнительных языков программирования это только плюс

Руби — мертворождённый язык, для хипстеров и стартапов, без перспектив в Украине. Вы хипстер, пишущий стартап?

Хотите поднимать сотни бабла на похапэ — учите пхп-фпм, нжинксы, перконы + стек их по, ораклы, no-sql’ы, сфинксы с люценами, зенды\yii\симфони, шаблоны проектирования, методы хранения структур данных, ооп + иные парадигмы, методы оптимизации всего, чего можно наоптимизировать, бенчмаркинг, профайлинг (бд, код, qa), линуксы уровня аппер убунтиум, глубокое понимание работы %RDBMS-name% и пхп, php.net в конце концов штудируйте, там много чего интересного, читайте хабр. За год средней напряженности межушного нерва достигнете высокооплачиваемых высот. Этого хватит со скромностью на $2500, наклеите синиорско-лидские лычки — и на 3к вытянете. Дальше — больше: теория алгоритмов, масштабирование, облака, кластера, репликации, хадупы-редьюсы — и будете красавчиком на расхват у рекрутёров. Для увеличения ЧСВ и привлекательности у забугорных работодателей пройдите сертификацию ZCE — на таких программистов у западных рекрутёров перманентный стояк, вдруг решите покупать трактор?

А с руби будет Ад и Израиль, везущий вас в бездну уныния. По рельсам, да.

Да, вы правы: больше, чем С, меньше, блджад, СИЛЬНО МЕНЬШЕ, чем руби :)

у руби однопроходность, пшп в этом смысле чуть получше да еще и с кешем байткода... для крайних случаев есть HHVM/hiphop — скорость можно как минимум удвоить

Берем jruby и вуаля — jit compiler все делает за нас :)
Зачем изобретать велосипед который к тому же еще с квадрамтными колесами ?

Сначала этот самый hiphop стоит попробывать чтоб говрить о нем как о законченом решении.

Не могу не ответить на это классической копипастой:

Только это всё не нужно. Ваш сайт, результат вашей работы никогда не получит хоть какой-то нагрузки. Когда на ресурс заходит 10 человек в день, а 90% хитов совершают боты гугла, можно **ярить страницы на 50, и даже на 150 SQL-запросов, ведь все таблицы бд влезают в оперативку, и страница даже на каком-нибудь позапрошлогоднем zend framework без твиков соберётся менее, чем за секунду. Да какой там фреймворк! Какой там MVC! Проще дёргать по необходимости разнородные готовые куски, часть кода бросить голодным доширак-макакам, и склеить всё воедино лишь-бы-работало спагетти-кодом. Ведь проект нужно было сдать ещё вчера, а завтра он будет навсегда забыт. И останется крутиться на задрипанном, надолго предоплаченном vps, в cron которому прописана ежедневная перезагрузка.

Не могу не ответить на это классическим контраргументом: фейсбук, википедия, дигг :)

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

Не обязательно «работать на пхп» в виде написания сайтов :) Скажем, устроиться в «продуктовую компанию» (тм), или в ИТ-отдел какой либо неайтишной и девелопить внутренние интересные проекты. И таких вакансий хватает.

ну в бодишопы они не отдаются, а вот в режиме телекоммутинга вполне , я о трех знаю «из топ1000»

Руби это:

-когда йоба-ооп (youth oriented and bydło approved, ориентированная на молодёжь и одобренная быдлом) заменяет здравый смысл;

-когда пишут «begin end begin begin end end...» вместо кода;

-когда программа тормозит настолько, что за время подсчёта произведения 2 матриц 10×10 можно сходить попить чай;

-когда нормальным считается писать вещи типа 12.5.integer? или 3.times {puts «Ruby sucks!»};

-когда скорость увеличения и так небольшого количества библиотек падает на глазах — ведь есть гораздо более удобный Python

©

2. В паскале тоже были бегин — енд, и ничего, никто не раздражался особо. Мне это больше нравится чем отсутствие оператора в конце.

Меня — сильно раздражало. Но с остальным согласен.

В паскале тоже были бегин — енд, и ничего, никто не раздражался особо.

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

и когда увидел в Ruby — end — «дальше не читал»

а когда отделят компиляцию от исполнения в 2.0 — будет как питон, а то и быстрее.

Быстрее — не будет. Разве что если не использовать массу истинно rubyвских вещей.
В python, то ли в силу истории развития, то ли по замыслу — многие вещи сделаны сразу с оглядкой на работу интерпретатора. в Ruby упор был при создании языка — на красоту концепции.

В python — ООП «прикручено сбоку», и его тормозов можно избежать, зная как оно прикручено, если нужно, в Ruby — оно фундаментально.

Ну, насчет оператора завершения — тут вопрос вкуса. Мне например нравится такой стиль и вообще излишнюю многословность языков вообще проблемой не считаю.

это все в моем студенчестве до хрипоты спорилось — сишники против паскалистов. :)

меня — раздражало. Потому что глаза мозолило, и перемешивались с буквами операторов и названиями переменных. Плевался — ну хоть бы b. и e. какой сделали, чтобы — ОТДЕЛЬНО виделись границы блока кода...

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

проблема у руби не в отсутствии прекомпиляции в байт-код.

там некоторые концепции никак кроме больших синтаксических деревьев не реализуются. а в питон Гвидо их то избегал вставлять.

То же и с метапрограммированием.

Кстати, с прекомпиляцией потому проблемы — а вот язык такой что его и в обсфуцированный байт-код не втиснуть :)

И
Чтобы добиться скорости ВМ Руби как у ВМ Питона — нужно из Руби все фичи которых нет в Питоне — выбросить.

Но тогда — зачем он нужен такой, если как раз этими фичами — и красивше Питона?

Быстрее — не будет. Разве что если не использовать массу истинно rubyвских вещей.

Людиии!! Забейте на скорость. Если вам нужна скорость, то пишите на джаве (или Ц/ЦПП, но тогда затраты вырастут на порядок).

В python, то ли в силу истории развития, то ли по замыслу — многие вещи сделаны сразу с оглядкой на работу интерпретатора

От только стандартный хинт для увеличения производительности в питончеге — это использовать либу написанную на Ц. А сам язык просто для «скриптования».

Людиии!! Забейте на скорость.

так это не мне. я уже давно почти все объясняю:

«скоростью разработки»

всего лишь высказался по поводу «интерпретатор Ruby скоро догонит интерпретатор Python по скорости выполнения»

От только стандартный хинт для увеличения производительности в питончеге — это использовать либу написанную на Ц.

а в Ruby что ли можно достигать увеличения производительности по другому?

А сам язык просто для «скриптования».

да, Рельсы на нем такой же приятности не напишешь.

Но повторюсь, я отвечал на вот это:
когда отделят компиляцию от исполнения в 2.0 — будет как питон, а то и быстрее.

не будет!

а не что лучше, что важнее, что красивше

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

Смысл очень прост: явные блочные скобки принципиально нужны для того, чтобы быстро одним взглядом охватывать структуру, и не спотыкаться на проблемных случаях (как хрестоматийные множественные if-else в C и аналогах). Конкретная их реализация — {}, begin-end или отступами — уже не принципиальна, это дело вкусовщины конкретного языка. Меня устраивают все три, но меня не устраивает (а когда натыкаюсь на проблемы — бесит) кривой стиль, как в классическом Паскале (до Модулы) или в C с наследниками.

Например, правильный стиль для if, с моей точки зрения, выглядит так (пример из SER):

if (cond1) { body1 }
elif (cond2) { body2 }
else { body3 };

Здесь неважно, elif, elsif, else if или как-то ещё, можно пропускать всё кроме блока if, но важно, что скобки ({}) обязательны вокруг тела блока под условием, и финальное ’;’ однозначно завершает разбор всей конструкции. За счёт минимального оверхеда (2-3 знака) мы получаем чёткость, ясность и однозначность, в отличие от сишных соплей.

Не зря все практически известные стили кодирования требуют, что если под if/else/etc. что-то сложнее одного простого оператора, или в несколько строк — требуется ставить блочные скобки.

В python — ООП «прикручено сбоку», и его тормозов можно избежать, зная как оно прикручено, если нужно, в Ruby — оно фундаментально.

Не вижу принципиальной разницы, с учётом того, что на самом деле основные тормоза идут за счёт принципиально динамической (хоть и строгой) типизации. Это показал опыт Cython, который в основе есть Python с уточнением действий за счёт типизации переменных: основное ускорение возникает именно там.

Можно опираться на JIT, время компиляции или подсказки автора кода, но реальная польза начнётся с вывода типов и сокращения всего оверхеда на возможность получения произвольного типа в произвольном месте и, соответственно, анализа полученного перед каждой операцией.

вы поломали разметку форума :)

Это проблема форума:) у меня всё сбалансировано.

лично к вам претензий нет. просто поздравления :)

хоть и очевидно что толсто, но если так сесть подумать, то чтото в этом таки есть...

Если легко переучитесь на то, что:
1. Типы надо всё время приводить (на пхп от этого здорово отвыкаешь, 1!="1″ в руби!);
2. Всё есть объекты и в голове надо выстроить объектную модель языка с элементами наследования;
3. Хэши и массивы это СОВСЕМ не одно и то же (лично у меня был шок после привычки к ассоциативным массивам пхп);
а также
4. Привыкните к такой штуке, как mixins (traits в php только появились, они с mixins где-то рядом, но не все ещё осознали даже «как их (traits) готовить»);
5. Готовы к тому, что в языке и коде будет много «синтаксического сахара» (к чему «каноническому» пхписту с 2+ летним стажем приучиться не очень просто);

5. Вам нравятся образцы кода, которые легко находятся в Гугле по словам «ruby sample program»

-вперед, Ruby вас ждет.

Отдельный вопрос в готовности ваших будущих коллег поддерживать вас в вашем обучении и языку (всех тонкостей сразу вы, конечно, не познаете) и фреймворкам и проектам, с которыми они работают (здесь тоже может быть неохватный с первого раза вал информации). Если готовность невысокая и подход «сначала всё вдумчиво гуглим» — можете здорово просесть на время «дообучения». Поэтому всё хорошенько сами для себя и в своих обстоятельствах взвесьте и решайте.

И ещё, если вы не замечаете за собой высокой быстрообучаемости (я, к сожалению, за собой таки не замечаю, например), помочь может существующее сообщество рубистов поблизости (в вашем городе и пр.), не связанное с вашей работой (ибо люди и работы бывают очень разные). Если с таким сообществом туго и у вас «свои обстоятельства» с «въезжанием» в разные головоломки новых языков и фреймворков — ещё раз всё тщательно взвесьте.

Лично у меня ощущение, что в Украине даже Питон распространен сильнее Руби. Тут я не агитирую за или против, я предлагаю поразмышлять (это на случай, если вы и в дальнейшем планируете работать с украинскими командами).

Типы надо всё время приводить

И это правильно — язык с эффектами, когда 5-"3"==2, но 5+"3"==53 — очень стрёмный для разработки чего-то больше анимации одной страницы. Вообще, только группа Perl — PHP — Javascript (из массовых) позволяет такой бред, остальные используют значительно более строгую типизацию.

Лично у меня ощущение, что в Украине даже Питон распространен сильнее Руби.

Угу, и он однозначно перспективнее на сейчас. И, кстати, между ним и Ruby короче прыгать, если нужно, чем между Ruby и PHP.

Не совсем про perl:

diesel@bender-2:~$ perl -e ’if(5-"3″ == 2){ print “OK\n”}’
OK
diesel@bender-2:~$ perl -e ’if(5+"3″ == 8){ print “OK\n”}’
OK
diesel@bender-2:~$ perl -e ’if(5+"3″ == “53”){ print “OK\n”}’
diesel@bender-2:~$ perl -e ’if(5+"3″ == 53){ print “OK\n”}’
diesel@bender-2:~$

Я и не говорил, что тот пример был про Perl. Вообще-то он был про Javascript.
Но в названных языках сама по себе неявная конверсия между числами и строками — диверсия.
У нас с ней был другой эффект — когда при экспорте правил телефонного раутинга из Perl через YAML префиксы, начинающиеся с 0, неожиданно потеряли этот 0, хотя передавались как строки. Оказалось, что из-за невозможности различить число и строку, YAML dumper пытался опознать это своими силами и ошибался. Лечением стал экспорт всего со спец-ключом dumper’а «экспортировать скаляры как строки даже если это числа» и делать конверсию уже по контексту на приёмной стороне.
После этого случая я все языки, где типизация недостаточно жёсткая и возможна конверсия между числами и строками, строками и булевскими переменными и т.д., считаю шеллами-переростками и не воспринимаю их как языки для крупной разработки. Некоторые языки честно признают, что они шеллы-переростки, и отлично работают в этом смысле — например, Tcl. Некоторые признают и неплохо справляются, маскируясь под высокоуровневые — например, Perl. Но если такой язык в принципе не признаёт этот факт — то ему место на помойке.

PHP в этом смысле вообще клинический случай — там у типизаций, сравнений и т.д. нет никакой логической согласованности ни с самим собой, ни с внешними концепциями, сплошные хаки и отклонения.

Но в названных языках сама по себе неявная конверсия между числами и строками — диверсия.

Если по простому: «если с двумя скалярами вы делаете операцию как для строки(string) тогда мы их считаем строками, если как для чисел — тогда мы их считаем числами». Операции со строками и числами явно разделены: то есть числа и строки таки по разному складывают и сравнивают. Если про это помнить, в большинстве случаев проблем не будет, а жизнь кое где может упростить. А дальше следуя перловому правилу «простые вещи делаются просто, а сложные — сделать возможно», Вы нашли решение для конкретной хитространной проблемы :)

Да, этот подход не особо универсальный, и может быть опасным. Но Perl вроде как и никогда не тащили во все дыры, а в традиционных для него областях вполне оправдано в приницпе-то.

Если по простому: «если с двумя скалярами вы делаете операцию как для строки(string) тогда мы их считаем строками, если как для чисел — тогда мы их считаем числами».

Ну вот в Javascript вроде бы так и делают. ’-’ оно для чисел. А вот ’+’ оно и для чисел и для строк, и тогда начинает зависеть от приоритета: 5+"3″ это сложение чисел или строк?

Но объясните мне всё-таки — конверсия в JSON/YAML/etc. скаляр, который может быть числом или строкой — это операция для числа или для строки?

Но Perl вроде как и никогда не тащили во все дыры, а в традиционных для него областях вполне оправдано в приницпе-то.

Простите, а какие области считать «традиционными»? Если считать «традиционной» областью задачу дополнить /bin/sh до логического завершения, а не оставлять концептуально дырявым, как решето (я не в смысле безопасности, а в смысле логической целостности) — то да, Perl на это хорошо ложится. Только тогда проблема, на кой нужен Perl5? Последним, который соответствовал именно этой задаче, был Perl4.

А вот если мы переходим к языку, на котором пишутся крупные проекты — то надо многие вещи делать уже совершенно иначе. В частности, подход языка должен быть таким, что он не маскирует ошибки, а выявляет их. Например, в Python написав a[x], мы получаем исключение, если ключ x не существует; а чтобы явно получить пустое значение, надо писать a.get(x, None), и это явно привлекает внимание при анализе кода. В Perl, $a{x} даёт undef, если ключа нет, а для генерации исключения надо рисовать явную проверку с die, или вызывать специально написанную для этого функцию. И так с очень многими чертами языка и библиотеки. Чем толще и сложнее проект, тем больше язык с подобными умолчаниями и решениями за программиста мешает, а не помогает.

Ну вот в Javascript вроде бы так и делают. ’-’ оно для чисел. А вот ’+’ оно и для чисел и для строк, и тогда начинает зависеть от приоритета: 5+"3″ это сложение чисел или строк?

в том то и дело что ’-’ только для чисел, потому что для строк ’-’ имеет на самом деле не очень много смысла. а ’+’ для чисел и строк потому что имеет смысл — и это фигово. В Perl ’+’ всегда для чисел, ’.’ - это ’+’ для строк, то есть операции разделены явно: ’+’ не сделает concat, а ’.’ не будет делать арифметического сложения. Поэтому нет, если все так как вы говорите (я к JS не имею никакого отношения), то в JS таки «делают не совсем так».

Но объясните мне всё-таки — конверсия в JSON/YAML/etc. скаляр, который может быть числом или строкой — это операция для числа или для строки?

В случае с Perl’ом я бы наверное предпочел чтобы всё что пишется в YAML было «строками». Это если бы Вы меня в пять утра разбудили и спросили «как делать конверсию». А вот что на эту тему думали создатели библиотек которыми вы пользовались — я не знаю, может быть свое видение они в документации изложили. YAML перлом загружал, но ничего похожего на числа не было.

Если считать «традиционной» областью задачу дополнить /bin/sh до логического завершения

...

А вот если мы переходим к языку, на котором пишутся крупные проекты

между шеллом и «крупными проектами» — достаточно большое расстояние. Хотя тут еще конечно вопрос что считать «крупным». «Традиционная» область перла: «натащить из CPAN’а модулей, и побыстрому шонить наваять». Иногда с ООП-вариантами модулей работать проще, поэтому все же Perl 5 удобнее будет.

Вот «Modern Perl» или как они его называют — это уже размышления на тему чего-то покрупнее. Но это такая себе «вещь в себе».

В Perl, $a{x} даёт undef, если ключа нет, а для генерации исключения надо рисовать явную проверку с die, или вызывать специально написанную для этого функцию.

И это тоже:

явно привлекает внимание при анализе кода

С другой стороны это получается:
if(exists $a{x}){
...
}else{
...

}

супротив:

try:
... a[x]
...
catch:
...
?

Дык это больше вопрос стиля.

Дык это больше вопрос стиля.

Если Вы ищете полный аналог, то «exists $a[$x]» заменяется на «x in a», или, в более старом стиле, «a.has_key(x)». Ловить этот через немедленный catch («except» в Питоне) смысла нет, код с прямым непроверяемым доступом («a[x]») рассчитан на то, что ошибки будут ловиться в общем случае и на другом уровне.
Или же вместо этого пишется «r = a.get(x, None)», а затем «if r is not None:...» (тоже вариант, выгоднее в некоторых случаях).

Так что это не вопрос стиля самой проверки — это вопрос стиля всего построения программы. В таких ситуациях лучше писать код с расчётом на то, что явно некорректное действие вызовет исключение, а затем где-то на верхнем уровне будет глобальная обработка ошибки, чем на явную проверку каждого чиха, или на то, что код молча выполнит полную ересь, а затем мы будем разбираться, что же за ерунда получилась в итоге.

«Традиционная» область перла: «натащить из CPAN’а модулей, и побыстрому шонить наваять».

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

В случае с Perl’ом я бы наверное предпочел чтобы всё что пишется в YAML было «строками».

Ну вот мы поневоле пришли к этому. Потому что иначе просто не работало — умничало, когда не имеет права.

Поэтому нет, если все так как вы говорите (я к JS не имею никакого отношения), то в JS таки «делают не совсем так».

Я не вижу смысла сурово разделять их (JS с одной стороны, Perl, PHP с другой), потому что это всё проявления одной и той же болезни: наплевательство на типизацию.

Вот ещё один пример проявления: в Perl в булевском контексте «0» — false, но «0.0» и «00» — true:

$ perl -e 'print "true\n" if "0";'
$ perl -e 'print "true\n" if "0.0";'
true
$ perl -e 'print "true\n" if "00";'
true

А разгадка всё та же — безблагодатность наплевательство на строгость типизации и попытка сэкономить объём кода на неявных эффектах, которые имеют смысл только для микрообъёмов кода, но не для существенного проекта...

Так что это не вопрос стиля самой проверки — это вопрос стиля всего построения программы. В таких ситуациях лучше писать код с расчётом на то, что явно некорректное действие вызовет исключение, а затем где-то на верхнем уровне будет глобальная обработка ошибки, чем на явную проверку каждого чиха, или на то, что код молча выполнит полную ересь, а затем мы будем разбираться, что же за ерунда получилась в итоге.

Сложный вопрос на самом деле. Ну то есть вот у нас есть хэш — в основном таки применяется для хранения чего-нибудь. Если мы в нем не можем этого чего-нибудь найти: то на это требуется как минимум явная реакция именно для этого хранилища. Ну то есть не общее «в каком-то хэше чего-то нет», а там «мы пытаемся достать информацию о несуществующем товаре». Ловить проблемы все же лучше поближе к месту их возникновения: так можно и пользователю что-то более разумное показать, и самому быстрее найти. Иначе разве что «сорри, сам щит хэппенед, не шмогла я».

Вот ещё один пример проявления: в Perl в булевском контексте «0» — false, но «0.0» и «00» — true

А разгадка всё та же — безблагодатность наплевательство на строгость типизации и попытка сэкономить объём кода на неявных эффектах

Разгадка проще: в документации явно указано что является false. «0.0» и «00», аки строки, false не являются, аки числа — являются. Поскольку в Вашем примере:
diesel@bender-2:~$ perl -e ’print «OK\n» if "0.0«’
OK
явно указано что 0.0 — это строка, поэтому стоит ожидать не проверки:
diesel@bender-2:~$ perl -e ’print «OK\n» if «0.0» == "0«’

OK

которая для чисел, а проверки:
diesel@bender-2:~$ perl -e ’print «OK\n» if «0.0» eq "0"’

diesel@bender-2:~$

которая для строк.

Если мы в нем не можем этого чего-нибудь найти: то на это требуется как минимум явная реакция именно для этого хранилища.

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

Самый яркий пример такого подхода — в эрланговском «Let it crash». Но и вообще рекомендации для языков с системой исключений именно такие — проверяйте явно только то, что надо явно проверять по спецификации или если защиты по недопустимой ситуации или значению просто нет (как в перле).

А ещё есть вопрос тестирования — на котором особенно явно, что поиск багов резко облегчается, если видим исключение, но не если проблема замолчена (тогда без пошагового отладчика фиг чего найдёшь).

Ловить проблемы все же лучше поближе к месту их возникновения: так можно и пользователю что-то более разумное показать, и самому быстрее найти.

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

Разгадка проще: в документации явно указано что является false.

В документации может быть задокументировано что угодно (например, что 0 и 3.1415926 являются False, а остальные значения — True). Вопрос в том, насколько такое поведение консистентно в общих рамках языка и средства. Понимание любой непустой строки как истинной, как в Python, консистентно с логикой языка, в котором неявная конверсия строки в число недопустима. Язык, в котором числа и строки смешаны до такой степени, что их нельзя отличить никакими средствами самого языка, но при этом 0.0 есть false, а «0.0» есть true — неконсистентен и поэтому ущербен. И сколько бы его авторы ни документировали этот подход — правильнее он от этого не станет.

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

вообще в вашем варианте, при use strict/warnings; вы увидите сообщения об ошибках когда пытаетесь использовать undef (который вытащен из хэша).

Вопрос в том, насколько такое поведение консистентно в общих рамках языка и средства.

ну в том то и дело, что в рамках языка это поведение консистентно и понятно. только в рамках этого конкретного языка, а не другого.

вообще в вашем варианте, при use strict/warnings; вы увидите сообщения об ошибках когда пытаетесь использовать undef (который вытащен из хэша).

Использовать под что, простите? Это уже зависит от целевой операции. Может, где-то undef — нормальное значение (как оно часто и бывает). А просто сообщения об ошибке — это путь в никуда. Недопустимая операция просто не должна выполняться.

ну в том то и дело, что в рамках языка это поведение консистентно и понятно.

Что именно? Что 0.0 это false, а «0.0» это true, и отличить на уровне языка нельзя? Это не может быть консистентным и понятным в любом языке.

Использовать под что, простите? Это уже зависит от целевой операции. Может, где-то undef — нормальное значение (как оно часто и бывает).

да в принципе-то практически во всех встроенных функциях undef — это не нормальное значение. То есть как только вы попробуете сложить, изменить, напечатать и так далее свой undef — получите warning.

А просто сообщения об ошибке — это путь в никуда. Недопустимая операция просто не должна выполняться.

И это тоже возможно... Например вот так:
diesel@bender-2:~$ perl -e ’use strict; use warnings FATAL => qw(all); $a=undef; $b = $a; print $b; print «OK\n»;’
Use of uninitialized value $b in print at -e line 1.

diesel@bender-2:~$

Что именно? Что 0.0 это false, а «0.0» это true, и отличить на уровне языка нельзя? Это не может быть консистентным и понятным в любом языке.

Хм, про язык мы знаем что в случае строк false — это или пустая строка(«") или «0», все остальное — true, для чисел false — это 0. C точки зрения языка, если вы задаете переменную со значением «0.0» — вы задаете строку(если вы ее читаете из файла — это тоже будет строка), строка «0.0» — не пустая, и по правилам сравнения строк не равна «0», соответственно это true. Тем не менее, если вы явно: if(int("0.0″)) или не очень явно: if("0.0″ + 0) скажите что это не строка, а таки число, то по тем же правилам оно станет false. Все достаточно просто и предсказуемо.

То есть как только вы попробуете сложить, изменить, напечатать и так далее свой undef — получите warning.

А толку мне с того варнинга, если из-за отсутствия значения выполнение пошло не по той ветке и стёрло пол-базы?

Не должно быть «варнингов», если значение непустимо — надо не писать нечитанную ботву в лог, а порождать исключение.

perl -e ’use strict; use warnings FATAL => qw(all);

Само по себе то, что это надо явно включать, делает язык опасным.

Тем не менее, если вы явно: if(int("0.0″)) или не очень явно: if("0.0″ + 0) скажите что это не строка, а таки число,

if(int($x)) при $x==0.1 даст ложный false.
$x+0, если $x является signaling NAN, должно вызвать исключение.

Обе Ваших проверки чреваты боком.

А толку мне с того варнинга, если из-за отсутствия значения выполнение пошло не по той ветке и стёрло пол-базы?

Не должно быть «варнингов», если значение непустимо — надо не писать нечитанную ботву в лог, а порождать исключение.

зависит от ситуации: есть задачи «пусть лучше вылетит, чем работает абы как», есть задачи «пусть хоть что-то сделает, а там посмотрим». Снесет пол базы — да, проблема, не найдет значение в 10 файлах из миллиона — может проблемой и не быть.

if(int($x)) при $x==0.1 даст ложный false.

да, пардон.

$x+0, если $x является signaling NAN, должно вызвать исключение.

не совсем понял(я не особо в теме): signaling NaN собсно для того и signaling

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

зависит от ситуации: есть задачи «пусть лучше вылетит, чем работает абы как», есть задачи «пусть хоть что-то сделает, а там посмотрим». Снесет пол базы — да, проблема, не найдет значение в 10 файлах из миллиона — может проблемой и не быть.

Система, в которой вылетает при любом некорректном действии, конвертируется в систему, которая не вылетает, одним простейшим обобщающим try-catch.

Система, которая скрывает внутри своих действий все проблемы, выдавая вместо исключений всякие undef/None/etc., конвертируется в систему, которая отвечает за свои действия и не делает некорректных действий, очень долго и муторно, а чаще всего — просто заменой языка на надёжный.

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

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

Что мешает в php принудительно приводить типы?

Ну приходят из форму строки, и строки извлекаются из БД, но что военного в нужном месте использовать (int) или intval() или floatval() etc в зависимости от ситуации?

После приведения типов всё становится более-менее согласовано. Ну и можно иногда на всякие жесткие вещи смотреть, типа строгого тождества (===, !==), всяких параметров в функциях, указывающих н строгое сравнение и т.п.

Я согласен, что при привычке работать с языками с жесткой типизацией от php может возникнуть butthurt, если не похуже. Но тем не менее. Кстати, в функциях и методах уже можно задавать не скалярные типы входящих переменных (массивы и классы объектов), и это также несколько облегчает жизнь.

Что мешает в php принудительно приводить типы?

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

но что военного в нужном месте использовать (int) или intval() или floatval() etc в зависимости от ситуации?

То, что где-то проконвертировали значение, а где-то — забыли. Вот ошибся программист после 7 часов упорной работы (а впереди ещё 3 часа). А затем начинается, что в типичной ситуации «оно» работает без ошибок, а в некоторых маргинальных — начинает нести фатальную чушь. И вы даже тестами этого не ловите, потому что обычный тест не позволяет проверить, в скаляре число или строка, представляющая это число. Напоминаю мой пример про префиксы телефонных номеров: это вылезло не сразу.

После приведения типов всё становится более-менее согласовано.

Мне нравится это «более-менее», оно как раз отражает ситуацию. Вот именно, когда более, а когда менее. Вы привели данные (ну, 99% из них — потому что 1% или забыт, или не приведён из-за изменения структуры базы). А дальше что? Как проверить, что операция в принципе корректна, потому что она однозначно применима именно с той функциональностью, которая задумана?

Я согласен, что при привычке работать с языками с жесткой типизацией от php может возникнуть butthurt, если не похуже.

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

Для задачи уровня «пол-экрана» меня устроит и /bin/sh, в котором вообще всё — строка. Но для задачи объёмом на миллион строк я принципиально запрещу выбирать язык без строгой типизации и с такими несогласованностями, как в PHP, Perl, JS и иже с ними, потому что работа или не будет закончена, или получится только при таком феноменальном вливании средств, как в Facebook.

А если ещё больше, или требования будут включать в себя надёжность выше чем «я вам верну стоимость программы, если докажете» — все топовые современные средства пойдут лесом.

Что качественная защита против характерных ошибок, включая некорректные сравнения и неожиданную функциональность операторов, экономит человеко-годы отладки и сокращает количество ошибок в разы?

Intval/floatval «на автомате». Вот такая качественная защита опытного пхписта. Ну и прослеживания и проверки.

От ошибок же в целом не застрахован ни один язык — ни Руби, ни Ява, ни Питон, склонность к ошибкам и умение их локализовывать и избавляться от них по-моему и есть показатель профессионализма.

Вот ошибся программист после 7 часов упорной работы (а впереди ещё 3 часа).

А вот лучше так вообще не работать: официальные 8 рабочих часов не зря придумали. Если у меня получаются вынужденные овертаймы, я обычно коммичу на следующий день и перед этим критично пересматриваю код — тут напортачить просто от усталости любой может.

А дальше что? Как проверить, что операция в принципе корректна, потому что она однозначно применима именно с той функциональностью, которая задумана?

Проверяем с допустимым диапазоном значений. Берём блок кода, загоняем его в автономный файл (или прогоняем через eval()) с допустимым диапазоном. По дороге отслеживаем всё то же приведение типов.

например в си тоже строки напрямую нельзя сравнивать , и ничего , все живы :)

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

например в си тоже строки напрямую нельзя сравнивать

Си это переносимый ассемблер, соответственно, его ограничения растут из его нацеленности на железо. А названная троица претендует на роль ЯВУ.

и ничего , все живы :)

Ой сказки-то не рассказывайте. Почитайте, какие дикие дыры находили в коде на Си в 90-х (все интернетовские сервисы того времени) и как медленно народ учился писать секьюрно.

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

Чем более язык оптимизирован на безопасность операций, тем более явные кривые действия требуются для прострела своей ноги. Соответственно они будут хорошо заметны.

А названная троица претендует на роль ЯВУ.

с чего бы вдруг. тот же пшп «претендует» только на веб

Ой сказки-то не рассказывайте. Почитайте, какие дикие дыры находили в коде на Си в 90-х (все интернетовские сервисы того времени) и как медленно народ учился писать секьюрно.

несколько передергиваете, дыры не были связаны с тем что программисты использовали операторы сравнения со строками

Чем более язык оптимизирован на безопасность операций, тем более явные кривые действия требуются для прострела своей ноги. Соответственно они будут хорошо заметны.

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

с чего бы вдруг. тот же пшп «претендует» только на веб

Вы действительно не знаете разницу между уровнем и ориентацией языка? ;)

несколько передергиваете, дыры не были связаны с тем что программисты использовали операторы сравнения со строками

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

почему же тогда программы на «типобезопасных» языках все также имеют глюки ?

Потому что не все глюки ловятся системой типов. Хотя наиболее опасные могут ею быть легко отловлены.

как по мне тут борьба с проблемой, которая затрагивает только школьников

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

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

угу. только вот очень легко находится

Потому что не все глюки ловятся системой типов. Хотя наиболее опасные могут ею быть легко отловлены.

то что программа скомпилилась еще не значит что она верна, а вот то что в динамических языках просто быстрее написать реализацию и начать тестить — єто факт

по поводу опасности смешно — теже boundary errors компиляторы статически типизированных языков не отлавливают , и что ? часто валится ?

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

так не закрывайте — тестируйте, а там всплывет все , и в основном это будут не ошибки типов

ну и еще про глаза — посмотрите на мир, где циклы проца дешевые, а «циклы» прогера дорогие... все крупные конторы так или иначе «лезут» в динамику, кое где она уже давно стандартом (теже базы с их sql — я даже не слышал есть не ли строго типизированный язык запросов :)

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

угу. только вот очень легко находится

Не в коде стиля пресловутого imap-uw :)

а вот то что в динамических языках просто быстрее написать реализацию и начать тестить — єто факт

Динамическая типизация != нестрогая типизация

это ортогональные понятия.

теже boundary errors компиляторы статически типизированных языков не отлавливают , и что ? часто валится ?

Да, бывает.

посмотрите на мир, где циклы проца дешевые, а «циклы» прогера дорогие...

И снова — не путайте два разных аспекта типизации.

когда 5-"3"==2, но 5+"3"==53
в след за Vasiliy Litovchenko повторил в php
>php -r ’if(5-"3″ == 2){ print “OK\n”;}’
OK
>
>php -r ’if(5+"3″ == 53){ print “OK\n”;}’
>

тщательнее надо быть

тщательнее надо быть

тщательнее надо читать и не приписывать собеседнику то, чего он не говорил.

я просто вас процитирую

только группа Perl — PHP — Javascript (из массовых) позволяет такой бред,

Абсолютно верная цитата. Да, из массовых сейчас только эти языки позволяют неявную конверсию между числами и строками, при этом используя достаточно неадекватные правила этой конверсии и взаимодействия для разных операторов, что приводит к неожиданным плохо управляемым эффектам.

С чем Вы не согласны?

я еще раз повторюсь — вы приписали перлу и пшп то, чего нет
а по поводу конверсии — лично мне (после си) такой подход нравиться , код чистый от явных преобразований и лучше читается

«неожиданные эффекты» возникают обычно от быдлокода, так быдлокодера строгая типизация не остановит

я еще раз повторюсь — вы приписали перлу и пшп то, чего нет

Я «приписал» им неявную конверсию между числами и строками. Она, очевидно, есть.

а по поводу конверсии — лично мне (после си) такой подход нравиться , код чистый от явных преобразований и лучше читается

Он в разы хуже читается, потому что непонятно, что ожидать от каждой операции.

«неожиданные эффекты» возникают обычно от быдлокода, так быдлокодера строгая типизация не остановит

Она позволит тому, кто будет читать код, увидеть эту конверсию и оценить её необходимость и эффекты в этом конкретном месте. И не позволит замаскировать такие конверсии.

В языках, где этот вопрос решён адекватно (например, в Go), даже конверсия между равномощными int и int32 запрещена, потому что первый — тип конкретной платформы, а второй — межплатформенный переносимый.

Личные впечатления о руби очень положительные. Ничего серьезного на нем не писал, так, поигрался малехо и прочитал книгу. Код на руби читается легко, нравится парадигма mix-in-ов, блоки и широкие возможности метапрограммирования. Идеален для написания всякого-рода domain specific languages — самый яркий пример — Rails. Ну и корни у него смолтолковские как ни крути, а это о многом говорит в его пользу.

Три года назад перешел в пыхи на руби — полёт нормальный! :) Первое время долго плевался и жалел, т/к язык и сама рельса не воспринимались, все время ожидал иного поведения, магия не воспринималась. Но в итоге со временем все далось и не знаю, как я раньше мучалcя с этой пыхой и тем же zendframework’ом, небо и земля!

Раньше ЗП рубистов и пыхарей значительно отличались, сейчас же с выходом symfony2 и развитием языка уже все выровнялось, пыхари получают столько же. Вакансий на пыху гораздо больше чем на руби — тут ничего не изменилось :( но если смотреть с другой стороны — каждая вакансия руби это от 1.5к$ а на пхп идет мазня от 500... т/е вакансии руби берут не количеством а большей стартовой зп :)

И сколько времени изучения прошло прежде, чем все начало нормально восприниматься?

В моем случае процесс адаптации длился пол года, я занимался багфиксами проектов на рельсе и продолжал кодить на пыхе. Может если бы разрабатывал rails-проекты с нуля было бы быстрее...

Ну и ничего не мешает вернуться потом к похапэ, если не понравится руби :)
Помешают устаревшие знания. Мир PHP развивается уже огромными шагами последние годы. 2 года на другом языке — и перед вами пропасть.

я так понимаю автор это и пытается тут сделать :)

А что нового появилось в мире ПХП за последние 2 года?

почитайте, что появилось с выходом php 5.4 , как минимум.

Несколько незначительных языковых изменений — это вы называете «пропасть»? )

нет, пропастью я называю изменения в течении 2 лет, а это так, буквально за пару месяцев только обновление.

+вышла альфа пхп 5.5.

и я бы не сказал, что это прямо «незначительные» языковые изменения. :)

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

Вот вам и пропасть за пару лет.

Ну и что же там значительного? Генераторы, finaly? До то что есть в более зрелых языках ещё пилить и пилить.

вы сейчас про какое из моих утверждений?

да уж, препроцессора, полноценных шаблонов (аля с++) и множественного наследования там не предвидится , увы :)

кому нахрен нужно множественное наследие?

кому нахрен нужно множественное наследие?

ну да, для средних умов лучше че нить попроще

все правильно говориш. Сложности ведь для глупых. ;)

При всей моей нелюбви к PHP и как бывший C++ программист должен сказать, что множественное наследование — одно из самых паршивых свойств языка, иначе как для примисей ни к чему и не годное. Не зря в Джаве и Шарпе его выпилили.

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

есть traits но эт немного другая история

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

есть traits но эт немного другая история

Былоб не плохо, еслиб вы пояснили дремучим людям, вроде меня, чем traits не достаточно ?

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

ИМХО, вопрос- реализации.

навскидку — добавить в таблицу виртуальных методов еще парочку адресов для вызова — не проблема.

скала же допускает вары внутри треитов, иль я чегото не понял, и о каких переменных класса идет речь ? и зачем нужна некая «мета информация» ?

а причем тут скала ?

Сори, я чет фтыканул под вечер :-) То что термин trait теперь есть и в «неком пхп», у меня напрочь вылетело из головы.

:)

а фейсбучег еще и пишет потихоньку свой on-fly транслятор из пшп в си

Во цукенбергу денег девать некуда...

и зачем нужна некая «мета информация»

ну при наследовании «цепляется» все цепь предков и реализованных интерфейсов... конечно в пшп это не так критично, но всеже

«Предпочитайте композицию наследованию»,
Стандарты программирования на C++,

Герб Саттер, Андрей Александреску.

Видимо, автору, как бывшему с++ прогеру, об этом не известно :)

there is no silver bullet

если вы понимаете конечно

Назвался сишником — будь готов к критике :)

Пыха по-другому решает задачи, для которых нужны шаблоны; а то что нет множественного наследования может оно и к лучшему.

и да, все компании прям спешат обновлятся на новые пхп, многие сидят на старых и в ус не дуют, пхп то обновляется, но инерция компаний остается.

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

не работайте в таких компаниях, вот и все.

Я бы сказал, не работайте в тех компаниях, что постоянно обновляются. Знаю я таких «самих по себе», что скачут по языкам(а вы это уже ниже подтвердили) и не могут остепенится в то время, как надо сосредоточится на продукте.

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

Некоторые вакансии на php видишь, и глаза вытекают.
ну то что пшп покрывает широкий сегмент — он мелочи типа сайтов-визиток, до монстров типа мордокнижий — это большой плюс языку
А еще у руби порог входа всё же повыше, чем у пыха
вроде как руби рекламируют как простой язык. типа делфи для веба

вакансии ... в основном для миддлов и выше

это в свое время убило смолток , хаскель и многие другие удачные языки. откуда браться достаточному числу миддлов если нет джунов ? переманивать ? ну да, набирать джунов по цене мидлов — это еще сильнее убивает язык

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

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

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

опыт работы в крупной стоит дополнительных денег

Обоснуйте, пожалуйста.

в крупных чаще техпроцесс более менее поставлен — бранчи, таски, трекинг, тестинг ,
плюс человек попавший в крупную скорее всего прошел успешно сито отбора, а не просто человек «с улицы»
по своему опыту, если новый сотрудник не работал в крупной конторе, скорее всего ему придется обьяснять что надо мержить , а не копипастить, что нельзя делать коммитов без привязки к jira и все такое
вроде бы мелочи, но иногда раздражает

И в маленькой компании всё то же самое возможно: и тщательный отбор, и поставленные процессы (что даже проще делать в маленькой).
И в крупных бывает частичный бардак.

И отбор в большинстве мест стремится примерно к одному и тому же: есть требования, есть кандидаты. Или нет кандидатов. :-)

конечно все возможно, но по сути этот опыт можно «продавать» за дополнительные деньги

Я бы не купил. На месте работодателя я купил бы другое — реальный опыт с технологиями и способность решать проблемы.

реальный опыт с технологиями и способность решать проблемы.

ну так я про то, но человек с реальным опытом и способностями да еще и с опытом в крупной конторе стоит дороже такого же «самородка»

Не убедили.

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

ну может под

необходимые проф. навыки

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

— опыт работы с большими базами, ну пусть от 50млн. строк на таблицу

такие вещи с меньшей вероятностью встретятся в маленьких конторках , а если и встретятся то врядли такая конторка будет искать джунов

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

High load в любом случае немногие занимаются. И уж совсем не обязательно это крупная компания. Там и 20 человек хватит с лихвой.

Количество записей в БД — вообще ни о чём. Могут быть, а могут не быть, при маленьких объёмах кода в том числе.

Опыт с «миллионами строк кода» — участие в саппорте г@внопроекта, бОльшую часть которого всё равно не видел, ибо он большой. К тому же не способствует улучшению знаний о грамотном проектировании программных систем.

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

Полная ерунда.

добротный, аргументированный ответ. спасибо

Ну допустим в крупной у нас нету вакансий сеньеоров. Все места заняты.
А в маленькой они есть, но не могут людей найти на эти места так, как никто не знает Руби на этот уровень. Вот они и ждут когда те, кто есть подтянут свои скилы. Это может быть хороший шанс.

И чем же проще в большой выбиваться вверх?

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

так вот — в маленькие конторы лучше сразу идти сеньером — там удобнее — прямой контакт с руководством, разнообразнее задачи , но вот места для карьерного роста среди 5-10 человек нет , выше единственного начальника не вырастешь

в больших с этим проще — кто-то увольняется, кто-то переходит на другие проекты, новый народ нанимается, всегда есть некий движ

без разницы
насчёт рейтов очень сомневаюсь, разве что средний может выше

думаю есть смысл выбирать между компаниями/проектами, а не между языками

да это давно устоявшийся миф про то, что мол PHPшники самое меньше получают :)

это как средняя температура по больнице — ни о чем не говорит.

Т.е., если я правильно понял, Вам предлагают изучить еще один язык программирования и при этом будут платить зарплату? И Вы еще думаете? :-)

Изучать мне прийдется в не рабочее время, чтобы нормальный уровень был. Без знания Руби они меня не возьмут.

И что тут такого мега хорошого — выучить еще один язык программирования? Разве в количестве сила?

безусловно, но этого не достичь без кругозора ;-)

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

Но нам нем ведь больше половины Веба висит...

потому что действительно удобный язык с множеством плюсов.

и что дальше? (может и круче) Дальше-то что? Рынок работает не по принципу крутизны.

А вы, собственно, с какими еще имели дело языками кроме РНР?

Вполне. Только не надо так нервничать ))

вы знаете, когда в каждом втором подобном треде задается подобный вопрос в надежде, что человек дальше своего носа не видит — то это вызывает вполне заслуженную аггрессию :-)

Я так понимаю, в эту тему стоит писать только тем, кто поклоняется РНР. Иначе — «заслуженная агрессия» )

почему же — нет, стоит писать любому. Только когда это не попытка набросить, как в вашем случае было :)

открыл tutorial и посмотрел — это называется имел дело?

А вы, собственно, с какими еще имели дело языками кроме РНР?

обычно после вопроса про «ты с какова района», шел вопрос «а кого ты знаешь» .... в гоп-айтишнигов паттерн поменялся :)

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

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

а посмотреть статистику здесь же на ДОУ что мешает?

Руби отвратительный, это правда — наследие перловского синтаксиса и динамзма. Но по крайней мере это язык программирования а не сборище конструкций как ПХП.

Т.е. выбор шило на мыло по сути.

наследие перловского синтаксиса

Где в руби такое?

Название навеяно языком Perl, многие особенности синтаксиса и семантики из которого заимствованы в Ruby: англ. pearl — «жемчужина», ruby — «рубин».
ru.wikipedia.org/wiki/Ruby

наследие перловского синтаксиса и динамзма.

ваще-та пшп эт «наследник» перла,

ваш ко

правда, «наследник» — чисто исторически, не так уж много там связей осталось.

ну «визуально» синтаксис очень близок

пыха наследник вообще всего, ООП вообще почти как от явы, но все пишут в сишном синтаксисе

ООП вообще почти как от явы, но все пишут в сишном синтаксисе

только никому не говорите что ооп придумали именно создатели java :)

только никому не говорите что ооп придумали именно создатели java :)

вижу шиза вконец косит ряды похапешников

В том виде, как оно есть в PHP впервые в java и было сделано.

гм. а что именно в java реализации ооп было уникального ?

ну что бы понимать :)

До явы интерфейс и реализация прописывались отдельно(что православнее в рамках чистого ООП). Взять тот же C++. Сначала объявляешь интерфейс класса в header, а уже потом уже реализуешь его в .cpp. Точно так же в objective-C. В Java же можно сразу прописывать реализацию в классе.

До явы интерфейс и реализация прописывались отдельно(что православнее в рамках чистого ООП).

Взять тот же C++. Сначала объявляешь интерфейс класса в header, а уже потом уже реализуешь его в .cpp.

1) Абсолютно параллельные явления.

2) В ЦПП можно реализацию прямо в заголовном файле писать и даже сразу при объявления метода.

я к тому что богдан описал еще добавлю — в дотнете возможность разнесения «класса» по разным файлам подавалась как selling point повышающее удобство :)

partial class дотнета — это совсем из другой оперы.

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

я незнаю, что у вас в голове происходит, если вы не понимаете разницы между partial class и хедерами C++. Это тупо разные вещи. Видимо таки пхп на мозги повлиял.

ну расскажите нам , о великий всезнайка, чем же отличаются цели данных фич ?

вместе посмеемся

Тем, что в С++ реализовывались подходы к ООП, интерфейс отдельно, реализация отдельно, ну и еще спефичные штуки с линковкой(о которых я мало знаю) Partial Class — это всего лишь возможность разнести класс на кучу файлов(хоть с десяток). Тоесть у вас может быть 1 класс и 10 методов, каждый метод может быть прописан в отдельном файле с помощью директивы partial class.

Так же partial class призван упростить работу с nested классами. Это позволяет разнести внутренний класс по разным местам внутри другого класса.

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

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

эк, сколько кирпичей нарожали.

в принципе, на єтом можно заканчивать — переход на личности это чистый слив

но для остальных читателей я напомню, что в с++ точно также имплементацию класса можно разнести на кучу файлов, даже без необходимости писать partial class

либо же прописать имплементацию прямо при обьявлении класса

чем это отличается от с# (за исключением «сахара» и специфики компиляции) — я не вижу

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

что у пхпшников мозг рака

Главное — не обляпайся, о мозговитый

о еще один представитель пхпшной фауны.

о еще один представитель фауны придурков

Продолжай, очень информативно.

Perl и Ruby? Не в ту степь товарищ. Perl отличный язык, но никак они не похожу с рубинычем.

Perl и Ruby схожи тем что это прежде всего достаточно продуманные языки, а не «набор возможностей», как PHP.

кто бы знал о руби, если бы не рельсы? :) PHP же пользуются от мала до велика. Да PHP написан людьми со слабым использованием реальной технической матчасти, но зато PHP решал реальные проблемы Web того времени, и за счет этого он стал очень популярным(а это не оспоримый факт со всеми вытекающими).

И сейчас он вполне справляется с многими вещами. Так что нельзя говорить, что PHP не продуман.

Я например часто использую PHP для тестирования ajax запросов простых или какихто быстрых вещей, у меня на виртуалке стоит Linux с апач — скрипт разместил коротенький и вуаля в 2 клика все работает. У того же Ruby есть неплохая штука тоже — Sinatra, для быстрого тестирования, но опять же нужно разбиратся, подымать сервер и т.п.

Кстати в свете этого, нельзя не вспомнить цитату Торвальдса,
«Bad programmers worry about the code. Good programmers worry about data structures and their relationships.»

Что в переводе, плохие программисты волнуются о коде, а хорошие о структурах данных и их взаимоотношениях.

И сейчас он вполне справляется с многими вещами. Так что нельзя говорить, что PHP не продуман.

Вполне справляется со многими вещами отлично может сочетаться с «непродуман». У PHP просто достаточно тяжелое наследие с тех времен, когда он уже «вполне справлялся со многими вещами», но «думать» над языком особо не начинали.

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

Підписатись на коментарі