Какой серверный язык учить?
 

Всем привет! )

В очередной раз передо мной встала проблема, проблема выбора - серверные технологии. Какой язык учить, что осваивать? Есть ли смысл изучать что-то новое, раз существует node.js? Хотелось бы услышать ваше мнение на этот счет.

В качестве "языков" для обучения я рассматриваю:

• Python
• Ruby
• PHP
• Node.js
• ваш вариант )

p.s.: ссылки на литературу для освоения приветствуются

С++

А если серьёзно - выбор языка зависит от того, что и как ты собираешся делать.

PHP (если сайты делать собрался)
+ на него проще перейти с javascript, чем на ruby или python
+ существует масса крутых фреймворков, yii, codeinghter, symphony, kohana, и тд
+ самые популярные движки сайтов написаны на php, joomla, drupal, wordpress, TYPO3, PHPBB, bitrix и тд

если посмотреть на движки 10 000 самых популярных сайтов, то становится ясно что знание php позволит охватить где-то 90% рынка.



бесплатные по рунету 2012г

А мне php не нравится. На js мне приятнее писать. Потихоньку ковыряю Node.js

Php стоит практически на всех хостингах, затрудняюсь ответить где его нет. С другой стороны всё зависит от поставленных задач.

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

На фреймворки я забил большущий болт, некогда изучать и js и php и фреймворки обоих языков.

Php программистов море, потому что начинать изучение с php очень легко и просто, старт изучения гораздо легче чем js. Книг тоже много и есть очень хорошие, хотя и плохих навалом.

По поводу руби или питона, я бы выбрал Питон, в линуксе я его чаще встречаю, чем руби.

php программист, php программисту рознь
ты можешь писать приложения на zend или yii
моешь клпать модули для джумлы, drupal или wordpress
получить сертификат и ваять для 1с битрикс

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

К примеру я не могу писать для drupal к примеру, так как я воспитан на c++ то ООП для меня всё. Без него я как на другой планете. Посли красивого yii выворачивает наизнанку от убожества битрикса т.д.

Бывает, но иногда проходит. ООП головного мозга лечится расширением кругозора.

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

Тогда уж быдлооопышниками с быдлокодерами.

Так как иначе оопешниками с процедурщиками.

Попиши на Erlang.

DjDiablo,
да войны не надо :D

erlang всятаки для многопроцессорных/многоядровых систем создан, тыбы ещё ассемблер привёл в пример. Это не тот класс задач.

я рассматриваю вопрос моделирования.
Есть плита есть чайник, плита передаёт тепло чайнику, чайник реагирует и нагревается, по достижению какого то уровня он начинает трещать, при достижении критичиской температуры он воспламеняется. На ооп всё понятно, есть экземпляр класса чайник. Каждый раз при повышении температуры, какая-то функция чайника сопоставляет температуру с критическими значениями и определяет что надо трещать или воспламенятся. То есть чайник отвечает сам за своё поведение, плита отдельно, чайник отдельно.

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

Да бог с ней с логикой, посмотрим на удобство.
плита вызывает функцию A нагрева чайника, функция A вызывает все остальные. b-треск C-возгорания
1) если чайников много, то между функциями a-b, a -c постоянно придётся таскать указатель на структуру со свойствами чайника

2) если появится второй тип чайников, которые не загараются а взрываются ( функция d)то придётся не только писать функцию d но и изменять функцию a чтобы она взависимости от типа чайника вызывала либо С либо D.. Либо менять поведение плиты, чтобы она для разного типа чайников вызывала разное a(нагрев который вызывает взрыв вместо возгорания), что уж со всем странно, с какого перепуга плита должна подстраиватся под чайник.

3) если будет сто типов чайников и каждый со свое реакцией, то функция A станет адово сложной, ибо вынуждена учитывать в себе поведение всех 1000 типов чайников при максимальном нагреве. Придётся выносить вызов возгорания/взрывания/ расплавления и тд в другую отдельную функцию. Я же должен как то разгрузить функцию A.

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

А теперь вопрос, НАХРЕНА ВЕСЬ ЭТОТ ГЕМОР НУЖЕН ?
Ведь в ооп мне достаточно создать один базовый класс чайника, и унаследовать от него хоть 100 хоть 1000 различных видов чайника, там где реакция будет отличаться я просто впишу нужную функцию реакции и всё.

DjDiablo,
да, именно поэтому и придумали ООП

DjDiablo,
Это абсолютно беспредметный разговор "на тему". Абстрактные сравнения - словоблудие. Ты бы ещё пример с конями в вакууме привел. Примеры про чайники оставь для школьников. Если хочешь что-то показать, то приведи пример того, что на процедурном нельзя сделать, что можно на ООП и от этого только выиграет модель всегда и везде!

