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

A>Нет, я не понимаю, что в JavaScript непредсказуемого (не необычного, а непредсказуемого) после прочтения спецификации?

Я (и не только я, например Douglas Crockford ) говорю о качестве самой спецификации.

Ну не должно такое:

function foo()
{
  return 
  {
    ok:true
  };
}

function foo()
{
  return { 
    ok:true 
  };
}

генерировать разные результаты.

Этот semicolon injection это вообще недоразумение. Либо это ruby|lua|python|vb|etc. тип синтаксиса либо это C|C++|Java|Pike|Squirrel|etc.

Т.е. стоит в текст воткнуть символы \u2028 или \u2029 (которые далеко не всеми редакторами воспринимается как перевод строки, а просто как whitespace) и все — тот хрустальный замок можно только в качестве наждака использовать. Во всяком случае искать почему оно не работает можно до посинения.

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

CS>Либо это ruby|lua|python|vb|etc. тип синтаксиса либо это C|C++|Java|Pike|Squirrel|etc.

Почему?

CS>Т.е. стоит в текст воткнуть символы \u2028 или \u2029 (которые далеко не всеми редакторами воспринимается как перевод строки, а просто как whitespace) и все — тот хрустальный замок можно только в качестве наждака использовать. Во всяком случае искать почему оно не работает можно до посинения.

Да, а можно ещё кириллические буквы вместо латинских использовать.

M>>Re: [js] А вот интересно ...>>JS печально известен своим идиотским правилом, что у него один scope на тело функции. Второго такого >>языка, возможно и нет. Починить это можно так (я как то переписывал код с JS и долго не мог понять >>зачем это нужно):

M>>Ну какбы всякие Python, php тоже с таким вот идиотским правилом

N>Угу — по сравнению с ними Perl с его my выглядит значительно приятнее (я уж не вспоминаю, что local играет роль ещё и try-finally для замены переменной или элемента хэша).

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

CS>Предполагается что это свойство наследуется всеми языками использующими её.
CS>И это действительно так за единственным исключением — ECMAScript.
CS>Абсолютно не понятно почему оно так собственно. Ради чего?

Руками парсер писали. Для быстродействия. И облажались. А потом объявили баг — фичей.

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

dmz>Кстати, понятно почему — разрешение переменных по блокам — достаточно ресурсоемкий алгоритм

Ничего там трудоемкого нет. Вообще.

Вот процедура которая парсит блок:
http://code.google.com/p/tiscript/source/browse/trunk/com/cs_com.cpp#2142

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

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

CS>>Либо это ruby|lua|python|vb|etc. тип синтаксиса либо это C|C++|Java|Pike|Squirrel|etc.

A>Почему?

"Патамучта" вот это вот все хорошо:

function foo() { return 0; }

function foo() 
         { return 0; }

  var baz = { bar: { ok: false } };
  var baz = 
   { 
     bar: 
      { 
        ok: false 
      } 
   };

А это вот вдруг не работает:

  return 
    { 
      ok: false 
    };

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

M>Re[3]: [js] А вот интересно ...
M>Perl потихоничку отмирает, с сожалению

Ну не знаю, к сожалению или без. Я на нём много писал, но с какого-то момента он задолбал так, что больше не хочется его использовать. Основные неприятности:

1. Нестрогая типизация скаляров, нет чёткой границы между числами и строками. Есть контексты, в которых это больно бьёт граблями. Последний встретившийся пример: экспорт в YAML стандартным модулем превратил строку типа "123000" в число, хотя это по контексту был префикс телефонного номера и не мог быть числом — приёмный парсер на этом обломался. Или вот "0" — false, а "00" — true. Я сравниваю с Питоном — там всё чётче: пересечь границу типов от строки к числу или наоборот можно только явно, типизация хоть и динамическая, но строгая.

2. Манера генерировать undef в массе случаев когда данных нет — вместо генерации исключения. Например, в Питоне получить элемент словаря с вылетом если его нет — "a[b]", а с возвратом None который аналог undef — "a.get(b,None)". В перле a{b} даёт возврат undef, если элемента нет, а для вылета надо писать или явный код проверки, или отдельную функцию. В результате программист обламывается писать проверки и генерирует код, который вместо адекватного действия гонит туфту.

3. Средства, удобные для программ размером в пару экранов, и средства, удобные для больших объёмов кода, резко различаются, а вторые — синтаксически громоздки. До какого-то размера можно использовать массивы и хэши напрямую, а после него — только по ссылке. А значит надо уже наворачивать скобки и кавычки. Есть определённый синтаксический сахар — сначала вместо ${$a}{b} придумали $a->{b}, затем вместо $a->{b}->{c}->{d} придумали $a->{b}{c}{d}, но всё это выглядит ужаснее, чем a.b.c.d, как в питоне и многих прочих. На сложном коде в глазах страшно рябит и работать с этим становится невозможно.

Конечно, есть и дофига хорошего. Но мне как-то от него пользы не было.:)