что значит нет? + это ппрегруженеый оператор конкатенации. парсер видит левый токен с типом данных строка и неявно приводит все остальное к строке.
в чем проблема? в женской логике, "ну я же подразумеваю другое"?
Настолько очевидно, что мимокрокодил никогда не предугадал бы такой порядок сортировки, а для понимания нужно иметь специальные знания. Очевидно, блядь, на хуй иди.
Ага. Сделать нихуя не логичное поведение в языке, из-за чего заставлять всех читать доку по, казалось бы, элементарным операциям, это вот как раз очень по-джаваскриптовски. Именно за это жскрипт и не любят.
Нет. Ты в коде явно задаешь массив только чисел. Система вывода типов нормального языка, например, скалы, выведет тип коллекции как минимальный общий для всех элементов(в данном случае, интежер), и, естественно, при вызове метода сортировки, применит компа для этого типа по-умолчанию, а для инта это математическое сравнение.
Как работает вывод типов в жскрипте - это полный пц.
Нет, тип элементов выводится при компиляции. Компилятор, естественно, чекает все обращения к объекту, в данном случае типы элементов при создании массива.
А тут-то в массив в любой момент можно добавить всё, что угодно. И это не заставить интерпретатор внезапно конвертировать массив из массива интов в массив вариеблов каких-нить.
Так что сравнивать надо именно с массивом, в который в любой момент можно добавить всё, что угодно.
Ситуация несколько шире. Метод sort принимает в качестве параметра функцию-компаратор. Если компаратор не указан явно, используется компаратор алфавитного порядка. https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Global_Objects/Array/sort
Если включить голову, то сразу должен возникнуть вопрос, как будет работать сортировка, если не указан компаратор. В js массивы гетерогенные, т.е. могут содержать объекты разных типов. Как их сравнивать?
То, что у программиста не возникло подозрений при использование сортировки без какого-либо указания способа сравнения элементов, говорит о его низкой квалификации и непонимании базовых основ информатики
Ну скажем в нормальном ООП языке программирования есть такое понятие, как перегрузки => пришедший из какого-нибудь C# подумает, что вызовется перегрузка метода с нужным типом => будет сортировка интов, а не строк.
Собственно JS является ООП языком программирования. А то, что все приводится к строкам и потом сортируется- это неочевидная хрень и не понятно зачем вообще иметь такую дефолтную сортировку, если она заведомо в 90% случаев не та, которая нужна.
В C# статическая типизация. Это значит, что объявляя массив, компилятор потребует явно или косвенно указать тип элементов массива. Причем все элементы должны принадлежать к этому типу. Поэтому перегрузка оператор сравнения (компаратор) будет работать. Например,
List myList = new List();
В последней строке метод Sort, зная тип элементов массива, попытается привести их к типу Comparable. А так как строки наследуются от Coparable, у него это получится.
В JS массивы могут содержать объекты произвольного типа. Причем заранее может быть неизвестно какие элементы окажутся в массиве.
Ты мне лучше скажи, чем динамическая типизация лучше статической и почему JS пошел этим путем? Лично я не вижу в ней достоинств кроме того, что можно поговнокодить. По идее, раз ты делашь сайт => тебе известны все модели с которыми ты будешь работать => ты можешь сделать конкретные типы.
Сам по себе вопрос "чем динамическая типизация лучше статической" с явным оттенком пренебрежения по отношению к динамической типизации выдает в Вас новичка. Это все равно что задаться вопросом "чем спорткар лучше вездехода". Профессионал понимает, что ответ зависит от контекста использования. Динамическая типизация, например, упрощает написание несложных программ (скриптов). Внезапно JS - это сокращение от JavaScript. JS создавался в те времена, когда выкачать mp3-шную песню в 4 МБ размером из Интернета было победой. Так же он должен быть настолько простым, чтобы его могли начать использовать web-дизайнеры с минимальными навыками в программировании. Основной функционал сайта обеспечивался элементами html (верстка и формы). Скрипты использовались для вспомогательных целей (падающие снежинки и все такое). Поэтому JS известен проглатыванием ошибок. Ну сломались снежинки, ну не блокировать же работу сайта из-за этого!?
Так же замечу, что огромное сообщество программистов на языках с динамической типизацией Python, Ruby, PHP, прости Господи, не согласятся с Вашим мнением. В web-программировании как правило имеет место работа с некой СУБД. Результат запросов к реляционным БД имеют вид гетерогенных массивов значений. Динамическая типизация здесь весьма кстати. Динамически типизированный Python благодаря библиотеке SciPy так же очень популярен в научной среде. Так как позволяет сконцентрироваться именно на прикладной части, а не на аспектах программирования. Тот же Python широко применяется в системных утилитах Linux. Он мне попадался даже в отладчике gdb.
Опираясь на многолетний опыт программирования на языках как статической типизации (C++, Java), так и динамической (Python, JS), ответственно утверждаю: Количество говнокода в большей степени зависит от кривизны рук разраба, нежели от языка.
'Сам по себе вопрос "чем динамическая типизация лучше статической" с явным оттенком пренебрежения по отношению к динамической типизации выдает в Вас новичка.'
Я попросил привести пример того, где статика не справится со своей задачей. Я привел аргумент в пользу статики "Зачем мне динамика, если строя сайт я знаю модели с которыми я буду работать?".
'В web-программировании как правило имеет место работа с некой СУБД. Результат запросов к реляционным БД имеют вид гетерогенных массивов значений. Динамическая типизация здесь весьма кстати.'
Опять же, тебе заранее известны запросы, которые ты посылаешь к СУБД. Что тебе мешает обернуть все в типизированные модели?
'Поэтому JS известен проглатыванием ошибок. Ну сломались снежинки, ну не блокировать же работу сайта из-за этого!?'
Ну так проглатывать ошибки можно в явном виде. В любом другом язык, ты для подобного поведения в критические места try/catch можешь повесить.
'Ну сломались снежинки, ну не блокировать же работу сайта из-за этого!?'
Если бы это были только снежинки. Сейчас JS чего только не повесили =>поломка скрипта приведет сайт в полурабочее состояние.
Строго говоря, в шарпе и прочих, технически, массив точно так же может содержать объекты любого ссылочного типа(а вот в с/с++ - нет, там попытка записать в коллекцию объект другого типа приведет к непредсказуемым результатам). Но в шарпе, жабе, и прочих, есть шаблоны и типы у коллекций, в том числе и у массива. Это метаинфа на уровне компиляции, т. е. кода. Компилятор выбирает для статик массива минимальный общий тип. И применяет все операции уже к нему.
А вот в жскрипте типа у коллекций нет, и это полная ж. Хотя с типизацией у жскрипта вообще пиздец.
Также как в свое время в ПэХаПе ломанулось куча народу, так и в джаваскрипт ломанулись. И теперь уже куча js-макак никак не осилят правила сортировки и им разрывает шаблоны от некоторых конструкций.
На жабоскрипт возрос спрос, туда ломанулась куча макак, которые делают говнокод для этих ваших браузеров, который заставляет их рыдать, как сучек. А жабоскрипт - идеальный язык, чтобы ебашить самый лютый говнокод. Он настолько нестрогий, что даже по сравнению с ним самый последний анон строг, как твоя училка Марья Петровна. Динамическая нестрогая типизация позволяет творить абсолютно любую хуйню, складывать числа со строками, числа с массивами, строки с объектами, передавать в функцию совершенно не то, что она ожидает. Ты можешь обращаться к несуществующим полям объектов или вовсе необъявленным переменным, получая ебучий undefined вместо ошибки. В итоге вся эта хуйня позволяет стрелять в ногу со скоростью овер 9000 раз в секунду, не получая никаких ошибок компиляции, потому что это - интерпретируемый язык, сучки. Если ты накосячил, оно может упадет сразу, а может проработает кучу времени, прежде чем упасть, и хер ты узнаешь заранее.
Этот язык в чистом виде ни на что, кроме как рулить домом не годен, все это уже поняли и придумали typescript(но мне тоже не нравится, но скорее всего потому что я долбоёб)
1) Нахера один язык подо всё? Вроде бы давно уже все выяснили, что для разных задач разные языки подходят лучше
2) Для всего, кроме браузеров - C/C++. Хотя даже в браузеры, если WebAssembly. Но да, я хардкорен
3) Как частично эмбедер я имею нехилый бугурт по поводу пихания JS в микроконтроллеры. Это просто пиздец.
Ох. Я видел "кровавый энтерпрайз" на плюсах. И очень хочу развидеть.
Поверь, ты не захочешь жить в мире, где все, кроме веба, на плюсах. Потому что в этом мире у тебя не будет и тени уверенности вообще в чем-либо.
JS популярный и востребованный язык, кроме того он очень легок в освоении. Практически любой анончик с интеллектом чуть выше среднего может освоить элементарные навыки JS за пару месяцев, и клепать гавно скриптики на фрилансе, зарабатывая при этом 1-2 k баксов в месяц. Именно от этого люто бомбят пердаки у супер тру гик-кодеров, которые учились кодить еще в 1993-м на паскале, знают 20 никому не нужных и забытых языков, и работают наладчиками ЧПУ станков из Чехословакии на местном заборостроительном комбинате, но работают "на настоящем языке программирования, а не на этом вашем тупом говне для школоты"
Ну да, погорячился, просто у меня незажившая боль от эпохи когда ie был еще стронг и новые стандарты только начали внедряться, в 2018м писать как-то иначе конечно не нужно
Причем тут es6? Можно бы написать так:
[10,9,8,7,6,5,4,3,2,1,0].sort( function(a, b){return a -b;} );
Суть в том, что сортировать можно только объекты, над которыми определена операция сравнения. Это базовые знания информатики. В js массивы могу содержать объекты любого типа. Поэтому способ сравнения элементов нельзя определить по типу элементов. Следовательно необходимо указать компаратор явно. Однако мы видим, что sort работает и без явно указанного компаратора. Отсюда вывод - существует компаратор по-умолчании. Здесь должно возникнуть желание почитать документацию. https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Global_Objects/Array/sort
Как раз таки нет. А все потому что в это языке сатаны все числа это double(класс Number). То есть если ты хочешь !ТОЧНУЮ! 64 битную целочисленную арифметику, то тебе придется как всегда качать стороннюю библиотеку (А js'еры ещё и хвастаются как много у них библиотек. Их много потому что сам язык нихера не может)
Именно этих - нету. Арифметика целых чисел в java строгая.
Для флоатов подобные ошибки норма просто из-за их двоичного представления. Поэтому любой нормальный девелопер знает, что флоаты нельзя использовать для точных вычислений, например, для подсчета денег(нужно использовать целые плюс порядок).
Но в js, как обычно, все через жопу, и для представления целых чисел используются неточные флоаты...
На самом деле JS вполне себе удобный язык, ну да нестрогая типизация это конечно чаще плохо, чем хорошо, но на самом деле в реальной работе все эти мемные операции сложения чисел со строками и шишек с елками встречаются не так часто
Немножко не так. В реальной работе НЕОБХОДИМОСТЬ сложения шишек с ёлками встречается не так часто, а вот само сложение в результате невнимательности попадает в код чаще, чем нужно, и до поры до времени остаётся там незамеченным.
Сам использую scalajs, там статическая типизация.
Саске сунул руку в штаны Наруто и усмехнулся, когда блондин застонал от его прикосновения. - Уже, Наруто? Спросил он
Извините, не тот чат
Я по поводу вакансии ]э-программиста
Введите сообщение и нажмите Enter
'5'+3 = '53'
'5'-3 = 2
в чем проблема? в женской логике, "ну я же подразумеваю другое"?
Как работает вывод типов в жскрипте - это полный пц.
А тут-то в массив в любой момент можно добавить всё, что угодно. И это не заставить интерпретатор внезапно конвертировать массив из массива интов в массив вариеблов каких-нить.
Так что сравнивать надо именно с массивом, в который в любой момент можно добавить всё, что угодно.
Если включить голову, то сразу должен возникнуть вопрос, как будет работать сортировка, если не указан компаратор. В js массивы гетерогенные, т.е. могут содержать объекты разных типов. Как их сравнивать?
То, что у программиста не возникло подозрений при использование сортировки без какого-либо указания способа сравнения элементов, говорит о его низкой квалификации и непонимании базовых основ информатики
Собственно JS является ООП языком программирования. А то, что все приводится к строкам и потом сортируется- это неочевидная хрень и не понятно зачем вообще иметь такую дефолтную сортировку, если она заведомо в 90% случаев не та, которая нужна.
List myList = new List();
myList.Add("a");
myList.Add("z");
myList.Add("g");
myList.Sort(); // ["a", "g", "z"]
В последней строке метод Sort, зная тип элементов массива, попытается привести их к типу Comparable. А так как строки наследуются от Coparable, у него это получится.
В JS массивы могут содержать объекты произвольного типа. Причем заранее может быть неизвестно какие элементы окажутся в массиве.
Так же замечу, что огромное сообщество программистов на языках с динамической типизацией Python, Ruby, PHP, прости Господи, не согласятся с Вашим мнением. В web-программировании как правило имеет место работа с некой СУБД. Результат запросов к реляционным БД имеют вид гетерогенных массивов значений. Динамическая типизация здесь весьма кстати. Динамически типизированный Python благодаря библиотеке SciPy так же очень популярен в научной среде. Так как позволяет сконцентрироваться именно на прикладной части, а не на аспектах программирования. Тот же Python широко применяется в системных утилитах Linux. Он мне попадался даже в отладчике gdb.
Опираясь на многолетний опыт программирования на языках как статической типизации (C++, Java), так и динамической (Python, JS), ответственно утверждаю: Количество говнокода в большей степени зависит от кривизны рук разраба, нежели от языка.
Я попросил привести пример того, где статика не справится со своей задачей. Я привел аргумент в пользу статики "Зачем мне динамика, если строя сайт я знаю модели с которыми я буду работать?".
'В web-программировании как правило имеет место работа с некой СУБД. Результат запросов к реляционным БД имеют вид гетерогенных массивов значений. Динамическая типизация здесь весьма кстати.'
Опять же, тебе заранее известны запросы, которые ты посылаешь к СУБД. Что тебе мешает обернуть все в типизированные модели?
'Поэтому JS известен проглатыванием ошибок. Ну сломались снежинки, ну не блокировать же работу сайта из-за этого!?'
Ну так проглатывать ошибки можно в явном виде. В любом другом язык, ты для подобного поведения в критические места try/catch можешь повесить.
Если бы это были только снежинки. Сейчас JS чего только не повесили =>поломка скрипта приведет сайт в полурабочее состояние.
А вот в жскрипте типа у коллекций нет, и это полная ж. Хотя с типизацией у жскрипта вообще пиздец.
2) Для всего, кроме браузеров - C/C++. Хотя даже в браузеры, если WebAssembly. Но да, я хардкорен
3) Как частично эмбедер я имею нехилый бугурт по поводу пихания JS в микроконтроллеры. Это просто пиздец.
Поверь, ты не захочешь жить в мире, где все, кроме веба, на плюсах. Потому что в этом мире у тебя не будет и тени уверенности вообще в чем-либо.
Ясно понятно
Вот поэтому js и не любят, потому что это нагромождение костылей из костылей с костылями
Т.е. надо использовать ES3?
[10,9,8,7,6,5,4,3,2,1,0].sort( function(a, b){return a -b;} );
Суть в том, что сортировать можно только объекты, над которыми определена операция сравнения. Это базовые знания информатики. В js массивы могу содержать объекты любого типа. Поэтому способ сравнения элементов нельзя определить по типу элементов. Следовательно необходимо указать компаратор явно. Однако мы видим, что sort работает и без явно указанного компаратора. Отсюда вывод - существует компаратор по-умолчании. Здесь должно возникнуть желание почитать документацию.
https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Global_Objects/Array/sort
9999999999999999 // -> 10000000000000000
10000000000000000 + 1 // -> 10000000000000000
10000000000000000 + 1.1 // -> 10000000000000002
С этого в своё время долго ржал
0.1 + 0.2 // -> 0.30000000000000004
https://en.m.wikipedia.org/wiki/Machine_epsilon
https://ru.m.wikipedia.org/wiki/Машинный_ноль
Java - это достаточно мощный язык со статической типизацией, синтаксически выросший из C++.
Для флоатов подобные ошибки норма просто из-за их двоичного представления. Поэтому любой нормальный девелопер знает, что флоаты нельзя использовать для точных вычислений, например, для подсчета денег(нужно использовать целые плюс порядок).
Но в js, как обычно, все через жопу, и для представления целых чисел используются неточные флоаты...
Сам использую scalajs, там статическая типизация.
' ' == 0 // истинно
при этом
'' == ' ' // ложно
Всё очевидно конечно, но выглядит как нарушение принципа транзитивности )
https://www.destroyallsoftware.com/talks/wat