Объясните мне кто-нибудь популярно, зачем гугл изобретает новый язык в котором мало того, что нет ни одной оригинальной особенности или идеи, так он еще и какой-то недотипизированный — т.е. типы есть, но во время исполнения информация о них не используется
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>Объясните мне кто-нибудь популярно, зачем гугл изобретает новый язык в котором мало того, что нет ни одной оригинальной особенности или идеи, так он еще и какой-то недотипизированный — т.е. типы есть, но во время исполнения информация о них не используется
ЕА>вот неплохой пост на тему
Здравствуйте, ilnar, Вы писали:
ЕА>>Объясните мне кто-нибудь популярно, зачем гугл изобретает новый язык в котором мало того, что нет ни одной оригинальной особенности или идеи, так он еще и какой-то недотипизированный — т.е. типы есть, но во время исполнения информация о них не используется
ЕА>>вот неплохой пост на тему
I>дык Go не пошел, надежда на новый язык
Потому что надо не языки придумывать, а компиляторы нормальные делать. Тогда и Го пойдёт, и Дарт взлетит. Развели тут, блин, народное творчество, а реальную работу делать никто не хочет. Вон С++ и Фортран, на что страшные языки, но в их компиляторы несколько человеко-веков уже вложено, вот их никто и не может прибить, несмотря на все усилия ярких личностей языкотворцев.
Мне вся эта возня с языками напоминает программные заявления нашего пока ещё Президента. Трёпа много, дела мало.
Здравствуйте, Mazay, Вы писали:
M>Потому что надо не языки придумывать, а компиляторы нормальные делать. Тогда и Го пойдёт, и Дарт взлетит. Развели тут, блин, народное творчество, а реальную работу делать никто не хочет. Вон С++ и Фортран, на что страшные языки, но в их компиляторы несколько человеко-веков уже вложено, вот их никто и не может прибить, несмотря на все усилия ярких личностей языкотворцев. M>Мне вся эта возня с языками напоминает программные заявления нашего пока ещё Президента. Трёпа много, дела мало.
Что называется плюс сто. Особенно умиляют слепые функциональщики, которые считают что язык это только фронтенд компилятора и потом удивляющиеся почему не взлетает. А потому и не взлетает. Фронтенд любого языка, его синтаксис и семантика, это всё только верхушка айсберга. Самое интересное начинается потом и это именно оптимизации в миддл-энде и кодогенерация. Я не знаю *ни одной* книжки хотя бы с перечнем существующих алгоритмов оптимизации с учётом функциональной специфики. Ну там что вместо loop unrolling, что вместо value numbering, что вместо constant propagation... Генерируемый код того же ghc это же без слёз не взглянешь. Хочется лезть в оптимизирующую часть и править ВСЁ.
Здравствуйте, Tilir, Вы писали:
T>Генерируемый код того же ghc это же без слёз не взглянешь. Хочется лезть в оптимизирующую часть и править ВСЁ.
Тут ты не совсем прав.
Дело в том, что хаскель по своей природе тормоз просто дичайший.
Так что ребята проявляют просто чудеса смекалки для того чтобы он работал с той скоростью с какой работает. Но все равно тормозит.
Но все их усилия тратятся на высокоуровневую оптимизацию.
А на низкий уровень ни сил, ни желания не остается.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>Объясните мне кто-нибудь популярно, зачем гугл изобретает новый язык в котором мало того, что нет ни одной оригинальной особенности или идеи, так он еще и какой-то недотипизированный — т.е. типы есть, но во время исполнения информация о них не используется
ИМХО, всё Гугл делает вполне последовательно. Go — язык для "системного ядра", теперь Dart — замена JavaScript. В случае Dart, по-моему, они просто ищут приемлемое решение для устройств со слабым процессором.
ЕА>вот неплохой пост на тему
Рафаэль глядит не туда, куда надо, у него какие-то странные ожидания. Dart — замена JS и он вынужденно копирует подходы, принятые в JS-мире, в том числе и весь бедлам рантайм-конструирования чего-то фырчащего из не пойми чего, отсюда и специфика статических проверок, например. Вполне нормальный ход — уж какая культура сложилась, в неё и вписываемся.
И вообще Рафаэль местами ошибается:
Isolates communicate via message passing. It's not clear if there is some synchronisation method available in the standard libraries, semaphore-based or other.
Смотрим в спецификацию:
An isolate is a unit of concurrency. It has its own memory and its own
thread of control. Isolates communicate by message passing (10.14.4). No state
is ever shared between isolates. Isolates are created by spawning (10.11).
Какие ещё семафоры?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ЕА>>Объясните мне кто-нибудь популярно, зачем гугл изобретает новый язык в котором мало того, что нет ни одной оригинальной особенности или идеи, так он еще и какой-то недотипизированный — т.е. типы есть, но во время исполнения информация о них не используется
ГВ>ИМХО, всё Гугл делает вполне последовательно. Go — язык для "системного ядра", теперь Dart — замена JavaScript. В случае Dart, по-моему, они просто ищут приемлемое решение для устройств со слабым процессором.
а чем существующие не приемлемы? ну чем он например лучше Java будет?
ЕА>>вот неплохой пост на тему
ГВ>Рафаэль глядит не туда, куда надо, у него какие-то странные ожидания. Dart — замена JS и он вынужденно копирует подходы, принятые в JS-мире, в том числе и весь бедлам рантайм-конструирования чего-то фырчащего из не пойми чего, отсюда и специфика статических проверок, например. Вполне нормальный ход — уж какая культура сложилась, в неё и вписываемся.
Че то до меня не доходит, чем нормальная статика не угодила — раз информация о типах есть, почему ей не пользоваться хотя бы в своей VM ?
ГВ>И вообще Рафаэль местами ошибается:
Да, на аккуратный анализ не тянет, но многие вещи, как мне кажется, подмечены верно
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>>>Объясните мне кто-нибудь популярно, зачем гугл изобретает новый язык в котором мало того, что нет ни одной оригинальной особенности или идеи, так он еще и какой-то недотипизированный — т.е. типы есть, но во время исполнения информация о них не используется ГВ>>ИМХО, всё Гугл делает вполне последовательно. Go — язык для "системного ядра", теперь Dart — замена JavaScript. В случае Dart, по-моему, они просто ищут приемлемое решение для устройств со слабым процессором. ЕА>а чем существующие не приемлемы? ну чем он например лучше Java будет?
Java обладает очень серьёзным недостатком — её контролирует Oracle. Странно было бы, если бы Гугл полез в возню вокруг Java. Ну и потом, этот вопрос можно задать и сугубо риторическим порядком: "Люди, почему вы пользуетесь JavaScript, а не Java?" Ну вот так сложилось.
ЕА>>>вот неплохой пост на тему ГВ>>Рафаэль глядит не туда, куда надо, у него какие-то странные ожидания. Dart — замена JS и он вынужденно копирует подходы, принятые в JS-мире, в том числе и весь бедлам рантайм-конструирования чего-то фырчащего из не пойми чего, отсюда и специфика статических проверок, например. Вполне нормальный ход — уж какая культура сложилась, в неё и вписываемся. ЕА>Че то до меня не доходит, чем нормальная статика не угодила — раз информация о типах есть, почему ей не пользоваться хотя бы в своей VM ?
Не знаю. Надо изучить повнимательней руководство к Dart, я пока его только вскользь просмотрел, вполне вероятно, что не всё так плохо.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
T>Что называется плюс сто. Особенно умиляют слепые функциональщики, которые считают что язык это только фронтенд компилятора и потом удивляющиеся почему не взлетает. А потому и не взлетает.
Они считают соверщенно справедливо, потому что на уровне IR уже все эквивалентно. Специфичные для ФЯ оптимизации многократно описаны в литературе и в интернете:
SPJ, Appel. Closure conversion, closure elimination, common subexpression elimination и т.п.
T>Фронтенд любого языка, его синтаксис и семантика, это всё только верхушка айсберга. Самое интересное начинается потом и это именно оптимизации в миддл-энде и
T>кодогенерация. Я не знаю *ни одной* книжки хотя бы с перечнем существующих алгоритмов оптимизации с учётом функциональной специфики. Ну там что вместо loop T>unrolling,
Что бы был loop unrolling, нужно что бы появились сначала циклы. В императивных языка их семантика указывается явно, там много проще. Возможно, ответом на это является суперкомпиляция. Которой в GHC занимаются прямо сейчас. Кстати, возможно LLVM умеет на уровне IR.
T>что вместо value numbering, что вместо constant propagation...
Вместо constant propagation там constant propagation, сюрприз?
T>оптимизирующую часть и T>править ВСЁ.
Здравствуйте, dmz, Вы писали:
I>>>дык Go не пошел, надежда на новый язык
M>>Потому что надо не языки придумывать, а компиляторы нормальные делать. Тогда и Го пойдёт, и Дарт взлетит.
dmz>Нормальный компилятор делает команда LLVM. И почему ее не использует Google --- это другой вопрос.
На LLVM в большой степени влияет Apple ("вдохновитель LLVM — Крис Латтнер — теперь работает в Apple" wikipedia). Возможно Google опасается конфликта интересов. Хотя судя по всему в LLVM сильно вкладывается команда разрабатывающая GCC. Да и сам Google называют в числе главных спонсоров проекта (wikipedia).
А вообще я согласен, что за LLVM или чем-то подобным будущее. Go однозначно нужно было компилировать через LLVM IL. Почему этого не сделали
T>>Генерируемый код того же ghc это же без слёз не взглянешь. Хочется лезть в оптимизирующую часть и править ВСЁ. WH>Тут ты не совсем прав. WH>Дело в том, что хаскель по своей природе тормоз просто дичайший.
Конкретнее можно? По какой природе он тормоз дичайший. А то тут надысь в тесте на совершенно несвойственную
для Haskell задачу рассчета crc16 получили отставание от Си 26%. При том, что в хаскелле делается на списках,
которыми в Си и не пахнет.
Подсчет sha1 от большого файла
fileHash :: FilePath -> IO FileHash
fileHash f = do
content <- L.readFile f
let hash = H.hashlazy content
return $ concatMap (printf "%02x") (B.unpack hash)
работает со скоростью стандартной линуксовой sha1sum или чуть быстрее.
WH>Так что ребята проявляют просто чудеса смекалки для того чтобы он работал с той скоростью с какой работает. Но все равно тормозит.
Тормозит по сравнению с Си, наверное? Ну, извините.
WH>Но все их усилия тратятся на высокоуровневую оптимизацию. WH>А на низкий уровень ни сил, ни желания не остается.
Да оптимизация низкого уровня не будет особенно отличаться от императивных языков, с чего бы?
M>На LLVM в большой степени влияет Apple ("вдохновитель LLVM — Крис Латтнер — теперь работает в Apple" wikipedia). Возможно Google опасается конфликта интересов.
Оно под BSD или похожей лицензией.
M>А вообще я согласен, что за LLVM или чем-то подобным будущее. Go однозначно нужно было компилировать через LLVM IL. Почему этого не сделали
Да, потому что бэкенды писать это сотни человеко-лет, и какой смысл их писать каждый раз заново?
Здравствуйте, dmz, Вы писали:
T>>Что называется плюс сто. Особенно умиляют слепые функциональщики, которые считают что язык это только фронтенд компилятора и потом удивляющиеся почему не взлетает. А потому и не взлетает.
dmz>Они считают соверщенно справедливо, потому что на уровне IR уже все эквивалентно. Специфичные для ФЯ оптимизации многократно описаны в литературе и в интернете: dmz>SPJ, Appel. Closure conversion, closure elimination, common subexpression elimination и т.п.
dmz>Что бы был loop unrolling, нужно что бы появились сначала циклы. В императивных языка их семантика указывается явно, там много проще. Возможно, ответом на это является суперкомпиляция. Которой в GHC занимаются прямо сейчас. Кстати, возможно LLVM умеет на уровне IR.
Здравствуйте, dmz, Вы писали:
M>>На LLVM в большой степени влияет Apple ("вдохновитель LLVM — Крис Латтнер — теперь работает в Apple" wikipedia). Возможно Google опасается конфликта интересов. dmz>Оно под BSD или похожей лицензией.
Это понятно. Но в случае конфликта интересов, в сообществе разработчиков больше "голосов" будет у того, кто больше вкладывается.
M>>А вообще я согласен, что за LLVM или чем-то подобным будущее. Go однозначно нужно было компилировать через LLVM IL. Почему этого не сделали dmz>Да, потому что бэкенды писать это сотни человеко-лет, и какой смысл их писать каждый раз заново?
Угу.
ЕА>а чем существующие не приемлемы? ну чем он например лучше Java будет?
После того, как Javа стала контролироваться Ораклом и он уже начал плющить Гугл, уже даже неважно, хороша она хоть чем-то вообще, или нет.
ЕА>Че то до меня не доходит, чем нормальная статика не угодила — раз информация о типах есть, почему ей не пользоваться хотя бы в своей VM ?
Использование информации о типах в VM -- это уже динамическая типизация. Про ситуацию в типами в Dart нужно что бы кто-то изучил вопрос
и высказался, пока в интерпретациях понимания тамошней ситуации с типами не видно, так что при любых рассуждениях на эту тему можно сесть
в лужу. Нужно читать первоисточники, кому интересно.
Здравствуйте, Tilir, Вы писали:
T>Что называется плюс сто. Особенно умиляют слепые функциональщики, которые считают что язык это только фронтенд компилятора и потом удивляющиеся почему не взлетает. А потому и не взлетает. Фронтенд любого языка, его синтаксис и семантика, это всё только верхушка айсберга. Самое интересное начинается потом и это именно оптимизации в миддл-энде и кодогенерация. Я не знаю *ни одной* книжки хотя бы с перечнем существующих алгоритмов оптимизации с учётом функциональной специфики. Ну там что вместо loop unrolling, что вместо value numbering, что вместо constant propagation... Генерируемый код того же ghc это же без слёз не взглянешь. Хочется лезть в оптимизирующую часть и править ВСЁ.
Я тут давно уже спрашивал, как реализовать решение двумерной модели Изинга на Хаскеле без дополнительных O(log N) к сложности. Ничего путного на этот счёт так и не услышал. Эта проблема явно не уровня кодогенерации, явно более высокоуровневая чем loop unrolling. Она должна решаться на миддл-энде или может даже суперкомпиляцией.
P.S.
Если в кратце, то проблема заключается в том, что функциональные языки запрещают изменять значения, но иногда это необходимо для эффективной реализации. Следовательно, нужно научить компилятор видеть, когда фактически можно изменять значения в памяти а не создавать модифицированные копии.
ЕА>>а чем существующие не приемлемы? ну чем он например лучше Java будет?
dmz>После того, как Javа стала контролироваться Ораклом и он уже начал плющить Гугл, уже даже неважно, хороша она хоть чем-то вообще, или нет.
Ну да, я пока это вижу как единственный валидный аргумент, чтобы бросить развивать GWT и Java-VM и начинать делать то же самое с нуля.
ЕА>>Че то до меня не доходит, чем нормальная статика не угодила — раз информация о типах есть, почему ей не пользоваться хотя бы в своей VM ?
dmz>Использование информации о типах в VM -- это уже динамическая типизация.
Не, там как я понял как раз VM с динамической типизацией, т.е. несмотря на то, что информация о типах в коде есть и можно подставить вызов метода на этапе компиляции, они все равно считают, что тип неизвестен и разрешают все связи динамически.
M>Я тут давно уже спрашивал, как реализовать решение двумерной модели Изинга на Хаскеле без дополнительных O(log N) к сложности. Ничего путного на этот счёт так и не услышал.
Ну, например, никак. Выносить в Си, например. Использовать готовые модули для деструктивных структур данных. И да, это будет жить в IO.
