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

A>Если спуститься на землю, то ИБ вводится с целью сокращения убытков компании

Ну зачем сразу так пессимистично-то? Бывает, что и просто для предотвращения еще не понесенных убытков

A>и целью является недопущение утраты/копирования/изменения данных которые могут привести к убыткам.

Не совсем так. Зачастую случается, что мы имеем 100% гарантию того, что данные будут утрачены/скопированы/изменены. И в этом случае, ИБ вводится для того, чтобы минимизировать ущерб, который понесет корпорация в результате успешной атаки.

A>При этом нужно учитывать следующее
A>1) целесообразность, да с точки зрения теории вынос кода на клиента в недоверенную зону особо не отличается что на javascript, что на flash/silverlight, но на практике стоимость взлома javascript и бинарников отличается, поэтому с точки зрения коммерции иногда не допустимо размещать код в javascript, но допускается в бинарном виде.

Вы меня не поняли. Никто не будет ломать (и на практике не ломает) javascript или flash/sl, будучи нацелененным на сервер. Все факторы, необходимые для реализации угроз на сервере уже включены в используемый протокол и клиент, в данном случае, не представляет сколь-нибудь существенного интереса для атакующего, на чем бы он не был реализован.

Для атак на сторону клиента, доступ к его исходникам и возможность реверсинга, в большинстве случаев, также не является определяющим фактором. Например, чтобы обнаружить и проэксплуатировать DOM-based XSS, совершенно необязательно иметь доступ к исходнику javascript, в котором допущена данная уязвимость. Если пройтись по любой из существующих классификаций угроз веб-приложений, и рассмотреть клиентские угрозы, то независимость их существования от технологии реализации client-side станет очевидной. Готов обсудить примеры конкретных угроз, для которых это не так.

A>Например клиент-банк приложение отдается клиенту, но вот исходники этого клиент-банка вам врятли отдадут

Так мы о веб-приложениях в частности или о клиент-серверах в общем? Я — о веб-приложениях.

A>или предложат клиент-банк в виде javascript,

https://click.alfabank.ru и это — один из наиболее защищенных и грамотно реализованных клиент-банков из известных мне.

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

Да за счет чего она снижается-то? Как я уже сказал, она обусловлена исключительно, я подчеркиваю, исключительно особенностями используемого в веб-приложениях протокола. Мне не нужно знать устройство клиента, чтобы отреверсить контракт серверной стороны и успешно попытаться отправить на нее malformed-данные. Если же между клиентом и сервером появляется криптография, то для ее грамотной реализации, ее устойчивость не должна зависеть от обладания атакующим какими-либо знаниями о клиентской стороне. Иначе мы получаем security-by-obscurity, которая, как известно, заканчивается весьма печально и security'ей не является по определению.

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

Попытка проведения аналогий для теории информации с реальным миром и его объектами — одно из наиболее распространенных заблуждений. Скажите, какова вероятность того, что злоумышленник вместо угона машины сделает себе ее копию и увезет с собой? А какова вероятность того, что машина бесследно исчезнет прямо у вас на глазах? А того, что вы сядете в бмв, а приехав на место назначения выйдите из запорожца? А того, что кто-то попросит вас дать ему машину на пару часов, вы ему 100% ее дадите, потому что не можете иначе по физическим законам этого мира, а он задавит на ней десяток человек и обвинят в этом вас, т.к. он будет все отрицать? А того, что вашу машину примут за машину террориста №1 и на этом основании посадят в кутузку?

Я только что перечислил все угрозы по STRIDE, если что. Похоже на случаи из реального мира? По-моему не очень

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

A>Если размышлять по теории ИБ то защитить машину не возможно, кроме как удаления ее на бесконечное расстояние,

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

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

И именно поэтому, обеспечение ИБ сводится почти к классическому: "конфиденциально, доступно, целостно — выбери любые два".

Но какое это имеет отношение к javascript?

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

A>Да собственно никто и не говорит что HTML5 не найдет своего применения, конечно когда нужно нарисовать "летающие снежинки", показать видео или прожужжать чтонибудь ( это условно сложность задачи )

Забавно, но именно это говорили в свое время про javascript, пока на нем линуксы и думы не начали запускать

A> то тащить флеш с сильверлайтом смысла нет особого, но если что-то более сложное , а как правило толстые клиенты на flash, silverlight достаточно сложны и на языке javascript их писать — это будет ад.

