[JavaScript] Формирование DOM-а в броузере - Языки с динамической типизацией

Всем привет!

У меня возник один, на первый взгляд, странный вопрос.

Я пишу макрос (метапрограмму) который по коду на статически типизированном языке (Nemerle) генерирует клиентский JavaScript для Web-страниц. В том числе этот генератор должен формировать скрипты клиентских шаблонов. Шаблон — это генератор HTML. К шаблону можно будет производить декларативную привязку ViewModel (используется шаблон проектирования MVVM).

Так вот в коде Nemerle шаблон представлен в виде AST который формирует XML в формате XLinq (XElement(...)). Другими словами имеется уже разобранный HTML, а не просто текст.

Вопрос заключается в том можно ли генерировать JavaScript который будет работать не с текстом, а напрямую с DOM-ом HTML-я? Не приведет ли это к тормозам или очень большому объему скриптов (ведь их придется слать на клиента)?

Если вопрос производительности не критичен, то второй вопрос. Какими методами лучше всего формировать DOM? Пока что я склоняюсь к использованию JQuery.

VD>Всем привет!

VD>У меня возник один, на первый взгляд, странный вопрос.

VD>Я пишу макрос (метапрограмму) который по коду на статически типизированном языке (Nemerle) генерирует клиентский JavaScript для Web-страниц. В том числе этот генератор должен формировать скрипты клиентских шаблонов. Шаблон — это генератор HTML. К шаблону можно будет производить декларативную привязку ViewModel (используется шаблон проектирования MVVM).

VD>Так вот в коде Nemerle шаблон представлен в виде AST который формирует XML в формате XLinq (XElement(...)). Другими словами имеется уже разобранный HTML, а не просто текст.

VD>Вопрос заключается в том можно ли генерировать JavaScript который будет работать не с текстом, а напрямую с DOM-ом HTML-я? Не приведет ли это к тормозам или очень большому объему скриптов (ведь их придется слать на клиента)?

VD>Если вопрос производительности не критичен, то второй вопрос. Какими методами лучше всего формировать DOM? Пока что я склоняюсь к использованию JQuery.

Манипуляции с DOM медленные, особенно удаление поддеревьев. Создавать лучше всего так:

e = document.createElement('div');
e.innerHTML = "что отрендерил шаблон";

Ну или e = $("что отрендерил шаблон")[0], если очень хочется впихнуть jQuery.

Работает везде, но в IE, конечно, с оговорками: http://www.ericvasilik.com/2006/07/code-karma.html

Здравствуйте, VladD2, Вы писали:

VD>Если вопрос производительности не критичен, то второй вопрос. Какими методами лучше всего формировать DOM? Пока что я склоняюсь к использованию JQuery.

Насколько я понимаю, рекомендуемое авторами jQuery — jQuery.tmpl

Здравствуйте, Temoto, Вы писали:

T>Манипуляции с DOM медленные, особенно удаление поддеревьев.

Шаблон должен только рендерить некую часть ХТМЛ-я и заменять ее то что было до этого.

Вот примеры того что требуется реализовать:
http://knockoutjs.com/examples/templating.html
http://knockoutjs.com/examples/cartEditor.html

T>Создавать лучше всего так:

T>e = document.createElement('div');
T>e.innerHTML = "что отрендерил шаблон";

То есть тупо формировать код который сначала создаст строку, а потом скормит ее броузеру?

А со строками жабаскрипт шустро работает?

T>>Манипуляции с DOM медленные, особенно удаление поддеревьев.

VD>Шаблон должен только рендерить некую часть ХТМЛ-я и заменять ее то что было до этого.

VD>Вот примеры того что требуется реализовать:
VD>http://knockoutjs.com/examples/templating.html
VD>http://knockoutjs.com/examples/cartEditor.html

T>>Создавать лучше всего так:

T>>e = document.createElement('div');
T>>e.innerHTML = "что отрендерил шаблон";

VD>То есть тупо формировать код который сначала создаст строку, а потом скормит ее броузеру?

Да. Жаваскриптер Алексей подсказывает, что только V8 и какая-то опера делают createElement незначительно быстрее, чем innerHTML. Поэтому innerHTML выбирается как "неплохое на современных браузерах и лучшее на старых".

Вот ещё ссылка по теме: http://gaperton.livejournal.com/55094.html

VD>А со строками жабаскрипт шустро работает?

Ну, как обычно, + медленнее, чем join.

Здравствуйте, Курилка, Вы писали:

VD>>Если вопрос производительности не критичен, то второй вопрос. Какими методами лучше всего формировать DOM? Пока что я склоняюсь к использованию JQuery.

К>Насколько я понимаю, рекомендуемое авторами jQuery — jQuery.tmpl

Его же использует и кнокаут. Вопрос, насколько он шустрый. По моим ощущениям — не очень.

Здравствуйте, Temoto, Вы писали:

T>Ну, как обычно, + медленнее, чем join.

А полноценного StringBuilder/StringBufer я так понимаю не?

А массивы в ЖС шустро работают? Можно промежуточные результаты в них складывать, а потом join использовать?

Здравствуйте, VladD2, Вы писали:

T>>e = document.createElement('div');
T>>e.innerHTML = "что отрендерил шаблон";
VD>То есть тупо формировать код который сначала создаст строку, а потом скормит ее броузеру?

Если вы завяжетесь на innerHTML, то на вашем фреймворке никогда не удастся создать XML-документ (XHTML и прочее).

Здравствуйте, VladD2, Вы писали:

VD>Вопрос заключается в том можно ли генерировать JavaScript который будет работать не с текстом, а напрямую с DOM-ом HTML-я? Не приведет ли это к тормозам или очень большому объему скриптов (ведь их придется слать на клиента)?

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

VD>Если вопрос производительности не критичен, то второй вопрос. Какими методами лучше всего формировать DOM? Пока что я склоняюсь к использованию JQuery.

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

T>>Ну, как обычно, + медленнее, чем join.

VD>А полноценного StringBuilder/StringBufer я так понимаю не?

VD>А массивы в ЖС шустро работают? Можно промежуточные результаты в них складывать, а потом join использовать?

Все только так и делают.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Курилка, Вы писали:

VD>>>Если вопрос производительности не критичен, то второй вопрос. Какими методами лучше всего формировать DOM? Пока что я склоняюсь к использованию JQuery.

К>>Насколько я понимаю, рекомендуемое авторами jQuery — jQuery.tmpl

VD>Его же использует и кнокаут. Вопрос, насколько он шустрый. По моим ощущениям — не очень.

Про скорость вспоминается только этот пост годишней давности

Здравствуйте, VladD2, Вы писали:

T>>Ну, как обычно, + медленнее, чем join.
VD>А полноценного StringBuilder/StringBufer я так понимаю не?
VD>А массивы в ЖС шустро работают? Можно промежуточные результаты в них складывать, а потом join использовать?

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

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Курилка, Вы писали:

VD>>>Если вопрос производительности не критичен, то второй вопрос. Какими методами лучше всего формировать DOM? Пока что я склоняюсь к использованию JQuery.

К>>Насколько я понимаю, рекомендуемое авторами jQuery — jQuery.tmpl

VD>Его же использует и кнокаут. Вопрос, насколько он шустрый. По моим ощущениям — не очень.

Я сравнивал следующие движки:

PURE
Mustache
jQuery.tmpl()
Trimpath
JavaScript Micro-Templating (это фактически client side PHP processor)
EJS (Embedded JS)

jQuery.tmpl() и JavaScript Micro-Templating должны быть самыми быстрыми — templates компилируются в JS bytecode и исполняются.

Здравствуйте, anonymous, Вы писали:

A>Если вы завяжетесь на innerHTML, то на вашем фреймворке никогда не удастся создать XML-документ (XHTML и прочее).

Это по чему это? И что "прочее"?

Здравствуйте, anonymous, Вы писали:

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

Вопрос как раз совершенно корректный и очевидный. Конечно же рассчитывать надо самый медленный из реально используемых робузеров. Так что если скажем IE 6 тормозит, то "+" лучше не использовать.

Ну, а массив + join хорош еще и тем, что в отличии от + — это динамическое решение. Скорость упрется только в скорость изменения размеров массива. "+" же будет по любому перезанимать память при каждом присвоении переменной.

Здравствуйте, anonymous, Вы писали:

A>Не сложно написать код переводящий некую структуру, описывающую разобранный HTML, в текст для последующей вставки через innerHTML или в фрагмент документа, для вставки методами DOM. Поэтому достаточно будет предавать эту структуру и код работающей с ней. Кроме того, все эти текстовые данные достаточно хорошо сжимаются при передаче.

Интересная мысль. Надо подумать над этим.

VD>>Если вопрос производительности не критичен, то второй вопрос. Какими методами лучше всего формировать DOM? Пока что я склоняюсь к использованию JQuery.

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

Основная задача вообще снять с разработчика необходимость писать ЖабаСкрипты.
Здесь можно увидеть примеры альфа-версии (прототипа) библиотеки.
Вот один из примеров:

  [Record, ViewModel]
  public class BetterListViewModel
  {
    public ItemToAdd     : string { get; set; }
    public AllItems      : VMArray[string] { get; set; }
    public SelectedItems : VMArray[string] { get; set; }

    public AddItem() : void
    {
      when (ItemToAdd != "" && AllItems.IndexOf(ItemToAdd) < 0) // Prevent blanks and duplicates
        AllItems.Add(ItemToAdd);
        
      ItemToAdd = ""; // Clear the text box
    }

    public RemoveSelected() : void
    {
      AllItems.RemoveAll(SelectedItems);
      SelectedItems = VMArray.Empty; // Clear selection
    }
  }

  public partial module Views
  {
    [View]
    public BetterListView(viewModel : BetterListViewModel) : XElement
    {
      _ = viewModel;
      xml <# 
        <div class="note" xmlns="">
          <form data-bind="submit:AddItem">
              Add item: <input type="text" data-bind='value:ItemToAdd, valueUpdate: "afterkeydown"' />
              <button type="submit" data-bind="enable: ItemToAdd().length > 0">Add</button>
          </form>
           
          <p>Your values:</p>
          <select multiple="multiple" height="5" data-bind="options:AllItems, selectedOptions:SelectedItems"> </select>
           
          <div>
              <button data-bind="click: RemoveSelected, enable: SelectedItems().length > 0">Remove</button>
              <button data-bind="click: function() { AllItems.sort() }, enable: AllItems().length > 1">Sort</button>
          </div>
        </div>
      #>
    }
  }

По модели представления (BetterListViewModel в данном случае) генерируется объект ЖабаСкрипта который автоматически оповещает всех подписчиков.

Представление генерируется на сервере, но использует клиентский биндинг. Для элементов вроде button, input и select на клиенте ничего генерировать не надо.

Шаблоны же нужны для более сложных случаев. Они так же будут описываться на статически типизированном языке. Их можно будет отрендерить на сервере (и получить ХТМЛ), или на клинте (с использованием скрипта сформированного по описанию представления в статически типизированном языке). При этом к этим шаблонам должен быть доступен биндинг. Шаблоны должны перереднедиться при изменении модели представления.

Таким образом программист не будет непосредственно работать с ЖабаСикрипотом. Он будет описывать код в статически-типизированном виде (с интеллигентом и проверками строго компилятора) и получать все скрипты в готовом виде. Так что что за сктипт генерируется и какие базовые ЖабаСкрипт-библиотеки используются зависит только от нас (меня в данном случае).

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

Здравствуйте, VladD2, Вы писали:

A>>Если вы завяжетесь на innerHTML, то на вашем фреймворке никогда не удастся создать XML-документ (XHTML и прочее).
VD>Это по чему это? И что "прочее"?

Про XHTML я ошибся, там теперь innerHTML работает, по крайней мере в Gecko. Хотя раньше не работал, потому что вставлять текст в валидный XML-документ не считалось хорошей идеей. А прочее это, к примеру, XUL. Мало ли какой язык разметки решит использовать разработчик, DOM даёт тут единый подход.

Здравствуйте, VladD2, Вы писали:

А где можно посмотреть на исходники компилятора nemerle в js?

VD>Собственно можно даже обойтись без библиотек. Но боюсь придется убить много времени на обход несовместимостей разных броузеров. По сему и думаю как упростить свою задачу.
Имхо, в голом javascript смысла нет, идеалогически было бы конечно правильно сделать обертку, но вроде никто так не делает, тот же asp.net mvc завязан на jquery, думаю jQuery.noConflict() оптимальный вариант.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

Здравствуйте, VladD2, Вы писали:

Замените уж тогда HTML на что-нибудь читабельное. Вроде HAML.

Здравствуйте, Gaperton, Вы писали:

G>Замените уж тогда HTML на что-нибудь читабельное. Вроде HAML.

DSL, конечно, можно прикрутить любой, но что-то я не вижу в HAML-е особой читаемости.
Сейчас это дело выглядит как HTML/XML с активными областями (как квази-цитата):
http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/Nemerle.Xml

using Nemerle.Collections;
using Nemerle.Xml;

using System;
using System.Console;
using System.Xml.Linq;

[assembly: DefineXmlns(ns1="some-ns")]

class TestClass
{
  public Prop1 : int { get; set; }
  public Prop2 : string { get; set; }
}

module Program
{
  Main() : void
  {
    def makeClassInfoPage(cls : Type) : void
    {
      def props  = cls.GetProperties();
      def events = cls.GetEvents();
      def title  = $"Класс <$(cls.Name)>";

      def html = xml <# 
        <html>
          <head>
            <title>$title</title>
            <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/> 
            <link rel="stylesheet" href="http://rsdn.ru/css/article.css" type="text/css" />
          </head>
          <body marginwidth="20" marginheight="20">
            <H1>$title</H1>
            
            <H2 $unless (props.IsEmpty())>Свойства</H2>
            <ol $unless (props.IsEmpty())>
              <li $foreach (p in props)>$(p.Name) : $(p.PropertyType)</li>
            </ol>
            
            <H2 $unless (events.IsEmpty())>События</H2>
            <ol $unless (events.IsEmpty())>
              <li $foreach (e in events)>$(e.Name) : $(e.EventHandlerType)</li>
            </ol>
          </body>
        </html>
   #>;
   
      def path = IO.Path.ChangeExtension(IO.Path.GetTempFileName(), "html");
      IO.File.WriteAllText(path, html.ToString());
      _ = Diagnostics.Process.Start(path);
    }
    
    makeClassInfoPage(typeof(XAttribute));
    makeClassInfoPage(typeof(TestClass));
  }
}

Если нужно сохранять markup то посмотри мой KiTE тогда: http://code.google.com/p/kite/
В частности его TDL : http://code.google.com/p/kite/wiki/TemplateDefintionLanguage
Ну или {{mustache}}.

Здравствуйте, c-smile, Вы писали:

CS>Если нужно сохранять markup то посмотри мой KiTE тогда: http://code.google.com/p/kite/
CS>В частности его TDL : http://code.google.com/p/kite/wiki/TemplateDefintionLanguage
CS>Ну или {{mustache}}.

А чем это лучше чем шаблоны jQuery?

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, c-smile, Вы писали:

CS>>Если нужно сохранять markup то посмотри мой KiTE тогда: http://code.google.com/p/kite/
CS>>В частности его TDL : http://code.google.com/p/kite/wiki/TemplateDefintionLanguage
CS>>Ну или {{mustache}}.

VD>А чем это лучше чем шаблоны jQuery?

Основные критерии template definition languages:
1) Компактность и "неинтрузивность" синтаксиса. Чем компактнй — тем лучше — легче понимать. Maintenance лучше одним словом.
2) Скорость исполнения.

В принципе оба TDL позволяют делать примерно одно и то же но {{mustache}}/KiTE синтаксис более компактный.
Скорость исполнения в случае {{mustache}}/KiTE теоретически (и практически в случае KiTE) выше.
jQuery.template без использования оператора with() {} не построить — а это один из основных тормозов.

Вот посмотри на тестах: http://jsperf.com/dom-vs-innerhtml-based-templating/100

Resig Micro Templating                  -   129,220
Resig Micro Templating without 'with'   - 1,589,419

Разница — на порядок.

Как собственно и разница между jQuery.template() от Microsoft и моим KiTE (больше — лучше):

KiTE              - 603,649
jQuery Templates  -  54,745

По поводу TDL:

