LINUX.ORG.RU

Релиз KPHP и движков

 , ,


1

3

Вечером 6 марта, состоялся долгожданный релиз языка программирования KPHP, от компании ВКонтакте. Исходный код KPHP доступен под лицензией GNU (GPL и LGPL). Исходный код ВКонтакте разрабатывается на PHP-подобном языке, названном KittenPHP или коротко KPHP.

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

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

  • PMemcached (“Persistent Memcached”)
  • Lists
  • Lists-X
  • Search
  • Storage
  • Texts
  • Hints
  • Queue

Исходный код движков и KPHP

Подробная документация

>>> Подробности

★★

Проверено: Shaman007 ()

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

ritsufag ★★★★★ ()
Ответ на: комментарий от KRoN73

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

note173 ★★★★★ ()

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

anonymous ()
Ответ на: комментарий от note173

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

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

KRoN73 ★★★★★ ()

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

anonymous ()
Ответ на: комментарий от yoghurt

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

anonymous ()
Ответ на: комментарий от Bad_ptr

кстати не.

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

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

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

qulinxao ★★☆ ()
Ответ на: комментарий от anonymous

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

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

qulinxao ★★☆ ()
Ответ на: комментарий от anonymous

т.е ООП лиш дизайнерский обвес , ровно настолько же насколько использование языка мнемоник(ака ассемблер) и в дальнейшем «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

qulinxao ★★☆ ()

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

darkenshvein ★★★★★ ()

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

Dron ★★★★★ ()
Ответ на: комментарий от anonymous

1. gtk (до 3)

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

yoghurt ★★★★★ ()
Ответ на: комментарий от yoghurt

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

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

qulinxao ★★☆ ()
Ответ на: комментарий от Xroft

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

Debasher ★★★★★ ()

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

Meyer ★★★★ ()
Ответ на: комментарий от Debasher

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

ChAnton ★★ ()
Последнее исправление: ChAnton (всего исправлений: 1)

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

kto_tama ★★★★★ ()

KPHP

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

Nebuchadnezzar ★★★★ ()
Ответ на: комментарий от yoghurt

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

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

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

anonymous ()
Ответ на: комментарий от ChAnton

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

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

Debasher ★★★★★ ()
Ответ на: комментарий от umren

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

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

TDrive ★★★★★ ()
Ответ на: комментарий от q11q11

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

TDrive ★★★★★ ()
Последнее исправление: TDrive (всего исправлений: 1)
Ответ на: комментарий от Debasher

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

ChAnton ★★ ()
Последнее исправление: ChAnton (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

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

ChAnton ★★ ()
Последнее исправление: ChAnton (всего исправлений: 2)
Ответ на: комментарий от anonymous

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

...

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

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

yoghurt ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

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

quiet_readonly ★★★★ ()
Ответ на: комментарий от Debasher

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

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

quiet_readonly ★★★★ ()
Ответ на: комментарий от KRoN73

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

buddhist ★★★★★ ()

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

Zubok ★★★★★ ()
Ответ на: комментарий от umren

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

ChAnton ★★ ()
Ответ на: комментарий от anonymous

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

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

ChAnton ★★ ()
Последнее исправление: ChAnton (всего исправлений: 1)

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

SI ★★☆☆ ()
Ответ на: комментарий от vitalif

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

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

anonymoos ★★★★★ ()

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

Nebuchadnezzar ★★★★ ()
Ответ на: комментарий от anonymoos

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

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

ChAnton ★★ ()
Последнее исправление: ChAnton (всего исправлений: 1)
Ответ на: комментарий от quiet_readonly

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

stevejobs ★★★★☆ ()
Ответ на: комментарий от anonymoos

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

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

tailgunner ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.