Задачи решаются исходя из необходимости. Теми инструментами, которые нужны для решения поставленной задачи. Мне php ООП нафиг не сдалось, т.к. у меня полностью отсутствуют объекты - ибо не нужны! От этого я только выигрываю простотой кода и его поддержки и расширяемости и скоростью выполнения.

серверную часть

DjDiablo, спасибо за картинки и мнение )
чем? Я знаю не так много языков и технологий, но исходя из того что имею, могу утверждать, что на js мне писать удобнее/логичнее/проще, чем на vba/vbscipt.
не то, чтобы я искал легкие пути, но все говорит в пользу пыхи. Т.е. зная пыху, например, будет проще найти работу, чем зная питон.

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

Согласен полностью, всему своё место.

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

Наиболее естественно выглядит решение на инкапсуляции, которое можно было бы использовать за счёт включение ссылок на функции в структуру в которой хранятся свойства чайников Но это будет уже инкапсуляция, а это часть ООП, ООП головного мозга как мы знаем от gozar'а это болезь.

Ну тогда остаются надо полагать хуки, либо событийная система.
Ну и кто нас сегодня поразит мощью процедурного стиля ???? :D :D :D

Именно поэтому я на это и указал. Превратили дружно учебники по ООП в изучение зоопарка или ещё какой-нибудь ерунды. Если ты говоришь о справочнике, то и говори - справочник.

Какой задачи? Коней в вакууме? Какие ещё чайники, магазин по продаже чайников делаешь?

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

Я и нехотел некого удивлять
Меня задело ООП головного мозга :D
Я говорю ООП это круто, если пишеш cms или приложение, вот собственно и всё.

А я говорю php ООП нафиг не сдалось для cms, вот собственно и всё.

Что, ООП нужно для того чтобы дергать из базы страницы и отдавать в браузер? Так это можно делать 2-3 строчками. ООП нужно, чтобы принимать от браузера контент страницу и писать её в базу? Ну хорошо тут можно обойтись 40 строчками накрыв почти любой сложности cms.

Давай поточнее, что такое можно написать на PHP ООП, что нельзя в процедурном стиле?

Я могу например сказать, что PDO нужно для того чтобы избежать инъекций, сделать код короче и читабельней. Про ООП я так же однозначно сказать не могу.

В процедурном стиле можно сделать всё тоже что и на ооп, однако всё тоже можно сделать и на ассемблере :D

DjDiablo,
Ну тогда на ассемблере круче чем на ООП. :D

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

Ты можешь это доказать?

Года 3 назад меня тут запинали за процедурный стиль кода. Ну тогда я был маленьким и глупым, ещё не просекал ООП.
Сейчас же я предпочитаю ООП. Мне так легче понимать/расширять код.

Если кто не в курсе, на хабре сейчас неделя ООП. Там эта тема разжевана со всех сторон.

По теме: NodeJS не язык. Но советую познакомиться с этой платформой. PHP отстой, попробуй Perl, Phyton, Ruby, Erlang.

:)

Я с перла начинал, вряд ли вернусь. Но и с PHP я собираюсь потихоньку расстаться.

Ты не понимал ООП PHP? Теперь ты его понимаешь и используешь? Речь идет не о абстрактном ООП.

А ты сомневаешся ??? :D :D :D
рейтинг популярности языков программирования

В твоей табличке, да сомневаюсь.

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

табличка с хабра
я для тебя код нарисовал, специально выдумывал сидел задачу, интересную, практичную, и весёлую :D

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

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

Достаточно реализиции одних контролёров, хотя бы на псевдокоде.

пример вызова приложения
index.php?contr=test&cmd=index
результат
<ul> <li>меню 1</li> <li> меню 2</li> <ul>
bla bla это контент

код ядра

//фабрика контролёров, возвращает экземпляры контролёров
// при создании экземпляра проверяются права доступа
class manager{
    static function getComponent($name){
        requere ("controller/".$name.php");
        $n="controller".$name;
        $result=new $name;
        
        if ($result->rights()) return $result;
        else die ("доступ закрыт");
    }
}

// базовый класс всех контролёров
class controller{
    public function init(){

    }
    public function rights($usr){
        return true;
    } 
}

//базовый класс приложения, инкапсулирует в себе настройки, глобальные переменные приложения, и базовый функционал
class Capp{
    
    function Capp(){
        //здесь приложение инициализруется, грузит конфиги и занимается прочей фигнёй
    }
    
