M>Что, по вашему, должно быть в интернете такого, чтобы он был идеален? От браузеров до языков.
Контент. Современному вебу остро не хватает вменяемого контента. Все прочее там есть.
Здравствуйте, Mamut, Вы писали:
M>Что, по вашему, должно быть в интернете такого, чтобы он был идеален? От браузеров до языков.
Разделить текст и интерактивную среду. В интерактивной среде упразднить HTML и использовать язык а-ля TeX. В интерактивной среде использовать более-менее стандартный интерфейс для разных элементов (в который бы вошли tree, tab, ...) + обработчики событий + создание своих элементов управления. Но не сильно наворочено. И, желательно, без XML
Здравствуйте, Mamut, Вы писали:
M>Что, по вашему, должно быть в интернете такого, чтобы он был идеален? От браузеров до языков.
M>Мне, среди прочего, не хватает достаточно нативных расширямых виджетов типа tree, tab и т.п. А что не хватает вам?
Чего не хватает интернету? Известно чего. Семантики.
Социализм — это власть трудящихся и централизованная плановая экономика.
M>>Что, по вашему, должно быть в интернете такого, чтобы он был идеален? От браузеров до языков. V>Контент. Современному вебу остро не хватает вменяемого контента. Все прочее там есть.
Ну и вменяемого посика и способов нахожения этого контента Но не уверен, что эта зхадача решаема
Здравствуйте, Mamut, Вы писали:
M>Что, по вашему, должно быть в интернете такого, чтобы он был идеален? От браузеров до языков.
M>Мне, среди прочего, не хватает достаточно нативных расширямых виджетов типа tree, tab и т.п. А что не хватает вам?
M>>Что, по вашему, должно быть в интернете такого, чтобы он был идеален? От браузеров до языков.
M>>Мне, среди прочего, не хватает достаточно нативных расширямых виджетов типа tree, tab и т.п. А что не хватает вам?
L>Нормального языка для клиентских скриптов.
Здравствуйте, Vamp, Вы писали:
M>>Что, по вашему, должно быть в интернете такого, чтобы он был идеален? От браузеров до языков. V>Контент. Современному вебу остро не хватает вменяемого контента. Все прочее там есть.
Здравствуйте, Mamut, Вы писали:
L>>Нормального языка для клиентских скриптов.
M>Javascript достаточно хороший язык. Советую презентацию Javascript: the good stuff http://yuiblog.com/blog/2007/06/08/video-crockford-goodstuff/ и книгу этого же автра Javascript The Good Parts
Спасибо, читал. Он хорош для мелких скриптов, для чего-то большего не хватает как минимум модульности, типизированности.
A>-на десктопе — я не хочу знать что такое exe-шник и папки
Сделать это возможно, и никакого бинома ньютона тут нет — возьми апплефон. Ни экзешников, ни папок. Но на мой вкус, это ЖУТКО неудобно.
Здравствуйте, Vamp, Вы писали:
A>>-на десктопе — я не хочу знать что такое exe-шник и папки V>Сделать это возможно, и никакого бинома ньютона тут нет — возьми апплефон. Ни экзешников, ни папок. Но на мой вкус, это ЖУТКО неудобно.
На мой тоже. Однако же, большинство людей именно что знать не хотят ни про какие файлы и папки.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
E__>На мой тоже. Однако же, большинство людей именно что знать не хотят ни про какие файлы и папки.
Проблема в том, что IT идет по пути взаимного исключения — либо одно, либо другое. Если файлы и папки — то не слишком удобно, если нет файлов и папок — то нифига не понятно, как что-то делать с этим.
Идеальное устройство — это автомобиль. Хочешь — воспринимай его как руль и педали, хочешь — открой капот и там все есть.
Здравствуйте, Vamp, Вы писали:
V>Идеальное устройство — это автомобиль. Хочешь — воспринимай его как руль и педали, хочешь — открой капот и там все есть.
Не сказал бы, что оно идеально... Особенно, когда возникнет проблема добавить туда гусеничный ход
L>>>Нормального языка для клиентских скриптов.
M>>Javascript достаточно хороший язык. Советую презентацию Javascript: the good stuff http://yuiblog.com/blog/2007/06/08/video-crockford-goodstuff/ и книгу этого же автра Javascript The Good Parts
L>Спасибо, читал. Он хорош для мелких скриптов, для чего-то большего не хватает как минимум модульности, типизированности.
Я бы сказал, строгой типизации. Да, модульность было бы неплохо (хотя есть варианты решения, как, например, в Node.js)
Здравствуйте, LaPerouse, Вы писали:
LP>Здравствуйте, Mamut, Вы писали:
LP>>>Чего не хватает интернету? Известно чего. Семантики. M>>Имхо, нереально. Нельзя оъять необъятное.
LP>Никто не предлагает это делать
Не, ну почему же Можно организовать Министерство Правды (что-то вспомнилось, «кто ж на Плюке правду-то думает» ), новояз и вперед
M>>>Javascript достаточно хороший язык. Ц>>JS великолепный язык на самом деле
YKU>ИМХО единственное его достоинство в том, что он умеет выполняться на клиенте. Но и это к преимуществам именно языка отнести сложно.
Далеко не единственное. Поддержка и функциональщины и императивзины, например
Здравствуйте, Mamut, Вы писали:
M>Вот открываю я приложение по работе с документами, там мне и папки и полочки и документы. А зачем мне эти документы среди приложений
Опять же, приложений для работы с документами может быть несколько... Документы могут храниться в системе контроля версий или синхронизироваться с чем-либо. Усложнение системы разрушает идиллию...
M>Вот открываю я приложение по работе с документами, там мне и папки и полочки и документы. А зачем мне эти окументы среди приложений
А вот если ты вдруг хочешь скопировать этот документ на какое-то третье устройство — тут-то и оказывается, что хорошо бы это был файл. Или еще лучше — коллекцию своих документов (естественным образом организовываемую в папку) — но то место, куда ты это копируешь, не понимает папок в смысле твоего приложения по работе с документами (кстати, совершенно реальный случай с иТюнс)
Здравствуйте, yoriсk.kiev.ua, Вы писали:
YKU>ИМХО единственное его достоинство в том, что он умеет выполняться на клиенте. Но и это к преимуществам именно языка отнести сложно.
ну зачем же так? вы, наверное, очень плохо понимаете JavaScript
Здравствуйте, Mamut, Вы писали:
YKU>>ИМХО единственное его достоинство в том, что он умеет выполняться на клиенте. Но и это к преимуществам именно языка отнести сложно.
M>Далеко не единственное. Поддержка и функциональщины и императивзины, например
Да хреновая у него поддержка функциональщины. С таким громоздким синтаксисом "лямбд" уж проще циклами все писать.
Здравствуйте, Mamut, Вы писали:
M>Что, по вашему, должно быть в интернете такого, чтобы он был идеален? От браузеров до языков. M>Мне, среди прочего, не хватает достаточно нативных расширямых виджетов типа tree, tab и т.п. А что не хватает вам?
1) Отказ от всего зоопарка современных клиентских веб технологий, бо гора заплаток по сути.
2) Отказ от JS в пользу стандартной VM.
3) Разделение средств создания гипертекста и средств создания приложений. Для первого нужно что то с поддержкой качественной типографики и без груза совместимости, для второго что то навроде SL.
4) Вынесение понятия сессий на уровень стандартов и протоколов.
5) На том же уровне — нотификации.
Здравствуйте, Mamut, Вы писали:
M>Здравствуйте, LaPerouse, Вы писали: LP>>Здравствуйте, Mamut, Вы писали: LP>>>>Чего не хватает интернету? Известно чего. Семантики. M>>>Имхо, нереально. Нельзя оъять необъятное. LP>>Никто не предлагает это делать M>Не, ну почему же Можно организовать Министерство Правды (что-то вспомнилось, «кто ж на Плюке правду-то думает» ), новояз и вперед
Семантик веб — это лишь попытка найти способ выгрузки неявной семантики из головы людей в документ в машинном формате, чтобы сделать возможной автоматическую обработку информации.
Пример. Лента.ру, главная новость — "КНДР разорвала отношения с Южной Кореей". Для нас это предложение несет определенный смысл, в то время как для машины это лишь 39 символов UTF-8. Машина не может находить ответы на вопросы наподобие "с кем еще КНДР разорвала отношения за последний год" — по той простой причине, что семантика данных ей недоступна. Как же научить ее выполнять такого рода запросы? Есть два способа. Первый — разработать методику автоматического извлечения семантики из текста (требует по сути создания ИИ). Второй — снабжать информацию метаданными, которыми и будет задаваться семантическая модель данных. Последнее и есть Semantic Web.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, Mystic, Вы писали:
M>Опять же, приложений для работы с документами может быть несколько... Документы могут храниться в системе контроля версий или синхронизироваться с чем-либо. Усложнение системы разрушает идиллию...
YKU>>>ИМХО единственное его достоинство в том, что он умеет выполняться на клиенте. Но и это к преимуществам именно языка отнести сложно.
M>>Далеко не единственное. Поддержка и функциональщины и императивзины, например
L>Да хреновая у него поддержка функциональщины. С таким громоздким синтаксисом "лямбд" уж проще циклами все писать.
Что в нем громоздкого и предлагается взамен? Не лямбдами только жива императивщина
Здравствуйте, Цыба, Вы писали:
YKU>>ИМХО единственное его достоинство в том, что он умеет выполняться на клиенте. Но и это к преимуществам именно языка отнести сложно.
Ц>ну зачем же так? вы, наверное, очень плохо понимаете JavaScript
Ну, если вы хорошо так понимаете JS, обьясните чего у него хорошего. По сравнению с C#, например.
YKU>>>ИМХО единственное его достоинство в том, что он умеет выполняться на клиенте. Но и это к преимуществам именно языка отнести сложно.
Ц>>ну зачем же так? вы, наверное, очень плохо понимаете JavaScript
YKU>Ну, если вы хорошо так понимаете JS, обьясните чего у него хорошего. По сравнению с C#, например.
Здравствуйте, Mamut, Вы писали:
YKU>>>>ИМХО единственное его достоинство в том, что он умеет выполняться на клиенте. Но и это к преимуществам именно языка отнести сложно.
Ц>>>ну зачем же так? вы, наверное, очень плохо понимаете JavaScript
YKU>>Ну, если вы хорошо так понимаете JS, обьясните чего у него хорошего. По сравнению с C#, например.
M>Что именно будем сравнивать?
Ну, как что. Всё, чтобы доказать, что JS — это плохой C#
Бывают такие люди.
Здравствуйте, yoriсk.kiev.ua, Вы писали:
YKU>Ну, если вы хорошо так понимаете JS, обьясните чего у него хорошего. По сравнению с C#, например.
пынць, готово, приехали имея опыт разработки и на том и на другом, могу с уверенностью заявить, что люблю как шарп на сервере так и джаваскрипт на клиенте более того, никогда бы не согласился использовать сишарп на клиенте (за исключением сильверлайта разве), а вот на сервере какой-то бы джаваскрипт.нет я бы, наверное, хотел попробовать у вас не возникало мысли использовать сишарп, например, вместо батников, а то многие дальше пишут на нём?
YKU>>Ну, если вы хорошо так понимаете JS, обьясните чего у него хорошего. По сравнению с C#, например.
Ц>пынць, готово, приехали имея опыт разработки и на том и на другом, могу с уверенностью заявить, что люблю как шарп на сервере так и джаваскрипт на клиенте более того, никогда бы не согласился использовать сишарп на клиенте (за исключением сильверлайта разве), а вот на сервере какой-то бы джаваскрипт.нет я бы, наверное, хотел попробовать
Здравствуйте, Mamut, Вы писали:
L>>Да хреновая у него поддержка функциональщины. С таким громоздким синтаксисом "лямбд" уж проще циклами все писать.
M>Что в нем громоздкого и предлагается взамен?
Сравни с тем же C#-ом или Haskell-ем. Земля и небо.
M>Не лямбдами только жива императивщина
Про лямбды я писал в контексте функциональщины, императивщина тут непричем.
каюсь, не знал. я всегда, визуально встречая упоминание о node.js, думал, что это очередной клиентский фреймворк, какой-нибудь джейквери-киллер шейм он ми спасибо, интересно
L>>>Да хреновая у него поддержка функциональщины. С таким громоздким синтаксисом "лямбд" уж проще циклами все писать.
M>>Что в нем громоздкого и предлагается взамен?
L>Сравни с тем же C#-ом или Haskell-ем. Земля и небо.
Что сравнивать?
M>>Не лямбдами только жива императивщина
L>Про лямбды я писал в контексте функциональщины, императивщина тут непричем.
Сорри, хотел написать функциональщина. Вернемся к изначальному посылу:
Да хреновая у него поддержка функциональщины. С таким громоздким синтаксисом "лямбд" уж проще циклами все писать.
M>В коде различия становятся вообще достаточно слабоотличимы
M>
M> firstSmallNumbers = takeWhile (\x -> x >= index) [1..20]
M>var firstSmallNumbers = numbers.TakeWhile((n, index) => n >= index);
M>var firstSmallNumbers = numbers.TakeWhile(function(n, index){ return n >= index});
M>
Да, у этого чудесного функционального языка еще и стандартной библиотеки работы с функциями нет. Действительно, самый замечательный функциональный язык.
M>Учитывая, что JS лямбды — это частный случай ФВП вообще (и это правильно), то зачем для них требовать другого синтаксиса —
Затем, зачем я и писал — чтобы поддежка ФП была менее хреновой. Ты не согласен с тем, что поддержка ФП в шарпе/хаскеле лучше?
Здравствуйте, Цыба, Вы писали:
L>>Да, у этого чудесного функционального языка еще и стандартной библиотеки работы с функциями нет.
Ц>библиотеки или средств?
L>>>Да хреновая у него поддержка функциональщины. С таким громоздким синтаксисом "лямбд" уж проще циклами все писать.
M>>Что в нем громоздкого и предлагается взамен?
L>Сравни с тем же C#-ом или Haskell-ем. Земля и небо.
Что сравнивать?
M>>Не лямбдами только жива императивщина
L>Про лямбды я писал в контексте функциональщины, императивщина тут непричем.
Сорри, хотел написать функциональщина. Вернемся к изначальному посылу:
Да хреновая у него поддержка функциональщины. С таким громоздким синтаксисом "лямбд" уж проще циклами все писать.
M>>различаются только синтаксисом.
M>>В коде различия становятся вообще достаточно слабоотличимы
M>>
M>> firstSmallNumbers = takeWhile (\x -> x >= index) [1..20]
M>>var firstSmallNumbers = numbers.TakeWhile((n, index) => n >= index);
M>>var firstSmallNumbers = numbers.TakeWhile(function(n, index){ return n >= index});
M>>
L>Да, у этого чудесного функционального языка еще и стандартной библиотеки работы с функциями нет. Действительно, самый замечательный функциональный язык.
Как это относится к:
— поддержке ФП
— синтаксису?
M>>Учитывая, что JS лямбды — это частный случай ФВП вообще (и это правильно), то зачем для них требовать другого синтаксиса —
L>Затем, зачем я и писал — чтобы поддежка ФП была менее хреновой. Ты не согласен с тем, что поддержка ФП в шарпе/хаскеле лучше?
Чем лучше? Скажем, в том же C#'е, про Haskell знаю.
имелось в виду "если нет стандартной библиотеки". я провтыкал, извините
L>да хотя бы банальных map-ов, fold-ов, filter-ов
у C#, который здесь не раз упоминали, тоже нет ничего такого по сути, зато есть у .NET/LINQ. и то, появилось не сразу
все эти мэпы, фолды и фильтры просто реализуемы с помощью средств самого JavaScript
и если хуже с его стандартными библиотеками, то язык сам по себе от этого совсем не хуже
о хаскеле ничего не скажу, поскольку не имею опыта работы с ним
Здравствуйте, Mamut, Вы писали:
L>>>>Сравни с тем же C#-ом или Haskell-ем. Земля и небо. M>>>Что сравнивать? L>>Синтаксис лямбд.
M>Что это даст?
Более чистый и читаемый код, что же еще.
L>>Да, у этого чудесного функционального языка еще и стандартной библиотеки работы с функциями нет. Действительно, самый замечательный функциональный язык.
M>Как это относится к: M>- поддержке ФП M>- синтаксису?
Дабы не ходить вокруг да около, давай ты лучше сам расскажешь, чем так хороша поддержка ФП в javascript-е.
M>>>Учитывая, что JS лямбды — это частный случай ФВП вообще (и это правильно), то зачем для них требовать другого синтаксиса —
L>>Затем, зачем я и писал — чтобы поддежка ФП была менее хреновой. Ты не согласен с тем, что поддержка ФП в шарпе/хаскеле лучше?
M>Чем лучше? Скажем, в том же C#'е, про Haskell знаю.
Здравствуйте, Цыба, Вы писали:
L>>да хотя бы банальных map-ов, fold-ов, filter-ов
Ц>у C#, который здесь не раз упоминали, тоже нет ничего такого по сути, зато есть у .NET/LINQ.
А они (C# и .NET/LINQ) существуют отдельно? Ссылочку не подкинете,
Ц>и то, появилось не сразу
И что с того, в js аналогов и сейчас нет
Ц>все эти мэпы, фолды и фильтры просто реализуемы с помощью средств самого JavaScript
ну да, ну да. если уж на то пошло, то все тьюринг-полные языки эквивалентны и спорить дествительно не о чем.
Ц>и если хуже с его стандартными библиотеками, то язык сам по себе от этого совсем не хуже
хуже. отвратительный синтаксис лямб приводит к нечитаемому коду. и программист, который заботится о поддерживаемости своего кода, трижды подумает прежде чем станет писать в функциональном стиле на js-е.
Здравствуйте, Цыба, Вы писали:
L>>а то и просто var c = (*);
Ц>это не могу уже знать, но подозреваю, что это просто ссылка на функцию умножения с шарпа просто взял, поскольку почти своё-родное
не, для шарпа это вообще кекорректный код. это был типа псевдо-хаскель.
L>>>>>Сравни с тем же C#-ом или Haskell-ем. Земля и небо. M>>>>Что сравнивать? L>>>Синтаксис лямбд.
M>>Что это даст?
L>Более чистый и читаемый код, что же еще.
Не даст. Примеры я приводил. В яваскрипте анонимные функции/лямбды используются повсеместно, а не только для написания кортких однострочных мыслей. Что не мешает, естественно, использовать их и для достаточно коротких вещей.
L>>>Да, у этого чудесного функционального языка еще и стандартной библиотеки работы с функциями нет. Действительно, самый замечательный функциональный язык.
M>>Как это относится к: M>>- поддержке ФП M>>- синтаксису?
L>Дабы не ходить вокруг да около, давай ты лучше сам расскажешь, чем так хороша поддержка ФП в javascript-е.
Стоп. В роли обвинения выступешь ты. Пока что от тебя было:
— аяяяй, синтаксис (к поддержке ФВП не имеет отношения)
— аяяяй, нет стандартной библиотеки (к поддержке ФВП не имеет отношения)
M>>>>Учитывая, что JS лямбды — это частный случай ФВП вообще (и это правильно), то зачем для них требовать другого синтаксиса —
L>>>Затем, зачем я и писал — чтобы поддежка ФП была менее хреновой. Ты не согласен с тем, что поддержка ФП в шарпе/хаскеле лучше?
M>>Чем лучше? Скажем, в том же C#'е, про Haskell знаю.
L>Чем в javascript.
Ц>>и то, появилось не сразу L>И что с того, в js аналогов и сейчас нет
Есть. Там где надо (в jQuery, например)
Ц>>и если хуже с его стандартными библиотеками, то язык сам по себе от этого совсем не хуже
L>хуже. отвратительный синтаксис лямб приводит к нечитаемому коду. и программист, который заботится о поддерживаемости своего кода, трижды подумает прежде чем станет писать в функциональном стиле на js-е.
Странно, миллионы программистов используют ФП в JS и не парятся, а Lloyd трижды думает
*ушел писать при помощи насквозь функционального jQuery...*
Здравствуйте, Lloyd, Вы писали:
L>А они (C# и .NET/LINQ) существуют отдельно? Ссылочку не подкинете,
на практике — нет, но мы говорим именно о языках ведь? а если не существуют отдельно, я подозреваю, тогда и VB.NET значительно более функционален по своей природе, нежели JavaScript, куда там F# до бэйсика
L>И что с того, в js аналогов и сейчас нет
снова же, существует готовый нестандартизированный JSLINQ, например, но речь не об этом
L>ну да, ну да. если уж на то пошло, то все тьюринг-полные языки эквивалентны и спорить дествительно не о чем.
не спорю
L>хуже. отвратительный синтаксис лямб приводит к нечитаемому коду. и программист, который заботится о поддерживаемости своего кода, трижды подумает прежде чем станет писать в функциональном стиле на js-е.
я вчера, кстати, упоминал о том, что мне не нравится такой синтаксис лямбд. это сильно заметно при использовании того же JSLINQ, а если потом ещё и автоматически отформатировать исходный код, где вызываются .Where(), .Select() и прочее — все эти методы становятся, чего греха таить, жутко нечитабельными. я же говорю, что этот момент я бы сам хотел усовершенствовать
Здравствуйте, Mamut, Вы писали:
L>>Дабы не ходить вокруг да около, давай ты лучше сам расскажешь, чем так хороша поддержка ФП в javascript-е.
M>Стоп. В роли обвинения выступешь ты. Пока что от тебя было: M>- аяяяй, синтаксис (к поддержке ФВП не имеет отношения) M>- аяяяй, нет стандартной библиотеки (к поддержке ФВП не имеет отношения)
Гм. Синткасис и библиотеки не относятся. Что же тогда относится-то?
Здравствуйте, Mamut, Вы писали:
Ц>>>и то, появилось не сразу L>>И что с того, в js аналогов и сейчас нет
M>Есть. Там где надо (в jQuery, например)
уныло там все с этим.
L>>хуже. отвратительный синтаксис лямб приводит к нечитаемому коду. и программист, который заботится о поддерживаемости своего кода, трижды подумает прежде чем станет писать в функциональном стиле на js-е.
M>Странно, миллионы программистов используют ФП в JS и не парятся, а Lloyd трижды думает
M>*ушел писать при помощи насквозь функционального jQuery...*
jQuery исползуют в большинстве своем из-за удобного синтаксиса селекоторов, а не из-за того, что он "функционален". выброси оттуда селекторы и миллионы программистов сразу куда-то испарятся.
L>>>Дабы не ходить вокруг да около, давай ты лучше сам расскажешь, чем так хороша поддержка ФП в javascript-е.
M>>Стоп. В роли обвинения выступешь ты. Пока что от тебя было: M>>- аяяяй, синтаксис (к поддержке ФВП не имеет отношения) M>>- аяяяй, нет стандартной библиотеки (к поддержке ФВП не имеет отношения)
L>Гм. Синткасис и библиотеки не относятся. Что же тогда относится-то?
Для полноценной поддержки ФП языку нужно что? (это вопрос «на засыпку»)
Синтаксис в стиле (x, y) -> return_value? Это все равно, как сказать, что для поддержки ООП обязательно нужнен С-подобный синтаксис.
Стандартная библиотека? Сорри, но только в С++ стандартная библиотека включена в спецификацию языка. От отсутсвия Prelude Haskell не становится менее функциональным. Чем ФП в C# лучше, чем в JS ты так и не ответил.
Ц>>>>и то, появилось не сразу L>>>И что с того, в js аналогов и сейчас нет
M>>Есть. Там где надо (в jQuery, например)
L>уныло там все с этим.
Нормально. Не больше и не меньше, чем нужно.
// http://erlanger.ru/lib/js/init.js
$('span.rss-url').each(
function(){
var url = $(this).html();
var parent = $(this).parent();
var feed = new google.feeds.Feed(url);
feed.load(function(result){
//что-то там
});
}
);
$('pre').filter(
function(){
return $(this).attr('class') == '';
}
).addClass('brush: plain');
сплошная функциональщина.
L>>>хуже. отвратительный синтаксис лямб приводит к нечитаемому коду. и программист, который заботится о поддерживаемости своего кода, трижды подумает прежде чем станет писать в функциональном стиле на js-е.
M>>Странно, миллионы программистов используют ФП в JS и не парятся, а Lloyd трижды думает
M>>*ушел писать при помощи насквозь функционального jQuery...*
L>jQuery исползуют в большинстве своем из-за удобного синтаксиса селекоторов, а не из-за того, что он "функционален". выброси оттуда селекторы и миллионы программистов сразу куда-то испарятся.
Какая разница? Функциональный подход там спокойно себе есть. Даже в банальном
body.onload = function(){
// что-то там
};
он был N лет.
миллионы программистов используют ФП в JS и не парятся, а Lloyd трижды думает
Здравствуйте, Mamut, Вы писали:
L>>Гм. Синткасис и библиотеки не относятся. Что же тогда относится-то?
M>Для полноценной поддержки ФП языку нужно что? (это вопрос «на засыпку»)
Считай, что я засыпался. Если не сложно, ответь на вопрос.
Здравствуйте, Mamut, Вы писали:
M>Нормально. Не больше и не меньше, чем нужно.
уныло. сравни с тем же линком из шарпа.
M>сплошная функциональщина.
M>>>*ушел писать при помощи насквозь функционального jQuery...*
L>>jQuery исползуют в большинстве своем из-за удобного синтаксиса селекоторов, а не из-за того, что он "функционален". выброси оттуда селекторы и миллионы программистов сразу куда-то испарятся.
M>Какая разница? Функциональный подход там спокойно себе есть. Даже в банальном
Есть. Уверен, что там в коде jquery можно и goto найти. Но означает ли это, что миллионы программистов пользуются этой библиотекой из-за наличния в ней goto?
L>>>Гм. Синткасис и библиотеки не относятся. Что же тогда относится-то?
M>>Для полноценной поддержки ФП языку нужно что? (это вопрос «на засыпку»)
L>Считай, что я засыпался. Если не сложно, ответь на вопрос.
Вообще-то, всего лишь функций высшего порядка и functions as first-class objects Ах да, и рекурсия (спасибо википедии за напоминание)
Синтаксис вообще к этому не имеет никакого отноенния. map/fold/filter и т.п. ты сам сказал, что реализуется в библиотеке (и насквозь функциональный Haskell это подтверждает).
M>>Нормально. Не больше и не меньше, чем нужно.
L>уныло. сравни с тем же линком из шарпа.
уныло. сравни с тем же Functional из Javascript'а Да хотя бы с тем же Prelude из Haskell'а
Ну что за ребячество?
M>>сплошная функциональщина.
M>>>>*ушел писать при помощи насквозь функционального jQuery...*
L>>>jQuery исползуют в большинстве своем из-за удобного синтаксиса селекоторов, а не из-за того, что он "функционален". выброси оттуда селекторы и миллионы программистов сразу куда-то испарятся.
M>>Какая разница? Функциональный подход там спокойно себе есть. Даже в банальном
L>Есть. Уверен, что там в коде jquery можно и goto найти. Но означает ли это, что миллионы программистов пользуются этой библиотекой из-за наличния в ней goto?
Нет. Повторю еще раз. В придуманном тобой мире в ФП-подход в javascripte мало кто использует («программист трижды подумает, ага»). В реальном мире его используют миллионы (иногда даже не догадываясь об это, кстати).
Здравствуйте, Mamut, Вы писали:
L>>Считай, что я засыпался. Если не сложно, ответь на вопрос.
M>Вообще-то, всего лишь функций высшего порядка и functions as first-class objects Ах да, и рекурсия (спасибо википедии за напоминание)
Это как бы необходимое условие, чтобы язык имел право называться функциональным. Этим критериям js удовлетворяет, не спорю.
Когда я писал, что он хреново поддерживает ФП, я имел в виду, что писать в функциональном стиле на js неудобно и зачастую аналогичный императивный код выглядит лучше и понятнее. Причина этого неудобства, имхо, в громоздком синтаксисе лямбд и отсутствии стандартной библиотеки.
Здравствуйте, Mamut, Вы писали:
L>>уныло. сравни с тем же линком из шарпа.
M>уныло. сравни с тем же Functional из Javascript'а Да хотя бы с тем же Prelude из Haskell'а
Спасибо, конечно, но зашивать "функции" в строки большого ума не надо. Этак и в С можно подключить интерпретатор питона.
M>Ну что за ребячество?
И в самом деле.
L>>Есть. Уверен, что там в коде jquery можно и goto найти. Но означает ли это, что миллионы программистов пользуются этой библиотекой из-за наличния в ней goto?
M>Нет. Повторю еще раз. В придуманном тобой мире в ФП-подход в javascripte мало кто использует («программист трижды подумает, ага»). В реальном мире его используют миллионы (иногда даже не догадываясь об это, кстати).
Повторю еще раз. jQuery в реальном случае используют из-за удобных селекторов, а не из-за наличия в нем ФП-подхода.
L>>>уныло. сравни с тем же линком из шарпа.
M>>уныло. сравни с тем же Functional из Javascript'а Да хотя бы с тем же Prelude из Haskell'а
L>Спасибо, конечно, но зашивать "функции" в строки большого ума не надо. Этак и в С можно подключить интерпретатор питона.
And all these functions accept strings, such as 'x -> x+1', 'x+1', or '+1' as synonyms for the more verbose function(x) {return x+1}.
Ты не поверишь, но обыкновенные функции он тоже принимает.
L>>>Есть. Уверен, что там в коде jquery можно и goto найти. Но означает ли это, что миллионы программистов пользуются этой библиотекой из-за наличния в ней goto?
M>>Нет. Повторю еще раз. В придуманном тобой мире в ФП-подход в javascripte мало кто использует («программист трижды подумает, ага»). В реальном мире его используют миллионы (иногда даже не догадываясь об это, кстати).
L>Повторю еще раз. jQuery в реальном случае используют из-за удобных селекторов, а не из-за наличия в нем ФП-подхода.
Повторю в третий раз, уже другими словами. Даже без jQuery функциональщина в JS ыла, есть и будет.
Здравствуйте, Mamut, Вы писали:
L>>Спасибо, конечно, но зашивать "функции" в строки большого ума не надо. Этак и в С можно подключить интерпретатор питона.
M>
M>And all these functions accept strings, such as 'x -> x+1', 'x+1', or '+1' as synonyms for the more verbose function(x) {return x+1}.
M>Ты не поверишь, но обыкновенные функции он тоже принимает.
Ты не поверишь, но с этим синтаксисом мы опять приходим к озвученой ранее проблеме громоздкого синтаксиса. Btw, задумайся, зачем они сделали возможность передавать строки, там где можно использовать функции.
M>>>Нет. Повторю еще раз. В придуманном тобой мире в ФП-подход в javascripte мало кто использует («программист трижды подумает, ага»). В реальном мире его используют миллионы (иногда даже не догадываясь об это, кстати).
L>>Повторю еще раз. jQuery в реальном случае используют из-за удобных селекторов, а не из-за наличия в нем ФП-подхода.
M>Повторю в третий раз, уже другими словами. Даже без jQuery
Ок. Согласился-таки, что jQuery ты приплел не в тему. Уже лучше.
M>функциональщина в JS ыла, есть и будет.
С этим никто и не соприт. Я писал, что она там хреновая, а значит она там-таки есть.
V>А вот если ты вдруг хочешь скопировать этот документ на какое-то третье устройство — тут-то и оказывается, что хорошо бы это был файл. Или еще лучше — коллекцию своих документов (естественным образом организовываемую в папку) — но то место, куда ты это копируешь, не понимает папок в смысле твоего приложения по работе с документами (кстати, совершенно реальный случай с иТюнс)
А что значит скопировать?
Твои документы должны быть доступны только тебе на всех устройствах которыми ты пользуешься,
ровно в том виде и версии, которые ты оставил в последний раз.
L>Когда я писал, что он хреново поддерживает ФП, я имел в виду, что писать в функциональном стиле на js неудобно и зачастую аналогичный императивный код выглядит лучше и понятнее. Причина этого неудобства, имхо, в громоздком синтаксисе лямбд и отсутствии стандартной библиотеки.
Насчет громоздкости. Это, скорее, во благо, чем во зло.
Потому что чем отличается лямбда от функции? Да ничем, абсолютно. При этом в C#, например, они используют абсолютно разный синтаксис.
В JS лямбды/анонимные функции используются повсеместно (примеры я уже приводил), наравне с обычными функциями. Зачем им другой синтаксис в таких условиях — непонятно.
Здравствуйте, Цыба, Вы писали:
Ц>Здравствуйте, Mamut, Вы писали:
M>>Чем? Если брать практическиеприменения, то скорее даже хуже.
Ц>эээ, я, наверно, не совсем то имел в виду. возьмём практический подход, например, к JSLINQ. фильтрация следующим образом, вроде, более-менее читаема:
Ц>
Ц>(*) дефолтный автоформаттер того же Intellij Idea уродливо форматирует это выражение так, впрочем подобное форматирование применяется повсеместно:
Ц>
ND>Твои документы должны быть доступны только тебе на всех устройствах которыми ты пользуешься, ND>ровно в том виде и версии, которые ты оставил в последний раз.
Это красиво звучит, но трудно реализуемо.
Здравствуйте, Mamut, Вы писали:
M>>>функциональщина в JS ыла, есть и будет. L>>С этим никто и не соприт. Я писал, что она там хреновая, а значит она там-таки есть.
M>Причем хреновость у тебя упирается только в синтаксис и библиотеки. Это несерьезно
А что может быть "серьезно"? Самого факта наличия функциий высшего порядка, имхо, недостаточно.
Здравствуйте, Mamut, Вы писали:
L>>Когда я писал, что он хреново поддерживает ФП, я имел в виду, что писать в функциональном стиле на js неудобно и зачастую аналогичный императивный код выглядит лучше и понятнее. Причина этого неудобства, имхо, в громоздком синтаксисе лямбд и отсутствии стандартной библиотеки.
M>Насчет громоздкости. Это, скорее, во благо, чем во зло.
Несогласен.
M>Потому что чем отличается лямбда от функции? Да ничем, абсолютно. При этом в C#, например, они используют абсолютно разный синтаксис.
В теории все верно, на практике удобнее использовать раткий синтаксис.
M>В JS лямбды/анонимные функции используются повсеместно (примеры я уже приводил), наравне с обычными функциями. Зачем им другой синтаксис в таких условиях — непонятно.
Expression closures (Merge into own page/section)
This addition is nothing more than a shorthand for writing simple functions, giving the language something similar to a typical Lambda notation.
JavaScript 1.7 and older:
function(x) { return x * x; }
JavaScript 1.8:
function(x) x * x
This syntax allows you to leave off the braces and 'return' statement — making them implicit. There is no added benefit to writing code in this manner, other than having it be syntactically shorter.
вот оно, пожалуй, II больше не будет так форматировать предикаты
Здравствуйте, Цыба, Вы писали:
Ц>>>я просто полюбил javascript и незаметную на первый взгляд его мощь L>>подробнее, если не затруднит.
Ц>т.е., вы не считаете JS мощным языком?
Здравствуйте, Lloyd, Вы писали:
Ц>>т.е., вы не считаете JS мощным языком? L>По сравнению с C#-ом? Нет, не считаю.
почему сразу "по сравнению с C#"? сразу же: я говорил, исходя личных предпочтений, о том, что C# я бы не променял на сервере на что либо другое. это дело привычки и личных предпочтений. я обожаю C# на самом деле, и это можно увидеть даже в моей подписи. и я бы не променял на клиентской стороне JavaScript на другие языки, и был бы только за его дальнейшее развитие. об этом я и писал выше. мне трудно представить, по крайней мере, в нынешнее время использование традиционно компилируемого языка в браузере, пусть он бы компилировался/интерпретировался в фоне. это не важно — компилировать/оптимизировать/etc в таких случаях можно, что успешно и делается. важна суть используемого языка, и мне нравится довольно таки краткий синтаксис JavaScript (хотя иногда я ненавижу его за казалось бы слишком громоздкие конструкции), мне нравится, что в его базовом варианте существует лишь несколько объектов, и мне нравится что я могу манипулировать ими как угодно, мне нравятся прототипы и т.д. и т.п. я повёлся на ваш вопрос и, надеюсь, ответил на него
Здравствуйте, Цыба, Вы писали:
L>>По сравнению с C#-ом? Нет, не считаю.
Ц>почему сразу "по сравнению с C#"?
Потому что вы сказали, что не променяли бы js на C#. Потому я и спросил.
Ц>и я бы не променял на клиентской стороне JavaScript на другие языки, и был бы только за его дальнейшее развитие. об этом я и писал выше.
Ц>мне трудно представить, по крайней мере, в нынешнее время использование традиционно компилируемого языка в браузере, пусть он бы компилировался/интерпретировался в фоне. это не важно — компилировать/оптимизировать/etc в таких случаях можно, что успешно и делается.
Как-то не вяжутся эти 2 фразы: "трудно представить" и тут же "что успешно и делается". Как это у вас одновременно в голове уживается?
Ц>важна суть используемого языка, и мне нравится довольно таки краткий синтаксис JavaScript (хотя иногда я ненавижу его за казалось бы слишком громоздкие конструкции),
синтаксис js-а не кратче, чем C#-а.
Ц>мне нравится, что в его базовом варианте существует лишь несколько объектов,
Same shit и в шарпе.
Ц>и мне нравится что я могу манипулировать ими как угодно,
Что тут имеется в виду?
Ц>мне нравятся прототипы и т.д. и т.п. я повёлся на ваш вопрос и, надеюсь, ответил на него
Увы, нет. Кроме прототипов ни одного аргумента за js не было.
M>>Потому что чем отличается лямбда от функции? Да ничем, абсолютно. При этом в C#, например, они используют абсолютно разный синтаксис.
L>В теории все верно, на практике удобнее использовать раткий синтаксис.
M>>В JS лямбды/анонимные функции используются повсеместно (примеры я уже приводил), наравне с обычными функциями. Зачем им другой синтаксис в таких условиях — непонятно.
L>Читабельность лучше.
$('span.rss-url').each(function(){
var url = $(this).html();
var parent = $(this).parent();
var feed = new google.feeds.Feed(url);
feed.load(function(result){
if(result.error) {
var div = $('<div class="item"></div>');
div.appendTo(parent);
div.append('Не удалось получить RSS с ' + url);
return;
}
for(i = 0; i < 10 && i < result.feed.entries.length; i++){
var div = $('<div class="item"></div>');
div.appendTo(parent);
var item = result.feed.entries[i];
div.append('<'+headerElement+'><a href="'+item.link+'">'+item.title+'</a></'+headerElement+'>'+item.content);
div.find('p:gt(0), p+div').hide();
if(div.find('p').length > 1) div.find('p:eq(0)').append(' ...');
}
});
}
);
против:
$('span.rss-url').each(() => {
var url = $(this).html();
var parent = $(this).parent();
var feed = new google.feeds.Feed(url);
feed.load((result) => {
if(result.error) {
var div = $('<div class="item"></div>');
div.appendTo(parent);
div.append('Не удалось получить RSS с ' + url);
return;
}
for(i = 0; i < 10 && i < result.feed.entries.length; i++){
var div = $('<div class="item"></div>');
div.appendTo(parent);
var item = result.feed.entries[i];
div.append('<'+headerElement+'><a href="'+item.link+'">'+item.title+'</a></'+headerElement+'>'+item.content);
div.find('p:gt(0), p+div').hide();
if(div.find('p').length > 1) div.find('p:eq(0)').append(' ...');
}
});
}
);
Ц>>мне нравится, что в его базовом варианте существует лишь несколько объектов, L>Same shit и в шарпе.
Только вот C# навязывает ООП Чисто процедурно там не попишешь.
Ц>>мне нравятся прототипы и т.д. и т.п. я повёлся на ваш вопрос и, надеюсь, ответил на него L>Увы, нет. Кроме прототипов ни одного аргумента за js не было.
JS позволяет тебе писать в любом удобном тебе стиле/парадигме. И позволяет легко смешивать их друг с другом.
Кго минусы — это свосем не синтаксис и свосем не отсутствие стандартной библиотеки.
— строгая типизация была бы плюсом (=== там появилось не от хорошей жизни)
— автоматическая подстановка ";" — это зло
— отсутствие внятного scope для функций — это зло
В общем все это можно у Crockford'а в javascript the good stuff увидеть.
В общем, этакий Nemerle, но без статической типизации и мтапрограммирования
M>>Читабильность становится еще сомнительнее. Особенно если объекты растут в размерах
L>А не надо приводить примеры, где лябды на полэкрана, тогда увидишь, где читабельность.
Повторю в пятый раз. В JS нет разницы между лямбдой, анонимной функцией и функцией вообще. И то и другое и третье — это просто функция
Здравствуйте, Lloyd, Вы писали:
L>Потому что вы сказали, что не променяли бы js на C#. Потому я и спросил.
ок L>Как-то не вяжутся эти 2 фразы: "трудно представить" и тут же "что успешно и делается". Как это у вас одновременно в голове уживается? JS же оптимизируется во время исполнения, а C# я не представляю вместо JS — вот и ужилось L>синтаксис js-а не кратче, чем C#-а.
спорно Ц>>мне нравится, что в его базовом варианте существует лишь несколько объектов, L>Same shit и в шарпе.
нет, вы сказали, что C# и .NET (а посему и BCL) неразлучны, то будем считать, что далеко не пару объектов, а целый пакован классов. или это имеются в виду алиасы на производные структуры от System.ValueType, а также System.String и System.Object (включительно с BCL-зависимыми foreach/throw/catch...)? Ц>>и мне нравится что я могу манипулировать ими как угодно, L>Что тут имеется в виду?
да простое манипулирование объектами и его свойствами же, этц. тот же
спасает как от тех, кто алертами дальше пользуется в целях дебага, так и в грисманки на алертолюбивых сайтах (да-да, слабый пример, соглашусь) Ц>>мне нравятся прототипы и т.д. и т.п. я повёлся на ваш вопрос и, надеюсь, ответил на него L>Увы, нет. Кроме прототипов ни одного аргумента за js не было.
пусть. впрочем, если я лично не могу ответить так, как вы того хотите, от этого JS не станет хуже
Здравствуйте, Mamut, Вы писали:
Ц>>>мне нравится, что в его базовом варианте существует лишь несколько объектов, L>>Same shit и в шарпе.
M>Только вот C# навязывает ООП Чисто процедурно там не попишешь.
+1. Это тоже может быть записано в плюсы js-у.
Ц>>>мне нравятся прототипы и т.д. и т.п. я повёлся на ваш вопрос и, надеюсь, ответил на него L>>Увы, нет. Кроме прототипов ни одного аргумента за js не было.
M>JS позволяет тебе писать в любом удобном тебе стиле/парадигме. И позволяет легко смешивать их друг с другом.
Здравствуйте, Mamut, Вы писали:
L>>А не надо приводить примеры, где лябды на полэкрана, тогда увидишь, где читабельность.
M>Повторю в пятый раз. В JS нет разницы между лямбдой, анонимной функцией и функцией вообще. И то и другое и третье — это просто функция
Не надо повторять. Просто напиши что я предложил и посмотри на код, сам все поймешь. Удачи.
L>>>А не надо приводить примеры, где лябды на полэкрана, тогда увидишь, где читабельность.
M>>Повторю в пятый раз. В JS нет разницы между лямбдой, анонимной функцией и функцией вообще. И то и другое и третье — это просто функция
L>Не надо повторять. Просто напиши что я предложил и посмотри на код, сам все поймешь. Удачи.
Что ты предложил? Ты предложил map/fold и т.п.?
Я тебе тоже предложил, причем примеры из реальной жизни. Ты почему-то решил отмести их напрочь.
Здравствуйте, Цыба, Вы писали:
L>>Как-то не вяжутся эти 2 фразы: "трудно представить" и тут же "что успешно и делается". Как это у вас одновременно в голове уживается? Ц> JS же оптимизируется во время исполнения, а C# я не представляю вместо JS — вот и ужилось
Это просто песня какая-то. Где связь м/у оптимизацией js и тем, что ты не представляешь C# на его месте?
L>>синтаксис js-а не кратче, чем C#-а. Ц>спорно
Если спорно, приведи пример, где он кратче.
Ц>>>мне нравится, что в его базовом варианте существует лишь несколько объектов, L>>Same shit и в шарпе. Ц>нет, вы сказали, что C# и .NET (а посему и BCL) неразлучны, то будем считать, что далеко не пару объектов, а целый пакован классов. или это имеются в виду алиасы на производные структуры от System.ValueType, а также System.String и System.Object (включительно с BCL-зависимыми foreach/throw/catch...)?
Да, именно они (+ линк). Все остально — часть библиотеки.
Ц>>>и мне нравится что я могу манипулировать ими как угодно, L>>Что тут имеется в виду? Ц>да простое манипулирование объектами и его свойствами же, этц. тот же Ц>
Здравствуйте, Mamut, Вы писали:
L>>Не надо повторять. Просто напиши что я предложил и посмотри на код, сам все поймешь. Удачи.
M>Что ты предложил? Ты предложил map/fold и т.п.? M>Я тебе тоже предложил, причем примеры из реальной жизни. Ты почему-то решил отмести их напрочь.
Ты сравниваешь синтаксис лямбд в шарпе и jsvscript-е и утверждаешь, что он в js не хуже и при этом обосновываешь этот вывод на примере, где лямбда — большая. И из этого частного случая делаешь общий вывод. Это некорректно, нужно рассматривать не частные случаи, а все случаи. Если ты перепишешь свой же код, вынеся функционал высасывания rss-а в отдельную функцию и будешь использовать ее в each-е, то ты заметишь громоздкость синтаксиса лямб в js.
Здравствуйте, Цыба, Вы писали:
L>>Если спорно, приведи пример, где он кратче.
Ц>var F = function(){}; // лямбду в шарпе так нельзя
можно
Ц>var A = [];
new List<object>();?
Ц>var O = {};
Что это?
Ц>описание объектов, методов, этц
Ц>и это как минимум
Слабовато как-то.
L>>в свете появления dynamic в шарпе, это уже не исключительно преимущество js-а.
Ц>динамика никогда не являлась свойством исключительно джаваскрипта
Зачем тогда приводить это как его преимущество перед шарпом?
Здравствуйте, Mamut, Вы писали:
L>>А C#?
M>Процедурное программирование, например
Ты имеешь в виду, что нельзя объявить методы вне класса или что-то другое? Если это, то воспринимай это просто как своего рода namespace.
M>И, насколько я помню, функции все же не first-class objects в C#
Здравствуйте, Lloyd, Вы писали:
Ц>>var F = function(){}; // лямбду в шарпе так нельзя L>можно
нельзя с выводом типа
CS0815: Cannot assign lambda expression to an implicitly-typed local variable
+ не нужно возиться с делегатами
Ц>>var A = []; L>new List<object>();?
грубо говоря, да
Ц>>var O = {}; L>Что это?
похоже на var O = new Object(); в C#
Ц>>описание объектов, методов, этц Ц>>и это как минимум L>Слабовато как-то.
что именно слабовато в описании объектов и методов в JS?
L>>>в свете появления dynamic в шарпе, это уже не исключительно преимущество js-а. Ц>>динамика никогда не являлась свойством исключительно джаваскрипта L>Зачем тогда приводить это как его преимущество перед шарпом?
а слишком давно ли вышел динамический 4.0 в шарпе? хотя да, мы лучше мы со временем обвешаем шарп всем-всем-всем, чтобы его можно было использовать везде
Здравствуйте, Цыба, Вы писали:
Ц>>>var F = function(){}; // лямбду в шарпе так нельзя L>>можно
Ц>нельзя с выводом типа Ц>CS0815: Cannot assign lambda expression to an implicitly-typed local variable
Да, тип добавить нужно. это минус
Ц>+ не нужно возиться с делегатами
Не нужно
Ц>>>var A = []; L>>new List<object>();?
Ц>грубо говоря, да
Ок.
Ц>>>var O = {}; L>>Что это?
Ц>похоже на var O = new Object(); в C#
Гм. Это преимущество js-а?
Ц>>>описание объектов, методов, этц Ц>>>и это как минимум L>>Слабовато как-то.
Ц>что именно слабовато в описании объектов и методов в JS?
а что именно сильно по сравнению с C#-ом?
L>>>>в свете появления dynamic в шарпе, это уже не исключительно преимущество js-а. Ц>>>динамика никогда не являлась свойством исключительно джаваскрипта L>>Зачем тогда приводить это как его преимущество перед шарпом?
Ц>а слишком давно ли вышел динамический 4.0 в шарпе? хотя да, мы лучше мы со временем обвешаем шарп всем-всем-всем, чтобы его можно было использовать везде
Недавно вышел. Если учитывать dynamic в 4-м шарпе, остаются какие-либо преимущества js-а или нет?
Здравствуйте, Lloyd, Вы писали:
Ц>>+ не нужно возиться с делегатами L>Не нужно
возможно, вы имеете в виду, если не ошибаюсь, Action, Func?.. если не вы, значит за вас
L>Гм. Это преимущество js-а?
я же сказал: одно из
спрашивать меня это сейчас — это всё-равно, что я бы спрашивал вас "ну неужели (x,y)=>x+y*2 лучше function(x,y){return x+y*2;}?"
Ц>>что именно слабовато в описании объектов и методов в JS?
Lloyd?
L>Недавно вышел. Если учитывать dynamic в 4-м шарпе, остаются какие-либо преимущества js-а или нет?
да, нет нужды даже в урезанном BCL, на котором даже обычный foreach стоит (foreach-foreach, мы же ведь о языках)
Здравствуйте, Цыба, Вы писали:
Ц>>>+ не нужно возиться с делегатами L>>Не нужно
Ц>возможно, вы имеете в виду, если не ошибаюсь, Action, Func?.. если не вы, значит за вас
но тем не менее не нужно
L>>Гм. Это преимущество js-а?
Ц>я же сказал: одно из
если "var O = {}" — аналог "var O = new Object()", то почему он считается преимуществом? Или вы что-то недоговариваете, или...
Ц>спрашивать меня это сейчас — это всё-равно, что я бы спрашивал вас "ну неужели (x,y)=>x+y*2 лучше function(x,y){return x+y*2;}?"
Не вижу ничего общего, если честно.
Ц>>>что именно слабовато в описании объектов и методов в JS?
Ц>Lloyd?
Тьфу, в шарпе.
L>>Недавно вышел. Если учитывать dynamic в 4-м шарпе, остаются какие-либо преимущества js-а или нет?
Ц>да, нет нужды даже в урезанном BCL, на котором даже обычный foreach стоит (foreach-foreach, мы же ведь о языках)
а js видимо святым духом выполняется и в нем нет ни string-ов, ни Array-ев. В чем ткое коренное отличие-то?
Здравствуйте, Mystic, Вы писали:
M>Здравствуйте, Vamp, Вы писали:
V>>Идеальное устройство — это автомобиль. Хочешь — воспринимай его как руль и педали, хочешь — открой капот и там все есть.
M>Не сказал бы, что оно идеально... Особенно, когда возникнет проблема добавить туда гусеничный ход
Это ж разве проблема...
¯\_(ツ)_/¯
И когда они были в поле, восстал Каин на Авеля, брата своего, и убил его.
Здравствуйте, Lloyd, Вы писали:
L>но тем не менее не нужно
значит, я не знаю чего-то. my bad. могли бы и указать — я бы вспомнил хоть
L>если "var O = {}" — аналог "var O = new Object()", то почему он считается преимуществом? Или вы что-то недоговариваете, или... Ц>>спрашивать меня это сейчас — это всё-равно, что я бы спрашивал вас "ну неужели (x,y)=>x+y*2 лучше function(x,y){return x+y*2;}?" L>Не вижу ничего общего, если честно.
а я вижу. причём даже очень ясно. и вы, пожалуй. лукавите, что "не видите". краткий синтаксис ведь — наше всё сегодня. да или нет?
L>>>Недавно вышел. Если учитывать dynamic в 4-м шарпе, остаются какие-либо преимущества js-а или нет? Ц>>да, нет нужды даже в урезанном BCL, на котором даже обычный foreach стоит (foreach-foreach, мы же ведь о языках) L>а js видимо святым духом выполняется и в нем нет ни string-ов, ни Array-ев. В чем ткое коренное отличие-то?
где это я говорил, о святых духах? я выше сказал, что в JS значительно меньше "родных" объектов, чем в C# с его огромным BCL
Здравствуйте, Цыба, Вы писали:
L>>но тем не менее не нужно
Ц>значит, я не знаю чего-то. my bad. могли бы и указать — я бы вспомнил хоть
Я имел в виду, раз эти делегаты (Func, Action) есть в стандартной библиотеке, то писать их не нужно.
L>>если "var O = {}" — аналог "var O = new Object()", то почему он считается преимуществом? Или вы что-то недоговариваете, или... Ц>>>спрашивать меня это сейчас — это всё-равно, что я бы спрашивал вас "ну неужели (x,y)=>x+y*2 лучше function(x,y){return x+y*2;}?" L>>Не вижу ничего общего, если честно.
Ц>а я вижу. причём даже очень ясно. и вы, пожалуй. лукавите, что "не видите". краткий синтаксис ведь — наше всё сегодня. да или нет?
А, так вот ты о чем. Теперь понятно.
На самом деле, синтаксис шарпа не намного длиннее — достаточно new {};
L>>>>Недавно вышел. Если учитывать dynamic в 4-м шарпе, остаются какие-либо преимущества js-а или нет? Ц>>>да, нет нужды даже в урезанном BCL, на котором даже обычный foreach стоит (foreach-foreach, мы же ведь о языках) L>>а js видимо святым духом выполняется и в нем нет ни string-ов, ни Array-ев. В чем ткое коренное отличие-то?
Ц>где это я говорил, о святых духах? я выше сказал, что в JS значительно меньше "родных" объектов, чем в C# с его огромным BCL
Часть BCL-я, необходимая для работы C#-а не такая уж и огромная. Возьми тот же SL — 2 метра всего, а функциональности по сравнению с js — море.
Здравствуйте, Lloyd, Вы писали:
L>Я имел в виду, раз эти делегаты (Func, Action) есть в стандартной библиотеке, то писать их не нужно.
ну да, "за вас", т.е. теперь понятно, о чём вы
L>На самом деле, синтаксис шарпа не намного длиннее — достаточно new {};
эммм, разве здесь не объект анонимного типа создаётся, или это new Object()?
L>Часть BCL-я, необходимая для работы C#-а не такая уж и огромная. Возьми тот же SL — 2 метра всего, а функциональности по сравнению с js — море.
будь у меня доступ к SL-ому BCL прямо из JS — я бы не менее эффективно использовал этот BCL из JS
Здравствуйте, yoriсk.kiev.ua, Вы писали:
YKU>Ну, если вы хорошо так понимаете JS, обьясните чего у него хорошего. По сравнению с C#, например.
JSON-нотация уже многого стоит... Функции являются first-class object'ами. В C# есть два вида функций — "лябмды" и "обычные функции". Но это уже больше тема "статическая типизация vs динамическая"...
Здравствуйте, Цыба, Вы писали:
L>>На самом деле, синтаксис шарпа не намного длиннее — достаточно new {};
Ц>эммм, разве здесь не объект анонимного типа создаётся, или это new Object()?
Анонимного.
L>>Часть BCL-я, необходимая для работы C#-а не такая уж и огромная. Возьми тот же SL — 2 метра всего, а функциональности по сравнению с js — море.
Ц>будь у меня доступ к SL-ому BCL прямо из JS — я бы не менее эффективно использовал этот BCL из JS
Здравствуйте, koandrew, Вы писали:
YKU>>Ну, если вы хорошо так понимаете JS, обьясните чего у него хорошего. По сравнению с C#, например.
K>JSON-нотация уже многого стоит...
ну как бы и в шарпе object initializer никто не отменял.
K>Функции являются first-class object'ами.
Что вы в это понятие вкладываете?
K>В C# есть два вида функций — "лябмды" и "обычные функции".
Здравствуйте, Lloyd, Вы писали:
L>ну как бы и в шарпе object initializer никто не отменял.
Ну как бы их нельзя получить из сети... Опять же это следствие динамической типизации JS
K>>Функции являются first-class object'ами.
L>Что вы в это понятие вкладываете?
см. ниже
K>>В C# есть два вида функций — "лябмды" и "обычные функции".
L>Да ну? И в чем же отличие?
class Something
{
private Func<string, string> m_function = x => x; //это поле типа "делегат"private string Function(string s) //это функция
{
return s;
}
}
JavaScript:
var Function = function(x) { return x; };
function Function(x) { return x; }; //эти две записи _полностью_ эквивалентны
Здравствуйте, koandrew, Вы писали:
L>>ну как бы и в шарпе object initializer никто не отменял.
K>Ну как бы их нельзя получить из сети...
Ну это как бы относится не к языку, а к наличию библиотеки сериализации, не более того.
K>Опять же это следствие динамической типизации JS
Это не следствие динамической типизации ни разу. Это слдествие наличия eval в стандартной библиотеки.
K>>>Функции являются first-class object'ами.
L>>Что вы в это понятие вкладываете? K>см. ниже
K>>>В C# есть два вида функций — "лябмды" и "обычные функции".
L>>Да ну? И в чем же отличие?
K>
K>class Something
K>{
K> private Func<string, string> m_function = x => x; //это поле типа "делегат"
K> private string Function(string s) //это функция
K> {
K> return s;
K> }
K>}
K>
K>JavaScript:
K>
K>var Function = function(x) { return x; };
K>function Function(x) { return x; }; //эти две записи _полностью_ эквивалентны
K>
Ну и в чем принципиальное отличие? Только в том, что я не могу изменить значение в том случае, когда функция является методом? Дык я и поле могу сделать readonly.
Здравствуйте, Lloyd, Вы писали:
L>Ну и в чем принципиальное отличие? Только в том, что я не могу изменить значение в том случае, когда функция является методом? Дык я и поле могу сделать readonly.
Принципиальное отличие в том, что в C# это два разных типа объектов, а в JS они неотличимы и полностью эквивалентны
Здравствуйте, koandrew, Вы писали:
L>>Ну и в чем принципиальное отличие? Только в том, что я не могу изменить значение в том случае, когда функция является методом? Дык я и поле могу сделать readonly.
K>Принципиальное отличие в том, что в C# это два разных типа объектов,
и в чем будет проявляться отличие в случае сипользования public readonly поля типа Func/Action? если абстрагироваться от метаданых сборки и говорить только о языке.
Здравствуйте, Lloyd, Вы писали:
L>и в чем будет проявляться отличие в случае сипользования public readonly поля типа Func/Action? если абстрагироваться от метаданых сборки и говорить только о языке.
В том, что в C# они не взаимозаменяемы. И к чему это ограничение readonly? Они _разные_ и точка. Или всё ещё непонятно, о чём я?
Здравствуйте, koandrew, Вы писали:
L>>и в чем будет проявляться отличие в случае сипользования public readonly поля типа Func/Action? если абстрагироваться от метаданых сборки и говорить только о языке.
K>В том, что в C# они не взаимозаменяемы. И к чему это ограничение readonly? Они _разные_ и точка. Или всё ещё непонятно, о чём я?
Не, не понятно. Ты с завидным упорством продолжаешь повторять это, не приводя примеров.
Здравствуйте, Mamut, Вы писали:
M>Я бы сказал, строгой типизации.
Одна из ранних имплементаций Sciter имела JavaVM on board (вместо tiscript).
С 99% вероятностью могу сказать что тебе бы это не понравилось. Именно из-за типизации.
jquery со строгой типизацией напрмер есть вельми грустное зрелище.
А вот нормальная модульность это the must в случаях когда у тебя используется несколько библиотек.
Я имею ввиду как минимум namespaces котрые я сделал в tiscript.
L>>>Не надо повторять. Просто напиши что я предложил и посмотри на код, сам все поймешь. Удачи.
M>>Что ты предложил? Ты предложил map/fold и т.п.? M>>Я тебе тоже предложил, причем примеры из реальной жизни. Ты почему-то решил отмести их напрочь.
L>Ты сравниваешь синтаксис лямбд в шарпе и jsvscript-е и утверждаешь, что он в js не хуже и при этом обосновываешь этот вывод на примере, где лямбда — большая. И из этого частного случая делаешь общий вывод. Это некорректно, нужно рассматривать не частные случаи, а все случаи. Если ты перепишешь свой же код, вынеся функционал высасывания rss-а в отдельную функцию и будешь использовать ее в each-е, то ты заметишь громоздкость синтаксиса лямб в js.
Повторю в шестой раз. То, что я показал, и есть общий случай для js
L>>>А C#?
M>>Процедурное программирование, например
L>Ты имеешь в виду, что нельзя объявить методы вне класса или что-то другое? Если это, то воспринимай это просто как своего рода namespace.
Я имею в виду процедурное программирование Без классов, без ООП
M>>И, насколько я помню, функции все же не first-class objects в C#
L>Что ты имеешь в виду?
Можно ли в C# такое:
function func(){ /* что-то там */ }
var a = func;
a();
M>>Я бы сказал, строгой типизации.
CS>Одна из ранних имплементаций Sciter имела JavaVM on board (вместо tiscript). CS>С 99% вероятностью могу сказать что тебе бы это не понравилось. Именно из-за типизации. CS>jquery со строгой типизацией напрмер есть вельми грустное зрелище.
CS>Ну и вот тебе инфа к размышлению: CS>http://www.codeproject.com/Surveys/1038/Compile-time-Language-Type-Safety-a-help-or-a-hind.aspx
Эээ. Строгая не есть статическая
M>>Да, модульность было бы неплохо (хотя есть варианты решения, как, например, в Node.js)
CS>А вот нормальная модульность это the must в случаях когда у тебя используется несколько библиотек. CS>Я имею ввиду как минимум namespaces котрые я сделал в tiscript.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Цыба, Вы писали:
Ц>>>>+ не нужно возиться с делегатами L>>>Не нужно
Ц>>возможно, вы имеете в виду, если не ошибаюсь, Action, Func?.. если не вы, значит за вас
L>но тем не менее не нужно
L>>>Гм. Это преимущество js-а?
Ц>>я же сказал: одно из
L>если "var O = {}" — аналог "var O = new Object()", то почему он считается преимуществом? Или вы что-то недоговариваете, или...
Просто можно пойти дальше:
> var o = {}
Object
__proto__: Object
> var o = { a: 1, b: 2}
Object
a: 1
b: 2
__proto__: Object
> var o = { method: function(){ return this; }}
Object
method: function (){ return this; }
__proto__: Object
Вот так вот легко и ненапряжно мы создали три разных объекта.
Расширяем объект:
> o = {}
Object
__proto__: Object
> o['method'] = function(){}
> o
Object
method: function (){}
__proto__: Object
Здравствуйте, Mamut, Вы писали:
L>>Ты имеешь в виду, что нельзя объявить методы вне класса или что-то другое? Если это, то воспринимай это просто как своего рода namespace.
M>Я имею в виду процедурное программирование Без классов, без ООП
Да сколько угодно, статические классы — и вперед. Пусть тебя не смущает слово class в их определении, это не имеет ничего общего с классами из ООП.
M>>>И, насколько я помню, функции все же не first-class objects в C#
L>>Что ты имеешь в виду?
M>Можно ли в C# такое:
M>
M>function func(){ /* что-то там */ }
M>var a = func;
M>a();
M>
Можно, только синтаксис немного другой и надо указать аннотацию типа у переменной a, т.к. язык — статически типизированный.
Здравствуйте, Mamut, Вы писали:
Ц>>>я же сказал: одно из
L>>если "var O = {}" — аналог "var O = new Object()", то почему он считается преимуществом? Или вы что-то недоговариваете, или...
M>Просто можно пойти дальше:
M>
>> var o = {}
M>Object
M> __proto__: Object
>> var o = { a: 1, b: 2}
M>Object
M> a: 1
M> b: 2
M> __proto__: Object
>> var o = { method: function(){ return this; }}
M>Object
M> method: function (){ return this; }
M> __proto__: Object
M>
M>Вот так вот легко и ненапряжно мы создали три разных объекта.
Спасибо, Кэп. Странно, что ты поправил меня, а не Цыбу.
Здравствуйте, Цыба, Вы писали:
L>>Спасибо, Кэп. Странно, что ты поправил меня, а не Цыбу.
Ц>Цыба, вообще-то, писал о синтаксисе, а не о "можно пойти дальше"
Да, с телепатическими способностями у меня совсем плохо, надо над этим поработать.
т.е. все веб-технологии задумывались как лучше, а исторически сложилось как всегда (причем скорее даже не от недостатков самих технологий, а из-за того, что в интернете их используют не так как надо).
А еще чего мне не хватает в интернете — так это определенности и постоянства. Как ненадежен интернет — сегодня есть, а завтра нет Например, был какой-нибудь хороший ресурс, потом бац — его закрыли, или перенесли на другой сервер без сохранения старого имени, или просто изменили что-то на нем — и все ссылки, которые я сохранил или отправил знакомым, стали битыми. И даже нет механизма проверить в момент сохранения ссылки, насколько постоянным можно считать тот контент, на который она ссылается. Также на многих интернет-ресурсах нет возможности сослаться именно на нужный кусок контента (например, хочу послать кому-нибудь ссылку на текст какой-нибудь статьи, а не на кучу рекламы вокруг нее).
Да, и еще чего не хватает — это возможностей поиска. Хочу, чтобы в браузере была возможность а ля "Поиск во всех файлах проекта" в VisualStudio. И хочу, чтобы это было именно в браузере, чтобы для этого мне не надо было лезть в гугл — чтобы это работало как в онлайне, так и в оффлайне, и чтобы для этого разработчику контента не надо было создавать в своем HTML извращениский скрипт — хочу, чтобы это все делалось стандартными средствами.
M>>Повторю в шестой раз. То, что я показал, и есть общий случай для js
L>Ты просто жжошь. 1 случай не может быть общим, т.к. он — частный случай по определению.
Аналогично с твоими лямбдами.
В JS анонимные функции используется постоянно, причем именно так, как я показал. Поэтому твое
не надо приводить примеры, где лябды на полэкрана, тогда увидишь, где читабельность.
L>>>Ты имеешь в виду, что нельзя объявить методы вне класса или что-то другое? Если это, то воспринимай это просто как своего рода namespace. M>>Я имею в виду процедурное программирование Без классов, без ООП L>Да сколько угодно, статические классы — и вперед. Пусть тебя не смущает слово class в их определении, это не имеет ничего общего с классами из ООП.
Это все равно ООП.
M>>>>И, насколько я помню, функции все же не first-class objects в C#
L>>>Что ты имеешь в виду?
M>>Можно ли в C# такое:
M>>
M>>function func(){ /* что-то там */ }
M>>var a = func;
M>>a();
M>>
L>Можно, только синтаксис немного другой и надо указать аннотацию типа у переменной a, т.к. язык — статически типизированный.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Mamut, Вы писали:
Ц>>>>я же сказал: одно из
L>>>если "var O = {}" — аналог "var O = new Object()", то почему он считается преимуществом? Или вы что-то недоговариваете, или...
M>>Просто можно пойти дальше:
M>>
>>> var o = {}
M>>Object
M>> __proto__: Object
>>> var o = { a: 1, b: 2}
M>>Object
M>> a: 1
M>> b: 2
M>> __proto__: Object
>>> var o = { method: function(){ return this; }}
M>>Object
M>> method: function (){ return this; }
M>> __proto__: Object
M>>
M>>Вот так вот легко и ненапряжно мы создали три разных объекта.
L>Спасибо, Кэп. Странно, что ты поправил меня, а не Цыбу.
Поправил тебя, потому что "var O = {}" — не аналог "var O = new Object()". И поправил тебя, потому что такое впечатление, что о JS ты знаешь если не понаслышке, то очень мало (многстрочные лямбды, ага)
Здравствуйте, Mamut, Вы писали:
L>>Да сколько угодно, статические классы — и вперед. Пусть тебя не смущает слово class в их определении, это не имеет ничего общего с классами из ООП.
M>Это все равно ООП.
ООП без объектов? Это пять.
L>>Можно, только синтаксис немного другой и надо указать аннотацию типа у переменной a, т.к. язык — статически типизированный.
M>Что значит синтаксис немного другой?
int func() { /* чтщ-то там */}
Func<int> a = func;
Здравствуйте, Mamut, Вы писали:
L>>Спасибо, Кэп. Странно, что ты поправил меня, а не Цыбу.
M>Поправил тебя, потому что "var O = {}" — не аналог "var O = new Object()".
Вот и попровлял бы того, кто написал про аналог. Подсказка: это был не я.
M>И поправил тебя, потому что такое впечатление, что о JS ты знаешь если не понаслышке, то очень мало (многстрочные лямбды, ага)
Это неверное впечатление. JS я знаю хорошо, а вот ты похоже не очень, раз не видишь его недостатков.
Здравствуйте, Mamut, Вы писали:
M>>>Повторю в шестой раз. То, что я показал, и есть общий случай для js
L>>Ты просто жжошь. 1 случай не может быть общим, т.к. он — частный случай по определению.
M>Аналогично с твоими лямбдами.
Не аналогично ни разу.
С большой "лямбдой" ты показал только то, что js-синтаксис не проигрывает шарповому при больших лямбдах. Из этого ты сделал вывод, что js-синтаксис никогда не проигрывает шарповому. Этот вывод неверен, для доказательства этого достаточно одного примера, когда js-синтаксис проигрывает. Я и привел пример с маленькой лямбдой в качестве такого примера.
Здравствуйте, Цыба, Вы писали:
L>>Это неверное впечатление. JS я знаю хорошо, а вот ты похоже не очень, раз не видишь его недостатков.
Ц>позвольте поинтересоваться, почему вы тогда спрашивали, о том, что такое var O = {}?
Ты почитай тот пост, в ответе на который я это спросил. Только прочитай его непредвзято. Вопросы сами пропадут, уверяю тебя.
Здравствуйте, Lloyd, Вы писали:
L>Ты почитай тот пост, в ответе на который я это спросил. Только прочитай его непредвзято. Вопросы сами пропадут, уверяю тебя.
я, как и вы, не обладаю даром чтения мыслей, к сожалению, а посему ответьте здесь на мой вопрос выше, пожалуйста
Здравствуйте, Цыба, Вы писали:
L>>Ты почитай тот пост, в ответе на который я это спросил. Только прочитай его непредвзято. Вопросы сами пропадут, уверяю тебя.
Ц>я, как и вы, не обладаю даром чтения мыслей, к сожалению, а посему ответьте здесь на мой вопрос выше, пожалуйста
Я не понял, к чему ты привел эти строчки, что ты хотел получить в итоге на выходе. С синтаксисом проблем не было, уверяю тебя.
P.S. Немного личного: когда посылаешь ответ, перечитывай его перед тем, как послать. В частности это относится и к этому посту — ты зачем-то выбросил из сообщения вопрос, на который сам же просишь ответить.
M>>И поправил тебя, потому что такое впечатление, что о JS ты знаешь если не понаслышке, то очень мало (многстрочные лямбды, ага)
L>Это неверное впечатление. JS я знаю хорошо, а вот ты похоже не очень, раз не видишь его недостатков.
Я вижу его недостатки, и уже их тут один раз рассказал. И это точно не громоздкий синтаксис лямбд, который якобы является свидетельством плохой поддержки ФП (объяснение
M>>>>Повторю в шестой раз. То, что я показал, и есть общий случай для js
L>>>Ты просто жжошь. 1 случай не может быть общим, т.к. он — частный случай по определению.
M>>Аналогично с твоими лямбдами.
L>Не аналогично ни разу. L>С большой "лямбдой" ты показал только то, что js-синтаксис не проигрывает шарповому при больших лямбдах. Из этого ты сделал вывод, что js-синтаксис никогда не проигрывает шарповому.
Этого вывода я не делал
L>Этот вывод неверен, для доказательства этого достаточно одного примера, когда js-синтаксис проигрывает. Я и привел пример с маленькой лямбдой в качестве такого примера.
Класс, сделал какой-то вывод, который я лично не делал, и сам его блестяще опроверг. Браво. Апплодирую стоя.
В яваскрипте анонимные функции/лямбды используются повсеместно, а не только для написания кортких однострочных мыслей.
Я понимаю, кому-то так и хочется ввести однострочные лямбды по типу питоновских, только смысла в этом нет. Потому что повсеместно и в большинстве своем лямбды, они же — анонимные функции, в Javascript'е применяются именно как многострочные конструкции, и ввод отдельного нового синтаксиса специально для коротких/однострочных лямбд не приведет к ожидаемому повышению читаемости кода. Примеры я тоже приводил.
Желание краткого синтаксиса для коротких вещей типа map/filter понятно, но что делать с тем кодом, что писался, пишется и будет писаться с использованием анонимных функций? «Пожалуйста, злдесь используйте такой синтаксис, а здесь — такой»? А смысл?
Здравствуйте, Mamut, Вы писали:
L>>Это неверное впечатление. JS я знаю хорошо, а вот ты похоже не очень, раз не видишь его недостатков.
M>Я вижу его недостатки, и уже их тут один раз рассказал. И это точно не громоздкий синтаксис лямбд, который якобы является свидетельством плохой поддержки ФП (объяснение
Кстати, я запамятовал, ты уже ответил на вопрос зачем надо было в Functional добавлять передачу "функций" в виде строк, когда и с существующим синтаксисом якобы все хорошо?
Здравствуйте, Mamut, Вы писали:
L>>Не аналогично ни разу. L>>С большой "лямбдой" ты показал только то, что js-синтаксис не проигрывает шарповому при больших лямбдах. Из этого ты сделал вывод, что js-синтаксис никогда не проигрывает шарповому.
M>Этого вывода я не делал
Ты привел пример большой лямбды чтобы продемонстрировать, что альтернативный синтаксис ничего не дает. Несколькими постами позже ты начал утверждать, что такие лямбды — общий случай. Из этого я сделал вывод, что ты считаешь, что в общем случае краткий синтаксис не нужен. Я где-то допустил ошибку? Где?
L>>Этот вывод неверен, для доказательства этого достаточно одного примера, когда js-синтаксис проигрывает. Я и привел пример с маленькой лямбдой в качестве такого примера.
M>Класс, сделал какой-то вывод, который я лично не делал, и сам его блестяще опроверг. Браво. Апплодирую стоя.
M>
M>В яваскрипте анонимные функции/лямбды используются повсеместно, а не только для написания кортких однострочных мыслей.
M>Я понимаю, кому-то так и хочется ввести однострочные лямбды по типу питоновских, только смысла в этом нет. Потому что повсеместно и в большинстве своем лямбды,
Так "повсеместно" или "в большинстве"? Ты уж определись окончательно.
M>они же — анонимные функции, в Javascript'е применяются именно как многострочные конструкции, и ввод отдельного нового синтаксиса специально для коротких/однострочных лямбд не приведет к ожидаемому повышению читаемости кода. Примеры я тоже приводил.
M>Желание краткого синтаксиса для коротких вещей типа map/filter понятно, но что делать с тем кодом, что писался, пишется и будет писаться с использованием анонимных функций? «Пожалуйста, злдесь используйте такой синтаксис, а здесь — такой»? А смысл?
Гм. Извините, что повторяюсь, но смысл остается тем же, что и в моем первом посте — лучшая читабельность.
Здравствуйте, Lloyd, Вы писали:
L>Кстати, я запамятовал, ты уже ответил на вопрос зачем надо было в Functional добавлять передачу "функций" в виде строк, когда и с существующим синтаксисом якобы все хорошо?
Это eval() — стандартная возможность таких языков. Добавили, потому что можно.
Здравствуйте, anonymous, Вы писали:
L>>Кстати, я запамятовал, ты уже ответил на вопрос зачем надо было в Functional добавлять передачу "функций" в виде строк, когда и с существующим синтаксисом якобы все хорошо?
A>Это eval() — стандартная возможность таких языков. Добавили, потому что можно.
Здравствуйте, anonymous, Вы писали:
L>>Кстати, я запамятовал, ты уже ответил на вопрос зачем надо было в Functional добавлять передачу "функций" в виде строк, когда и с существующим синтаксисом якобы все хорошо?
A>Это eval() — стандартная возможность таких языков. Добавили, потому что можно.
M>>Желание краткого синтаксиса для коротких вещей типа map/filter понятно, но что делать с тем кодом, что писался, пишется и будет писаться с использованием анонимных функций? «Пожалуйста, злдесь используйте такой синтаксис, а здесь — такой»? А смысл?
L>Гм. Извините, что повторяюсь, но смысл остается тем же, что и в моем первом посте — лучшая читабельность.
Неверно для Яваскрипта. Объясняю на пальцах.
В C# лямбды — это "add-on". Поздно появившийся, являющейся лишь сахаром для делегатов. Предназначен для выполнения коротких, однострочных функций. Как только строчек становится больше, чем одна, все, ховайся, читабельность убегает далеко и надолго:
static Func<double, double, double> hypotenuse =
(x, y) => Math.Sqrt(x * x + y * y);
static Func<int, int, bool> divisibleBy =
(int a, int b) => a % b == 0;
static Func<int, bool> isPrime =
x => {
for (int i = 2; i <= x / 2; i++)
if (divisibleBy(x, i))
return false;
return true;
};
static void Main(string[] args)
{
int n = 19;
if (isPrime(n)) Console.WriteLine(n + " is prime");
Console.ReadLine();
}
Для определения isPrime вообще лучше, наверное, использовать delegate(x), чтобы не потерять объявление собственно лямбды в коде. И правильно, отношение к лямбдам ВНЕЗАПНО становится «не используй многострочных лямбд». Почему? А потому что многострочность резко сводит на нет всю читабельность лямбд.
В Javascript'е опять же ВНЕЗАПНО оказывается, что коротких лямбд достаточно мало. А анонимные многострочные функции — это в порядке вещей. Ты же не против многстрочных делегатов в C#? Зачем же вводить еще один синтаксис для тех же яиц? Ради некоей мифической читаемости кода, которая в реально используемом Яваскрипте не проявится?
Здравствуйте, koandrew, Вы писали:
A>>Если вдаваться в подробности, то это не так. Но здесь сойдёт. K>Не поясните, в чём разница? Ну за исключением ситуации, когда var объявлен в некотором scope...
Разница в том, что в одном случае это объявление функции (создаётся на этапе входа в контекст), а в другом — функция-выражение (создаётся на этапе интерпретации кода контекста), отсюда немного различное поведение:
Здравствуйте, Mamut, Вы писали:
M>В Javascript'е опять же ВНЕЗАПНО оказывается, что коротких лямбд достаточно мало. А анонимные многострочные функции — это в порядке вещей. Ты же не против многстрочных делегатов в C#? Зачем же вводить еще один синтаксис для тех же яиц? Ради некоей мифической читаемости кода, которая в реально используемом Яваскрипте не проявится?
Ну это кто как пишет. Тот код, что ты приводил, я не считаю образцом для подражания. Как я уже писал, я бы вытащил код модификации дома в отдельную функцию и передавал бы ее в jQuery-вский each. Тут громоздкость уже явно мозолила бы глаза. А если все загонять в одно выражение, то разницы никакой не будет.
Здравствуйте, Lloyd, Вы писали:
L>>>Кстати, я запамятовал, ты уже ответил на вопрос зачем надо было в Functional добавлять передачу "функций" в виде строк, когда и с существующим синтаксисом якобы все хорошо? A>>Это eval() — стандартная возможность таких языков. Добавили, потому что можно. L>Это твое мнение или мнение авторов библиотеки?
Нужны функции, код которых формируется динамически во время исполнения, для этого и нужен конструктор функций, принимающий строку.
M>>В Javascript'е опять же ВНЕЗАПНО оказывается, что коротких лямбд достаточно мало. А анонимные многострочные функции — это в порядке вещей. Ты же не против многстрочных делегатов в C#? Зачем же вводить еще один синтаксис для тех же яиц? Ради некоей мифической читаемости кода, которая в реально используемом Яваскрипте не проявится?
L>Ну это кто как пишет. Тот код, что ты приводил, я не считаю образцом для подражания.
Я его и не выдвигаю, как образец для подражания.
L>Как я уже писал, я бы вытащил код модификации дома в отдельную функцию и передавал бы ее в jQuery-вский each. Тут громоздкость уже явно мозолила бы глаза.
??? Где и как бы она мозолила?
// для полноты картины, это находится в $(document).ready();
$(document).ready(function(){
$('span.rss-url').each(function(){
var url = $(this).html();
var parent = $(this).parent();
var feed = new google.feeds.Feed(url);
feed.load(function(result){
if(result.error) {
var div = $('<div class="item"></div>');
div.appendTo(parent);
div.append('Не удалось получить RSS с ' + url);
return;
}
for(i = 0; i < 10 && i < result.feed.entries.length; i++){
var div = $('<div class="item"></div>');
div.appendTo(parent);
var item = result.feed.entries[i];
div.append('<'+headerElement+'><a href="'+item.link+'">'+item.title+'</a></'+headerElement+'>'+item.content);
div.find('p:gt(0), p+div').hide();
if(div.find('p').length > 1) div.find('p:eq(0)').append(' ...');
}
});
});
против (синтаксис как есть сейчас):
// избавляемся от всех «многострочных лямбд»
// в loadCallback придется протягивать parent, которая
// иначе была бы в замыканииfunction loadCallback(parent, result) {
if(result.error) {
var div = $('<div class="item"></div>');
div.appendTo(parent);
div.append('Не удалось получить RSS с ' + url);
return;
}
for(i = 0; i < 10 && i < result.feed.entries.length; i++){
var div = $('<div class="item"></div>');
div.appendTo(parent);
var item = result.feed.entries[i];
div.append('<'+headerElement+'><a href="'+item.link+'">'+item.title+'</a></'+headerElement+'>'+item.content);
div.find('p:gt(0), p+div').hide();
if(div.find('p').length > 1) div.find('p:eq(0)').append(' ...');
}
}
function eachCallback() {
var url = $(this).html();
var parent = $(this).parent();
var feed = new google.feeds.Feed(url);
feed.load(function(result){ loadCallback(parent, result) });
}
$(document).ready(function(){
$('span.rss-url').each(eachCallback);
});
против (синтаксис с лямбдами a la С#):
// избавляемся от всех «многострочных лямбд»
// в loadCallback придется протягивать parent, которая
// иначе была бы в замыканииfunction loadCallback(parent, result) {
if(result.error) {
var div = $('<div class="item"></div>');
div.appendTo(parent);
div.append('Не удалось получить RSS с ' + url);
return;
}
for(i = 0; i < 10 && i < result.feed.entries.length; i++){
var div = $('<div class="item"></div>');
div.appendTo(parent);
var item = result.feed.entries[i];
div.append('<'+headerElement+'><a href="'+item.link+'">'+item.title+'</a></'+headerElement+'>'+item.content);
div.find('p:gt(0), p+div').hide();
if(div.find('p').length > 1) div.find('p:eq(0)').append(' ...');
}
}
function eachCallback() {
var url = $(this).html();
var parent = $(this).parent();
var feed = new google.feeds.Feed(url);
feed.load(result => loadCallback(parent, result));
}
$(document).ready(
() => $('span.rss-url').each(eachCallback);
});
Разница? Минимальна, если она вообще есть. В случае, если нам не надо протягивать parent в loadCallback, то — вау! — лямбда будет ровно в одном месте.
Здравствуйте, anonymous, Вы писали:
L>>Это твое мнение или мнение авторов библиотеки?
A>Нужны функции, код которых формируется динамически во время исполнения, для этого и нужен конструктор функций, принимающий строку.
Здравствуйте, Lloyd, Вы писали:
L>>>Это твое мнение или мнение авторов библиотеки? A>>Нужны функции, код которых формируется динамически во время исполнения, для этого и нужен конструктор функций, принимающий строку. L>Это твое мнение или мнение авторов библиотеки?
Здравствуйте, anonymous, Вы писали:
A>>>Нужны функции, код которых формируется динамически во время исполнения, для этого и нужен конструктор функций, принимающий строку. L>>Это твое мнение или мнение авторов библиотеки?
A>Какой библиотеки?
Кто здесь? Ты хоть прочитал пост, на который отвечал?
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, anonymous, Вы писали:
A>>>>Нужны функции, код которых формируется динамически во время исполнения, для этого и нужен конструктор функций, принимающий строку. L>>>Это твое мнение или мнение авторов библиотеки? A>>Какой библиотеки? L>Кто здесь? Ты хоть прочитал пост, на который отвечал?
Да, только я перепутал Functional с Function. Но ответ мой остаётся прежним, это возможность языка — создавать функции из строк. Авторы её использовали. Можно передавать в функции библиотеки и функции вместо строк. А если хочешь знать мнение авторов, спрашивай у них, мы — не авторы.
Здравствуйте, anonymous, Вы писали:
A>Да, только я перепутал Functional с Function. Но ответ мой остаётся прежним, это возможность языка — создавать функции из строк. Авторы её использовали. Можно передавать в функции библиотеки и функции вместо строк. А если хочешь знать мнение авторов, спрашивай у них, мы — не авторы.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, anonymous, Вы писали:
L>>>Это твое мнение или мнение авторов библиотеки?
A>>Нужны функции, код которых формируется динамически во время исполнения, для этого и нужен конструктор функций, принимающий строку.
L>Это твое мнение или мнение авторов библиотеки?
В таком случае мнение авторов библиотеки надо бы спрашивать у авторов библиотеки, нет? Зачем ты задаешь этот вопрос тут не авторам библиотеки?
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Здравствуйте, yuriylsh, Вы писали:
L>>Это твое мнение или мнение авторов библиотеки?
Y>В таком случае мнение авторов библиотеки надо бы спрашивать у авторов библиотеки, нет? Зачем ты задаешь этот вопрос тут не авторам библиотеки?
ну я не знаю, может мой собеседник знает мнение авторов, раз он так смело высказывается по вопросу.
M>>Разница? Минимальна, если она вообще есть.
L>Разница есть. И если ты будешь работать с теми же коллекциями, отфильтровать там, обработать как-нить специфично, то разницу и увидишь, она есть.
Работаю, фильтрую, обрабатываю специфично (jQuery же).
L>Кстати, ты так и не ответил на вопрос про библиотеку Functional. Ответь, если не сложно.
L>>>Кстати, ты так и не ответил на вопрос про библиотеку Functional. Ответь, если не сложно.
M>>http://osteele.com/archives/2007/07/functional-javascript
M>>Исключительно из-за однострочных лямбд.
L>Дык эта. Нафик они неужны-то, если и с существующим синтаксисиом все в шоколаде? Чего ж не используют-то? Или счастья своего не понимают?
Ну спроси создателей именно этой библиотеки. Создатели других библиотек абсолютно не парятся с синтаксисом
Здравствуйте, Mamut, Вы писали:
M>>>Исключительно из-за однострочных лямбд.
L>>Дык эта. Нафик они неужны-то, если и с существующим синтаксисиом все в шоколаде? Чего ж не используют-то? Или счастья своего не понимают?
M>Ну спроси создателей именно этой библиотеки.
У меня ответ есть, я его здесь неоднократно озвучивал. А вам стоит задуматься.
M>>>>Исключительно из-за однострочных лямбд. L>>>Дык эта. Нафик они неужны-то, если и с существующим синтаксисиом все в шоколаде? Чего ж не используют-то? Или счастья своего не понимают? M>>Ну спроси создателей именно этой библиотеки. L>У меня ответ есть, я его здесь неоднократно озвучивал. А вам стоит задуматься.
С чего это вдруг? Как я ответил где-то рядом — почему0то создателей других библиотек это вообще не напрягает, как и их пользователей
Здравствуйте, Mamut, Вы писали:
L>>У меня ответ есть, я его здесь неоднократно озвучивал. А вам стоит задуматься.
M>С чего это вдруг? Как я ответил где-то рядом — почему0то создателей других библиотек это вообще не напрягает, как и их пользователей
Я уже отвечал, почему создателей того же jQuery это не напрягает: в тех немногих usecase-ах, где передаются callback-и, они как правило не бывают компактными, потому выгоды от использования более краткого синтаксиса не будет.
ФП-же, например при работе с коллекциями, свойствены короткие лямбды. Functional — пример библитеки, при работе с которой краткие лямбды будут использоваться часто, и из-зы громоздкого синтаксиса лямбд, это приведет к громоздкому нечитаемому коду. потому там и появилась возможность записывать "лямбды" в более кратком виде в виде строки.
Т.е. есть потребность в кратком синтаксисе для написания функционального кода и пример Funtional это достаточно отчетливо демонстрирует.
Здравствуйте, x64, Вы писали:
x64>Нет-нет, желания, кстати, очень правильные и, как мне кажется, Microsoft это понимает и медленно, но верно, идёт к этому.
Обязательно бахнем! И не раз. Весь мир в труху! Но потом. (ДМБ)
у вас не возникало мысли использовать сишарп, например, вместо батников, а то многие дальше пишут на нём? 
