@themailvnk, паттент не нужен. Если вам нужно сделать шаблонизатор простенький вы уже реализуете разделение логики и представления. ООП для этого использовать совсем не обязательно. Пример я дал чуть ниже, причем его можно додумать и получится вполне себе юзабельная штука.
@Taiyonoryoshy, текут не интерпритаторы/виртуальные машины, течет обычно стандартная библиотека, парсеры могут протекать (у PHP пару раз был баг связанный с этим вроде как)... Вообще сборщик мусора все за вас должен подбирать, если вы лишних ссылок на объекты не оставили. А что до борьбы с утечкой памяти - если вы определили что в этом виноват ЯП - баг репорт и обычно такие вещи оперативно фиксят.
Словом, 99,9% что ни Java ни Python сами по себе не текут. То что есть либы и под то и под другое, которые могут течь, это уже 100%. Но большинство популярных, которые используют больше двух человек, обычно от этого не страдают.
p.s. Псевдокод и байткод это несколько разные вещи) PHP и Python тоже сначала в опкоды/байткод транслируются, а у Java есть JIT, который эти опкоды может в зависимости от ситуации более оптимально выполнять, комбинировать по другому и т.д. (как и у PyPy, HHVM, HyppyVM).
распределенные приложения - приложения части которых запускаются в разных процессах, на разных машинах и т.д. Там нужны механизмы взаимодействия всех этих частей отлаженные. Так же на Go удобно писать штуки типа DNS-серверов, различные сетевые сервисы и т.д.
Словом... мы видно о разном говорим. Мне Go импонирует для задачь где крайне удобно запилить пул из 1000 потоков и путь оно работает. А Node.js... если честно - я меня на нем завязана только сборка фронтэнда и все.
@Boniface Си может заменить и Go и Node.js, но время разработки будет на порядок выше. Надеюсь вы уловили суть. Вы не будете писать простенький push-сервер на go с точки зрения заказчика, так как с этим прекрасно справляется node.js и за довольно небольшой бюджет (js-ников много, очень много).
По поводу распределенных приложений - я уж точно колбэки не имел в виду, я больше имел ввиду более эффективную модель паралелизма в Go (в node.js из коробки даже потоков нету, все в одном делается). Вообще Go лучше уж с Erlang сравнивать, у них сходств явно больше чем c node.js.
@Boniface, все просто. Есть довольно большое количество задачь, которые на node.js банально быстрее реализовать. golang все же создавался несколько для других типов приложений. Да и JS знает на порядок больше людей, так что для бизнеса эта технология еще довольно долго останется основной для реализации разных чатиков и пуш-серверов. А для Go это лишь капля в море. Go больше подходит для написания распределенных систем, это то, чего вообще не может Node (ну как бы может в теории, но это будет ад).
@RadiationX что поделать... можете попробовать попрофалить, поинлайлить функции что бы уменьшить задержки на вызовы, попробовать использовать векторизацию, поиграться с FFT... вариантов много. Самый быстрый булр будет с применением шейдеров, но сами понимаете, работать это будет не везде.
@JRazor не путайте функциональный стиль и процедурный. Сейчас, с учетом ухода в паралелизм, функциональное программирование становится более востребованным даже в контексте ООП.
@marrk2 вопросы... ну... это не очень интересно. То есть да, что такое типы данных и какие они есть может и стоит спросить, ну и так, поспрашивать что бы оценить уровень знания подопытного (джуниора ж берем)... а дальше нужно смотреть как человек думает... Ибо если он не в состоянии быстро ориентироваться в информации, или будет тупить над простенькой задачкой то толку... То есть не обязательно нужно что бы человек задачку решил, просто мысли интересно увидеть.
Словом пусть лучше джуниор знает меньше но будет более обучаем и сообразительнее. Ибо сколько бы у джуниора нибыло знаний, всеравно придется переучивать...
@jsom поддерживаю. Использовать phonegap имеет смысл только на очень простых проектах (ладно, wifi direct довольно простая штука) и больше чем на одной платформе.
Таки што вы говорите. Я все еще надеюсь что люди ставят теги не просто так и тег open source исключает (хотя бы на ранних этапах) мысли о продаже и прибыли.
@hogddttr27, суть в том что вы не сможете так составить cssquery. Да и как бы предложенный способ никакого отношения к jQuery не имеет. Это сродни document.querySelector('*') и последующих обход все элементов и сравнение по атрибутам.
@sanchezzzhak оверхэд с кешами и этими шаблонизаторами в случае твига стримится к нулю. Зато повышается гибкость разработки (наследование шаблонов, можножность легко и просто экстендить функционал шаблонизатора), уменьшается вероятность XSS уязвимостей и всякого рода HTML/JS инъекций, ограничивает разработчика что бы тот не начал творить несусветную ересь в шаблонах + синтаксический сахар.
IDE прекрасно понимают синтаксис твига (плагины есть ко всем основным IDE), более того, в том же PhpStorm полная поддержка twig-а. А автокомплит по дефолту и в случае нативных шаблонов не будет работать для данных, есть только не написать в начале в phpdoc все что тутда экспоузится.
все эти "фифи шаблонизаторы не нужны php сам по себе шаблонизатор" - чушь. Точно так же как использовать CHtml/виджеты для вывода кнопочек (что меня очень повеселило в экстеншене для внедрения twitter boostrap в свое время).