    public function go(){
        // фабрика вернёт экземпляр контролёра
        $cmp=manager::getComponent($_GET['contr']);
        // это типо события, я инициализирован
        $cmp->init();

        //вызовем метод контролёра 
        $cmd="cmd_".$_GET['cmd'];
        $cmp->$cmd();
    }
}

$app=new Capp();
$app->go();

первый контролёр controller/Test

class controllerTest extends controller{
    function cmd_index(){
        $cmp=manager::getComponent("menu");
        $result=$cmp->cmd_menu();
        $result.="bla bla это контент";
        echo $result;
    }
}

второй контролёр controller/Menu

class controllerMenu extends controller{
    function cmd_index(){
        echo "hello";
    }
    function cmd_menu(){
        return "<ul> <li>меню 1</li> <li> меню 2</li> <ul>";
    }   
}

Ну я про JS говорил, в PHP я до сих пор нуб.

Сокращу код пожалуй до этого, раз результат одинаковый.

<?php
echo '<ul> <li>меню 1</li> <li> меню 2</li> <ul>bla bla это контент';
?>

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

А как же поддержка и расширяемость?

О какой расширяемости идет речь?

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

В подавляющем большинстве случаев можно просто поставить switch

я смотрю тебе опять кони в астрале, программы писать мешают :D :D :D

результат неодинаковый,
в одном случае это базовая идея для движка, в твоём случае чушь из одной строчки:D

Решение в процедурном стиле существует штуки два как минимум, пусть не такие красивые как в ооп, но они есть. Жду до завтра, потом сам отвечу.

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

но это всё детские шалости, страшнее всех задача с чайниками :D :D :D

Обычная такая расширяемость. Сталкиваюсь постоянно, ты нет?

Я ещё не писал "всё", поэтому уверенно сказать не могу. Я склоняюсь к тому, что всё можно написать в процедурном стиле. Более того, мне нравится идеология Erlang-а, на хабре есть очень хорошая статься на эту тему.

Но я бы хотел услышать ответ на другой вопрос: что дает процедурный стиль, чего не даёт ООП? Меньший объем кода, расхода памяти? Возможно, но это ли главное?

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

И ещё. Твой пример:

на самом деле не пример процедурного подхода - тут нет процедур. Просто исходный пример неудачный.

Ты не показал ничего интересного, жди хоть до послезавтра.

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

Есть такое слово - достаточно. Так вот этого мне достаточно.

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

В целом это утверждение относиться в той же степени и к процедурному подходу.

У меня есть проблема. У меня почти нет повторяющихся частей кода. Вот незадача. Мне нечего реюзабить. Мне вообще незачем создавать объекты, тогда напрашивается вопрос: - зачем мне классы?

Легкость восприятия? Когда это ООП стало легче в восприятии? А не от комментариев ли зависит скорость понимания происходящего в коде?

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

Какой пример, такой и ответ.

Чтобы небыло батхерта, я могу сказать что в js я использую ООП, много и жирно :) Ну ещё могу сказать, что наверняка бы использовал ооп php в шаблонизаторе, но не уверен, т.к. я не хочу писать на php в последнее время.

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

Cоциальная сеть в одном файле ??? :blink:

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

Ты это признаешь? :) Ты сам себя так назвал. Прости, если это задело твои чувства, но это просто вывод из твоих слов.

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

Хотите поговорить об этом? (с)Зигмунд Фрейд.

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

Оно есть и в ООП. Всему должна быть мера.

Требую пример.

С момента его появления. Людям легче ассоциировать программный объект с физическим. Его свойства и методы легко проецируются в мозг.

Опять же - всему есть предел. Посмотри пример. Внешне - ООП (конструктор, вся хуйня), но внутри методов нет объектов - они не нужны там! И как ты предлагаешь реализовать буфер в процедурном стиле? PHP-way с кучей методов? Жду ответа.

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

NodeJS:

Ресурсы посвященные NodeJS:
Руководства по Node.js
БЫСТРЫЙ ВЕБ-СЕРВЕР НА JAVASCRIPT ДВИЖКЕ V8
Node.js для начинающих

Базы данных:
Перевод The Little Redis Book Redis - это NoSQL база данных которая очень хорошо дополняет NodeJS. Мне очень нравится.
The Little MongoDB Book

Статьи:
JUST — JavaScript шаблонизатор
Наглядно о потоке выполнения в Node.js
Разработка WEB-проекта на Node.JS
Полезные инструменты, туториалы и ресурсы
Удаленный вызов процедур в Node.js с использованием Now.js
О WebSocket-ах на примере реализации чата мгновенных сообщений с помощью node.JS Немного устаревшая статья.
Вызываем функции Windows API (и любые другие функции, написанные на языке Си) джаваскриптом из Node.js

CMS:
Calipso is a simple content management system

Не придирайся к словам.