Это вот jQuery.tmpl():

 <ul>
   {{each contacts}}
     <li><b>${$value.firstName}</b> <i>${$value.lastName}</i></li>
   {{/each}}
  </ul>

Это вот {{mustache}}/KiTE:

  <ul>
   {{#contacts}}
     <li><b>{{firstName}}</b> <i>{{lastName}}</i></li>
   {{/contacts}}
 </ul>

как-то последний мне больше нравится. Конструкции вида ${$value.lastName} достаточно сильно "шумят" синтаксически.
Дело вкуса конечно но тем не менее.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Gaperton, Вы писали:

G>>Замените уж тогда HTML на что-нибудь читабельное. Вроде HAML.

VD>DSL, конечно, можно прикрутить любой, но что-то я не вижу в HAML-е особой читаемости.

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

Здравствуйте, Аноним, Вы писали:

А>HAML позволяет избежать ошибки закрытия тега. И — благодаря двумерному синтаксису, вынуждает делать отступы. Это повышает читабельность.

Закрытие тегов у нас парсер проверяет. А вот этой самой читаемости я как-то и не вижу. Все же раз генерируется ХТМЛ, то лучше его и видеть.

Здравствуйте, c-smile, Вы писали:

CS>Основные критерии template definition languages:
CS>1) Компактность и "неинтрузивность" синтаксиса. Чем компактнй — тем лучше — легче понимать. Maintenance лучше одним словом.

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

CS>2) Скорость исполнения.

А вот скорость, конечно, важна.

CS>В принципе оба TDL позволяют делать примерно одно и то же но {{mustache}}/KiTE синтаксис более компактный.
CS>Скорость исполнения в случае {{mustache}}/KiTE теоретически (и практически в случае KiTE) выше.
CS>jQuery.template без использования оператора with() {} не построить — а это один из основных тормозов.

CS>Вот посмотри на тестах: http://jsperf.com/dom-vs-innerhtml-based-templating/100
CS>

CS>Resig Micro Templating                  -   129,220
CS>Resig Micro Templating without 'with'   - 1,589,419
CS>

CS>Разница — на порядок.

А кто такой "Resig Micro-Templating with += instead of push and join" и что это за 'with'?

CS>Как собственно и разница между jQuery.template() от Microsoft и моим KiTE (больше — лучше):
CS>

CS>KiTE              - 603,649
CS>jQuery Templates  -  54,745
CS>

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

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Аноним, Вы писали:

А>>HAML позволяет избежать ошибки закрытия тега. И — благодаря двумерному синтаксису, вынуждает делать отступы. Это повышает читабельность.

VD>Закрытие тегов у нас парсер проверяет. А вот этой самой читаемости я как-то и не вижу. Все же раз генерируется ХТМЛ, то лучше его и видеть.

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

Генерация HTML из HAML прямолинейна, и имена тегов совпадают, так что проблем тут никаких нет.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Аноним, Вы писали:

А>>HAML позволяет избежать ошибки закрытия тега. И — благодаря двумерному синтаксису, вынуждает делать отступы. Это повышает читабельность.

VD>Закрытие тегов у нас парсер проверяет. А вот этой самой читаемости я как-то и не вижу. Все же раз генерируется ХТМЛ, то лучше его и видеть.

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

Здравствуйте, VladD2, Вы писали:

VD>Мне может подойти самый невзрачный и сложный в оформлении шаблонизатор, но шустрый. По большому счету можно даже голый жабоскрипт генерировать. Лишь бы было шустро и надежно.

А собственно в чем проблема-то тогда? Генерируй js функцию. Или отдавай на клиент сгенеренный текст.

Я вообще так и не понял что ты делаешь.

Можешь внятно объяснить зачем тебе вообще шаблоны нужны на client side?
В Nemerle (server side) я еще могу понять. Но как ты это все связать хочешь с client side не ясно.

Здравствуйте, Gaperton, Вы писали:

G>А ты, Влад, совсем не изменился.

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

.

G>Вместо того, чтобы подумать, начинаешь спорить.

Тут не о чем думать. Аргумент о закрытии тегов надуман. Парсер отлично выявляет это дело.
Заявление о читаемости не более чем высказывание своих вкусов.
А вот зачем людям учить еще один язык ты как-то объяснить забыл.

Что до закрытия тегов, то в нашем случае их можно закрывать без указания имени — </>, как в VB.NET. Зато можно просто взять и скопипастить готовый кусок ХТМЛ-я.

Здравствуйте, c-smile, Вы писали:

CS>А собственно в чем проблема-то тогда? Генерируй js функцию. Или отдавай на клиент сгенеренный текст.

В выборе оптимального подхода. Чтобы и быстро было, и работы по преобразования по минимуму, и объем передаваемых данных был не очень большим.

CS>Я вообще так и не понял что ты делаешь.

CS>Можешь внятно объяснить зачем тебе вообще шаблоны нужны на client side?
CS>В Nemerle (server side) я еще могу понять. Но как ты это все связать хочешь с client side не ясно.

Я делаю прототип реактивного фрэймворка поддерживающего иделогию MVVM. Вот первые примеры применения:
HelloWorld.n ClickCounter.n
BetterList.n
ControlTypes.n

Общая идея такая. ViewModel и View описывается на сильно усеченном Nemerle. Например, вот как выглядит код ViewModel для редактируемого списка:

Скрытый текст

  [Record, ViewModel]
  public class BetterListViewModel
  {
    public ItemToAdd     : string { get; set; }
    public AllItems      : VMArray[string] { get; set; }
    public SelectedItems : VMArray[string] { get; set; }

    public AddItem() : void
    {
      when (ItemToAdd != "" && AllItems.IndexOf(ItemToAdd) < 0) // Prevent blanks and duplicates
        AllItems.Add(ItemToAdd);
        
      ItemToAdd = ""; // Clear the text box
    }

    public RemoveSelected() : void
    {
      AllItems.RemoveAll(SelectedItems);
      SelectedItems = VMArray.Empty; // Clear selection
    }
  }

  public partial module Views
  {
    [View()]
    public BetterListView(viewModel : BetterListViewModel) : XElement
    {
      _ = viewModel;
      xml <# 
        <div class="note" xmlns="">
          <form data-bind="submit:AddItem">
              Add item: <input type="text" data-bind='value:ItemToAdd, valueUpdate: "afterkeydown"' />
              <button type="submit" data-bind="enable: ItemToAdd().length > 0">Add</button>
          </form>
           
          <p>Your values:</p>
          <select multiple="multiple" height="5" data-bind="options:AllItems, selectedOptions:SelectedItems"> </select>
           
          <div>
              <button data-bind="click: RemoveSelected, enable: SelectedItems().length > 0">Remove</button>
              <button data-bind="click: function() { AllItems.sort() }, enable: AllItems().length > 1">Sort</button>
          </div>
        </div>
      #>
    }
  }

И модель представления, и представления компилируются (а значит проверяются статически). В процессе компиляции генерируются методы возвращающие жабасткрипт-код и ХТМЛ. Это дело пихается в страницу и работает автономно на клиенте (в броузере).

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

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

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

Собственно для стандартных контролов все работает, что называется, из коробки. Но сам понимаешь, одними контролами интерактивный WUI не построить. Нужны чтобы представления описываемые на немерле генерировали бы некий клиентский код шаблонов. Все это дело должно поддерживать декларативный биндинг (на подобии того что я показал выше).

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

Здравствуйте, VladD2, Вы писали:

VD>Сейчас вот обдумываю как это дело лучше реализовать. Сначала думал генерировать код работающий с DOM-ом, так как на сервере ХТМЛ разбирается до АСТ. Но меня вот отговорили. Сказали что это медленно. Теперь думаю как лучше формировать код клиентского шаблона. Тупо генерировать конкатенацию строк, или генерировать код на одном из шаблонных движков.

Что-то мне гворит что "Тупо генерировать конкатенацию строк" будет мудро. Зачем тебе а) лишние зависимости и б) ограничения TE?

Здравствуйте, c-smile, Вы писали:

VD>>Сейчас вот обдумываю как это дело лучше реализовать. Сначала думал генерировать код работающий с DOM-ом, так как на сервере ХТМЛ разбирается до АСТ. Но меня вот отговорили. Сказали что это медленно. Теперь думаю как лучше формировать код клиентского шаблона. Тупо генерировать конкатенацию строк, или генерировать код на одном из шаблонных движков.

CS>Что-то мне гворит что "Тупо генерировать конкатенацию строк" будет мудро. Зачем тебе а) лишние зависимости и б) ограничения TE?

Чтобы писать меньше. Я же не коммерческий проект создаю.

В прочем, я уж и сам склонился к генерации конкатенации строк.

Здравствуйте, VladD2, Вы писали:
мыслей

.

G>>Вместо того, чтобы подумать, начинаешь спорить.

VD>Тут не о чем думать. Аргумент о закрытии тегов надуман. Парсер отлично выявляет это дело.

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

VD>Заявление о читаемости не более чем высказывание своих вкусов.

Заявление о читабельности к личным вкусам не имеет никакого отношения, оно объективно. В HAML-разметке меньше мусора, и она гарантировано правильно отформатирована.

VD>А вот зачем людям учить еще один язык ты как-то объяснить забыл.

Там нечего "учить". HAML — это не более чем двумерный синтаксис для HTML.

VD> Зато можно просто взять и скопипастить готовый кусок ХТМЛ-я.

Охрененски важный юзкейс для разработки своих сайтов

.

Здравствуйте, Gaperton, Вы писали:

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

Надуман, надуман. Если бы это было не так, то все давно бы отказались от использования Си-подобного скобочного синтаксиса.

Что до отбивки, то он пол любому нужна.

G>Заявление о читабельности к личным вкусам не имеет никакого отношения, оно объективно. В HAML-разметке меньше мусора, и она гарантировано правильно отформатирована.

А к чему имеет? Где хоть какие-то объективные показатели? То что ты называешь мусором лично я таковым не считаю.

VD>>А вот зачем людям учить еще один язык ты как-то объяснить забыл.

G>Там нечего "учить". HAML — это не более чем двумерный синтаксис для HTML.

Там есть чего учить. И потом еще придется постоянно транслировать ХТМЛ в ХАМЛ, так как народ прежде чем заложить что-то в шаблон сначала это что-то создает в коком-нить визивидж-редкаторе.

VD>> Зато можно просто взять и скопипастить готовый кусок ХТМЛ-я.

G>Охрененски важный юзкейс для разработки своих сайтов

.

Да уж удобнее чем трансляция в другой язык.

В общем, ты уж извини, но неубедительны твои речи.

Здравствуйте, VladD2, Вы писали:

VD>В общем, ты уж извини, но неубедительны твои речи.
У вас тут спор, мне нравятся апельсины, нет яблоки лучше. Если люди которые сознательно отказываются от html в пользу haml, очевидно для них он удобнее. Оптимально делать так, что бы не было жесткой завязки на xml литеры, и если кому то очень хочется haml, мог бы сделать его поддрежку с минимальными усилиями.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

Здравствуйте, dotneter, Вы писали:

D>У вас тут спор, мне нравятся апельсины, нет яблоки лучше.

Я и сказал, что речь идет о вкусах.

D>Если люди которые сознательно отказываются от html в пользу haml, очевидно для них он удобнее.

Очевидно. Как очевидно и то, что этим людям не стоит навязывать свое мнение тем, кто с ними не согласен.

Здравствуйте, VladD2, Вы писали:

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

VD>Надуман, надуман.

Не надуман, не надуман.

VD>Если бы это было не так, то все давно бы отказались от использования Си-подобного скобочного синтаксиса.

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

VD>Что до отбивки, то он пол любому нужна.

Если она "по любому" присутствует, то закрывающий тег "по любому" избыточен.

G>>Заявление о читабельности к личным вкусам не имеет никакого отношения, оно объективно. В HAML-разметке меньше мусора, и она гарантировано правильно отформатирована.

VD>А к чему имеет? Где хоть какие-то объективные показатели? То что ты называешь мусором лично я таковым не считаю.

Есть. Наличие мусора в тексте, не несущего полезной информации, затрудняет читабельность.

В современных веб страницах, где доминируют теги div, а основную смысловую нагрузку несут их свойства — class и id, мусором является не только закрывающие теги и не нужные угловые скобки, но и сам "div".

То есть, вот этот текст заполнен мусором чуть меньше, чем полностью:

<div class="comment" id="1">
  <div class="head">
  </div>
  <div class="body">
  </div>
</div>

А вот этот, эквивалентный ему — нет:

.comment#1
  .head
  .body

Разница не понятна? Тебе требуются еще какие-нибудь "объективные показатели"?

VD>>>А вот зачем людям учить еще один язык ты как-то объяснить забыл.

G>>Там нечего "учить". HAML — это не более чем двумерный синтаксис для HTML.

VD>Там есть чего учить.

Неужели? И чего же такого там надо учить-непереучить?

VD>>> Зато можно просто взять и скопипастить готовый кусок ХТМЛ-я.

G>>Охрененски важный юзкейс для разработки своих сайтов

.

VD>Да уж удобнее чем трансляция в другой язык.

Удобнее — пиши с тегами и скобками.

Здравствуйте, Gaperton, Вы писали:

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

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

VD>>Что до отбивки, то он пол любому нужна.
G>Если она "по любому" присутствует, то закрывающий тег "по любому" избыточен.

Ну, иди поспорь по этому поводу с теми кто предпочитает языки со скобками (коих большинство).
Мне этот спор не интересен.

VD>>А к чему имеет? Где хоть какие-то объективные показатели? То что ты называешь мусором лично я таковым не считаю.
G>Есть. Наличие мусора в тексте, не несущего полезной информации, затрудняет читабельность.

Пользуйся брэнфаком или J/K там удельный вес "полезной" информации выше крыши.
Но не в этой теме. Она другому посвящена. А вопрос применения разных ивзращений вроде ХАМЛов меня ни разу не интересует. Если бы интересовал, то я бы так тему и назвал.

G>То есть, вот этот текст заполнен мусором чуть меньше, чем полностью:
G>

G><div class="comment" id="1">
G>  <div class="head">
G>  </div>
G>  <div class="body">
G>  </div>
G></div>
G>

G>А вот этот, эквивалентный ему — нет:

G>

G>.comment#1
G>  .head
G>  .body
G>

G>Разница не понятна? Тебе требуются еще какие-нибудь "объективные показатели"?

Да, понятна. Сверху ХТМЛ, а снизу какой-то суржик который нужно изучить чтобы потом из него все равно получать тот же ХТМЛ. Мне еще один язык не нужен.

Рассуждать о читаемости ХТМЛ-я мне тоже не интересно. Результат нужно получить в нем, и не фига вводить какие-то промежуточные структуры. В правльно написанном коде ХТМЛ-я на одну вьюху должно быть минимальное количество. Соответственно разговаривать просто не о чем.

VD>>Там есть чего учить.

G>Неужели? И чего же такого там надо учить-непереучить?

Еще один язык, твой КО.

VD>>Да уж удобнее чем трансляция в другой язык.
G>Удобнее — пиши с тегами и скобками.

Нивапрос.

Здравствуйте, Gaperton, Вы писали:

G>Не надуман, не надуман...

Подумалось... Меня удивляет даже не том, что ты так упорно не понимаешь, что не всем нужен этот ХАМЛ.

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

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Gaperton, Вы писали:

G>>Не надуман, не надуман...

VD>Подумалось... Меня удивляет даже не том, что ты так упорно не понимаешь, что не всем нужен этот ХАМЛ.

VD>Меня больше удивляет, что ты ищешь оверхэд там где в этом нет никакого смысла. Основная сложность в современном вебе — это необходимость использования ужасного недоязыка жабаскрипа, реализация интерактива, связывание данных, реализация разного рода анимацией и прочих излишеств.
Опять же, задачи бывают разные, кому то нужно написать один сайт с интерактивом и данными и поддеживать его пару лет, а кому то нужно делать по десять визиток в месяц, и у них оставная работа с хтмл.
VD>Сами теги без проблем рисуются в визивидж-редакторах коих сегодня выше крыши.
Никто вижуал-редакторами не пользуется, если кода в haml в три раза меньше то и написание страницы будет в три раза быстрее.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

Здравствуйте, dotneter, Вы писали:

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

