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