Комментарии 260
Я не против свободы, но как показывает практика, разработчику лучше ехать по «рельсам». Набрать команду хотя бы из 5 адекватных разработчиков, которые будут делать «все правильно» очень не просто.
Ну и «миллионы мух не могут ошибаться — что-то в этом есть»…
VS Code с легкостью решает все проблемы дебага ноды
$ node --inspect --debug-brk server.js
update: опоздал с комментарием
Команду из "правильно пишущих" набрать сложно и в других ЯП. В каждом есть крайности. В принципе, большинство проблем решается грамотными гайдлайнами для разработчиков.
Минус языка в том, что его невозможно на все 100% контролировать.
несколько офтоплю, но… а что можно контролировать на все 100%?
и это стоило очень больших больших усилий sun, а теперь стоит очень больших усилий ораклу.
и 100% обратная совместимость, и максимально возможная спека языка с требованиями к джава-машине с эталонным поведением.
Одна из проблем JS, на мой взгляд — то что чьи-то фантазии и эксперименты, или узкоспециализированные штуки и точечные решения — на волне хайпа быстро поднимаются чут ли не до уровня стандартов и «ты обязан в этом разбиратся».
Кому-то мозолит отсутствие «его любимой фичи из другого языка потому что он привык кодить в таком стиле», и он обганяя стандарты ES запиливает трансплиттер. Кто-то терпеть не может скобочки или точки с запятыми. Есть любители «написать свой велосипед и назвать его фреймворком нового поколения».
По сути в последнее время развитие JS напоминает базар — кто громче кричит (за свой фреймворк) у того и покупают (берут как маст ноу).
Так это я о чем: JS сам по себе довольно шустрый и мошьный, но именно потому что его заставляют работать «как другой язык», загоняя в трансплиттеры и обвешивая фреймворками он так и тормозит.
Потому — не хотите терять клиентов — не насилуйте язык.
Только мой камень в огород фреймворков, сборщиков и транспилеров имеет немного иную форму:
Напишите свой продукт один раз на JS и больше не понадобится переписывать его на очередной хайповый фреймворк по прихоти 23-летнего сеньера, который увлекся функциональщиной и теперь лоббирует очередной HaskellScript в продакшн.
Найти человека, который знает javascript намного проще, чем выискивать уникальную смесь из скиллов, типа Vue, Redux, Gulp, LESS и т.д. Сообщество слишком раздроблено и объединять его надо под флагом чистого JS.
Я не ратую за революцию… я за реставрацию)
Напишите свой продукт один раз на JS и больше не понадобится переписывать его на очередной хайповый фреймворк
Я бы сформулировал иначе: не бойтесь переделывать выбранный фреймворк под себя, и через год-другой у вас будет свой фреймворк, заточенный под ваш проект.
У нас от выбранного некогда JavaScriptMVC не осталось камня на камне, все его элементы постепенно заместились своими.
Там по сути не так уж много кода внутри: обсервер/медиатор и модули. Практически все фреймворки работают по этой схеме (правда некоторые предпочитают хранить стейт во внешней модели, а другие — внутри модуля в его замыкании, но это нюансы). Для CRUD-приложений еще может понадобиться некое подобие виртуального dom.
Напишите свой продукт один раз на JS и больше не понадобится переписывать его на очередной хайповый фреймворк по прихоти 23-летнего сеньера, который увлекся функциональщиной и теперь лоббирует очередной HaskellScript в продакшн.
напишите, ага) только есть пара-тройка особенностой иусловий для вашего проекта, что бы он стал успешным на какое то время на js:
1. он не должен иметь долгий жизненный цикл. потому что есть over 100500 причин, что он перестанет работать с заменой ядра движка в следующем поколении браузеров. никто не обещает обратной совместимости.
2. он должен быть маленьким. вы не сможете написать свой продукт, потому что верхний порог логики и сложности, который вы сможете контролировать в условиях динамической типизации не даст вам развернуться. я не говорю о таких «сложных» системах как курсовая, проект jQuery, или пошаговая ммо-игрушечка. я говорю о действительно вещах типа СЭД, учетные системы с историяеской отчетностью, хранилище данных, олап, и тд и т.п.
3. вам не стоит к нему возвращаться что бы рефакторить и добавлять в него фичи. потому что если вы создадите большого монстра, со ложной бизнес-логикой, то как только вы начнете рефакторить и модифицировать свой продукт (под влиянием времени, и изменния требований окружения) — вы поймете что «не успеваете». ни оттестировать, ни предсказать влияние ваших изменний. потому что прогнозировать влияние изменний в языке с динамической типизацией сложно. и typescript не панацея. потому что… где стандартна тайпскрипт и гарантия обратной совместимости? (см проблему 1).
а так, да, js, вполне прикольный, для маленьких здесь и сейчас задач. как прослойка скриптовапия компонентами, для задач, где где бизнес-логика примитивна, задачи прозрачные, а ответственность минмальна — самое то.
(не в конце концов, никто же не умрет, аэс не взорвется, поезда с рельс не сойдут, если ваш мега сайтик с оvер 8миллионов конекшенов просто подохнет, после обновлепия или какого иного чиха.
просто не надо думать что js может заменить, или тем более вытеснить джаву, c++ или ассемблер.
это глупо.
а так… хайп кончится, будет новая мода. visualbasic, delphi, php, python, ruby, javascript… что из этого продержалось на волне популярности долго?..
никто не обещает обратной совместимости.
Если бы не было обратной совместимости, мы бы давно имели нормальный современный язык.
2.
Нет возражений. Язык явно не для этого.
3.
typescript
см пункт 1
просто не надо думать что js может заменить, или тем более вытеснить джаву, c++ или ассемблер.
это глупо.
Странно, что вы так думаете. никто не собирается никуда вытеснять ваши (наши) любимые плюсы.
будет новая мода
Казалось бы, "питон не брошу, потому что он хороший"? Да и пхп пока никто не списывает?
трансплиттер
транспилер наверное? (от англ. transpiler)
Второй минус, это производительность на стадии инициализации. Уже часто встречаются кривые сайты тормозящие при старте.
Я всегда думал что это разработчики должны контролировать – что 95% их кода при старте не нужно инициализировать.
Разве class не просто языковая конструкция, которая сводиться к тому же прототипному наследованию?
Синтаксический сахар по сути.
А чем классы от прототипа отличаются?
Конструкция class декларирует семантику его экземпляров, а прототип является экземпляром и ничего более не декларирует. На практике это означает следующее:
1. class позволяет организовать проверку типов, а прототипам доступна только утиная типизация
2. class может наследовать семантику нескольких классов, прототипам множественное наследование не доступно (только миксины)
3. class может наследовать только классы, прототипом же может выступать любой объект
4. прототипам не доступны интерфейсы, то есть невозможно объявить семантики или абстрактные классы
продолжать можно долго.
class может наследовать только классы, прототипом же может выступать любой объект
Это недостаток.
прототипам не доступны интерфейсы, то есть невозможно объявить семантики или абстрактные классы
Мы пробовали. Не взлетело.
class может наследовать только классы, прототипом же может выступать любой объект
Вот тут я поправлю, класс может наследовать не только классы, но и функции.
Дело в том, что class это конструкция, которая по факту выполняет роль синтаксического сахара. Внутри это функция с прототипом равным содержимому класса. Вот например:
class User {
constructor(name, age) {
this.name = name;
this.age = age;
}
sayHello() {
console.log(`Hello, my name is ${this.name}!`);
}
}
Если переписать без конструкции class вы получите этого:
function User(name, age) {
this.name = name;
this.age = age;
}
User.prototype = {
constructor: User,
sayHello() {
console.log(`Hello, my name is ${this.name}!`);
}
};
Если проверить тип класса из первого примера вы увидите, что результатом будет function.
По этому фактически классы (функции) наследуют функции.
Вводит в заблуждение приставка Script
А мне кажется, что в заблуждение вводит как раз таки Java
в названии. Т.к. JavaScript к Java не имеет никакого отношения.
Если в те самые времена был VBScript как упрощенный Visual Basic, то JavaScript по логике, это упрощённая Java.
то JavaScript по логике, это упрощённая Java.
Да никакая это не упрощенная Java. Хотя бы потому, что в JavaScript прототипное наследование, а это существенная разница.
А еще все почему-то забывают про язык ActionScript, который является одной из реализаций стандарта EcmaScript. С виду весьма неплохой язык (я на нём не программил) со статической типизацией (привет TypeScript), пакетами (привет ES6) и т.д. Если бы в своё время звёзды сошлись иначе, мы бы сейчас холиварили по поводу него, а не JavaScript, но нет)
А люди, когда читают Java* подразумевают Java в основании, несмотря на то, что ничегошеньки общего (кроме сишных фигурных скобочек) с жабой язык не имеет.
Просто представьте, что стало бы с TypeScript или Rust после 10 лет отсутствия обновлений.
C++ жил, жив и будет жить. Хотя стандарт очень долгое время оставался стабильным.
Отсутствие изменений — это стагнация.
В математике, если теорема один раз доказана, создатели не выпускают каждый год новую версию доказательства, а спокойно переходят к другом задачам
Не-а. Почитайте, например, истории теории множеств. Там было несколько разных версий :) И так много где в математике. Просто оно менее заметно, чем в программировании, потому что там выпуск версии дольше тянется.
Молодой человек, в математике помимо теорем какбы вот… есть еще алгоритмы, которые время от времени ревизируются и меняются, разрабатываются новые версии, гибридизируются. Улучшать инструмент со временем — это нормально. Менять факты со временем — нет. Язык программирования — это не теория, подлежащая проверке или опровержению. Это инструмент решения задачи. Для него нормально периодически меняться. Вы же гвозди камнем не забиваете, верно? Камень, слава богу, успел за много лет развиться до молотка.
В математике, если теорема один раз доказана, создатели не выпускают каждый год новую версию доказательства, а спокойно переходят к другом задачам.
Не думаю, что сравнение корректно. Стандарт языка не подразумевает единственного правильного пути для решаемых задач, он разрабатывается так, чтобы быть удобным при решении этих задач. Где-то максимально эффективно, где-то максимально быстро (в плане времени разработки), где-то максимально элегантно. К тому же время меняется, сегодня все любят быстро, модно и сахарно. Вот и C++ и решил к растянутому свитеру добавить что-нибудь из модненького.
Я бы провёл аналогию не с математикой, а с естественными языками. Посмотрите на латынь и европейские языки, из неё вышедшие. Латынь красива, помпезна, но достаточно сложна, чтобы быстро и кратко донести мысль. Другие же европейские языки пошли по пути упрощения в силу различных обстоятельств. И они продолжают меняться, это неизбежно. Поэтому я уверен, к этому
Поверьте, через 100-200 лет никто не будет переписывать языки каждый год, а сформируют единый стандарт, который достаточно хорош и самодостаточен.
вряд ли всё идет. Языки программирования, подобно языкам естественным, развиваются практически безостановочно. Потому что возникают новые идеи, относительно того, как сделать разработку быстрее и проще, возникают новые предметные области и задачи, которых раньше не было.
В математике, если теорема один раз доказана, создатели не выпускают каждый год новую версию доказательства, а спокойно переходят к другом задачам.
Да, именно поэтому факт, что 0.(9) = 1 доказан только одним-единственным способо… А нет, не одним.
лучше языка чем JavaScript для общих задач вам не найти
Слова евангелиста, похоже. Вы видели тот же жирный Electron? Это всего лишь обёртка над Chromium, которая отжирает памяти мама не горюй.
Ну, а что до браузеров — так сложилось. Вместо JavaScript мог быть любой другой из семейства EcmaScript. При всём при этом я считаю JS нормальным языком. Сейчас на волне хайпа он еще обрастает новыми возможностями, так что писать становится приятнее)
Вопрос 11: const ( который на самом деле НЕ const )
Насколько я понял, там было про объекты. Мол, const
не делает объекты неизменяемыми. Но мне всегда казалось это и так понятным.
Собственно, я об этом и написал.
По крайней мере я именно так понимаю выражение «константный объект».
Вроде так нигде не работает и это все мой воспаленный мозг, но все же хочется))
Это ж философия js — дать возможность делать практически всё, что хочешь.
Да и const же только в ES6 заехал. Раньше и того не было.
Так, на самом деле, делать нельзя:
let foo = { something: 42 }
const bar = foo
Object.freeze(bar)
foo.something = 58 // doesn't change anything
Нет. const
означает константную ссылку на объект. Не более того.
А я так понял, что речь про ускорение с помощью const. Ну типа, в компилируемых языках const имеет только одно отличие от других переменных — компилятор на момент компиляции проверяет, не хочет ли кто его переопределить. Т е. по скорости никаких отличий.
(или даже — где-то встречал, что const — это аналог #define, который считается в момент компиляции и подставляется препроцессором)
В js же const ставит специальный флаг у переменной, и интерпретатор наоборот должен тратить доп. ресурсы и следить, чтобы эту переменную никто не изменил.
В js же const ставит специальный флаг у переменной, и интерпретатор наоборот должен тратить доп. ресурсы и следить, чтобы эту переменную никто не изменил.
Не должен. Интерпретаторы js давно уже перестали выполнять инструкции "строчку за строчкой" — код сначала парсится в AST, потом преобразуется в удобную для интерпретации форму — и на этом этапе все "спецфлажки" заканчиваются: код проверен и пригоден для исполнения. Единственное исключение — если внутри есть вызов eval
. Это одна из причин почему eval
— зло.
Вопрос 11: const ( который на самом деле НЕ const )
Не особо вы ответили на этот вопрос, ошибка у вас выпала о невозможности заново объявить переменную (если бы убрали const упала бы нужная ошибка).
А имелось ввиду, что const не работает с объектами.
Код ниже вполне ок работает без ошибок (в браузере по крайней мере):
const a = { b: 1 }
a.b = 2
А вообще основная претензия к JS, то что он все разрешает, а основной аргумент автора данной статьи в том, что «сам дурак, не фиг в ногу стрелять».
По такому принципу любой язык хорош, если в нем разобраться.
Язык который ставит ограничения ЗАСТАВЛЯЕТ программиста писать как надо (либо бежать в ужасе), и тем самым повышает профессианализм самого программиста т.к. приходится решать задачи с ограниченным набором инструментов, которые позволяют сделать правильно (не факт, но все же).
А т.к. JS позволяет делать все, программисту чтобы написать нормальный код нужно читать мануалы и книги, это не круто.
А имелось ввиду, что const не работает с объектами
Ссылка на объект не изменилась, const работает как и должен.
программисту чтобы написать нормальный код нужно читать мануалы и книги, это не круто
Читать мануалы и книги — это единственный способ программисту писать хороший код. Не круто — это когда кто-то считает себя разработчиком, ничего при этом не читая.
А имелось ввиду, что const не работает с объектами
В другой ветке это обсуждают, там интереснее)))
Читать мануалы и книги — это единственный способ программисту писать хороший код. Не круто — это когда кто-то считает себя разработчиком, ничего при этом не читая.
Вообще не согласен.
Можно прочитать все книги и мануалы по конкретной теме, но нифига в ней не разобраться.
А можно делать правильные вещи, не зная что ты используешь какой-нибудь паттерн.
Если человек не читал книги, но сам допер как нужно делать правильно, неужели он не является хорошим программистом?
Немного странная логика
Особенно веселят теоретики-отличники — это прям победа.
Прочитали кучу книжек, типа умные, а вот руки к сожалению (или к счастью) не из того места растут.
Почему у всех книги это панацея?!
Книга написано конкретным автором (иногда несколькими), у которых свой взгляд на вещи, и своя точка зрения.
По вашей логике, чтобы было прям совсем круто, нужно прочитать книги нескольких авторов, с разной точной зрения, чтобы быть красавчиком, однако пока вы будете погрязать в чтении книг, некоторые/многие моменты уже устареют.
Я не против изучения новой/другой информации, а против чтения книг ради этого.
В чем проблема: в книге написано много всего, с кучей воды и, опять-таки, с одной точки зрения.
Рассмотрим конкретный пример/случай из жизни: нужно изучить паттерны, чтобы разрабатывать «правильно».
Я не бегу скачивать книгу Фаулера, я иду в гугл и вбиваю: «паттерны», «паттерны веб-разработка», «паттерны JS» и т.д.
То есть я не трачу время на изучение всего подряд, что мне может-быть когда-нибудь пригодиться, я ищу конкретные вещи.
Да я понимаю, что статьи и советы других людей это в большей степени аккумулирование книг, НО если после прочтения книги, мной будет усвоена часть информации (а так чаще всего и бывает, а пригодиться еще меньше (скажем 25% из книги мной было усвоено и пригодилось в жизни), то какой смысл мне читать ВСЮ книгу?
GeekBrains или Hexlet?
Окончание таких курсов тоже показатель крутости программиста и без наличия их сертификатов человек не может стать хорошим разработчиком?
Че-то пришла гениальная мысль:
Недостаточно читать книжки, чтобы быть хорошим программистом.
Чтобы стать хорошим программистом, необходимо читать книжки/статьи/слушать советы опытных ребят.
Не круто — это когда кто-то считает себя разработчиком, ничего при этом не читая.
Чукча не читатель, чукча писатель, ага)
Решение задач единственным способом к развитию вообще не имеет отношения. Наоборот — это ограничение выбора.
По последнему предложению вообще забавно. Мануалы как раз нужны, когда на каждый чих надо искать то самое единственное «правильное» решение.
Это очень субективное мнение, как и критерий «правильности». Я вот, например, терпеть не могу когда язык нянчится и не дает мне сделать то, что я хочу. Если я знаю что делаю, то я не хочу бороться с компилятором.
Язык — это лишь инструмент. Не нравится, используйте другой. Но опять-таки, не нужно думать, что ограничения придуманы просто так.
Решение задач единственным способом к развитию вообще не имеет отношения. Наоборот — это ограничение выбора.
Почему люди так критично относятся к ограничениям?
Ограничения нужны не для того, чтобы как то ущемить программиста, а для того чтобы он не сделал себе больно.
А написать пару лишних классов, которые в будущем облегчать вам возможность изменений (а точнее расширение функционала), для вас наверное моветон?
По последнему предложению вообще забавно. Мануалы как раз нужны, когда на каждый чих надо искать то самое единственное «правильное» решение.
Про мануалы я погорячился, они как раз таки самый нормальный источник информации. А про книги тут.
Пожалуйста не кричите на меня. То, что не делается правильно, может делаться левельно (за счёт мастерства и глубокого понимания происходящего)(в основе юмора английское слово Level которое ты и так знаешь %username%). И это здорово — можно не вставлять квадратное в треугольное в угоду правильности и закостеневшим в мозгу паттернам.
Я не пытаюсь сказать, что паттерны это плохо, а лишь намекаю на волновую структуру жизненного цикла [людей и программ]. Сейчас ты упарываешься по паттерну и делаешь всё правильно (хотя и не понимаешь почему именно так правильно). Завтра упираешься в его углы и начинаешь мыслить за пределами его границ и получаешь свободу, в том числе выстрела в ногу. Послезавтра, когда надоест танцевать на граблях, снова примешь чью-то новомодную методу. Далее по синусоиде, но уже с пониманием того почему ты использовал этот паттерн и почему именно таким образом. А дальше ночь, улица, фонарь, аптека…
Автор соседнего поста ругает ES8 за низкий порог входа, но ПМЛМ это зря. Язык разрабатываемый десятком светил до которых не достать, может быть сколь угодно крутым, но что толку если программирует на нём всего сотня-другая людей?
PHP в своё время взлетел и стал очень популярен из-за своей доступности. Достаточно было скачать бинарники, написать в командной строке php file.php
в котором написано <?=6*7?>
и получить ответ 42. Ну или можно поставить себе локальный денвер и байбай консоль, теперь можно результаты вписывать в разметку\оформление. Красиво. А до него был Perl.
Сейчас вообще ничего скачивать не нужно и файлов создавать тоже. Жмёшь заветные ctrl + shift + i, пишешь 2**10
и получаешь 1024 в ответ! Даже знать о том, что пишешь на JSES не нужно. А стоит узнать о том, как пользоваться переменными и всё — ты программист. И тут я понимаю всё негодование тех кто отучился не один год, чтобы написать свой первый хеловорд. Такая щемящая несправедливость просто, обязана не давать им покоя.
Интерпретируемые языки имеют отличную от компилируемых парадигму разработки. Если для компилятора ты готовишь свою программу, пишешь, потом ещё пишешь, потом исправляешь и только потом компилируешь и наслаждаешься результатом. То в интерпретируемых скриптах мелкоитеративный цикл разработки, в котором ты смотришь на результат во время программирования (привет LiveReload), сверяя его с тем чего ожидаешь.
Сделав изменение в одну букву, можешь сразу посмотреть результат и убедиться, что всё идёт так как задумано. В таких условиях недостатки отсутствия строгой типизации вываливаются сразу, а не накапливаются и выдаются в качестве непредсказуемых результатов после компиляции. Если складываешь цифру со строкой, то заметишь, что в результате у тебя не цифра. И это здорово. Пишешь интуитивно и лаконично. Сразу получаешь результат.
А если с типом накосячил в компилируемом языке, притом в не очевидном месте, то можно провести не один час в поисках ошибки которую допустил час назад и строгая типизация тут и вправду помочь может. Но что, тебе поможет если ты перепутал две очень похожие функции, тем более если они отличаются в названии всего одним символом‽ Статическая типизация, компиляция, строгие правила — не панацея. Если ты достаточно везуч и любознателен, ты найдёшь способ выстрелить себе в ногу, даже если разработчики языка всеми силами стараются этому помешать.
Но если ты хочешь программировать здесь и сейчас то, JS твой почти безальтернативный выбор. И помни, что наговнокодить можно на любом языке и только годы практики и танцев на граблях отделяют тебя от чистого кода (совершенного кода кстати не бывает, это вектор, а не точка). И на чём бы ты ни писал, год за годом ты будешь смотреть на свой код, написанный год назад и мысль — «Что за говнокод?», тебя не покинет.
ЗЫ всё это моё личное мнение, я не учился в институте и руководствуюсь только своим опытом разработки на PHP/JS. Ну а то, что я так и не написал своё первое приложение на C++ это потому, что [irony]С++ плохой и сразу не работает[/irony]
Похоже слишком простыня вышла, извините за то, что вам пришлось читать этот поток сознания.
Если коротко:
Низкий порог входа это здорово. Так больше людей сможет научиться основам программирования. Это сделает мир лучше.
Сейчас ты упарываешься по паттерну и делаешь всё правильно (хотя и не понимаешь почему именно так правильно). Завтра упираешься в его углы и начинаешь мыслить за пределами его границ и получаешь свободу, в том числе выстрела в ногу
Если вы выходите за границы паттерна, то это уже ошибка.
Паттерны не делают вас тупее, они говорят как надо делать правильно (никто не машает вам разобраться почему именно так правильно).
А если вы выходите за рамки паттерна, значит уже делаете что-то не так.
Низкий порог входа это здорово. Так больше людей сможет научиться основам программирования. Это сделает мир лучше.
А каким образом это сделает мир лучше?
Даст кучу «разработчиков», которые могут использовать язык как калькулятор и писать Hello World?
Сомнительная польза для мира, да и для разработчика.
Даст кучу «разработчиков», которые могут использовать язык как калькулятор и писать Hello World?
Даст кучу «разработчиков» которые сами смогут решать свои задачи и не отвлекать «других разработчиков» по пустякам. Или смогут лучше объяснить, чего они хотят от других разработчиков если сами не справятся.
Слово переменная для них будет ассоциироваться не с погодой, а цикл станет не менструальным. Что в конечном итоге даже если они будут писать калькуляторы сделает их жизнь чуть проще, а они хоть и не большая, но часть мира. И если чуть лучше им, то чуть чуть лучше миру.
И это не означает, что от этого станет классно всем разом на планете. Те кто не хочет, чтобы им было классно, могут оставаться в том расположении духа которое им по душе.
Как по мне, то основы лучше осваивать не на js. А низкий порог входа означает низкое качество кода в целом.
Возможно если поставить себе цель стать программистом то есть более подходящие языки.
Но у меня такой цели не было например. А была цель не править шапку сайта с играми в локалке на каждой странице и для решения этой задачи подошёл PHP с его include(), а потом ещё были задачи и он тоже отлично подходил.
Но когда стало нужно держать миллион коннектов, PHP оказался слоном и прога написанная на C++ работала в миллион раз быстрее. Это была чужая прога и в исходниках не сказал бы, что удалось разобраться. Вся остальная часть сайта продолжала работать на PHP/MySQL и с этими задачами язык продолжал прекрасно справляться. Потом для решения задач понадобился JS и сейчас на нём писать классно.
А низкий порог входа означает низкое качество кода в целом.
В целом конечно. Но кто вообще это целое видел и зачем?
Я полагаю среде JS хватает высококлассных программистов которые пишут качественный код и могут на ревью джунов подтянуть.
Но от того, что нубы марают светлое лицо языка кому от этого хуже кроме статистики?
Если есть софт который написан некачественно, и софт которого нет — какой лучше?
И это не означает, что от этого станет классно всем разом на планете. Те кто не хочет, чтобы им было классно, могут оставаться в том расположении духа которое им по душе.
Как то вы слишком крутите и филосовствуете.
На хрен это надо?
Не нужно говорить что JS крутой язык, универсальный, может все и всегда, а по факту используется только в вебе, во фронтенде и периодически на бекенде.
Этакий язык Шредингер — может все в теории, пока не проверишь на практике.
Даст кучу «разработчиков» которые сами смогут решать свои задачи и не отвлекать «других разработчиков» по пустякам. Или смогут лучше объяснить, чего они хотят от других разработчиков если сами не справятся.
Я могу показаться немного адольфиком, но все же.
Если уже есть куча говнокодеров, которые прошли курсы, прочитали пару статей и книг, и считают себя программистами, то это не значит, что нужно вносить свою лепту в эту кучу говна.
Но когда стало нужно держать миллион коннектов, PHP оказался слоном и прога написанная на C++ работала в миллион раз быстрее.
PHP для веба, а не для highload.
Все почему то этим упрекают РНР и говорят, что он говно.
Но по факту РНР и не для highload.
Как по мне, то нода тоже вряд ли справиться с такой нагрузкой.
Но это, как говориться, не точно.
Если есть софт который написан некачественно, и софт которого нет — какой лучше?
Очень и очень плохая позиция.
Где то рядышком с «зачем трогать если работает?».
В некоторых, не побоюсь даже, во многих вопросах пусть уж лучше нет ничего, чем кривой табурет с педалями на одной ножке.
Не нужно говорить что JS крутой язык, универсальный, может все и всегда, а по факту используется только в вебе, во фронтенде и периодически на бекенде.
Соглашусь JS крутой язык (моё субъективное мнение). Насчёт остального не от меня информация. Можно действительно многое. Но я нынче фронтенд программист, поэтому не искушён в забраузерных возможностях. Но в браузере оно будет работать без установки, на любой платформе где есть браузер. Без компиляции и скачивания инсталяторов. Кроссплатформенность — это круто.
От себя скажу, что написав функциональность на клиенте со сборкой SVG, я конечно не мог принимать результат на бэкенде. Там пришлось написать нечто похожее, принимающее только исходные настройки и повторяющее из них то, что видел в браузере пользователь. Это было проще чем фантазировать как победить XSS. Если бы на бэкенде тоже был на JS, то мне не пришлось бы после каждой правки переписывать и тестировать обе версии.
Это я к тому, что повторно использовать код, а не писать велосипеды и на клиенте и на бэкэнде — это круто.
Я могу показаться немного адольфиком, но все же.
Это не круто.
пусть уж лучше нет ничего, чем кривой табурет с педалями на одной ножке.
Для того кто его сделал быть может он нужен (мало ли шоу какое устраивает), а ты можешь его не замечать и для тебя его не будет.
Но ты предпочитаешь замечать и выбиваешь у шоумена табурет из под ног потому, что табурет не правильный. Надеюсь у шоумена не было петли на шее. Извини, опять филлосовствую.
А тем временем человек сделавший табурет, может (если ты конечно уже не успел его линчевать) в следующий раз учесть ошибки проектирования и сделать табурет который тоже будет говном, но не вонючим. А потом новый, следующий, ещё один, сто пятый и наконец классный.
Мне кажется вообще все мастера из всех областей начинали с «куска говна» который потом выбрасывали, чтобы сделать новый «кусок чего-нибудь».
Отрывать им руки за первый блин, по Адольфски.
Это я к тому, что повторно использовать код, а не писать велосипеды и на клиенте и на бэкэнде — это круто.
Вот все про это говорят, а кто нибудь может привести пример?
Это мой реальный интерес, очень часто слышу как достоинство JS + Node.js, но по факту это маловероятно.
Frontend — это абсолютно событийно-ориентированное программирование. Только события, ничего более.
Backend — разве это событийно-ориентированное программирование? Как по мне, бэкенд можно спокойно разложить в последовательный (синхронный) порядок выполнения.
Ваш пример про SVG вполне можно перенести, но вот часто ли такое случается?
А тем временем человек сделавший табурет, может (если ты конечно уже не успел его линчевать) в следующий раз учесть ошибки проектирования и сделать табурет который тоже будет говном, но не вонючим. А потом новый, следующий, ещё один, сто пятый и наконец классный.
Абсолютно согласен.
И это применимо ко всему.
Вот только речь здесь про то, что говняных табуреток с JS будет больше, чем с каким-нибудь C#.
И это опять такие мое, и думаю не только, мнение.
Backend — разве это событийно-ориентированное программирование? Как по мне, бэкенд можно спокойно разложить в последовательный (синхронный) порядок выполнения.
И в результате получить 42
По мне так вызов метода API это уже событие. Да, что там вызов метода. Запуск программы это тоже событие! А передача ей входных данных, ещё какое событие! Наступление определённого времени? Достижение конца файла? Подключение с определённого IP? Без тех или иных событий смысл в программировании сомнителен.
Или вы под событиями только onClick понимаете?
Вот только речь здесь про то, что говняных табуреток с JS будет больше, чем с каким-нибудь C#.
И это опять такие мое, и думаю не только, мнение.
Сложнее станет выбирать себе поверхность без наклона? Или от них место в интернете закончится? С мнением я не спорю. Спорю скорее с тем, что взывает вас к сжиганию всего, что расходится с вашим чувством прекрасного.
Backend — разве это событийно-ориентированное программирование? Как по мне, бэкенд можно спокойно разложить в последовательный (синхронный) порядок выполнения.
Смотрели CQRS + Event Sourcing?
CQRS
Это вообще не про события
Event Sourcing
Ну, а также есть другие способы работы без событий.
Я к тому, что МОЖНО на событиях организовать и бизнес-логику, и весь бэкенд, вот только на сколько это адекватно?
Вполне адекватно для больших систем
Не считая того, что события в моделях (бизнес-логике) я считаю вообще не должны быть.
Но это отдельный разговор, и кто я такой чтобы навязывать свое мнение)))
Разве кто-то говорил про ноду? :)
Ну и подозреваю что сорцов таких систем в открытом доступе нет.
А то, что я читал по этой технологии — это все .net, если кто поделится примерами под другие платформы, буду только рад
* Регистраторы = Event
* Регистры = Events Store
* Агрегаторы = Snapshot
Говорят еще Redux работает в том же духе.
В остальном самому интересна эта тема, частично даже применяем, но есть много минусов.
1. Довольно ресурсоемко — далеко не везде вам требуется хранить историю событий, приведших к текущему снимку состояния сущности, а значит, вы будете тратить ресурсы впустую
2. Сложно в тестировании — возможно тут проблема больше в инструментарии, нежели в решении, но такую систему сложно тестировать модульными тестами, и просто сквозными
3. Новичкам взрывает мозги — для работы с такой системой нужно быть теоретически подкованным, иначе становится довольно сложно разбираться во всех этих неявных связях (немного помогают графы состояний и взаимосвязей компонентов в виде схемы)
4. Сложность в реализации — событийная модель накладывает одно серьезное ограничение на архитектуру, она: «асинхронна» — на деле это означает, что вы не сможете выполнять синхронные операции над доменом, к примеру: «пользователь заполняет тест и сразу получает результат анализа»
Есть и другие пункты, я просто их не могу пока припомнить. В остальном решение интересное, если его хорошенько изучить и правильно применить. По сути это паттерн «Команда», только немного в иной обертке и с другой областью применения, но с теми же плюсами и минусами.
Вот все про это говорят, а кто нибудь может привести пример?
Лично сталкивался только с примером для SVG, но сферически могу предположить:
- Балансировку нагрузки между клиентом и сервером;
- Преобразования форматирования для вывода на сайте или отправки электронных писем с сервера;
- Генерацию\верификацию открытых\закрытых ключей;
- Можно рендерить страницы на сервере и отправлять в IPFS;
- Писать проверки данных на клиенте и использовать тот же код на сервере, чтобы не дать клиенту на эти проверки повлиять, но не плодить запросы к серверу;
- Давать клиентам возможность на себе выполнять абстрактные операции, а по подписке принимать их на сервер;
- Comming soon…
Низкий порог входа это здорово. Так больше людей сможет научиться основам программирования. Это сделает мир лучше.
С одной стороны, да. А с другой — рынок наводняется неквалифицированными специалистами, из-за чего общая ценность этого занятия падает.
Код ниже вполне ок работает без ошибок (в браузере по крайней мере):
const a = { b: 1 }
a.b = 2
Все верно, однако присваивание a = {} выдаст ошибку, что вполне очевидно, на мой взгляд. С объектами const гарантирует, что ссылка будет всегда указывать на заданный при объявении объект. Для объектов с неизменяемыми полями следует смотреть в сторору Object.freeze().
А имелось ввиду, что const не работает с объектами.Можно спросить у автора, что имелось ввиду, он даже здесь отметился.
Я рискну предположить, что const должен быть константой на все время работы приложения. То есть это реально должна быть константа. Как например в языке C#. const же в javascript работает так как readonly в С#.
То есть в функции вы можете написать const a = weatherOnMars === 42? 4: 2; И при первом выполнении функции a будет 4, при втором 2. То есть, по сути своей это не константа вовсе. В функциональных языках именно так себя ведет var(могу ошибаться).
На любом языке можно написать фигню.
Например, мне может захотеться сделать в плюсах #define true false, и писать исходя из этого. Или я могу захотеть сортировать массив пузырьком, чтобы найти максимум.
Так что читать мануалы и книги действительно нужно. В любом языке.
Можете наследовать через классы, можете через прототипы.
Тот неловкий момент, когда забыл, что классы в JS работают через прототипы...
Тут разница в подходах. Когда говорят про прототипное наследование предполагается, что можно наследовать один объект через другой без создания классов:
const proto = {
hello () {
return `Hello, my name is ${ this.name }`;
}
};
const george = Object.assign(Object.create(proto), { name: 'george' });
console.log(george.hello());
И это порой очень гибко и удобно. С таким подходом, например, вы можете сделать factory, которая будет отлично альтернативой классам (и многим это нравится из-за отсутствия необходимости писать new
)
const greeter = (name) => Object.assign(Object.create(proto), {
name
});
const george = greeter('george');
const msg = george.hello();
И надо понимать, что именно это базовый подход в js для наследования. А классы, которые используют под капотом этот же механизм просто вариант для тех, кто не видит наследования без них.
Не исключено, что это именно то, что имел ввиду автор.
Да, это инерция объектного подхода к программированию. Мне тоже тяжело давалось (и до сих пор дается) понимание что javascript'овый this — это не надежный java'вский this, а что-то ближе к сишным указателям. Отметил тенденцию, что все чаще встречается мысль, что можно и совсем без this в JS'е обходиться. Не спрашивайте как — я тоже далеко не гуру в JS :)
Автор повторил свои мантры 3-летней давности о том, какой JS замечательный, мощный и безграничный (в смысле отсутствия границ для программиста: хочешь — стреляй в колено, а хочешь — в лодыжку) язык. Конечно, если ты идеальный (сферический в вакууме) программист, каковым себя автор, похоже, и считает. Хотя в его первой статье на хабре его поймали на том, что он сам толком не знает деталей поведения языка.
Я — не профессиональный программист. Но считаю, что ценность языка программирования должна заключаться не в том, что он позволяет тебе застрелиться бесконечным количеством способов, а в том, чтобы с его помощью можно было написать программу с минимальным количеством ошибок, привлекая для этого многочисленных разработчиков средней квалификации, а не редких и дорогих гуру, познавших дзен JS.
Но автор-то позиционирует язык как универсальный, пригодный для любых сфер применения.
Я руководил программистами на JavaScript и средние программисты с ним справляются прекрасно
Понимаете, в данном контексте «прекрасно» это сравнительная характеристика. «Прекрасно» должно быть не само по себе, а по сравнению с чем-то. Если бы вы руководили программистами на других языках, и они справлялись менее «прекрасно» с аналогичными задачами, тогда можно было бы о чем-то говорить. А у вас получается аргументация «я пишу на JS, больше ничего не знаю и знать не хочу, но меня все устраивает». Лично для вас этот аргумент конечно работает, но для остальных выглядит неубедительно.
Вы пишите, что не программист, и при этом ругаете язык. Любите критиковать то, в чём не разбираетесь?
Я пишу, что я не профессиональный программист (т.е. что не зарабатываю этим себе на жизнь), а не то что я не программист.
А профессиональный программист (как, впрочем, любой инженер вообще) просто обязан пользоваться максимально точным языком. Хотя, возможно, долгое использование JS могло вызвать такой эффект.
Так вот, я не менеджер и не дизайнер. Я инженер-системотехник, специальность «Вычислительные машиины, комплексы, системы и сети». Поэтому чуть-чуть разбираюсь в теме. И критикую я не язык, а необъективное его восхваление. Как уже было написано до меня, JS — замечательный язык для той сферы применения, для которой он был изначально создан. Не более того.
Автор написал тонну текста
Автор написал даже 2 тонны текста — 3 года назад и сейчас. И, по сути, ни одного аргумента почему JS восхитителен кроме «могу писать как хочу» так и не привел.
и сделал пару описок
Описки — в письме, здесь могут быть опечатки. Но приведенный пример — это именно ошибка.
А ваши жалобы идут
Это не жалобы, и они, соответственно, никуда не идут. Это констатация фактов.
Считать, что знание языка определяется тем, помнит ли человек, что возвращается при делении на 0… Ну не знаю.
Дабы не быть голословным, покажу код.
Есть у меня библиотека для рисования на канвасе DeltaJS (ранее известная как Graphics2D.js, я даже писал о ней на Хабре). Сейчас она в фазе активного переписывания и дописывания, и её можно найти вот тут: https://github.com/keyten/Graphics2D
В ней можно создать квадрат на канвасе:
ctx.rect(10, 10, 200, 200, 'red');
Каждая из координат прогоняется через функцию `Delta.distance`.
Вдруг в какой-то момент разработчик вспомнил, что существует Ретина, и захотел рисовать квадраты с шириной не в px (пикселях), а в pt. Что ж, он делает так:
var oldDistance = Delta.distance;
Delta.distance = function (dist) {
if (isPtDist(dist)) {
return convertPtToPx(dist);
}
return oldDistance.apply(this, arguments);
}
И всё, благополучно можно писать
ctx.rect('10pt', '10pt', '200pt', '200pt', 'red');
Вообще-то все css-единицы итак поддерживаются в Delta, однако distance всё ещё может быть переопределение, чтобы добавить, например, полярные координаты или какие-нибудь специальные координаты в условиях специального Layout. По факту, distance специально вынесена как публичная функция, чтобы её можно было переопределить, тем самым вмешавшись в логику всей библиотеки, меняя лишь маленький кусочек. Требование при переопределении одно: возвращаться должно число. В пикселях.
Если мне понадобится что-то более существенное, например, изменить порядок аргументов функции или добавить новые, я могу переопределить Delta.Context.prototype.rect.
И подобных точек вмешательства несколько. Можно вмешаться в логику attr (Delta.Drawable.prototype.attr), добавив или изменив своё в attrHooks. Вмешаться в логику событий через eventsHooks. Через тот же attrHooks вмешаться в логику animate.
Обсуждая это с людьми, пишущими на плюсах, я спросил, как с этим справляются они. Что, если захочется добавить дополнительный параметр в std:sort или научить новому методу std:string?
Никак — ответили мне. Так ты можешь только выстрелить в ногу.
Но… — попытался возразить я.
Никаких но. Нога.
Между тем, jQuery таким образом существует уже фиг знает сколько лет. Со своими плагинами и многим другим. Ты можешь добавить на страницу сто плагинов, которые вмешиваются во внутреннюю логику jQuery и меняют разные куски, и — внезапно окажется, что у кода на js настолько большой запас прочности, что это всё будет отлично работать и синхронизироваться друг с другом, делая ровно то, что ты от них ожидаешь. Даже если меняют ровно одно и то же (при этом сохраняя предыдущее переопределение функции и передавая ему управление, если нужно).
Да, иногда плагины бывают несовместимы. Но это не отменяет того, что концепция крутая и работает.
Упс, прошу прощения, неправильно выразился.
Стоило написать так: представь, что ты пишешь std:sort или std:string, и захотел разрешить в каком-то месте их расширять.
Да, в определенных пределах, выход за которые грозит отстрелом ноги.
Считать, что знание языка определяется тем, помнит ли человек, что возвращается при делении на 0… Ну не знаю.
Я не рискну выразить в двух словах что такое знание языка. Тем более, как я уже указал выше, я — не профессиональный программист. Но, IMHO, знание неочевидных особенностей этого языка туда входит.
Поясню на примере естественных языков. Мы говорим на русском и не считаем его сложным. Но на деле это такой себе JS среди естественных языков — очень много конкретных случаев, которые нужно знать вместо малочисленных четких правил. К примеру, ударения. В русском языке правил для них нет вообще! Нужно знать все(!) случаи. И это ад для любого человека, родной язык которого имеет правила для ударений.
Причем даже носители русского языка делают кучу ошибок в ударениях, причем даже в очень распространенных словах, типа «позвОнишь» вместо «позвонИшь».
Или можно взять случаи, когда носители делают ошибку в грамматическом роде существительных — «шампунью» вместо «шампунем».
В общем, большинству всей жизни не хватает для того, чтобы грамотно научиться говорить по-русски.
И язык программирования такого типа (условно) никак не может считаться хорошим универсальным языком.
Автор вовсе не говорил, что возможность застрелиться большим количеством способов — непревзойдённое преимущество. Автор говорил именно о свободе действий — да, в том числе и свободе стреляться.
Только свобода застрелиться как раз и вытекает из свободы «вообще». Причем на практике (скорее всего) первое будет превращаться во второе.
Взять тезис о том, что если программа вместо аварийного прекращения продолжает стараться хоть как-нибудь работать дальше — это хорошо. Ну, на самом деле. Программа завершилась с ошибкой — это же кошмар. Надо же искать ошибку, исправлять ее, это ж лишняя работа. А так программа кое-как работает, пусть неправильно, ну и что? Ведь правильность не самое главное, верно? Зато разрабатывается быстро!
То же самое насчет системы типов, насчет статического анализа.
Я даже могу не знать вообще абсолютно ничего о языке. Если язык позволяет делать какую-то ошибку — люди обязательно ее сделают. И в случае с JS это означает, что люди делают гораздо больше ошибок, чем в других языках. Обязательно.
При этом доводы о том, что в JS можно сделать то, что в других языках сделать нельзя, меня не впечатляют.
Мне совершенно неочевидно, почему сразу не написать функцию, которая позволяла бы явный выбор единицы измерения.
ctx.rect(10, 10, 200, 200, 'red', CSS_PT);
ctx.rect(10, 10, 200, 200, 'red', CSS_PX);
Тогда можно будет единообразно рисовать эти самые квадраты независимо от единиц измерения, например в цикле. В вашем же случае с «мощным переопределением» для px нужно передавать числа, а для pt — строки, которые нужно еще и сформировать. Нет, конечно же, можно сделать и переопределяемую функцию рисования квадратов в цикле… Но зачем???
Я допускаю, что раз в году найдется такой пример, который без переопределения никак нельзя сделать. Но, блин, на мой взгляд, вы используете не потому, что без этого никак или смертельно неудобно, а потому что можно и потому что привыкли. и иначе уже просто не мыслите.
Но время прошло, и JS превратился в промышленный язык. А от детских болезней избавиться так и не смог. Сообщество (за исключением некоторых фанатов, которых мы здесь наблюдаем) понимает его недостатки, но избавиться от них не могут из-за обратной совместимости.
В этом и состоит основной недостаток JS — сложившаяся экосистема не позволяет сломать обратную совместимость, вследствие чего детские болезни остаются в нем навсегда, а развитие происходит в основном за счет синтаксического сахара и костылей типа Symbol.
И язык программирования такого типа (условно) никак не может считаться хорошим универсальным языком.
Сравнивать языки программирования и естественные тоже не очень правильно по очевидной причине. Правильнее сравнивать ЯП с эсперанто, токи пона, ифкуилем, илакшем и иже с ними.
А так программа кое-как работает, пусть неправильно
А может, внезапно, работать правильно! Хотя бы чуть-чуть.
Вот я пишу-пишу в программе на Java, и вдруг там непойманный exception в одном из модулей, и вся программа вылетает. И мой несохранённый документ… тоже вылетает.
А вот я пишу-пишу в программе на JS / [другом языке, позволяющем ошибки], и вдруг там непойманный exception в одном из модулей. Пол-интерфейса ломается, зато второй половины мне хватает, чтобы сохранить документ. И я благополучно перезапускаю программу и работаю дальше.
Если я правильно понял ваш пример.
Мне совершенно неочевидно, почему сразу не написать функцию, которая позволяла бы явный выбор единицы измерения.
ctx.rect(10, 10, 200, 200, 'red', CSS_PT); ctx.rect(10, 10, 200, 200, 'red', CSS_PX);
Напрашивается заметить, что все 4 параметра могут быть в разных системах координат, а там ещё есть и цвет, и делать ещё 5 доппараметров в функции как-то некрасиво, как минимум.
Но тут гораздо важнее иное: логика превращения каких-то единиц в пиксели может быть достаточно сложной (сложнее, чем взять константу и, например, умножить на число). Ну, например, я написал плагин для изометрии и хочу делать так (пример немножко утрированный):
var pointInIsometria = {
plane: planeObject,
rectOfPlane: [x, y, z]
};
ctx.rect(pointInIsometria, pointInIsometria, 200, 200, 'red');
// или даже так:
ctx.rect(planeObject, [x, y, z], 200, 200, 'red');
Кроме того, мне не нужно добавлять какие-то дополнительные параметры, чтобы позволять что-то расширять. Я по умолчанию разрешаю это делать практически со всеми своими объектами и методами (но с риском выстрелить в ногу, разумеется). И совершенно не забочусь, что пойдёт, если кто-то расширит как-то не так.
На ум пришла аналогия: это как продавать машину, разрешать на ней менять колёса, двигатель и дворники (компоненты, хочу заметить, вполне себе самостоятельные, и замена любого из них на делающий то же, но по-другому, и предоставляющий тот же io-интерфейс, не ломает систему в целом), но забивать на гарантию в случае нестоковой комплектации ).
У меня у объектов на канвасе есть функция
attr
. Она возвращает / изменяет значение во внутреннем хэше объекта:rect.attr('x'); // -> 20; работает как getAttr
rect.attr('x', 200); // работает как setAttr
Но кроме этого она проверяет наличие геттера / сеттера в объекте attrHooks в классе, и дёргает его. Например, на изменение координат прямоугольника дёргается перерисовка.
Фишка в том, что есть несколько классов (Rect, Circle, Path, Image, Text), которые наследуются от абстрактного класса Drawable. У Drawable есть свои общие attrHooks, и у каждого из классов есть свои специфические. При этом я хочу, чтобы при добавлении новых методов в attrHooks у Drawable они появлялись у всех его наследников (если они там не перезаписаны, естественно). Но не наоборот — специфические attrHooks у Rect не должны затрагивать attrHooks у Drawable.
На прототипах это реализовалось достаточно легко:
function drawableAttrHooks() {}
Drawable.prototype.attrHooks = drawableAttrHooks.prototype;
Rect.prototype.attrHooks = new drawableAttrHooks();
// теперь если я напишу
Drawable.prototype.attrHooks.someProperty = 5;
// то оно прокинется в Rect:
Rect.prototype.attrHooks.someProperty; // -> 5
// но в обратную сторону это не действует:
Rect.prototype.attrHooks.someAnotherProperty = 8;
Drawable.prototype.attrHooks.someAnotherProperty; // -> undefined
А вот я пишу-пишу в программе на JS / [другом языке, позволяющем ошибки], и вдруг там непойманный exception в одном из модулей. Пол-интерфейса ломается, зато второй половины мне хватает, чтобы сохранить документ. И я благополучно перезапускаю программу и работаю дальше.
Это если вам очень повезло. Довольно часто можно оказаться в ситуации, что сохранить-то удалось, а ошибка была в каких-нибудь внутренних структурах. В итоге сохранён мусор. Тихая порча данных засчёт проглоченной ошибки — куда более неприятная ситуация, чем просто падение.
Есть вещи которые бы не рискнул разрабатывать на node(Это связанно с ООП и с глубоким наследованием)…
Респект автору, согласен на 200%. Хейтить то, чего не понимаешь — обычное человеческое свойство, но будучи инженером — ты, имхо, должен быть осторожее и объективнее. Легко называть всех вокруг идиотами, но будте готовы потом доказать что сами не идиот. Хейтеры, по моему опыту, доказать этого чаще всего не могут, а споры "о вкусах" тут не имеют смысла, ибо значение имеют только "pros/cons".
И сейчас «мир раскололся» на 2-3 лагеря:
1. те кто любят псевдосвободу и придерживаются позиции «сам дурак», а JS красавчег
2. те кто считают, что инструмент должен минимизировать ошибки разработчика.
3. все остальные
Основной аргумент 1 лагеря и автора статьи, это то что если программист нормальный, то все будет ок.
Но если программист норм, то проблем в принципе не должно быть.
JS (как инструмент) никак не уменьшает число ошибок, а наоборот местами способствует их появлению, зато имеет низкий порог
Но надо оговориться, порог вхождения в программки типа «Hello World» действительно низкий, а вот порог вхождения в мир качественной разработки, ни чуть не ниже чем у других «ограничивающих свободы» языков.
Популярность и эффективность/правильность/качество — это к сожаления далеко не одно и тоже.
Очень далеко.
И, опять таки к сожалению, низкий порог вхождения, как раз таки в большей степени и определяет популярность.
если вы действительно хорошо разбираетесь и в языках, и в архитектуре, и в парадигмах, и умеете всем этим пользоваться — лучше языка чем JavaScript для общих задач вам не найти.
Порог входа в JavaScript был и остаётся очень низким, это даёт повод многим новичкам ругать то, в чём они не разобрались.
я, например, прекрасно читаю даже обфусцированный код библиотек, чего и вам желаю.
Перечитайте про duck typing и научитесь им пользоваться
А вообще, развивайте дисциплину кода, не всё время за юбкой IDE прятаться. Это не стёб, анализаторы это хорошо, но если для вас проблема такие ошибки — как-то вы не правильно программируете.
Общий посыл статьи понятен — язык великолепный, просто вы не умеете программировать)
const a = 5
const a = 4
VM1825:1 Uncaught SyntaxError: Identifier 'a' has already been declared
А если попробовать так:
const a = 5;
a = 4;
Насколько я помню, в этом случае значение останется равным пяти, но никаких уведомлений об ошибках не последует.
Насколько я помню, в этом случае значение останется равным пяти, но никаких уведомлений об ошибках не последует.
"use strict";
const a = 5
undefined
a = 3
VM156:1 Uncaught TypeError: Assignment to constant variable.
at <anonymous>:1:3
Хром умеет такое вылавливать, тут уже вопросы к разработчикам движков.
Uncaught TypeError: Assignment to constant variable.
я буду обновлять комментарии перед написанием своего
и дело даже не в наличии у джаваскрипта хоть какой-то ecma-спеки.
как мне показывали, руби восхитителен вплоть до превращения класса в переменную типа стринг, с естественным «обломом» при попытке создать объект этого класса после такого финта ушами.
особенно это прекрасно, если этот финт ушами проделал падаван в левом подключенном модуле, при попытке дополнить класс «очень нужными мегафичами».
class ololo {
constructor() { this.hello = 'Привет';}
}
class hohoho extends ololo {
toString() { return this.hello; }
}
let bathert = `${new hohoho}`;
console.log(bathert);
JS может всё, или Ruby может так?
class ruby {
constructor() {this = 'Строка'}
}
JS второй пример не может
Изначальные принципы языка были настолько хороши, что 10 лет (с 1999 по 2009) язык прожил вообще без изменений. Конечно к этому были и негативные причины, политика Microsoft и Mozilla, многое другое, но, уверен, не многие из других популярных языков смогли бы пройти такое же испытание и подняться после этого. Просто представьте, что стало бы с TypeScript или Rust после 10 лет отсутствия обновлений. Причина по которой JavaScript выжил очень проста, он решает одну задачу и делает это идеально.
Да он прожил 10 лет без изменений и решал свою задачу — добавление лёгкого скриптования к свёрстанному html-коду. Как только какие-то умники решили на нём "программировать" всё сразу пошло наперекосяк.
Если вы вызываете функцию как myObj.func(), то можете быть уверены, что this будет равен myObj.Всё-таки почти уверены:
function f() {console.log(this.field)}
let obj = {field:321, f:f.bind({field:123})}
obj.f()
О боже, только не опять, мне работать надо!
На данный момент JavaScript — самый популярный ЯП на планете. И, как бы я не уважал TypeScript, Java, C#, Go, другие языки — у них нет шансов изменить статус кво.
Лол, лол, лол, вы на какой планете живёте?
На планете Земля самый популярный язык — Java, без Script
Он даёт действительно много свободы и в нём нет защиты от дурака, поэтому такие люди там не задерживаются.
Лол, толпы jquery-говнокодеров-формошлёпов и не знали…
мир гораздо богаче вашего любимого языка и то, что для одних странно, для других норма. посмотрите хотя бы на haskell с его монадами и функторами, очень мощные штуки,
Лол, вы говорите это человеку который
всю жизнь писал на Erlang, Elixir, Haskell и Lisp
Как спортивный байк
Спортивный байк под тяжестью костылей весящий 30 тонн? Не, спасибо.
не делайте логических ошибок и будет вам счастье
Лол, даже лучшие в мире программисты и компании тратящие 7 миллиардов долларов на разработку делают ошибки.
отсутствие нормальных классов / ООП — ооп здесь богаче, чем в большинстве других языков. Можете наследовать через классы, можете через прототипы.
Идите создайте интерфейс
Лично я пишу на JavaScript уже 15 лет, искренне считаю его одним из самых мощных ЯП на сегодняшний день, поэтому не позволю его обижать
Ещё один защитничек не знающий язык который защищает https://habrahabr.ru/post/214087/#comment_7360557
И колбеки, и промисы, и async/await — нативные, поэтому код они не утяжеляют. Не знаю, что вы называете фьючерсами, я этим не торгую.
И вы себя называете программистом?
https://en.wikipedia.org/wiki/Futures_and_promises
Изначальные принципы языка были настолько хороши, что 10 лет (с 1999 по 2009) язык прожил вообще без изменений.
однопоточный рантайм — это очень удобно.
Иногда удобно, иногда нет. Ваш «гибкий» и «мощный» джаваскрипт не дает выбора. Я например пишу на python, и там похожая проблема (GIL). Но я, в отличие от вас, отсутствие выбора не собираюсь заносить ему в достоинства. Как сказал один умный человек, «lack of something is not a feature».
NodeJS на одной средней машинке может держать по 100 000 коннектов
И это прекрасно. А потом у вас появляется код, который делает что-то в цикле над несколькими объектами. А потом бизнес вводит новое правило, и в каких-то редких случаях у вас будет не 3 объекта, а 3000. (пример: как-то обрабатываем сообщения пользователя отправленные за последнюю минуту, потом добавили фичу «рассылка», где пользователь отправляет сообщения целой группе).
И в результате у вас «пусть весь мир подождет» — все ваши 100 000 коннектов подвисают на время выполнения цикла. Любая CPU-bound задача вешает все ваши сотни тысяч коннектов. Вы думаете все программисты при написании каждой строчки кода задумываются о том, может ли она стать cpu-bound при каких-то условиях? Как только вы уходите от IO-bound формошлепства, внезапно оказывается что нужна архитектура. И тут «гибкость» джаваскрипта дает вам широчайшие возможности налажать с этой самой архитектурой.
Работа с ассинхронностью/потоками это не слабость, а одно из мощнейших преимуществ JavaScript. Это может требовать переучивания и изменения привычек, но поверьте, вы приобретёте очень многое.
Какбэ асинхронный ввод-вывод появился задолго до NodeJS. Просто в какой-то момент кучка JS-разработчиков дорвалась до него и стала вовсю визжать о революции. Было дововльно забавно слышать все эти вопли, ведь те, у кого была потребность в async IO и так давно о нем знали (python-twisted например вышел в 2002 году, если говорить о динамических языках).
слабые типы с неявными (и порой довольно странными) преобразованиями
Странными для кого?
Перечитайте про duck typing и научитесь им пользоваться, проблем с типами у вас не возникнет.
5 - '3' // 2
5 + '3' // "53"
Странными для здравого смысла. Львиная доля багов в JS-коде связана именно с ними. Это реальность.
Если бы можно было просто «перечитать про duck typing» и все баги пропали, люди давно бы это сделали. За последние 24 года пока им это не удалось. Наверное челлендж состоит не только в «перечитать про duck typing». Наверное duck typing, имеет как достоинства, так и недостатки. Наверное ситуации, где недостатки перевешивают достоинства возникают довольно часто.
Во многих случаях правильного применения JavaScript прототипы оказываются быстрее, удобнее и логичнее
Ага, а шотландцы не насилуют женщин, потому что во многих случаях насилие в Шотландии совершается ненастоящими шотландцами. Ведь "настоящий шотландец" не будет никого насиловать.
Понимаете, проблема в том, что случаев «правильного», как вы выразились, применения Javascript очень мало. И, как ни странно, почти всегда эти примеры «правильного» использования навеяны какой-то другой экосистемой.
А вообще, развивайте дисциплину кода, не всё время за юбкой IDE прятаться. Это не стёб, анализаторы это хорошо, но если для вас проблема такие ошибки — как-то вы не правильно программируете.
Понимаете, когда дисциплина навязывается, а не является опциональной, это зачастую (пусть и не всегда) позволяет сократить издержки. Именно поэтому и придумали typescript и его аналоги.
отсутствие вывода типов в самом языке или в каком-либо инструменте
Это есть, изучайте синтаксис.
myVar.constructor
Странно, что за 15 лет разработки вы так и не узнали что такое Type inference. Ах да, вы же 15 лет пишете на JS.
(впрочем, аргумент про type inference в динамическом языке выглядит довольно странно)
При правильном использовании проблем с this не возникает
Опять это волшебное «правильное использования». Понимаете, при «правильном использовани»и проблем не возникает ни на perl, ни на C++, ни на brainfuck. Суть в том, насколько быстро разработчики проходят путь от «неправильного» использования до «правильного». В случае джаваскрипта — они зачастую его не проходят вовсе. Аргумент «я один стою тут в пальто красивый» не работает когда критикуют экосистему, а не вас.
не делайте логических ошибок. Ваши ошибки — не вина языка
Если средний разработчик решая некую задачу на языке Х в среднем делает 10 ошибок, а на языке У — 5 ошибок, то это вина языка Х.
если хотите сделать регулярные выражения удобнее — используйте или напишите библиотеки
Автор, речь идет не о регулярных выражениях, а о pattern matching. Вы точно 15 лет в разработке?
В общем, оригинальная статья конечно была слабой, но ваша уж совсем ни о чем. Состоит наполовину из фанбоизма и наполовину из непонимания основ и терминологии.
Инструментом надо уметь пользоваться. Пользуешься правильно — профит, неправильно — не профит. Не хочешь — не используй совсем, как этот делает тот же Крокфорд.
Речь про удобство использования инструмента.
Если многим людям не удобно пользоваться инструментом, значит это в большей степени проблема инструмента, нежели кривых рук.
Если говорить про «правильно не правильно» — правильно используют язык, наверное малая часть людей которая им пользуется, и проблема это из-за низкого порога вхождения.
В этой ветке про это.
Пруфы на то, что в случае с JavaScript это так? Статистика использования, сравнение одинаковых проектов на разных языках, замеры? Ах да, это же «всем очевидные вещи».
Ну вообще то да — это очевидные вещи.
JS имеет очень мало ограничений, и многие (в том числе автор и многие комментаторы тут) ставят это в достоинство.
Исходя из-за малого количества ограничений (которые как раз таки уберегают от ошибок), гораздо проще сделать ошибку, в сравнении с тем же РНР.
JS динамическая типизация.
В сравнении с языками со статической типизацией, он явно уступает в количество ошибок типов.
Это все не пруфы, а логика и здравый смысл, а не истерика с пеной у рта.
Многим это сколько? Их больше, чем «немногих»? Где это посмотреть? Мне вот, например, вполне комфортно. На основании чего я — немногих? На основании вашего личного мнения?
На основании того, что JS в большей степени используется для придания динамики веб страничкам.
На основании того, что использование JS заключается в привязке событий с помощью jQuery и использовании вышеупомянутой библиотеке (при чем это заслуга библиотеки, а не языка).
На основании того, что существуют различные TypeScript, CoffieScript, и др. вещи, которые расширяют язык (явно не от хорошей жизни, верно?).
Если вы еще и для этого пруфы попросите, то я тут бессилен.
Статическая типизация, достаточная чтобы удовлетворить большую часть потребностей в JavaScript
давно есть.
Большую — это какую, пруфы пожалуйста.
Опциональная динамическая типизация позволяет разработать и запустить проект быстрее, что в этом плохого?
Плохо что быстро запуститься калымага, которая может сломаться в любой момент, просто потому что произошла конкатенация вместо сложения.
Для вас может и верно, для меня это напротив показатель гибкости языка, который позволяет делать в том числе и вот такие штуки, удовлетворяя потребности многих из тех, кто раньше от языка плевался, и при этом оставаясь тем же самым языком.
Причем тут гибкость языка? Это просто транслитераторы из одного синтаксиса в другой. Такое можно сделать вообще для любого языка, никакой особенности для javascript тут нет. Для Java вот есть MPS.
Нет. Это разные языки. В Javascript нет строгой типизации, в typescript есть. Одно это отличие позволяет весьма четко их разделить.
Это как, например, ругать Java и хвалить Kotlin вполне нормально, потому что хоть runtime и один, языки то разные.
И вы перепутали коммент. Вы тут выше отвечали на то, что существование таких вещей, как TypeScript, говорит вам о том, что
для меня это напротив показатель гибкости языка, который позволяет делать в том числе и вот такие штуки
Но вот причем тут гибкость языка, совсем не понятно.
Вы уже сами не знаете как оправдать JS.
Небольшой вопрос-пример:
В TS есть такая замечательная вещь как интерфейсы.
И вы хотите сказать что это заслуга-особенность JavaScript?!
WAT?!
Статическая типизация#Преимущества
Например, это:
Многие ошибки исключаются уже на стадии компиляции.
В интегрированной среде разработки осуществимо более релевантное автодополнение, особенно если типизация — строгая статическая: множество вариантов можно отбросить как не подходящие по типу.
Чем больше и сложнее проект, тем большее преимущество дает статическая типизация, и наоборот.
А теперь, чтобы не быть голословным, приведите пожалуйста пример статической типизации, на native JS, которая так сможет.
Я возможно открою вам глаза, но в реальной жизни, в реальной работе огромное число проектов переписываются заново независимо от языка на котором они были изначально написаны
И это я так понимаю очередная крутость JS?
Давайте быстренько напишем на JS, все равно получится говно и потом придется переписать на другой нормальный язык?
Основные причины тому обычно изменение требований к проекту после проверки идеи, необходимость оптимизации(писать под хайлоад с самого начала ни один менеджер проекта в своем уме не даст). Да вообще необходимость переписывания прототипа хорошо известное правило
Можно писать проект на одном языке, если хорошо подойти к вопросам архитектуры и ограничений.
Но я так понимаю это невозможно с JS, т.к. «язык не ставит никаких рамок и это его основная особенность», нет?
Это не так. Лет эдак пять как. Года эдак три как это не знают только те, кто в коме.
Там для вас специально написано в БОЛЬШЕЙ степени (выделю побольше чтобы наверняка).
Если я не прав, то просвятите меня, где JS используется чаще, чем во frontend?
Откуда взялось Native JavaScript когда речь шла о JavaScript?
Но мы уже выяснили это ваше воспаленное сознание считают TypeScript, Dart (так уж и быть) и… «обычным» JS, так что тут уже выяснять нечего.
Да, это очевидная для любой компании крутость JavaScript — это прекрасный инструмент для создания полнофункциональных прототипов. Наверное удивитесь, людям которые такие прототипы создают платят кучу денег. К слову переписать можно(выдыхайте) опять на JavaScript.
Т.е. люди платят за прототип (чего вот только вопрос, frontend, backend, всего вместе?), и потом платят за перепись прототипа.
Интересно у вас дела делаются.
«для придания динамики веб страничкам.» === «чаще, чем во frontend»
Front-end для вас ограничивается приданием динамики веб-страничкам? Мда, с кем я разговариваю?
Таки я допустил ошибку, черт((((
Специально для вас — ПРУФЫ про большую степень. Если вы сайты-визитки клепаете на апворке или фигачите в JSP, это не значит что весь остальной мир занимается тем же самым. Кроме того, более 10 лет существуют настоящие монстры типа Sencha / ExtJS которые написаны на JavaScript.
WAAAAAAAAAAAAAAAAAAT?!
А чем эти монстры занимаются?
ExtJS — «JavaScript framework for web application»
React — «A JavaScript library for building user interfaces»
AngularJS — «Superheroic JavaScript MVW Framework»
Мне кажется или только frontend'ом?
современный фронтенд сейчас это UI целиком и еще кусок бекенда в придачу, который отдали фронтендщикам чтобы они уже наконец отстали от занятых людей и готовили себе свои модельки для формочек сами. И отдавали данные желательно тоже сами, а еще лучше, чтобы и вообще API для этих прослоек сами создали и задокументировали, и чтоб саппортили, чтобы бекенд-разработчики могли спокойно жить в своем мире баз данных и сложной бизнес-логики.
А все это фронтендщикам оказалось удобнее делать на джаваскрипте, который они уже знали. И решив так, получилось очень даже неплохо для всех. Кроме, похоже, некоторых «бекендщиков», которые теперь остались без работы и у которых теперь от этого пукан бомбит — «а вот в твистед это было», «а вот тут это было».
Прекрасно сказано.
А чем эти монстры занимаются?
ExtJS — «JavaScript framework for web application»
…
Мне кажется или только frontend'ом?
Ваш ответ:
ExtJS это супермашина, которая умеет создавать вообще весь юай, очень сложный, основываясь только на данных с бекенда
WAT?!
Ну да. А теперь это называется фронтенд на джаваскрипте. Отнюдь не «придание динамики веб-страничкам», не так ли?
Ну как бы это и есть придание динамики веб страничке)))
А у вас видимо истерика из-за того что парни из frontend — это недооцененные гении?)))
SPA — это тоже придание динамики веб страничкам.
При ответе только постарайтесь не забрызгать меня слюной.
Ну пожалуйста…
Язык мало то, что не однопоточный, так как в нем есть потоки — называется WebWorkerДа ладно? Вебворкеров вообще-то нет ни в стандарте ECMAScript (оттуда их убрали), ни в серверном джаваскрипте (NodeJS). А знаете где есть API вебворкеров? В браузерах. А когда люди говорят о многопоточности, обычно речь вовсе не о них. Вы предлагаете на серверах запускать браузеры для числодробилок что-ли?
Где была асихнронная функциональность в других языках в том виде, в котором она была популяризирована Node.js?«В том виде» — это на колбеках что-ли? Где нужно там и была, в том же Twisted например. В 2002 году. Просто никто не кричал на весь мир что это революция, т.к. там все-таки сообщество ближе к инженерам, чем к истеричным хипстерам.
Вы так делаете в коде на реальных проектах? Вы — говнокодер.Скатились до перехода на личности в первом же комментарии. Не умеете холиварить :)
Но суть не.в том, пишет так какой-то конкретный программист или нет. Суть в том, что такие ошибки возникают у огромного кол-ва JS-разработчиков. И не возникают у разработчиков на других языках (даже динамических).
Вот вам пример из жизни: API одного из монополистов некоего рынка возвращает цену услуги, обычно числом, но иногда внезапно строкой. В документации естественно об этом ничего нет. Вы решили стать посредником, берете с юзера цену за услугу, и добавляете к ней $5. Пишете на своем любимом nodejs:
itemPrice = api.requestPrice(item)
chargePrice = itemPrice + COMMISSION
Тестируете — все работает. Запустили в продакшен, клиенты приходят, все вроде хорошо. И вдруг через несколько месяцев вы узнаете, что в 0.1% случаев вы чаржили с юзеров в 10 раз больше, чем обещали. $3005 вместо $300. Был бы код на другом языке, при первой же такой ситуации вы бы получили runtime error, traceback, и уведомление. Решили бы проблему в тот же день. Но поскольку вы писали на JS, вместо этого вы получили несколько месяцев скрытого бага. Корпоративные клиенты от вас в страхе уходят, обычные юзеры угрожают подать в суд и ругают вашу компанию в соцмедиа.
Плохое third-party API? Безусловно. Но факт остается в том, любой другой вменяемый язык спас бы вас от этой ситуации. Но у вас же дажваскрипт. «Г» —
Пруфы?Само существование (и достаточная популярность) typescript является пруфом того, что та же статическая типизация бывает полезна.
Пруфы на то, что в случае с JavaScript это так? Статистика использования, сравнение одинаковых проектов на разных языках, замеры? Ах да, это же «всем очевидные вещи».
Это было всего лишь опровержением достаточно глупого утверждения: «ваши ошибки — не вина языка». И тут важно не то, о каком языке это было сказано, а лишь то, что аргумент ложный. Ошибки, которые программисты допускают в одних языках чаще, чем в других — это вина и языка, и программиста.
Вы сказали что в языке есть многопоточность в виде вебворкеров. Я вам показал почему это утверждение ложное: в языке нет вебворкеров (есть API в браузерах), и ту многопоточность о которой вам говорят, они не дают.
Пишете критические для вещи не зная инструментария?Вы даже не удосужились прочитать мой комментарий? Повторю еще раз, более коротко: есть баг (заранее неизвестный) в third-party API. Плохой язык позволил бы этот баг проглотить без каких-то уведомлений, и выдать непредсказуемый результат. Это — очевидный недостаток языка. Что никак не отменяет того, что баг-то на самом деле в API. Но его поменять нельзя, а язык — можно.
TypeScript это и есть JavaScript
Ха-ха. А еще Python — это и есть Javascript. Да и вообще, любой Тьюриг-полный язык — это JavaScript.
Я ничего не утверждал — я попросил вас доказать ваше утверждение, что на JavaScript допускают больше ошибок, чем на других языках
Перечитайте мой комментарий: «Если средний разработчик решая некую задачу на языке Х в среднем делает 10 ошибок, а на языке У — 5 ошибок, то это вина языка Х». Я специально не упоминал JS. Потому что мое утверждение применимо к любой комбинации Х и У.
itemPrice = api.requestPrice(item)
chargePrice = itemPrice + COMMISSION
Проект проклят ровно с момента, когда кто-то решил использовать для финансовых вычислений язык, в котором itemPrice теоретически может оказаться чем угодно, и в самом лучшем случае — float'ом.
Валидные математические операции над разнородными объектами и применяемый при этом тупой автокастинг — существенный минус языка, непонятно зачем задизайненный изначально.
Можно попробовать соответствующие библиотеки — bignumber.js и decimal.js
Они и эксепшен бросят, и ошибки округления постараются не допустить.
Вы так делаете в коде на реальных проектах? Вы — говнокодер.
Так это как? Суммирую две переменных? Да это часто люди делают в своих проектах. И в других языках такого дикого неявного приведения типов почти нет, что очень помогает.
Но ведь заставляют использовать, потому что оно происходит автоматически. Если там получилось, что в функцию попадает строка, вместо числа, то в таком случае мне нужно везде ставить проверки.
Зачем вообще нужно такое отбитое поведение? Можете привести хотя бы один кейс, где оно реально было бы полезно?
Где была асихнронная функциональность в других языках в том виде, в котором она была популяризирована Node.js?
В C# была как на клиенте так и на сервере (async/await). А без async/await — дык любой делегат можно было вызвать асинхронно где-то с .NET 2.0 (Это за 10 лет до появления nodejs, если что). В плюсах была (boost::asio).
Пруфы на то, что в случае с JavaScript это так? Статистика использования, сравнение одинаковых проектов на разных языках, замеры? Ах да, это же «всем очевидные вещи».
Когда человек для настолько очевидных утверждений начинает требовать "статистику и пруфы" — что-то с его пониманием субъекта обсуждения не так.
Что за такой клиент на C#?
Вы серьезно? WPF, WinForms, Xamarin, консоль… Я сказал "клиент" потому что некоторые из собравшихся ошибочно полагают что на C# можно писать только backend.
Нет «очевидных» вещей.
Очевидные вещи есть. Дышать — хорошо, не дышать — плохо. Типизация — хорошо, отсутствие типизации — плохо. Наличие стандартов и регламентов — хорошо, хаос и беспорядок — плохо. И любое "плохо" — оно не с потолка берется. Если у вас в коде хаос и беспорядок — очевидно что вы будете больше времени тратить на то, чтобы разобраться где что лежит и дописать требуемое. Если компилятор не проверяет для вас типы данных — значит у вас есть риск столкнуться рано или поздно с рантайм-ошибкой (если конечно у вас у самого в голове нет пары плашек RAM и мощного процессора). И это — печальные факты окружающей действительности. Следовательно, для того чтобы понять, что в решениях, оформленных на языке без контроля типов и дозволенным хаосом будет больше багов и они будут хуже поддерживаться — статистика не нужна. Для этого достаточно проанализировать факты и сделать выводы. Если несмотря на это, вы требуете от оппонента статистического анализа — то вы или знаете далеко не все факты, что идентифицирует вас как новичка в вопросе, или же вы не умеете делать логические выводы, что идентифицирует вас как человека откровенно глуповатого для профессии разработчика.
Простите, я правильно понял, у вас львиная доля багов в коде происходит из-за вычитания строк из чисел?
Из суммирования переменных, без предварительного приведения их к числовому типу. Вот, например, достал я из XML-ки значение, и мне нужно прибавить его к некоторой переменной.
accumulator +=+ valueFromXML;
Если второй плюсик забыть — будет неприятность.
Конечно, это привычно. Конечно, это не вызывает особых затруднений. Но если задуматься, если бы второй операнд всегда приводился к первому — было бы удобнее.
const o = {};
o.a = 5;
Работает без проблем. Хотя переназначить o естественно нельзя, очень даже предсказуемое поведение, если знать типы данных.
Нет такого принципа
Правило наименьшего удивления
Что простите?
Есть даже целый язык, который следует этому принципу.
А JavaScript уже обогнал Java по популярности или хотя бы сравнялся с ней
Может хватит уже может сравнивать проекты на JS и на Java?
Если вы считаете за использование различные куски кода, для добавления «динамики» веб страницам, то это не стоит сравнивать с программами на Java, которые совсем не для этого и не могут быть такими простыми.
Почему Node.js используется в крупных и серьезных проектах реже чем та же Java?
Может потому что в ней легко отстрелить себе ногу?
А в биллинговых системах (например), крайне важна надежность?
— Jenkins
— Jira
— Eclipse
— NetBeans
— Intellij
Ну и Java окопалась в мобильной разработке (хотя вроде как ее двигает Kotlin).
И немного про Highload.
Я не Java-разработчик и уж тем более Java-евангелист, так что не могу похвастаться знаниями проектов на данном языке.
Но судя по вашим требованиям пруфов по любому вопросу, вы очень активно пользуетесь «презумпцией невиновности» языка.
Однако это не значит что JS хорош :-)
Что из этого нельзя написать на JavaScript? Да нет тут такого. Более того, пишут и успешно. Те же ребята из Wrike и команды Visual Studio Code.
Конечно можно.
Вот только насколько можно будет сравнивать полученные проекты по надежности или скорости и удобству разработки?
Крупные проекты типа Идеи давно уже написаны, и аналогов им нет не только на JavaScript, но и на других языках особо не наблюдается. Потому что не в языке тут дело.
Visual Studio достойный тяжеловес, по моему на Сишке или на одном из отростков.
Но это не точно.
Вы сами выше упомянули про VS Code, он написан на Electron (кстати Atom на нем же, и собственно атомом я пользуюсь и очень доволен).
Но это лишь один пример, другие, достойные вряд ли есть.
Вообщем как раз таки в языке дело, насколько он подходит под определенные задачи.
Я не говорил, что JavaScript хорош. Я говорю, что это нормальны язык программирования, и большинство предъявляемых ему претензий происходят от незнания.
Незнание в большей степени исходит из-за непонимания некоторых вещей, которые в других языках совсем иначе выглядят.
Мне например, как JavaScript разработчику, который столкнулся с Java после, а не до изучения JavaScript, удивительна работа this там
Дело в том, что также как в Java и в других языках (C# как минимум), а JS во многих вопросах единственный в своем роде: стоит в сторонке и ссыт против ветра.
Хочешь пиши в JS на ООП
Но нет многих конструкций interface и trait/mixin, да и классы недавно появились (в их обычном представлении).
В js прототипное наследование, не такое как у всех.
Хочешь пиши в JS в функциональном стиле
Тут вроде ок, но опять таки если сравнивать с TRUE функциональными языками (lisp, prolog, ...) js не чисто функциональный, и отличается от них.
То есть откуда бы не пришел человек, он будет ловить много WATов достаточно продолжительное время, прежде чем начнет делать все как надо.
Я говорю, что это нормальны язык программирования
Что такое «нормальный»? Какая метрика нормальности? Если нормальный — это на нем пилят рабочие проекты, то конечно нормальный. Если нормальный — это снижение выстрелов в ногу, то очень ненормальный.
большинство предъявляемых ему претензий происходят от незнания.
Вы издеваетесь? Большинство претензий к нему как раз от знания чего-то за пределами JS. А большинство аргументов в защиту (по крайней мере на хабре) именно от ограниченного кругозора.
«Я пишу только на JS и у меня все хорошо.»
«Пишите правильно, тогда ошибок не будет.»
«Во всех проблемах виноваты плохие программисты, я проблем не замечаю.»
«Язык не умеет Х, потому что это не нужно.»
«Что-то работает криво, но это описано в спецификации, значит все ок.»
«Раньше было еще хуже, скажите спасибо что язык развивается»
Ни один из указанных проектов не написан на javascript. VS code написан как и Atom на coffeescript, а wrike используют dart.
CoffeeScript это такой же «язык» как и TypeScipt.
А написаны данные IDE на Electrone.
Тут подробнее.
А то как то страшно немного становится.
Видимо такие люди потом создают вакансии «Требуется CoffeeScript-разработчик»
Ну а вообще ничего постыдного в такой вакансии нет.
Ведь если вся команда пишет на Coffie, то они вряд ли будут искать JS разработчика.
Или мол и так выучит, нормально?
или «Electron-разработчик».
А я разве писал что Electron это язык?
По вашей логике .NET язык?
Грустно товарищи, грустно когда не знаешь к чему прицепиться((((
atom да, но не vscode — там ts/js
Node.js успешно применяется в энтепрайз веб разработке, как просто для приготовления моделей для фронтенда, так и для сложнейших высоконагруженных систем — пруфы надо
Естественно, да!
JavaScript сам по себе монополист на клиенте, давайте сравним… кстати с чем, с GWT? Кстати, где он? Пруфы надо?
И тут определенно да.
Вот только еще стоит оговориться: JS монополист на клиенте потому что нет альтернатив.
Так что JS будет в любом случае лучшим выбором, как бы лютым дерьмом он не был, лишь только потому, что нет альтернатив.
Ну а вообще есть TypeScript, CoffieScript,… которые, хоть и впоследствии компилируются в JS, но не являются JS в полной мере.
Другой синтаксис, другие конструкции.
Так что это как раз таки можно рассматривать, как альтернативы Native JS.
И поэтому каким таким монополистом он является?
Являются, в полной мере, TypeScript к примеру надмножество JavaScript. А CoffeeScript — вы серьезно? Хотя бы Dart или Elm привели бы в пример, вот как раз по их объему использования и динамике роста статистика вполне общедоступна.
Как раз НАДмножеством, т.е. расширяет нативные возможности языка.
Как по мне, это вполне можно считать другим языком, т.к. языковые конструкции другие/новые.
Но а если вернуться к пруфам, то:
Язык программи́рования — формальный язык, предназначенный для записи компьютерных программ
TypeScript имеет свой синтаксис, поэтому его вполне можно назвать ЯП.
Если не заглядывать под капот (то что TS в итоге компилируется в JS), то можно провести аналогию между C# и C++, или C# и Java.
Синтаксис похожий, все друг у друга заимствуют конструкции и синтаксис.
По вашей логике C# это НАДстройка над C++, или я не прав?
Для меня, для моих коллег кого я знаю, которые занимаются тем же самым — это не отдельный язык программирования. А раз это лишь вопрос формулировок, то предлагаю особо и не спорить, какая разница.
Это получается демагогия немного) JavaScript не поддерживает написание DSL, а значит TypeScript — не его часть. И это довольно важно, так как показывает, что сам по себе javascript очень сильно не тянет для больших компаний.
Это обсуждение любопытно тем, что уважаемый Synoptic в одном месте под предметом обсуждения подразумевает собственно JavaScript, а в другом — множество языков, включающее TypeScript.
Такое мышление сильно напоминает поведение this в JavaScript, из чего можно сделать предположение, что Synoptic — бот, написанный на JS.
Однако, если это предположение неверно, имеем две других возможности:
1) JS подходит людям с определенным складом мышления;
2) либо же взаимодействие с JS воздействует определенным образом на мозг, меняя мышление человека.
Второе из них пугает, ведь в таком случае, время от времени используя JS, следует опасаться негативных воздействий на логику. Сигналами могут быть подмена контекста обсуждения (this), изменение значений терминов (const) по ходу беседы, успешные операции сложения килограммов с вольтами.
Это предположение требует дополнительных исследований, однако будем осторожны уже сейчас, не дожидаясь предупреждений Минздрава о вреде JS!
С уважением, ваш DC-4C5866
Первая ссылка в гугле
Там всего лишь перечислены компании, которые используют nodejs в production-е. Если у MS крутится лендинг из трех страниц на ноде и собирает фидбеки от пользователей — я не удивлюсь. Вопрос был про готовые enterprise-проекты, а не про "вот эти люди когда-то скачали ноду".
крупных энтерпрайз-проектов целиком на одном языке не бывает, что там всегда туча подмодулей и каждый пишется на том, что больше подходит.
Вот именно. И если ноде в этой куче подсистем отведено место сборочного инструмента, или же сервера для лендингов ну или она просто сидит и куда-то копирует файлы — то ваш восторг сильно преувеличен.
Не стал бы делать таких громких заявлений, можно подождать и посмотреть пока язык еще более стабилизируется и обрастет необходимыми фреймворками. Глядишь, окажется что и биллинг вполне можно написать.
Отлично-отлично.
А сколько ждать?
Автор статьи тут утверждает что 10 лет язык не менялся и это круто.
Так какие перспективы?
Понятия не имею, как и вы о том, что этого не случится.
Но нет и довыдов что это случиться.
Пока не видел тут статей от тех, кто пытался написать на нем биллинг и не получилось. Появится — почитаю.
То что нет статей о том «как мы пытались поднять биллинг и не получилось», может говорить также о том что никто просто этим и не занимается, нет?
Все больше и больше убеждаюсь что JS это какой-то язык Шрединегра))))))
Не стал бы делать таких громких заявлений, можно подождать и посмотреть пока язык еще более стабилизируется и обрастет необходимыми фреймворками. Глядишь, окажется что и биллинг вполне можно написать.
не обрастет. и не во фреймворках дело.
дело в прогнозируемости результата, в динамической типизации, и как следствие этого всего — низкая скорость рефакторинга.
все это — заложено by dezign.
кроме того, что бы js оброс такими фичами как аннотации в java и системой метаданных, что бы с объекты в базу данных запихивать с теми же фичами и удобством как это делается в jpa, или можно было тот же xml ваять, так же удобно и просто (с валидацией, кстати) как это делается с jaxb или simple xml framework… для этого js должен перестать быть джава скриптом.
оставьте эту роль догоняющего сишарпу ;) у него много чего появилось, но пока и он не тянет и половины только что перечисленного.
Почему я не могу применить тот же аргумент к Java?Потому что ваш аргумент субъективный: «мне, как js-разработчику, удивительна работа this в Java». Подсказываю, он начинается со слова «мне».
Вы про const так и не ответили, а уже на this в Java перескакиваете.
Кстати, тот же const в Java называется final. Делает то же самое, но соответствует POLA.
const, между прочим, в других языках обычно как раз означает неизменяемую сущность, а не неизменяемую ссылку. Потому что когда программисты говорят о константах, они обычно заинтересованы именно в первом.
удивительна работа this там.
А что в ней удивительного? Что this не меняет туда-сюда контекст?
А JavaScript уже обогнал Java по популярности или хотя бы сравнялся с ней.
О, ещё один житель другой планеты.
Вы видимо с Альфа-Центавры?
На планете Земля на 1 месте — Java а JavaScript — на восьмом.
https://insights.stackoverflow.com/survey/2017#most-popular-technologies
PS. я думаю, это то ребята не с центавры?
Лучше смотреть на кол-во вакансий или профили разработчиков.
Я например поискал по skill на angellist:
Java: 267,012
JavaScript: 247,781
Думаю это ближе к истине. Хотя тут тоже стоит учитывать, что многие Java разработчики знают JavaScript, а вот обратное обычно не верно.
Это же статы от stackoverflow. Мне кажется, что если собрать статистику "по какой технологии люди больше всего задают вопросов" — это будет ни разу не "какой технологией люди больше всего пользуются". Если JavaScript лидирует по количеству задаваемых на stackoverflow вопросов, то я вам доложу что что-то не так с этим языком :)
Рейтинг популярности вот: https://www.tiobe.com/tiobe-index/
(на правах шутки) :)
Причина по которой JavaScript стал таким популярным (кроме монополии в веб) — его демократичность
Основная причина только одна — это монополия на web. Не было бы этой монополии, такие штуки как nodejs вообще бы никогда бы не появились, а javascript умер бы в конце нулевых.
Ну и как многие уже написали — javascript очень кривой сам по себе и тысячи попыток исправить это лишь доказывают то, как он плох. Но пока он един в качестве веб-скриптового стандарта, эта боль компаний будет продолжатся.
Больше даже бесит не его кривость, она то как раз нивелируется языками-заменами (раз уж браузеры больше ничего не понимают) — typescript, purescript, elm, clojurescript и так далее, а тем, что, чем "дальше" от родного js, тем выше риски по найму, и, соответственно, нельзя просто так взять и обучить команду, например, purescript, так как разработка проекта на этой команде и кончится.
То есть как бы вот оно перед носом, бери не хочу, только протянуть руку. Но нет, нельзя, ни один менеджер в зравом уме не позволит вести проект на purescript.
Вопрос 11: const ( который на самом деле НЕ const )
Не знаю, почему вы так решили. Моя простая проверка в консоли показала обратное:
Скорее всего поэтому:
const a = [1,2]
a.push(3)
console.log(a);
[1, 2, 3]
Автор не понимает о чем говорит. Пустая спекуляция, но вероятно других языков не знает и серьёзных проектов не делал. Теория ЯП прошла мимо в институте, если была. Javascript как язык г-но, не потому что слабая типизация, не потому что eval, или ещё что-то. А потому что базовые принципы непоследовательны. Очень тяжело думать на javascript. Очень тяжело гонять код на javascript в интерпретаторе, встроенном в мозг. И наконец, более-менее сложная архитектура на javascript не поддается изменению, проще переписать, чем поменять. Это я на личном опыте утверждаю, а не абстрактно. На секундочку, пишу на C++, Python, Php, Haskell, Go, VB, asm, ну и на js конечно (хотя больше на ts), и именно как язык хуже js пожалуй разве что vba, который в офис встроен, да и то спорно. Если совсем копать, то bash ещё ужасен. Но на нем не пишут северное ПО. И клиентское тоже не пишут. Так, скрипты мелкие в основном.
Вот эти мелкие скрипты на баш в серверном ПО иногда и вызывают rm -rf "$path_I_failed_to_set/*”
set -euo pipefail
и shellcheck
в помощь, без этого долгоживущие переиспользуемые скрипты на баше писать вредно
Вводит в заблуждение приставка Script и несерьёзный имидж языка, а на деле обнаруживается, что язык применяется от front-end и back-end до дескопных и мобильных приложений, программирования интегральных микросхем, обработки видео и в множестве других сфер.
Do tell me all about it.
Большая часть интегральных микросхем высечены в кремнии и не программируются вообще. Варианты, когда nodejs запускается на микрокомпьютере (raspberry pi и подобное) — это обыкновенный nodejs на обыкновенном linux'е. Промежуточный вариант (микроконтроллеры) — только запуск сильно урезанного варианта на старших моделях без всяких библиотек из nodejs, т. к. нет ОС, нет всяких примитивов типа файлов, сетевых сокетов и т. п. В теории можно написать слой совместимости, удовлетворяющий nodejs и вместить его на имеющийся 1-2 MiB ROM, но сделать на этом что-либо полезное уже не получится.
Про другие сферы типа обработки видео тоже хочется услышать. Желательно, чтобы там не вызывался сишный/плюсовый кодек, а тупая обвязка была на js. Ибо иначе — это простой маркетинговый буллшит.
Посмотрите хотя бы на Haskell с его монадами и функторами (очень мощные штуки, кстати. В JS тоже используются, в jQuery).
Ничего себе, а где можно посмотреть на монады в jQuery?
UPD: в статье JavaScript как мыслевирус pnovikov оскорбил всё сообщество JavaScript, назвав их фанатиками.
JavaScript пока не канонизирован православной церковью, чтобы так оскорбляться в ответ на вполне невинную статью, да ещё и не лишённую справедливости. Немного самоиронии не помешало ещё ни одному сообществу.
Как вы считаете, это этично?
Считаю, что вы этой припиской только подтвердили исходный тезис о мыслевирусе.
Мне вот не нравятся плюсы по ряду объективных лично сформированных причин, но это не означает, что я сиюминутно должен броситься стряпать статью «C++ как мыслевирус». Я просто не пишу на нем без явной на то необходимости. Что, ящщитаю, логично. Или, например, шарп. Я пишу на нем, но могу сформировать ряд неловких вопросов к профильным дотнеттерам. Но зачем? Практически на любом языке можно написать требуемый тебе функционал, но практически во всех этих случаев найдётся язык, в котором этот функционал написать проще и правильнее; и практически всегда обратное. Нет универсального языка. И это не повод усомниться в чужом интеллекте просто потому, что свой не способен воспринять другой стиль программирования.
PS: И, да, я бы хотел почитать мнение автора той статьи о Аде, Форте или Фортране. Ну так, чисто для себя, поржать…
Зачем вам нужна многопоточность?
Чтобы использовать железо более эффективно и делать больше CPU-bound задач в единицу времени. Если вы пишите бложик для 100 пользователей, то да, вам это ни к чему. Откройте для себя разницу между Concurrency и Parallelism.
не делайте логических ошибок. Ваши ошибки — не вина языка
При работе с любой средой важнее не то, что происходит, когда ошибок нет, а то, что происходит при наличии этих самых ошибок.
Это общая проблема всех интерпретируемых языков с eval, и отказываться от этой мощи ради возможности ловить 5% самых глупых ошибок — сомнительная идея.
Скорее наоборт: сомнительная идея иметь eval ради того 0.001% случаев, где он полезен (смелое предположение, ни разу не находил eval полезного применения), если это ломает статический анализатор, способный мгновенно поймать 99% глупых ошибок. Правда, на самом деле eval тут не при чём.
Скажете asm не странный? А Lisp?
В Lisp как раз с типами всё хорошо. Я частенько читаю спеки Common Lisp, удивляюсь, насколько всё-таки умные люди над ним работали. Он, конечно, далеко не идеален, но по сравнению с лиспом современный js выглядит как поделка из шишек и клея.
А типы в JavaScript не слабые, их принципиально нет (кроме примитивных).
Это предложение лишено всякого смысла.
С типами знакомо 100% программистов, закончивших любой технический ВУЗ
На картинке (которая, к слову, не моя) речь идёт не о "типах" а о "теории типов". Разница примерная такая же, как "быть знакомым с числами" и "быть знакомым с теорией чисел". Для первого достаточно закончить 3 класса школы, для второго нужна более серьёзная подготовка. Так что ваша фраза не опровергает, а лишний раз подтверждает справедливость изображения.
Вы знаете, к примеру, что такое параметрический и ad-hoc полиморфизм? Типы-суммы и типы-произведения?
Зависимые типы? Линейные типы? Фантомные типы? Структурная типизация? Что такое Hindley-Milner System и System F?
Не язык определяет тебя, а ты определяешь язык ©
JavaScript как праздник