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

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

N>>Моя практика показывает, что тестов достаточно. Разумеется, если они грамотно построены (вот это уже совершенно неформализуемый признак).
WH>А я обхожусь исключительно функциональными тестами. Как показывает практика при наличии статической типизации другие не нужны.

Извини, "другие" это какие? Юниттесты? Мнэээ... Давай разберём следующий пример (да, я знаю, что он почти учебный):

int // number of roots
solve_square(double a, double b, double c, double *px1, double *px2)
{
  double dd = b*b - 3*a*c;
  if (dd < 0)
    return 0;
  double qb = -b / (2.0 * a);
  if (dd == 0) {
    *px1 = qb;
    return 1;
  }
  double d2a = sqrt(d) / (2.0 * a);
  *px1 = qb + d2a;
  *px2 = qb - d2a;
  return 2;
}

В первой строчке тела ошибка в коэффициенте. Как ты предлагаешь с помощью статической типизации выловить эту ошибку на этапе компиляции? Прошу чёткое решение для любого из достаточно распространённых языков. Математическую библиотеку не привлекать. И опиши, что будет в твоём проекте, если в функции такого низкого уровня будет ошибка. Сможешь ли ты опознать при запуске функционального теста, что вообще есть ошибка, и указать, в какой функции?

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

ВВ>Это не вы ли спрашивали, удобнее ли Немерле, чем ПХП?

Точно не я: я не терплю PHP настолько, что отказываюсь связываться с любой работой, где он хоть как-то участвует.
А к чему вопрос?

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

N>А подумай с другой стороны — если бы не его характер, он бы бросил Nemerle.
Если увидит что-то получше бросит.
Но все остальное недотягивает...

N>В динамической типизации нет ничего фундаментально ущербного: это то, как думают _люди_. У нашего мышления не бывает статической типизации, она — не более чем оптимизация под свойства современных компьютеров.
Ерунду ты говоришь.
Люди думают на языке и в соответствии с правилами языка.
А язык может быть любым.

Также не нужно забывать что человек может держать в голове 7+-2 сущьности.
А компилятор может запоминать пока память у компьютера не кончится... а учитывая сколько на современных машинах памяти...
Вот и получается что в случае с динамической типизацией человек должен следить за всем сам (а краткосрочная память у человека мааааленькая). А в случае со статикой можно кучу всего переложить на компилятор.
И чем система типов круче тем больше может проверить компилятор.
Причем чем больше делает проверок компилятор тем меньше их остается рантайму. Скажем зависимые типы могут устранить практически все проверки в программе. Делая код надежней и быстрее.
Да и человеку будет легче. Вместо того чтобы судорожно соображать что там может придти можно посмотреть на тип функции. А если не посмотришь компилятор тебя носом ткнет.
Так что статическая типизация это оптимизация не только под процессор но и под человека.

Вот и получается что динамическая типизация не подходит ни человеку ни машине.

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

N>Потому что подменяет статически типизированный язык — мультиконцептуальным, где преобладает статическая типизация, но можно использовать и динамическую.
Ты вообще о чем?
Метапрограммирование в немерле работает на этапе компиляции и никакой динамики не использует.

N>Любое место, где используешь динамическую типизацию, начинает хромать по тем же причинам, что и полностью динамическая типизация.
Да я не спорю.
И я уже сказал что единственное место где я считаю допустимой динамику это загрузка кода во время работы программы.
Там просто иначе невозможно.
Но и тут динамика должна быть ограничена одним привидением типа при загрузке кода.

N>Так он статически или динамически типизирован?
Статически.

WH>>И этот движок разбирает C# со скоростью более 2х мегабайт в секунду на моей машине.
WH>>http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/peg-parser
N>Не буду пытаться спорить с этой цифрой. Но к чему она?
К тому что можно сделать при помощи метапрограммирования времени компиляции на статически типизированном языке.
Просто у меня возникает ощущение что ты не веришь в то что макросы могут работать в статически типизируемом языке.
Так они могут. И делают это очень хорошо.

WH>>Только не надо про динамику. Ошибка есть ошибка. И в отличии от шаблонов С++ она имеет все шансы вылезти в продакшене, а не при компиляции.
WH>>Нужны явные контракты. Это решает много проблем.
N>Это речь про статику или динамику?
Про статику конечно. В динамике контракты бесполезны ибо их проверять некому.

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

N>>В динамической типизации нет ничего фундаментально ущербного: это то, как думают _люди_. У нашего мышления не бывает статической типизации, она — не более чем оптимизация под свойства современных компьютеров.
WH>Ерунду ты говоришь.
WH>Люди думают на языке и в соответствии с правилами языка.

Я не видел, чтобы люди думали, например, "uint32", а не "целое число", кроме случаев, когда их специально приучили к специфике предметной области. И даже "шестизначное число" — это уже адаптация к специфике конкретного применения, которую ещё надо уточнить и понять (например, ведущие нули нужны или нет?)

