Комментарии 96
Я все понимаю, но это серьезно? Мучать язык, который для этого не предназначен?
Этак можно подумать, что функции socket_ тоже не нужны.
Допустим есть компания, занимающаяся разработкой веб-проектов. Приходит заказчик и говорит, что вот мол помимо веб-нитерфейса нужно сделать также оконный клиент. Все программисты в компании знают только PHP. Да и в принципе — с точки зрения управления сложностью нет желания писать часть проекта на ещё одном языке.
Допустим есть компания, занимающаяся разработкой веб-проектов. Приходит заказчик и говорит, что вот мол помимо веб-нитерфейса нужно сделать также оконный клиент. Все программисты в компании знают только PHP. Да и в принципе — с точки зрения управления сложностью нет желания писать часть проекта на ещё одном языке.
Есть инструментарий в виде библиотеки и гибкий язык, который элементарно используется не только в web-среде. Так почему бы и не использовать на десктопе? И не надо только заводить древний холивар «РНР — шаблонизатор, а не язык».
РНР — шаблонизатор, а не язык
Я такой бред в первые слышу, но скажу, что нужно глаза не огурцами закрывать, а реально смотреть на жизнь. Я простите, разрабатываю на php, но и в голову не придет его использовать в GUI. Почему? Потому, что он не предназначен для этого, мало того, что среда разработки для этого не предусмотрена нормальная, так и возможностей будет поменьше, чем у своих старших братьев.
Если постоянно так говорить, и не будет. Не надо ограничивать себя рамками. Полноценная кроссплатформенность(в том смысле, что среда всегда одна(в отличии от .NET/Mono) и никаких дополнительных действий при переноси делать не нужно (например, компиляция в случае С)) и прекрасный синтаксис (да, мне он действительно таким кажется) дают языку широкую дорогу в жизнь. Со временем появится, например, плагин для NetBeans упрощающий работу с GTK. Тогда уже будет просто смешно говорить что «РНР для этого не предназначен».
Эээ, чтобы не поняли двусмысленно насчет .NET/Mono я имел в виду исключительно то, что среды разные, т.к. они от разных производителей, и ни для кого не секрет, что до конца они не совместимы, следовательно могут(и будут) проблемы совместимости. В случае РНР интерпретатор на всех платформах один и, естественно, сам с собой он полностью совместим.
Я бы посмотрел уже бы в сторону Ruby или Python, хотя конечно же если мне предстоит что-то разрабатывать в Win среде, то я бы делал это на .NET, даже если .NET отпадает, сейчас есть прекрасное RIA, тот же Flex. Но все же мне не совсем нравится работать на php, как не крути, а это голый язык, во всех остальных технология уже много включено.
Кстати, почему все упускают из вида РНР-фреймворки? Они предоставляют богатую функциональность приближающуюся (или уже приблизившуюся) к RoR. C# без фреймворка это тоже «голый язык». Исключительно фреймворк дает ему достойную функциональность. Так же и РНР с фреймворком (CI, Kohana или CakePHP — не важно) это очень мощный инструмент. В случае десктоп программирования, уверен, если будет расти интерес к теме то будут и фреймворки направленные на десктоп, аналогичные .NET.
«РНР — шаблонизатор, а не язык» — это любимый пред РНР ненавистников и АСПшников (видимо таят обиду).
> Я простите, разрабатываю на php, но и в голову не придет его использовать в GUI
А если жизнь заставит? Будете изучать java или C++? Замечательно, времени уйдет явно больше, соответственно стоимость разработки будет выше. А это немаловажный параметр для потенциального заказчика которому по барабану на чем что написано, используется ли ООП и если да, то какие паттерны при этом задействованы. Ему главное чтобы все работало. Да, возможно GTK на сегодняшний день недостаточно хорош, но это временно. PHP на сегодняшний день — четвертый по популярности язык программирования. Было бы глупо если бы он позиционировал себя только как гипертекстовый препроцессор.
А если жизнь заставит? Будете изучать java или C++? Замечательно, времени уйдет явно больше, соответственно стоимость разработки будет выше. А это немаловажный параметр для потенциального заказчика которому по барабану на чем что написано, используется ли ООП и если да, то какие паттерны при этом задействованы. Ему главное чтобы все работало. Да, возможно GTK на сегодняшний день недостаточно хорош, но это временно. PHP на сегодняшний день — четвертый по популярности язык программирования. Было бы глупо если бы он позиционировал себя только как гипертекстовый препроцессор.
>Было бы глупо если бы он позиционировал себя только как гипертекстовый препроцессор.
Топор есть в каждом доме, было бы глупо. если бы топор позиционировал себя только как для рубки сучков, а не конкурировал с бензопилой ;)
>Будете изучать java или C++?
я прошел и через С++, MFC, C# и только после этого php.
Топор есть в каждом доме, было бы глупо. если бы топор позиционировал себя только как для рубки сучков, а не конкурировал с бензопилой ;)
>Будете изучать java или C++?
я прошел и через С++, MFC, C# и только после этого php.
Я думаю здесь многие изучали что-нибудь кроме PHP. Но когда приходится профессионально работать именно с PHP, то все остальное так или иначе забывается. Ну и ещё раз повторю про то что писал выше — вполне вероятно что по прямому приказу свыше тот или иной проект должен быть написан исключительно на PHP. Это как раз пример того случая когда жизнь заставит изучать GTK :).
И небольшой +, да если жизнь заставит буду изучать, нужно хотя бы пытаться быть в мейнстриме, а не в конце состава.
изучать нада заранее
хотя бы потому, что Garbage Collector в пхп, если мне не изменяет склероз оставляет очень сильно желать лучшего, а потому целесообразность написания долгоживущих приложения типа десктопных весьма сомнительна
Вы не знакомы с РНР 5.3? А точнее с его изменениями? Ознакомьтесь: www.linux.org.ru/view-message.jsp?msgid=3828133 только вернее сказать, он не появился, а был улучшен.
goto добавлен, да хорошее улучшение *сарказм*
Недо-лямбда функции — не впечатлило
Новый разделитель "\" для пакетов — ужасно. уже есть "->", "::" теперь вот еще "\" добавился… Замечательно. В нормальных языках (читай: python, java) это простая и понятная "."
Ах да, забыл, пхп точка занята под конкатенацию строк… Ну что же, лишний аргумент в пользу того, что это препроцессор текста, а не ЯП.
Недо-лямбда функции — не впечатлило
Новый разделитель "\" для пакетов — ужасно. уже есть "->", "::" теперь вот еще "\" добавился… Замечательно. В нормальных языках (читай: python, java) это простая и понятная "."
Ах да, забыл, пхп точка занята под конкатенацию строк… Ну что же, лишний аргумент в пользу того, что это препроцессор текста, а не ЯП.
Не нравится — не пользуйтесь. Не надо наводить евангелизм пайтона и явы. И то и другое ничто не мешаетс знать вместе с РНР. А по улучшениям, помимо гоуту (я, пока что, недоумеваю зачем он), все пункты — это шаги вперед. И не надо принижать этого. Еще раз спрошу, ЧЕМ лично вас он обидел?
Ну и не пользуюсь… Просто интересуюсь, чтоб быть «в теме», так сказать.
>Не надо наводить евангелизм пайтона и явы.
Почему? Языки-то хорошие )
>Еще раз спрошу, ЧЕМ лично вас он обидел?
Искренне не понимаю сути вопроса. Как неодушевленная сущность способна обидеть? Обижать могут только люди.
>Не надо наводить евангелизм пайтона и явы.
Почему? Языки-то хорошие )
>Еще раз спрошу, ЧЕМ лично вас он обидел?
Искренне не понимаю сути вопроса. Как неодушевленная сущность способна обидеть? Обижать могут только люди.
> Почему? Языки-то хорошие )
Я ни разу не говорил, что это не так. Я скорее согласен, что они хороши. Но и РНР хороший. Каждому свое.
> Обижать могут только люди.
Ладно, по другому, ЧЕМ вас обидели любители РНР, что так сильно хаяте хороший язык?
Я ни разу не говорил, что это не так. Я скорее согласен, что они хороши. Но и РНР хороший. Каждому свое.
> Обижать могут только люди.
Ладно, по другому, ЧЕМ вас обидели любители РНР, что так сильно хаяте хороший язык?
>Каждому свое.
Это верно. Я же не навязываю кому-то что-то. Я лишь говорю о том, что по моему скромному мнению удобнее использовать в качестве языка общего назначения. Не станете же вы спорить, что вне веба пхп удобнее, скажем, питона? Или станете? Если станете то могу посоветовать читнуть следующую ссылку startupjournal.ru/articles-graham-lisp.php в особенности повествование про парадокс вымышленного языка программирования Блаб. Имхо, ситуация вполне применима )
>ЧЕМ вас обидели любители РНР, что так сильно хаяте хороший язык
да в общем-то ничем ) В большинстве своем они хорошие ребята, просто вынуждены по долгу службы заниматься не слишком благодарным делом, только и всего =)
Однако если ПХП это еще и для души — тогда могу только посочувствовать )
Это верно. Я же не навязываю кому-то что-то. Я лишь говорю о том, что по моему скромному мнению удобнее использовать в качестве языка общего назначения. Не станете же вы спорить, что вне веба пхп удобнее, скажем, питона? Или станете? Если станете то могу посоветовать читнуть следующую ссылку startupjournal.ru/articles-graham-lisp.php в особенности повествование про парадокс вымышленного языка программирования Блаб. Имхо, ситуация вполне применима )
>ЧЕМ вас обидели любители РНР, что так сильно хаяте хороший язык
да в общем-то ничем ) В большинстве своем они хорошие ребята, просто вынуждены по долгу службы заниматься не слишком благодарным делом, только и всего =)
Однако если ПХП это еще и для души — тогда могу только посочувствовать )
1. Я же не навязываю кому-то что-то. — вот, как раз наоборот.
2. Не станете же вы спорить, что вне веба пхп удобнее, скажем, питона? — нет, не стану. РНР удобнее питона.
3. Почитаю на досуге. Честно.
4. Язык на котором работаешь, это чаще всего язык, который начал изучать сам по себе, не потому что по работе надо было. Иначе, значит не там работаешь.
5. тогда могу только посочувствовать — Ну сочувствуйте, я на РНР помимо работы и для души пишу. И мне очень это нравится. Я так релаксирую. Я получаю удовольствие. Воссоединяюсь с высшими силами, если угодно :)
2. Не станете же вы спорить, что вне веба пхп удобнее, скажем, питона? — нет, не стану. РНР удобнее питона.
3. Почитаю на досуге. Честно.
4. Язык на котором работаешь, это чаще всего язык, который начал изучать сам по себе, не потому что по работе надо было. Иначе, значит не там работаешь.
5. тогда могу только посочувствовать — Ну сочувствуйте, я на РНР помимо работы и для души пишу. И мне очень это нравится. Я так релаксирую. Я получаю удовольствие. Воссоединяюсь с высшими силами, если угодно :)
>РНР удобнее питона.
и в чем же, позвольте полюбопытствовать, кроме того что им вы владеете лучше всего? Имхо, по всем пунктам в пролете (разговор о применении вне веба) начиная от скорости исполнения и кончая языковыми возможностями.
>Ну сочувствуйте
Сочуствую. Но уверен, что вскоре Вы тоже поймете, что есть инструменты изящнее/удобнее )
и в чем же, позвольте полюбопытствовать, кроме того что им вы владеете лучше всего? Имхо, по всем пунктам в пролете (разговор о применении вне веба) начиная от скорости исполнения и кончая языковыми возможностями.
>Ну сочувствуйте
Сочуствую. Но уверен, что вскоре Вы тоже поймете, что есть инструменты изящнее/удобнее )
Если уж на то пошло, то за красоту синтаксиса. Красивее я встречал только у Руби(но с ним не сложились отношения). Ну а вот пайтон, возьму небольшой кусок и поставлю в комментарии к нему мои первые мысли об увиденном:
[ [[[[[ //Че за фигня? нафиг так делать?
( //Мдаа, множество пустых скобок без предваряющих конструкций — это супер читаемо.
(
p('Multiplications:'), //Функция? Методы объекта в сцепке? Хз.
doMult(4, 10),
l()
), //хммм, "," — это похоже на перечисление
( //А нет, похоже на разделитель. Блин, ";" логичнее
p(),
p('Fib:'),
и т.д.
Вот примерные размышления о пайтоне. РНР даже выглядит более зрело и законченно.
[ [[[[[ //Че за фигня? нафиг так делать?
( //Мдаа, множество пустых скобок без предваряющих конструкций — это супер читаемо.
(
p('Multiplications:'), //Функция? Методы объекта в сцепке? Хз.
doMult(4, 10),
l()
), //хммм, "," — это похоже на перечисление
( //А нет, похоже на разделитель. Блин, ";" логичнее
p(),
p('Fib:'),
и т.д.
Вот примерные размышления о пайтоне. РНР даже выглядит более зрело и законченно.
протестую! это вырвано из контекста… кроме того в тексте из которого Вы взяли этот код явно написано, что «так делать не надо» )
О, и правда, я до конца не дочитал. Сразу предупреждать надо было. Но тем не менее суть особо не меняется. Контекст не важен, мы же синтаксис обсуждаем, а не изящность применения функциональных подходов в императивных языках. Это первый какой мне попался под руку пайтоновский код.
Вы по сути добились того, что вызвали у меня неприязнь к пайтону:) Раньше я его радушно воспринимал.
рано делаете выводы… это не серьезно.
А если серьезно. То вот пару примерчивов из интерактивной питоновской консоли (аналога которой в пхп конечно же нет):
ну и так далее можно много фокусов делать
все эти примеры (и много других) можно прогнать онлайн тут shell.appspot.com/
А если серьезно. То вот пару примерчивов из интерактивной питоновской консоли (аналога которой в пхп конечно же нет):
>>> a = range(10)
>>> a
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>>> [2^x for x in a]
[2, 3, 0, 1, 6, 7, 4, 5, 10, 11]
>>> a = range(10)
>>> a
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>>> [2**x for x in a] # степени двойки
[1, 2, 4, 8, 16, 32, 64, 128, 256, 512]
>>> [x**2 for x in a] # квадраты
[0, 1, 4, 9, 16, 25, 36, 49, 64, 81]
>>> ["a"*x for x in a] # возрастающие строчки из букв а
['', 'a', 'aa', 'aaa', 'aaaa', 'aaaaa', 'aaaaaa', 'aaaaaaa', 'aaaaaaaa', 'aaaaaaaaa']
>>> list(reversed(a)) # обращение списка
[9, 8, 7, 6, 5, 4, 3, 2, 1, 0]
>>> sum(a)
45
>>> max(a), min(a)
(9, 0)
>>> a
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>>> a[::-1] # ну или обращение через срез
[9, 8, 7, 6, 5, 4, 3, 2, 1, 0]
>>> a[5:8]=['q','q','q'] # присвоение срезу
>>> a
[0, 1, 2, 3, 4, 'q', 'q', 'q', 8, 9]
ну и так далее можно много фокусов делать
все эти примеры (и много других) можно прогнать онлайн тут shell.appspot.com/
Короче, вот почитайте. habrahabr.ru/blogs/php/46783/
гггггггг) Вот это лепим из мухи слона)
Пусть расцветает тысяча цветов! © Мао
Жизнь сама решит, нужно это, или бред.
Жизнь сама решит, нужно это, или бред.
Действительно, поживем — увидим. Вдруг лет через 10-20-30 уже никто и не вспомнит, что раньше РНР использовали «для того, чтобы сайты писать»
но зачем? ведь есть куда более разумные альтернативы (python, не говоря уже о java'е)
А почему бы и нет? Что в этом неразумного?
Для хороших десктопных приложений очень важно иметь нормальную поддержку тредов (интерфейс не должен лагать пока программа работает). А с этим в пхп очень грустно и будет грустно еще долго.
<холивор мод он><имхо>пока код пхп сценариев будут начинаться с <?php и заканчиваться ?> то извините, но пхп таки не язык а препроцессор текста, пусть навороченный, но все же эдакий препроцессор-переросток </></>
хотел написать тут умную и витиеватую мыслеформу, но потом передумал, и решил сказать только то, что в принципе давно и не раз говорено и многим известно. Как ЯП (язык программирования) общего назначения пхп довольно убог и крайне неряшлив (если будет нужно, расшифрую). Так стоит ли писать на нем на десктопе и в других областях (типа написания собственно веб-серверов на голом пхп (да, были прецеденты)) только лишь потому, что вы привыкли на нем писать.
хотел написать тут умную и витиеватую мыслеформу, но потом передумал, и решил сказать только то, что в принципе давно и не раз говорено и многим известно. Как ЯП (язык программирования) общего назначения пхп довольно убог и крайне неряшлив (если будет нужно, расшифрую). Так стоит ли писать на нем на десктопе и в других областях (типа написания собственно веб-серверов на голом пхп (да, были прецеденты)) только лишь потому, что вы привыкли на нем писать.
Если так достают эта пара конструкций, вы можете писать без них, а потом просто добавлять через однострочный .sh скрипт)
да мне как бы пох ибо на пхп я не пишу ))
это был как бы аргумент в пользу того что пхп не ЯП общего назначения, а препроцессор текста, негармонично увешанный всякими языковыми конструкциями в тщетной попытке стать похожим на хороший ЯП, но мы то знаем, что (цитирую) www.linux.org.ru/view-message.jsp?msgid=3828133#comment-3828441
это был как бы аргумент в пользу того что пхп не ЯП общего назначения, а препроцессор текста, негармонично увешанный всякими языковыми конструкциями в тщетной попытке стать похожим на хороший ЯП, но мы то знаем, что (цитирую) www.linux.org.ru/view-message.jsp?msgid=3828133#comment-3828441
Зачем тогда критиковать то, чем не пользуетесь? Он вас чем-то обидел? Если нет, то зачем вообще обращать внимания на РНР? Развивается и пусть себе развивается. Рассуждения о том что на нем стоит делать, а что не стоит значимы только от людей которые на нем пишут.
Затем чтоб помочь другим начинающим/колеблющимся программистам определится с выбором, не совершить ошибки и т.д. )
Вы уверены, что РНР это ошибка? Может ява это ошибка? или пайтон? или с#? или с++? или {любой ЯП} это ошибка? Личный выбор это личный выбор, а не выбор под действие наставлений «РНР — ошибка» из уст неизвестного евангелиста.
вообще то я имел в виду именно контекст поднятой в корневом посте темы а именно GUI на PHP. В вебе его использование вполне оправдано, не спорю, тем более что уже созданно н-ное количество вполне неплохих программ/систем/форумов етц… Впрочем я и этого не стал бы делать
Всегда с чего-то нужно начинать. Может быть в будущем PHP-GTK будет довольно популярной библиотекой. А с таким отношением ничего серьёзного не получится. Нужно сначала попробовать и на конкретных примерах объяснить несостоятельность PHP для десктопа, а не голословно кричать.
да где же голословность? Вам уже как минимум несколько причин привели
— нет поддержки многопоточности
— слабый сборщик мусора (сомневаюсь, что он стал гораздо лучше, наконец только научился циклические ссылки находить и килять)
— сам язык, что бы не говорили, плох. Да вроде и исключения есть, но стандартная библиотека их не использует (будь добр писать в стиле старого доброго си). Да есть неймспейсы, но тысячи либных функций по прежнему в глобал спейсе и т.д. Не говоря о самых уж простых вещах о том зачем каждую переменную префиксовать $ и куда более важную штуку как доступ к полю класса осуществлять через "->" вместо "." ну и так далее. Если для веба это еще куда ни шло, то для серьезного прикладного программирования это неприемлемо. Если только PHP очень сильно не изменится, но это маловероятно, ведь на нем лежит ноша обратной совместимости.
— нет поддержки многопоточности
— слабый сборщик мусора (сомневаюсь, что он стал гораздо лучше, наконец только научился циклические ссылки находить и килять)
— сам язык, что бы не говорили, плох. Да вроде и исключения есть, но стандартная библиотека их не использует (будь добр писать в стиле старого доброго си). Да есть неймспейсы, но тысячи либных функций по прежнему в глобал спейсе и т.д. Не говоря о самых уж простых вещах о том зачем каждую переменную префиксовать $ и куда более важную штуку как доступ к полю класса осуществлять через "->" вместо "." ну и так далее. Если для веба это еще куда ни шло, то для серьезного прикладного программирования это неприемлемо. Если только PHP очень сильно не изменится, но это маловероятно, ведь на нем лежит ноша обратной совместимости.
Знак доллара перед именем переменной очень удобно. В питоне я долго не мог освоиться писать без него. Про '->' совсем не понятно, из-за одного лишнего байта считать язык плохим?
Лор таки стал авторитетным ресурсом?
Пхп конечно стихийно образовавшийся язык, но по количеству дерьмокода он недалеко обгоняет яву. А если писать нормально, то и на пхп можно писать нормально. Если пхп знать, то на нём можно неплохо писать.
Пхп конечно стихийно образовавшийся язык, но по количеству дерьмокода он недалеко обгоняет яву. А если писать нормально, то и на пхп можно писать нормально. Если пхп знать, то на нём можно неплохо писать.
«ибо на пхп я не пишу»
«пхп не ЯП общего назначения, а препроцессор текста, негармонично увешанный всякими языковыми конструкциями в тщетной попытке стать похожим на хороший ЯП»
Согласен с вами. Когда я маюсь от бзделья, тоже люблю пообсуждать на всяких форумах то о чём вообще понятия не имею. И для пущего эффекта всегда прикрепляю к свои постам цитату.
В общем хороший псот. Одобряю.
«пхп не ЯП общего назначения, а препроцессор текста, негармонично увешанный всякими языковыми конструкциями в тщетной попытке стать похожим на хороший ЯП»
Согласен с вами. Когда я маюсь от бзделья, тоже люблю пообсуждать на всяких форумах то о чём вообще понятия не имею. И для пущего эффекта всегда прикрепляю к свои постам цитату.
В общем хороший псот. Одобряю.
почему Вы считаете, что я «не имею понятия»?
Да я вот вот прочитал про
«Не говоря о самых уж простых вещах о том зачем каждую переменную префиксовать $ и куда более важную штуку как доступ к полю класса осуществлять через „->“ вместо »."
Я вот видел много аргументов о том какой плохой пхп, но это… это капец (извините за мой французский).
Я так понимаю если у X языка программирования синтаксис отличается от <вашего_любимого_языка> — это недостаток X языка программирования. Весьма оригинальная позиция.
А у вас, простите, какой стаж работы с ПХП? На какой версии работали?
«Не говоря о самых уж простых вещах о том зачем каждую переменную префиксовать $ и куда более важную штуку как доступ к полю класса осуществлять через „->“ вместо »."
Я вот видел много аргументов о том какой плохой пхп, но это… это капец (извините за мой французский).
Я так понимаю если у X языка программирования синтаксис отличается от <вашего_любимого_языка> — это недостаток X языка программирования. Весьма оригинальная позиция.
А у вас, простите, какой стаж работы с ПХП? На какой версии работали?
ну вот ругают же питон за отступы (хотя это на самом деле благо), так почему бы не поругать пхп за $ -> :: \ и прочие корявости синтаксиса, кои явно есть зло.
> Я так понимаю если у X языка программирования синтаксис отличается от <вашего_любимого_языка> — это недостаток X языка программирования.
Если отличается в (подчеркиваю) лучшую сторону, то правильно понимаете.
> А у вас, простите, какой стаж работы с ПХП? На какой версии работали?
~месяца хватило.
> Я так понимаю если у X языка программирования синтаксис отличается от <вашего_любимого_языка> — это недостаток X языка программирования.
Если отличается в (подчеркиваю) лучшую сторону, то правильно понимаете.
> А у вас, простите, какой стаж работы с ПХП? На какой версии работали?
~месяца хватило.
«ну вот ругают же питон за отступы (хотя это на самом деле благо), так почему бы не поругать пхп за $ -> :: \ и прочие корявости синтаксиса, кои явно есть зло.»
Ваша объективность видна невооружённым глазом.
«Если отличается в (подчеркиваю) лучшую сторону, то правильно понимаете.»
Только вы не учитываете, что у каждого «лучшая сторона» своя. Почитайте о смысле слова «привычка» и о том как она влияет на человеческие суждения.
"~месяца хватило. "
Я примерно такого и ожидал. Больше вопросов нет.
Ваша объективность видна невооружённым глазом.
«Если отличается в (подчеркиваю) лучшую сторону, то правильно понимаете.»
Только вы не учитываете, что у каждого «лучшая сторона» своя. Почитайте о смысле слова «привычка» и о том как она влияет на человеческие суждения.
"~месяца хватило. "
Я примерно такого и ожидал. Больше вопросов нет.
>Ваша объективность видна невооружённым глазом.
А я очень субъективен, и выражаю здесь только свое субъективное, но оттого не менее искреннее мнение, при этом аргументирую его. Какие претензии?
>Только вы не учитываете, что у каждого «лучшая сторона» своя. Почитайте о смысле слова «привычка» и о том как она влияет на человеческие суждения.
Открою Вам (уверен) большую тайну. Префиксование $ переменных было введено исключительно ради упрощения парсера\семантического анализатора, а отнюдь не ради мифического удобства. В самом деле, представьте, что парсеру гораздо проще понять где, например переменная, а где ключевое слово языка, если все переменные помечены долларом. Спасибо хоть @ % из перла не взяли ). То же самое по поводу разделителей :: \ -> вместо одной точки.
>Я примерно такого и ожидал. Больше вопросов нет.
Вот и замечательно. Будем считать, что моя позиция вам ясна )
А я очень субъективен, и выражаю здесь только свое субъективное, но оттого не менее искреннее мнение, при этом аргументирую его. Какие претензии?
>Только вы не учитываете, что у каждого «лучшая сторона» своя. Почитайте о смысле слова «привычка» и о том как она влияет на человеческие суждения.
Открою Вам (уверен) большую тайну. Префиксование $ переменных было введено исключительно ради упрощения парсера\семантического анализатора, а отнюдь не ради мифического удобства. В самом деле, представьте, что парсеру гораздо проще понять где, например переменная, а где ключевое слово языка, если все переменные помечены долларом. Спасибо хоть @ % из перла не взяли ). То же самое по поводу разделителей :: \ -> вместо одной точки.
>Я примерно такого и ожидал. Больше вопросов нет.
Вот и замечательно. Будем считать, что моя позиция вам ясна )
Мои 5 копеек насчет знака $:
1) Никаких мифов об удобстве — исключительно факты: визуально легко отличимы переменные от других ключевых слов. Особенно полезно при изучении чужого кода, где не держишь в голове имена всех переменных.
2) Есть еще великолепные возможности благодаря этому знаку, которые вы в меру ограниченности своего знакомства с РНР вряд ли знаете. Вот наглядный пример:
$a = «foo»;
$b = «bar»;
$c = $a($b); // Вызывает функцию с именем foo и параметром bar, т.е. $c=foo(«bar»);
$d = $b->$a($c); //Вызывает метод foo объекта bar с параметром $c, т.е. $d = bar -> foo($c);
Очень часто такие методы достаточно удобны. Без всяких call_user_func
1) Никаких мифов об удобстве — исключительно факты: визуально легко отличимы переменные от других ключевых слов. Особенно полезно при изучении чужого кода, где не держишь в голове имена всех переменных.
2) Есть еще великолепные возможности благодаря этому знаку, которые вы в меру ограниченности своего знакомства с РНР вряд ли знаете. Вот наглядный пример:
$a = «foo»;
$b = «bar»;
$c = $a($b); // Вызывает функцию с именем foo и параметром bar, т.е. $c=foo(«bar»);
$d = $b->$a($c); //Вызывает метод foo объекта bar с параметром $c, т.е. $d = bar -> foo($c);
Очень часто такие методы достаточно удобны. Без всяких call_user_func
>1)
имхо, это заблуждение. Все эти значки создают совершенно ненужный синтаксический шум. С визуальным выделением переменных поможет любой мало-мальски пристойный редактор кода. Ни в жизнь не поверю, что вы пишете код в Блокноте.
>2)
Знаю, отчего же
Только это нифига не плюс. В любом динамическом языке возможны подобные финты, которые, кстати, нужны довольно редко.
имхо, это заблуждение. Все эти значки создают совершенно ненужный синтаксический шум. С визуальным выделением переменных поможет любой мало-мальски пристойный редактор кода. Ни в жизнь не поверю, что вы пишете код в Блокноте.
>2)
Знаю, отчего же
Только это нифига не плюс. В любом динамическом языке возможны подобные финты, которые, кстати, нужны довольно редко.
>> 1) даже в редакторе с подсветкой с $ более заметно.
Ни в жизнь не поверю, что вы пишете код в Блокноте. — я так начинал. Принцип такой. Типа «тяжело в учении — легко в бою». Сейчас Блокнота у меня тупо нет ;) (есть gedit) но в работе использую исключительно NetBeans.
>> 2) опять же зависит от задачи. Но гораздо лучше, когда есть возможность, чем когда ее нет. Так что, вполне плюс.
Ни в жизнь не поверю, что вы пишете код в Блокноте. — я так начинал. Принцип такой. Типа «тяжело в учении — легко в бою». Сейчас Блокнота у меня тупо нет ;) (есть gedit) но в работе использую исключительно NetBeans.
>> 2) опять же зависит от задачи. Но гораздо лучше, когда есть возможность, чем когда ее нет. Так что, вполне плюс.
PHP мой основной язык уже года 4, но с аргументами xonix полностью согласен. Уже ко всему привык, в целом все нравится, но если бы сейчас пересаживался на PHP с другого языка то многие вещи сильно бы напрягали, особенно:
— стихийно образовывающаяся библиотека, где нет единого подхода к наименованию функций и методов, как уже было сказано, куча функций в глобальном пространстве.
— доступ к полям, пространствам имен, методам и тп через единственный символ "." действительно удобнее. Как бы ни говорили, что 2 символа вместо одного, 1 всеравно удобнее.
— "<?php" был актуален вначале развития языка, но сейчас, когда 80% файлов проекта состоят из классов эта констукция смотрится нелепо. Особенно раздражает когда заказчики требуют оформление кода согласно принятому в компании и в конце кода нужно обязательно добалвять закрывающий "?>"
— очень не хватает полноценных свойств
— базовые типы не являются объектами. В принципе, это не так важно, но было бы приятно.
Большинство недостатков складываются из исторического прошлого. Но в остальном, пишу с удовольствием и пока серьезно не планирую переходить на другой язык.
По поводу GTK, использовал один раз когда нужно было накидать простенький гуй к существующей библиотеке. Писать можно, но толку мало. Может, когда-нибудь это направление подрастет, но сейчас есть смысл использовать либу только для простого интерфейса, в сложных приложениях проще потратить время на изучение другой среды
— стихийно образовывающаяся библиотека, где нет единого подхода к наименованию функций и методов, как уже было сказано, куча функций в глобальном пространстве.
— доступ к полям, пространствам имен, методам и тп через единственный символ "." действительно удобнее. Как бы ни говорили, что 2 символа вместо одного, 1 всеравно удобнее.
— "<?php" был актуален вначале развития языка, но сейчас, когда 80% файлов проекта состоят из классов эта констукция смотрится нелепо. Особенно раздражает когда заказчики требуют оформление кода согласно принятому в компании и в конце кода нужно обязательно добалвять закрывающий "?>"
— очень не хватает полноценных свойств
— базовые типы не являются объектами. В принципе, это не так важно, но было бы приятно.
Большинство недостатков складываются из исторического прошлого. Но в остальном, пишу с удовольствием и пока серьезно не планирую переходить на другой язык.
По поводу GTK, использовал один раз когда нужно было накидать простенький гуй к существующей библиотеке. Писать можно, но толку мало. Может, когда-нибудь это направление подрастет, но сейчас есть смысл использовать либу только для простого интерфейса, в сложных приложениях проще потратить время на изучение другой среды
Вспомнил анекдот про чувака, который в библиотеку за хлебом ходил.
Почему бы и нет, на .HTA можно делать приложения в виндовсе. PHP-GTK ничем не хуже. Хотя нет, хуже, HTA позволяет из HTML сделать приложение только лишь переименовав файл, здесь же придется специально программировать.
Вот бы на базе PHP кода, выдающего HTML, получить обычное приложение без веб-сервера, и чтобы работало на разных платформах, тогда портировать веб-приложения (уже написанные) на десктоп было бы проще простого.
Вот бы на базе PHP кода, выдающего HTML, получить обычное приложение без веб-сервера, и чтобы работало на разных платформах, тогда портировать веб-приложения (уже написанные) на десктоп было бы проще простого.
А мусор кто будет собирать? Язык ориентирован на программы выполняющиеся доли секунды (в большинстве случаев). Очевидно что такая ориентация отражена в реализации. Соответсвенно он не может быть производительным и эффективным на десктопе
прикольно — там даже Glade, Gladexml есть — можно клепать GUI визуально
Всё конечно круто, но невозможность скомпилировать, или скрыть реализацию определённых моментов — удручает =(
Я ярый сторонник теории OpenSource, поэтому лично меня этот факт наоборот радует.
А сам автор знает что-то, кроме PHP? Уж очень не предназначен он для GUI.
Мне очень даже кажется, что намного полезнее расширять свой кругозор изучением других языков, чем проработав N лет в PHP, понять что ничего не смыслишь в программировании (точнее, технологиях).
Холивар разводить не хочу. Просто пусть куча людей будут писать на PHP и только на нем, а я буду изучать другие технологии и точки зрения:)
Мне очень даже кажется, что намного полезнее расширять свой кругозор изучением других языков, чем проработав N лет в PHP, понять что ничего не смыслишь в программировании (точнее, технологиях).
Холивар разводить не хочу. Просто пусть куча людей будут писать на PHP и только на нем, а я буду изучать другие технологии и точки зрения:)
Простите, если вы работаете в проекте, написанном на пхп, вы станете включать туда код на других языках? ( не имею ввиду js и тому подобное… )
вас послушать, так гуи на чистом винапи — ЗЛО… :)
вас послушать, так гуи на чистом винапи — ЗЛО… :)
SQL тоже не считать? :) Библиотеки, на писаные на чистом C из-за производительности — тоже?
Я для начала оценю что будет эффективнее. Для каждой задачи есть подходящие инструменты и нет. Если надо к сайту на PHP сделать GUI (зачем??) более чем нам одну кнопку, то я воспользуюсь более подходящим для этого решением.
Также не стоит забывать о будущих изменениях. Сколько будут стоить изменения GUI на PHP? А сколько на предназначенного для этого языке?
GUI на винапи я имел несчастье писать. Для развлечения. Второй раз не тянет. Производительность труда слишком низкая.
Я для начала оценю что будет эффективнее. Для каждой задачи есть подходящие инструменты и нет. Если надо к сайту на PHP сделать GUI (зачем??) более чем нам одну кнопку, то я воспользуюсь более подходящим для этого решением.
Также не стоит забывать о будущих изменениях. Сколько будут стоить изменения GUI на PHP? А сколько на предназначенного для этого языке?
GUI на винапи я имел несчастье писать. Для развлечения. Второй раз не тянет. Производительность труда слишком низкая.
а скрины почему не выложил?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Небольшая программа на PHP-GTK