Здравствуйте, 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-контентом. Куда лучше, чем программисты.