WH>А язык может быть любым.

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

WH>Также не нужно забывать что человек может держать в голове 7+-2 сущьности.
WH>А компилятор может запоминать пока память у компьютера не кончится... а учитывая сколько на современных машинах памяти...
WH>Вот и получается что в случае с динамической типизацией человек должен следить за всем сам (а краткосрочная память у человека мааааленькая). А в случае со статикой можно кучу всего переложить на компилятор.

Получается иное: что человек в принципе не начинает с чёткого мышления о сущностях, и тем более о их типизации. Более того, всякая типизация есть _ограничение_, а ограничения в мышлении применяются только тогда, когда они не мешают, и до тех пор, пока они не мешают. Ограниченное мышление вытесняется рано или поздно, и неважно, в чём это ограничение — в uint32 или в борьбе рабочего класса за свои интересы.

Если у тебя нет динамической типизации, то альтернативой в случае изменения является смена API и порой радикальная. Например, в Erlang типичен возврат {error, Error} в качестве признака ошибки, где Error — произвольно сложный терм. Обычно он не анализируется (или анализируется только на типичные шаблоны). Полный анализ ведёт уже человек. Что ты дашь альтернативой при статической типизации? Базовый класс Exception?

WH>И чем система типов круче тем больше может проверить компилятор.

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

WH>Да и человеку будет легче. Вместо того чтобы судорожно соображать что там может придти можно посмотреть на тип функции. А если не посмотришь компилятор тебя носом ткнет.

"Что там может прийти" должно быть в документации.

WH>Так что статическая типизация это оптимизация не только под процессор но и под человека.
WH>Вот и получается что динамическая типизация не подходит ни человеку ни машине.

"Ерунду ты говоришь" ((c) некто WolfHound)

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

N>>Потому что подменяет статически типизированный язык — мультиконцептуальным, где преобладает статическая типизация, но можно использовать и динамическую.
WH>Ты вообще о чем?
WH>Метапрограммирование в немерле работает на этапе компиляции и никакой динамики не использует.

Что ты здесь понимаешь под метапрограммированием?

WH>>>И этот движок разбирает C# со скоростью более 2х мегабайт в секунду на моей машине.
WH>>>http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/peg-parser
N>>Не буду пытаться спорить с этой цифрой. Но к чему она?
WH>К тому что можно сделать при помощи метапрограммирования времени компиляции на статически типизированном языке.
WH>Просто у меня возникает ощущение что ты не веришь в то что макросы могут работать в статически типизируемом языке.
WH>Так они могут. И делают это очень хорошо.

Я верю. Но проблема не в этом и не в макросах.

WH>>>Только не надо про динамику. Ошибка есть ошибка. И в отличии от шаблонов С++ она имеет все шансы вылезти в продакшене, а не при компиляции.
WH>>>Нужны явные контракты. Это решает много проблем.
N>>Это речь про статику или динамику?
WH>Про статику конечно. В динамике контракты бесполезны ибо их проверять некому.

Ну вообще-то даже простой assert() времени выполнения уже проверяет какой-то контракт.

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

M>Вот это — верх аргументации, ага.
Ты бы почитал на что я отвечал.
Одна из фраз вообще твоя. Я там просто несколько слов изменил для того чтобы продемонстрировать тебе ущербность твоей логики. Но похоже не помогло.

M>Никому не нужна сферовакуумная скорость в отрыве от задачи. Если динамически типизируемый Erlang дает мне обработать 5000 запросов в секунду при том, что у меня пиковая нагрузка 1000, то зачем мне нужен статически типизируемый C#, например?
Это пока ты остаешься в рамках.
Но шаг в сторону и превет.
Если нужно что-то посчитать начинаются тормоза.
Скажем при помощи этого http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/peg-parser#peg-parser/CSharp
Я могу парсить C#4 со скорость 2 мегабайта в секунду.
Слабо повторить на ерланге?

M>Ошибки на этапе компиляции — это очень малая часть всех ошиок, что встречаются в программировании. Даже здесь, в «философии программирвания» про это говорили, и не раз, со ссылками на исследования и т.п.
Да мне плевать что кто-то что-то там писал.
http://www.impredicative.com/ur/
Вот попробуй тестами гарантировать отсутствие перечисленных проблем.

Not only do they not crash during particular page generations, but they also may not:

* Suffer from any kinds of code-injection attacks
* Return invalid HTML
* Contain dead intra-application links
* Have mismatches between HTML forms and the fields expected by their handlers
* Include client-side code that makes incorrect assumptions about the "AJAX"-style services that the remote web server provides
* Attempt invalid SQL queries
* Use improper marshaling or unmarshaling in communication with SQL databases or between browsers and web servers

