Закат Веба?

    7 марта прошлого года W3C, после 10-летнего перерыва, возобновила работу над HTML.

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

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

    Я решил выложить их в виде статьи, переработав и снабдив иллюстрациями и примечаниями.


    Содержание:

    1. Вступление
    2. Сценарии гибели
      • Гибель ментальная, или HTML — новый ассемблер
      • Гибель физическая, или HTML — новый Turbo Pascal
    3. Все ли так серьезно?
      • Ментальной гибели не будет, если web-технологии будут правильно поняты
      • Физической гибели не будет, если web-технологии будут развиваться
    4. Заключение
    5. Примечания


    В настоящий момент мир вступает в эпоху расцвета богатых web-приложений.

    Программы, работающие через Веб, все больше вытесняют традиционные десктопные приложения. Gmail, Google Map, online-офис, даже web-операционные системы… Список можете продолжить сами.

    Однако, по мере продвижения web-приложений, все больше возрастают требования к основным клиентским web-технологиям: xHTML, CSS, JavaScript.

    И, если эти технологии не будут поспевать за все более возрастающими требованиями, это приведет к их медленному закату…
     

    Сценарии гибели:



    Гибель ментальная,

    или HTML – новый ассемблер

    АссемблерНа заре IT все программы писались на ассемблере.

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

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

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

    Поэтому, на смену ассемблеру пришли языки высокого уровня. Ассемблер при этом физически никуда не делся — все программы на высокоуровневых языках компилируются во все тот же ассемблерный код [1]. В уродский неэффективный ассемблерный код.

    C++ Тем не менее, ассемблер исчез [2]. Исчез из сознания программистов. Они стали писать на высокоуровневых языках, уже на этих языках вылизывать код программы и доводить его до совершенства. А то, что красивая программа на C++ компилируется в уродский ассемблерный код, уже никого не волнует.

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

    Таким образом, никуда не деваясь физически, ассемблер исчез из IT индустрии.

     

    Подобная судьба может ждать и xHTML/CSS/JS.

    HTML За все время существования Веба, основной web-технологией был xHTML.

    Web-разработчики довели эту технологию до совершенства: научились отделять представление от содержания посредством CSS, применять бестабличную и семантическую верстку, использовать микроформаты…

    Но, в xHTML нет столь нужных для современных web-приложений тегов, таких как вкладки, меню, деревья, календари и т.д.

    Чем удачно воспользовалась корпорация Микрософт. У Микрософта давний зуб на web-технологии, ведь будучи открытыми стандартами, они (в отличие от Windows API) не подчиняются микрософтовской власти. С этим надо было что-то делать, и раз Микрософт не могла уничтожить xHTML физически, надо было, чтобы он исчез хотя бы в сознании разработчиков.

    ASP.net Так появилась web-интерфейсная модель ASP.NET. В ASP.NET работа идет с высокоуровневым серверными контролами (меню, вкладками, деревьями), которые затем «компилируется» в HTML, CSS и JavaScript, так же как программа на C++ компилируется в ассемблер.

    xHTML/CSS/JS исчезает из сознания web-разработчиков; более того, они в какой-то мере перестают быть web-разработчиками, возвращаясь в привычную Windows forms / Delphi / Visual Basic парадигму, к старым добрым Windows API.

    В ASP.NET обесценивается то, что мы так долго учили: умение писать понятный xHTML код, бестабличная и семантическая верстка и т.д. Обесценивается даже одна из основ Веба — CSS, ведь оформление сайта можно задавать при помощи ASP.NET тем (themes), идеология которых сильно отличается от каскадной модели CSS.

    Script# Для того, чтобы разработчики забыли и про JavaScript, Микрософт собирается выпустить Script# — компилятор, позволяющий писать клиентские скрипты на C#, а затем компилировать их в JavaScript.

    Многие разработчики не любят ASP.NET [3]. Он заточен под быстрое и удобное решения типовых задач. Но сделать что-то нетривиальное гораздо красивее на чистом HTML, CSS и JavaScript.

    Однако нетривиальные задачи встречаются, может быть только в 1% случаев, а оставшиеся 99% типовых задач быстрее решить на ASP.NET. Быть может, это не так красиво, но бизнес требует скорости разработки…

    Delphi for PHP Другим web-технологиям уже сложно конкурировать с ASP.NET. Недавно появился продукт Delphi for PHP, с помощью которого PHP разработчики начинают думать в рамках Windows парадигмы Delphi [4].

    Если дело пойдет дальше, web-технологии ждет судьба нового ассемблера. HTML/CSS/JS физически по-прежнему оставаясь основными web-технологиями, могут стать низкоуровневыми языками и исчезнуть из сознания разработчиков.
     

    Гибель физическая,

    или HTML — новый Turbo Pascal

    Вы наверно помните среду разработки Turbo Pascal. Это была консольная программа с текстовым псевдографическим интерфейсом. Все, что было у разработчиков оболочки Turbo Pascal — это матрица из 80 * 25 символов ASCII, их цвет и фон. Все!

    Turbo PascalИ из этих текстовых символов они сделали невозможное: реализовали многооконный интерфейс, с главным и контекстным меню, псевдо-трехмерными нажимающимися кнопками, технологией перетаскивания окон… В общем, почти все, что сейчас есть в современной графической Windows'овской программе.

    Однако, перепрыгнуть ограничения таблицы из 80*24 символов было невозможно. Как ни старайся, нельзя нарисовать объект тоньше одного символа или провести диагональную, а тем более изогнутую линию. Интерфейсы наподобие Turbo Pascal ушли в историю, уступив место графическим интерфейсам Windows…

     

    И опять, история может повториться. Призрак Turbo Pascal'я витает над xHTML…

    Основа Веба — язык HTML не предназначался даже для создания сайтов (в современном их понимании), а тем более web-приложений. Тим Бернерс-Ли создал его для простой разметки научных документов, наподобие Word.

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

    Однако у web-технололгий есть ограничения, которые, как ни старайся, перепрыгнуть не удастся. Средствами чистого xHTML/CSS/JS нельзя создать 3D графику, векторную анимацию, управлять звуком, хранить большие объемы данных на стороне клиента…

    SilverlightСмена не заставит себя долго ждать. В качестве основы «богатых интернет приложений» компания Macromedia (сейчас Adobe) уже много лет продвигает Flash/Flex. Микрософт относительно недавно, но с удвоенным рвением продвигает WPF/Silverlight [5].

    И если xHTML не изменится, он может повторить судьбу псевдографического интерфейса Turbo Pascal, навсегда исчезнув из IT-индустрии.
     

    Все ли так серьезно?


    Итак, клиентские web-технологии могут ждать две трагические судьбы:
    • Ментальная гибель: останутся физически, но исчезнут из сознания разработчиков, накрывшись высокоуровневыми абстракциями, вроде ASP.NET, став низкоуровневыми языками — новым ассемблером;
    • Физическая гибель: исчезнут полностью, уступив место Silverlight или Flex.


    Ментальной гибели не будет,

    если web-технологии будут правильно поняты

    В отличие от ассемблера, который объективно был низкоуровневым языком, xHTML/CSS/JS лишь воспринимаются как низкоуровневые из-за неправильного их понимания разработчиками. Попробую показать, почему.

    Еще раз повторю:

    Причина, по которой столь популярны серверные ASP.NET контролы (вкладки, деревья, меню, календари и т.д.), состоит в том, что в самом xHTML нет тегов для этих высокоуровневых интерфейсных элементов.

    И поэтому, разработчикам приходится вручную описывать эти вкладки, меню и деревья с помощью мешанины низкоуровневых xHTML тегов: таблиц со сложными объединенными ячейками, внутри которых вложенные таблицы с большим количеством тегов <font> и декоративных картинок для обрисовки веток. Примерно также, как много лет тому назад ассемблерные программисты описывали операцию деления с помощью мешанины низкоуровневых команд сложения и сдвига регистра.

    ASP.net контролы в Visual StudioВсе «прелести» низкоуровневого xHTML программирования налицо. Поэтому, гораздо проще выбросить из головы низкоуровневый xHTML код и работать с высокоуровневым ASP.NET контролом, который затем автоматически «скомпилируется» в xHTML, также как программа на C++ скомпилируется в ассемблер. Пусть получившийся xHTML негибок и уродлив [6], пусть нетривиальные вещи на ASP.NET сделать невозможно, но зато в оставшиеся 99% тривиальных задач решаются быстро и привычно.

    Так вот:

    Такой подход возникает, если относиться к xHTML как к языку визуальной разметки. Секрет же в том, что xHTML является языком не визуальной, а логической разметки, т.е. описывает не то, как должен выглядеть документ, а то, какие данные он содержит. И поэтому, он и не должен содержать теги, описывающие конкретные визуальные интерфейсные элементы. Вместо внешнего вида, xHTML описывает данные, которые содержит тот или иной интерфейсный элемент. А уже с помощью CSS соответствующий элемент «разукрашивается», так, чтобы выглядел как меню, вкладка или дерево; а JS придает ему требуемую функциональность.

    Пример 1:

    При высокоуровневом подходе:

    Дерево — это не мешанина таблиц, вложенных таблиц, тегов <font> и картинок.

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

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

    JavaScript придает списку функциональность дерева — открытие/закрытие узлов, выделение, перетаскивание и т.д.

    Пример 2:

    Меню, также, также как и дерево — это иерархическая структура. И оно, также, создается с помощью многоуровневого списка.

    Просто потом, к этому списку применяется уже другой CSS и JS, придающий списку внешний вид и функциональность именно меню.

    Пример 3:

    Вкладки, по сути своей — это несколько разделов документа со своим заголовком. Поэтому, в xHTML, вкладки прекрасно описываются как несколько блоков <div>, каждый со своим заголовком <h2>.

    А уже потом, JavaScript придает этим блокам функциональность вкладок, скрывая или показывая блоки в зависимости от действий пользователя.


    Соответствующий CSS и JS код легко вынести во внешний компонент, позволяя тем самым программисту не думать об оформлении и работать только с данными интерфейсного элемента, сосредоточенными в xHTML коде.

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

    Более того, xHTML является даже более гибким и высокоуровневым языком построения интерфейса, чем многие другие. Ведь именно потому, что xHTML хранит лишь данные, а не внешний вид и функциональность интерфейсного элемента, делает интерфейсы гораздо более универсальным. Т.е., в одной ситуации, один и тот же элемент ведет себя как дерево, в другой — как меню, в третьей — как обычный список. При этом, xHTML код интерфейса остается неизменным. Мы даже можем превратить дерево в контекстное меню, а контекстное меню в список прямо на лету, без перезагрузки страницы! В каком еще языке разметки интерфейса так можно?!

    Но такой «высокоуровневый» подход сильно отличается от традиционного оконного Windows-подхода, и поэтому, непривычен и непонятен многим разработчикам. ASP.NET не является в полной мере более высокоуровневой, чем xHTML. Она скорее, больше пытается применить к Веб Windows-парадигму, чем перейти на более высокий уровень абстракции. А web-парадигма не всегда хорошо соотносится с парадигмой Windows, например, модель тем (themes) оформления в ASP.NET плохо соотносится с каскадной моделью CSS.

     

    JSON Еще одна непривычная и малопонятная для многих разработчиков web-технология — это JavaScript (который даже прозвали СНЯП — Самый Недооцененный Язык Программирования в мире).

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

    Однако, многие особенности JavaScript, придающие ему такую мощь и гибкость: ООП на основе прототипов, объекты-как-хеши, функциональное программирование, замыкания и т.д. оказались недопоняты разработчиками, привыкшими к классическим языкам, вроде C++, Java, Delphi или VB. Из-за этого, JavaScript стал восприниматься как детский, «игрушечный» недоязык для скрипткидди.

    Не язык это, а скрипт. Даже классов нормальных в нем нету…

    — не помню, откуда

    Prototype.jsХуже всего, часть разработчиков даже не желают понять JavaScript, а пользуются уродскими библиотеками, вроде Prototype.js, или недавно вышедшей Microsoft Ajax Library (бывшая Atlas), в которых эмулируется классическое классовое ООП, что является страшным надругательством над JavaScript, лишающим его такой красоты и гибкости.

    Prototype.js был написан теми, кто не знает JavaScript, для тех, кто не знает JavaScript

    — Richard Cornford


     

    Итак, первая причина потенциальной «гибели» xHTML/CSS/JS — превращения их в новый ассемблер, состоит в недопонятости этих технологий. Но, я надеюсь, в скором времени, большинство разработчиков лучше поймут философию web-технологий и научатся обходиться без псевдо-высокоуровневых костылей.
     

    Физической гибели не будет,

    если web-технологии будут развиваться

    С «физической гибелью» все серьезнее.

    В web-технологиях сейчас действительно отсутствует ряд возможностей, необходимых для создания полноценных web-приложений: работа с 2D и 3D графикой, векторной анимацией, управление звуком, хранение большие объемы данных на стороне клиента…

    И поэтому, угроза со стороны Flash/Silverlight сильна как никогда.

    Для того, чтобы не исчезнуть из IT-индустрии и не повторить судьбу Turbo Pascal, эти технологии должны развиваться и преодолевать собственные ограничения.

    Надо заметить, что xHTML, CSS и JavaScript никогда не переставали развиваться.

    W3C Однако, под руководством W3C, они развивались как средства представления информации, а не как технологии создания web-приложений.

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

    Была проделана огромная работа по созданию технологий Semantic Web: RDF, OWL и SPARQL. Semantic Web позволит сделать информацию в Вебе понятной не только человеку, но и компьютеру. Это, например, даст возможность строить SPARQL-запросы «ко всему интернету», вроде такого: «Сколько щенков у собаки 2-го президента России?»

    Но, скажем, web-формы так и остались на уровне 1995 года [7].

    И, похоже, на W3C надежды было мало.

    WHATWGК счастью, нашлись те, кто осознал проблему. Ими стали фирмы-разработчики трех основных «нормальных» браузеров: Mozilla Foundation, Opera Software и Apple, которые организовали рабочую группу WHATWG, предназначенную для развития web-технологий, как технологий создания web-приложений.

    И вот, 7 марта произошло, историческое событие: WHATWG официально вошла в состав W3C. В настоящий момент ведется работа над спецификацией HTML5 (или Web Applications 1.0) [8], которая:
    • во-первых, является развитием HTML4/xHTML1.1 и включает многие теги, столь необходимые для web-приложений: <canvas> — тег для рисования графики, <video> — для видеоконтента, высокоуровневые элементы формы и т.д.
    • во-вторых, является развитием DOM и включает API для: хранения данных на стороне клиента и работы offline, управления кнопками вперед/назад, управления Drag&Drop и многое-многое другое!

    Так что HTML5 — это не еще одна ненужная версия HTML, а жизненно необходимое направление развития web-технологий.
     

    Заключение


    Таким образом, xHTML/CSS/JS выживут, если:
    • Будут развиваться как технология построения web-приложений;
    • И, главное, будут правильно поняты web-разработчиками.

    Примечания

    1.   Обычно программы компилируются не в ассемблерный код, а сразу в машинный. Но, для удобства, в пределах этой статьи будем считать, что это одно и то же.
    2.   В системном программировании ассемблер, разумеется, используется. Однако, оно не является определяющим в IT-индустрии.
    3.   Конечно, ASP.NET не ограничивается одними серверными контролами. ASP.NET — очень могучая, производительная, надежная технология, использующая всю мощь .NET Framework. Однако, многие разработчики используют ASP.NET именно из-за серверных контролов.
    4.   Насчет «Delphi for PHP», я, похоже, ошибся. Прошел уже почти год, а о «Delphi for PHP» мало что слышно.
    5.   А вот насчет Silverlight, я оказался прав. Он получает все большее и большее распространение.
    6.   Надо признать, Микрософт очень старается. От версии к версии, генерируемый ASP.NET'ом xHTML код становится все менее уродливым, более валидным и семантичным.
    7.   Предложенная W3C технология xForms не обладает обратной совместимостью и практически не поддерживается браузерами. Даже Mozilla Firefox, в котором реализованы почти все современные стандарты, поддерживает xForms только с помощью специального плагина.
    8.   Помимо технологии создания web-приложений, стандарт (x)HTML5 призван:
      • обеспечить обратную совместимость с HTML4/xHTML1;
      • определить единый для всех браузеров механизм обработки ошибок;
      • и не забыть о первоначальном предназначении языка HTML — средства представления информации. В HTML5 вводятся новые элементы для более семантической разметки документа: <section>, <article>, <header>, <footer> и др.

    При подготовке статьи были использованы изображения с сайта www.wikimedia.org, а также: www.codegear.com, www.microsoft.com, www.w3c.org, www.json.org, www.whatwg.org, www.gmail.com, www.dotnetheaven.com, idesisnery.blogspot.com

    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 282

      +8
      Вам явно было не лень набирать теги…
        +23
        Статья длинная, поэтому я постарался сделать все, чтобы ее было удобнее и приятнее читать.
        • НЛО прилетело и опубликовало эту надпись здесь
        +7
        Очень интерестно, спасибо!
          –2
          а посля прочтения «Гибель ментальная» мне как-то жутко стало… не ужели все так плохо? :-\
            –1
            Дочитайте до конца :-)

            Нет, все не так плохо.

            В отличие от ассемблера, который объективно был низкоуровневым языком, xHTML/CSS/JS лишь воспринимаются как низкоуровневые из-за неправильного их понимания разработчиками.
            +5
            В уродский неэффективный ассемблерный код.
            Похоже о ассемблере вы знаете только название. Печально.

            Таким образом, никуда не деваясь физически, ассемблер исчез из IT индустрии.
            Абсолютное заблуждение.
              +1
              В уродский неэффективный ассемблерный код.
              Вы не согласны с тем, что ассемблерный (а точнее, машинный) код, полученный в рещультате компиляции высокоуровневой программы является уродским? Во всяком случае по сравнению с ассемблерным кодом написанном вручную.

              Таким образом, никуда не деваясь физически, ассемблер исчез из IT индустрии.
              См. сноску. Речь идет о прикладной IT-индустрии, а не о системном программировании. Тестовый редактор сейчас на ассемблере никто не пишет.
                +5
                Смотря что понимаьб под «уродский». А вот на счёт эффективности я не согласен — современные компиляторы достаточно «умны» чтобы сгенерировать относительно быстрый код.

                Сорри, сноску действительно не прочтитал. Но такое надо писать не в сносках, а в скобках, прямо в тексте.
                  –1
                  А вот на счёт эффективности я не согласен — современные компиляторы достаточно «умны» чтобы сгенерировать относительно быстрый код.

                  Ключевое слово здесь — относительно.

                  Действительно, при мощностях современного железа, уменьшение эффективности сгенерированного кода относительно не заметно. Но это не значит, что ухудшения нет!

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

                    это необратимый процесс усиления абстракций, относительно старых ресурсов; сами ресурсы также развиваются параллельно с усилением абстракций.

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

                    Еще одно правило — всегда есть профессионалы в текущих абстракциях (часто именно они являются создателями последующих (усиленных) абстракций); и они всегда будут видеть недочеты в новых абстракциях — где-то сетовать, где устранять, где-то — помогать советами. Потом появятся профи в новых абстракциях и будут видеть недочеты в следующих.
                      –1
                      Так никто и не спорит с тем, что переход на новый уровень абстракции — хорошо. И что при постоянном увеличении мощности железа, это происходит безболезненно.

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

                        а кто это говорил? я не видел; в любом случае — это глупость, переход на новый уровень (на то он и прогресс, а не регресс) будет нести дополнительные расходы, но благодаря параллельному развитию того, для чего (или кого) эта абстракция писалась (в данном случае — язык для машины) получается прогресс (иначе был бы регресс — потребление ресурсов увеличивается и все тормозит, т.к. то, для чего была создана новая абстракция не развивается)
                          0
                          > Я просто не согласен с той фразой, что переход на новый уровень происходит совсем без увеличения накладных расходов.

                          а кто это говорил? я не видел; в любом случае — это глупость ...

                          Я спорю с superhabra, который утверждает, что программы на высокоуровневых языках всегда более эффективны, чем низкоуровневые ассемблерные:
                          >[программа на высокоуровневом языке компилируется] в неэффективный ассемблерный [или машинный] код.
                          Похоже о ассемблере вы знаете только название

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

                          Если бы это всегда было не так, то никто бы не писал ассемблерные программы для маломощных устройств.

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

                            Мой вам совет, завязывайте с тяжелыми наркотиками.

                            Я думаю что вы в курсе, что есть такой метод ведения спора, как «подмена понятий».
                            Так вот, воспользовавшись им вы подтвердили свою некомпетентность в это сфере, и дальнейшее продолжение дискуссии считаю бессмысленным.
                              0
                              Я написал:
                              [программа на высокоуровневом языке компилируется] в неэффективный ассемблерный [или машинный] код.
                              Т.е. я хотел показать, что в большинстве случаев (хоть и не всегда), программа, написанная на высокоуровневом языке менее эффективна, чем низкоуровневая; т.к. накладные расходы перехода на новый уровень абстракции снижают эффективность.

                              На что Вы ответили:
                              Похоже о ассемблере вы знаете только название.
                              Возможно, если бы Вы ответили нормально, а не применили демагогический прием «Ad hominem», то Ваша истинная мысль стала бы ясна.

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

                              Я стал доказывать обратное: приводить пример с накладными расходами и микроволновками.

                              На что dsCode вполне резонно заметил: зачем я доказываю очевидные вещи…

                              Но, если Вы обещаете больше не продолжать дискуссию — я не буду настаивать…
                                0
                                Я спорю с superhabra, который утверждает, что программы на высокоуровневых языках всегда более эффективны, чем низкоуровневые ассемблерные

                                Вот оно, ключевое слово. Я думаю что вы согласитесь что при написании ассемблернго кода эффективность больше зависит от профессионализма программиста, чем в случае высокоуровнего ЯП. А рассматривать «идеального программиста в вакууме» не имеет смысла.
                                  0
                                  Ну, да, в общем.

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

                                  Все сходится :-)

                                  Точнее всего, думаю, сформулировал dsCode в этом комментарии.
                                0
                                Ладно, ничего страшного :-) Просто не надо вместо возражений по существу, использовать «Ad hominem» типа: «ты ничего не знаешь о предмете, кроме названия» — тогда и не будет недоразумений…
                                  +1
                                  Ок, сорри что разговор перешел в такое русло :)
                                +2
                                > Если бы это всегда было не так, то никто бы не писал ассемблерные программы для маломощных устройств.

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


                                Друзья, и то, и то — верно.

                                Кстати, ассемблерные вставки могут использовать (помимо убыстрения) также и для более низкоуровневых операция, если таковые недоступны из «обёрточных» функций языка (например, модуль асма для программирования на Питоне — habrahabr.ru/blogs/python/45726/)

                                Можно так же задавать вопросы — почему, например, JavaScript / Python / Ruby и т.д. написаны не на ассемблере? А что? — было бы быстрее в разы. Это вот как раз то, когда абстракция усилилась (появился Си), когда появились автоматизации сканеров и парсеров (типа Flex'a и Bison'a) — стало удобней и быстрей создавать новые языки. При этом, вероятно, создателей языков все же волновал вопрос, что их новый язык будет медленней даже Си (раз в 200), не то, что ассемблера. Но и так же, они, вероятно, осознавали, что если начнут сейчас писать JavaScript на асме, то потеряют много своих человеческих ресурсов (и может, и когда закончат — этот новый язык уже устареет и мало кому будет нужным).

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

                                Что же касается меня лично — рассуждая о теме абстракций в языках программирования, я при этом являюсь большим почитателем ассемблера (хоть моя работа и не связана напрямую с ним). Так же я фанат демо-сцен, когда на чистом асме (ну а сейчас уже на Си), общаясь с железом напрямую в реальном времени, пишут замечательные красивые демки размером всего 64Кб (а иногда и интро в 4Кб). Кто не в курсе — посмотрите, например, демо немецкой команды Farb-Rausch. Это, конечно, искусство!
                                  0
                                  Можно так же задавать вопросы — почему, например, JavaScript / Python / Ruby и т.д. написаны не на ассемблере? А что? — было бы быстрее в разы.
                                  Не были бы. Сам по себе ассемблер — не гарантия скорости. Большая и сложная программа на нём будет менее эффективна — просто внимания не хватит оптимально всё писать. Посмотрите рассказы про современные JavaScript-машины и подумайте — сколько лет вы бы отлаживали подобную систему на ассеблере и какой реальный выигрыш вы бы получили.
                                    0
                                    > Не были бы.

                                    Были бы. Именно по скорости выполнения — были бы.

                                    > Сам по себе ассемблер — не гарантия скорости.

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

                                    > Большая и сложная программа на нём будет менее эффективна — просто внимания не хватит оптимально всё писать.

                                    Ну так я именно об этом и говорю (внимательней прочитайте пост выше).

                                    > и подумайте

                                    :) я «оценил».

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

                                    туда же относится — я именно об этом и говорил постом выше (еще прочитайте внимательно).

                                    В очередной раз повторяю — основная идея усиления абстракций — убыстрить разработку, жертвуя ресурсами (но с верой и знанием, что то, для чего разрабатывается абстракция — тоже развивается). Вы же, «цитируя» меня же из поста выше (поскольку я говорил об этом же) подменяете понятия — «скорость выполнения» и «скорость разработки».
                                      0
                                      Относительно верхней абстракции? (мы имеем в виду скорость выполнения, а не скорость разработки).
                                      Скорость исполнения чего? Давайте не сравнивать сферических коней в вакууме. Простой интерпретатор, написанный на ассемблере против JIT'а проиграет с вероятностью 99%. И даже JIT, написанный на ассемблере (и потому не включащий в себя многих оптимизаций) проиграет JIT'у, написанному на C/C++.

                                      Еще какая гарантия, поскольку верхняя абстракция используется эту нижнюю внутри себя с многочисленных проверками, чтобы уменьшить монотонные операции.
                                      Если вы запрограммируете один и тот же алгоритм — то да. Но так задача не стоит. Вам приходится сравнивать сложный, хитрый алгоритм, написанный на C/C++/Java/Python с простым, бесхитростным на ассемблере. Либо с плохо написанным кодом на ассемблере (потому что после нескольких миллионов строк вы либо вообще забудете что вы там замышляли вначале, либо начнёте халтурить). В обоих случаях ассеблерная версия, с большой вероятностью, проиграет.

                                      В очередной раз повторяю — основная идея усиления абстракций — убыстрить разработку, жертвуя ресурсами (но с верой и знанием, что то, для чего разрабатывается абстракция — тоже развивается).
                                      Есть ещё одна сторона у медали, которую вы упорно не желаете замечать. Использование высокоуровненого кода позволяет менять нижележащий код на основе взаимодействия кода с реальными миром (посмотрите на досуге как работает profile-based optimization и JIT не говоря уже о всяких ATLAS'ах), а то, что вы породите на более низком уровне — будет статично. И во многих случаях (но, разумеется, не всегда) вещь, порождённая на низком уровне будет проигрывать за счёт своей статичности.

                                      Начиная с некоторого уровня сложности системы код, написанный на низком уровне оказывается менее эффективен, чем код, переведённый с высокого уровня с учётом сложившихся реалий! А сложившиеся реалии могут быть разные: новые процессоры, учёт профайла и т.д. и т.п. Разумеется это относится к достаточно эффективным асбтракциям — таким как C, Java или JavaScript. Я не могу представить себе ситуацию когда манипуляция бинарными данными будет медленнее, чем работа с XML. Возможно когда речь зайдёт о триллионах строк кода…
                                        0
                                        > Начиная с некоторого уровня сложности системы код, написанный на низком уровне оказывается менее эффективен, чем код, переведённый с высокого уровня с учётом сложившихся реалий!

                                        А то я тут рассуждаю про код под железо, сшитое при царе Гороже?! Когда проводятся аналогии — они и должны быть аналогиями.

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

                                        > И даже JIT, написанный на ассемблере (и потому не включащий в себя многих оптимизаций) проиграет JIT'у, написанному на C/C++.

                                        Это как? Мне реально интересно. Я правильно понимаю — Си-транслятор, написанный на асме (при этом Си-шные обертки внтри себя имеют по несколько десятков ассемблерных вставок, чтобы предусмотреть «все случаи жизни») быстрее того же самого асма (того же самого! а не того, который был был при Рамзесе-III написан и не учитывал новые возможности железа).

                                        Какой смысл сравнивать то, что не может учитывать новых особенностей с тем, что это может делать? (и в случае с JIT'ом и PBO еще и делает это в рантайме, подстраиваясь под текущие аппаратные возможности) — обычная подмена понятий.

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

                                        При этом, несомненно, JIT добавляет в интерпретируемость приближение с компилируемым скоростям.

                                        Все эти оптимизации — есть так же абстрагированные сущности прогресса и, конечно, очень важны в скорости разработки (для которой все это создается).
                                          0
                                          Это как? Мне реально интересно. Я правильно понимаю — Си-транслятор, написанный на асме (при этом Си-шные обертки внтри себя имеют по несколько десятков ассемблерных вставок, чтобы предусмотреть «все случаи жизни») быстрее того же самого асма (того же самого! а не того, который был был при Рамзесе-III написан и не учитывал новые возможности железа).
                                          Того же самого не бывает! В этом весь прикол. JIT и PBO порождают код «на лету» и потому могут обогнать статический ассемблерный код! И вы не сможете написать «правильный» код, который смог бы с этим бороться потому что вариантов — бесконечное число (на самом деле конечно, конечное — но разница между гуголом и бесконечностью невелика). Конечно вы можете на ассемблере написать код, который будет порождать реальный код на основании некоторых таблиц, но… тогда реальная программа у вас окажется зашитой вот в этих самых таблицах — и это и будет ваш язык высокого уровня. С чем боролись, на то и напоролись!

                                          При этом, несомненно, JIT добавляет в интерпретируемость приближение с компилируемым скоростям.
                                          Есть задачи на которых JIT обгоняет и PBO и ассемблер. Сейчас пока таких не много, но как повернётся дело в будущем? Посмотрим…
                                            0
                                            > Есть задачи на которых JIT обгоняет и PBO и ассемблер.

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

                                            Другой вопрос, если говорить только лишь о динамических, интерпретируемых сущностях — так для этого, повторю, эти оптимизаторы (JIT и т.д.) создавались, чтобы быть быстрее.
                                              0
                                              Ладно, не охота мне разводить спор, но по-любому — заточенные под одно и тоже железо асм будет быстрее си (при этом оба компилируемые) и уж тем более они оба будут быстрее интерпретируемой сущности (хоть и JIT-оптимизатором).
                                              Вот нифига подобного! JIT видит программу в целом и видит поток её исполнения — и может на основе этого знания делать соотвествующие оптимизации. Например: у вас в программе подгружается модуль работы с джойстиком. В каком-то месте вызываются функции, зависящие от типа джойстика. Но JIT замечает что в реально запущенной программе джойстик — только один. И этот вычисляемый переход (весьма дорогой на современных CPU) можно заменить на безусловный (стоимость которого стремится к нулю). JIT может это сделать так как он знает что других джойстиков в программе нет, а буде они появятся — программа будет перекомпилирована. PBO тоже может заметить такие вещи и хотя ему придётся подстраховаться (код будет состоять из двух команд: проверка на тип джойстика и переход «на медленную часть функции» если тип «неправильный»), но код всё равно будет быстрее чем то, что вы напишите руками на ассемблере!

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

                                              Если вдуматься то современные процессоры (все эти предсказания ветвлений, спекулятивные загрузки и прочее) занимаются тем, что делает JIT — но свободы для манёвра у них на порядок меньше!

                                              Другой вопрос, если говорить только лишь о динамических, интерпретируемых сущностях — так для этого, повторю, эти оптимизаторы (JIT и т.д.) создавались, чтобы быть быстрее.
                                              Это самоочевидно. Но вы забываете что кроме динамических, интерпретируемых задач есть динамический мир! У большинства компьютеров только одна клавиатура — но воткните в USB-порт сканер штрих-кодов и их станет две! Ассемблерной программе нужно всё это учитывать и на все эти проверки уходит время, а JIT и, в меньшей степени, PBO могут «срезать углы» — за счёт того, что они могут отследить редкие, нестандартные, случаи и в этом случае сделать всё ну очень медленно, но зато в 99.9% случаев они будут обгонять ассемблер.

                                              Правда надо сказать что для того, чтобы эти эффекты увидеть нужно писать очень аккуратно, а большинство программистов на ЯВУ этим себя не утруждает (в отличие от использующих ассемблер).
                                                0
                                                А, да, это — да. А на каком этапе (какой большой ИИ заложен в различные версии JIT?) определяется, что модуль с джойстиком можно выбросить из кода? Для подобных статичных условий есть известные препроцессорные директивы, aka

                                                #ifdef CONFIG_TEST
                                                  int a = 10;
                                                #endif


                                                При этом в код никогда не попадет «a», если CONFIG_TEST не задан.

                                                А в случае с джойстиком? Допустим, есть кнопка, по нажатию на которую, осуществляется то или иное действие (в зависимости от присутствия джойстика). Джойстик не подключен, компилируется программа, из нее выбрасывается часть кода с if'ом для джойстика. Дальше нажимается кнопка — что должно произойти? Выдаться сообщение — «JIT выкинул эту часть кода»? Или начнется тотальная перекомпиляция?

                                                Я понимаю, зачем нужен JIT и что он делает; мне интересно, на каком моменте определяется — когда выбрасывать (по сути — сделать статичными if'ы как в случае с #ifdef) тот или иной кусок, а когда — восстанавливать.
                                                  0
                                                  я забыл написать самое важное действие — дальше джойстик подключается во время работы программы (с уже выкинутыми кусками кода для работы с джойстиком) и — Дальше нажимается кнопка
                                                    0
                                                    А на каком этапе (какой большой ИИ заложен в различные версии JIT?) определяется, что модуль с джойстиком можно выбросить из кода?
                                                    На этапе исполнения. Когда несколько раз вызывается одна и та же функция из одного места в программе JIT может решить что она и дальше так будет вызываться. Если в принципе функция виртуальная (то есть на-final), но в реальности есть только одна реализация то JIT может выкинуть эту виртуальность.

                                                    я забыл написать самое важное действие — дальше джойстик подключается во время работы программы (с уже выкинутыми кусками кода для работы с джойстиком) и
                                                    JIT забывает всё что он ранее накомпилировал. У него появляется новый класс и предположение что вызов на самом деле статический становится неверно. Когда этот же кусок кода скопилируется второй раз — он уже будет отрабатывать события, связанные с джойстиком.

                                                    Тут важно выдержать баланс между подстройкой под внешнюю среду (ускоряющей программу) и затратами времени на эту подстройку (замедляющими программу).

                                                    Разумеется всю эту логику с джойстиком можно вставить в программу на ассемблере тоже, но фишка в том, что JIT способен отлавливать такие фишки по всему коду программы, а человек, пишущий код на ассемблере сможет предусмотреть весьма ограниченный набор вариантов.
                                                      0
                                                      > Когда несколько раз вызывается одна и та же функция из одного места в программе JIT может решить что она и дальше так будет вызываться

                                                      что значит «может решить»? А если функция 99 раз вызвалась так, а вот на сотый — по-другому? Не правильно. JIT, анализирует какой-то главный условный блок, а потом может удалить все остальные блоки кода, завязанные на это условие (я так понимаю). Т.е. однозначное детерминированы участки. А решения «авось будет, авось нет» — такого JIT не делает.

                                                      > Тут важно выдержать баланс между подстройкой под внешнюю среду (ускоряющей программу) и затратами времени на эту подстройку (замедляющими программу).

                                                      Ну вот это точно.
                                                        0
                                                        что значит «может решить»? А если функция 99 раз вызвалась так, а вот на сотый — по-другому?
                                                        А та же самая фигня что и в спекулятивном исполнении в процессоре: JIT должен гарантировать что «если что» созданных им код всё откатит и случайные неправильные изменения исправит.

                                                        JIT, анализирует какой-то главный условный блок, а потом может удалить все остальные блоки кода, завязанные на это условие (я так понимаю). Т.е. однозначное детерминированы участки. А решения «авось будет, авось нет» — такого JIT не делает.
                                                        Делает. И Sun'овская Java делает и V8 делает. Грубо говоря один-два самых распространённых варианта он может вставить в код, остальное — в медленно исполняющуюся подпрограмму. Если эта подпрограмма слишком часто вызывается — всё перекомпилируется. Или нет. В зависимости от результатов профайлера.

                                                        Самое обидное что вся эта мощь не спасает от простого головотяпства: JIT, спекулятивное исполнение, параллельная сборка мусора и… какой-нибудь хитрый Injection Framework замедляющий скорость в 100 раз. А потом ещё удивляются почему программы на Java тормозят. Нет — тут дело не в отказе от ассемблера…
                                                          0
                                                          > А та же самая фигня что и в спекулятивном исполнении

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

                                                          > Делает.… В зависимости от результатов профайлера.

                                                          Т.е. JIT опирается только на профайлер?
                                                            0
                                                            Ага, при этом эта «работа над ошибками» (если предсказание было неверным) займет много больше времени.
                                                            А это уже от задачи и от создателей JIT'а зависит.

                                                        0
                                                        А реальные примеры есть с тестами и замерами? Просто реально интересно. Теоретически-то оно хорошо, и для интерпретируемых языков, само-собой, несет увеличение производительности (пусть памяти больше жрет, пусть тратит время каждый раз на компиляцию кусков байт-кода и отсеиванию ненужных). Хочется, действительно, посмотреть, что интерпретируемый язык с JIT'ом может обгонять скомпилированный код.
                                                          0
                                                          Под рукой нету, но с ними вообще беда: всегда можно заявить что «ну мы вот тут перепишем вашу программу — и С/C++ опять вашу java'у обгонят». Но тут ведь фишка как раз в том, что программа подстраивается под изменяющуюся среду! Поищите в гугле на «Java faster than C++» (скажем вот). Там есть много статей, обсуждений, критики и прочего. В любом случае речь уже давно не стоит как: «может ли JIT обогнать компилируемый язык или ассемблер?», а как "часто ли JIT обгоняет компилируемый язык или ассемблер?". Ответ на него: да, такое бывает, но редко. Сторонникам Java этот ответ не нравится (они бы предпочли бы чтобы ответ был «да, почти всегда»), противников он бесит (как-так: Java и обгоняет ассемблер?), но таква вот объективная истина на сегодня…

                                                          P.S. JavaScript даже с JIT'ом пока отстаёт и от Java и от C/C++… Но там ещё JIT'ы очень примитивные — посмотрим как оно дальше будет…
                                                            0
                                                            > Ответ на него: да, такое бывает, но редко.

                                                            Да, сам JIT должен быть при этом очень грамотно спроектирован (с отличным предсказанием), тогда, возможно, будет чаще.

                                                            > но таква вот объективная истина на сегодня… посмотрим как оно дальше будет…

                                                            Посмотрим; anyway, спасибо за инфу ;)
                                                  0
                                                  Ок, раз на то пошло, давайте тогда примерами, а не пустыми минусами ;) А то несерьезно как-то.
                                                    0
                                                    В качестве примера — сравните время работы тупого когда, который проверяет много вложенных условий по типу:
                                                    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 именно для ускорения программы (ну и немного в нём налажали, но это уже другая история).
                              +1
                              Действительно, при мощностях современного железа, уменьшение эффективности сгенерированного кода относительно не заметно. Но это не значит, что ухудшения нет!
                              Не значит. Но тут тоже срабатывает эффект масштаба: отличный вылизанный ассемблерный код к моменту выхода твоего творения в свет (через годы, а то и десятилетия) будет однозначно хуже того, что сгенерирует компилятор ибо железо со временем меняется и оно затачивается под компилятор, а не под ручной ассембленый код. Простейший пример: набор инструкций x86 содержит операции работы со строками — но на соврменных процессорах гораздо быстрее сделать обычный цикл и просто набором mov'ов всё скопировать! Хотя на старых процессорах было наоборот.

                              Таким образом использованием компилятора генерирует относительно неплохой код (но не самый лучший), а прямое использование ассемблера — однозначно никуда не годный код…
                                –1
                                >>вылизанный ассемблерный код к моменту выхода твоего творения в свет (через годы, а то и десятилетия)
                                Какие годы? Вы о чём? Часто на асме писать проще и быстрее чем на том же C.
                                Проблема совершенно в другом — в поддержке этого кода.
                                Когда я смотрю в то, что GCC генерит под PowerPC, иногда чуть ли не слёзы наворачиваются.
                                  0
                                  Какие годы? Вы о чём?
                                  О разработке ПО, однако. В выходящих сейчас «новых» продуктах зачастую сидит код даже не из 90х, а и из 80х. За это время микроархитектура успевает смениться кардинально.

                                  Когда я смотрю в то, что GCC генерит под PowerPC, иногда чуть ли не слёзы наворачиваются.
                                  А вы уверены, что то, что породите вы и что будет вам казаться красивым и замечательным будет реально хорошо работать на будущих поколениях PowerPC? Да даже и на нанешнем: PowerPC бывают разные и то что хорошо для суперскаляра вполне может оказаться не самым лучшим вариантом для какой-нибудь простой версии.
                                    –2
                                    1) Предпочитаю не работать на проектах, срок разработки которых > 2 лет. Я не мазохист.
                                    Я не верю в реюзинг кода. Обычно многое из того что было написано 2 года назад, достойно быть переписанным с чистого листа под конкретную задачу.
                                    Производительность — приоритет. Остальное неважно.
                                    2) Я пишу под конкретную фиксированную платформу. Пишу здесь и сейчас, а не в будущем под несуществующие архитектуры. Временные рамки обозначены.
                                      0
                                      1) Предпочитаю не работать на проектах, срок разработки которых > 2 лет. Я не мазохист.
                                      Я правильно понял что:
                                      1. Вы не пользуетесь операционной системой.
                                      2. Вы не пользуетесь ни C, Perl'ом, Python'ом и JavaScript'ом.
                                      3. Вы не создаёте серъёзных проектов, которыми будут пользоваться миллионы людей.
                                      Простите, а какое отношение вся ваша деятельность имеет к IT? Мне кажется что вы либо кривите душой и выдаёте желаемое за действительное (наиболее вероятный подход), либо всё ваше программирование — это какие-то жёсткий embed, который, конечно, важен, но составляет ничтожную часть IT.
                                      2) Я пишу под конкретную фиксированную платформу. Пишу здесь и сейчас, а не в будущем под несуществующие архитектуры. Временные рамки обозначены.
                                      То есть это всё-таки embed? Ну так если всё что вы делаете — выпуск гвоздей, то не нужно рассуждать о строительстве домов и современной архитектуре.
                                        0
                                        >>Я правильно понял что:
                                        Неправильно. Откуда вы выудили столько информации из этой строки?
                                        Там написано только то, что я не хочу как зомби выдрачивать один проект на протяжении десятилетий.
                                        Допустим правда, что JS я не пользуюсь, но это ничего не меняет.

                                        >>3. Вы не создаёте серъёзных проектов, которыми будут пользоваться миллионы людей.
                                        Ну да, «что ты сделал для хип-хопа?» весомый аргумент.
                                        Я работаю только с проектами которые доставляют мне фан. В данный момент это низкоуровневое программирование и железо.
                                        Да и сколько вам нужно миллионов? Пары миллионов достаточно?

                                        >>не нужно рассуждать о строительстве домов и современной архитектуре.

                                        Я не рассуждаю об абстрактных вещах, я просто подверг сомнению ваше беаппеляционное заявление
                                        «ассемблерный код к моменту выхода твоего творения в свет (через годы, а то и десятилетия)»

                                        Ассемблерный код на сроки выхода проекта не может сильно повлиять, потому что он не нужен везде где попало, а только в некоторых местах, где реально можно поднять скорость.
                                        Асм влияет на сложность поддержки кода и понимания его другими,
                                        но написание асм-кода не займёт сильно больше времени чем написание оптимизированного кода на C++, а часто и меньше его.
                                        Профессионал сам решит где и что нужно применять, и чужие стоны его не будут волновать.
                            +9
                            Вы не согласны с тем, что ассемблерный (а точнее, машинный) код, полученный в рещультате компиляции высокоуровневой программы является уродским? Во всяком случае по сравнению с ассемблерным кодом написанном вручную.
                            А вы видели то, что порождает современный компилятор? Вот реально? Мне — доводилось (когда в нём глюки начинаются). Да, есть и уродские места, но зачастую возникает ощущение чуда. Простейший пример (просто наобум из головы):
                            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 мешают ему сделать хороший код (и если писать на ассемблере, то на это можно «забить» если будут основания), но есть посмотреть в целом, то выдержать на этом уровне программу больше одного-двух килобайт руками — не сдюжишь…
                              0
                              абсолютно согласен. хотя это верно для обычных компиляторов. те, которые позволяют программировать микроконтроллерны на СИ частенько генерят бред.
                              • НЛО прилетело и опубликовало эту надпись здесь
                                  –1
                                  Ещё смешнее, что автор статьи путает ассемблерный код и машинный.
                                  См. 1-ю сноску.
                                  • НЛО прилетело и опубликовало эту надпись здесь
                                      0
                                      >>… относятся не к епархии ассемблера, а к архитектуре.
                                      я так понял что речь о макроассемблерах и таких штуках как INVOKE в masm
                                      • НЛО прилетело и опубликовало эту надпись здесь
                                          +1
                                          Автор прав в том, что HTML/CSS/JS — это устаревшая технология. Не фактически, но морально.
                                          Я рад, что Вы со мной согласились, но я имел в виду как-раз противоположенное :-)

                                          Я считаю, что HTML/CSS/JS — не являются устаревшей технологией! И они лишь воспринимаются многими разработчиками как устаревшие, из-за недооценки заложенных в них гибкости и мощи.

                                          Другое дело, что эти технологии, перестав развиваться как технологии развития web-приложений, действительно могут устареть, и уйти со сцены, уступив место Flex или Silverlight. Подобно тому, как интерфейсы на основе Turbo Vision уступили место windows'овским интерфейсам («гибель физическая»).

                                          Но, именно для того, чтобы, чтобы HTML/CSS/JS не прекращали развиваться, как технологии создания web-приложений, и была создана WHATWG. И HTML5 — один из шагов такого развития.

                                          Будущее всё-таки за виртуальными машинами — будь то .NET или JVM или аналогичное решение от Adobe
                                          Полностью согласен. Но, пусть этой виртуальной машиной будет браузер!

                                          • НЛО прилетело и опубликовало эту надпись здесь
                                              +1
                                              Windows стала востребована позднее, когда массово стали закупать 386-е машины, а так то она с середины 80-х существует. Да и это разного класса продукты — TurboVision библиотека, каких тогда были десятки.
                                              У вас в этом месте каша. Да, Windows появилась раньше Turbo Vision — но это была библиотека плюс кучка демо-программ. Aldus Pagemaker поставлялся с Windows, а не наоборот! А вот уже Windows NT — это другая история. Это была полноценная операционка, но она появилась заметно позже Turbo Vision…
                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                  0
                                                  Нет, это у вас в этом месте каша. Windows никогда не была просто библиотекой. До полной операционной системы есть не хватало загрузчика, и загрузчиком выступала DOS.
                                                  Ну тогда с тем же успехом можно сказать что и GEM и DESQview/X и куча других подобных оболочек — это всё были разные операционки.

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

                                                  Короче говоря, учите матчасть. И по поводу NT — посмотрите на копирайт во время загрузки. С удивлением обнаружите там 1985-2001 (если речь идёт об XP).
                                                  Ага. А Solaris вообще от 70х годах пишет. Значит ли это что в 70е годы кто-то мечтал от SPARC'е?
                                                  • НЛО прилетело и опубликовало эту надпись здесь
                                                +1
                                                Ну вот как это у Вас получается? 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!
                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                    0
                                                    [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 чего-то». Мы используем эту технологию из-за ее мощности, гибкости, удобства (ну и на красоту тоже нельзя не обращать внимание :-) ).
                                          0
                                          Имитация стека и вызов функций относятся не к епархии ассемблера, а к архитектуре. В процессорах Intel, начиная с 8086, стек присутствовал, и были соответствующие инструкции для работы с ним.
                                          Стек присутствует не во всех процессорах. В старых процессорах Intel и Motorolla стека не было. Однако, потом для этих процессоров были созданы ассемюлеры, в которых стек эмулировался, позволяя программисту писать код так, как будто в процессоре стек есть. Поправьте меня, где я не прав.

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

                                          Но, на всякий случай, пока заменил другой «фишкой» продвинутого ассемблера — использованием макросов. «Фишкой», которая стала не нужной высокоуровневым разработчикам. Также, как станут не нужными многие «фишки», облегчающие разработку front-end разработчикам, если xHTML/CSS/JS-код будет генерироваться автоматически…
                                          • НЛО прилетело и опубликовало эту надпись здесь
                                              0
                                              Всю эту информацию Вы почерпнули из книг. Вероятно, очень классических. Стека и функций не было на старых процессорах — это да.… С 60-х такой проблемы нет у программистов. :)
                                              Но, все же, это, показывает, что имитация стека в ассемблерах для старых процессоров не является чушью :-)

                                              И это можно привести в качестве примера, пусть и очень старого.
                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                  0
                                                  Он просто ни при чём.
                                                  Этот пример вот о чем:

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

                                                  Так, ассемблерные макросы (или имитация стека для бесстековых процессоров) облегчала разработку программистам на ассемблере. Но стали совершенно не нужной для высокоуровневых программистов на C++.

                                                  Так же, и использование «Ненавязчивого JavaScript» облегчает жизнь xHTML/CSS/JS разработчикам, но становится совершенно не нужным, если xHTML/CSS/JS-код генерируется автоматически.

                                                  Это показывает, что на ассемблере [без стека, как я понимаю] Вы не писали, но где-то прочитали, как оно было.
                                                  Я как-то писал на ассемблере для микроконтроллера, на котором стека не было (так просто ради развлечения, не углубляясь). Но, да, для нормальных компьютеров я на ассемблере без стека никогда не писал (но, читал об этом), Вы правы.
                                            0
                                            И это я уже не говорю об антимайкрософтовской идеологии

                                            В статье нет никакой «антимайкрософтовской идеологии».

                                            Я считаю классические xHTML/CSS/JS замечательными и удивительно гибкими технологиями построения интерфейса; и выступаю против отказа от их использования не только в сторону микрософтовских ASP.NET-контролов и Silverlight, но и Flex от Adobe и JSF от SUN.

                                            К самой же Микрософт и, даже, «чистой» ASP.NET (без учета контролов), я отношусь с большим уважением.

                                            См. 3-ю сноску:
                                            Конечно, ASP.NET не ограничивается одними серверными контролами. ASP.NET — очень могучая, производительная, надежная технология, использующая всю мощь .NET Framework. Однако, многие разработчики используют ASP.NET именно из-за серверных контролов.
                                            • НЛО прилетело и опубликовало эту надпись здесь
                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                    +1
                                                    SelenIT видимо имеет в виду, что использование обработчиков в тексте xHTML-кода — полностью не соответствует идее отделения разметки от интерфейсной логики и противоречит концепции «Ненавязчивый JavaScript» (см., например здесь и здесь).

                                                    Что не намного лучше конструкций типа: <font color = "" size = "">

                                                     
                                                    Позволю себе процитировать фрагменты двух моих комментариев (по поводу серверных контролов, уродского кода, MVC и оптимизма):

                                                    этого:
                                                    Традиционное ASP.NET меня сильно раздражает — впечатление такое, что старались переманить разработчиков GUI-приложений, делая вид, что веб ничем не отличается.

                                                    … тогда пощупаю MVC.
                                                    Полностью согласен. Сама по себе ASP.NET и .Net вообще — очень мощная технология.

                                                    Но попытка применить к 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-й сноске.
                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                        0
                                                        А вот отделение javascript от html — в коде, который автоматом генерируется на сервере… Ну, чёрт его знает. На мой взгляд, на серверную логику это никак не влияет.
                                                        Ну вот, мы и пришли к общему мнению :-)

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

                                                        Компиляторы C++ часто генерирует некрасивый низкоуровневый код (а порой и менее эффективный, чем мог бы написать профессиональный низкоуровневый программист). Но это не страшно для C++ программиста, ведь его высокоуровневый C++ код, с которым он работает и на который любуется — очень красив.

                                                        Так же, и ASP.NET часто генерирует уродский низкоуровневый HTML-код. Для меня — смешение разметки с JavaScript-логикой — страшное уродство.

                                                        Но для Вас — это не проблема, ведь Вы работаете с красивым ASP.NET-кодом.
                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                          0
                                                          А вы посмотрите на любой генерированный код любого развитого фреймворка. Он везде страшный.
                                                          Большинство современных 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 для построения интерфеса не является менее высокоуровневым, чем использование серверных контролов…
                                      0
                                      Я думаю, что по «IT индустрией» автор понимает Прикладное программирование. Всмысле разработку настольных приложений, которые в основной своей массе редко используют ассемблер для решения низкоуровневых задач, а скорее используют готовые библиотеки.
                                        0
                                        Я думаю, что по «IT индустрией» автор понимает Прикладное программирование.
                                        Да, именно так. Это я указал во 2-й сноске.
                                      +6
                                      По поводу использования prototype и jQuery — это очень удобный способ не задумываться над «особенностями» и «нюансами» реализации функций под различными версиями в браузерах… Как мне кажется знание таких особенностей не столь уж важно при высоком темпе разработки… а вот когда останется время оглянуться…
                                        0
                                        jQuery — замечательная библиотека, сильно упрощающая работу с DOM. Главное ее преимущество в том, что она развивает JavaScript, а не пытается сделать из JS «упрощенный огрызок».

                                        Prototype.js — совсем другое дело. Она не развивает прототипную парадигму языка, а пытается эмулировать классическое классовое ООП, что является страшным надругательством над JavaScript, лишающим его такой красоты и гибкости.
                                          +3
                                          Вообще-то в jQuery тоже есть extend, а в prototype никто не заставляет использовать Class. Тут как раз полная свобода выбора.
                                            +2
                                            да ну, смешно насчет прототипа
                                            в нем помимо объекта Class есть масса других удобных классов
                                              0
                                              Ага. Такое ощущение, что автор ничего кроме ASP.NET не видел. Только читал на википедии…
                                              +1
                                              Плюс ко всему, jQuery весит меньше. Не у всех есть возможность gzip'ить прототайповский файл.
                                                +3
                                                > классовое ООП, что является страшным надругательством над JavaScript

                                                насколько Вы профи в JS? а с Python'ом Вы знакомы, например? А классы в Питоне видели? А практически 93% сходство идеологий описания классов в Python и prototype based inheritance в JS видели? Тем не менее, в Python это назвали классы (да и Ruby тоже).

                                                Не обращайте внимание на то, что кто-то делает для себя обертки в виде классов для JS. В любом случае — внутри этих оберток — все то же (единственное в текущей версии ECMAScript) — прототайп-бэйзд-инхеритэнс, а значит человек который писал эту обертку — понимал, в чем дело.

                                                Другой вопрос, что новичкам это может туманить разум; вот в этих случаях им надо помогать.
                                                  +1
                                                  > Не обращайте внимание на то, что кто-то делает для себя обертки в виде классов для JS. В любом > случае — внутри этих оберток — все то же (единственное в текущей версии ECMAScript) —? прототайп-бэйзд-инхеритэнс, а значит человек который писал эту обертку — понимал, в чем дело.

                                                  5 баллов, а то иногда попадаются умники, которые начинают долдонить свое, какие же это классы и т.д.
                                                    +1
                                                    Можно поспорить над фразой «а значит человек который писал эту обертку — понимал, в чем дело». Не факт. Ситуация схожа с пугалом «eval — зло!», профи понимает, что это не так однозначно, но пугало-то стоит не для профи. С классическим ООП та же история, с фреймворками та же история и т.д.
                                                      0
                                                      Да конечно, не факт. Только вот с фразами «надругались над JS — используют классы» та же история. Конечно, печально, когда действительно не понимают, как это работает, и яро доказывают всякую отсебятину. Но вот те, кто создает просто удобные обертки для создания последовательной связи объектов через прототипы, мне кажется, и холиворить-то не будут никогда не эту тему. Ну назвали бы они эту обертку InheriteFrom(...) (или ObjectConstructorWithInheritance), а не Class(...) (при этом бы начинка не поменялась бы ни на байт) — все! — вряд ли бы вообще кто-то что-то критиковал.

                                                      Хотя, да — человек может и не осознавать, что он пишет обертку, а думать, что доводит до «ума» этот «бесклассовый язык». Здесь надо просто с самого начала сказать (и показать), что есть альтернативная модель наследования (что человек просто не в курсе, что речь о разных подходах ведется) и что она так же хороша и даже относительно лучше (это я опять не тебе говорю (ты и так хорошо преподаешь), а — вообще — всем, кто выбирает сам постоянно вестить на выкрики новичков aka «че за язык? тут даже классов нормальных нет!»)
                                                        0
                                                        Понимаешь, какое дело — автор пристрелил в статье prototype.js и одновременно назвал jQuery э… чего-то там развивающей в javascript. Это в стиле «я за абстракции, но я против абстракций» или «долой обёртки, но одна из самых худших обёрток мне сильно-сильно нра...». Вот как всё это принимать? Как сознательное или бессознательное? Принимать это можно только в самых общих чертах по результату (безотносительно мотивов и деталей) — выставлено пугало «классовое ООП — зло!», выставлено пугало «prototype.js — зло!», ну, и отлично, пусть теперь постоят и детей попугают…
                                                          0
                                                          > выставлено пугало «классовое ООП — зло!»

                                                          Вот именно, что пугало. При этом одними, когда они видят заголовки «классы в 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 уровней. Конечно его выгодней вынести в прототип. Таким образом делегирующая прототипная модель получается выгодней в ресурсах.
                                                            0
                                                            а черт! )) случайно кнопка нажалась, не дописал и теги не закрыл )) ну в вроде все, что хотел — упомянул )) да, в Питоне — то же самое:

                                                            Хотя, я не читал спецификацию ES4 — возможно там сделано оптимизация, и это на самом деле, один метод (просто из-за того, что он связан с инстансами выдается false — но я не знаю точно, это только предположение)
                                                    0
                                                    Про prototype — ерунда. Class — очень незначительная часть prototype.js.
                                                    Настоящее надругательство — это DOM database storage.
                                                  +2
                                                  Не могу полностью согласиться с выпадом в сторону JS-фрэймворков.
                                                  С прототайп работать не довелось, но с jQuery работаю уже около полутора лет, при этом около полутора лет до этого работал с чистым яваскриптом — конечно далеко не на «полную катушку», но с аяксом и ДОМ работал довольно плотно.

                                                  Так вот, я к тому, что тот же JavaScript-jQuery я бы сравнил с C-C++ — многие вещи организованы намного более удобно + кроссбраузерность, что крайне важно (вспоминаю нехорошими словами отладку чистого яваскрипт под IE/FF/Opera/Safari).
                                                    0
                                                    Полностью с Вами согласен. Именно это я сформулировал в предыдущем комментарии.

                                                    Бывают фрэймворки двух типов:

                                                    • Хорошие(например jQuery, Dojo) — которые развивают JavaScript.
                                                    • Плохие (например, Prototype.js) — которые не развивают JS, а, наоборот «отрезают» от языка многие мощные, но малопонятные многим разработчикам возможности, вроде прототипного программирования и т. д.


                                                    Еще раз процитирую Ричарда Корнфорда:
                                                    Prototype.js был написан теми, кто не знает JavaScript, для тех, кто не знает JavaScript


                                                    Но и Prototype.js надо отдать должное — на момент своего выхода это была чуть ли не единственная целостная JS-библиотека, упрощающая работу с DOM. Так что в свое время она сильно упростила жизнь разработчикам…
                                                      +2
                                                      Вы неправильно, как мне кажется, понимаете причины создания такого фреймворка как prototype. Prototype создавался под RoR и потому основная цель автора, кроме абстрагирования от особенностей браузера, состоит в создании синтаксиса максимально приближенного к RoR.

                                                      Но я согласен, что это снижает ценность Prototype для всех остальных.
                                                        +1
                                                        Prototype создавался под RoR

                                                        Да, полностью согласен.

                                                        Поскольку Ruby поддерживает класс-ориентированное ООП (хотя, как и в Python (см. комментарий dsCode ), близкое к прототипному ОПП JavaScript'а), использование Prototype.js как часть Ruby on Rails гармонично и красиво.

                                                        Но, использование класс-ориентированного ОПП в самом JavaScript'е является, как я считаю большим «надругательством» над прототипной идеалогией JavaScript.

                                                        Что, конечно, не отменяет достоинств Prototype.js, как одной из первой библиотеки для упрощения работы с DOM.
                                                        0
                                                        напишите, чем конкретно плох prototype?
                                                          –3
                                                          Возможено выскажу мысль остальных противников, prototype не сильно урощает/сокращает код, точнее все же сокращает но только из-за того что не приходится подгонять под все броузеры, т е если предположить что js работает во всех броузерах _одинаково_ то тольку от него _меньше_ чем от, например, jQuery.

                                                          З.Ы. не есть истина, с prototype знаком плохо.
                                                            +1
                                                            Вы говорите, что плохо знакомы с proototype, но беретесь утверждать, что это плохая библиотека.
                                                            Я вот не утверждаю, что jQuery хуже prototype.
                                                            Ваш ответ не засчитан.
                                                              –2
                                                              я не утверждал что она плохая, я лишь сказал что она малоэффективна…
                                                          +1
                                                          Если уж цитировать R.C. про prototype, так и про jQuery было бы неплохо… А то как-то даже неудобно… ;)
                                                        0
                                                        По поводу ассемблера. Никуда он не пропал. Программирование простых систем на ассемблере как было, так и осталось. Может действительно чуть меньше.

                                                        По поводу верстки и всего остального. Если на этом «нечто» будет писаться прикладное «ПО», то будут и платформы.

                                                        А вообще все сведется к X (%
                                                          0
                                                          По поводу ассемблера. Никуда он не пропал. Программирование простых систем на ассемблере как было, так и осталось. Может действительно чуть меньше.
                                                          Еще раз повторю:

                                                          См. сноску. Речь идет о прикладной IT-индустрии, а не о системном программировании. Тестовый редактор на ассемблере пишут только эстеты, вроде разработчиков KolibriOS.

                                                          Но это уже искусство, а не IT-индустрия.
                                                          +1
                                                          Название страшное и не соответствует содержанию. Допустим, устареют xHTML, CSS, JS, веб от этого никуда не денется, ничего страшного в этом не вижу. Да, уже сейчас можно не зная JS, xHTML как такового, за пол часика накропать богатую контролами страничку, работающую на одном аяксе. Неплохо знать XML и тэги используемых неймспейсов, собственно ничто не мешает держать в голове и использовать «дефолтный» неймспейс xHTML, содержащий сами HTML тэги. CSS в случае ASP.net подобных платформ остается в полной силе, в Silverlight / Flex да, убираем. Все это прекрасно, я считаю.
                                                            +1
                                                            Я склонен думать, что HTML — это все-таки действительно язык разметки гипертекста, со всеми вытекающими.
                                                            Именно поэтому появились специально предназначенные для этого технологии, которые позволяют более эффективно строить RIA-приложения, так как предназначены для этого (Flex, Silverlight).
                                                            Думаю, в определенной перспективе, просто каждая технология станет использоваться более-менее по прямому назначению.

                                                            Мы, создавая сложные RIA на основе HTML, CSS, Ajax, сталкивались непосредственно с тем, что эти технологии изначально не предназначены для этого, а используются за отсутствием альтернатив. И, кстати, я сам до сих пор не понимаю, почему народ зачастую так излишне зациклен на JavaScript-фреймворках, а не использует те же Flex и Silverlight для многих задач.
                                                              0
                                                              Я склонен думать, что HTML — это все-таки действительно язык разметки гипертекста, со всеми вытекающими.
                                                              Сам по себе XHTML — действительно только язык разметки гипертекста.

                                                              Но в сочетании с CSS и JS он приобретает столь фантастическую мощь, масштаб которой до сих пор даже не оценен.

                                                              Это делает HTML одним гибчайшихх языков построения интерфейса.

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

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

                                                              Мы даже можем превратить дерево в контекстное меню, а контекстное меню в список прямо на лету, без перезагрузки страницы, просто динамически заменив таблицу стилей!

                                                              В каком еще языке разметки интерфейса так можно?!


                                                                0
                                                                Да я и не говорю, что HTML сам по себе очень уж плох для интерфейсов. Я как раз про маленький аспектик — «Это делает HTML одним из гибчайших языков построения интерфейса». Ключевое слово — «делает». А подмножества тех же XAML (в Silverlight) и MXML (во Flex) — специально предназначены для этого.
                                                                Собственно, вместе с тем же MXML используется CSS, а отдельно для графики еще и FXG. Я говорил именно о мощи таких средств. И после того, как пробуешь их, использование HTML кажется несколько чрезмерно трудозатратным.

                                                                В общем, нюансов еще много и можно спорить очень долго на эту тему. HTML (с CSS и JS) сегодня само собой имеет полное право на жизнь в мире RIA-интерфейсов, ну а там уж посмотрим что будет дальше.
                                                                  +1
                                                                  Знаете, даже в тех случаях, когда 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-интерфейсы обладают такими общими гипертекстовыми фичами, как возможность (в теории) уникально идентифицировать и сослаться на любой элемент в интерфейсе и др.

                                                                   
                                                                  Вот так, несколько сумбурно и отрывочно, я попытался описать некоторые свои представления о красоте и гибкости классических клиентских технологий. Надеюсь, Вы меня поняли… Постараюсь четко и подробно описать сформулировать эти мысли в статье.
                                                              +12
                                                              дочитал до шедевральной строчки

                                                              «В ASP.NET работа идет с высокоуровневым Windows API и серверными контролами (меню, вкладками, деревьями), которые затем компилируется в HTML, CSS и JavaScript, так же как программа на C++ компилируется в ассемблер.»

                                                              и бросил.
                                                              Автор в плане ASP.NET вы написали откровенный бред, который нисколько не соответствует действительности.

                                                              Кроме того, ваши тезисы про «уродский ассемблерный код» так же считаю несостоятельными. Уверен, что вы сами пишите на ассемблере не лучше компилятора Intel C++.

                                                              Читать далее нет никакого желания. Почему-то кажется, что остальное написано настолько же «компетентно».
                                                                +3
                                                                Тоже считаю, что по поводу ASP.NET автор перегнул палку, возможно и есть люди, которые тупо перетаскивают контролы на страничку и задают пару свойств, но назвать их программистами нельзя. Нормальные же программисты на ASP.NET пишут классные сайты и нисколько об этом не жалеют.
                                                                  –1
                                                                  В ASP.NET работа идет с высокоуровневым Windows API и серверными контролами (меню, вкладками, деревьями), которые затем компилируется в HTML, CSS и JavaScript, так же как программа на C++ компилируется в ассемблер.
                                                                  Чем Вас не устраивает это сравнение? Действительно, на «высокоуровневой» страница, описанная с помощью ASP.Net контролов затем автоматически «компилируется» в результирующий xHTML/CSS/JS — код, со в всеми вытекающими после автоматической генерации кода последствиями.

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

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

                                                                    какой Windows API? «работа идет» с clr, которая платформонезависимая
                                                                    на asp.net вам никто не мешает писать чистый html, контролы никто не компилирует, тем более нет никакой «компиляции в HTML, CSS и JavaScript»… про mvc framework в котором вообще нет серверных контролов вы видимо не знаете вовсе,
                                                                    про последствия «компиляции» я вообще промолчу…

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

                                                                    я не могу сказать что было «несколько десятков лет назад», но лично мне не знакомы примеры того, когда компилятор C генерировал «уродливый код», возможно такое было 30 лет назад во время i8086, не знаю, вам наверное такие факты известны — поделитесь
                                                                      0
                                                                      отличный оптимизированный код, который в большинстве случаев будет лучше того, что напишет средней руки программист.
                                                                      Когда я смотрю на 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. Но, согласен, сформулировано некорректно. Убрал, пока не переформулирую.
                                                                        0
                                                                        Кстати, вообще-то контролы компилируются и автор в этом прав.
                                                                        Как минимум, нужно скомпилировать код классов, содержащийся в code-behind-файлах страниц и сами вставки кода на страничке. То же самое касается ASP.NET MVC — странички не работают просто так, сами по себе — если они являются объектами класса, который не определен в сборках — будет ошибка.

                                                                        P.S. Я сейчас говорю НЕ про превращение декларативно созданных контролов в JS, CSS и HTML, а именно компиляцию кода (например C#) в VS200x или при первом попадании странички в ASP.NET Runtime.
                                                                          0
                                                                          да кто бы спорил, что code-behind компилируется в сборки, в этом суть asp.net
                                                                          только автор то не о том пишет
                                                                            0
                                                                            Ну насчет того, что превращение декларативных ASP.NET-контролов в HTML, JS, CSS нельзя называть компиляцией — в этом я полностью согласен. Скорее, некоторая трансформация (как XSLT, к примеру, не называется же компиляцией из XML в HTML или другой XML).
                                                                              0
                                                                              Ну почему?

                                                                              Конечно, компиляция в узком смысле — генерация машинного кода на основе исходника.

                                                                              Но «компилияция» в широком смысле — генерация низкоуровневого кода на основе кода высокоуровневого.

                                                                              И такое сравнение я считаю вполне уместным: высокоуровневые ASP.NET контролы генерируют («компилируются» в) низкоуровневый HTML-код, подобно тому, как высокоуровневая программа на C++ компилируется в низкоуровневый машинный код.
                                                                        0
                                                                        >Просто сейчас, благодаря, более мощному железу, мы, слава богу, можем себе компилируемые программы

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

                                                                        Да что уж говорить, сейчас даже видеокарты программируются для любых задач. Библиотеки тоже не стоят на месте, ведь ещё десять лет назад всё было иначе и выбора-то особого не было, но не сейчас. Но это всё разговор про компиляцию в машинный код (не в ассемблер :) ), а не в промежуточный язык (MSIL), как у всех дотнетовских технологий.
                                                                          0
                                                                          Дело не только в железе, но и в компиляторах, те же C++ компиляторы эволюционировали очень сильно. Они выжимают и из нового и из старого железа намного больше, чем раньше.
                                                                          Действительно, скорость выполнения программ возросла не только из-за увеличения мощности железа, но и благодаря повышению эффективности компиляторов.

                                                                          Но, все-же, согласитесь: подавляющую роль в этом играет именно железо — ведь его мощность растет экспоненциально (Закон Мура), а эффективность компиляторов не могла вырости в 10 000 раз за 20 лет…
                                                                            0
                                                                            >Но, все-же, согласитесь: подавляющую роль в этом играет именно железо

                                                                            Ну да, мысль просто была, что чтобы выжать из железа максимум нужны компиляторы учитывающие это железо, навроде применения новых инструкций MMX/SSE/SSE2/SSE3, иначе будет учитываться только возросшая частота ядер.

                                                                            И то что делая новые компиляторы разработчики устранили многие глюки и теперь даже для старых машин у которых не было этих инструкций, вновь откомпилированный код более эффективен тоже верно.
                                                                              0
                                                                              Ну, да: скорость программ растет за счет роста производительности железа, а современные компиляторы умеют использовать это железо по-максмуму.
                                                                        0
                                                                        Насчет Intel C++ можно немножко поподробнее — не хотите ли вы сказать что icc «плохо пишет на ассемблере»? По сравнению с чем?
                                                                          0
                                                                          наоборот, я хочу сказать, что не каждый программист напишет так же хорошо, как Intel C++ скомпилирует код
                                                                          о чем, в общем-то, я и написал чуть ниже
                                                                        0
                                                                        Я не думаю, что xHTML может не угнаться за ходом технологий. Это ведь частный случай XML, а значит в любой момент можно добавить элементы разметки для медиа-контента, розширить инструментарий для структурирования данных и т.д. Кроме этого xHTML (равно как и CSS вместе с ним) не предназначен для задач иных кроме разметки. Он используются только для управления размещением элементов (несколько утрированно, но это по сути так) на экране пользователя, а значит не должен страдать из-за отсутствия возможности, например, генерировать 3D-объекты в нем. Это на мой взгляд.
                                                                          0
                                                                          Я не думаю, что xHTML может не угнаться за ходом технологий. Это ведь частный случай XML, а значит в любой момент можно добавить элементы разметки для медиа-контента, розширить инструментарий для структурирования данных и т.д.
                                                                          Конечно, xHTML — это подмножество XML и чисто теоретически ничего не стоит добавить в него новый элемент (для контрола, медиаконтента и т.д.)

                                                                          Но:

                                                                          — Кто придумает этот элемент?

                                                                          — Кто заставит производителей браузеров (особенно самого распространенного) поддерживать этот элемент?

                                                                          В этом и вся проблема :-)
                                                                            0
                                                                            Думаю W3C и заставит и придумает. Как Это уже делается в HTML 5. Потребность в этом уже назрела и долго ждать не придется, я думаю.
                                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                                            0
                                                                            Интерфейсы развиваются по большей части косметически.

                                                                            Не согласен, такие сервисы как GMail, Google Map, on-line текстовые редакторы и т.д. произвели революцию именно из-за клиентского интерфейса!
                                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                                                0
                                                                                Но, все же, согласитесь — развитие интерфейса является важнейшей частью развития web-приложений.

                                                                                И технология AJAX, совершившая революцию в Вебе, ставшая технологической основой Web 2.0, была именно клиентской технологией.

                                                                                Картографические и почтовые сервисы были задолго до появления Gmail и GMap.

                                                                                Но Gmail и GMap произвели революцию, во многом, именно благодаря AJAX: возможность прямо в браузере колесиком мышки плавно увеличить карту с космического масштаба до масштаба отдельного дома, перетаскивание писем методом Drag&Drop, автосохранение, горячие клавиши и другие возможности, до того присутствовавшие только в десктопных приложениях.
                                                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                                                    0
                                                                                    Ну да:

                                                                                    user-generated content был одной из социальных составляющих революции Web 2.0,

                                                                                    — а AJAX — одной их технических.

                                                                                    Все сходится :-)
                                                                            0
                                                                            Линка «возобновила работу над HTML»
                                                                              +1
                                                                              …в смысле, выглядит битой )
                                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                                                  +3
                                                                                  +1, Прямое сравнение програмистской лени и замечательной технологии ASP.NET это несколько не правильно. Любая технология в умелых руках деоает чудеса, и ASP.NET в данном слечае просто отличный инструмент. Да конечно набор стандартных контролов выдаёт несколько устаревший html.
                                                                                  +1
                                                                                  Учитывая, что ASP.NET не ограничен набором контролов, а позволяет выдавать любое содержимое, будь то HTML или Flash, вопрос как бы риторический.

                                                                                  А вот при использовании шаблонов aspx ограничения уже появляются. Например, единственный тег <form> на странице.
                                                                                  И стандартные контролы зачастую выдают не вполне логичный код. Если пользоваться только стандартными средствами ASP.NET, то и фиг бы с ним, но когда пишешь свой JavaScript, неудобно добираться до нужного элемента.
                                                                                  • НЛО прилетело и опубликовало эту надпись здесь
                                                                                      0
                                                                                      Да, надо попробовать. Традиционное ASP.NET меня сильно раздражает — впечатление такое, что старались переманить разработчиков GUI-приложений, делая вид, что веб ничем не отличается. Получилось что-то не совсем вебовое, и не совсем десктопное.

                                                                                      Но сейчас я больше пишу десктопные приложения, вот появятся интернет-проекты, тогда пощупаю MVC.
                                                                                        +2
                                                                                        Традиционное ASP.NET меня сильно раздражает — впечатление такое, что старались переманить разработчиков GUI-приложений, делая вид, что веб ничем не отличается.
                                                                                        Полностью согласен.

                                                                                        Сама по себе ASP.NET и .Net вообще — очень мощная технология.

                                                                                        Но попытка применить к web десктопную windows-овскую GUI парадигму с помощью ASP.NET контролов — это выглядит ужасно!

                                                                                        Поэтому, ASP.NET MVC Framework — это большой шаг вперед!

                                                                                        Но, знаете, я очень не уверен, что все ASP.NET разработчики перейдут на MVC. Ведь модель ASP.NET контролов настолько является настолько родной, привычной и понятной для тех, кто привык к Visual Basic / Delphi парадигме: кинул контрол на форму → щелкнул два раза мышкой → написал обработчик и все дела…
                                                                                      0
                                                                                      «когда пишешь свой JavaScript, неудобно добираться до нужного элемента. „

                                                                                      вас спасет asp.net 4.0, в котором появилось 3 способа генерации id в том числе и без автогенерации
                                                                                      уже сейчас все это есть и работает, можно скачать и пробовать, тестировать :)
                                                                                        0
                                                                                        Вот счастье-то привалило! Серьезно, хитроумные id сильно мешали. Как в CSS стиль к id привязать, если сам его не знаешь? А ведь как-то привязывал… вспомнить бы.
                                                                                          0
                                                                                          да
                                                                                          честно говоря, лично мне счастье привалило с выходом MVC Framework, у в котором ни проблемы генерации id ни viewstate нет, как нет контролов их коллекции на странице и страшного существа под названием Page Lifecycle
                                                                                    +4
                                                                                    Но, в xHTML нет столь нужных для современных web-приложений тегов, таких как вкладки, меню, деревья, календари и т.д.

                                                                                    Ну, да. Ясно. Т.е. вы совсем не различаете оформление контролов и мета-язык разметки информации.

                                                                                    На всякий случай: деревья — это вложенные списки, а календари — таблицы. Меню есть в HTML 5, а вкладки… это по сути <menu> + <section>, тоже из HTML 5
                                                                                      +3
                                                                                      На всякий случай: деревья — это вложенные списки, а календари — таблицы.

                                                                                      Да, именно это и показывается в статье.

                                                                                      Вы привели пример «высокоуровневого xHTML».

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

                                                                                      Разумеется, вместо этой мешанины тегов им проще работать с серверным контролом «дерево». Не понимая, что при высокоуровневыом семантическом xHTML эта мешанина тегов просто не нужна…
                                                                                        +3
                                                                                        Тогда я отказываюсь понимать пафос вашей публикации о_0
                                                                                          +2
                                                                                          Возможно, я недостаточно понятно сформулировал свою мысль в предыдущем комментарии.

                                                                                          Вот, в кратце, смысл этой части статьи:

                                                                                          Ассемблер был объективно низкоуровневым языком, поэтому, совершенно справедливо, был заменен высокоуровневыми языками.

                                                                                          xHTML/CSS/JS лишь воспринимается многими разработчиками как низкоуровневый из-за неправильного понимания.

                                                                                          Например, воспринимают «дерево» как мешанину низкоуровневых тегов: сложных вложенных таблиц, тегов <font>, 1-пиксельных картинок и т. д.

                                                                                          При таком «низкоуровневом» подходе к xHTML/JScript, работать с ними не удобно, как и не удобно работать с любым низкоуровневым языком.

                                                                                          И поэтому, разработчики выбирают "псевдовысокоуровневые" серверные ASP.Net-контролы.

                                                                                          Но, на самом деле, xHTML/JS — это высокоуровневые технологии. Надо только правильно понимать их.

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

                                                                                          И тогда, при правильном использовании xHTML/JS псевдовысокоуровневые надстройки становятся не нужны.

                                                                                          Другой пример: JS — это не кривое классовое ООП, а прототипное ОПП. И поэтому, если понимать прототипное ОПП, псевдовысокоуровневые надстройки вроде Script# опять-же становятся не нужными.

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

                                                                                            С этими полужирностями действительно всё выглядит вполне логично.
                                                                                              0
                                                                                              Пожалуйста, не пишите, что разработчики выбирают ASP.NET из-за " «псевдовысокоуровневые» серверные ASP.Net-контролы.". Разработчики выбирают ASP.NET совсем не из-за этого и если вы этого не понимаете, то уж лучше не писать такого.
                                                                                                +1
                                                                                                Пожалуйста, не пишите, что разработчики выбирают ASP.NET из-за " «псевдовысокоуровневые» серверные ASP.Net-контролы."

                                                                                                См. 3-ю сноску.

                                                                                                Я не утверждаю, что все разработчики используют ASP.NET только из-за серверных контролов.

                                                                                                Но, я говорю, что есть разработчики, которые не хотят осваивать web-парадигму, и, поэтому, выбирают привычную им с со времен Delphi и Visual Basic модель серверных контролов…
                                                                                        –3
                                                                                        JavaScript убивает уродская реализация массивов. Неделю назад реализация «очереди объектов» из которой можно произвольно их вытаскивать заняла у меня часа три, не меньше — хотя то же самое с php-массивом, который имеет «внутренний порядок» элементов делается за 5 минут элементарно. И даже jQuery мне ничем не помог.
                                                                                          0
                                                                                          JavaScript убивает уродская реализация массивов.

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

                                                                                           
                                                                                          Неделю назад реализация «очереди объектов»

                                                                                          Для работы с очередями в JS есть два метода:

                                                                                          array.unshift (element)добавляет в очередь array элемент element.

                                                                                          var element = array.shift ()извлекает из очереди array элемент и присваивает его переменной element.

                                                                                           
                                                                                          И даже jQuery мне ничем не помог.

                                                                                          jQuery тут совсем не причем. Его главная задача — не работа с JavaScript core (в том числе массивами), а упрощение работы с DOM.
                                                                                            –1
                                                                                            Рассказать, как выглядело решение?

                                                                                            1) Понадобился массив A, хранящий id объектов и порядок их добавления.
                                                                                            2) Понадобился объект B, с индексами {id_объекта}, чтобы можно было хоть как-то находить объекты по их ID.

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

                                                                                            a = []
                                                                                            a[2008] = 123
                                                                                            alert(a.length) //O, RLY?

                                                                                            Реализация массивов в JavaScript отвратительна для языка такого уровня.
                                                                                              0
                                                                                              возможно вам нужен был хеш, а не массив?
                                                                                                0
                                                                                                a.shift() для хеша оказался undefined function
                                                                                                0
                                                                                                Возможно, Вы не корректно сформулировали проблему.

                                                                                                Очередь — эта такая структура, элементы которой добавляются в конец и извлекаются из начала.

                                                                                                Ни какого «вытягивания элементов из середины очереди» быть не может! Во всяком случае, это уже будет не очередь…
                                                                                                  0
                                                                                                  Давайте вы не будете цепляться к словам, а предложите мне нормальное решение этой задачи.

                                                                                                  Например, на php это бы выглядело так:

                                                                                                  $queue = array();
                                                                                                  $queue[$it->id] = $it; //Добавление элемента
                                                                                                  shift($queue); //Сдвиг первого элемента из очереди
                                                                                                  unset($queue[$it->id]); //Удаление элемента по id

                                                                                                  Других функций мне не надо. Всего четыре строчки. Сделайте то же самое на javascript, где, как вы выражаетесь одна из мощнейших реализаций массивов. Пусть же эта мощщ проявит себя уже наконец.
                                                                                                    0
                                                                                                    slice/splice?
                                                                                                      0
                                                                                                      Приведите пожалуйста рабочий пример аналогичный моему.
                                                                                                        0
                                                                                                        Судя по вашему примеру, массив вам не подходит — в js массив не может быть разреженным, насколько я понимаю. А у хеша меньше возможностей :(
                                                                                                        Самым простым, имхо, будет эмулировать хеш — отдельный массив ключей и отдельный массив значений. Сделать для этого обёртку…
                                                                                                          0
                                                                                                          habrahabr.ru/blogs/webdev/45552/#comment_1153274 ну я так и сделал, но по-моему для такой простой задачи решение просто уродское. Тем более, что как язык javascript мне нравится больше чем php, а такие вот мелочи его просто портят.
                                                                                                            0
                                                                                                            А, я ответил на вторую часть этого комментария — привел функции для подобной работы с массивом.
                                                                                                            Да, обидно конечно.
                                                                                                    0
                                                                                                    Алсо, в первом посте очередь была взята в кавычки и написано было «из которой можно произвольно их вытаскивать». Слово «произвольно» в переводе с русского на русский означает «как угодно».
                                                                                              0
                                                                                              Средствами чистого xHTML/CSS/JS нельзя создать 3D графику, векторную анимацию, управлять звуком, хранить большие объемы данных на стороне клиента…

                                                                                              CSS Transforms 3D
                                                                                              SVG Animation
                                                                                              — <audio> и <video>, из HTML 5, управление воспроизведением через JS/DOM
                                                                                              — SQLite в HTML5, WebKit Does HTML5 Client-side Database Storage

                                                                                              …короче, не публикация, а чистой воды дилетантизм.
                                                                                                +3
                                                                                                Средствами чистого xHTML/CSS/JS нельзя создать 3D графику, векторную анимацию, управлять звуком, хранить большие объемы данных на стороне клиента…

                                                                                                Вадим, статья действительно большая, но прочитайте, пожалуйста до конца…

                                                                                                Данные ограничения действительно присутствуют на данный момент при реализации web-технологий основными браузерами.

                                                                                                И именно WHATWG и HTML5 я привел как то, что поможет web-технологиям продолжить развитие, преодолеть ограничения и избежать гибели, на подобии псевдографического интерфейса Turbo Pascal.

                                                                                                  –4
                                                                                                  storage к примеру так же будут в ie8

                                                                                                  "…короче, не публикация, а чистой воды дилетантизм"

                                                                                                  согласный, а пипл ведь хавает
                                                                                                    0
                                                                                                    Так ведь, кроме SVG, все это еще не принятые стандарты, разве не так?
                                                                                                    И даже SVG, сколько уж ему лет, никак не догонит Flash.
                                                                                                      0
                                                                                                      SVG не может догнать Flash по одной простой причине: нет поддержки в одном известном браузере.
                                                                                                        0
                                                                                                        вы про анимацию? статические SVG Mozilla вполне себе показывает.

                                                                                                        и откуда такая несправедливость? вроде, стандарт вполне логичный и на вид не шибко напряжный в реализации…
                                                                                                    0
                                                                                                    И поэтому, разработчикам приходится вручную описывать эти вкладки, меню и деревья с помощью мешанины низкоуровневых xHTML тегов: таблиц со сложными объединенными ячейками, внутри которых вложенные таблицы с большим количеством тегов и декоративных картинок для обрисовки веток.
                                                                                                    Слёзы на глаза наворачиваются) Особенно учитывая что фонт не используют и таблицами не верстают
                                                                                                    Непонятно, о чем статья. Не вижу трагедии в том, что html — язык разметки, он им ведь и создавался. Что предлагает автор для предотвращения ужасного апокалипсиса делать конкретно мне? Конкретно веб-разработчику?
                                                                                                      0
                                                                                                      Не справилась с управлением) (с)
                                                                                                        –1
                                                                                                        Краткий пересказ основной части статьи — в этом комментарии.

                                                                                                        Насчет тега <font>в этом.

                                                                                                        Что предлагает автор для предотвращения ужасного апокалипсиса делать конкретно мне? Конкретно веб-разработчику?
                                                                                                        Я пытаюсь показать необычайную мощь стандартных xHTM/CSS/JS как средства построения интерфейса при правильном их понимании и использовании.
                                                                                                          0
                                                                                                          Все и так пользуются ими на полную мощь. Дело в том, что после прочтения вашей статьи возникает куча противоречий. Мешанина примеров в конце показывает, что вы недооцениваете кодеров. Устаревшие методы не используются. Для кого стандарты писаны? Книги? Читают да верстают, какие проблемы. Большинство сайтов же не на асп. А при подходе — вижу много тегов и пугаюсь человека сложно назвать программистом. Вы ж не о новичках писали, а о развитии веба в целом. Хоть убейте, не вижу новых или хотя бы чётких мыслей в статье
                                                                                                            +3
                                                                                                            Суть в чём. ХТМЛ под угрозой, но его спасает WHATWG. Всё)
                                                                                                        +4
                                                                                                        Вот буквально недавно (в комментариях к статье в одном блоге) затрагивал тему усиления абстракций + еще один комментарий туда же.

                                                                                                        Можно полностью почитать те мои комментарии; а здесь я скажу основную суть, как я вижу линейный ход усиления абстракций:

                                                                                                        В этой мешанине наиболее ключевыми фигурами являются идеологи-созидатели и прикладные созидатели (возможно — потребители продуктов идеологов)

                                                                                                        — выделяется физическая сущность (не абстрактная), например — программирование «проводками»;

                                                                                                        — идеологи создают абстракцию (bin- и hex- коды) и уже управляют переключением проводов сигналами кодов — 0 и 1;

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

                                                                                                        — идеологи продвигаются дальше (в виду различных причин), создавая все более абстрактные сущности — так появляются ассемблеры, которые являются очень мощной абстракцией, относительно программирования hex-кодами;

                                                                                                        — и снова подключаются прикладные потребители, называя «уродливыми» hex- и bin- коды и холиворят на «форумах», отстаивая идеи продукта (при этом не являясь создателями); так же выделяются новые идеологи, которые уже на ассемблере пишут абстракции вроде Си, Паскаль, др.

                                                                                                        — … и т.д. (от уровня ассемблера развитие абстракций можно найти в статье)

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

                                                                                                          0
                                                                                                          Спасибо. Да, я читал эту статью и ваши комментарии к ней. (Кстати, ссылка на «Стандарты кодирования для (X)HTML, CSS и JavaScript’a» есть на Хабре)

                                                                                                          Я полностью с Вами согласен. Усиление уровня абстракции — фундаментальный процесс.

                                                                                                          Да, он сопровождается потерей производительности. Но зато он увеличивает скорость и качество разработки; увеличение мощности железа нивелирует потери в производительности.

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

                                                                                                          Поэтому, процесс усиления абстракции необратим.

                                                                                                          НО! В этой статье я хотел показать следующее:

                                                                                                          Ассемблер объективно был низкоуровневым языком, поэтому его замена языками высокого уровня была правильной и неизбежной.

                                                                                                          Однако, xHTML/CSS/JS на самом деле являются высокоуровневыми языками построения интерфейсов; и лишь воспринимаются разработчиками как низкоуровневые.

                                                                                                          Поэтому, их замена «псевдовысокоуровневыми» серверными контролами не является обязательной, и ее можно (и нужно) избежать.
                                                                                                            0
                                                                                                            В двух словах:

                                                                                                            Переход «Ассемблер → C» — это переход на новый уровень абстракции.

                                                                                                            Переход «xHTML/CSS/JS → серверный контрол» — это не переход на новый уровень, а замена парадигмы web на десктопную Delphi / Visual Basic парадигму.
                                                                                                              0
                                                                                                              А вот тут, как говорится, «собака и порылась».

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

                                                                                                              Но… может так и нужно? Ведь для сложных приложений, которые будут удобны пользователю, нужен тот самый «утолщенный» функционал.

                                                                                                              Что касается ASP.NET, то это как раз-таки абстракция (использование состояний там, где они вообще не должны быть), только, совершенно верно, не новый ее уровень. Понимая это, MS и выводит на рынок RIA-приложений технологию Silverlight, которая (или аналоги которой) в некоем будущем заменят ASP.NET WebForms.
                                                                                                          0
                                                                                                          я не стал зацикливаться на ASP.NET весь есть еще JAVA и JSF… хотя принцип примерно один и тотже…
                                                                                                            +1
                                                                                                            «Обычно программы компилируются не в ассемблерный код, а сразу в машинный. Но, для удобства, в пределах этой статьи будем считать, что это одно и то же.»

                                                                                                            напомнило

                                                                                                            «Для удобства расчетов примем пи равным 4»
                                                                                                              +1
                                                                                                              для удобства этой статьи ассемблер в ней лучше вообще не трогать и не упоминать.
                                                                                                                0
                                                                                                                особенно учитывая галимый бред про стек, умножение и вызовы (-:
                                                                                                                  0
                                                                                                                  Который, к тому же, повторён в течении статьи несколько раз)