Я не против чтобы было и 12 дюймов. Такой планшет с «альбомным» захватом и небольшой клавиатурой по бокам экрана, для набора преимущественно большими пальцами рук. Но вполне можно и меньше чем 12. Если ОС специальная (тот же Андроид), то и софт для такой железки специальный. Полноценную винду или линукс никто запускать там не собирается.
Реальные сценарии использования для меня — это главным образом чтение и редактирование текстов.
Было бы хорошо, если бы такие штуки как Atari Portfolio (или скажем Samsung Q1 Ultra, мне больше нравится его концепция клавиатуры для ультрапортативного использования, т.е. «на ходу») производили на современном железе и современных ОС.
Но вот нет.
Я не так давно озадачился гораздо более простой штукой: смартфоном с торцевой камерой (т.е. с дополнительной камерой, расположенной на переднем торце, как ИК-светодиод у пульта ДУ). И даже этого нет.
Фантазия у разработчиков железа совсем иссякла.
В D действительно правильно сделано. И в Rust этот подход кстати тоже применен — для атрибутов: символ # изменяет логику квадратных скобок
#[test]
fn test_foo() {
/* ... */
}
А в C# сделано неправильно. Там есть оператор switch, его и нужно было расширять — разрешить ему возвращать значения, расширить синтаксис case-образцов и всё остальное, а они вместо этого взяли и ввели альтернативный синтаксис, совершенно ни на что не похожий. В конце концов, можно было бы кроме switch добавить еще match, в котором не требуется break после каждого case; но в остальном и switch и match должны обладать одинаковыми возможностями. Это логично, подобно тому как скажем циклы while и do..while существуют одновременно и отличаются только в одном аспекте.
На большинстве клавиш по 3 символа. Вполне влезет и 4.
Но кстати, какие у них интересные есть символы — полускобочки двух видов, еще одни «панциреобразные» скобочки ❲ ❳
В принципе, такие бы всем непомешали, соответственно этим ребятам свободных клавиш понадобилось бы меньше:)
Не, не подтянутся. Программисты это слишком малая часть пользователей клавиатур. Боюсь, уже поздно, а вот предлагаемая мной модификация Unicode, будь она сделана сразу в 1991 году, может и помогла бы.
Ну есть в этом что-то логичное и правильное — «законодательно» разделить все символы на 3 группы: «международные», «национальные» и «дополнительные». И сделать так, чтобы «международные» кодировались 1 байтом даже в utf-8 (и заодно у производителей клавиатур появилась бы мотивация их наносить на клавиши), «национальные» укладывались в два байта utf-16 (кодовую плоскость, если я не ошибаюсь), а всякие эмодзи и древние алфавиты — всё остальное.
А первые 32 байта ASCII как раз не используются, кроме нуля, пробела, переносов строк и табов. Совместимость с древними телетайпами вряд ли кому нужна.
Интересная тема.
Во-первых, конечно, любому современному сложному языку программирования не хватает спецсимволов. Тех же скобок, например, чтобы не использовать знаки «больше» и «меньше» в качестве скобок. Да, есть целый Unicode, но нужно чтобы эти символы были на всех клавиатурах мира — а значит, мы опять возвращаемся к ASCII. Наверное, неплохим решением было бы, если бы консорциум Unicode выделил 20 наиболее важных символов и предложил бы наносить их на все клавиатуры на буквенные клавиши (возможно потребовался бы еще один Shift). Для полной совместимости с ASCII можно было бы даже
продублировать их в начале ASCII, в кодах 0x01..0x1F (исключая POSIX-символы переносов строки, табуляций и чего-то там еще). Но такое чудо вряд ли случится:)
Фигурные скобки и точка с запятой нужны. Это именно то, что позволяет структурировать код явно, не надеясь на невидимые пробелы и табы, как это принято в Python, а также make-файлах и еще каких-то древних форматах.
Постфиксная запись типа… ну лично мне не нравится. Но наверное авторы правы. Смысл var и let я понимаю, ключевые слова, предваряющие введение новых имен, должны быть обязательно.
Сокращения в ключевых словах это хорошо, особенно fn. Это лучше чем функции в C/C++ без ключевых слов вообще. Значительно упрощает работу парсера. А вот стрелки в сигнаруте функций… в Go вообще обошлись без спецсимволов там. Просто возвращаемый тип после скобок с аргументами.
Замыкания — нет, не нравятся. Я бы вообще не стал делить функции на обычные и замыкания, использовал бы везде fn как универсальное ключевое слово. Кстати, в Rust вроде бы нет явного связывания переменных, как в С++ (в квадратных скобках).
Также не нравится применение символа "|" в паттерн-матчинге. Это же всегда было «Битовое ИЛИ», зачем его мешать сюда? Чем запятая не угодила?
match x {
1 | 2 => println!("one or two"), // ну и что это такое? "Битовое или" или несколько аргументов матчинга?
_ => println!("anything"),
}
С использованием :: наверное авторы правы, хотя мне не нравится. Опять же — недостаточно спецсимволов!
Использование угловых скобок — с одной стороны наверное это выразительно, но всем известно про то что они путаются с символами «меньше» и «больше», и для парсера это тоже может быть проблемой. Опять же нехватка спецсимволов.
Для «цитирования» кода в макросах тоже не помешали бы особые, уникальные скобки-кавычки. Ну и т.д.
ИМХО, если уж ехать, то куда нибудь где совсем тепло и вечное лето. В Европе цивилизованное общество, но все-же есть и осень и зима. Есть много стран где вечное лето, но нет цивилизации. На пересечении этих множеств остается не так уж и много.
Хочется поздравить всех причастных, ведь в конечном итоге без информационных технологий в широком смысле слова современные и будущие биотехнологии были бы невозможны!
Кстати, а в какой книге по Swift (на русском) наиболее полное описание самого языка? Меня интересует не с точки зрения разработки под iOS, а именно язык как таковой.
У меня в детстве тоже основным развлечением были настольные игры, их придумывание, анализ и т.п. В «двойные шахматы» играл (доска 16*16 и два набора фигур).
Но в конечном итоге компьютеры и программирование оказались гораздо интереснее:)
Интересно, а на пенсии можно стать цифровым кочевником? Или хотя-бы просто свалить в теплую страну и жить там постоянно, пусть и без кочевничества, но чтобы было вечное лето. Бывают такие прецеденты?
Мне до пенсии еще далеко, но и «средний возраст кочевника» уже давно позади:)
Достаточно уровня языка Си. Полноценный Ассемблер нужен крайне редко — возможно тогда, когда используются специальные системные команды для уровня ядра.
А по поводу накручивания абстракций, я еще 5 лет назад писал статью.
Например, в случае сборщика мусора: если он есть и прибит гвоздями к языку (как в Go или D) — язык уже не может быть «системным». Если его нет вообще — это неудобно для высокоуровневого программирования (как в С++). А вот если он есть, но в виде «расширения», которое можно включить или отключить в свойствах проекта — это совсем другое дело.
Это как раз фигня для низкоуровневого языка. Основные недостатки ИМХО — древний препроцессор и система инклудов вместо синтаксических макросов и модулей, немного слабоватая система типов (в С++ лучше и близко к оптимальной, в Rust уже ИМХО перебор со строгостью), некоторые нелогичности вроде «имя массива это адрес первого элемента массива», что мешает массивам быть «first-class objects». Еще явный ляп — приоритет битовых операций ниже чем у операций сравнения.
Вроде существуют сверхмассивные черные дыры с очень низкой плотностью, пересечение горизонта событий которых для наблюдателя происходит без разрушительных последствий. Вот пересечет наблюдатель такой горизонт — и что он увидит? Голую сингулярность?
Кстати, как вообще распространяется свет внутри горизонта? Сам горизонт — это тонкая граница (сфера) или сплошная "заполненная" область пространства (шар)?
Я не помню предлагал ли я это при обсуждении)
Но подумалось что флиппер напоминает чем-то плеер, и соответственно напрашивается наличие аудиовыхода для наушников и собственно функция плеера, а также радиосканнер с возможностью прослушивания некоторого диапазона частот «на слух» (а может и записи в аудиофайл). Без передачи, только прием. Вроде бы в этой версии такой функциональности нет (но как я понимаю, у вас еще есть Filpper One) А вообще имеет ли смысл такая функциональность сейчас, в эпоху цифровой связи?
Реальные сценарии использования для меня — это главным образом чтение и редактирование текстов.
Но вот нет.
Я не так давно озадачился гораздо более простой штукой: смартфоном с торцевой камерой (т.е. с дополнительной камерой, расположенной на переднем торце, как ИК-светодиод у пульта ДУ). И даже этого нет.
Фантазия у разработчиков железа совсем иссякла.
А в C# сделано неправильно. Там есть оператор switch, его и нужно было расширять — разрешить ему возвращать значения, расширить синтаксис case-образцов и всё остальное, а они вместо этого взяли и ввели альтернативный синтаксис, совершенно ни на что не похожий. В конце концов, можно было бы кроме switch добавить еще match, в котором не требуется break после каждого case; но в остальном и switch и match должны обладать одинаковыми возможностями. Это логично, подобно тому как скажем циклы while и do..while существуют одновременно и отличаются только в одном аспекте.
Но кстати, какие у них интересные есть символы — полускобочки двух видов, еще одни «панциреобразные» скобочки ❲ ❳
В принципе, такие бы всем непомешали, соответственно этим ребятам свободных клавиш понадобилось бы меньше:)
А первые 32 байта ASCII как раз не используются, кроме нуля, пробела, переносов строк и табов. Совместимость с древними телетайпами вряд ли кому нужна.
Во-первых, конечно, любому современному сложному языку программирования не хватает спецсимволов. Тех же скобок, например, чтобы не использовать знаки «больше» и «меньше» в качестве скобок. Да, есть целый Unicode, но нужно чтобы эти символы были на всех клавиатурах мира — а значит, мы опять возвращаемся к ASCII. Наверное, неплохим решением было бы, если бы консорциум Unicode выделил 20 наиболее важных символов и предложил бы наносить их на все клавиатуры на буквенные клавиши (возможно потребовался бы еще один Shift). Для полной совместимости с ASCII можно было бы даже
продублировать их в начале ASCII, в кодах 0x01..0x1F (исключая POSIX-символы переносов строки, табуляций и чего-то там еще). Но такое чудо вряд ли случится:)
Фигурные скобки и точка с запятой нужны. Это именно то, что позволяет структурировать код явно, не надеясь на невидимые пробелы и табы, как это принято в Python, а также make-файлах и еще каких-то древних форматах.
Постфиксная запись типа… ну лично мне не нравится. Но наверное авторы правы. Смысл var и let я понимаю, ключевые слова, предваряющие введение новых имен, должны быть обязательно.
Сокращения в ключевых словах это хорошо, особенно fn. Это лучше чем функции в C/C++ без ключевых слов вообще. Значительно упрощает работу парсера. А вот стрелки в сигнаруте функций… в Go вообще обошлись без спецсимволов там. Просто возвращаемый тип после скобок с аргументами.
Замыкания — нет, не нравятся. Я бы вообще не стал делить функции на обычные и замыкания, использовал бы везде fn как универсальное ключевое слово. Кстати, в Rust вроде бы нет явного связывания переменных, как в С++ (в квадратных скобках).
Также не нравится применение символа "|" в паттерн-матчинге. Это же всегда было «Битовое ИЛИ», зачем его мешать сюда? Чем запятая не угодила?
С использованием :: наверное авторы правы, хотя мне не нравится. Опять же — недостаточно спецсимволов!
Использование угловых скобок — с одной стороны наверное это выразительно, но всем известно про то что они путаются с символами «меньше» и «больше», и для парсера это тоже может быть проблемой. Опять же нехватка спецсимволов.
Для «цитирования» кода в макросах тоже не помешали бы особые, уникальные скобки-кавычки. Ну и т.д.
Но в конечном итоге компьютеры и программирование оказались гораздо интереснее:)
Мне до пенсии еще далеко, но и «средний возраст кочевника» уже давно позади:)
А по поводу накручивания абстракций, я еще 5 лет назад писал статью.
Например, в случае сборщика мусора: если он есть и прибит гвоздями к языку (как в Go или D) — язык уже не может быть «системным». Если его нет вообще — это неудобно для высокоуровневого программирования (как в С++). А вот если он есть, но в виде «расширения», которое можно включить или отключить в свойствах проекта — это совсем другое дело.
Вроде существуют сверхмассивные черные дыры с очень низкой плотностью, пересечение горизонта событий которых для наблюдателя происходит без разрушительных последствий. Вот пересечет наблюдатель такой горизонт — и что он увидит? Голую сингулярность?
Кстати, как вообще распространяется свет внутри горизонта? Сам горизонт — это тонкая граница (сфера) или сплошная "заполненная" область пространства (шар)?
Путин властелин мира mp4
Но подумалось что флиппер напоминает чем-то плеер, и соответственно напрашивается наличие аудиовыхода для наушников и собственно функция плеера, а также радиосканнер с возможностью прослушивания некоторого диапазона частот «на слух» (а может и записи в аудиофайл). Без передачи, только прием. Вроде бы в этой версии такой функциональности нет (но как я понимаю, у вас еще есть Filpper One) А вообще имеет ли смысл такая функциональность сейчас, в эпоху цифровой связи?