Здравствуйте, Глеб Алексеев, Вы писали:
V>>гораздо более слабые языки (с т.з. выразительности) ГА>Разрешите поинтересоваться, о какой выразительности идет речь? Я вот выбрал ОКамл именно из-за выразительности, верифицируемость пока на втором плане, может быть зря?
Конечно зря! Ruby -- вот правильный выбор. Ну или Oberon. В самом крайнем случае -- C#.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Не обязательно ИМХО пространно отвечать на подобные замечания. От себя добавлю — с удовольствием читаю посты reductora, особенно с удовольствием читал первые посты. К сожалению, налицо низкая "помехоусточивость". Стоит кому-нибудь пытаться увести беседу в сторону, как reductor бросается акцентами на эти факты вместо того, чтобы просто скипнуть эти абзацы в ответах. В последних постах за помехами трудно уловить единицы полезной информации.
Мне откровенно жаль вашего времени, коллеги
------------
с анонимностью все понятно, лично я для себя выбрал правило, отвечая кому-либо позволять себе только то, что позволил бы себе в очной беседе (за кружечкой-другой пива )
Здравствуйте, vdimas, Вы писали:
V>ПОЧЕМУ до сих пор С++ не приведен в состояние, более верифицируемое компилятором? От того всякие редукторы и приводят в пример гораздо более слабые языки (с т.з. выразительности), но которые обладают одним неоспоримым преимуществом — безопасностью (верифицируемостью, которая тянет за собой возможность настоящей whole program optimmization ;) ). Причем, эта безопасность достигается без managed и всяких VM. (как в Fortran в свое время, чего не скажешь, кстати, о том же Паскаль)
Пардон, я тут на ключевое слово отреагировал.
Но не могу не заметить, что окамл ни на секунду не менее выразителен, чем С++.
Больше — можно, меньше — ни-ни (с). Это без расчета на поспорить, просто личное мнение.
Одна из причин: http://caml.inria.fr/pub/docs/tutorial-camlp4/index.html
Другая:
let rec qsort array = match array with
[] -> []
| pivot::rest -> let left,right = List.partition (function x -> x < pivot) rest
in (qsort left) @ pivot::(qsort right);;
V>OCalm еще явно сырой. Но представь хоть на минуту, если в него вложить столько же усилий, сколько в С++ от MS. Мне не нравится этот язык, просто я отдаю себе отчет в потенциале верифицируемого и заведомо оптимизируемого кода.
Как язык окамл не сырой. Да и вообще он не то, чтобы сырой — просто разработчики родного компилятора считают, что чем проще компилятор, тем лучше. Где-то они правы.
А так у у него некоторые вещи — просто произведения искусства. Тот же GC, например.
Окамлу 15 лет уже и он уже много где очень хорошо поработал.
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, alexeiz, Вы писали:
A>>Здравствуйте, c-smile, Вы писали:
CS>>>D как язык для UI лучше чем C++ скажем в разы. Это я со всей отвественностью CS>>>могу сказать.
A>>А причины не трудно описать? По пунктам и конкретно. А то не очень-то верится.
CS>(this caffe has no russian keyboard installed yet, so msg is in english)
CS>First of all all these is based on my projects: CS>D — Harmonia framework CS>Java — J-SMILE and others. CS>C++ — HTMLayout and other projects.
CS>1) GC. GC helps a lot managing DOM/windows/elements structure. This is huge in fact. Simplifies significantly code. Makes it clean and compact thus more robust.
Мне кажется, что это просто аргумент в пользу GC, а не конкретно GC для программирования UI. В UI обычно у каждого элемента есть свой owner, который его и освобождает. Так устроено в MFC, QT, да и даже в старом Motif'е. Может быть внутри фреймвока и легче отслеживать время жизни элементов с помощью GC, но для пользователя это никогда не было проблемой.
Кстати, о проблемах с GC в UI. Бывает и так: пользователь открывает новое окно/диалог, который отъедает кучу ресурсов. Пользователь закончил свою работу с окном, закрыл его. А ресурсы всё ещё в памяти. GC ни сном ни духом не ведает, что при закрытии окна нужно что-то освободить. А пользователь жалуется. Мол окно уже закрыто, почему программа до сих пор столько памяти держит? И вот GC ждёт пока другое такое ресурсопрожорливое окно откроется, тогда он сразу спохватится, начнёт освобождать. А окно в это время тормозит.
Да и на C++ это дело можно сделать, так как GC имеются, а в большинстве случаев smart pointer'ов дольжно быть достаточно.
Поэтому тут по возможностям D не перекрывает C++.
CS>2) Closures/Delegates. This in fact is not so critical as I am using sinking/bubbling. Let's say it is nice to have feature — allows to simplify code and make it more understandable an regular.
boost::function, boost::signal? win32 gui generics использует этот же механизм. C++ не нужно иметь delegates в языке, т.к. они есть в библиотеке.
CS>3) Properties (getters/setters). Ideally reduces twice methods you need to remember. Again, it is about simplification.
Если бы ты упомянул свойства для создания компонент с их последующем использовании в дизайнере, то это бы имело смысл. А иначе свойства представляют спорный вопрос, опять же не имеющий отношение к UI per se.
CS>4) There are more features in D helping UI development e.g. mixins and templates parametrized by character strings, etc., I'll skip them here.
Миксины есть в C++. Curiously recurring template pattern, policies — это всё имеет отношение к миксинам.
Может быть параметризация шаблонов строками и помогает. Об этом судить не берусь.
CS>Use of Java for massive UI development has one and big benefit — isolation between logic and system low level and critical functions. This is sort of critical for development in teams.
Здесь не совсем понятно, что ты имеешь ввиду, и каким образом это подкрепляет аргумент в пользу Java для программирования UI.
CS>And again Java has good set of design tools. Intellisense is a real tool increasing productivity.
You mean UI design tools? К языку это имеет опоследовательное отношение. Для C++ тоже есть UI design tools.
Здравствуйте, vdimas, Вы писали:
V>Я бы внес в стандарт С++ невозможность взятия адреса локальной переменной или адреса значения по ссылке. Это нонсенсы и унаследованные совершенно ненужные св-ва С.
Скорее, от ассемблера. Без этой возможности сложно что-то вообще написать, на языке такого уровня. Компилятор так или иначе будет это делать, хотя бы неявно, как для var в Pascal.
V>Ты даже не представляешь как это далеко от совершенства на виртуальных
На виртуальных работает плохо, за исключением случаев, когда компилятор способен заменить вызов на обычный.
V>экспортируемых или библиотечных ф-иях.
Для экспортируемых понятно, что нереально это делать. А библиотечные ф-ции OCaml написаны на С. Он их вызывает через обёртку.
V>Приемлимо работает только с небольшими ф-иями. И практически не оптимизирует "игры" с указателями, на что был сделан акцент, а ты не обратил внимания.
Да я скорее не обратил внимание, что игры с указателями не оптимизируются. Либо всё время вижу оптимизированный код, либо не понимаю о чём речь
V>OCalm еще явно сырой. Но представь хоть на минуту, если в него вложить столько же усилий, сколько в С++ от MS.
Вот в этом как раз и вопрос. Индустрия судя по всему не собирается вкладывать деньги в обозримом будующем.
V>Мне не нравится этот язык, просто я отдаю себе отчет в потенциале верифицируемого и заведомо оптимизируемого кода.
V>Это без оптимизатора, очевидно.
Оптимизатор не поможет. Любое число хранится в виде 2*n+1. Хотим мы или нет, но избежать дополнительных операций нельзя. Только для того, что бы вычесть 2 числа нужно делать 2 операции вместо одной
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, Глеб Алексеев, Вы писали:
ГА>Здравствуйте, vdimas, Вы писали:
V>>гораздо более слабые языки (с т.з. выразительности) ГА>Разрешите поинтересоваться, о какой выразительности идет речь? Я вот выбрал ОКамл именно из-за выразительности, верифицируемость пока на втором плане, может быть зря?
Под выразительностью С++ я подразумеваю возможность переопределения практически любых операторов (в т.ч. операторов приведения типов) и шаблонные возможности.
В итоге, на программе на С++ можно разработать такую систему прикладных типов и множество операций над этой системой в "привычном" виде (т.е "+" это "+", а не AddItem) в терминах которых данная прикладная задача описывается наиболее:
— эффективно
— читаемо/понятно
— надежно
— приближенно к прикладной области
GN>Оптимизатор не поможет. Любое число хранится в виде 2*n+1. Хотим мы или нет, но избежать дополнительных операций нельзя. Только для того, что бы вычесть 2 числа нужно делать 2 операции вместо одной
Стоп, именно про эти "битовые" моменты я и говорил. Представь, что у нас есть некая библиотечная (или в коде) небольшая ф-ия, которая принимает несколько целых чисел, что-то вычисляет из них и возвращает результат.
Затем мы начинаем эту ф-ю использовать. Грузим в пару локальных переменных числовые константы, вызываем эту маленькую ф-ию, а результат помещаем в следующую маленькую ф-ию.
Как я себе представляю whole program optimization в этом случае:
— если содержимое этих локальных переменных не уходит дальше контекста, то нет смысла их кодировать по схеме Calm, можно хранить в регистрах в native виде
— целевую "маленькую" ф-ию инлайним (как в С++, который это делает за нас даже без ключевого слова inline перед такой ф-ией), вызывем эту ф-ию, весь проинлайненный код так же работает с native представлением чисел
— если мы и дальше передаем получившееся значение в следующую аналогичную "маленькую" ф-ию, то нет смысла перекодировать и результат работы ф-ии
— тоже самое относится к случаям, когда мы возвращаем не просто единственное значение, а структуры или списки/массивы таковых
— даже если с т.з. оптимизатора не имеет смысла делать подобную ф-ию inline ввиду ее размеров, но удается локализовать и "обозрить" все места ее использования, то все равно можно обойтись native-представлением чисел с соответствующей корректировкой мест, использующих ее
— и т.д. рекурсивно (вверх/вниз/вбок), собственно, пока не натыкаемся на некие "границы" (библиотечные или экспортируемые ф-ии или вызов таковых)
Просмотренный мною пример трассирвки лучей как нельзя лучше подходил для подобных оптимизаций, т.е. для исключения из вычислений моментов преобразования числа к native и обратно.
Считаю, что подбная оптимизация — это вообще оптимизация 0-го уровня.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Глеб Алексеев, Вы писали:
ГА>>Здравствуйте, vdimas, Вы писали:
V>>>гораздо более слабые языки (с т.з. выразительности) ГА>>Разрешите поинтересоваться, о какой выразительности идет речь? Я вот выбрал ОКамл именно из-за выразительности, верифицируемость пока на втором плане, может быть зря?
V>Под выразительностью С++ я подразумеваю возможность переопределения практически любых операторов (в т.ч. операторов приведения типов) и шаблонные возможности.
V>В итоге, на программе на С++ можно разработать такую систему прикладных типов и множество операций над этой системой в "привычном" виде (т.е "+" это "+", а не AddItem) в терминах которых данная прикладная задача описывается наиболее: V>- эффективно V>- читаемо/понятно V>- надежно V>- приближенно к прикладной области
Здравствуйте, vdimas, Вы писали:
V>именно про эти "битовые" моменты я и говорил. Представь, что у нас есть некая библиотечная (или в коде) небольшая ф-ия, которая принимает несколько целых чисел, что-то вычисляет из них и возвращает результат.
В таких случаях даже немного проще — когда в вычислениях участвует много чисел, оверхед будет стремиться к нулю, поскольку конверсия в\из формата нужна не на всех этапах вычисления.
V>Затем мы начинаем эту ф-ю использовать. Грузим в пару локальных переменных числовые константы, вызываем эту маленькую ф-ию, а результат помещаем в следующую маленькую ф-ию.
V>Как я себе представляю whole program optimization в этом случае:
[теоретически всё хорошо]
V>Просмотренный мною пример трассирвки лучей как нельзя лучше подходил для подобных оптимизаций, т.е. для исключения из вычислений моментов преобразования числа к native и обратно.
Только одно но — там плавающая точка используется
V>Считаю, что подбная оптимизация — это вообще оптимизация 0-го уровня.
В общем-то, да. Мне, например, совершенно непонятно, почему sqrt(2) должен обязательно вычисляться в runtime
Но всё же — касательно интов, как бы там внутири не было всё хорошо, программа существует именно ради наблюдаемого (побочного) эффекта. Вот в этом месте WPO уже не смождет работать как следует — поскольку есть вызовы I/O функций. И оверхед никуда не денется, какой бы малый он не был.
and compile with ocamlopt -S int.ml -o int to generate assembly language in int.s. Recall from the discussion above that we are expecting OCaml to inline the print_int function as output_string (string_of_int 3), and examining the assembly language output we can see that this is exactly what OCaml does:
The important code is shown in red. It shows two things: Firstly the integer is unboxed (not allocated on the heap), but is instead passed directly to the function in the register %eax. This is fast. But secondly we see that the number being passed is 7, not 3.
This is a consequence of the representation of integers in OCaml. The bottom bit of the integer is used as a tag — we'll see what for next. The top 31 bits are the actual integer. The binary representation of 7 is 111, so the bottom tag bit is 1 and the top 31 bits form the number 11 in binary = 3. To get from the OCaml representation to the integer, divide by two and round down.
Why the tag bit at all? This bit is used to distinguish between integers and pointers to structures on the heap, and the distinction is only necessary if we are calling a polymorphic function. In the case above, where we are calling string_of_int, the argument can only ever be an int and so the tag bit would never be consulted. Nevertheless, to avoid having two internal representations for integers, all integers in OCaml carry around the tag bit.
Как-то это всё странно — ничего не мешало компилятору вызвать даже сразу Pervasives__output_string_212 со строкой, но тем не менее, вызывается ф-ция конверсии, причём в неё передаётся именно число во внутреннем представлении, хотя это и не нужно
ИМХО это связано с полиморфизмом (который, кстати, "на дне" реализуется вызовом С библиотеки). Pervasives__string_of_int_152 ожидает (?) на вход либо int, либо указатель на int. Хотя, никто же не мешает использовать 2 варианта для разных входных данных, когда компилятор может типы определить статически (и 3й — для полиморфизма в runtime).
Не знаю, насколько моё предположение верно, но вот что меня смущает — сложностей с WPO особых нет, теоретически OCaml можно оптимизировать проще, чем С++... но почему за 15 лет никто этого не сделал? Чувствую, где-то всё равно меня кидают
Хотя сама по себе идея с этим тегом довольно интересна — где-то можно и выиграть, вероятно. И ещё более вероятно, что можно эти тэги применить в каком-нибудь классе С++. А вот сделать обратное — увы
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, Mamut, Вы писали:
M>Хм. Я обратил внимание, что многие функциональные языки называют языками очень высокого уровня. Видимо, в противовес "просто" языкам высокого уровня, таким как С++ и прочие
Давно пора водить понятия: язык низчайшего уровня, никзого уровня, среднего уровня и высокого уровня. Тогда можно было бы точно сказать, что на две последних ступени плюсы явно не тянут.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, reductor, Вы писали:
R>И не только вызов функции. R>Что особо примечательно, компилятор у окамла почти не оптимизирует ничего, он простой как три рубля. R>Если бы еще и оптимизировал...
Офигительно простой. Видимо из-за простоты умудряется переписывать рекурсию в итерацию. И за одно размещать объекты в стеке, а не в ЖЦ. Ява и дотнет до такой простоты еще не доросли.
ЗЫ
Тебе не программированием, тебе пиаром нужно было заниматься.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, reductor, Вы писали:
R>Да даже gcc умеет разворачивать хвостовую рекурсию — это простейшая совершенно оптимизация. Дело не в этом. R>Просто откомпилируйте что-нибудь простое на окамле и си++ — увидите в чем разница
Такая оптимизация большая редкость в мире С++. Она просто на фиг не нужна, так как язык императивный. А вот в ФЯ она жизненно не обходима. Ну, а сравнивать по данному критерию скорости компиляторов просто мошейничество.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gear nuke, Вы писали:
GN>Измерения проводились при помощи отладчика (режима ядра, поэтому влияние на системную кучу отсутствует) Soft ICE. Каждая программа запускалась 3 раза так: GN>
GN>ray > out.txt
GN>
А зачем же так через задницу измерять то? Не проще было воспользоваться тем же перформанскаунтером? Ну, или тиками на худой конец...
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
И все же результаты сравнимые. Я бы сказал, что даже этот тест показал, что типобезопасные языки способны работать на равных с низкоуровневыми вроде С++.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, reductor, Вы писали:
R>Думаю, трех человек достаточно. R>Кто-нибудь может сказать как здесь удалить аккаунт вместе со всеми своими сообщениями?
Вообще-то слушать тебя интересно. Если бы ты вместо того чтобы обижаться просто снизил бы объем рекламщины и пиара в своих словах, то и те немногие трое тоже изменили бы свое мнение.
ЗЫ
Экаунты вечны и возврату не подлежат.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gear nuke, Вы писали:
GN>(Замечание про стек Вы уже никак обосновывать не хотите )
GN>И какие проблемы это даёт для компилятора?
Потенциально огромные. В курпе с тотальным ручным контролем ресуросов (главным образом памяти) — это снижает количество доступных оптимизаций и повышает возможность получения некорректного кода в результате оптимизаций.
У Окамла есть одно небольшое приемущество — он полностью типобезопасный и не содержит срудств ручного управления ресурсами. Это потенциально позволяет создать умный оптимизатор который порадит машинный код более быстрый нежели смогут написать большинство крутых С++-ников. Вот только у этого языка не те родители. И врдя ли в ближайшее время случится чудо.
Однако чисто теоритически reductor во многом прав.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Вы явно говорите о рзном. Ты о том что С++ позволяет вызать из компьютера умелыми руками, а reductor о том, что типобезопасный язык с тяготеющим к декларативности синтаксисом лучше поддается автоматической оптимизации.
Забавно, что вы оба правы. Да, на С++ намного проще оптимизировать программу в ручную, но черт побери, С++-над точно так же намного сложнее оптимизировать автоматически.
Что до предстакзаемости, то тут я скорее соглашусь с reductor. Надежда на свою непогрешимость и на то что в программе уже нет ошибок — это плохая надежда.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2,
GN>>Измерения проводились при помощи отладчика (режима ядра, поэтому влияние на системную кучу отсутствует) Soft ICE.
VD>А зачем же так через задницу измерять то? Не проще было воспользоваться тем же перформанскаунтером? Ну, или тиками на худой конец...
Ну это был наиболее простой способ — поставить точку останова, и отладчик сам напишет время потраченное до её достижения. Меряется там всё через timestamp counter, поэтому точность очень хорошая.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
VD>И все же результаты сравнимые. Я бы сказал, что даже этот тест показал, что типобезопасные языки способны работать на равных с низкоуровневыми вроде С++.
Я бы добавил ещё и скипнутое:
Вне конкурса проходит тот же MSVC с ключиком /clr
Время выполнения ~ 28-29 сек.
что бы было проще выбирать. Всё-таки JIT не очень просто использовать в С++, не знаю как там с этим в OCaml...
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth