The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Релиз PHP 5.5.0, opennews (??), 21-Июн-13, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


3. "Релиз PHP 5.5.0"  –1 +/
Сообщение от бедный буратино (ok), 21-Июн-13, 09:32 
А вообще, судя по ченчлогу, php плавно скатывается в python (разработчики явно с туториала python-а не вылазили), только с С-синтаксисом и набором legacy-ужаса.

Но, опять же, зачем? Зачем нишевую вещь превращать в гибрид ужа и матрёшки? Кому это надо? Отпугнуть одних и не привлечь других.

Или это уже агония?

Ответить | Правка | Наверх | Cообщить модератору

14. "Релиз PHP 5.5.0"  +7 +/
Сообщение от Аноним (-), 21-Июн-13, 10:11 
Тоже самое говорили такие же «аналитики» про 5.0 версию — «php скатился в java», «зачем это нужно». Агония затянулась, не находите?
Ответить | Правка | Наверх | Cообщить модератору

15. "Релиз PHP 5.5.0"  –1 +/
Сообщение от бедный буратино (ok), 21-Июн-13, 10:18 
> Тоже самое говорили такие же «аналитики» про 5.0 версию — «php скатился
> в java», «зачем это нужно». Агония затянулась, не находите?

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

Кто использует родные функции map/reduce/filter в php, поднимите руки?! Кто использует нововведения 5.3 и 5.4, много ли таких?

Ну а что половина ченчлога это python в чистом виде, вплоть до скобочек - это вообще смешно.

Ответить | Правка | Наверх | Cообщить модератору

32. "Релиз PHP 5.5.0"  +1 +/
Сообщение от куросава (?), 21-Июн-13, 14:05 
Пхп есть смысл выбирать хотя бы потому, что это сейчас единственный нормальный инструмент веб-разработки. Питон - поделка для лабораторных исследователей и админских утилит, с убогим ООП и отсутствием поддержки контрактного программирования "из коробки". Руби - тот же перл, где можно одно утверждение написать восемью способами, поэтому суппортить проекты на нем невозможно. Ява - микроскоп для забивания гвоздей.
Ответить | Правка | Наверх | Cообщить модератору

34. "Релиз PHP 5.5.0"  –1 +/
Сообщение от arisu (ok), 21-Июн-13, 14:31 
выше мы можем прочитать поппеншмерц похаписта.
Ответить | Правка | Наверх | Cообщить модератору

36. "Релиз PHP 5.5.0"  –1 +/
Сообщение от Аноним (-), 21-Июн-13, 14:40 
> Руби - тот же перл, где можно одно утверждение написать восемью
> способами, поэтому суппортить проекты на нем невозможно.

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

Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

45. "Релиз PHP 5.5.0"  +/
Сообщение от Rodegast (??), 21-Июн-13, 16:40 
> Пхп есть смысл выбирать хотя бы потому, что это сейчас единственный нормальный инструмент веб-разработки.

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

Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

35. "Релиз PHP 5.5.0"  +3 +/
Сообщение от Аноним (-), 21-Июн-13, 14:39 
> Кто использует родные функции map/reduce/filter в php, поднимите руки?!

Все используют, они написаны на C и более оптимальны, чем если писать руками интерпретируемый цикл.

> Кто использует нововведения 5.3 и 5.4, много ли таких?

Ну как только мигрировали на серверах, так сразу и стали использовать, $res = []; удобнее писать чем $res = array();

> Ну а что половина ченчлога это python в чистом виде, вплоть до
> скобочек - это вообще смешно.

Смешно — это библиотеки python и их совместимость с python 2 и python 3 :)

Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

66. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 07:44 
> Ну как только мигрировали на серверах, так сразу и стали использовать, $res
> = []; удобнее писать чем $res = array();

Надо же :)

Только в python, наоборот, как-то нагляднее получается, когда пишешь list(), dict(), set(), tuple(). Чтобы сохранить единообразие при заполнении и использовании. Чаще требуется не пустой, а заполненный dict (а я вообще всегда использую свой mydict).

Как-то проще и писать, и читать

a = dict(users=users,girls=girls,datas=datas)

чем

a = { "users": users, "girls": girls, "datas": datas }

да и вообще, с таким "диктованием", как в python, проще вообще всё в dict-ы заворачивать, и вместо:

def myfunc(hello,world,yet1,yet2,yet319,bss):

if something:
   myfunc(hello,world,'','','','')
elif sky==14:
   myfunc(hello,world,sky,sky1,sky319,bss)
else:
   myfunc(hello,'no','no','no','no','no)

использовать:

def mykw(**kw):
    if 'sky' in kw:
         print 'sky!'
    if 'zzz' in kw:
         print 'zzz!'

r = dict(sky=14,hello=hello)
if something: r.update(zzz=something)
mykw(r)

впрочем, и в первом случае можно использовать дефотлвалуи
def myfunc(hello='',world='no',bss='bss'):
    if hello: print hello
    if world: print world
    if bss: print bss

myfunc(hello='15')
15
no
bss

myfunc(bss='')
no

или

r = dict(hello='',world='')
myfunc(**r)
bss


поэтому все эти страшные myfunc(nado,nado,nado,ochennado) - в прошлом, и поэтому dict(), list() используется довольно часто. И лучше привыкать к ним везде, это не такая уж проблема, написать a = dict() вместо a = {}

Ответить | Правка | Наверх | Cообщить модератору

77. "Релиз PHP 5.5.0"  +/
Сообщение от arisu (ok), 22-Июн-13, 13:21 
> myfunc(**r)

единообразие налицо, ага. {}, значит — это сложно, ради единообразия пишем dict(). а вот ** вместо какого-нибудь unpack() — это ничего, это нормально.

гвидофаны такие гвидофаны.

Ответить | Правка | Наверх | Cообщить модератору

79. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 13:27 
>> myfunc(**r)
> единообразие налицо, ага. {}, значит — это сложно, ради единообразия пишем dict().
> а вот ** вместо какого-нибудь unpack() — это ничего, это нормально.
> гвидофаны такие гвидофаны.

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

**r никак не отвлекает внимание, не усложняет лексический парсер глаз. myfunc(unpack(r)) однозначно усложнит парсинг глазами и увелчит нервную усталость (мозгу нужно о фигне думать) из-за двойных скобок. Терпеть не могу двойных (а уж как не могу терпеть тройных-четверных)))) скобочек, за ними всеми нужно следить, как за дитями маленькми. Хуже только } в условиях { :)


Ответить | Правка | Наверх | Cообщить модератору

103. "Релиз PHP 5.5.0"  +/
Сообщение от arisu (ok), 22-Июн-13, 15:16 
я не сомневался, что у тебя есть Обоснование. а вот я тебе скажу, что длинные слова вместо понятных знаков отвлекают намного больше. особенно если эти слова — часто встречающиеся конструкции. это как раз и есть мусор, на парзинг которого надо тратить лишнее время.
Ответить | Правка | Наверх | Cообщить модератору

109. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 15:20 
> я не сомневался, что у тебя есть Обоснование. а вот я тебе
> скажу, что длинные слова вместо понятных знаков отвлекают намного больше.

Это вы о чём?

Ответить | Правка | Наверх | Cообщить модератору

116. "Релиз PHP 5.5.0"  +/
Сообщение от arisu (ok), 22-Июн-13, 15:31 
>> я не сомневался, что у тебя есть Обоснование. а вот я тебе
>> скажу, что длинные слова вместо понятных знаков отвлекают намного больше.
> Это вы о чём?

myvar = {…} — шибко проще читается, чем myvar = dict(…).

Ответить | Правка | Наверх | Cообщить модератору

118. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 15:33 
>>> я не сомневался, что у тебя есть Обоснование. а вот я тебе
>>> скажу, что длинные слова вместо понятных знаков отвлекают намного больше.
>> Это вы о чём?
> myvar = {…} — шибко проще читается, чем myvar = dict(…).

raz=raz,dva=dva,tri=tri

шибко проще читается, чем

{ "raz": raz, "dva": dva, "tri": tri }

(даже сейчас в наборе я на вторую строчку затратил в три раза больше времени и больше отвлекался)

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


Ответить | Правка | Наверх | Cообщить модератору

119. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 15:35 
> raz=raz,dva=dva,tri=tri
> шибко проще читается, чем
> { "raz": raz, "dva": dva, "tri": tri }

кроме того, это вводит единообразие с вызовом функций, везде всё одинаковое.

Ответить | Правка | Наверх | Cообщить модератору

127. "Релиз PHP 5.5.0"  +/
Сообщение от arisu (ok), 22-Июн-13, 15:54 
> raz=raz,dva=dva,tri=tri
> шибко проще читается, чем
> { "raz": raz, "dva": dva, "tri": tri }

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

Ответить | Правка | К родителю #118 | Наверх | Cообщить модератору

135. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 16:02 
>> raz=raz,dva=dva,tri=tri
>> шибко проще читается, чем
>> { "raz": raz, "dva": dva, "tri": tri }
> совершенно не факт. во второй форме я сразу вижу, где имена полей,
> а где значения. в первой это не так очевидно, не «бросается в глаза».

это не просто факт, это самый настоящий мазефакт!

впрочем, кто как хочет, тут пусть так и использует. можно оба варианта. так указывает и мануал python 1.4 1996 года. в отличие от php, где это появилось совсем недавно "яки чудо". Спросил, кто какие фишки из 5.3/5.4 использует, а в ответ - []; вместо array(). чюдо.

Ответить | Правка | Наверх | Cообщить модератору

139. "Релиз PHP 5.5.0"  +/
Сообщение от arisu (ok), 22-Июн-13, 16:16 
слушай, тебя действительно какой-то похапэшник обидел? ну вот зачем ты тащишь похапэ туда, где его вообще не упоминали?
Ответить | Правка | К родителю #135 | Наверх | Cообщить модератору

142. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 16:20 
> слушай, тебя действительно какой-то похапэшник обидел? ну вот зачем ты тащишь похапэ
> туда, где его вообще не упоминали?

Вы за нитью дискуссии вообще следите? Это изначально был ответ на "в 5.3/5.4 где-то там появилось []".

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

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

Ответить | Правка | К родителю #139 | Наверх | Cообщить модератору

144. "Релиз PHP 5.5.0"  +/
Сообщение от arisu (ok), 22-Июн-13, 16:24 
> Вы за нитью дискуссии вообще следите?

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

> Но, скорее всего, научу их любить python

война была равна, сражались два…

Ответить | Правка | К родителю #142 | Наверх | Cообщить модератору

148. "Релиз PHP 5.5.0"  –1 +/
Сообщение от бедный буратино (ok), 22-Июн-13, 16:33 
>> Вы за нитью дискуссии вообще следите?
> а ничего, что с тех пор дискуссия ушла несколько в сторону?

У меня всё записано.

> или в голове жёсткие рельсы, шаг влево или вправо невозможен?

В теме про пых упомянуть пых - это что-то невероятное? :)

>> Но, скорее всего, научу их любить python
> война была равна, сражались два…

Дело было в вебе. Для веба python ахренительно хорош. Особенно, если прибирать за младоразработчиками. Пыхокод обычно используется один раз и после выкидывается, ни о каком развитии речи не идёт.

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

Ответить | Правка | К родителю #144 | Наверх | Cообщить модератору

150. "Релиз PHP 5.5.0"  +/
Сообщение от AlexAT (ok), 22-Июн-13, 16:35 
> Дело было в вебе. Для веба python ахренительно хорош.

Мы видим, угу.
http://w3techs.com/technologies/overview/programming_languag...

Ответить | Правка | К родителю #148 | Наверх | Cообщить модератору

157. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 16:50 
>> Дело было в вебе. Для веба python ахренительно хорош.
> Мы видим, угу.
> http://w3techs.com/technologies/overview/programming_languag...

Есть такая вещь, называется "свой мозг".

Технологии понятного твитера за 2 часа и в 100 строк на php я так и не увидел. Когда на php 99% кода 'write once', который потом выкидывается, когда приходит следующий пыхер - это просто круговорот. На python тупо удобнее, что не возьми, на python оказывается удобнее и быстрее. И не надо молиться на новую версию, чего там ещё возьмут у конкурентов - даже python 2.7 практически идеал для быстрой веб-разработки от чего-то мизерного до крупного и модульного (а слова php и "модульность" вообще рядом лучше не ставить).

Даже если по каким-то левым графикам и по legacy-поддержке php будет 122.4523%, на python всё равно будет удобнее. Это доказывается и тем, что знающие python и php используют python, и тем, что даже прожжёные пыхеры радуются появлению в php функций, которые в python уже были двадцать лет назад (а скольких там ещё нет).

