Комментарии 209
НЛО прилетело и опубликовало эту надпись здесь
Что wow - это одни эмоции...
Для желающий обсудить интернет образование в школах
готов выделить отдельный уголок на PHP Conf 2007
http://www.habrahabr.ru/blog/webdev/7743…
Для желающий обсудить интернет образование в школах
готов выделить отдельный уголок на PHP Conf 2007
http://www.habrahabr.ru/blog/webdev/7743…
Зачем детям в школе php? С паскалем и бейсиком далеко не все справляются, а это все же основы. Разработка веб-приложений, на мой взгляд, выходит за рамки стандартных школьных знаний.
А те еденицы в классах, кто хочет изучить веб-программирование, получают возможность иметь деятельность в рамках школьной жизни.
а остальным незачем даже паскаль, потому как те, кто с компьютером не работал, за турбо паскаль его не полюбят, это точно.
Кроме того, всем знания по программированию без толку - пользы практической от них мало, да и мозги вцелом это развивает слабее, чем математика, например.
а остальным незачем даже паскаль, потому как те, кто с компьютером не работал, за турбо паскаль его не полюбят, это точно.
Кроме того, всем знания по программированию без толку - пользы практической от них мало, да и мозги вцелом это развивает слабее, чем математика, например.
Добавление изучения php в обязательную программу не нужно это только навредит, а вот организация кружков не помешала бы: кто хочет, тот научится, а кому это даром не надо тот и время (нервы, кофе, сигареты) тратить на это занятие не будет.
Зачем php в принципе где-либо.
Разработка приложений в этой среде повышает энтропию и ухудшает карму.
Если бы не php, программистов могло бы быть меньше примерно в пять раз, и результат был бы лучше в три.
Разработка приложений в этой среде повышает энтропию и ухудшает карму.
Если бы не php, программистов могло бы быть меньше примерно в пять раз, и результат был бы лучше в три.
Это уже вопрос мировоззренческий :)
Сегодняшние реалии таковы, что без знаний php, веб-разработчику будет сложно. Другое дело, что это безусловно не школьная программа - да речь об этом и не идет.
Сегодняшние реалии таковы, что без знаний php, веб-разработчику будет сложно. Другое дело, что это безусловно не школьная программа - да речь об этом и не идет.
Веб-разработчику без знания php будет сложно, потому что веб-разработчик в сегодняшних реалиях, как правило, кроме php ничего и не знает.
Я немного занимался веб-разработкой в качестве неосновного занятия последние лет десять, и пока не было php, жизнь была легка и приятна. Иногда разработка сводится к написанию плагинов в готовые системы, иногда к правке этих систем. Корреляция между выбором пхп и качеством кода просто потрясающа. Я согласен, что плохой код можно писать на любом языке. Но языки, которые к этому подталкивают своим дизайном и идеологией модели конца семидесятых, это не оправдывает. Помимо нахождения в главном контексте трёх тысяч встроенных функций, чего стоит заманчивая лёгкость смешения кода и маркапа при помощи встроенного интерпретатора. Убеждён, что конструкция <? нанесла тяжкий удар по развитию веба, и затормозила популяризацию идей всуе помянутого 2.0 на несколько лет.
Я немного занимался веб-разработкой в качестве неосновного занятия последние лет десять, и пока не было php, жизнь была легка и приятна. Иногда разработка сводится к написанию плагинов в готовые системы, иногда к правке этих систем. Корреляция между выбором пхп и качеством кода просто потрясающа. Я согласен, что плохой код можно писать на любом языке. Но языки, которые к этому подталкивают своим дизайном и идеологией модели конца семидесятых, это не оправдывает. Помимо нахождения в главном контексте трёх тысяч встроенных функций, чего стоит заманчивая лёгкость смешения кода и маркапа при помощи встроенного интерпретатора. Убеждён, что конструкция <? нанесла тяжкий удар по развитию веба, и затормозила популяризацию идей всуе помянутого 2.0 на несколько лет.
Возможно, в чем-то вы и правы - не готов судить, нет достаточного опыта.
Если говорить о развитии веба, то убежден, что проблема далеко не в php, а скорее в давно морально устаревшем html.
Если говорить о развитии веба, то убежден, что проблема далеко не в php, а скорее в давно морально устаревшем html.
НЛО прилетело и опубликовало эту надпись здесь
Тот кто знает не только PHP и понимает, что такое процедурная, объектно-ориентированная, функциональная, декларативная парадигмы и понимает чем они отличаются обычно о PHP отзываются как bobuk и собственно правильно делают.
оставили бы свой бред при себе. было бы полезнее. правда.
А что так лаконично? Открыли бы мне глаза, как вещи устроены на самом деле, коли я во тьме живу все эти годы. Я верю, вы можете. И все мои ощущения и опыт (а не суждения, прошу заметить) носят иллюзорный, бредовый характер.
а смысл разбирать весь бред подробно? только конкретно - какое из предложений вашего сообщения должно подлежать обсужденияю, как "ценная мысль"? исключая единственную фразу - "Я согласен, что плохой код можно писать на любом языке."
Смысл разбирать подробно следующий. Мне было заявлено, что мной многолетний опыт является бредом. Коротенечно так.
До получения сатисфакции считаю это просто бранью и личным оскорблением.
До получения сатисфакции считаю это просто бранью и личным оскорблением.
Ну у меня вот тоже есть многолетний опыт, который показывает, что всегда найдется разряд людей, особенно вашего поколения, которые просто зачастую не готовы к новым реалиям и все старое им кажетсяф верхом совершенства, но обида, что современный PHP может зарабатывать больше, и делать качественные продукты без вашего опыта мешает жить, от того и появляются такие вот замечания, ничем не обоснованые, как справедливо заметил ваш прежний аппонент.
О, я создал образ брюзжащего старпёра? :)
Настолько, чтобы называть «новыми реалиями» нечто, чему 13 лет? :)
Отчего же тогда, молодой человек, к значительно более новым реалиям под названием ruby, lua, XML, тот же web2, будь он неладен, у меня гораздо меньше претензий?
Настолько, чтобы называть «новыми реалиями» нечто, чему 13 лет? :)
Отчего же тогда, молодой человек, к значительно более новым реалиям под названием ruby, lua, XML, тот же web2, будь он неладен, у меня гораздо меньше претензий?
Забыл уточнить: я не зарабатываю программированием на жизнь, у меня нет зависти к заработкам. Мой опыт и комментарии относятся исключительно к миру опен-сорса. Допускаю, что в корпоративной модели закрытых разработок результаты могут быть иные.
отнюдь, в корпоративной модели часто обратная ситуация с качеством и документацией кода, а OpenSource, я не говорю о школьных поделках, в основном гораздо читабельнее и масштабируемый.
но бывают и исключения из правил :)
но бывают и исключения из правил :)
следует учитывать что "порог вхождения" для PHP-специалистов один из самых низких. Это одна из причин, по которым пхп сложно назвать вменяемым языком, она влечет за собой очень высокую стоимость редких хороших спецов и копеечную - массы.
повеселили, спасибо.
еще раз повторяю. нет смысла разбирать тот бред, который вы написали выше, за исключением одной единственной фразы, которуя я привел. вам нужно скопировать ваш же пост и попросить отметить те предложения, которые по вашему нуждаются в обсуждении или вы самостоятельно это сможете проделать?
наличие опыта и написание бреда - ни как не коррелируют между собой.
наличие опыта и написание бреда - ни как не коррелируют между собой.
Какая-то диковинная манера вести дискуссию. В обсуждении нуждается не мой пост, а ваш.
Я утверждаю А, потому что имею причину Б.
Бред.
Что именно бред, А, Б, или импликация?
Напишите ещё раз, и я вам подчеркну.
(ничего, что я к вам спиной сижу?)
Тема закрыта. Мне такой формат общения неинтересен.
Я утверждаю А, потому что имею причину Б.
Бред.
Что именно бред, А, Б, или импликация?
Напишите ещё раз, и я вам подчеркну.
(ничего, что я к вам спиной сижу?)
Тема закрыта. Мне такой формат общения неинтересен.
Мне аналогично не интересно обсуждать абстрактные вещи. На мою просьбу выделить те места вашего сообщения, которые есть необходимость обсуждать, вы отвечаете отказом. Придется разобрать каждое предложение по отдельности.
Веб-разработчик должен знать как минимум (помимо одного языка разработки):
html
основы протокола http
основы работы веб-серверов
основы *nix систем
основы проектирования БД
основы работы с БД
основы ООП (хотя бы для того чтобы в состоянии понимать как сделать простейшую проверку на заполненность элемента форма на JavaScripte)
Это так, на вскидку. Для интереса можете попробовать написать программу обучения с нуля основам веб-разработки – сразу будет все понятно понятно. Резюмируем – в предложении написан бред.
В огороде бузина... Два ну совершенно не связанных факта. Может быть она (жизнь) стала такой потому что бросила девушка? Или может с работы уволили? Есть замечательный анекдот: «- А как же вы расслабляетесь? - А я не напрягаюсь». Хотя, если вам не дают покоя лавры разработчиков, которые смогли на основе этого языка заработать известность и деньги, то да, РНР сыграл действительно важную роль в вашей жизни. Итог – это предложение бред.
Вы могли бы нам еще подробно описать как после того как проснулис – тщательно чистите зубы. Итого - бред.
Я наверное отстал от жизни, привык, знаете ли на цифирки смотреть, можно увидеть цифирки и методику проведения исследования? Без циферок данное продолжение является мягко говоря бредом ну или буйной фантазией.
Язык ни к чему не подталкивает. Язык предоставляет инструмент. «Разруха не в туалетах, а в головах». То, что С был разработан в начале 70 совершенно ему не мешает оставаться одним из ведущих языков разработки. Итог не утешителен – снова бред.
Мне кажется, что для этого предложения даже доказательства его бредовости не нужны – попробуйте его еще раз перечитать и понять смысл. Думаю ни у одного здравомыслящего человека это не получится. Потому что это не просто бред, а бессвязный бред.
Думаю что это предложение стоит показать столпам из яхи, фликра, дигга, википедии и др. А то пацаны то не знают, что они оказались в пролете с основным языком разработки. Бред.
Подводя итоги печальной статистики. Было рассмотрено 8 предложений. Из них только 1 не является бредом (о чем я заявлял с самого начала). 4 (50%!!) предложения страдают отсутствием причинно-следственных связей. Неужели такой пост нельзя считать бредом? Мне кажется на полных основаниях можно.
Веб-разработчику без знания php будет сложно, потому что веб-разработчик в сегодняшних реалиях, как правило, кроме php ничего и не знает.
Веб-разработчик должен знать как минимум (помимо одного языка разработки):
Это так, на вскидку. Для интереса можете попробовать написать программу обучения с нуля основам веб-разработки – сразу будет все понятно понятно. Резюмируем – в предложении написан бред.
Я немного занимался веб-разработкой в качестве неосновного занятия последние лет десять, и пока не было php, жизнь была легка и приятна.
В огороде бузина... Два ну совершенно не связанных факта. Может быть она (жизнь) стала такой потому что бросила девушка? Или может с работы уволили? Есть замечательный анекдот: «- А как же вы расслабляетесь? - А я не напрягаюсь». Хотя, если вам не дают покоя лавры разработчиков, которые смогли на основе этого языка заработать известность и деньги, то да, РНР сыграл действительно важную роль в вашей жизни. Итог – это предложение бред.
Иногда разработка сводится к написанию плагинов в готовые системы, иногда к правке этих систем.
Вы могли бы нам еще подробно описать как после того как проснулис – тщательно чистите зубы. Итого - бред.
Корреляция между выбором пхп и качеством кода просто потрясающа.
Я наверное отстал от жизни, привык, знаете ли на цифирки смотреть, можно увидеть цифирки и методику проведения исследования? Без циферок данное продолжение является мягко говоря бредом ну или буйной фантазией.
Но языки, которые к этому подталкивают своим дизайном и идеологией модели конца семидесятых, это не оправдывает.
Язык ни к чему не подталкивает. Язык предоставляет инструмент. «Разруха не в туалетах, а в головах». То, что С был разработан в начале 70 совершенно ему не мешает оставаться одним из ведущих языков разработки. Итог не утешителен – снова бред.
Помимо нахождения в главном контексте трёх тысяч встроенных функций, чего стоит заманчивая лёгкость смешения кода и маркапа при помощи встроенного интерпретатора.
Мне кажется, что для этого предложения даже доказательства его бредовости не нужны – попробуйте его еще раз перечитать и понять смысл. Думаю ни у одного здравомыслящего человека это не получится. Потому что это не просто бред, а бессвязный бред.
Убеждён, что конструкция <? нанесла тяжкий удар по развитию веба, и затормозила популяризацию идей всуе помянутого 2.0 на несколько лет.
Думаю что это предложение стоит показать столпам из яхи, фликра, дигга, википедии и др. А то пацаны то не знают, что они оказались в пролете с основным языком разработки. Бред.
Подводя итоги печальной статистики. Было рассмотрено 8 предложений. Из них только 1 не является бредом (о чем я заявлял с самого начала). 4 (50%!!) предложения страдают отсутствием причинно-следственных связей. Неужели такой пост нельзя считать бредом? Мне кажется на полных основаниях можно.
«Ничего не знают» имелось в виду не вообще ничего, в том числе читать и писать. Имелось в виду, «не знают других средств разработки бэкенда». Мне это казалось очевдным.
Когда я говорю, есть корреляция, я основываю это на своём собственном опыте, а не на результате исследований третьих лиц.
Вы мне скажете, когда я выпью плохой водки, наутро, как правило, испытываю недомогание, я закричу, это ненаучно, где статистика, приведите цифры! Это ваш бред и фантазии!
Схоластические приёмы позволяют назвать бредом любое высказываение, мы в курсе.
Когда я говорю, есть корреляция, я основываю это на своём собственном опыте, а не на результате исследований третьих лиц.
Вы мне скажете, когда я выпью плохой водки, наутро, как правило, испытываю недомогание, я закричу, это ненаучно, где статистика, приведите цифры! Это ваш бред и фантазии!
Схоластические приёмы позволяют назвать бредом любое высказываение, мы в курсе.
я правильно понимаю, что возражений по существу моего ответа нет? значит мы благополучно пришли к тому с чего начали - то что было написано тут является бредом.
НЛО прилетело и опубликовало эту надпись здесь
PHP - это всего лишь инструмент. Такой же как молоток. Им можно чинить, можно ломать, а можно и пробить голову. Например, свою. Все зависит от квалификации.
Есть два молотка. Один обычный, а у другого ручка скользкая, и наконечник разбалансирован. И тот и другой инструменты. Обоими можно чинить и ломать, пытаясь не пробить себе голову. Зависит от квалификации. И зависимость такова: чем хуже инструмент, тем выше должна быть квалификация. Поэтому при заданной наперёд квалификации N процент пробитых голов выше.
НЛО прилетело и опубликовало эту надпись здесь
По Вашему PHP - это молоток со скользкой ручкой и отваливающимся наконечником? Это значит, что во всем мире не нашлось человека сделать нормальный молоток?..
Я думаю, что скользкость инструмента связана исключительно с "прямотой" рук :) А точность ударов - это следствие первого.
У меня сложилось впечатление, что Вы в своем споре со всеми просто пошли на принцип.
Я думаю, что скользкость инструмента связана исключительно с "прямотой" рук :) А точность ударов - это следствие первого.
У меня сложилось впечатление, что Вы в своем споре со всеми просто пошли на принцип.
Это значит, что во всем мире не нашлось человека сделать нормальный молоток ?
А вы пробовали другие молотки? :)
Я думаю, что скользкость инструмента связана исключительно с "прямотой" рук :) А точность ударов - это следствие первого.
При достаточной квалификации скользкость инструмента меньше влияет на точность ударов. У тех кого хватает квалификации по возможности стараются использовать другие инструменты. Скажем более удобные.
Ну сравнивать PHP с молотком слишком круто, молоток все таки продуманная и удобная в использовании конструкция которая выдает предсказуемый результат
Наличие возможности смешивания HTML-разметки с PHP-кодом не означает обязательное её использование — это лишь грань гибкости. Предвзятое отношение к PHP и иным интерпретируемым языкам рождает убогие CGI-решения, которые приносят боль и веб-разработчикам и клиентам.
PHP, в отличие, от языков общего назначения, предназначенных для системного программирования, позволяет применительно к веб-приложениям заниматься делом вместо изобретения ограниченного числа (время не резиновое) заведомо кривых (один-два [и при этом наверняка не веб-] программиста вместо десятков программистов, ясно понимающих, что именно нужно для веб-программирования) велосипедов (сотни функций уже давно и качественно реализованы и отлажены в рамках PHP).
PHP, в отличие, от языков общего назначения, предназначенных для системного программирования, позволяет применительно к веб-приложениям заниматься делом вместо изобретения ограниченного числа (время не резиновое) заведомо кривых (один-два [и при этом наверняка не веб-] программиста вместо десятков программистов, ясно понимающих, что именно нужно для веб-программирования) велосипедов (сотни функций уже давно и качественно реализованы и отлажены в рамках PHP).
Наличие возможности смешивания HTML-разметки с PHP-кодом не означает обязательное её использование — это лишь грань гибкости.
Допустим JSP это позволяет. Но не пощряет.
PHP, в отличие, от языков общего назначения, предназначенных для системного программирования, позволяет применительно к веб-приложениям заниматься делом вместо изобретения ограниченного числа (время не резиновое) заведомо кривых (один-два [и при этом наверняка не веб-] программиста вместо десятков программистов, ясно понимающих, что именно нужно для веб-программирования) велосипедов (сотни функций уже давно и качественно реализованы и отлажены в рамках PHP).
Больше всего велосипедов я видел именно для PHP каждый PHP проект старается изобрести собственный слой абстракции от СУБД если он требуется, собственный шаблонный движок если он требуется, собственную систему кеширования если она требуется. А теперь вопрос к вам, почему язык который по вашим словам является так хорошо заточенным под веб проигрывает по функциональности веб-фреймворкам языков общего приложения? В чем сила брат? Чем PHP лучше для веба чем языки общего назначения?
Уточните, пожалуйста, что именно подразумевается под «веб-фреймворками».
Под веб-фреймворками подразумевается специализированный набор библиотек используемый при создании веб-приложений. Обычно имеет свою целостную идеологию и документацию.
Что такое фреймворк вообще, я в курсе. Не вполне ясно, что именно подразумеваете вы под этим словом применительно к веб-программированию с использованием языков с предкомпиляцией вроде С++. Конкретные примеры would be appreciated. Спасибо.
Интересно причем тут C++? Или у вас языки общего назначения им заканчиваются? Если надо примеров то вон возьмите django для python или struts для java. В чем приемущество PHP по сравнению с ними?
Ваще сообщение блаженный бред, всего 3 минуты работы с Google сэкономили бы читателям этой ветки кучу времени на просмотр ваших комментариев.
Вы, видимо, встречались только с очень плохо написанными приложениями на PHP.
Возьмите Propel, возьмите Doctrine, возьмите Creole, возьмите фреймворки Symfony или CakePHP, наконец! Для PHP все уже придумано, написано, и люди этим пользуются.
А сила, брат, в том, что хороший специалист по PHP стоит на рынке в 1.5 раза дешевле, чем по другому языку.
Возьмите Propel, возьмите Doctrine, возьмите Creole, возьмите фреймворки Symfony или CakePHP, наконец! Для PHP все уже придумано, написано, и люди этим пользуются.
А сила, брат, в том, что хороший специалист по PHP стоит на рынке в 1.5 раза дешевле, чем по другому языку.
Вы, видимо, встречались только с очень плохо написанными приложениями на PHP.
Я видел и хорошие приложения на PHP, но все же значительная часть тех приложений, что написаны на PHP все же обладают низким качеством.
Возьмите Propel, возьмите Doctrine, возьмите Creole, возьмите фреймворки Symfony или CakePHP, наконец! Для PHP все уже придумано, написано, и люди этим пользуются.
Я знаю что они есть. Но замечу в каждом из них часто используется свои велосипеды. К тому же в чем тогда удобство PHP как языка именно для веба если в нем удобнее работать с фреймворками, как и в обычных прикладных языках?
А сила, брат, в том, что хороший специалист по PHP стоит на рынке в 1.5 раза дешевле, чем по другому языку.
Хорошие специалисты дешево не стоят как и по PHP так и по любому другому языку. Это миф из разряда, что админы Windows систем получают меньше админов Unix систем.
Хорошего специалиста по PHP найти проще и дешевле, чем по другому языку. Не хочу об этом спорить, я сталкиваюсь с этим профессионально и просто знаю о чем говорю. Например, у нас в Екатеринбурге грамотного специалиста по Питону найти сложно (и он будет стоить приличных денег), а по Руби вообще не найти днем с огнем. PHP-исты сами ломятся в двери толпами, и их можно в конце концов чему-то научить.
В PHP есть много удобных готовых инструментов для работы в вебе. Вы говорили о том, что 3000 встроенных функций - это плохо. Скажите, а если бы к вам в дом пришел сантехник и сказал, что у него с собой только молоток, "но им ведь все можно починить"? Я бы предпочел, чтобы у него был обширный набор инструментов.
Наконец, как вы думаете, почему умерли RISC-процессоры? Да потому что их неудобно программировать, а CISC - удобно. Большой набор функций - это НЕ плохо.
Ну и наконец, PHP - это open source. Тут мы ведь не будем разводить священные войны? Open source - это дешево и хорошо для меня.
Не знаю, как для вас.
В PHP есть много удобных готовых инструментов для работы в вебе. Вы говорили о том, что 3000 встроенных функций - это плохо. Скажите, а если бы к вам в дом пришел сантехник и сказал, что у него с собой только молоток, "но им ведь все можно починить"? Я бы предпочел, чтобы у него был обширный набор инструментов.
Наконец, как вы думаете, почему умерли RISC-процессоры? Да потому что их неудобно программировать, а CISC - удобно. Большой набор функций - это НЕ плохо.
Ну и наконец, PHP - это open source. Тут мы ведь не будем разводить священные войны? Open source - это дешево и хорошо для меня.
Не знаю, как для вас.
PHP-исты сами ломятся в двери толпами, и их можно в конце концов чему-то научить.
Вы вроде по хороших специалистов говорили. А теперь говорите обучить :)
В PHP есть много удобных готовых инструментов для работы в вебе.
Сравните для примера спецификацию на jsp & servlets и язык java в общем и документацию на PHP. Если вы про фреймворки так они в других языках есть.
Вы говорили о том, что 3000 встроенных функций - это плохо. Скажите, а если бы к вам в дом пришел сантехник и сказал, что у него с собой только молоток, "но им ведь все можно починить"? Я бы предпочел, чтобы у него был обширный набор инструментов.
В остальных языках инструметарий бедный-бедный! У PHP этот инструментарий обширный путанный и часто дублируется. Если я правильно помню одних реализаций работы с PHP есть две. Причем обе включены в дистрибутив. Кроме этого имеется две различных реализации абстракции СУБД ADO и PDO (я думаю что их даже несколько больше, я перечислил те с которыми сталкивался) и эта ситуация повторяется в других функционале PHP. Тут вот уже говорили "Разруха она не в туалетах, а в головах". В PHP не имеет стройной системы это такой бардак куда все лепят, что им нравится.
Под "хорошими специалистами" я понимаю в том числе тех, кого можно обучить. :) А обучить грамотно программировать можно далеко не каждого.
Хорошо, я принимаю все ваши аргументы. Я не склонен сверх меры защищать PHP, во многом он действительно и мне не нравится.
Но объясните, объясните мне пожалуйста, почему на PHP работает более 90% сайтов рунета? Мы все такие идиоты, не видим своего счастья в Джаве? :(
Хорошо, я принимаю все ваши аргументы. Я не склонен сверх меры защищать PHP, во многом он действительно и мне не нравится.
Но объясните, объясните мне пожалуйста, почему на PHP работает более 90% сайтов рунета? Мы все такие идиоты, не видим своего счастья в Джаве? :(
Потому что много, дёшево и доступно. Потому что эти сайты не решают проблемы поддерживаемости и расширяемости. Когда придёт время обновить сайт, они наймут другого дешёвого мальчика, и он сделает всё заново. Это вполне корректная бизнес-модель, throw-away programming.
Проблемы начинаются тогда, когда те же мальчики начинают писать большие системы, используя те же повадки.
Проблемы начинаются тогда, когда те же мальчики начинают писать большие системы, используя те же повадки.
НЛО прилетело и опубликовало эту надпись здесь
Под "хорошими специалистами" я понимаю в том числе тех, кого можно обучить. :) А обучить грамотно программировать можно далеко не каждого.
Понятное дело что далеко не каждого. Да и стоит ли обучать только PHP?
Но объясните, объясните мне пожалуйста, почему на PHP работает более 90% сайтов рунета?
А откуда у вас такие цифры?
Я не склонен сверх меры защищать PHP, во многом он действительно и мне не нравится.
Ну постепенно количество профессионалов пишущих на PHP увеличивается и он потихоньку начинает перерастать студенческую поделку. Так что надо просто подождать.
Мы все такие идиоты, не видим своего счастья в Джаве? :(
У PHP более низкий порог вхождения. Чем проще и доступнее язык тем больше на нем пишут не профессионалы. Хотя я вот считаю чт java сервер поставить проще чем apache и mod_php.
Понятное дело что далеко не каждого. Да и стоит ли обучать только PHP?
Если мне нужен сотрудник для работы над PHP-проектами, я буду обучать его только PHP.
А откуда у вас такие цифры?
Работаю с интернетом с 1998 года. Это называется "репрезентативная выборка". Или проще, "много на своем веку повидал".
А вообще, я устал спорить. Результат и польза нулевые. История нас рассудит. :)
Работаю с интернетом с 1998 года. Это называется "репрезентативная выборка". Или проще, "много на своем веку повидал".
Проще говоря, то что я видел на 90% пишется на PHP. Я могу сделать аналогичное заявление но выборка будет другой. Реальному положению дел оно имеет мало.
Результат и польза нулевые. История нас рассудит. :)
Кому что надо то и использует собственно.
Единственная путаница, которую готов признать - где-то используется "_", где-то нет. Если вы хоть раз сталкивались с perl'ом - такие мелочи не будут являться серьезным препятствием в изучении. Далее давайте подтвержать слова ссылками. ссылку на "свстроенный шаблонизатор" я уже получил, и выяснилось, что никакой он не встроенный.
теперь было приятно получить ссылки:
- на дублирующиеся функции.
- на ADO.
на всякий случай, официальная документация тут.
теперь было приятно получить ссылки:
- на дублирующиеся функции.
- на ADO.
на всякий случай, официальная документация тут.
Единственная путаница, которую готов признать - где-то используется "_", где-то нет. Если вы хоть раз сталкивались с perl'ом - такие мелочи не будут являться серьезным препятствием в изучении.
Еще периодически глаголы и существительные в функциях меняются местами :) Т.е. do_this this_do. Причем часть функций в такой нотации написаны часть в другой.
Далее давайте подтвержать слова ссылками. ссылку на "свстроенный шаблонизатор" я уже получил, и
выяснилось, что никакой он не встроенный.
У нас разные понятия о встроенный и невстроенный. У меня встроенный это то что включается в дистрибутив самими разработчиками. У вас же все что можно отключить в дистрибутиве. Давайте тогда определимся, что есть встроенный что нет.
теперь было приятно получить ссылки:
- на дублирующиеся функции.
функции mysql и mysqli и еще тоже самое через PDO.
Функции для работы с XML. Но в PHP5 уже сделали все же DOM XML. Но в результате сломали совместимость с PHP4.
- на ADO.
Похоже спутал с dba.
на всякий случай, официальная документация тут
Я знаю. Кстати знаете я тут заметил одну вещь. Вы сами что-то редко что-то противопоставляете. Большую часть времени вы говорите, не подкреплено ссылками значит чушь. Может перейдете к более активному диалогу?
Еще периодически глаголы и существительные в функциях меняются местами
возможно где-то встречается, но на вскидку даже не вспомню такого. поэтому скорее всего проблемы как таковой не существует.
У нас разные понятия о встроенный и невстроенный.
по вашему получается, что если ножем можно зарезать человека, то значит такая возможность в него встроена? ;) потому что если есть функция замены подстроки в строке и есть функция считывания файла, то то что вы называли "встроенный шаблонизатор" есть в любом языке :)
функции mysql и mysqli и еще тоже самое через PDO.
а еще есть ODBC - вас это не смущает? то, что реализует разный _подход_ сложно считать дублированием функционала.
Функции для работы с XML. Но в PHP5 уже сделали все же DOM XML. Но в результате сломали совместимость с PHP4.
для версии 4 используется расширение DOM XML, для 5 DOM. Два разных подхода. где, что сломали? И вообще, использовать DOM для каких-то серьезных объемов обрабатываемой информации - самоубийство, поскольку объем памяти, необходимой для обработки, растет такими темпами... например обработка относительно не большого документа 5.5М требует порядка 115М оперативки. use SAX и будет щастье :)
Вы сами что-то редко что-то противопоставляете. Большую часть времени вы говорите, не подкреплено ссылками
спрашивайте, если что-то нужно подкрепить ссылкой, постараюсь найти, если она существует. пока не было такой необходимости.
возможно где-то встречается, но на вскидку даже не вспомню такого. поэтому скорее всего проблемы как таковой не существует.
Есть там такое просто там нотация хотя бы в пределах одного функционала одна. Это скажем не страшно, а просто немного не приятно.
по вашему получается, что если ножем можно зарезать человека, то значит такая возможность в него встроена? ;)
Помоему в дистрибутив все же не должны входить сторонние расширения :) А в PHP они как-то входят :)
потому что если есть функция замены подстроки в строке и есть функция считывания файла, то то что вы называли "встроенный шаблонизатор" есть в любом языке :)
В PHP есть дополнительные средства для работы с этим "шаблонизатором", в других языках их еще прийдется добавить.
для версии 4 используется расширение DOM XML, для 5 DOM. Два разных подхода. где, что сломали?
А что совместимость не сломали? То есть приложение написаное под DOM XML будет хорошо работать под DOM? Что-то не припомню такого :)
И вообще, использовать DOM для каких-то серьезных объемов обрабатываемой информации - самоубийство, поскольку объем памяти, необходимой для обработки, растет такими темпами... например обработка относительно не большого документа 5.5М требует порядка 115М оперативки.
Ну java его довольно активно используют и ничего.
use SAX и будет щастье :)
Если я правильно помню, что это такое, то что-то меня его подход не впечатлил. Хотя может это мои личные тараканы.
спрашивайте, если что-то нужно подкрепить ссылкой, постараюсь найти, если она существует. пока не было такой необходимости.
Учту.
Помоему в дистрибутив все же не должны входить сторонние расширения
у РНР нет "единого" разработчика. поэтому расширения поддерживаются различными людьми. думаю любому разработчику очень удобно когда решение "из коробки" умеет делать широчайший спектр работ. и я легко включаю нужным мне функционал.
В PHP есть дополнительные средства для работы с этим "шаблонизатором"
вы имеете ввиду функции замены строки или возможность прочитать файл "шаблона"? или по вашему это (Listing 2) много лучше?
А что совместимость не сломали? То есть приложение написаное под DOM XML будет хорошо работать под DOM?
для версии 4 используйте расширение DOM XML, а не DOM - все должно работать. и потом, обратная совместимость - это палка о двух концах. часто нужно принять кардинальные изменения. и это правильно.
Ну java его довольно активно используют и ничего
я разве сказал, что в РНР нельзя? я лишь отметил, что использование DOM ведет к неразумным расходам памяти. и это не зависит от языка.
у РНР нет "единого" разработчика. поэтому расширения поддерживаются различными
людьми.
А "единая" идеология?
думаю любому разработчику очень удобно когда решение "из коробки" умеет делать широчайший спектр работ. и я легко включаю нужным мне функционал.
Удобно. Но иногда мне приходилось пересобирать PHP или что-то добавлять поскольку у разработчика была отличный от моего PHP функционал.
вы имеете ввиду функции замены строки или возможность прочитать файл "шаблона"? или по вашему это (Listing 2) много лучше?
Из файла. Ну если брать JSP и использовать его на манер PHP то ничем не лучше.
для версии 4 используйте расширение DOM XML, а не DOM - все должно работать. и потом, обратная совместимость - это палка о двух концах. часто нужно принять кардинальные изменения. и это правильно.
Да DOM правильнее DOM XML. Но если бы они вынесли DOM XML к примеру в тот же PECL или объявили его DEPRECATED, а удалили бы в версии 6 было было бы логичнее. Но это из разряда в огороде бузина в киеве дядька.
я лишь отметил, что использование DOM ведет к неразумным расходам памяти. и это не зависит от языка.
Есть такое. Но в некоторых случаях он удобен.
А "единая" идеология?
и единая идеалогия. если интересно - подпишитесь на листы рассылок
Но иногда мне приходилось пересобирать PHP
собирайте расширения и подключайте их. если вы хотите и функционал получить и ничего не делать ручками - может стоит задуматься о смене рода деятельности ;)
Из файла.
а есть популярные языки, в которых отсутствует чтение из файла?? я таких не знаю. а если есть возможность прочитать и сделать замены в строке, то ничего не мешает реализовать такой "встроенный" шаблонизатор на любом языке.
Но если бы они вынесли DOM XML к примеру в тот же PECL или объявили его DEPRECATED
скажите, а вы смотрите те ссылки, что я даю? зачем вы просили их активно использовать, если все равно их не смотрите? DOM XML.
а удалили бы в версии 6 было было бы логичнее
а как же обратная совместимость, за которую вы так ратуете постами выше?
и единая идеалогия. если интересно - подпишитесь на листы рассылок
В стадии разработки ? :))
собирайте расширения и подключайте их. если вы хотите и функционал получить и ничего не делать ручками - может стоит задуматься о смене рода деятельности ;)
Хочу как в java :))) Все в одном пакете :)
а есть популярные языки, в которых отсутствует чтение из файла?? я таких не знаю. а если есть возможность прочитать и сделать замены в строке, то ничего не мешает реализовать такой "встроенный" шаблонизатор на любом языке.
Вообще речь шла о том что он там уже есть. То что реализовать то не проблема это понятно.
скажите, а вы смотрите те ссылки, что я даю? зачем вы просили их активно использовать, если все равно их не смотрите? DOM XML.
Эт я проглядел. Но то что это есть в PECL уже заметно лучше.
а как же обратная совместимость, за которую вы так ратуете постами выше?
Я говорил про совместимость от версии к версии. Т.е. если имеем версию 4 и версию 5, то в 5 версии все что планируется снести помечаются как deprecated, а в 6 версии удаляются. Разумный надеюсь баланс между совместимостью и новшествами?
В стадии разработки
если вы считаете что идеалогия для языка - это что-то костное, никогда не меняющееся, то глубоко заблуждаетесь. другое дело, что дать прямую ссылку на страницу, где будет расписана "идеалогия разработки" я затрудняюсь. но если вам интересно, то без труда сможите определить ее читая листы рассылки. в общих чертах для 6 версии заявлена полная поддержка юникода.
Хочу как в java
так пользуйтес java, получайте тяжелые приложения, которые можно использовать только для внутрикорпортативных разработок :) и не надо утверждать, что РНР использует "не правильную" концепцию ;)
Вообще речь шла о том что он там уже есть. То что реализовать то не проблема это понятно.
еще раз - такой подход "есть" в любом языке, в котором есть возможность прочитать файл и использовать функцию замены.
Я говорил про совместимость от версии к версии. Т.е. если имеем версию 4 и версию 5, то в 5 версии все что планируется снести помечаются как deprecated, а в 6 версии удаляются. Разумный надеюсь баланс между совместимостью и новшествами?
не разумный. снести и оставить расширение в PECL - две большие разницы. есть еще достаточно много приложений, написанных еще под 3ю версию. и они вполне выполняют возложенные на них задачи. где мы будем брать расширения под старые версии? или наоборот, вот есть расширение mnoGoSearch - оно вполне себе работает у меня под 5.2, хотя оно давно вынесено в PECL.
если вы считаете что идеалогия для языка - это что-то костное, никогда не меняющееся, то глубоко заблуждаетесь. другое дело, что дать прямую ссылку на страницу, где будет расписана "идеалогия разработки" я затрудняюсь. но если вам интересно, то без труда сможите определить ее читая листы рассылки. в общих чертах для 6 версии заявлена полная поддержка юникода.
То что оно костное я и не говорю. Про поддержку уникода я в курсе. Вот как 6 версия выйдет, так посмотрю, что у них там получилось. 5 версия таки лучше 4 версии.
так пользуйтес java, получайте тяжелые приложения, которые можно использовать только для внутрикорпортативных разработок :) и не надо утверждать, что РНР использует "не правильную" концепцию ;)
Использую. PHP использует ту концепцию которую они считают правильной. А она уже может нравиться или не нравиться.
еще раз - такой подход "есть" в любом языке, в котором есть возможность прочитать файл и использовать функцию замены.
А зачем тогда они говорят, что это шаблонизатор ? :)
не разумный. снести и оставить расширение в PECL - две большие разницы. есть еще достаточно много приложений, написанных еще под 3ю версию. и они вполне выполняют возложенные на них задачи. где мы будем брать расширения под старые версии? или наоборот, вот есть расширение mnoGoSearch - оно вполне себе работает у меня под 5.2, хотя оно давно вынесено в PECL.
Для кого как. Просто если функции не помечать как "устаревшие" никто с них переходить не будет.
А зачем тогда они говорят, что это шаблонизатор ?
в который раз хочется конкретики - кто "они", и про что говорят "шаблонизатор"? :)
Просто если функции не помечать как "устаревшие" никто с них переходить не будет.
согласитесть, "устаревший" и "deprecated" различные понятия. deprecated должно помечаться то, что противоречит существующей концепции языка. поверьте (ну или сделайте поиск по слову deprecated по php.net), функции и подходы, которые действительно "мешаются" именно так и помечаются.
в который раз хочется конкретики - кто "они", и про что говорят "шаблонизатор"? :)
Я про tpl шаблоны.
согласитесть, "устаревший" и "deprecated" различные понятия. deprecated должно помечаться то, что противоречит существующей концепции языка. поверьте (ну или сделайте поиск по слову deprecated по php.net), функции и подходы, которые действительно "мешаются" именно так и помечаются.
Так оно. Вопрос в том как они это определяют :)
Как это умерли RISC процессоры?
PPC, Niagara, Cell.
Другой вопрос в том, что они не совсем RISC процессоры, но очень близки к этому.
Поправьте меня, если я не прав.
PPC, Niagara, Cell.
Другой вопрос в том, что они не совсем RISC процессоры, но очень близки к этому.
Поправьте меня, если я не прав.
Вы говорили о том, что 3000 встроенных функций - это плохо.
Это говорил я, я и отвечу. Не утверждалось, что 3000 плохо. Утверждалось, что плохо, что они встроены. Я бы предпочёл, чтобы сантехник принёс то, что нужно для смены труб, а не для укладки кафеля, равняния паркета, штукатурки стен, вставки окон, а также всего, что может понадобиться впредь. Что php опен-сорс все сознают и не отрицают, и противопоставляют ему столь же опенсорсные скриптовые языки.
По поводу смерти RISC процессоров ваша информация ложна. Википедия: "Today, the ARM family accounts for over 75% of all 32-bit embedded CPUs, making it one of the most prolific 32-bit architectures in the world." Если они умерли, то в моём свитче, холодильнике и в стиральной машине сейчас зомби :)
Я уточню свою позицию. Для разработки в большой компании, или для менеджеров, которым нужен многочисленный недорогой персонал, ПХП может и неплох. Он плох для тех, кто пытается поддерживать и развивать написанное.
Вы же сами сказал, что пхписты ломятся толпами, а это значит, что средний уровень как программистов их ниже, потому что для освоения ruby, скажем, нужно приложить больше усилий, потому что не так распиарено да и вообще сложнее. Плохие программисты создают плохой код. Только и всего.
НЛО прилетело и опубликовало эту надпись здесь
А я был бы рад, если бы сантехник все перечисленное с собой тоже принес. А то вдруг мне одну плитку кафеля надо заменить, не вызывать же его еще раз. ;)
ARM, чтоб вы знали, это не чистые RISC-процессоры, как бы им этого ни хотелось. Да и программ под них пишут очень мало. Напишут ПО для холодильника - и наштампуют 10 миллионов. А у нас здесь специфика другая. Проекты индивидуальные.
ПХП не плох для тех, кому нужно поддерживать и развивать. Мы у себя в студии пользуемся Symfony, и нам хорошо. Мы поддерживаем и развиваем.
ПХПисты ломятся толпами, значит из них можно выбрать вменяемых.
ARM, чтоб вы знали, это не чистые RISC-процессоры, как бы им этого ни хотелось. Да и программ под них пишут очень мало. Напишут ПО для холодильника - и наштампуют 10 миллионов. А у нас здесь специфика другая. Проекты индивидуальные.
ПХП не плох для тех, кому нужно поддерживать и развивать. Мы у себя в студии пользуемся Symfony, и нам хорошо. Мы поддерживаем и развиваем.
ПХПисты ломятся толпами, значит из них можно выбрать вменяемых.
ARM, чтоб вы знали, это не чистые RISC-процессоры, как бы им этого ни хотелось. Да и программ под них пишут очень мало. Напишут ПО для холодильника - и наштампуют 10 миллионов. А у нас здесь специфика другая.
Система RISC команд более эффективна чем CISC и текущие процессоры при выполнении дробят эти команды на подобие системы команд RISC и выполняют уже их. К тому же под ARM пишут мнооого программ. Практически все процессоры в КПК, телефонах, смартфона имеют RISC архитектуру. CISC архитектура прижилась более менее только в мире PC :)
Что творится у процессора внутри - уже не наше дело. :)
Факт остается фактом: если вы будете программировать чистые RISC-процессоры, вы быстро сойдете с ума, и мы вас больше никогда не увидим. К сожалению.
Вообще, это уже оффтоп. К чему этот спор? Иллюстрация про сантехника более наглядна. :)
Факт остается фактом: если вы будете программировать чистые RISC-процессоры, вы быстро сойдете с ума, и мы вас больше никогда не увидим. К сожалению.
Вообще, это уже оффтоп. К чему этот спор? Иллюстрация про сантехника более наглядна. :)
Что творится у процессора внутри - уже не наше дело. :)
Я собственно про смерть RISC.
Факт остается фактом: если вы будете программировать чистые RISC-процессоры, вы быстро сойдете с ума, и мы вас больше никогда не увидим. К сожалению.
Тоже самое можно сказать и про программирование CISC и про разработчиков компиляторов. Но что-то они все явно не в психушках, а вполне здравствуют :)
Иллюстрация про сантехника более наглядна. :)
У сантехника PHP имеется одна большая сумка со всеми инструментами. У сантехника Java и других языков использующих понятие пакетов, Большой сундук с выдвижными ящиками :)
опа... чесно говоря думал что вы-то в курсе. рекомендую ман. ссылка была выше. внимательно читаем, и о чудо! видим что чтобы получить весь набор фнкцций нам то придется ручками поработать - скомпилировать нужные расширения, ну или хотя бы в ини-файле их включить.
зы. в предыдущей дискуссии вы как раз сетовали на то, что много нужного находится в PEAR. доктор, вы уж определитесь ;)
зы. в предыдущей дискуссии вы как раз сетовали на то, что много нужного находится в PEAR. доктор, вы уж определитесь ;)
и о чудо! видим что чтобы получить весь набор фнкцций нам то придется ручками поработать - скомпилировать нужные расширения, ну или хотя бы в ини-файле их включить.
Для скольки из? У PHP по сравнению с Java коробка с выдвижными ящиками есть. Но инструменты просто досыпаются в огромную сумку с инструментами.
в предыдущей дискуссии вы как раз сетовали на то, что много нужного находится в PEAR. доктор, вы уж определитесь ;)
В дистрибутив PHP входит слишком много всего. Было бы лучше если бы был небольшой дистрибутив только с основными функциями которые требуются для работы. Все остальное же цеплялось через PECL и PEAR. На данный же момент имеем несколько другую ситуацию, в основной дистрибутив напихано дофига всего-всего.
мне кажется, что вы все таки не посмотрели ман. ну ладно, ваше право.
тогда я кратенько, для ленивых ;) если мне нужен функционал для работы с (например) фтп, то я подключаю в ини-файле необходимое расширение. до этого момента у меня НЕТ этого функционала. понимаете?
То что они входят в дистрибутив и легко могут быть скомпилированы и подключены - это как раз большой плюс. а 9М в архиве в современном интернете уже давно никого не напрягает.
PECL это не лучшее место для распространения, у него несколько другие цели. PEAR - вообще тут не при чем, там обраны модули, написанные на самом РНР. и у PEAR своих проблем хватает.
тогда я кратенько, для ленивых ;) если мне нужен функционал для работы с (например) фтп, то я подключаю в ини-файле необходимое расширение. до этого момента у меня НЕТ этого функционала. понимаете?
То что они входят в дистрибутив и легко могут быть скомпилированы и подключены - это как раз большой плюс. а 9М в архиве в современном интернете уже давно никого не напрягает.
PECL это не лучшее место для распространения, у него несколько другие цели. PEAR - вообще тут не при чем, там обраны модули, написанные на самом РНР. и у PEAR своих проблем хватает.
тогда я кратенько, для ленивых ;) если мне нужен функционал для работы с (например) фтп, то я подключаю в ини-файле необходимое расширение. до этого момента у меня НЕТ этого функционала. понимаете?
Про это я в курcе. Но это надо специально компилировать все в подключаемые библиотеки. Хотя я вот сейчас посмотрел в Gentoo таки начали собирать расширения модулями. Но по умолчанию PHP грузит все модули которые имеются. И к тому же если мне надо будет добавить модулей прийдется пересобирать PHP. Хотя это возможно заморочки этого конкретного дистрибутива. И в скором времени можно будет собирать отдельными модулями.
То что они входят в дистрибутив и легко могут быть скомпилированы и подключены - это как раз большой плюс. а 9М в архиве в современном интернете уже давно никого не напрягает.
Ну могу привести пример противоположный пример. X-Window систему X.org наоборот раздробил на большое число мелких пакетов. И как показывает практика это правильно. К тому же раз у PHP есть возможность загружать расширения в виде библиотек, то почему все сторонние библиотеки не вынести в отдельные расширения? А то как-то странно дистрибутив готовят разработчики, но при этом в дистрибутив добавляются сторонние модули, поддержкой которых разработчики не занимаются.
PECL это не лучшее место для распространения, у него несколько другие цели.
С сайта PECL:
PECL is a repository for PHP Extensions, providing a directory of all known extensions and hosting facilities for downloading and development of PHP extensions.
Написано, что репозиторий. Чем оно плохо, то что компилировать надо под каждую платформу?
PEAR - вообще тут не при чем, там обраны модули, написанные на самом РНР.
Это понятно. Мне собственно в PHP не нравится отсутствие стройности и логичности. Ну а выдавать это за гибкость право не стоит.
Но это надо специально компилировать все в подключаемые библиотеки.
вам шашечки или ехать? ;) то вам не нравится, что все "в кучее", то не нравится что есть возможность собрать то, что необходимо. собрать именно то, что нужно - это нормальная практика в *nix системах, не находите?
Но по умолчанию PHP грузит все модули которые имеются
далеко не все. например в 5.2.0 фактически единственный модуль, который "вкомпиливается" libxml. при этом никто не мешает перед установкой сделать ./configure и указать свой набор модулей. либо собрать как расширение и включать через ini-файл.
если мне надо будет добавить модулей прийдется пересобирать PHP.
не придется. собираете модуль и подключаете через ини-файл.
почему все сторонние библиотеки не вынести в отдельные расширения
именно так и сделано. при этом оставлена возможность вкомпилить при сборке. все малопопулярные расирения регулярно убираются в PECL.
дистрибутив готовят разработчики, но при этом в дистрибутив добавляются сторонние модули, поддержкой которых разработчики не занимаются.
не вижу тут никакого противоречия. многие расширения основываются на сторонних библиотеках. некоторые не могут быть вкомпилены исходя из лицензии. потом РНР не принадлежит кому-то конкретно, поэтому разные расширения поддерживаются различными людьми.
Написано, что репозиторий. Чем оно плохо
в дистрибутив включены наиболее популярные расширения. в PECL вынесены экспериментальные расширения и малопопулярные. хотя тут я могу ошибаться - это мое понимание смысла PECL.
Мне собственно в PHP не нравится отсутствие стройности и логичности.
вот мы с вами второй раз обсуждаем РНР. и второй раз вы говорите об отсутствии стройности и логичности. и до сих пор никаких существенных аргументов не приводите. для меня все выглядит стройно и логично. для вас нет. скорее всего это не "проблема" языка, а субъективное восприятие. которое связано с тем, что не существует единственно правильного подхода. и если вы это примите, то все встанет на свои места.
вам шашечки или ехать? ;) то вам не нравится, что все "в кучее", то не нравится что есть возможность собрать то, что необходимо. собрать именно то, что нужно - это нормальная практика в *nix системах, не находите?
А помоему вы что-то не допонимаете. Компиляция ведется из общей большой кучи. Меня устраивает, что есть возможность, что-то отключить. Мне не нравится то что туда пихают сторонние модули. Если это сторонние модули, то почему они в дистрибутиве?
далеко не все. например в 5.2.0 фактически единственный модуль, который "вкомпиливается" libxml. при этом никто не мешает перед установкой сделать ./configure и указать свой набор модулей. либо собрать как расширение и включать через ini-файл.
Мне вот кажется, что модули все же одним способом должны подключаться, а не двумя-тремя или четырьмя. А тут можно вкомпилить, можно не вкомплить, можно взять из PECL.
не придется. собираете модуль и подключаете через ини-файл.
Хорошо ткните в ссылку которая рассказывает как собрать модуль идущий в дистрибутиве PHP и при этом не пересобирая его.
именно так и сделано. при этом оставлена возможность вкомпилить при сборке. все малопопулярные расирения регулярно убираются в PECL.
Если бы все расширения соответствовали PECL и ставились из него я бы согласился, что действительно все сделано хорошо и корректно. Но на данный момент ведь это не так?
не вижу тут никакого противоречия. многие расширения основываются на сторонних библиотеках. некоторые не могут быть вкомпилены исходя из лицензии. потом РНР не принадлежит кому-то конкретно, поэтому разные расширения поддерживаются различными людьми.
Я вот вижу. Во первых получается разброд и шатание с тем откуда и как берутся модули. Давайте сравним с Perl. Там есть базовый набор функций + CPAN. Все стройно и логично. В PHP почему-то во первых есть сторонние модули в дистрибутиве и аж два репозитария PECL и PEAR. В чем логика? Я не думаю, что это диктуется гибкостью, это скорее диктуется тем, что разработчики PHP включают все, что не попадя в PHP и не имеют четкого видения, что в нем должно быть, а чего не должно быть.
в дистрибутив включены наиболее популярные расширения. в PECL вынесены экспериментальные расширения и малопопулярные. хотя тут я могу ошибаться - это мое понимание смысла PECL.
В таком виде вообще не понятно зачем оно нужно :)
вот мы с вами второй раз обсуждаем РНР. и второй раз вы говорите об отсутствии стройности и логичности. и до сих пор никаких существенных аргументов не приводите. для меня все выглядит стройно и логично. для вас нет. скорее всего это не "проблема" языка, а субъективное восприятие. которое связано с тем, что не существует единственно правильного подхода. и если вы это примите, то все встанет на свои места.
Наличие трех различных способов подключения к MySQL это логично? Причем два их них входят в дистрибутив. А третьий PDO подключается, через PECL который судя по вашим словам не является популярным. С моей точки зрения нелогичность PHP возникает из того, что он пишется большим количеством людей без каких либо четких соглашений, на то как оно должно выглядеть. В результате получаем лоскутное одеяло, из большого числа модулей, которые часто имеют разную стилистику и нотацию. Кстати до разработчиков уже дошло, что если они продолжат в таком духе, то PHP просто развалится как башня из кубиков.
Ваша неграмотность в PHP надоела...
Может покажете свою грамотность и заодно расскажете, что в моих доводов неграмотного?
Еще чего, время на тебя тратить. Иди PHP учи.
Тогда не делайте не обоснованных заявлений. Если вам не нравится, то что я пишу про PHP, то это ваши проблемы. А пока вы не подкрепили мою "неграмотность" фактами. То что я неграмотен в PHP бред.
У тебя каша в голове, пиар сравнял с пеклом, pdo в пекл отправил. Наверно нахватался с чем пришлось связаться.
Далее. Сколько бы не находил в PHP отрицательного факт остается фактом: мои поделки более нужны если они написаны на PHP нежели на Ruby или Java. Как у PHP организованы репозитории модулей, сколько способов подключения к бд пользователей вообще не ипет.
Не можешь пользоваться молотком у которого "ручка скользкая, и наконечник разбалансирован", делай однотипную скучную работу, что сверху накапает :)
ps: обратись к президенту с требованием запретить PHP, бо деградацию вызывает, я тебя поддержу.
Далее. Сколько бы не находил в PHP отрицательного факт остается фактом: мои поделки более нужны если они написаны на PHP нежели на Ruby или Java. Как у PHP организованы репозитории модулей, сколько способов подключения к бд пользователей вообще не ипет.
Не можешь пользоваться молотком у которого "ручка скользкая, и наконечник разбалансирован", делай однотипную скучную работу, что сверху накапает :)
ps: обратись к президенту с требованием запретить PHP, бо деградацию вызывает, я тебя поддержу.
У тебя каша в голове, пиар сравнял с пеклом, pdo в пекл отправил. Наверно нахватался с чем пришлось связаться.
И то и то репозиторий. Их вместе я не смешиваю. Это разные вещи. Но было бы удобнее иметь один репозиторий. К тому же pdo в свое время было в PECL если мне память не изменяет. И появился в самом PHP только с версии 5.1.
Далее. Сколько бы не находил в PHP отрицательного факт остается фактом: мои поделки более нужны если они написаны на PHP нежели на Ruby или Java.
Флаг вам в руки. Я что мешаю вам их делать? Я и сам иногда пишу небольшие поделки на PHP если надо. От того что на нем пишет много народу он лучше чтоли стал?
Как у PHP организованы репозитории модулей, сколько способов подключения к бд пользователей вообще не ипет.
Вот это уже зависит от объемов и то что надо сделать. Давайте представим, что вы написали приложение на PHP и используете там только MySQL. А потом по прошествию времени вам потребовалось завести все тоже самое на PostgreSQL. В случае если есть единый слой абстракции СУБД, то это проблем не составляет, подкорректировали строку подключения и все. Понятное дело, что можно просто использовать PDO и не ломать себе голову. Но миллионы лемингов его не используют :)
Не можешь пользоваться молотком у которого "ручка скользкая, и наконечник разбалансирован", делай однотипную скучную работу, что сверху накапает :)
Да я как от того что не пишу много PHP от однотипной и скучной работы не страдаю.
Если это сторонние модули, то почему они в дистрибутиве?
давйте представим, что расширение mysql для РНР отсутствует. вы решили, что такое расширение просто жизненно необходимо для языка. вы его написали, закоммитили, расширение попадает в PECL, далее все понимают, что расширение оказылось крайне полезным для большинства разработчиков. оно включается в дистрибутив. я ответил на вопрос?
Мне вот кажется, что модули все же одним способом должны подключаться
вам кажется не правильно. язык может быть использован в большом проекте, работать на сервере, на который возложена обработка сообщений пользователей. с xml такой скрипт не работает. понятно, что собирать нужно без этого модуля. смотрим другую ситуацию - у нас есть виртуальный хостинг. большинству клиентов xml также не нужен. зачем собирать ядро с поддержкой языка? мы включаем расширение для конкретного хоста, при этом большинство клиентов не ждут пересборки ядра. это вопрос гибкости в настройках.
Хорошо ткните в ссылку которая рассказывает как собрать модуль идущий в дистрибутиве PHP и при этом не пересобирая его.
легко
Если бы все расширения соответствовали PECL и ставились из него я бы согласился, что действительно все сделано хорошо и корректно. Но на данный момент ведь это не так?
вы можете найти все расширения, в том числе те, которые включены в дистрибутив, в PECL. при этом в дистрибутив не включены расширения, которые малопопулярны, либо имеют статус "экспериментальный".
Во первых получается разброд и шатание с тем откуда и как берутся модули.
вот если разобраться что же такое PECL - все встанет на свои места. надеюсь то что написано выше в этом посте поможет этому.
и аж два репозитария PECL и PEAR.
да, в одном (PECL) расширения, написанные на С и которые необходимо собирать, в другом - написанные на самом РНР (PEAR). это очень логично и не вносит никакой путаницы.
Наличие трех различных способов подключения к MySQL это логично?
на мой взгляд - очень логично. поскольку позволяет элегантно сохранить обратную совместимость с большим количеством программ, разработанных ранее (расширение mysql). при этом мы получаем возможность работать через объектную модель ноступа (mysqli), либо через универсальный драйвер (pdo). при правильной организации архитектуры приложения вообще без разницы какой драйвер бутет использован.
Причем два их них входят в дистрибутив.
в дистрибутив входят все три.
он пишется большим количеством людей без каких либо четких соглашений
на сколько я понимаю - отсутствие соглашений это ваше личное предположение? или вы где-то это прочитали?
давйте представим, что расширение mysql для РНР отсутствует. вы решили, что такое расширение просто жизненно необходимо для языка. вы его написали, закоммитили, расширение попадает в PECL, далее все понимают, что расширение оказылось крайне полезным для большинства разработчиков. оно включается в дистрибутив. я ответил на вопрос?
Если его поддерживают сами разработчики PHP и они считают, что оно должно входить в базовый пакет языка флаг им в руки. Или там все сторонние модули поддерживаются разработчиками PHP ? :)
вам кажется не правильно. язык может быть использован в большом проекте, работать на сервере, на который возложена обработка сообщений пользователей. с xml такой скрипт не работает. понятно, что собирать нужно без этого модуля. смотрим другую ситуацию - у нас есть виртуальный хостинг. большинству клиентов xml также не нужен. зачем собирать ядро с поддержкой языка? мы включаем расширение для конкретного хоста, при этом большинство клиентов не ждут пересборки ядра. это вопрос гибкости в настройках.
Я говорил про унификацию модулей. Зачем пихать в ядро поддержку xml я не знаю. Все же логичнее было бы запихать ее в отдельный модуль.
легко
Это компиляция расширений PECL. А я говорил, про те что входят в дистрибутив PHP. Каким образом мне собрать расширение оттуда?
вы можете найти все расширения, в том числе те, которые включены в дистрибутив, в PECL. при этом в дистрибутив не включены расширения, которые малопопулярны, либо имеют статус "экспериментальный".
Хорошо они там есть. Но вот сейчас я проверил, на одной из машин где установлен PHP и пара пакетов из pecl. И к сожалению в списках pecl установленных расширений я не увидел.
вот если разобраться что же такое PECL - все встанет на свои места. надеюсь то что написано выше в этом посте поможет этому.
Pecl - менеджер используемый для установки/обновления/удаления расширений PHP написанных на C. Надеюсь показывает, что понимаю что это такое?
да, в одном (PECL) расширения, написанные на С и которые необходимо собирать, в другом - написанные на самом РНР (PEAR). это очень логично и не вносит никакой путаницы.
Ну как вам сказать. Не очень это логично.
на мой взгляд - очень логично. поскольку позволяет элегантно сохранить обратную совместимость с большим количеством программ, разработанных ранее (расширение mysql). при этом мы получаем возможность работать через объектную модель ноступа (mysqli), либо через универсальный драйвер (pdo). при правильной организации архитектуры приложения вообще без разницы какой драйвер бутет использован.
Тогда почему-бы не убрать все расширения типа mysql и mysqli в PECL? Им там IMHO самое место.
в дистрибутив входят все три.
Ну а какой смысл поддерживать три реализации?
на сколько я понимаю - отсутствие соглашений это ваше личное предположение? или вы где-то это прочитали?
Личное предположение. Если покажете мне соглашение, что можно, что нельзя я с удовольствием почитаю. Может тогда хоть станет понятно, почему и зачем делают так а не эдак в PHP.
Если его поддерживают сами разработчики PHP и они считают, что оно должно входить в базовый пакет языка флаг им в руки. Или там все сторонние модули поддерживаются разработчиками PHP
мне кажется вы так и не понимаете принципов заложенных в расширения. расширение - это то, что нет необходимости включать в ядро языка, поскольку оно может кому-то не потребоваться. часто - расширение является враппером для какой-то библиотеки (например, теже расширения для БД). или просто реализует неких функционал (например, функции работы с фтп). и еще - что вы подразумеваете под "разработчиками РНР"? есть компания Zend, которая разрабатывает движок, есть комунити, которое разрабатывает расширения, делает сборки. вы о ком говорите?
Зачем пихать в ядро поддержку xml я не знаю. Все же логичнее было бы запихать ее в отдельный модуль.
так оно и есть в отдельном модуле.
Это компиляция расширений PECL. А я говорил, про те что входят в дистрибутив PHP. Каким образом мне собрать расширение оттуда?
а чем расширение PECL, отличается от того, что есть в дистрибутиве? (кроме того, что PECL содержит последние исходники расширений).
Но вот сейчас я проверил, на одной из машин где установлен PHP и пара пакетов из pecl. И к сожалению в списках pecl установленных расширений я не увидел.
это какие расширения? может они и в дистрибутив не входят? ;)
Pecl - менеджер используемый для установки/обновления/удаления расширений PHP написанных на C.
Ну как вам сказать. Не очень это логично.
не находите, что сами себе противоречите, либо не понимаете разницы между PECL и PEAR. смотрите сообщение
Тогда почему-бы не убрать все расширения типа mysql и mysqli в PECL
хотя бы по этому.
Ну а какой смысл поддерживать три реализации?
для того чтобы:
- не иметь проблем с обратной совместимостью
- предоставить разработчику тот инструмент, который нужен ему, а не тот, который хочется абстрактным разработчикам языка
какие доводы есть против такого подхода?
Если покажете мне соглашение, что можно, что нельзя я с удовольствием почитаю.
я уже давал ссылки на листы рассылки. если подпишитесь то увидите обсуждения тех или иных изменений.
мне кажется вы так и не понимаете принципов заложенных в расширения. расширение - это то, что нет необходимости включать в ядро языка, поскольку оно может кому-то не потребоваться. часто - расширение является враппером для какой-то библиотеки (например, теже расширения для БД). или просто реализует неких функционал (например, функции работы с фтп).
В этом случае должен быть единый интерфейс для расширений не так ли?
и еще - что вы подразумеваете под "разработчиками РНР"? есть компания Zend, которая разрабатывает движок, есть комунити, которое разрабатывает расширения, делает сборки. вы о ком говорите?
Компанию Zend в таком случае.
так оно и есть в отдельном модуле.
Ну я почему-то понял что в ядре.
а чем расширение PECL, отличается от того, что есть в дистрибутиве? (кроме того, что PECL содержит последние исходники расширений).
К примеру тем, что они не фигурируют в базе pecl вообще. Если бы PHP было выполнено как базовое ядро + PECL + установленные через него расширения , то было бы несколько удобнее. А то получается, что при установке расширений с дистрибутивом, а потом при дальнейшей установке PECL они не отображаются в его списке. Как-то немного не логично.
это какие расширения? может они и в дистрибутив не входят? ;)
Ни одного из расширений которые есть в дистрибутиве в списке PECL нет.
не находите, что сами себе противоречите, либо не понимаете разницы между PECL и PEAR.
Разницу я понимаю. Я не понимаю к чему они столько сущностей наплодили :)
хотя бы по этому.
Мало кто пользуется? И мало пакетов? Ну это дело поправимое. Надеюсь все же PHP будет двигаться в направлении выноса всего что не является базовым в репозитарии или будет использовать для установки по умолчанию популярных расширений PECL.
* не иметь проблем с обратной совместимостью
* предоставить разработчику тот инструмент, который нужен ему, а не тот, который хочется абстрактным разработчикам языка
А почему DOM XML вынесли в PECL? Из-за того что мол этим все пользуются, а им не все и те кто им пользуется переключатся на DOM ? Вот это я и называю тянуть одеяло на себя. В одном месте будем совместимыми до упора, а в другом нет.
какие доводы есть против такого подхода?
Довод простой. Поддерживать одну реализацию проще чем три. Надеюсь все же постепенно все перейдут на PDO и проблема отстутствия абстрактного слоя работы с СУБД исчезнет.
я уже давал ссылки на листы рассылки. если подпишитесь то увидите обсуждения тех или иных изменений.
Вы разницу между официальным документом и листом рассылки понимаете? Вот к примеру к ядру Linux есть документ в котором описано какого стиля надо придерживаться если вы хотите, чтобы ваш патч вошел в ядро.
В этом случае должен быть единый интерфейс для расширений не так ли?
самостоятельно пишем С-расширение для РНР.
Компанию Zend в таком случае
компания Zend разрабатывает движок. комунити разрабатыват расширения, делает сборки и выпускает билды. все довольны и счастливы :)
Если бы PHP было выполнено как базовое ядро + PECL + установленные через него расширения , то было бы несколько удобнее.
есть дистрибутив, который включает в себя определенный набор расширений. если вам не хватает чего-то - идете в PECL, скачиваете, ставите. это обычная практика. возмите любую *nix-подобную ОС.
а потом при дальнейшей установке PECL они не отображаются в его списке
в каком списке? вы говорите загадками.
Ни одного из расширений которые есть в дистрибутиве в списке PECL нет.
наверное мы из разных источников берем дистрибутивы...
Разницу я понимаю. Я не понимаю к чему они столько сущностей наплодили
затем, что это разные сущьности.
А почему DOM XML вынесли в PECL?
поэтому
Довод простой. Поддерживать одну реализацию проще чем три.
вы забываете о том, что существует комунити, которое поддерживает те расширения, которые нужны самому комунити.
проблема отстутствия абстрактного слоя работы с СУБД исчезнет.
в грамотно спроектированном приложении такой проблемы не существует. в принципе.
Вы разницу между официальным документом и листом рассылки понимаете? Вот к примеру к ядру Linux есть документ в котором описано какого стиля надо придерживаться если вы хотите, чтобы ваш патч вошел в ядро.
вы не понимаете разницы между "стилем кодирования" и идеалогией развития языка? о чем мы вообще говорим?
есть дистрибутив, который включает в себя определенный набор расширений. если вам не хватает чего-то - идете в PECL, скачиваете, ставите. это обычная практика. возмите любую *nix-подобную ОС.
Есть разные *nix ОС и те что обладают пакетными менеджерами основное ядро все равно держат как пакеты. Это требуется для того чтобы была возможность простого обновления.
в каком списке? вы говорите загадками.
pecl list - показывает установленные расширения. В его списке нет расширений установленных с дистрибутивом.
наверное мы из разных источников берем дистрибутивы...
emerge php
:)
затем, что это разные сущьности.
Да не совсем. Выполняют они одни и те же функции. Только одно в виде бинарных расширений, а второе ввиде скриптовых.
поэтому
Молодцы. А почему тогда по аналогичным причинам не убрать две из трех реализаций mysql?
вы забываете о том, что существует комунити, которое поддерживает те расширения, которые нужны самому комунити.
В таком случае эти расширения должны быть в PECL. Ну не понимаю я такой модели когда в дистрибутив пихают сторонние модули при наличии механизма их установки.
в грамотно спроектированном приложении такой проблемы не существует. в принципе.
Угу она решается одним из блоков абстракции. Но это как раз один из велосипедов :)
вы не понимаете разницы между "стилем кодирования" и идеалогией развития языка? о чем мы вообще говорим?
А что идеология языка и "стиль кодирования" расширений и самого языка вещи не взаимосвязанные?
Есть разные *nix ОС и те что обладают пакетными менеджерами основное ядро все равно держат как пакеты. Это требуется для того чтобы была возможность простого обновления.
это к чему было сказано?
pecl list - показывает установленные расширения
а это что за инструмент? никогда его не использовал.
Выполняют они одни и те же функции.
делить только этому принципу нельзя. надеюсь, как ооп-программисту вам не надо это объяснять.
А почему тогда по аналогичным причинам не убрать две из трех реализаций mysql? В таком случае эти расширения должны быть в PECL.
не должны. потому что в PECL остаются либо малопопулярные, либо експериментальные расширения.
Ну не понимаю я такой модели когда в дистрибутив пихают сторонние модули при наличии механизма их установки.
как же вам тяжело приходится при работе с *nix дистрибутивами...
Угу она решается одним из блоков абстракции. Но это как раз один из велосипедов
это не велосипед. это грамотно спроектированное приложение. в котором зависимость от внешних модулей сводится к минимуму.
А что идеология языка и "стиль кодирования" расширений и самого языка вещи не взаимосвязанные?
связь между ними безусловно существует. но это принципиально разные документы, и у них совершенно разные цели. это все равно что пытаться сравнивать устав предприятия и его внутренние документы.
это к чему было сказано?
К тому что у меня не показываются установленные расширения их базового дистрибутива :)
а это что за инструмент? никогда его не использовал.
эээ... А чем ставите расширения из pecl?
делить только этому принципу нельзя. надеюсь, как ооп-программисту вам не надо это объяснять.
Их существование допустимо только из-за модели PHP.
не должны. потому что в PECL остаются либо малопопулярные, либо експериментальные расширения.
В таком случае не понимаю зачем было делать такое функциональный менеджер.
как же вам тяжело приходится при работе с *nix дистрибутивами...
С чего вы взяли? :) Я предпочитаю модульность большим кускам. Но пока на данный момент в Gentoo PHP идет одним большим куском.
это не велосипед. это грамотно спроектированное приложение. в котором зависимость от внешних модулей сводится к минимуму.
В случае если модуль дает необходимую абстракцию и является стандартным такой слой абстракции можно свести к минимуму. Хороший пример таких слоев это DBI в Perl JDBC в Java, PDO в PHP.
связь между ними безусловно существует. но это принципиально разные документы, и у них совершенно разные цели.
К сожалению для PHP не видел ни того ни другого.
К тому что у меня не показываются установленные расширения их базового дистрибутива. А чем ставите расширения из pecl?
теперь я понимая что жаловаться то надо не на PECL, а на некоторую утилиту, которой вы ставите расширения. я предпочитаю делать ручками (если мы говорим о *nix). ссылку на то, как это рекомендовано делать, я уже давал выше.
есть код для работы с XML.
смотрим и понимаем, что модули имеют вполне конкретные цели.
Их существование допустимо только из-за модели PHP.
не только. и уже не раз говорил об этом. С-расширения имеет смысл делать если имеется тяжелая (ресурсоемкая) операция или мы приходим к системным ограничениям языка (например, нам надо работать с железом или с системой). PEAR - это (в большинстве своем) набор "велосипедов" для конкретных действий, которые нет смысла писать на компилируемых языках. на такой велосипед сел и поехал. однако, сам PEAR не лешен недостатков. например - необходимость поддерживать возможность использования классов и в 4й и 5й версии.
В таком случае не понимаю зачем было делать такое функциональный менеджер.
менеджер? мы говорили о репозитарии...
С чего вы взяли? :) Я предпочитаю модульность большим кускам.
я имел ввиду тот факт, что в дистрибутивы ОС включены различные сторонние модули и приложения ;)
Но пока на данный момент в Gentoo ...
используйте правильные системы, например FreeBSD :D
В случае если модуль дает необходимую абстракцию и является стандартным такой слой абстракции можно свести к минимуму.
вы забываете, что помимо собственно абстрагирования мы получаем свой интерфейс. и этот интерфейс дает нам гарантию того, что изменения во внешнем модуле не приведет к необходимости переписывать приложение с нуля заново.
К сожалению для PHP не видел ни того ни другого.
согласитесь, это не является проблемой языка ;) про идеалогию думаю лучше всего может рассказать подписка на рассылку, расширения - см. выше, я давал ссылку на Zend API
теперь я понимая что жаловаться то надо не на PECL, а на некоторую утилиту, которой вы ставите расширения. я предпочитаю делать ручками (если мы говорим о *nix). ссылку на то, как это рекомендовано делать, я уже давал выше.
Эээ утилита вообще-то штатная :) Если бы она была не штатной я бы вообще молчал :) Вот тут про нее написано
http://ru2.php.net/manual/en/install.pec…
Ручками то понятно что там и какое стоит.
не только. и уже не раз говорил об этом. С-расширения имеет смысл делать если имеется тяжелая (ресурсоемкая) операция или мы приходим к системным ограничениям языка (например, нам надо работать с железом или с системой).
Ну на тяжелых операциях не совсем понятно зачем использовать PHP. Ну ладно могу допустить что иногда надо
PEAR - это (в большинстве своем) набор "велосипедов" для конкретных действий, которые нет смысла писать на компилируемых языках. на такой велосипед сел и поехал. однако, сам PEAR не лешен недостатков. например - необходимость поддерживать возможность использования классов и в 4й и 5й версии.
Ну это то понятно.
смотрим и понимаем, что модули имеют вполне конкретные цели.
Да ? А что функций XML_DTD и XML_Parser чего делают? ;)
я имел ввиду тот факт, что в дистрибутивы ОС включены различные сторонние модули и приложения ;)
Ага включаются, но в виде пакетов.
используйте правильные системы, например FreeBSD :D
Спасибо, но portage намного удобнее ports
вы забываете, что помимо собственно абстрагирования мы получаем свой интерфейс. и этот интерфейс дает нам гарантию того, что изменения во внешнем модуле не приведет к необходимости переписывать приложение с нуля заново.
Никто этого делать не мешает. Иногда даже полезно :)
согласитесь, это не является проблемой языка ;)
И да и нет.
про идеалогию думаю лучше всего может рассказать подписка на рассылку, расширения - см. выше, я давал ссылку на Zend API
Рассылки мало что говорят о иделогии и того как оно там делается.
>утилита вообще-то штатная
у меня оно вообще отказалось работать. если взялись админить *nix сервер, то работайте ручками :) тем более что "ручками то понятно что там и какое стоит".
>Ну на тяжелых операциях не совсем понятно зачем использовать PHP.
смотрите архитектуры больших приложений. например, в одном из топиков вам raa давал ссылку на яху (если мне память не изменяет).
>А что функций XML_DTD и XML_Parser чего делают
эсли вы почитаете наконец описание пакета, то увидите на чем он базируется. этот модуль предоставлет интерфейс.
>Спасибо, но portage намного удобнее ports
ну что, еще одна религиозная война? :D
>Рассылки мало что говорят о иделогии и того как оно там делается.
если это было бы так, я бы не советовал на них подписываться.
у меня оно вообще отказалось работать. если взялись админить *nix сервер, то работайте ручками :) тем более что "ручками то понятно что там и какое стоит".
>Ну на тяжелых операциях не совсем понятно зачем использовать PHP.
смотрите архитектуры больших приложений. например, в одном из топиков вам raa давал ссылку на яху (если мне память не изменяет).
>А что функций XML_DTD и XML_Parser чего делают
эсли вы почитаете наконец описание пакета, то увидите на чем он базируется. этот модуль предоставлет интерфейс.
>Спасибо, но portage намного удобнее ports
ну что, еще одна религиозная война? :D
>Рассылки мало что говорят о иделогии и того как оно там делается.
если это было бы так, я бы не советовал на них подписываться.
у меня оно вообще отказалось работать. если взялись админить *nix сервер, то работайте ручками :) тем более что "ручками то понятно что там и какое стоит".
А у меня работает причем хорошо. Ручками я и так работаю, но софт и пакеты все же правильнее ставить используя специализированные менеджеры, меньше бардака.
смотрите архитектуры больших приложений. например, в одном из топиков вам raa давал ссылку на яху
Поменяли шило на мыло. Это как раз один из тех случаев когда использовать подобное проще, чем переделывать архитектуру. Java они отсекли из-за не возможности работы под freeBSD. Да в целом и сейчас поддержка Java там хромает.
эсли вы почитаете наконец описание пакета, то увидите на чем он базируется. этот модуль предоставлет интерфейс.
Объектная обертка? Ну тогда понятно зачем нужен PEAR. Так как бинарные расширения этого делать собственно не позволяют.
ну что, еще одна религиозная война? :D
А то!:) На самом деле удобнее и прощее. Достаточно сравнить Makefile ports и ebuild portage. Ну и местами заметно гибче.
если это было бы так, я бы не советовал на них подписываться.
Я подписан на рассылку gentoo-dev. Думаете там много говорят о иделогии?
>пакеты все же правильнее ставить используя специализированные менеджеры, меньше бардака.
переходите на винду - там за вас уже все решили :)
>Поменяли шило на мыло.
это ваше личное мнение, а у людей, которые там работают оно обоснованное, в том числе и опытом работы с высоконагруженными проектами. почувствуйте разницу.
>Я подписан на рассылку gentoo-dev.
о боже! это тоже я вам насоветовал? тогда немедленно отпишитесь :D можно подписаться на какую-нибудь порно-рассылку (такие существуют?) наверняка там тоже не говорят об идеалогии. то, что из рекомендованных рассылок можно понять идеалогию (если конечно захотеть) безусловно.
переходите на винду - там за вас уже все решили :)
>Поменяли шило на мыло.
это ваше личное мнение, а у людей, которые там работают оно обоснованное, в том числе и опытом работы с высоконагруженными проектами. почувствуйте разницу.
>Я подписан на рассылку gentoo-dev.
о боже! это тоже я вам насоветовал? тогда немедленно отпишитесь :D можно подписаться на какую-нибудь порно-рассылку (такие существуют?) наверняка там тоже не говорят об идеалогии. то, что из рекомендованных рассылок можно понять идеалогию (если конечно захотеть) безусловно.
переходите на винду - там за вас уже все решили :)
Вот где решили так решили :)))
это ваше личное мнение, а у людей, которые там работают оно обоснованное, в том числе и опытом работы с высоконагруженными проектами. почувствуйте разницу.
Да это мое личное мнение. Но там нагрузка распределяется между узлами и наболее высоконагруженная часть написана на C++. Ну работает значит смогли заставить.
о боже! это тоже я вам насоветовал? тогда немедленно отпишитесь :D можно подписаться на какую-нибудь порно-рассылку (такие существуют?) наверняка там тоже не говорят об идеалогии. то, что из рекомендованных рассылок можно понять идеалогию (если конечно захотеть) безусловно.
Ладно верю вам что там говорят про идеологию. Вы сами подписаны? Если да то можете в двух-тех словах описать идеологию проекта?
аж два репозитария PECL и PEAR. В чем логика?
Вы понимаете разницу между скомпилированной программой, написанной на C, и сценарием, написанным на интерпретируемом языке?
Понимаю. Но совершенно не понимаю зачем плодить две сущности которые делают одно и тоже. В python и perl единая система и для того и для того. Что мешало тут сделать так же?
вы видите разницу меду пакетом, который нужно собрать, откомпилировать, установить и пакетом, который разворачивается на _любом_ виртуальном хостинге?
Вам не кажется, что проблема надумана? Мне кажется. Что мешает поддерживать только PEAR если он более универсален, чем PECL?
м не кажется, что проблема надумана?
мне кажется что проблемы вообще не существует ни для кого, кроме вас ;)
Что мешает поддерживать только PEAR если он более универсален, чем PECL?
то, что PEAR - это модули, написанные на РНР, а PECL - это С-расширения. у них разные задачи.
мне кажется что проблемы вообще не существует ни для кого, кроме вас ;)
Да да мне не нравится PHP и я этого не скрываю :)
то, что PEAR - это модули, написанные на РНР, а PECL - это С-расширения. у них разные задачи.
А у меня есть ощущение, что господа не смогли осилить быстрый интерпретатор поэтому породили два репозитория, тот что побыстрее и тот что помедленне :)
А у меня есть ощущение, что господа не смогли осилить быстрый интерпретатор поэтому породили два репозитория, тот что побыстрее и тот что помедленне
это вам только кажется. повторюсь - если вы не видите разницы между пакетом, который нужно собрать, откомпилировать, установить и пакетом, который разворачивается на _любом_ виртуальном хостинге, то помочь в преодолении этого предрасудка очень сложно :)
Разницу я вижу. Но я так же вижу что функционал PECL может дублировать функционал PEAR. Хотя видимо это специальная фича PHP :))) Иметь в одном комплекте несколько реализаций одного и того же, чтобы пользователь подумал, а чего же ему хочется :)
О разнице в скорости работы скомпилированной программы и интерпретируемого сценария представление имеете?
Я имею представление о скорости скомпилированной программы и интерпретируемого сценария. Но в java почему-то практически все пакеты расширений написаны на ней. А в PHP нет. В результате получаем если хотите чтобы быстро работало юзайте бинарные расширения. А интерпретируемые работают не ахти быстро.
где видите реальное дублирование функционала?давайте рассмотрим эти случаи и поймему почему так.
Вы сами сказали, что PEAR используется там где нет возможности установить бинарные расширения. Из-за это и возникает дублирование функционала с функциями PHP и PECL. В PEAR есть код для работы с СУБД есть код для работы с XML. Список можно продолжить.
В PEAR есть код для работы с СУБД
надеюсь не надо пояснять разницу между драйвером бд и кодом, организующим абстрактный слой?
есть код для работы с XML.
смотрим и понимаем, что модули имеют вполне конкретные цели.
Список можно продолжить.
с нетерпением жду продолжения :)
надеюсь не надо пояснять разницу между драйвером бд и кодом, организующим абстрактный слой?
Хорошо задам вопрос подругому. PDO оно дублирует или нет. Если нет то почему?
смотрим и понимаем, что
модули имеют вполне конкретные цели.
И так же понимаем, что это может быть так же реализовано средствами DOM.
И какие же?
например, нам надо работать с железом или с системой, или перед нами стоит ресурсоемкая задача.
Хорошо задам вопрос подругому. PDO оно дублирует или нет. Если нет то почему?
в части функционала - наверняка. но дает нам возможность использовать любой, из имеющихся в наличии драйверов + мы не зависимы от изменений интерфейса расширения. еще рекомендую просмотреть одно обсуждение.
И так же понимаем, что это может быть так же реализовано средствами DOM.
т.е. вы предлагаете каждый раз изобретать велосипед заново?
в части функционала - наверняка. но дает нам возможность использовать любой, из имеющихся в наличии драйверов + мы не зависимы от изменений интерфейса расширения. еще рекомендую просмотреть одно обсуждение.
Понятно. Но основное различие сводится к тому, что одно бинарное второе не очень. Хотя опять же классы на самом языке более расширяемы.
т.е. вы предлагаете каждый раз изобретать велосипед заново?
Нет, я предлагаю базировать велосипеды, на базе бинарных расширений.
>Хотя опять же классы на самом языке более расширяемы.
это почему? никакой принципиальной разницы (в плане программирования) нет откуда будут использован функционал.
>Нет, я предлагаю базировать велосипеды, на базе бинарных расширений.
так PEAR именно это и делает.
это почему? никакой принципиальной разницы (в плане программирования) нет откуда будут использован функционал.
>Нет, я предлагаю базировать велосипеды, на базе бинарных расширений.
так PEAR именно это и делает.
это почему? никакой принципиальной разницы (в плане программирования) нет откуда будут использован функционал.
Разница все же есть. К примеру как вы их расширений будете экспортировать классы?
так PEAR именно это и делает.
Да ? А разве не вы говорили, что PEAR применяется при не возможности использования, бинарных расширений?
> К примеру как вы их расширений будете экспортировать классы?
это куда нам их потребовалось экспортировать? если мне нужно расширить функционал класса - я от него наследую.
>А разве не вы говорили, что PEAR применяется при не возможности использования, бинарных расширений?
я говорил что эти два репозитария отличаются тем, что в одном лежат С-модули, в другом РНР. я говорил о том, что С-модуль на виртуальном хостинге нет возможности использовать. но я никогда не говорил, что PEAR может заменить PECL модуль. это вы такое уже додумали. и я даже знаю почему. потому что считаете что они выполняют одинаковые функции.
это куда нам их потребовалось экспортировать? если мне нужно расширить функционал класса - я от него наследую.
>А разве не вы говорили, что PEAR применяется при не возможности использования, бинарных расширений?
я говорил что эти два репозитария отличаются тем, что в одном лежат С-модули, в другом РНР. я говорил о том, что С-модуль на виртуальном хостинге нет возможности использовать. но я никогда не говорил, что PEAR может заменить PECL модуль. это вы такое уже додумали. и я даже знаю почему. потому что считаете что они выполняют одинаковые функции.
это куда нам их потребовалось экспортировать? если мне нужно расширить функционал класса - я от него наследую.
Чтобы его откуда-то наследовать, то сначала надо получить откуда-то предка. А теперь вопрос вы можете предка поместить в бинарное расширение ? :)
я говорил что эти два репозитария отличаются тем, что в одном лежат С-модули, в другом РНР. я говорил о том, что С-модуль на виртуальном хостинге нет возможности использовать. но я никогда не говорил, что PEAR может заменить PECL модуль. это вы такое уже додумали. и я даже знаю почему. потому что считаете что они выполняют одинаковые функции.
Частично выполняют. Но так же (насколько я понял) представляют из себя ООП обертку процедур PHP.
>А теперь вопрос вы можете предка поместить в бинарное расширение ?
для этого есть API, ссылку на который я уже давайл. Там же где-то рядом есть про то, как писать расширения. вы можете реализовать функциональный, а можете объектный интерфейс расширения.
>Но так же (насколько я понял) представляют из себя ООП обертку процедур PHP
1. не обязательно процедур и не пхп, а скорее расширений.
2. PEAR модули позволяют не изобретать велосипеды для стандартных решений.
для этого есть API, ссылку на который я уже давайл. Там же где-то рядом есть про то, как писать расширения. вы можете реализовать функциональный, а можете объектный интерфейс расширения.
>Но так же (насколько я понял) представляют из себя ООП обертку процедур PHP
1. не обязательно процедур и не пхп, а скорее расширений.
2. PEAR модули позволяют не изобретать велосипеды для стандартных решений.
Там же где-то рядом есть про то, как писать расширения. вы можете реализовать функциональный, а можете объектный интерфейс расширения.
Объектный интерфейс для бинарного расширения прямо в нем я как-то даже представить не могу. Т.к. если я правильно помню, подключаемые библиотеки умеют только функции.
1. не обязательно процедур и не пхп, а скорее расширений.
Я это и имел ввиду.
2. PEAR модули позволяют не изобретать велосипеды для стандартных решений.
Сборник готовых велосипедов :)))
>если я правильно помню, подключаемые библиотеки умеют только функции.
не правильно помните :) можно и объектный интерфейс делать. тот же PDO, mysqli, DOM и т.д.
не правильно помните :) можно и объектный интерфейс делать. тот же PDO, mysqli, DOM и т.д.
не правильно помните :) можно и объектный интерфейс делать. тот же PDO, mysqli, DOM и т.д.
А откуда берется информация о самом объекте? Через специальную функцию или структуру данных?
не очень понял вопрос. если нужно "исследовать" объект, то есть такой инструментарий - Reflection. А вообще, порядочное расширение имеет описание своих данных и методов.
меня интересует каким образом из бинарного расширения они получают данные о структуре объекта.
Плохие программисты есть везде. Если человек хочет развиваться - он будет развиваться. И PHP, опять, тут замешан вряд ли.
Руби достаточно прост, если не углубляться. А уж если вспомнить rails - так многие и вовсе не углубляются - там всё за них делают. Скаффолдинг, метапрограммирование, все дела.
Руби достаточно прост, если не углубляться. А уж если вспомнить rails - так многие и вовсе не углубляются - там всё за них делают. Скаффолдинг, метапрограммирование, все дела.
Лучше иметь круг общения с умными и богатыми, а не с толпой низкооплачиваемых неспециалистов.
Товарищ, здесь речь идет не о посиделках в гламурном ночном клубе (с умными и богатыми, как вы любите), а о приеме на работу специалистов (недорогих и способных к обучению).
Вы можете нанять одного умного и богатого руби-специалиста, а я лучше найму на эти же деньги трех способных PHP-шников без опыта, научу их и буду делать сайты в три раза быстрее вас. И не хуже.
Вы можете нанять одного умного и богатого руби-специалиста, а я лучше найму на эти же деньги трех способных PHP-шников без опыта, научу их и буду делать сайты в три раза быстрее вас. И не хуже.
А не вызывает подозрение нелогичность получившейся картины мира? Куча гламурных педерастов нанимает на работу за большие деньги python/ruby-программистов чтобы тусоваться в клубе, а молодые и "способные к обучению" PHP-шники ждут когда их за копейки возмет на работу Kiwi-студио?
Откуда тогда у представителей демонического мира клубных гламурных негодяев такая убогая идея брать на работу дорогих программистов (да еще и гоняются за ними и пытаются переманивать)? Где логика?
Понимаю, что мой пример не показателен и вообще вреден к рассмотрению как от участника спора, но мы НЕ БЕРЕМ ЛЮДЕЙ которые в резюме пишут, что знают PHP. Потому, что они не способны обучаться и мыслить как Программист (с большой буквы чтобы отличать PHP-программистов и тех-кто-не-знает-PHP). И в тех случаях когда все таки брали приходилось увольнять.
Откуда тогда у представителей демонического мира клубных гламурных негодяев такая убогая идея брать на работу дорогих программистов (да еще и гоняются за ними и пытаются переманивать)? Где логика?
Понимаю, что мой пример не показателен и вообще вреден к рассмотрению как от участника спора, но мы НЕ БЕРЕМ ЛЮДЕЙ которые в резюме пишут, что знают PHP. Потому, что они не способны обучаться и мыслить как Программист (с большой буквы чтобы отличать PHP-программистов и тех-кто-не-знает-PHP). И в тех случаях когда все таки брали приходилось увольнять.
Заметьте, про педерастов вы сами начали.
Я программирую на PHP и считаю себя хорошим программистом. Вы меня не возьмете на работу, конечно, но я даже рад. Вы сноб и ортодокс, не видящий дальше своего носа. И еще грубиян.
У меня нет никакого желания дальше продолжать дискуссию с человеком, который меня оскорбляет.
Я программирую на PHP и считаю себя хорошим программистом. Вы меня не возьмете на работу, конечно, но я даже рад. Вы сноб и ортодокс, не видящий дальше своего носа. И еще грубиян.
У меня нет никакого желания дальше продолжать дискуссию с человеком, который меня оскорбляет.
Возьмите Propel, возьмите Doctrine, возьмите Creole, возьмите фреймворки Symfony или CakePHP, наконец
1) Результаты тестирования шести ведущих фреймворков на производительность
2) Почему же "90% сайтов" на PHP пишутся с использованием велосипедных конструкций?
Что-то я не видел пока языков предназначенных для веба, которые не позволяют смешать программу с html-кодом.
В школе PHP как собственно и любой язык не нужны. Нужен базис теории алгоритмов. Практика только факультативом. Дабы занимались с теми кому это действительно интересно. Обучать конкретному языку это тоже самое что обучать только работе с ОС Windows в школе.
"Суха теория, мой друг, но древо жизни вечно зеленеет", как говорил один наш немецкий товарищ.
Одной лишь теорией аппелировать нельзя, без практики она очень трудно усваивается.
Одной лишь теорией аппелировать нельзя, без практики она очень трудно усваивается.
Хотел написать "оперировать", получилось "аппелировать" :))) Простите
А зачем она там нужна? Вот зачем детей учить программированию в школе? Кто-нибудь мне может объяснить?
Это непростой вопрос.
А зачем учить литературе или химии?
Программирование играет в современном мире роль не меньшую, чем химия. Мне так кажется.
Кстати, курс химии почти всегда сопровождается лабораторными работами - это к вопросу о практике.
А зачем учить литературе или химии?
Программирование играет в современном мире роль не меньшую, чем химия. Мне так кажется.
Кстати, курс химии почти всегда сопровождается лабораторными работами - это к вопросу о практике.
Программирование играет в современном мире роль не меньшую, чем химия. Мне так кажется.
Кто-нибудь из обычных людей программирует что-то сложнее макросов в текстовых процессорах и электронных таблицах ?
Кто-нибудь из обычных людей смешивает химические реагенты сложнее сахара в чае?
Учителям, почему детям?
Мне кажется, имелось в виду именно изучение школьниками.
Не учителям, даже, людям, заинтересованным в создании школьных сайтов. Я говорю настолько уверенно только потому, что работаю в образовательной организации, в которой это мероприятие проводилось)) Правда, сам я не присутствовал.
Вот цитата из рассылки-анонса:
"Уважаемые коллеги!
Приглашаем учителей информатики, зам. директоров по ИТ и просто заинтересованных лиц принять участие в серии мастер-классов посвященных сайтостроению. В первую очередь мастер-класс адресован школам, в которых ведётся самостоятельная работа по разработке школьного сайта."
Так что никакое это не преподавание PHP детям))
Вот цитата из рассылки-анонса:
"Уважаемые коллеги!
Приглашаем учителей информатики, зам. директоров по ИТ и просто заинтересованных лиц принять участие в серии мастер-классов посвященных сайтостроению. В первую очередь мастер-класс адресован школам, в которых ведётся самостоятельная работа по разработке школьного сайта."
Так что никакое это не преподавание PHP детям))
А я думаю на будущее будет полезно.
Многие учителя высказывались за стенгазету для учеников в стиле WEB 2.0Дорогие учителя, как вы сами себе представляете стенгазету в стиле WEB 2.0??? Я вот одного из самых важных вебдванольных элементов простую навигацию в стенгазете даже и представить не могу, вы уж извините :)
А вот дванольные уроки возможны. В одной школе видел. Там во всех классах гуманитарных наук обычную доску заменили сенсорной с проэктором на нее. Очень удобно для уроков истории, билогии, географии. Только вот учителям надо обучаться пользованию доской и заново составлять уроки. Прошло 2 года, пока директор добился желаемого результата. Но зато теперь на уроках таких учитилей интереснее чем раньше.
Я знаю!!
Стенгазета в стиле Web 2.0, это та, рядом лежит фломастер.
Каждый может подойти и написать - +1 :)
Стенгазета в стиле Web 2.0, это та, рядом лежит фломастер.
Каждый может подойти и написать - +1 :)
Даже не так. Web 2.0 - юзеры сами генерируют контенет.
Вы представьте себе, что обычный школьник (с их еще и грамотностью) напишет про свою любимую школу и свою любимую учительницу по биологии, к примеру. +)
Вы представьте себе, что обычный школьник (с их еще и грамотностью) напишет про свою любимую школу и свою любимую учительницу по биологии, к примеру. +)
Хмм.. если включить фантазию, то это будет выглядеть так:
На стене висит ватман, хорошим ученикам (с большой кармой в глазах преподавателей) выдаются специальные листы, на которые они могут что-то написать и наклеить на ватман. Все остальные могут взять из стопки маленьких листочков (которые около ватмана вместе с ручкой лежат), написать коммент и приклеить под листом с записью. Так же ученикам каждый день выдается в зависимости от рейтинга успеваемости некое количество значков-наклеек, которые они могут лепить на комменты =)
На стене висит ватман, хорошим ученикам (с большой кармой в глазах преподавателей) выдаются специальные листы, на которые они могут что-то написать и наклеить на ватман. Все остальные могут взять из стопки маленьких листочков (которые около ватмана вместе с ручкой лежат), написать коммент и приклеить под листом с записью. Так же ученикам каждый день выдается в зависимости от рейтинга успеваемости некое количество значков-наклеек, которые они могут лепить на комменты =)
побольше бы таких конференций..
В процессе обсуждения технологий и практик - всплыл любопытный момент, каждая школа желает иметь свой персональный сайт
Зачем каждой школе по сайту? IMHO лучше если будет один сайт для всех школ. Такой проект в Web 2.0 легче финансировать, он будет лучше технически и по дизайну чем миллионы отдельных страничек. Кстати, интересный проект. Типа хабрахабра для школ где будет расписание, учителя, история школы, вход для родителей и учеников - индивидуально для каждой школы и всевозможные справочники для всех. Проект можно сделать совершенно монстроподобным вплоть до интеграции с гугл мапс :) Захочет ли кто нибудь такое делать?
P.S. Надеюсь подобный портал не будет делать мин образования т.к. они просто распилят фининсирование и при этом случится неудобный выкидишь.
Скорее нужна общая для всех школ платформа + региональные (областные) площадки, на которые можно перейти с общего портала. Это более масштабируемо и более гибко. К тому же позволяет не сосать лапу в отсутсвие связи до центрального портала.
к сожалению, именно министерство образования и занимается созданием подобных ресурсов. Например, у нас в городе существует сайт http://eduvluki.ru/
(конечно, о ведваноль говорить не приходится)
(конечно, о ведваноль говорить не приходится)
хороший сайт.
но мне более симпатичен
http://gimnasia.vluki.ru/
чем такой раздел
http://eduvluki.ru/schools/?sch_id=11
одно другому не мешает в принципе :-)
но мне более симпатичен
http://gimnasia.vluki.ru/
чем такой раздел
http://eduvluki.ru/schools/?sch_id=11
одно другому не мешает в принципе :-)
Кстати обсуждался вариант использования движка ЖЖ ;-)
Именно все перечисленное и хотят видеть наши учителя - сайт школы не 1 страничка
на narod.ru, а полноценный инструмент - хотя бы как информационный.
Именно все перечисленное и хотят видеть наши учителя - сайт школы не 1 страничка
на narod.ru, а полноценный инструмент - хотя бы как информационный.
Предаставляю насколько у некоторых учителей будет отрицательная карма.
Означает ли это, что они будут лишены возможности писать новости на этот портал.
Хотя, возможно у них будет своя учительская черная карма! :) а у учеников белая.
Тогда каждый будет ранжирован дважды.
Означает ли это, что они будут лишены возможности писать новости на этот портал.
Хотя, возможно у них будет своя учительская черная карма! :) а у учеников белая.
Тогда каждый будет ранжирован дважды.
Даешь lisp и haskel в школы!
А если серьезно, паскаль как учебный язык почти идеален (ведь создавался именно с этой целью). И можно потихоньку на питон переходить, тоже прекрасный язык для обучения.
А если серьезно, паскаль как учебный язык почти идеален (ведь создавался именно с этой целью). И можно потихоньку на питон переходить, тоже прекрасный язык для обучения.
но и за стенгазету для учеников в стиле WEB 2.0
? Это вообще как? Это уже слишком. Теперь все будет 2.0?
Ну зачем использовать термин (пусть даже абстрактный) совершенно не по месту. Все же рекомендую почитать:
Тим Бернерс-Ли не понимает, что такое Веб 2.0 http://www.habrahabr.ru/blog/columns/614…
Тим О’Рейли: Движение в новую реальность http://www.habrahabr.ru/blog/translation…
Веб 2.0 Ну, так что это? http://www.habrahabr.ru/blog/web_2_0/502…
Зная о уровне компьютерной грамотности школьных учителей, завучей и директоров могу предположить, что они просто качали головой приговаривая "да, это нам нужно", "web 2.0 - обязательно!" ни на йоту не понимая о чем речь...
Обощение - плохая вещь. Страна-то у нас ой как велика и сейчас в школах вполне можно встретить влеченных молодых да и не очень людей. В нас, еще в 1992, когда класс был наполен Корветами, была учителем информатики женщина, в те годы ей уже было за 40, и, представь себе, проиходило это в далеком Абакане в Сибири. И писали программы, викторины и прочую интерактивную вкуснятину, в том числе и многие девченки. Так что не надо обобщений.
Хорошо, когда есть реальные примеры в противовес моему утверждению. Это очень хорошо!
К сожалению, все примеры которые могу привести я применимы только в пользую моей точки зрения... При этом, конечно же, я ни в коем случае не берусь утверждать, что это касается всех школ! Но - большинства. Доминирующего большинства!
По роду своей деятельности я связан с организацией, которая активно контактирует с образовательными структурами именно по вопросам интернет- и иных компьютерных технологий. Моя точка зрения взята не с неба, это реальность... О которой сообщаю с сожалением.
К сожалению, все примеры которые могу привести я применимы только в пользую моей точки зрения... При этом, конечно же, я ни в коем случае не берусь утверждать, что это касается всех школ! Но - большинства. Доминирующего большинства!
По роду своей деятельности я связан с организацией, которая активно контактирует с образовательными структурами именно по вопросам интернет- и иных компьютерных технологий. Моя точка зрения взята не с неба, это реальность... О которой сообщаю с сожалением.
Ну я бы так не сказал, вопросы были весьма жизненные.
Хочу заметить мастер-класс был не в том что WEB 2.0 - это супер-пупер
и покупайте наших слонов - а именно что это такое и про ошибочное восприятие термина тоже.
Но согласитесь каждой школе лучше иметь свой сайт, если уже есть безлимитный интернет:
1) Во первых будет понятно - для чего он нужен
2) Пооощряет творчество и развитие всяких кружков
3) Позволяет обмениваться информацией между преподавателями (вести авторскую факультативную программу)
4) Оживить внешкольную творческую активность
Хочу заметить мастер-класс был не в том что WEB 2.0 - это супер-пупер
и покупайте наших слонов - а именно что это такое и про ошибочное восприятие термина тоже.
Но согласитесь каждой школе лучше иметь свой сайт, если уже есть безлимитный интернет:
1) Во первых будет понятно - для чего он нужен
2) Пооощряет творчество и развитие всяких кружков
3) Позволяет обмениваться информацией между преподавателями (вести авторскую факультативную программу)
4) Оживить внешкольную творческую активность
Займитесь, пожалуйста, Санкт-Петербургским Государственным Университетом Аэрокосмического Приборостроения.
Наш преподаватель по PHP, профессор, путает WiFi и HiFi.
А задание на 1-ю лабу заключается в том, чтобы с помощью PHP подключиться к веб-камере и графически обработать изображение. И все это в автоматическом режиме с заданной периодичностью. И это при том, что 40%—60% студентов пугаются при слове браузер. Сказать сюрреализм — это ничего не сказать. Впрочем, у нас там так все. Впрочем, почти во всех ВУЗах Питера.
Насчет школ... делайте выводы из вышесказанного. Нужны четкие представления о сетевом взаимодействии вообще. И о системахдальше носа кроме Windows. Пытаться насадить сейчас PHP на неокрепшие (мягко сказано) умы, мне видится неправильным. Помните: бочка дегтя + ложка меда = бочка дегтя.., менее качественного. ;)
Наш преподаватель по PHP, профессор, путает WiFi и HiFi.
А задание на 1-ю лабу заключается в том, чтобы с помощью PHP подключиться к веб-камере и графически обработать изображение. И все это в автоматическом режиме с заданной периодичностью. И это при том, что 40%—60% студентов пугаются при слове браузер. Сказать сюрреализм — это ничего не сказать. Впрочем, у нас там так все. Впрочем, почти во всех ВУЗах Питера.
Насчет школ... делайте выводы из вышесказанного. Нужны четкие представления о сетевом взаимодействии вообще. И о системах
Самопиар да и только.
причем таким образом набирают подопытных кроликов на свои курсы.
причем таким образом набирают подопытных кроликов на свои курсы.
Ведущие мастер-класса: http://****** совместно с http://*******
Мне кажется, у некоторых участников обсуждения сложилось неверное понимание целей данного мероприятия. Это вовсе не внедрение PHP или какого-либо другого языка программирования в школьную программу. Это принципиально невозможно, потому что в этой программе уже все занято и даже с избытком. Да и дело это не PHPCLUB, а чиновников минобразования. Фактически, у мероприятия цели две. Во-первых, обсуждение с учителями программирования и зам.дир по ИТ и рассказ о современном состоянии веб-технологий и тенденций их развития от практикующих специалистов отрасли. Такой подход, как показывает практика, вполне доступен современному школьному учителю (хотя, согласен с iBear по поводу плачевного уровня квалификации учителей информатики). Это позволит учителю хотя бы поверхностно ориентироваться в вопросе и на уровне общих представлений рассказывать ученикам, и это важно, потому как ориентировки закладываются в школе. Во-вторых, это способ поиска интересующиеся и инициативной школьной молодежи и организации мероприятий дополнительного образования уже по конкретным тематикам, например, по серверному программированию. Это и есть подготовка молодых специалистов отрасли со школьной скамьи. Но никто не забывает, что это элитарное образование и идут на него в лучшем случае единицы процентов. Еще раз отмечу, что и по подходу и по идеологии ничего обязательного здесь нет.
согласен с 
DGusev думаю подобные мероприятия просто необходимы в текущем образовании, как для школ так и для ВУЗов.
По больше бы подобных мероприятий и вполне возможно, что учителям не будет стыдно изза того, что они знают меньше учеников :(
DGusev думаю подобные мероприятия просто необходимы в текущем образовании, как для школ так и для ВУЗов.По больше бы подобных мероприятий и вполне возможно, что учителям не будет стыдно изза того, что они знают меньше учеников :(
В мастер-классе приняли учителя информатики и зам. директора по ИТ московских школ.И по сколько грамм они приняли?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Первый мастер-класс по WEB 2.0, социальным сетям, php был проведен для учителей г.Москвы