Зачем ты мне это рассказываешь? Расскажи это Гапертону. Он почему-то считает, что ХАМЛ хорош на все случаи жизни.

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

Советую говорить за себя, а не выражать мнение общественности.

D>если кода в haml в три раза меньше то и написание страницы будет в три раза быстрее.

Меньше буквы не значит быстрее или качественнее. Если смысл букв один и тот же то разницы не будет. К тому же не все набивают текст побуквенно.

Здравствуйте, VladD2, Вы писали:

VD>Зачем ты мне это рассказываешь? Расскажи это Гапертону.
Потому что вы не понимаете зачем ему нужен haml.

VD>Советую говорить за себя, а не выражать мнение общественности.
Это общеизвестный факт
http://stackoverflow.com/questions/406052/do-most-web-programmers-not-designers-use-wysiwyg-editors-or-hand-code-their

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

Здравствуйте, dotneter, Вы писали:

VD>>Зачем ты мне это рассказываешь? Расскажи это Гапертону.
D>Потому что вы не понимаете зачем ему нужен haml.

Мне от чистой души на плевать на его мотивы. Ну, не интересны они мне.

VD>>Советую говорить за себя, а не выражать мнение общественности.
D>Это общеизвестный факт
D>http://stackoverflow.com/questions/406052/do-most-web-programmers-not-designers-use-wysiwyg-editors-or-hand-code-their

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

Здравствуйте, VladD2, Вы писали:

VD>Мне от чистой души на плевать на его мотивы. Ну, не интересны они мне.
Это не его мотивы, а мотивы некого процента програмистов которые пытаются не тупо кодить, а использовать новые инструменты для повышения своей продуктивности, если вам на таких програмистов наплевать, незнаю насколько далеко пойдет ваш фреймворк.

VD>Даже если почитать эту тему становится видно, что по этому поводу нет единого мнения.
VD>И в любом случае не стоит вещать от лица всех. Даже одиночный пример опровергает твое заявление и выставляет тебя трепачом.
Надеюсь вы отсортировали ответы по голосам. Конечно всегда можно найти программистов которые используют WYSIWYG, но имхо подавляющему большенству их них не нужен не Nemerle, не тем более ваш фремворк, зачем же о них вспоминать?

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

Здравствуйте, VladD2, Вы писали:

D>>Это общеизвестный факт
D>>http://stackoverflow.com/questions/406052/do-most-web-programmers-not-designers-use-wysiwyg-editors-or-hand-code-their
VD>Даже если почитать эту тему становится видно, что по этому поводу нет единого мнения.
VD>И в любом случае не стоит вещать от лица всех. Даже одиночный пример опровергает твое заявление и выставляет тебя трепачом.

В веб и вправду никто (почти никто) не пользуется WYSIWYG-редакторами, по крайней мере при изготовлении профессиональной вёрстки. Если же нужно сверстать домашнюю страничку при полном незнании технологий, то да, редактор — самое то.

Здравствуйте, VladD2, Вы писали:

G>>

G>>.comment#1
G>>  .head
G>>  .body
G>>

G>>Разница не понятна? Тебе требуются еще какие-нибудь "объективные показатели"?
VD>Да, понятна. Сверху ХТМЛ, а снизу какой-то суржик который нужно изучить чтобы потом из него все равно получать тот же ХТМЛ. Мне еще один язык не нужен.

Вообще-то, этот суржик ни что иное как CSS, знание которого, если уж ты занялся разработкой для веб, обязательно.

Здравствуйте, VladD2, Вы писали:

VD>И в любом случае не стоит вещать от лица всех. Даже одиночный пример опровергает твое заявление и выставляет тебя трепачом.

А ты, Влад, совсем не изменился. Чуть что — начинаешь переходить на личности и хамить.

Здравствуйте, VladD2, Вы писали:

VD>Да, понятна. Сверху ХТМЛ, а снизу какой-то суржик который нужно изучить чтобы потом из него все равно получать тот же ХТМЛ. Мне еще один язык не нужен.

G>>Неужели? И чего же такого там надо учить-непереучить?

VD>Еще один язык, твой КО.

Насколько я припоминаю, ты тут выше по ветке jQuery применять собирался. Так вот, вопрос. Как выглядит в jQuery выборка тега ".comment#1"?

Вопрос с подвохом, ага.

Ответ — в jQuery это выглядит ни много ни мало, как $(".comment#1").

Этот незнакомый тебе "суржик" и "еще один язык" называется CSS-селекторы, и его знает каждый школьник, взявшийся изучать верстку. Скоро и ты приобщишься — деваться тебе некуда. Либо нихрена не сделаешь, либо выучишь.

Пока. Твой КО.

Здравствуйте, VladD2, Вы писали:

G>>Не надуман, не надуман...

VD>Подумалось... Меня удивляет даже не том, что ты так упорно не понимаешь, что не всем нужен этот ХАМЛ.

А меня удивляет, что ты берешь на себя смелость объяснять мне, что "всем" нужно, а что не нужно. И немного смешит, что ты при этом не знаешь, как выглядит CSS-селектор. В этом, Влад, ты весь.

Здравствуйте, VladD2, Вы писали:

VD>Основная сложность в современном вебе — это

VD>необходимость использования ужасного недоязыка жабаскрипа,

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

Необходимости, кстати, тоже нет — давно есть такие вещи, как, например, GWT. И есть разные мнения на тему, что же проще — использовать монструозные магические фреймворки с компиляцией, или же писать на простом и понятном JS с хорошим клиентским фреймворком вроде Dojo или Sencha.

VD>реализация интерактива,

В современных JS фреймворках делается прямолинейно.

VD>связывание данных,

В современных JS фреймворках делается прямолинейно.

VD>реализация разного рода анимацией и прочих излишеств.

Анимация выполняется в одну строку на jQuery, а с последним CSS делается вообще без JS. Ни малейшей сложности не представляет.

VD>Сами теги без проблем рисуются в визивидж-редакторах коих сегодня выше крыши.

Это вообще смешно. Никто визивигами не пользуется для профессиональной верстки, ибо для применения CSS необходим контроль над структурой документа. А без CSS в наши времена только совершеннейшая школота верстает.

VD>Но ты упираешься в какие-то совершенно не важный вопрос и в упор не видишь реальную сложность.

Влад, ты, похоже, живешь в каком-то своем волшебном мире, где по улицам бегают единороги, какающие бабочками. В этом мире свои сложности, мне их не понять. Засим — пока.

Здравствуйте, Gaperton, Вы писали:

VD>>Подумалось... Меня удивляет даже не том, что ты так упорно не понимаешь, что не всем нужен этот ХАМЛ.

G>А меня удивляет, что ты берешь на себя смелость объяснять мне, что "всем" нужно, а что не нужно.

Мне кажется ты что-то путаешь. Это не я тебе навязываю ХТМЛ, а ты мне ХАМЛ.

Ты лучше прочти тематическое сообщение и попробуй понять, что тема ХАМЛ-а мня попросту не интересует. У меня другие задачи.

G>И немного смешит, что ты при этом не знаешь, как выглядит CSS-селектор. В этом, Влад, ты весь.

Я осмотрю тебя так и прет наступить на старые грабли. Будь добр держать себя в рамках приличия, а то ведь снова будешь спрашивать почему на РСДН нет демократии.

Здравствуйте, Gaperton, Вы писали:

VD>>Подумалось... Меня удивляет даже не том, что ты так упорно не понимаешь, что не всем нужен этот ХАМЛ.
G>А меня удивляет, что ты берешь на себя смелость объяснять мне, что "всем" нужно, а что не нужно. И немного смешит, что ты при этом не знаешь, как выглядит CSS-селектор. В этом, Влад, ты весь.

А все-таки, зачем нужен какой-то специальный ДСЛ, целью которого является повысить читабельность, если для Влада HTML и JavaScript — это бекенд, в который он собирается компилироваться? Никто это руками править не будет да и смотреть, скорее всего, тоже.

Здравствуйте, Gaperton, Вы писали:

G>Насколько я припоминаю, ты тут выше по ветке jQuery применять собирался. Так вот, вопрос. Как выглядит в jQuery выборка тега ".comment#1"?

