Надо теперь, чтобы кто-нибудь написал статью "поскольку джаваскрипт не предназначен для программирования в большом, а система модулей и скоупов Си хуже любой из инкарнаций модулей JS, Си также не предназначен для программирования в большом"
В JS случайно забытый var приводит к использованию (созданию) глобальной переменной.
В C при опечатке в имени поля структуры - будет ошибка при компиляции. В Python - будет ошибка при работе программы. В JavaScript - это не ошибка, будет "значение по-умолчанию".
В C проверяется количество и тип параметров. В Python - хотя бы количество хотя бы в runtime.
В JavaScript - можно позвать функцию с любым количеством параметров, ошибки не будет даже в runtime.
Система типов в JS "в непонятной ситуации - считаем всё строками". По сравнению с JS можно считать C аккуратным со строгой системой типов.
Есть впечатление, что чем более повышается уровень программирования, тем больше самоограничений мы на себя накладываем. В Agda, вроде, вообще ограничение уже математическое (она же Тьюринг-неполная?).
Но вот есть ли за корреляцией уровня абстрагирования программирования и его scale причинно-следственная связь, неясно.
Наиболее популярный ответ немного хромает, например:
> There is no modularization system; there are no classes, interfaces, or even namespaces. These elements are in other languages to help organize large codebases.
> The inheritance system -- prototype inheritance -- is both weak and poorly understood. It is by no means obvious how to correctly build prototypes for deep hierarchies (a captain is a kind of pirate, a pirate is a kind of person, a person is a kind of thing...) in out-of-the-box JavaScript. — даже хардкорные ООПшники какбы уже давно согласились, что при любом сомнении лучше предпочитать агрегацию наследованию.
> There is no encapsulation whatsoever; every property of every object is yielded up to the for-in construct, and is modifiable at will by any part of the program. — снова фигня: замыкания обеспечивают нужную инкапсуляцию, а зачем ограничивать доступ к полям структур, неясно.
Я о том, что странно, когда в структуре одни данные закрыты, а другие нет. Контекст в JS все-таки замыканиями структурируется, а не зависимостью от классов.
>а зачем ограничивать доступ к полям структур, неясно.
Скорее всего, имеется в виду доступ к полям прототипа, там, где это не нужно. Например, при обходе циклом for in. Признаться, на практике никогда не имел с этим проблем, хотя книжки советуют проверять hasOwnProperty.
Тут из меня плохой советчик, я вебом не занимаюсь. Но тот же Dart выглядит неплохо. Практичнее, чем многие компиляторы в JS из статических языков, коих сейчас туча.
Да, к нему сейчас как раз присматриваюсь. Сам тоже этим не особо занимался последние 4 года, но вот сейчас нужно пару вещей сделать и решил посмотреть, может что интересное придумали
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
timeasmymeasure
no subject
Date: 2014-01-28 06:48 am (UTC)no subject
Date: 2014-01-28 07:23 am (UTC)no subject
Date: 2014-01-28 07:44 am (UTC)no subject
Date: 2014-01-28 08:00 am (UTC)no subject
Date: 2014-01-28 08:40 am (UTC)no subject
Date: 2014-01-28 08:48 am (UTC)no subject
Date: 2014-01-28 01:13 pm (UTC)В C при опечатке в имени поля структуры - будет ошибка при компиляции. В Python - будет ошибка при работе программы.
В JavaScript - это не ошибка, будет "значение по-умолчанию".
В C проверяется количество и тип параметров. В Python - хотя бы количество хотя бы в runtime.
В JavaScript - можно позвать функцию с любым количеством параметров, ошибки не будет даже в runtime.
Система типов в JS "в непонятной ситуации - считаем всё строками". По сравнению с JS можно считать C аккуратным со строгой системой типов.
no subject
Date: 2014-01-28 09:00 am (UTC)Но вот есть ли за корреляцией уровня абстрагирования программирования и его scale причинно-следственная связь, неясно.
Наиболее популярный ответ немного хромает, например:
> There is no modularization system; there are no classes, interfaces, or even namespaces. These elements are in other languages to help organize large codebases.
> The inheritance system -- prototype inheritance -- is both weak and poorly understood. It is by no means obvious how to correctly build prototypes for deep hierarchies (a captain is a kind of pirate, a pirate is a kind of person, a person is a kind of thing...) in out-of-the-box JavaScript.
— даже хардкорные ООПшники какбы уже давно согласились, что при любом сомнении лучше предпочитать агрегацию наследованию.
> There is no encapsulation whatsoever; every property of every object is yielded up to the for-in construct, and is modifiable at will by any part of the program.
— снова фигня: замыкания обеспечивают нужную инкапсуляцию, а зачем ограничивать доступ к полям структур, неясно.
no subject
Date: 2014-01-28 09:31 am (UTC)чтобы не появилась зависимость от детали реализации.
no subject
Date: 2014-01-28 12:32 pm (UTC)no subject
Date: 2014-01-28 09:36 am (UTC)Скорее всего, имеется в виду доступ к полям прототипа, там, где это не нужно. Например, при обходе циклом for in. Признаться, на практике никогда не имел с этим проблем, хотя книжки советуют проверять hasOwnProperty.
no subject
Date: 2014-01-28 01:31 pm (UTC)django можно vibe.d заменить(функциональность не дотягивает конечно, но легче самому дописывать), а с фронтендом что делать?
no subject
Date: 2014-01-28 03:18 pm (UTC)Но тот же Dart выглядит неплохо. Практичнее, чем многие компиляторы в JS из статических языков, коих сейчас туча.
no subject
Date: 2014-01-28 03:31 pm (UTC)no subject
Date: 2014-01-28 06:04 pm (UTC)no subject
Date: 2014-01-29 08:38 am (UTC)no subject
Date: 2014-02-02 05:03 pm (UTC)