Здравствуйте, yoriсk.kiev.ua, Вы писали:
YKU>Угу. На голом js что-то побольше "hello world" писать никому не хочется, вот и рождаются конвертеры с java/C#/.. на "замечательный недооценённый" язык.
Так и на голых Java и C# не особо пишут что-то большое. Для большого нужны мощные отлаженные библиотеки, которых под JS может не быть. Тут на помощь и приходят трансляторы.
Здравствуйте, WolfHound, Вы писали:
N>>Не вижу причин присобачивать к динамическому языку костыли в виде системы проверки типов. Тут всего лишь другой подход — у него есть свои плюсы и минусы — так же как и у статически типизированных языков. Если смотреть с точки зрения C#/Java-программиста — то да, без проверки типов жить невозможно. WH>Назови хоть один минус статической типизации.
Чрезмерные ограничения.
N>>А вот мне с точки зрения любителя функциональных и динамических языков непонятно, как можно жить без возможности pattern matching'а и добавления методов в рантайме. WH>Зачем добавлять метода в рантайм?
Для удобства.
WH>Где ты видел pattern matching в жибаскрипте?
Здравствуйте, anonymous, Вы писали:
YKU>>Угу. На голом js что-то побольше "hello world" писать никому не хочется, вот и рождаются конвертеры с java/C#/.. на "замечательный недооценённый" язык. A>Так и на голых Java и C# не особо пишут что-то большое. Для большого нужны мощные отлаженные библиотеки
А библиотеки для них на чём пишутся и отлаживаются?
A>которых под JS может не быть.
Щаз.
Просто проще написать на чём-то удобном, там-же отладить и скрестив пальцы надеяться, что на js оно не изменит поведение чем писать то-же самое на js.
Здравствуйте, anonymous, Вы писали:
WH>>Назови хоть один минус статической типизации. A>Чрезмерные ограничения.
Их нет.
WH>>Зачем добавлять метода в рантайм? A>Для удобства.
А конкретно?
WH>>Где ты видел pattern matching в жибаскрипте? A>Регулярные выражения.
В таком виде "pattern matching" везде есть.
За все годы, которые я пытаюсь выяснить, для чего нужны динамически типизированные языки мне не показали ни одной задачи, где они давали бы хоть что-то.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, yoriсk.kiev.ua, Вы писали:
YKU>>>Угу. На голом js что-то побольше "hello world" писать никому не хочется, вот и рождаются конвертеры с java/C#/.. на "замечательный недооценённый" язык. A>>Так и на голых Java и C# не особо пишут что-то большое. Для большого нужны мощные отлаженные библиотеки YKU>А библиотеки для них на чём пишутся и отлаживаются?
Зачем их писать и отлаживать второй раз?
A>>которых под JS может не быть. YKU>Щаз. Просто проще написать на чём-то удобном, там-же отладить и скрестив пальцы надеяться, что на js оно не изменит поведение чем писать то-же самое на js.
Можно пример библиотеки специально написанной для последующей трансляции в JavaScript и использования именно в таком виде?
Здравствуйте, WolfHound, Вы писали:
WH>>>Назови хоть один минус статической типизации. A>>Чрезмерные ограничения. WH>Их нет.
Их есть.
WH>>>Зачем добавлять метода в рантайм? A>>Для удобства. WH>А конкретно?
Например, решили мы по каким-то причинам изменить поведение объекта.
WH>>>Где ты видел pattern matching в жибаскрипте? A>>Регулярные выражения. WH>В таком виде "pattern matching" везде есть.
Ну вот, я ответил на твой вопрос.
WH>За все годы, которые я пытаюсь выяснить, для чего нужны динамически типизированные языки мне не показали ни одной задачи, где они давали бы хоть что-то.
Вот есть Интернет, значимая (а возможно, и большая) часть которого, написана на динамических языках. Чем тебе не задача? Конечно, можно было б всё это написать и на статических языках. Но ведь не написали.
WH>>>>Где ты видел pattern matching в жибаскрипте? A>>>Регулярные выражения. WH>>В таком виде "pattern matching" везде есть.
A>Ну вот, я ответил на твой вопрос.
Справедливости ради, это не ответ на вопрос. Паттерн матчинга (сопоставления с образцом) в том виде, который подразумевает Wolfhound, в JS нет.
Здравствуйте, anonymous, Вы писали:
A>Можно пример библиотеки специально написанной для последующей трансляции в JavaScript и использования именно в таком виде?
Это что, попытка уехать во флейм — "это библиотека, а это — нет" что-ли?
Здравствуйте, anonymous, Вы писали:
WH>>>>Назови хоть один минус статической типизации. A>>>Чрезмерные ограничения. WH>>Их нет. A>Их есть.
Аргументации как обычно нет.
A>Например, решили мы по каким-то причинам изменить поведение объекта.
Это не задача. Это деталь реализации конкретного решения.
А если ты сформулируешь исходную задачу, то станет ясно что динамическая типизация для ее решения не нужна.
WH>>В таком виде "pattern matching" везде есть. A>Ну вот, я ответил на твой вопрос.
Вот только толку от этого нихрена нет.
Ибо вот такой код ты не напишешь. https://github.com/rsdn/nemerle/blob/master/snippets/peg-parser/Nemerle.Peg.Macros/Optimizer/Optimizer.OptimizeRule.n
A>Вот есть Интернет, значимая (а возможно, и большая) часть которого, написана на динамических языках. Чем тебе не задача? Конечно, можно было б всё это написать и на статических языках. Но ведь не написали.
1)Миллион мух это не аргумент.
2)Ты сейчас общаешься на сайте где вся серверная часть написана на статически типизированном языке.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, hattab, Вы писали:
H>Flash на мобильных девайсах есть На Андроиде флэш работает, на HP'шном WebOS тоже поддержка есть, на ежевике тоже, для яблы проблема решаемая, WP7 хз.
На WP7 флэш работает. Говорю как пользователь оного девайса.
Сложность программы растет до тех пор, пока не превысит способности программиста
Здравствуйте, WolfHound, Вы писали:
WH>>>>>Назови хоть один минус статической типизации. A>>>>Чрезмерные ограничения. WH>>>Их нет. A>>Их есть. WH>Аргументации как обычно нет.
Я вижу.
A>>Например, решили мы по каким-то причинам изменить поведение объекта. WH>Это не задача. Это деталь реализации конкретного решения. WH>А если ты сформулируешь исходную задачу, то станет ясно что динамическая типизация для ее решения не нужна.
Вот только толку от такого кода ни хрена нет.
A>>Вот есть Интернет, значимая (а возможно, и большая) часть которого, написана на динамических языках. Чем тебе не задача? Конечно, можно было б всё это написать и на статических языках. Но ведь не написали. WH>1)Миллион мух это не аргумент.
Ещё какой аргумент. Потому что миллион мух — это практика, которая борет все ваши философствования.
WH>2)Ты сейчас общаешься на сайте где вся серверная часть написана на статически типизированном языке.
Здравствуйте, yoriсk.kiev.ua, Вы писали:
A>>Можно пример библиотеки специально написанной для последующей трансляции в JavaScript и использования именно в таком виде? YKU>Это что, попытка уехать во флейм — "это библиотека, а это — нет" что-ли?
Здравствуйте, Mamut, Вы писали:
M>Справедливости ради, это не ответ на вопрос. Паттерн матчинга (сопоставления с образцом) в том виде, который подразумевает Wolfhound, в JS нет.
Да, я понимаю, что для него «настоящий» pattern matching — это то, что реализовано в Nemerle. Только это ни разу не отменяет того, что регулярные выражения являются образцами для сопоставления.
Здравствуйте, anonymous, Вы писали:
A>Да, я понимаю, что для него «настоящий» pattern matching — это то, что реализовано в Nemerle.
Такой pattern matching есть во всех языках семейства ML созданном в 1973 году.
A>Только это ни разу не отменяет того, что регулярные выражения являются образцами для сопоставления.
А мне не нужно сопоставлять строки.
Мне нужно сопоставлять деревья.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
A>>Я вижу. WH>Что ты видишь? Ты выдвинул утверждение вот и доказывай.
Что доказать, что статическая типизация меня ограничивает? Клянусь! Теперь опровергай.
A>>Да в общем-то и статическая тоже не нужна. WH>Она сокращает количество ошибок и увеличивает скорость работы по сравнению с динамической типизацией. Значит нужна.
Здравствуйте, WolfHound, Вы писали:
A>>Да, я понимаю, что для него «настоящий» pattern matching — это то, что реализовано в Nemerle. WH>Такой pattern matching есть во всех языках семейства ML созданном в 1973 году.
Ну и что?
A>>Только это ни разу не отменяет того, что регулярные выражения являются образцами для сопоставления. WH>А мне не нужно сопоставлять строки. Мне нужно сопоставлять деревья.
Здравствуйте, Menestrel, Вы писали:
M> H>Flash на мобильных девайсах есть На Андроиде флэш работает, на HP'шном WebOS тоже поддержка есть, на ежевике тоже, для яблы проблема решаемая, WP7 хз.
M> На WP7 флэш работает. Говорю как пользователь оного девайса.
M>>Справедливости ради, это не ответ на вопрос. Паттерн матчинга (сопоставления с образцом) в том виде, который подразумевает Wolfhound, в JS нет.
A>Да, я понимаю, что для него «настоящий» pattern matching — это то, что реализовано в Nemerle. Только это ни разу не отменяет того, что регулярные выражения являются образцами для сопоставления.
Этот паттерн матчинг точно так же реализован в Scala, Erlang'е, Haskell'е. И никакого отношения к регулярным выражениеям не имеет
Здравствуйте, Mamut, Вы писали:
M>>>Справедливости ради, это не ответ на вопрос. Паттерн матчинга (сопоставления с образцом) в том виде, который подразумевает Wolfhound, в JS нет. A>>Да, я понимаю, что для него «настоящий» pattern matching — это то, что реализовано в Nemerle. Только это ни разу не отменяет того, что регулярные выражения являются образцами для сопоставления. M>Этот паттерн матчинг точно так же реализован в Scala, Erlang'е, Haskell'е. И никакого отношения к регулярным выражениеям не имеет
Ещё раз спрошу: ну и что, регулярные выражения от этого перестают быть сопоставлением с образцом? Напоминаю, вопрос был: есть ли в JavaScript patterm matching? Мой ответ: да. Ваш: нет?
На Андроиде флэш работает, на HP'шном WebOS тоже поддержка есть, на ежевике тоже, для яблы проблема решаемая, WP7 хз.