Я не собирался и не собираюсь применять jQuery. Речь шла исключительно о их шаблонах. О шаблонах jQuery речь зашла потому что ни используются в knockoutjs.com (см. например http://knockoutjs.com/documentation/template-binding.html). А knockout используется как базовая библиотека для того что я пытаюсь смастерить.

G>Этот незнакомый тебе "суржик" и "еще один язык" называется CSS-селекторы, и его знает каждый школьник, взявшийся изучать верстку. Скоро и ты приобщишься — деваться тебе некуда. Либо нихрена не сделаешь, либо выучишь.

Думаю ты прекрасно понял мои слова. Замена ХТМЛ-я ХАМЛ-ом — это бесполезная трата времени, сил и процессора.
Согласен ты со мной или нет мне все равно. Можешь оставаться при своем мнении. Только хамить не стоит.

Здравствуйте, Gaperton, Вы писали:

VD>>необходимость использования ужасного недоязыка жабаскрипа,
G>Нет в этой необходимости никаких сложностей. По своим свойствам JS ничем не хуже популярных динамических языков. И выполняется быстрее большинства из них.
G>Необходимости, кстати, тоже нет — давно есть такие вещи, как, например, GWT. И есть разные мнения на тему, что же проще — использовать монструозные магические фреймворки с компиляцией, или же писать на простом и понятном JS с хорошим клиентским фреймворком вроде Dojo или Sencha.

Вообще мне известны три стадии знакомства с ДжаваСкриптом:
1. Какое же это говно
2. О, а какой это на самом мощный язык!
3. Какое же это все-таки говно

Возможно, есть и следующие стадии, и что вообще вся эта цепочка зацикливается. Не знаю — я пока на третьей. При этом очевидно, что в дизайне самого языка есть явные глупости и странности, которые, под флагом backward compatibility, придется терпеть еще много лет.
Наконец те, кому нравится ДжаваСкрипт, могут просто не пользоваться таким фреймворком. Всегда есть альтернативы. Для больших любителей ДжаваСкрипта есть и вовсе node.js.

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

Вообще в ДжаваСкрипте следующая проблема. Есть довольно мощная база — в случае с JS это замыкания и P-OOP, — но нет нужных высокоуровневых средств, включая даже самые банальные. В итоге, используя эту самую базу, мы и пытаемся через ректальное отверстие имитировать то, что легко и просто достигается на других языках, потому что уже есть "из коробки".

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

В итоге идея компиляции основного языка в ДжаваСкрипт мне кажется очень даже многообещающей. Ее основная задача — даже не избавиться от "плохого" JS, а писать весь код приложения на одном языке, а следовательно, иметь возможность использовать общие подходы и паттерны, даже реюзать одни и те же функции и пр.

Здравствуйте, Воронков Василий, Вы писали:

VD>>>Подумалось... Меня удивляет даже не том, что ты так упорно не понимаешь, что не всем нужен этот ХАМЛ.
G>>А меня удивляет, что ты берешь на себя смелость объяснять мне, что "всем" нужно, а что не нужно. И немного смешит, что ты при этом не знаешь, как выглядит CSS-селектор. В этом, Влад, ты весь.

ВВ>А все-таки, зачем нужен какой-то специальный ДСЛ, целью которого является повысить читабельность, если для Влада HTML и JavaScript — это бекенд, в который он собирается компилироваться? Никто это руками править не будет да и смотреть, скорее всего, тоже.

Во-первых, HAML — это не специальный DSL, а по сути обыкновенные CSS-селекторы, которые и так все, имеющие дело с вебом, знают. Порог вхождения для человека, знающего HTML/CSS — примерно 10-15 минут, уходящие на чтение короткой доки.

Во-вторых — если он обойдется вообще без HTML, и собирается транслировать в HTML/JS определения форм — то действительно не нужен. Ну, скажем — не особо нужен тому, кто эти формы будет комбинировать. Так снаружи выглядит, например, применение фреймворка extjs/sencha, на "ненавистном недоязыке" javascript — ни строчки HTML.

Но даже в этом случае в самих описаниях виджетов будет в том или ином виде присутствовать HTML/CSS/JS. И его очень даже надо править руками, если делается что-то помимо типового бизнес-приложения, которое не покидает пределов внутренней сети.

В третьих — он в данной подветке ничего не говорил про то, что собирается обойтись без HTML.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>но нет нужных высокоуровневых средств, включая даже самые банальные.
Можно список?

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Здравствуйте, Gaperton, Вы писали:

VD>>>необходимость использования ужасного недоязыка жабаскрипа,
G>>Нет в этой необходимости никаких сложностей. По своим свойствам JS ничем не хуже популярных динамических языков. И выполняется быстрее большинства из них.
G>>Необходимости, кстати, тоже нет — давно есть такие вещи, как, например, GWT. И есть разные мнения на тему, что же проще — использовать монструозные магические фреймворки с компиляцией, или же писать на простом и понятном JS с хорошим клиентским фреймворком вроде Dojo или Sencha.

ВВ>Вообще мне известны три стадии знакомства с ДжаваСкриптом:
ВВ>1. Какое же это говно
ВВ>2. О, а какой это на самом мощный язык!
ВВ>3. Какое же это все-таки говно

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

ВВ>Наконец те, кому нравится ДжаваСкрипт, могут просто не пользоваться таким фреймворком. Всегда есть альтернативы. Для больших любителей ДжаваСкрипта есть и вовсе node.js.

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

А вот dojo с extjs — уже есть, как и GWT.

ВВ>К тому же мысль о том, что фреймворк, отвечающий за компиляцию основного языка в ДжаваСкрипт, должен быть монструозным, а клиентские фреймворки — всегда белые и пушистые, мне кажется несколько сомнительной. Как раз наоборот — последнее время библиотеки для ДжаваСкрипта становятся все более и более монструозными. И прежде всего потому что они пытаются восполнить недостатки самого языка. Очевидно же, что куда лучше, когда у нас есть, так сказать, "первоклассные" средства, а не их эмуляция на уровне библиотек.

Когда эта мысль кажется сомнительной — всегда можно посмотреть на Google Web Toolkit, транслирующий Java в HTML/JS, и сравнить монструозность. Заодно станет понятно, что при подходе с компиляцией возникает интереснейшая проблема с отладкой. В GWT, например, она решается своим контейнером и специальным рантаймом для запуска и отладки приложений на JAVA без компиляции.

ВВ>Вообще в ДжаваСкрипте следующая проблема. Есть довольно мощная база — в случае с JS это замыкания и P-OOP, — но нет нужных высокоуровневых средств, включая даже самые банальные. В итоге, используя эту самую базу, мы и пытаемся через ректальное отверстие имитировать то, что легко и просто достигается на других языках, потому что уже есть "из коробки".

Так не надо имитировать — не будет и проблем. На JS надо писать так, как положено писать на JS, не пытаясь изображать из него всякие явы, сишарпы, и прочие. Там свои идиомы. Я, например, разного рода "объектными" обертками вроде Prototype не пользуюсь.

ВВ>На мой взгляд и Питон, и Руби — если уж говорить о других популярных динамических языках — гораздо лучше ДжаваСкрипта. Они продуманней и повернуты к пользователю нужным местом, а не этим самым ректальным отверстием. Это уж не говоря о том, что вообще есть такие языки как Эрланг.

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

ВВ>В итоге идея компиляции основного языка в ДжаваСкрипт мне кажется очень даже многообещающей. Ее основная задача — даже не избавиться от "плохого" JS, а писать весь код приложения на одном языке, а следовательно, иметь возможность использовать общие подходы и паттерны, даже реюзать одни и те же функции и пр.

Такое средство уже есть, и оно достаточно зрелое. Это Google Web Toolkit.

Здравствуйте, VladD2, Вы писали:

G>>Насколько я припоминаю, ты тут выше по ветке jQuery применять собирался. Так вот, вопрос. Как выглядит в jQuery выборка тега ".comment#1"?

VD>Я не собирался и не собираюсь применять jQuery. Речь шла исключительно о их шаблонах. О шаблонах jQuery речь зашла потому что ни используются в knockoutjs.com (см. например http://knockoutjs.com/documentation/template-binding.html). А knockout используется как базовая библиотека для того что я пытаюсь смастерить.

Реализация шаблонов на стороне браузера — это в простейшем случае примерно пара десятков строк кода. Говорить не о чем. Пример здесь.

http://ejohn.org/blog/javascript-micro-templating/

Именно так устроены шаблоны jQuery внутри.

G>>Этот незнакомый тебе "суржик" и "еще один язык" называется CSS-селекторы, и его знает каждый школьник, взявшийся изучать верстку. Скоро и ты приобщишься — деваться тебе некуда. Либо нихрена не сделаешь, либо выучишь.

VD>Думаю ты прекрасно понял мои слова. Замена ХТМЛ-я ХАМЛ-ом — это бесполезная трата времени, сил и процессора.
VD>Согласен ты со мной или нет мне все равно. Можешь оставаться при своем мнении. Только хамить не стоит.

Да с моей точки зрения вся твоя затея — есть бесполезная трата времени, сил, и процессора. Но время, естественно, твое, тебе и решать, как его тратить.

Здравствуйте, dotneter, Вы писали:

ВВ>>но нет нужных высокоуровневых средств, включая даже самые банальные.
D>Можно список?

Да начните хотя бы с модулей или пространств имен. Если это функциональный язык, то где первоклассные средства для частичного применения функций? Язык не в последнюю очередь расчитан на работу с ДОМ-ом, но где хоть какие-то встроенные средства для этого вроде ПМ-а? За исключением самых последних версий, которые все равно на широком уровне использовать нельзя, нет встроенных средств для представления non strict вычислений. Обращения к родительскому скопу (base, super) нет. Отсутствует понятие иммутабельности, констант или чего-то подобного. Из-за этого, кстати, уже в сам язык заложены чудесатые грабли — например, можно спокойно переопределить undefined.

Вообще такое ощущение, что ДжаваСкрипт никто под его предметную область не затачивал. Просто некий динамический язык, с неким рандомным набором парадигм. К тому же, чтобы писать на нем более или менее безопасный код, придется писать столько кода, что даже C# на этом фоне покажется лаконичным.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Здравствуйте, dotneter, Вы писали:

ВВ>>>но нет нужных высокоуровневых средств, включая даже самые банальные.
D>>Можно список?

ВВ>Да начните хотя бы с модулей или пространств имен.
Неплохо эмулируется.
ВВ>Если это функциональный язык, то где первоклассные средства для частичного применения функций? Язык не в последнюю очередь расчитан на работу с ДОМ-ом, но где хоть какие-то встроенные средства для этого вроде ПМ-а? За исключением самых последних версий, которые все равно на широком уровне использовать нельзя, нет встроенных средств для представления non strict вычислений.
Ничего что этого нет в большенстве популярных языков?
ВВ>Обращения к родительскому скопу (base, super) нет. Отсутствует понятие иммутабельности, констант или чего-то подобного. Из-за этого, кстати, уже в сам язык заложены чудесатые грабли — например, можно спокойно переопределить undefined.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

Здравствуйте, Gaperton, Вы писали:

ВВ>>Наконец те, кому нравится ДжаваСкрипт, могут просто не пользоваться таким фреймворком. Всегда есть альтернативы. Для больших любителей ДжаваСкрипта есть и вовсе node.js.
G>"Такого фреймворка" — сейчас нет, им, в конце концов, невозможно воспользоваться, и об альтернативах ему и свободе выбора говорить рановато.

А вот dojo с extjs — уже есть, как и GWT.

Ну и монструозным его называть тоже ведь рановато, правда?

ВВ>>К тому же мысль о том, что фреймворк, отвечающий за компиляцию основного языка в ДжаваСкрипт, должен быть монструозным, а клиентские фреймворки — всегда белые и пушистые, мне кажется несколько сомнительной. Как раз наоборот — последнее время библиотеки для ДжаваСкрипта становятся все более и более монструозными. И прежде всего потому что они пытаются восполнить недостатки самого языка. Очевидно же, что куда лучше, когда у нас есть, так сказать, "первоклассные" средства, а не их эмуляция на уровне библиотек.

G>Когда эта мысль кажется сомнительной — всегда можно посмотреть на Google Web Toolkit, транслирующий Java в HTML/JS, и сравнить монструозность. Заодно станет понятно, что при подходе с компиляцией возникает интереснейшая проблема с отладкой. В GWT, например, она решается своим контейнером и специальным рантаймом для запуска и отладки приложений на JAVA без компиляции.

В отличие от Джава, Немерле довольно хорошо подходит для решения такого класса задач. Задача с отладкой может быть решена по-разному — в том числе и имитацией хост-среды браузера. Опять же — могу сказать, что я очень редко отлаживаю ДжаваСкрипт. Вполне можно прожить без пошаговой отладки вообще, просто с расширенным отладочным дампом, позволяющий "снимать" стек на определенный момент времени, глобальный скоп и пр. На худой конец можно отлаживать ДжаваСкрипт

ВВ>>Вообще в ДжаваСкрипте следующая проблема. Есть довольно мощная база — в случае с JS это замыкания и P-OOP, — но нет нужных высокоуровневых средств, включая даже самые банальные. В итоге, используя эту самую базу, мы и пытаемся через ректальное отверстие имитировать то, что легко и просто достигается на других языках, потому что уже есть "из коробки".

G>Так не надо имитировать — не будет и проблем. На JS надо писать так, как положено писать на JS, не пытаясь изображать из него всякие явы, сишарпы, и прочие. Там свои идиомы. Я, например, разного рода "объектными" обертками вроде Prototype не пользуюсь.

А как на нем положено писать? В функциональном стиле на нем писать нельзя — он просто никакой в этом плане. P-OOP через делегацию — кто-то реально использует его на полную катушку в более или менее габаритных проектах? Это ж тихий ужас — вся программа превращается в один гигантский спец-эффект и никаких средств контроля над этим. Как это вообще с функциональной парадигмой сочетается? Говорят, что Схемой при дизайне JS вдохнялись? Ага.

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

Вообще проблема JS в том, что на нем очень сложно писать надежный код. Неспроста возникают паттерны вроде:

function foo(bar, undefined) {
   if (bar == undefined) {
      ...
   }
}

foo(bar);

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

ВВ>>На мой взгляд и Питон, и Руби — если уж говорить о других популярных динамических языках — гораздо лучше ДжаваСкрипта. Они продуманней и повернуты к пользователю нужным местом, а не этим самым ректальным отверстием. Это уж не говоря о том, что вообще есть такие языки как Эрланг.
G>Это вопрос исключительно привычек и умения готовить конкретный язык. На JS, Питоне, и Руби одна и та же задача может быть решена по разному. И выглядеть при этом хорошо.

Я так не считаю. Я считаю, что ДжаваСкрипт куда более низкоуровневый язык по сравнению с Питоном и Руби. И решения на нем выглядят, соответственно. Там, где на Руби получится изящный ДСЛ, на ДжаваСкрипте будет тонна говнокода, играющего с замыканиями. Покажи мне код на ДжаваСкрипте, отличный от тривиального, который выглядит хорошо?

Сравни фичи ДжаваСкрипта и Руби. В последнем куча *высокоуровневых* абстракций. В ДжаваСкрипте — замыкания и спец-эффекты.

ВВ>>В итоге идея компиляции основного языка в ДжаваСкрипт мне кажется очень даже многообещающей. Ее основная задача — даже не избавиться от "плохого" JS, а писать весь код приложения на одном языке, а следовательно, иметь возможность использовать общие подходы и паттерны, даже реюзать одни и те же функции и пр.
G>Такое средство уже есть, и оно достаточно зрелое. Это Google Web Toolkit.

А на дотнете мне толку от него?

Еще и ur/web есть, но вопрос — аналогичный.

Здравствуйте, dotneter, Вы писали:

ВВ>>Да начните хотя бы с модулей или пространств имен.
D>Неплохо эмулируется.

На ДжаваСкрипте все в той или иной степени эмулируется. Плохо именно то, что эмулируется. И зачастую по-разному.

ВВ>>Если это функциональный язык, то где первоклассные средства для частичного применения функций? Язык не в последнюю очередь расчитан на работу с ДОМ-ом, но где хоть какие-то встроенные средства для этого вроде ПМ-а? За исключением самых последних версий, которые все равно на широком уровне использовать нельзя, нет встроенных средств для представления non strict вычислений.
D>Ничего что этого нет в большенстве популярных языков?

В популярных языках есть нормальное следование главной концепции. Если таковой не является ФП, то мы имеем стандартный набор из перегрузки, именованных параметров и пр. Но в ДжаваСкрипте нет и этого. Собственно, в нем нет полноценной реализации ни одной из поддерживаемых парадигм.

ВВ>>Обращения к родительскому скопу (base, super) нет. Отсутствует понятие иммутабельности, констант или чего-то подобного. Из-за этого, кстати, уже в сам язык заложены чудесатые грабли — например, можно спокойно переопределить undefined.
D>Не сказал бы что это все тянет на вашу третью стадию, скорее должно быть
D>3) Да, чего-то не хватает, но пользоваться вполне можно.

Чего конкретно в нем не хватает, зависит от того, с каких позиций к нему подходить.

Как у функционального языка у него не хватает много чего, вплоть до сомнений в том, что он является функциональным. Реализована лишь самая базовая инфраструктура. Где частичное применение? Операторы для работы с функциями? Где иммутабельные переменные и структуры данных? Хвостовую рекурсию из имеющихся реализаций хоть кто-нибудь раскручивает?

Если рассматривать его как P-OOP язык и сравнивать, скажем, с Self, то опять же окажется, что реализована лишь самая базовая инфраструктура. Где трейты, уникальные объекты, миксины? Глядя на Self, возникает впечатление, что действительно у этого языка есть проработанная концепция, которая создавалась в расчете на то, что P-OOP действительно будет использоваться как главенствующая парадигма при программировании на Self. Глядя на ДжаваСкрипт...

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Глядя на Self, возникает впечатление, что действительно у этого языка есть проработанная концепция.
Опять же вы берете какие то сферические языки, возьмите тот же топ http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html и скажите каким их них js сильно проигрывает в проработке концепции. Да, есть хорошо продуманые языки, но им уступает не только js, но и большенство остальных популярных языков.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

Здравствуйте, dotneter, Вы писали:

D>Здравствуйте, Воронков Василий, Вы писали:

ВВ>>Глядя на Self, возникает впечатление, что действительно у этого языка есть проработанная концепция.
D>Опять же вы берете какие то сферические языки,

Это не сферические языки. Это прямые прародители JS. Если Self — это сферический язык программирования, то P-OOP — это сферическая парадигма программирования. А Схема так и вовсе в вашем топе есть.

D>возьмите тот же топ http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html и скажите каким их них js сильно проигрывает в проработке концепции. Да, есть хорошо продуманые языки, но им уступает не только js, но и большенство остальных популярных языков.

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

VD>>>Советую говорить за себя, а не выражать мнение общественности.
D>>Это общеизвестный факт
D>>http://stackoverflow.com/questions/406052/do-most-web-programmers-not-designers-use-wysiwyg-editors-or-hand-code-their

VD>Даже если почитать эту тему становится видно, что по этому поводу нет единого мнения.
VD>И в любом случае не стоит вещать от лица всех. Даже одиночный пример опровергает твое заявление и выставляет тебя трепачом.

В вебе WYSIWIG'ами для верстки чего-либо пользуются только люди, для которых и Word — это WYSIWIG редактор для веб'а. По вполне очевидной причине — вызивиги просто не умеют генерировать правильный код для визуального представления того, что на экране. И это задача на данный момент нереализуема вообще, кстати.

Здравствуйте, Gaperton, Вы писали:

G>Реализация шаблонов на стороне браузера — это в простейшем случае примерно пара десятков строк кода. Говорить не о чем. Пример здесь.

В простейшем случае все просто.

G>Именно так устроены шаблоны jQuery внутри.

G>Да с моей точки зрения вся твоя затея — есть бесполезная трата времени, сил, и процессора. Но время, естественно, твое, тебе и решать, как его тратить.

Было бы странно от тебя услышать что-то другое.

Здравствуйте, VladD2, Вы писали:

G>>Реализация шаблонов на стороне браузера — это в простейшем случае примерно пара десятков строк кода. Говорить не о чем. Пример здесь.

VD>В простейшем случае все просто.

Ой, извини. У тебя же сложнейший случай, я не учел.

Здравствуйте, Gaperton, Вы писали:

VD>>В простейшем случае все просто.

G>Ой, извини. У тебя же сложнейший случай, я не учел.

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

Здравствуйте, Воронков Василий, Вы писали:

G>>Когда эта мысль кажется сомнительной — всегда можно посмотреть на Google Web Toolkit, транслирующий Java в HTML/JS, и сравнить монструозность. Заодно станет понятно, что при подходе с компиляцией возникает интереснейшая проблема с отладкой. В GWT, например, она решается своим контейнером и специальным рантаймом для запуска и отладки приложений на JAVA без компиляции.

ВВ>В отличие от Джава, Немерле довольно хорошо подходит для решения такого класса задач.

Тот факт, что Java внезапно стала для него подходить плохо — еще надо обосновать. Про неуловимого Джо по кличке Немерле — я вообще молчу.

ВВ>Задача с отладкой может быть решена по-разному — в том числе и имитацией хост-среды браузера.

Человеческий способ ровным счетом один — сделать так же, как в GWT. Все остальное приведет к "ухудшению качества сервиса" для разработчика.

ВВ>Опять же — могу сказать, что я очень редко отлаживаю ДжаваСкрипт. Вполне можно прожить без пошаговой отладки вообще, просто с расширенным отладочным дампом, позволяющий "снимать" стек на определенный момент времени, глобальный скоп и пр.

Если джаваскрипта всего три строки "для придания сайтам динамики" — то отлаживать почти нечего. И говорить тоже не о чем.

А вот в каком-нибудь GMail — его как минимум тысячи строк. Про Google Docs я вообще молчу.

ВВ>На худой конец можно отлаживать ДжаваСкрипт

Автогенеренный? Ради счастья работать с фреймворком, избавляющим программиста от говноязыка JS?

Спасибо, без меня.

Я предпочитаю отлаживать код, написанный человеком для человека.

ВВ>>>Вообще в ДжаваСкрипте следующая проблема. Есть довольно мощная база — в случае с JS это замыкания и P-OOP, — но нет нужных высокоуровневых средств, включая даже самые банальные. В итоге, используя эту самую базу, мы и пытаемся через ректальное отверстие имитировать то, что легко и просто достигается на других языках, потому что уже есть "из коробки".

G>>Так не надо имитировать — не будет и проблем. На JS надо писать так, как положено писать на JS, не пытаясь изображать из него всякие явы, сишарпы, и прочие. Там свои идиомы. Я, например, разного рода "объектными" обертками вроде Prototype не пользуюсь.

ВВ>А как на нем положено писать? В функциональном стиле на нем писать нельзя — он просто никакой в этом плане.

В целом — получается очень похоже на generic programming Степанова — объекты + ФВП. А этот стиль, в свою очередь взят из лиспа.

На JS прекрасно можно писать в функциональном стиле. И делать "монадные" протяжки в духе LINQ — это вообще элементарно.

ВВ>P-OOP через делегацию — кто-то реально использует его на полную катушку в более или менее габаритных проектах? Это ж тихий ужас — вся программа превращается в один гигантский спец-эффект и никаких средств контроля над этим.

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

ВВ> Как это вообще с функциональной парадигмой сочетается? Говорят, что Схемой при дизайне JS вдохнялись? Ага.

Вполне нормально сочетается.

У меня, по крайней мере. Схема и Лисп не являются чистыми ФЯ — там применяется ровно тот же стиль, что в JS, плюс еще макросы.

ВВ>Я концепцию этого языка не понимаю. И по ходу ее никто вообще не понимает.

Никто? Да неужели?

Ты опрос проводил?

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

А на Немерле — все продвинутые библиотеки непременно написаны красиво и кому угодно понятно?

ВВ>Вообще проблема JS в том, что на нем очень сложно писать надежный код. Неспроста возникают паттерны вроде:

ВВ>

ВВ>function foo(bar, undefined) {
ВВ>   if (bar == undefined) {
ВВ>      ...
ВВ>   }
ВВ>}

ВВ>foo(bar);
ВВ>

Эвона как. Век живи — век учись говнокод писать.

Можно подробнее — и откуда же возникают подобные "паттерны"?

ВВ>И не надо говорить, что ДжаваСкрипт — это просто обычный динамический язык. Есть и другие динамические языки, не все атрибуты ДжаваСкрипта являются необходимыми для динамического языка.

Почему не надо-то?

Оно так и есть.

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

ВВ>Я так не считаю. Я считаю, что ДжаваСкрипт куда более низкоуровневый язык по сравнению с Питоном и Руби. И решения на нем выглядят, соответственно. Там, где на Руби получится изящный ДСЛ, на ДжаваСкрипте будет тонна говнокода, играющего с замыканиями. Покажи мне код на ДжаваСкрипте, отличный от тривиального, который выглядит хорошо?

Дай мне пример, где по твоему непременно на JS говнокод должен получиться — и поговорим. Давай, show me your code.

ВВ>>>В итоге идея компиляции основного языка в ДжаваСкрипт мне кажется очень даже многообещающей. Ее основная задача — даже не избавиться от "плохого" JS, а писать весь код приложения на одном языке, а следовательно, иметь возможность использовать общие подходы и паттерны, даже реюзать одни и те же функции и пр.
G>>Такое средство уже есть, и оно достаточно зрелое. Это Google Web Toolkit.

ВВ>А на дотнете мне толку от него?

На дотнете аналогичная штука делалась в рамках F#.

Здравствуйте, VladD2, Вы писали:

G>>Ой, извини. У тебя же сложнейший случай, я не учел.

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

Интересно. Примеры использования этого языка шаблонов у тебя есть? Наброски какие-нибудь?

Здравствуйте, Gaperton, Вы писали:

G>>>Ой, извини. У тебя же сложнейший случай, я не учел.

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

G>Интересно. Примеры использования этого языка шаблонов у тебя есть? Наброски какие-нибудь?

Желательно — иллюстрирующие идею формирования фрагментов шаблонов с помощью ФВП.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Да начните хотя бы с модулей, или пространств имен

Модули закрыты спецификацией CommonJS.

Пространства имен делаются тривиально. Например, так.

var module = function(){
   var _privateVar;

   return {
      publicVar: ...
   }
}();

ВВ>Если это функциональный язык, то где первоклассные средства для частичного применения функций?

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

ВВ>Язык не в последнюю очередь расчитан на работу с ДОМ-ом, но где хоть какие-то встроенные средства для этого вроде ПМ-а?

Средства для работы с DOM-ом берутся в абсолютно любом современном веб фреймворке (например — jQuery). Выглядят везде одинаково, и основаны на CSS-селекторах. Паттерн-матчинг в этой задаче в сравнении с селекторами нервно курит в сторонке.

ВВ>За исключением самых последних версий, которые все равно на широком уровне использовать нельзя, нет встроенных средств для представления non strict вычислений.

Что характерно — JS в этом не одинок, и никакой трагедии в этом нет.

ВВ> Обращения к родительскому скопу (base, super) нет.

Есть. Прототипы.

ВВ> Отсутствует понятие иммутабельности, констант или чего-то подобного. Из-за этого, кстати, уже в сам язык заложены чудесатые грабли — например, можно спокойно переопределить undefined.

Так же, как в Схеме и Лиспе. И что?

ВВ>Вообще такое ощущение, что ДжаваСкрипт никто под его предметную область не затачивал.

Достаточно один раз взглянуть на jQuery, чтобы понять, что заточка под "предметную область" JS-у не требуется. Она излишня.

ВВ>Просто некий динамический язык, с неким рандомным набором парадигм. К тому же, чтобы писать на нем более или менее безопасный код, придется писать столько кода, что даже C# на этом фоне покажется лаконичным.

Пример.

Здравствуйте, Gaperton, Вы писали:

ВВ>>В отличие от Джава, Немерле довольно хорошо подходит для решения такого класса задач.
G>Тот факт, что Java внезапно стала для него подходить плохо — еще надо обосновать. Про неуловимого Джо по кличке Немерле — я вообще молчу.

Одних квази-цитат по-моему достаточно, что определить, что подходит хорошо, а что плохо.

ВВ>>Задача с отладкой может быть решена по-разному — в том числе и имитацией хост-среды браузера.
G>Человеческий способ ровным счетом один — сделать так же, как в GWT. Все остальное приведет к "ухудшению качества сервиса" для разработчика.
ВВ>>Опять же — могу сказать, что я очень редко отлаживаю ДжаваСкрипт. Вполне можно прожить без пошаговой отладки вообще, просто с расширенным отладочным дампом, позволяющий "снимать" стек на определенный момент времени, глобальный скоп и пр.
G>Если джаваскрипта всего три строки "для придания сайтам динамики" — то отлаживать почти нечего. И говорить тоже не о чем.
G>А вот в каком-нибудь GMail — его как минимум тысячи строк. Про Google Docs я вообще молчу.

Ты разрабатывал GMail и отлаживал там ДжаваСкрипт? Я писал достаточно большие приложения на JS и отладчиком практически не пользовался. Вообще полезность пошагового отладчика сильно преувеличена. Есть куча языков, где его вообще нет — и ничего. Пишите тесты и будет вам счастье.

ВВ>>На худой конец можно отлаживать ДжаваСкрипт

G>Автогенеренный? Ради счастья работать с фреймворком, избавляющим программиста от говноязыка JS?

Спасибо, без меня.

Я предпочитаю отлаживать код, написанный человеком для человека.

Ну и что? Народ не смущает отлаживать автогенеренный JS в который компилируется CoffeeScript. Тебя смущает — проходите дальше. В чем проблема-то?

G>В целом — получается очень похоже на generic programming Степанова — объекты + ФВП. А этот стиль, в свою очередь взят из лиспа.
G>На JS прекрасно можно писать в функциональном стиле. И делать "монадные" протяжки в духе LINQ — это вообще элементарно.

Примерчик приведи такой "протяжки". Пока что Linq из императивного языка C# у меня слабо ассоциируется с функциональщиной.

ВВ>>P-OOP через делегацию — кто-то реально использует его на полную катушку в более или менее габаритных проектах? Это ж тихий ужас — вся программа превращается в один гигантский спец-эффект и никаких средств контроля над этим.
G>Это не тихий ужас, а очень интересная особенность, которую надо уметь правильно готовить. Реальная потребность в этом возникает редко.

Нет там ничего интересного. Реализован самый базис из того же Self-а. А обо всем остальном забыли. Рекурсивный люкап по хэш-таблицами — вот и весь ваш П-ООП в JS.

ВВ>> Как это вообще с функциональной парадигмой сочетается? Говорят, что Схемой при дизайне JS вдохнялись? Ага.
G>Вполне нормально сочетается.

У меня, по крайней мере. Схема и Лисп не являются чистыми ФЯ — там применяется ровно тот же стиль, что в JS, плюс еще макросы.

Какой такой "тот же стиль"? P-OOP что ли?
Лисп вообще ни разу не похож не JS, там принципиально другая идеология.

ВВ>>Я концепцию этого языка не понимаю. И по ходу ее никто вообще не понимает.
G>Никто? Да неужели?

Ты опрос проводил?

Я видел довольно много кода, а ты?

ВВ>>Вообще проблема JS в том, что на нем очень сложно писать надежный код. Неспроста возникают паттерны вроде:
ВВ>>

ВВ>>function foo(bar, undefined) {
ВВ>>   if (bar == undefined) {
ВВ>>      ...
ВВ>>   }
ВВ>>}

ВВ>>foo(bar);
ВВ>>

G>Эвона как. Век живи — век учись говнокод писать.

Можно подробнее — и откуда же возникают подобные "паттерны"?

Ну если ты не знаешь, то undefined можно переопределить и это единственный способ гарантированно получить "правильный" undefined. В противном случае в коде будет уязвимость. Иначе говоря, он является говно-кодом.

ВВ>>И не надо говорить, что ДжаваСкрипт — это просто обычный динамический язык. Есть и другие динамические языки, не все атрибуты ДжаваСкрипта являются необходимыми для динамического языка.
G>Почему не надо-то?

Оно так и есть.

Потому что это не так. Все языки разные. Динамика вовсе не обязывает всех превращаться в ДжаваСкрипт.

G>>>Это вопрос исключительно привычек и умения готовить конкретный язык. На JS, Питоне, и Руби одна и та же задача может быть решена по разному. И выглядеть при этом хорошо.
ВВ>>Я так не считаю. Я считаю, что ДжаваСкрипт куда более низкоуровневый язык по сравнению с Питоном и Руби. И решения на нем выглядят, соответственно. Там, где на Руби получится изящный ДСЛ, на ДжаваСкрипте будет тонна говнокода, играющего с замыканиями. Покажи мне код на ДжаваСкрипте, отличный от тривиального, который выглядит хорошо?
G>Дай мне пример, где по твоему непременно на JS говнокод должен получиться — и поговорим. Давай, show me your code.

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

Здравствуйте, Воронков Василий, Вы писали:

G>>Эвона как. Век живи — век учись говнокод писать.

Можно подробнее — и откуда же возникают подобные "паттерны"?
ВВ>Ну если ты не знаешь, то undefined можно переопределить и это единственный способ гарантированно получить "правильный" undefined. В противном случае в коде будет уязвимость. Иначе говоря, он является говно-кодом.

Есть как минимум ещё 2 способа проверки на неопределённое значение:

typeof bar == "undefined"

и

bar == void 0

А выше приведённый код и вправду так себе.

G>>Дай мне пример, где по твоему непременно на JS говнокод должен получиться — и поговорим. Давай, show me your code.
ВВ>В любой. Любое значение можно переопределить. Почти любая операция над любыми типами корректна. Все высокоуровневые возможности имитируются на замыканиях. Получается куча кода, которую легко поломать простой опечаткой.

Всё перечисленное не имеет непосредственного отношения к говнокоду, но облегчает его написание при желании и определённой форме рук. В любом случае, без примеров тут говорить не о чем, что показывает предыдущий пример.

Здравствуйте, Gaperton, Вы писали:

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

G>Интересно. Примеры использования этого языка шаблонов у тебя есть? Наброски какие-нибудь?

Шаблонов пока не реализовано. Так что могу только показать как примерно тоже самое выглядит на базе встроенных элементов:
ClickCounter.n
В комментарии преведен жабаскрипт в который раскрывается модель.
Ниже приведена вьюха. Собственно вот такие вьюхи и должны становиться за одно и клиентскими шаблонами, к которым можно осуществлять декларативный биндинг (как это делается со встроенными элементами).
Внутри биндинга пока жабаскрипт, но планируется там тоже использовать статически-типизированный язык.

В качестве прототипа можно рассматривать knockout:
http://knockoutjs.com/documentation/template-binding.html
Только нам нужно генерировать аналог из типизированных шаблонов (на сервере).

Здравствуйте, VladD2, Вы писали:

VD>Шаблонов пока не реализовано. Так что могу только показать как примерно тоже самое выглядит на базе встроенных элементов:
VD>[url=http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/Nemerle.WUI.Reactive/Test/MVVMs/ClickCounter.n
VD>]ClickCounter.n[/url]
VD>В комментарии преведен жабаскрипт в который раскрывается модель.
VD>Ниже приведена вьюха. Собственно вот такие вьюхи и должны становиться за одно и клиентскими шаблонами, к которым можно осуществлять декларативный биндинг (как это делается со встроенными элементами).
VD>Внутри биндинга пока жабаскрипт, но планируется там тоже использовать статически-типизированный язык.

Понятно.
1) Как собираемся решать проблему отсутствия отладчика?
2) Как будет устроено взаимодействие клиента на JS и сервера?