M>Процитирую
Ты не забывай заголовки читать... а то смешно получается.

Static Typing Where Possible, Dynamic Typing When Needed

Если у тебя есть помойка со слабо структуированными данными то приходится как то выкручиваться.
Но это очень редкий случай.
Но и тут польза динамической типизации мягко говоря не очевидна.
Ну во есть у тебя какая то байда в которой есть не поймешь что.
И что дальше?
Ну загрузил ты это все в объект.
И что дальше?
Обратишься к полю по имени? А если там ничего нет? Данные то у нас структуированы как попало.
Что делать?
Схлопывать ласты?
Или проверять есть ли у объекта поле?
И так на каждое поле. И каждый подобъект. И так до бесконечности.

Теперь сравним со статикой:
Описал тип.
И макросом сгенерировал для этого типа читалку которая проверяет наличие всех нужных нам полей. Если поле опционально то Option никто не отменял.

Итого:
Статика:
1)Проверка структуры декларативна.
2)Автокомплит, рефакторинг, навигация,...
3)Компилятор находит все опечатки и несоответствия типов. Хрен что забудешь.
4)Скорость работы высокая.

Динамика:
1)Проверки структуры императивны и размазаны по всей программе.
2)Поддержки IDE нет. Ибо структура объекта не извесна. И взять ее негде.
3)Компилятор молчит.
4)Тормоза.

Где профит то?

M>Не имею ни малейшего представления. Ах, Немерле, наверное? Ну, когда Немерле станет хоть где-то когда-то использоваться, тогда и поговорим.
Тебе нужен миллион леммингов?
Или корпорация?

M>Нет. У меня есть опыт компании, разрабатывавшей Erlang, и использующей его в гигантском проекте. Оказалось, что преимуществ статическая типизация им не дает.
У тебя есть демагогия: Аппеляция к толпе. Аппеляция к авторитету.
Технических аргументов нет.

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

N>Что ты здесь понимаешь под метапрограммированием?
Метапрограмма — программа которая пишет другую программу.
Метапрограммирование — написание программы которая пишет другую программу.

Макросы немерла это программы которые пишут другие программы.

N>Я верю. Но проблема не в этом и не в макросах.
Какая проблема? Все отлично работает.

N>Ну вообще-то даже простой assert() времени выполнения уже проверяет какой-то контракт.
Фигня это, а не контракт.

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

N>В первой строчке тела ошибка в коэффициенте. Как ты предлагаешь с помощью статической типизации выловить эту ошибку на этапе компиляции? Прошу чёткое решение для любого из достаточно распространённых языков. Математическую библиотеку не привлекать. И опиши, что будет в твоём проекте, если в функции такого низкого уровня будет ошибка. Сможешь ли ты опознать при запуске функционального теста, что вообще есть ошибка, и указать, в какой функции?
Проверь тестами:

Not only do they not crash during particular page generations, but they also may not:

* Suffer from any kinds of code-injection attacks
* Return invalid HTML
* Contain dead intra-application links
* Have mismatches between HTML forms and the fields expected by their handlers
* Include client-side code that makes incorrect assumptions about the "AJAX"-style services that the remote web server provides
* Attempt invalid SQL queries
* Use improper marshaling or unmarshaling in communication with SQL databases or between browsers and web servers

http://www.impredicative.com/ur/

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

N>Я не видел, чтобы люди думали, например, "uint32", а не "целое число", кроме случаев, когда их специально приучили к специфике предметной области. И даже "шестизначное число" — это уже адаптация к специфике конкретного применения, которую ещё надо уточнить и понять (например, ведущие нули нужны или нет?)
Сначала "я не видел" и тутже пошли отмазки...

N>Получается иное: что человек в принципе не начинает с чёткого мышления о сущностях, и тем более о их типизации. Более того, всякая типизация есть _ограничение_, а ограничения в мышлении применяются только тогда, когда они не мешают, и до тех пор, пока они не мешают. Ограниченное мышление вытесняется рано или поздно, и неважно, в чём это ограничение — в uint32 или в борьбе рабочего класса за свои интересы.
Ну да... давай уберем все перила с балконов?
Это же ограничения.

Не нарвится тип смени. В че проблема то?
А что касается не ограниченного мышления то оно плод твоего воображения.
Мышление всегда ограничено.
Уж такие люди ограниченные создания.

N>Если у тебя нет динамической типизации, то альтернативой в случае изменения является смена API и порой радикальная. Например, в Erlang типичен возврат {error, Error} в качестве признака ошибки, где Error — произвольно сложный терм. Обычно он не анализируется (или анализируется только на типичные шаблоны). Полный анализ ведёт уже человек. Что ты дашь альтернативой при статической типизации? Базовый класс Exception?
И чем плох Exception?