Я не знаю, для кого это ад, но писать UI на http://knockoutjs.com/ — одно удовольствие, флеш там и рядом не стоял. А ведь это даже и не html5...

A>Поэтому как я уже писал в начальном посте HTML5 войдет в жизнь но не так кардинально как об этом некоторые переживают.

Это Google, что-ли? Да пусть переживает, что с того? Среда, в которой развиваются веб-приложения весьма агрессивна. Эдайкий эволюционный рай. И даже Google не сможет протащить туда и удерживать на плаву что-то, что не впишется в эту окружающую среду (wave тому пример). Если html5 выживет, то это здорово, значит мы имеем еще одну технологию, которую можем выбрать. Возможность выбора — это всегда здорово. Если нет, то не он первый, не он последний.

Но, к слову сказать, flash-плеер на javascript+html5 я видел. Весьмо достойно работал. Движка js и рендерилки html5 на flash почему-то до сих пор нет. К чему бы это?

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

g> H>Слабо верится. Либо у первых (Flash, SL) единственная исполняющая среда/платформа (а значит ноль проблем с совместимостью), либо у второго, по меньшей мере, 4 сильных игрока. Как уже сказали, вряд-ли HTML5 уйдет дальше украшательств страничек (которые начнут резать, как и flash-баннеры) и несложных игрушек

g> Она "единственная" только для PC. А сейчас набирает обороты мобильный веб, куда пока ни один, ни второй не влез.

Flash на мобильных девайсах есть На Андроиде флэш работает, на HP'шном WebOS тоже поддержка есть, на ежевике тоже, для яблы проблема решаемая, WP7 хз.

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

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

Лично я не вижу никаких проблем с JavaScript'ом. Скорость работы интерпретируемых движком V8 скриптов уже неумолимо приближается к скорости программ, скомпилированных gcc.
Удобство разработки же — дело привычки. Насколько я понимаю, вам более привычны .NET/Java — я же их терпеть не могу, и предпочту им динамические JavaScript или Ruby. К тому же, насколько могу судить, флэшевский ActionScript не сильно отличается от JS.

Касаемо контроля за количеством передаваемых параметров — так он делается элементарно:

function foo(a, b) {
  if (arguments.length < foo.length) {
    throw new Error('Too few arguments.');
  }
  console.log(a, b);
}

foo('foo', 'bar'); // foo bar
foo('foo'); // Error: Too few arguments

A>По сути объекты в javascript все имеют один тип Dictionary<string,object> , который заполняется именем поля и значением. Это в целом существенно ухудшает читабельность кода что достаточно существенно замедляет и поддержку и разработку.
A>Таким образом разработка на Javascript обойдется очень дорого.

Очень субъективные утверждения. У подхода "любой объект = хэш-таблица" и у прототипного наследования есть много преимуществ — методы в объекты и классы можно добавлять динамически (в том числе и в объекты вроде String, Number, Array, и т.д.). Прототипное наследование же, к примеру, позволяет запросто построить "классическую" модель ООП, включая приватные, защищенные, и абстрактные методы, примеси (которые mixin), и многое другое.

A>3) Преимущества ради чего кто-то кинется писать GUI проекты под html5 это кроссплатформенность [...] Что опять сводится к разработке некой общей части с использованием стандартных объектно-ориентированных приемов, тот же полиморфизм, которые в javascript будут очень плохо укладываться.

С чего бы они будут плохо укладываться?
JS — объектно-ориентированный язык — не побоюсь сказать, даже более объектно-ориентированный, чем та же Java.
И все возможности по инкапсуляции, полиморфизму, и наследованию там присутствуют — просто в непривычном виде.

A>4) Вопрос открытости исходников и безопасности, тут все думаю и так понятно без пояснений, не всем такой вариант подойдет в принципе.

Да, это проблема. С другой стороны — из Flash точно также можно при желании достать код, и если там нет обфускации — то и получить почти в первозданном виде.
К тому же, Google почему-то не боится "открывать" исходники очень многих своих проектов, как то: Google Docs, Google Mail, Google Maps, и так далее. Весь их JS-код доступен — читайте на здоровье. Если получится.

A>Итого мое мнение что с приходом Html5 произойдет небольшое смещение реализации части user-интерфейса в javascript, например красивые меню, интерактивные каталоги, сайты визитки, все что не требует сложной логики, основная логика будет реализовываться по прежнему в сервисах на удобных типизированных и объектно-ориентированных языках.