VD>В качестве прототипа можно рассматривать knockout:

Кнокаут знаю.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Ты разрабатывал GMail и отлаживал там ДжаваСкрипт? Я писал достаточно большие приложения на JS и отладчиком практически не пользовался. Вообще полезность пошагового отладчика сильно преувеличена. Есть куча языков, где его вообще нет — и ничего. Пишите тесты и будет вам счастье.

О, переход на личности. Какая разница, разрабатывал ли лично я GMail? Это что-то меняет?

Если тебе интересно — я делал не уступающее ему по сложности офллайновое веб-проложение для POS-терминалов, работающее в FF 3.6 на google gears, в котором _вся_ логика реализована на JS.

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

G>>Автогенеренный? Ради счастья работать с фреймворком, избавляющим программиста от говноязыка JS?

Спасибо, без меня.

Я предпочитаю отлаживать код, написанный человеком для человека.

ВВ>Ну и что? Народ не смущает отлаживать автогенеренный JS в который компилируется CoffeeScript. Тебя смущает — проходите дальше. В чем проблема-то?

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

ВВ>Примерчик приведи такой "протяжки". Пока что Linq из императивного языка C# у меня слабо ассоциируется с функциональщиной.

var map = _db.select("*").from("mytable").where("key = ?", value ).as_map( "Id", RowConstructor );

G>>Это не тихий ужас, а очень интересная особенность, которую надо уметь правильно готовить. Реальная потребность в этом возникает редко.

ВВ>Нет там ничего интересного. Реализован самый базис из того же Self-а. А обо всем остальном забыли. Рекурсивный люкап по хэш-таблицами — вот и весь ваш П-ООП в JS.

А весь ООП в С++ — это косвенный вызов по VMT. И что?

ВВ>>> Как это вообще с функциональной парадигмой сочетается? Говорят, что Схемой при дизайне JS вдохнялись? Ага.
G>>Вполне нормально сочетается.

У меня, по крайней мере. Схема и Лисп не являются чистыми ФЯ — там применяется ровно тот же стиль, что в JS, плюс еще макросы.

ВВ>Какой такой "тот же стиль"? P-OOP что ли?

Нет, не что ли. Я ответил в письме — ты ответ проскипал.

ВВ>Лисп вообще ни разу не похож не JS, там принципиально другая идеология.

Внешняя похожесть к вопросу никакого отношения не имеет.

ВВ>>>Я концепцию этого языка не понимаю. И по ходу ее никто вообще не понимает.
G>>Никто? Да неужели?

Ты опрос проводил?
ВВ>Я видел довольно много кода, а ты?

А я довольно много писал.

G>>Эвона как. Век живи — век учись говнокод писать.

Можно подробнее — и откуда же возникают подобные "паттерны"?

ВВ>Ну если ты не знаешь, то undefined можно переопределить и это единственный способ гарантированно получить "правильный" undefined. В противном случае в коде будет уязвимость. Иначе говоря, он является говно-кодом.

Ну, если ты не знаешь, то для надежной проверки на undefined достаточно написать:

if(typeof myVar == 'undefined')

Теперь давай вернемся к вопросу — и откуда же у нас возникают подобные "паттерны"?

ВВ>>>И не надо говорить, что ДжаваСкрипт — это просто обычный динамический язык. Есть и другие динамические языки, не все атрибуты ДжаваСкрипта являются необходимыми для динамического языка.
G>>Почему не надо-то?

Оно так и есть.

ВВ>Потому что это не так. Все языки разные. Динамика вовсе не обязывает всех превращаться в ДжаваСкрипт.

Конечно не обязывает. КО сообщает — если бы в JavaScript не было никаких отличий от Ruby, он назывался бы не JavaScript, а Ruby. Языки разные — но по своим возможностям равноценны.

G>>Дай мне пример, где по твоему непременно на JS говнокод должен получиться — и поговорим. Давай, show me your code.

ВВ>В любой. Любое значение можно переопределить.

Как в Лиспе и Схеме. И что?

ВВ>Почти любая операция над любыми типами корректна. Все высокоуровневые возможности имитируются на замыканиях.

Как в лиспе и схеме.

ВВ>Получается куча кода, которую легко поломать простой опечаткой.

Как в любом динамическом языке.

Здравствуйте, Gaperton, Вы писали:

ВВ>>Ты разрабатывал GMail и отлаживал там ДжаваСкрипт? Я писал достаточно большие приложения на JS и отладчиком практически не пользовался. Вообще полезность пошагового отладчика сильно преувеличена. Есть куча языков, где его вообще нет — и ничего. Пишите тесты и будет вам счастье.
G>О, переход на личности. Какая разница, разрабатывал ли лично я GMail? Это что-то меняет?

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

G>Если тебе интересно — я делал не уступающее ему по сложности офллайновое веб-проложение для POS-терминалов, работающее в FF 3.6 на google gears, в котором _вся_ логика реализована на JS.
G>И позволь мне тебе не поверить, что ты смог сделать что-то мало-мальски сложное, работающее в браузере, не пользуясь отладчиком.