Просто тупо удобнее. И это знают пыхеры. И поэтому у них никогда не было аргументов на тысячи записей (включая мою, со знанием php с 2002 года), что python превосходит php по удобству, по красоте, по понятности в разы. Только лабуда всякая. По одной простой причине - их бесит, что их раскрасивый php, убог как тряпка. Что их крыша тупо тырит функции с python и других, чтобы превратить php в "язык программирования". И что их тупость никогда не позволит им научиться писать на python грамотно, а неграмотно на python писать очень больно.

Поэтому пыхеры и ведут свои священные войны, и на реальные неопровержимые аргументы привностят только то, что Петя и его друзья-недоумки пишут на php (классная компания, ребята, там и оставайтесь. отлично, что сами себя на такой уровень поставили). Но всё равно, несмотря на силу недоумков, для серьёзной разработки php не используют, никто не будет делать серьёзный проект на php, в google нет php, инстаграмы пишут на python, а не на php. На php пишут только недоумки. Пусть пишут. Только пусть не лезут со своим калашным рылом, которое они называют "мнением". php-кодеры - это самый низший уровень. и пыхеры это прекрасно знают, все до единого. все до единого при слове "быдлокодер" и "быдлоязык" представляют, АВТОМАТИЧЕСКИ представляют именно php. И натуру не обманешь. :)

А на python всё равно писать удобнее. И это классный язык. Как бы пыхеры не пыжились и не пытались статистикой обмануть здравый смысл и элементарную логику (как будто они не понимают, почему php массовый, и что это вообще слабо коррелирует с культурой и удобством).

Ответить | Правка | К родителю #150 | Наверх | Cообщить модератору

161. "Релиз PHP 5.5.0"  +/
Сообщение от AlexAT (ok), 22-Июн-13, 17:00 
Пойми. Я не говорю, что python плох. Он для веба ни хорош, ни плох. Его просто НЕТ. Возможно, это временное явление, возможно - нет. Тренды говорят о том, что и не будет - но... кто знает, PHP когда-то тоже всерьез особо не воспринимали.
Ответить | Правка | К родителю #157 | Наверх | Cообщить модератору

258. "Релиз PHP 5.5.0"  +/
Сообщение от Geol (??), 24-Июн-13, 01:09 
>По одной простой причине - их бесит

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

Ответить | Правка | К родителю #157 | Наверх | Cообщить модератору

263. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 24-Июн-13, 06:04 
>>По одной простой причине - их бесит
> По моему бесит тут как раз пвас, остальные вроде спокойны.

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

А пыхеров бесит то, что все, кроме пыхеров, читают их "быдлокодерами". И что пых нигде не воспринимают. Приди в google и скажи "я веб-разработчик на php", смеяться будут так, что здесь будет слышно. А на python там много чего делается.

Ответить | Правка | К родителю #258 | Наверх | Cообщить модератору

265. "Релиз PHP 5.5.0"  +/
Сообщение от AlexAT (ok), 24-Июн-13, 07:22 
> Меня бесят все эти люди, которые ходят за мной и рассказывают, что
> php, оказывается, можно сравнивать с python. Бред полнейший, я на php
> писал, когда они ещё под стол ходили.

PHP нельзя сравнивать с Python - последний по сравнению с PHP достаточно куцый. С какой версии конкретно начинал?

> ещё не привёл примера, чтобы человек, много лет знающий и php
> и python, говорил бы, что ему больше нравится php

Ну я универсал, допустим. Сам себе аналитик+алгоритмист+кодер. Много лет знаю PHP, C, Pascal (Delphi), ASM ARM (Thumb), ASM x86. Начинал с ASM Z80. Писал и на жабах с шарпами и одинэсами. О всяких жабоскриптах, шелах, SQL'ях и прочих мелочах подробно не буду. В целом могу писать на чём угодно, лишь бы было вменяемо по реализации.

На питон взглянул два раза, прослезился с индентационного flow control и переноса условий в конец выражения, выкинул - уровень невменяемости такого решения даже обсуждать смысла нет. С перлом в своё время было примерно то же самое (только из-за зубодробительного синтаксиса) - и меня так же пытались отдельные упёртые личности убеждать, что перл - это сила. Ну и где он сейчас?

Ответить | Правка | К родителю #263 | Наверх | Cообщить модератору

267. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 24-Июн-13, 07:34 
>> Меня бесят все эти люди, которые ходят за мной и рассказывают, что
>> php, оказывается, можно сравнивать с python. Бред полнейший, я на php
>> писал, когда они ещё под стол ходили.
> PHP нельзя сравнивать с Python - последний по сравнению с PHP достаточно куцый.

И это говорят про язык, ченчлог каждой версии которого вызывает кучу вопросов "И ЭТОГО ТОЖЕ НЕ БЫЛО"? И пользователи которого запись $a = [] В 20XX ГОДУ воспринимают, как откровение!

Где на python используется 1 строка в несколько символов, в php делается много. Да и начинается проект php с горожения воркэраундов. Которые следующий разработчик не поймёт, и сделает всё по-своему.

"как язычники, ибо они думают, что в многословии своем будут услышаны"

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

Ответить | Правка | К родителю #265 | Наверх | Cообщить модератору

268. "Релиз PHP 5.5.0"  +/
Сообщение от AlexAT (ok), 24-Июн-13, 07:42 
> Где на python используется 1 строка в несколько символов, в php делается
> много.

Пытаться впихнуть всё и вся в одну строку - очень плохой тон. Отчасти то, что перл ныне RIP - обусловлено тем же подходом. Код становится нечитабельным. Объем сокращать нужно, но не в ущерб читабельности за счёт усложнения конструкций. Принцип KISS действует и на языки.

Ответить | Правка | К родителю #267 | Наверх | Cообщить модератору

271. "Релиз PHP 5.5.0"  +/
Сообщение от arisu (ok), 24-Июн-13, 13:14 
> Где на python используется 1 строка в несколько символов, в php делается
> много.

голубчик, в руби это реализовано намного красивей.

Ответить | Правка | К родителю #267 | Наверх | Cообщить модератору

270. "Релиз PHP 5.5.0"  +/
Сообщение от arisu (ok), 24-Июн-13, 13:12 
> Меня бесят все эти люди, которые ходят за мной и рассказывают, что
> php, оказывается, можно сравнивать с python.

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

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

Ответить | Правка | К родителю #263 | Наверх | Cообщить модератору

153. "Релиз PHP 5.5.0"  +1 +/
Сообщение от arisu (ok), 22-Июн-13, 16:39 
> Дело было в вебе. Для веба python ахренительно хорош.

такое же говно, как и любой язык, где нет first class continuations.

Ответить | Правка | К родителю #148 | Наверх | Cообщить модератору

158. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 16:53 
>> Дело было в вебе. Для веба python ахренительно хорош.
> такое же говно, как и любой язык, где нет first class continuations.

юзкейс, где это РЕАЛЬНО ПРИМЕНИМО, можно?

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

веб - это выборка. по запросу сделать выборку, учитывая внешние и внутренние влияния. почти всегда - это всё. какой смысл в "состоянии", если МИР ИЗМЕНИЛСЯ?


Ответить | Правка | К родителю #153 | Наверх | Cообщить модератору

160. "Релиз PHP 5.5.0"  +/
Сообщение от arisu (ok), 22-Июн-13, 16:57 
>>> Дело было в вебе. Для веба python ахренительно хорош.
>> такое же говно, как и любой язык, где нет first class continuations.
> юзкейс, где это РЕАЛЬНО ПРИМЕНИМО, можно?

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

Ответить | Правка | К родителю #158 | Наверх | Cообщить модератору

163. "Релиз PHP 5.5.0"  +/
Сообщение от AlexAT (ok), 22-Июн-13, 17:02 
> в любой обработке любой формы. собственно, везде, где есть необходимость что-то у
> юзера спросить. мне лично намного удобней не размазывать вопрос и ответ,
> а просто писать обычную функцию, которая выводит форму, вызывает какой-нибудь wait-for-answer
> и продолжает работу, не теряя состояния локальных переменных и прочих ништяков.

Да, было бы удобно. Если бы не одно "но"...

В вебе нет никаких гарантий для "wait-for-answer". Ответа может не быть вообще. Или быть, но не туда и с другими данными. Или просто через пару часов. Потому что на удаленной стороне - человек, а не машина с гарантированным паттерном поведения. И держать запущенным процесс страницы со сложной логикой для каждого пользователя бог знает сколько времени - накладно.

Ответить | Правка | К родителю #160 | Наверх | Cообщить модератору

166. "Релиз PHP 5.5.0"  +/
Сообщение от arisu (ok), 22-Июн-13, 17:05 
> Да, было бы удобно. Если бы не одно «но»…
> В вебе нет никаких гарантий для «wait-for-answer». Ответа может не быть вообще.

ну и фиг с ним. значит, continuation некоторое время полежит в сейфе, а потом его выкинут по истечению тайм-аута на сессию (или wait-for-answer вернёт какое-нибудь false, и функция отработает вариант «ниасилили»). с точки зрения функции это совершенно неважно.

> Или быть, но не туда и с другими данными.

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

Ответить | Правка | К родителю #163 | Наверх | Cообщить модератору

173. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 17:20 
>> Да, было бы удобно. Если бы не одно «но»…
>> В вебе нет никаких гарантий для «wait-for-answer». Ответа может не быть вообще.
> ну и фиг с ним. значит, continuation некоторое время полежит в сейфе,
> а потом его выкинут по истечению тайм-аута на сессию (или wait-for-answer
> вернёт какое-нибудь false, и функция отработает вариант «ниасилили»). с точки
> зрения функции это совершенно неважно.
>> Или быть, но не туда и с другими данными.
> не может. именно вот ситуации «что, куда и зачем» — разруливает фрэймворк.
> как именно — опять же неважно для функции, она ни о
> каких «сессиях» не знает и знать не хочет вообще.

Вы объясните, эта штука может восстанавливать историю? То есть, там есть каждый шаг, который пройден, до которого можно откатиться? Или просто состояние в определённый момент времени?

Ответить | Правка | К родителю #166 | Наверх | Cообщить модератору

177. "Релиз PHP 5.5.0"  +/
Сообщение от arisu (ok), 22-Июн-13, 17:26 
не буду я ничего объяснять, это бессмысленно. про «эту штуку» можно в интернетах почитать. там же и узнать, сколько всего интересного с «этой штукой» можно наворотить, и не только для вебни.
Ответить | Правка | К родителю #173 | Наверх | Cообщить модератору

179. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 17:31 
> не буду я ничего объяснять, это бессмысленно. про «эту штуку» можно в
> интернетах почитать. там же и узнать, сколько всего интересного с «этой
> штукой» можно наворотить, и не только для вебни.

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

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

Ответить | Правка | К родителю #177 | Наверх | Cообщить модератору

182. "Релиз PHP 5.5.0"  +/
Сообщение от arisu (ok), 22-Июн-13, 17:37 
> Твитеры в сто строк только так пишутся. :)

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

Ответить | Правка | К родителю #179 | Наверх | Cообщить модератору

193. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 18:04 
>> Твитеры в сто строк только так пишутся. :)
> вот это и есть «потолок» простоты гвидобейсика. когда задачи посложнее и строк
> побольше — начинается мегакостыляние. потому что невпихуемое, конечно, пихается в любую дырку, но с трудом.

А в чём проблема делать нормальную модульность? Нормальный обмен данными? Функции пофиг, что в неё пихают.

У меня есть проекты и посложнее, и намного посложнее. Эти примеры - прежде всего, учебные. Показывающие достоинства python и предоставляющие скелет.

Ответить | Правка | К родителю #182 | Наверх | Cообщить модератору

197. "Релиз PHP 5.5.0"  +/
Сообщение от AlexAT (ok), 22-Июн-13, 18:10 
> Эти примеры - прежде всего, учебные.

'nuff said.

Ответить | Правка | К родителю #193 | Наверх | Cообщить модератору

200. "Релиз PHP 5.5.0"  +/
Сообщение от arisu (ok), 22-Июн-13, 18:13 
проблемы начинаются, когда с этой фигнёй надо взлетать.
Ответить | Правка | К родителю #193 | Наверх | Cообщить модератору

186. "Релиз PHP 5.5.0"  +/
Сообщение от AlexAT (ok), 22-Июн-13, 17:48 
> Поэтому считаем, что python для веба удобен и прост. Твитеры в сто
> строк только так пишутся. :)

