Вот еще бы полноценну IDE под JS.

То чувство, когда пишешь код в текстовом редакторе.

ну поставь

ну поставь

Так нету.

Вот еще бы полноценну IDE под JS.

Нет смысла

Нет смысла

Ну, как это нет. Посмотри на решарпер для C#.

Она разве что за тебя код не пишет.

Драматически увеличивает скорость кодирования и уменьшает число опечаток.

я думала, вебшторм ок

Я не против иде (но нормальных для жс не находил, хотел бы для хаскеля), но должен сказать, что если иде генерит кучу кода, то язык скорее всего очень бойлерплейтный (что вообще характерно для pure "ооп" языков)

Я не против иде (но нормальных для жс не находил, хотел бы для хаскеля), но должен сказать, что если иде генерит кучу кода, то язык скорее всего очень бойлерплейтный (что вообще характерно для pure "ооп" языков)

Это не язык бойлерплейтный, а реалии промышленной разработки такие.

Драматически увеличивает скорость кодирования и уменьшает число опечаток.

Уменьшает ошибки?

Уменьшает ошибки?

Поправил.

Т.е. делает частично то же, что и компилятор?

Т.е. делает частично то же, что и компилятор?

Наверное.

Но не средствами компилятора?

Скорей всего.

Ну, там логика другая. Печатаешь два символа, и IDE тебе сразу выдает правильное название метода. Ты его выбираешь из списка и готово.

А значит, нет гарантии, что качество проверки IDE будет эквивалентно качеству проверки со стороны компилятора?

А какую проверку делает компилятор?

А какую проверку делает компилятор?

Компилятор делает разбор.

Я думаю, это статический анализ?

И проверяет он ошибки в типах, прежде всего.

А знаешь почему IDE не использует средства нативного компилятора?

Я думаю, это статический анализ?

Ну, да, это все поверх статического анализа, конечно, работает.

А знаешь почему IDE не использует средства нативного компилятора?

В C#.

А знаешь почему IDE не использует средства нативного компилятора?

Наверное, потому что инструменты разные?

Потому что там нет нормального вывода типов, и на каждый чих надо самому кастовать. А IDE пытается кастовать за тебя. Т.е. авторы IDE в теории могли бы дописать чуток и сам язык.

Наверное, потому что инструменты разные?

Всё очень взаимосвзанно.

Так вот. К чему это я.

IDE для JS существует.

Всё очень взаимосвзанно.

Ну, я тут ХЗ. Компилятор компилирует, IDE подставляет всякие штуки и рефакторит.

Ну, я тут ХЗ. Компилятор компилирует, IDE подставляет всякие штуки и рефакторит.

IDE делает всё это на основе более продвинутого статического анализа, чем есть у компилятора.

IDE для JS существует.

flow.org

Ну и TS можешь попробовать. Но я не пробовал.

IDE делает всё это на основе более продвинутого статического анализа, чем есть у компилятора.

Ну, для этого язык должен позволять делать вывод типов. А в js-е информация о типах появляется только на этапе исполнения. Собственно, почему все IDE для js-а плохие.

flow.org

Ну, да. Шаг вперед, конечно. Раньше такого не было.

Там теория даже есть под это, на самом деле. Как делать вывод типов.

Но я ее забыл.

Ну, для этого язык должен позволять делать вывод типов. А в js-е информация о типах появляется только на этапе исполнения. Собственно, почему все IDE для js-а плохие.

Тем не менее, никто не мешает построить поверх языка диалект, который привносит сильную типизацию. Если код проходит проверку, ты коммитишь. Если не проходит, не коммитишь. В замен получаешь профит в виде крутейшего вывода типов, который тебе в C# не снился даже, и который юзают большинство редакторов, превращаясь сразу в IDE.

Тем не менее, никто не мешает построить поверх языка диалект, который привносит сильную типизацию. Если код проходит проверку, ты коммитишь. Если не проходит, не коммитишь. В замен получаешь профит в виде крутейшего вывода типов, который тебе в C# не снился даже, и который юзают большинство редакторов, превращаясь сразу в IDE.

статическую*

Тем не менее, никто не мешает построить поверх языка диалект, который привносит сильную типизацию. Если код проходит проверку, ты коммитишь. Если не проходит, не коммитишь. В замен получаешь профит в виде крутейшего вывода типов, который тебе в C# не снился даже, и который юзают большинство редакторов, превращаясь сразу в IDE.

Это работает, только если весь код 100% свой и написан на flow. А обычно приходится работать с легаси кодом, да с кодом, который написан без деклараций типов. Сейчас, конечно, с этим полегче стало. Но тем не менее.

статическую*

Во. Клевый ник, как раз в тему бестипового лямбда-исчисления.

хех

статическую*

Ну, если мутирование значения в рамках какого-нибудь юниона попадает в рамки понятия статической типизации, то ок.

по сабжу: без HKT и нормальных тайпклассов все равно по-человечески программировать нельзя

ну и без ADT (не через костыли как в flow)

