Ну как точку и косвенными способами можно определить — все равно на выходе будет «точка» с какими-то параметрами (масса, расстояние от звезды, период обращения и т.п.) Интересно же увидеть планету как таковую, и в максимально возможном разрешении. Понятно что современные телескопы на это не способны, но если пофантазировать и представить что где-нибудь на Луне можно сделать площадку радиусом несколько сотен километров, содержащую миллионы телескопов, способных работать под управлением суперкомпьютера как единое целое… такая система будет способна что-нибудь разглядеть на экзопланете или тут есть какие-то фундаментальные ограничения, которые все равно не позволят ничего увидеть?
Интересно, возможно ли в принципе создание таких телескопов (м.б. космических, на луне и т.п.), чтобы можно было непосредственно увидеть экзопланеты?
Желательно чтобы увидеть хотя-бы океаны и континенты (если они там конечно есть).
Все-же иногда возникает такое чувство, что где-то там идет глубокая подковерная борьба двух группировок: самодержавно-сталинских мракобесов и более-менее адекватных цивилизованных людей. Первые лоббируют принятие все новых и новых запретительных законов, вторые иногда пытаются их сгладить или замять. А то что мы видим — лишь поверхностные результаты…
Очень интересно (побольше бы таких статей на Хабре!), правда слишком кратко и сжато, хотелось бы более подробно и последовательно.
А что такое «классы типов» в Go? То что там называется ключевым словом «interface» или что-то другое?
Что такое «типы высших порядков»?
По крайней мере в руководстве по Swift я не нашел упоминаний динамических возможностей — все что связано с отправкой сообщений (я подозреваю что отправка сообщений используется неявно — но я ожидал увидеть возможность явно указывать вызов метода или отправку сообщения), также всевозможные добавления методов в классы на лету, доступ к метаинформации и т.д.
У Objective C синтаксис непривычный, хотя концептуально это очень интересный язык — не менее интересный чем Rust и Go (а в чем-то даже и более). А вот у Swift к сожалению, насколько я понял, синтаксис привычный, а многих интересных возможностей ObjC (пока еще?) нет.
Мицгол, давно хочу вас спросить: в стародавние времена вы, помнится, были сторонником «православного самодержавия». Сейчас, когда вы испытываете его на себе в действии, ваше отношение к нему изменилось?
Язык очень интересный, но синтаксис меня местами огорчает. Самый лучший синтаксис из си-подобных языков пожалуй у C#. Rust претендует на низкоуровневость Си (и еще очень интересно что в итоге получится со встроенными «умными указателями»), Go содержит интерейшие концепции эмбеддинга вместо наследования и интерфейсов, в D весьма много мелочей, которые упустили в С++; в общем, идеального языка опять нет.
Есть два нормальных решения: или как в Nemerle — плагины пишутся на том же языке что и основной код; компилятор делает несколько проходов и компилирует сначала плагины («макросы») а затем с их помощью основной код. Преимущества — один язык а не два, повторное использование кода (можно один код использовать как в плагинах так и в основной программе).
Второй вариант — использование для плагинов другого языка (например тот же javascript). Для С++ думаю это подойдет лучше — ибо плагины на небезопасном С++ со всеми его костылями и граблями это будет еще тот номер. Сам по себе JavaScript вполне стандартизирован и общеизвестен, все что остается — разработать и стандартизировать объектную модель для компиляторов (аналог HTML DOM для браузеров).
В том-то и дело, что делать языковые фичи на уровне компилятора НАМНОГО проще. Там это обычные «сишные» структуры данных и функции. А здесь это адские хаки, основанные на случайных свойствах языковых конструкций, изначально предназначавшихся для совершенно других вещей.
А так получается что каждый программист дописывает компилятор практически вслепую (сообщения об ошибках при метапрограммировании на шаблонах это ад). Вот даже автор не уверен что код идеально работает.
Вся проблема в том что эти возможности С++ были случайно открыты, а не спроектированы изначально. По хорошему нужно бы всю часть языка, связанную с метапрограммированием, перепроектировать заново. С новыми ключевыми словами, нормальными синтаксическими макросами, нормальным доступом к AST и т.д. А старую оставить для совмесимости, но строго рекомендовать этим не пользоваться.
Восхищаюсь теми кто может придумывать и реализовывать такие вещи. Супер!
Но с другой стороны грустно… все это — SFINAE, compile-time-последовательности чисел, вычисления на шаблонах, да те же туплы в реализации С++… это мега костыли к компилятору. Даже не костыли, а внутренности компилятора, почему-то существующие снаружи в виде библиотек и пользовательского кода и подключенные к нему многочисленными трубочками.
Почти все это должно быть в самом языке, а не в библиотеках. Все что в boost отмечено как «Language Features Emulation», «Generic Programming», «Template Metaprogramming» и много чего еще.
Желательно чтобы увидеть хотя-бы океаны и континенты (если они там конечно есть).
Не «более грамотный», а «этимологически более грамотный»
</zanuda_mode>
А что такое «классы типов» в Go? То что там называется ключевым словом «interface» или что-то другое?
Что такое «типы высших порядков»?
Кстати, а в России есть где нибудь музей компьютерной техники (желательно работающей)? Не частная коллекция а именно музей.
Второй вариант — использование для плагинов другого языка (например тот же javascript). Для С++ думаю это подойдет лучше — ибо плагины на небезопасном С++ со всеми его костылями и граблями это будет еще тот номер. Сам по себе JavaScript вполне стандартизирован и общеизвестен, все что остается — разработать и стандартизировать объектную модель для компиляторов (аналог HTML DOM для браузеров).
А так получается что каждый программист дописывает компилятор практически вслепую (сообщения об ошибках при метапрограммировании на шаблонах это ад). Вот даже автор не уверен что код идеально работает.
Вся проблема в том что эти возможности С++ были случайно открыты, а не спроектированы изначально. По хорошему нужно бы всю часть языка, связанную с метапрограммированием, перепроектировать заново. С новыми ключевыми словами, нормальными синтаксическими макросами, нормальным доступом к AST и т.д. А старую оставить для совмесимости, но строго рекомендовать этим не пользоваться.
Но с другой стороны грустно… все это — SFINAE, compile-time-последовательности чисел, вычисления на шаблонах, да те же туплы в реализации С++… это мега костыли к компилятору. Даже не костыли, а внутренности компилятора, почему-то существующие снаружи в виде библиотек и пользовательского кода и подключенные к нему многочисленными трубочками.
Почти все это должно быть в самом языке, а не в библиотеках. Все что в boost отмечено как «Language Features Emulation», «Generic Programming», «Template Metaprogramming» и много чего еще.