Ничего про него не знаю. Еще можно сказать что в C/C++ также нет приличной модульности, есть только инклюды.
Только инклюды?
Даже в древности были extern/define. Страуструп конечно боролся с препроцессорром (и namespace это один из), и до сих пор всего его не выпилил.
Так и не понял, что имеешь ввиду такого особенного в плане модульности у JS?
KEFIR написал:
Основная проблема в том, что часть потенциальных ошибок ловит компилятор. Автоматически. Динамическая типизация такого себе не позволяет. Но зато позволяет упасть в самый подходящий момент. А внезапно падающие программы никому не нравятся.
Ошибки с типами данных могут быть отловлены, но есть и куча других проблем,
Другие проблемы нужно обсуждать в другой ветке. Проблема отсутствия проверки типов для языков с динамической типизацией - это Проблема.
KEFIR написал:
Ну и снова приходится возвращаться к тому, что если писать код нормально, то ошибки с "неправильными" типами не будут вызывать фатальных проблем.
Люди ошибаются. Кто-то чаще, кто-то реже. Но они это делают, рано или поздно.
А если инструмент может закрыть автоматически часть потенциальных проблем, то это всеобщее благо и желанная цель.
KEFIR написал:
Попишешь некоторое время на JS и такие вещи не будут тебя шокировать абсолютно. Просто нужно мыслить out of the box :-D
Да и все описанные выражения абсолютно логичны даже с первого взгляда, кроме первого.
Но конечно не для того, кто всю жизнь просидел на C++/Java/C#/Pascal'e :)
Я писал некоторое время на JS. Возвращатся не хочется.
Добавлю про JS: 1 2 - не помню, здесь на сайте недавно жаловались на ==? а вот в JS есть ===
JS ещё тот сын ошибок трудных.. С судьбой, похожую на Perl..
bsivko написал:
Другие проблемы нужно обсуждать в другой ветке. Проблема отсутствия проверки типов для языков с динамической типизацией - это Проблема.
Это не Проблема, это особенность, которую нужно иметь в виду при разработке. Также как необходимость следить за выделением памяти в C/C++. Разве это Проблема в C/C++? Для криворукого и невнимательного "программиста" да, но в целом это особенность языка, которую можно использовать во благо, а можно выстрелить себе в ногу.
Какие действительно серьезные проблемы могут возникнуть от отсутствия типизации? Я правда не могу себе представить. За мою практику в JS были проблемы связанные с облостью видимости замыкания, с операторами сравнения и со многим другим, за что далекие от JS люди его ругают, но никак не с типизацией.
Добавлю про JS:.
Все эти примеры с "кривостью" это примеры особенности языка да и только. Меня забавляют всегда эти посты в духе "смотрите, я написал немыслимую конструкцию, она работает в логике языка, но я считаю что это неправильно. Я умный, а инженеры, которые работают над языком 20 лет, дураки и не смогли учесть такие простые кейсы. ахахаха". На самом деле все подобные кейсы отлично показывают на собеседованиях кто понимает суть языка, а у кого в голове застряли С-подобные языки твердо и на долго :)
Вот кстати в копилку еще один кейс, на котором я чуть не завалился на собеседовании, но быстро сообразил что к чему :)
Код
function a() {
return {
a: "string"
}
}
И код
function a() {
return
{
a: "string"
}
}
Результат тоже будет разным. Для непонимающих еще один повод блеснуть своей способностью находить изъяны в хорошо продуманном ЯП, для понимающих ничего странного :)
Просто действительно надо понять что JavaScript это не C, не C++, не Java даже и совсем не Pascal. Здесь своя атмосфера и понимая ее можно много чего наворотить хорошего :)
bsivko написал:
Другие проблемы нужно обсуждать в другой ветке. Проблема отсутствия проверки типов для языков с динамической типизацией - это Проблема.
Это не Проблема, это особенность, которую нужно иметь в виду при разработке. Также как необходимость следить за выделением памяти в C/C++. Разве это Проблема в C/C++? Для криворукого и невнимательного "программиста" да, но в целом это особенность языка, которую можно использовать во благо, а можно выстрелить себе в ногу.
Выделение памяти обычно не проблема. А вот утечки памяти - это уже Проблема.
Особенность языка говоришь? Как думаешь, что общего между
MISRA-C:2004 - Rule 20.4
JPL Coding Standard - Rule 5
и IEC 61508-3, он же ГОСТ 61508-3 (табл. C.11. п.2)
и почему?
Проблемы с динамикой вообще-то поставили на колени далеко не один проект C/C++.
А c++11, кстати и в частности, значительно в этом плане безопаснее.
KEFIR написал:
Какие действительно серьезные проблемы могут возникнуть от отсутствия типизации? Я правда не могу себе представить. За мою практику в JS были проблемы связанные с облостью видимости замыкания, с операторами сравнения и со многим другим, за что далекие от JS люди его ругают, но никак не с типизацией.
KEFIR написал:
Результат тоже будет разным. Для непонимающих еще один повод блеснуть своей способностью находить изъяны в хорошо продуманном ЯП, для понимающих ничего странного :)
Кто-то, а JS никаким образом не является хорошо продуманным языком. По крайней мере изначально и в ядре. Его собирали по-быстрому на гребне волны Java. И я хорошо помню то время, когда объявленные переменные жили всегда и везде, к элементам не было getelementbyid, а вся отладка делалась через alert. И восхищение этим набором костылей очень похоже на восхищениями атавизмов человека со стороны не особо образованных.
Теперь конечно пытаются JS подпиливать всеми способами. Но от наследия давно спроектированного ядра так просто не уползти. Вот плюсы от старого наследия C уже 30 лет потиху избавляется.
KEFIR написал:
Просто действительно надо понять что JavaScript это не C, не C++, не Java даже и совсем не Pascal. Здесь своя атмосфера и понимая ее можно много чего наворотить хорошего :)
Эти аргументы пожалуйста кому-нибудь другому. На JS я писал ещё на рубеже века, а сам JS могу сравнивать с perl/ruby в силу имеющегося опыта.
Все это достаточно слабые аргументы как по мне. Так любую фичу любого языка можно рассматривать с двух сторон. С одной стороны это позволяет сделать A, с другой стороны это чревато X. Это нормально для языка с широкими возможностями.
Мне не приходилось иметь проблем связанных именно с этим. Наверное я что-то делают не так.
Вот здесь вообще глупость написана:
Низкая скорость, связанная с динамической проверкой типа, и большие расходы памяти на переменные, которые могут хранить «что угодно». К тому же большинство языков с динамической типизацией интерпретируемые, а не компилируемые.
Все давно оптимизировано-переоптимизирванно, не говоря уже про JIT.
хорошо помню то время, когда объявленные переменные жили всегда и везде, к элементам не было getelementbyid, а вся отладка делалась через alert.
Переменные, объявленные без какой-либо области видимости считаются объявленными в глобальном объекте (т.е. Window для браузера) и до сих пор оказываются видимы всегда и везде. Это никуда не делость. Поэтому хорошим стилем считается написание кода с минимумом глобальных переменных (как собственно и в любом другом ЯП, но здесь это может привести к конфликтам между модулями).
getElementByID вообще никакого отношения к языку не имеет. Это DOM API которого например вообще нет в node.js и сейчас.
Также и отладка не имеет никакого отношения к языку. Сейчас иструментов для отладки, тестирования, статического анализа и прочего более чем достаточно. Когда-то и для C был только gdb и никакого визуального step-into-step-over.
Как я понимаю единственная проблема JS это динамическая типизация (на самом деле неявное приведение типов) и все? Мне кажется бывают сложности и посерьезнее.
Кстати, я нигде не восхищался JS более чем чем-то еще. Я вообще самый толерантный программист, одинаково люблю все языки на которых программировал (ну ладно, не одинаково) и вижу в каждом свою мощь, красоту и область применения.
KEFIR написал:
Вот здесь вообще глупость написана:
Низкая скорость, связанная с динамической проверкой типа, и большие расходы памяти на переменные, которые могут хранить «что угодно». К тому же большинство языков с динамической типизацией интерпретируемые, а не компилируемые.
Все давно оптимизировано-переоптимизирванно, не говоря уже про JIT.
dynamic_cast он байткод, но тормозит больше, и менее безопасен, чем static_cast
и от этого JIT не спасет.
KEFIR написал:
хорошо помню то время, когда объявленные переменные жили всегда и везде, к элементам не было getelementbyid, а вся отладка делалась через alert.
Переменные, объявленные без какой-либо области видимости считаются объявленными в глобальном объекте (т.е. Window для браузера) и до сих пор оказываются видимы всегда и везде. Это никуда не делость. Поэтому хорошим стилем считается написание кода с минимумом глобальных переменных (как собственно и в любом другом ЯП, но здесь это может привести к конфликтам между модулями).
В "некоторых" других ЯП хорошим стилем является отсутствие глобальных переменных.
И при таких свойствах, каким образом тогда JS претендует на звание языка хорошей модульности?
KEFIR написал:
getElementByID вообще никакого отношения к языку не имеет. Это DOM API которого например вообще нет в node.js и сейчас.
Также и отладка не имеет никакого отношения к языку. Сейчас иструментов для отладки, тестирования, статического анализа и прочего более чем достаточно. Когда-то и для C был только gdb и никакого визуального step-into-step-over.
Сейчас это другая история. Но чтобы понимать почему JS такой, желабельно иметь представление, из чего он вышел.
KEFIR написал:
Как я понимаю единственная проблема JS это динамическая типизация (на самом деле неявное приведение типов) и все? Мне кажется бывают сложности и посерьезнее.
Проблемы JS начинаются когда зубной щеткой пытаются забивать гвозди. JS живет в своей нише и здравствует, а до звания глобального ответа на самый вопрос ему ещё далековато будет.
KEFIR написал:
Кстати, я нигде не восхищался JS более чем чем-то еще. Я вообще самый толерантный программист, одинаково люблю все языки на которых программировал (ну ладно, не одинаково) и вижу в каждом свою мощь, красоту и область применения.
Да?
KEFIR написал:
На самом деле это будущее уже здесь
bsivko написал:
В "некоторых" других ЯП хорошим стилем является отсутствие глобальных переменных.
И при таких свойствах, каким образом тогда JS претендует на звание языка хорошей модульности?
JS не претендует на язык с хорошей модульностью. Совершенно справедливо говорить что в браузерной реализации ее вообще нет. Но язык дает возможность реализовать модульность своими силами и ее хорошесть зависет только от реализации. require.js добавляет в браузерный JS вполне себе сносную модульность. В node.js аналогичная реализация есть из коробки.
Сейчас это другая история. Но чтобы понимать почему JS такой, желабельно иметь представление, из чего он вышел.
Да я прекрасно представляю из чего он вышел, занимаюсь вебом уже скоро 10 лет как :) Однако развитие DOM и веб-стандартов не имеет особого отношения к языку, принципы которого особо не изменились за это время. Ну и V8 дал сильнейший толчок популяризации языка и открыл массу его возможностей.
Проблемы JS начинаются когда зубной щеткой пытаются забивать гвозди. JS живет в своей нише и здравствует, а до звания глобального ответа на самый вопрос ему ещё далековато будет.
Однако ниша эта уже сильно расширилась и вылезла за пределы браузера на серверы, десктопы и мобильные устройства. Довольно круто для зубной щетки.
Да?
Да. У меня не вызывает боли даже написание программ на Java.
bsivko написал:
В "некоторых" других ЯП хорошим стилем является отсутствие глобальных переменных.
И при таких свойствах, каким образом тогда JS претендует на звание языка хорошей модульности?
Но язык дает возможность реализовать модульность своими силами и ее хорошесть зависет только от реализации.
Все, понял. Язык не запрещает и не препятствует программисту самому организовать модульность. И то хорошо.
KEFIR написал:
Проблемы JS начинаются когда зубной щеткой пытаются забивать гвозди. JS живет в своей нише и здравствует, а до звания глобального ответа на самый вопрос ему ещё далековато будет.
Однако ниша эта уже сильно расширилась и вылезла за пределы браузера на серверы, десктопы и мобильные устройства. Довольно круто для зубной щетки.
KEFIR написал:
Да. У меня не вызывает боли даже написание программ на Java.
Прям аж чуть инфаркт не хватил. Я понимаю, что это самоирония (я периодически смотрю твои репозитории, кстати), но чутка припекло.
На JS писал буквально месяца 3-4. Впечатление было не из лучших, но по большей части из-за Ext-JS с которым приходилось работать ("хрупкое дерьмецо" - так этот FW называл один из менеджеров).
Так так. Когда я писал про Java я имел в виду именно Java а не JavaScript (надеюсь никто, кто имеет хоть какое-то отношение к программированию, уже не путается :)). Вот по поводу хреновости Java я почти со всем согласен, уж слишком многословный код получается и вообще. Но тем не менее я легко переключаюсь на Java и пишу на ней без ругани и слез. Потому что со всем этим вполне можно жить и делать хорошие продукты и сама платформа прекрасна :)
Да не, никто не путает.
Просто Java - няшка. :3
Особенно если подсластить при помощи Lombok и Guava. Да и появление лямбд и default имплементации в интерфейсах радует.
Хотя операторы хочется порой перегрузить. И использование stream'ов достаточно странное в 1.8.
Ну а без сахара и нововведений иногда довольно печально :) Особенно всякие конструкциий, где в качестве параметра нужно передавать свежесозданный анонимный класс...
Но к этому можно привыкнуть и даже прочувствовать красоту и мощь такого решения :) (но лямбды лучше).
KEFIR написал:
Какие действительно серьезные проблемы могут возникнуть от отсутствия типизации? Я правда не могу себе представить. За мою практику в JS были проблемы связанные с облостью видимости замыкания, с операторами сравнения и со многим другим, за что далекие от JS люди его ругают, но никак не с типизацией.
Но ведь, опять же, проблема не в типизации. Про быдлокодность вконтактовского фронтенда писали уже ни одну статью.
И со строгой типизацией поразительно глупые ошибки проскакивают в продакшен. Достаточно почитать отчеты PVS Studio на хабре.
Все еще не вижу ничего критичного в динамической типизации. Мне это вообще никак не мешает, чаще наоборот :). Да и миллионам других разработчиков тоже никак не машет делать потрясающие стабильные вещи.
Ну так способствует ли динамическая типизация быдлокодности вконтактовского фронтенда - вот в чем вопрос. И мешает ли она миллионам других разработчиков.
Я сегодня довольно долго бился, заставляя работать на питоне довольно простой участок кода, просто потому, что не понимал, как работает сторонний класс. Документации недостаточно, она не охватывает все примеры, бедная IDE умирает, пытаясь подсказать мне, что за объект вернула мне функция и какими свойствами и методами он обладает.
Но главное, что меня убило - внутренняя структура этого модуля, которая убивает уже меня. Не знаю, что там со стройностью и логичностью кода, но отследить внутренние связи решительно невозможно. Я понимаю, почему IDE мне не помогает.
Понятно, что есть те, кому не мешает. Ну или кажется что не мешает. Или, что в моем представлении главное - есть люди, которым очень мешает статическая типизация. Например, кажется очень избыточной синтаксически или мешает делает на их взгляд красивые универсальные функции. Но если второй аргумент еще хоть как то понятен, то экономия на словах и сокращения - то, чего Я перестал понимать.
В моем понимании проблема в глобальном смысле одна - программы на js или том же python может быть и легче писать, но радикально тяжелее читать. И структура языка никак этому не помогает и не может помочь - этим могут озаботится только конечные программисты.
Быдлокодности способствует что угодно, что не очень понятно или непривычно для программиста. В этом вся проблема, я уверен. Если человек всю жизнь сидел на C/C++ и тут ему нужно написать приложение на JavaScript, то он там наворотит такого...
Я все еще не понимаю почему для вас динамическая типизация это на столько фатальный недостаток (недостаток ли?). Может это от того, что я бОльшую часть своей практики пишу именно на таких языках (PHP, ActionScript например). По мне так читаемость программ на C/C++ никак не легче, скорее десятикратно наоборот, особенно если пишет криворукий идиот, который не понимает как сделать это читаемо и понятно, это еще в 100 раз ухудшает ситуацию. Тоже можно сказать и про Java, и про Delphi и про что угодно. Говнокод, в котором не разобраться, бывает на любом языке и типизация здесь не самый главный фактор. Все эти конструкции типа (утрированно)
И я не вижу динамическую типизацию как экономию на словах. Скорее это просто избавление от сущности, которая не так уж необходима, когда речь идет о платформонезависимом языке (очень) высокого уровня. Здесь нет никакой разницы сколько там байт в переменной, какой там bit align, как выделать, адресовать и освобождать память и т.д. Да и про то, что "компилятор ругнулся бы на ошибку!!!" тоже не подходит, ведь код компилируется непосредственно при выполнении и он и ругается в этот момент, если что-то не сошлось.
Еще пока я читал твой, Mefistofel, коммент, я понял что причина еще может быть в том, что даже методы отладки несколько отличаются в этих случаях :) Ты написал что пытлся из кода понять какой тебе объект возвращается, я бы просто выполнил бы этот код и посмотрел бы отладочную информацию, стек и т.д. :) Приложения на JS олично отлаживаются прямо на лету с современным средствами. По мне так гораздо быстрее и понятнее, чем читать код, во многих случаях.
Не обязательно даже что-то ломать. В JS ты можешь просто взять и посмотреть все что у тебя есть в выполняющемся в данный момент прилоежнии, попробовать дернуть какой-нибудь метод, посмотреть что он вернет и т.п.. Все это прямо на лету.
KEFIR написал:
Да и про то, что "компилятор ругнулся бы на ошибку!!!" тоже не подходит, ведь код компилируется непосредственно при выполнении и он и ругается в этот момент, если что-то не сошлось.
Одна из особенностей динамических языков, кстати. Для которой два случая. Первый - куски ниразунезапущенного кода могут лежать годами, и потом в самый подходящий момент вывалится с ошибкой. Второй - если программист хочет спать по ночам, то ему приходится покрывать тестами все участки кода, иначе пункт 1й. В статических же зачастую происходит так (если это средней серьезности или ниже), что полагаются на компилятор.
KEFIR написал:
я бы просто выполнил бы этот код и посмотрел бы отладочную информацию, стек и т.д. :) Приложения на JS олично отлаживаются прямо на лету с современным средствами.
Только сегодня у тебя вернулся объект A, а завтра вернется объект B.
Компилятор же обеспечивает гарантию на уровне языка того, что это будет объект нужного типа.