Oberon space
General Category => Общий раздел => Тема начата: Geniepro от Сентябрь 04, 2012, 01:20:44 pm
-
Я давно подозревал, что отношение Ермакова к хаскеллу является глубоко необъективным по религиозной причине. Илья не скрывает свою приверженность православному христианству, а в хаскелле есть -- о ужас!!! -- монады (http://ru.wikipedia.org/wiki/Монада)!!! :o
Люцифер в мифологии Розы мира — великий демон, богорожденная монада, поднявшая бунт против замысла Бога, ставший причиной отпадения множества меньших монад — демонов.
Ну то есть очевидно, что хаскель -- зло! :'(
Но! В хаскелле же совсем другие монады (http://ru.wikipedia.org/wiki/%CC%EE%ED%E0%E4%E0_(%EF%F0%EE%E3%F0%E0%EC%EC%E8%F0%EE%E2%E0%ED%E8%E5))!!! :P так что не всё та страшно на самом деле )))
-
Монада - маловато будет. Нужна хотя бы диада:
(http://img5.joyreactor.cc/pics/post/art-%D1%82%D0%B5%D1%82%D1%80%D0%B0%D0%B4%D1%8C-119875.jpeg)
-
Geniepro блещет остроумием.
На самом деле одна из основных причин неприятия в том, что все энтузиасты новых "супервысокоуровневых" подходов толком не разобрались с резервами и возможностями "традиционных" инструментов и методов.
Поэтому у меня нет доверия к их изыскам никакого - в том плане, что решаемые проблемы могут быть решены проще. А цена за их применение - большая. Инструменты толстые, накладные расходы большие.
Короче, всё это полезный научный поиск, но реальный надёжный шаг вперёд должны делать люди, полностью исчерпавшие огромные резервы обычных императивных инструментов. А тут до исчерпания ого-го.
-
На самом деле одна из основных причин неприятия в том, что все энтузиасты новых "супервысокоуровневых" подходов толком не разобрались с резервами и возможностями "традиционных" инструментов и методов.
Да разобрались с ними уже давно -- Дейкстра и прочие. Вот и пожинаем плоды их разбирательств...
-
Евгений, Вы спрашивали, почему я лично так отношусь к Хаскеллу и ФП.
Я Вам ответил. Пока я, работая с Оберонами, раз за разом открываю какие-то новые свойства/архитектурные приёмы, ранее никому в массах неизвестные, я не буду доверять тем искателям, которые прохлопали эти свойства у себя под ногами, а теперь ведут "добычу где-то на Луне".
Если я нахожу жемчужинки в возможностях применения инструмента малого размера, почему я должен доверять изыскам тех, кто что-то городит на порядок более громоздкое. Когда я исчерпаю возможности текущих интересующих меня подходов, займусь другими. Аккуратно и экономно займусь.
-
Евгений, Вы спрашивали, почему я лично так отношусь к Хаскеллу и ФП.
Я Вам ответил. Пока я, работая с Оберонами, раз за разом открываю какие-то новые свойства/архитектурные приёмы, ранее никому в массах неизвестные
А можно пример подобного?
-
Я ими периодически делился. Например, про возможность сочетать герметичность и валидность ссылок с работой без GC. Это невозможно и в Java, ни в C#. Принципиально невозможно. И много более мелких моментов.
Моё основное направление мысли пока что - это как многие актуальные проблемы, которые народ решает новыми языками, можно решить библиотечно, используя сочетание свойств Оберона.
Когда Google в 2009-м году публиковал свой Go и тестовый примерчик с Веб-сервером, у меня был только что написан свой HTTP-сервер, который месяц пахал "в боевом режиме". Дело не в том, что я мерялся чем-то там с Гуглом, но я чётко увидел, что они решают тот же спектр проблем и подобной "алгеброй типов и операций". Только новый язык - это позволительно гуглу и академикам, для всех остальных это слишком накладный и неэффективный способ пробовать новые идеи.
-
Я ими периодически делился. Например, про возможность сочетать герметичность и валидность ссылок с работой без GC. Это невозможно и в Java, ни в C#.
Зато это возможно как минимум в Аде (от 83 года) и в С++ (через свои типы). Как минимум. Также, если мне склероз не изменяет, в одном из фортранов. То есть ничего нового.
(кстати, а вы знаете, что в .net'e не гарантируется что value-тип будет на стеке? :-) также как в java никто не гарантирует что объект будет в куче. и, если на то пошло, то и в Обероне нет ни слова про стек и кучу )
Когда Google в 2009-м году публиковал свой Go и тестовый примерчик с Веб-сервером, у меня был только что написан свой HTTP-сервер, который месяц пахал "в боевом режиме". Дело не в том, что я мерялся чем-то там с Гуглом, но я чётко увидел, что они решают тот же спектр проблем и подобной "алгеброй типов и операций". Только новый язык - это позволительно гуглу и академикам, для всех остальных это слишком накладный и неэффективный способ пробовать новые идеи.
Go'шный примерчик с Веб-сервером тоже никакой новизны в себе не нес. Подобному подходу минимум 20 лет :-)
Нет, я отлично понимаю что ты для себя открываешь все новые и новые подходы и приемы. Это здорово, я тоже периодически открываю для себя нечто эдакое. Но это не значит что это прям таки новаторские приемы не известные широко. Они известны и применяются, просто чтобы их понять и увидеть нужно до них дорости. Как дорос - начинаешь их видеть много где.
Также не вижу смысла ограничивать себя пристальным разглядыванием одного ЯП, много лучше (как мо мне) смотреть сразу на несколько. Иметь одновременно несколько точек зрения. Когда поработал на хаскеле, пощупал ерланг, увидел smalltalk, то совершенно по новому, более ясно видишь суть разных подходов в разных языках, видишь их общность. Общая картина становится ясна. И новые для себя подходы на любом языке (даже на хорошо знакомом) открываются много проще.
-
Я ими периодически делился.
Да, я потому и попросил дать примеры, потому что каждый раз когда ты чем-то делился, я видел что подобное давно в мейнстриме применяется.
-
Я ими периодически делился. Например, про возможность сочетать герметичность и валидность ссылок с работой без GC. Это невозможно и в Java, ни в C#.
Зато это возможно как минимум в Аде (от 83 года) и в С++ (через свои типы). Как минимум. Также, если мне склероз не изменяет, в одном из фортранов. То есть ничего нового.
Вы так хорошо друг друга поняли, а я нет. Что такое "сочетать герметичность и валидность ссылок с работой без GC. Это невозможно и в Java, ни в C#" ? ? ?
-
Нет, я отлично понимаю что ты для себя открываешь все новые и новые подходы и приемы. Это здорово, я тоже периодически открываю для себя нечто эдакое. Но это не значит что это прям таки новаторские приемы не известные широко. Они известны и применяются, просто чтобы их понять и увидеть нужно до них дорости. Как дорос - начинаешь их видеть много где.
Алексей, я здесь не рекламу делаю, меня спросили в начале ветке почему мне что-то там не интересено.
Я ответил - потому что имею возможности не заморачиваться, делать сам инструменты, не зависеть от кого-нибудь, кто вложил годы в свои инструменты и теперь всех на них подсаживает. Делаю свои и решая разные задачи, которые передо мной ставит жизнь. Особенно если учесть свои возможности подготовки кадров.
Также не вижу смысла ограничивать себя пристальным разглядыванием одного ЯП, много лучше (как мо мне) смотреть сразу на несколько. Иметь одновременно несколько точек зрения. Когда поработал на хаскеле, пощупал ерланг, увидел smalltalk, то совершенно по новому, более ясно видишь суть разных подходов в разных языках, видишь их общность. Общая картина становится ясна. И новые для себя подходы на любом языке (даже на хорошо знакомом) открываются много проще.
Период знакомства с самыми разными языками у меня прошёл очень давно. Все основные и неосновные книги по языкам, парадигмам (типа Пратта, Кауфмана, Бен-Ари и много других) были перечитаны. Уважаю компактные языки типа Форта, Смоллтока, Лиспа, Эрланга и проч., но вижу, что по универсальности и подходящести под любую задачу и "под любой свежий мозг свежего кадра" они уже Оберона. Уважаю Аду за основательность и гарантии, но позволить себе зависимость от такого жирного инструментария не могу. Принимаю подход Страуструпа в плане свойств "универсального языка системного программирования", вообще библиотечно на КП воплощаю некоторые свойства, достижимые именно на С++ (на котором я тоже пописал 2 года).
В общем, я сейчас однозначно за подход библиотечных экспеиментов, как самый экономичный, близкий к практике. На базе Оберона, потому что... сто раз говорено, почему. Язык выше уровнем, прячущий императивную машину, задаром не нужен, ибо я её и сам спрячу библиотечно. Языки того же уровня ничего принципиального содержать не могут, а цена зависимости от жирного инструмента высока.
Какие могут быть дальнейшие шаги, если не зацикливаться на текущей области? Думаю, в частности, подход семантических сред, генерации из табличных-графических спецификаций, и т.п. Над удачными библиотеками обычного императивного ЯП.
Ну а ФП... курит. :)
-
Go'шный примерчик с Веб-сервером тоже никакой новизны в себе не нес. Подобному подходу минимум 20 лет :-)
Примерчик не нёс. Я его даже и не смотрел.
Идея безопасного программирования системных и сетевых приложений - нова.
Говоря оберонистым языком - запрограммировать реализацию любого сетевого протокола/сервиса быстро, с хорошей абстракцией/декомпозицией, с эффективным использованием памяти (без GC) - и в то же время без SYSTEM.
У меня это уже работало как раз тогда, когда Гугл это опубликовал...
-
с эффективным использованием памяти (без GC)
Если будет когда-нибудь время, напишите пожалуйста, какими принципами при этом пользуетесь. Особенно в плане безопасности (Оберон без GC - ручное удаление или резерв однажды выделенной памяти?).
-
с эффективным использованием памяти (без GC)
Если будет когда-нибудь время, напишите пожалуйста, какими принципами при этом пользуетесь. Особенно в плане безопасности (Оберон без GC - ручное удаление или резерв однажды выделенной памяти?).
Банальная автоматическая память. То есть все на стеке.
-
или регионы памяти...
-
Так ведь у стопки весьма ограниченный размер и её глубину сложно прогнозировать.
или регионы памяти...
Зарезервированное место фиксированного размера с реальным выделением при потребности? Если да, то логически ничем не отличается от большого статического массива (кроме экономии памяти, доступной другим приложениям).
-
Так ведь у стопки весьма ограниченный размер и её глубину сложно прогнозировать.
Стопка -- в смысле стек? Стек можно располагать и на куче, если транслятор умеет это делать, тогда его размер можно указать хоть в гигабайт, лишь бы памяти хватило...
или регионы памяти...
Зарезервированное место фиксированного размера с реальным выделением при потребности? Если да, то логически ничем не отличается от большого статического массива (кроме экономии памяти, доступной другим приложениям).
http://oberspace.dyndns.org/index.php/topic,310.msg7517.html#msg7517
-
Так ведь у стопки весьма ограниченный размер и её глубину сложно прогнозировать.
Зависит от реализации (и от железяки). Весьма часто стек и куча делят память между собой. То есть есть у тебя скажем 100 Мб ОЗУ, и если из них стек скушает 80 мегабайт (после глубокой рекурсии), то на кучу останется 20 мегабайт.
Стек аппаратным бывает не слишком часто. Железяка обычно ничего не знает ни про кучу ни про стек. Есть просто память и есть указатель на вершину стека в регистре каком-то там.
Скажем в линуксе на x86 есть возможность сделать стек безразмерным (ограничено будет лишь объемом ОЗУ). То же самое в msp430 в принципе (другие подходы не эффективны и сложны, кроме того, в МК куча обычно не используется вообще - все на стеке (автоматическая) и "глобальных" переменных (статическая память) - глобальные в кавычках, потому что область видимости у них не глобальная).
-
Стопка -- в смысле стек?
Да, если вы не против, я люблю русские слова.
http://oberspace.dyndns.org/index.php/topic,310.msg7517.html#msg7517
Хоть убейте, ручное управление как было, так и осталось. Вот что интересно. Создали мы регион на 1000 объектов, все выделили, 500 из них стало мусором, просим выделить ещё один и программа валится на невозможности это сделать. Имеем простой самодельный менеджер памяти с функциями Alloc и ClearAll.
-
Стопка -- в смысле стек?
Да, если вы не против, я люблю русские слова.
Это не всегда полезно, особенно в программировании.
И почему какая-то там стопка (тарелок, видимо), а не стандартный для русскоязычной программистской терминологии магазин?
-
Это не всегда полезно, особенно в программировании.
Это точно - лично мои ассоциации с чакушкой и поллитра... ну и некоторая неприязнь к крайностям (это сугубо личное) в виде русофобии и русофилии..
-
ну все раз такая ассоциация пошла - нужно выпить пива...
-
Go'шный примерчик с Веб-сервером тоже никакой новизны в себе не нес. Подобному подходу минимум 20 лет :-)
Примерчик не нёс. Я его даже и не смотрел.
Стоп. Если ты его даже не смотрел, то о чем вообще речь?
Идея безопасного программирования системных и сетевых приложений - нова.
Говоря оберонистым языком - запрограммировать реализацию любого сетевого протокола/сервиса быстро, с хорошей абстракцией/декомпозицией, с эффективным использованием памяти (без GC) - и в то же время без SYSTEM.
Во-первых, при чем тут системное программирование вообще (особенно если мы говорим в контексте Go)? (вообще системное программирование - ужасный термин. под ним подразумевает столько всего сразу.. и написание драйвера системное программирование (хотя это банальнейшая программа работающая с железякой напрямую) и написание компилятора/транслятора внезапно тоже системное (а там наоборот - не банальная задача в полном отрыве от железа) )
Во-вторых чем сетевое программирование так уж принципиально отличается от банальной работы с файлами? По сути реализация какого-либо (сетевого)протокола это банальный парсер + конечный автомат (возможно с памятью). И то и другое отлично формализуется и автоматизируется.
А работа с файлами сетью эффективно и безопасно есть в той же Аде (привет 1983 год!), а если не пытаться писать все руками, то это безопасно и эффективно будет в любом языке, даже в Си. Заодно получим некоторые дополнительные преимущества, которые при программировании ручками ну никак не достижимы (и это уберет еще один класс ошибок).
-
Я ими периодически делился. Например, про возможность сочетать герметичность и валидность ссылок с работой без GC. Это невозможно и в Java, ни в C#.
Зато это возможно как минимум в Аде (от 83 года) и в С++ (через свои типы). Как минимум. Также, если мне склероз не изменяет, в одном из фортранов. То есть ничего нового.
Вы так хорошо друг друга поняли, а я нет. Что такое "сочетать герметичность и валидность ссылок с работой без GC. Это невозможно и в Java, ни в C#" ? ? ?
Насколько я понял, речь идет о полиморфных объектах на стеке с невозможностью утекания ссылок на них куда-то во вне и без рукопашного управления памятью. Собственно ровно то, из за чего ты ковыряешь тему Оберона под .net.
Но я тут подумал, и пришел к выводу что в случае java у оптимизатора достаточно информации для того чтобы описанный Ильей сценарий реализовывался всегда когда это возможно. То есть, переходя к сишным терминам, new Foo будет всегда когда это возможно вызывать не malloc, а alloca. Причем у оптимизатор тут может работать более эффективно чем человек (потому что он не ленится заглянуть во все библиотеки и выявить все места где это возможно).
(про C# ничего не скажу, я его не знаю)
-
Я ответил - потому что имею возможности не заморачиваться, делать сам инструменты, не зависеть от кого-нибудь, кто вложил годы в свои инструменты и теперь всех на них подсаживает. Делаю свои и решая разные задачи, которые передо мной ставит жизнь. Особенно если учесть свои возможности подготовки кадров.
А какие ты инструменты делаешь? Насколько я вижу (то есть то что публично известно) компиляторы Оберона например ты не пишешь.
Период знакомства с самыми разными языками у меня прошёл очень давно. Все основные и неосновные книги по языкам, парадигмам (типа Пратта, Кауфмана, Бен-Ари и много других) были перечитаны. Уважаю компактные языки типа Форта, Смоллтока, Лиспа, Эрланга и проч., но вижу, что по универсальности и подходящести под любую задачу и "под любой свежий мозг свежего кадра" они уже Оберона.
Не скажу за смоллтолк и лисп, я их не слишком знаю (да, чтобы знать lisp не достаточно знать s-expressions, нужно целиком осилить весь Common Lisp, и, да, я бы не назвал его компактным :-) ), но форт и ерланг применимы там и решают те задачи, где оберон будет смотреться ну очень не к месту. Я вообще слабо себе представляю как можно противопоставлять оберон и ерланг. Они просто для разного созданы. Совсем для разного. На уровне того что пишешь в момент изучения языка (пишешь сам с нуля) этого просто не видно.
Уважаю Аду за основательность и гарантии, но позволить себе зависимость от такого жирного инструментария не могу.
У Ады сейчас одна радость и одна печаль - AdaCore. Радость потому, что AdaCore Аду развивает, печаль потому, что AdaCore либо вытеснила либо поглотила всех конкурентов. Моновендор (которому к тому же не интересны все кто мельче Боинга).
Принимаю подход Страуструпа в плане свойств "универсального языка системного программирования", вообще библиотечно на КП воплощаю некоторые свойства, достижимые именно на С++ (на котором я тоже пописал 2 года).
К сожалению те свойства, которые мне нужны от С++, на КП не достижимы.
В общем, я сейчас однозначно за подход библиотечных экспеиментов, как самый экономичный, близкий к практике. На базе Оберона, потому что... сто раз говорено, почему. Язык выше уровнем, прячущий императивную машину, задаром не нужен, ибо я её и сам спрячу библиотечно. Языки того же уровня ничего принципиального содержать не могут, а цена зависимости от жирного инструмента высока.
С++ выше уровнем чем Оберон. Ada, С# и даже Java - тоже выше. Ниже уровнем, если не ошибаюсь, Паскаль (обычный, не Object). А вот Modula-3 уже выше. Куда поставить Си я затрудняюсь сказать (по некоторым признакам он ниже уровнем, по некоторым выше).
-
Да, как пример где нет ручного управления памятью (для объектов) и сборщика мусора тоже нет: Objective-C 2.0
И все эффективно :-)
-
Да, на счет эффективности подхода Go. Вот результаты теста того самого Web-сервера
(http://timyang.net/blog/wp-content/uploads/2009/11/c_erlang_java_go.png)
Как видим, Java с её не эффективной работой с памятью этот самый эффективный Go как Тузик грелку.
Ах да, под большими нагрузками у Go-примерчика еще и самая большая латентность (по горизонтали число одновременных соединений: 30, 100, 1000, 5000 соответственно, латентность в миллисекундах):
| 30 | 100 | 1000 | 5000 |
| Nginx html(1C) | 1 | 4 | 42 | 3,079 |
| Nginx module(1C) | 1 | 4 | 32 | 3,047 |
| Nginx module(Multi-core) | 1 | 6 | 205 | 3,036 |
| Erlang(1C) | 3 | 8 | 629 | 6,337 |
| Erlang(Multi-Core) | 2 | 7 | 223 | 3,084 |
| Java, Netty | 1 | 3 | 3 | 3,084 |
| Go | 26 | 33 | 47 | 9,005 |
Желающие могут перепроверить на современных версиях всего этого: http://timyang.net/programming/c-erlang-java-performance/
PS. Илья, помнится писал что его Веб-сервер, видимо тот самый о котором в данном треде идет речь, бегал почти или также шустро как Apache web server, так вот, апач тут был бы еще медленее чем Go.
-
Да, интерпретируемый функциональный erlang (оторванный от реального железа и замаскировавший императивную машину) со сборщиком мусора работает на уровне java и быстрее чем хвалимый Go.
-
А вот тут сравнение Go с Python'ом: http://ziutek.github.com/web_bench/ Внезапно быстродействие одно и то же.
-
Я ответил - потому что имею возможности не заморачиваться, делать сам инструменты, не зависеть от кого-нибудь, кто вложил годы в свои инструменты и теперь всех на них подсаживает.
Кстати, а что значит "подсаживает"? Ну вот кто конкретно подсаживает например на С++?
И, какие такие специфические у тебя задачи, что тебе требуется автономность в плане компиляторов (именно компиляторов, в плане ОС и другого софта а также железа, по моему, у тебя нет таких требований).
Откровенно говоря, я не вижу смысла отказываться от сообщества.
-
По поводу того, как работаю с памятью, я кое-что писал - и меня тут уже даже цитировали где-то на этом форуме.
Не регионы. Не стек для объектов. Конечно, использование является как раз фишкой Оберона по сравнению с Java/C#, в том смысле, что массивы/строки и проч., нужные для того чтобы принять-передать части данных, можно держать полностью на стеке. Ясен хрен, что изменить Java, ввести всякие оптимизации можно, только вы сможете это сделать? И какую сложность и багонасыщенность имеют все новые рантаймы, даже от больших корпораций?
А какие ты инструменты делаешь? Насколько я вижу (то есть то что публично известно) компиляторы Оберона например ты не пишешь.
Библиотеки для серверных и веб-приложений и NoSQL. Для своих задач и, кроме того, держа в голове каждый раз то, насколько удобно я смогу на этом кого-нибудь научить.
Они просто для разного созданы. Совсем для разного. На уровне того что пишешь в момент изучения языка (пишешь сам с нуля) этого просто не видно.
Конечно. Эрланг создан как DSL для приложений массового обслуживания. Безусловно, ему в конкретной нише общий язык проиграет. Но применяться он там тоже сможет. И если ведётся разработка для разных ниш, то нецелесообразно использовать разные языки. Не будет накопления компонентов.
С++ выше уровнем чем Оберон. Ada, С# и даже Java - тоже выше. Ниже уровнем, если не ошибаюсь, Паскаль (обычный, не Object). А вот Modula-3 уже выше. Куда поставить Си я затрудняюсь сказать (по некоторым признакам он ниже уровнем, по некоторым выше).
Модула-3 - очень хороший, очень аккуратно спроектированный язычок. Но для меня крест поставило на нём то, что всё ООП там только на куче. Приехали :)
-
Кстати, а что значит "подсаживает"? Ну вот кто конкретно подсаживает например на С++?
Не в смысле злонамеренности... Но в смысле общественного мнения, например.
Блин, Алексей, ну Борланд же оценивал, было дело, разработку компилятора С++ в 100 млн.$ Во сколько раз должен он увеличивать производительность и проч., что было оправдано применение его, а не того инструмента, который на порядок дешевле?
Это обманчивое впечатление, что "оно уже разработано - какая разница, сколько внутри человекочасов". Это зависимости от сложности, одна сложность тянет другую - всё это накапливается лавинообразно, ну блин, это же видно. Сколько технологий, отсосавших внимание, силы, деньги (ресурсы планеты, в конце концов :) ) было - CORBA, COM, COM+.... ? В Java и .NET научились, с горем пополам, удерживать громоздкость на тот уровне, чтобы это было не обузой, а реально доступным людям инструментом. Но, в принципе, что мешало сделать это раньше, не плутая по дебрям избыточной сложности предыдущих компонентных технологий? Не в последнюю очередь дух С++, кстати, в широком смысле :) Эйфория от сложности.
Давайте подумаем, сколько человек на планете именно сейчас тратит своё время на изучение новой модной мейнстримной технологии, вместо того, чтобы делать что-то нужное и/или что-то полезное.
Откровенно говоря, я не вижу смысла отказываться от сообщества.
А смысл в сообществе, продукты которого я не могу применять из-за того, что они недостаточно "рафинированы", если я вынужден проходить цепочку мысли по каждой задаче самостоятельно, чтобы найти более компактный и базовый вариант, потому что кто-то не потрудился этого сделать?
-
И почему какая-то там стопка (тарелок, видимо), а не стандартный для русскоязычной программистской терминологии магазин?
По трём причинам:
1) Один из прямых переводов.
2) Яркое соответствие смыслу структуры данных. Стопка книг или тарелок, сверху кладём, сверху забираем.
3) Близко к английскому варианту, так как тоже начинается на "ст".
То, что heap не хип, а куча, никого ведь не смущает.
-
То, что heap не хип, а куча, никого ведь не смущает.
Скажите, а компьютер Вы называете "электронной вычислительной машиной" и никак иначе?
Трансляторы/интерпретаторы -- толмачами, переводчиками на машинный язык?
Вообще само "программирование" тоже надо перевести на русский, например как "планирование действий для вычислений"...
А может быть стоит всё же использовать устоявшиеся, общеупотребительные термины, ведь половина проблем непонимания возникает из-за несогласованности в терминологии...
-
Отсутствует механизм отсева, фильтрации мусора. Нет таких слов, как юзабилити и фреймворк, бенчмарк и сплайсинг. Наверное по той же причине, по которой нет слов nastrojka, karkas, razjom. В настоящее время появиться "термину" не сложно: берёте английское слово и делаете транскрипцию, начинаете употреблять. Не сразу, но подтянутся.
-
Отсутствует механизм отсева, фильтрации мусора. Нет таких слов, как юзабилити и фреймворк, бенчмарк и сплайсинг. Наверное по той же причине, по которой нет слов nastrojka, karkas, razjom.
Зато есть слово Sputnik.
Жаргонизмы следуют за лидером.
-
Русская интеллигенция всегда отдавала предпочтение иностранным языкам, использованию заимствованных слов в устной и письменной речи. Этот феномен жив и сейчас. В любом случае, думаю, вряд ли произойдёт что-то страшное, если будет употреблён именно перевод, пусть и непривычный, а если не употреблять, то альтернатив никогда и не появится.
-
Русская интеллигенция всегда отдавала предпочтение иностранным языкам, использованию заимствованных слов в устной и письменной речи. Этот феномен жив и сейчас. В любом случае, думаю, вряд ли произойдёт что-то страшное, если будет употреблён именно перевод, пусть и непривычный, а если не употреблять, то альтернатив никогда и не появится.
Да не, я то не против. Сам иногда стек называют стопкой (и да, с алкоголем у меня почему-то не ассоциируется).
А феномен потому имеет место, что русский язык отлично впитывает (обвязывая приставками/суфиксами) корни иностранных слов. И я не вижу в этом ничего плохого - больше корней, однозначней фразы. Англоговорящих мне даже жалко. У них очень контекстно зависимые предложения получаются.
Но я против повторного заимствования слов. Например замечательное слово экспертиза (да, это заимствованное слово) сейчас заимствуется повторно в другом смысле - экспертиза это опыт (опыт человека). Таким образом вместо узкого устоявшегося значения слова появляется новое, что вносит неоднозначность.
-
В любом случае, думаю, вряд ли произойдёт что-то страшное, если будет употреблён именно перевод, пусть и непривычный, а если не употреблять, то альтернатив никогда и не появится.
Да, в худшем случае Вас просто не поймут и Вам придётся объяснять, что Вы имеете в виду, иначе из-за непонимания обсуждение будет развиваться неизвестно как...
-
Я ими периодически делился. Например, про возможность сочетать герметичность и валидность ссылок с работой без GC. Это невозможно и в Java, ни в C#.
Зато это возможно как минимум в Аде (от 83 года) и в С++ (через свои типы). Как минимум. Также, если мне склероз не изменяет, в одном из фортранов. То есть ничего нового.
Вы так хорошо друг друга поняли, а я нет. Что такое "сочетать герметичность и валидность ссылок с работой без GC. Это невозможно и в Java, ни в C#" ? ? ?
Насколько я понял, речь идет о полиморфных объектах на стеке с невозможностью утекания ссылок на них куда-то во вне и без рукопашного управления памятью. Собственно ровно то, из за чего ты ковыряешь тему Оберона под .net.
Так у меня не стек, у меня куча управляемая врукопашную, но безопасно (без порчи памяти). Мой тезис состоит в том, что при больших объёмах оперативной памяти (гораздо больших чем даст 32 разрядный Блэкбокс) использование сборщика мусора становится нежелательным из-за слишком длинных пауз: Паузы в работе программы вызываемые GC (http://oberspace.dyndns.org/index.php/topic,173.0.html). Например, на уборку мусора всего лишь на 8 Гб в дотнете может уйти до 20 секунд на Core i7 2600K, что же будет если программа займёт 32-64 Гб оперативки? А если несколько сотен гигабайтов??? Моё ковыряние -- поиск безопасных способов организации работы с очень большой памятью, на которой никакой GC эффективно работать не сможет. Размещение объектов на массивах структур и обращение к ним по индексам прокатывает. Порча памяти невозможна так как всё сэйфное. Работает за О(1). Правда с индексами массива встаёт проблема подобная проблеме "повисших указателей". Вот такая фигня. Как мне кажется её можно на 95% победить сделав оператор присваивания "умных индексов" приватным. Почти как в плюсах. Но только в плюсах пошли уж слишком далеко -- разрешили его переопределять, по моему достаточно всего лишь делать его приватным.
-
Размещение объектов на массивах структур и обращение к ним по индексам прокатывает. Порча памяти невозможна так как всё сэйфное. Работает за О(1). Правда с индексами массива встаёт проблема подобная проблеме "повисших указателей". Вот такая фигня.
Может стоит эти массивы организовать по принципу регионов памяти?
Как стал ненужным какой-то кусок такого массива (группа объектов в нём) -- так и освобождать его целиком, не заботясь об объектах по отдельности...
-
Может стоит эти массивы организовать по принципу регионов памяти? Как стал ненужным какой-то кусок такого массива (группа объектов в нём) -- так и освобождать его целиком, не заботясь об объектах по отдельности...
Тут парится не из-за чего, так как взять или освободить объект на массиве - это O(1). Просто держится список (точнее стек) свободных элементов. Свободить объект означает поместить в этот стек индекс элемента массива. Создать объект означает взять из стека индекс свободного элемента, а если стек пуст, то запросить у ОС ещё одну "страницу". "Страничную" организацию (массив указателей на массивы вместо одномерного массива) я использую чтобы у операционной системы слишком много памяти с самого начала не брать: новую "страницу" запрашиваю по мере надобности. Если на какой-то "странице" объекты перестали использоваться, то её можно было бы и вернуть обратно в операционную систему, но иногда это делать противопоказано. Я имею дело с программами которые работают, скажем так, циклически 365/7/24. Изо дня в день программа выполняет практически одно и тоже (телефонная станция), а значит если ей один раз понадобилось сколько-то памяти под объекты определённого сорта, то через некоторое время она понадобится ещё раз. Через несколько дней работы программа отъест сколько-то памяти и практически перестанет запрашивать новую память. Расход памяти такой "циклической" программой в зависимости от времени очень похож на логарифмический. Для программ общего назначения конечно память обратно в систему отдавать надо.
-
Свободить объект означает поместить в этот стек индекс элемента массива.
Но эту операцию (по сути аналог оператора delete) приходится делать вручную? И, так же как с delete, её можно забыть сделать и вызвать "утечку памяти"?
Регионы могли бы автоматизировать этот процесс...
-
Регионы могли бы автоматизировать этот процесс...
Как?
-
Регионы могли бы автоматизировать этот процесс...
Как?
Ну как вариант, придётся сделать некий класс -- аллокатор в этом массиве, знающий про тот стек, и работать через него.
Сам этот класс должен реализовать интерфейс IDisposable, и затем его использование оформить внутри оператора using -- тогда при выходе действия программы за пределы жизни этого региона (выход за пределы оператора using) автоматически освободит (вернёт в стек) ненужные уже элементы того массива (их индексы).
Хотя, возможно, там придётся повозиться с многопоточностью, и, видимо, как-то разрулить вложенные регионы...
-
... как-то разрулить вложенные регионы...
Возможно, для каждого региона придётся создавать отдельные стеки, и как-то увязывать эти стеки между собой...
-
Может стоит эти массивы организовать по принципу регионов памяти? Как стал ненужным какой-то кусок такого массива (группа объектов в нём) -- так и освобождать его целиком, не заботясь об объектах по отдельности...
Тут парится не из-за чего, так как взять или освободить объект на массиве - это O(1). Просто держится список (точнее стек) свободных элементов. Свободить объект означает поместить в этот стек индекс элемента массива. Создать объект означает взять из стека индекс свободного элемента, а если стек пуст, то запросить у ОС ещё одну "страницу".
Это ручное управление памятью в чистом виде внутри отдельного "адресного пространства" (с точно теми же рисками (в рамках того "адресного пространства")). По сути, эмуляция своего аллокатора. В яве подобными вещами тоже занимаются иногда (но не всегда с точно той же целью).
Для программ общего назначения конечно память обратно в систему отдавать надо.
Программ общего назначения не бывает :-) Наверно ты хотел сказать - интерактивных программ которые работают на персональном компьютере (сюда же конечно входят и телефоны со смартфонами и планшетники).
-
Это ручное управление памятью в чистом виде.
Давай выражение "в чистом виде" оставим для обозначения случая когда сохраняется возможность порчи памяти. Размещение объектов на массивах структур безопасно - порчу памяти вызвать не может. Надо эти градации ручного управления как-то различать. Программ общего назначения не бывает :-) Наверно ты хотел сказать - интерактивных программ которые работают на персональном компьютере (сюда же конечно входят и телефоны со смартфонами и планшетники).
Да, я имел в виду что-то вроде этого. Надо было сказать для рантаймов общего назначения. В частности рантаймы дотнета, явы или блэкбокса должны уметь возвращать память обратно в ОС. Правда рантайм блэкбокса так этому и не научился до сих пор...
-
Это ручное управление памятью в чистом виде.
Давай выражение "в чистом виде" оставим для обозначения случая когда сохраняется возможность порчи памяти. Размещение объектов на массивах структур безопасно - порчу памяти вызвать не может. Надо эти градации ручного управления как-то различать.
Ну, саму память испортить достаточно сложно (хотя флеш-память в МК я пожалуй смогу убить за несколько дней).
А вот получить по данному индексу/идентификатору не тот объект который ожидаешь (кто-то уже переиспользовал эту ячейку массива объектов) - вполне можно. И это вполне эквивалентно тому, если бы скажем в C++ для объектов некоторого типа я отведу средствами ОС отдельное адресное пространство (то есть как в нем ни гадь, ничего не затрешь из того что вне его), написал свой аллокатор/менеджер памяти для этого адресного пространства, и стал бы там ручками манипулировать (руками new, руками delete).
То есть отличие конечно есть. И градации нужно проводить. Но и общее в этих подходах также имеется. Причем общего больше чем различного.
Программ общего назначения не бывает :-) Наверно ты хотел сказать - интерактивных программ которые работают на персональном компьютере (сюда же конечно входят и телефоны со смартфонами и планшетники).
Да, я имел в виду что-то вроде этого. Надо было сказать для рантаймов общего назначения. В частности рантаймы дотнета, явы или блэкбокса должны уметь возвращать память обратно в ОС. Правда рантайм блэкбокса так этому и не научился до сих пор...
Это да. Кстати, поскольку ява больше ориентировалась на сервера (долгое время) странички памяти обратно системе отдавать она научилась довольно недавно - лет шесть-семь назад. Ну и, помню, в Borland C++ Builder'e 6.0 тоже была эта беда, и, видимо в соответствующей делфи тоже. Впрочем народ-делфисты быстро написали свой менеджер памяти который полностью заменяет борландовский стандартный. И счастье наступило (народный менеджер работает быстрее и странички возвращает).
-
Кстати, я могу сесть в лужу со своими изысканиями если скорость работы памяти будет расти быстрее чем её объём. Ведь если будет расти скорость работы памяти, то будет расти и скорость работы сборщика мусора. Если бы сейчас память работала в 20 раз быстрее, то сбор мусора на 8 Гигах отнимал бы не более 1 секунды, что для меня приемлемо. Тогда не пришлось бы отказываться от GC.
Если экстраполировать, то для того чтобы не пришлось отказываться от GC при работе на 32 гигабайтах оперативки, скорость работы памяти надо увеличить в 80 раз по сравнению с DDR3 1600 Mhz 9-9-9-24. Реально такое?
-
Это да. Кстати, поскольку ява больше ориентировалась на сервера (долгое время) странички памяти обратно системе отдавать она научилась довольно недавно - лет шесть-семь назад.
Я подумал, и понял что не прав - это было так (по крайней мере по умолчанию) в сановских реализациях java, но ведь были и другие (сертифицированные, то есть прошедшие все тесты) реализации которые никак от sun не зависили, например от IBM. Кроме того, возможно что например на солярисе сановская jvm память таки отдавала обратно (ну или была такая настройка).
-
Если экстраполировать, то для того чтобы не пришлось отказываться от GC при работе на 32 гигабайтах оперативки, скорость работы памяти надо увеличить в 80 раз по сравнению с DDR3 1600 Mhz 9-9-9-24. Реально такое?
Думаю да. Но скорее всего быстрее случится что во-первых раз в несколько вырастет сткорость ОЗУ + изменятся алгоритмы GC (я уверен что про эту проблему они знают, и в java вроде бы даже решили её (в оракловской реализации)). Тут ява немного впереди, потому что на серверах она используется более активно чем .net (в любых его ипостасях).
-
Кстати, я могу сесть в лужу со своими изысканиями если скорость работы памяти будет расти быстрее чем её объём. Ведь если будет расти скорость работы памяти, то будет расти и скорость работы сборщика мусора. Если бы сейчас память работала в 20 раз быстрее, то сбор мусора на 8 Гигах отнимал бы не более 1 секунды, что для меня приемлемо. Тогда не пришлось бы отказываться от GC.
Если экстраполировать, то для того чтобы не пришлось отказываться от GC при работе на 32 гигабайтах оперативки, скорость работы памяти надо увеличить в 80 раз по сравнению с DDR3 1600 Mhz 9-9-9-24. Реально такое?
А хрен его знает - вы же ведь не из ленивых - производительность связана с частотой, последняя связана с тех процессом ( его размерностью), последний имеет пределы ... так что если индустрия будет развиваться традиционным (вышеописанным) способом (я говорю о массовых решениях) - то все это (вклад железа) можно оценить...
-
А хрен его знает - вы же ведь не из ленивых - производительность связана с частотой, последняя связана с тех процессом ( его размерностью), последний имеет пределы ... так что если индустрия будет развиваться традиционным (вышеописанным) способом (я говорю о массовых решениях) - то все это (вклад железа) можно оценить...
Там не все так просто - увеличение быстродействия обеспечивается не только техпроцессом и повышением частоты. Там есть еще куда архитектурно расти.
-
но в любом случае, думаю , что в течении некоторого времени ваш подход 3 - 5 лет будет иметь преимущества...
-
Если по закону Мура, то через 22 года размер кэшпамяти у процессора в десктопном компьютере станет 32 гигабайта. То есть через 22 года GC стопудово можно будет использовать для программ использующих 32 гигабайта памяти. Но только по тому же закону Мура объём оперативки в десктопе станет 64 террабайта. При наличии 64 террабайтов кому будут нужны мелкие жалкие программки использующие ничтожные 32 гига? :) :) :)
-
А хрен его знает - вы же ведь не из ленивых - производительность связана с частотой, последняя связана с тех процессом ( его размерностью), последний имеет пределы ... так что если индустрия будет развиваться традиционным (вышеописанным) способом (я говорю о массовых решениях) - то все это (вклад железа) можно оценить...
Там не все так просто - увеличение быстродействия обеспечивается не только техпроцессом и повышением частоты. Там есть еще куда архитектурно расти.
да знаю я это, по этому и намекаю на то, что оценка требует определенных трудозатрат...
-
А хрен его знает - вы же ведь не из ленивых - производительность связана с частотой, последняя связана с тех процессом ( его размерностью), последний имеет пределы ... так что если индустрия будет развиваться традиционным (вышеописанным) способом (я говорю о массовых решениях) - то все это (вклад железа) можно оценить...
Там не все так просто - увеличение быстродействия обеспечивается не только техпроцессом и повышением частоты. Там есть еще куда архитектурно расти.
да знаю я это, по этому и намекаю на то, что оценка требует определенных трудозатрат...
нда - вроде как смена архитектуры на ivy bridge - дала на тех же частотах всего 15% процентов чистой производительности..
-
вроде как смена архитектуры на ivy bridge - дала на тех же частотах всего 15% процентов чистой производительности..
У меня на работе неразогнанный 2600K, а дома 3770K разогнанный до 4.2 ГГц. Память одинаковая 1600 МГц 9-9-9-24. Разница в производительности примерно 10%.
-
ну да Интель в массовом сегменте похоже , что сконцентрировалось на повышение эффективности - то есть в грубо можно предположить что при изменении архитектуры производительность изменяется на 20% а архитектура меняется раз в год прорыв (увеличение производительности скачком в 2-3 раза случается через 5 лет) можно оценить когда производительность увеличится в 80 раз (конечно лучше опираться на инфу о перспективных Интеловских разработках...).
-
даже если они и имеют в загашники 10 гигагерцивые технологии... вряд ли они будут выкидывать их на рынок пока не окупились их предыдущие вложения (серьезных конкурентов у них в этом сегменте рынка нет)
-
Посмотрел какая память сейчас продаётся (кстати, память каторую брал весной уже подешевела рублей на 400), так вот есть предложения работающие на частоте 2400 МГц с таймингами 9-11-11-31, то есть она быстрее чем память на 1600 МГц с таймингами 9-9-9-24 на величину (50%, 22%, 22%, 16%). Думаю в течение года-двух можно ожидать чего-то на уровне 2400 МГц с 8-шными таймингами, что будет на 68% быстрее. Память работающая в 2 раза быстрее вероятно уже будет DDR4, она вроде как появится не раньше чем в 2014 году.
Короче, использование GC в программах использующих 8-32 гигабайтов памяти будет оставаться нежелательным (это мягко говоря) на столько долго на сколько вообще можно сейчас предвидеть. Скорей всего, на 8 гигабайтах GC станет работать с удовлетворительной скоростью не раньше чем через десять лет.
Ну или, да, таки возьмут и изобретут другой алгоритм сбора мусора...
-
Вчера перед сном покурил монады (http://www.rsdn.ru/article/funcprog/monad.xml)
Вынос мозга.. :-\
Основную идею вроде понял. Но когда дошло до реального кода на Haskell мой мозг вскипел.
Количество букв в статье зашкаливает.
Существует более простое изложение?
-
Вчера перед сном покурил монады (http://www.rsdn.ru/article/funcprog/monad.xml)
Вынос мозга.. :-\
Основную идею вроде понял. Но когда дошло до реального кода на Haskell мой мозг вскипел.
Количество букв в статье зашкаливает.
Существует более простое изложение?
Конечно! Вот оно: монада — это моноид в категории эндофункторов. Пруф: http://iportnov.blogspot.com/2010/10/haskell-monads.html
-
Я более чем полностью уверен что там очередная элементарная хрень спрятана. Просто сложно ее разглядеть за всем этим пафосом, обилием непривычных терминов и значков. Да и лень тратить время и энергию на сомнительные вещи.
Если человек не может объяснить концепцию "на пальцах", то либо он сам ее плохо понял, либо излагать не умеет.
Оберон изучить по сообщению о языке проще, чем одну эту статью вкурить ;D
Как так?
-
Я более чем полностью уверен что там очередная элементарная хрень спрятана. Просто сложно ее разглядеть за всем этим пафосом, обилием непривычных терминов и значков. Да и лень тратить время и энергию на сомнительные вещи.
Если человек не может объяснить концепцию "на пальцах", то либо он сам ее плохо понял, либо излагать не умеет.
Оберон изучить по сообщению о языке проще, чем одну эту статью вкурить ;D
Как так?
Это так потому, что язык Оберон никаких концепций сам по себе не несет. А монады это внеязыковая довольно интересная штука. Замечу, что в хаскелле на уровне языка монады в общем то не поддерживаются, точнее там есть только do-нотация и все. Сами монады они вне языка.
А вообще, технически, монады, как и многое другое в haskell'e, эксплуатируют одну простую методику: согласование операндов в выражении через систему типов. Но, конечно, это не вся их суть :-)
Вообще, я бы советовал вначале пописать на haskell'e не задумываясь что такое монада, точнее без них вообще (это можно сделать). Через какое-то время поймешь что у тебя во многих местах имеется некий четко прослеживающийся паттерн, который неплохо бы окультурить, вот тогда-а ты и вспомнишь про монады и про do-синтаксис ;-)
-
Как говорится, пока я читаю статью по хаскеллу, у меня скринсейвер успевает запуститься раньше, чем я перелистываю страницу... )))
-
Вообще, я бы советовал вначале пописать на haskell'e не задумываясь что такое монада, точнее без них вообще
Да, а вот что надо понимать в haskell'е сразу - так это функции высшего порядка (HOF). Без этого никак. Ну и вывод типов, систему типов (хотя бы на примитивном уровне) неплохо бы знать. А монады.. Они потом. Как приятное (но не обязательное) дополнение.
-
Нашел на додиезе:
http://dogfuntomdev.wordpress.com/2012/05/20/%D0%BF%D0%B5%D1%80%D0%B5%D0%B2%D0%BE%D0%B4-%D1%87%D1%83%D0%B4%D0%BE-%D0%BC%D0%BE%D0%BD%D0%B0%D0%B4/ (http://dogfuntomdev.wordpress.com/2012/05/20/%D0%BF%D0%B5%D1%80%D0%B5%D0%B2%D0%BE%D0%B4-%D1%87%D1%83%D0%B4%D0%BE-%D0%BC%D0%BE%D0%BD%D0%B0%D0%B4/)
Надеюсь лучше пойдет :)
add: и вот еще:
http://rsdn.ru/forum/decl/4049523.1
-
Забавный коммент:
Haskell certainly hurts my brain. Sometimes it's a good hurt.
I've been playing on and off for a couple of years. I've even written a couple of tutorials on things like monad transformers. And yet on a scale of 0-10 of guruness, I feel like I'm only just climbing out of level 0.
I really enjoyed the puzzle of trying to figure out how to thread a global counter through a logic program here. But I enjoyed it because I'm a mathematician and I like puzzles for their own sake. But did I really have to go through that simply to add a counter to my code?
http://koweycode.blogspot.com/2006/08/does-haskell-hurt-your-brain.html