Мне для тестирования и разного рода не-продакшн работы нравится groovy. Write-only язык, разобраться что делает код, совершенно невозможно.
Но! Зато, писать на нём дикий кайф - он как будто бы читает твои мысли, даже если они очень путанные, не принуждая выражать их полным и непротиворечивым образом, отсюда и сложности с чтением результата.
"Лаконичность" в значении числа символов не улучшает "читаемость". Её повышает лаконичность в значении семантических конструкций. Т.е. чем меньше лишнего делает код, тем проще его читать. Чем более прямо исполняется написанное - тем проще это читать.
Котлин проигрывает джаве в "читаемости". Когда читаешь код на джаве - абсолютно точно знаешь, что происходит в каждый конкретный момент времени. Если читается поле - то читается поле. Если вызывается метод - то он объявлен в классе. Выведение типов на каждом шагу мешает при чтении кода понимать, кто на ком стоит. И так далее, и тому подобное.
Простите, но я искренне не понимаю, почему вы считаете, что вам кто-то что-то должен. Потому что вам приходится хуже, чем другим? Существует на планете множество других людей, которым ещё хуже чем вам, им тоже все всё должны?
Вам, возможно, "должно" государство или общество: этически мы хотим обеспечивать какой-то уровень комфорта всем членам общества, и понятно, что кому-то нужно больше поддержки, чем другим.
Но когда мы говорим про бизнес, мы говорим про наши конкурентные преимущества, не недостатки. И если у нас оказывается достаточно преимуществ, выделяющих нас среди других, то бизнес закрывает глаза на наши недостатки. Но не нужно ставить телегу впереди лошади.
Ну во времена более простых компиляторов это эксплуатировалось на ура: строка формируется таким образом, чтобы а) дожить до возврата из функции любой ценой б) на стэке в адрес возврата положить фиксированный адрес в программе, по которому будет лежать инструкция jmp esp. Дальше небольшой трамплин и поехали.
А я всё-таки не соглашусь про думать. Подавляющее большинство литкода - чистое знание, загруженное на кончики пальцев, мало связанное с интеллектуальной работой и скорее про наработку техник.
Современные собеседования с алгоритмами и лайвкодингом дают (и достаточно неплохо) понимание двух вещей:
Может ли кандидат в принципе нажимать кнопки на клавиатуре.
Готов ли кандидат потратить несколько недель/месяцев своей жизни, чтобы изучить популярные на собеседовании алгоритмы.
К сожалению, первое не всегда правда, даже если кандидат утверждает что 300 лет работал самым главным инженером.
Второе - такой своеобразный показатель мотивации, усидчивости и вот этого всего. Очень странный, но, по ощущениям, скорее работающий.
Впрочем, я очень много раз сталкивался с тем, что люди задают задачи, которые сами не способны решить (даже зная эталонное решение!). Мотивируют это на словах чем угодно, но очевидно, просто хотят почувствовать себя крутыми на фоне кандидата.
Если формальные процессы требовали от меня при найме давать вот такие задачи, я старался брать из пула что-то самое простое, старался успокоить кандидата, налить чайку, вот это всё, и по проще относиться к мелким промахам, которые могут произойти от волнения.
Да, может так сложиться, что очень опытный кандидат не сможет с разбега развернуть односвязный список, бывает. Но в компаниях с формализованным процессом найма, считается, и, возможно, обосновано, что потерять такого кандидата - это не смертельно, гораздо хуже нанять того, кто вообще не умеет нажимать на кнопки, даже если умеет чесать языком. Помножим это на потребность масштабировать процесс интервью и имеем что имеем: чтобы устроиться на работу, требуется научиться проделывать эти цирковые трюки с литкодом, без этого никак.
На полях замечу, что лично мне в работе помогает знание алгоритмов и навык литкода. Но соглашусь, что это исключение и чаще этот навык в реальной жизни бесполезен практически полностью.
Годная статья для вкатунов. Как мне, возможно наивно, кажется, читать хотя бы настолько упрощённые изложения основ важно даже перекладывателям JSON'ов. Даже если ничего не запомнится напрямую, всё равно в головах будет чуть меньше магического мышления.
Я скорее про то, что порог входа для новичков может приподняться слишком крутым и неприятным образом, потому что раньше надо было конкурировать с такими же новичками, а теперь ещё и с железным конём. Причем учиться самостоятельно мыслить станет сложнее.
Но поживем увидим, я не очень уверен в своих же прогнозах. Может напротив всё станет как в старые добрые с зелёной травой: в профессии снова смогут закрепляться только те, кто горят инженерным делом и качество среднего человеческого материала вырастет.
Для питона шаг наверное очень правильный, но всё равно звучит слабенько. Да, can benefit without JIT, но без возможности убер-оптимизаций связанных с инлайном, питон всё равно будет оставаться неприлично медленным.
Не уверен, откуда цифры про удесетирять, и не уверен в её правомерности. Впрочем, интерпретатор питона тоже довольно примитивен в сравнении, например, с джавовым.
Это бессмысленно. Для любого эффективного JIT нужно считать статистику. Если вы уже имеете на руках статистику - поставить trap для редких случаев тривиально. Инлайн всё равно нужно уметь делать, иначе всё будет медленно, т.к. именно инлайн открывает пути к другим оптимизациям (убрать дублирующиеся проверки, выкинуть аллокацию неиспользуемых объектов, разложить по стеку то, что не убегает за пределы скоупа и т.д.). Хотите чтобы работало быстро - нужен нормальный JIT. Иначе всё мёртвому припарки.
Предположим, адепты билдеров фабрик везде объявляют интерфейсы. Вызов интерфейсного метода очень похож на вызов в динамическом языке: нужно сделать перебор по иерархии, чтобы найти имплементацию.
Но JIT ведёт статистику, и если в какой-то метод приходит (почти) только одна имплементация (или две, для двух тоже есть оптимизация) - JIT поставит специальную ловушку на случай "а что если нет", в которой проводит деоптимизацию (на самом деле не совсем так, но в первом приближении пойдет). Для нормального же случая код будет работать так, будто был объявлен конкретный класс, вызовы будет дозволено инлайнить и проводить все возможные оптимизации.
Теоретически, для питона никто не мешает делать так же. На практике же JIT питона просто находится в совершенно зачаточном состоянии.
По ощущениям, инженеры, понимающие, как работает ассемблер и основные концепции работы современных процессоров, никуда не делись. Просто появились и другие тоже. Не думаю, что это проблема.
Наоборот, когда mailru купил, банить перестали. Более того, мы даже чинили, когда случайно ломали альтернативщиков)
Тут вам странные вопросы задают, типа "зачем это нужно". А я так скажу: во-первых, это красиво!
Мне для тестирования и разного рода не-продакшн работы нравится groovy. Write-only язык, разобраться что делает код, совершенно невозможно.
Но! Зато, писать на нём дикий кайф - он как будто бы читает твои мысли, даже если они очень путанные, не принуждая выражать их полным и непротиворечивым образом, отсюда и сложности с чтением результата.
"Лаконичность" в значении числа символов не улучшает "читаемость". Её повышает лаконичность в значении семантических конструкций. Т.е. чем меньше лишнего делает код, тем проще его читать. Чем более прямо исполняется написанное - тем проще это читать.
Котлин проигрывает джаве в "читаемости". Когда читаешь код на джаве - абсолютно точно знаешь, что происходит в каждый конкретный момент времени. Если читается поле - то читается поле. Если вызывается метод - то он объявлен в классе. Выведение типов на каждом шагу мешает при чтении кода понимать, кто на ком стоит. И так далее, и тому подобное.
Да вроде у нас тут не принято синусит, когда по делу высказываются)
Простите, но я искренне не понимаю, почему вы считаете, что вам кто-то что-то должен. Потому что вам приходится хуже, чем другим? Существует на планете множество других людей, которым ещё хуже чем вам, им тоже все всё должны?
Вам, возможно, "должно" государство или общество: этически мы хотим обеспечивать какой-то уровень комфорта всем членам общества, и понятно, что кому-то нужно больше поддержки, чем другим.
Но когда мы говорим про бизнес, мы говорим про наши конкурентные преимущества, не недостатки. И если у нас оказывается достаточно преимуществ, выделяющих нас среди других, то бизнес закрывает глаза на наши недостатки. Но не нужно ставить телегу впереди лошади.
Ну во времена более простых компиляторов это эксплуатировалось на ура: строка формируется таким образом, чтобы а) дожить до возврата из функции любой ценой б) на стэке в адрес возврата положить фиксированный адрес в программе, по которому будет лежать инструкция jmp esp. Дальше небольшой трамплин и поехали.
А я всё-таки не соглашусь про думать. Подавляющее большинство литкода - чистое знание, загруженное на кончики пальцев, мало связанное с интеллектуальной работой и скорее про наработку техник.
Современные собеседования с алгоритмами и лайвкодингом дают (и достаточно неплохо) понимание двух вещей:
Может ли кандидат в принципе нажимать кнопки на клавиатуре.
Готов ли кандидат потратить несколько недель/месяцев своей жизни, чтобы изучить популярные на собеседовании алгоритмы.
К сожалению, первое не всегда правда, даже если кандидат утверждает что 300 лет работал самым главным инженером.
Второе - такой своеобразный показатель мотивации, усидчивости и вот этого всего. Очень странный, но, по ощущениям, скорее работающий.
Впрочем, я очень много раз сталкивался с тем, что люди задают задачи, которые сами не способны решить (даже зная эталонное решение!). Мотивируют это на словах чем угодно, но очевидно, просто хотят почувствовать себя крутыми на фоне кандидата.
Если формальные процессы требовали от меня при найме давать вот такие задачи, я старался брать из пула что-то самое простое, старался успокоить кандидата, налить чайку, вот это всё, и по проще относиться к мелким промахам, которые могут произойти от волнения.
Да, может так сложиться, что очень опытный кандидат не сможет с разбега развернуть односвязный список, бывает. Но в компаниях с формализованным процессом найма, считается, и, возможно, обосновано, что потерять такого кандидата - это не смертельно, гораздо хуже нанять того, кто вообще не умеет нажимать на кнопки, даже если умеет чесать языком. Помножим это на потребность масштабировать процесс интервью и имеем что имеем: чтобы устроиться на работу, требуется научиться проделывать эти цирковые трюки с литкодом, без этого никак.
На полях замечу, что лично мне в работе помогает знание алгоритмов и навык литкода. Но соглашусь, что это исключение и чаще этот навык в реальной жизни бесполезен практически полностью.
Годная статья для вкатунов. Как мне, возможно наивно, кажется, читать хотя бы настолько упрощённые изложения основ важно даже перекладывателям JSON'ов. Даже если ничего не запомнится напрямую, всё равно в головах будет чуть меньше магического мышления.
Ну уж нет, на С эксплуатировать уязвимости типа buffer overflow, мягко говоря, неудобно (хоть и возможно).
Я скорее про то, что порог входа для новичков может приподняться слишком крутым и неприятным образом, потому что раньше надо было конкурировать с такими же новичками, а теперь ещё и с железным конём. Причем учиться самостоятельно мыслить станет сложнее.
Но поживем увидим, я не очень уверен в своих же прогнозах. Может напротив всё станет как в старые добрые с зелёной травой: в профессии снова смогут закрепляться только те, кто горят инженерным делом и качество среднего человеческого материала вырастет.
Ну на наш век конечно хватит, а вот за молодняк обидно. Им теперь вайти в айти будет сильно тяжелее. Ну или мне просто так кажется.
Нет, спасибо, я напротив считаю, что питон не нужон и должен умереть)
Жаль только мир считает иначе)
Для питона шаг наверное очень правильный, но всё равно звучит слабенько. Да, can benefit without JIT, но без возможности убер-оптимизаций связанных с инлайном, питон всё равно будет оставаться неприлично медленным.
Не уверен, откуда цифры про удесетирять, и не уверен в её правомерности. Впрочем, интерпретатор питона тоже довольно примитивен в сравнении, например, с джавовым.
Это бессмысленно. Для любого эффективного JIT нужно считать статистику. Если вы уже имеете на руках статистику - поставить trap для редких случаев тривиально. Инлайн всё равно нужно уметь делать, иначе всё будет медленно, т.к. именно инлайн открывает пути к другим оптимизациям (убрать дублирующиеся проверки, выкинуть аллокацию неиспользуемых объектов, разложить по стеку то, что не убегает за пределы скоупа и т.д.). Хотите чтобы работало быстро - нужен нормальный JIT. Иначе всё мёртвому припарки.
В Java сделано иначе (хоть и для других целей).
Предположим, адепты билдеров фабрик везде объявляют интерфейсы. Вызов интерфейсного метода очень похож на вызов в динамическом языке: нужно сделать перебор по иерархии, чтобы найти имплементацию.
Но JIT ведёт статистику, и если в какой-то метод приходит (почти) только одна имплементация (или две, для двух тоже есть оптимизация) - JIT поставит специальную ловушку на случай "а что если нет", в которой проводит деоптимизацию (на самом деле не совсем так, но в первом приближении пойдет). Для нормального же случая код будет работать так, будто был объявлен конкретный класс, вызовы будет дозволено инлайнить и проводить все возможные оптимизации.
Теоретически, для питона никто не мешает делать так же. На практике же JIT питона просто находится в совершенно зачаточном состоянии.
Я не знаю какой продакшн у вас, но за 20 лет ни я не бил, ни меня не били за switch.
Да и во многих случаях switch читается/дебажится/поддерживается лучше, чем потуги в полиморфизм на пустом месте.
По ощущениям, инженеры, понимающие, как работает ассемблер и основные концепции работы современных процессоров, никуда не делись. Просто появились и другие тоже. Не думаю, что это проблема.