Ну или можно пушкой жахнуть этого воробья:
const q=a=>a.length?[...q(a.slice(1).filter(e=>e<=a[0])),a[0],...q(a.slice(1).filter(e=>e>a[0]))]:[];
q([1,10,2,11])
@Suvitruf Что такое int'ы в языке с динамической типизацией? Типы эфемерны)
@yolosora Это да. Но они изолированы синтаксически. То есть, нестрогий код выглядит не так, как строгий. В JS единственный тип переменной — dynamic, что требует серьёзной дисциплины разработчиков.
В хорошо спроектированной системе необходимость в понижающем приведении (downcast'е) минимальна. Однако, существуют случаи, при которых он нужен. Вот несколько примеров. Обычная причина — слабость системы типов.
Представьте себе, что вы хотите запрограммировать класс с выделенным экземпляром. Н...
Вот так отображаются комментарии под ответом:
А на самом деле там вот так:
Почему в первом случае не отображается последний комментарий?
Давайте продолжим обсуждение в чате.
Вот так отображаются комментарии под ответом:
А на самом деле там вот так:
Почему в первом случае не отображается последний комментарий?
Давайте продолжим обсуждение в чате.
@VladD сугубо на личном опыте (поэтому приписал "кмк"), со статической типизацией много больше писанины и лишних конструкций/шаблонного кода, часто уход от изначально красивого замысла в сторону "как бы впихнуть в возможности языка" и т.п. Опять же при изменении исходных требований/входных данных -- в строгом варианте либо куча работы по переписыванию либо костыли с последующими мутными ошибками.
@VladD В динамике же гораздо быстрее адаптироваться к изменениям в процессе разработки (яркий пример - взрывной рост популярности безсхемной БД mongodb).
@VladimirGamalyan ну мне хотелось бы какой-то пример. С моей точки зрения строгая типизация как раз очень помогает при изменениях в коде, ведь если у вас передаётся один тип, а в реальности ожидается совсем другой, код просто не скомпилируется.
Если же типов нету, то у вас нету лёгкой возможности узнать, где вы уже поменяли код, а где он ещё старый.
@VladD в этом частном случае достаточно поставить на входе в ф-ию проверку типа (либо использовать возможности языка по проверке входных аргментов с помощью аннотаций или ещё чего похожего).
@VladimirGamalyan Не, популярность связана не с этим. Наоборот, стандартный объектно-ориентированный подход очень плохо ложится на реляционные базы данных. Например, в ООП если тип A владеет коллекцией экземплярв типа B, то знания этого не требуются в типе B. При реляционном подходе в тип B приходится класть внешний ключ на владеющий экземпляр типа A. Инкапсуляция, таким образом, полностью отсутствует. Документоориентированные базы данных куда ближе к объектно-ориентированному подходу.
@VladimirGamalyan Угу, вот это и называется строгой типизацией :)
@VladimirGamalyan Тесты на много порядков слабее проверки типов. Вы не сможете написать тесты на каждое присваивание, это большой overhead.
@NicolasChabanovsky Можете передать мне мой список банов? Мне сложно получить его самостоятельно, потому что придётся разгребать огромное количество почты.