N>Никаких возражений. Но это начинает работать только там, где человек намеренно загнал значение в определённые рамки — например, установил, что тут целое число от нуля до миллиона. А если не загнал?
А рамки они часть предметной области.
И если программист имея возможность сделать статические проверки их не сделал то гнать эту обезьяну из разработки поганой метлой.

WH>>Да и человеку будет легче. Вместо того чтобы судорожно соображать что там может придти можно посмотреть на тип функции. А если не посмотришь компилятор тебя носом ткнет.
N>"Что там может прийти" должно быть в документации.
Обычное состояние документации:
Ее нет!
Если таки есть то устарела.
Если таки не устарела то с ошибками.

Актуальную документацию без ошибок я еще не видел. Ни разу.

А типы проверяет робот. У него не забалуешь.

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

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

N>>Я не видел, чтобы люди думали, например, "uint32", а не "целое число", кроме случаев, когда их специально приучили к специфике предметной области. И даже "шестизначное число" — это уже адаптация к специфике конкретного применения, которую ещё надо уточнить и понять (например, ведущие нули нужны или нет?)
WH>Сначала "я не видел" и тутже пошли отмазки...

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

N>>Получается иное: что человек в принципе не начинает с чёткого мышления о сущностях, и тем более о их типизации. Более того, всякая типизация есть _ограничение_, а ограничения в мышлении применяются только тогда, когда они не мешают, и до тех пор, пока они не мешают. Ограниченное мышление вытесняется рано или поздно, и неважно, в чём это ограничение — в uint32 или в борьбе рабочего класса за свои интересы.
WH>Ну да... давай уберем все перила с балконов?
WH>Это же ограничения.

И что показывает твоё сравнение? Именно то, что введение перил или типов — искусственно, ибо вызвано предшествующими действиями (создание многоэтажных домов, впихивание в конкретный тип). Более того, часто оказывается, что типы есть, а перил нет — чему равно сложение 0x5000 и 0x4000 в int16?

WH>Не нарвится тип смени. В че проблема то?

На что я его должен сменить, и почему, если мне нужно, например, представить _число_?

WH>А что касается не ограниченного мышления то оно плод твоего воображения.
WH>Мышление всегда ограничено.

В конкретный момент — да. В общем — нет.

WH>Уж такие люди ограниченные создания.

Ты хочешь уподобить людей компьютеру? Даже в тех пределах, в которых люди ограниченны — они ограничены иначе, чем компьютер.

N>>Никаких возражений. Но это начинает работать только там, где человек намеренно загнал значение в определённые рамки — например, установил, что тут целое число от нуля до миллиона. А если не загнал?
WH>А рамки они часть предметной области.

С чего ты взял?

WH>>>Да и человеку будет легче. Вместо того чтобы судорожно соображать что там может придти можно посмотреть на тип функции. А если не посмотришь компилятор тебя носом ткнет.
N>>"Что там может прийти" должно быть в документации.
WH>Обычное состояние документации:
WH>Ее нет!
WH>Если таки есть то устарела.
WH>Если таки не устарела то с ошибками.

WH>Актуальную документацию без ошибок я еще не видел. Ни разу.

WH>А типы проверяет робот. У него не забалуешь.

Я до сих пор думал, что "RTFS!" это лозунг красноглазных линуксоедов. А тут он приходит почти с противоположной стороны. Непонятно...

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

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

N>>В первой строчке тела ошибка в коэффициенте. Как ты предлагаешь с помощью статической типизации выловить эту ошибку на этапе компиляции? Прошу чёткое решение для любого из достаточно распространённых языков. Математическую библиотеку не привлекать. И опиши, что будет в твоём проекте, если в функции такого низкого уровня будет ошибка. Сможешь ли ты опознать при запуске функционального теста, что вообще есть ошибка, и указать, в какой функции?
WH>Проверь тестами:

И давно ты стараешься отвечать вопросом на вопрос?

Я понимаю, к чему ты это рассказываешь. Но сначала ответь на мои вопросы.

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

N>Это не отмазки. Без намеренного укладывания в прокрустово ложе конкретного типа не зайдёт мысль о соответствующих ограничениях. Конечно, человек — существо гибкое и даже в таких условиях будет работать, но вообще-то они ему претят.
Отучаемся говорить за всех.
Лично я не могу мыслить не накладывая ограничений на сущьность.
И чесно говоря не могу представить как это можно сделать.
Ведь тогда сущьность может быть чем угодно.
Как рассуждения то строить?

N>И что показывает твоё сравнение?
Это не сравнение.
Это иллюстрация того для чего нужны ограничения вообще и типы в частности.

N>Именно то, что введение перил или типов — искусственно, ибо вызвано предшествующими действиями (создание многоэтажных домов, впихивание в конкретный тип).
Чтож теперь обходится без многоэтажных домов и многомегабатных (в смысле исходного кода) программ?