по сабжу: без HKT и нормальных тайпклассов все равно по-человечески программировать нельзя

Я все понимаю, но вот этого не понимаю.

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

Началось.

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

Это домыслы.

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

Ща кину пример кода, потом поговорим про "помогает или не помогает уложиться в дедлайн"

Я проверил.

смотри, вот реализация Maybe через костыльный ADT на Flow: https://github.com/zerobias/apropos/blob/master/src/adt/maybe.js

Это домыслы.

Ну, понятно, что на любое общее утверждение найдется свой частный случай.

Но блииин.

мне лень выдёргивать оттуда сам ADT, без логики, но суть в чём

вот соответствующий код на Haskell: data Maybe a = Just a | Nothing

чувствуешь разницу?

Видел я в проекте чел писал на Maybe в проекте.

или Rust: enum Maybe<T> { Some(T), None, }

Угадай, зачем Maybe в JS-е?

Ну, понятно, что на любое общее утверждение найдется свой частный случай.

Ничего не понятно. =) Ты провозглашаешь догму, которой является твой стереотип, не проверенный на пректике.

Угадай, зачем Maybe в JS-е?

чтобы не ловить тайп эрроры из-за нуллов в рантайме

При этом я его состоятельность проверил в реальном проекте и готов тебе возразить.

ERROR: S client not available

Не пренебрегай научным подходом. Иначе кто-нибудь сделает это за тебя.

чтобы не ловить тайп эрроры из-за нуллов в рантайме

Нет. Ни за чем он там не нужен. Можно абсолютно спокойно и безболезненно обойтись без него.

Нет. Ни за чем он там не нужен. Можно абсолютно спокойно и безболезненно обойтись без него.

нет, спасибо

куда отсутствующие значения заворачивать? в null? это в 2017-то?

Нет. Ни за чем он там не нужен. Можно абсолютно спокойно и безболезненно обойтись без него.

Можно обойтись без всего.

Но зачем?

нет, спасибо

Вопрос привычки просто -) Я пишу на JS-е и мне Maybe не нужен, хотя я даже сам когда-то делал его реализацию и думал, что это клево.

куда отсутствующие значения заворачивать? в null? это в 2017-то?

От отсутствующих значений нужно избавляться как можно раньше.

привычка тут не при чём

глупо делать самому то, что за тебя может сделать компилятор

например, проверять типы

Maybe/Option - это способ гарантировать на уровне типов отсутствие всяких NPE

В js-е никто типы не проверяет, все обращаются по указателю так, как будто там лежит правильное значение.

В js-е никто типы не проверяет, все обращаются по указателю так, как будто там лежит правильное значение.

и что в этом хорошего?

не, понятно что ручные тайп ассерты это хуйня

ну так для того и придумали Flow

и что в этом хорошего?

В общем-то ничего. Но ты просто говоришь, что вручную типы проверять — зашквар. Я и аргументирую, что никто этим не занимается.

ну так или иначе - занимаются

В общем-то ничего. Но ты просто говоришь, что вручную типы проверять — зашквар. Я и аргументирую, что никто этим не занимается.

F L O W

Ну, проверка на undefined я лично за проверку типов не считаю.

ну так или иначе - занимаются

когда у тебя где-то выскакивает TypeError и ты лезешь искать где накосячил - это тоже ручная проверка типов)

F L O W

Ответил ведь уже, что тема хорошая, но пока что сыровато.

при чём выскакивать TypeError может только при специфических условиях, раз в 1000 запусков, когда программист чешет левую пятку под полной луной

он ведь в рантайме выскакивает

Ответил ведь уже, что тема хорошая, но пока что сыровато.

Так ты даже не разобрался, и топишь за то, что решения нет.

Ответил ведь уже, что тема хорошая, но пока что сыровато.

ну да, пока HKT нет, всё плохо

при чём выскакивать TypeError может только при специфических условиях, раз в 1000 запусков, когда программист чешет левую пятку под полной луной

Ну да, это боль, конечно.

вот соответствующий код на Haskell: data Maybe a = Just a | Nothing

Ты не прав, ты приводишь «пустую» реализацию datatype, которая в жс выглядит как аналогичное объявление классов. Дальше идут имплементации тайпклассов

Так ты даже не разобрался, и топишь за то, что решения нет.

В плане, не разобрался?

То есть это отнюдь не все объявление maybe

Ты не прав, ты приводишь «пустую» реализацию datatype, которая в жс выглядит как аналогичное объявление классов. Дальше идут имплементации тайпклассов

ну да, мне лень было вырезать само определение или добавлять реализации к примеру на Haskell но суть в том что в любом случае типобезопасное определение ADT на Flow выглядит как костыль по сравнению с ADT в нормальных языках это ни разу не камень в твой огород, если чё)

Просто видел я по коду, как один программист писал в проекте на Maybe. Использовал он его для получения значения из форм, а что, логично, в форме нифига — это Nothing. Регрессировал обратно на сравнение с пустотой где-то к третьему модулю в системе -)