Нет, это не так.
Во-первых, HTML5 и предлагаемая им парадигма разработки уже пришли — посмотрите на сервисы Гугла. Google Maps — похож ли он на сайт-визитку?
Совсем нет, а ведь это и есть HTML5.
Во-вторых, никто не заставляет писать все на JS — сервер-сайд будет актуален еще очень долгое время. HTML5 пока что лишь удобное средство для создания UI, которое постепенно будет занимать нишу Rich UI (Flex, Silverlight), небольших игр (Flash), и десктопных приложений (.NET, C++, etc.). Если сомневаетесь насчет смещения десктопных приложений — почитайте про Chrome OS.

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

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

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

N>Лично я не вижу никаких проблем с JavaScript'ом. Скорость работы интерпретируемых движком V8 скриптов уже неумолимо приближается к скорости программ, скомпилированных gcc.
N>Удобство разработки же — дело привычки. Насколько я понимаю, вам более привычны .NET/Java — я же их терпеть не могу, и предпочту им динамические JavaScript или Ruby. К тому же, насколько могу судить, флэшевский ActionScript не сильно отличается от JS.

N>Касаемо контроля за количеством передаваемых параметров — так он делается элементарно:

N>

N>function foo(a, b) {
N>  if (arguments.length < foo.length) {
N>    throw new Error('Too few arguments.');
N>  }
N>  console.log(a, b);
N>}

N>foo('foo', 'bar'); // foo bar
N>foo('foo'); // Error: Too few arguments
N>

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

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


A>>По сути объекты в javascript все имеют один тип Dictionary<string,object> , который заполняется именем поля и значением. Это в целом существенно ухудшает читабельность кода что достаточно существенно замедляет и поддержку и разработку.
A>>Таким образом разработка на Javascript обойдется очень дорого.

N>Очень субъективные утверждения. У подхода "любой объект = хэш-таблица" и у прототипного наследования есть много преимуществ — методы в объекты и классы можно добавлять динамически (в том числе и в объекты вроде String, Number, Array, и т.д.). Прототипное наследование же, к примеру, позволяет запросто построить "классическую" модель ООП, включая приватные, защищенные, и абстрактные методы, примеси (которые mixin), и многое другое.

A>>3) Преимущества ради чего кто-то кинется писать GUI проекты под html5 это кроссплатформенность [...] Что опять сводится к разработке некой общей части с использованием стандартных объектно-ориентированных приемов, тот же полиморфизм, которые в javascript будут очень плохо укладываться.

N>С чего бы они будут плохо укладываться?
N>JS — объектно-ориентированный язык — не побоюсь сказать, даже более объектно-ориентированный, чем та же Java.
N>И все возможности по инкапсуляции, полиморфизму, и наследованию там присутствуют — просто в непривычном виде.

как сделать internal protected override член класса? сколько кода тебе на это потребуется? (не забываем, что а нарушении контракта должен узнать программист, а не пользователь)

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

A>> то тащить флеш с сильверлайтом смысла нет особого, но если что-то более сложное , а как правило толстые клиенты на flash, silverlight достаточно сложны и на языке javascript их писать — это будет ад.

KV>Я не знаю, для кого это ад, но писать UI на http://knockoutjs.com/ — одно удовольствие, флеш там и рядом не стоял. А ведь это даже и не html5...

а есть real-life примеры использования этого чуда? все что у них на сайте на уровне HelloWorld

Здравствуйте, Евгений Акиньшин, Вы писали:

N>>Касаемо контроля за количеством передаваемых параметров — так он делается элементарно

ЕА>так это и есть увеличение трудозатрат — напиши в каждом методе проверку на количество параметров, напиши проверку на тип параметров

А зачем в каждом методе-то писать одинаковый код?
Для этой цели можно код вынести в обертку, с которой проверка на количество и тип параметров будет выглядеть примерно так:

var Foo = new Class({
  bar : strictArgs([Number, Array], function (foo, bar) {
    console.log([foo, bar]);
  })
});

За время программирования на JS лично мне такой проверки не понадобилось почти ни разу.

ЕА> не забудь написать юнит тест на КАЖДОЕ использование этого метода — мы же не хотим чтобы о неправильном количестве переданных параметров узнал конечный пользователь вместо программиста, не забываем затраты на поддержание этого зоопарка в актуальном состоянии (сравни количество действий при добавлении параметра с типизацией и без: в первом случае надо только добавить параметр и пройти по ошибкам компилятора, во втором еще исправить проверки и в ручную найти все обращения)