N>Более того, часто оказывается, что типы есть, а перил нет — чему равно сложение 0x5000 и 0x4000 в int16?
Ошибке компиляции в системе с зависимыми типами.

N>Ты хочешь уподобить людей компьютеру? Даже в тех пределах, в которых люди ограниченны — они ограничены иначе, чем компьютер.
Когда ты работаешь с чемто то ты ограничен не только своими ограничениями но и ограничениями этого чегото.
Ограничения внутри программы весьма сложны и многочисленны.
И человек должен их учитывать.
Но ограничения человека не позволяют следить за всем.
И тут на помощь приходит компилятор.

WH>>А рамки они часть предметной области.
N>С чего ты взял?
А откуда ты их тогда взял?

N>Я до сих пор думал, что "RTFS!" это лозунг красноглазных линуксоедов. А тут он приходит почти с противоположной стороны. Непонятно...
Любой крупный проект это всегда RTSF. Исключений я еще не видел.

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

N>>Это не отмазки. Без намеренного укладывания в прокрустово ложе конкретного типа не зайдёт мысль о соответствующих ограничениях. Конечно, человек — существо гибкое и даже в таких условиях будет работать, но вообще-то они ему претят.
WH>Отучаемся говорить за всех.
WH>Лично я не могу мыслить не накладывая ограничений на сущьность.

Те ограничения, о которых ты говоришь, искусственны.

N>>И что показывает твоё сравнение?
WH>Это не сравнение.
WH>Это иллюстрация того для чего нужны ограничения вообще и типы в частности.

Перила возникают там, где уже есть ограничения (нельзя шагать с лестницы вбок).

N>>Именно то, что введение перил или типов — искусственно, ибо вызвано предшествующими действиями (создание многоэтажных домов, впихивание в конкретный тип).
WH>Чтож теперь обходится без многоэтажных домов и многомегабатных (в смысле исходного кода) программ?

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

N>>Более того, часто оказывается, что типы есть, а перил нет — чему равно сложение 0x5000 и 0x4000 в int16?
WH>Ошибке компиляции в системе с зависимыми типами.

Вот именно, что ты выбрал только один вариант из многих возможных. Но вариант в духе Си (не заметили вообще, что есть какая-то проблема) не сильно лучше.

N>>Ты хочешь уподобить людей компьютеру? Даже в тех пределах, в которых люди ограниченны — они ограничены иначе, чем компьютер.
WH>Когда ты работаешь с чемто то ты ограничен не только своими ограничениями но и ограничениями этого чегото.
WH>Ограничения внутри программы весьма сложны и многочисленны.
WH>И человек должен их учитывать.
WH>Но ограничения человека не позволяют следить за всем.
WH>И тут на помощь приходит компилятор.

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

WH>>>А рамки они часть предметной области.
N>>С чего ты взял?
WH>А откуда ты их тогда взял?

Я? Их "взял" тот, кто укладывал на машинный язык.

N>>Я до сих пор думал, что "RTFS!" это лозунг красноглазных линуксоедов. А тут он приходит почти с противоположной стороны. Непонятно...
WH>Любой крупный проект это всегда RTSF. Исключений я еще не видел.

И часто ты читаешь код ядра Windows для реализации своего проекта?

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

WH>>Отучаемся говорить за всех.
WH>>Лично я не могу мыслить не накладывая ограничений на сущьность.
N>Те ограничения, о которых ты говоришь, искусственны.
Они естественны для модели с которой я работаю.
А работать без модели не получится даже на динамически типизируемом языке.

N>Перила возникают там, где уже есть ограничения (нельзя шагать с лестницы вбок).
Почему нельзя?
Можно.
Но будет больно. Возможно смертельно больно.
И динамикой таже байда. Оторвали перила и айда ходить где попало. Если ходить осторожно и прыгать не слишком далеко то вроде даже все хорошо. Но если оступишся костей не соберешь.

N>Зачем? Не обходиться — использовать. И статическую типизацию активно использовать, но при этом не забывать, что она вызвана, как правило, не естественными ограничениями, а спецификой укладки задачи на возможности компьютера.
"Естественность" ограничений вопрос весьма филосовский.
Но главное тут то что ты признал что ограничения есть. И отних нельза избавится.
Осталось признать что контроль ограничений машиной есть благо, а не как тут пытаются всех убедить что зло великое есть сие.

N>Вот именно, что ты выбрал только один вариант из многих возможных. Но вариант в духе Си (не заметили вообще, что есть какая-то проблема) не сильно лучше.
Переполнение для int16 не имеет смысла.
Для uint16 возможны варианты.
Но лично я бы предпочел отдельный тип. Например uintmod16 чтобы ясно дать понять что у нас тут арифметика по модулю.

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