Проблема в том, что твитеры в сто строк никому не интересны. А за пределами оных начинаются грабли. Именно поэтому и имеем падающие 0.2% охвата.

Ответить | Правка | К родителю #179 | Наверх | Cообщить модератору

190. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 17:56 
>> Поэтому считаем, что python для веба удобен и прост. Твитеры в сто
>> строк только так пишутся. :)
> Проблема в том, что твитеры в сто строк никому не интересны. А
> за пределами оных начинаются грабли. Именно поэтому и имеем падающие 0.2% охвата.

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

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


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

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

Ответить | Правка | К родителю #186 | Наверх | Cообщить модератору

201. "Релиз PHP 5.5.0"  +/
Сообщение от arisu (ok), 22-Июн-13, 18:14 
> А пыхеры именно тем и занимаются, что переписывают, переделывают. Пыхеры требуются в
> больших количествах именно потому, что нужно поддерживать. А проекты на python
> требуют меньше внимания и заботы, потому что средний python-проект спроектирован гораздо
> лучше и нянек не требует. Потому что Дао.

поэтому пока питонисты медитируют (денег-то на еду нет, проект работает), пыхеры едят хлеб с колбасой.

Ответить | Правка | К родителю #190 | Наверх | Cообщить модератору

206. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 18:18 
> поэтому пока питонисты медитируют (денег-то на еду нет, проект работает), пыхеры едят хлеб с колбасой.

А нехер было в программисты идти. Но по факту получается наоборот - пыхеры работают, а проект нихрена не работает. А если разогнать программистов, и взять python, то проект работает. :) Для меня главное - чтобы проект работал, а не чтобы программы программировать. :) Я бы предпочёл ни строчки кода не писать, но, увы, с программистами работать - по волчьи выть.

Ответить | Правка | К родителю #201 | Наверх | Cообщить модератору

209. "Релиз PHP 5.5.0"  +/
Сообщение от arisu (ok), 22-Июн-13, 18:23 
а мне вообще на твой проект плевать, мне надо, чтобы колбаса регулярно поступала. вот так.
Ответить | Правка | К родителю #206 | Наверх | Cообщить модератору

211. "Релиз PHP 5.5.0"  +/
Сообщение от AlexAT (ok), 22-Июн-13, 18:24 
> А если разогнать программистов, и взять python, то проект

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

Ответить | Правка | К родителю #206 | Наверх | Cообщить модератору

214. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 18:26 
>> А если разогнать программистов, и взять python, то проект
> вряд ли будет существовать вообще в разумные сроки, потому что теоретики такие теоретики.

сроки стали раз в 10 меньше :)

Ответить | Правка | К родителю #211 | Наверх | Cообщить модератору

215. "Релиз PHP 5.5.0"  +/
Сообщение от AlexAT (ok), 22-Июн-13, 18:28 
> сроки стали раз в 10 меньше :)

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

Ответить | Правка | К родителю #214 | Наверх | Cообщить модератору

217. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 18:30 
>> сроки стали раз в 10 меньше :)
> Все проблемы начинаются обычно не на самом взлете, а в первые дни
> после оного, на этапе отладки/стресс-тестирования. И вот тут теоретики сольют, потому
> что реальные жизненные условия порушат все стройные описания, а адаптироваться они
> не умеют :) Видел в своей жизни очень много вещей, красиво работающих в концепте, и никак - в реальности.

А я видел много пыхеров. И вот это - про них. А заявленная вещь работает именно как надо. Потому что просто. А пыхеры "ниасилили".

ps. Смешно, что пыхер меня уверяет в том, что У МЕНЯ не работает.

Вся суть в том, что пыхеры используют php, потому что не знают или не понимают python, а python-щики используют python, потому что ОЧЕНЬ ХОРОШО ЗНАЮТ php (и пыхеров). То же самое, кстати, с виндой и linux/bsd, там тоже все уверены, что мне уже 8 лет в linux НЕУДОБНО и ВСЁ ПЛОХО. А то, что я решил 95% хронических проблем, и это реальное чудо, сэкономившее мешок времени - они просто не понимают.

Ответить | Правка | К родителю #215 | Наверх | Cообщить модератору

220. "Релиз PHP 5.5.0"  +/
Сообщение от AlexAT (ok), 22-Июн-13, 18:31 
Мы с тобой ниже беседуем про инкапсуляцию данных сессии в URL/cookie. Так вот: повторюсь - это всё красиво только в теории. Сферической и в вакууме, с неограниченным ресурсом и возможностями.

А в реальности твой запрос с хистори обрежется где-то на 4-16K на большинстве веб-серверов. Ну или тебе засрут память твоего сервера запросами по несколько мегабайт хедеров в случае DoS.

Насчет Linux/BSD - тут скорее как раз PHP/Python. Вторые в парах одинаково уверены, что у них всё идеально, и вообще по феншую. Несмотря на 0.2% охвата и продолжающееся вымирание.

Ответить | Правка | К родителю #217 | Наверх | Cообщить модератору

225. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 18:41 
> Мы с тобой ниже беседуем про инкапсуляцию данных сессии в URL/cookie. Так
> вот: повторюсь - это всё красиво только в теории. Сферической и
> в вакууме, с неограниченным ресурсом и возможностями.
> А в реальности твой запрос с хистори обрежется где-то на 4-16K на
> большинстве веб-серверов. Ну или тебе засрут память твоего сервера запросами по
> несколько мегабайт хедеров в случае DoS.

Поэтому планирование должно быть вперёд реализации. И не должно быть запросов по 4к, ибо это ненормально. А если должно - то должно обрабатываться, и сразу выбираться другие средства.

За досы, большие запросы и прочую ересь (как и за кеширование) будет отвечать nginx. А сервер в bottle.py по умолчанию однопоточный :), но при связке с nginx это не является проблемой, потому что все блокирующие запросы висят на фронтенде, и работа с ними - это уже искусство программирование nginx, и лучше оставаться теоретиком и не допускать крайних случаев в коде, чем завесить весь код крайними случаями, вместо того, чтобы отлавливать их на сервере или в middleware.

"Практики", которые решают задачи в лоб, как раз и превращают код в непрактичную кашу, которую никто не поддерживает, а следующий пыхер просто приходит, выкидывает, и заменяет своей (в одной достаточно крупной компании, которую я краем уха наблюдаю последние лет 5, такое произошло уже ни один раз).

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

Ответить | Правка | К родителю #220 | Наверх | Cообщить модератору

226. "Релиз PHP 5.5.0"  +/
Сообщение от AlexAT (ok), 22-Июн-13, 18:43 
> Поэтому планирование должно быть вперёд реализации. И не должно быть запросов по
> 4к, ибо это ненормально.

Так у тебя они будут - ты же собрался всю историю в запросе держать.

Вот о том и речь - что лучше СРАЗУ выбрать другие средства. Инженерно оправданные.

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

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

Который как раз и обрежет тебе запрос теми самыми 4-16К. А если не обрежет - один фиг, nginx, не nginx, память всё равно не резиновая.

Ответить | Правка | К родителю #225 | Наверх | Cообщить модератору

232. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 18:55 
>> Поэтому планирование должно быть вперёд реализации. И не должно быть запросов по
>> 4к, ибо это ненормально.
> Так у тебя они будут - ты же собрался всю историю в
> запросе держать.

Какую историю? Всё состояние. Обычный dict. Для корзинки магазина это список товаров (как минимум, для копирования). Если строка будет большой, значит, нельзя будет скопировать. Обидно. Но я в пыхерских проектах видел столько "нельзя" на ровном месте, что по сравнению с этим желание перекопировать весь магазин - это мелочи.

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


> Вот о том и речь - что лучше СРАЗУ выбрать другие средства. Инженерно оправданные.

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


> А не писать "концептуальную" вещь, которую через месяц надо будет выкинуть, ибо
> заложенные красивые концепты оказались полностью несовместимы с реальностью.

Пока это пыхеры свои мега-убер проекты всё время с нуля переписывают.


> Который как раз и обрежет тебе запрос теми самыми 4-16К.

Пусть режет. Если это запланированное поведение.


Ответить | Правка | К родителю #226 | Наверх | Cообщить модератору

233. "Релиз PHP 5.5.0"  +/
Сообщение от AlexAT (ok), 22-Июн-13, 18:56 
> Всё состояние. Если строка будет большой, значит

Её обрежет Web-сервер. На входе.

Ответить | Правка | К родителю #232 | Наверх | Cообщить модератору

235. "Релиз PHP 5.5.0"  +/
Сообщение от arisu (ok), 22-Июн-13, 19:00 
>> Всё состояние. Если строка будет большой, значит
> Её обрежет Web-сервер. На входе.

или браузер. на выходе.

Ответить | Правка | К родителю #233 | Наверх | Cообщить модератору

238. "Релиз PHP 5.5.0"  +1 +/
Сообщение от AlexAT (ok), 22-Июн-13, 19:06 
> или браузер. на выходе.

Вариант :)

Ответить | Правка | К родителю #235 | Наверх | Cообщить модератору

240. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 19:10 
>> или браузер. на выходе.
> Вариант :)

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

Ответить | Правка | К родителю #238 | Наверх | Cообщить модератору

237. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 19:04 
>> Всё состояние. Если строка будет большой, значит
> Её обрежет Web-сервер. На входе.

Пусть режет. Но "нельзя будет скопировать" имеется ввиду, что ограничитель сработает, и плашку выведет. Это всё не имеет большого значения. Точно так же можно вбить в сообщение форума 32 гб, а потом плакать, почему иконки на форуме покосились.


Ответить | Правка | К родителю #233 | Наверх | Cообщить модератору

229. "Релиз PHP 5.5.0"  +/
Сообщение от arisu (ok), 22-Июн-13, 18:50 
> Поэтому планирование должно быть вперёд реализации. И не должно быть запросов по
> 4к, ибо это ненормально. А если должно — то должно обрабатываться,
> и сразу выбираться другие средства.

итого: ты пишешь две реализации одного и того же вместо одной. передовой подход, да.

Ответить | Правка | К родителю #225 | Наверх | Cообщить модератору

236. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 19:02 
> итого: ты пишешь две реализации одного и того же вместо одной. передовой подход, да.

нет. если я хочу использовать сериализацию в url, я знаю, зачем. если не хочу - то я знаю, почему.

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

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


Ответить | Правка | К родителю #229 | Наверх | Cообщить модератору

162. "Релиз PHP 5.5.0"  +/
Сообщение от arisu (ok), 22-Июн-13, 17:01 
более того. при наличии first class continuations таких «обработчиков» у меня может быть вообще куча, каждый из них заведует своей частью страницы. и мне не надо размазывать эту логику, сохранять состояния между запросом и ответом и ты пы. поверь, таким образом строить какую-нибудь веб-апликуху намного удобней. и в итоге это получается сильно проще в поддержке и доработке/переработке.
Ответить | Правка | К родителю #158 | Наверх | Cообщить модератору

171. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 17:14 
> более того. при наличии first class continuations таких «обработчиков» у меня
> может быть вообще куча, каждый из них заведует своей частью страницы.
> и мне не надо размазывать эту логику, сохранять состояния между запросом
> и ответом и ты пы. поверь, таким образом строить какую-нибудь веб-апликуху
> намного удобней. и в итоге это получается сильно проще в поддержке
> и доработке/переработке.

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

Только я не особо понимаю, зачем мне может понадобиться сохранять состояние? Можно с примером?

Вот, например, у меня простейший модель магазина, который никому ничего нигде не сохраняет, а корзинку сериализует в сам url (можно и текущую страницу там же сериализовать), и юзер ходит, и может всегда восстановить любой ход, не зависящий от внешних данных (например, вот так вот сделано тут: http://nz.51t.ru/game1-new где вообще система ничего не сохраняет и нет никаких "состояний" на выдачу данных - всё "состояние" полностью сериализуется в url).

Но, при такой модели, если юзер кинет ссылку другому юзеру, у того отобразится чужая корзинка или что-то подобное. Для большей социальности и удобства юзера ссылка должна быть вида шоп.хрю/2 , чтобы легко было твитернуть, послать по sms, голубиной почтой, а главное - запомнить и вернуться. Чем мне тут может помочь это "повторение"?

Ответить | Правка | К родителю #162 | Наверх | Cообщить модератору

172. "Релиз PHP 5.5.0"  +/
Сообщение от AlexAT (ok), 22-Июн-13, 17:16 
> Вот, например, у меня простейший модель магазина, который никому ничего нигде не
> сохраняет, а корзинку сериализует в сам url

С ходу замечание по сути: а если юзер ходит с двух браузеров (или открытых страниц) сразу, а корзина должна быть одна?

Самый простой пример: я в ебее могу сразу 10-15 товаров открыть, но в корзину добавлю только 3-4 из них.

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

Ответить | Правка | К родителю #171 | Наверх | Cообщить модератору

174. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 17:24 
>> Вот, например, у меня простейший модель магазина, который никому ничего нигде не
>> сохраняет, а корзинку сериализует в сам url
> С ходу замечание по сути: а если юзер ходит с двух браузеров
> (или открытых страниц) сразу, а корзина должна быть одна?

Да там больше замечаний, на самом деле. :)