Не вижу причин присобачивать к динамическому языку костыли в виде системы проверки типов. Тут всего лишь другой подход — у него есть свои плюсы и минусы — так же как и у статически типизированных языков. Если смотреть с точки зрения C#/Java-программиста — то да, без проверки типов жить невозможно. А вот мне с точки зрения любителя функциональных и динамических языков непонятно, как можно жить без возможности pattern matching'а и добавления методов в рантайме.

ЕА>ну и выполнятся эти проверки будут в рантайме, что еще сильнее просадет производительность

Да, на проверке типов теряется примерно 20-30% скорости при вызове метода.
В абсолютном значении для нетяжелых вычислений разница небольшая — 2-4 мс.

ЕА>в нарушение всех законов физики, неумолимо приближающуюся к gcc

Каюсь, про приближение к gcc, конечно, преувеличил. И я не уточнил — приближается к gcc производительность в определенных задачах, за счет JIT компиляции.
Но в то же время на данный момент V8 объективно один из лучших по скорости интерпретаторов для скриптовых языков, оставляя Python, Ruby, и PHP далеко позади.

N>>JS — объектно-ориентированный язык — не побоюсь сказать, даже более объектно-ориентированный, чем та же Java.
N>>И все возможности по инкапсуляции, полиморфизму, и наследованию там присутствуют — просто в непривычном виде.

ЕА>как сделать internal protected override член класса? сколько кода тебе на это потребуется? (не забываем, что а нарушении контракта должен узнать программист, а не пользователь)

Пожалуйста:

var Foo = new atom.Class({
  bar : atom.Class.protectedMethod(function(msg) {
    console.log(msg);
  }),
  foo : function(msg) {
        this.bar(msg);
  }
});

var Bar = new atom.Class({
  Extends : Foo,
  bar : atom.Class.protectedMethod(function(msg) {
    console.log('Hello, ' + msg + '!');
  })
});

var a = new Foo();
var b = new Bar();

a.bar('world'); // Error: The method «bar» is protected.
b.bar('world'); // -/ /-

a.foo('world'); // Hello
b.foo('world'); // Hello, world!

Теперь у меня встречный вопрос — как средствами самого языка в Java добавить mixin'ы?

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

n> Лично я не вижу никаких проблем с JavaScript'ом. Скорость работы интерпретируемых движком V8 скриптов уже неумолимо приближается к скорости программ, скомпилированных gcc.

Конечно, если движки точить на определенные сценарии... Только ведь такие тесты нифига не показывают

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

n>> Лично я не вижу никаких проблем с JavaScript'ом. Скорость работы интерпретируемых движком V8 скриптов уже неумолимо приближается к скорости программ, скомпилированных gcc.

H>Конечно, если движки точить на определенные сценарии... Только ведь такие тесты нифига не показывают

Согласен, приукрасил.
Полагаю, gcc он догоняет за счет JIT оптимизации, которая хорошо ложиться на определенный круг задач. В любом случае, Google V8 невероятно быстр — для Веб-приложений такой скорости вполне достаточно. А ведь его еще периодически улучшают.

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

N>За время программирования на JS лично мне такой проверки не понадобилось почти ни разу.

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


пока проект маленькийи работаешь один и все с памяти держишь — на динамике оно может и быстрее пишется


ЕА>> не забудь написать юнит тест на КАЖДОЕ использование этого метода — мы же не хотим чтобы о неправильном количестве переданных параметров узнал конечный пользователь вместо программиста, не забываем затраты на поддержание этого зоопарка в актуальном состоянии (сравни количество действий при добавлении параметра с типизацией и без: в первом случае надо только добавить параметр и пройти по ошибкам компилятора, во втором еще исправить проверки и в ручную найти все обращения)

N>Не вижу причин присобачивать к динамическому языку костыли в виде системы проверки типов. Тут всего лишь другой подход — у него есть свои плюсы и минусы — так же как и у статически типизированных языков. Если смотреть с точки зрения C#/Java-программиста — то да, без проверки типов жить невозможно. А вот мне с точки зрения любителя функциональных и динамических языков непонятно, как можно жить без возможности pattern matching'а и добавления методов в рантайме.