N>но если не позволит сложить int16 и int32, это не есть естественное ограничение, это специфика проекции на возможности компьютера.
Ессно любой уважающий себя компилятор такое позволит.

N>И часто ты читаешь код ядра Windows для реализации своего проекта?
А они где?
Но вот код библиотек .НЕТ рефлектором смотреть приходилось.

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

G>С современными языками довольно сложно придумать адекватное применение динамики.

Потому что водораздел в характеристиках м/у динамикой и статикой стерся. Тут даже не о чем спорить.
Раньше у динамики был целый список преимуществ:
— метапрограммирование
— кодогенерация в рантайм (даже банальный eval("runtime-generated expression") мог решить выбор в пользу динамики)
— невозможность попортить память и прочие важные ресурсы в случае ошибок

Сейчас ни одного этого преимущества нет, ибо managed платформы все это дело обеспечили для своих статически-типизируемых языков. И скорость исполнения того самого промежуточного кода обеспечили тоже.
Так что спор превратился из динамика vs статика, в типизация vs бестиповость. И там остался только один довод в пользу динамики: это возможность запуска некоректной/неполной программы, что удобно для целей макетирования.

Но прикол в том, что для одного и того же языка со статическим выводом типов и прочей оптимизацией мог бы существовать как компилятор, так и такой динамический REPL для макетирования. Схема или Хаскель тому пример. С объектными языками беда, понятное дело, ибо непонятно что делать с незавершенными определениями типов... Но можно как в HUGS prompt, чтобы интерпретатор "глотал" корректную часть программы из файлов, а затем в REPL был доступ к "переваренным" типам для экспериментов.

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

ВВ>V8 — это реализация ECMAScript в Хроме, которая джитится. Причем джитится она напрямую, насколько я знаю, без всякого промежуточного представления. Вот, кстати, тестик, тупой по самое не могу:

ВВ>

ВВ>var list = [];
ВВ>var size = 1000;

ВВ>for (var i = 0; i < size; i++)
ВВ>    list[i] = size - i;

ВВ>function BubbleSort(item)
ВВ>{  
ВВ>    for(var i = 0; i < item.length; i++)
ВВ>    {
ВВ>        for(var j = 0; j < item.length - i - 1; j++)
ВВ>        {
ВВ>            if(item[j + 1] < item[j])
ВВ>            {
ВВ>                var x = item[j];
ВВ>                item[j] = item[j + 1];
ВВ>                item[j + 1] = x;
ВВ>            }
ВВ>        }
ВВ>    }
ВВ>};

ВВ>BubbleSort(list);
ВВ>

ВВ>JScript MSIE8 — 367
ВВ>V8 — 22

ВВ>Как видишь, разница некислая все же.

А это в каких попугаях измерялось? Не уж то в секундах?

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

ВВ>>Как видишь, разница некислая все же.
VD>А это в каких попугаях измерялось? Не уж то в секундах?

В миллисекундах, конечно.

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

WH>>>Отучаемся говорить за всех.
WH>>>Лично я не могу мыслить не накладывая ограничений на сущьность.
N>>Те ограничения, о которых ты говоришь, искусственны.
WH>Они естественны для модели с которой я работаю.

Вот именно, что с которой _ты_ работаешь. Это включает в себя не только персональную ограниченность опыта, но и временную. А что будет, когда она будет меняться? А она таки будет меняться.

WH>А работать без модели не получится даже на динамически типизируемом языке.

Не получится, не спорю. Но дальше вопрос — пределы её гибкости.

N>>Перила возникают там, где уже есть ограничения (нельзя шагать с лестницы вбок).
WH>Почему нельзя?
WH>Можно.
WH>Но будет больно. Возможно смертельно больно.
WH>И динамикой таже байда. Оторвали перила и айда ходить где попало. Если ходить осторожно и прыгать не слишком далеко то вроде даже все хорошо. Но если оступишся костей не соберешь.

Нет, динамика не "та же байда", что отсутствие перил. Как раз просто перила — это динамика: тебя ограничили только от невольных ошибок. А когда тебя зажали в узкую полосу на лестнице и обрешётили, как в ментовке — это статика. Точнее, даже не так: тебя ещё ставят на рельсы. Чтобы катился быстро. Да, это будет быстрее. Но с соответствующими проблемами: например, ты сможешь пройти сам, но не сможешь пронести два пакета еды — для них банально не хватит места.

Вообще, эти аналогии всегда хромают и поэтому смешны. Предлагаю избавиться от них.

N>>Зачем? Не обходиться — использовать. И статическую типизацию активно использовать, но при этом не забывать, что она вызвана, как правило, не естественными ограничениями, а спецификой укладки задачи на возможности компьютера.
WH>"Естественность" ограничений вопрос весьма филосовский.
WH>Но главное тут то что ты признал что ограничения есть. И отних нельза избавится.

Не считаю это "главным". Ограничения есть всегда. Но есть принципиальная разница как минимум между следующими тремя категориями
1) естественные ограничения (например, законы сохранения)
2) ограничения укладки в модель
3) ограничения укладки на возможности компьютера

и, во-первых, ты явно нечётко разделяешь (2) и (3). Во-вторых, статическая типизация — это именно (3), в то время как человек, не зажатый явно в рамки применяемой системы типов, мыслит на уровне (1) и (2). Статическая типизация как процесс — в основном переход от (2) к (3). Тут у тебя обязательно int16, а тут — int32 (а завтра потребуют не экономить байты, а хранить числа до миллиона — int16 пойдёт лесом). Тут у тебя обязательно два возвращаемых значения, а третье уже не лезет. Тут у тебя ошибка — целое (и надо хитрым образом распределять диапазоны значений — системные налево, библиотечные направо, свои — прямо и вверх через левое ухо). И тэ дэ и тэ пэ. Цена статики — та же, что её преимущество — чёткая определённость. Надо изменить возможности, особенно расширить — надо ломать интерфейс.

В Erlang я могу передать любые уточнения как элементы списка свойств (proplist), если функция в принципе принимает подобные уточнения. Аналогично со всеми динамическими языками. В статике получаются монстры в стиле CreateFile(), которые тут же устаревают, не успев выпуститься (ты можешь указать в ней путь относительно каталога, заданного другим хэндлом, как в юниксовой openat()?)

WH>Осталось признать что контроль ограничений машиной есть благо, а не как тут пытаются всех убедить что зло великое есть сие.

Я не знаю, кто тут "пытается убедить" что "зло великое". Я говорю, что это благо только на нижнем уровне. На верхнем оно действительно становится злом (великим или нет — вопрос эмоций, не учитываем). Хорошая аналогия из сетевого мира: на нижних уровнях протокольного стека по максимуму используются двоичные форматы посылок с фиксированным размещением и смыслом полей, иначе просто времени не хватит на элементарные операции типа форварда пакета. Но на верхних уровнях ситуация совсем другая — в завивисимости от лагеря, это или ASN.1 с двоичными кодеками (ISO), или текстовые протоколы (IETF). А всё почему? — потому что подобные форматы не только сконструированы как расширяемые и пригодные выдержать что угодно (чему равно максимально представимое целое в BER?, но и принципиально неограничиваемые — ты не можешь придумать в рамках ASN.1+BER, не нарушая правила, как сделать нерасширяемый формат посылки. А любая мультиформатность — это уже динамика: ты в рантайме определяешь, что пришло и как с этим работать.

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

N>>Вот именно, что ты выбрал только один вариант из многих возможных. Но вариант в духе Си (не заметили вообще, что есть какая-то проблема) не сильно лучше.
WH>Переполнение для int16 не имеет смысла.

Этого не понял. В каком смысле оно не имеет смысла? Нельзя допускать, чтобы оно происходило? Ну так ведь допускают, если не попросить.

WH>Для uint16 возможны варианты.
WH>Но лично я бы предпочел отдельный тип. Например uintmod16 чтобы ясно дать понять что у нас тут арифметика по модулю.

Да, в статически типизированном языке это хороший вариант.

N>>Компилятор следит не за ограничениями, свойственными предметной области, а ограничениями, которые ты сам ввёл. У тебя есть промежуточный уровень для этого. И хорошо, если оно не позволит сложить секунды с километрами —
WH>Ты всегда работаешь с моделью предметной области.
WH>И у модели есть ограничения.
WH>Вот за ними компилятор и следит.

Нет, он за ними не следит. Следит за тем, что ты ввёл в модель типов. Проекцию же на неё выполняешь ты, как программист. Тебе это позволяет получать нужный результат, например, в духе твоего примера — невалидный HTML на выходе невозможен. Но это ты сделал, и ты контролируешь, например, что используются _только_ твои типы. Если у тебя выходная функция будет конвертировать выдачу в текст и приписывать к нему "<a<<<baba<<<galamaga<<<<", как у тебя это отловится? Да никак, потому что ты где-то по любому должен был перевести в текст, и тут к тебе врывается реальный мир.

N>>но если не позволит сложить int16 и int32, это не есть естественное ограничение, это специфика проекции на возможности компьютера.
WH>Ессно любой уважающий себя компилятор такое позволит.

Дааа? Ты зря так думаешь. В Go специально запретили такие вещи — более того, если у тебя int и int32 имеют одинаковую размерность, то всё равно нужна явная конверсия между ними. И мне кажется, что это значительно правильнее для дела Света статической типизации.

N>>И часто ты читаешь код ядра Windows для реализации своего проекта?
WH>А они где?

Для NT4 и части W2000 валяется на каждом углу. Для более нового не видел.

WH>Но вот код библиотек .НЕТ рефлектором смотреть приходилось.

Значит, плохая документация.

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

N>1) естественные ограничения (например, законы сохранения)
N>2) ограничения укладки в модель
N>3) ограничения укладки на возможности компьютера

