Считаю что объектный формат хранения и линковка вообще устаревшие концепции, т.к. они не позволяют хранить метапрограммы (например шаблоны C++), в результате в том же C++ шаблоны могут существовать только в *.h-файлах. Хранить нужно частично скомпилированные синтаксические деревья, а вместо линковки применять процесс «окончательной компиляции».
Я не то чтобы предлагаю, я размышляю. Вот например, можно ли закорючку от буквы 'й' присоединить к иероглифу, цифре или знаку препинания? Что получится?
Если идти по пути универсальности, то почему бы и нет? А если закорючку присоединить к другой закорючке?
С одной стороны это конечно хорошо, что можно генерировать некоторые новые символы таким образом. А с другой… как-то бессистемно. Ну ввели бы тогда специальный код «escape» для специальных escape-последовательностей — и вот туда можно было бы добавить элементы форматирования. В том числе жирный/курсив/подчеркивание, капитель, верхний и нижний индекс, надстрочные и подстрочные символы (Ruby character), геометрические преобразования (поворот символа на 90/180/270 градусов или даже повороты с каким-то шагом типа 5°, отражение по горизонтали и вертикали), цвет символов (для всяких эмодзи вполне актуально, и сейчас это уже как-то делают) и т.п. Это было бы хотя-бы системно. Но тогда бы это была уже не таблица символов, а нечто большее. А сейчас оно застряло где-то на полпути…
Не знаком с немецким, но почитал — занимательно, получается что это как раз тот случай, когда Unicode повлиял на язык (введение заглавной буквы в Unicode раньше чем она появилась в языке).
Unicode — это прежде всего набор символов и соответствующих им кодов. Как их использовать — дело софта. И наверное, если разные модификации (декорации) одного смыслового символа значительно отличаются и не могут быть сгенерированы программно (как в случае underline, subscript, superscript — просто подчеркиванием или уменьшением размеров), то нужно эти символы вводить отдельно…
Одинаковые символы с разными кодами (как например латинское 'A' и русское 'А') введены просто для удобства группировки, чтобы символы одного языка не были разбросаны по всему диапазону. Для европейских языков большая часть символов общая, и лишь некоторые (2..4 штуки в каждом алфавите) свои собственные — поэтому не имеет смысла вводить отдельно коды для «немецких», «французских» и «итальянских» букв 'A', а проще сформировать единый общеевропейский метаалфавит, что и было сделано. В русском большая часть символов отличается, поэтому сделали отдельный набор.
В общем понятно, что Unicode несет на себе бремя обратной совместимости не только с ASCII, но и с историей письменности как таковой:) И идеального решения не найти. Может быть нужно было радикальное решение в виде разделения абстракций — отдельно слой сопоставления символов и «кодов символов» (в этом слое все буквы, выглядящие как 'A', будут иметь единый код), и отдельно слой сопоставления «кодов символов» и «смысловых кодов» (здесь уже разделение по алфавитам). В результате было бы две кодировки — графическая и семантическая. Понятно, что это кардинально повлияло бы на все ОС и на весь софт, и мы бы жили в совсем другом мире:)
Дизайн Unicode по большому счету содержит множество ошибок. Из за желания угодить всем нагородили вот это всё, и это при том что Unicode создавался во времена «однополярного мира», когда США и американские корпорации, будучи практически монополистами в сфере IT-стандартов и технологий, вполне могли продавить более простую концепцию.
Зачем например в Unicode «направление письма»? Unicode это просто набор символов. Как их вводить, выводить и интерпретировать — дело софта. Вот в Китае и Японии направление письма вообще «сверху вниз», но ведь Unicode такое не поддерживает? И кстати, китайцы и японцы с появлением компьютеров вполне адаптировались к направлению «слева направо», может и арабы бы также адаптировались?
Далее, регистр символов — это особенность исключительно европейских языков, унаследованная из ASCII (который создавался в условиях гораздо более жесткой экономии оперативной памяти). Понятно что старались сделать обратную совместимость, но по большому счету регистр должен был стать «декорацией» (как bold, italic, subscript или superscript), а не отдельными кодовыми точками. Символы 'a' и 'a' (курсивом) — как-бы один символ, хотя они совершенно отличаются визуально. Символы 'a' и 'A' при этом — разные. Логика?
Из-за той же обратной совместимости осталась незадействованной большая часть символов в самом начале кодовой таблицы, с 0x00 до 0x1F. А между тем их стоило бы задействовать для наиболее употребительных спецсимволов (таких например как стрелки, дополнительные знаки пунктуации, некоторые математические символы и т.п.). Размещение этих символов в однобайтовой части важно, так как именно однобайтовая часть Unicode по очевидным причинам нанесена на все клавиатуры мира. Оставить в этой области можно было бы только нулевой код и код новой строки, и заодно провести редизайн концепции переноса строки, т.к. в основных системах (Win, Mac, Linux) перенос строки устроен по-разному (0x0D, 0x0A или оба сразу).
Ну и наверное можно еще накопать таких вот нелогичностей.
Почему-то до сих пор в язык не ввели встроенные геттеры и сеттеры. Хотя например уже очень давно такое было в C++Builder (__property), у Microsoft (__declspec(property)). А вот в GCC такой возможности нет, хотя казалось бы — именно GCC как никакой другой компилятор богат на языковые расширения.
Воспроизведение связи между матерью и ребенком, с точно рассчитанным высвобождением нужных гормонов в течение всего периода, находится за пределами досягаемости современных биотехнологий.
Интересно почему? Неужели этот процесс не изучить простым взятием анализов с каким-то периодом (пусть даже каждый день) у подопытных животных?
Компьютерные игры — это отличный способ уберечь детей от влияния улицы и подворотни. От сбивания в уличные шайки, от мордобоя и уличного криминала. В общем, игры вносят вклад в снижение уровня насилия на планете. 3dnews.ru/1035263/igri-spasut-mir-feature
Фактор снижения насилия
Большинство экспертов с уверенностью заявляют: игры не имеют никакого отношения к насилию в мире. Но есть и другая позиция — интерактивные виды досуга снижают уровень преступности на планете. Среди них есть и российские общественные деятели, например политолог Екатерина Шульман, известная игровому сообществу в первую очередь благодаря интервью радио Sputnik. Там она произнесла удивительную вещь: «Есть обывательская логика: игры с насилием провоцируют реальное насилие. В реальности происходит ровно противоположное…»
Социологи подтверждают — уровень насилия и преступности на нашей планете неуклонно снижается. Тут, конечно, важно понимать, что говорим мы о плавном и постепенном процессе в развитых странах, а не о сиюминутном искоренении всех злодеяний на земном шаре. Тем не менее осязаемый процесс идёт, и это обнадёживает. Естественно, это заслуга множества факторов — развития гражданского общества, укрепления роли человеческой жизни как основополагающей ценности, усиления эмпатии у превалирующей части жителей мира и прочего. Но и видеоигры оказывают, как выяснилось, заметное влияние.
Согласно исследованиям, интерактивные развлечения способны уменьшать уровень преступности. А точнее, самый распространённый её подвид — уличную преступность, в которую вовлечены молодые люди. Наиболее подробно этот вопрос раскрывает исследование Understanding the Effects of Violent Video Games on Violent Crime («Понимание воздействия жестоких видеоигр на насильственные преступления»), проведённое Скоттом Канингемом, Бенджамином Энгельштеттером и Майклом Р. Уордом. Группа учёных смогла определить корреляцию между популярностью интерактивных развлечений и снижением уровня преступности среди молодёжи.
В своём исследовании они отмечают: взаимосвязь между склонностью конкретного человека к насилию и предпочтением им игр с элементами жестокости (заметьте, не наоборот) наблюдается. Но позже подводят к очевидной мысли: если такой человек проводит время за играми, сублимируя антисоциальный пыл на NPC, а не ходит по улицам в поисках утоления своих низменных порывов, то это — однозначно позитивная тенденция. Удерживая внимание человека дома у экрана, игра буквально уничтожает интерес, например, к перспективе вступления в уличную банду, к праздному вандализму или, что страшнее, грабежу, разбою или убийству. Да и времени с энергией на противоправные действия просто не останется…
Для цветных экранов с как минимум 256 цветами дополнительно можно добавить сглаживание (4 или 16 бит на пиксель). Я такое делал, надписи получаются гораздо приятнее.
Ну и сам способ организации массива может быть разным Иногда удобнее сплошным массивом, а иногда — когда не нужны все символы из диапазона — удобнее таблица указателей на отдельные массивы для каждого символа.
Возможно, в технологической гонке упустили несколько промежуточных этапов и скакнули слишком далеко, в результате что-то потеряли и не поняли. Например, кроме «простого текста» могло бы появиться еще несколько «простых» форматов, которые бы стали стандартами де факто и получили бы повсеместное распространение. Или мог бы появиться совсем другой принцип запуска программ, и как следствие — другой способ передачи им аргументов.
Впрочем, тут можно углубляться очень глубоко. Возможно, дело в текстовой клавиатуре и изначально текстовых интерфейсах пользователя. Или в изначально последовательном командном способе взаимодействия с компьютером. Или еще в чем-то.
Это несущественно, там xml, который вы руками править точно не будете. Вполне можно было использовать какой-нибудь бинарный аналог. В конечном итоге «текстовость» и «бинарность» — лишь ограничение на множество байт, которые могут быть использованы в файле.
Дело ведь не в формате, а в том, что всё связывание программ и организация потоков данных осуществляется через командную строку консоли. Когда-то у Microsoft была задумка — COM-объекты, ActiveX, встраивание одних документов и программ в другие… Но в конечном итоге оно пошло куда-то не туда, возможно технология была слишком сложной, или ей чего-то не хватало.
Идея Unix-way хорошая, но как ее соотнести со сложнейшим современным софтом? Да с тем же Офисом, Фотошопом, различными средами разработки, проектирования, конструирования и т.п.?
Насколько имеет смысл ограничиваться консолью и текстовым форматом (пусть и в JSON)? Не имеет ли смысл пересмотреть концепцию на более глубоком уровне, допустив, что у программ могут быть не только текстовые входы и выходы?
x86 вообще представляет собой некое нагромождение слоев и возможностей, добавляемых с каждым новым релизом очередного процессора. При этом некоторые расширения могут отсутствовать, и их наличие еще нужно проверять какими-то специальным кодом типа CPUID.
Сама система регистров — очевидный пример такого нагромождения. Есть базовые регистры x86, регистры x64, регистры FPU, регистры MMX, регистры SSE и т.д. При этом некоторые регистры совмещены, некоторые — отдельные. Регистры FPU зачем-то организованы в виде стека, что выбивается из общей системы прямой индексации.
В системе команд нет встроенных команд MIN, MAX и CLAMP (это все делается конечно через проверки и условные переходы, но операции определения минимума и максимума достаточно частые, почему бы их не сделать командами?)
Нет команды RBIT (разворота битов в слове). Хотя места для того чтобы ее воткнуть имеются — например в унарной группе 0xF6 есть свободная позиция (TEST, <свободно>, NOT, NEG, MUL, IMUL, DIV, IDIV). Кто-то говорит что такая команда не нужна, т.к. редко используется. Но в ARM она есть, и кроме того это по смыслу фундаментальная операция.
Арифметические операции с насыщением хоть и существуют, но не для базовых регистров, а в MMX и SSE. Хотя наверное можно было бы сделать это префиксами для основных команд и регистров.
В FPU почему-то операции сравнения числа на равенство и неравенство с NaN всегда дают false, хотя какой в этом смысл? В результате код сравнения для float усложняется. При этом минимум и максимум с NaN дает второй аргумент (не NaN).
Система SIMD сделана на отдельных командах, хотя тоже напрашивается мысль — почему бы не сделать ее префиксами для стандартного набора команд? Есть же префиксы повторения операций (REPE, REPNE). Но и они работают не унифицированно, а только с ограниченным набором команд. Но конечно все это потребовало бы глубокого редизайна системы команд и регистров.
Понятно что архитектура развивалась эволюционно, сначала все было достаточно просто, затем стали усложнять, появлялись новые задачи и потребности. Но в какой-то момент нужно уже остановиться и полностью пересмотреть систему команд, провести полный рефакторинг всего — как минимум для повышения ясности самой архитектуры. Кто знает, возможно это привело бы и к высвобождению транзисторов на кристалле, и к устранению каких-то уязвимостей, и к упрощению компиляторов.
Гениальными был интерфейс старых ОС. Там заголовок окна — это заголовок, кнопка это кнопка, а не непонятная надпись на сером фоне, сливающаяся с остальными элементами окна. У каждого окна есть четкая рамка, однозначно отделяющая его содержимое от содержимого остальных окон. И т.д.
А сейчас интерфейс катится куда-то не туда. Вот калькулятор Win10 (картинка из инета)
Что мы видим: надписи «Инженерный», «DEG», «HYP», «M+», «M-», «MS», некое число — результат вычисления, история вычислений, «Память», и все они выполнены одним цветом на одном фоне, хотя некоторые из них — просто надписи, а другие — кнопки. Между элементами никаких разделителей. Это называется нищета интерфейса. Как будто взяли кусок грязного упаковочного картона и простым карандашом от руки что-то нарисовали.
В десктопе кнопки подсвечиваются если на них навести мышь. Как такое работает с сенсорным экраном вообще не знаю (пока не нажмешь не узнаешь?)
В общем, может там в ядре и замечательные нововведения, но зачем принуждать юзеров к единственно возможному интерфейсу пользователя? Плитки — замечательная идея, но почему им не быть в том стиле, в котором захочет пользователь (в том числе и в старом классическом стиле win2000)? И вообще пора бы уже отделить Desktop Environment от ядра системы, это достаточно простое разделение абстракций.
ew.com/movies/the-matrix-4-footage-fan-website-poster
www.reddit.com/r/matrix/comments/pjt33g/i_compiled_all_the_scenes_in_one_video_for_yall
www.reddit.com/r/matrix/comments/pjtnot/stitched_together_as_much_of_the_teaser_footage_i
Если идти по пути универсальности, то почему бы и нет? А если закорючку присоединить к другой закорючке?
С одной стороны это конечно хорошо, что можно генерировать некоторые новые символы таким образом. А с другой… как-то бессистемно. Ну ввели бы тогда специальный код «escape» для специальных escape-последовательностей — и вот туда можно было бы добавить элементы форматирования. В том числе жирный/курсив/подчеркивание, капитель, верхний и нижний индекс, надстрочные и подстрочные символы (Ruby character), геометрические преобразования (поворот символа на 90/180/270 градусов или даже повороты с каким-то шагом типа 5°, отражение по горизонтали и вертикали), цвет символов (для всяких эмодзи вполне актуально, и сейчас это уже как-то делают) и т.п. Это было бы хотя-бы системно. Но тогда бы это была уже не таблица символов, а нечто большее. А сейчас оно застряло где-то на полпути…
Unicode — это прежде всего набор символов и соответствующих им кодов. Как их использовать — дело софта. И наверное, если разные модификации (декорации) одного смыслового символа значительно отличаются и не могут быть сгенерированы программно (как в случае underline, subscript, superscript — просто подчеркиванием или уменьшением размеров), то нужно эти символы вводить отдельно…
Одинаковые символы с разными кодами (как например латинское 'A' и русское 'А') введены просто для удобства группировки, чтобы символы одного языка не были разбросаны по всему диапазону. Для европейских языков большая часть символов общая, и лишь некоторые (2..4 штуки в каждом алфавите) свои собственные — поэтому не имеет смысла вводить отдельно коды для «немецких», «французских» и «итальянских» букв 'A', а проще сформировать единый общеевропейский метаалфавит, что и было сделано. В русском большая часть символов отличается, поэтому сделали отдельный набор.
В общем понятно, что Unicode несет на себе бремя обратной совместимости не только с ASCII, но и с историей письменности как таковой:) И идеального решения не найти. Может быть нужно было радикальное решение в виде разделения абстракций — отдельно слой сопоставления символов и «кодов символов» (в этом слое все буквы, выглядящие как 'A', будут иметь единый код), и отдельно слой сопоставления «кодов символов» и «смысловых кодов» (здесь уже разделение по алфавитам). В результате было бы две кодировки — графическая и семантическая. Понятно, что это кардинально повлияло бы на все ОС и на весь софт, и мы бы жили в совсем другом мире:)
Зачем например в Unicode «направление письма»? Unicode это просто набор символов. Как их вводить, выводить и интерпретировать — дело софта. Вот в Китае и Японии направление письма вообще «сверху вниз», но ведь Unicode такое не поддерживает? И кстати, китайцы и японцы с появлением компьютеров вполне адаптировались к направлению «слева направо», может и арабы бы также адаптировались?
Далее, регистр символов — это особенность исключительно европейских языков, унаследованная из ASCII (который создавался в условиях гораздо более жесткой экономии оперативной памяти). Понятно что старались сделать обратную совместимость, но по большому счету регистр должен был стать «декорацией» (как bold, italic, subscript или superscript), а не отдельными кодовыми точками. Символы 'a' и 'a' (курсивом) — как-бы один символ, хотя они совершенно отличаются визуально. Символы 'a' и 'A' при этом — разные. Логика?
Из-за той же обратной совместимости осталась незадействованной большая часть символов в самом начале кодовой таблицы, с 0x00 до 0x1F. А между тем их стоило бы задействовать для наиболее употребительных спецсимволов (таких например как стрелки, дополнительные знаки пунктуации, некоторые математические символы и т.п.). Размещение этих символов в однобайтовой части важно, так как именно однобайтовая часть Unicode по очевидным причинам нанесена на все клавиатуры мира. Оставить в этой области можно было бы только нулевой код и код новой строки, и заодно провести редизайн концепции переноса строки, т.к. в основных системах (Win, Mac, Linux) перенос строки устроен по-разному (0x0D, 0x0A или оба сразу).
Ну и наверное можно еще накопать таких вот нелогичностей.
Интересно почему? Неужели этот процесс не изучить простым взятием анализов с каким-то периодом (пусть даже каждый день) у подопытных животных?
3dnews.ru/1035263/igri-spasut-mir-feature
Ну и сам способ организации массива может быть разным Иногда удобнее сплошным массивом, а иногда — когда не нужны все символы из диапазона — удобнее таблица указателей на отдельные массивы для каждого символа.
Впрочем, тут можно углубляться очень глубоко. Возможно, дело в текстовой клавиатуре и изначально текстовых интерфейсах пользователя. Или в изначально последовательном командном способе взаимодействия с компьютером. Или еще в чем-то.
Дело ведь не в формате, а в том, что всё связывание программ и организация потоков данных осуществляется через командную строку консоли. Когда-то у Microsoft была задумка — COM-объекты, ActiveX, встраивание одних документов и программ в другие… Но в конечном итоге оно пошло куда-то не туда, возможно технология была слишком сложной, или ей чего-то не хватало.
Насколько имеет смысл ограничиваться консолью и текстовым форматом (пусть и в JSON)? Не имеет ли смысл пересмотреть концепцию на более глубоком уровне, допустив, что у программ могут быть не только текстовые входы и выходы?
* не гик и не нёрд
* не гик и нёрд
* гик и не нёрд
* гик и нёрд
Сама система регистров — очевидный пример такого нагромождения. Есть базовые регистры x86, регистры x64, регистры FPU, регистры MMX, регистры SSE и т.д. При этом некоторые регистры совмещены, некоторые — отдельные. Регистры FPU зачем-то организованы в виде стека, что выбивается из общей системы прямой индексации.
В системе команд нет встроенных команд MIN, MAX и CLAMP (это все делается конечно через проверки и условные переходы, но операции определения минимума и максимума достаточно частые, почему бы их не сделать командами?)
Нет команды RBIT (разворота битов в слове). Хотя места для того чтобы ее воткнуть имеются — например в унарной группе 0xF6 есть свободная позиция (TEST, <свободно>, NOT, NEG, MUL, IMUL, DIV, IDIV). Кто-то говорит что такая команда не нужна, т.к. редко используется. Но в ARM она есть, и кроме того это по смыслу фундаментальная операция.
Арифметические операции с насыщением хоть и существуют, но не для базовых регистров, а в MMX и SSE. Хотя наверное можно было бы сделать это префиксами для основных команд и регистров.
В FPU почему-то операции сравнения числа на равенство и неравенство с NaN всегда дают false, хотя какой в этом смысл? В результате код сравнения для float усложняется. При этом минимум и максимум с NaN дает второй аргумент (не NaN).
Система SIMD сделана на отдельных командах, хотя тоже напрашивается мысль — почему бы не сделать ее префиксами для стандартного набора команд? Есть же префиксы повторения операций (REPE, REPNE). Но и они работают не унифицированно, а только с ограниченным набором команд. Но конечно все это потребовало бы глубокого редизайна системы команд и регистров.
Понятно что архитектура развивалась эволюционно, сначала все было достаточно просто, затем стали усложнять, появлялись новые задачи и потребности. Но в какой-то момент нужно уже остановиться и полностью пересмотреть систему команд, провести полный рефакторинг всего — как минимум для повышения ясности самой архитектуры. Кто знает, возможно это привело бы и к высвобождению транзисторов на кристалле, и к устранению каких-то уязвимостей, и к упрощению компиляторов.
А сейчас интерфейс катится куда-то не туда. Вот калькулятор Win10 (картинка из инета)
Что мы видим: надписи «Инженерный», «DEG», «HYP», «M+», «M-», «MS», некое число — результат вычисления, история вычислений, «Память», и все они выполнены одним цветом на одном фоне, хотя некоторые из них — просто надписи, а другие — кнопки. Между элементами никаких разделителей. Это называется нищета интерфейса. Как будто взяли кусок грязного упаковочного картона и простым карандашом от руки что-то нарисовали.
В десктопе кнопки подсвечиваются если на них навести мышь. Как такое работает с сенсорным экраном вообще не знаю (пока не нажмешь не узнаешь?)
В общем, может там в ядре и замечательные нововведения, но зачем принуждать юзеров к единственно возможному интерфейсу пользователя? Плитки — замечательная идея, но почему им не быть в том стиле, в котором захочет пользователь (в том числе и в старом классическом стиле win2000)? И вообще пора бы уже отделить Desktop Environment от ядра системы, это достаточно простое разделение абстракций.