Вы это мне отвечаете? Вы это лучше напишите человеку, который предложил формулу сравнения O(..) выше. Потому что константа играет в любом случае, есть O() или нет.
Вопрос: нужен ли водителю навык торможения ручником? Ответ рядового автомобилиста: наверное можно без него и обойтись, но было бы здорово это уметь. Но обязательно придет человек, который скажет, что если водитель не умеет в торможение с разворотом, то допускать до баранки его нельзя — имея ввиду дрифт, а другой человек, который всю жизнь на трамвае ездит пассажиром, вообще не поймет, зачем такое может понадобиться. К чему весь этот разговор, если в коментах каждый говорит о чем-то своем, а сам пост ни о чем и не дает никакой конкретики? Просто посраться на вечнохоливарную тему?
Думаю, здесь нельзя разделить на такой/нетакой кейс. Конечно, если говорить о кандово-математическом процессе создания алгоритмов, то думаю разработчик который не занимается этим непосредственно может и обойтись без таких знаний и умений. Однако, если говорить о представлении того как работают те алгоритмы и структуры, которыми ты пользуешься, то тут совсем другая ситуация. Потому что каждый раз используя что-то из стандартной библиотеки ты можешь сделать это осознанно, выбирая этот способ и понимая, что за собой это может повлечь, или просто потому что обычно делают так.
Думаю, разработчику очень полезно хорошо представлять как пишутся алгоритмы, какие бывают структуры, как они работают, наверное даже без нюансов реализации, т.е. ему не нужно уметь написать реализацию на листочке, но иметь представление важно для абстрактного представления как работает то, чем он пользуется. Для 80% (цифра взята из закона Парето) случаев вообще нечего такого не понадобится (по ощущению же это цифра еще больше, может быть 95% для рядовой разработки), но зато оставшиеся случаи потребуют от разработчика хорошего понимания как работают его инструменты, чтобы сделать правильно/быстро/разобраться с проблемой. Вот здесь-то непонимающий разработчик и потратит 80% своего времени (опять смотрим на Парето) — на что будет потрачено это время? 1) Разработчик всё-таки разберется как что устроено 2) будет пытаться обойти проблему в поисках на стековерфлоу рабочего решения. Как можно догадаться, первый вариант быстро перейдет из непонимающего в понимающего, второй же скорее всего всегда будет пользоваться вторым способом. Отсюда можно сделать вывод, что важно не столько понимать все инструменты, которыми ты пользуешься (а все знать невозможно), но быть мотивированным на их исследование.
Судя по всему вы просто не очень технологично подошли к решению вашей проблемы. Думаю, намного более эффективно было бы просто складывать все номера на обработку в очередь, а её уже молотил бы отдельный процесс. Если правда то, что процесс создается просто, чтобы висеть и ждать, то это чрезвычайно расточительно. Судя по перечисленным "возможностям параллельного исполнения", для эффективной реализации, лучше было бы взять другой инструмент. В java, например, есть неблокирующий io, который позволяет делать обработку большого числа соединений в одном потоке, при этом никому не надо будет ждать.
Вы уж простите меня за такой офтоп, но как говорит старый анекдот: "Ты или крест сними или трусы надень" — или уж пишите "Богу" с большой буквы или "о" вместо минуса ставьте. А то фигня какая-то получается.
Он же вроде был китайским философом, а цитата почему-то на английском. Не логичнее ли было бы или по-русски её написать или по-китайски в крайнем случае?
Да, я отлично понял о чем вы. Но это актуально только для совпадения двух не очень часто встречающихся факторов: когда функция ничего не возвращает, а вы много лет писали на скала :-)
Я понимаю мотивацию дизайнера языка, который принял решение о таком переопределении операторов. Максимального ограничение возможностей переопределения операторов — это максимальная изоляция программиста от ошибок связанных с такие переопределением, однако минимальнонеобходимая возможность переопределения есть. К тому же это позволяет сохранить достаточно однообразный код.
По поводу объявления метода, то в котлине
fun func():Int = 10
// и
fun func():Int { return 10 }
идентичны. Однако вот такой код
fun func():Int = { 10 }
не скомпилируется, потому что возвращаемое значение будет ()->Int
Единственное различие которое я знаю: если использовать expression вариант, то возвращаемое значение можно не писать, а в блочном варианте компилятор такое уже не пропустит.
У груви есть "строгий режим", да. Но он создает массу ограничений и видно, что приделан сбоку к языку. К тому же я не уверен, но вроде этот режим включается только на уровне каждого отдельного класса, не на уровне компиляции, которая у груви насколько я помню динамическая.
Да, в этом смысле котлин хорош тем, что не пытается придумать какой-то свой синтаксис, а максимально использует распространенные способы записи — это сильно упрощает вход, большинство синтаксиса интуитивно понятно для того, кто имел дело с си-подобными языками.
Вот такой синтаксис действительно кажется плохо читаемым, но по факту я никаких проблем с "распаршеванием" таких выражений не испытываю. Наверное сказывается некоторая практика, но всё же.
Груви — это всё-таки динамический язык, из за этого с котлином их не часто сравнивают, а чаще со скала. Честно говоря, мне не очень нравится дизайн груви, это коненчно субъективно, но всё же. У меня на нем не получается внятно "выразить мысль", часто спотыкаешься о какие-то неприятные мелочи.
Основная киллер-фича котлина, что они не пытаются делать киллер-фич, а нацелены на разработку простого и удобного инструмента для реальной разработки. Конечно, можно пытаться сравнивать скалу и котлин, и в каждом посте обязательно про это бывает, но лично я не вижу большого смысла про это много писать — в статье по этому поводу раздел "Простой и совместимый". Это же и главные отличия от скалы, на мой взгляд.
По поводу объявления метода, то в котлине
идентичны. Однако вот такой код
не скомпилируется, потому что возвращаемое значение будет ()->Int
Единственное различие которое я знаю: если использовать expression вариант, то возвращаемое значение можно не писать, а в блочном варианте компилятор такое уже не пропустит.
Вот такой синтаксис действительно кажется плохо читаемым, но по факту я никаких проблем с "распаршеванием" таких выражений не испытываю. Наверное сказывается некоторая практика, но всё же.