> Самый простой пример: я в ебее могу сразу 10-15 товаров открыть, но
> в корзину добавлю только 3-4 из них.
> И второе: если в корзине пара тысяч разных единиц? URL такой длины
> может уже и не влезть.

Выдавать при запуске ID, а { хэш: [товар,товар,товар], таймлимит: xxx } хранить уже в памяти, и регулярно чистить. Но это уже не так чисто и не так красиво, как в url :) Проще повесить плашку "не выпендривайся, олигарх. итить"

А вариант с двумя браузерами, кроме авторизации, даже в голову не приходит. Можно узнать, как двум браузерам получить одну корзинку?

Ответить | Правка | К родителю #172 | Наверх | Cообщить модератору

175. "Релиз PHP 5.5.0"  +/
Сообщение от AlexAT (ok), 22-Июн-13, 17:24 
> А вариант с двумя браузерами, кроме авторизации, даже в голову не приходит.
> Можно узнать, как двум браузерам получить одну корзинку?

Сессии, ID юзера + транзакционность :)

Ответить | Правка | К родителю #174 | Наверх | Cообщить модератору

176. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 17:26 
>> А вариант с двумя браузерами, кроме авторизации, даже в голову не приходит.
>> Можно узнать, как двум браузерам получить одну корзинку?
> Сессии, ID юзера + транзакционность :)

Как получить сессию из одного браузера в другой?

Ответить | Правка | К родителю #175 | Наверх | Cообщить модератору

178. "Релиз PHP 5.5.0"  +/
Сообщение от AlexAT (ok), 22-Июн-13, 17:29 
> Как получить сессию из одного браузера в другой?

Варианта реализации на самом деле два (больше, но остальные менее интересны):

1) разные ID сессий, один ID юзера внутри - наиболее распространенный вариант

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

2) привязка одного и того же ID сессии к ID юзера в пределах сеанса авторизации - иногда встречается, менее безопасно, вызывает грабли при закрытии сессии в одном из браузеров

Ответить | Правка | К родителю #176 | Наверх | Cообщить модератору

181. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 17:37 
>> Как получить сессию из одного браузера в другой?
> Варианта реализации на самом деле два (больше, но остальные менее интересны):

Я так и не понял одного - если зайти с двух браузеров, без авторизации, на главную страницу, то как понять, что это один юзер?

Если сериализовать всё состояние в url, то по url-у всегда можно сохранить и восстановить состояние, перекидывая ссылку туда-сюда.

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

История, которую не нужно хранить, достигается только "хранением" её на клиенте, в url - один url = одно состояние, идентичный url = идентичное состояние. Всё остальное для меня - одни загадки.

Ответить | Правка | К родителю #178 | Наверх | Cообщить модератору

185. "Релиз PHP 5.5.0"  +/
Сообщение от AlexAT (ok), 22-Июн-13, 17:46 
> Я так и не понял одного - если зайти с двух браузеров,
> без авторизации, на главную страницу, то как понять, что это один
> юзер?

Без авторизации - проблематично.

> Если сериализовать всё состояние в url, то по url-у всегда можно сохранить
> и восстановить состояние, перекидывая ссылку туда-сюда.

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

Таким образом мы так и приходим к тому, что на стороне юзера надо хранить только волатильные вещи, которые не жалко потерять между браузерами и т.д. А вот неволатильные - ID юзера, корзинку, etc. - надо хранить на сервере. И привязывать по возможности к ID юзера, а не к конкретному session ID.

Ответить | Правка | К родителю #181 | Наверх | Cообщить модератору

180. "Релиз PHP 5.5.0"  +/
Сообщение от arisu (ok), 22-Июн-13, 17:35 
ты сам всё и описал: отличный пример костыляния. с ходу, не думая: я делаю функцию «обработать-покупки», которая где-то там у себя вызывает функцию «дать-список-покупок». откуда этот список берётся — функции пофигу совершенно. хоть из файла, хоть из веб-сессии, хоть вообще из астрала. всё, что ей надо уметь — это обработать ситуацию «список ниасилили», что прекрасно укладывается хоть в проверку результата вызова, хоть в исключение.

в свою очередь, «дать-список-покупок» тупо печатает какую-нибудь табличку и вызывает «ожидать-списка-от-юзера» или что-то типа того. и так далее.

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

Ответить | Правка | К родителю #171 | Наверх | Cообщить модератору

183. "Релиз PHP 5.5.0"  +/
Сообщение от AlexAT (ok), 22-Июн-13, 17:38 
> в свою очередь, «дать-список-покупок» тупо печатает какую-нибудь табличку
> и вызывает «ожидать-списка-от-юзера» или что-то типа того. и так далее.

А если у тебя вместо "ожидать-списка-от-юзера" (внезапно) снова пришло "дать-список-покупок"? F5 нажали :)

Или результат "ожидать-списка-от-юзера" пришел вместо "дать-список-покупок" без вызова первого (снова внезапно).

Механика Web как раз и хитра тем, что мы не можем 100% закладываться на строго определенную последовательность запросов. Соблюдать последовательность там, где это строго необходимо - да, можем. С оговорками. Поэтому механизм "оффлайновых" сессий и прижился так хорошо. Другие не влезают.

Ответить | Правка | К родителю #180 | Наверх | Cообщить модератору

187. "Релиз PHP 5.5.0"  +/
Сообщение от arisu (ok), 22-Июн-13, 17:49 
> А если у тебя вместо «ожидать-списка-от-юзера» (внезапно) снова пришло «дать-список-покупок»?
> F5 нажали :)

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

> Или результат «ожидать-списка-от-юзера» пришел вместо «дать-список-покупок» без вызова
> первого (снова внезапно).

это как это? O_O

> Механика Web как раз и хитра тем, что мы не можем 100%
> закладываться на строго определенную последовательность запросов.

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

Ответить | Правка | К родителю #183 | Наверх | Cообщить модератору

189. "Релиз PHP 5.5.0"  +/
Сообщение от AlexAT (ok), 22-Июн-13, 17:52 
> да на здоровье. я ж сказал, это no-brainer

Это не no-brainer. Это нормальное поведение. Юзер может в соседней странице (и фиг ты определишь, что это другая сессия) спокойно уйти, посмотреть пару товаров, еще раз открыть тот же список (или не открыть), и спокойно далее кликнуть на него уже в первом окне (которое благополучно проспало свой шанс). Если такое поведение отстреливать - юзер просто сбежит.

>> Или результат «ожидать-списка-от-юзера» пришел вместо «дать-список-покупок» без вызова
>> первого (снова внезапно).
> это как это? O_O

Легко. См. пример выше. Пока юзер ходил по страницам, логика "забыла", что он запрашивал вывод списка. Или второй вариант - юзер оставил страничку со списком, процесс на сервере благополучно терминировался по таймауту через 10-15 минут (час, два), а юзер кликнул на кнопочку в открытой странице. Отстреливать? Опять же - сбежит.

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

Ответить | Правка | К родителю #187 | Наверх | Cообщить модератору

191. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 18:01 
> Легко. См. пример выше. Пока юзер ходил по страницам, логика "забыла", что
> он запрашивал вывод списка. Или второй вариант - юзер оставил страничку
> со списком, процесс на сервере благополучно терминировался по таймауту через 10-15
> минут (час, два), а юзер кликнул на кнопочку в открытой странице.
> Отстреливать?

Не должно быть такого.

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

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

Ответить | Правка | К родителю #189 | Наверх | Cообщить модератору

194. "Релиз PHP 5.5.0"  +/
Сообщение от AlexAT (ok), 22-Июн-13, 18:06 
> И, по идее, когда заходишь в корзинку, лучше сериализовать всю корзинку в
> url (или давать ссылку на такую корзинку), именно для того, чтобы
> было легко передавать состояние корзинки с помощью обычной закладки.

Шпасибо. Я хочу корзинку, при которой я могу открыть сразу 10-15 окон с товарами, поглядеть, сравнить, и добавить любые 3-4 из них. Без сериализации похода по товарам.

Сгенерить же специальные URL для передачи корзинки - задача на самом деле микронная.

Ответить | Правка | К родителю #191 | Наверх | Cообщить модератору

203. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 18:16 
>> И, по идее, когда заходишь в корзинку, лучше сериализовать всю корзинку в
>> url (или давать ссылку на такую корзинку), именно для того, чтобы
>> было легко передавать состояние корзинки с помощью обычной закладки.
> Шпасибо. Я хочу корзинку, при которой я могу открыть сразу 10-15 окон
> с товарами, поглядеть, сравнить, и добавить любые 3-4 из них. Без
> сериализации похода по товарам.

Сериализация не похода по товарам. url-ы у товаров обычные /2, /234, /244

Просто хранится list со списком (или со списком dict-ов, если нужно хранить что-то особое), чья сериализация (или ссылка на текущее состояние) хранятся в cookie. Добавляй, удаляй сколько хошь. Лучше, видимо, ссылку хранить, просто хранить список в памяти, а в cookie хранить его номер (можно и время жизни сессии, для убиения ненужных).

А в самой корзинке - хранить url. Когда мы заходим на товар - мы видим товар. И когда мы заходим по url корзинки - мы получаем идентичную корзинку, кто бы мы не были и откуда бы мы эту ссылку не взяли. Можно ею заменять текущую, а можно просто просматривать с возможностью замены по требованию или перекидки товаров туда-сюда.

А уж если позволять только авторизованным дёргать корзинку - это вообще не вопрос.

Ответить | Правка | К родителю #194 | Наверх | Cообщить модератору

208. "Релиз PHP 5.5.0"  +/
Сообщение от AlexAT (ok), 22-Июн-13, 18:21 
> Просто хранится list со списком (или со списком dict-ов, если нужно хранить
> что-то особое), чья сериализация (или ссылка на текущее состояние) хранятся в
> cookie.

Так в URL или в cookie? Cookie - та же сессия, только с другого боку. Ну и да - не все данные желательно в сookie хранить. Есть данные, которые пользователю знать не обязательно.

И опять же - cookie не спасут от проблемы "а вот я дома вчера авторизовался, товары подобрал, а с работы сейчас свою корзину не вижу".

Ответить | Правка | К родителю #203 | Наверх | Cообщить модератору

210. "Релиз PHP 5.5.0"  +1 +/
Сообщение от arisu (ok), 22-Июн-13, 18:24 
> Ну и да — не все данные желательно
> в сookie хранить. Есть данные, которые пользователю знать не обязательно.

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

Ответить | Правка | К родителю #208 | Наверх | Cообщить модератору

212. "Релиз PHP 5.5.0"  +/
Сообщение от AlexAT (ok), 22-Июн-13, 18:25 
> да ему вообще ничего знать не надо, кроме id сессии. меньше знаешь
> — крепче спишь. заодно и возможности что-то испортить значительно поменьше.

+100500

Ответить | Правка | К родителю #210 | Наверх | Cообщить модератору

216. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 18:28 
>> Ну и да — не все данные желательно
>> в сookie хранить. Есть данные, которые пользователю знать не обязательно.
> да ему вообще ничего знать не надо, кроме id сессии. меньше знаешь
> — крепче спишь. заодно и возможности что-то испортить значительно поменьше.

Восстановление всей ситуации. URL однозначно идентифицирует всю историю. Если что-то сломали, забыли, убежали, а потом по history пробежались назад, то всё действительно вернётся "как было".

А хранить всю историю на сервере, а у юзера только id и "шаг" - жаба давит.

Ответить | Правка | К родителю #210 | Наверх | Cообщить модератору

218. "Релиз PHP 5.5.0"  +/
Сообщение от AlexAT (ok), 22-Июн-13, 18:30 
> Восстановление всей ситуации. URL однозначно идентифицирует всю историю. Если что-то сломали

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

А history в URL/Cookie - просто не влезет в запрос. Размер заголовка запроса _в реальности_ не так уж и неограничен :)

Ответить | Правка | К родителю #216 | Наверх | Cообщить модератору

