или к кедам пришили

HHVM поддерживает кучу фреймворков, а тут даже ООП нет.

Если задача взять из базы и отдать во вьюшку, то не нужно.

К сожалению, со столь примитивной задачей я последний раз сталкивался лет 12 назад :)

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

юникод поддерживает?

привет Броняша

Скажи почему бы не сменить Твайли на Редкость, у неё же Опал!

Что-то мне кажется, на их сайте задачи не очень примитивные

А это уже третий вопрос :)

Вот читаю, что без ООП «ненужно». Как они там без него живут и т.д. и т.п. А вот все высказавшиеся по этому поводу понимают, что: 1. ООП - это лишь дизайнерский обвес над процедурным программированием. Как бы, всё это можно решить без классов и объектов. 2. Вообще при должном проектировании можно обойтись с минимумом процедур (используя, тапример include (по крайней мере в php)) даже на достаточно сложных задачах. Конечно для этого надо потратить время на проектирование. 3. Собсвенно, на сложных задачах остутствие проектирования более опасно, нежели отсутствие объектов и классов?

ООП - это лишь дизайнерский обвес над процедурным программированием

Здесь твоя главная ошибка

Мне сейчас сильно лень искать ссылки на именитых мастеров, по этому приведу всево 2 примера из практики, где вроде как обходились без ООП, а вроде как и с ним. (т.е. логически классы и объекты этих классов были реализованны, но несколько иными возможностями).
1. gtk (до 3)
2. drupal (до 7 - 8)(это как раз из PHP)
Да, я понимаю, что и те и другие першли на нормальное ООП, но ведь до этого как-то спровлялись. Т.е. вывод для себя - да нормальное ООП несколько удобней, но не критично.

кстати не.

под отсутсвием ооп подразумевается нет наследования(своего) не так ли?

али даже свои составные(ака структуры/записи) не можно ваять? ибо всё есть асоциативный массив и узбагойса.

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

если ООП это именно то , как компромисно реализованно было в мэйнстриме то уже контекст сменился и ....

если ООП это АТД[наследование] то это очень как раз таки облегчает процедурное(хвала ему) программирование.

т.е ООП лиш дизайнерский обвес , ровно настолько же насколько использование языка мнемоник(ака ассемблер) и в дальнейшем «hll» лиш дизайнерский обвес вокруг кодирования маш.кодами.

короче тебе

Bret Victor The Future of Programming - YouTube

http://www.youtube.com/results?search_query=future of programming youtube&amp...

http://www.youtube.com/watch?v=8pTEmbeENF4

Нахуа это все если есть http://vibed.org/ ?

http://worrydream.com/#!/dbx

А давайте теперь каждый напишем по одному вконтакте?

Вроде не нужно, но я побёг собирать ::)

1. gtk (до 3)

GTK с появления GObject (когда он стал GTK+) - вполне себе объектно-ориентирован. Кстати, отсутствие в языке ключевого слова class (и иже с ним) ещё вовсе не говорит о том, что на нём нельзя писать ОО-код.

отсутствие в языке ключевого слова class (и иже с ним) ещё вовсе не говорит о том, что на нём нельзя писать ОО-код

золотые слова

Наверное переписать весь ВК сложнее чем написать новый компилятор.

Зачем оно нужно? Код без ООП вполне можно писать и на PHP.

Написано же: пхп жрёт и тормозит.

Интересная технология, но вот нужна ли она где-то, кроме вк? В мордокниге вон, D немножко используется, в критичных местах

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

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

KPHP

