У заметного числа людей она вызвала неприятные проблемы с драйверами на Windows, причём как на хостовой системе, так и в гостевых. Что-то установщик совершенно дикое мутит. Пишут, что во время установки система отключает и переподключает чуть ли не все аппаратные устройства, у некоторых пользователей этот процесс сдох на полпути и часть устройств осталась висеть то ли не подключённой, то ли неопознанной. У других инсталлятор тоже упал, и хотя система осталась жива, сам VBox после этого не удалось ни починить, ни удалить, ни переустановить по-нормальному.
Не знаю, что они там накрутили и зачем; не удивлюсь, если опять какую-то уязвимость нашли и по своей привычке заткнули дыру максимально кривым и уродским способом, как в своё время проделали с харденингом.
Примерно так. Если VBox нужен просто чтобы поиграться, то да, можно брать последнюю версию и если что не так, откатываться на предыдущую линейку. Лучше предварительно пробежаться по форумам и багтрекеру, оценить наиболее критичные проблемы. Некоторые версии лучше обойти стороной, как ту же 7.1.6.
У каждой мажорной версии есть определённый срок поддержки, в течение которого продолжают выпускаться обновления с наиболее важными исправлениями. Сейчас актуальной линейкой считается 7.1, но 7.0 тоже продолжает поддерживаться. На этот раз были выпущены 7.0.24 и 7.1.6. Предыдущее обновление включало в себя 7.0.22 и 7.1.4, также выпущенные одновременно (просто их новостная лента показывает лишь три последних записи).
Это принципиальное архитектурное ограничение. WSL2, в отличие от WSL1, использует полноценный гипервизор, захватывающий аппаратную виртуализацию. А она работает лишь в эксклюзивном режиме. Если один гипервизор её захватил, никакой другой воспользоваться ей уже не сможет.
Этот "очень медленный" режим — это экспериментальная функция: когда VBox обнаруживает, что Hyper-V захватил виртуализацию, он пытается запускать свои машиины через Hyper-V вместо использования своего родного гипервизора. Пока что получается плохо, но по-другому вообще никак. Раньше в VBox'е имелась софтовая виртуализация, но она была очень ограниченной по возможностям и не поддерживала 64-битных гостей и многопроцессорность. С версии 6.1 её полностью выпилили.
В полном списке изменений упоминается, что переделали систему установки драйверов для хоста и гостя. Подробности не раскрываются, но народ уже жалуется, что в устаревших гостевых виндах дрова не ставятся совсем (XP, 7, 8.1).
Это понятно, что в норме он там не нужен — потому и возник вопрос, откуда всё-таки в коде взялся break и для чего его туда засунули. Конечно, есть вариант, что писал сишник, привыкший ставить брейки, но ведь могли быть и другие причины…
Я не отрицаю, что читаемость важна. Я пытаюсь сказать, что читаемость — субъективное понятие, зависящее в числе прочего от квалификации читающего. Невозможно подогнать формат кода под любого будущего чтеца. А попытки облегчить читаемость кода путём избавления от невразумительных (точнее, кому-то кажущихся невразумительными) конструкций могут привести прямо к противоположному эффекту, когда вместо одной простенькой операции, о которой можно прочесть в мануале, читателю придётся разгребать полстраницы кода, делающего то же самое. Пускай даже очень грамотно написанного и понятного кода, но полстраницы — это полстраницы.
А вот тут всё совсем не так просто. Чем короче код, тем быстрее его можно охватить взглядом, просто за счёт меньшего объёма исходных данных. То есть при прочих равных (очень важное уточнение!) более короткий код выигрывает у длинного.
Но возьмём следующий пример. Какая из двух строчек тут быстрее читается и понимается?
Очевидно, вторая. Но очень легко представить аргументацию вида: вторая строчка использует какой-то странный оператор, который не все могут знать и помнить наизусть, а первая строчка совершенно чётко описывает действие на всем понятном языке. То есть такое сокращение вредит и ухудшает поддерживаемость кода, и в серьёзных проектах надо всем от него отказаться.
Я специально взял такой утрированный пример, ибо сложно представить программиста на C, который не знает про инкремент. И тем не менее, факт остаётся: код упростили, но для его понимания стала требоваться более высокая квалификация, более глубокое знание языка. Так вот, с Перлом всё абсолютно то же самое, просто выражено более явно за счёт большего числа "сахарных" конструкций и меньшего числа людей, которые готовы эти конструкции изучать и осваивать.
Весь вопрос в балансе между читаемостью и краткостью. Но баланс — дело субъективное. Для профессионала нет абсолютно ничего сложного в понимании всяких там $_, $., <>=~/foo/bar/gr, это стандартные типовые конструкции, он ими и сам по двадцать раз на дню пользуется, и в чужом коде постоянно видит, что там может быть непонятного? А кто-то другой смотрит на это нагромождение символов и материт разработчика за совершенно нечитаемый код. Казалось бы, давайте немножко подстроимся в пользу менее квалифицированных разработчиков, будем писать чуть более распространённо? Но для владеющего языком это предложение выглядит точно так же, как для сишника — предложение отказаться от инкремента и писать полные присваивания. В конце концов, для кого-то и регулярные выражения — неподъёмная тема, так что же теперь, от них тоже в своём коде отказываться, переписывая всё на дерево с цепочками сравнений подстрок?..
Какие-то взаимоисключающие параграфы - синтаксический сахар и призван для упрощения и урезания, поэтому не понял почему тут "Но" стоит.
Он сокращает код, но не всегда сокращение равносильно упрощению. Для программиста это требует более глубокого знания языка, а иногда и освоения нестандартных подходов, как скажем, булевый оператор диапазона. А сейчас всем некогда изучать глубоко, надо бегом-бегом клепать под очередной фреймворк, пока он не устарел.
А великий однострочник, хоть и навёл в своё время шороху, но больше из-за методики его применения, чем из-за того, что он перловый. Схожие примеры я видел и для других языков. Как, например, после выхода очередного стандарта C++ народ стебался, что теперь в нём выражение ([](){})() — это осмысленная компилирующаяся синтаксическая конструкция, язык достиг совершенства. Да и в чистом C определения типов порой такие, что никакой Перл с ним не сравнится.
просто часто был свидетелем того, как такие поделки "для себя" потом попадали в большой проект
Опять же, это не специфично для Перла, а происходит с любыми проектами на любых языках.
Это синтаксический сахар. Можно и не использовать, если не нравится. А писать нечитаемый код можно абсолютно на любом языке, это претензия не к языку, а к программистам. И особенно удобно, что перл позволяет делать ибыстро на коленке, чисто для себя, и детально-развёрнуто, для проектов с долгосрочной поддержкой. Подход TIMTOWTDI, There Is More Than One Way To Do It.
Но да, современный мир этого не любит, всем подавай упрощение и урезание.
Создавать окружение не надо, это требуется только в тех сценариях, где необходимо обеспечить фиксированный набор модулей и их версий, заточенный под конкретный скрипт.
Я, например, пишу на перле и на питоне, но когда требуется склепать что-нибудь для себя, первым делом выбираю перл. Во многих сценариях он намного лаконичнее:
my $out = `ls -la`;
die "Oh no, we failed!" if ($?);
import sys
import subprocess
try:
out = subprocess.check_output(['ls', '-la'])
except:
print("Oh no, we failed!")
sys.exit(1)
Кроме того, перл гораздо свободнее в оформлении кода. Добавить отладочные принты с намеренным нарушением отступа, чтобы их потом можно было быстрее найти и удалить? Вставить в произвольное место некий временный кусок кода для какой-нибудь проверки наживую, а потом удалить его, без необходимости каждый раз выравнивать пробелы туда-сюда? Быстро сварганить однострочник для одноразового действия (включающего условные операторы)? Питон тут совсем не помощник.
Разумеется, существует и множество сценариев, где питон выигрывает. Как с любым инструментом, нужно просто оценивать применимость к конкретной задаче.
Будучи сам заядлым перлистом, всё же не могу не отметить, что у динамической типизации есть свои минусы. Во-первых, человеки банально могут ошибаться. Во-вторых, забывать. Попробуй через три года влезть в проект и сходу понять, что там куда и как передаётся. Комментарии, конечно, помогают, но они тоже зачастую пишутся "в моменте" и могут разъяснять совсем не то, что окажется непонятным когда-то в будущем. В-третьих, есть ещё задачи по изучению и поддержке чужого кода, когда надо понять, что за фигня сидит в переменной, а инициализация этой фигни живёт за тридевять прослоек в тридесятом модуле, да ещё и делается по-разному в зависимости от сотен условных веток исполнения.
Были случаи, когда даже по владению недвижкой в Турции отказывались продлять ВНЖ.
Вот только агентессу звали Кора, а не Кира. Кора Орват.
У заметного числа людей она вызвала неприятные проблемы с драйверами на Windows, причём как на хостовой системе, так и в гостевых. Что-то установщик совершенно дикое мутит. Пишут, что во время установки система отключает и переподключает чуть ли не все аппаратные устройства, у некоторых пользователей этот процесс сдох на полпути и часть устройств осталась висеть то ли не подключённой, то ли неопознанной. У других инсталлятор тоже упал, и хотя система осталась жива, сам VBox после этого не удалось ни починить, ни удалить, ни переустановить по-нормальному.
Не знаю, что они там накрутили и зачем; не удивлюсь, если опять какую-то уязвимость нашли и по своей привычке заткнули дыру максимально кривым и уродским способом, как в своё время проделали с харденингом.
Главное, чтобы не в футбольных полях.
Примерно так. Если VBox нужен просто чтобы поиграться, то да, можно брать последнюю версию и если что не так, откатываться на предыдущую линейку. Лучше предварительно пробежаться по форумам и багтрекеру, оценить наиболее критичные проблемы. Некоторые версии лучше обойти стороной, как ту же 7.1.6.
У каждой мажорной версии есть определённый срок поддержки, в течение которого продолжают выпускаться обновления с наиболее важными исправлениями. Сейчас актуальной линейкой считается 7.1, но 7.0 тоже продолжает поддерживаться. На этот раз были выпущены 7.0.24 и 7.1.6. Предыдущее обновление включало в себя 7.0.22 и 7.1.4, также выпущенные одновременно (просто их новостная лента показывает лишь три последних записи).
Ключевые отличия между линейками можно посмотреть в списке изменений для версии 7.1.0:
https://www.virtualbox.org/wiki/Changelog-7.1#v0
Это принципиальное архитектурное ограничение. WSL2, в отличие от WSL1, использует полноценный гипервизор, захватывающий аппаратную виртуализацию. А она работает лишь в эксклюзивном режиме. Если один гипервизор её захватил, никакой другой воспользоваться ей уже не сможет.
Этот "очень медленный" режим — это экспериментальная функция: когда VBox обнаруживает, что Hyper-V захватил виртуализацию, он пытается запускать свои машиины через Hyper-V вместо использования своего родного гипервизора. Пока что получается плохо, но по-другому вообще никак. Раньше в VBox'е имелась софтовая виртуализация, но она была очень ограниченной по возможностям и не поддерживала 64-битных гостей и многопроцессорность. С версии 6.1 её полностью выпилили.
В полном списке изменений упоминается, что переделали систему установки драйверов для хоста и гостя. Подробности не раскрываются, но народ уже жалуется, что в устаревших гостевых виндах дрова не ставятся совсем (XP, 7, 8.1).
Индикатор есть, но чисто графический, чиселки с процентом нет. Как я понял, новость именно о добавлении чиселки. Сформулировано по-дурацки, конечно.
Это понятно, что в норме он там не нужен — потому и возник вопрос, откуда всё-таки в коде взялся break и для чего его туда засунули. Конечно, есть вариант, что писал сишник, привыкший ставить брейки, но ведь могли быть и другие причины…
Я не отрицаю, что читаемость важна. Я пытаюсь сказать, что читаемость — субъективное понятие, зависящее в числе прочего от квалификации читающего. Невозможно подогнать формат кода под любого будущего чтеца. А попытки облегчить читаемость кода путём избавления от невразумительных (точнее, кому-то кажущихся невразумительными) конструкций могут привести прямо к противоположному эффекту, когда вместо одной простенькой операции, о которой можно прочесть в мануале, читателю придётся разгребать полстраницы кода, делающего то же самое. Пускай даже очень грамотно написанного и понятного кода, но полстраницы — это полстраницы.
А вот тут всё совсем не так просто. Чем короче код, тем быстрее его можно охватить взглядом, просто за счёт меньшего объёма исходных данных. То есть при прочих равных (очень важное уточнение!) более короткий код выигрывает у длинного.
Но возьмём следующий пример. Какая из двух строчек тут быстрее читается и понимается?
Очевидно, вторая. Но очень легко представить аргументацию вида: вторая строчка использует какой-то странный оператор, который не все могут знать и помнить наизусть, а первая строчка совершенно чётко описывает действие на всем понятном языке. То есть такое сокращение вредит и ухудшает поддерживаемость кода, и в серьёзных проектах надо всем от него отказаться.
Я специально взял такой утрированный пример, ибо сложно представить программиста на C, который не знает про инкремент. И тем не менее, факт остаётся: код упростили, но для его понимания стала требоваться более высокая квалификация, более глубокое знание языка. Так вот, с Перлом всё абсолютно то же самое, просто выражено более явно за счёт большего числа "сахарных" конструкций и меньшего числа людей, которые готовы эти конструкции изучать и осваивать.
Весь вопрос в балансе между читаемостью и краткостью. Но баланс — дело субъективное. Для профессионала нет абсолютно ничего сложного в понимании всяких там
$_,$.,<>=~/foo/bar/gr, это стандартные типовые конструкции, он ими и сам по двадцать раз на дню пользуется, и в чужом коде постоянно видит, что там может быть непонятного? А кто-то другой смотрит на это нагромождение символов и материт разработчика за совершенно нечитаемый код. Казалось бы, давайте немножко подстроимся в пользу менее квалифицированных разработчиков, будем писать чуть более распространённо? Но для владеющего языком это предложение выглядит точно так же, как для сишника — предложение отказаться от инкремента и писать полные присваивания. В конце концов, для кого-то и регулярные выражения — неподъёмная тема, так что же теперь, от них тоже в своём коде отказываться, переписывая всё на дерево с цепочками сравнений подстрок?..В Паскале/Дельфи такое присвоение, а одиночный = для сравнения и определения типов. Но историю вопроса тоже не знаю.
Так а break-то там в итоге зачем?
Он сокращает код, но не всегда сокращение равносильно упрощению. Для программиста это требует более глубокого знания языка, а иногда и освоения нестандартных подходов, как скажем, булевый оператор диапазона. А сейчас всем некогда изучать глубоко, надо бегом-бегом клепать под очередной фреймворк, пока он не устарел.
А великий однострочник, хоть и навёл в своё время шороху, но больше из-за методики его применения, чем из-за того, что он перловый. Схожие примеры я видел и для других языков. Как, например, после выхода очередного стандарта C++ народ стебался, что теперь в нём выражение
([](){})()— это осмысленная компилирующаяся синтаксическая конструкция, язык достиг совершенства. Да и в чистом C определения типов порой такие, что никакой Перл с ним не сравнится.Опять же, это не специфично для Перла, а происходит с любыми проектами на любых языках.
Это синтаксический сахар. Можно и не использовать, если не нравится. А писать нечитаемый код можно абсолютно на любом языке, это претензия не к языку, а к программистам. И особенно удобно, что перл позволяет делать ибыстро на коленке, чисто для себя, и детально-развёрнуто, для проектов с долгосрочной поддержкой. Подход TIMTOWTDI, There Is More Than One Way To Do It.
Но да, современный мир этого не любит, всем подавай упрощение и урезание.
Создавать окружение не надо, это требуется только в тех сценариях, где необходимо обеспечить фиксированный набор модулей и их версий, заточенный под конкретный скрипт.
Я, например, пишу на перле и на питоне, но когда требуется склепать что-нибудь для себя, первым делом выбираю перл. Во многих сценариях он намного лаконичнее:
Кроме того, перл гораздо свободнее в оформлении кода. Добавить отладочные принты с намеренным нарушением отступа, чтобы их потом можно было быстрее найти и удалить? Вставить в произвольное место некий временный кусок кода для какой-нибудь проверки наживую, а потом удалить его, без необходимости каждый раз выравнивать пробелы туда-сюда? Быстро сварганить однострочник для одноразового действия (включающего условные операторы)? Питон тут совсем не помощник.
Разумеется, существует и множество сценариев, где питон выигрывает. Как с любым инструментом, нужно просто оценивать применимость к конкретной задаче.
Будучи сам заядлым перлистом, всё же не могу не отметить, что у динамической типизации есть свои минусы. Во-первых, человеки банально могут ошибаться. Во-вторых, забывать. Попробуй через три года влезть в проект и сходу понять, что там куда и как передаётся. Комментарии, конечно, помогают, но они тоже зачастую пишутся "в моменте" и могут разъяснять совсем не то, что окажется непонятным когда-то в будущем. В-третьих, есть ещё задачи по изучению и поддержке чужого кода, когда надо понять, что за фигня сидит в переменной, а инициализация этой фигни живёт за тридевять прослоек в тридесятом модуле, да ещё и делается по-разному в зависимости от сотен условных веток исполнения.
Кроме того, есть ещё $#x — последний существующий индекс в массиве @x (== длина минус один).