224. "Релиз PHP 5.5.0"  +1 +/
Сообщение от arisu (ok), 22-Июн-13, 18:39 
> А хранить всю историю на сервере, а у юзера только id и
> «шаг» — жаба давит.

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

Ответить | Правка | К родителю #216 | Наверх | Cообщить модератору

228. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 18:48 
>> А хранить всю историю на сервере, а у юзера только id и
>> «шаг» — жаба давит.
> вот поэтому, например, тебя вообще нельзя допускать к разработке сколько-нибудь серьёзных
> больших проектов. не потому, что они совсем не будут работать, а
> потому, что они будут работать криво, нагружать каналы лишними данными и
> обламываться в самый неподходящий момент, потому что «голова в шапочку перестала
> помещаться».

Сейчас лучше, чем никогда.

Хотя никогда зачастую лучше, чем прямо сейчас.


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


Это лирика. А физика в том, что не вижу проблем с сериализацией там, где она уместна. А чтобы узнать, что она уместна, достаточно попробовать. А чтобы узнать, что она вызывает проблемы, достаточно встроенного профайлера. Абстрактные случаи могут доказать всё, что угодно, и спор "мало оптимизации" vs "много оптимизации" vs "просторы для расширения" - он бесполезен, важна практичность, а не оптимизация и просторы. Если решение практично - оно будет использоваться. Если вызывает проблемы - то не будет. Всё.

Ответить | Правка | К родителю #224 | Наверх | Cообщить модератору

230. "Релиз PHP 5.5.0"  +/
Сообщение от arisu (ok), 22-Июн-13, 18:51 
проблема в том, что у тебя нет ни технической практичности, ни юзерской. вот в чём беда-то.
Ответить | Правка | К родителю #228 | Наверх | Cообщить модератору

234. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 18:58 
> проблема в том, что у тебя нет ни технической практичности, ни юзерской. вот в чём беда-то.

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

Хотя вроде есть, практичность, как и мастерство, не пропьёшь.

Ответить | Правка | К родителю #230 | Наверх | Cообщить модератору

192. "Релиз PHP 5.5.0"  +/
Сообщение от arisu (ok), 22-Июн-13, 18:03 
>> да на здоровье. я ж сказал, это no-brainer
> Это не no-brainer.

я имел в виду свой пример. :3

>> это как это? O_O
> Легко. См. пример выше. Пока юзер ходил по страницам, логика «забыла», что
> он запрашивал вывод списка.

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

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

> Или второй вариант — юзер оставил страничку
> со списком, процесс на сервере благополучно терминировался по таймауту через 10–15
> минут (час, два), а юзер кликнул на кнопочку в открытой странице.
> Отстреливать? Опять же — сбежит.

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

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

Ответить | Правка | К родителю #189 | Наверх | Cообщить модератору

195. "Релиз PHP 5.5.0"  +/
Сообщение от AlexAT (ok), 22-Июн-13, 18:08 
> как это «забыла»? это возможно только по истечению некоторого таймаута. что,
> в принципе говоря, совершенно логичное действие.

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

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

Ответить | Правка | К родителю #192 | Наверх | Cообщить модератору

202. "Релиз PHP 5.5.0"  +/
Сообщение от arisu (ok), 22-Июн-13, 18:15 
> В случае хранения сессии в виде данных — это нормально, потому что
> фреймворк восстановит весь контекст исполнения.

(вздыхает) continuation и есть такой контекст. в том-то и соль.

> У Web совершенно иная парадигма, нежели у консольных/гуевых аппликух.

да без разницы *в данном случае*. вообще.

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

да по-фи-гу.

Ответить | Правка | К родителю #195 | Наверх | Cообщить модератору

205. "Релиз PHP 5.5.0"  +/
Сообщение от AlexAT (ok), 22-Июн-13, 18:17 
> (вздыхает) continuation и есть такой контекст. в том-то и соль.

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

> да без разницы *в данном случае*. вообще.

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

Ответить | Правка | К родителю #202 | Наверх | Cообщить модератору

219. "Релиз PHP 5.5.0"  +/
Сообщение от arisu (ok), 22-Июн-13, 18:30 
>> (вздыхает) continuation и есть такой контекст. в том-то и соль.
> Не такой. Определить, что сохранять в этом контексте в каждом конкретном случае
> — невероятно сложно.

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

> Всё и сразу? Вот прямо-таки весь дамп области данных апликухи?

зачем? O_O у нас есть замыкание, оно знает, что в нём сохранено. вот это и писать. простейшие объекты там умеет (де)сериализовать сам рантайм, юзерские объекты надо этому научить один раз.

> Лучше все-таки оставить контекст на откуп самому приложению.

оно так и есть. только не надо руками над этим плясать.

>> да без разницы *в данном случае*. вообще.
> Огромная разница. В консольной аппликухе ты задал вопрос, и ждёшь на него
> ответа — и юзеру никуда не деться (кроме SIGKILL :) ).
> А в вебне он может спокойно сначала уйти на другую часть
> приложения, там что-то поделать, и только потом — ответить на твой
> вопрос.

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

Ответить | Правка | К родителю #205 | Наверх | Cообщить модератору

223. "Релиз PHP 5.5.0"  +/
Сообщение от AlexAT (ok), 22-Июн-13, 18:37 
> очень просто. надо только отвыкнуть пихать везде глобальные переменные — и сразу
> становится просто.

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

Но это не самое страшное. Самое страшное - это обеспечение конзистентности. К моменту получения от пользователя "ответа" ряд данных по цепочке вызовов вниз (да и просто) мог устареть, и эти данные всегда должны быть перезагружены из БД (например), а не из контекста. Или пересчитаны.

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

>> Всё и сразу? Вот прямо-таки весь дамп области данных апликухи?
> зачем? O_O у нас есть замыкание, оно знает, что в нём сохранено.

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

Ответить | Правка | К родителю #219 | Наверх | Cообщить модератору

227. "Релиз PHP 5.5.0"  +1 +/
Сообщение от arisu (ok), 22-Июн-13, 18:47 
> Непросто. Контекст может включать в себя целую пачку объектов, а цепочка вызовов
> — быть достаточно длинной.

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

> Но это не самое страшное. Самое страшное — это обеспечение конзистентности. К
> моменту получения от пользователя «ответа» ряд данных по цепочке вызовов вниз
> (да и просто) мог устареть, и эти данные всегда должны быть
> перезагружены из БД (например), а не из контекста. Или пересчитаны.

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

> Модель «вопрос-ответ» с полным сохранением контекста никуда не годится в случае наличия
> хоть малейшей доли параллелизма.

вообще-то абсолютно все программы работают по модели «вопрос-ответ». вообще все. просто иногда это *настолько* неочевидно… и писать это неочевидно, и читать это неочевидно, и проектировать это неочевидно. а всё от того, что сохранять состояния-continuations кода-то было действительно дорого.

>>> Всё и сразу? Вот прямо-таки весь дамп области данных апликухи?
>> зачем? O_O у нас есть замыкание, оно знает, что в нём сохранено.
> И никакой цепочки вызовов тоже не существует? Если нет — модель годится
> только для простейших аппликух, где нет никакой вложенности и/или зависимости контроллеров.

(вздыхает ещё раз) con-ti-nu-a-ti-on. наличие общей части с «continue» о чём-то говорит?

я тебе сейчас ещё более страшную штуку скажу: это самое continuation можно передать по сети другому исполнителю. и там продолжить (при условии, понятно, что на обоих одна и та же версия юзерского софта). load balancing? да пожалуйста. несколько серверов — да на здоровье. прозрачная миграция сессии пользователя с одного сервера на другой? да без проблем. а функции-обработчики об этом как не знали, так и не знают. им всё равно.

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

Ответить | Правка | К родителю #223 | Наверх | Cообщить модератору

231. "Релиз PHP 5.5.0"  +/
Сообщение от AlexAT (ok), 22-Июн-13, 18:54 
> и это тоже не страшно. потому что о кэшировании данных мы не
> то, что не думаем — мы вообще забываем, что такое на
> свете существует. в нашем мире существует только объект со свойствами. и
> вот этот-то объект отлично знает, что и когда надо перечитывать. а
> мы просто обращаемся к его свойствам.

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

Ответить | Правка | К родителю #227 | Наверх | Cообщить модератору

241. "Релиз PHP 5.5.0"  +1 +/
Сообщение от arisu (ok), 22-Июн-13, 19:11 
> Вот так вот плавно мы и пришли к концепту фреймворка :) Всё
> равно всё в итоге превращается в банальный набор тех или иных
> костылей, позволяющих этот функционал реализовать.

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

в моём случае — есть фрэймворк (который пишется один раз и потом используется где угодно) и поверх него язык, в котором прозрачно реализована поддержка continuations (вдобавок, они first-class citizens). это не серебряная пуля, но убирает кучу костылей. убирает настолько, что на этой фигне становится пофигу, для чего пишется софт: для веба, для терминала, для крутых гуёв…

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

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

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

Ответить | Правка | К родителю #231 | Наверх | Cообщить модератору

243. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 19:17 
>[оверквотинг удален]
> поддержка continuations (вдобавок, они first-class citizens). это не серебряная пуля,
> но убирает кучу костылей. убирает настолько, что на этой фигне становится
> пофигу, для чего пишется софт: для веба, для терминала, для крутых
> гуёв…
> софт можно «замораживать» и «размораживать», можно переносить замороженое
> тельце с машины на машину, можно на 100500 лет о софте
> вообще забыть, а потом снова его разморозить и доделать то, что
> делал. можно «заморозить» вебовый софт и «разморозить» его в гуях.
> а можно наоборот. а можно одновременно и в браузер показывать, и
> окошко гуёвое держать.

и чо?

время на разработку - это раз

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

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

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

Ответить | Правка | К родителю #241 | Наверх | Cообщить модератору

245. "Релиз PHP 5.5.0"  +/
Сообщение от arisu (ok), 22-Июн-13, 19:31 
> короче говоря — оно само уже может разрабатываться, или ждать нам другого?

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

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

Ответить | Правка | К родителю #243 | Наверх | Cообщить модератору

196. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 18:10 
> помнишь, как писал первые программки такого типа? вот и не надо усложнять,
> можно так же и продолжать писать. без заморочек о том, что «это веб».

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

А в чём заморочка "это веб", я не пойму. Кроме того, что одни юзеры могут сидеть на url-е /a, а другие - на урле /b, и никогда не пересекатся.

Роутоориентированный интерфейс (а не как в php, эмуляция через хаки) - это самое лучшее, что может быть.

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

Ответить | Правка | К родителю #192 | Наверх | Cообщить модератору

199. "Релиз PHP 5.5.0"  +/
Сообщение от AlexAT (ok), 22-Июн-13, 18:11 
> А в чём заморочка "это веб", я не пойму. Кроме того, что
> одни юзеры могут сидеть на url-е /a, а другие - на
> урле /b, и никогда не пересекатся.

В том, что один и тот же юзер одновременно может сидеть на урлах /a, /b и /c. И нет строгого порядка, в котором он с них уйдёт на /d, /e и /f. И даже гарантий, что он с /a на /d уйдёт - нет. Может тупо уйти с /a на /b кнопкой "назад". Или вбить URL. Или F5 нажать.


Ответить | Правка | К родителю #196 | Наверх | Cообщить модератору

204. "Релиз PHP 5.5.0"  +/
Сообщение от arisu (ok), 22-Июн-13, 18:17 
а не может, не положено!
Ответить | Правка | К родителю #199 | Наверх | Cообщить модератору

207. "Релиз PHP 5.5.0"  +/
Сообщение от AlexAT (ok), 22-Июн-13, 18:20 
> а не может, не положено!

Ну, увы, в реальности юзер хочет относительной свободы действий. Если скажете "не положено" - уйдёт к тем, у кого это всё допустимо. И делов.

Ответить | Правка | К родителю #204 | Наверх | Cообщить модератору

221. "Релиз PHP 5.5.0"  +/
Сообщение от arisu (ok), 22-Июн-13, 18:33 
>> а не может, не положено!
> Ну, увы, в реальности юзер хочет относительной свободы действий. Если скажете "не
> положено" - уйдёт к тем, у кого это всё допустимо. И
> делов.

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

Ответить | Правка | К родителю #207 | Наверх | Cообщить модератору

242. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 19:14 
>>> а не может, не положено!
>> Ну, увы, в реальности юзер хочет относительной свободы действий. Если скажете "не
>> положено" - уйдёт к тем, у кого это всё допустимо. И делов.
> зато у питониста тогда сервер под нагрузкой не будет проседать. в виду
> отсутствия нагрузки.

