Вариантов масса, знаете ли. Например диагональ 5" и толщина 10мм, чтобы нормально лежал в руке и нормально вмещал начинку. Например, бОльшая «брусочность». Но все, поголовно все пытаются косить под Эппл. Претензия была не к Эппл, а к остальным брендам, по поводу бездумного копирования.
Я к тому, что эта цепочка версий больше похожа не на 1-2-3-4-5, а 0.2-0.4-0.6-0.8-1.0
Любой другой язык за такие хронические breaking changes давно запинали бы ногами. Вон, Python 3 до сих пор вызывает сопротивление, уже который год.
Не упомянут один важный момент. Почему-то даже в ноутах дороже $1000 часто ставят ужасающий, вырвиглазный TN. А среди среднего и нижнего сегмента ноутбуков с IPS считай что нет. А за глянцевое покрытие на дорогом ноуте так вообще дезигнера убить хочется.
Справедливости ради, TFT (thin film transistor) — это класс почти всех ЖК-дисплеев — и IPS, и TN. Вы наверное с TN перепутали. Хотя, в таком случае получается, что тип матрицы не указали вообще.
Ну и конечно 5-й андроид, когда скоро релизнут 8-й, это просто infinite facepalm. Граждане ASUS, вы чем вообще думаете?
Интересно, когда МС сделают нормальную виртуализацию ресурсов для приложений — чтобы каждое из них сидело в своём маленьком болотце и считало, что кроме него в системе никого нет, и оно работает под админом.
Забавно. Как только сообщество некоего языка узнаёт, что в нём нельзя использовать юникод в идентификаторах, начинаются дикие вопли. При этом то же сообщество считает плохим код с не-английскими идентификаторами, и даже транслит.
Вообще же, как по мне, ключевые слова и идентификаторы должны быть только латиницей, чувствительные к регистру, но при этом с запретом иметь два идентификатора, отличающиеся только регистром букв. А в идеале ещё и линт иметь, считающий расстояние Хэмминга.
Как по мне, вырисовывается вполне себе зависимость, где объём свободно поддерживаемого кода обратно пропорционален условной сложности компилятора
На перле или APL/K (из-за эзотеричности их синтаксиса) легко писать короткострочники, но код средних размеров уже может стать нечитаем. Уточню, что и Перл может быть читаем в среднем объёме, если не использовать "клинопись".
Питон, человеческий перл, яваскрипт и т.п. динамика читаемы и поддерживаемы в рамках среднего объёма (мои наблюдения — в среднем 500, до 1000 значащих строк). И в этом объёме в среднем более продуктивны чем языки со статической типизацией. Так как содежимое модуля и связи внутри вполне можно удержать в голове.
Всё что выше — требует статической типизации, т.к. кол-во связей и общий объём уже таков, что прилетевший из ниоткуда инт вместо строки в рантайме приводит к боли при отладке. А транслятор в этом помогать не желает. И рефакторинг превращается в охоту за тараканами.
А не будет проблем с тамошними джетами, по аналогии с джетами тех же ЧД? Мощность будет, понятно, несравнимая, но аппарату думаю хватит чтобы быстро помереть в плотном потоке заряженных частиц.
Просчёт топологии меша из нескольких десятков тысяч треугольников тоже далеко не "суперсистемная" задача. Автору стоило оговориться, что питон достаточно быстр для типичного сценария вебсайта со сравнительно небольшой БД.
Ваш пример годится только для однострочника, накиданного в командной строке по месту. Как только вы захотите переиспользовать этот код — упрётесь в чтение этой клинописи. Почему-то многие при сравнении "одноразовых" языков и "многоразовых" не учитывают, что сам автор может и не прочитать своё творение через недельку — из-за того, что писал в клинописном стиле.
По поводу use strict/my/our — у меня есть перед глазами замечательный пример в виде основного инструмента, С++. Языка, на 50-60% состоящего из легаси. Можно писать хорошо и красиво — но для этого придётся написать свою мини-обвязку, а также следовать правилам, в порверке которых компилятор вам просто так не поможет. Короткий вывод — есть языки, на которых легко писать криво и неправильно — и есть языки, на которых если писать криво и неправильно, придётся постоянно ублажать компилятор "обходными манёврами".
Дело вкуса и подхода. Я скорее пишу первичный каркас, на который навешиваю дополнительные плюшки и рефакторю по мере необходимости. Вот в процессе такой "перестройки" система типов помогает очень сильно.
Я сталкивался с подобным. Конечно подобные баги "мучили" меня не неделю и не день, а часа 2-3. Но осадочек остался. По поводу аннотаций — я работал с 2.7, и скрипт был подсобный, для прогона своего рода интеграционных тестов. Собственно, я столкнулся с неприятностями на немного извратном сравнении двух JSON документов.
Порог на один файл, и конечно очень условно. За счёт того, что питон таки умеет инкапсулцию на уровне файлов. Читаемым и легко поддерживаемым может быть и 1000-строчный скрипт.
Я вас огорчу, это не полиморфизм. Это, по сути:
В оригинальной статье был ещё небольшой раздельчик, что выкинули. В частности:
Вопрос — зачем он теперь такой нужен?
Ах да. Хайп «нет аудиоджеку». Повбывав бы.
Я к тому, что эта цепочка версий больше похожа не на 1-2-3-4-5, а 0.2-0.4-0.6-0.8-1.0
Любой другой язык за такие хронические breaking changes давно запинали бы ногами. Вон, Python 3 до сих пор вызывает сопротивление, уже который год.
Мне одному кажется, что Свифт слегка недопилен? Особенно как для 3-й версии.
Подозреваю, проблема в том, что JS ставит их там где не надо.
Не упомянут один важный момент. Почему-то даже в ноутах дороже $1000 часто ставят ужасающий, вырвиглазный TN. А среди среднего и нижнего сегмента ноутбуков с IPS считай что нет. А за глянцевое покрытие на дорогом ноуте так вообще дезигнера убить хочется.
Ну и конечно 5-й андроид, когда скоро релизнут 8-й, это просто infinite facepalm. Граждане ASUS, вы чем вообще думаете?
Забавно. Как только сообщество некоего языка узнаёт, что в нём нельзя использовать юникод в идентификаторах, начинаются дикие вопли. При этом то же сообщество считает плохим код с не-английскими идентификаторами, и даже транслит.
Вообще же, как по мне, ключевые слова и идентификаторы должны быть только латиницей, чувствительные к регистру, но при этом с запретом иметь два идентификатора, отличающиеся только регистром букв. А в идеале ещё и линт иметь, считающий расстояние Хэмминга.
Как по мне, вырисовывается вполне себе зависимость, где объём свободно поддерживаемого кода обратно пропорционален условной сложности компилятора
Просчёт топологии меша из нескольких десятков тысяч треугольников тоже далеко не "суперсистемная" задача. Автору стоило оговориться, что питон достаточно быстр для типичного сценария вебсайта со сравнительно небольшой БД.
Ваш пример годится только для однострочника, накиданного в командной строке по месту. Как только вы захотите переиспользовать этот код — упрётесь в чтение этой клинописи. Почему-то многие при сравнении "одноразовых" языков и "многоразовых" не учитывают, что сам автор может и не прочитать своё творение через недельку — из-за того, что писал в клинописном стиле.
По поводу use strict/my/our — у меня есть перед глазами замечательный пример в виде основного инструмента, С++. Языка, на 50-60% состоящего из легаси. Можно писать хорошо и красиво — но для этого придётся написать свою мини-обвязку, а также следовать правилам, в порверке которых компилятор вам просто так не поможет. Короткий вывод — есть языки, на которых легко писать криво и неправильно — и есть языки, на которых если писать криво и неправильно, придётся постоянно ублажать компилятор "обходными манёврами".
Дело вкуса и подхода. Я скорее пишу первичный каркас, на который навешиваю дополнительные плюшки и рефакторю по мере необходимости. Вот в процессе такой "перестройки" система типов помогает очень сильно.
Я сталкивался с подобным. Конечно подобные баги "мучили" меня не неделю и не день, а часа 2-3. Но осадочек остался. По поводу аннотаций — я работал с 2.7, и скрипт был подсобный, для прогона своего рода интеграционных тестов. Собственно, я столкнулся с неприятностями на немного извратном сравнении двух JSON документов.
Порог на один файл, и конечно очень условно. За счёт того, что питон таки умеет инкапсулцию на уровне файлов. Читаемым и легко поддерживаемым может быть и 1000-строчный скрипт.