Я вообще практически не пользуюсь отладчиком. И можешь мне не верить. Мне, честно говоря, как-то по фиг

G>>>Автогенеренный? Ради счастья работать с фреймворком, избавляющим программиста от говноязыка JS?

Спасибо, без меня.

Я предпочитаю отлаживать код, написанный человеком для человека.
ВВ>>Ну и что? Народ не смущает отлаживать автогенеренный JS в который компилируется CoffeeScript. Тебя смущает — проходите дальше. В чем проблема-то?
G>Ты видишь какую-то проблему в том, что я предпочитаю отлаживать код, написанный человеком для человека, и предлагаю вам отлаживать автогенеренный код без меня? Я — не вижу.

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

ВВ>>Примерчик приведи такой "протяжки". Пока что Linq из императивного языка C# у меня слабо ассоциируется с функциональщиной.
G>

G>var map = _db.select("*").from("mytable").where("key = ?", value ).as_map( "Id", RowConstructor );
G>

Не вижу здесь никаких монад. В лучшем случае это банальная цепочка вызовов, по аналогии с pipe-operator-ами. Которая здесь имитируется на чем-то вроде fluent API.
Объясни мне пожалуйста, что в этом коде функционального и какое он имеет отношение к Linq.

G>>>Это не тихий ужас, а очень интересная особенность, которую надо уметь правильно готовить. Реальная потребность в этом возникает редко.
ВВ>>Нет там ничего интересного. Реализован самый базис из того же Self-а. А обо всем остальном забыли. Рекурсивный люкап по хэш-таблицами — вот и весь ваш П-ООП в JS.
G>А весь ООП в С++ — это косвенный вызов по VMT. И что?

Тогда бы С++ мало чем отличался от С, где косвенный вызов тоже не проблема.
Речь, видимо, о том, что П-ООП предполагает еще что-то, кроме, собственно, механизма делегации и самих прототипов, но вот в JS ничего этого нет.
А class based OOP в С++ достаточно полон.

ВВ>>>> Как это вообще с функциональной парадигмой сочетается? Говорят, что Схемой при дизайне JS вдохнялись? Ага.
G>>>Вполне нормально сочетается.

У меня, по крайней мере. Схема и Лисп не являются чистыми ФЯ — там применяется ровно тот же стиль, что в JS, плюс еще макросы.
ВВ>>Какой такой "тот же стиль"? P-OOP что ли?
G>Нет, не что ли. Я ответил в письме — ты ответ проскипал.

Ах, ты про монадические протяжки. Опять же мимо. Вся программа на Лиспе может рассматриваться как один большой список, текст программы — манипуляция с самим текстом программы как со списком. ДжаваСкриптом тут не пахнет.

ВВ>>Лисп вообще ни разу не похож не JS, там принципиально другая идеология.
G>Внешняя похожесть к вопросу никакого отношения не имеет.

Я не про внешнюю похожесть.

ВВ>>>>Я концепцию этого языка не понимаю. И по ходу ее никто вообще не понимает.
G>>>Никто? Да неужели?

Ты опрос проводил?
ВВ>>Я видел довольно много кода, а ты?
G>А я довольно много писал.

И пришел к выводу, что ДжаваСкрипт похож на Лисп?

G>>>Эвона как. Век живи — век учись говнокод писать.

Можно подробнее — и откуда же возникают подобные "паттерны"?

ВВ>>Ну если ты не знаешь, то undefined можно переопределить и это единственный способ гарантированно получить "правильный" undefined. В противном случае в коде будет уязвимость. Иначе говоря, он является говно-кодом.

G>Ну, если ты не знаешь, то для надежной проверки на undefined достаточно написать:
G>

G>if(typeof myVar == 'undefined')
G>

Этот код не одинаков. null == undefined вычисляется в true. Тип null при этом object. То, что я привел — это просто пример. Его можно записать и проще, просто объявив переменную без инициализации. И в отличие от твоего варианта он работает.

G>Теперь давай вернемся к вопросу — и откуда же у нас возникают подобные "паттерны"?

Видимо, от понимания семантики языка.

ВВ>>>>И не надо говорить, что ДжаваСкрипт — это просто обычный динамический язык. Есть и другие динамические языки, не все атрибуты ДжаваСкрипта являются необходимыми для динамического языка.
G>>>Почему не надо-то?

Оно так и есть.
ВВ>>Потому что это не так. Все языки разные. Динамика вовсе не обязывает всех превращаться в ДжаваСкрипт.
G>Конечно не обязывает. КО сообщает — если бы в JavaScript не было никаких отличий от Ruby, он назывался бы не JavaScript, а Ruby. Языки разные — но по своим возможностям равноценны.

Если сейчас мы начнем скатываться в тему "все языки тюринг полны", то это просто демагогия. В большинстве популярных языков достаточно полно реализованы их основные парадигмы. В ДжаваСкрипте этого нет. Если он нахватался исключительно худших черт от своих прародителей, это его вовсе не оправдывает.

Здравствуйте, Gaperton, Вы писали:

G>Понятно.
G>1) Как собираемся решать проблему отсутствия отладчика?

Модель представления компилируется в исполняемый код и отладка для нее есть (при наличии тестов).
Представление тоже можно в тестах дергать в скомппилированом виде.
С биндингом дела обстоят хуже. Но он ведь декларативный, а значит и отлаживать в нем особо нечего.

Для сложных случаев можно отлаживать сгенерированные скрипты (в броузере).

G>2) Как будет устроено взаимодействие клиента на JS и сервера?

Для модели представления у нас есть все матаданные (во время компиляции). По ней можно генерировать код для сериализации в JSON и обратно (с контролем типов и т.п.).

VD>>В качестве прототипа можно рассматривать knockout:

G>Кнокаут знаю.

Ну, вот собственно идея сделать к нему (или аналогичный ему) фрэймворк, только не на JS, а на базе усеченного (до возможностей JS) немерла. Модель представления и представление описывается на немерле. Далее по этому описанию генерируется скрипт и ХТМЛ которые отправляются клиенту.

При этом имеем следующие фичи:
1. Статическая типизация для кода модели представления и представлений, что позволяет отслеживать несоответствия между ними.
2. Интеллисенс.
3. Наличие метаданных модели во время компиляции позволяет генерировать много разных разностей вроде сериализации в JSON или кода валидации.
4. Все преимущества реактивного подхода в UI. Ну, как в кнокауте.
5. Сокрытие деталей реализации. В том же кнокауте приходится заниматься преситаниями, так как вместо простых типов нужно использовать разные обзервабл-обертки. Тут же код чистый, а обзерверность припаивается при генерации кода.
6. Кнокаут вычисляет зависимости в рантайме. Мы же можем вычислить их статически и не дать, например, создать циклическую зависимость.

Здравствуйте, Gaperton, Вы писали:

G>>Интересно. Примеры использования этого языка шаблонов у тебя есть? Наброски какие-нибудь?

G>Желательно — иллюстрирующие идею формирования фрагментов шаблонов с помощью ФВП.

В шаблонах будет допустим урезанный немерл. Собственно идеологически все очень просто. Шаблон == представление.

Общий вид примерно такой:

ИмяПредставления(моделиПредставления : ТипМоделиПредставления) :  : XElement
{
  здесь код манипулирующий XLinq-овским DOM-ом с помощью Linq-овских фукнций и XML-литералов.
}

Описание XML-литералов можно найти здесь.
Собственно это неплохо легло бы на генерацию жабастрипта который манипулировал бы DOM-ом броузера. Вот только, как я понял, манипуляция домом сильно медленнее возни с текстом.

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

Здравствуйте, Воронков Василий, Вы писали:

ВВ>В итоге идея компиляции основного языка в ДжаваСкрипт мне кажется очень даже многообещающей. Ее основная задача — даже не избавиться от "плохого" JS, а писать весь код приложения на одном языке, а следовательно, иметь возможность использовать общие подходы и паттерны, даже реюзать одни и те же функции и пр.

Именно! И не просто на языке, а на весьма строгом статически-типизированном языке, с комплитом и шлюхами.

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

Здравствуйте, Gaperton, Вы писали:

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

Мне кажется Ворнков как-то сильно в дебри философии зашел. Лично мне достаточно того, что жабаскрип "сильно слаботипизирован". Получить в жабасктипре проблему на ровном месте ничего не стоит. Забыл return написать (что после применения ФЯ постоянно происходит) и получи странное поведение вместо сообщения об ошибке. Типы приводятся по чем зря. Видя в коде 1 + b можно только догадываться что же будет в результате.
Ну, а про неуклюжесть конструкцию я вообще молчу. Где это видано, чтобы сктипт проигрывал в лаконичности статически-типизированным языкам?

G>"Такого фреймворка" — сейчас нет, им, в конце концов, невозможно воспользоваться, и об альтернативах ему и свободе выбора говорить рановато.

А вот dojo с extjs — уже есть, как и GWT.

Не ясно только к чему это все сказано.

Здравствуйте, Gaperton, Вы писали:

ВВ>>Получается куча кода, которую легко поломать простой опечаткой.

G>Как в любом динамическом языке.

Это тоже достоинство?

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

Здравствуйте, Воронков Василий, Вы писали:

ВВ>>>Ну если ты не знаешь, то undefined можно переопределить и это единственный способ гарантированно получить "правильный" undefined. В противном случае в коде будет уязвимость. Иначе говоря, он является говно-кодом.
G>>Ну, если ты не знаешь, то для надежной проверки на undefined достаточно написать:
G>>

G>>if(typeof myVar == 'undefined')
G>>

ВВ>Этот код не одинаков. null == undefined вычисляется в true. Тип null при этом object. То, что я привел — это просто пример. Его можно записать и проще, просто объявив переменную без инициализации. И в отличие от твоего варианта он работает.

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

Здравствуйте, anonymous, Вы писали:

A>Не честно, менять условие задачи на ходу. null не является неопределённым значением, а изначально декларировалась проверка на него.

Неправда. Декларировался надежный аналог кода:

if (myVal == undefined) {

}

Этот код учитывает и null.

Здравствуйте, Воронков Василий, Вы писали:

G>>Если тебе интересно — я делал не уступающее ему по сложности офллайновое веб-проложение для POS-терминалов, работающее в FF 3.6 на google gears, в котором _вся_ логика реализована на JS.
G>>И позволь мне тебе не поверить, что ты смог сделать что-то мало-мальски сложное, работающее в браузере, не пользуясь отладчиком.

ВВ>Я вообще практически не пользуюсь отладчиком. И можешь мне не верить. Мне, честно говоря, как-то по фиг

Ну что ты. В то, что ты не пользуешься отладчиком — я как раз верю легко. Я не верю в то, что ты писал что-то мало-мальски сложное на JS. И мне пофиг, что тебе пофиг.

ВВ>>>Ну и что? Народ не смущает отлаживать автогенеренный JS в который компилируется CoffeeScript. Тебя смущает — проходите дальше. В чем проблема-то?
G>>Ты видишь какую-то проблему в том, что я предпочитаю отлаживать код, написанный человеком для человека, и предлагаю вам отлаживать автогенеренный код без меня? Я — не вижу.

ВВ>Я не понимаю, зачем это вообще обсуждается тут. Речь была не о твоих личных предпочтениях.

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

ВВ>>>Примерчик приведи такой "протяжки". Пока что Linq из императивного языка C# у меня слабо ассоциируется с функциональщиной.
G>>

G>>var map = _db.select("*").from("mytable").where("key = ?", value ).as_map( "Id", RowConstructor );
G>>

ВВ>Не вижу здесь никаких монад.

Не внимательно смотришь. Или плохо представляешь себе, что такое "монада". Впрочем, это, в отличии от JS, реально мало кто способен понять.

ВВ>Объясни мне пожалуйста, что в этом коде функционального и какое он имеет отношение к Linq.

В монадной протяжке нет ничего функционального — она имеративная по сути. Монады применяются в Хаскеле для императивщины, если ты не в курсе. Тема Linq к беседе вообще не относится.

G>>А весь ООП в С++ — это косвенный вызов по VMT. И что?

ВВ>Тогда бы С++ мало чем отличался от С, где косвенный вызов тоже не проблема.

А он вначале действительно мало отличался от С. Его первое название — "С с классами".

ВВ>Речь, видимо, о том, что П-ООП предполагает еще что-то, кроме, собственно, механизма делегации и самих прототипов, но вот в JS ничего этого нет.

Ну так расскажи наконец про это "что-то кроме", не томи.

ВВ>>>Какой такой "тот же стиль"? P-OOP что ли?
G>>Нет, не что ли. Я ответил в письме — ты ответ проскипал.

ВВ>Ах, ты про монадические протяжки.

Нет, я про generic programming, который ты проскипал.

ВВ>Опять же мимо. Вся программа на Лиспе может рассматриваться как один большой список, текст программы — манипуляция с самим текстом программы как со списком. ДжаваСкриптом тут не пахнет.

Выделенное жирным — неправда. С текстом программы в LISP манипулируют только макросы, и интерпретатор трактует макросы совсем не так, как функции. Макросов и метакода в реальных программах мало, он не определяет стиль решения типовых задач. То, что в лиспе макросы сделаны унификацией представления данных и кода — частность, практически не влияющая на паттерны проектирования.

ВВ>>>Лисп вообще ни разу не похож не JS, там принципиально другая идеология.
G>>Внешняя похожесть к вопросу никакого отношения не имеет.

ВВ>Я не про внешнюю похожесть.

Ты про внешнюю похожесть. Там — скобочки, здесь — не скобочки.

ВВ>>>>>Я концепцию этого языка не понимаю. И по ходу ее никто вообще не понимает.
G>>>>Никто? Да неужели?

Ты опрос проводил?
ВВ>>>Я видел довольно много кода, а ты?
G>>А я довольно много писал.

ВВ>И пришел к выводу, что ДжаваСкрипт похож на Лисп?

И для меня очевидно, что ходовые паттерны проектирования, исключая макросы — имеют много общего. То есть, по практике применения — да, похож.

G>>Ну, если ты не знаешь, то для надежной проверки на undefined достаточно написать:
G>>

G>>if(typeof myVar == 'undefined')
G>>

ВВ>Этот код не одинаков. null == undefined вычисляется в true. Тип null при этом object.

"Этот код одинаков". typeof null == undefined вычисляется в false. Ведь "тип null при этом object". Открой консоль, и проверь.

ВВ>То, что я привел — это просто пример. Его можно записать и проще, просто объявив переменную без инициализации.

Давай называть вещи своими именами. То, что ты привел — это не просто пример. Это ацкий, невероятный говнокод, за который надо вырывать руки, и больше никогда не подпускать к клаве.

ВВ>И в отличие от твоего варианта он работает.

Мой вариант прекрасно работает, в чем несложно убедится, открыв в браузере JS консоль (вот прям сейчас — открой и убедись).

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

G>>Теперь давай вернемся к вопросу — и откуда же у нас возникают подобные "паттерны"?

ВВ>Видимо, от понимания семантики языка.

Пацталом.

G>>Конечно не обязывает. КО сообщает — если бы в JavaScript не было никаких отличий от Ruby, он назывался бы не JavaScript, а Ruby. Языки разные — но по своим возможностям равноценны.

ВВ>Если сейчас мы начнем скатываться в тему "все языки тюринг полны", то это просто демагогия.

Ты уже давно ей занимаешься. Я тебя уже предлагал — show me your code. Хватит языком чесать, покажи, насколько плох JS.

А я тебе в ответ покажу, как на нем пишут те, кто его знает.

Здравствуйте, VladD2, Вы писали:

ВВ>>>Получается куча кода, которую легко поломать простой опечаткой.

G>>Как в любом динамическом языке.

VD>Это тоже достоинство?

Это особенность. В ряде ситуаций — это достоинство. В ряде других — недостаток. Единого мнения на этот счет нет.

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

Не, не канает за аргумент. Ибо — берешь Google Closure Compiler — и непринужденно получаешь статическую типизацию в JS. Было бы желание

.

Здравствуйте, VladD2, Вы писали:

VD>Лично мне достаточно того, что жабаскрип "сильно слаботипизирован". Получить в жабасктипре проблему на ровном месте ничего не стоит. Забыл return написать (что после применения ФЯ постоянно происходит) и получи странное поведение вместо сообщения об ошибке. Типы приводятся по чем зря. Видя в коде 1 + b можно только догадываться что же будет в результате.

