Спасибо вам за ваш блог, отчасти он подвигнул меня начать учить FP (в частности остановился на Haskell, хотя есть вещи немного смущающие).
>> ИМХО лучше с практики начинать.
Ну в метро-то надо что-то делать. Тем более в теории я не глубоко (всего лишь главы про \-исчисление и комбинаторы книги «14 занимательных эссе о хаскел»).
Просто удивляет что не очень понимаю что там написано (собственно подозреваю что там пара базовых моментов недообъяснена для совсем новичка).
Можно я не в подходящей для этого теме вас немного помучаю:
1. Оптимизации в движке Haskell:
— они в основном на AST делаются (или в IR)?
— все далаются в compile-time или сам бинарник (exe\elf) занимается оптимизацией и (JIT\интерпретацией) — где-то видел такую версию, но неправдоподобно по скорости.
2. Зачем нужно каррирование? Как отдельная и важная парадигма отличительная черта парадигмы FP?
Пока вижу лишь «сахар» для «абстрактных фабрик» или виде затыкания дыр там где по синтаксису нужна функция 1й переменной, типа:
map ( (\x y -> x /= y) param_var) param_list
Который (сахар / поддержка паттернов) на отдельное важное свойство парадигмы не тянет
3. Что лучше из (относительно теоретического) почитать для улучшения скила в FP (важное дополнение — на русском).
Наверное тут тоже два вопроса:
— в какую сторону (теория типов \ CT \ частично рекурсивные функции \ ещё что-то)?
— на какой именно книге стоит остановиться?
1. Преждевременные оптимизации — зло.
Узнай место, которое замедляет программу, реализуй его на C(*).
Собственно про профилирование кода сказали, а дальше свернули куда-то не туда и стали говорить про всякие микрооптимизации, зачем?
*) по аналогии — мало кто пишет весь код сейчас на assembler, если узкое место CPU находят самую прожорливую ф-ию и переписывают её и только её (например используя параллельность по данным через SSE инструкции)
2. Не упоминуть про CPython (и другие интерпретаторы байткода), почему?
3. На фоне 1,2 то что описано в статье даст весьма незначительные улучшения.
3.1 Вот это чрезмерная оптимизация, даже в сравнении с остальными пунктами статьи.
>> Как это возможно? Дело в том, что при обработке большого набора данных без использования генераторов (итераторов) данные могут привести к переполнению L1-кэша процессора, что значительно замедлит операции по поиску значений в памяти.
Даже на фоне присутствующих в статье советов это уж совсем экономия на спичках.
Интерпретатор всё равно загрузится в L1-instraction-cache (который свой для кода\данных).
А уж пара промахов по data-cache дадут доли процентов на фоне общей неспешности внутренних мехазинмов python, типа __getattribute__ (которые вовсе не для производительности так проектировались).
>> Перспективы не радужные, все мужское население, которое остается без работы идет в строительство или перевозки.
Понял да, удачи вам.
Вот я сейчас в (чем-то) похожей ситуации.
Решил учить FP (решил ознакомиться с базисом — лямбда и комбинаторным исчислениями) и чувствую себя таким тупым, как те «троечники» которые в студенчестве вечно какие-то очевидные вещи не понимали.
И вот думаю то-ли я действительно тупее стал, то-ли требуется «период въезжания» в практически полностью новую тему.
>> до них сложно доходит понятие профессионализм и почему надо платить больше, чем бригаде забулдыг.
Ну я, конечно, в Мск а не провинции.
Но по моим понятиям профессионалы берут столько же сколько и забулдыги. Просто профессионалы (с хорошо налаженным конвейром работы и инструментом) делают работу за 1 день, а забулдыги за 3.
>> >> В моём понимании, при наличии заказчиков и прямых рук, конечно
>> а когда накосячили то платили за день исправлений… побелка с потолка осыпалась прямо в момент финальной приемки, не говоря уже о кривых стенах
Во-первых мы обсуждаем (условно) профессионалов не ниже некоторого среднего уровня что в IT, что в строительстве (см ремарку); соответственно неизбежные косяки не столь часты.
Во-вторых такие профессионалы ценят своё время и предварительно оценивают трудоёмкость работ профессионально <=> обычно адекватно.
В третьих человек идёт из опытного строителя в неопытного IT-шника (т.е.косячить в IT будет больше по определению).
ПС
Если хотите обсудить «уровень последствий для исполнителя» — то в IT он в среднем ниже чем в строительстве (хотя удивительно уровень ответственности выше и это нельзя сбрасывать со счетов).
Хотя в разработке каких-нибудь аэрокосмических систем не исключаю что и посадить могут (т.е. как всегда есть нюансы).
Это, конечно, хорошо обсудить за обедом.
Но тащить код способный удивить коллег, который потом читать (и желательно понять потратив не очень много времени) и при необходимости модифицировать, в средний-большой проект так себе идея (средний-большой условно если все разработчики проекта не сидят в одной комнате).
А С++ к этому если не принуждает, то активно подталкивает.
>> Как в таком случе с вашей точки зрения должен быть запрограмированн именно ваш автопилот: чтобы спасти своего пассажира или чтобы спасти максимальное количество людей?
Очевидно (для бизнеса) чтобы спасти своего пассажира.
Иначе такую машину никто не купит ;)
Ну надо отметить, что 3 и 4 уровни автоматизации (по SAEJ3016) работают весьма фигово.
Т.е. после некоторых систем содействия водителю надо переходить сразу на полностью автоматическое управление ТС.
Да два уточнения:
1. В авиации с автоматизированием работы пилота ещё как-то справляются, за счёт выделения отдельных часов для пилотов, когда они они обрабатывают нештатные ситуации. В вождении личного ТС будет совсем не так.
2. Наиболее вероятный сценарий аварии, на 4 уровне автоматизации будет выглядеть так:
«еду за рулём пью кофе 'готов в любую секунду взять на себя управление ТС при нештатной ситуации' вдруг (редкое событие или цепочка высоковероятных событий...) авто едет не туда, во рту бутерброд, в руке кофе, как управлять авто я уже подзабыл, а как управлять во внештатной ситуации никогда и не знал… бумц… хорошо хоть подушки безопасности есть»
>> Я сейчас учу Java (работал в банках, занимаюсь строительством коттеджей, 2 вышки)
А можно вопрос о мотивах?
В моём понимании, при наличии заказчиков и прямых рук, конечно, в строительной сфере, даже простым монтажником можно заработать на уровне программиста (да монтажникам надо в-job-ывать) — профессионалы хотят 10-25тыс\день работы.
А монтажники в коттеджных посёлках (по слухам и рассказам) получают в пару раз больше.
Ну т.е. в моём понимании уходить из строительства (при наличии наработанной клиентской базы) на ± начальные позиции в IT смысла особого нет.
>> Тем не менее это всё не значит, что нужно уже сейчас платить программерам как водителю автобуса
Несомненно. Я подчёркиваю лишь две вещи не надо думать что схватил бога за тестикулы:
а) не надо забывать, что нам просто повезло «оказаться в нужное время в нужном месте»
б) спрос на разработчиков может и упасть.
Вот из нашего компьютерного класса физ-мат школы люди стали:
— программистами
— физиками-математиками (в основном R&D, но есть и наука)
— часть пошла в финансы.
Так вот ЗП программистов раза в 1.5 больше, чем у выбравших физ-мат (не смотря на то, что предыдущий НТП-рывок требовал как раз много физиков и благоволил их зарплатам), а у финансистов ощутимо больше программистов.
Это я к чему:
>> потребность в программистах будет только расти, как и их зарплаты.
Собственно в любой момент такая лафа (в виде благ, спускаемых на отрасль и рядовых сотрудников) может закончиться (*). И… и всё будем мы работать за ЗП «водителя автобуса».
*) Сценарии могут быть разными:
— выстрелит ИИ
— амазон + гугл всех сожрут (и не нужно будет больше столько программистов и столько высокооплачиваемых программистов)
— закончится «низковисяцие» плоды в R&D
…
Сложение и вычитание рациональных чисел (чисел, представленных в виде рациональных дробей) тоже дорогое удовольствие.
Там ведь (при приведении к общему знаменателю) и числитель и знаменатель будут расти (весьма быстр и почти гарантировано). В результате чего вам очень быстро не хватит int_64.
В результате чего вы перейдёте на длинную арифметику, а производительность упадёт катастрофически.
ПС
А цель, избежать накопления ошибки, в общем случае, так и не будет достигнута ;)
У вас очень интересная ветка разговора.
Хотел бы спросить: какое обучение (схема, плюс конкретные учебники, наверное) вы бы предложили «типичному айтишнику» — т.е. человеку читающему мануалы по техническим темам, но недовольному своим английским в целом. Целью можно считать владение, в том числе письменное и разговорное на уровне B2-B2.
>> И почему, как вы считаете, отсутствие регулярной практики лично в вашем случае повлияло только на наличие пунктуационных ошибок — но не орфографических, не синтаксических, не лексических и не стилистических?
Я для себя дал не так давно такое объяснение: русская пунктуация, как правило является излишней, для понимания смысла. Поэтому она, как наиболее ненужный навык, забывается первой.
Более того она, зачастую, и не учится вообще. Скажем я в детстве читал много художественной литературы, практически не обращая внимания на пунктуацию — морфологии, синтаксиса и семантики вполне хватало для понимания смысла.
А как бы вы отреагировали на честный ответ (исключая вопросы про конкретный ключ, верно названные здесь «тестом объёма оперативной памяти»): «Половина претендентов на эту вакансию не показала никаких знаний по этому вопросу, поэтому считайте ещё 1-2 таких вопроса нашей обязательной программой»
С одной стороны мы рискуем уйти в холивар, но с другой от языка ожидаешь некоторого уровня контроля за кодом «по-умолчанию». Вот я бы (на java не пишу) ожидал бы, что в настройках по умолчанию java выведет как минимум 2 варнинга в compile-time.
int i=(false?0:null);
Просто по анализу AST проверить семантику типов в операции. Для языка со строгой типизацией, неужели сложно?
public static void work(){
try{
work();
}finally{
work();
}
}
Цикл без выходной дуге в графе вызовов? Тоже практически без накладных расходов (при компиляции). И тоже я бы ожидал от java увидеть при компиляции варнинг.
Давайте начнём с того, что вы сравнили «сложность дебага» трёх совершенно разных программ:
1. Неверной программы, которая никак не показывает прогресс выполнения.
2. Неверной программы, которая чертит график в процессе выполнения. Т.е. есть прогресс, есть точка выполнения, есть номер итерации
3. Верную программу.
И сделали вывод — проще всего устранить ошибку в провильно работающей программе.
Во-вторых давайте про С++:
1. Определитесь с терминами: у вас падает ОС или приложение (и есть .core файл для linux)? Предположу, что второе.
2. Просто поймать в отладчике момент прихода сигнала от ОС — что в этом сложного (да возможно надо предварительно скомпилироваться с отладочной информацией).
3. У вас отдельным пунктом выделена ЗАДАЧА сохранить счётчик итерации в переменной — извините если это отдельная задача, то наверное действительно не стоит заниматься дебагом кода на С++.
>> ИМХО лучше с практики начинать.
Ну в метро-то надо что-то делать. Тем более в теории я не глубоко (всего лишь главы про \-исчисление и комбинаторы книги «14 занимательных эссе о хаскел»).
Просто удивляет что не очень понимаю что там написано (собственно подозреваю что там пара базовых моментов недообъяснена для совсем новичка).
Можно я не в подходящей для этого теме вас немного помучаю:
1. Оптимизации в движке Haskell:
— они в основном на AST делаются (или в IR)?
— все далаются в compile-time или сам бинарник (exe\elf) занимается оптимизацией и (JIT\интерпретацией) — где-то видел такую версию, но неправдоподобно по скорости.
2. Зачем нужно каррирование? Как отдельная и важная
парадигмаотличительная черта парадигмы FP?Пока вижу лишь «сахар» для «абстрактных фабрик» или виде затыкания дыр там где по синтаксису нужна функция 1й переменной, типа:
map ( (\x y -> x /= y) param_var) param_list
Который (сахар / поддержка паттернов) на отдельное важное свойство парадигмы не тянет
3. Что лучше из (относительно теоретического) почитать для улучшения скила в FP (важное дополнение — на русском).
Наверное тут тоже два вопроса:
— в какую сторону (теория типов \ CT \ частично рекурсивные функции \ ещё что-то)?
— на какой именно книге стоит остановиться?
Узнай место, которое замедляет программу, реализуй его на C(*).
Собственно про профилирование кода сказали, а дальше свернули куда-то не туда и стали говорить про всякие микрооптимизации, зачем?
*) по аналогии — мало кто пишет весь код сейчас на assembler, если узкое место CPU находят самую прожорливую ф-ию и переписывают её и только её (например используя параллельность по данным через SSE инструкции)
2. Не упоминуть про CPython (и другие интерпретаторы байткода), почему?
3. На фоне 1,2 то что описано в статье даст весьма незначительные улучшения.
3.1 Вот это чрезмерная оптимизация, даже в сравнении с остальными пунктами статьи.
>> Как это возможно? Дело в том, что при обработке большого набора данных без использования генераторов (итераторов) данные могут привести к переполнению L1-кэша процессора, что значительно замедлит операции по поиску значений в памяти.
Даже на фоне присутствующих в статье советов это уж совсем экономия на спичках.
Интерпретатор всё равно загрузится в L1-instraction-cache (который свой для кода\данных).
А уж пара промахов по data-cache дадут доли процентов на фоне общей неспешности внутренних мехазинмов python, типа __getattribute__ (которые вовсе не для производительности так проектировались).
Понял да, удачи вам.
Вот я сейчас в (чем-то) похожей ситуации.
Решил учить FP (решил ознакомиться с базисом — лямбда и комбинаторным исчислениями) и чувствую себя таким тупым, как те «троечники» которые в студенчестве вечно какие-то очевидные вещи не понимали.
И вот думаю то-ли я действительно тупее стал, то-ли требуется «период въезжания» в практически полностью новую тему.
>> до них сложно доходит понятие профессионализм и почему надо платить больше, чем бригаде забулдыг.
Ну я, конечно, в Мск а не провинции.
Но по моим понятиям профессионалы берут столько же сколько и забулдыги. Просто профессионалы (с хорошо налаженным конвейром работы и инструментом) делают работу за 1 день, а забулдыги за 3.
>> а когда накосячили то платили за день исправлений… побелка с потолка осыпалась прямо в момент финальной приемки, не говоря уже о кривых стенах
Во-первых мы обсуждаем (условно) профессионалов не ниже некоторого среднего уровня что в IT, что в строительстве (см ремарку); соответственно неизбежные косяки не столь часты.
Во-вторых такие профессионалы ценят своё время и предварительно оценивают трудоёмкость работ профессионально <=> обычно адекватно.
В третьих человек идёт из опытного строителя в неопытного IT-шника (т.е.косячить в IT будет больше по определению).
ПС
Если хотите обсудить «уровень последствий для исполнителя» — то в IT он в среднем ниже чем в строительстве (хотя удивительно уровень ответственности выше и это нельзя сбрасывать со счетов).
Хотя в разработке каких-нибудь аэрокосмических систем не исключаю что и посадить могут (т.е. как всегда есть нюансы).
Т.е. когда делал ремонт, то отдавал примерно по 10-25 тыр за человекодень (двери \ окна \ шкафы \ кондиционеры \ потолки....) за монтаж.
Это, конечно, хорошо обсудить за обедом.
Но тащить код способный удивить коллег, который потом читать (и желательно понять потратив не очень много времени) и при необходимости модифицировать, в средний-большой проект так себе идея (средний-большой условно если все разработчики проекта не сидят в одной комнате).
А С++ к этому если не принуждает, то активно подталкивает.
Очевидно (для бизнеса) чтобы спасти своего пассажира.
Иначе такую машину никто не купит ;)
Т.е. после некоторых систем содействия водителю надо переходить сразу на полностью автоматическое управление ТС.
Да два уточнения:
1. В авиации с автоматизированием работы пилота ещё как-то справляются, за счёт выделения отдельных часов для пилотов, когда они они обрабатывают нештатные ситуации. В вождении личного ТС будет совсем не так.
2. Наиболее вероятный сценарий аварии, на 4 уровне автоматизации будет выглядеть так:
«еду за рулём пью кофе 'готов в любую секунду взять на себя управление ТС при нештатной ситуации' вдруг (редкое событие или цепочка высоковероятных событий...) авто едет не туда, во рту бутерброд, в руке кофе, как управлять авто я уже подзабыл, а как управлять во внештатной ситуации никогда и не знал… бумц… хорошо хоть подушки безопасности есть»
А можно вопрос о мотивах?
В моём понимании, при наличии заказчиков и прямых рук, конечно, в строительной сфере, даже простым монтажником можно заработать на уровне программиста (да монтажникам надо в-job-ывать) — профессионалы хотят 10-25тыс\день работы.
А монтажники в коттеджных посёлках (по слухам и рассказам) получают в пару раз больше.
Ну т.е. в моём понимании уходить из строительства (при наличии наработанной клиентской базы) на ± начальные позиции в IT смысла особого нет.
Несомненно. Я подчёркиваю лишь две вещи
не надо думать что схватил бога за тестикулы:а) не надо забывать, что нам просто повезло «оказаться в нужное время в нужном месте»
б) спрос на разработчиков может и упасть.
— программистами
— физиками-математиками (в основном R&D, но есть и наука)
— часть пошла в финансы.
Так вот ЗП программистов раза в 1.5 больше, чем у выбравших физ-мат (не смотря на то, что предыдущий НТП-рывок требовал как раз много физиков и благоволил их зарплатам), а у финансистов ощутимо больше программистов.
Это я к чему:
>> потребность в программистах будет только расти, как и их зарплаты.
Собственно в любой момент такая лафа (в виде благ, спускаемых на отрасль и рядовых сотрудников) может закончиться (*). И… и всё будем мы работать за ЗП «водителя автобуса».
*) Сценарии могут быть разными:
— выстрелит ИИ
— амазон + гугл всех сожрут (и не нужно будет больше столько программистов и столько высокооплачиваемых программистов)
— закончится «низковисяцие» плоды в R&D
…
Плюсы: ничего не надо придумывать.
Минусы: не достойно статьи на Хабре.
Там ведь (при приведении к общему знаменателю) и числитель и знаменатель будут расти (весьма быстр и почти гарантировано). В результате чего вам очень быстро не хватит int_64.
В результате чего вы перейдёте на длинную арифметику, а производительность упадёт катастрофически.
ПС
А цель, избежать накопления ошибки, в общем случае, так и не будет достигнута ;)
Хотел бы спросить: какое обучение (схема, плюс конкретные учебники, наверное) вы бы предложили «типичному айтишнику» — т.е. человеку читающему мануалы по техническим темам, но недовольному своим английским в целом. Целью можно считать владение, в том числе письменное и разговорное на уровне B2-B2.
>> И почему, как вы считаете, отсутствие регулярной практики лично в вашем случае повлияло только на наличие пунктуационных ошибок — но не орфографических, не синтаксических, не лексических и не стилистических?
Я для себя дал не так давно такое объяснение: русская пунктуация, как правило является излишней, для понимания смысла. Поэтому она, как наиболее ненужный навык, забывается первой.
Более того она, зачастую, и не учится вообще. Скажем я в детстве читал много художественной литературы, практически не обращая внимания на пунктуацию — морфологии, синтаксиса и семантики вполне хватало для понимания смысла.
Просто по анализу AST проверить семантику типов в операции. Для языка со строгой типизацией, неужели сложно?
Цикл без выходной дуге в графе вызовов? Тоже практически без накладных расходов (при компиляции). И тоже я бы ожидал от java увидеть при компиляции варнинг.
1. Неверной программы, которая никак не показывает прогресс выполнения.
2. Неверной программы, которая чертит график в процессе выполнения. Т.е. есть прогресс, есть точка выполнения, есть номер итерации
3. Верную программу.
И сделали вывод — проще всего устранить ошибку в провильно работающей программе.
Во-вторых давайте про С++:
1. Определитесь с терминами: у вас падает ОС или приложение (и есть .core файл для linux)? Предположу, что второе.
2. Просто поймать в отладчике момент прихода сигнала от ОС — что в этом сложного (да возможно надо предварительно скомпилироваться с отладочной информацией).
3. У вас отдельным пунктом выделена ЗАДАЧА сохранить счётчик итерации в переменной — извините если это отдельная задача, то наверное действительно не стоит заниматься дебагом кода на С++.