Comments 282
Вам явно было не лень набирать теги…
Очень интерестно, спасибо!
а посля прочтения «Гибель ментальная» мне как-то жутко стало… не ужели все так плохо? :-\
В уродский неэффективный ассемблерный код.
Похоже о ассемблере вы знаете только название. Печально.
Таким образом, никуда не деваясь физически, ассемблер исчез из IT индустрии.
Абсолютное заблуждение.
Похоже о ассемблере вы знаете только название. Печально.
Таким образом, никуда не деваясь физически, ассемблер исчез из IT индустрии.
Абсолютное заблуждение.
В уродский неэффективный ассемблерный код.Вы не согласны с тем, что ассемблерный (а точнее, машинный) код, полученный в рещультате компиляции высокоуровневой программы является уродским? Во всяком случае по сравнению с ассемблерным кодом написанном вручную.
Таким образом, никуда не деваясь физически, ассемблер исчез из IT индустрии.См. сноску. Речь идет о прикладной IT-индустрии, а не о системном программировании. Тестовый редактор сейчас на ассемблере никто не пишет.
Смотря что понимаьб под «уродский». А вот на счёт эффективности я не согласен — современные компиляторы достаточно «умны» чтобы сгенерировать относительно быстрый код.
Сорри, сноску действительно не прочтитал. Но такое надо писать не в сносках, а в скобках, прямо в тексте.
Сорри, сноску действительно не прочтитал. Но такое надо писать не в сносках, а в скобках, прямо в тексте.
А вот на счёт эффективности я не согласен — современные компиляторы достаточно «умны» чтобы сгенерировать относительно быстрый код.
Ключевое слово здесь — относительно.
Действительно, при мощностях современного железа, уменьшение эффективности сгенерированного кода относительно не заметно. Но это не значит, что ухудшения нет!
Например несколько десятков лет назад или на сейчас на устройствах с малой производительностью (мобильники, микроволновки и т.д.) эти ухудшения уже сильно сказываются, что, к сожалению, побуждает в этих ситуация отказаться от использования высокоуровневых языков.
> Но это не значит, что ухудшения нет!
это необратимый процесс усиления абстракций, относительно старых ресурсов; сами ресурсы также развиваются параллельно с усилением абстракций.
Идеологи, которые создают новые абстракции прекрасно понимают, на что идут и осознают все ухудшения в потреблении ресурсов; однако, их идеи подпитываются улучшением возможностей железа.
Еще одно правило — всегда есть профессионалы в текущих абстракциях (часто именно они являются создателями последующих (усиленных) абстракций); и они всегда будут видеть недочеты в новых абстракциях — где-то сетовать, где устранять, где-то — помогать советами. Потом появятся профи в новых абстракциях и будут видеть недочеты в следующих.
это необратимый процесс усиления абстракций, относительно старых ресурсов; сами ресурсы также развиваются параллельно с усилением абстракций.
Идеологи, которые создают новые абстракции прекрасно понимают, на что идут и осознают все ухудшения в потреблении ресурсов; однако, их идеи подпитываются улучшением возможностей железа.
Еще одно правило — всегда есть профессионалы в текущих абстракциях (часто именно они являются создателями последующих (усиленных) абстракций); и они всегда будут видеть недочеты в новых абстракциях — где-то сетовать, где устранять, где-то — помогать советами. Потом появятся профи в новых абстракциях и будут видеть недочеты в следующих.
Так никто и не спорит с тем, что переход на новый уровень абстракции — хорошо. И что при постоянном увеличении мощности железа, это происходит безболезненно.
Я просто не согласен с той фразой, что переход на новый уровень происходит совсем без увеличения накладных расходов.
Я просто не согласен с той фразой, что переход на новый уровень происходит совсем без увеличения накладных расходов.
> Я просто не согласен с той фразой, что переход на новый уровень происходит совсем без увеличения накладных расходов.
а кто это говорил? я не видел; в любом случае — это глупость, переход на новый уровень (на то он и прогресс, а не регресс) будет нести дополнительные расходы, но благодаря параллельному развитию того, для чего (или кого) эта абстракция писалась (в данном случае — язык для машины) получается прогресс (иначе был бы регресс — потребление ресурсов увеличивается и все тормозит, т.к. то, для чего была создана новая абстракция не развивается)
а кто это говорил? я не видел; в любом случае — это глупость, переход на новый уровень (на то он и прогресс, а не регресс) будет нести дополнительные расходы, но благодаря параллельному развитию того, для чего (или кого) эта абстракция писалась (в данном случае — язык для машины) получается прогресс (иначе был бы регресс — потребление ресурсов увеличивается и все тормозит, т.к. то, для чего была создана новая абстракция не развивается)
> Я просто не согласен с той фразой, что переход на новый уровень происходит совсем без увеличения накладных расходов.
а кто это говорил? я не видел; в любом случае — это глупость ...
Я спорю с superhabra, который утверждает, что программы на высокоуровневых языках всегда более эффективны, чем низкоуровневые ассемблерные:
>[программа на высокоуровневом языке компилируется] в неэффективный ассемблерный [или машинный] код.
Похоже о ассемблере вы знаете только название
Я же утвержаю, что в большинстве случаев (хоть и не всегда), программа, написанная на высокоуровневом языке менее эффективна, чем низкоуровневая; т.к. накладные расходы перехода на новый уровень абстракции снижают эффективность.
Если бы это всегда было не так, то никто бы не писал ассемблерные программы для маломощных устройств.
Но, то что во многих случаях программы для устройств с малой производительностью пишут именно на ассемблере, а не на высокоуровневых языках, говорит о том, что накладные расходы при переходе на новый уровень абстракции приводят к уменьшению эффективности (несущественного для современных компьютеров, но критичного для маломощных устройств).
Я спорю с superhabra, который утверждает, что программы на высокоуровневых языках всегда более эффективны, чем низкоуровневые ассемблерные
Мой вам совет, завязывайте с тяжелыми наркотиками.
Я думаю что вы в курсе, что есть такой метод ведения спора, как «подмена понятий».
Так вот, воспользовавшись им вы подтвердили свою некомпетентность в это сфере, и дальнейшее продолжение дискуссии считаю бессмысленным.
Я написал:
На что Вы ответили:
Однако, на основании этого ответа можно сделать только один вывод — Вы не согласны с моим утверждением «программы, написанные на высокоуровневом языке бывают менее эффективны, чем низкоуровневые; т.к. накладные расходы перехода на новый уровень абстракции снижают эффективность».
Я стал доказывать обратное: приводить пример с накладными расходами и микроволновками.
На что dsCode вполне резонно заметил: зачем я доказываю очевидные вещи…
Но, если Вы обещаете больше не продолжать дискуссию — я не буду настаивать…
[программа на высокоуровневом языке компилируется] в неэффективный ассемблерный [или машинный] код.Т.е. я хотел показать, что в большинстве случаев (хоть и не всегда), программа, написанная на высокоуровневом языке менее эффективна, чем низкоуровневая; т.к. накладные расходы перехода на новый уровень абстракции снижают эффективность.
На что Вы ответили:
Похоже о ассемблере вы знаете только название.Возможно, если бы Вы ответили нормально, а не применили демагогический прием «Ad hominem», то Ваша истинная мысль стала бы ясна.
Однако, на основании этого ответа можно сделать только один вывод — Вы не согласны с моим утверждением «программы, написанные на высокоуровневом языке бывают менее эффективны, чем низкоуровневые; т.к. накладные расходы перехода на новый уровень абстракции снижают эффективность».
Я стал доказывать обратное: приводить пример с накладными расходами и микроволновками.
На что dsCode вполне резонно заметил: зачем я доказываю очевидные вещи…
Но, если Вы обещаете больше не продолжать дискуссию — я не буду настаивать…
Я спорю с superhabra, который утверждает, что программы на высокоуровневых языках всегда более эффективны, чем низкоуровневые ассемблерные
Вот оно, ключевое слово. Я думаю что вы согласитесь что при написании ассемблернго кода эффективность больше зависит от профессионализма программиста, чем в случае высокоуровнего ЯП. А рассматривать «идеального программиста в вакууме» не имеет смысла.
Ладно, ничего страшного :-) Просто не надо вместо возражений по существу, использовать «Ad hominem» типа: «ты ничего не знаешь о предмете, кроме названия» — тогда и не будет недоразумений…
> Если бы это всегда было не так, то никто бы не писал ассемблерные программы для маломощных устройств.
> накладные расходы при переходе на новый уровень абстракции приводят к уменьшению эффективности (несущественного для современных компьютеров, но критичного для маломощных устройств).
Друзья, и то, и то — верно.
Кстати, ассемблерные вставки могут использовать (помимо убыстрения) также и для более низкоуровневых операция, если таковые недоступны из «обёрточных» функций языка (например, модуль асма для программирования на Питоне — habrahabr.ru/blogs/python/45726/)
Можно так же задавать вопросы — почему, например, JavaScript / Python / Ruby и т.д. написаны не на ассемблере? А что? — было бы быстрее в разы. Это вот как раз то, когда абстракция усилилась (появился Си), когда появились автоматизации сканеров и парсеров (типа Flex'a и Bison'a) — стало удобней и быстрей создавать новые языки. При этом, вероятно, создателей языков все же волновал вопрос, что их новый язык будет медленней даже Си (раз в 200), не то, что ассемблера. Но и так же, они, вероятно, осознавали, что если начнут сейчас писать JavaScript на асме, то потеряют много своих человеческих ресурсов (и может, и когда закончат — этот новый язык уже устареет и мало кому будет нужным).
Так же можно провести аналогию — оружие разных времен (тема не очень гуманная, но все же) — ясно-понятно, что для создания боевой дубины из ресурсов нужна только палка. В то время как для ядерной бомбы будет затрачено ресурсов >>>> больше. Разница в масштабы — понятно какая.
Что же касается меня лично — рассуждая о теме абстракций в языках программирования, я при этом являюсь большим почитателем ассемблера (хоть моя работа и не связана напрямую с ним). Так же я фанат демо-сцен, когда на чистом асме (ну а сейчас уже на Си), общаясь с железом напрямую в реальном времени, пишут замечательные красивые демки размером всего 64Кб (а иногда и интро в 4Кб). Кто не в курсе — посмотрите, например, демо немецкой команды Farb-Rausch. Это, конечно, искусство!
> накладные расходы при переходе на новый уровень абстракции приводят к уменьшению эффективности (несущественного для современных компьютеров, но критичного для маломощных устройств).
Друзья, и то, и то — верно.
Кстати, ассемблерные вставки могут использовать (помимо убыстрения) также и для более низкоуровневых операция, если таковые недоступны из «обёрточных» функций языка (например, модуль асма для программирования на Питоне — habrahabr.ru/blogs/python/45726/)
Можно так же задавать вопросы — почему, например, JavaScript / Python / Ruby и т.д. написаны не на ассемблере? А что? — было бы быстрее в разы. Это вот как раз то, когда абстракция усилилась (появился Си), когда появились автоматизации сканеров и парсеров (типа Flex'a и Bison'a) — стало удобней и быстрей создавать новые языки. При этом, вероятно, создателей языков все же волновал вопрос, что их новый язык будет медленней даже Си (раз в 200), не то, что ассемблера. Но и так же, они, вероятно, осознавали, что если начнут сейчас писать JavaScript на асме, то потеряют много своих человеческих ресурсов (и может, и когда закончат — этот новый язык уже устареет и мало кому будет нужным).
Так же можно провести аналогию — оружие разных времен (тема не очень гуманная, но все же) — ясно-понятно, что для создания боевой дубины из ресурсов нужна только палка. В то время как для ядерной бомбы будет затрачено ресурсов >>>> больше. Разница в масштабы — понятно какая.
Что же касается меня лично — рассуждая о теме абстракций в языках программирования, я при этом являюсь большим почитателем ассемблера (хоть моя работа и не связана напрямую с ним). Так же я фанат демо-сцен, когда на чистом асме (ну а сейчас уже на Си), общаясь с железом напрямую в реальном времени, пишут замечательные красивые демки размером всего 64Кб (а иногда и интро в 4Кб). Кто не в курсе — посмотрите, например, демо немецкой команды Farb-Rausch. Это, конечно, искусство!
Можно так же задавать вопросы — почему, например, JavaScript / Python / Ruby и т.д. написаны не на ассемблере? А что? — было бы быстрее в разы.Не были бы. Сам по себе ассемблер — не гарантия скорости. Большая и сложная программа на нём будет менее эффективна — просто внимания не хватит оптимально всё писать. Посмотрите рассказы про современные JavaScript-машины и подумайте — сколько лет вы бы отлаживали подобную систему на ассеблере и какой реальный выигрыш вы бы получили.
> Не были бы.
Были бы. Именно по скорости выполнения — были бы.
> Сам по себе ассемблер — не гарантия скорости.
Относительно верхней абстракции? (мы имеем в виду скорость выполнения, а не скорость разработки). Еще какая гарантия, поскольку верхняя абстракция используется эту нижнюю внутри себя с многочисленных проверками, чтобы уменьшить монотонные операции.
> Большая и сложная программа на нём будет менее эффективна — просто внимания не хватит оптимально всё писать.
Ну так я именно об этом и говорю (внимательней прочитайте пост выше).
> и подумайте
:) я «оценил».
> сколько лет вы бы отлаживали подобную систему на ассеблере и какой реальный выигрыш вы бы получили.
туда же относится — я именно об этом и говорил постом выше (еще прочитайте внимательно).
В очередной раз повторяю — основная идея усиления абстракций — убыстрить разработку, жертвуя ресурсами (но с верой и знанием, что то, для чего разрабатывается абстракция — тоже развивается). Вы же, «цитируя» меня же из поста выше (поскольку я говорил об этом же) подменяете понятия — «скорость выполнения» и «скорость разработки».
Были бы. Именно по скорости выполнения — были бы.
> Сам по себе ассемблер — не гарантия скорости.
Относительно верхней абстракции? (мы имеем в виду скорость выполнения, а не скорость разработки). Еще какая гарантия, поскольку верхняя абстракция используется эту нижнюю внутри себя с многочисленных проверками, чтобы уменьшить монотонные операции.
> Большая и сложная программа на нём будет менее эффективна — просто внимания не хватит оптимально всё писать.
Ну так я именно об этом и говорю (внимательней прочитайте пост выше).
> и подумайте
:) я «оценил».
> сколько лет вы бы отлаживали подобную систему на ассеблере и какой реальный выигрыш вы бы получили.
туда же относится — я именно об этом и говорил постом выше (еще прочитайте внимательно).
В очередной раз повторяю — основная идея усиления абстракций — убыстрить разработку, жертвуя ресурсами (но с верой и знанием, что то, для чего разрабатывается абстракция — тоже развивается). Вы же, «цитируя» меня же из поста выше (поскольку я говорил об этом же) подменяете понятия — «скорость выполнения» и «скорость разработки».
Относительно верхней абстракции? (мы имеем в виду скорость выполнения, а не скорость разработки).Скорость исполнения чего? Давайте не сравнивать сферических коней в вакууме. Простой интерпретатор, написанный на ассемблере против JIT'а проиграет с вероятностью 99%. И даже JIT, написанный на ассемблере (и потому не включащий в себя многих оптимизаций) проиграет JIT'у, написанному на C/C++.
Еще какая гарантия, поскольку верхняя абстракция используется эту нижнюю внутри себя с многочисленных проверками, чтобы уменьшить монотонные операции.Если вы запрограммируете один и тот же алгоритм — то да. Но так задача не стоит. Вам приходится сравнивать сложный, хитрый алгоритм, написанный на C/C++/Java/Python с простым, бесхитростным на ассемблере. Либо с плохо написанным кодом на ассемблере (потому что после нескольких миллионов строк вы либо вообще забудете что вы там замышляли вначале, либо начнёте халтурить). В обоих случаях ассеблерная версия, с большой вероятностью, проиграет.
В очередной раз повторяю — основная идея усиления абстракций — убыстрить разработку, жертвуя ресурсами (но с верой и знанием, что то, для чего разрабатывается абстракция — тоже развивается).Есть ещё одна сторона у медали, которую вы упорно не желаете замечать. Использование высокоуровненого кода позволяет менять нижележащий код на основе взаимодействия кода с реальными миром (посмотрите на досуге как работает profile-based optimization и JIT не говоря уже о всяких ATLAS'ах), а то, что вы породите на более низком уровне — будет статично. И во многих случаях (но, разумеется, не всегда) вещь, порождённая на низком уровне будет проигрывать за счёт своей статичности.
Начиная с некоторого уровня сложности системы код, написанный на низком уровне оказывается менее эффективен, чем код, переведённый с высокого уровня с учётом сложившихся реалий! А сложившиеся реалии могут быть разные: новые процессоры, учёт профайла и т.д. и т.п. Разумеется это относится к достаточно эффективным асбтракциям — таким как C, Java или JavaScript. Я не могу представить себе ситуацию когда манипуляция бинарными данными будет медленнее, чем работа с XML. Возможно когда речь зайдёт о триллионах строк кода…
> Начиная с некоторого уровня сложности системы код, написанный на низком уровне оказывается менее эффективен, чем код, переведённый с высокого уровня с учётом сложившихся реалий!
А то я тут рассуждаю про код под железо, сшитое при царе Гороже?! Когда проводятся аналогии — они и должны быть аналогиями.
Если железо перешло на новые стадии, то, естественно, код, который не в силах учитывать эти стадии будет менее эффективным. Это прописная истина.
> И даже JIT, написанный на ассемблере (и потому не включащий в себя многих оптимизаций) проиграет JIT'у, написанному на C/C++.
Это как? Мне реально интересно. Я правильно понимаю — Си-транслятор, написанный на асме (при этом Си-шные обертки внтри себя имеют по несколько десятков ассемблерных вставок, чтобы предусмотреть «все случаи жизни») быстрее того же самого асма (того же самого! а не того, который был был при Рамзесе-III написан и не учитывал новые возможности железа).
Какой смысл сравнивать то, что не может учитывать новых особенностей с тем, что это может делать? (и в случае с JIT'ом и PBO еще и делает это в рантайме, подстраиваясь под текущие аппаратные возможности) — обычная подмена понятий.
Кстати, JIT — такая же высокая абстракция, которая жертвует различного рода ресурсами (требует время на постоянную, больше памяти и т.д.), для создания прогресса. Как иначе создать кросс-платформенность, кроме как интерпретации (с промежуточным байт-кодом, и где-то — компиляции этого байт в нэйтив-код)? — Ответ — давайте потратим чуть больше времени на компиляцию некоторых критичных кусков прямо в рантайм, но зато будем учитывать специфику аппаратуры. Но, если если сравнивать сравнимое и аналогичное, то это и ежу понятно, что статичный скомпилированный код будет быстрее интерпретируемого (не важно какие оптимизации (JIT, PBO и т.д.) используются при этом).
При этом, несомненно, JIT добавляет в интерпретируемость приближение с компилируемым скоростям.
Все эти оптимизации — есть так же абстрагированные сущности прогресса и, конечно, очень важны в скорости разработки (для которой все это создается).
А то я тут рассуждаю про код под железо, сшитое при царе Гороже?! Когда проводятся аналогии — они и должны быть аналогиями.
Если железо перешло на новые стадии, то, естественно, код, который не в силах учитывать эти стадии будет менее эффективным. Это прописная истина.
> И даже JIT, написанный на ассемблере (и потому не включащий в себя многих оптимизаций) проиграет JIT'у, написанному на C/C++.
Это как? Мне реально интересно. Я правильно понимаю — Си-транслятор, написанный на асме (при этом Си-шные обертки внтри себя имеют по несколько десятков ассемблерных вставок, чтобы предусмотреть «все случаи жизни») быстрее того же самого асма (того же самого! а не того, который был был при Рамзесе-III написан и не учитывал новые возможности железа).
Какой смысл сравнивать то, что не может учитывать новых особенностей с тем, что это может делать? (и в случае с JIT'ом и PBO еще и делает это в рантайме, подстраиваясь под текущие аппаратные возможности) — обычная подмена понятий.
Кстати, JIT — такая же высокая абстракция, которая жертвует различного рода ресурсами (требует время на постоянную, больше памяти и т.д.), для создания прогресса. Как иначе создать кросс-платформенность, кроме как интерпретации (с промежуточным байт-кодом, и где-то — компиляции этого байт в нэйтив-код)? — Ответ — давайте потратим чуть больше времени на компиляцию некоторых критичных кусков прямо в рантайм, но зато будем учитывать специфику аппаратуры. Но, если если сравнивать сравнимое и аналогичное, то это и ежу понятно, что статичный скомпилированный код будет быстрее интерпретируемого (не важно какие оптимизации (JIT, PBO и т.д.) используются при этом).
При этом, несомненно, JIT добавляет в интерпретируемость приближение с компилируемым скоростям.
Все эти оптимизации — есть так же абстрагированные сущности прогресса и, конечно, очень важны в скорости разработки (для которой все это создается).
Это как? Мне реально интересно. Я правильно понимаю — Си-транслятор, написанный на асме (при этом Си-шные обертки внтри себя имеют по несколько десятков ассемблерных вставок, чтобы предусмотреть «все случаи жизни») быстрее того же самого асма (того же самого! а не того, который был был при Рамзесе-III написан и не учитывал новые возможности железа).Того же самого не бывает! В этом весь прикол. JIT и PBO порождают код «на лету» и потому могут обогнать статический ассемблерный код! И вы не сможете написать «правильный» код, который смог бы с этим бороться потому что вариантов — бесконечное число (на самом деле конечно, конечное — но разница между гуголом и бесконечностью невелика). Конечно вы можете на ассемблере написать код, который будет порождать реальный код на основании некоторых таблиц, но… тогда реальная программа у вас окажется зашитой вот в этих самых таблицах — и это и будет ваш язык высокого уровня. С чем боролись, на то и напоролись!
При этом, несомненно, JIT добавляет в интерпретируемость приближение с компилируемым скоростям.Есть задачи на которых JIT обгоняет и PBO и ассемблер. Сейчас пока таких не много, но как повернётся дело в будущем? Посмотрим…
> Есть задачи на которых JIT обгоняет и PBO и ассемблер.
Ладно, не охота мне разводить спор, но по-любому — заточенные под одно и тоже железо асм будет быстрее си (при этом оба компилируемые) и уж тем более они оба будут быстрее интерпретируемой сущности (хоть и JIT-оптимизатором).
Другой вопрос, если говорить только лишь о динамических, интерпретируемых сущностях — так для этого, повторю, эти оптимизаторы (JIT и т.д.) создавались, чтобы быть быстрее.
Ладно, не охота мне разводить спор, но по-любому — заточенные под одно и тоже железо асм будет быстрее си (при этом оба компилируемые) и уж тем более они оба будут быстрее интерпретируемой сущности (хоть и JIT-оптимизатором).
Другой вопрос, если говорить только лишь о динамических, интерпретируемых сущностях — так для этого, повторю, эти оптимизаторы (JIT и т.д.) создавались, чтобы быть быстрее.
Ладно, не охота мне разводить спор, но по-любому — заточенные под одно и тоже железо асм будет быстрее си (при этом оба компилируемые) и уж тем более они оба будут быстрее интерпретируемой сущности (хоть и JIT-оптимизатором).Вот нифига подобного! JIT видит программу в целом и видит поток её исполнения — и может на основе этого знания делать соотвествующие оптимизации. Например: у вас в программе подгружается модуль работы с джойстиком. В каком-то месте вызываются функции, зависящие от типа джойстика. Но JIT замечает что в реально запущенной программе джойстик — только один. И этот вычисляемый переход (весьма дорогой на современных CPU) можно заменить на безусловный (стоимость которого стремится к нулю). JIT может это сделать так как он знает что других джойстиков в программе нет, а буде они появятся — программа будет перекомпилирована. PBO тоже может заметить такие вещи и хотя ему придётся подстраховаться (код будет состоять из двух команд: проверка на тип джойстика и переход «на медленную часть функции» если тип «неправильный»), но код всё равно будет быстрее чем то, что вы напишите руками на ассемблере!
Кстати речь идёт не только об изменениях в железе: точно также JIT может «заметить» что, скажем, программа долгое время не использует функции работы с файлами для работы с файлами на диске (а в основном использует их для работы с сетью) и «временно отключить» части, которые нужны только для работы с файловой системой. А когда надо будет — включить.
Если вдуматься то современные процессоры (все эти предсказания ветвлений, спекулятивные загрузки и прочее) занимаются тем, что делает JIT — но свободы для манёвра у них на порядок меньше!
Другой вопрос, если говорить только лишь о динамических, интерпретируемых сущностях — так для этого, повторю, эти оптимизаторы (JIT и т.д.) создавались, чтобы быть быстрее.Это самоочевидно. Но вы забываете что кроме динамических, интерпретируемых задач есть динамический мир! У большинства компьютеров только одна клавиатура — но воткните в USB-порт сканер штрих-кодов и их станет две! Ассемблерной программе нужно всё это учитывать и на все эти проверки уходит время, а JIT и, в меньшей степени, PBO могут «срезать углы» — за счёт того, что они могут отследить редкие, нестандартные, случаи и в этом случае сделать всё ну очень медленно, но зато в 99.9% случаев они будут обгонять ассемблер.
Правда надо сказать что для того, чтобы эти эффекты увидеть нужно писать очень аккуратно, а большинство программистов на ЯВУ этим себя не утруждает (в отличие от использующих ассемблер).
А, да, это — да. А на каком этапе (какой большой ИИ заложен в различные версии JIT?) определяется, что модуль с джойстиком можно выбросить из кода? Для подобных статичных условий есть известные препроцессорные директивы, aka
При этом в код никогда не попадет «a», если CONFIG_TEST не задан.
А в случае с джойстиком? Допустим, есть кнопка, по нажатию на которую, осуществляется то или иное действие (в зависимости от присутствия джойстика). Джойстик не подключен, компилируется программа, из нее выбрасывается часть кода с if'ом для джойстика. Дальше нажимается кнопка — что должно произойти? Выдаться сообщение — «JIT выкинул эту часть кода»? Или начнется тотальная перекомпиляция?
Я понимаю, зачем нужен JIT и что он делает; мне интересно, на каком моменте определяется — когда выбрасывать (по сути — сделать статичными if'ы как в случае с #ifdef) тот или иной кусок, а когда — восстанавливать.
#ifdef CONFIG_TEST int a = 10; #endif
При этом в код никогда не попадет «a», если CONFIG_TEST не задан.
А в случае с джойстиком? Допустим, есть кнопка, по нажатию на которую, осуществляется то или иное действие (в зависимости от присутствия джойстика). Джойстик не подключен, компилируется программа, из нее выбрасывается часть кода с if'ом для джойстика. Дальше нажимается кнопка — что должно произойти? Выдаться сообщение — «JIT выкинул эту часть кода»? Или начнется тотальная перекомпиляция?
Я понимаю, зачем нужен JIT и что он делает; мне интересно, на каком моменте определяется — когда выбрасывать (по сути — сделать статичными if'ы как в случае с #ifdef) тот или иной кусок, а когда — восстанавливать.
я забыл написать самое важное действие — дальше джойстик подключается во время работы программы (с уже выкинутыми кусками кода для работы с джойстиком) и — Дальше нажимается кнопка
А на каком этапе (какой большой ИИ заложен в различные версии JIT?) определяется, что модуль с джойстиком можно выбросить из кода?На этапе исполнения. Когда несколько раз вызывается одна и та же функция из одного места в программе JIT может решить что она и дальше так будет вызываться. Если в принципе функция виртуальная (то есть на-final), но в реальности есть только одна реализация то JIT может выкинуть эту виртуальность.
я забыл написать самое важное действие — дальше джойстик подключается во время работы программы (с уже выкинутыми кусками кода для работы с джойстиком) иJIT забывает всё что он ранее накомпилировал. У него появляется новый класс и предположение что вызов на самом деле статический становится неверно. Когда этот же кусок кода скопилируется второй раз — он уже будет отрабатывать события, связанные с джойстиком.
Тут важно выдержать баланс между подстройкой под внешнюю среду (ускоряющей программу) и затратами времени на эту подстройку (замедляющими программу).
Разумеется всю эту логику с джойстиком можно вставить в программу на ассемблере тоже, но фишка в том, что JIT способен отлавливать такие фишки по всему коду программы, а человек, пишущий код на ассемблере сможет предусмотреть весьма ограниченный набор вариантов.
> Когда несколько раз вызывается одна и та же функция из одного места в программе JIT может решить что она и дальше так будет вызываться
что значит «может решить»? А если функция 99 раз вызвалась так, а вот на сотый — по-другому? Не правильно. JIT, анализирует какой-то главный условный блок, а потом может удалить все остальные блоки кода, завязанные на это условие (я так понимаю). Т.е. однозначное детерминированы участки. А решения «авось будет, авось нет» — такого JIT не делает.
> Тут важно выдержать баланс между подстройкой под внешнюю среду (ускоряющей программу) и затратами времени на эту подстройку (замедляющими программу).
Ну вот это точно.
что значит «может решить»? А если функция 99 раз вызвалась так, а вот на сотый — по-другому? Не правильно. JIT, анализирует какой-то главный условный блок, а потом может удалить все остальные блоки кода, завязанные на это условие (я так понимаю). Т.е. однозначное детерминированы участки. А решения «авось будет, авось нет» — такого JIT не делает.
> Тут важно выдержать баланс между подстройкой под внешнюю среду (ускоряющей программу) и затратами времени на эту подстройку (замедляющими программу).
Ну вот это точно.
что значит «может решить»? А если функция 99 раз вызвалась так, а вот на сотый — по-другому?А та же самая фигня что и в спекулятивном исполнении в процессоре: JIT должен гарантировать что «если что» созданных им код всё откатит и случайные неправильные изменения исправит.
JIT, анализирует какой-то главный условный блок, а потом может удалить все остальные блоки кода, завязанные на это условие (я так понимаю). Т.е. однозначное детерминированы участки. А решения «авось будет, авось нет» — такого JIT не делает.Делает. И Sun'овская Java делает и V8 делает. Грубо говоря один-два самых распространённых варианта он может вставить в код, остальное — в медленно исполняющуюся подпрограмму. Если эта подпрограмма слишком часто вызывается — всё перекомпилируется. Или нет. В зависимости от результатов профайлера.
Самое обидное что вся эта мощь не спасает от простого головотяпства: JIT, спекулятивное исполнение, параллельная сборка мусора и… какой-нибудь хитрый Injection Framework замедляющий скорость в 100 раз. А потом ещё удивляются почему программы на Java тормозят. Нет — тут дело не в отказе от ассемблера…
> А та же самая фигня что и в спекулятивном исполнении
Ага, при этом эта «работа над ошибками» (если предсказание было неверным) займет много больше времени. А какой большой алгоритм за этим стоит? При спекулятивном исполнении команд, команды загрузки данных выполняются первыми (далее, в местах, где эти данные используются — сначала идет проверка, что данные не повредились (может, какая-то инструкция записала данные поверх) — это тоже время, и если данные повредились, производится «работа над ошибками» по восстановлению данных). А здесь что?
> Делает.… В зависимости от результатов профайлера.
Т.е. JIT опирается только на профайлер?
Ага, при этом эта «работа над ошибками» (если предсказание было неверным) займет много больше времени. А какой большой алгоритм за этим стоит? При спекулятивном исполнении команд, команды загрузки данных выполняются первыми (далее, в местах, где эти данные используются — сначала идет проверка, что данные не повредились (может, какая-то инструкция записала данные поверх) — это тоже время, и если данные повредились, производится «работа над ошибками» по восстановлению данных). А здесь что?
> Делает.… В зависимости от результатов профайлера.
Т.е. JIT опирается только на профайлер?
А реальные примеры есть с тестами и замерами? Просто реально интересно. Теоретически-то оно хорошо, и для интерпретируемых языков, само-собой, несет увеличение производительности (пусть памяти больше жрет, пусть тратит время каждый раз на компиляцию кусков байт-кода и отсеиванию ненужных). Хочется, действительно, посмотреть, что интерпретируемый язык с JIT'ом может обгонять скомпилированный код.
Под рукой нету, но с ними вообще беда: всегда можно заявить что «ну мы вот тут перепишем вашу программу — и С/C++ опять вашу java'у обгонят». Но тут ведь фишка как раз в том, что программа подстраивается под изменяющуюся среду! Поищите в гугле на «Java faster than C++» (скажем вот). Там есть много статей, обсуждений, критики и прочего. В любом случае речь уже давно не стоит как: «может ли JIT обогнать компилируемый язык или ассемблер?», а как "часто ли JIT обгоняет компилируемый язык или ассемблер?". Ответ на него: да, такое бывает, но редко. Сторонникам Java этот ответ не нравится (они бы предпочли бы чтобы ответ был «да, почти всегда»), противников он бесит (как-так: Java и обгоняет ассемблер?), но таква вот объективная истина на сегодня…
P.S. JavaScript даже с JIT'ом пока отстаёт и от Java и от C/C++… Но там ещё JIT'ы очень примитивные — посмотрим как оно дальше будет…
P.S. JavaScript даже с JIT'ом пока отстаёт и от Java и от C/C++… Но там ещё JIT'ы очень примитивные — посмотрим как оно дальше будет…
Ок, раз на то пошло, давайте тогда примерами, а не пустыми минусами ;) А то несерьезно как-то.
В качестве примера — сравните время работы тупого когда, который проверяет много вложенных условий по типу:
if (FLAGS::flag_A) {
if (FLAGS:: flag_B) {
return 1;
}
if (FLAGS::flag_B) {
return 2;
}
} else {
if (FLAGS:: flag_B) {
return 3;
}
if (FLAGS::flag_B) {
return 4;
}
}
Если все эти флаги будут заданы в командной строке (а не в исходниках программы), то ассемблерной программе придётся либо заниматься хитрыми трюками с динамической компиляцией самой себя, либо мириться с изрядными потерями времени и памяти, JIT же может просто выкинуть лишние участки кода.
Как я уже говорил: конечно на ассемблере можно сделать всё что на более высокоуровневом языке, но в какой-то момент оказывается что реальная логика программы у вас лежит не в коде на ассемблере, а в некоторых таблицах, которые управляют динамической рекомпиляцией программы на ассемблере! А это значит что фактически у вас программа оказалась переведена с ассемблера на какой-то метаязык…
Посмотрите на историю с ftrace: фактически ребятки создали мини-JIT именно для ускорения программы (ну и немного в нём налажали, но это уже другая история).
if (FLAGS::flag_A) {
if (FLAGS:: flag_B) {
return 1;
}
if (FLAGS::flag_B) {
return 2;
}
} else {
if (FLAGS:: flag_B) {
return 3;
}
if (FLAGS::flag_B) {
return 4;
}
}
Если все эти флаги будут заданы в командной строке (а не в исходниках программы), то ассемблерной программе придётся либо заниматься хитрыми трюками с динамической компиляцией самой себя, либо мириться с изрядными потерями времени и памяти, JIT же может просто выкинуть лишние участки кода.
Как я уже говорил: конечно на ассемблере можно сделать всё что на более высокоуровневом языке, но в какой-то момент оказывается что реальная логика программы у вас лежит не в коде на ассемблере, а в некоторых таблицах, которые управляют динамической рекомпиляцией программы на ассемблере! А это значит что фактически у вас программа оказалась переведена с ассемблера на какой-то метаязык…
Посмотрите на историю с ftrace: фактически ребятки создали мини-JIT именно для ускорения программы (ну и немного в нём налажали, но это уже другая история).
Действительно, при мощностях современного железа, уменьшение эффективности сгенерированного кода относительно не заметно. Но это не значит, что ухудшения нет!Не значит. Но тут тоже срабатывает эффект масштаба: отличный вылизанный ассемблерный код к моменту выхода твоего творения в свет (через годы, а то и десятилетия) будет однозначно хуже того, что сгенерирует компилятор ибо железо со временем меняется и оно затачивается под компилятор, а не под ручной ассембленый код. Простейший пример: набор инструкций x86 содержит операции работы со строками — но на соврменных процессорах гораздо быстрее сделать обычный цикл и просто набором mov'ов всё скопировать! Хотя на старых процессорах было наоборот.
Таким образом использованием компилятора генерирует относительно неплохой код (но не самый лучший), а прямое использование ассемблера — однозначно никуда не годный код…
>>вылизанный ассемблерный код к моменту выхода твоего творения в свет (через годы, а то и десятилетия)
Какие годы? Вы о чём? Часто на асме писать проще и быстрее чем на том же C.
Проблема совершенно в другом — в поддержке этого кода.
Когда я смотрю в то, что GCC генерит под PowerPC, иногда чуть ли не слёзы наворачиваются.
Какие годы? Вы о чём? Часто на асме писать проще и быстрее чем на том же C.
Проблема совершенно в другом — в поддержке этого кода.
Когда я смотрю в то, что GCC генерит под PowerPC, иногда чуть ли не слёзы наворачиваются.
Какие годы? Вы о чём?О разработке ПО, однако. В выходящих сейчас «новых» продуктах зачастую сидит код даже не из 90х, а и из 80х. За это время микроархитектура успевает смениться кардинально.
Когда я смотрю в то, что GCC генерит под PowerPC, иногда чуть ли не слёзы наворачиваются.А вы уверены, что то, что породите вы и что будет вам казаться красивым и замечательным будет реально хорошо работать на будущих поколениях PowerPC? Да даже и на нанешнем: PowerPC бывают разные и то что хорошо для суперскаляра вполне может оказаться не самым лучшим вариантом для какой-нибудь простой версии.
1) Предпочитаю не работать на проектах, срок разработки которых > 2 лет. Я не мазохист.
Я не верю в реюзинг кода. Обычно многое из того что было написано 2 года назад, достойно быть переписанным с чистого листа под конкретную задачу.
Производительность — приоритет. Остальное неважно.
2) Я пишу под конкретную фиксированную платформу. Пишу здесь и сейчас, а не в будущем под несуществующие архитектуры. Временные рамки обозначены.
Я не верю в реюзинг кода. Обычно многое из того что было написано 2 года назад, достойно быть переписанным с чистого листа под конкретную задачу.
Производительность — приоритет. Остальное неважно.
2) Я пишу под конкретную фиксированную платформу. Пишу здесь и сейчас, а не в будущем под несуществующие архитектуры. Временные рамки обозначены.
1) Предпочитаю не работать на проектах, срок разработки которых > 2 лет. Я не мазохист.Я правильно понял что:
1. Вы не пользуетесь операционной системой.
2. Вы не пользуетесь ни C, Perl'ом, Python'ом и JavaScript'ом.
3. Вы не создаёте серъёзных проектов, которыми будут пользоваться миллионы людей.
Простите, а какое отношение вся ваша деятельность имеет к IT? Мне кажется что вы либо кривите душой и выдаёте желаемое за действительное (наиболее вероятный подход), либо всё ваше программирование — это какие-то жёсткий embed, который, конечно, важен, но составляет ничтожную часть IT.
2) Я пишу под конкретную фиксированную платформу. Пишу здесь и сейчас, а не в будущем под несуществующие архитектуры. Временные рамки обозначены.То есть это всё-таки embed? Ну так если всё что вы делаете — выпуск гвоздей, то не нужно рассуждать о строительстве домов и современной архитектуре.
>>Я правильно понял что:
Неправильно. Откуда вы выудили столько информации из этой строки?
Там написано только то, что я не хочу как зомби выдрачивать один проект на протяжении десятилетий.
Допустим правда, что JS я не пользуюсь, но это ничего не меняет.
>>3. Вы не создаёте серъёзных проектов, которыми будут пользоваться миллионы людей.
Ну да, «что ты сделал для хип-хопа?» весомый аргумент.
Я работаю только с проектами которые доставляют мне фан. В данный момент это низкоуровневое программирование и железо.
Да и сколько вам нужно миллионов? Пары миллионов достаточно?
>>не нужно рассуждать о строительстве домов и современной архитектуре.
Я не рассуждаю об абстрактных вещах, я просто подверг сомнению ваше беаппеляционное заявление
«ассемблерный код к моменту выхода твоего творения в свет (через годы, а то и десятилетия)»
Ассемблерный код на сроки выхода проекта не может сильно повлиять, потому что он не нужен везде где попало, а только в некоторых местах, где реально можно поднять скорость.
Асм влияет на сложность поддержки кода и понимания его другими,
но написание асм-кода не займёт сильно больше времени чем написание оптимизированного кода на C++, а часто и меньше его.
Профессионал сам решит где и что нужно применять, и чужие стоны его не будут волновать.
Неправильно. Откуда вы выудили столько информации из этой строки?
Там написано только то, что я не хочу как зомби выдрачивать один проект на протяжении десятилетий.
Допустим правда, что JS я не пользуюсь, но это ничего не меняет.
>>3. Вы не создаёте серъёзных проектов, которыми будут пользоваться миллионы людей.
Ну да, «что ты сделал для хип-хопа?» весомый аргумент.
Я работаю только с проектами которые доставляют мне фан. В данный момент это низкоуровневое программирование и железо.
Да и сколько вам нужно миллионов? Пары миллионов достаточно?
>>не нужно рассуждать о строительстве домов и современной архитектуре.
Я не рассуждаю об абстрактных вещах, я просто подверг сомнению ваше беаппеляционное заявление
«ассемблерный код к моменту выхода твоего творения в свет (через годы, а то и десятилетия)»
Ассемблерный код на сроки выхода проекта не может сильно повлиять, потому что он не нужен везде где попало, а только в некоторых местах, где реально можно поднять скорость.
Асм влияет на сложность поддержки кода и понимания его другими,
но написание асм-кода не займёт сильно больше времени чем написание оптимизированного кода на C++, а часто и меньше его.
Профессионал сам решит где и что нужно применять, и чужие стоны его не будут волновать.
Вы не согласны с тем, что ассемблерный (а точнее, машинный) код, полученный в рещультате компиляции высокоуровневой программы является уродским? Во всяком случае по сравнению с ассемблерным кодом написанном вручную.А вы видели то, что порождает современный компилятор? Вот реально? Мне — доводилось (когда в нём глюки начинаются). Да, есть и уродские места, но зачастую возникает ощущение чуда. Простейший пример (просто наобум из головы):
int foo(int v) {
if (v>42)
return 5;
else
return 7;
}
на выходе получаем:
.globl foo
.type foo, @function
foo:
xorl %eax, %eax
cmpl $43, %edi
setl %al
leal 5(%rax,%rax), %eax
ret
Что называется ни убавить, ни прибавить. Да, есть случаи, когда компилятор генерит откровенную «лажу», иногда и пресловутые calling convention мешают ему сделать хороший код (и если писать на ассемблере, то на это можно «забить» если будут основания), но есть посмотреть в целом, то выдержать на этом уровне программу больше одного-двух килобайт руками — не сдюжишь…
абсолютно согласен. хотя это верно для обычных компиляторов. те, которые позволяют программировать микроконтроллерны на СИ частенько генерят бред.
Ещё смешнее, что автор статьи путает ассемблерный код и машинный. Язык ассемблера — это всё-таки язык, предназначенный для человека. Генерация ассемблерного кода компиляторами — приятная опция, не более, и она встречается далеко не везде. А основное назначение — генерировать машинный код.
И я, пожалуй, промолчу про уровень знаний автора в ASP.NET, и особенно в пресловутых «темах», про которые он так много пишет. ;)
И я, пожалуй, промолчу про уровень знаний автора в ASP.NET, и особенно в пресловутых «темах», про которые он так много пишет. ;)
Ещё смешнее, что автор статьи путает ассемблерный код и машинный.См. 1-ю сноску.
Вы же на основе своих выкладок делаете далекоидущие выводы. Но эти выводы можно делать только если речь идёт об ассемблерном коде, никак ни о машинном. А для Вас это одно и то же.
Фактических ошибок очень много. Имитация стека и вызов функций относятся не к епархии ассемблера, а к архитектуре. В процессорах Intel, начиная с 8086, стек присутствовал, и были соответствующие инструкции для работы с ним. Точно так же, как и инструкции для вызова функций. Точно так же, как и инструкции для целочисленного умножения. Соответственно, всё это существовало и в языке ассемблера.
Резюме: ошибки в посылках, ошибки в выводе. И это я уже не говорю об антимайкрософтовской идеологии, которая статью делает ещё одним лозунгом.
Фактических ошибок очень много. Имитация стека и вызов функций относятся не к епархии ассемблера, а к архитектуре. В процессорах Intel, начиная с 8086, стек присутствовал, и были соответствующие инструкции для работы с ним. Точно так же, как и инструкции для вызова функций. Точно так же, как и инструкции для целочисленного умножения. Соответственно, всё это существовало и в языке ассемблера.
Резюме: ошибки в посылках, ошибки в выводе. И это я уже не говорю об антимайкрософтовской идеологии, которая статью делает ещё одним лозунгом.
>>… относятся не к епархии ассемблера, а к архитектуре.
я так понял что речь о макроассемблерах и таких штуках как INVOKE в masm
я так понял что речь о макроассемблерах и таких штуках как INVOKE в masm
Про то и пишу: в огороде бузина, в Киеве дядька. Язык ассемблера, как таковой, современным компиляторам не нужен. Не фигурирует он в процессе производства программ, а если и фигурирует, то в редчайших случаях.
Автор прав в том, что HTML/CSS/JS — это устаревшая технология. Не фактически, но морально. Будущее всё-таки за виртуальными машинами — будь то .NET или JVM или аналогичное решение от Adobe (но им, наверное, всё-таки слабо). Но этот вывод у автора как-то размазан и даже нивелирован. Вроде как, вывод неправильный (неполиткорректный), и поэтому автору не нравится. А уж количество фактических ошибок просто подрывает доверие к материалу.
Автор прав в том, что HTML/CSS/JS — это устаревшая технология. Не фактически, но морально. Будущее всё-таки за виртуальными машинами — будь то .NET или JVM или аналогичное решение от Adobe (но им, наверное, всё-таки слабо). Но этот вывод у автора как-то размазан и даже нивелирован. Вроде как, вывод неправильный (неполиткорректный), и поэтому автору не нравится. А уж количество фактических ошибок просто подрывает доверие к материалу.
Автор прав в том, что HTML/CSS/JS — это устаревшая технология. Не фактически, но морально.Я рад, что Вы со мной согласились, но я имел в виду как-раз противоположенное :-)
Я считаю, что HTML/CSS/JS — не являются устаревшей технологией! И они лишь воспринимаются многими разработчиками как устаревшие, из-за недооценки заложенных в них гибкости и мощи.
Другое дело, что эти технологии, перестав развиваться как технологии развития web-приложений, действительно могут устареть, и уйти со сцены, уступив место Flex или Silverlight. Подобно тому, как интерфейсы на основе Turbo Vision уступили место windows'овским интерфейсам («гибель физическая»).
Но, именно для того, чтобы, чтобы HTML/CSS/JS не прекращали развиваться, как технологии создания web-приложений, и была создана WHATWG. И HTML5 — один из шагов такого развития.
Будущее всё-таки за виртуальными машинами — будь то .NET или JVM или аналогичное решение от AdobeПолностью согласен. Но, пусть этой виртуальной машиной будет браузер!
Ну вот как это у Вас получается? TurboVision уступили место Windows… Вы не поверите, но TurboVision появилась после Windows. Windows стала востребована позднее, когда массово стали закупать 386-е машины, а так то она с середины 80-х существует. Да и это разного класса продукты — TurboVision библиотека, каких тогда были десятки. Windows — среда исполнения. Их сравнивать бессмысленно. Ну вот Borland после TV разработала библиотеку VCL (которая использовалась в Delphi и C++ Builder) — её разве можно сравнивать с Windows?
И, кстати. Зачем Вы держитесь за HTML/CSS/JavaScript, как инструменты разработки вебприложений? Вам нравится писать низкоуровневый код?
Мне вот наоборот: я переползаю на F# и Haskell. Вот где поле для программистской деятельности.
И, кстати. Зачем Вы держитесь за HTML/CSS/JavaScript, как инструменты разработки вебприложений? Вам нравится писать низкоуровневый код?
Мне вот наоборот: я переползаю на F# и Haskell. Вот где поле для программистской деятельности.
Windows стала востребована позднее, когда массово стали закупать 386-е машины, а так то она с середины 80-х существует. Да и это разного класса продукты — TurboVision библиотека, каких тогда были десятки.У вас в этом месте каша. Да, Windows появилась раньше Turbo Vision — но это была библиотека плюс кучка демо-программ. Aldus Pagemaker поставлялся с Windows, а не наоборот! А вот уже Windows NT — это другая история. Это была полноценная операционка, но она появилась заметно позже Turbo Vision…
Нет, это у вас в этом месте каша. Windows никогда не была просто библиотекой. До полной операционной системы есть не хватало загрузчика, и загрузчиком выступала DOS.
Короче говоря, учите матчасть. И по поводу NT — посмотрите на копирайт во время загрузки. С удивлением обнаружите там 1985-2001 (если речь идёт об XP).
[утирает пот]
Короче говоря, учите матчасть. И по поводу NT — посмотрите на копирайт во время загрузки. С удивлением обнаружите там 1985-2001 (если речь идёт об XP).
[утирает пот]
Нет, это у вас в этом месте каша. Windows никогда не была просто библиотекой. До полной операционной системы есть не хватало загрузчика, и загрузчиком выступала DOS.Ну тогда с тем же успехом можно сказать что и GEM и DESQview/X и куча других подобных оболочек — это всё были разные операционки.
Единственная распространённая полноценная операционка тех времён, загрузчиком которой был DOS — это Novell Netware: она стартовала из MS DOS, но дальше выгружала её из памяти и с диском и перефирией работала самостоятельно. А всё остальное — это надстройки.
Короче говоря, учите матчасть. И по поводу NT — посмотрите на копирайт во время загрузки. С удивлением обнаружите там 1985-2001 (если речь идёт об XP).Ага. А Solaris вообще от 70х годах пишет. Значит ли это что в 70е годы кто-то мечтал от SPARC'е?
А Вы читать умеете в принципе? Ладно, верю, что умеете, а читать внимательно? Где в моём посте написано, что Windows операционка? У меня там написано «среда исполнения». Пока ещё не операционка, но уже и не библиотека. Причём тут полноценные ОС?
> Ага. А Solaris вообще от 70х годах пишет.
Принимайте к сведению. Работа над NT началась в 85-м году, это раньше, чем работа над TurboVision. Вот и всё.
> Ага. А Solaris вообще от 70х годах пишет.
Принимайте к сведению. Работа над NT началась в 85-м году, это раньше, чем работа над TurboVision. Вот и всё.
Ну вот как это у Вас получается? TurboVision уступили место Windows… Вы не поверите, но TurboVision появилась после Windows.Я имею в виду вот что:
Turbo Vision была оконной библиотекой для текстового режима.
Это была гениальная библиотека: она выжала из этого текстового режима 100%.
Но, несмотря на свою гениальность, преодолеть фундаментальные ограничения текстового режима (матрица из 80 * 25, невозможность проводить изогнутые линии, 256 цветов и т.д.) она не могла.
Поэтому, она и ушла в историю, уступив место графическим библиотекам Windows… (Не потому, что она появилась раньше, или позже Windows, а потому, что в Windows-библиотеках отстутствовали фундаментальные ограничения текстового режима).
Тоже самое может случиться с HTML/CSS/JS, если они не будут развиваться.
В этих технологиях пока есть ряд мультимедийных ограничений, которые, как не старайся, какую изобретательность не применяй, разработчикам web-приложений преодалеть не возможно.
И, поэтому, HTML/CSS/JS могут уступить тем технологиям, в которых нет этих фундаментальных ограничений, например Flex или Silverlight.
Но, я надеюсь, под руководтсвом WHATWG эти технологии будут развиваться как технологии создания Web-приложений, и «физической гибели» не случится.
И, кстати. Зачем Вы держитесь за HTML/CSS/JavaScript, как инструменты разработки вебприложений? Вам нравится писать низкоуровневый код?В этой статье я как раз хотел показать, что HTML/CSS/JS-код не является низкоуровневым!
Что он только воспринимается некоторыми разработчиками как низкоуровневый из-за неверного понимания.
И что, при правильном понимании, работа с HTML/CSS/JavaScript является такой же высокоуровневой, что и работа с серверным контролом, а порой, и даже более высокоуровневой!
См. пример, где мы можем «на лету» превратить список в дерево, дерево в контекстное меню, а в режиме печати снова представит его в виде списка и скопировать в виде списка в Word, просто подменив CSS и JS-класс! Такой высокоуровневой возможности в серверных контролах нет (поправьте меня, если я не прав)!
Поэтому я так выступаю за классические HTML/CSS/JavaScript, понимаю из высокоуровневость, ценю красоту и гибкость и выступаю против отказа от использования это web-парадигмы в строну имитации десктопных GUI!
А зачем вы так часто используете выделения? Возникает ощущение, как будто вы или кричите, или давите. Зачем?
> Но, несмотря на свою гениальность, преодолеть фундаментальные
> ограничения текстового режима (матрица из 80 * 25, невозможность
> проводить изогнутые линии, 256 цветов и т.д.) она не могла.
Странно, что Вы именно об этом написали. В 91-м году я со своим другом перевёл паскалевскую TV в графический режим. Это оказалось несложно — весь вывод там осуществлялся через одну-единственную функцию, которую мы и переопределяли.
Вывод я писал на ассемблере, и там пришлось серьёзно заниматься оптимизацией. Не знаю, в курсе ли Вы, но в EGA и 16-тицветных режимах VGA вывод осуществлялся через битовые плоскости. Существовало 3 режима вывода, весьма запутанные. В конечном итоге, за месяц удалось довести задачу до конца, и TV работала даже в модных тогда SVGA-режимах 800*600*16. 256 цветов мы не использовали просто потому, что мониторы в те времена не поддерживали высокого разрешения для этих режимов.
А делали мы это для заказчиков, которые писали графические приложения. Естественно, там были и изогнутые линии (эка невидаль! в текстовом режиме даже прямые линии не всегда рисуются). Так что зря Вы говорите, что TV отмерла из-за этого. :)
Кстати, Вы ошибаетесь даже в том, почему именно TV стала столь популярна. Дело в том, что тогда это была единственная ОО-библиотека среди ДОС-программистов (Си++ отставал на 2-3-4 года). Поскольку ОО идеально подходит для интерфейсов, естественно, разрабатывать программы с GUI она позволяла значительно проще.
> Поэтому, она и ушла в историю, уступив место графическим библиотекам
> Windows… (Не потому, что она появилась раньше, или позже Windows, а
> потому, что в Windows-библиотеках отстутствовали фундаментальные
> ограничения текстового режима).
А я ещё раз говорю, что Windows — это среда исполнения, почти операционная система. Там, помимо графической составляющей… Кстати, Вы на Windows API писали когда-нибудь? Там очень неудобно всё делается, поскольку приходиться имитировать ОО-стиль средствами процедурных языков. В TV всё значительно проще и удобнее. На порядок, наверное.
Так вот, в Windows 3.0 помимо графической составляющей была уже невытесняющая многозадачность, виртуальная память, межпрограммное взаимодействие, собственное управление дисками (что естественно, ведь ДОС-овские функции не всегда были реентерабельными). А в 3.1 появилась поддержка локальных сетей.
TV и Windows — это продукты разного класса. Странно, что приходиться писать такие элементарные вещи. Ещё раз думаю, что Вы строите теорию, не опираясь на фактическую базу. А это чревато.
> В этих технологиях пока есть ряд мультимедийных ограничений, которые,
> как не старайся, какую изобретательность не применяй, разработчикам
> web-приложений преодалеть не возможно.
> И, поэтому, HTML/CSS/JS могут уступить тем технологиям, в которых нет
> этих фундаментальных ограничений, например Flex или Silverlight.
Ну вот, вы же сами всё понимаете.
> Но, я надеюсь, под руководтсвом WHATWG эти технологии будут
> развиваться как технологии создания Web-приложений, и «физической
> гибели» не случится.
Вот я и интересуюсь — для чего надеетесь? Зачем держитесь за то, что уже морально устарело? Пока Вы будете играть в бирюльки, вручную на js рисуя графики, остальные разработчики возьмут готовый chart-компонент и будут решать высокоуровневые интересные задачи. Машина должна работать, человек думать — слышали про такое?
> И что, при правильном понимании, работа с HTML/CSS/JavaScript является
> такой же высокоуровневой, что и работа с серверным контролом, а порой,
> и даже более высокоуровневой!
Нет. Высокоуровневая работа это выцеплять ссылочный спам или ненормативную лексику, используя ИИ. Ну, если спуститься чуть на землю, то это использование бизнес-уровня. А этот canvas всего лишь позволит на js делать то же самое, что на Java можно было делать в 97-м году.
> См. пример, где мы можем «на лету» превратить список в дерево, дерево в
> контекстное меню, а в режиме печати снова представит его в виде списка
> и скопировать в виде списка в Word, просто подменив CSS и JS-класс! Такой
> высокоуровневой возможности в серверных контролах нет (поправьте меня,
> если я не прав)!
Конечно, неправы. Всё это бирюльки. Я вообще не понимаю, зачем всё такое сложное нужно, но, как Вы думаете, трудно ли то же самое сделать в Java или Flash или Silverlight? На мой взгляд, достаточно просто, хотя я флеша не знаю. И — речь всё-таки про клиентский код.
> Поэтому я так выступаю за классические HTML/CSS/JavaScript, понимаю из
> высокоуровневость, ценю красоту и гибкость и выступаю против отказа от
> использования это web-парадигмы в строну имитации десктопных GUI!
Мне кажется, Вы просто молоды очень, поэтому Вам и интересно писать yet another чего-то там. А на мой взгляд, времени у нас не так много и тратить его надо на действительно важные вещи.
> Но, несмотря на свою гениальность, преодолеть фундаментальные
> ограничения текстового режима (матрица из 80 * 25, невозможность
> проводить изогнутые линии, 256 цветов и т.д.) она не могла.
Странно, что Вы именно об этом написали. В 91-м году я со своим другом перевёл паскалевскую TV в графический режим. Это оказалось несложно — весь вывод там осуществлялся через одну-единственную функцию, которую мы и переопределяли.
Вывод я писал на ассемблере, и там пришлось серьёзно заниматься оптимизацией. Не знаю, в курсе ли Вы, но в EGA и 16-тицветных режимах VGA вывод осуществлялся через битовые плоскости. Существовало 3 режима вывода, весьма запутанные. В конечном итоге, за месяц удалось довести задачу до конца, и TV работала даже в модных тогда SVGA-режимах 800*600*16. 256 цветов мы не использовали просто потому, что мониторы в те времена не поддерживали высокого разрешения для этих режимов.
А делали мы это для заказчиков, которые писали графические приложения. Естественно, там были и изогнутые линии (эка невидаль! в текстовом режиме даже прямые линии не всегда рисуются). Так что зря Вы говорите, что TV отмерла из-за этого. :)
Кстати, Вы ошибаетесь даже в том, почему именно TV стала столь популярна. Дело в том, что тогда это была единственная ОО-библиотека среди ДОС-программистов (Си++ отставал на 2-3-4 года). Поскольку ОО идеально подходит для интерфейсов, естественно, разрабатывать программы с GUI она позволяла значительно проще.
> Поэтому, она и ушла в историю, уступив место графическим библиотекам
> Windows… (Не потому, что она появилась раньше, или позже Windows, а
> потому, что в Windows-библиотеках отстутствовали фундаментальные
> ограничения текстового режима).
А я ещё раз говорю, что Windows — это среда исполнения, почти операционная система. Там, помимо графической составляющей… Кстати, Вы на Windows API писали когда-нибудь? Там очень неудобно всё делается, поскольку приходиться имитировать ОО-стиль средствами процедурных языков. В TV всё значительно проще и удобнее. На порядок, наверное.
Так вот, в Windows 3.0 помимо графической составляющей была уже невытесняющая многозадачность, виртуальная память, межпрограммное взаимодействие, собственное управление дисками (что естественно, ведь ДОС-овские функции не всегда были реентерабельными). А в 3.1 появилась поддержка локальных сетей.
TV и Windows — это продукты разного класса. Странно, что приходиться писать такие элементарные вещи. Ещё раз думаю, что Вы строите теорию, не опираясь на фактическую базу. А это чревато.
> В этих технологиях пока есть ряд мультимедийных ограничений, которые,
> как не старайся, какую изобретательность не применяй, разработчикам
> web-приложений преодалеть не возможно.
> И, поэтому, HTML/CSS/JS могут уступить тем технологиям, в которых нет
> этих фундаментальных ограничений, например Flex или Silverlight.
Ну вот, вы же сами всё понимаете.
> Но, я надеюсь, под руководтсвом WHATWG эти технологии будут
> развиваться как технологии создания Web-приложений, и «физической
> гибели» не случится.
Вот я и интересуюсь — для чего надеетесь? Зачем держитесь за то, что уже морально устарело? Пока Вы будете играть в бирюльки, вручную на js рисуя графики, остальные разработчики возьмут готовый chart-компонент и будут решать высокоуровневые интересные задачи. Машина должна работать, человек думать — слышали про такое?
> И что, при правильном понимании, работа с HTML/CSS/JavaScript является
> такой же высокоуровневой, что и работа с серверным контролом, а порой,
> и даже более высокоуровневой!
Нет. Высокоуровневая работа это выцеплять ссылочный спам или ненормативную лексику, используя ИИ. Ну, если спуститься чуть на землю, то это использование бизнес-уровня. А этот canvas всего лишь позволит на js делать то же самое, что на Java можно было делать в 97-м году.
> См. пример, где мы можем «на лету» превратить список в дерево, дерево в
> контекстное меню, а в режиме печати снова представит его в виде списка
> и скопировать в виде списка в Word, просто подменив CSS и JS-класс! Такой
> высокоуровневой возможности в серверных контролах нет (поправьте меня,
> если я не прав)!
Конечно, неправы. Всё это бирюльки. Я вообще не понимаю, зачем всё такое сложное нужно, но, как Вы думаете, трудно ли то же самое сделать в Java или Flash или Silverlight? На мой взгляд, достаточно просто, хотя я флеша не знаю. И — речь всё-таки про клиентский код.
> Поэтому я так выступаю за классические HTML/CSS/JavaScript, понимаю из
> высокоуровневость, ценю красоту и гибкость и выступаю против отказа от
> использования это web-парадигмы в строну имитации десктопных GUI!
Мне кажется, Вы просто молоды очень, поэтому Вам и интересно писать yet another чего-то там. А на мой взгляд, времени у нас не так много и тратить его надо на действительно важные вещи.
[Turbo Vision] и Windows — это продукты разного класса Странно, что приходиться писать такие элементарные вещиГде я сравниваю Windows и Turbo Vision?
Я сравниваю оконные библиотеки для графического и текстового режимов.
И показываю, что библиотеки текстового режима, какую бы изобретательность не проявляли бы их создатели, не могли преодолеть ограничения текстового режима (а если начинали использовать графический режим, то переставали быть текстовыми библиотеками) и уступили место графическим. И Turbo Vision — это просто пример одной из лучших текстовых библиотек.
Это я показал как историческую аналогию того, что может случиться с xHTML/CSS/JS интерфейсами, если они не будут развиваться. Какую бы изобретательность не проявляли бы разработчики HTML интерфейсов (подобно той, которую проявили разработчики TV), они не могут преодолеть ограничения HTML, и, поэтому, уступят интерфейсам Flex (подобно тому, как текстовые интерфейсы уступили место графическим).
Но, в отличие от текстового режима, который не мог развиваться; xHTML/CSS/JS развиваться могут. И поэтому, «физическая гибель» совершенно не является неизбежной.
Вот я и интересуюсь — для чего надеетесь? Зачем держитесь за то, что уже морально устарело?Подробнее в этом комментарии.
Я не считаю, что эти технологии морально устарели.
Я считаю, что описание интерфейсов в HTML, при правильном к нему подходе, имеет такой же уровень абстракции, что и серверный контрол.
И совершенно не обязательно «кодировать контрол вручную». Достаточно описать данные в HTML-элементе, а потом вызвать JS-класс, который оформит HTML-элемент нужным образом и придаст ему функциональность контрола.
Вам и интересно писать yet another чего-то тамПоскольку я руководитель небольшой фирмы, я не могу позволить использовать у нас технологию, просто, чтобы «писать yet another чего-то». Мы используем эту технологию из-за ее мощности, гибкости, удобства (ну и на красоту тоже нельзя не обращать внимание :-) ).
Имитация стека и вызов функций относятся не к епархии ассемблера, а к архитектуре. В процессорах Intel, начиная с 8086, стек присутствовал, и были соответствующие инструкции для работы с ним.Стек присутствует не во всех процессорах. В старых процессорах Intel и Motorolla стека не было. Однако, потом для этих процессоров были созданы ассемюлеры, в которых стек эмулировался, позволяя программисту писать код так, как будто в процессоре стек есть. Поправьте меня, где я не прав.
Насчет вызова функций я точно не уверен. Но, по-моему, команды
CAL и RET были чисто ассемблерными командами, и не для всех процессоров имели аналог в машинных кодах.Но, на всякий случай, пока заменил другой «фишкой» продвинутого ассемблера — использованием макросов. «Фишкой», которая стала не нужной высокоуровневым разработчикам. Также, как станут не нужными многие «фишки», облегчающие разработку front-end разработчикам, если xHTML/CSS/JS-код будет генерироваться автоматически…
Всю эту информацию Вы почерпнули из книг. Вероятно, очень классических. Стека и функций не было на старых процессорах — это да. На процессорах времён Фортрана, то есть 50-х годов. С 60-х такой проблемы нет у программистов. :)
На PC (т.е. с 79-го года) все эти машинные коды были.
Если уж на то пошло, то появление персоналок отбросило индустрию программирования на 20 лет назад. Снова пришлось вспоминать ассемблер, хотя на больших машинах на смолтоке писали уже в 70-е годы. И большинство современных перспективных языков были задуманы на больших машинах уже в 80-е, просто на персоналках они были слишком медленными.
На PC (т.е. с 79-го года) все эти машинные коды были.
Если уж на то пошло, то появление персоналок отбросило индустрию программирования на 20 лет назад. Снова пришлось вспоминать ассемблер, хотя на больших машинах на смолтоке писали уже в 70-е годы. И большинство современных перспективных языков были задуманы на больших машинах уже в 80-е, просто на персоналках они были слишком медленными.
Всю эту информацию Вы почерпнули из книг. Вероятно, очень классических. Стека и функций не было на старых процессорах — это да.… С 60-х такой проблемы нет у программистов. :)Но, все же, это, показывает, что имитация стека в ассемблерах для старых процессоров не является чушью :-)
И это можно привести в качестве примера, пусть и очень старого.
> Но, все же, это, показывает, что имитация стека в ассемблерах для старых
> процессоров не является чушью :-)
Это показывает, что на ассемблере Вы не писали, но где-то прочитали, как оно было.
> И это можно привести в качестве примера, пусть и очень старого.
И снова нет. Языки высокого уровня вытеснили язык ассемблера, это факт. И произошло это значительно позже, чем в машинах появилась поддержка стека и вызова функций. По меньшей мере лет на 10. Так что этот факт совершенно ничего не показывает, ни в поддержку Вашей точки зрения, ни для её опровержения. Он просто ни при чём.
> процессоров не является чушью :-)
Это показывает, что на ассемблере Вы не писали, но где-то прочитали, как оно было.
> И это можно привести в качестве примера, пусть и очень старого.
И снова нет. Языки высокого уровня вытеснили язык ассемблера, это факт. И произошло это значительно позже, чем в машинах появилась поддержка стека и вызова функций. По меньшей мере лет на 10. Так что этот факт совершенно ничего не показывает, ни в поддержку Вашей точки зрения, ни для её опровержения. Он просто ни при чём.
Он просто ни при чём.Этот пример вот о чем:
Фишки, которые облегчают разработку на языке низкого уровня, становятся не нужными высокоуровневым программистам.
Так, ассемблерные макросы (или имитация стека для бесстековых процессоров) облегчала разработку программистам на ассемблере. Но стали совершенно не нужной для высокоуровневых программистов на C++.
Так же, и использование «Ненавязчивого JavaScript» облегчает жизнь xHTML/CSS/JS разработчикам, но становится совершенно не нужным, если xHTML/CSS/JS-код генерируется автоматически.
Это показывает, что на ассемблере [без стека, как я понимаю] Вы не писали, но где-то прочитали, как оно было.Я как-то писал на ассемблере для микроконтроллера, на котором стека не было (так просто ради развлечения, не углубляясь). Но, да, для нормальных компьютеров я на ассемблере без стека никогда не писал (но, читал об этом), Вы правы.
И это я уже не говорю об антимайкрософтовской идеологии
В статье нет никакой «антимайкрософтовской идеологии».
Я считаю классические xHTML/CSS/JS замечательными и удивительно гибкими технологиями построения интерфейса; и выступаю против отказа от их использования не только в сторону микрософтовских ASP.NET-контролов и Silverlight, но и Flex от Adobe и JSF от SUN.
К самой же Микрософт и, даже, «чистой» ASP.NET (без учета контролов), я отношусь с большим уважением.
См. 3-ю сноску:
Конечно, ASP.NET не ограничивается одними серверными контролами. ASP.NET — очень могучая, производительная, надежная технология, использующая всю мощь .NET Framework. Однако, многие разработчики используют ASP.NET именно из-за серверных контролов.
Серверные контролы в ASP.NET никак не противоречат идеологии HTML. И код генерируется чистый, я через Tidy специально проверяю. Или Вы имеете в виду, что эти контролы генерируют POST-запросы там, где традиционно используют GET?
Хочу Вас обрадовать — можно вполне работать через GET, благодаря MVC. Можно даже в классическом ASP.NET обходиться без POST, если есть такая потребность. Весь вопрос в том, что именно нужно программисту.
Хочу Вас обрадовать — можно вполне работать через GET, благодаря MVC. Можно даже в классическом ASP.NET обходиться без POST, если есть такая потребность. Весь вопрос в том, что именно нужно программисту.
UFO just landed and posted this here
Я не очень понимаю, в чём ужас. В том, что onClick, а не onclick? Или в том, что javascript?
SelenIT видимо имеет в виду, что использование обработчиков в тексте xHTML-кода — полностью не соответствует идее отделения разметки от интерфейсной логики и противоречит концепции «Ненавязчивый JavaScript» (см., например здесь и здесь).
Что не намного лучше конструкций типа:
Позволю себе процитировать фрагменты двух моих комментариев (по поводу серверных контролов, уродского кода, MVC и оптимизма):
этого:
… и этого:
Что не намного лучше конструкций типа:
<font color = "" size = "">Позволю себе процитировать фрагменты двух моих комментариев (по поводу серверных контролов, уродского кода, MVC и оптимизма):
этого:
Традиционное ASP.NET меня сильно раздражает — впечатление такое, что старались переманить разработчиков GUI-приложений, делая вид, что веб ничем не отличается.Полностью согласен. Сама по себе ASP.NET и .Net вообще — очень мощная технология.
… тогда пощупаю MVC.
Но попытка применить к web десктопную windows-овскую GUI парадигму с помощью ASP.NET контролов — это выглядит ужасно!
Поэтому, ASP.NET MVC Framework — это большой шаг вперед!
Но, знаете, я очень не уверен, что все ASP.NET разработчики перейдут на MVC. Ведь модель ASP.NET контролов настолько является настолько родной, привычной и понятной для тех, кто привык к Visual Basic / Delphi парадигме: кинул контрол на форму → щелкнул два раза мышкой → написал обработчик и все дела…
… и этого:
Когда я смотрю на HTML/CSS/JS-код сгенерированный ASP.Net (особенно ранних версий), мне становится страшно :-) Чего только__VIEWSTATEстоит!
Но, надо отдать Микрософту должное: от версии к версии, генерируемый ASP.NET-контролами xHTML код становится все менее уродливым. В последней версии код уже является полностью валидным, и довольно семантичным. Я написал об этом в 6-й сноске.
> SelenIT видимо имеет в виду, что использование обработчиков в тексте
> xHTML-кода — полностью не соответствует идее отделения разметки от
> интерфейсной логики и противоречит концепции «Ненавязчивый JavaScript»
В этом случае возникает вопрос, при чём тут ASP.NET. Я не знаю, много ли фреймворков вообще поддерживают эту концепцию, подозреваю, что из распространнёных ни один. Я подозреваю даже, что концепция появилась позже, чем вышла ASP.NET 1.0.
Если этот подход действительно окажется жизнеспособным, будет и в ASP.NET его поддержка. Всегда надо смотреть. Например, разделение содержания и представления понятно зачем делается. Независимо от фреймворка это полезно. А вот отделение javascript от html — в коде, который автоматом генерируется на сервере…
Ну, чёрт его знает. На мой взгляд, на серверную логику это никак не влияет.
> Когда я смотрю на HTML/CSS/JS-код сгенерированный ASP.Net (особенно
> ранних версий), мне становится страшно :-) Чего только __VIEWSTATE
> стоит!
А вы посмотрите на любой генерированный код любого развитого фреймворка. Он везде страшный. Но Вас почему то угнетает именно ASP.NET. Вот в этом и вижу проявление антимайкрософтовской идеологии.
Так и скажите: ну его на фиг, фреймворки, даёшь возвращение к ручной вёрстке.
> xHTML-кода — полностью не соответствует идее отделения разметки от
> интерфейсной логики и противоречит концепции «Ненавязчивый JavaScript»
В этом случае возникает вопрос, при чём тут ASP.NET. Я не знаю, много ли фреймворков вообще поддерживают эту концепцию, подозреваю, что из распространнёных ни один. Я подозреваю даже, что концепция появилась позже, чем вышла ASP.NET 1.0.
Если этот подход действительно окажется жизнеспособным, будет и в ASP.NET его поддержка. Всегда надо смотреть. Например, разделение содержания и представления понятно зачем делается. Независимо от фреймворка это полезно. А вот отделение javascript от html — в коде, который автоматом генерируется на сервере…
Ну, чёрт его знает. На мой взгляд, на серверную логику это никак не влияет.
> Когда я смотрю на HTML/CSS/JS-код сгенерированный ASP.Net (особенно
> ранних версий), мне становится страшно :-) Чего только __VIEWSTATE
> стоит!
А вы посмотрите на любой генерированный код любого развитого фреймворка. Он везде страшный. Но Вас почему то угнетает именно ASP.NET. Вот в этом и вижу проявление антимайкрософтовской идеологии.
Так и скажите: ну его на фиг, фреймворки, даёшь возвращение к ручной вёрстке.
А вот отделение javascript от html — в коде, который автоматом генерируется на сервере… Ну, чёрт его знает. На мой взгляд, на серверную логику это никак не влияет.Ну вот, мы и пришли к общему мнению :-)
Я высказал утверждение (которое принесло мне много-много минусов в карму :-) ): компиляторы часто (хотя далеко не всегда) генерируют уродливый низкоуровневый код. Но это не плохо для высокоуровневых программистов, ведь их высокоуровневый код вполне красив.
Компиляторы C++ часто генерирует некрасивый низкоуровневый код (а порой и менее эффективный, чем мог бы написать профессиональный низкоуровневый программист). Но это не страшно для C++ программиста, ведь его высокоуровневый C++ код, с которым он работает и на который любуется — очень красив.
Так же, и ASP.NET часто генерирует уродский низкоуровневый HTML-код. Для меня — смешение разметки с JavaScript-логикой — страшное уродство.
Но для Вас — это не проблема, ведь Вы работаете с красивым ASP.NET-кодом.
Тут имеет смысл рассмотреть правомерность употребления слов «некрасивый» и «уродский». Если код предназначен для чтения человеком, можно говорить о стиле.
А если нет? В чём смысл? Код страницы не отформатирован, из скриптов выброшены все пробелы и отступы, переменные названы a, v, k, все из одной буквы. Это характерно для любого фреймворка, не только для ASP.NET.
Так Вы и озвучьте полную свою позицию: Вы против фреймворков, за ручную вёрстку. И минусов Вам поставят ещё в два раза больше. :)
А если нет? В чём смысл? Код страницы не отформатирован, из скриптов выброшены все пробелы и отступы, переменные названы a, v, k, все из одной буквы. Это характерно для любого фреймворка, не только для ASP.NET.
Так Вы и озвучьте полную свою позицию: Вы против фреймворков, за ручную вёрстку. И минусов Вам поставят ещё в два раза больше. :)
А вы посмотрите на любой генерированный код любого развитого фреймворка. Он везде страшный.Большинство современных MVC фреймворков заполняют данными некий шаблон. Но шаблон то этот сверстан вручную!
См. например HTML/CSS/JS код Хабра — он очень красив, т.к. его шаблон сверстали вручную rossomachin и др.
даёшь возвращение к ручной вёрстке.Да, я выступаю за ручную верстку!
Но я не считаю ее чем-то страшным и низкоуровневым.
Я уверен, что уровень абстракции xHTML/CSS/JS (особенно с учетом их развития, например HTML5) вполне соответствует уровню абстракции интерфейса.
И мне совершенно не требуется «вручную кодировать контролы».
Мне надо дерево — создал обычный многоуровневый список. Надо вкладки — создал для каждой по div-у.
А потом использовал класс, придающий списку внешний вид и функциональность дерева:
var objTree1 = new Tree ($("ulMyList"))А если захотелось по ходу программы переделать дерево в меню, вызываю другой класс:
var objMenu1 = new ContextMenu ($("ulMyList"))(Обратите внимание: эти классы не генерируют HTML-код дерева на основе кода списка. HTML-код и DOM может (хотя, на практике, к сожалению, не всегда) оставаться неизменным. Просто к нему применяются JS-обработчики и CSS-стили, придающие внешний вид и функциональность дерева).
Для того, чтобы сделать график, опять же, не обязательно «рисовать вручную на канвасе». А достаточно создать список значений, и использовать класс, который придаст ему нужный вид.
Эти классы совсем не обязательно должен писать я сам — можно воспользоваться готовыми библиотеками JS-контролов. А я работаю только с высокоуровневыми логикой и данными (HTML-кодом).
Я думаю, каждый из нас прав по своему.
Вам нравится десктопная парадигма — вы используете ASP.NET-контролы, которые генерируют HTML код.
Мне, из-за ее гибкости, нравится web-парадигма, я описываю контролы в столь же высокоуровневом HTML.
Но я уверен — использование xHTML/CSS/JS для построения интерфеса не является менее высокоуровневым, чем использование серверных контролов…
Я думаю, что по «IT индустрией» автор понимает Прикладное программирование. Всмысле разработку настольных приложений, которые в основной своей массе редко используют ассемблер для решения низкоуровневых задач, а скорее используют готовые библиотеки.
По поводу использования prototype и jQuery — это очень удобный способ не задумываться над «особенностями» и «нюансами» реализации функций под различными версиями в браузерах… Как мне кажется знание таких особенностей не столь уж важно при высоком темпе разработки… а вот когда останется время оглянуться…
jQuery — замечательная библиотека, сильно упрощающая работу с DOM. Главное ее преимущество в том, что она развивает JavaScript, а не пытается сделать из JS «упрощенный огрызок».
Prototype.js — совсем другое дело. Она не развивает прототипную парадигму языка, а пытается эмулировать классическое классовое ООП, что является страшным надругательством над JavaScript, лишающим его такой красоты и гибкости.
Prototype.js — совсем другое дело. Она не развивает прототипную парадигму языка, а пытается эмулировать классическое классовое ООП, что является страшным надругательством над JavaScript, лишающим его такой красоты и гибкости.
Вообще-то в jQuery тоже есть extend, а в prototype никто не заставляет использовать Class. Тут как раз полная свобода выбора.
да ну, смешно насчет прототипа
в нем помимо объекта Class есть масса других удобных классов
в нем помимо объекта Class есть масса других удобных классов
Плюс ко всему, jQuery весит меньше. Не у всех есть возможность gzip'ить прототайповский файл.
> классовое ООП, что является страшным надругательством над JavaScript
насколько Вы профи в JS? а с Python'ом Вы знакомы, например? А классы в Питоне видели? А практически 93% сходство идеологий описания классов в Python и prototype based inheritance в JS видели? Тем не менее, в Python это назвали классы (да и Ruby тоже).
Не обращайте внимание на то, что кто-то делает для себя обертки в виде классов для JS. В любом случае — внутри этих оберток — все то же (единственное в текущей версии ECMAScript) — прототайп-бэйзд-инхеритэнс, а значит человек который писал эту обертку — понимал, в чем дело.
Другой вопрос, что новичкам это может туманить разум; вот в этих случаях им надо помогать.
насколько Вы профи в JS? а с Python'ом Вы знакомы, например? А классы в Питоне видели? А практически 93% сходство идеологий описания классов в Python и prototype based inheritance в JS видели? Тем не менее, в Python это назвали классы (да и Ruby тоже).
Не обращайте внимание на то, что кто-то делает для себя обертки в виде классов для JS. В любом случае — внутри этих оберток — все то же (единственное в текущей версии ECMAScript) — прототайп-бэйзд-инхеритэнс, а значит человек который писал эту обертку — понимал, в чем дело.
Другой вопрос, что новичкам это может туманить разум; вот в этих случаях им надо помогать.
> Не обращайте внимание на то, что кто-то делает для себя обертки в виде классов для JS. В любом > случае — внутри этих оберток — все то же (единственное в текущей версии ECMAScript) —? прототайп-бэйзд-инхеритэнс, а значит человек который писал эту обертку — понимал, в чем дело.
5 баллов, а то иногда попадаются умники, которые начинают долдонить свое, какие же это классы и т.д.
5 баллов, а то иногда попадаются умники, которые начинают долдонить свое, какие же это классы и т.д.
Можно поспорить над фразой «а значит человек который писал эту обертку — понимал, в чем дело». Не факт. Ситуация схожа с пугалом «eval — зло!», профи понимает, что это не так однозначно, но пугало-то стоит не для профи. С классическим ООП та же история, с фреймворками та же история и т.д.
Да конечно, не факт. Только вот с фразами «надругались над JS — используют классы» та же история. Конечно, печально, когда действительно не понимают, как это работает, и яро доказывают всякую отсебятину. Но вот те, кто создает просто удобные обертки для создания последовательной связи объектов через прототипы, мне кажется, и холиворить-то не будут никогда не эту тему. Ну назвали бы они эту обертку InheriteFrom(...) (или ObjectConstructorWithInheritance), а не Class(...) (при этом бы начинка не поменялась бы ни на байт) — все! — вряд ли бы вообще кто-то что-то критиковал.
Хотя, да — человек может и не осознавать, что он пишет обертку, а думать, что доводит до «ума» этот «бесклассовый язык». Здесь надо просто с самого начала сказать (и показать), что есть альтернативная модель наследования (что человек просто не в курсе, что речь о разных подходах ведется) и что она так же хороша и даже относительно лучше (это я опять не тебе говорю (ты и так хорошо преподаешь), а — вообще — всем, кто выбирает сам постоянно вестить на выкрики новичков aka «че за язык? тут даже классов нормальных нет!»)
Хотя, да — человек может и не осознавать, что он пишет обертку, а думать, что доводит до «ума» этот «бесклассовый язык». Здесь надо просто с самого начала сказать (и показать), что есть альтернативная модель наследования (что человек просто не в курсе, что речь о разных подходах ведется) и что она так же хороша и даже относительно лучше (это я опять не тебе говорю (ты и так хорошо преподаешь), а — вообще — всем, кто выбирает сам постоянно вестить на выкрики новичков aka «че за язык? тут даже классов нормальных нет!»)
Понимаешь, какое дело — автор пристрелил в статье prototype.js и одновременно назвал jQuery э… чего-то там развивающей в javascript. Это в стиле «я за абстракции, но я против абстракций» или «долой обёртки, но одна из самых худших обёрток мне сильно-сильно нра...». Вот как всё это принимать? Как сознательное или бессознательное? Принимать это можно только в самых общих чертах по результату (безотносительно мотивов и деталей) — выставлено пугало «классовое ООП — зло!», выставлено пугало «prototype.js — зло!», ну, и отлично, пусть теперь постоят и детей попугают…
> выставлено пугало «классовое ООП — зло!»
Вот именно, что пугало. При этом одними, когда они видят заголовки «классы в JS», движет «несовершенство внешнего мира» :) и они хотят подкорректировать, уточнить, помочь, показать, — что в ECMAScript другая альтернативная модель и что стоит это учитывать. А другие могут насмотреться на это (на высказывания профи) и вообще бессознательно постоянно потом говорить «надругались».
При этом — копни чуть глубже (тот же Питон или Руби) — то, вроде, как и «тоже самое как в JS», но почему-то названо «класс». Поэтому, можно сразу уточнить — «Вы какие классы имеете в виду, когда говорите „надругались“? Статические или динамические, порождающие мьютэбл-объекты и сами являющиеся мьютэбл-объектами?». При этом сразу будет получен ответ — «эм… да, статические...». И дальше ответ — но это не возможно в текущей версии JS, поэтому обертка, которую люди называют «класс» (или еще как) внутри себя оперирует все теми же динамическими сущностями с делегирующим к прототипам наследованием.
При этом можно показать самое главное преимущество использования прототипов с делегирующей моделью — один метод расшаривается по всем инстансам (в то время как при описании той же порождающей сущности классом — будет использовать каскадная модель, которая создаст каждому инстансу свои одни и те же по семантике методы). Но при этом делегация имеет меньшую скорость в отличии от каскадирования. Мне вообще смутным представляется большая выгода (кроме скорости обращения) описания методов в классе, а не в прототипе. Например, из ES4:
a.hasOwnProperty('test'); // true
На кой ляд мне один и тот же одинаковый метод? А если инстансов будет 1000 (а если 100000?)? — при этом я не думаю, что будет цепь наследования в 10000 уровней. Конечно его выгодней вынести в прототип. Таким образом делегирующая прототипная модель получается выгодней в ресурсах.
Вот именно, что пугало. При этом одними, когда они видят заголовки «классы в JS», движет «несовершенство внешнего мира» :) и они хотят подкорректировать, уточнить, помочь, показать, — что в ECMAScript другая альтернативная модель и что стоит это учитывать. А другие могут насмотреться на это (на высказывания профи) и вообще бессознательно постоянно потом говорить «надругались».
При этом — копни чуть глубже (тот же Питон или Руби) — то, вроде, как и «тоже самое как в JS», но почему-то названо «класс». Поэтому, можно сразу уточнить — «Вы какие классы имеете в виду, когда говорите „надругались“? Статические или динамические, порождающие мьютэбл-объекты и сами являющиеся мьютэбл-объектами?». При этом сразу будет получен ответ — «эм… да, статические...». И дальше ответ — но это не возможно в текущей версии JS, поэтому обертка, которую люди называют «класс» (или еще как) внутри себя оперирует все теми же динамическими сущностями с делегирующим к прототипам наследованием.
При этом можно показать самое главное преимущество использования прототипов с делегирующей моделью — один метод расшаривается по всем инстансам (в то время как при описании той же порождающей сущности классом — будет использовать каскадная модель, которая создаст каждому инстансу свои одни и те же по семантике методы). Но при этом делегация имеет меньшую скорость в отличии от каскадирования. Мне вообще смутным представляется большая выгода (кроме скорости обращения) описания методов в классе, а не в прототипе. Например, из ES4:
dynamic class A {
function test() {}
}
var a = new A();
var b = new B();
a.test === b.test; // false!a.hasOwnProperty('test'); // true
На кой ляд мне один и тот же одинаковый метод? А если инстансов будет 1000 (а если 100000?)? — при этом я не думаю, что будет цепь наследования в 10000 уровней. Конечно его выгодней вынести в прототип. Таким образом делегирующая прототипная модель получается выгодней в ресурсах.
а черт! )) случайно кнопка нажалась, не дописал и теги не закрыл )) ну в вроде все, что хотел — упомянул )) да, в Питоне — то же самое:
Хотя, я не читал спецификацию ES4 — возможно там сделано оптимизация, и это на самом деле, один метод (просто из-за того, что он связан с инстансами выдается false — но я не знаю точно, это только предположение)
Хотя, я не читал спецификацию ES4 — возможно там сделано оптимизация, и это на самом деле, один метод (просто из-за того, что он связан с инстансами выдается false — но я не знаю точно, это только предположение)
Про prototype — ерунда. Class — очень незначительная часть prototype.js.
Настоящее надругательство — это DOM database storage.
Настоящее надругательство — это DOM database storage.
Не могу полностью согласиться с выпадом в сторону JS-фрэймворков.
С прототайп работать не довелось, но с jQuery работаю уже около полутора лет, при этом около полутора лет до этого работал с чистым яваскриптом — конечно далеко не на «полную катушку», но с аяксом и ДОМ работал довольно плотно.
Так вот, я к тому, что тот же JavaScript-jQuery я бы сравнил с C-C++ — многие вещи организованы намного более удобно + кроссбраузерность, что крайне важно (вспоминаю нехорошими словами отладку чистого яваскрипт под IE/FF/Opera/Safari).
С прототайп работать не довелось, но с jQuery работаю уже около полутора лет, при этом около полутора лет до этого работал с чистым яваскриптом — конечно далеко не на «полную катушку», но с аяксом и ДОМ работал довольно плотно.
Так вот, я к тому, что тот же JavaScript-jQuery я бы сравнил с C-C++ — многие вещи организованы намного более удобно + кроссбраузерность, что крайне важно (вспоминаю нехорошими словами отладку чистого яваскрипт под IE/FF/Opera/Safari).
Полностью с Вами согласен. Именно это я сформулировал в предыдущем комментарии.
Бывают фрэймворки двух типов:
Еще раз процитирую Ричарда Корнфорда:
Но и Prototype.js надо отдать должное — на момент своего выхода это была чуть ли не единственная целостная JS-библиотека, упрощающая работу с DOM. Так что в свое время она сильно упростила жизнь разработчикам…
Бывают фрэймворки двух типов:
- Хорошие(например jQuery, Dojo) — которые развивают JavaScript.
- Плохие (например, Prototype.js) — которые не развивают JS, а, наоборот «отрезают» от языка многие мощные, но малопонятные многим разработчикам возможности, вроде прототипного программирования и т. д.
Еще раз процитирую Ричарда Корнфорда:
Prototype.js был написан теми, кто не знает JavaScript, для тех, кто не знает JavaScript
Но и Prototype.js надо отдать должное — на момент своего выхода это была чуть ли не единственная целостная JS-библиотека, упрощающая работу с DOM. Так что в свое время она сильно упростила жизнь разработчикам…
Вы неправильно, как мне кажется, понимаете причины создания такого фреймворка как prototype. Prototype создавался под RoR и потому основная цель автора, кроме абстрагирования от особенностей браузера, состоит в создании синтаксиса максимально приближенного к RoR.
Но я согласен, что это снижает ценность Prototype для всех остальных.
Но я согласен, что это снижает ценность Prototype для всех остальных.
Prototype создавался под RoR
Да, полностью согласен.
Поскольку Ruby поддерживает класс-ориентированное ООП (хотя, как и в Python (см. комментарий dsCode ), близкое к прототипному ОПП JavaScript'а), использование Prototype.js как часть Ruby on Rails гармонично и красиво.
Но, использование класс-ориентированного ОПП в самом JavaScript'е является, как я считаю большим «надругательством» над прототипной идеалогией JavaScript.
Что, конечно, не отменяет достоинств Prototype.js, как одной из первой библиотеки для упрощения работы с DOM.
напишите, чем конкретно плох prototype?
Возможено выскажу мысль остальных противников, prototype не сильно урощает/сокращает код, точнее все же сокращает но только из-за того что не приходится подгонять под все броузеры, т е если предположить что js работает во всех броузерах _одинаково_ то тольку от него _меньше_ чем от, например, jQuery.
З.Ы. не есть истина, с prototype знаком плохо.
З.Ы. не есть истина, с prototype знаком плохо.
Если уж цитировать R.C. про prototype, так и про jQuery было бы неплохо… А то как-то даже неудобно… ;)
По поводу ассемблера. Никуда он не пропал. Программирование простых систем на ассемблере как было, так и осталось. Может действительно чуть меньше.
По поводу верстки и всего остального. Если на этом «нечто» будет писаться прикладное «ПО», то будут и платформы.
А вообще все сведется к X (%
По поводу верстки и всего остального. Если на этом «нечто» будет писаться прикладное «ПО», то будут и платформы.
А вообще все сведется к X (%
По поводу ассемблера. Никуда он не пропал. Программирование простых систем на ассемблере как было, так и осталось. Может действительно чуть меньше.Еще раз повторю:
См. сноску. Речь идет о прикладной IT-индустрии, а не о системном программировании. Тестовый редактор на ассемблере пишут только эстеты, вроде разработчиков KolibriOS.
Но это уже искусство, а не IT-индустрия.
Название страшное и не соответствует содержанию. Допустим, устареют xHTML, CSS, JS, веб от этого никуда не денется, ничего страшного в этом не вижу. Да, уже сейчас можно не зная JS, xHTML как такового, за пол часика накропать богатую контролами страничку, работающую на одном аяксе. Неплохо знать XML и тэги используемых неймспейсов, собственно ничто не мешает держать в голове и использовать «дефолтный» неймспейс xHTML, содержащий сами HTML тэги. CSS в случае ASP.net подобных платформ остается в полной силе, в Silverlight / Flex да, убираем. Все это прекрасно, я считаю.
Я склонен думать, что HTML — это все-таки действительно язык разметки гипертекста, со всеми вытекающими.
Именно поэтому появились специально предназначенные для этого технологии, которые позволяют более эффективно строить RIA-приложения, так как предназначены для этого (Flex, Silverlight).
Думаю, в определенной перспективе, просто каждая технология станет использоваться более-менее по прямому назначению.
Мы, создавая сложные RIA на основе HTML, CSS, Ajax, сталкивались непосредственно с тем, что эти технологии изначально не предназначены для этого, а используются за отсутствием альтернатив. И, кстати, я сам до сих пор не понимаю, почему народ зачастую так излишне зациклен на JavaScript-фреймворках, а не использует те же Flex и Silverlight для многих задач.
Именно поэтому появились специально предназначенные для этого технологии, которые позволяют более эффективно строить RIA-приложения, так как предназначены для этого (Flex, Silverlight).
Думаю, в определенной перспективе, просто каждая технология станет использоваться более-менее по прямому назначению.
Мы, создавая сложные RIA на основе HTML, CSS, Ajax, сталкивались непосредственно с тем, что эти технологии изначально не предназначены для этого, а используются за отсутствием альтернатив. И, кстати, я сам до сих пор не понимаю, почему народ зачастую так излишне зациклен на JavaScript-фреймворках, а не использует те же Flex и Silverlight для многих задач.
Я склонен думать, что HTML — это все-таки действительно язык разметки гипертекста, со всеми вытекающими.Сам по себе XHTML — действительно только язык разметки гипертекста.
Но в сочетании с CSS и JS он приобретает столь фантастическую мощь, масштаб которой до сих пор даже не оценен.
Это делает HTML одним гибчайшихх языков построения интерфейса.
Процитирую один пример из статьи:
Более того, xHTML является даже более гибким и высокоуровневым языком построения интерфейса, чем многие другие. Ведь именно потому, что xHTML хранит лишь данные, а не внешний вид и функциональность интерфейсного элемента, делает интерфейсы гораздо более универсальным.
Т.е., в одной ситуации, один и тот же элемент ведет себя как дерево, в другой — как меню, в третьей — как обычный список. При этом, xHTML код интерфейса остается неизменным.
Мы даже можем превратить дерево в контекстное меню, а контекстное меню в список прямо на лету, без перезагрузки страницы, просто динамически заменив таблицу стилей!
В каком еще языке разметки интерфейса так можно?!
Да я и не говорю, что HTML сам по себе очень уж плох для интерфейсов. Я как раз про маленький аспектик — «Это делает HTML одним из гибчайших языков построения интерфейса». Ключевое слово — «делает». А подмножества тех же XAML (в Silverlight) и MXML (во Flex) — специально предназначены для этого.
Собственно, вместе с тем же MXML используется CSS, а отдельно для графики еще и FXG. Я говорил именно о мощи таких средств. И после того, как пробуешь их, использование HTML кажется несколько чрезмерно трудозатратным.
В общем, нюансов еще много и можно спорить очень долго на эту тему. HTML (с CSS и JS) сегодня само собой имеет полное право на жизнь в мире RIA-интерфейсов, ну а там уж посмотрим что будет дальше.
Собственно, вместе с тем же MXML используется CSS, а отдельно для графики еще и FXG. Я говорил именно о мощи таких средств. И после того, как пробуешь их, использование HTML кажется несколько чрезмерно трудозатратным.
В общем, нюансов еще много и можно спорить очень долго на эту тему. HTML (с CSS и JS) сегодня само собой имеет полное право на жизнь в мире RIA-интерфейсов, ну а там уж посмотрим что будет дальше.
Знаете, даже в тех случаях, когда xHTML/CSS/JS и XAML/Flex примерно равны по функциональным возможностям, я предпочитаю именно xHTML/CSS/JS.
Вообще, это достаточно большой вопрос, и я собираюсь сформулировать и написать отдельную статью на эту тему: почему я считаю xHTML/CSS/JS лучшими технологиями создания богатого клиентского web-интерфейса (если интересно, можете подписаться на мой блог :-)). Но здесь приведу несколько тезисов:
Во-первых, HTML является открытым и универсальным стандартом. И web-интерефсом можно воспользоваться где угодно: с полным набором функций на компьютере, с усеченными функциями на мобильнике; а также, создать версию для печати, синтезатора или шрифта Брайля.
Во-вторых, самое главное: HTML, прежде всего, является структурированным иерархическим текстом. А то или иное оформление или функциональность навешивается уже потом. Причем, один и тот же web-интерфейс может принять много различных видов оформления и функциональности.
В качестве примера я хочу привести раздел сайта Apple. (Этот пример подходит и для web-приложений).
На нем находится очень красивый, сложный и функциональный слайдер:
Но, если отключить стили на странице, этот слайдер превращается в обычный список:
Который можно выделить и скопировать в Word. Или просто применив другие CSS и JS-классы, представить в виде вкладок или контекстного меню…
Если же этот слайдер был сделан на Flash или Silverlight, то он, в отличие от универсального иерархического текста, так и остался бы слайдером на Flash или Silverlight. Который нельзя посмотреть на мобильнике без специального плагина, скопировать в Word в виде списка, представить для печати или превратить в контекстное меню…
Ну, и в-третьих, нельзя забывать, что xHTML-интерфейсы обладают такими общими гипертекстовыми фичами, как возможность (в теории) уникально идентифицировать и сослаться на любой элемент в интерфейсе и др.
Вот так, несколько сумбурно и отрывочно, я попытался описать некоторые свои представления о красоте и гибкости классических клиентских технологий. Надеюсь, Вы меня поняли… Постараюсь четко и подробно описать сформулировать эти мысли в статье.
Вообще, это достаточно большой вопрос, и я собираюсь сформулировать и написать отдельную статью на эту тему: почему я считаю xHTML/CSS/JS лучшими технологиями создания богатого клиентского web-интерфейса (если интересно, можете подписаться на мой блог :-)). Но здесь приведу несколько тезисов:
Во-первых, HTML является открытым и универсальным стандартом. И web-интерефсом можно воспользоваться где угодно: с полным набором функций на компьютере, с усеченными функциями на мобильнике; а также, создать версию для печати, синтезатора или шрифта Брайля.
Во-вторых, самое главное: HTML, прежде всего, является структурированным иерархическим текстом. А то или иное оформление или функциональность навешивается уже потом. Причем, один и тот же web-интерфейс может принять много различных видов оформления и функциональности.
В качестве примера я хочу привести раздел сайта Apple. (Этот пример подходит и для web-приложений).
На нем находится очень красивый, сложный и функциональный слайдер:
Но, если отключить стили на странице, этот слайдер превращается в обычный список:
Который можно выделить и скопировать в Word. Или просто применив другие CSS и JS-классы, представить в виде вкладок или контекстного меню…
Если же этот слайдер был сделан на Flash или Silverlight, то он, в отличие от универсального иерархического текста, так и остался бы слайдером на Flash или Silverlight. Который нельзя посмотреть на мобильнике без специального плагина, скопировать в Word в виде списка, представить для печати или превратить в контекстное меню…
Ну, и в-третьих, нельзя забывать, что xHTML-интерфейсы обладают такими общими гипертекстовыми фичами, как возможность (в теории) уникально идентифицировать и сослаться на любой элемент в интерфейсе и др.
Вот так, несколько сумбурно и отрывочно, я попытался описать некоторые свои представления о красоте и гибкости классических клиентских технологий. Надеюсь, Вы меня поняли… Постараюсь четко и подробно описать сформулировать эти мысли в статье.
дочитал до шедевральной строчки
«В ASP.NET работа идет с высокоуровневым Windows API и серверными контролами (меню, вкладками, деревьями), которые затем компилируется в HTML, CSS и JavaScript, так же как программа на C++ компилируется в ассемблер.»
и бросил.
Автор в плане ASP.NET вы написали откровенный бред, который нисколько не соответствует действительности.
Кроме того, ваши тезисы про «уродский ассемблерный код» так же считаю несостоятельными. Уверен, что вы сами пишите на ассемблере не лучше компилятора Intel C++.
Читать далее нет никакого желания. Почему-то кажется, что остальное написано настолько же «компетентно».
«В ASP.NET работа идет с высокоуровневым Windows API и серверными контролами (меню, вкладками, деревьями), которые затем компилируется в HTML, CSS и JavaScript, так же как программа на C++ компилируется в ассемблер.»
и бросил.
Автор в плане ASP.NET вы написали откровенный бред, который нисколько не соответствует действительности.
Кроме того, ваши тезисы про «уродский ассемблерный код» так же считаю несостоятельными. Уверен, что вы сами пишите на ассемблере не лучше компилятора Intel C++.
Читать далее нет никакого желания. Почему-то кажется, что остальное написано настолько же «компетентно».
Тоже считаю, что по поводу ASP.NET автор перегнул палку, возможно и есть люди, которые тупо перетаскивают контролы на страничку и задают пару свойств, но назвать их программистами нельзя. Нормальные же программисты на ASP.NET пишут классные сайты и нисколько об этом не жалеют.
В ASP.NET работа идет с высокоуровневым Windows API и серверными контролами (меню, вкладками, деревьями), которые затем компилируется в HTML, CSS и JavaScript, так же как программа на C++ компилируется в ассемблер.Чем Вас не устраивает это сравнение? Действительно, на «высокоуровневой» страница, описанная с помощью ASP.Net контролов затем автоматически «компилируется» в результирующий xHTML/CSS/JS — код, со в всеми вытекающими после автоматической генерации кода последствиями.
Кроме того, ваши тезисы про «уродский ассемблерный код» так же считаю несостоятельными.Вы не согласны с тем, что код, сгенерированный автоматически хуже (некрасивее, сложнее для чтения, менее эффективен), чем код написанный вручную?
Я, конечно-же, не отрицаю преимуществ компиляции (автоматической генерации машинного кода), к.к. это переводит разработку на новый уровень абстракции и позволяет более эффективно использовать время разработчика. Просто сейчас, благодаря, более мощному железу, мы, слава богу, можем себе компилируемые программы. Несколько десятков лет назад (да и сейчас на некотором встраиваемом оборудовании), неэффективность скомпилированного кода давала о себе знать.
вы опять несете чупуху
какой Windows API? «работа идет» с clr, которая платформонезависимая
на asp.net вам никто не мешает писать чистый html, контролы никто не компилирует, тем более нет никакой «компиляции в HTML, CSS и JavaScript»… про mvc framework в котором вообще нет серверных контролов вы видимо не знаете вовсе,
про последствия «компиляции» я вообще промолчу…
я не согласен с тем, что код сгенерированный автоматически современными компиляторами — это «уродливый код», термин который вы столько раз употребили. Я уверен в том, что современные компиляторы генерируют отличный оптимизированный код, который в большинстве случаев будет лучше того, что напишет средней руки программист.
я не могу сказать что было «несколько десятков лет назад», но лично мне не знакомы примеры того, когда компилятор C генерировал «уродливый код», возможно такое было 30 лет назад во время i8086, не знаю, вам наверное такие факты известны — поделитесь
какой Windows API? «работа идет» с clr, которая платформонезависимая
на asp.net вам никто не мешает писать чистый html, контролы никто не компилирует, тем более нет никакой «компиляции в HTML, CSS и JavaScript»… про mvc framework в котором вообще нет серверных контролов вы видимо не знаете вовсе,
про последствия «компиляции» я вообще промолчу…
я не согласен с тем, что код сгенерированный автоматически современными компиляторами — это «уродливый код», термин который вы столько раз употребили. Я уверен в том, что современные компиляторы генерируют отличный оптимизированный код, который в большинстве случаев будет лучше того, что напишет средней руки программист.
я не могу сказать что было «несколько десятков лет назад», но лично мне не знакомы примеры того, когда компилятор C генерировал «уродливый код», возможно такое было 30 лет назад во время i8086, не знаю, вам наверное такие факты известны — поделитесь
отличный оптимизированный код, который в большинстве случаев будет лучше того, что напишет средней руки программист.Когда я смотрю на HTML/CSS/JS-код сгенерированный ASP.Net (особенно ранних версий), мне становится страшно :-) Чего только
__VIEWSTATE стоит!Но, надо отдать Микрософту должное: от версии к версии, генерируемый ASP.NET-контролами xHTML код становится все менее уродливым. В последней версии код уже является полностью валидным, и довольно семантичным. Я написал об этом в 6-й сноске.
тем более нет никакой «компиляции в HTML, CSS и JavaScript»Генерация низкоуровневого кода (HTML/CSS/JS) на основе высокоуровневого (ASP.NET) — это и есть «компиляция» (или «трансляция», если быть пуристом). Разве не так?
про mvc framework в котором вообще нет серверных контролов вы видимо не знаете вовсеКонечно, я знаю про ASP.NET MVC Framework :-) Но на момент написания тезисов статьи (а они были приурочены к началу работы над HTML5, см. аннотацию), ее еще не было. Но, опять же, ASP.NET MVC говорит о том, что модель ASP.NET контролов не идеальна…
какой Windows API?Речь идет не о Win16/Win32/Win64 API. Речь идет о том, что web-разработчики ASP.NET используют тот же самый API (базовые классы .Net Framework), что и Windows-разработчики .Net. Но, согласен, сформулировано некорректно. Убрал, пока не переформулирую.
Кстати, вообще-то контролы компилируются и автор в этом прав.
Как минимум, нужно скомпилировать код классов, содержащийся в code-behind-файлах страниц и сами вставки кода на страничке. То же самое касается ASP.NET MVC — странички не работают просто так, сами по себе — если они являются объектами класса, который не определен в сборках — будет ошибка.
P.S. Я сейчас говорю НЕ про превращение декларативно созданных контролов в JS, CSS и HTML, а именно компиляцию кода (например C#) в VS200x или при первом попадании странички в ASP.NET Runtime.
Как минимум, нужно скомпилировать код классов, содержащийся в code-behind-файлах страниц и сами вставки кода на страничке. То же самое касается ASP.NET MVC — странички не работают просто так, сами по себе — если они являются объектами класса, который не определен в сборках — будет ошибка.
P.S. Я сейчас говорю НЕ про превращение декларативно созданных контролов в JS, CSS и HTML, а именно компиляцию кода (например C#) в VS200x или при первом попадании странички в ASP.NET Runtime.
да кто бы спорил, что code-behind компилируется в сборки, в этом суть asp.net
только автор то не о том пишет
только автор то не о том пишет
Ну насчет того, что превращение декларативных ASP.NET-контролов в HTML, JS, CSS нельзя называть компиляцией — в этом я полностью согласен. Скорее, некоторая трансформация (как XSLT, к примеру, не называется же компиляцией из XML в HTML или другой XML).
Ну почему?
Конечно, компиляция в узком смысле — генерация машинного кода на основе исходника.
Но «компилияция» в широком смысле — генерация низкоуровневого кода на основе кода высокоуровневого.
И такое сравнение я считаю вполне уместным: высокоуровневые ASP.NET контролы генерируют («компилируются» в) низкоуровневый HTML-код, подобно тому, как высокоуровневая программа на C++ компилируется в низкоуровневый машинный код.
Конечно, компиляция в узком смысле — генерация машинного кода на основе исходника.
Но «компилияция» в широком смысле — генерация низкоуровневого кода на основе кода высокоуровневого.
И такое сравнение я считаю вполне уместным: высокоуровневые ASP.NET контролы генерируют («компилируются» в) низкоуровневый HTML-код, подобно тому, как высокоуровневая программа на C++ компилируется в низкоуровневый машинный код.
>Просто сейчас, благодаря, более мощному железу, мы, слава богу, можем себе компилируемые программы
Дело не только в железе, но и в компиляторах, те же C++ компиляторы эволюционировали очень сильно. Они выжимают и из нового и из старого железа намного больше, чем раньше. Конечно, новые виды компиляторов научились ускорять программы используя новые программные инструкции CPU, но и сами стали совершеннее.
Да что уж говорить, сейчас даже видеокарты программируются для любых задач. Библиотеки тоже не стоят на месте, ведь ещё десять лет назад всё было иначе и выбора-то особого не было, но не сейчас. Но это всё разговор про компиляцию в машинный код (не в ассемблер :) ), а не в промежуточный язык (MSIL), как у всех дотнетовских технологий.
Дело не только в железе, но и в компиляторах, те же C++ компиляторы эволюционировали очень сильно. Они выжимают и из нового и из старого железа намного больше, чем раньше. Конечно, новые виды компиляторов научились ускорять программы используя новые программные инструкции CPU, но и сами стали совершеннее.
Да что уж говорить, сейчас даже видеокарты программируются для любых задач. Библиотеки тоже не стоят на месте, ведь ещё десять лет назад всё было иначе и выбора-то особого не было, но не сейчас. Но это всё разговор про компиляцию в машинный код (не в ассемблер :) ), а не в промежуточный язык (MSIL), как у всех дотнетовских технологий.
Дело не только в железе, но и в компиляторах, те же C++ компиляторы эволюционировали очень сильно. Они выжимают и из нового и из старого железа намного больше, чем раньше.Действительно, скорость выполнения программ возросла не только из-за увеличения мощности железа, но и благодаря повышению эффективности компиляторов.
Но, все-же, согласитесь: подавляющую роль в этом играет именно железо — ведь его мощность растет экспоненциально (Закон Мура), а эффективность компиляторов не могла вырости в 10 000 раз за 20 лет…
>Но, все-же, согласитесь: подавляющую роль в этом играет именно железо
Ну да, мысль просто была, что чтобы выжать из железа максимум нужны компиляторы учитывающие это железо, навроде применения новых инструкций MMX/SSE/SSE2/SSE3, иначе будет учитываться только возросшая частота ядер.
И то что делая новые компиляторы разработчики устранили многие глюки и теперь даже для старых машин у которых не было этих инструкций, вновь откомпилированный код более эффективен тоже верно.
Ну да, мысль просто была, что чтобы выжать из железа максимум нужны компиляторы учитывающие это железо, навроде применения новых инструкций MMX/SSE/SSE2/SSE3, иначе будет учитываться только возросшая частота ядер.
И то что делая новые компиляторы разработчики устранили многие глюки и теперь даже для старых машин у которых не было этих инструкций, вновь откомпилированный код более эффективен тоже верно.
Насчет Intel C++ можно немножко поподробнее — не хотите ли вы сказать что icc «плохо пишет на ассемблере»? По сравнению с чем?
Я не думаю, что xHTML может не угнаться за ходом технологий. Это ведь частный случай XML, а значит в любой момент можно добавить элементы разметки для медиа-контента, розширить инструментарий для структурирования данных и т.д. Кроме этого xHTML (равно как и CSS вместе с ним) не предназначен для задач иных кроме разметки. Он используются только для управления размещением элементов (несколько утрированно, но это по сути так) на экране пользователя, а значит не должен страдать из-за отсутствия возможности, например, генерировать 3D-объекты в нем. Это на мой взгляд.
Я не думаю, что xHTML может не угнаться за ходом технологий. Это ведь частный случай XML, а значит в любой момент можно добавить элементы разметки для медиа-контента, розширить инструментарий для структурирования данных и т.д.Конечно, xHTML — это подмножество XML и чисто теоретически ничего не стоит добавить в него новый элемент (для контрола, медиаконтента и т.д.)
Но:
— Кто придумает этот элемент?
— Кто заставит производителей браузеров (особенно самого распространенного) поддерживать этот элемент?
В этом и вся проблема :-)
UFO just landed and posted this here
Интерфейсы развиваются по большей части косметически.
Не согласен, такие сервисы как GMail, Google Map, on-line текстовые редакторы и т.д. произвели революцию именно из-за клиентского интерфейса!
UFO just landed and posted this here
Но, все же, согласитесь — развитие интерфейса является важнейшей частью развития web-приложений.
И технология AJAX, совершившая революцию в Вебе, ставшая технологической основой Web 2.0, была именно клиентской технологией.
Картографические и почтовые сервисы были задолго до появления Gmail и GMap.
Но Gmail и GMap произвели революцию, во многом, именно благодаря AJAX: возможность прямо в браузере колесиком мышки плавно увеличить карту с космического масштаба до масштаба отдельного дома, перетаскивание писем методом Drag&Drop, автосохранение, горячие клавиши и другие возможности, до того присутствовавшие только в десктопных приложениях.
И технология AJAX, совершившая революцию в Вебе, ставшая технологической основой Web 2.0, была именно клиентской технологией.
Картографические и почтовые сервисы были задолго до появления Gmail и GMap.
Но Gmail и GMap произвели революцию, во многом, именно благодаря AJAX: возможность прямо в браузере колесиком мышки плавно увеличить карту с космического масштаба до масштаба отдельного дома, перетаскивание писем методом Drag&Drop, автосохранение, горячие клавиши и другие возможности, до того присутствовавшие только в десктопных приложениях.
Линка «возобновила работу над HTML»
UFO just landed and posted this here
UFO just landed and posted this here
Учитывая, что ASP.NET не ограничен набором контролов, а позволяет выдавать любое содержимое, будь то HTML или Flash, вопрос как бы риторический.
А вот при использовании шаблонов aspx ограничения уже появляются. Например, единственный тег <form> на странице.
И стандартные контролы зачастую выдают не вполне логичный код. Если пользоваться только стандартными средствами ASP.NET, то и фиг бы с ним, но когда пишешь свой JavaScript, неудобно добираться до нужного элемента.
А вот при использовании шаблонов aspx ограничения уже появляются. Например, единственный тег <form> на странице.
И стандартные контролы зачастую выдают не вполне логичный код. Если пользоваться только стандартными средствами ASP.NET, то и фиг бы с ним, но когда пишешь свой JavaScript, неудобно добираться до нужного элемента.
UFO just landed and posted this here
Да, надо попробовать. Традиционное ASP.NET меня сильно раздражает — впечатление такое, что старались переманить разработчиков GUI-приложений, делая вид, что веб ничем не отличается. Получилось что-то не совсем вебовое, и не совсем десктопное.
Но сейчас я больше пишу десктопные приложения, вот появятся интернет-проекты, тогда пощупаю MVC.
Но сейчас я больше пишу десктопные приложения, вот появятся интернет-проекты, тогда пощупаю MVC.
Традиционное ASP.NET меня сильно раздражает — впечатление такое, что старались переманить разработчиков GUI-приложений, делая вид, что веб ничем не отличается.Полностью согласен.
Сама по себе ASP.NET и .Net вообще — очень мощная технология.
Но попытка применить к web десктопную windows-овскую GUI парадигму с помощью ASP.NET контролов — это выглядит ужасно!
Поэтому, ASP.NET MVC Framework — это большой шаг вперед!
Но, знаете, я очень не уверен, что все ASP.NET разработчики перейдут на MVC. Ведь модель ASP.NET контролов настолько является настолько родной, привычной и понятной для тех, кто привык к Visual Basic / Delphi парадигме: кинул контрол на форму → щелкнул два раза мышкой → написал обработчик и все дела…
«когда пишешь свой JavaScript, неудобно добираться до нужного элемента. „
вас спасет asp.net 4.0, в котором появилось 3 способа генерации id в том числе и без автогенерации
уже сейчас все это есть и работает, можно скачать и пробовать, тестировать :)
вас спасет asp.net 4.0, в котором появилось 3 способа генерации id в том числе и без автогенерации
уже сейчас все это есть и работает, можно скачать и пробовать, тестировать :)
Но, в xHTML нет столь нужных для современных web-приложений тегов, таких как вкладки, меню, деревья, календари и т.д.
Ну, да. Ясно. Т.е. вы совсем не различаете оформление контролов и мета-язык разметки информации.
На всякий случай: деревья — это вложенные списки, а календари — таблицы. Меню есть в HTML 5, а вкладки… это по сути <menu> + <section>, тоже из HTML 5
На всякий случай: деревья — это вложенные списки, а календари — таблицы.
Да, именно это и показывается в статье.
Вы привели пример «высокоуровневого xHTML».
Просто многие разработчики не понимают этого, и используют низкоуровневый xHTML: для создания дерева, вместо семантической высокоуровневой конструкции «список» используют машанну тегов: сложных вложенных таблиц, тегов
<font> и т. д.Разумеется, вместо этой мешанины тегов им проще работать с серверным контролом «дерево». Не понимая, что при высокоуровневыом семантическом xHTML эта мешанина тегов просто не нужна…
Тогда я отказываюсь понимать пафос вашей публикации о_0
Возможно, я недостаточно понятно сформулировал свою мысль в предыдущем комментарии.
Вот, в кратце, смысл этой части статьи:
Ассемблер был объективно низкоуровневым языком, поэтому, совершенно справедливо, был заменен высокоуровневыми языками.
xHTML/CSS/JS лишь воспринимается многими разработчиками как низкоуровневый из-за неправильного понимания.
Например, воспринимают «дерево» как мешанину низкоуровневых тегов: сложных вложенных таблиц, тегов
При таком «низкоуровневом» подходе к xHTML/JScript, работать с ними не удобно, как и не удобно работать с любым низкоуровневым языком.
И поэтому, разработчики выбирают "псевдовысокоуровневые" серверные ASP.Net-контролы.
Но, на самом деле, xHTML/JS — это высокоуровневые технологии. Надо только правильно понимать их.
Например, для дерева вместо мешанины низкоуровневых тегов из вложенных таблиц и картинок, есть прекрасная высокоуровневая конструкция — список.
И тогда, при правильном использовании xHTML/JS псевдовысокоуровневые надстройки становятся не нужны.
Другой пример: JS — это не кривое классовое ООП, а прототипное ОПП. И поэтому, если понимать прототипное ОПП, псевдовысокоуровневые надстройки вроде Script# опять-же становятся не нужными.
Вот, в кратце, смысл этой части статьи:
Ассемблер был объективно низкоуровневым языком, поэтому, совершенно справедливо, был заменен высокоуровневыми языками.
xHTML/CSS/JS лишь воспринимается многими разработчиками как низкоуровневый из-за неправильного понимания.
Например, воспринимают «дерево» как мешанину низкоуровневых тегов: сложных вложенных таблиц, тегов
<font>, 1-пиксельных картинок и т. д.При таком «низкоуровневом» подходе к xHTML/JScript, работать с ними не удобно, как и не удобно работать с любым низкоуровневым языком.
И поэтому, разработчики выбирают "псевдовысокоуровневые" серверные ASP.Net-контролы.
Но, на самом деле, xHTML/JS — это высокоуровневые технологии. Надо только правильно понимать их.
Например, для дерева вместо мешанины низкоуровневых тегов из вложенных таблиц и картинок, есть прекрасная высокоуровневая конструкция — список.
И тогда, при правильном использовании xHTML/JS псевдовысокоуровневые надстройки становятся не нужны.
Другой пример: JS — это не кривое классовое ООП, а прототипное ОПП. И поэтому, если понимать прототипное ОПП, псевдовысокоуровневые надстройки вроде Script# опять-же становятся не нужными.
Да, видимо я попался в ловушку вашей публикации с лихим детективным сюжетом. Даже если дочитать до конца остаются сомнения — за кого же, собственно, автор.
С этими полужирностями действительно всё выглядит вполне логично.
С этими полужирностями действительно всё выглядит вполне логично.
Пожалуйста, не пишите, что разработчики выбирают ASP.NET из-за " «псевдовысокоуровневые» серверные ASP.Net-контролы.". Разработчики выбирают ASP.NET совсем не из-за этого и если вы этого не понимаете, то уж лучше не писать такого.
Пожалуйста, не пишите, что разработчики выбирают ASP.NET из-за " «псевдовысокоуровневые» серверные ASP.Net-контролы."
См. 3-ю сноску.
Я не утверждаю, что все разработчики используют ASP.NET только из-за серверных контролов.
Но, я говорю, что есть разработчики, которые не хотят осваивать web-парадигму, и, поэтому, выбирают привычную им с со времен Delphi и Visual Basic модель серверных контролов…
JavaScript убивает уродская реализация массивов. Неделю назад реализация «очереди объектов» из которой можно произвольно их вытаскивать заняла у меня часа три, не меньше — хотя то же самое с php-массивом, который имеет «внутренний порядок» элементов делается за 5 минут элементарно. И даже jQuery мне ничем не помог.
JavaScript убивает уродская реализация массивов.
Вообще-то реализация массивов в JS одна из самых мощнейших. Другое дело, что за это приходится расплачиваться производительностью…
Неделю назад реализация «очереди объектов»
Для работы с очередями в JS есть два метода:
array.unshift (element) — добавляет в очередь array элемент element.var element = array.shift () — извлекает из очереди array элемент и присваивает его переменной element.И даже jQuery мне ничем не помог.
jQuery тут совсем не причем. Его главная задача — не работа с JavaScript core (в том числе массивами), а упрощение работы с DOM.
Рассказать, как выглядело решение?
1) Понадобился массив A, хранящий id объектов и порядок их добавления.
2) Понадобился объект B, с индексами {id_объекта}, чтобы можно было хоть как-то находить объекты по их ID.
Название функции, позволяющей вытягивать элементы из середины очереди (о чем вы мило забыли), чрезвычайно «очевидно», так же как и ее интерфейс. Предлагаю вспомнить название и порядок передачи элементов сейчас же, не залезая в справочник, а потом подумать как это сделано в том же php и сравнить.
a = []
a[2008] = 123
alert(a.length) //O, RLY?
Реализация массивов в JavaScript отвратительна для языка такого уровня.
1) Понадобился массив A, хранящий id объектов и порядок их добавления.
2) Понадобился объект B, с индексами {id_объекта}, чтобы можно было хоть как-то находить объекты по их ID.
Название функции, позволяющей вытягивать элементы из середины очереди (о чем вы мило забыли), чрезвычайно «очевидно», так же как и ее интерфейс. Предлагаю вспомнить название и порядок передачи элементов сейчас же, не залезая в справочник, а потом подумать как это сделано в том же php и сравнить.
a = []
a[2008] = 123
alert(a.length) //O, RLY?
Реализация массивов в JavaScript отвратительна для языка такого уровня.
возможно вам нужен был хеш, а не массив?
Возможно, Вы не корректно сформулировали проблему.
Очередь — эта такая структура, элементы которой добавляются в конец и извлекаются из начала.
Ни какого «вытягивания элементов из середины очереди» быть не может! Во всяком случае, это уже будет не очередь…
Очередь — эта такая структура, элементы которой добавляются в конец и извлекаются из начала.
Ни какого «вытягивания элементов из середины очереди» быть не может! Во всяком случае, это уже будет не очередь…
Давайте вы не будете цепляться к словам, а предложите мне нормальное решение этой задачи.
Например, на php это бы выглядело так:
$queue = array();
$queue[$it->id] = $it; //Добавление элемента
shift($queue); //Сдвиг первого элемента из очереди
unset($queue[$it->id]); //Удаление элемента по id
Других функций мне не надо. Всего четыре строчки. Сделайте то же самое на javascript, где, как вы выражаетесь одна из мощнейших реализаций массивов. Пусть же эта мощщ проявит себя уже наконец.
Например, на php это бы выглядело так:
$queue = array();
$queue[$it->id] = $it; //Добавление элемента
shift($queue); //Сдвиг первого элемента из очереди
unset($queue[$it->id]); //Удаление элемента по id
Других функций мне не надо. Всего четыре строчки. Сделайте то же самое на javascript, где, как вы выражаетесь одна из мощнейших реализаций массивов. Пусть же эта мощщ проявит себя уже наконец.
slice/splice?
Приведите пожалуйста рабочий пример аналогичный моему.
Судя по вашему примеру, массив вам не подходит — в js массив не может быть разреженным, насколько я понимаю. А у хеша меньше возможностей :(
Самым простым, имхо, будет эмулировать хеш — отдельный массив ключей и отдельный массив значений. Сделать для этого обёртку…
Самым простым, имхо, будет эмулировать хеш — отдельный массив ключей и отдельный массив значений. Сделать для этого обёртку…
habrahabr.ru/blogs/webdev/45552/#comment_1153274 ну я так и сделал, но по-моему для такой простой задачи решение просто уродское. Тем более, что как язык javascript мне нравится больше чем php, а такие вот мелочи его просто портят.
Алсо, в первом посте очередь была взята в кавычки и написано было «из которой можно произвольно их вытаскивать». Слово «произвольно» в переводе с русского на русский означает «как угодно».
Средствами чистого xHTML/CSS/JS нельзя создать 3D графику, векторную анимацию, управлять звуком, хранить большие объемы данных на стороне клиента…
— CSS Transforms 3D
— SVG Animation
— <audio> и <video>, из HTML 5, управление воспроизведением через JS/DOM
— SQLite в HTML5, WebKit Does HTML5 Client-side Database Storage
…короче, не публикация, а чистой воды дилетантизм.
Средствами чистого xHTML/CSS/JS нельзя создать 3D графику, векторную анимацию, управлять звуком, хранить большие объемы данных на стороне клиента…
Вадим, статья действительно большая, но прочитайте, пожалуйста до конца…
Данные ограничения действительно присутствуют на данный момент при реализации web-технологий основными браузерами.
И именно WHATWG и HTML5 я привел как то, что поможет web-технологиям продолжить развитие, преодолеть ограничения и избежать гибели, на подобии псевдографического интерфейса Turbo Pascal.
storage к примеру так же будут в ie8
"…короче, не публикация, а чистой воды дилетантизм"
согласный, а пипл ведь хавает
"…короче, не публикация, а чистой воды дилетантизм"
согласный, а пипл ведь хавает
Так ведь, кроме SVG, все это еще не принятые стандарты, разве не так?
И даже SVG, сколько уж ему лет, никак не догонит Flash.
И даже SVG, сколько уж ему лет, никак не догонит Flash.
И поэтому, разработчикам приходится вручную описывать эти вкладки, меню и деревья с помощью мешанины низкоуровневых xHTML тегов: таблиц со сложными объединенными ячейками, внутри которых вложенные таблицы с большим количеством тегов и декоративных картинок для обрисовки веток.
Слёзы на глаза наворачиваются) Особенно учитывая что фонт не используют и таблицами не верстают
Непонятно, о чем статья. Не вижу трагедии в том, что html — язык разметки, он им ведь и создавался. Что предлагает автор для предотвращения ужасного апокалипсиса делать конкретно мне? Конкретно веб-разработчику?
Не справилась с управлением) (с)
Краткий пересказ основной части статьи — в этом комментарии.
Насчет тега
Насчет тега
<font> — в этом.Что предлагает автор для предотвращения ужасного апокалипсиса делать конкретно мне? Конкретно веб-разработчику?Я пытаюсь показать необычайную мощь стандартных xHTM/CSS/JS как средства построения интерфейса при правильном их понимании и использовании.
Все и так пользуются ими на полную мощь. Дело в том, что после прочтения вашей статьи возникает куча противоречий. Мешанина примеров в конце показывает, что вы недооцениваете кодеров. Устаревшие методы не используются. Для кого стандарты писаны? Книги? Читают да верстают, какие проблемы. Большинство сайтов же не на асп. А при подходе — вижу много тегов и пугаюсь человека сложно назвать программистом. Вы ж не о новичках писали, а о развитии веба в целом. Хоть убейте, не вижу новых или хотя бы чётких мыслей в статье
Вот буквально недавно (в комментариях к статье в одном блоге) затрагивал тему усиления абстракций + еще один комментарий туда же.
Можно полностью почитать те мои комментарии; а здесь я скажу основную суть, как я вижу линейный ход усиления абстракций:
В этой мешанине наиболее ключевыми фигурами являются идеологи-созидатели и прикладные созидатели (возможно — потребители продуктов идеологов)
— выделяется физическая сущность (не абстрактная), например — программирование «проводками»;
— идеологи создают абстракцию (bin- и hex- коды) и уже управляют переключением проводов сигналами кодов — 0 и 1;
— на этом этапе подключаются прикладные потребители абстракций, созданных идеологами и начинают использовать эти абстракции (называя «уродливым» программирование проводками); некоторые потребители на этом этапе становятся идеологами-созидателями (но уже относительно этого нового уровня абстракции)
— идеологи продвигаются дальше (в виду различных причин), создавая все более абстрактные сущности — так появляются ассемблеры, которые являются очень мощной абстракцией, относительно программирования hex-кодами;
— и снова подключаются прикладные потребители, называя «уродливыми» hex- и bin- коды и холиворят на «форумах», отстаивая идеи продукта (при этом не являясь создателями); так же выделяются новые идеологи, которые уже на ассемблере пишут абстракции вроде Си, Паскаль, др.
— … и т.д. (от уровня ассемблера развитие абстракций можно найти в статье)
Главное здесь — этот процесс необратим. И главное, понимать, что любая новая абстракция несет потери в ресурсах, относительно предыдущей, на старом железе и сглаживает (и опережает) — на новом. В идеале, весь код должны будут генерировать машины, люди же будут созидать иными формами «языков» (возможно, мысленно).
Можно полностью почитать те мои комментарии; а здесь я скажу основную суть, как я вижу линейный ход усиления абстракций:
В этой мешанине наиболее ключевыми фигурами являются идеологи-созидатели и прикладные созидатели (возможно — потребители продуктов идеологов)
— выделяется физическая сущность (не абстрактная), например — программирование «проводками»;
— идеологи создают абстракцию (bin- и hex- коды) и уже управляют переключением проводов сигналами кодов — 0 и 1;
— на этом этапе подключаются прикладные потребители абстракций, созданных идеологами и начинают использовать эти абстракции (называя «уродливым» программирование проводками); некоторые потребители на этом этапе становятся идеологами-созидателями (но уже относительно этого нового уровня абстракции)
— идеологи продвигаются дальше (в виду различных причин), создавая все более абстрактные сущности — так появляются ассемблеры, которые являются очень мощной абстракцией, относительно программирования hex-кодами;
— и снова подключаются прикладные потребители, называя «уродливыми» hex- и bin- коды и холиворят на «форумах», отстаивая идеи продукта (при этом не являясь создателями); так же выделяются новые идеологи, которые уже на ассемблере пишут абстракции вроде Си, Паскаль, др.
— … и т.д. (от уровня ассемблера развитие абстракций можно найти в статье)
Главное здесь — этот процесс необратим. И главное, понимать, что любая новая абстракция несет потери в ресурсах, относительно предыдущей, на старом железе и сглаживает (и опережает) — на новом. В идеале, весь код должны будут генерировать машины, люди же будут созидать иными формами «языков» (возможно, мысленно).
Спасибо. Да, я читал эту статью и ваши комментарии к ней. (Кстати, ссылка на «Стандарты кодирования для (X)HTML, CSS и JavaScript’a» есть на Хабре)
Я полностью с Вами согласен. Усиление уровня абстракции — фундаментальный процесс.
Да, он сопровождается потерей производительности. Но зато он увеличивает скорость и качество разработки; увеличение мощности железа нивелирует потери в производительности.
Да, сгенерированный низкоуровневый код часто выглядит уродливо, что приводит в ужас разработчиков с предыдущего уровня абстракции. Но более высокоуровневые программисты пишут код на высокоуровневом языке и именно на нем вылизывают его, делают более красивым и лаконичным. Поэтому, несмотря, на уродство низкоуровневого кода, код на высокоуровневом языке выглядит красиво… до тех пор, пока не появится новый уровень абстракции…
Поэтому, процесс усиления абстракции необратим.
НО! В этой статье я хотел показать следующее:
Ассемблер объективно был низкоуровневым языком, поэтому его замена языками высокого уровня была правильной и неизбежной.
Однако, xHTML/CSS/JS на самом деле являются высокоуровневыми языками построения интерфейсов; и лишь воспринимаются разработчиками как низкоуровневые.
Поэтому, их замена «псевдовысокоуровневыми» серверными контролами не является обязательной, и ее можно (и нужно) избежать.
Я полностью с Вами согласен. Усиление уровня абстракции — фундаментальный процесс.
Да, он сопровождается потерей производительности. Но зато он увеличивает скорость и качество разработки; увеличение мощности железа нивелирует потери в производительности.
Да, сгенерированный низкоуровневый код часто выглядит уродливо, что приводит в ужас разработчиков с предыдущего уровня абстракции. Но более высокоуровневые программисты пишут код на высокоуровневом языке и именно на нем вылизывают его, делают более красивым и лаконичным. Поэтому, несмотря, на уродство низкоуровневого кода, код на высокоуровневом языке выглядит красиво… до тех пор, пока не появится новый уровень абстракции…
Поэтому, процесс усиления абстракции необратим.
НО! В этой статье я хотел показать следующее:
Ассемблер объективно был низкоуровневым языком, поэтому его замена языками высокого уровня была правильной и неизбежной.
Однако, xHTML/CSS/JS на самом деле являются высокоуровневыми языками построения интерфейсов; и лишь воспринимаются разработчиками как низкоуровневые.
Поэтому, их замена «псевдовысокоуровневыми» серверными контролами не является обязательной, и ее можно (и нужно) избежать.
В двух словах:
Переход «Ассемблер → C» — это переход на новый уровень абстракции.
Переход «xHTML/CSS/JS → серверный контрол» — это не переход на новый уровень, а замена парадигмы web на десктопную Delphi / Visual Basic парадигму.
Переход «Ассемблер → C» — это переход на новый уровень абстракции.
Переход «xHTML/CSS/JS → серверный контрол» — это не переход на новый уровень, а замена парадигмы web на десктопную Delphi / Visual Basic парадигму.
А вот тут, как говорится, «собака и порылась».
Дело в том, что даже те же RIA-приложения, это, по сути, те же десктопные приложения, только работающие в браузере и они имеют аналогичную программную структуру.
Но… может так и нужно? Ведь для сложных приложений, которые будут удобны пользователю, нужен тот самый «утолщенный» функционал.
Что касается ASP.NET, то это как раз-таки абстракция (использование состояний там, где они вообще не должны быть), только, совершенно верно, не новый ее уровень. Понимая это, MS и выводит на рынок RIA-приложений технологию Silverlight, которая (или аналоги которой) в некоем будущем заменят ASP.NET WebForms.
Дело в том, что даже те же RIA-приложения, это, по сути, те же десктопные приложения, только работающие в браузере и они имеют аналогичную программную структуру.
Но… может так и нужно? Ведь для сложных приложений, которые будут удобны пользователю, нужен тот самый «утолщенный» функционал.
Что касается ASP.NET, то это как раз-таки абстракция (использование состояний там, где они вообще не должны быть), только, совершенно верно, не новый ее уровень. Понимая это, MS и выводит на рынок RIA-приложений технологию Silverlight, которая (или аналоги которой) в некоем будущем заменят ASP.NET WebForms.
я не стал зацикливаться на ASP.NET весь есть еще JAVA и JSF… хотя принцип примерно один и тотже…
«Обычно программы компилируются не в ассемблерный код, а сразу в машинный. Но, для удобства, в пределах этой статьи будем считать, что это одно и то же.»
напомнило
«Для удобства расчетов примем пи равным 4»
напомнило
«Для удобства расчетов примем пи равным 4»
для удобства этой статьи ассемблер в ней лучше вообще не трогать и не упоминать.
особенно учитывая галимый бред про стек, умножение и вызовы (-:
Который, к тому же, повторён в течении статьи несколько раз)
особенно учитывая галимый бред про стек, умножение и вызовы (-:
См. этот мой комментарий:
Стек присутствует не во всех процессорах. В старых процессорах Intel и Motorolla стека не было. Однако, потом для этих процессоров были созданы ассемблеры, в которых стек эмулировался, позволяя программисту писать код так, как будто в процессоре стек есть.
<Также, как и не было в старых ассемблерах команд деления.>
Насчет вызова функций я точно не уверен. Но, по-моему, командыCALиRETбыли чисто ассемблерными командами, и не для всех процессоров имели аналог в машинных кодах.
Но, на всякий случай, пока заменил другой «фишкой» продвинутого ассемблера — использованием макросов. «Фишкой», которая стала не нужной высокоуровневым разработчикам. Также, как станут не нужными многие «фишки», облегчающие разработку front-end разработчикам, если xHTML/CSS/JS-код будет генерироваться автоматически…
И markshevchenko согласился с отсутствие стека в старых процессорах:
Стека и функций не было на старых процессорах — это да.Правда, вы все правы, это было очень и очень давно…
Вообще говоря, ассемблерный код и объектный код, получаемый после компиляции — совершенно разные вещи. Из ассемблерного кода тоже можно получить объектный — для этого существует класс программ, называемых _ассемблерами_, которые это и делают.
ассемблер, говорите, умер? а у вас телефон есть? или стиральная машина, которую программировать можно?
ассемблер, говорите, умер? а у вас телефон есть? или стиральная машина, которую программировать можно?
ассемблер, говорите, умер? а у вас телефон есть? или стиральная машина, которую программировать можно?
Еще раз повторю свой комментарий:
См. сноску. Речь идет о мейнстримной прикладной IT-индустрии, а не о системном программировании. Тестовый редактор на ассемблере пишут только эстеты, вроде разработчиков KolibriOS.
Но это уже искусство, а не IT-индустрия.
стоп. а производство стиральных машин, микроволновок, мобильных телефонов, плейеров — не мэйнстрим?
Ну, все же, согласитесь — программирование микроволновок не является определяющим в IT-индустрии :-)
Да, сейчас ассемблер используется, но только для специальных задач.
Также, как в случае «ментальной гибели» Веба, JavaScript будет использоваться, но, опять-же, только для специальных задач.
Однако, поскольку ассемблер объективно является низкоуровневым языком, его использование только для специальных задач — правильно.
xHTML/CSS/JS только кажутся некоторым разработчикам низкоуровневым языком построения интерфейса, поэтому, при правильном понимании их возможностей, сведение этих языков к низкоуровневым-узкоспециальным можно (и нужно) избежать.
Да, сейчас ассемблер используется, но только для специальных задач.
Также, как в случае «ментальной гибели» Веба, JavaScript будет использоваться, но, опять-же, только для специальных задач.
Однако, поскольку ассемблер объективно является низкоуровневым языком, его использование только для специальных задач — правильно.
xHTML/CSS/JS только кажутся некоторым разработчикам низкоуровневым языком построения интерфейса, поэтому, при правильном понимании их возможностей, сведение этих языков к низкоуровневым-узкоспециальным можно (и нужно) избежать.
Умер. но еще не совсем.
Прослушать курс лекций, необходимо большинству разработчиков… а вот именно програмировать…
Да и собственно где это требуется?
для мало-мальских устройст уже давно есть SDK
неговоря уже о Телефонах, микроволновках и тп)
Прослушать курс лекций, необходимо большинству разработчиков… а вот именно програмировать…
Да и собственно где это требуется?
для мало-мальских устройст уже давно есть SDK
неговоря уже о Телефонах, микроволновках и тп)
Машинный код в общем случае — родной язык процессора. В случае с PC это ассемблер. Теоретически возможны процессоры с нативным кодом другого порядка. В бинарных файлах он содержится не в виде команд, а в виде 16ричных чисел, которые и означают эти команды(буквенные mov, cmp, xor — по сути мнемоники для человека), достаточно открыть файл 16риным редактором и переключиться в режим ASM. Ну и порадуйте себя, почитайте про форматы исполняемых файлов PE, ELF…
да не ассемблер — язык процессора. ассемблер — изначально был лишь мнемоникой над машинным кодом. сейчас же ассемблер — полноценный низкоуровневый язык, который нужно приводить к машинному коду более сложными методами.
а 16-ричные числа — лишь одно из представлений машинных кодов, относительно удобоваримое для человека.
а 16-ричные числа — лишь одно из представлений машинных кодов, относительно удобоваримое для человека.
> да не ассемблер — язык процессора.
сами Вы язык «процессора»! :D есть только два положения — «есть напряжение / нет напряжения» и мнемокоды и hex- код (и даже bin- коды) — все это абстрагированные от физического проявления (есть напряжение / нет напряжения) сущности.
сами Вы язык «процессора»! :D есть только два положения — «есть напряжение / нет напряжения» и мнемокоды и hex- код (и даже bin- коды) — все это абстрагированные от физического проявления (есть напряжение / нет напряжения) сущности.
> сами Вы язык «процессора»!
ток прошу — не обижайтесь )) я по-доброму сказал )
это я к тому, что процессор — камень, кристал, железка — она не знает никаких ассемблеров
ток прошу — не обижайтесь )) я по-доброму сказал )
это я к тому, что процессор — камень, кристал, железка — она не знает никаких ассемблеров
да не ассемблер — язык процессора
да не, ассемблер — язык процессора
есть разница?
да, коды — абстракция. но именно она является _интерфейсом_ управления процессором. а то так и напряжение можно свести к электронным потокам.
да не, ассемблер — язык процессора
есть разница?
да, коды — абстракция. но именно она является _интерфейсом_ управления процессором. а то так и напряжение можно свести к электронным потокам.
Интересно, на чем программирует автор? Полстатьи написано о ASP.NET, но это таааак далеко от реальности. Возьмем хотя бы это:
Какие таблицы, какой, черт возьми, <font>! Какой сейчас год на дворе? Когда писалась статья? Страшно, страшно далек автор от веб-программирования.
Дерево — это не мешанина таблиц, вложенных таблиц, тегов <font> и картинок.
Какие таблицы, какой, черт возьми, <font>! Какой сейчас год на дворе? Когда писалась статья? Страшно, страшно далек автор от веб-программирования.
Какие таблицы, какой, черт возьми, <font>!Пожалуйста, прочитайте до конца…
Я привожу гиперболизированный пример старого, низкоуровневого подхода к построению web-интерфейсов.
Которому противостоит новый — семантичный, высокоуровневый.
По-моему семантичный и высокоуровневый в данном случае разные вещи. Вы вообще о чем? О верстке? Вы в статье говорили только о представлении информации и не затронули само программирование
По-моему семантичный и высокоуровневый в данном случае разные вещи.
Я о высокоуровневости. Но высокоуровневое применение xHTML подразумевает и семантичное его использование.
Пример:
Если мы используем xHTML на низком уровне, то для кодирования дерева применяем мешанину тегов. Которая, разумеется не семантична.
При высокоуровневом подходе мы, соответственно применяем высокоуровневую конструкцию — «список». Которая рдновременно и семантична.
вообще все непонятно
что значит «низкоуровневый подход в XHTML» для кодирования дерева?
что значит «низкоуровневый подход в XHTML» для кодирования дерева?
При низкоуровневом подходе, мы кодируем интерфейсный элемент множеством низкоуровневых тегов.
Например, дерево кодируется при помощи сложной вложенной таблицы и изображений.
При высокоуровневом подходе, интерфейсный элемент кодируется одной соответствующей ему высокоуровневой xHTML конструкцией + CSS и JS.
Например, дерево кодируется с помощью одного обычного списка + CSS оформление и JS-фанкциональность.
Например, дерево кодируется при помощи сложной вложенной таблицы и изображений.
При высокоуровневом подходе, интерфейсный элемент кодируется одной соответствующей ему высокоуровневой xHTML конструкцией + CSS и JS.
Например, дерево кодируется с помощью одного обычного списка + CSS оформление и JS-фанкциональность.
жесть какая-то, низкоуровневые теги, высокоуровневые теги…
я всегда дерево списком представлял — куда уж проще-то, да и многие реализации дерева тоже формируют список
это не «низкоуровневый подход», это руки кривые
я всегда дерево списком представлял — куда уж проще-то, да и многие реализации дерева тоже формируют список
это не «низкоуровневый подход», это руки кривые
я всегда дерево списком представлял — куда уж проще-то, да и многие реализации дерева тоже формируют список.Сделать дерево на основе списка — не такая уж и тривиальная задача. Я имею в виду, конечно, не просто дерево, а дерево с ветками, как на рисунке:
это не «низкоуровневый подход», это руки кривые
Попробуйте, если интересно, не заглядывая в интернет, сделать такое на досуге, используя только список и стили. Здесь требуется чуть повышенное знание CSS и некоторая изобретательность.
И многие библиотеки контролов до сих пор вместо списков используют низкоуровневую мешанину тегов и/или таблицы. Основные библиотеки сразу не вспомню, пока вот в голову приходит BlueShoes.
Поэтому, многие разработчики, не до конца понявшие CSS, вместо высокоуровневого списка используют низкоуровневую кашу из тегов. А, поскольку, с низкоуровневой кашей им работать не удобно, переходят на «псевдовысокоуровневые» серверные контролы.
Хотя, если чуть лучше понять клиентские технологии, станет понятно, как можно использовать прекрасный высокоуровневый список, и тогда низуоуровневая каша из тегов или серверные контролы становятся совсем не обязательны.
Это, как раз, среди прочего, я и хотел показать в статье.
я, в общем-то, и имел ввиду дерево с ветками, и да, я сделал такое, но не на досуге, а по долгу службы, и не заглядывая в интернет, особо сложного я тут не вижу ничего
еще раз хочу сказать, это не «низкий уровень», а руки кривые (или в случае с вашей библиотекой — нежелание рефакторить код)
«низкий уровень» — это, например, использование «чистого js» безо всяких фреймворков, а «низкоуровневых тегов» не бывает
кстати, никто не мешает использовать серверный контрол, который может генерировать наш «прекрасный высокоуровневый список»
еще раз хочу сказать, это не «низкий уровень», а руки кривые (или в случае с вашей библиотекой — нежелание рефакторить код)
«низкий уровень» — это, например, использование «чистого js» безо всяких фреймворков, а «низкоуровневых тегов» не бывает
кстати, никто не мешает использовать серверный контрол, который может генерировать наш «прекрасный высокоуровневый список»
См. также этот комментарий.
Очень хорошо, что Вы используете правильный, высокоуровневый подход к HTML.
Просто многие разработчики (у которых «руки кривые», или скорее всего, просто не успели или не захотели освоить новый подход) продолжают использовать старый низкоуровневый подход. В котором дерево описывается мешаниной тегов.
Такой подход не удобен, как и все низкоуровневые подходы.
Поэтому, часть разработчиков пытается уйти от «низкоуровневого» HTML к более «высокоуровневым» серверным контролам.
Но, если понять правильный высокоуровневый подход, в котором дерево описывается не мешаниной тегов, а единой высокоуровневой конструкцией — списком, то программировать HTML становится удобно, и нужда в серверных контролах пропадает.
Вот, что я хотел показать.
Очень хорошо, что Вы используете правильный, высокоуровневый подход к HTML.
Просто многие разработчики (у которых «руки кривые», или скорее всего, просто не успели или не захотели освоить новый подход) продолжают использовать старый низкоуровневый подход. В котором дерево описывается мешаниной тегов.
Такой подход не удобен, как и все низкоуровневые подходы.
Поэтому, часть разработчиков пытается уйти от «низкоуровневого» HTML к более «высокоуровневым» серверным контролам.
Но, если понять правильный высокоуровневый подход, в котором дерево описывается не мешаниной тегов, а единой высокоуровневой конструкцией — списком, то программировать HTML становится удобно, и нужда в серверных контролах пропадает.
Вот, что я хотел показать.
про «низкоуровневые теги» слышу впервые :)
Попробую объяснить, чо я имею в виду под «низкоуровневыми» и «высокоуровневыми» тегами.
Компьютерные языки (как программирования, так и разметки) бывают высокоуровневыми и низкоуровневыми.
В более высокоуровневых языках сущность реального мира описывается одной конструкцией языка.
В более низкоуровневых языках та же сущность описывается как набор своих составных частей множеством низкоуровневых конструкций.
На низкоуровневых языках писать не удобно, поэтому программисты предпочитают писать код на более высокоуровневых языках, который затем компилируется (или рендерится) в код низкоуровневый.
Старый подход к HTML — низкоуровневый. При нем разработчики описывают эти высокоуровневые интерфейсные элементы множеством низкоуровневых тегов. (Как операция деления в некоторых ассемблерах описывается множеством команд сложения и сдвига).
Такой подход не удобен, как и все низкоуровневые подходы.
Поэтому, часть разработчиков пыталась уйти от «низкоуровневого» HTML к более «высокоуровневым» серверным контролам. Которые затем «компилируются» (трансформируется) в HTML, подобно тому, как C++ компилируется в машинный код.
Однако, есть и новый подход — высокоуровневый. И почти любой интерфейсный элемент может быть описан не мешаниной низкоуровневых тегов, а единственной конструкцией xHTML. Дерево — списокм, вкладки набором div'ов и т.д. (также, как операция деления на С++ описывается единственным оператором "/"). Правда, для этого нужен чуть новый подход и чуть большее знание CSS.
Так вот: при таком высокоуровневом подходе программировать удобно, поэтому и не требуются серверные контролы.
Компьютерные языки (как программирования, так и разметки) бывают высокоуровневыми и низкоуровневыми.
В более высокоуровневых языках сущность реального мира описывается одной конструкцией языка.
В более низкоуровневых языках та же сущность описывается как набор своих составных частей множеством низкоуровневых конструкций.
Пример 1:
В более высокоуровневом языке программирования C++ операции деления соответствует одна конструкция языка – оператор «/».
В более низкоуровневом ассемблере (не во все, конечно) операции деления соответствует множество ассемблерных команд.
Пример 2:
В более высокоуровневом языке разметки SVG круг описывается соответствующей конструкцией:<circle cx="200px" cy="200px" r="100px" />
В более низкоуровневом «языке разметки» растрового файла этот круг описывается множеством точек.
На низкоуровневых языках писать не удобно, поэтому программисты предпочитают писать код на более высокоуровневых языках, который затем компилируется (или рендерится) в код низкоуровневый.
Старый подход к HTML — низкоуровневый. При нем разработчики описывают эти высокоуровневые интерфейсные элементы множеством низкоуровневых тегов. (Как операция деления в некоторых ассемблерах описывается множеством команд сложения и сдвига).
Такой подход не удобен, как и все низкоуровневые подходы.
Поэтому, часть разработчиков пыталась уйти от «низкоуровневого» HTML к более «высокоуровневым» серверным контролам. Которые затем «компилируются» (трансформируется) в HTML, подобно тому, как C++ компилируется в машинный код.
Однако, есть и новый подход — высокоуровневый. И почти любой интерфейсный элемент может быть описан не мешаниной низкоуровневых тегов, а единственной конструкцией xHTML. Дерево — списокм, вкладки набором div'ов и т.д. (также, как операция деления на С++ описывается единственным оператором "/"). Правда, для этого нужен чуть новый подход и чуть большее знание CSS.
Так вот: при таком высокоуровневом подходе программировать удобно, поэтому и не требуются серверные контролы.
Еще один момент против использования большинства новых технологий — скорость.
Как мне кажется, скорость передачи данных и необоснованно громадное количество съедаемой памяти браузером для поддержки новых плагинов держит html и т.д. на плаву… и будут делать это долго. Я имею виду что да, мы смотрим видео… и это ресурсоемко, но!.. когда я хочу походить по информационным страничкам терпеть загрузку java-машины(или Silverlight)… я хочу моментального отклика…
К тому же трафик… тоже не последняя причина при наших ценах на тарифах сотовых операторов…
т.е. простое элегантное клиентское решение на html/css/javascript+php|python|ruby|java|asp пока выигрышно… и потенциал решений и находок не исчерпан.
Как мне кажется, скорость передачи данных и необоснованно громадное количество съедаемой памяти браузером для поддержки новых плагинов держит html и т.д. на плаву… и будут делать это долго. Я имею виду что да, мы смотрим видео… и это ресурсоемко, но!.. когда я хочу походить по информационным страничкам терпеть загрузку java-машины(или Silverlight)… я хочу моментального отклика…
К тому же трафик… тоже не последняя причина при наших ценах на тарифах сотовых операторов…
т.е. простое элегантное клиентское решение на html/css/javascript+php|python|ruby|java|asp пока выигрышно… и потенциал решений и находок не исчерпан.
Полностью согласен. Я бы не стал вообще как-то ассоциировать html c ассемблером. Ну разные это вещи и имеют различное предназначение.
Еще один момент против использования большинства новх технологий — скорость.А вот здесь я не совсем согласен…
Уменьшение производительности и скорости работы при переходе на новый уровень абстракции — неизбежность. Но, которая, благодаря увеличению мощности железа, в большинстве случаев (за исключением маломощного железа, вроде микроволновок, для которых до сих пор пишут на ассемблере), не мешает переходу на новый уровень.
И, поэтому, xHTML/CSS/JS останутся на плаву не потому, что они низкоуровневы (и соответственно, быстрее работают), а потому что они — очень мощные и гибкие технологии создания web-интерфейсов.
Но, все равно, спасибо за замечание.
Ключевой идеей, на которой построены выводы является проведенная аналогия между вебом и прикладным программированием. Но эта аналогия недостаточна. В современном вебе есть две, качественно разные, категории продуктов. Приложения, где вполне оправданными могут быть (и ИМХО есть) аналогии с прикладным программированием, и сайты, которые и близко не похожи на прикладные программы и никогда такими не станут. Так вот для приложений все уже случилось, никто не пишет их на чистом хтмл (хотя JS и CSS во многих местах сохранились), используются библиотеки, наборы компонентов, целыe фреймворки и в конце концов технологии вроде flex'a и silverlight'a. Но для сайтов это вряд ли вообще когда-нибудь случится когда-нибудь в силу многих причин.
Кстати еще одни аргументом против ментальной гибели html/css является как раз wpf и подобные технологии. XAML и тамошняя система стилей очень даже напоминает html и css
Кстати еще одни аргументом против ментальной гибели html/css является как раз wpf и подобные технологии. XAML и тамошняя система стилей очень даже напоминает html и css
Согласен по сути. Наконец-то нашёл точку зрения, которая совпадает с моей. Статья особо не разделяет сайты на виды, а пытается подходит в общем. И тут разработка HTML5 будет не таким уж большим шагом вперёд, а скорее только продолжит агонию Веб-а.
Думаю, что говорить о смерти HTML-а рано. На тех сайтах, где нужна семантическая разметка информации — он так и останется доминировать. А на сайта, которые реализуют RIA будут использоваться более удобные технологии с возможностями быстрой разработки. Спасибо автору заметки, я открыл для себя Flex (беглое ознакомление впечатляет и если дальше будет так же хорошо, то огромное спасибо автору! :) ).
Думаю, что говорить о смерти HTML-а рано. На тех сайтах, где нужна семантическая разметка информации — он так и останется доминировать. А на сайта, которые реализуют RIA будут использоваться более удобные технологии с возможностями быстрой разработки. Спасибо автору заметки, я открыл для себя Flex (беглое ознакомление впечатляет и если дальше будет так же хорошо, то огромное спасибо автору! :) ).
сайты, которые реализуют RIAВ статье идет речь только о web-приложениях (прикладных программах, а не сайтах).
Так вот, я считаю, что xHTML/CSS/JS — это очень хорошие технологии именно для создания RIA интерфейсов web-приложений.
И, HTML5 не продолжит агонию Веба, а будет одним из шагов развития xHTML/CSS/JS как технологий создания web-приложений.
Спасибо автору заметки, я открыл для себя FlexНа здоровье! Всегда рад помочь хотя бы одному
«а пользуются уродскими библиотеками, вроде Prototype.js»
Помоему как-то грубо. Сам использую jQuery в основном, но в то же время Prototype(который кстати фреймворк) так грубо нельзя называть. Он делает более легким решение определенного количество задач. Никто не запрещает разработчикам дополнять этот функционал.
Помоему как-то грубо. Сам использую jQuery в основном, но в то же время Prototype(который кстати фреймворк) так грубо нельзя называть. Он делает более легким решение определенного количество задач. Никто не запрещает разработчикам дополнять этот функционал.
Да, действительно, статья довольно длинная, поэтому я старался писать ее более живо, отчасти даже несколько грубо и провокационно.
Prototype.js действительно сделал большое доброе дело, когда в свое время был чуть-ли не единственной библиотекой, облегчающей работу с DOM. На сколько я помню (хотя, могу и ошибаться) легендарная функция
Но, к сожалению, Prototype.js пошел в сторону упрощения (а точнее обеднения) JavaScript'а, лишая его красоты и гибкости.
Из-за этого, многие разработчики думают, что знают JavaScript, хотя, на самом деле они знают только Prototype.js.
Prototype.js действительно сделал большое доброе дело, когда в свое время был чуть-ли не единственной библиотекой, облегчающей работу с DOM. На сколько я помню (хотя, могу и ошибаться) легендарная функция
$(id) впервые появилась именно в нем…Но, к сожалению, Prototype.js пошел в сторону упрощения (а точнее обеднения) JavaScript'а, лишая его красоты и гибкости.
Из-за этого, многие разработчики думают, что знают JavaScript, хотя, на самом деле они знают только Prototype.js.
можно поинтересоваться, в чем prototype лишил javascript красоты и гибкости?
Еще многи разработчики думают, что знают PHP и что с того? Prototype не виноват в том, что многие там себе напридумывают. Насколько я помню(давно пользовался Prototype), там есть блок, в котором можно писать чистым javascript.
> Из-за этого, многие разработчики думают, что знают JavaScript, хотя, на самом деле они знают только Prototype.js.
повторяю (Вы, кстати, игнорировали мой коммент выше) — не стоит холиворить с теми, кто пока на начальном этапе изучения JS и можетпо дурости из-за нехватка информации нести всякую чушь aka «классы! классы! ибо Class.create()!». Вы-то знаете, что в ECMAScript на данный момент прототипное наследование. А вот то, что Вы постоянно пишите про «надругались!» — это тоже говорит о том, что Вы мыслите ограничено.
Вот здесь и здесь я проводил аналогию протипного наследования JS с классовой моделью Python'а. Почитайте; если Вам нравится JavaScript, Вам будет интересно. Поэтому, не волнуйтесь по поводу новичков, которые будут Вам доказывать, что они выучились JS по Prototype.js и уверены, что классы в JS есть — у них все еще впереди. А вот если Вы будете мыслить системно и абстрактно, то увидите, что роль классов в JS (пусть в больших кавычках) играет прототип конструктора (как подтверждение — схожая модель в Питоне, и там и там налицо — делегация).
повторяю (Вы, кстати, игнорировали мой коммент выше) — не стоит холиворить с теми, кто пока на начальном этапе изучения JS и может
Вот здесь и здесь я проводил аналогию протипного наследования JS с классовой моделью Python'а. Почитайте; если Вам нравится JavaScript, Вам будет интересно. Поэтому, не волнуйтесь по поводу новичков, которые будут Вам доказывать, что они выучились JS по Prototype.js и уверены, что классы в JS есть — у них все еще впереди. А вот если Вы будете мыслить системно и абстрактно, то увидите, что роль классов в JS (пусть в больших кавычках) играет прототип конструктора (как подтверждение — схожая модель в Питоне, и там и там налицо — делегация).
Необычно большая статья для нынешнего хабра… Прям прорвало авторов, сегодня есть что почитать, спасибо:)
По поводу статьи, имхо, автор попытками экстраполировать и категоризировать варианты вызвал шквал негодования в комментах. Вообще, такое ощущение, что автор хочет, чтобы веб так и остался на основе HTML, который он выучил ещё в школе:) Возможно, непрерывным развитием он и будет оставаться основой веба, но если придёт ему на смену другая технология — энергичная, расширяемая, стандартизированая — то, я думаю, мало кто будет скучать по «старым добрым временам предсемантичного веба, гуглепочты, войны браузеров и всего такого»:)
По поводу статьи, имхо, автор попытками экстраполировать и категоризировать варианты вызвал шквал негодования в комментах. Вообще, такое ощущение, что автор хочет, чтобы веб так и остался на основе HTML, который он выучил ещё в школе:) Возможно, непрерывным развитием он и будет оставаться основой веба, но если придёт ему на смену другая технология — энергичная, расширяемая, стандартизированая — то, я думаю, мало кто будет скучать по «старым добрым временам предсемантичного веба, гуглепочты, войны браузеров и всего такого»:)
Вообще, такое ощущение, что автор хочет, чтобы веб так и остался на основе HTML, который он выучил ещё в школе:)Я хочу показать, что в стандартной связке xHTML/CSS/JS гораздо больше возможностей для построения интерфейсов, чем считают многие разработчики.
>
Я хочу показать, что в стандартной связке xHTML/CSS/JS гораздо больше возможностей для построения интерфейсов, чем считают многие разработчики.
<
Вау, а там есть какие-то ограничения??))
Я хочу показать, что в стандартной связке xHTML/CSS/JS гораздо больше возможностей для построения интерфейсов, чем считают многие разработчики.
<
Вау, а там есть какие-то ограничения??))
Вопрос не понял… Пожалуйста, уточните.
>Я хочу показать, что в стандартной связке xHTML/CSS/JS гораздо больше возможностей для построения интерфейсов,
<
Говоря такое предложение, вы говорите что они чем — то ограничены.
Возможности.
вопрос — < чем, они конкретно ограничены?
<
Говоря такое предложение, вы говорите что они чем — то ограничены.
Возможности.
вопрос — < чем, они конкретно ограничены?
Особенностями протокола HTTP и средой обработки всей этой радости — антивирус, например, на этой связке не напишешь, только на ActiveX…
Тогда зачем вы написали столько много букв в этой статье?
Лучше бы сразу написали научно-популярную статью «о создании богатого пользовательского интерфейса средствами xHTML/CSS/JS» (и без всяких сравнений ассемблеров и С++).
Лучше бы сразу написали научно-популярную статью «о создании богатого пользовательского интерфейса средствами xHTML/CSS/JS» (и без всяких сравнений ассемблеров и С++).
Тогда зачем вы написали столько много букв в этой статье?Эта статья не только «о создании богатого пользовательского интерфейса средствами xHTML/CSS/JS».
Лучше бы сразу написали научно-популярную статью «о создании богатого пользовательского интерфейса средствами xHTML/CSS/JS» (и без всяких сравнений ассемблеров и С++).
В этой статье я хотел показать, какие существуют угрозы для xHTML/CSS/JS-технологий:
— Ментальная гибель: останутся физически, но исчезнут из сознания разработчиков, накрывшись высокоуровневыми абстракциями, вроде серверных контролов, став низкоуровневыми языками — новым ассемблером;
— Физическая гибель: исчезнут полностью, уступив место Silverlight или Flex.
… и о том, как их избежать:
— Ментальной гибели не будет, если web-технологии будут правильно поняты.
— Физической гибели не будет, если web-технологии будут развиваться как технологии создания web-приложений под руководством WHATWG.
Раздел «о создании богатого пользовательского интерфейса средствами xHTML/CSS/JS» — лишь иллюстрация тезиса о том, что xHTML/CSS/JS должны правильно восприниматься как высокоуровневые технологии построения интерфейса.
Раздел с асесемблером — иллюстрация возможной «ментальной гибели» xHTML/CSS/JS (подобно той, какая случилась с ассемблером в сознании высокоуровневых прикладных разработчиков).
И все таки высокоуровневые языки сначала транслируются в ассемблер, а потом уже в машинный код. Взять тот же gcc
И все таки высокоуровневые языки сначала транслируются в ассемблер, а потом уже в машинный код. Взять тот же gccДа, но не всегда.
Так что компилирование программы на высокоуровневом языке в ассемблерный код (а не сразу в машинный) — не такая чушь, как меня пытаются упрекнуть :-)
Хотя, конечно, сейчас это используется не часто.
Чего не понравилось, это то что проблема ставится, когда решение уже в процессе и то что в течении статьи часть фраз банально повторяется.
Хорошая статья.
Правда, ассемблер, например, еще не забыт разработчиками. Когда нужна скорость (например, в расчете физики), на низком уровне пишут операции вроде перемножения матриц, которое превосходит по скорости высокоуровневое чуть ли не в сотни раз.
Также, насколько я понимаю, сейчас не так уж и много ASP.NET-разработчиков. Я бы не стал бить тревогу. Адекватные разработчики (коих немало), я уверен, будут пользоваться «низкоуровневыми» инструментами, и, как вы, понимают к чему приведет полный переход на s#, Silverlight (с WPF) и т.д.
Насчет Prototype. Ничего не могу сказать насчет prototype, не использую :-) Поэтому, насчет jQuery. Когда я начал использовать jQuery, я мягко говоря был слаб в JS, понравился он мне из-за простоты. Но, когда я купил хорошую книгу и начал походу поглядывать на устройтсво jQuery, месяца за два-три стал очень неплохо понимать JavaScript, со всей его гибкостью.
Правда, ассемблер, например, еще не забыт разработчиками. Когда нужна скорость (например, в расчете физики), на низком уровне пишут операции вроде перемножения матриц, которое превосходит по скорости высокоуровневое чуть ли не в сотни раз.
Также, насколько я понимаю, сейчас не так уж и много ASP.NET-разработчиков. Я бы не стал бить тревогу. Адекватные разработчики (коих немало), я уверен, будут пользоваться «низкоуровневыми» инструментами, и, как вы, понимают к чему приведет полный переход на s#, Silverlight (с WPF) и т.д.
Насчет Prototype. Ничего не могу сказать насчет prototype, не использую :-) Поэтому, насчет jQuery. Когда я начал использовать jQuery, я мягко говоря был слаб в JS, понравился он мне из-за простоты. Но, когда я купил хорошую книгу и начал походу поглядывать на устройтсво jQuery, месяца за два-три стал очень неплохо понимать JavaScript, со всей его гибкостью.
Да JavaScript действительно очень интересный, гибкий и т.д. язык. Проблема не в том, что он не понят. Проблема в том, что само веб-программирование долгое время воспринималось как детская игрушка. Это сейчас появилась такая профессия как веб-технолог, это сейчас появились веб-приложения, которые по сложности и функциональности перещеголяли своих настольных братьев, это сейчас остро стал вопрос о профессионалах, которые могут написать грамотный, оптимальный, понятный, легко модифицируемый код. У меня нет статистических данных, но я уверен, что куда более 50% работающего js-кода — это быдлокод.
Так что с JS уж точно все будет в порядке — те тенденции, которые выделили вы должны только упрочить его положение (в индустрию придут хорошие программисты, потому что большинство самоучек скорее всего не потянут сложность современных и будущих веб-приложений).
Предлагаю думать о хорошем и ожидать повышение уровня программистов (не только JS, но PHP, Perl, верстальщиков и т.д.), хотя согласен — костыли, подобные тем, что вы описали в своей статье могут сместить баланс в другую сторону (вместо хороших программистов появятся вспомогательные технологии). С другой стороны посудите сами — за веб-приложениями будущее. Уже сейчас на хабре можно прочитать мечты о программах, которые придут на смену современным настольным приложеням. Web-игры с абонентской платой или даже оплачиваемы за счет рекламы, фильмы, которые абсолютно легально можно будет посмотреть в сети, заплатив за это приемлемую сумму и т.д… Я думаю, что в ближайшее время быть web-программистом станет не только прибыльно, но и престижно. Веб-приложения уже перестали быть простенькими поделками.
Единственное, я не понял чем вам не угодила эмуляция классов? Мне она очень помогает и экономит много времени. :(
Так что с JS уж точно все будет в порядке — те тенденции, которые выделили вы должны только упрочить его положение (в индустрию придут хорошие программисты, потому что большинство самоучек скорее всего не потянут сложность современных и будущих веб-приложений).
Предлагаю думать о хорошем и ожидать повышение уровня программистов (не только JS, но PHP, Perl, верстальщиков и т.д.), хотя согласен — костыли, подобные тем, что вы описали в своей статье могут сместить баланс в другую сторону (вместо хороших программистов появятся вспомогательные технологии). С другой стороны посудите сами — за веб-приложениями будущее. Уже сейчас на хабре можно прочитать мечты о программах, которые придут на смену современным настольным приложеням. Web-игры с абонентской платой или даже оплачиваемы за счет рекламы, фильмы, которые абсолютно легально можно будет посмотреть в сети, заплатив за это приемлемую сумму и т.д… Я думаю, что в ближайшее время быть web-программистом станет не только прибыльно, но и престижно. Веб-приложения уже перестали быть простенькими поделками.
Единственное, я не понял чем вам не угодила эмуляция классов? Мне она очень помогает и экономит много времени. :(
Есть замечания. но основная идея понятна… Что ж тк являюсь диким оптимизатором. то обычно пишу на «корневом» языке.
А про общество разработчиков в целом… просто пока это некий переходный период. Нужно знать много по чуть-чуть и где-то углубленно. Поэтому как более или менее всё станет стабильнее будут отличные отряды PRO ребят))
А про общество разработчиков в целом… просто пока это некий переходный период. Нужно знать много по чуть-чуть и где-то углубленно. Поэтому как более или менее всё станет стабильнее будут отличные отряды PRO ребят))
Консольная библиотека для построения интерфейсов, которая использовалась в продуктах Borland, называлась Turbo Vision. Очень неплохая ООП библиотека, с теми же идеями и объектной моделью, что сейчас используются для построения интерфексов. В оригинале на паскале, но были порты на сях, а также под платформу unix.
HTML уже превратился в ассемблер. Вопрос в том, что будет для него «языком высокого уровня». Есть различные концепции, например, GWT и JSF, которые имплементируют компонентную модель, не вдаваясь в подробности рендеринга (генерации html-кода). В принципе, это направление правильно. Возможности рендеринга html очень убоги (по сравнению с flex, silverlight, javafx), а компонентная модель позволит в будущем абстрагироваться от «языка низкого уровня».
Почему HTML не умрет? Потому, что он не создан и не был задуман как платформа для функционирования апликаций, но как язык разметки документа. На сей день html — это лучший и универсальный способ для представления гипертекстовой статичной информации. Все фреймворки и технологии «высокого уровня» ориентированы на создание интерфейсов сложных динамичных веб апликаций, тогда как не каждый сайт апликация. Иногда просто нужно показать красиво сверстанную информацию с минимальным динамизмом.
HTML уже превратился в ассемблер. Вопрос в том, что будет для него «языком высокого уровня». Есть различные концепции, например, GWT и JSF, которые имплементируют компонентную модель, не вдаваясь в подробности рендеринга (генерации html-кода). В принципе, это направление правильно. Возможности рендеринга html очень убоги (по сравнению с flex, silverlight, javafx), а компонентная модель позволит в будущем абстрагироваться от «языка низкого уровня».
Почему HTML не умрет? Потому, что он не создан и не был задуман как платформа для функционирования апликаций, но как язык разметки документа. На сей день html — это лучший и универсальный способ для представления гипертекстовой статичной информации. Все фреймворки и технологии «высокого уровня» ориентированы на создание интерфейсов сложных динамичных веб апликаций, тогда как не каждый сайт апликация. Иногда просто нужно показать красиво сверстанную информацию с минимальным динамизмом.
Консольная библиотека для построения интерфейсов, которая использовалась в продуктах Borland, называлась Turbo Vision.Да. Я упомянул «Turbo Vision» в тегах к статье.
Очень неплохая ООП библиотека«Turbo Vision» — не просто неплохая библиотека, «Turbo Vision» была гениальной!
Все, что было в распоряжении «Turbo Vision» — это текстовая матрица из 80 * 25 символов ASCII, их цвет и фон. Все!
Из этих текстовых символов она сделала невозможное: реализовала многооконный интерфейс, с главным и контекстным меню, псевдо-трехмерными нажимающимися кнопками, технологией перетаскивания окон… В общем, почти все, что сейчас есть в современной графической Windows'овской программе.
Однако, несмотря на свою гениальность; она выжала из текстовой матрицы ВСЕ, и преодолеть фундаментальные ограничения текстового интерфейса была не в состоянии. Как ни старайся, нельзя нарисовать объект тоньше одного символа или провести диагональную, а тем более изогнутую линию.
Поэтому, «Turbo Vision» ушла в историю, уступив место графическим библиотекам Windows.
Тоже самое может ожидать и xHTML. Несмотря на невероятную изобретательность ряда web-разработчиков, сумевших выжать из xHTML невозможное; в xHTML сейчас есть фундаментальные ограничения, которые не позволяют реализовывать некоторые интерфейсные возможности. И, если xHTML перестанет развиваться как технология создания web-приложений, то она может исчезнуть, уступив место Flex или Silverlight, подобно тому, как «Turbo Vision» ууступила место графическим библиотекам Windows («гибель физическая»).
Однако, я уверен, под руководством WHATWG, развитие xHTML/CSS/JS как технологий создания web-приложений будет продолжено, ит HTML5 — хороший тому пример.
HTML уже превратился в ассемблер.А вот с этим я совсем не согласен.
Действительно, для разработчиков ASP.NET, GWT, JSF — xHTML действительно, во многом, стал ассемблером. Но, есть также и большое число разработчиков, использующих xHTML/CSS/JS на высоком уровне.
И не только для создания сайтов (язык разметки), но и для создания web-приложений (язык построения богатых интерфейсов). В xHTML/CSS/JS (особенно с учетом их развития) есть для этого все возможности. И надо только правильно понять и воспользоваться ими…
> Однако, несмотря на свою гениальность; она выжала из текстовой матрицы ВСЕ
Неа, не совсем все :) Меня в то время поражал дизайн нортоновских утилит под DOS. Оконный интерфейс был сделан в текстовом режиме, но полностью походивший на Windows. И причем, был графический курсор мыши, а также приятная палитра background цветов!!! С цветами я разобрался быстро. Мне стало понятно, что они часть графической информации записывают прямо в знакогенератор так, чтобы рамки окон и прочие эффекты выглядели натуральными. Я дописал к Turbo Vision экстеншн, который позволял значительно улучшить дизайн окошек и теней. В свое время он бродил по сети фидо. А потом наткнулся на библиотечку, реализующую графическую мышь в текстовом режиме. К сожалению, примерно в это время эра текстовых программ подошла к концу.
Неа, не совсем все :) Меня в то время поражал дизайн нортоновских утилит под DOS. Оконный интерфейс был сделан в текстовом режиме, но полностью походивший на Windows. И причем, был графический курсор мыши, а также приятная палитра background цветов!!! С цветами я разобрался быстро. Мне стало понятно, что они часть графической информации записывают прямо в знакогенератор так, чтобы рамки окон и прочие эффекты выглядели натуральными. Я дописал к Turbo Vision экстеншн, который позволял значительно улучшить дизайн окошек и теней. В свое время он бродил по сети фидо. А потом наткнулся на библиотечку, реализующую графическую мышь в текстовом режиме. К сожалению, примерно в это время эра текстовых программ подошла к концу.
Ну да, согласен, и я о том же.
Оконные библиотеки, работающие в текстовом режиме (Turbo Vision, нортоновские библиотеки и т.д.), как бы хороши они не были, не могли преодолеть фундаментальные ограничения текстового режима и были вытеснены оконными библиотеками режима графического.
Судьба оконных библиотек текстового режима может ожидать и интерфесы на xHTML/CSS/JS, если они не будут развиваться.
Как бы не были хороши интерфейсы на xHTML/CSS/JS, они не могут преодолеть мультимедийные ограничения этих технологий. И, поэтому, могут исчезнуть, уступив место интерфейсам на основе Flex/Silverlight.
Но, в отличает от текстового режима, который объективно не мог преодолеть ограничения матрицы из символов, у xHTML/CSS/JS есть очень хорошие шансы на развитие.
И, если xHTML/CSS/JS воспользуются своим шансом на развитие, то они избегут гибели, подобно той, что случилась с оказавшимися в тупике текстовыми библиотеками.
А HTML5 — важный шаг в этом развитии.
Оконные библиотеки, работающие в текстовом режиме (Turbo Vision, нортоновские библиотеки и т.д.), как бы хороши они не были, не могли преодолеть фундаментальные ограничения текстового режима и были вытеснены оконными библиотеками режима графического.
Судьба оконных библиотек текстового режима может ожидать и интерфесы на xHTML/CSS/JS, если они не будут развиваться.
Как бы не были хороши интерфейсы на xHTML/CSS/JS, они не могут преодолеть мультимедийные ограничения этих технологий. И, поэтому, могут исчезнуть, уступив место интерфейсам на основе Flex/Silverlight.
Но, в отличает от текстового режима, который объективно не мог преодолеть ограничения матрицы из символов, у xHTML/CSS/JS есть очень хорошие шансы на развитие.
И, если xHTML/CSS/JS воспользуются своим шансом на развитие, то они избегут гибели, подобно той, что случилась с оказавшимися в тупике текстовыми библиотеками.
А HTML5 — важный шаг в этом развитии.
А почему JavaFX не упомянули? Тоже красивый и мощный язык, может работать с Java классами. На днях выходит официальный релиз.
Дочитал про xHTML и бросил. Автор пытается дать экспертный прогноз, описывая при этом такие вещи, которые для профессиональный веб-разработчиков очевидны (я про семантику и проч.). Извините, но это скорее статья в какой-нибудь популярный журнал, где все обо всем. Ощущение, что автор сам профессиоанально описанные технологии не использует (или использовал раньше).
Уберите амбициозное предсказательство и станет нормальная обычная статья.
Также ни к чему там упоминание про ассемблер. Тем более (но я не специалист в этом области), по-моему компиляция происходит в объектный код или как-то так; и не «ассемблер», а «язык ассемблера». Думаю, неточностей можно найти много. Для статьи «Мой взгляд на веб-технологии» это простительно, но заявляя о прогнозах нужно быть точным (и компетентным) в мелочах.
Уберите амбициозное предсказательство и станет нормальная обычная статья.
Также ни к чему там упоминание про ассемблер. Тем более (но я не специалист в этом области), по-моему компиляция происходит в объектный код или как-то так; и не «ассемблер», а «язык ассемблера». Думаю, неточностей можно найти много. Для статьи «Мой взгляд на веб-технологии» это простительно, но заявляя о прогнозах нужно быть точным (и компетентным) в мелочах.
Мде, самому недавно попалась интересная статья под заголовком «HTML 5 might not be ready until 2022. What's going on?» в журнале .NET. Прикольную и правдивую иллюстрацию смотрите здесь: sgolubev.livejournal.com/60130.html :-)
«А то, что красивая программа на C++ компилируется в уродский ассемблерный код, уже никого не волнует.»
Я думаю вам не надо объяснять насколько более уродский код по сравнению с версатльщиком вам сгенерирует ворд из ваших страничек?
Я думаю вам не надо объяснять насколько более уродский код по сравнению с версатльщиком вам сгенерирует ворд из ваших страничек?
Любой код, сгенерированный программно (машинный код, сгенерированный компилятором; xHTML/CSS/JS код сгенерированный Word'ом или ASP.Net) будет хуже, уродливее и медленнее, чем код написанный и вылизанный программистом вручную.
Другое дело, если работа ведется на языке более высокого уровня, то уродствр сгенерированного кода действительно никого не должно волновать.
Другое дело, если работа ведется на языке более высокого уровня, то уродствр сгенерированного кода действительно никого не должно волновать.
Любой код, сгенерированный программно (машинный код, сгенерированный компилятором; xHTML/CSS/JS код сгенерированный Word'ом или ASP.Net) будет хуже, уродливее и медленнее, чем код написанный и вылизанный программистом вручную.Это аксиома? Проверять не пробовали? Попробуйте на досуге написать что-нибудь, что обгонит, скажем ATLAS. Желательно — на процессоре, который ещё будет в продаже не только в атрикварном магазине когда вы закончите…
Это аксиома?Нет это не аксиома. Но в большинстве случаев, сгенерированный код действительно менее эффективен, чем написанный вручную.
Еще раз повторю: если бы это всегда было не так, то никто бы не писал ассемблерные программы для маломощных устройств.
Но, то что во многих случаях программы для устройств с малой производительностью пишут именно на ассемблере, а не на высокоуровневых языках, говорит о том, что накладные расходы при переходе на новый уровень абстракции приводят к уменьшению эффективности (несущественного для современных компьютеров, но критичного для маломощных устройств).
Хотя, я не отрицаю, что в некоторых случаях, сгенерированный код является более эффективным (особенно, если сравнивать с ручным кодом неопытного ассемблерного программиста). И вполне возможно, что в случае ATLAS это действительно так.
мне кажется заголовок статьи слегка переврали :) плюс, тем не менее
мне кажется заголовок статьи слегка переврали :)Почему? Действительно, если клиентские языки разработки (xHTML/CSS/JS) перестанут развиваться, то их могут ждать две трагические судьбы:
Ментальная гибель: останутся физически, но исчезнут из сознания разработчиков, накрывшись высокоуровневыми абстракциями, став низкоуровневыми языками — новым ассемблером;
Физическая гибель: исчезнут полностью, уступив место Silverlight или Flex.
Так что «Закат Веба» действительно может наступить…
не могу согласиться. Там где одни находят свой закат, других встричает рассвет. Вэб уже бессмертен, мы все его часть. ВЭБ имеет гораздо более глобальное значение и терминологию. Поэтому даже если хтмл отвалится, вэб будет развиваться дальше, причем с удвоенной скоростью.
Вэб уже бессмертенНу, здесь идет речь не о Вебе вообще, или даже всем всем Интернете, а о клиентских web-технологиях: xHTML/CSS/JS.
Во-первых, они могут исчезнуть объективно, уступив место Silverlight или Flex («физическая гибель»).
Во-вторых, они могут объективно остаться, но исчезнуть субъективно — из сознания web-разработчиков, накрывшись высокоуровневыми абстракциями. Также, как язык машинных кодов, никуда не деваясь объективно, субъективно исчез из сознания прикладных высокоуровневых программистов («ментальная гибель»).
Ну, и, конечно, Веб как таковой, а тем более весь Интернет фактически бессмертны. Ведь Интернет задумывался как сеть, способная пережить атомною войну :-)
От физической гибели технологий xHTML/CSS/JS уже давно спасают поисковики, т.е. их неумение полноценной семантической индексации содержимого сайта. В последнее время чувствуется движение и в этой области (FLASH/Flex, PDF уже начинают индексировать понемногу), поэтому именно сейчас, как никогда раньше, есть такая физическая опасность. Но HTML5 и др. как раз подоспевает с обновлением.
Еще одна палка в колесах xHTML/CSS/JS, по сравнению с FLASH/Flex и Silverlight, это последствия браузерных войн. По этой причине (эта причина не единственная конечно) и возникли многочисленные JS-фреймворки, поэтому многие и стали делать сайты почти полностью на FLASH/Flex. Но как уже сказано выше, страх перед тем, что сайт из-за некорректной индексации поисковиком, все-таки частично останавливал таких перебежчиков. Но надолго ли?
Еще одна палка в колесах xHTML/CSS/JS, по сравнению с FLASH/Flex и Silverlight, это последствия браузерных войн. По этой причине (эта причина не единственная конечно) и возникли многочисленные JS-фреймворки, поэтому многие и стали делать сайты почти полностью на FLASH/Flex. Но как уже сказано выше, страх перед тем, что сайт из-за некорректной индексации поисковиком, все-таки частично останавливал таких перебежчиков. Но надолго ли?
От физической гибели технологий xHTML/CSS/JS уже давно спасают поисковикиДа, действительно, неумение поисковиков индексировать Flash, PDF и т.д. сыграло xHTML на пользу.
Но, все же, хотелось, что бы разработчики использовали xHTML/CSS/JS не вынужденно, «из под палки» поисковика, а добровольно — осознав его возможности для построения богатых web-интерфейсов.
И появление HTML5 здесь очень кстати.
С идеей согласен. С идеей того, что чем дальше тем больше будут уходить от низкоуровневых механик, которые тормозят разработку (верстать под различные браузеры дело не особо интелектуальное и недляфанатов неинтересное :) ). Потом их будут учить для того чтоб люди понимали «как все устроено внутри» и «сколько преимущества дают современные технологии». С асемблером и паскалем у меня было именно так.
UFO just landed and posted this here
Ваше описание проблемы уродского кода сгенеренного автоматически я понял. Для решения этой проблемы есть два пути.
Путь первый — просветительская работа среди разработчиков использующих надстройки над языком с целью объяснить им идеи JS и как этот язык правильно использовать. Правильно используя язык весь код становится красивым.
Выход второй — совершенствование самих надстроек для генерации более качественного кода. В результате получим качественный код в приложениях (пусть даже и менее качественный чем идеальный код написаный вручную)
А вот дальше вы сосредоточились на первом пути. А ребята использующие .NET, насколько я понял, вместе со своим фреймворком пошли по второму пути и постепенно избавляются от страшненькой кодогенерации первых версий фреймворка. Не думаете же вы всерьез, что они были в восторге от ужасных значений id создаваемых раньше?
Вы идете к одной цели(красивому коду) разными путями. Вам нравиться JS и вы пишете красивый код на нем. Дотнетчикам нравится их фреймворк и они его используют, а создатели фреймворка постепенно приводят в чувства кодогенерацию. Вот собственно и все.
К слову, мне ближе позиция генерации кода и сейчас слежу вот за этим проектом: groups.google.com/group/ruby-red-js
Путь первый — просветительская работа среди разработчиков использующих надстройки над языком с целью объяснить им идеи JS и как этот язык правильно использовать. Правильно используя язык весь код становится красивым.
Выход второй — совершенствование самих надстроек для генерации более качественного кода. В результате получим качественный код в приложениях (пусть даже и менее качественный чем идеальный код написаный вручную)
А вот дальше вы сосредоточились на первом пути. А ребята использующие .NET, насколько я понял, вместе со своим фреймворком пошли по второму пути и постепенно избавляются от страшненькой кодогенерации первых версий фреймворка. Не думаете же вы всерьез, что они были в восторге от ужасных значений id создаваемых раньше?
Вы идете к одной цели(красивому коду) разными путями. Вам нравиться JS и вы пишете красивый код на нем. Дотнетчикам нравится их фреймворк и они его используют, а создатели фреймворка постепенно приводят в чувства кодогенерацию. Вот собственно и все.
К слову, мне ближе позиция генерации кода и сейчас слежу вот за этим проектом: groups.google.com/group/ruby-red-js
Хорошо описали. Все по полочкам разложено.
> К слову, мне ближе позиция генерации кода и сейчас слежу вот за этим проектом: groups.google.com/group/ruby-red-js
сразу бросается в глаза надпись, выделенная жирным шрифтом:
Объективно, во всем этом лежит желание создать такую абстракцию, которая была бы единой для всех и не надо было бы изучать всякие другие непонятные/сложные/нудные (каждый свое выберет) абстракции. Но и это не получится, поскольку будут появляться еще более абстрагированные сущности, которые будут автоматом генерировать уже и код на Руби (и где-то будет блестать надпись «You don't need to learn Ruby») и т.д. — до тех пор, пока нужда писать код вручную отпадет полностью. И естественно, как и любая усиленная абстракция (когда Вы не будете писать ни строчки JS, а JS код полностью будет сформирован посредством Ruby), этот подход будет иметь большие потери в ресурсах на «нынешнем железе».
> К слову, мне ближе позиция генерации кода и сейчас слежу вот за этим проектом: groups.google.com/group/ruby-red-js
сразу бросается в глаза надпись, выделенная жирным шрифтом:
You don't need to learn JavaScript.
Объективно, во всем этом лежит желание создать такую абстракцию, которая была бы единой для всех и не надо было бы изучать всякие другие непонятные/сложные/нудные (каждый свое выберет) абстракции. Но и это не получится, поскольку будут появляться еще более абстрагированные сущности, которые будут автоматом генерировать уже и код на Руби (и где-то будет блестать надпись «You don't need to learn Ruby») и т.д. — до тех пор, пока нужда писать код вручную отпадет полностью. И естественно, как и любая усиленная абстракция (когда Вы не будете писать ни строчки JS, а JS код полностью будет сформирован посредством Ruby), этот подход будет иметь большие потери в ресурсах на «нынешнем железе».
Те факты, собранные в этой статье, собственно, обсуждаются уже давно. Я столкнулся с явлением «автогенерации» html и js как ассемблерного кода в JSF и IceFaces (вроде ruby Rails в том же направлении работает?).
И получается так, что данные форматы\спецификации (html и js) являются asm'ом в Web'e на данное время. Но лично я об это сожалею и очень был бы рад за модификацию технологий(т.н. интенсивный прогресс а не экстенсивный). Т.к. подобное текущие использование автогенерации просто огорчает, хоть и позволяет абстрагироваться от многих неприятных мелочей. Да и, имхо, html слишком неповоротлив чтобы стать ассемблером для Web-приложений. А asm нельзя недооценивать, даже программируя на чем-то «предельно высокоуровневом» :)
И получается так, что данные форматы\спецификации (html и js) являются asm'ом в Web'e на данное время. Но лично я об это сожалею и очень был бы рад за модификацию технологий(т.н. интенсивный прогресс а не экстенсивный). Т.к. подобное текущие использование автогенерации просто огорчает, хоть и позволяет абстрагироваться от многих неприятных мелочей. Да и, имхо, html слишком неповоротлив чтобы стать ассемблером для Web-приложений. А asm нельзя недооценивать, даже программируя на чем-то «предельно высокоуровневом» :)
Мысли может и не плохие местами, но:
1) Плохо построенно повествование, автору пришлось 5 раз пояснять, что он хотел сказать
2) Явный недостаток знаний по предмету обсуждения, так, например, позабавило
«Для того, чтобы разработчики забыли и про JavaScript, Микрософт собирается выпустить Script# — компилятор, позволяющий писать клиентские скрипты на C#, а затем компилировать их в JavaScript.»
Уже упомянуле о куче разработок (которые вовсю используюся), где применяеся та же технология, так для Явы это ГВТ, эхо3 и т.д. и т.п.
ЗЫ После высказываний в адрес Prototype.js на последок автору захотелось дать ссылку, чтобы он уснуть не смог.
cappuccino.org/learn/demos/
Еще на последок:
почему-то XUL вспомнился, вспомнилось как все выглядит AS3 со своими стилями и XML'ем пока не компильнется и т.д…
1) Плохо построенно повествование, автору пришлось 5 раз пояснять, что он хотел сказать
2) Явный недостаток знаний по предмету обсуждения, так, например, позабавило
«Для того, чтобы разработчики забыли и про JavaScript, Микрософт собирается выпустить Script# — компилятор, позволяющий писать клиентские скрипты на C#, а затем компилировать их в JavaScript.»
Уже упомянуле о куче разработок (которые вовсю используюся), где применяеся та же технология, так для Явы это ГВТ, эхо3 и т.д. и т.п.
ЗЫ После высказываний в адрес Prototype.js на последок автору захотелось дать ссылку, чтобы он уснуть не смог.
cappuccino.org/learn/demos/
Еще на последок:
почему-то XUL вспомнился, вспомнилось как все выглядит AS3 со своими стилями и XML'ем пока не компильнется и т.д…
Несмотря на недостатки статьи, можно отметить явную проблему — web-приложения усложняются, а инструментария для их создания нет. Доходит до того, что мой любимый Eclipse начинает заметно тормозить на моих JavaScript файлах при редактировании, он реально не помогает при написании программ, и это ещё не беда.
Беда — что асинхронная модель выполнения JS и AJAX не очень хорошо поддерживается на уровне языка (вообще никак). Как писать логику программы, если неизвестно, какой ajax запрос выполнится первым, не блокировать же интерфейс на время выполнения длинных запросов.
И постепенно появляется желание писать на Java — тем более что последняя реализация открыла доступ к DOM. Может быть в этом и будет решение большинства проблем? Хотя зачем DOM и HTML для сайта на яве…
Вообще стоит разделять сайты корпоративные и для web-пользователей. Проблемы и решения настолько разные, что правильней говорить о двух разных вебах.
Лет десять назад мне казалось, что Микрософт протащит RTF как стандарт для Web.
Беда — что асинхронная модель выполнения JS и AJAX не очень хорошо поддерживается на уровне языка (вообще никак). Как писать логику программы, если неизвестно, какой ajax запрос выполнится первым, не блокировать же интерфейс на время выполнения длинных запросов.
И постепенно появляется желание писать на Java — тем более что последняя реализация открыла доступ к DOM. Может быть в этом и будет решение большинства проблем? Хотя зачем DOM и HTML для сайта на яве…
Вообще стоит разделять сайты корпоративные и для web-пользователей. Проблемы и решения настолько разные, что правильней говорить о двух разных вебах.
Лет десять назад мне казалось, что Микрософт протащит RTF как стандарт для Web.
>В ASP.NET работа идет с высокоуровневым Windows API
Бред
>пусть нетривиальные вещи на ASP.NET сделать невозможно
Какие такие «нетривиальные вещи»?
Бред
>пусть нетривиальные вещи на ASP.NET сделать невозможно
Какие такие «нетривиальные вещи»?
Еще раз повторю: речь идет не о Win16/Win32/Win64 API. Речь идет о том, что web-разработчики ASP.NET используют тот же самый API (базовые классы .Net Framework), что и Windows-разработчики .Net.
Здесь говорится о следующем:
Джоэл Спольски, кстати, бывший сотрудник и большой апологет Микрософт, еще в 2004 году заметил: вся сила, богатство и власть Микрософта — в его Windows API.
Windows API заставляет писать под Windows большинство разработчиков → наличие подавляющего количества программ именно под Windows заставляет большинство пользователей покупать Windows → наличие Windows у большинства пользователей заставляет разработчиков использовать Windows API. Такой вот замкнутый круг, положительная обратная связь в деле завоевания мира Микрософтом.
Поскольку web-приложениям не требуется Windows API, Веб — самая смертельная угроза для Микрософт.
Именно поэтому, Микрософт сделала все, чтобы приблизить web-разработку под ASP.NET к классической десктопной разработке:
— Во-первых, путем использования в ASP.NET того же API, что и для разработки десктопных программ (не WinAPI, конечно, что мне приписывают; а базовые классы .Net Framework)
— Во-вторых, путем замены парадигмы web на десктопную Windows-парадигму с помощью серверных контролов.
Ситуация стала меняться к лучшему:
— Во первых, после того, как .Net перестала быть в какой-то степени чисто windows-платформой после появления Mono. Поначалу Микрософт хотела судебным образом задушить этот проект, но, не достигнув желаемого, отказалась от этой идеи и даже стала помогать проекту.
— Во-вторых, после выхода ASP.NET MVC Framework, которая не требует использования серверных контролов.
Здесь говорится о следующем:
Джоэл Спольски, кстати, бывший сотрудник и большой апологет Микрософт, еще в 2004 году заметил: вся сила, богатство и власть Микрософта — в его Windows API.
Windows API заставляет писать под Windows большинство разработчиков → наличие подавляющего количества программ именно под Windows заставляет большинство пользователей покупать Windows → наличие Windows у большинства пользователей заставляет разработчиков использовать Windows API. Такой вот замкнутый круг, положительная обратная связь в деле завоевания мира Микрософтом.
Поскольку web-приложениям не требуется Windows API, Веб — самая смертельная угроза для Микрософт.
Именно поэтому, Микрософт сделала все, чтобы приблизить web-разработку под ASP.NET к классической десктопной разработке:
— Во-первых, путем использования в ASP.NET того же API, что и для разработки десктопных программ (не WinAPI, конечно, что мне приписывают; а базовые классы .Net Framework)
— Во-вторых, путем замены парадигмы web на десктопную Windows-парадигму с помощью серверных контролов.
Ситуация стала меняться к лучшему:
— Во первых, после того, как .Net перестала быть в какой-то степени чисто windows-платформой после появления Mono. Поначалу Микрософт хотела судебным образом задушить этот проект, но, не достигнув желаемого, отказалась от этой идеи и даже стала помогать проекту.
— Во-вторых, после выхода ASP.NET MVC Framework, которая не требует использования серверных контролов.
>после появления Mono. Поначалу Микрософт хотела судебным образом задушить этот проект, но, не достигнув желаемого, отказалась от этой идеи
А можно первоисточник? Первый раз слышу.
>Поскольку web-приложениям не требуется Windows API, Веб — самая смертельная угроза для Микрософт.
То-то опенсорсники так лаются на Saas
А можно первоисточник? Первый раз слышу.
>Поскольку web-приложениям не требуется Windows API, Веб — самая смертельная угроза для Микрософт.
То-то опенсорсники так лаются на Saas
Сижу, гадаю, чего же ждать? Что я буду в блокноте писать 3D дизайн для сайта, или что буду запускать флэшплеер для серфинга по инету?))
Что-то очень много в статье бреда. Начиная с якобы «уродского ассемблерного кода, сгенерированного компилятором» (современные компиляторы намного эффективнее программиста оптимизируют код) и заканчивая WinAPI в ASP.NET (ха, ха, и еще раз ха, вы даже .NET в названии ASP.NET не видите). Что касается конкуренции с Flash/Flex и Silverlight это скорее преувеличение. Есть SVG, есть ExtJS. И много ли вы видели реально функциональных и удобных сайтов, целиком на упомянутых RIA-технологиях?
И что? Америку открыли? Это и есть разделение логики от представления, о котором вы чуть выше же и писали.
Про JavaScript согласен. Только недавно разработчики браузеров стали наконец чесаться и ускорять тормозные реализации JS.
Такой подход возникает, если относиться к xHTML как к языку визуальной разметки. Секрет же в том, что xHTML является языком не визуальной, а логической разметки[…]
И что? Америку открыли? Это и есть разделение логики от представления, о котором вы чуть выше же и писали.
Про JavaScript согласен. Только недавно разработчики браузеров стали наконец чесаться и ускорять тормозные реализации JS.
якобы «уродского ассемблерного кода, сгенерированного компилятором» (современные компиляторы намного эффективнее программиста оптимизируют код)Даже современные компиляторы далеко не всегда генерируют более эффективный код, по сравнению с кодом, написанным вручную. Иначе, сейчас просто не было бы нужды писать ассемблерные программы для маломощных устройств.
Но, то что во многих случаях программы для устройств с малой производительностью пишут именно на ассемблере, а не на высокоуровневых языках, говорит о том, что накладные расходы при переходе на новый уровень абстракции приводят к уменьшению эффективности (несущественного для современных компьютеров, но критичного для маломощных устройств).
и заканчивая WinAPI в ASP.NETЕще раз повторю: речь идет не о Win16/Win32/Win64 API. Речь идет о том, что web-разработчики ASP.NET используют тот же самый API (базовые классы .Net Framework), что и Windows-разработчики .Net. Но, согласен, сформулировано некорректно.
Что касается конкуренции с Flash/Flex и Silverlight это скорее преувеличение.В xHTML сейчас действительно присутствуют ряд существенных мультимедийных ограничений при реализации web-технологий основными браузерами.
Поэтому, если xHTML/CSS/JS не будут развиваться, как технологии создания web-приложений, они действительно могут уступить место Flex или Silverlight.
Однако, я уверен, под руководством WHATWG, развитие xHTML/CSS/JS как технологий создания web-приложений будет продолжено, ит HTML5 — хороший тому пример.
Как всегда очень интересная и полная статья
спасибо
спасибо
Зря на асп.нет гонишь, ничего тут не исчезло есть и хтмл и яваскрипт и цсс, ты взял парочку контролов, и показал их)))))) на самом деле, дорогие веб-проекты, почти не юзают эти контролы, а пишут свои, руцями на базе хтмл, яваскрипта и цсс)))))))))
так что зря ты так
А по поводу S#, я такого даже не слышал, но спасибо просветил
Кстати, в дот нет, уже включена джей квери, ну это в защиту яваскрипта
А по поводу исчезновения веб в виде, яваскрипта и цсс, и хтмл, ты прав
Всякие рич приложения, аля флеш и сильвер лайт, убьют хтмл, потому что это действительно круче! нет проблем с эти браузерами и разметками и тд. Единственная трабла, пока в ходе таких событий это узкие каналы и слабые сервера.
Когда технически будет возможно во всю юзать эти технологии, то их и будут юзать!))))))))
И не ругай больше асп.нет, на асп.нете можно достичь любой гипкости, только в отличии от всякой опен сорсовой лабуды, просто быстрее)))))))) улыбайся и учи си шарп и акшен скрипт)))))))
так что зря ты так
А по поводу S#, я такого даже не слышал, но спасибо просветил
Кстати, в дот нет, уже включена джей квери, ну это в защиту яваскрипта
А по поводу исчезновения веб в виде, яваскрипта и цсс, и хтмл, ты прав
Всякие рич приложения, аля флеш и сильвер лайт, убьют хтмл, потому что это действительно круче! нет проблем с эти браузерами и разметками и тд. Единственная трабла, пока в ходе таких событий это узкие каналы и слабые сервера.
Когда технически будет возможно во всю юзать эти технологии, то их и будут юзать!))))))))
И не ругай больше асп.нет, на асп.нете можно достичь любой гипкости, только в отличии от всякой опен сорсовой лабуды, просто быстрее)))))))) улыбайся и учи си шарп и акшен скрипт)))))))
У Джо Спольски есть близкие идеи</>. Правда вывод совсем другой
Вопрос: а кто виноват? Мы, веб разработчики сами и виноваты. Уже давно пора делать сайты по стандартам хтмл, а не эксплорера.
Уже давно пора занимать рынок автоматизации, а не рекламы.
Уже дошло до того, что рынок автоматизации веб технлогиями стали занимать дектопные девелоперы, с их жалким вин формс.
Мы используем js для каких-то визуальных фишек, вместо управления контентом, до аякс я считал, что js вообще не нужен.
Неверно это. Мы можем писать клиент-серверные приложения, при этом избавлены от потребности устанавливать клиент, обновлять его и пр. Этим нужно пользоваться.
Уже давно пора занимать рынок автоматизации, а не рекламы.
Уже дошло до того, что рынок автоматизации веб технлогиями стали занимать дектопные девелоперы, с их жалким вин формс.
Мы используем js для каких-то визуальных фишек, вместо управления контентом, до аякс я считал, что js вообще не нужен.
Неверно это. Мы можем писать клиент-серверные приложения, при этом избавлены от потребности устанавливать клиент, обновлять его и пр. Этим нужно пользоваться.
Отличная статья. Я тоже так думаю)) Это (то, что будет достигнуто), имхо, и есть web2.0
В идеале, имхо, html должен умереть в пользу xml, то есть данные окончательно отойдут от представления, но это уже ближе к web3.0
В идеале, имхо, html должен умереть в пользу xml, то есть данные окончательно отойдут от представления, но это уже ближе к web3.0
Шел 2015-й год… веб все еще не закатился.
Sign up to leave a comment.
Закат Веба?