Ну наконец-то кто-то ткнул в реальный недостаток.

Думал, не дождусь.

Да, это реально серьезный косяк. JS — опасный язык. Не все динамические языки такие. ДЛя примера — ощущения от Эрланга в сравнении с JS — как будто на статике пишешь.

VD>Ну, а про неуклюжесть конструкцию я вообще молчу. Где это видано, чтобы сктипт проигрывал в лаконичности статически-типизированным языкам?

Действительно — где?

Покажи!

Show me your code.

G>>"Такого фреймворка" — сейчас нет, им, в конце концов, невозможно воспользоваться, и об альтернативах ему и свободе выбора говорить рановато.

А вот dojo с extjs — уже есть, как и GWT.

VD>Не ясно только к чему это все сказано.

Ну, ты контекст беседы восстанови — там будет ясно, к чему оно сказано.

Здравствуйте, Gaperton, Вы писали:

G>>>Если тебе интересно — я делал не уступающее ему по сложности офллайновое веб-проложение для POS-терминалов, работающее в FF 3.6 на google gears, в котором _вся_ логика реализована на JS.
G>>>И позволь мне тебе не поверить, что ты смог сделать что-то мало-мальски сложное, работающее в браузере, не пользуясь отладчиком.

ВВ>>Я вообще практически не пользуюсь отладчиком. И можешь мне не верить. Мне, честно говоря, как-то по фиг

G>Ну что ты. В то, что ты не пользуешься отладчиком — я как раз верю легко. Я не верю в то, что ты писал что-то мало-мальски сложное на JS. И мне пофиг, что тебе пофиг.

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

ВВ>>>>Ну и что? Народ не смущает отлаживать автогенеренный JS в который компилируется CoffeeScript. Тебя смущает — проходите дальше. В чем проблема-то?
G>>>Ты видишь какую-то проблему в том, что я предпочитаю отлаживать код, написанный человеком для человека, и предлагаю вам отлаживать автогенеренный код без меня? Я — не вижу.
ВВ>>Я не понимаю, зачем это вообще обсуждается тут. Речь была не о твоих личных предпочтениях.

Да нет, мы тут тебя развлекаем.

ВВ>>>>Примерчик приведи такой "протяжки". Пока что Linq из императивного языка C# у меня слабо ассоциируется с функциональщиной.
G>>>

G>>>var map = _db.select("*").from("mytable").where("key = ?", value ).as_map( "Id", RowConstructor );
G>>>

ВВ>>Не вижу здесь никаких монад.
G>Не внимательно смотришь. Или плохо представляешь себе, что такое "монада". Впрочем, это, в отличии от JS, реально мало кто способен понять.

Я думаю есть еще третий вид людей — тех кто не понимает ни JS, ни монады. И ты своим примером это прекрасно демонстрируешь.
Смешно блин. Но ты главное продолжай. Я хочу еще один пример "монады".
А заодно расскажи, как ты этот дебажишь. Особенно весело будет.

ВВ>>Объясни мне пожалуйста, что в этом коде функционального и какое он имеет отношение к Linq.
G>В монадной протяжке нет ничего функционального — она имеративная по сути. Монады применяются в Хаскеле для императивщины, если ты не в курсе. Тема Linq к беседе вообще не относится.

Т.е. приведенный код сугубо императивный? Причем императивный код в императивном языке написан в виде монады? И привел ты его, чтобы показать функциональный стиль в JS? Да еще Линк сюда приплел, который теперь конечно же к теме не относится.

G>>>А весь ООП в С++ — это косвенный вызов по VMT. И что?
ВВ>>Тогда бы С++ мало чем отличался от С, где косвенный вызов тоже не проблема.
G>А он вначале действительно мало отличался от С. Его первое название — "С с классами".

Видимо, ты и сейчас разницы не видишь.

ВВ>>Речь, видимо, о том, что П-ООП предполагает еще что-то, кроме, собственно, механизма делегации и самих прототипов, но вот в JS ничего этого нет.
G>Ну так расскажи наконец про это "что-то кроме", не томи.

Открываешь любой обзор Селфа, смотришь. Я уж упоминал тут, повторяться не хочу.

ВВ>>Ах, ты про монадические протяжки.
G>Нет, я про generic programming, который ты проскипал.

Generic programming в динамическом языке? О, продолжай плиз.

ВВ>>Опять же мимо. Вся программа на Лиспе может рассматриваться как один большой список, текст программы — манипуляция с самим текстом программы как со списком. ДжаваСкриптом тут не пахнет.
G>Выделенное жирным — неправда. С текстом программы в LISP манипулируют только макросы, и интерпретатор трактует макросы совсем не так, как функции. Макросов и метакода в реальных программах мало, он не определяет стиль решения типовых задач. То, что в лиспе макросы сделаны унификацией представления данных и кода — частность, практически не влияющая на паттерны проектирования.

Извини, забыл, что ты еще по Лиспу специалист. Конечно же, в реальных программах на Лиспе макросов совсем нет. Кому они там нужны. Там не макросы, там "скобочки".

ВВ>>>>Лисп вообще ни разу не похож не JS, там принципиально другая идеология.
G>>>Внешняя похожесть к вопросу никакого отношения не имеет.
ВВ>>Я не про внешнюю похожесть.
G>Ты про внешнюю похожесть. Там — скобочки, здесь — не скобочки.

Я тоже могу в эту игру играть. Я не про внешнюю похожесть.

ВВ>>И пришел к выводу, что ДжаваСкрипт похож на Лисп?

G>И для меня очевидно, что ходовые паттерны проектирования, исключая макросы — имеют много общего. То есть, по практике применения — да, похож.

Да, я понял. Один из них ты выше привел. Монады.

ВВ>>Этот код не одинаков. null == undefined вычисляется в true. Тип null при этом object.
G>"Этот код одинаков". typeof null == undefined вычисляется в false. Ведь "тип null при этом object". Открой консоль, и проверь.

Читаешь хорошо? null == undefined равно true. typeof ты сюда сам приплел.

ВВ>>То, что я привел — это просто пример. Его можно записать и проще, просто объявив переменную без инициализации.
G>Давай называть вещи своими именами. То, что ты привел — это не просто пример. Это ацкий, невероятный говнокод, за который надо вырывать руки, и больше никогда не подпускать к клаве.

Я так понимаю, тебе руки давно уже вырвали. А по ходу и мозги.

ВВ>>И в отличие от твоего варианта он работает.
G>Мой вариант прекрасно работает, в чем несложно убедится, открыв в браузере JS консоль (вот прям сейчас — открой и убедись).

Твой вариант не работает. Открой консоль и убедись.

G>И не является говнокодом, за который надо вырывать руки.
G>>>Теперь давай вернемся к вопросу — и откуда же у нас возникают подобные "паттерны"?
ВВ>>Видимо, от понимания семантики языка.
G>

Пацталом.

Да ты оттуда и вылезаешь, как я погляжу.

G>>>Конечно не обязывает. КО сообщает — если бы в JavaScript не было никаких отличий от Ruby, он назывался бы не JavaScript, а Ruby. Языки разные — но по своим возможностям равноценны.
ВВ>>Если сейчас мы начнем скатываться в тему "все языки тюринг полны", то это просто демагогия.
G>Ты уже давно ей занимаешься. Я тебя уже предлагал — show me your code. Хватит языком чесать, покажи, насколько плох JS.
G>А я тебе в ответ покажу, как на нем пишут те, кто его знает.

Спасибо, ты уже показал. Впрочем, показывай еще. Будет над чем поржать.

Здравствуйте, Воронков Василий, Вы писали:

A>>Не честно, менять условие задачи на ходу. null не является неопределённым значением, а изначально декларировалась проверка на него.

ВВ>Неправда. Декларировался надежный аналог кода:

ВВ>

ВВ>if (myVal == undefined) {

ВВ>}
ВВ>

ВВ>Этот код учитывает и null.

Да неужели? Так ты "надежный" аналог проверки ( x == null || typeof x == 'undefined' ) приводил?

А что будет, если кто-нибудь твою мегафункцию с двумя аргументами вызовет, вот так: f( x, x )? Что, закладываешься на переопределение undefined — и надеешься, что никто не вызовет? Странно, право. Быть параноиком — так до конца.

И хватит людям голову морочить. undefined в твоем примере возникает в ситуации, когда первый аргумент опущен. И это совсем не то же самое, когда он есть, и в него передан null.

Если уж ты допускаешь такую ситуацию как валидную — то вести себя вызовы должны по разному. То есть, например, вот так —
геттер: myProperty()
сеттер: myProperty( null )
— хорошо. А за одинаковое поведение такого рода функций by design надо ампутировать руки проектировщику — и особенности JS здесь совершенно не причем.

В реальной, а не выдуманной тобой ситуации, ты всегда представляешь себе тип аргумента, и знаешь, когда тебе надо:
— детектировать опциональный аргумент независимо от типа, что будет именно typeof x == undefined, и никак иначе,
— проверять на существование проперти объекта, которое if( x in obj ), и никаких сверок с undefined
— либо ты знаешь, что аргумент у тебя есть, и это именно объект, а не бул, не число, и никакая другая хрень, и тогда достаточно if( x ). Если вдруг это у тебя получается не так, и могут прям разные типы припереть (но не "any"), то ты сначала определяешь его тип.

Здравствуйте, Воронков Василий, Вы писали:

G>>>>Если тебе интересно — я делал не уступающее ему по сложности офллайновое веб-проложение для POS-терминалов, работающее в FF 3.6 на google gears, в котором _вся_ логика реализована на JS.
G>>>>И позволь мне тебе не поверить, что ты смог сделать что-то мало-мальски сложное, работающее в браузере, не пользуясь отладчиком.

ВВ>>>Я вообще практически не пользуюсь отладчиком. И можешь мне не верить. Мне, честно говоря, как-то по фиг

G>>Ну что ты. В то, что ты не пользуешься отладчиком — я как раз верю легко. Я не верю в то, что ты писал что-то мало-мальски сложное на JS. И мне пофиг, что тебе пофиг.

ВВ>Судя по твоим высказываниям, я вообще не верю в то, что ты хоть самую малость понимаешь в том, о чем говоришь.

Это не страшно. Я-то отлично понимаю не только то, что говорю я, но и то, что говоришь ты. А что там в вашем волшебном мире единорогов происходит — неважно.

ВВ>>>>>Ну и что? Народ не смущает отлаживать автогенеренный JS в который компилируется CoffeeScript. Тебя смущает — проходите дальше. В чем проблема-то?
G>>>>Ты видишь какую-то проблему в том, что я предпочитаю отлаживать код, написанный человеком для человека, и предлагаю вам отлаживать автогенеренный код без меня? Я — не вижу.
ВВ>>>Я не понимаю, зачем это вообще обсуждается тут. Речь была не о твоих личных предпочтениях.
ВВ>Да нет, мы тут тебя развлекаем.

А вот это верно подмечено. Только не "вы", а ты.

ВВ>>>Не вижу здесь никаких монад.
G>>Не внимательно смотришь. Или плохо представляешь себе, что такое "монада". Впрочем, это, в отличии от JS, реально мало кто способен понять.
ВВ>Я думаю есть еще третий вид людей — тех кто не понимает ни JS, ни монады. И ты своим примером это прекрасно демонстрируешь.

Расскажи же мне, что такое монада, о гуру JS, владеющий паттернами защиты от перекрытия undefined.

Я весь внимание.

ВВ>Смешно блин. Но ты главное продолжай. Я хочу еще один пример "монады".

Вот тебе четыре — посмейся.

http://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/baastad.pdf

ВВ>А заодно расскажи, как ты этот дебажишь. Особенно весело будет.

Ну я-то отладчиком дебажу, здесь ничего интересного. А вот как ты дебажишь браузерный код без отладчика — вот где настоящая загадка.

ВВ>>>Объясни мне пожалуйста, что в этом коде функционального и какое он имеет отношение к Linq.
G>>В монадной протяжке нет ничего функционального — она имеративная по сути. Монады применяются в Хаскеле для императивщины, если ты не в курсе. Тема Linq к беседе вообще не относится.

ВВ>Т.е. приведенный код сугубо императивный? Причем императивный код в императивном языке написан в виде монады?

Именно так.

ВВ>И привел ты его, чтобы показать функциональный стиль в JS? Да еще Линк сюда приплел, который теперь конечно же к теме не относится.

Нет, конечно. Я его привел для того, чтобы до тебя дошел смысл термина "монадная протяжка в духе LINQ" — ты просил привести пример. Но тебе не помогло.

ВВ>>>Тогда бы С++ мало чем отличался от С, где косвенный вызов тоже не проблема.
G>>А он вначале действительно мало отличался от С. Его первое название — "С с классами".

ВВ>Видимо, ты и сейчас разницы не видишь.

А что, есть какая-то разница?

Там же такие же фигурные скобочки как в С!

ВВ>>>Речь, видимо, о том, что П-ООП предполагает еще что-то, кроме, собственно, механизма делегации и самих прототипов, но вот в JS ничего этого нет.
G>>Ну так расскажи наконец про это "что-то кроме", не томи.

ВВ>Открываешь любой обзор Селфа, смотришь. Я уж упоминал тут, повторяться не хочу.

Не, не открываю, и не смотрю. А просто констатирую факт — ты не в состоянии объяснить, что стоит за "что-то кроме", и прочими твоими проявлениями загадочности. Что и требовалось доказать.

ВВ>>>Ах, ты про монадические протяжки.
G>>Нет, я про generic programming, который ты проскипал.
ВВ>Generic programming в динамическом языке? О, продолжай плиз.

Это лишнее. По моему, тебе уже хватило.

ВВ>>>Опять же мимо. Вся программа на Лиспе может рассматриваться как один большой список, текст программы — манипуляция с самим текстом программы как со списком. ДжаваСкриптом тут не пахнет.
G>>Выделенное жирным — неправда. С текстом программы в LISP манипулируют только макросы, и интерпретатор трактует макросы совсем не так, как функции. Макросов и метакода в реальных программах мало, он не определяет стиль решения типовых задач. То, что в лиспе макросы сделаны унификацией представления данных и кода — частность, практически не влияющая на паттерны проектирования.

ВВ>Извини, забыл, что ты еще по Лиспу специалист.

Самое время вспомнить.

ВВ>Конечно же, в реальных программах на Лиспе макросов совсем нет. Кому они там нужны. Там не макросы, там "скобочки".

Не "совсем нет", а относительно мало.

ВВ>>>>>Лисп вообще ни разу не похож не JS, там принципиально другая идеология.
G>>>>Внешняя похожесть к вопросу никакого отношения не имеет.
ВВ>>>Я не про внешнюю похожесть.
G>>Ты про внешнюю похожесть. Там — скобочки, здесь — не скобочки.

ВВ>Я тоже могу в эту игру играть. Я не про внешнюю похожесть.

Не, не можешь.

ВВ>>>И пришел к выводу, что ДжаваСкрипт похож на Лисп?

G>>И для меня очевидно, что ходовые паттерны проектирования, исключая макросы — имеют много общего. То есть, по практике применения — да, похож.

ВВ>Да, я понял. Один из них ты выше привел. Монады.

Ну естественно ты не понял.

Здесь про Степановский Generic Programming, который основан на сочетании объектов и ФВП. Лиспу с его макросами и побочными эффектами монадические трюки нафиг не вперлись.

ВВ>>>Этот код не одинаков. null == undefined вычисляется в true. Тип null при этом object.
G>>"Этот код одинаков". typeof null == undefined вычисляется в false. Ведь "тип null при этом object". Открой консоль, и проверь.

ВВ>Читаешь хорошо? null == undefined равно true. typeof ты сюда сам приплел.

О как. То есть, мне надо за каким-то хреном не различать ситуации f() и f( null )? Типо, паттерн такой, да? Не знаю, что вы там в волшебном мире курите, но это как слышится, так и пишется:

if( myVal == null || typeof myVal = 'undefined' )

Да, а на вызов f( x, x ) мне тоже надо реакцию говнокода воспроизвести — мой код, как и твой, должен думать, что его без параметров вызвали, да? Прости, не учел. Это уже так влегкую не повторить.