Мы ещё раз пришли к тому, от чего ушли. Веб в подавляющем большинстве случаев это "получили нужную страничку, сделали выборку, отрисовали". Он не коддориентирован, он данно-ориентирован, там может быть вообще две функции фильтрации, а весь основной проект - это организация данных. Никаких "как в доме под одеялом на паскале" там быть не может. У юзера есть закладки, твитер и 50 вкладок. Юзер хочет простоты и свободы, и ему наплевать, как оно там работает.

Ответить | Правка | К родителю #221 | Наверх | Cообщить модератору

247. "Релиз PHP 5.5.0"  +/
Сообщение от arisu (ok), 22-Июн-13, 19:35 
может, может. в том-то и фикус спрятан. it's just you who can't wrap your mind around it.

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

Ответить | Правка | К родителю #242 | Наверх | Cообщить модератору

188. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 17:50 
> ты сам всё и описал: отличный пример костыляния. с ходу, не думая:
> я делаю функцию «обработать-покупки», которая где-то там у себя вызывает функцию
> «дать-список-покупок». откуда этот список берётся — функции пофигу совершенно.
> хоть из файла, хоть из веб-сессии, хоть вообще из астрала. всё,
> что ей надо уметь — это обработать ситуацию «список ниасилили», что
> прекрасно укладывается хоть в проверку результата вызова, хоть в исключение.

Я не понимаю, что такое "список ниасилили"

У меня тоже список, который функции пофигу совершенно. Есть глобальный j = mydict(), есть функция dat_spisok_pokupok(l), но я могу её сделать и dat_spisok_pokupok(), и l передавать контекст-локалом - ничего вообще не изменится, она просто даёт dict из того, чем её кормят - нет никакой проблемы брать список из веб-сессии, я не понимаю, где загвоздка то? Я могу в mydict прописать вместо хранения - запись/чтение хоть в монго, хоть в астрал 2.0.3, никакой основной код не изменится.

Что касается (хоть в терминал) - я не знаю таких абстракций, всё, что меня волнует - это dict, который возвращает обработанный dict, и который я могу вывести хоть в json, хоть в шаблон для отрисовки, хоть в сессию, мой dict, что хочу, то и делаю.

И я думаю именно этими категориями. ПРИ ЭТОМ Я ЭТОТ DICT В ЛЮБОЙ МОМЕНТ МОГУ РУКАМИ ПОЩУПАТЬ. Я знаю, что у меня ходит, куда, и зачем. У меня предельно простая отладка - видно, что где потерялось. Функции гоняют dict, а шаблон рисует. Это очень просто и очень наглядно.

Я не вижу, что тут можно сделать лучше, сохранив понятность. Потому что из текста я мало что понял. :)


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

Что такое "логика сессий"? И что такое "обычный код"? И зачем об этом думать? auth отрабатывается один раз, при старте сессии, обрабатывает данные, сохраняет информацию об уровне доступа в тот же dict, который цепляется к контекст-локалу. Всё, когда функции нужно что-то отрисовать секретное, нужно в одном месте спросить "а какой уровень доступа у текущей сессии", и если не позволяется - не рисовать. Как работают сессии - это вообще дело десятое, я могу тупо импортировать модуль приложения, в консоли переопределять acl и дёргать те же самые функции, безо всякого веба, получая те же самые дикты.


> так, как будто юзер сидит за терминалом и честно отвечает на
> заданые вопросы. вся хитрая вебовая механика меня вообще не волнует. если
> мне захочется — я вообще вебовую механику выкину и привинчу чтение
> из файла или гуй на каком-нибудь тулките: программа от этого никак
> не поменяется. то есть, *вообще* не поменяется.

А можно простейший пример?

Ответить | Правка | К родителю #180 | Наверх | Cообщить модератору

198. "Релиз PHP 5.5.0"  +/
Сообщение от arisu (ok), 22-Июн-13, 18:10 
> Я не понимаю, что такое «список ниасилили»

перевожу: «истёк тайм-аут на сессию». или «иксы отвалились» в случае гуёв на X11, например.

> Есть глобальный

вот дальше читать уже неинтересно.

> Я не вижу, что тут можно сделать лучше, сохранив понятность. Потому что
> из текста я мало что понял. :)

потому что вообще не въехал в концепцию.

> нужно в одном месте спросить «а какой уровень доступа у текущей сессии»

нахрена? что такое вообще эта ваша «сессия»? зачем мне об этом знать? не хочу. я хочу писать обычную линейную функцию, которой на вход параметром пришло «чо показывать», она *запросила у юзера ввод*, обработала и вышла. всё. какие такие сессии-шмессии? что это? зачем оно надо?

> А можно простейший пример?

куда проще-то?


function sum_two_numbers () {
  int a, b;
  for (;;) {
    writeln("введите два числа");
    if (readln(a, b) != USER_IS_BLIND) break;
  }
  writeln("the sum is ", a+b);
}

всё. и вот это простейшее себе спокойно работает хоть для терминала, хоть для вебни с сотней окошек. без изменения кода.

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

Ответить | Правка | К родителю #188 | Наверх | Cообщить модератору

213. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 18:25 
>> Есть глобальный
> вот дальше читать уже неинтересно.

А в чём проблема? Если j это не коннектор к базе данных, а сама база данных? Кроме того, для того, чтобы это и была база данных, достаточно переписать класс mydict, не трогая ни строчки кода (все подобные вещи исполняются по требованию, а не по объявлению, им пофиг).

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

Проблем с синхронизацией тоже нет, насколько я понимаю. Неспециально влезть туда тоже нельзя. Кода требуется меньше. Суть трагедии?

Ответить | Правка | К родителю #198 | Наверх | Cообщить модератору

222. "Релиз PHP 5.5.0"  +/
Сообщение от arisu (ok), 22-Июн-13, 18:34 
> Суть трагедии?

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

Ответить | Правка | К родителю #213 | Наверх | Cообщить модератору

239. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 19:09 
> а вот это ты бы понял, если бы был программистом. каждый раз,
> когда ты используешь глобальную переменную, где-то страдает котёнок.

В чём принципиальная разница между той же глобальной переменной j, живущей в модуле ttt, и функцией f, возвращающей yield?

Вот мы сделали from ttt import j, f

что произошло в f, что спасло котёнка (именно принципиально?)


А также в чём разница между такой реализацией, и redis/memcache, которые получают ТЕ ЖЕ ДАННЫЕ, но нужно ещё делать коннекцию, разбор данных и т.п.?

Ответить | Правка | К родителю #222 | Наверх | Cообщить модератору

164. "Релиз PHP 5.5.0"  +/
Сообщение от arisu (ok), 22-Июн-13, 17:02 
p.s. я не спорю, что вышенаписаное можно *проэмулировать*. но это будет костыль.
Ответить | Правка | К родителю #158 | Наверх | Cообщить модератору

167. "Релиз PHP 5.5.0"  +/
Сообщение от AlexAT (ok), 22-Июн-13, 17:06 
> p.s. я не спорю, что вышенаписаное можно *проэмулировать*. но это будет костыль.

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

Ответить | Правка | К родителю #164 | Наверх | Cообщить модератору

168. "Релиз PHP 5.5.0"  +/
Сообщение от arisu (ok), 22-Июн-13, 17:08 
> Проблема в необходимости держать запущенным процесс на каждый сеанс.

или реализовать веб-сервер как часть фрэймворка. ну и да: тут ещё был бы полезен лёгкий и быстрый sandboxing.

Ответить | Правка | К родителю #167 | Наверх | Cообщить модератору

169. "Релиз PHP 5.5.0"  +/
Сообщение от AlexAT (ok), 22-Июн-13, 17:10 
> или реализовать веб-сервер как часть фрэймворка. ну и да: тут ещё был
> бы полезен лёгкий и быстрый sandboxing.

Вполне. С другой стороны - это гвоздями приколотит язык/фреймворк к вебу, и использовать его для чего-то другого станет тяжко (вся эта обвязка будет висеть мертвым грузом).

А вот насчет сэндбоксинга - да. Интересно, как скоро появится плагин к апачам, запускающий каждый процесс в отдельном контейнере... Подвижки в эту сторону в виде mpm_itk (в который сие можно в принципе привернуть) уже есть.

Ответить | Правка | К родителю #168 | Наверх | Cообщить модератору

184. "Релиз PHP 5.5.0"  +/
Сообщение от arisu (ok), 22-Июн-13, 17:42 
>> или реализовать веб-сервер как часть фрэймворка. ну и да: тут ещё был
>> бы полезен лёгкий и быстрый sandboxing.
> Вполне. С другой стороны — это гвоздями приколотит язык/фреймворк к вебу

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

Ответить | Правка | К родителю #169 | Наверх | Cообщить модератору

259. "Релиз PHP 5.5.0"  +/
Сообщение от Geol (??), 24-Июн-13, 01:12 
>веб - это выборка. по запросу сделать выборку, учитывая внешние и внутренние влияния. почти всегда - это всё.

вы в 90-х застряли.

Ответить | Правка | К родителю #158 | Наверх | Cообщить модератору

262. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 24-Июн-13, 06:02 
>>веб - это выборка. по запросу сделать выборку, учитывая внешние и внутренние влияния. почти всегда - это всё.
> вы в 90-х застряли.

А что ещё на php пишут? :)

ps. А куда такую высокоинтеллектуальную беседу дели? :)

Ответить | Правка | К родителю #259 | Наверх | Cообщить модератору

264. "Релиз PHP 5.5.0"  +/
Сообщение от AlexAT (ok), 24-Июн-13, 07:18 
> А что ещё на php пишут? :)

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

В целом - пишут на том, на чем писать удобно и практично в энном конкретном случае.

Ответить | Правка | К родителю #262 | Наверх | Cообщить модератору

272. "Релиз PHP 5.5.0"  +/
Сообщение от arisu (ok), 24-Июн-13, 13:14 
> Много чего пишут. У нас, например, анализатор аномалий объёма телефонного трафика на
> нём написан, прожевывающий миллионы записей в сутки.

НО ЗАЧЕМ?!

Ответить | Правка | К родителю #264 | Наверх | Cообщить модератору

279. "Релиз PHP 5.5.0"  +/
Сообщение от AlexAT (ok), 24-Июн-13, 14:40 
> НО ЗАЧЕМ?!

Что значит ЗАЧЕМ? С помощью конкретного инструмента конкретную задачу поиска аномалий удалось решить очень просто и быстро. Прикинули время и сложность разработки на плюсах и PHP, и выбрали второе. Можно было как альтернативу взять жабу, но она в нашем случае эксплуатируется только под виндой.

В основном анализатор представляет из себя обработку текстовых и статистических данных + работу с БД, в PHP всё необходимое есть из коробки, и работает достаточно шустро. Конкретно для нашей задачи очень удобны нестрогая типизация и хеш-массивы.

Ответить | Правка | К родителю #272 | Наверх | Cообщить модератору

282. "Релиз PHP 5.5.0"  +/
Сообщение от arisu (ok), 24-Июн-13, 14:49 
собственно, у меня есть ничем не подкреплённое подозрение, что перл тут подошёл бы лучше.
Ответить | Правка | К родителю #279 | Наверх | Cообщить модератору

284. "Релиз PHP 5.5.0"  +/
Сообщение от AlexAT (ok), 24-Июн-13, 14:54 
> собственно, у меня есть ничем не подкреплённое подозрение, что перл тут подошёл
> бы лучше.

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

Ответить | Правка | К родителю #282 | Наверх | Cообщить модератору

285. "Релиз PHP 5.5.0"  +/
Сообщение от arisu (ok), 24-Июн-13, 15:03 
читабельность перла, собственно, зависит от рук и мозга пишущего. и в перле сигилы таки имеют смысл, а от обилия долларовых знаков в похапэ лично у меня нервный тик.
Ответить | Правка | К родителю #284 | Наверх | Cообщить модератору

286. "Релиз PHP 5.5.0"  +/
Сообщение от arisu (ok), 24-Июн-13, 15:03 
кстати, никогда не мог запомнить:
$obj->field
или
$obj->$field
логическому выводу это не поддаётся, можно только зазубрить.
Ответить | Правка | К родителю #284 | Наверх | Cообщить модератору

287. "Релиз PHP 5.5.0"  +/
Сообщение от AlexAT (ok), 24-Июн-13, 15:17 
> кстати, никогда не мог запомнить:
> $obj->field
> или
> $obj->$field
> логическому выводу это не поддаётся, можно только зазубрить.