N>и, во-первых, ты явно нечётко разделяешь (2) и (3).
А это одно и тоже.
Ибо нет смысла делать модель которую нельзя впихнуть в компьтер.

А номер 1 это вообще смех на палочке.
Какие "естественные" ограничения у компилятора? А у бугалтерской программы? А у веб сайта?...

Программ которые имеют дело с твоими "естественными" ограничениями ничтожно малое колличество.

N>Во-вторых, статическая типизация — это именно (3), в то время как человек, не зажатый явно в рамки применяемой системы типов, мыслит на уровне (1) и (2).
1 не существует для почти 100% задач. 2-3 одно и тоже ибо не имеет смысла строить модель программы в отрыве от того где эта программа будет исполняться.

N>Цена статики — та же, что её преимущество — чёткая определённость. Надо изменить возможности, особенно расширить — надо ломать интерфейс.
Это не цена. Это всегда преимущество.
Вот буквально вчера делал рефакторинг для дальнейшего расширения функциональности.
Началось все с:

     -         private _rule : Rule;
     +         private _rule : option[Rule];

И вот к чему привело http://code.google.com/p/nemerle/source/detail?r=9272
После этих правок все скомпилировалось и заработало с первой попытки.
В процессе ничего сломано небыло.
Все места для правки показал компилятор.

А теперь скажи мне как мне проделать тоже самое с динамической типизацией?
Я просто не представляю как можно провести столько изменений без помощи роботов и ничего не сломать.

Может программисты на динамически типизированных языках мега гении и могут держать в голове всю программу?
Тогда не ясно почему вы до сих пор не захватили мир?

N>В Erlang я могу передать любые уточнения как элементы списка свойств (proplist), если функция в принципе принимает подобные уточнения.
Ты блин не поверишь.
Если функция принимает подобные уточнения то я тебе тоже самое и в статически типизированном языке на раз сделаю.

N>Аналогично со всеми динамическими языками. В статике получаются монстры в стиле CreateFile(), которые тут же устаревают, не успев выпуститься (ты можешь указать в ней путь относительно каталога, заданного другим хэндлом, как в юниксовой openat()?)
Не делай мне смешно.
Это просто два разных подхода.
Мелкософты сделали одну навороченную функцию. Линуксойды сделали кучу специализарованных.
Никакого отношения к типизации это не имеет.

И лично я считаю что обе реализации говно.
Ибо завязаны на глобальные переменные.
Сам пойемешь где я их нашол или подсказать?
Хотя это тема для отдельного флейма.

N>Но на верхних уровнях ситуация совсем другая — в завивисимости от лагеря, это или ASN.1 с двоичными кодеками (ISO),
Ты опять делаешь мне смешно.
Приводить ASN.1 в качестве защиты динамики...
Нука раскажи что это такое если не описание типов:

FooProtocol DEFINITIONS ::= BEGIN

    FooQuestion ::= SEQUENCE {
        trackingNumber INTEGER,
        question       IA5String
    }

    FooAnswer ::= SEQUENCE {
        questionNumber INTEGER,
        answer         BOOLEAN
    }

END

N>Этого не понял. В каком смысле оно не имеет смысла? Нельзя допускать, чтобы оно происходило? Ну так ведь допускают, если не попросить.
Ну в Сях много чего допускают что не имеет смысла.

N>Нет, он за ними не следит. Следит за тем, что ты ввёл в модель типов. Проекцию же на неё выполняешь ты, как программист. Тебе это позволяет получать нужный результат, например, в духе твоего примера — невалидный HTML на выходе невозможен. Но это ты сделал, и ты контролируешь, например, что используются _только_ твои типы. Если у тебя выходная функция будет конвертировать выдачу в текст и приписывать к нему "<a<<<baba<<<galamaga<<<<", как у тебя это отловится? Да никак, потому что ты где-то по любому должен был перевести в текст, и тут к тебе врывается реальный мир.
Если какойто гоблин начал специально обходить защиту компилятора это он сам себе злобный буратино.
Нормальный человек это делать не будет.
Так что мимо.

N>Дааа? Ты зря так думаешь. В Go специально запретили такие вещи — более того, если у тебя int и int32 имеют одинаковую размерность, то всё равно нужна явная конверсия между ними.
Про Go и его авторов у меня есть исключительно не цензурные соображения.

N>И мне кажется, что это значительно правильнее для дела Света статической типизации.
Ты обратился не по адресу.
Я исключительно прагматичен.

N>Значит, плохая документация.
Так а я о чем? И она вся такая.