ЕА>>ну и выполнятся эти проверки будут в рантайме, что еще сильнее просадет производительность

N>Да, на проверке типов теряется примерно 20-30% скорости при вызове метода.
N>В абсолютном значении для нетяжелых вычислений разница небольшая — 2-4 мс.

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

N>Пожалуйста:

N>

N>var Foo = new atom.Class({
N>  bar : atom.Class.protectedMethod(function(msg) {
N>    console.log(msg);
N>  }),
N>  foo : function(msg) {
N>        this.bar(msg);
N>  }
N>});

N>var Bar = new atom.Class({
N>  Extends : Foo,
N>  bar : atom.Class.protectedMethod(function(msg) {
N>    console.log('Hello, ' + msg + '!');
N>  })
N>});

N>var a = new Foo();
N>var b = new Bar();

N>a.bar('world'); // Error: The method «bar» is protected.
N>b.bar('world'); // -/ /-

N>a.foo('world'); // Hello
N>b.foo('world'); // Hello, world!
N>

что protected вижу, а где internal override?
ну опять же единственный способ убедиться, что везде вызвается коректно, написать тесты с 100% покрытием

N>Теперь у меня встречный вопрос — как средствами самого языка в Java добавить mixin'ы?

никак, типизированным языкам тоже есть куда расти

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

N>Полагаю, gcc он догоняет за счет JIT оптимизации, которая хорошо ложиться на определенный круг задач. В любом случае, Google V8 невероятно быстр — для Веб-приложений такой скорости вполне достаточно. А ведь его еще периодически улучшают.

Для веб приложений/UI важно с какой скоростью можно манипулировать DOM моделью. Если рендеринг тормозной то и никакой JIT в JS его не спасет.

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

G>Не останутся, HTML5 их вытеснит нафиг. Нету у SL и Flash значимых преимуществ перед html5, особенно в плане графики.


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

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

N>Но в то же время на данный момент V8 объективно один из лучших по скорости интерпретаторов для скриптовых языков, оставляя ... и PHP далеко позади.

О да! Достойный конкурент

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

G>>>http://chrome.angrybirds.com/
A>>Это вообще шикарны пример, который в javascripte создает флеш объект и его подгружает.
G>А developertools говорит что там canvas. Я ему как-то больше доверяю

A>>Если отключить flash то не работает
G>flash там для звуков, это пока "больное место" html5 и js вообще.

Вот оно что! А то у меня без звука ибо FlashBlock. А так да, работает.

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

TK>Для веб приложений/UI важно с какой скоростью можно манипулировать DOM моделью. Если рендеринг тормозной то и никакой JIT в JS его не спасет.

У вас устаревшие данные. JavaScript уже давно шагнул вперед за DOM — поглядите, например, Angry Birds или Linux в браузере — DOM-модель там упоминается разве только в ключе document.getElementById('canvas'). И это не говоря уже о серверном NodeJS, который тоже использует Google V8 — и в котором DOM нет вообще.

Здравствуйте, Евгений Акиньшин, Вы писали:

N>>За время программирования на JS лично мне такой проверки не понадобилось почти ни разу.

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

ЕА>пока проект маленькийи работаешь один и все с памяти держишь — на динамике оно может и быстрее пишется

Работал над проектами небольшого размера. Насколько могу судить — для Яваскрипта пока что не очень много таких проектов, чтобы "5 человек в течение 5 лет".

Кстати, совсем забыл — для тех, кому необходимо наличие "protected internal override" и проверки типов существует Google Web Toolkit — он напрямую транслирует код из Java в JavaScript.
Хоть это и костыли, но вполне рабочие и используемые тем же Google'ом.

ЕА>>>ну и выполнятся эти проверки будут в рантайме, что еще сильнее просадет производительность

N>>Да, на проверке типов теряется примерно 20-30% скорости при вызове метода.
N>>В абсолютном значении для нетяжелых вычислений разница небольшая — 2-4 мс.

ЕА>30%(!) — и это только проверки, а еще оверхед для поиска метода по имени итд. итп. Надо совсем никуда не спешить чтобы с этим мириться.

Поэтому по моему скромному мнению стоит использовать проверку типов только там, где это действительно нужно.

ЕА>что protected вижу, а где internal override?

