Почему web так убог?

if(file_exists(

Правильно, тут switch не нужен, тут нужен for. Записывать перебор условиями - это круто!

Можно я повторюсь? Код на пыхе выглядит как говно. Что только что было доказано в очередной раз.

Ну хотя бы то, что мне не надо отдельно описывать поля в html и в обработчике. Нужно просто написать какие поля я хочу и что с ними сделать, когда они будут получены.

Как это «и что с ними сделать»? Ты при генерации формы описываешь логику обработки запросов с нее? А если у тебя на сайте несколько форм с разной логикой обработки запросов?

Не, ты можешь проверить доступность картинки вообще в принципе (если сервер твой запрос не заблочит, вдруг ты хакир), а что там реально случилось и отреагировать всё равно на клиенте надо :)

Или в пыхе так не модно?

В Пыхе _модно_ давно уже что-то типа такого:

Yii

'rules'=>array(
                    'transport/cars/<action>/<brand>/<name>/*'=>'cars/<action>',
                    'transport/cars/*'=>'cars',
                    ),
                ),

Laravel:

Route::get('user/{name?}', function ($name = null) {
  return $name;
});

BORS:

bors_url_map(array(
    '(.*)\?edit => bors_admin_edit_go(1)',

    '/_apc/i/\d+/(\d+.*)\.(jpe?g|png|gif)$ => aviaport_imagick(1)',

    '(/images/)archive/ => aviaport_photoreports_main',
    '(/images/)archive/(\d+)\.html => aviaport_photoreports_main',
    '(/images/archive/)(\d{4})/ => aviaport_photoreports_year(2)',
    '(/images/archive/)(\d{1,3})/ => aviaport_photoreports_view(2)',
…

Вообще, про роутинг (не в PHP) я даже как-то тему заводил: В каких web-фреймфорках самый удобный и красивый роутинг?

Сам у себя понемногу допиливаю роутинг такого формата:

GET		/			b2_demo_main
GET		/blog/*			b2_simple_blog

И меня ещё спрашивают, почему я считаю что весь код на php выглядит как говно. Потому что он выглядит как говно!

Чем код на Perl или Ruby лучше?

Чем моё говно говённее?

Ты построил тот самый случай «умного слова», про который я писал выше. У тебя смешан и диспетчер, и генераторы кода. Когда он у тебя дорастёт до пары сотен килобайт и ты к нему вернёшься что-то добавлять год спустя с последней модификации, ты всё проклянёшь :)

Оставь диспетчер (тип элемента -> генератор html-кода) отдельно, а весь код распихай по отдельным генераторам. Такой вариант и поддерживать будет проще, и расширять, и тестировать. Или использовать потом эти же генераторы из какого-то другого компонента.

Не, ты можешь проверить доступность картинки вообще в принципе (если сервер твой запрос не заблочит, вдруг ты хакир), а что там реально случилось и отреагировать всё равно на клиенте надо :)

Можно отдавать картинку скриптом по байтам и записывать в процентах статус, а на клиенте аяксом получать этот статус и при 100% формировать событие.) Ну это just for fun.)

Это уже предполагает наличие клиентского кода, так что лучше обойтись менее эзотерическими извращениями (^__^)

+ Кстати, картинка может быть с чужого сервера.

Чем код на Perl или Ruby лучше?

перл лучше наличием переменной по умолчанию и встроенными регэкспами, в руби метапрограммирование и теже регэкспы.

Сдается мне что ООП во все поля это не менее плохо чем полностью процедурное решение.

Именно с таким отношением (да ещё подкреплённым кривым и медленным ООП в PHP4) я начинал делать фреймворк в процедурном виде. Хотя ООП к тому времени (на том же Си++) практиковал уже без малого лет 10. И даже успел пару проектов в таком виде выкатить. Увы, слишком скоро полезли грабли сложностей рефакторинга, расширения, общего усложнения кода. В какой-то момент поймал себя на том, что я на процедурах пытаюсь эмулировать объектный подход. Попробовал несколько компонентов написать в чисто объектном стиле — оказалось в 2-3 раза короче по коду, опрятнее, нагляднее, надёжнее и, (sic!) в итоге быстрее.

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

И переход на ООП окупился тысячекратно.

Не совсем. Я описываю форму как набор полей и набор экшенов. Далее обработчик смотрит в это описание и обрабатывает пришедшие данные, основываясь на описании полей и генерирую экшены по их описанию. Шаблон смотрит в описание и генерирует html форму основываясь на описании. Конечно я не описываю логику при генерации формы. И не описываю вид формы (кроме порядка полей) при описание формы. Разная логика описана в экшенах.

И продолжаешь считать что в вэбе все ровно и гладко...

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

Я описываю форму как набор полей и набор экшенов.

Можно пример кода генерации формы?

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

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

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

Одно из моих правил — если я поведение свойства модели описываю в нескольких разных местах, я что-то делаю не так.

Кстате руби еще лучше разным обозначением переменных в зависимости от области видимости $ @ @@. Очень удобная штука.

Правильно, тут switch не нужен, тут нужен for

Можно и for. Первоначально там было два элемента, и третий добавился просто копипастом. Опять был прав Лео Броуди на счёт того, что в редакторе программиста должна отсутствовать функция копирования блоков :)

Код на пыхе выглядит как говно. Что только что было доказано в очередной раз.

Скажи ещё, что ты не сможешь так написать на другом языке. Продемонстрируй ещё раз потерю адекватности :)

перл лучше наличием переменной по умолчанию

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

Я, кстати, в PHP пришёл именно из Perl'а, имея к тому времени года три большой практики. И поначалу плевался от отсутствия этой переменной и громоздкого синтаксиса регекспов. Оценил позже, когда сравнил затраты на поддержку и рефакторинг.

Ещё позже полюбил Python за ещё более строгий стиль.

в руби метапрограммирование и теже регэкспы.

Вообще, это всё минимальные отличия. Я же не сказал, что они одинаковы. Я сказал, что идентичны и близки. Всё равно, как на вопрос о различиях процессоров ты начнёшь говорить про различия SSE и 3DNow, в то время, как я имел в виду схожесть Intel и AMD на фоне ARM и AVR (а в уме для споров ещё удерживая К745ИК1302 и Cell).

Кстате руби еще лучше разным обозначением переменных в зависимости от области видимости $ @ @@. Очень удобная штука.

А в PHP мне очень нравятся смешанные массивы:

    function table_fields()
    {
        return array(
            'id',
            'title',
            'text_raw' => array('name' => 'text', 'title' => ec('Содержание')),
            'keywords_string' => 'tags',
            'publish_time' => array('title' => ec('Дата и время публикации'), 'type' => 'utime'),
            'is_important' => array('title' => ec('Важно')),
            'is_milestone' => array('title' => ec('Веха')),
            'is_published' => array('title' => ec('Опубликовано')),
            'is_auto',
            'linked_class_name',
            'linked_object_id',
            'type_id',
            'create_time',
            'modify_time',
            'owner_id',
            'last_editor_id',
        );
    }

Это всё мелочи, на самом деле. Синтаксический сахар по сути.

Вообще, это всё минимальные отличия.

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

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

Ну да, доллар перед переменной, метод доступа к элементам класса, оформление цикла… Повторюсь, это мелочи :) Кроме того, я сразу очертил, что Perl и PHP вообще близнецы, Ruby отошёл от них чуть дальше, Python — ещё дальше.

Но сравни их с Forth, Lisp, Haskell, Prolog... Молчу уже про Brainfuck или любой ассемблер :D Даже JavaScript и то отличается от них весьма сильно, хотя тоже идеологически весьма близкий язык.

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

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

Ну так основаны на C/Pascal, непонимаю тогда почему js отличается больше чем руби, из за своеобразного ооп?

Ну так основаны на C/Pascal, непонимаю тогда почему js отличается больше чем руби

Подход к программированию разный.

из за своеобразного ооп?

И из-за него в частности тоже.

Почему web так убог?

На то воля господня.

целиком и полностью решение задач средствами, совершенно не предназначенными для этого

Как же ловко тебе удалось описать вообще любое программирование на любом языке. Я восхищен :) Сам что-то такое всегда крутил в голове, но выразить никак не мог

именно поэтому и сваливаю из этого треда.

Откуда ж мне знать, что ты имел в виду.

я уточнил, исправив свой пост.

И вообще, с ЛОРа не уходят, в том числе из тредов :}

если б я знал, во что превратится этот тред, я б его даже не читал.

display:table-cell;

костыль, но работает. =P

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

Ахаха, прекрати.

Скажи ещё, что ты не сможешь так написать на другом языке

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

Чем код на Perl или Ruby лучше?

Я не знаю ничего насчёт руби, но на перле писать говно неудобно. Он как-то располагает к тому, чтобы перебор делать циклом, и совершенно не располагает к особо тяжким извращениям вроде $html .= "<tr><th>{$th}</th><td>".

display:table-cell;
костыль, но работает. =P

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

А ты попробуй, лол.

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

Обратная совместимость же. HTML создавали для текста с заголовками и гиперссылками, а потом понеслось.

А проблем там действительно гораздо больше. В том числе и с прибиванием футера

Каких проблем? В каком месте?

.footer {
   position: fixed; bottom: 0; left: 0; height: 60px;
}

body { margin-bottom: 60px; }

<div class="footer">It's a footer!</div>

Да, вот что меня удивляет, что в 2013 году HTML до сих пор не умеет нормально работать с высотой.

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

почему все эти люди которые создали всякие html, php, css и прочие js (возможно к последнему притензии мои и зря), смогли вывести это в мэйнстрим?

quick&dirty

Почему мэйнстримом де-факто стали настолько убогие и кривые стандарты и технологии?

Потому что в условиях, когда допустим quick&dirty, побеждает лучшее решение из худших.

Мнения тех, кто считает что все нормально и не видит глобального ада, не очень интересно. Интересно именно чем думали создатели этого.

хотели как лучше...

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

Но с другой стороны, другие решения еще хуже.

Правильно, тут switch не нужен, тут нужен for. Записывать перебор условиями - это круто!

есть красивое решение по борьбе с этим в некоторых языках: pattern/function matching + guards. Наличие данных возможностей на порядок снижает уровень «крутизны». К сожалению не во всех языках это есть и реализация не дешева...

dom вполне себе не плох, а с чем ты сравниваешь?

Интересно именно чем думали создатели этого.

Кастую телепатов в тред.

В Пыхе _модно_ давно уже что-то типа такого:

особенно модно в это:

...
'transport/cars/*'=>'cars', /* <=== оставим это <,> just for fun */
                    ),
...

Ты неадекватен.

/* <=== оставим это <,> just for fun */

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

совершенно не располагает к особо тяжким извращениям

Однако php-адепты именно так perl и используют, много раз такое видел. Недавно уволили жуниора который пытался писать на perl'е как на php.

сильно бесит в JSON невозможность оставить последнюю запятую

Если бы только в JSON...

И, да. Redmine, Ruby:

  def render_properties(properties)
    unless properties.nil? || properties.empty?
      content = ''
      properties.keys.sort.each do |property|
        content << content_tag('li', "<b>#{h property}</b>: <span>#{h properties[property]}</span>".html_safe)

            href, alt_title = check_refs( href ) if href
            url, url_title = check_refs( url )

            out = ''
            out << "<a#{ shelve( " href=\"#{ href }\"" ) }>" if href
            out << "<img#{ shelve( atts ) } />"
            out << "</a>#{ href_a1 }#{ href_a2 }" if href

cherrypy, Python:

    def login_screen(self, from_page='..', username='', error_msg='', **kwargs):
        return ntob("""<html><body>
Message: %(error_msg)s
<form method="post" action="do_login">
    Login: <input type="text" name="username" value="%(username)s" size="10" /><br />
    Password: <input type="password" name="password" size="10" /><br />

sphinx, Python:

        if format == 'svg':
            svgtag = '<img src="%s" alt="%s" %s/>\n' % (fname, alt, imgcss)
            self.body.append(svgtag)

Это НЕ нормальная работа с высотой.

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

а потом тихими вечерами, насладившись от трасс в 3 часа ночи к счастью находишь то самое место из-за чего глючило типа:

Fatal error: Call to a member function on a non-object...

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

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

и т.д.

100% бывшие пыхеры.

Call to a member function on a non-object

А запятая тут при чём?

то самое место из-за чего глючило типа

Каким макаром? o_O Как лишняя запятая может к этому привести? Почему я за 10 лет такого никогда не видел? :D