Поддается.
$obj->field - это property field объекта obj. Как и во всех языках, не надо ничего придумывать.

$obj->$field - это property объекта obj, определяемая переменной $field.
Если в $field положить 'xxx' - то будет эквивалентно $obj->xxx, если 'yyy' - то $obj->yyy. Тоже очень удобно, хотя и не очень производительно.
Можно например так же метод вызвать с не известным заранее именем, которое лежит в переменной.

Ответить | Правка | К родителю #286 | Наверх | Cообщить модератору

288. "Релиз PHP 5.5.0"  +/
Сообщение от arisu (ok), 24-Июн-13, 15:30 
не поддаётся. ибо конструкция '$var = value' тогда должна присваивать значение не переменной var, а переменной, имя которой хранится в var. вот эта фигня «на раз» сбивает логическую рассуждалку, и дальше на неё полагаться уже опасно.

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

в перле тоже не очень поняли, что обозначает оператор «$», но там хотя бы «$$» работает — то есть, хотя бы во взятии значения оператор «$» эмулируют логично.

Ответить | Правка | К родителю #287 | Наверх | Cообщить модератору

289. "Релиз PHP 5.5.0"  +/
Сообщение от AlexAT (ok), 24-Июн-13, 16:22 
> не поддаётся. ибо конструкция '$var = value' тогда должна присваивать значение не
> переменной var, а переменной, имя которой хранится в var

Нет. Такое присваивание, кстати, есть, и выглядит как $$var = value. Достаточно запомнить, что имена _переменных_ (не методов, не пропертей - именно переменных) всегда начинаются с $


Ответить | Правка | К родителю #288 | Наверх | Cообщить модератору

290. "Релиз PHP 5.5.0"  +/
Сообщение от arisu (ok), 24-Июн-13, 16:29 
> Достаточно запомнить, что имена _переменных_ (не методов, не пропертей — именно переменных)
> всегда начинаются с $

а зачем? вот в sh с этим всё понятно: «$» там — оператор. а тут — авторы как-то не смогли понять, что это оператор, и сделали глупость.

p.s. я совершенно не понимаю, по какой марсианской логике имя поля должно отличаться от имени переменной наличием доллара.

Ответить | Правка | К родителю #289 | Наверх | Cообщить модератору

146. "Релиз PHP 5.5.0"  +/
Сообщение от AlexAT (ok), 22-Июн-13, 16:27 
> Можно сказать, что mediawiki мне полжизни искалечила и лишила крупной
> суммы денег только из-за того, что я в неё поверил. Но
> можно и не говорить.

Ох, ёшкин код (sic!), а вот и источник детских комплексов вылез. Только, боюсь, это не MediaWiki, а руки...

Ответить | Правка | К родителю #142 | Наверх | Cообщить модератору

149. "Релиз PHP 5.5.0"  –1 +/
Сообщение от бедный буратино (ok), 22-Июн-13, 16:34 
> Ох, ёшкин код (sic!), а вот и источник детских комплексов вылез. Только, боюсь, это не MediaWiki, а руки...

Нихрена ты, Вася, не понял.

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

Ответить | Правка | К родителю #146 | Наверх | Cообщить модератору

151. "Релиз PHP 5.5.0"  +/
Сообщение от AlexAT (ok), 22-Июн-13, 16:36 
> Нихрена ты, Вася, не понял.
> Запомни, навсегда запомни. Чувство юмора - это умение смеяться над собой. Комплексы
> - это ваше поведение недотрог.

Слив засчитан.

Ответить | Правка | К родителю #149 | Наверх | Cообщить модератору

141. "Релиз PHP 5.5.0"  +/
Сообщение от AlexAT (ok), 22-Июн-13, 16:18 
> Спросил, кто какие фишки из 5.3/5.4 использует, а в ответ - []; вместо array().

Мне например от 5.3 нужны closures, от 5.4 - traits.

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

Опять же - goto в 5.3 - изменение спорное, но местами действительно удобное.

Ответить | Правка | К родителю #135 | Наверх | Cообщить модератору

152. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 16:38 
> Кроме того - в языке настолько до фига всего

В языке настолько дофига всего нет, что его пытаются превратить в python со скобочками. Это моё, и не только моё, впечатление от ченчлога 5.3, 5.4 и особенно 5.5.


> Опять же - goto в 5.3 - изменение спорное, но местами действительно удобное.

Через две версии опять объявят deprecated, потому что несколько дебилов порежутся.

Когда в python нет for, нет switch - пыхеры орут матом, а понимающие философию радуются такому единообразию и отсутствию РАЗНЫХ инструментов для ОДНОГО дела (меня в php умиляют функции array_, типа для массивов одна функция, для чего-нибудь ещё - другая, ЗАПОМНИ ИХ ВСЕ, будь пыхером). А goto, пыхерам... жалко дворняжек.


Ответить | Правка | К родителю #141 | Наверх | Cообщить модератору

154. "Релиз PHP 5.5.0"  +/
Сообщение от AlexAT (ok), 22-Июн-13, 16:43 
Ну... эээ... ты знаешь - радоваться отсутствию разных инструментов может только дебил. Потому что задача бывает одна (закрутить винт/болт), а калибр - разный (в корпус ПК или в стойку). Или закрутить полсотни болтов - тут уже лучше электроинструмент, чем обычная отвертка. Хотя задача всё та же - закручивание винтов/болтов. А где-то электроинструментом, да и отверткой, тупо не подлезть - и нужна гнущаяся отвертка.

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

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

Ответить | Правка | К родителю #152 | Наверх | Cообщить модератору

105. "Релиз PHP 5.5.0"  +/
Сообщение от arisu (ok), 22-Июн-13, 15:17 
p.s. и, кстати, вот это вот «**» — нифига не очевидная конструкция. фиг знает вообще, что она делает, и догадаться — никак. на что я и намекал весьма прозрачно. а если у человека есть опыт сей — он вообще от этой конструкции офигеет.
Ответить | Правка | К родителю #79 | Наверх | Cообщить модератору

110. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 15:26 
> p.s. и, кстати, вот это вот «**» — нифига не очевидная конструкция.
> фиг знает вообще, что она делает, и догадаться — никак.

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

А перед использованием python мануал, хотя бы по диагонали, просмотреть следует.

> а если у человека есть опыт сей — он вообще от этой конструкции офигеет.

Я в детстве, когда нужно использовать *, когда **, когда & или что там, я уже забыл, собирал только перебором (в смысле - подставил один символ, скомпилировал-запустил-не-подошло-подставил другой). И только когда комбинаторика иссякала, просто сдавался. И даже не понимаю, как такие штуки можно в голове держать. Поэтому python для непрограммистов и им сочувствующих, а C для программистов и интересующихся тонкими материями, и пусть так дальше и остаётся. python д о с т а т о ч н о эффективен для своей ниши, а борцы за чистоту тактов и закат производительности вручную пусть борятся где-нибудь в другом месте - мы к ним не лезем, ядра на python не пишем.

Ответить | Правка | Наверх | Cообщить модератору

120. "Релиз PHP 5.5.0"  +/
Сообщение от arisu (ok), 22-Июн-13, 15:36 
> Чувак, я ни разу не читал про эту конструкцию ни в одном
> мануале. Я просто видел её использование, без объяснения, в том же
> мануале, и просто догадался, как оно работает. Оно работало именно так,
> как я и ожидал.

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

> А перед использованием python мануал, хотя бы по диагонали, просмотреть следует.

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

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

есть мнение, что это вовсе не от сложности и непонятности синтаксиса.

> Поэтому python для непрограммистов и им сочувствующих,
> а C для программистов и интересующихся тонкими материями

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

Ответить | Правка | Наверх | Cообщить модератору

121. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 15:44 
>> Чувак, я ни разу не читал про эту конструкцию ни в одном
>> мануале. Я просто видел её использование, без объяснения, в том же
>> мануале, и просто догадался, как оно работает. Оно работало именно так,
>> как я и ожидал.
> а я ожидаю двойное разыменование указателя. а почему эта фигня заместо работы
> с указателями делает unpack, да ещё почему там нужны две звезды
> — для меня загадка.

Потому что одна звезда для другого:

def keyz(raz,dva,tri):
    print raz
    print dva
    print tri

a = ['one','two','three']

keyz (a)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: keyz() takes exactly 3 arguments (1 given)

keyz (*a)
one
two
three


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

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


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

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


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

две звезды - это двойное умножение :). одна звезда - это одинарное умножение. так же логично, как и

'a' * 20
'aaaaaaaaaaaaaaaaaaaa'

вот когда знак умножения означает не умножение - вот это становится загадочным :)


Ответить | Правка | Наверх | Cообщить модератору

123. "Релиз PHP 5.5.0"  +/
Сообщение от AlexAT (ok), 22-Июн-13, 15:48 
> 'a' * 20
> 'aaaaaaaaaaaaaaaaaaaa'

Именно. Ааааааааааааааааааааааааааааааааа!!! Уж лучше пыховый str_repeat - по крайней мере, найдя его, не придётся гадать, что получится при умножении строки на число.

Ответить | Правка | Наверх | Cообщить модератору

126. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 15:53 
>> 'a' * 20
>> 'aaaaaaaaaaaaaaaaaaaa'
> Именно. Ааааааааааааааааааааааааааааааааа!!! Уж лучше пыховый str_repeat - по крайней
> мере, найдя его, не придётся гадать, что получится при умножении строки на число.

Это не умножение строки на число. Это помножение строки числом. :)

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

['a'] * 20
['a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a']

ну в перле вроде x используется, есть принципиальная разница?


Ответить | Правка | Наверх | Cообщить модератору

128. "Релиз PHP 5.5.0"  +/
Сообщение от AlexAT (ok), 22-Июн-13, 15:54 
> Это не умножение строки на число. Это помножение строки числом. :)

Ну так * - оператор умножения или "помножения"? :)

> Это самое логчное, что ожидаешь увидеть, исходя из детсадовского курса

Obvious fix. А когда вырастаешь из детсада - то узнаёшь про строгие и нестрогие типизации, приведение типов, и много чего еще.

> Если чего-то взять пять раз, то получится пять чеготов.

А объект на число в ГБ умножить можно? Что получится на выходе? А если массив умножить - будет 5 массивов, или весь массив, умноженный на 5? А если в массиве еще массивы? А если число на объект? Или число на строку? Oops.

> ну в перле вроде x используется, есть принципиальная разница?

Да нет. Но и будущее при этом тоже должно быть более-менее сходным.


Ответить | Правка | К родителю #126 | Наверх | Cообщить модератору

137. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 16:10 
>> Это не умножение строки на число. Это помножение строки числом. :)
> Ну так * - оператор умножения или "помножения"? :)
>> Если чего-то взять пять раз, то получится пять чеготов.
> А объект на число в ГБ умножить можно? Что получится на выходе?
> А если массив умножить - будет 5 массивов, или весь массив,
> умноженный на 5? А если в массиве еще массивы? А если
> число на объект? Или число на строку? Oops.

f = lambda a: a
f(5)
5
f * 5
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for *: 'function' and 'int'

d = {'a': 5, 'b': [0,4,{'a':99}]}
d * 5
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for *: 'dict' and 'int'

l = list(d.items())
l
[('a', 5), ('b', [0, 4, {'a': 99}])]

l * 5
[('a', 5), ('b', [0, 4, {'a': 99}]), ('a', 5), ('b', [0, 4, {'a': 99}]), ('a', 5), ('b', [0, 4, {'a': 99}]), ('a', 5), ('b', [0, 4, {'a': 99}]), ('a', 5), ('b', [0, 4, {'a': 99}])]


>> Это самое логчное, что ожидаешь увидеть, исходя из детсадовского курса
> Obvious fix. А когда вырастаешь из детсада - то узнаёшь про строгие
> и нестрогие типизации, приведение типов, и много чего еще.

    Красивое лучше, чем уродливое.

    Явное лучше, чем неявное.

    Простое лучше, чем сложное.

    Сложное лучше, чем запутанное.

    Плоское лучше, чем вложенное.

    Разреженное лучше, чем плотное.

    Читаемость имеет значение.

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

    При этом практичность важнее безупречности.

    Ошибки никогда не должны замалчиваться.

    Если не замалчиваются явно.

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

    Должен существовать один — и, желательно, только один — очевидный способ сделать это.

    Хотя он поначалу может быть и не очевиден, если вы не голландец.

    Сейчас лучше, чем никогда.

    Хотя никогда зачастую лучше, чем прямо сейчас.

    Если реализацию сложно объяснить — идея плоха.

    Если реализацию легко объяснить — идея, возможно, хороша.

    Пространства имён — отличная штука! Будем делать их побольше!