Простите, не знаю, что именно должен делать internal override — но наверняка сэмулировать можно и его. Только тащить всю объектную систему из .NET в JavaScript как минимум странно — настолько же странно, как эмулировать в .NET объектную систему JavaScript, с прототипным наследованием и т.д. А в Python'е по сути нет даже protected и private — и ничего, живут ведь как-то, и не жалуются — такая философия языка.

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

ЕА>ну опять же единственный способ убедиться, что везде вызвается коректно, написать тесты с 100% покрытием

Тесты — да, они ж в любом случае лишними не будут.

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

N>Здравствуйте, Евгений Акиньшин, Вы писали:

N>>>За время программирования на JS лично мне такой проверки не понадобилось почти ни разу.

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

ЕА>>пока проект маленькийи работаешь один и все с памяти держишь — на динамике оно может и быстрее пишется

N>Работал над проектами небольшого размера. Насколько могу судить — для Яваскрипта пока что не очень много таких проектов, чтобы "5 человек в течение 5 лет".

может поэтому и не много

N>Кстати, совсем забыл — для тех, кому необходимо наличие "protected internal override" и проверки типов существует Google Web Toolkit — он напрямую транслирует код из Java в JavaScript.
N>Хоть это и костыли, но вполне рабочие и используемые тем же Google'ом.

т.е. таки пишем на типизированном языке?

ЕА>>что protected вижу, а где internal override?

N>Простите, не знаю, что именно должен делать internal override — но наверняка сэмулировать можно и его. Только тащить всю объектную систему из .NET в JavaScript как минимум странно — настолько же странно, как эмулировать в .NET объектную систему JavaScript, с прототипным наследованием и т.д. А в Python'е по сути нет даже protected и private — и ничего, живут ведь как-то, и не жалуются — такая философия языка.

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

я собственно спорил только с утверждением:

N>JS — объектно-ориентированный язык — не побоюсь сказать, даже более объектно-ориентированный, чем та же Java.
N>И все возможности по инкапсуляции, полиморфизму, и наследованию там присутствуют — просто в непривычном виде

а получилось возможности присутствуют не все, полноценно сэмулировать их нельзя
quod erat demonstrandum

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

N>У вас устаревшие данные. JavaScript уже давно шагнул вперед за DOM — поглядите, например, Angry Birds или Linux в браузере — DOM-модель там упоминается разве только в ключе document.getElementById('canvas').

В случае с canvas в первую очередь важна скорость рендеринга — это делается браузером.
Linux в браузере — это технодемо практического использования у нее никакого. Даже если скорость JavaScript будет сравнима со скоростью native кода (возможно, что на каких-то участках она сравнима уже и сейчас), но это не отменят того факта, что в браузере этот язык так и останется скриптом.

N>И это не говоря уже о серверном NodeJS, который тоже использует Google V8 — и в котором DOM нет вообще.

Понятно, что JavaScript как язык можно запихнуть в любую область. Какое это значение имеет в контексте HTML5, Silverlight, Flash?

Здравствуйте, Евгений Акиньшин, Вы писали:

N>>Кстати, совсем забыл — для тех, кому необходимо наличие "protected internal override" и проверки типов существует Google Web Toolkit — он напрямую транслирует код из Java в JavaScript.
N>>Хоть это и костыли, но вполне рабочие и используемые тем же Google'ом.

ЕА>т.е. таки пишем на типизированном языке?

Угу. На голом js что-то побольше "hello world" писать никому не хочется, вот и рождаются конвертеры с java/C#/.. на "замечательный недооценённый" язык.

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

N>Не вижу причин присобачивать к динамическому языку костыли в виде системы проверки типов. Тут всего лишь другой подход — у него есть свои плюсы и минусы — так же как и у статически типизированных языков. Если смотреть с точки зрения C#/Java-программиста — то да, без проверки типов жить невозможно.
Назови хоть один минус статической типизации.

N>А вот мне с точки зрения любителя функциональных и динамических языков непонятно, как можно жить без возможности pattern matching'а и добавления методов в рантайме.
Зачем добавлять метода в рантайм?
Где ты видел pattern matching в жибаскрипте?

N>Каюсь, про приближение к gcc, конечно, преувеличил. И я не уточнил — приближается к gcc производительность в определенных задачах, за счет JIT компиляции.
Она приближается _только_ там где код фактически статически типизированный.

N>Теперь у меня встречный вопрос — как средствами самого языка в Java добавить mixin'ы?
Они есть в скале из коробки. А скала компилируется все в ту же JVM.
В немерле их можно на раз два прикрутить макросами.