ВВ>>>То, что я привел — это просто пример. Его можно записать и проще, просто объявив переменную без инициализации.
G>>Давай называть вещи своими именами. То, что ты привел — это не просто пример. Это ацкий, невероятный говнокод, за который надо вырывать руки, и больше никогда не подпускать к клаве.
ВВ>Я так понимаю, тебе руки давно уже вырвали. А по ходу и мозги.

Не, не вырвали. Мне не за что. Я говнокода не пишу, и не доказываю другим, что говнокод — это правильно и круто.

G>>Ты уже давно ей занимаешься. Я тебя уже предлагал — show me your code. Хватит языком чесать, покажи, насколько плох JS.
G>>А я тебе в ответ покажу, как на нем пишут те, кто его знает.

ВВ>Спасибо, ты уже показал. Впрочем, показывай еще. Будет над чем поржать.

Ну так ты еще один пример говнокода дай, и паржом вместе.

Здравствуйте, Воронков Василий, Вы писали:

A>>Не честно, менять условие задачи на ходу. null не является неопределённым значением, а изначально декларировалась проверка на него.
ВВ>Неправда. Декларировался надежный аналог кода:
ВВ>

ВВ>if (myVal == undefined) {
ВВ>}
ВВ>

ВВ>Этот код учитывает и null.

В таком случае выше я привёл решение. Но вообще-то я даже не представляю, зачем проверять сразу и на неопределённое значение и на пустое.

Здравствуйте, Gaperton, Вы писали:

ВВ>>>>Не вижу здесь никаких монад.
G>>>Не внимательно смотришь. Или плохо представляешь себе, что такое "монада". Впрочем, это, в отличии от JS, реально мало кто способен понять.
ВВ>>Я думаю есть еще третий вид людей — тех кто не понимает ни JS, ни монады. И ты своим примером это прекрасно демонстрируешь.
G>Расскажи же мне, что такое монада, о гуру JS, владеющий паттернами защиты от перекрытия undefined.

Я весь внимание.

Вот с этого и надо было начинать. Дяденька, объясни. Глядишь, никаких "монадных протяжек" бы и не случилось.
Ну что ж — открою тебе большую тайну. Монады в Хаскеле совсем не для написания императивного кода. Это можно прекрасно делать без всяких монад. Вообще императивный и функциональный — вещи достаточно ортогональные. Так что же такое монады-то?

Монады в Хаскеле — это прежде всего абстракция, позволяющая выразить подобное вычисление, которое происходит в рамках другого вычисления и которое в императивном языке производилось бы неявно и *возможно* создавало бы побочные эффекты, — выразить его явным образом.

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

prod (xs,ys) = do {x <- xs;y <- ys; return (x,y)}

Вызываем со списками:

>prod ([1..3],[4..6])
[(1,4),(1,5),(1,6),(2,4),(2,5),(2,6),(3,4),(3,5),(3,6)]

А теперь с Мейби:

>prod (Just 2, Just 42)
Just (2,42)

Теперь давай посмотрим, какой смысл может иметь фраза "монадические протяжки в стиле Линк". Протяжки я оставлю на твоей совести, коснемся Линка.

Линк — это библиотека ФВП, большая часть которых дублирует функции обычного хаскелевского прелюда и Data.List. Дублирует весьма старательно — функции Линка чистые и большинство из имеет non-strict семантику. А это означает, что цепочки вида seq.Where(x => x % 2 == 0).Select(x => x + x) и seq.Select(x => x + x).Where(x => x % 2 == 0) полностью эквиваленты.

Вопрос в общем прежний — где здесь монада?

ВВ>>Смешно блин. Но ты главное продолжай. Я хочу еще один пример "монады".
G>Вот тебе четыре — посмейся.

G>http://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/baastad.pdf
ВВ>>А заодно расскажи, как ты этот дебажишь. Особенно весело будет.
G>Ну я-то отладчиком дебажу, здесь ничего интересного. А вот как ты дебажишь браузерный код без отладчика — вот где настоящая загадка.

Если приведенный тобой пример действительно сделан по подобию Линк, то пошаговая отладка несколько теряет свой смысл в коде, в котором нет "пошаговости". Но ты все равно, продолжай дебажить. Вдруг что найдешь.

G>Нет, конечно. Я его привел для того, чтобы до тебя дошел смысл термина "монадная протяжка в духе LINQ" — ты просил привести пример. Но тебе не помогло.

Потому что этот термин — бред.

G>>>Нет, я про generic programming, который ты проскипал.
ВВ>>Generic programming в динамическом языке? О, продолжай плиз.
G>Это лишнее. По моему, тебе уже хватило.

Ты знаешь — пожалуй ты прав. Бреда, наверное, хватит. Если у тебя действительно есть мозги, как ты уверяешь, попробуй их-таки напрячь и подумать, какой смысл может иметь понятие "генерик" в языке с динамической типизацией. Это тебе задание домашнее.

Остальной бред поскипан.

Здравствуйте, Gaperton, Вы писали:

ВВ>>>>Получается куча кода, которую легко поломать простой опечаткой.
G>>>Как в любом динамическом языке.
VD>>Это тоже достоинство?

G>Это особенность. В ряде ситуаций — это достоинство. В ряде других — недостаток. Единого мнения на этот счет нет.

Возможность поломать код неловким движением может быт достоинством?

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

G>Не, не канает за аргумент. Ибо — берешь Google Closure Compiler — и непринужденно получаешь статическую типизацию в JS. Было бы желание

.

А какой смысл пытаться прикрутить статическую типизацию к языку который не был на нее рассчитан?
Что это даст? Ну, прибавится скорость в некоторых местах. Все равно это будет во много раз медленнее компилированного статически-типизированного языка, потоку как реальную динамику ускорить нельзя.

Потом вот что написано в описание Google Closure Compiler:

The Closure Compiler is a tool for making JavaScript download and run faster. It is a true compiler for JavaScript. Instead of compiling from a source language to machine code, it compiles from JavaScript to better JavaScript.

То есть это дело даже компилятором по сути дела не является.

А уж о таких фичах как статических проверках типов, интелисенсе и рефакторинге и говорить не приходится.

Здравствуйте, VladD2, Вы писали:

G>>Это особенность. В ряде ситуаций — это достоинство. В ряде других — недостаток. Единого мнения на этот счет нет.

VD>Возможность поломать код неловким движением может быт достоинством?

Конечно не может. А вот, например, возможность поменять "класс" объекта в динамике в ряде ситуаций может сильно упростить жизнь. И это не единственное.

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

G>>Не, не канает за аргумент. Ибо — берешь Google Closure Compiler — и непринужденно получаешь статическую типизацию в JS. Было бы желание

.

VD>А какой смысл пытаться прикрутить статическую типизацию к языку который не был на нее рассчитан?

Типы проверять в статике, Влад. "Твой КО" (с). Ошибки ловить до компиляции. Чтобы иметь преимущества и динамики, и статики. Подобный тул (правда, на голову выше по возможностям) есть и для Эрланга — входит в штатную поставку (dyalizer).

VD>Что это даст? Ну, прибавится скорость в некоторых местах.

Скорость как раз не прибавится. Closure Compiler только статическую проверку типов выполняет, в все. Он ловит ошибки типов. Помогает от опечаток, и ошибок дизайна.

VD>Все равно это будет во много раз медленнее компилированного статически-типизированного языка, потоку как реальную динамику ускорить нельзя.

Будет, но не так уж во много раз. V8, все-таки, весьма неплох — он уже настолько адекватен, что можно сказать — скорость уже не проблема JS. Ситуация реально очень сильно поменялась за последние 3 года.

VD>Потом вот что написано в описание Google Closure Compiler:
VD>

VD>The Closure Compiler is a tool for making JavaScript download and run faster. It is a true compiler for JavaScript. Instead of compiling from a source language to machine code, it compiles from JavaScript to better JavaScript.

VD>То есть это дело даже компилятором по сути дела не является.

Да, не является. Это по сути тайпчерер + обфускатор.

VD>А уж о таких фичах как статических проверках типов, интелисенсе и рефакторинге и говорить не приходится.

Интиллисенс для JS работает в IDEA (а также младших братьях — WebStorm, PHP Storm), Komodo, и Eclipse. Рефакторинг в WebStorm вполне адекватен. Статическую проверку типов выполняет Closure Compiler.

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

Здравствуйте, Gaperton, Вы писали:

G>Хочешь ты этого или нет, но JavaScript вырастает из детских штанишек, и его поддержка тулами и фреймворками уже превосходит Немерле. На нем будут писать.

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

Вы, возможно, подобно древним шаманам, думаете, что можете управлять "ветром".

Не можете, дружище. Направление ветра можно предсказывать (с какой-то вероятностью) — но не управлять им.

Это точная аналогия. Поэтому вас иногда и называют "сектой".

Здравствуйте, Gaperton, Вы писали:

G>Вы, возможно, подобно древним шаманам, думаете, что можете управлять "ветром".

Не можете, дружище. Направление ветра можно предсказывать (с какой-то вероятностью) — но не управлять им.

И, знаешь, что? Вопреки прогнозам синоптиков, ветер может внезапно переменится.

Синоптик это учтет, и скорректирует модель. Шаман — укрепится в вере, и решит, что неправильным образом "взывал к богам".

Впрочем, я уверен, что эта аналогия до тебя не дойдет. Может быть, она дойдет до кого-нидуль их читателей? Я буду этому рад.

Здравствуйте, Gaperton, Вы писали:

G>Во-первых, HAML — это не специальный DSL, а по сути обыкновенные CSS-селекторы, которые и так все, имеющие дело с вебом, знают. Порог вхождения для человека, знающего HTML/CSS — примерно 10-15 минут, уходящие на чтение короткой доки.

HAML это таки DSL. Собственно это главная причина почему он востребован.

В реальности HAML находится в некоем странном месте (на шкале абстракций, а не там где Влад подумал).
Для моделей (в смысле MVC) он низко-уровневый. А то что и как он описывает не сильно далеко он собственно HTML.

У нас тут в одном проекте получилось вообще вот такое описание:

var model = form("Contact details")
    .group("Name")
      .field("First name", "contact.firstName")
      .field("Last name", "contact.lastName")
    .group(....)
      ...
    .list(....);

по которому строится несколько форм представления. Для чего здесь абстракции высшего порядка я понимаю.
Без них — что HTML, что HAML — одно и то же. ИМХО, ясное дело.

Здравствуйте, c-smile, Вы писали:

G>>Во-первых, HAML — это не специальный DSL, а по сути обыкновенные CSS-селекторы, которые и так все, имеющие дело с вебом, знают. Порог вхождения для человека, знающего HTML/CSS — примерно 10-15 минут, уходящие на чтение короткой доки.

CS>HAML это таки DSL. Собственно это главная причина почему он востребован.

Хорошо, пусть он таки DSL (не вижу смысла спорить о непринципиальных вещах). Тем не менее — порог для человека, знающего HTML/CSS, крайне низок, изучать там нечего.

CS>В реальности HAML находится в некоем странном месте (на шкале абстракций, а не там где Влад подумал).
CS>Для моделей (в смысле MVC) он низко-уровневый. А то что и как он описывает не сильно далеко он собственно HTML.

Конечно. Это альтернативный (лучший) синтаксис для HTML.

CS>У нас тут в одном проекте получилось вообще вот такое описание:

CS>

CS>var model = form("Contact details")
CS>    .group("Name")
CS>      .field("First name", "contact.firstName")
CS>      .field("Last name", "contact.lastName")
CS>    .group(....)
CS>      ...
CS>    .list(....);
CS>

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

В духе HAML то же самое выглядит примерно так:

%form Contact details
   %group Name
      %field{ bind-to="contact.firstName" } First Name 
      %field{ bind-to="contact.lastName" } Last Name 
   %group ...
   ...
   %list

То есть, хитрые "виджеты" вводятся как новые теги, и все.

CS>по которому строится несколько форм представления. Для чего здесь абстракции высшего порядка я понимаю.
CS>Без них — что HTML, что HAML — одно и то же. ИМХО, ясное дело.

Здесь ты комбинируешь готовые виджеты. То есть, ты на высоком уровне спрятал HTML/CSS, но не избавился от него. Для того, чтобы это показать в HTML, да еще натянуть стили — ты никуда не денешься от HTML/CSS, он в описании виджетов присутствовать будет. И, в конечном счете будет довольно-таки большая разница. Это не менее ясное дело, не так ли?

И это первое. А второе — с такими подходами вы вводите новый DSL с неявными правилами, которые куда сложнее правил HAML/HTML/CSS, с которыми и так знаком любой верстальщик. Это по какой-то причине вас не пугает. А зря. Хорошие верстальщики отлично умеют управляться с HTML-контентом. Куда лучше, чем программисты.

Здравствуйте, VladD2, Вы писали:

VD>А вот этой самой читаемости я как-то и не вижу.

А она есть. Пока я реально не использовал хамл, я ее тоже не видел. После использования взгляды поменялись, структура документа видна намного лучше. Впрочем это к теме не относится. Добавить к xml аналогичный макрос haml (а еще лучше slim, он немного читабельнее и, вероятно, сможет лечь в макрос кодом, а не строкой) совсем не сложно.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Gaperton, Вы писали:

VD>>>Подумалось... Меня удивляет даже не том, что ты так упорно не понимаешь, что не всем нужен этот ХАМЛ.

G>>А меня удивляет, что ты берешь на себя смелость объяснять мне, что "всем" нужно, а что не нужно.

VD>Мне кажется ты что-то путаешь. Это не я тебе навязываю ХТМЛ, а ты мне ХАМЛ.

Это ты путаешь. Я тебе ничего не навязываю, а просто предложил. С этого момента ты меня убеждаешь, что HAML говно, а я тебе возражаю.

VD>Ты лучше прочти тематическое сообщение и попробуй понять, что тема ХАМЛ-а мня попросту не интересует. У меня другие задачи.

Не интересно — так и скажи, "не так важно, какой там будет язык разметки, важно другое". Кто тебя за язык-то тянет высказывать свои суждения про HAML?

G>>И немного смешит, что ты при этом не знаешь, как выглядит CSS-селектор. В этом, Влад, ты весь.

VD>Я осмотрю тебя так и прет наступить на старые грабли. Будь добр держать себя в рамках приличия, а то ведь снова будешь спрашивать почему на РСДН нет демократии.

А что — ты правда штоли не знаешь, как выглядит CSS-селектор?

VD>>Я осмотрю тебя так и прет наступить на старые грабли. Будь добр держать себя в рамках приличия, а то ведь снова будешь спрашивать почему на РСДН нет демократии.

G>А что — ты правда штоли не знаешь, как выглядит CSS-селектор?

Давай я наступлю на старые грабли, и проведу персональный ликбез. Он выглядит так, Влад:

#id — это ссылка на элемент разметки с id="id"

.class — это ссылка на элемент разметки с class="class".

А вот это:

.comment#5 — ссылка на элемент с классом comment и id="5".

Ты прикинь, суржик какой в старый добрый CSS запихали, а?

Прям заразы весь HAML скопировали

.

Жаль, всетки, что на РСДН нет демократии. Проголосовали б, да запретили б нафиг CSS, и нет проблем.

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

От:	VladD2	www.nemerle.org
Дата:	01.03.11 13:04
Оценка:

	От:	Temoto
	Дата:	01.03.11 13:19
	Оценка:	+1

От:	Курилка	http://kirya.narod.ru/
Дата:	01.03.11 13:30
Оценка:

От:	VladD2	www.nemerle.org
Дата:	01.03.11 13:54
Оценка:

	От:	Temoto
	Дата:	01.03.11 14:44
	Оценка:	47 (1)

От:	anonymous	http://denis.ibaev.name/
Дата:	01.03.11 17:12
Оценка:

От:	c-smile	http://terrainformatica.com
Дата:	01.03.11 19:26
Оценка:	47 (1)

От:	Gaperton	http://gaperton.livejournal.com
Дата:	10.03.11 07:27
Оценка:

	От:	Воронков Василий
	Дата:	13.03.11 21:39
	Оценка:

От:	Mamut	http://dmitriid.com
Дата:	14.03.11 11:59
Оценка:

	От:	dotneter
	Дата:	02.03.11 08:04
	Оценка:

	От:	Аноним
	Дата:	11.03.11 17:06
	Оценка:

	От:	dotneter
	Дата:	12.03.11 15:11
	Оценка: