Интересно насколько глубоко он сможет погрузиться в атмосферу Сатурна прежде чем потеряет возможность передавать данные.
А вообще конечно напрашивается мысль о необходимости создания постоянных ретрансляторов на орбитах всех планет, чтобы исследовательские аппараты могли передавать больше информации.
И еще интересно, можно ли разработать «твердотельный» зонд, который мог бы передавать информацию (и в частности видео) при погружении в планеты-гиганты максимально долго.
У них расширения в том числе и для режима компиляции C90 (многие расширения в этом списке именно такие). И кроме того я хотел упомянуть про десигнаторы потому, что они не включены в расширения С++, а хотелось бы :)
Изменить форму ведра и посмотреть что получится — это в общем несложно и недорого. А полученная информация вполне может натолкнуть ученых на правильный путь построения точной модели…
Отличная статья! Хотя и переведено полуавтоматически, и фигня откровенная в некоторых пунктах, но в целом это можно использовать как краткий справочник по особенностям языков программирования. Мне как человеку увлекающемуся языками программирования как таковыми очень пригодится.
Антропный принцип тут не при чем. Даже если бы никаких людей не было бы, константы были бы все равно одинаковые везде. И это само по себе очень интересно.
Есть что-то, что обеспечивает например единый заряд электрона для всех электронов Вселенной. Это можно интерпретировать как статическую переменную, где этот заряд хранится. До сих пор наука изучает законы физики в read-only режиме, но никто не задавался вопросом (да, это все «очень теоретически» но все-же) — а возможно ли что-то поменять? Возможно ли во Вселенной изменение каких-то факторов, изнутри или извне, при которых фундаментальные константы или функции изменятся?
Совсем-совсем исчерпывающее? С описанием всех сотен фреймворков для фронтэнда и бэкэнда, их архитектуры, идеологии, сравнительного анализа, особенностей взаимодействия, истории возникновения и мотивации тех или иных архитектурных решений?
Все верно, параметризируемая абстракция должна быть.
В простейшем случае если нам нужен просто int и все равно сколько там байт, так и пишем int. А если нужно что-то конкретное (для сетевого пакета или двоичного файла) то пишем int8 или int16 или int32.
Но параметризация должна быть явная, как и модульность. Вообще все должно быть явное, стандартизированное и общее для всех компиляторов.
Возможно.
Если все типы одного 8-битного размера, то это не значит что нельзя сделать 16-битные типы из них. Просто программист будет знать, что 16-битные типы не нативные. Подобная ситуация есть с FPU: на некоторых микроконтроллерах FPU отсутствует, но никто не мешает объявить тип float или double. Другое дело что работать это будет медленно и нередко криво.
Более того, можно ввести понятие модульных возможностей языка. И подключать или отключать различные языковые модули в свойствах проекта (а к таковым я бы отнес floating point, длинную арифметику (GMP), исключения (кстати различных видов — SEH, DWARF, SJLJ и возможно какие-то еще), RTTI, различную рефлексию, динамическое выделение памяти, сборку мусора, многопоточность и т.д.). Если модуль используется в коде, но отключен в проекте — ошибка компиляции; или подключайте модуль, или переписывайте код так чтобы данные языковые возможности не использовались, либо пишите свой модуль (что тоже потенциально возможно).
Ничего сложного во всем этом не вижу. Есть куда более сложные концепции.
Например всякие монады, но пожалуй сложность для меня лично связана с отсутствием желания разбираться с Haskell, а примеров для других языков крайне мало.
Далее, неблокирующие структуры данных (на Хабре была серия статей) — в связи с достаточно высокой сложностью и одновременно низкоуровневостью кода
Метапрограммирование на шаблонах С++ — но это скорее с особенностями реализации именно в С++.
А что может быть сложного в рекурсии, вложенных циклах и тем более операции присваивания — ума не приложу)
Зря вас минусуют. Я разрабатываю на С и С++ уже около 15 лет, начиная от микроконтроллеров и заканчивая сложными распределенными системами — и могу сказать — да, жаль.
И нет, я не предлагаю перейти всем на javascript:) Но необходимость создания универсального языка программирования для замены С и С++ назрела уже давно. А не происходит это из-за инертности мышления и так называемого груза унаследованного кода, который якобы никто не хочет переписывать. Господа, переписать его не такая уж и проблема, было бы на что. Программисты так или иначе постоянно переписывают код, адаптируют его, переписали бы и на единую стандартизированную модификацию Си, заодно кучу древних багов выловили бы. Ах да, бизнес же не хочет тратить лишнее время и платить лишних денег за непонятную работу… им же надо чтобы тяп ляп и в продакшен. Ничего, не обеднели бы.
Если не углубляться в тонкости, сам язык Си вполне хорош за исключением некоторых мелочей. В нем есть некоторые странные соглашения, которые не мешало бы отменить ради универсальности (имя массива это указатель на первый элемент массива — в результате массивы это не first class objects) и некоторые древние и опасные наросты (препроцессор, #define true false, инклуды и т.п.). В нем нет многих современных фич — что плохо. И в нем есть неопределенное поведение (примеры которого показаны в статье) — что очень плохо. Не так уж и сложно жестко прописать правила выравнивания структур или размеры базовых типов. Но нет — с каких-то там древних времен, когда о стандартизации никто не задумывался и писали компиляторы на коленке для себя, получилось что под какую-то архитектуру размеры базовых типов оказались нестандартные. И может сейчас и архитектуры-то этой нет, но тягомотина с undefined behaviour продолжает тянуться ради дурацкой совместимости.
Еще добавлю, что нужно учитывать потенциальную ответственность (не помню ее ввели или собираются) за способы обхода блокировок. Конечно хорошо если владелец сайта за границей, а если нет? А тут функционал обхода будет встроен в плагин и не будет афишироваться явно.
Идея в том, что большинство простых пользователей про все эти плагины не знает. А когда понадобится, может оказаться уже поздно. Поэтому логично уже сейчас мотивировать пользователей устанавливать плагины, а в качестве мотивации можно придумать какие-то дополнительные сервисы, которые недоступны через чистый браузер.
У меня появилась мысль, что тенденция к блокировкам должна привести к тому, что популярные сайты, для которых велик риск блокировки, должны параллельно разрабатывать плагины к браузерам для обхода блокировок и популяризировать использование этих плагинов среди пользователей. Например добавляя какие-то еще возможности, которые нельзя получить просто через веб…
Для рутрекера кстати довольно быстро такой плагин появился (хоть и неофициальный). Весьма удобно — пропускает через прокси только запросы к рутрекеру.
Скорее украсит. Мосты получились красивые, особенно через Петровский фарватер (ИМХО конечно). Да и вообще, думаю что Петр Первый, основатель города, был бы доволен тем что его город не превратился в замерзшее болото а активно развивается.
Просто не делайте фотки длиннофокусными объективами, и все виды центра из центра останутся в норме.
Ну потому что перечисления это более примитивная сущность чем варианты. Также потому что некоторые типы все-же должны быть POD, например для работы с бинарными форматами или сетевыми протоколами.
Приведу вот такой пример. Можно отказаться от разнообразных числовых типов (int, short, long, unsigned int, float, double и т.д.) и перейти к единому числовому типу, скажем «numeric». Неограниченной длины, любой точности. Возможно это будет удобно. Но это будет сущность более сложная чем базовые типы, и безусловно, отказ от базовых типов уменьшит хакерскую мощь языка. Но в то же время добавление высокоуровневых вариантов с сохранением низкоуровневых перечислений не только не уменьшит, но и увеличит хакерские возможности языка программирования.
А вообще конечно напрашивается мысль о необходимости создания постоянных ретрансляторов на орбитах всех планет, чтобы исследовательские аппараты могли передавать больше информации.
И еще интересно, можно ли разработать «твердотельный» зонд, который мог бы передавать информацию (и в частности видео) при погружении в планеты-гиганты максимально долго.
Интересны не конкретные значения констант, а их константность как таковая.
Есть что-то, что обеспечивает например единый заряд электрона для всех электронов Вселенной. Это можно интерпретировать как статическую переменную, где этот заряд хранится. До сих пор наука изучает законы физики в read-only режиме, но никто не задавался вопросом (да, это все «очень теоретически» но все-же) — а возможно ли что-то поменять? Возможно ли во Вселенной изменение каких-то факторов, изнутри или извне, при которых фундаментальные константы или функции изменятся?
В простейшем случае если нам нужен просто int и все равно сколько там байт, так и пишем int. А если нужно что-то конкретное (для сетевого пакета или двоичного файла) то пишем int8 или int16 или int32.
Но параметризация должна быть явная, как и модульность. Вообще все должно быть явное, стандартизированное и общее для всех компиляторов.
Если все типы одного 8-битного размера, то это не значит что нельзя сделать 16-битные типы из них. Просто программист будет знать, что 16-битные типы не нативные. Подобная ситуация есть с FPU: на некоторых микроконтроллерах FPU отсутствует, но никто не мешает объявить тип float или double. Другое дело что работать это будет медленно и нередко криво.
Более того, можно ввести понятие модульных возможностей языка. И подключать или отключать различные языковые модули в свойствах проекта (а к таковым я бы отнес floating point, длинную арифметику (GMP), исключения (кстати различных видов — SEH, DWARF, SJLJ и возможно какие-то еще), RTTI, различную рефлексию, динамическое выделение памяти, сборку мусора, многопоточность и т.д.). Если модуль используется в коде, но отключен в проекте — ошибка компиляции; или подключайте модуль, или переписывайте код так чтобы данные языковые возможности не использовались, либо пишите свой модуль (что тоже потенциально возможно).
Например всякие монады, но пожалуй сложность для меня лично связана с отсутствием желания разбираться с Haskell, а примеров для других языков крайне мало.
Далее, неблокирующие структуры данных (на Хабре была серия статей) — в связи с достаточно высокой сложностью и одновременно низкоуровневостью кода
Метапрограммирование на шаблонах С++ — но это скорее с особенностями реализации именно в С++.
А что может быть сложного в рекурсии, вложенных циклах и тем более операции присваивания — ума не приложу)
И нет, я не предлагаю перейти всем на javascript:) Но необходимость создания универсального языка программирования для замены С и С++ назрела уже давно. А не происходит это из-за инертности мышления и так называемого груза унаследованного кода, который якобы никто не хочет переписывать. Господа, переписать его не такая уж и проблема, было бы на что. Программисты так или иначе постоянно переписывают код, адаптируют его, переписали бы и на единую стандартизированную модификацию Си, заодно кучу древних багов выловили бы. Ах да, бизнес же не хочет тратить лишнее время и платить лишних денег за непонятную работу… им же надо чтобы тяп ляп и в продакшен. Ничего, не обеднели бы.
Если не углубляться в тонкости, сам язык Си вполне хорош за исключением некоторых мелочей. В нем есть некоторые странные соглашения, которые не мешало бы отменить ради универсальности (имя массива это указатель на первый элемент массива — в результате массивы это не first class objects) и некоторые древние и опасные наросты (препроцессор, #define true false, инклуды и т.п.). В нем нет многих современных фич — что плохо. И в нем есть неопределенное поведение (примеры которого показаны в статье) — что очень плохо. Не так уж и сложно жестко прописать правила выравнивания структур или размеры базовых типов. Но нет — с каких-то там древних времен, когда о стандартизации никто не задумывался и писали компиляторы на коленке для себя, получилось что под какую-то архитектуру размеры базовых типов оказались нестандартные. И может сейчас и архитектуры-то этой нет, но тягомотина с undefined behaviour продолжает тянуться ради дурацкой совместимости.
Для рутрекера кстати довольно быстро такой плагин появился (хоть и неофициальный). Весьма удобно — пропускает через прокси только запросы к рутрекеру.
Просто не делайте фотки длиннофокусными объективами, и все виды центра из центра останутся в норме.
Приведу вот такой пример. Можно отказаться от разнообразных числовых типов (int, short, long, unsigned int, float, double и т.д.) и перейти к единому числовому типу, скажем «numeric». Неограниченной длины, любой точности. Возможно это будет удобно. Но это будет сущность более сложная чем базовые типы, и безусловно, отказ от базовых типов уменьшит хакерскую мощь языка. Но в то же время добавление высокоуровневых вариантов с сохранением низкоуровневых перечислений не только не уменьшит, но и увеличит хакерские возможности языка программирования.