Ответить | Правка | К родителю #128 | Наверх | Cообщить модератору

138. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 16:12 
и летний хит:

[f]
[<function <lambda> at 0x7f9a1d6bd578>]

[f] * 5
[<function <lambda> at 0x7f9a1d6bd578>, <function <lambda> at 0x7f9a1d6bd578>, <function <lambda> at 0x7f9a1d6bd578>, <function <lambda> at 0x7f9a1d6bd578>, <function <lambda> at 0x7f9a1d6bd578>]

Ответить | Правка | К родителю #137 | Наверх | Cообщить модератору

143. "Релиз PHP 5.5.0"  +/
Сообщение от AlexAT (ok), 22-Июн-13, 16:21 
Хорошее лучше, чем плохое.
Светлое светлее, чем яркое.
Красное краснее, чем зеленое...
Ответить | Правка | К родителю #137 | Наверх | Cообщить модератору

147. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 16:30 
> Хорошее лучше, чем плохое.
> Светлое светлее, чем яркое.
> Красное краснее, чем зеленое...

Вообще-то, всё в python отвечает этой философии. И именно поэтому python настолько удобен и предсказуем. А тем, кто этого не понимает, этого и не понять.

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

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

Ответить | Правка | К родителю #143 | Наверх | Cообщить модератору

130. "Релиз PHP 5.5.0"  +1 +/
Сообщение от arisu (ok), 22-Июн-13, 15:58 
> Это самое логчное, что ожидаешь увидеть, исходя из детсадовского курса арифметики.

а ещё из того же курса мы помним, что умножение — коммутативно. что должно получиться в результате (20 * 'a')? лично я никакого логичного пояснения придумать не могу. а если эта операция запрещена, то мы опять потеряли «логичность и привычность», и снова надо учить какие-то частные случаи.

Ответить | Правка | К родителю #126 | Наверх | Cообщить модератору

136. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 16:03 
>> Это самое логчное, что ожидаешь увидеть, исходя из детсадовского курса арифметики.
> а ещё из того же курса мы помним, что умножение — коммутативно.
> что должно получиться в результате (20 * 'a')?

20 * 'a'
'aaaaaaaaaaaaaaaaaaaa'

Ответить | Правка | К родителю #130 | Наверх | Cообщить модератору

140. "Релиз PHP 5.5.0"  +/
Сообщение от arisu (ok), 22-Июн-13, 16:17 
>> что должно получиться в результате (20 * 'a')?
> 20 * 'a'
> 'aaaaaaaaaaaaaaaaaaaa'

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

Ответить | Правка | К родителю #136 | Наверх | Cообщить модератору

145. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 16:26 
>>> что должно получиться в результате (20 * 'a')?
>> 20 * 'a'
>> 'aaaaaaaaaaaaaaaaaaaa'
> эту логику я постигнуть не способен. судя по твоему описанию, должно было
> получиться «'а' раз по 20», что бы это ни значило (я
> не знаю, что это должно значить).

'a' раз по 20 не может быть в принципе. а почему это работает, вы сами объяснили заметкой выше :)

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

чтобы это выяснить, достаточно набрать python и проверить (у php консоль уже появилась, чтобы простые вещи проверить? я - не нашёл. неудобно в сравнении всё время файлы с закорючками писать)

Ответить | Правка | К родителю #140 | Наверх | Cообщить модератору

155. "Релиз PHP 5.5.0"  +/
Сообщение от arisu (ok), 22-Июн-13, 16:45 
> 'a' раз по 20 не может быть в принципе.

вот именно. а должно. почему именно 20 раз по 'a', а не 'a' раз по 20? где логика? это напрочь уносит коммутативность умножения. и именно поэтому какой-нибудь repeat() или duplicate() был бы намного логичней.

> чтобы это выяснить, достаточно набрать python и проверить

вот именно: догадаться нельзя, можно только опытным путём выяснить. логика и рядом не лежала.

Ответить | Правка | К родителю #145 | Наверх | Cообщить модератору

165. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 17:03 
> вот именно: догадаться нельзя, можно только опытным путём выяснить. логика и рядом не лежала.

Когда постоянно будешь натыкаться на **kw, обязательно захочешь попробовать. :)


А вообще, слуш, мож ты просто не голландец?

Ответить | Правка | К родителю #155 | Наверх | Cообщить модератору

170. "Релиз PHP 5.5.0"  +/
Сообщение от arisu (ok), 22-Июн-13, 17:10 
> А вообще, слуш, мож ты просто не голландец?

Гурвіник (зніма з стіни гіпсового пірата). Жид? Шо мовчиш? Хрясь!
Пірат-жид пада на підлогу і розбивається. Карандаш стовпіє.
Гурвіник (до Карандаша). Шо, жалко жида? Може ти тоже жид?
Карандаш (злякавшись). Нє, я — украінєц.
Самодєлкін (танцює чочотку). Такий, як я китаєць.

Ответить | Правка | К родителю #165 | Наверх | Cообщить модератору

129. "Релиз PHP 5.5.0"  +/
Сообщение от arisu (ok), 22-Июн-13, 15:55 
> вот когда знак умножения означает не умножение — вот это становится загадочным
> :)

вот мы и вернулись к тому, с чего начинали.

Ответить | Правка | К родителю #121 | Наверх | Cообщить модератору

16. "Релиз PHP 5.5.0"  +/
Сообщение от Ivan1986email (?), 21-Июн-13, 10:22 
Да ладно, аналитики с ЛОРа они такие :)
Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

17. "Релиз PHP 5.5.0"  –1 +/
Сообщение от бедный буратино (ok), 21-Июн-13, 10:46 
> Тоже самое говорили такие же «аналитики» про 5.0 версию — «php скатился
> в java», «зачем это нужно». Агония затянулась, не находите?

Да никто и не говорит, что php умрёт в одночасье - кто ж тогда ораву голодных пыхеров кормить будет, которые так ничего делать и не научились? Речь именно о тенденции, о движении, когда проект думает не о своей основной аудитории (быдлокодеры, пишушие небезопасный лапшеобразный код), а начинает вводить то, что этой аудитории непонятно. В результате и получится гибрид, который будет только терять "своих" пользователей.

Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

42. "Релиз PHP 5.5.0"  +1 +/
Сообщение от Аноним (-), 21-Июн-13, 16:05 
чтобы умер php, надо убить много cms да фреймворков.
интернет, ессно, в одночасье не умрёт - не применило ещё сшп сиё оружие в полной мере. готовится только.
ну а как бабахнет - тут уж не волнуйтесь. неандертальцы им много выгоднее человеков, так что искоренят, будьте на этот счёт спокойны.
Ответить | Правка | Наверх | Cообщить модератору

44. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 21-Июн-13, 16:18 
> чтобы умер php, надо убить много cms да фреймворков.
> интернет, ессно, в одночасье не умрёт - не применило ещё сшп сиё
> оружие в полной мере. готовится только.
> ну а как бабахнет - тут уж не волнуйтесь. неандертальцы им много
> выгоднее человеков, так что искоренят, будьте на этот счёт спокойны.

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

Ну хочешь ты писать "как на python или на ruby" - ну и пиши ты на python или на ruby, зачем цепляться за php? я вот этого дебилизма никогда понять не смогу. "хочу python/ruby, но на php"? почему, млять, на php-то? когда python/ruby гораздо удобнее, гораздо понятнее, гораздо логичнее, и их проще читать и проще поддерживать? Зачем за php держаться-то? Не вижу ни одной причины. php - это для убогого небезопасного лапшекода, нормальный стиль а-ля python/ruby (я уж не говорю про спецсредства) там просто чужд.

Ответить | Правка | Наверх | Cообщить модератору

48. "Релиз PHP 5.5.0"  +1 +/
Сообщение от AlexAT (ok), 21-Июн-13, 18:17 
>> "хочу python/ruby, но на php"?

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

Ответить | Правка | Наверх | Cообщить модератору

53. "Релиз PHP 5.5.0"  +1 +/
Сообщение от Аноним (-), 21-Июн-13, 21:03 
> Пытаются эмулировать вещи, которых в php нет, но при этом при малейшем погружении вглубь оказывается, что их там и не появилось.

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

Сколько лет с тех пор прошло, сколько ядер в процессорах домашних компов перерабатывают ютуб в тепло да пакуют сейвы скайрима, а ни одного эксцеля и ни единого фотошопа внутри архитектур не появилось.
Истинно, это -- закат нашей цивилизации. Помяните моё слово.

Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

61. "Релиз PHP 5.5.0"  +2 +/
Сообщение от Аноним (-), 21-Июн-13, 22:47 
Потому что PHP как платформа для web разработки - лучше. А у ruby с python не получилось, не фортануло :)
Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

62. "Релиз PHP 5.5.0"  –1 +/
Сообщение от бедный буратино (ok), 22-Июн-13, 04:26 
> Потому что PHP как платформа для web разработки - лучше.

Лучше. Для разгильдяев. Потому что поощряет разгильдяйство. Для нормальных людей - не лучше.

Лучше. Для виндузятников. Потому что если один виндузятник спросит другого виндузятника, что есть для веба, тот ему посоветует Пых_с_Апачем.exe. Не потому, что действительно сравнивал средства, а потому что других он просто не знает. А если вдруг запустит python и окажется, что сначала нужно было мануал прочитать - естественно, убежит в пых, где интерпретатор плачет, даваится, но ест его код.

> А у ruby с python не получилось, не фортануло :)

У кого не получилось? У меня всё, что пишется, пишется на python. И после 9 лет с php я вижу, насколько это удобнее и понятнее. Это у пыхеров не получилось, у них на одного разработчика по три уязвимости приходится, и никто не чешется исправлять.

Многие умные люди давно перешли на ruby/python. Чтобы умные люди переходили обратно, я не слышал. Наоборот, только и говорят о том, как всё стало удобно. В истории новых взлётах, во всех этих твитерах, шмитерах, гитхабах, стограммах и прочих новых ярких взлетающих проектах - или ruby, или python, или node, или даже эрланг там встретить реальнее, чем php. У php только одна ниша - низкокачественное безалаберное программирование, когда нанимаются самые дешёвые низкоквалифицированные, и "работу работают", причем часто аналог их двухмесячной работы я мог повторить на bottle, с большим качеством и понятностью для групповой разработки, часа за два. Потому что решение задачи в лоб при хоть сколько-нибудь серьёзной задаче, заставляет "закапываться в код" и плодить монстра, когда никому не понятно, как он работает.

На современном python и ruby так не пишут. И именно об этом речь. Что средний код на python/ruby гораздо качественнее, гораздо понятнее, и гораздо проще в поддержке. И виноваты тут и язык php, и культура, которую он создал. "Быдловелоперс! Быдловелоперс! Быдловелоперс! Если не знаешь вообще ничего, то пиши на php."

Ответить | Правка | Наверх | Cообщить модератору

100. "Релиз PHP 5.5.0"  +/
Сообщение от kurokaze (ok), 22-Июн-13, 15:09 
> А вообще, судя по ченчлогу, php плавно скатывается в python (разработчики явно
> с туториала python-а не вылазили), только с С-синтаксисом и набором legacy-ужаса.

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

dev-lang/python
     Available versions:  
        (2.5)   2.5.4-r4 2.5.4-r5
        (2.6)   2.6.8 2.6.8-r1
        (2.7)   2.7.3-r2 2.7.3-r3 ~2.7.4 ~2.7.5
        (3.1)   3.1.5 3.1.5-r1
        (3.2)   3.2.3 ~3.2.3-r1 3.2.3-r2 ~3.2.4 ~3.2.5
        (3.3)   **3.3.1 ~3.3.2


Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

106. "Релиз PHP 5.5.0"  +/
Сообщение от бедный буратино (ok), 22-Июн-13, 15:18 
>> А вообще, судя по ченчлогу, php плавно скатывается в python (разработчики явно
>> с туториала python-а не вылазили), только с С-синтаксисом и набором legacy-ужаса.
> Не, когда php опуститься на дно окончательно, снизу постучит гвидобейсик. Это же
> надо было такого идиотизма наплодить что в системе приходиться держать 2.7
> и 3.2 к примеру

Это трагедия. Потеря целых 20 мб свободного пространства!

Какой-нибудь пых захочешь, а не сможешь держать несколько конкурентных веток (при использовании mod_php - уж точно). А в python хоть 5 штук изолированных используй, без проблем.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру