Ваш вариант самый крутой, умножение заменить сдвигом еще. Вариант с массивом чисел самый очевидный, но закодировать количества дней в 32-битное число — просто и гениально, в стиле олдскульной оптимизации, когда каждый байт был на счету.
Тем что при редактировании можно случайно стереть, например, меню программы? Я где-то читал про acme, именно это отмечалось как основная странная особенность. Вот сотрете вы меню, и — не зная команд — что будете делать? Интерфейс все-же должен иметь «защиту от дурака».
Собственно эта же проблема имеет место со всякими vim, из которых никто не знает как первый раз выйти: командный интерфейс мешается с рабочим пространством (в данном случае областью для ввода текста).
Подумал над статьей, и получается что из этого «притяжения будущего» не следует никакая свобода воли. Такая же детерминированность, только информация движется против оси времени (что кстати противоречит принципу причинности). Все те же контуры обратной связи, что формируют сознание в классической интерпретации, только теперь они у вас работают сквозь время.
Ну да ладно, статья как я понимаю не о принципах причинности, а о свободе воли… «Чистая» свобода воли возможна, если только она будет базовым, неразделяемым на составные части понятием — как «душа» в религиях. Иначе — или детерминированность, или случайность.
Похоже этот «текст как интерфейс» весьма любопытная штука. Необычная ветвь развития интерфейсов… вроде и не классическая юниксовая командная строка, но и не привычный всем GUI, а что-то еще, совершенно особенное.
Как я могу предположить, это и есть «интерпретации»: транзакционная — фотон что-то там получает из будущего, многомировая — фотон одновременно пролетает через обе щели, но при наличии датчиков одна версия фиксируется, а другая отменяется.
Устройство по сути своей одноразовое. То есть такие удлинители wi-fi должны стоить копейки, чтобы их можно было оставить где-нибудь в туалете библиотеки и больше за ним не возвращаться (потому что в случае обнаружения вполне могут отследить того кто устройство забирает)
Второе — источник питания, с этим в общественных местах могут быть проблемы. А аккумулятора ненадолго хватит.
Подумалось что было бы удобно ставить такие штуки в номерех гостиниц — там и бесплатный wi-fi есть, и можно, находясь в номере, спокойно без свидетелей смонтировать устройство где-нибудь в вентиляции, и запитать скрытно от проводки:)
С Project Ara сразу было понятно, смартфоны — все-же слишком «попсовая» вещь, чтобы быть модульными.
Вот возродили бы старый, но незаслуженно забытый класс устройств — UMPC, с возможностью модульности… пусть аудитория была бы меньше, но востребованность модульности как фичи была бы больше.
Я скачиваю картинку не с фотобанка, а с google.images (как правило она туда попадает не из фотобанка, а уже с какого-то сайта где ее используют). Кстати, нередко бывает что одна и та же картинка в нескольких фотобанках.
Время (абсолютное, с часами, минутами, секундами) нужно для людей. Чтобы человек посмотрел на время создания файла, время события в логе — и ему что-то стало понятно.
А компьютеру время не должно быть нужно, компьютеру должен быть важен логический порядок событий. А если компьютеры начинают использовать абсолютное время как основной (или даже единственный) источник для синхронизации каких-то событий в вычислительных сетях, то это плохо… архитектурно плохо. Вся синхронизация должна быть на транзакциях, а не на времени.
А вы написали про отказ от традиционного времени для людей, что совершенно ненужно — люди как ориентировались на вращение Земли, так и будут.
А мне вот непонятно, как так можно написать софт, чтобы из-за какой-то секунды все зависало на несколько дней??? Как по мне, так время для компьютерных систем это вообще некий «внешний физический маркер», который должен иметь смысл лишь для пользователя (время создания файла, завершения транзакции и т.д.), все остальное должно происходить без привязки к абсолютному времени и иметь внутренние средства синхронизации (порядковые номера пакетов в сети и т.п.).
Появление лишней секунды в системе должно интерпретировться так, как будто за секунду произошло в два раза больше событий. Ну и что? В реальной жизни при высоких нагрузках такого разве не может быть? Тем более всего лишь секунда, а реальные высокие нагрузки могут длиться часами.
А как например быть с фотобанками разных изображений (это не всегда фотографии, это могут быть и художественные работы). Они обычно предлагают купить картинки в хорошем разрешении, но при этом в инете (google.images, yandex.images...) можно найти массу картинок (иногда в маленьком разрешении, иногда с какими-то водяными знаками), которые я вполне могу сохранить к себе на диск. И если мне не нужны никакие высокие разрешения, можно ли использовать эти маленькие картинки в некоммерческих целях (допустим, многие используют их как КДПВ к статье на Хабре, или в любом другом блоге)?
C++ проектировался очень давно, на основе еще более древнего Си (который сам по себе содержит массу архитектурных решений, которые в современном мире выглядят как ошибки), метапрограмминг на шаблонах С++ получился «случайно» и только потом язык стали ориентировать на эту возможность (но все равно там очень много случайных по сути решений).
Go проектировался с нуля значительно позже С++, с учетом огромного опыта проектирования других языков. Но, как уже было сказано, в Go нет очень многих фич.
Тут некоторое время назад была серия статей про Оберон, где автор утверждал что минимум фич (и ключевых слов заодно) это хорошо. Хотя по факту там нет почти ничего, кроме старого процедурного программирования.
В общем, сравнивая количество ключевых слов, языки сравнивать совершенно некорректно. Нужно рассматривать семантику языков, их суть.
Автоматически конечно не измерить, но экспертная оценка вполне возможна. Языков много, и если мы рассматриваем равнозначные по охвату и функционалу — то и наборы возможностей у них вполне сравнимы.
Сравнение конечно ни о чем, но забавное:)
Я бы еще добавил, что примитивная «простота» — не главное в языке. Это слишком однобокий критерий. Например, количество ключевых слов должно быть не большим и не маленьким, оно должно быть соответствующим внутренней логике языка. Количество роли не играет вообще. Применение одного и того же ключевого слова для разных целей (чем грешит тот же С++ ради «совмесимости с legacy кодом») не есть хорошо. Когда ключевыми словами обозначается все подряд — тоже плохо.
Главное в языке — внутренняя стройность и логичность, отсутствие «белых пятен» в плане фич. Я уже писал об этом здесь — если в языке чего-то нет, программисты все равно это сделают, но оно будет не органично встроено в язык, а прикручено сбоку изолентой (C++/Boost), что сильно отрицательно скажется на удобстве использования.
А еще он депутат, и обладает какой-то властью. Его приглашают на телевидение, и журналисты на полном серьезе обсуждают его предложения, причем не критикуют, а наоборот выражают ему поддержку. Иногда одного мракобеса достаточно, чтобы скатить целый народ в мракобесие. Вспомните гитлеровскую Германию или сталинские репрессии в СССР. Да даже американский маккартизм…
Ведь ломать — не строить. Выстраивать толерантное, неагрессивное и умное общество очень сложно, на это у многих цивилизаций уходили столетия, если не тысячелетия… а разжечь костер ненависти, агрессии и разных фобий — элементарно просто.
Сообщество должно знать какие люди у нас во власти.
И сообщество должно на это реагировать.
Очень интересно наблюдать за развития информационных технологий… История таки развивается по спирали, на каждом витке дополняясь чем-то качественно новым.
Сначала были текстовые консольные интерфейсы.
Затем появились графические интерфейсы. Сначала — как вспомогательный режим, который нужно было запустить чтобы посмотреть картинку… после чего они поменялись местами, и теперь консоли — текстовые «окошки» в графическом окружении…
Затем браузеры. Сначала — просто одна из программ графического интерфейса. Со временем они становятся все более значимыми, и постепенно берут на себя функциональность рабочего стола как такового… И вот уже приложения, игры и даже трехмерная графика существует в браузерах, приложения пишутся на html и javascript (хотя еще недавно html — всего лишь язык разметки документов, а javascript — лишь средство создания надоедливых баннеров), появляются целые операционные системы, целиком основанные на браузере и javascript…
Вторая тенденция — виртуализация. В стародавние времена программисты работали напрямую с железом. Затем стали появляться драйверы устройств, API операционной системы, и только единственное устройство — процессор — оставалось доступно для программ напрямую. Но и здесь — Java, .NET, попытки абстрагироваться и от процессора тоже. Собственно, стоило ожидать что с Javascript произойдет что-то подобное, раз этот язык становится новым Си на новом витке развития технологий. Логично, что с помощью WebAssembly перешли от прямой интерпретации текста к виртуальному коду. Придет время — перейдут и к пре-компиляции в машинный код, как Гугл с Dalvik -> ART.
Собственно эта же проблема имеет место со всякими vim, из которых никто не знает как первый раз выйти: командный интерфейс мешается с рабочим пространством (в данном случае областью для ввода текста).
Ну да ладно, статья как я понимаю не о принципах причинности, а о свободе воли… «Чистая» свобода воли возможна, если только она будет базовым, неразделяемым на составные части понятием — как «душа» в религиях. Иначе — или детерминированность, или случайность.
Второе — источник питания, с этим в общественных местах могут быть проблемы. А аккумулятора ненадолго хватит.
Подумалось что было бы удобно ставить такие штуки в номерех гостиниц — там и бесплатный wi-fi есть, и можно, находясь в номере, спокойно без свидетелей смонтировать устройство где-нибудь в вентиляции, и запитать скрытно от проводки:)
Вот возродили бы старый, но незаслуженно забытый класс устройств — UMPC, с возможностью модульности… пусть аудитория была бы меньше, но востребованность модульности как фичи была бы больше.
А компьютеру время не должно быть нужно, компьютеру должен быть важен логический порядок событий. А если компьютеры начинают использовать абсолютное время как основной (или даже единственный) источник для синхронизации каких-то событий в вычислительных сетях, то это плохо… архитектурно плохо. Вся синхронизация должна быть на транзакциях, а не на времени.
А вы написали про отказ от традиционного времени для людей, что совершенно ненужно — люди как ориентировались на вращение Земли, так и будут.
Появление лишней секунды в системе должно интерпретировться так, как будто за секунду произошло в два раза больше событий. Ну и что? В реальной жизни при высоких нагрузках такого разве не может быть? Тем более всего лишь секунда, а реальные высокие нагрузки могут длиться часами.
Go проектировался с нуля значительно позже С++, с учетом огромного опыта проектирования других языков. Но, как уже было сказано, в Go нет очень многих фич.
Тут некоторое время назад была серия статей про Оберон, где автор утверждал что минимум фич (и ключевых слов заодно) это хорошо. Хотя по факту там нет почти ничего, кроме старого процедурного программирования.
В общем, сравнивая количество ключевых слов, языки сравнивать совершенно некорректно. Нужно рассматривать семантику языков, их суть.
Я бы еще добавил, что примитивная «простота» — не главное в языке. Это слишком однобокий критерий. Например, количество ключевых слов должно быть не большим и не маленьким, оно должно быть соответствующим внутренней логике языка. Количество роли не играет вообще. Применение одного и того же ключевого слова для разных целей (чем грешит тот же С++ ради «совмесимости с legacy кодом») не есть хорошо. Когда ключевыми словами обозначается все подряд — тоже плохо.
Главное в языке — внутренняя стройность и логичность, отсутствие «белых пятен» в плане фич. Я уже писал об этом здесь — если в языке чего-то нет, программисты все равно это сделают, но оно будет не органично встроено в язык, а прикручено сбоку изолентой (C++/Boost), что сильно отрицательно скажется на удобстве использования.
Ведь ломать — не строить. Выстраивать толерантное, неагрессивное и умное общество очень сложно, на это у многих цивилизаций уходили столетия, если не тысячелетия… а разжечь костер ненависти, агрессии и разных фобий — элементарно просто.
Сообщество должно знать какие люди у нас во власти.
И сообщество должно на это реагировать.
Сначала были текстовые консольные интерфейсы.
Затем появились графические интерфейсы. Сначала — как вспомогательный режим, который нужно было запустить чтобы посмотреть картинку… после чего они поменялись местами, и теперь консоли — текстовые «окошки» в графическом окружении…
Затем браузеры. Сначала — просто одна из программ графического интерфейса. Со временем они становятся все более значимыми, и постепенно берут на себя функциональность рабочего стола как такового… И вот уже приложения, игры и даже трехмерная графика существует в браузерах, приложения пишутся на html и javascript (хотя еще недавно html — всего лишь язык разметки документов, а javascript — лишь средство создания надоедливых баннеров), появляются целые операционные системы, целиком основанные на браузере и javascript…
Вторая тенденция — виртуализация. В стародавние времена программисты работали напрямую с железом. Затем стали появляться драйверы устройств, API операционной системы, и только единственное устройство — процессор — оставалось доступно для программ напрямую. Но и здесь — Java, .NET, попытки абстрагироваться и от процессора тоже. Собственно, стоило ожидать что с Javascript произойдет что-то подобное, раз этот язык становится новым Си на новом витке развития технологий. Логично, что с помощью WebAssembly перешли от прямой интерпретации текста к виртуальному коду. Придет время — перейдут и к пре-компиляции в машинный код, как Гугл с Dalvik -> ART.