Китайско-Русская Народная Республика? И тут нацпол =(

Кстати, отсутствие в языке ключевого слова class (и иже с ним) ещё вовсе не говорит о том, что на нём нельзя писать ОО-код.

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

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

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

Оно тормозило ещё когда ООП в нём небыло. Что конкретно тормозит - не знаю, не интересно.

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

Мы не вк судим, а ЯП обсуждаем.

Вот это уже более интересно. Только нужно было написать не «Новый ЯП KPHP» а «Транслятор пхп кода в код С++». Намного меньше было бы вопросов.

Что может жрать и тормозить в PHP, в котором не используется ООП?

Тормозить не знаю что может, а вот жрать оно всегда гораздо http://www.php.net/manual/en/internals2.variables.intro.php

Как-то расплывчато вы говорите. Тормозило до ООП, но что, где и когда конкретно не знаете. Воспринимаю это как отписку-лишь бы сказать. Не тормозит там ничего без ООП. Да и потом есть тот же python, хочешь с ООП, хочешь без-и работает гораздо быстрее чем любой ПХП в любом виде. Так что придумывать подобные велосипеды, причем копируя синтаксис языка, который и так можно использовать без ООП практически с той же производительностью, что оригинальный ПХП без ООП считаю неразумным.

Тормозить не знаю что может, а вот жрать оно всегда гораздо >http://www.php.net/manual/en/internals2.variables.intro.php

Возможно, но надо тестить. Хотя все равно велик, лишнее. Если только использовать совместимость синтаксиса для переноски старых версий проектов на новый ЯП. Но без ООП уже давно на ПХП никто не пишет(ну или почти никто не пишет). А для производительности можно использовать быстрый и мощный python, и даже с ООП.

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

...

приведу всево 2 примера из практики, где вроде как обходились без ООП, а вроде как и с ним

Боюсь, что тут как с женщиной, которая не может быть «немножко беременной».

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

Сабж, как и hhvm, полезен исключительно для работы с унаследованным PHP кодом. Проект начинается на обычном php, развивается, и со временем при появлении highload его можно перевести на hhvm или kphp, когда будут исчерпаны другие относительно простые оптимизации.

Если сабж не поддерживает ООП, то для многих проектов он не способен выполнять свою основную функцию — ускорять существующий код. А если переписывать, то лучше на Go, чем на kphp.

Оно тормозило ещё когда ООП в нём небыло. Что конкретно тормозит - не знаю, не интересно.

По словам знакомых, Java-сервлеты тормозят таки больше.

и работает гораздо быстрее чем любой ПХП в любом виде.

пруфы будут?

Я к тому, что это какие-то очень неточные тесты.

от компании НеНужно.

ВНенужно

Ждем ВКоммон лисп.

Вообще-то это общеизвестный факт. Тестов много было. Если поискать-найдете. Просто копаться нет времени особо. Но все обсуждалось не раз. То что Python быстрее имеется ввиду.

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

Реализовать то конечно возможно, но какой ценой. Да и потом все зависит от конкретной задачи, где-то целесообразно использовать именно ООП, и без него трудно или порой почти невозможно, а где-то ООП вообще вреден. И потом ООП-это скорее не стиль, а парадигма.

Открыли америку что ООП тормозит код

что-то я боюсь представить, какой у них там код...

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

Если вспомнить странное определение объекта, как функции с внутренней памятью для хранения своего состояния между вызовами, то можно сказать, что для создания объектов не нужны специальные возможности языка. Полиморфизм и наследование никогда не были прерогативой ООП. В современных языках программирования ООП используется больше как средство организации кода. Смолток - это другая история, но я сомневаюсь, что в PHP настолько мощная объектная система. Если в KPHP есть модули и пространства имён, то я не думаю, что отсутствие ООП такая большая потеря.

Да, когда я впервые столкнулся с ООП, я был сильно удивлен тем, насколько просто на нем программировать. Хотя поначалу долго пытался понять, что такое объект и зачем он нужен, при том что все вроде-бы дыло очевидно в теории. Но ООП-это конечно совсем другой стиль мышления, нежели процедурное программирование.

Но по большому счету, те же структуры в си, чем не объекты...

а представляешь как это ядро Linux без классов?

можно вначале сделать итерацию по рефакторингу PHP-с-классами на PHP-без-классов, и следующую итерацию - уже PHP->kPHP

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

Кхм. А в чем разница между «структурой алгоритма» и «реализацией алгоритма»?