Кстати, а существуют ли словари (англо-русские например), в которых слова объединены в ассоциативную сеть по различным признакам:
* похожести звучания
* похожести написания
* общей этимологии (как licence, leisure и pleasure в статье)
и тому подобное?
Вообще это чрезвычайно интересно — слова, у которых есть «интересная история», запоминаются гораздо лучше чем просто тупое заучивание пар «слово на английском-слово на русском». Можно легко запоминать целые кластеры слов с общей этимологией, опираясь именно на этимологию как на осмысленный и интересный контент. Можно изучать сразу несколько языков — ведь на самом деле очень многие слова имеют общее происхождение.
Цивилизация это не раковая опухоль, чтобы забивать собой всю галактику. Цивилизация стремится не к неограниченной экспансии, а к достижению равновесия. Весьма вероятно, что грандиозная космическая деятельность для этого просто не нужна. Постижение фундаментальных законов физики может открыть перед цивилизацией возможности, по сравнению с которыми колонизация космоса так же бессмысленна, как скажем постановка на кадастровый учет каждой песчинки в пустыне. Вообще, мысли о галактических империях напоминают мне Лондон, погребенный под кучами конского навоза. Т.е. некорректную футурологическую экстраполяцию без понимания сути явлений.
Впрочем, нам до всего этого еще далеко.
Отличная тема! Я об этом много думал и сейчас иногда думаю.
В общем, если брать пример с книгами, то наверное базовая иерархия все-же нужна, но и теги нужны тоже. Например, «Программирование» и «Qt» это не равноправные теги: «программирование» однозначно тег верхнего уровня, «Qt» — вложенный тег (причем между ними еще должен быть тег «C++»). Однако часто бывают ситуации когда теги действительно равноправны. Наиболее очевидный пример — статьи со сравнением двух технологий. Также — некая взаимосвязь технологий (когда одна используется для другой). Книги по программированию микроконтроллеров относятся одинаково и к программированию на конкретном языке (скажем Си), и к микроконтроллерам конкретного типа. Книги по программированию под некую ОС (Windows, Linux) — одинаково к программированию на языке (скажем С++) и программированию под ОС.
Проблема еще в современных файловых системах. Они совсем не базы данных. Хотя где-то там, внутри, у них есть какие-то дополнительные возможности типа хардлинков, симлинков и файловых потоков, этого все равно недостаточно. Но некоторые задачи можно решить с их помощью. От иерархической файловой системы все равно никуда не деться, и поддерживать на диске порядок в виде документов, сгруппированных в иерархической системе папок — это правильно. В Либгене например имена книг — это просто md5 хеши, все файлы лежат в куче, и найти что-то без софта просто невозможно. ИМХО, это не есть хорошо, это просто снижает надежность системы — если софт или база сломается, то найти что-либо не удастся в принципе (и вот кстати отличный пример применения файловых потоков или расширенных атрибутов — все хеши должны храниться именно там, а не в имени файла; также как и вся метаинформация типа автора, года издания и языка).
Ну и есть еще множество аспектов, тут надо целую статью писать, в комментарий не влезет. Сейчас, вспоминая свои заметки по этому вопросу, я отмечу лишь мысль о необходимости объединения подходов с иерархией и с тегами.
Базовая иерархия нужна — у каждого документа есть базовое место в ФС («главный тег»);
Если у документа два равноправных места в ФС, то применяется хардлинк;
Также у документа есть теги, позволяющие более точно описать документ, построить граф связей, определить место документа в поисковой выдаче и т.д.
Единственное правильное направление — децентрализованная сеть, в которой происходит непрерывный обмен как документами (книги, статьи, разумеется только то что пользователь расшарил) так и метаинформацией о них. В этом случае метаинформация никогда не пропадет — она будет храниться оффлайн у тысяч, а то и миллионов пользователей, и силами этих пользователей постоянно обновляться и совершенствоваться.
То что драйвера семерки не работают в десятке это кстати тоже проблемы модульности. Как и то что драйвера семерки или десятки не работают в линуксе.
Да, это проблемы другого уровня (отсутствие стандартизированного на уровне ISO интерфейса драйвера, отсутствие возможности автогенерации адаптера драйвера для конкретной ОС по метаинформации, хранящейся в драйвере).
Я например узнал очень полезную информацию — что оказывается в США есть люди, сохраняющие терабайтные архивы с разных сайтов и соцсетей. Я думал, что такие энтузиасты-романтики сейчас уже не встречаются.
Все это наводит на мысль о недостаточной модульности ядра и недостаточной поддержке модульности со стороны языка Си. Зачем удалять, если оно работает? Любой новый код по идее вообще никак не должен влиять на старый.
Я не против чтобы было и 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, а именно язык как таковой.
* похожести звучания
* похожести написания
* общей этимологии (как licence, leisure и pleasure в статье)
и тому подобное?
Вообще это чрезвычайно интересно — слова, у которых есть «интересная история», запоминаются гораздо лучше чем просто тупое заучивание пар «слово на английском-слово на русском». Можно легко запоминать целые кластеры слов с общей этимологией, опираясь именно на этимологию как на осмысленный и интересный контент. Можно изучать сразу несколько языков — ведь на самом деле очень многие слова имеют общее происхождение.
Я имел в виду оффлайн хранение данных и обмен метаинформацией в p2p сети.
Впрочем, нам до всего этого еще далеко.
В общем, если брать пример с книгами, то наверное базовая иерархия все-же нужна, но и теги нужны тоже. Например, «Программирование» и «Qt» это не равноправные теги: «программирование» однозначно тег верхнего уровня, «Qt» — вложенный тег (причем между ними еще должен быть тег «C++»). Однако часто бывают ситуации когда теги действительно равноправны. Наиболее очевидный пример — статьи со сравнением двух технологий. Также — некая взаимосвязь технологий (когда одна используется для другой). Книги по программированию микроконтроллеров относятся одинаково и к программированию на конкретном языке (скажем Си), и к микроконтроллерам конкретного типа. Книги по программированию под некую ОС (Windows, Linux) — одинаково к программированию на языке (скажем С++) и программированию под ОС.
Проблема еще в современных файловых системах. Они совсем не базы данных. Хотя где-то там, внутри, у них есть какие-то дополнительные возможности типа хардлинков, симлинков и файловых потоков, этого все равно недостаточно. Но некоторые задачи можно решить с их помощью. От иерархической файловой системы все равно никуда не деться, и поддерживать на диске порядок в виде документов, сгруппированных в иерархической системе папок — это правильно. В Либгене например имена книг — это просто md5 хеши, все файлы лежат в куче, и найти что-то без софта просто невозможно. ИМХО, это не есть хорошо, это просто снижает надежность системы — если софт или база сломается, то найти что-либо не удастся в принципе (и вот кстати отличный пример применения файловых потоков или расширенных атрибутов — все хеши должны храниться именно там, а не в имени файла; также как и вся метаинформация типа автора, года издания и языка).
Ну и есть еще множество аспектов, тут надо целую статью писать, в комментарий не влезет. Сейчас, вспоминая свои заметки по этому вопросу, я отмечу лишь мысль о необходимости объединения подходов с иерархией и с тегами.
Базовая иерархия нужна — у каждого документа есть базовое место в ФС («главный тег»);
Если у документа два равноправных места в ФС, то применяется хардлинк;
Также у документа есть теги, позволяющие более точно описать документ, построить граф связей, определить место документа в поисковой выдаче и т.д.
Да, это проблемы другого уровня (отсутствие стандартизированного на уровне ISO интерфейса драйвера, отсутствие возможности автогенерации адаптера драйвера для конкретной ОС по метаинформации, хранящейся в драйвере).
Реальные сценарии использования для меня — это главным образом чтение и редактирование текстов.
Но вот нет.
Я не так давно озадачился гораздо более простой штукой: смартфоном с торцевой камерой (т.е. с дополнительной камерой, расположенной на переднем торце, как ИК-светодиод у пульта ДУ). И даже этого нет.
Фантазия у разработчиков железа совсем иссякла.
А в 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 вроде бы нет явного связывания переменных, как в С++ (в квадратных скобках).
Также не нравится применение символа "|" в паттерн-матчинге. Это же всегда было «Битовое ИЛИ», зачем его мешать сюда? Чем запятая не угодила?
С использованием :: наверное авторы правы, хотя мне не нравится. Опять же — недостаточно спецсимволов!
Использование угловых скобок — с одной стороны наверное это выразительно, но всем известно про то что они путаются с символами «меньше» и «больше», и для парсера это тоже может быть проблемой. Опять же нехватка спецсимволов.
Для «цитирования» кода в макросах тоже не помешали бы особые, уникальные скобки-кавычки. Ну и т.д.