Не знаю про шифрование, но архитектурно, мне видится, что QR лучше (во всяком случае преимущества у QR есть, а преимуществ RFC не вижу).
Пользователь видит на своём устройстве, а не на "предполагаемо доверенном аппарате" (- скрам атаки) какой платёж он собирается провести и сообщает в банк: сделай это.
Превращение ПС "Мир" из региональной в мировую С начала 2021 года Google внесла огромные инвестиции, чтобы впервые в мире добавить региональные российские банковские карты "Мир" в глобальную платежную систему Google Pay.
Не очень понял, что имелось в виду под "огромными инвестициями" в этом пункте. В ноябре 2021 года буднично добавил карточку "Мир" в Apple Pay (после того, как Visa объявила об увеличении комиссии).
Так в чём собственно "революционность" гугл, если разница с Apple на пол-года?
Idea, например, достаточно интеллектуальна, чтобы распознать, что ты пишешь тот же текст, что и предлагается автодополнением и тем самым просто "подтверждаешь, что предложенное автодополнение верное").
Т.е. в сосотоянии, когда вы недописали 4 последних символа: if (MyObject.SomeCondition(|)) { Вы можете завершить строчку двумя способами: - перейти в конец и нажать Enter - вручную допечатать: ")) {" Предпочитаю второй вариант, как более удобный.
К стати хочу задать вам вопрос. Прикинул вчера, очень грубо "ощущений от Хаскеля" получается на 3 статьи ("ощущения" растянуть на 3 статьи - это явно перебор).
Как по-вашему, учитывая целевую аудиторию (целевая аудитория - как раз "я два года назад, когда увидел статьи с какими-то непонятными рассуждениями про Хаскель, ФП-подход...") лучше писать: - терпимо по краткости но без примеров кода? - разбить на 3 раздела: "совсем общее [подход сообщества]" "общее" "частное но важное" - разбить на 3 раздела: "понравилось" "не понравилось" "особенности: не плохо\не хорошо" ?
Как написавший большой коммент, не мог пройти момо и не написать код. Оказалось, что хранение списков, а также map, filter и lambda (избыточные в коде, но всё-же) не вызывают видимого увеличения времени работы.
Да не смотрел что будет с кодом, насыщенным try-except
ПС Правда моя оценка (ещё более простого кода, чем у вас) C-perf / PyPy-perf = 3.5.
Так что по прошествии суток, я бы сказал, что оценка замедления PyPy относительно C, как x2 - x4 (если не делать жуктих perf-ошибок) имеет право на жизнь.
В принципе прошло 3 месяца всего можно ещё собраться с мыслями.
Но если совсем тезисно, то критика звучала бы так (хорошее вы и без меня знаете), возможно немного сумбурно:
Статьи от сообщества про Хаскель: они явно демонстрируют best case, создавая завышенные ожидания.
200 часов явно недостаточно, в смысле instrument-mastery и чувствую себя довольно неуклюже, пытаясь решить какие-то реальные проблемы (конечно если решать на Хаскель только каждую 10-ую задачу будет ок).
Хаскель требует отдельного instrument-mastery, best-practics... о чём, к стати в статьях не говорится.
Не по-порядку но важно: язык очень сильно смещает акцент с "алгоритмов" на "структуры данных" (не знаю как это правильно описать). Сюда же: буквально у каждой строчки кода есть "законченное состояние", это прикольно и хорошо.
Вообще есть ощущение, что "если писать всё в манаде State - то нафига Хаскель", а если писать всё по-возможности чисто и функционально, то какая-нибудь внезапная не стоящая внимания деталь может потребовать вторые (а затем и третьи) 90% работы от тебя, на вроде бы пустом месте.
Вообще менять программу "чуть-чуть" очень легко и приятно, намного лучше чем, в ООП, но вот менять программу "средне" (я пытался сформулировать, лучшее что получилось - если приходится менять структуры данных) намного-намного больше работы, чем в ООП.
// Дальше обещанная критика "хорошие" вещи вы наверное знаете лучше меня.
Внезапно Хасель довольно многословен, ОСОБЕННО, если решать несвойственные ему задачи (State и аналоги просто ужасна как и массивы, может с непривычки).
Да и вообще весь синтаксис выглядит довольно неудачным (хороший он только в "подогнанных" учебных примерах), - тут много частных кэйсов можно и нужно приводить.
Хаскель требует повышенной ментальной нагрузки (помним про "всего лишь / целых" 200 часов опыта): через 3 часа я чувствую себя уставшим, голова не соображает...
Функции надо делать очень очень маленькими, соответственно и слоёв абстракций больше (Кажется не только по предыдущей причине, но и по какому-то внутреннему свойству языка). То есть "единицы кода" надо дробить мельче, чем ты к этому привык - мне не кажется, что это хорошо: 400 строк кода идеально раздробить на 20 функций по 20 строк, а на Хаскеле это будет 150 функций по 3 строчки.
Скомпилировалось-работает: оно в жизни совсем не так, как в статьях в интернете. От серьёзных ошибок (на каждой итерации вы приближаетесь к завершению) оно вас не защищает, а те ошибки от которых защищает - это обычно не слишком серьёзные низкоуровневые ошибки, неприятные, но быстро находимые\устроняемые. Самое полезное где "скомпилировалось-работает" пригодилось это рефакторинг, чуть более сложный, чем автоматический.
Да сюда не относится C/C++ UB - отсутствие такого поведения это, конечно же, благо.
Какой более сложный алгоритм удовлетворил бы Вас? Только без больших входных данных.
Э... даже теряюсь как объяснить, что по 1й точке поведение ф-ии не измеряется.
Какой 1 тест оставить в SPEC чтобы он всех устроил (спойлер - заранее непонятно на каком сценарии какой компилятор и где просядет, поэтому добавляют разные, принципиально разные, кэйсы).
Собственно именно поэтому подход "одного ЧЯ-теста" изначально неверный и вопрос "найдите мне серебрянную пулю" некорректный.
Собственно, поэтому и был написан вариант-2, чтобы работа с памятью на Си оказалась примерно сравнимой с тем, что делает Python.
Но вы же просто сильнее исследовали одну точку, вместо того, чтобы по бОльшему количеству точек хотя бы прикинуть общую картину.
Вообще я бы пошёл или "методом белого ящика" или "методом чёрного ящика".
Методом Б.Я. я бы проверил кэйсы-кандидаты на отсутствие оптимизаций в PyPy (список не исчерпывающий, есть ещё много чего, но боюсь что-то "тяжёлое" типа лямбд \ декораторов... PyPy просто не компилит): - map -> list / list -> map - hashmap / tree - list of objects(PyPy) vs list of structures (C) - "боксинг\анбоксинг в PyPy нет, но вдруг что вылезет". - встроенные генераторы / генераторы + yeild // кто представляет устройство Python + PyPy лучше меня добавьте других кандидатов, подозреваю, что сходу много чего пропустил.
Методом Ч.Я. я бы проверял так: Взять условный "adventofcode за любой год" (он мне нравится по ряду причин - на нём я проверял Haskell, и планирую Rust) или любой другой набор не слишком примитивных, но и не сложных тестов. Реализовать всё, отписаться о результатах. Среднее "усложнение написание" vs "увеличение времени работы". Можно также посмотреть на наличие/отсутствие корреляции.
Есть два утверждения: 1. "PyPy примерно вдвое медленнее C" 2. "На очень простом тесте, где компилятору просто негде облажаться PyPy примерно вдвое медленнее С".
Вы измерили вариант-2, но почему-то преподносите его как вариант-1. Без доказательства, что (в целом приемлемое замедление вдвое) будет сохраняться, при усложнении структуры вычислений.
Сначала вы сравнили алгоритмы с разной ассимптотической сложностию. Потом, вместо того, чтобы написать эффективный алгоритм на C - вы стали вкорячивать в решение на C плохую реализацию Scheme.
Потом вывод "есть смысл сперва делать MVP на высокоуровневом языке" - разумеется да, но вот угадывать "во сколько раз C будет быстрее" по мне так дело неблагодарное. Уверен, что способов "схватить замедление вдвое на банальной операции" в том же PyPy масса. И это без привлечения памяти, а с памятью (и неудачной раскладке по кэшам) - можно во сколько угодно раз замедлится "почти" на пустом месте.
Ну и по поводу Scheme, ведь сравнение могло бы выглядеть и так:
C, решение 1
сложность(грубо) N^2 / log(N)
Время = 2 сек.
// был не прав по поводу оптимизации "проверяем все меньшие" vs "проверяем меньшие до sqrt(N)" - там ассимптоты очень похожи.
Scheme, решение 1
сложность N^2 / log(n)^2
время: 1 сек
С, лучшее решение (решето эратосфена):
сложность N*log(N)
время: 0.005 сек
Scheme, лучшее решение... хД
ПС Ваша статья напомнила мне, когда я пол-года назад разбирался с Haskell (хороший своеобразный, но уж слишком академический язык) - так и подмывало написать статью типа "как ведёт себя Haskell, на произвольных задачах, а не только на красивых".
Важной особенностью является то, так как "под капотом" у слайса лежит указатель на массив — при изменении значений слайса они будут изменяться везде, где слайс используется (будь то присвоение в переменную, передача в функцию и т.д.) до момента, пока размер слайса не будет переполнен и не будет выделен новый массив для его значений (т.е. в момент изменения cap слайса всегда происходит копирование данных массива):
Я прям не сразу понял как такого добиться, а потом каааак понял. Вот это грабли.
Мне кажется архитекторы языка переупоролись в "простоту" и "интуитивную понятность", в итоге такое поведение является интуитивно понятным лишь в каких-то совсем простых кейсах, а шаг влево-шаг вправо и всё надо понимать как сделано под капотом.
Мне кажется, что здесь смешаны два разных вопроса, выводы по которым подаются как-бы вместе: 1. Войти-В-Айти 2. Полезность курсов.
1. По вопросу "войти-в-айти" согласен с автором. Проблема в том, что на таких курсах изначально (и боюсь, что умышленно) создают завышенные ожидания - ничего личного, просто бизнес.
2. По поводу полезности курсов и "прикладных книг" - я категорически не согласен с автором. Мне кажется, что как раз книги прикладного уровня: "100501 объяснение как выучить C++ забавно" - лишние на сегодняшний день. То есть я бы предпочёл изучать технологию так: - tutorial от авторов; - какие-то курсы (на 20-50 часов); - официальная документация - stackoverflow + статьи по появляющимся в процессе вопросам.
При этом курсы (на stepic например куча бесплатных курсов, не знаю как сейчас дела с coursera) - это те же книги 20 лет назад, но интерактивные, т.е .с быстрой обратной связью. - просмотрел ролик как подключать модули - написал qualified import ..... Когда ты "по-горячему" успеваешь закрепить материал.
Два замечания-комментария: 1. Умение самостоятельно разобратьсяв в проблеме - критически важное свойство программиста. Чем раньше это умнеие появится и закрепится как навык - тем для человека лучше.
2. Наличие ментора (человека, который может постоянно давать адекватную обратную связь, а также советовать что изучить и как) может кратно ускорить изначальный этап "вхождения в IT". В основном за счёт того, чтобы не тратить на то, что не нужно и то, что "явно не твоё".
Почему же автоматы обходят стороной и/или изобретают велосипеды, превращая код в спагетти?
По-моему, тут дело в стереотипе: мол, автоматы — это что-то сложное из теоретической математики и к реальной жизни не относится. А применять их можно только в лексических анализаторах или еще чем-нибудь специфичном.
Ну вот про парсеры мой опыт прямо обратный. В теории state-machine это что-то удобное простое и чуть-ли не формально доказуемо что верное. На практике же быстрее написать и отладить какой-нибудь рекурсивный спуск (не говоря уже о библиотеках типа Parsec), чем просто на бумажке завершить расписывание state-machine для лексера и для парсера.
А уж какой неинтуитивный (спагетти?) код, перенасыщенный низкоуровневыми деталями получается, при реализации прямой КО - это надо один раз увидеть, чтобы мысли к ним возвращаться не было.
Да есть ещё ваниант: не впрямую реализовывать КО, а объеденить несколько веточек в коде, сделать пару улучшающих код оптимизаций.... В результате: - код становится чуть лучше (но всё ещё уродливым) - единственное преимущество - код отражает ровно state machine, без возможности неточностей (при оптимизации и с резании углов) мы теряем.
ПС Единственное, где мне state-machine пригодилась - это при реализации специфических низкоуровневых примитивов синхронизации. Вот там действительно внимательность нужна и учесть все варианты.
Правда подозреваю, что "правильное" решение взять какой-нибудь пакет для разработки протоколов, но мааааа-леньких. Ничего хорошего не нашёл.
Вы так уверенно отвечаете, может быть вы подскажете: сколько налогов Гугл платил в США, а сколько в России с рекламы блогеров?
Не знаю про шифрование, но архитектурно, мне видится, что QR лучше (во всяком случае преимущества у QR есть, а преимуществ RFC не вижу).
Пользователь видит на своём устройстве, а не на "предполагаемо доверенном аппарате" (- скрам атаки) какой платёж он собирается провести и сообщает в банк: сделай это.
Не очень понял, что имелось в виду под "огромными инвестициями" в этом пункте.
В ноябре 2021 года буднично добавил карточку "Мир" в Apple Pay (после того, как Visa объявила об увеличении комиссии).
Так в чём собственно "революционность" гугл, если разница с Apple на пол-года?
По поводу автодополнения.
Idea, например, достаточно интеллектуальна, чтобы распознать, что ты пишешь тот же текст, что и предлагается автодополнением и тем самым просто "подтверждаешь, что предложенное автодополнение верное").
Т.е. в сосотоянии, когда вы недописали 4 последних символа:
if (MyObject.SomeCondition(|)) {
Вы можете завершить строчку двумя способами:
- перейти в конец и нажать Enter
- вручную допечатать: ")) {"
Предпочитаю второй вариант, как более удобный.
Как по мне - так слепая печать нужна для того, чтобы не уставать в то время как печатаешь.
А скорость набивания текста (100 или 220 CPM - 220 у меня в клавогонках в режиме релакса) - играет тут глубоко второстепенную роль.
Не понял этот комментарий. Приведённый код не подходит к использованию "из коробки"?
> Этот алгоритм про результат с заданной степенью точности.
Но ошибка распределена очень неравномерно.
Честно говоря, у вас как-то странно смещены значения, это может выплыть боком и привести к накоплению ошибки.
Вот что дало простое суммирование по 1 градусу:
[0] : 0.000000 - 0.000000 = 0.000000
[1] : 0.017456 - 0.017452 = 0.000004
[2] : 0.034790 - 0.034899 = -0.000109
[3] : 0.052216 - 0.052336 = -0.000120
[4] : 0.069580 - 0.069756 = -0.000176
[5] : 0.086975 - 0.087156 = -0.000181
[6] : 0.104309 - 0.104528 = -0.000219
[7] : 0.121643 - 0.121869 = -0.000226
[8] : 0.138947 - 0.139173 = -0.000227
[9] : 0.156219 - 0.156434 = -0.000215
[10] : 0.173431 - 0.173648 = -0.000217
[11] : 0.190643 - 0.190809 = -0.000166
[12] : 0.207764 - 0.207912 = -0.000148
[13] : 0.224823 - 0.224951 = -0.000128
[14] : 0.241791 - 0.241922 = -0.000131
[15] : 0.258759 - 0.258819 = -0.000061
[16] : 0.275574 - 0.275637 = -0.000064
[17] : 0.292358 - 0.292372 = -0.000013
[18] : 0.308990 - 0.309017 = -0.000027
[19] : 0.325562 - 0.325568 = -0.000007
[20] : 0.342072 - 0.342020 = 0.000051
[21] : 0.358429 - 0.358368 = 0.000061
[22] : 0.374695 - 0.374607 = 0.000088
[23] : 0.390869 - 0.390731 = 0.000138
[24] : 0.406921 - 0.406737 = 0.000185
[25] : 0.422791 - 0.422618 = 0.000172
[26] : 0.438568 - 0.438371 = 0.000197
[27] : 0.454193 - 0.453991 = 0.000203
[28] : 0.469696 - 0.469472 = 0.000224
[29] : 0.485046 - 0.484810 = 0.000237
[30] : 0.500244 - 0.500000 = 0.000244
[31] : 0.515289 - 0.515038 = 0.000251
[32] : 0.530151 - 0.529919 = 0.000232
[33] : 0.544891 - 0.544639 = 0.000252
[34] : 0.559479 - 0.559193 = 0.000286
[35] : 0.573853 - 0.573576 = 0.000276
[36] : 0.588043 - 0.587785 = 0.000258
[37] : 0.602081 - 0.601815 = 0.000266
[38] : 0.615906 - 0.615661 = 0.000244
[39] : 0.629547 - 0.629320 = 0.000227
[40] : 0.642975 - 0.642788 = 0.000187
[41] : 0.656250 - 0.656059 = 0.000191
[42] : 0.669312 - 0.669131 = 0.000181
[43] : 0.682159 - 0.681998 = 0.000161
[44] : 0.694794 - 0.694658 = 0.000135
[45] : 0.707245 - 0.707107 = 0.000138
[46] : 0.719482 - 0.719340 = 0.000143
[47] : 0.731445 - 0.731354 = 0.000092
[48] : 0.743225 - 0.743145 = 0.000080
[49] : 0.754761 - 0.754710 = 0.000051
[50] : 0.766083 - 0.766044 = 0.000038
[51] : 0.777161 - 0.777146 = 0.000015
[52] : 0.787994 - 0.788011 = -0.000016
[53] : 0.798584 - 0.798636 = -0.000052
[54] : 0.808960 - 0.809017 = -0.000057
[55] : 0.819061 - 0.819152 = -0.000091
[56] : 0.828949 - 0.829038 = -0.000089
[57] : 0.838593 - 0.838671 = -0.000078
[58] : 0.847961 - 0.848048 = -0.000087
[59] : 0.857056 - 0.857167 = -0.000112
[60] : 0.865875 - 0.866025 = -0.000150
[61] : 0.874481 - 0.874620 = -0.000139
[62] : 0.882782 - 0.882948 = -0.000166
[63] : 0.890839 - 0.891007 = -0.000168
[64] : 0.898590 - 0.898794 = -0.000204
[65] : 0.906128 - 0.906308 = -0.000180
[66] : 0.913361 - 0.913545 = -0.000185
[67] : 0.920319 - 0.920505 = -0.000186
[68] : 0.927002 - 0.927184 = -0.000182
[69] : 0.933380 - 0.933580 = -0.000200
[70] : 0.939514 - 0.939693 = -0.000178
[71] : 0.945343 - 0.945519 = -0.000176
[72] : 0.950897 - 0.951057 = -0.000159
[73] : 0.956146 - 0.956305 = -0.000159
[74] : 0.961090 - 0.961262 = -0.000172
[75] : 0.965790 - 0.965926 = -0.000136
[76] : 0.970184 - 0.970296 = -0.000111
[77] : 0.974243 - 0.974370 = -0.000127
[78] : 0.978027 - 0.978148 = -0.000120
[79] : 0.981567 - 0.981627 = -0.000060
[80] : 0.984741 - 0.984808 = -0.000067
[81] : 0.987640 - 0.987688 = -0.000048
[82] : 0.990234 - 0.990268 = -0.000034
[83] : 0.992523 - 0.992546 = -0.000023
[84] : 0.994507 - 0.994522 = -0.000015
[85] : 0.996216 - 0.996195 = 0.000021
[86] : 0.997589 - 0.997564 = 0.000025
[87] : 0.998657 - 0.998630 = 0.000028
[88] : 0.999420 - 0.999391 = 0.000029
[89] : 0.999908 - 0.999848 = 0.000061
SUM = 0.000685
К стати хочу задать вам вопрос.
Прикинул вчера, очень грубо "ощущений от Хаскеля" получается на 3 статьи ("ощущения" растянуть на 3 статьи - это явно перебор).
Как по-вашему, учитывая целевую аудиторию (целевая аудитория - как раз "я два года назад, когда увидел статьи с какими-то непонятными рассуждениями про Хаскель, ФП-подход...") лучше писать:
- терпимо по краткости но без примеров кода?
- разбить на 3 раздела: "совсем общее [подход сообщества]" "общее" "частное но важное"
- разбить на 3 раздела: "понравилось" "не понравилось" "особенности: не плохо\не хорошо"
?
Как написавший большой коммент, не мог пройти момо и не написать код.
Оказалось, что хранение списков, а также map, filter и lambda (избыточные в коде, но всё-же) не вызывают видимого увеличения времени работы.
Да не смотрел что будет с кодом, насыщенным try-except
ПС
Правда моя оценка (ещё более простого кода, чем у вас) C-perf / PyPy-perf = 3.5.
Так что по прошествии суток, я бы сказал, что оценка замедления PyPy относительно C, как x2 - x4 (если не делать жуктих perf-ошибок) имеет право на жизнь.
В принципе прошло 3 месяца всего можно ещё собраться с мыслями.
Но если совсем тезисно, то критика звучала бы так (хорошее вы и без меня знаете), возможно немного сумбурно:
Статьи от сообщества про Хаскель: они явно демонстрируют best case, создавая завышенные ожидания.
200 часов явно недостаточно, в смысле instrument-mastery и чувствую себя довольно неуклюже, пытаясь решить какие-то реальные проблемы (конечно если решать на Хаскель только каждую 10-ую задачу будет ок).
Хаскель требует отдельного instrument-mastery, best-practics... о чём, к стати в статьях не говорится.
Не по-порядку но важно: язык очень сильно смещает акцент с "алгоритмов" на "структуры данных" (не знаю как это правильно описать). Сюда же: буквально у каждой строчки кода есть "законченное состояние", это прикольно и хорошо.
Вообще есть ощущение, что "если писать всё в манаде State - то нафига Хаскель", а если писать всё по-возможности чисто и функционально, то какая-нибудь внезапная не стоящая внимания деталь может потребовать вторые (а затем и третьи) 90% работы от тебя, на вроде бы пустом месте.
Вообще менять программу "чуть-чуть" очень легко и приятно, намного лучше чем, в ООП, но вот менять программу "средне" (я пытался сформулировать, лучшее что получилось - если приходится менять структуры данных) намного-намного больше работы, чем в ООП.
// Дальше обещанная критика "хорошие" вещи вы наверное знаете лучше меня.
Внезапно Хасель довольно многословен, ОСОБЕННО, если решать несвойственные ему задачи (State и аналоги просто ужасна как и массивы, может с непривычки).
Да и вообще весь синтаксис выглядит довольно неудачным (хороший он только в "подогнанных" учебных примерах), - тут много частных кэйсов можно и нужно приводить.
Хаскель требует повышенной ментальной нагрузки (помним про "всего лишь / целых" 200 часов опыта): через 3 часа я чувствую себя уставшим, голова не соображает...
Функции надо делать очень очень маленькими, соответственно и слоёв абстракций больше (Кажется не только по предыдущей причине, но и по какому-то внутреннему свойству языка). То есть "единицы кода" надо дробить мельче, чем ты к этому привык - мне не кажется, что это хорошо: 400 строк кода идеально раздробить на 20 функций по 20 строк, а на Хаскеле это будет 150 функций по 3 строчки.
Скомпилировалось-работает: оно в жизни совсем не так, как в статьях в интернете. От серьёзных ошибок (на каждой итерации вы приближаетесь к завершению) оно вас не защищает, а те ошибки от которых защищает - это обычно не слишком серьёзные низкоуровневые ошибки, неприятные, но быстро находимые\устроняемые. Самое полезное где "скомпилировалось-работает" пригодилось это рефакторинг, чуть более сложный, чем автоматический.
Да сюда не относится C/C++ UB - отсутствие такого поведения это, конечно же, благо.
Э... даже теряюсь как объяснить, что по 1й точке поведение ф-ии не измеряется.
Какой 1 тест оставить в SPEC чтобы он всех устроил (спойлер - заранее непонятно на каком сценарии какой компилятор и где просядет, поэтому добавляют разные, принципиально разные, кэйсы).
Собственно именно поэтому подход "одного ЧЯ-теста" изначально неверный и вопрос "найдите мне серебрянную пулю" некорректный.
Но вы же просто сильнее исследовали одну точку, вместо того, чтобы по бОльшему количеству точек хотя бы прикинуть общую картину.
Вообще я бы пошёл или "методом белого ящика" или "методом чёрного ящика".
Методом Б.Я. я бы проверил кэйсы-кандидаты на отсутствие оптимизаций в PyPy (список не исчерпывающий, есть ещё много чего, но боюсь что-то "тяжёлое" типа лямбд \ декораторов... PyPy просто не компилит):
- map -> list / list -> map
- hashmap / tree
- list of objects(PyPy) vs list of structures (C) - "боксинг\анбоксинг в PyPy нет, но вдруг что вылезет".
- встроенные генераторы / генераторы + yeild
// кто представляет устройство Python + PyPy лучше меня добавьте других кандидатов, подозреваю, что сходу много чего пропустил.
Методом Ч.Я. я бы проверял так:
Взять условный "adventofcode за любой год" (он мне нравится по ряду причин - на нём я проверял Haskell, и планирую Rust) или любой другой набор не слишком примитивных, но и не сложных тестов.
Реализовать всё, отписаться о результатах.
Среднее "усложнение написание" vs "увеличение времени работы".
Можно также посмотреть на наличие/отсутствие корреляции.
Есть два утверждения:
1. "PyPy примерно вдвое медленнее C"
2. "На очень простом тесте, где компилятору просто негде облажаться PyPy примерно вдвое медленнее С".
Вы измерили вариант-2, но почему-то преподносите его как вариант-1. Без доказательства, что (в целом приемлемое замедление вдвое) будет сохраняться, при усложнении структуры вычислений.
Сначала вы сравнили алгоритмы с разной ассимптотической сложностию.
Потом, вместо того, чтобы написать эффективный алгоритм на C - вы стали вкорячивать в решение на C плохую реализацию Scheme.
Потом вывод "есть смысл сперва делать MVP на высокоуровневом языке" - разумеется да, но вот угадывать "во сколько раз C будет быстрее" по мне так дело неблагодарное.
Уверен, что способов "схватить замедление вдвое на банальной операции" в том же PyPy масса. И это без привлечения памяти, а с памятью (и неудачной раскладке по кэшам) - можно во сколько угодно раз замедлится "почти" на пустом месте.
Ну и по поводу Scheme, ведь сравнение могло бы выглядеть и так:
C, решение 1
сложность(грубо) N^2 / log(N)
Время = 2 сек.
// был не прав по поводу оптимизации "проверяем все меньшие" vs "проверяем меньшие до sqrt(N)" - там ассимптоты очень похожи.
Scheme, решение 1
сложность N^2 / log(n)^2
время: 1 сек
С, лучшее решение (решето эратосфена):
сложность N*log(N)
время: 0.005 сек
Scheme, лучшее решение... хД
ПС
Ваша статья напомнила мне, когда я пол-года назад разбирался с Haskell (хороший своеобразный, но уж слишком академический язык) - так и подмывало написать статью типа "как ведёт себя Haskell, на произвольных задачах, а не только на
красивых".Я прям не сразу понял как такого добиться, а потом каааак понял.
Вот это грабли.
Мне кажется архитекторы языка переупоролись в "простоту" и "интуитивную понятность", в итоге такое поведение является интуитивно понятным лишь в каких-то совсем простых кейсах, а шаг влево-шаг вправо и всё надо понимать как сделано под капотом.
Мне кажется, что здесь смешаны два разных вопроса, выводы по которым подаются как-бы вместе:
1. Войти-В-Айти
2. Полезность курсов.
1. По вопросу "войти-в-айти" согласен с автором.
Проблема в том, что на таких курсах изначально (и боюсь, что умышленно) создают завышенные ожидания - ничего личного, просто бизнес.
2. По поводу полезности курсов и "прикладных книг" - я категорически не согласен с автором.
Мне кажется, что как раз книги прикладного уровня: "100501 объяснение как выучить C++ забавно" - лишние на сегодняшний день.
То есть я бы предпочёл изучать технологию так:
- tutorial от авторов;
- какие-то курсы (на 20-50 часов);
- официальная документация
- stackoverflow + статьи по появляющимся в процессе вопросам.
При этом курсы (на stepic например куча бесплатных курсов, не знаю как сейчас дела с coursera) - это те же книги 20 лет назад, но интерактивные, т.е .с быстрой обратной связью.
- просмотрел ролик как подключать модули
- написал qualified import .....
Когда ты "по-горячему" успеваешь закрепить материал.
Два замечания-комментария:
1. Умение самостоятельно разобратьсяв в проблеме - критически важное свойство программиста. Чем раньше это умнеие появится и закрепится как навык - тем для человека лучше.
2. Наличие ментора (человека, который может постоянно давать адекватную обратную связь, а также советовать что изучить и как) может кратно ускорить изначальный этап "вхождения в IT". В основном за счёт того, чтобы не тратить на то, что не нужно и то, что "явно не твоё".
Сценарий: блочим (требуем блочить) всё подозрительное; разблокировка, "при лично посещении NSA с паспортом" - пока не рассматривается?
В даташите есть светодиоды 0.2-0.25 Вт.
Какую же мощность вы предлагаете ставить, чтобы было "гораздо сбалее по мощности"?
ПС
Из технических проблем - вижу нестандартные напряжения, на которые источники питания замучаешься искать.
Спасибо, как всегда интересно.
А на диодах Bridgelux Thrive - ленту ещё не делают?
(в идеале что-то похожее на 4000к, 80-100 люмин\ватт)
Ну вот про парсеры мой опыт прямо обратный.
В теории state-machine это что-то удобное простое и чуть-ли не формально доказуемо что верное.
На практике же быстрее написать и отладить какой-нибудь рекурсивный спуск (не говоря уже о библиотеках типа Parsec), чем просто на бумажке завершить расписывание state-machine для лексера и для парсера.
А уж какой неинтуитивный (спагетти?) код, перенасыщенный низкоуровневыми деталями получается, при реализации прямой КО - это надо один раз увидеть, чтобы мысли к ним возвращаться не было.
Да есть ещё ваниант: не впрямую реализовывать КО, а объеденить несколько веточек в коде, сделать пару улучшающих код оптимизаций....
В результате:
- код становится чуть лучше (но всё ещё уродливым)
- единственное преимущество - код отражает ровно state machine, без возможности неточностей (при оптимизации и с резании углов) мы теряем.
ПС
Единственное, где мне state-machine пригодилась - это при реализации специфических низкоуровневых примитивов синхронизации.
Вот там действительно внимательность нужна и учесть все варианты.
Правда подозреваю, что "правильное" решение взять какой-нибудь пакет для разработки протоколов, но мааааа-леньких. Ничего хорошего не нашёл.