Несколько лет программировал на С++. Устал от его корявости. Искал другой язык, более выразительный. Сначала наткнулся на D. Думал — все, нашел, что искал. Но мне не понравились 2 вещи: язык постоянно меняется, стабильности никакой. Ну и нету IDE нормального. Решил, что так дело не пойдет. Потом посмотрел на RSDN, тут расхваливают nemerle. Почитал, попытался вникнуть в примеры. Довольно приличный язык. И как раз узнаю, что разработчики отказались от языка. Никто теперь не продвигает его, он не достиг еще 1 версии, хоть как я понял, язык сформировался, а компилятор неоптимизированный. Плюс к тому интеграции с VS2008 не будет.
Пишу в принципе небольшие программки, в основном для себя, самое большое — несколько тысяч строк. Но это на С++, на тех же D или nemerle было бы явно меньше.
Вот хотел спросить совета, лучше пытаться переходить на какой-нибудь другой язык или оставаться программировать на с++?
Здравствуйте, Niovol, Вы писали:
N>Несколько лет программировал на С++. Устал от его корявости. Искал другой язык, более выразительный.
На Ruby смотрел? Язык очень красивый, выразительный. Активно развивается Rubinius — быстрая виртуальная машина для Ruby. Есть достаточно большое и, главное, очень внятное сообщество разработчиков. Язык достаточно зрелый, даже в России уже есть команды, которые занимаются коммерческой разработкой на Ruby.
Здря Nemerle хоронишь. Там уже есть группа энтузиастов, посему он будет жить независимо от двух авторов.
Что касается языков, то смотри для чего их. Для того чтобы просто зарабатывать, смотри mainstream (Java С# Python/Ruby). Если для того чтобы самому развиваться, то прежде всего смотри парадигмы. Функиональные (Lisp, Ocaml, Haskell). Логические — Prolog. Интересны старые языки — Refal, Forth. А после этого ты сможешь спокойно работать не только на любом языке, но и введешь в свой обиход новые приемы программирования.
Здравствуйте, Niovol, Вы писали:
N>Вот хотел спросить совета, лучше пытаться переходить на какой-нибудь другой язык или оставаться программировать на с++?
Можете взглянуть в сторону Scala (http://www.scala-lang.org/). В некотором смысле, это язык одного поколения с Nemerle и D, но ориентированный на JVM. Вот некоторые факты о нем, которые помогут сделать выбор:
Язык активно развивается, им занимается не пара энтузиастов, а институт EPFL. У него большое англоязычное community, почти каждый день в новостной группе по несколько сообщений. Русскоязычного community, по моим наблюдениям, почти нет.
Компилятор Scala self-hosting, имеет открытые исходники и покрыт тестами (это значит, что теоретически, компилятор всегда можно докрутить до своих нужд, если стандартных возможностей не хватает, а авторы не спешат из добавлять). Развитие языка ориентировано на добавление большого количества новых фич. Из-за этого страдает скорость компиляции, оптимизация (и скорость исполнения скомпилированного кода), простота и стабильность. Я обычно смотрю, что появилось в новом релизе, и за полчаса экспериментов мне удается в каждом релизе и подвесить компилятор, и найти креши. Бывают и дыры в типобезопасности.
У Scala есть формальная спецификация (в отличие от, например, Nemerle), описывающее большинство аспектов языка. Она уступает по полноте спецификации C# и чересчур переусложнена (возможно, это дань сложности самого языка).
У Scala очень сложная, гибкая (и красивая) система типов. Есть множественное наследование на основе trait'ов. Scala поощряет писать тела методов в функциональном стиле. Авторы принципиально не включают в язык операторы безусловного перехода (goto, break, continue). Есть вывод типов, хотя он заметно слабее, чем, например, в Nemerle. Он позволяет произвольную вложенность конструкций (например, типы могут определяться внутри методов), при этом вложенные конструкции образуют замыкания, захватывая переменные из внешней области. Scala (как Nemerle и D) имеет C-подобный синтаксис, и позволяет писать в очень лаконичном стиле.
К сожалению, пока нет возможностей метапрограммирования, но постоянно идет разговор о том, что их собираются добавить.
Почитал про парадокс Блаба. Интересно мнение обитателей форума на то, какие языки являются наиболее мощными. Прошу всех кому не лень написать в порядке убывания мощности несколько языков, и почему они занимают в вашем списке такое место.
Здравствуйте, Niovol, Вы писали:
N>Почитал про парадокс Блаба. Интересно мнение обитателей форума на то, какие языки являются наиболее мощными. Прошу всех кому не лень написать в порядке убывания мощности несколько языков, и почему они занимают в вашем списке такое место.
Здравствуйте, Niovol, Вы писали:
N>Почитал про парадокс Блаба. Интересно мнение обитателей форума на то, какие языки являются наиболее мощными. Прошу всех кому не лень написать в порядке убывания мощности несколько языков, и почему они занимают в вашем списке такое место.
ИМХО, языки некорректно сравнивать по одному параметру — некой абстрактной мощности. Я вот делал попытку
провести сравнение по нескольким параметрами, но и то такой подход вызвал у людей недовольство (в чем-то оправданное), потому что к одним языкам применимы одни параметры, а к другим — другие.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Niovol, Вы писали:
N>>Интересно мнение обитателей форума на то, какие языки являются наиболее мощными.
AVK>Для начала надо определиться с тем, что такое мощность языка.
Ну как же -- это размер такой волшебной красной кнопки, на которую нажимаешь и все работает. Чем больше кнопка, тем мощнее язык.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>Здравствуйте, FR, Вы писали:
FR>>Занял место поближе в ожидании большого флейма
ДГ>А что, разве тут народ ещё не охрип? Ну тогда подвинься.
На вашей рельсе место еще осталось? Тогда подвигайтесь — я тоже хочу послушать.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Niovol, Вы писали:
N>>Интересно мнение обитателей форума на то, какие языки являются наиболее мощными.
AVK>Для начала надо определиться с тем, что такое мощность языка.
Для этого можно, например, использовать следующий метод (кажется, этот метод был описан еще Холстедом
в его "Науке о программах"):
1. Написать на исследуемом языке программу.
2. Написать аналогичную программу на ассемблере.
2. Измерить длины обеих программ.
3. Можность языка — логарифм (десятичный) длины программы на ассмблере, деленной на длину
программы на исследуемом языке + 1(При этом можность ассемблера становится равной 1).
Например, если программа занимает 1000 строк на ассемблере, 100 строк на C и
10 строк на OCAML, то мощность C составит 2, а мощность OCAML — 3.
При этом возникает вопрос — как измерять длину программы. Строками,
наверное, не самый лучший способ. Наверное, точнее было бы по числу лексем
в исходном тексте.
Здравствуйте, Niovol, Вы писали:
N>Интересно мнение обитателей форума на то, какие языки являются наиболее мощными.
Вообще, "мощность языка" понятие довольно невнятное, для которого у каждого может быть свое интуитивное понимание. Лично я оцениваю мощность языка по сопротивлению, которое он оказывает при попытках думать и говорить на нем. Собственно, из самой статьи про парадокс Блаба следует, что мощность языка субъективна, ведь для того, кто думает на Блабе все языки не мощнее Блаба (в данном случае для Грэма все языки не мощнее LISPа). Статью я читал довольно давно, а перечитывать мне ее лень, но, если мне не изменяет память, ясного представления о том, что автор подразумевает под мощностью у меня не сложилось.
Эпиграф:
-- Да, я огнедышащий кратер. Из меня так и пышет пламя, а внутри
клокочут слова и комбинации слов, которые требуют выхода. Миллионы синонимов
и частей речи так и прут из меня на простор, и я не успокоюсь, пока не
произнесу какую-нибудь этакую речь.<...>
-- Нет ничего хуже
О.Генри
Можно ли выразить эту мощность в отрыве от мозговых тараканов? Попробовать можно, но, вернее всего, ничего не получится.
Если же все-таки попробовать, то я бы разделил одно большое зло на три малых — это уже прогресс.
То, что я понимаю под мощностью состоит из трех компанентов: выразительность, декларативность и легковесность.
1) Выразительность (по моему, наиболее туманное понятие из всех трех) дается большим количеством сущностей.
Предположим, у нас есть уравнения Максвелла записанные покомпонентно — т.е. неохватное нагромождение элементарных вещей.
Зная что такое трехмерные векторы и дифференциальные операторы можно записать более компактно и красиво, а использовав четырехвекторы и оператор Даламбера — еще компактнее и красивее. Цена успеха — необходимость знать все эти сущности. Про такое обычно говорят "более высокий уровень". Реакция человека от сохи: "посмотрел я ваше Тряляля — ничего не понял".
Считается, что безусловный переход проще, чем лексическое замыкание — первое я изучал в школе, а второе — нет.
2) Декларативность, по счастью, тривиальна. Есть мнение, что формулировка задачи
def ngt5 = numbers.Filter(_ > 5)
предпочтительнее описания пошагового решения
list<int> ngt5 = new list<int>();
for(int i = 0; i < numbers.Count; i++)
if(numbers[i] > 5) ngt5.Add(numbers[i]);
3) Легковесный синтаксис это то, что позволяет пользоваться возможностями языка.
Если синтаксис монструозен, (классический пример:
delegate(int a, int b){ return a + b; }
) то полезное средство легко может оказаться непригодным для использования.
Некоторое облегчение вроде
(a, b) => a + b
уже позволяет дышать, но хочется чего-то вроде (+) или _ + _
Упрощенно: громоздкий синтаксис тяготеет к литературному языку и доступен после окончания первого класса; легковесный — тяготеет к математической нотации, с понятными проблемами — первого класса уже недостаточно!
"Вчера посмотрел Траляля — одни закорючки" — примерно так я реагирую, например, на язык k.
N>Прошу всех кому не лень написать в порядке убывания мощности несколько языков, и почему они занимают в вашем списке такое место.
Надеюсь, что лень спасет форум.
... << RSDN@Home 1.2.0 alpha rev. 726>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Flying Dutchman, Вы писали:
FD>1. Написать на исследуемом языке программу.
Какую?
FD>2. Написать аналогичную программу на ассемблере. FD>2. Измерить длины обеих программ.
В чем мерять будем? В символах? Тогда брейнфак рулит . И как со стандартными библиотеками. Использовать? API ОС?
FD>Например, если программа занимает 1000 строк на ассемблере, 100 строк на C и FD>10 строк на OCAML, то мощность C составит 2, а мощность OCAML — 3.
Ах в строках. А если программу на С написать в одну строку? С будем мощнее OCAML в 10 раз?
FD>наверное, не самый лучший способ. Наверное, точнее было бы по числу лексем FD>в исходном тексте.
Т.е., скажем, при прочих равных, ООП язык менее мощен, нежели структурный, поскольку на объявление контракта объекта явно уйдет больше лексем, чем если бы это была одна длинная поцедура?
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
assert youKnowWhatYouReallyWant == true;
if (iAmWritingForPersonalUseOnly()) {
if (iWantAReallyNewParadigm()) { // actually you'll get some irreversible brain damage.
return "Huskell"; // dude, I really mean the DAMAGE!
return "F#"; I knew you'd skip the line above.
}
else {
if (isDynamicTypingOk()) { // hey, everyone wanna be a cool geek today.
if (cannotLiveWithoutCurlyBraces()) { // well, who can ?!
return "Ruby"; // it's Python done better.
}
else {
return "Python"; // it's Ruby done right.
}
}
else { // static typing obviously
if (isManagedOk()) { // let PC do some job for me, they are so smart nowdays. Sick of doing everything myself.
if (preferJavaWorld()) { // die, MS, die!!!
return "Scala"; // huge, really huge. Must be inspired by Noah Arc.
}
else if (preferDotNetWorld()) { // stuck on Windows, ha?
return "Nemerle"; // kazalos' by... oh, not again...
}
else {
throw new IsThereReallyAnythingElseException();
}
}
else if (unmanagedOnly()) { // computers will eliminate the humankind if they get enough control.
return "D"; // get a whole new language with every new release. Great fun.
}
else {
throw new YouWantSomethingStrangeHereException()
}
}
}
}
else {
return "Do Whatever Your Boss Says To And Keep Your Mouth Shut Programming Language";
}
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, c-smile, Вы писали:
CS>>На вашей рельсе место еще осталось? Тогда подвигайтесь — я тоже хочу послушать.
FR>Тихо, тихо не шуми FR>Хотя можно кое-что громко кричать: "Влад Немерли, Немерли" + добавить ругательств по вкусу
Сам, не шуми. Вишь горе у людей — Немерля нонче ушицы запросила.
assert youKnowWhatYouReallyWant == true;
if (forMyselfOnly()) {
if (wantReallyNewParadigm()) { // actually you'll bet some long lasting irreversible brain damage
return "Huskell"; // dude, I really mean the DAMAGE!
return "F#"; I knew you'd skip the line above. ;)
}
else {
if (dynamicTypingIsOk()) { // hey, everyone wanna be a cool geek today
if (cannotLiveWithoutCurlyBraces()) { // well, who can ?!
return "Ruby"; // it's Python done better
}
else {
return "Python"; // it's Ruby done right
}
}
else {
if (isManagedOk()) { // let PC do something for me, they are so smart nowdays.
if (preferJavaWorld()) { // die, MS, die!!!
return "Scala"; // huge, really huge. Must be inspired by Noah Arc.
}
else if (preferDotNetWorld()) { // stuck on Windows, ha?
return "Nemerle"; // kazalos' by... oh, not again... :)
}
else {
throw new IsThereReallyAnythingElseException();
}
}
else if (unmanagedOnly()) { // computers will eliminate the humankind if they get enough control.
return "D"; // get a whole new language with every new release
}
else {
throw new YouWantSomethingStrangeHereException()
}
}
}
}
else {
throw new DoWhateverBossSaysToAndKeepYourMouthShutException();
}
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, c-smile, Вы писали:
CS>>Вишь горе у людей — Немерля нонче ушицы запросила.
E>Ой, я, кажется, что-то пропустил E>Можно раскрыть тему подробнее?
сходи в ветку nemerle и прочитай новость про то, как оба создателя потеряли мотивацию
Здравствуйте, Константин Л., Вы писали:
КЛ>сходи в ветку nemerle и прочитай новость про то, как оба создателя потеряли мотивацию
Дайте, пожалуйста, ссылку.
Здравствуйте, Константин Л., Вы писали:
CS>>>Вишь горе у людей — Немерля нонче ушицы запросила.
E>>Ой, я, кажется, что-то пропустил E>>Можно раскрыть тему подробнее?
КЛ>сходи в ветку nemerle и прочитай новость про то, как оба создателя потеряли мотивацию
Сходил. Почитал. Грусно, однако.
Момент истины для Nemerle наступил, сейчас и выяснится, достаточно ли будет запала у Nemerle-евангелистов заниматься проектом дальше.
Поскольку я сам несколько раз оказывался в подобной ситуации, то от все души жалаю успеха всем, кто продолжит развитие Nemerle!
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Осмелюсь предложить еще один способ выбора языка — по характеристикам его реализаций на практике.
Есть такой интересный ресурс — http://shootout.alioth.debian.org , там можно сравнить кучу языков и реализаций на примере кучи задач по скорости, памяти и лаконичности решения. В частности, по лаконичности (выразительности?) Ruby и Python впереди планеты всей.
Если сортировать одновременно по скорости и выразительности, на горизонте появляется OCaml, который я последнее время весьма полюбил.
Язык, компилируемый в нативный код (но можно и в байткод при желании), по скорости близок к С/С++ (точно быстрее языков на jvm и .net), есть автоматическая сборка мусора; типизация строгая, но объявлять типы переменных и функций не нужно (вывод типов); есть паттерн матчинг; есть куча интересных вещей из функционального программирования (хотите монад? их есть у меня ), при этом вычисления не ленивые (отсюда предсказуемая скорость и скромное потребление памяти); есть ООП; есть макросы... Из минусов — нельзя в пределах одного процесса эксплуатировать несколько ядер/процессоров. Т.е. потоки есть, но параллельные вычисления приходится делать через межпроцессное общение, т.к. сборщик мусора однопоточный (это намеренно и не изменится), и все потоки в пределах процесса делят один мьютекс.
Здравствуйте, D. Mon, Вы писали:
DM>Осмелюсь предложить еще один способ выбора языка — по характеристикам его реализаций на практике. DM>Есть такой интересный ресурс — http://shootout.alioth.debian.org
В топку этот сайт, если человек неуверенно знающий Ocaml правит одну строчку в их примере и получает 15% ускорение, и видит как легко сделать еще намного быстрее, ни говоря уже об их старых косяках (как ни могли psyco запустить для питона).
Здравствуйте, eao197, Вы писали:
E>Сходил. Почитал. Грусно, однако. E>Момент истины для Nemerle наступил, сейчас и выяснится, достаточно ли будет запала у Nemerle-евангелистов заниматься проектом дальше.
E>Поскольку я сам несколько раз оказывался в подобной ситуации, то от все души жалаю успеха всем, кто продолжит развитие Nemerle!
По правде сказать, Камила уже давно не было видно в логах репозитория. А Михала и того дольше. И ничего, баги чинятся, на новую студию переходим. Правда, насколько заметил, народ какой-то неактивный в последнее время. Тоже мотивация понизилась? (да-да, и у меня тоже).
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Delight, Вы писали:
D>>Спасибо, сам уже прочитал. Вот только не было пояснения почему потеряли мотивацию.
E>Пришел в Microsoft работать. Там ему её и отбили.
знаешь, а с большой вероятностью так и есть. может им предложили кучу бабла, чтобы они бросили проект.
Здравствуйте, Константин Л., Вы писали:
КЛ>Здравствуйте, eao197, Вы писали:
E>>Здравствуйте, Delight, Вы писали:
D>>>Спасибо, сам уже прочитал. Вот только не было пояснения почему потеряли мотивацию.
E>>Пришел в Microsoft работать. Там ему её и отбили.
КЛ>знаешь, а с большой вероятностью так и есть. может им предложили кучу бабла, чтобы они бросили проект.
Не думаю, что им нужно было предлагать кучу бабла. Для вчерашних польских аспирантов достаточно было предложить нормальную зарплату в MS.
Да и предлагать бросить проект не обязательно было. Они могли увлечься перспективой реализовать свои идеи, скажем, в следующей версии C#. Или их могли включить в какой-нибудь другой, еще более амбициозный проект внутри MS. Думаю, что там найдется не мало чего грандиозного, ради чего можно было бы оставить свои студенческие увлечения.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Да и предлагать бросить проект не обязательно было. Они могли увлечься перспективой реализовать свои идеи, скажем, в следующей версии C#. Или их могли включить в какой-нибудь другой, еще более амбициозный проект внутри MS. Думаю, что там найдется не мало чего грандиозного, ради чего можно было бы оставить свои студенческие увлечения.
В майкрософте только Михал. А Камил — в Google . Но, в общем-то, не суть важно. Действительно, и там и сям есть много замечательных перспектив.
Здравствуйте, Константин Л., Вы писали:
E>>Пришел в Microsoft работать. Там ему её и отбили.
КЛ>знаешь, а с большой вероятностью так и есть. может им предложили кучу бабла, чтобы они бросили проект.
Странно было бы с их стороны сначала давать денег на развитие (грант по программе Ротор), а потом денег за закрытие, не правда ли?
Здравствуйте, Сергей Туленцев, Вы писали:
СТ>Здравствуйте, Niovol, Вы писали:
N>> Плюс к тому интеграции с VS2008 не будет.
СТ>Как это не будет? Уже есть и работает Вот только инсталлятора нет. Ну да это дело небольшого количества времени.
Здравствуйте, Niovol, Вы писали:
N>Здравствуйте, Сергей Туленцев, Вы писали:
СТ>>Здравствуйте, Niovol, Вы писали:
N>>> Плюс к тому интеграции с VS2008 не будет.
СТ>>Как это не будет? Уже есть и работает Вот только инсталлятора нет. Ну да это дело небольшого количества времени.
N>Можно ссылку в студию?
Здравствуйте, Константин Л., Вы писали:
CS>>>Вишь горе у людей — Немерля нонче ушицы запросила.
E>>Ой, я, кажется, что-то пропустил E>>Можно раскрыть тему подробнее?
КЛ>сходи в ветку nemerle и прочитай новость про то, как оба создателя потеряли мотивацию
Уписаться. Думал, не доживу . Годик-другой назад многие с удивлением спрашивали, почему тут кое-кто (в числе которых был и я) отказывается стартовать промышленные проекты на Немерле. Я говорил, что ни за что не стартую такой проект, что вызывало возмущение прогрессивной общественности.
Вот, господа, смотрите внимательно. Мы сейчас наблюдаем практическое, и самое существенное отличие наколенной поделки энтузиастов — пусть даже и удачной технически, от зрелой промышленной платформы.
Здравствуйте, lxa, Вы писали:
AVK>>Для начала надо определиться с тем, что такое мощность языка.
lxa>мощность языка = сила языка * скорость языка
Черт, не успел . Ты первый .
Сила Немерле, как известно, — в Макросах. Ну, а скоростью мы тут давно меряемся, Немерле быстр. Следовательно, Немерле очень Мощный язык, его Скорость умножается на Мощность. Да.
Здравствуйте, Сергей Туленцев, Вы писали:
СТ>Здравствуйте, Константин Л., Вы писали:
E>>>Пришел в Microsoft работать. Там ему её и отбили.
КЛ>>знаешь, а с большой вероятностью так и есть. может им предложили кучу бабла, чтобы они бросили проект.
СТ>Странно было бы с их стороны сначала давать денег на развитие (грант по программе Ротор), а потом денег за закрытие, не правда ли?
ну всякое бывает. стратегия, тактика . Про грант не в курсе
[]
G>Уписаться. Думал, не доживу . Годик-другой назад многие с удивлением спрашивали, почему тут кое-кто (в числе которых был и я) отказывается стартовать промышленные проекты на Немерле. Я говорил, что ни за что не стартую такой проект, что вызывало возмущение прогрессивной общественности.
G>Вот, господа, смотрите внимательно. Мы сейчас наблюдаем практическое, и самое существенное отличие наколенной поделки энтузиастов — пусть даже и удачной технически, от зрелой промышленной платформы.
К сожалению, первое от второго отличает все-лишь наличие бабла. Выпусти ща мс компайлер немерле в составе студии и начни маркетинг моушн — и начнешь, и про коленки забудешь
Здравствуйте, Константин Л., Вы писали:
КЛ>К сожалению, первое от второго отличает все-лишь наличие бабла. Выпусти ща мс компайлер немерле в составе студии и начни маркетинг моушн — и начнешь, и про коленки забудешь
Бабло тоже может не помощь, например Ада и Смаллталк.
И наоборот без гигантского бабла те же питон и руби неплохо живут.
Здравствуйте, Niovol, Вы писали:
N>Потом посмотрел на RSDN, тут расхваливают nemerle. Почитал, попытался вникнуть в примеры. Довольно приличный язык. И как раз узнаю, что разработчики отказались от языка.
Здравствуйте, Gaperton, Вы писали:
G>Уписаться. Думал, не доживу . Годик-другой назад многие с удивлением спрашивали, почему тут кое-кто (в числе которых был и я) отказывается стартовать промышленные проекты на Немерле. Я говорил, что ни за что не стартую такой проект, что вызывало возмущение прогрессивной общественности.
Только там есть еще кусок письма который на RSDN не процитировали...
On Jan 12, 2008 9:30 PM, Igor Tkachev <i...@rsdn.ru> wrote:
> Michal, congratulations on your new position at Microsoft.
> BTW, will it affect the Nemerle project somehow?
We have the insider in MS now! I remember Michal was mentioning to me
that some guys from CLR team asked him about our bug reports.
I don't think there will be any other changes, since you guys are
doing most of the work on Nemerle now...
Sadly I and Michal rather lost the motivation and time to work on the
compiler, but I really hope the language will be useful to people
world-wide. I still use it in one of my commercial projects, though it
is in rather stable phase now.
The way to go now is probably to encourage you to draw the future and
make more authoritative decisions about the language and compiler if
you want.
По факту сейчас немерле в основном пилят Иванков ДмитрийБлудов ПавелITVladD2
Возможно скоро еще я подтянусь... что-то вывод типов слабоват... иногда не то выводит .
Так что выбывание Камила и Михаля ничего сильно не меняет.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Gaperton, Вы писали:
G>Уписаться. Думал, не доживу . Годик-другой назад многие с удивлением спрашивали, почему тут кое-кто (в числе которых был и я) отказывается стартовать промышленные проекты на Немерле. Я говорил, что ни за что не стартую такой проект, что вызывало возмущение прогрессивной общественности.
G>Вот, господа, смотрите внимательно. Мы сейчас наблюдаем практическое, и самое существенное отличие наколенной поделки энтузиастов — пусть даже и удачной технически, от зрелой промышленной платформы.
Здравствуйте, FR, Вы писали:
FR>И наоборот без гигантского бабла те же питон и руби неплохо живут.
Ага. Только Ruby был сделан — 1995 год. Python — еще раньше. Nemerle — ?
Здравствуйте, Gaperton, Вы писали:
G>Вот, господа, смотрите внимательно. Мы сейчас наблюдаем практическое, и самое существенное отличие наколенной поделки энтузиастов — пусть даже и удачной технически, от зрелой промышленной платформы.
Язык еще не то чтобы не умер, но даже и не собирается пока (достаточно хотя бы в свн заглянуть), а тут я смотрю его уже и похоронили и цветов на могилку принесли
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, FR, Вы писали:
FR>>И наоборот без гигантского бабла те же питон и руби неплохо живут. GZ>Ага. Только Ruby был сделан — 1995 год. Python — еще раньше. Nemerle — ?
Питон вроде 91, TCL чуть раньше.
Так нормально, они все (еще перл и PHP и наверно еще что-то упустил) живы-здоровы, успешно развиваются. Кстати если Немерли повторит их судьбу это уже вполне успех, и не нужно никакого мирового господства
Здравствуйте, WolfHound, Вы писали:
WH>По факту сейчас немерле в основном пилят Иванков ДмитрийБлудов ПавелITVladD2 WH>Возможно скоро еще я подтянусь... что-то вывод типов слабоват... иногда не то выводит . WH>Так что выбывание Камила и Михаля ничего сильно не меняет.
Это действительно ничего не меняет. Я к вам парни нормально отношусь — но сами понимаете, теперь проект держится на такой шаткой материи, как ваша мотивация — и я не скажу, что это меня сильно успокаивает.
Здравствуйте, Klapaucius, Вы писали:
K>Упрощенно: громоздкий синтаксис тяготеет к литературному языку и доступен после окончания первого класса; легковесный — тяготеет к математической нотации, с понятными проблемами — первого класса уже недостаточно! K>"Вчера посмотрел Траляля — одни закорючки" — примерно так я реагирую, например, на язык k.
И какой подход предпочтителен, закорючки, которые мешают освоить язык, или громоздкость, которая мешает работать освоившему?
Здравствуйте, mkizub, Вы писали:
M>И какой подход предпочтителен, закорючки, которые мешают освоить язык, или громоздкость, которая мешает работать освоившему?
Nemerle. Ни закорючек. Ни громоздкости.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Константин Л., Вы писали:
G>>Уписаться. Думал, не доживу . Годик-другой назад многие с удивлением спрашивали, почему тут кое-кто (в числе которых был и я) отказывается стартовать промышленные проекты на Немерле. Я говорил, что ни за что не стартую такой проект, что вызывало возмущение прогрессивной общественности.
G>>Вот, господа, смотрите внимательно. Мы сейчас наблюдаем практическое, и самое существенное отличие наколенной поделки энтузиастов — пусть даже и удачной технически, от зрелой промышленной платформы.
КЛ>К сожалению, первое от второго отличает все-лишь наличие бабла. Выпусти ща мс компайлер немерле в составе студии и начни маркетинг моушн — и начнешь, и про коленки забудешь
Неправда ваша. Есть достаточно много open source проектов, которые поддерживает community, и которые не страшно применять в продакшн. Нет у вашего Немерле сильного коммьюнити. Есть точечный пеар на РСДН. Вот и все.
Здравствуйте, Gaperton, Вы писали:
G>Сила Немерле, как известно, — в Макросах. Ну, а скоростью мы тут давно меряемся, Немерле быстр. Следовательно, Немерле очень Мощный язык, его Скорость умножается на Мощность. Да.
Скорость на силу, конечно. Сам запутался — вот какой Немерле Мощный язык
Здравствуйте, rameel, Вы писали:
R>Язык еще не то чтобы не умер, но даже и не собирается пока (достаточно хотя бы в свн заглянуть), а тут я смотрю его уже и похоронили и цветов на могилку принесли
Еще не похоронили. Пока некоторые стучат по крышке гроба и спрашивают: "Есть кто живой?". А оттуда: "Есть, мы живые. Это не гроб. Видите ручки чтобы двери открывать. Это шкаф." А они туда: "Нет, ребята, вы дохлые. Пока количество индивидумов измеряется штуками они считаются усопшими и объявляю ваш шкаф — гробом. Двери крышкой, а ручки от двери — красивой ошибкой природы".
Здравствуйте, mkizub, Вы писали:
K>>Упрощенно: громоздкий синтаксис тяготеет к литературному языку и доступен после окончания первого класса; легковесный — тяготеет к математической нотации, с понятными проблемами — первого класса уже недостаточно! K>>"Вчера посмотрел Траляля — одни закорючки" — примерно так я реагирую, например, на язык k. M>И какой подход предпочтителен, закорючки, которые мешают освоить язык, или громоздкость, которая мешает работать освоившему?
Мне внутренний голос подсказывает, что за этим майевтическим вопросом последует целый квазиплатоновский диалог, в ходе которого сначала мы придем к выводу о том, что лучше было бы представлять AST в синтаксисах разной степени легковесности, а потом перейдем к обсуждению SymADE. Я правильно догадался?
... << RSDN@Home 1.2.0 alpha rev. 774>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Delight, Вы писали:
D>Надо делать из этой идеи полноценный проект, регистрировать в sf.net и обнародовать. Вот только осталось решить на каком языке его писать.
D>P.S. Рефакторинг творит чудеса. Приложение теперь просто не узнать...
Я думаю, нам придется разработать специальный язык с мощной макросистемой для этого проекта. Главное — мотивацию не потерять .
Здравствуйте, WolfHound, Вы писали:
M>>И какой подход предпочтителен, закорючки, которые мешают освоить язык, или громоздкость, которая мешает работать освоившему? WH>Nemerle. Ни закорючек. Ни громоздкости.
Ответ пристрастный, и следовательно неверный.
Я неоднократно видел, что даже С с его {} вместо begin/end, вызывает у людей ощущение закорючести.
Противоречие между понятным и удобным синтаксисом — диалектическое. Ты его своими лозунгами не отменишь. Оно решается только на следующем уровне развития ситуации.
Здравствуйте, Klapaucius, Вы писали:
K>Мне внутренний голос подсказывает, что за этим майевтическим вопросом последует целый квазиплатоновский диалог, в ходе которого сначала мы придем к выводу о том, что лучше было бы представлять AST в синтаксисах разной степени легковесности, а потом перейдем к обсуждению SymADE. Я правильно догадался?
Что прийдём к SymADE — правильно, а вот про сложный диалог — не угадал.
Эта проблема решается в SymADE изначально — программу можно представлять (отображать) как угодно, с разной степенью детальности.
Например то, чем так гордятся в FP — вывод типов — в SymADE просто нафиг не нужен, поскольку эти типы в декларации меторов/переменных можно отображать, а можно и не отображать.
Вы противопоставляете вызов функции описанию пошагового решения.
Понятно, что вызывать функцию предпочтительнее, чем выписывать её тело, но имеет ли это отношение к декларативности?
Что касается этих примеров
Здравствуйте, Klapaucius, Вы писали:
K>Вообще, "мощность языка" понятие довольно невнятное, для которого у каждого может быть свое интуитивное понимание. Лично я оцениваю мощность языка по сопротивлению, которое он оказывает при попытках думать и говорить на нем.
Ну, про мощность уже выяснили. А по сопротивлению надо оценивать упругость языка.
[]
G>Неправда ваша. Есть достаточно много open source проектов, которые поддерживает community, и которые не страшно применять в продакшн. Нет у вашего Немерле сильного коммьюнити. Есть точечный пеар на РСДН. Вот и все.
В чем неправда я так и не понял. Я не про популярность из-за коммъюнити, а про то, что она вполне может прийти если вложить бабло
Здравствуйте, Константин Л., Вы писали:
КЛ>Здравствуйте, Gaperton, Вы писали:
КЛ>[]
G>>Неправда ваша. Есть достаточно много open source проектов, которые поддерживает community, и которые не страшно применять в продакшн. Нет у вашего Немерле сильного коммьюнити. Есть точечный пеар на РСДН. Вот и все.
КЛ>В чем неправда я так и не понял.
В этом.
К сожалению, первое от второго отличает все-лишь наличие бабла.
КЛ>Я не про популярность из-за коммъюнити, а про то, что она вполне может прийти если вложить бабло.
Если вложить бабло, то ты его либо отобьешь, либо нет. Если второе — то тогда говорят, что бабло не вкладывают, а проси... тратят.
Затруднюсь предположить, кому было бы выгодно вложить в немерле бабло — и главное — не понимаю, каким именно образом это бабло предполагается инвестору отбивать. Уж больно по дурацки платформа выбрана — будь он реально кроссплатформенный и native, у него были бы какие-то шансы, возможно даже неплохие. Выбор .NET с точки зрения облегчения интеропа — балшыт. Сильно благодаря CLR облегчается интероп с Java да? А с C/C++? А это те языки, интероп с которыми реально требуется.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Константин Л., Вы писали:
КЛ>>Здравствуйте, Gaperton, Вы писали:
КЛ>>[]
G>>>Неправда ваша. Есть достаточно много open source проектов, которые поддерживает community, и которые не страшно применять в продакшн. Нет у вашего Немерле сильного коммьюнити. Есть точечный пеар на РСДН. Вот и все.
КЛ>>В чем неправда я так и не понял. G>В этом. G>
G>К сожалению, первое от второго отличает все-лишь наличие бабла.
согласен
КЛ>>Я не про популярность из-за коммъюнити, а про то, что она вполне может прийти если вложить бабло.
G>Если вложить бабло, то ты его либо отобьешь, либо нет. Если второе — то тогда говорят, что бабло не вкладывают, а проси... тратят.
G>Затруднюсь предположить, кому было бы выгодно вложить в немерле бабло — и главное — не понимаю, каким именно образом это бабло предполагается инвестору отбивать.
Ну, как обычно отбивается бабло от создания языков Всякой какой-нить приблудой вокруг него
G>Уж больно по дурацки платформа выбрана — будь он реально кроссплатформенный и native, у него были бы какие-то шансы, возможно даже неплохие. Выбор .NET с точки зрения облегчения интеропа — балшыт. Сильно благодаря CLR облегчается интероп с Java да? А с C/C++? А это те языки, интероп с которыми реально требуется.
его кроссплатформенность напрямую зависит от таковой у .net. Станет .net — станет и немерле.
Кстати, по поводу интеропа .net с с++ — есть очень удобный (по сравнению с предыдущими) в виде c++/cli
Здравствуйте, Gaperton, Вы писали:
G>Если вложить бабло, то ты его либо отобьешь, либо нет. Если второе — то тогда говорят, что бабло не вкладывают, а проси... тратят.
Ты бы пояснил, что назывешь "наколенной поделкой". А то ведь если в продукт бабло вложить, то он автоматом станет тем самым продакшн. А то ты уже попер платформы обсуждать и еще что-то. Почему Шарпу платформа не мешает? А?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Gaperton, Вы писали:
G>Затруднюсь предположить, кому было бы выгодно вложить в немерле бабло — и главное — не понимаю, каким именно образом это бабло предполагается инвестору отбивать. Уж больно по дурацки платформа выбрана — будь он реально кроссплатформенный и native, у него были бы какие-то шансы, возможно даже неплохие. Выбор .NET с точки зрения облегчения интеропа — балшыт. Сильно благодаря CLR облегчается интероп с Java да? А с C/C++? А это те языки, интероп с которыми реально требуется.
Ява и С++ реализованы на дотете и интероп с ними прекраснейший. Ты бы разорался сначала, а то других в подобных ситуациях ты с дерьмом мешаешь, а сам так подставляешся. Не порядок, однако.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Gaperton, Вы писали:
G>Это действительно ничего не меняет. Я к вам парни нормально отношусь — но сами понимаете, теперь проект держится на такой шаткой материи, как ваша мотивация — и я не скажу, что это меня сильно успокаивает.
Откровенно говоря меня самого это не радует. Вот только неужели это является причиной для некоторых сразу заупокойную заказывать? У нас вон мотивации развивать сай уже года 3 нет, но сайт живет и развивается.
Конечно бабло бы создала еще ту мативацию, но пока его нет. Но есть явная необходимость если не в самом языке, то хотя бы в его концепциях. Тот же Шарп уже получил не мало из-за того, что его разрабочики заметили, что в мире есть ФП. Если они заметят и МП, то вообще будет супер. Ну, а не заметят, мы догрызем Немерле или еще что-нить появится. Главное не плакать.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ява и С++ реализованы на дотете и интероп с ними прекраснейший. Ты бы разорался сначала, а то других в подобных ситуациях ты с дерьмом мешаешь, а сам так подставляешся. Не порядок, однако.
Здравствуйте, EvilChild, Вы писали:
EC>Здравствуйте, VladD2, Вы писали:
VD>>Ява и С++ реализованы на дотете и интероп с ними прекраснейший. Ты бы разорался сначала, а то других в подобных ситуациях ты с дерьмом мешаешь, а сам так подставляешся. Не порядок, однако.
EC>Покажешь как плюсовый шаблон из шарпа поюзать?
не получится
typedef std::vector<gcroot<System::String^>> container_type;
public ref class Test
{
container_type* Raw_;
public:
explicit Test( container_type* list )
: Raw_(new container_type(*list))
{}
property System::String^ default[int]
{
System::String^ get(int index)
{
return (*Raw_)[index];
}
}
};
Здравствуйте, Gaperton, Вы писали:
G>Я думаю, нам придется разработать специальный язык с мощной макросистемой для этого проекта. Главное — мотивацию не потерять .
Здравствуйте, VladD2, Вы писали:
VD>Откровенно говоря меня самого это не радует. Вот только неужели это является причиной для некоторых сразу заупокойную заказывать?
Если серъезно, то чтобы язык жил необходимо чтобы его развитие и само существование не зависело от настроения авторов. И к этому делу надо подходить примерно так, как например, сделало сообщество питона задавшись вопросом "что будет если Гвидо попадет под автобус" — http://www.python.org/psf/
Здравствуйте, FR, Вы писали:
FR>Если серъезно, то чтобы язык жил необходимо чтобы его развитие и само существование не зависело от настроения авторов. И к этому делу надо подходить примерно так, как например, сделало сообщество питона задавшись вопросом "что будет если Гвидо попадет под автобус" — http://www.python.org/psf/
FR>В случае Немерли (и D) к сожалению такого нет.
Список доноров и спонсоров впечатляет. А на что деньги идут?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Gaperton, Вы писали:
G>>Это действительно ничего не меняет. Я к вам парни нормально отношусь — но сами понимаете, теперь проект держится на такой шаткой материи, как ваша мотивация — и я не скажу, что это меня сильно успокаивает.
VD>Откровенно говоря меня самого это не радует. Вот только неужели это является причиной для некоторых сразу заупокойную заказывать?
Заупокойную — это к священникам надо, (в священные войны, сталбыть ), а пока я как врач оцениваю состояние пациента как критическое. А выживет или нет — на все воля господа, тут уж не у врача надо спрашивать, а к гадалке обращаться . Но в принципе — неплохой момент отпустить пациенту грехи — на всякий случай .
VD>У нас вон мотивации развивать сай уже года 3 нет, но сайт живет и развивается.
Истинно говорю, на все воля господа.
VD>Конечно бабло бы создала еще ту мативацию, но пока его нет.
Не знаю, не знаю. Нивабиду, но люди говорят, что бабло плохо вас мотивирует в случае сайта. Жалуются, что у вас даже за деньги рекламу разместить проблема. Жалуются, что баннер ваш меняется слишком редко — доходит до идиотизма, скажем, неделями висит баннер с рекламой уже прошедшего семинара, и снять его нельзя.
VD>Но есть явная необходимость если не в самом языке, то хотя бы в его концепциях. Тот же Шарп уже получил не мало из-за того, что его разрабочики заметили, что в мире есть ФП. Если они заметят и МП, то вообще будет супер. Ну, а не заметят, мы догрызем Немерле или еще что-нить появится. Главное не плакать.
С этим я безусловно согласен. Немерле — это отличный опыт, практически доказывающий, что возможно мягкое введение концепций ФП в мэйнстримовые языки. Примерно, как это было сделано с С, С++, и ООП. Важность Немерле с этой точки зрения сложно переоценить.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, goorov, Вы писали:
G>>это какая такая ява реализована на дотнете? j# что-ль? или я что-то пропустил?
AVK>Может имелась ввиду http://www.mono-project.com/Java . Там правда речь о рантайме.
JIT-компилятор Java на моно, транслирующий java байт-код в CLR? Интересный подход.
1) А как у нас, интересно, будет выглядеть интероп с каким-нибудь Java Application Server, где своя VM? Подмена VM не всегда канает.
2) Крайне любопытно, правда — неужели там сборщик мусора научился подбирать неиспользуемые Java классы, и у нас будет реально работать свой classloader (гранулярность загрузки/выгрузки — класс)? Что-то сомневаюсь — не умел такого делать CLR by design. А без этой штуки application-сервера и Java приложения с активным скриптингом в продакшне лучше не пускать. А это весьма приятное свойство Java, одно из его основных отличий от .NET.
Здравствуйте, AndrewVK, Вы писали:
G>>Уж больно по дурацки платформа выбрана — будь он реально кроссплатформенный
Вероятно, но не все хотят таскать за своей аппликухой mono.
AVK>Nemerle под Моно работает, Моно реально кроссплатформенный.
G>> и native
AVK>А native совершенно не обязателен, как показывает практика. Впрочем, mono --aot и флаг вам в руки
native обязателен, если хочется быстро работать и не таскать за собой mono .
Здравствуйте, Трурль, Вы писали:
K>>Да, и что из этого следует? Т>Что декларативность не столь уж тривиальна.
А. Вы хотите сказать, что код в декларативном стиле не всегда тривиален? Так это понятно даже и ежу. Сложность кода в декларативном стиле, по крайней мере не меньше сложности формулировки задачи.
Я то имел в виду лишь то, что по сравнению с невнятной характеристикой "выразительность" характеристика "декларативность" ясна. Но и это вопрос, конечно, дискуссионный.
Т>Вот здесь
, то у меня такое впечатление, что "декларативный" вариант гораздо более напоминает описание пошагового решения, чем императивный.
Даже с учетом того, что это только отчасти имеративный пример (перебор всех элементов списка xs декларативен, а построение отфильтрованного списка императивно) все равно не могу согласиться.
... << RSDN@Home 1.2.0 alpha rev. 726>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, mkizub, Вы писали:
M>Эта проблема решается в SymADE изначально — программу можно представлять (отображать) как угодно, с разной степенью детальности.
Ну так это для любого языка реализовать можно, распарсил исходники, построил AST и отображай в IDE как хочешь. Только так обычно никто не делает.
M>Например то, чем так гордятся в FP — вывод типов — в SymADE просто нафиг не нужен, поскольку эти типы в декларации меторов/переменных можно отображать, а можно и не отображать.
Сильное заявление. А декларировать?
... << RSDN@Home 1.2.0 alpha rev. 726>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Трурль, Вы писали:
Т>Ну, про мощность уже выяснили. А по сопротивлению надо оценивать упругость языка.
Я уже понял, что рассматривать язык в отрыве от программиста неправильно. Поэтому нужно переходить к лобовому сопротивлению программиста. Оно, понятное дело, делится на три компонента:
1) Абстрактное — возникает в результате напора потока абстракций языка на лобные доли программиста.
2) Декларативное — определятеся разностью между формулировкой задачи и ее решением на данном языке.
3) Синтаксическое — возникает при больших значениях числа Губанова.
... << RSDN@Home 1.2.0 alpha rev. 726>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Gaperton, Вы писали:
AVK>>А native совершенно не обязателен, как показывает практика. Впрочем, mono --aot и флаг вам в руки G>native обязателен, если хочется быстро работать и не таскать за собой mono .
Новые веяния? Java must die?
Здравствуйте, Gaperton, Вы писали:
G>JIT-компилятор Java на моно, транслирующий java байт-код в CLR? Интересный подход.
Необязательно. Можно сразу получить нормальную нетовскую сборку.
G>1) А как у нас, интересно, будет выглядеть интероп с каким-нибудь Java Application Server, где своя VM?
Что то на тему взаимодействия BEA и IKVM я в сети видел, но подробностей уже не помню. Есть, кстати, и обратные решения — преобразование CIL в джавовский байткод. Ну и компилятор
G>2) Крайне любопытно, правда — неужели там сборщик мусора научился подбирать неиспользуемые Java классы, и у нас будет реально работать свой classloader
Без понятия.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
Здравствуйте, Gaperton, Вы писали:
G>>>Уж больно по дурацки платформа выбрана — будь он реально кроссплатформенный
G>Вероятно, но не все хотят таскать за своей аппликухой mono.
Это не есть смертельный недостаток. Джаву же таскают, и ничего. Кроме того, в некоторых линухах и современных виндах CLR присутствует по умолчанию, а при необходимости легко устанавливается.
AVK>>А native совершенно не обязателен, как показывает практика. Впрочем, mono --aot и флаг вам в руки
G>native обязателен, если хочется быстро работать
Как показывает практика native совсем не означает быстро работать
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
Здравствуйте, AndrewVK, Вы писали:
G>>>>Уж больно по дурацки платформа выбрана — будь он реально кроссплатформенный
G>>Вероятно, но не все хотят таскать за своей аппликухой mono.
AVK>Это не есть смертельный недостаток. Джаву же таскают, и ничего. Кроме того, в некоторых линухах и современных виндах CLR присутствует по умолчанию, а при необходимости легко устанавливается.
Мне все равно не нравится, но ладно, допустим это действительно не смертельный недостаток. Про mono я как-то забыл, когда писал изначальный пост.
AVK>>>А native совершенно не обязателен, как показывает практика. Впрочем, mono --aot и флаг вам в руки
G>>native обязателен, если хочется быстро работать
AVK>Как показывает практика native совсем не означает быстро работать
Есть примеры, когда JIT или интерпретатор обходит native?
Здравствуйте, Gaperton, Вы писали:
AVK>>Как показывает практика native совсем не означает быстро работать G>Есть примеры, когда JIT или интерпретатор обходит native?
HotSpot JVM на некоторых микротестах.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Gaperton, Вы писали:
AVK>>>Как показывает практика native совсем не означает быстро работать G>>Есть примеры, когда JIT или интерпретатор обходит native? C>HotSpot JVM на некоторых микротестах.
Ты же понимаешь, что это не совсем "практика". Это спорт. В реальности все знают, что у JVM-приложений хуже отклик и они медленнее — это реально заметно на апликухах.
Здравствуйте, Gaperton, Вы писали:
AVK>>Как показывает практика native совсем не означает быстро работать G>Есть примеры, когда JIT или интерпретатор обходит native?
Это неверная постановка вопроса. Lisp тоже зачастую компилируется в native. И на многих тестах GC делает стандартное выделение памяти C++.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Gaperton, Вы писали:
AVK>>>Как показывает практика native совсем не означает быстро работать G>>Есть примеры, когда JIT или интерпретатор обходит native? GZ>Это неверная постановка вопроса. Lisp тоже зачастую компилируется в native. И на многих тестах GC делает стандартное выделение памяти C++.
Это верная постановка вопроса. Я говорил не про GC и не про компиящийся в нэйтив лисп, а про JIT и итерпретаторы.
Здравствуйте, Gaperton, Вы писали:
G>Это верная постановка вопроса. Я говорил не про GC и не про компиящийся в нэйтив лисп, а про JIT и итерпретаторы.
А при чем тут интерпретаторы? JIT — это компилятор. Просто вокруг него есть некоторая среда — VM, которая хотя и ограничивает некоторые действия, но в то же время достаточно универсально решает задачи управления памятью и предоставление некоторых других сервисов. Но в то же время любой native язык — это ограничение некоторых возможностей. Ессно, кроме ассемблера, который мы в расчет не берем.
Здравствуйте, Gaperton, Вы писали:
G>Не знаю, не знаю. Нивабиду, но люди говорят, что бабло плохо вас мотивирует в случае сайта. Жалуются, что у вас даже за деньги рекламу разместить проблема. Жалуются, что баннер ваш меняется слишком редко — доходит до идиотизма, скажем, неделями висит баннер с рекламой уже прошедшего семинара, и снять его нельзя.
Это утут совсем офтоп, но по сикрету тебе скажу, что банер менять можно. Можно даже снять, но вот продавать мы может только на фиксированный срок. Иначе ничего не спланируешь.
Ну, и деньги это копеечные. На них даже одному черовеку зарплату платить нельзя.
G>С этим я безусловно согласен. Немерле — это отличный опыт, практически доказывающий, что возможно мягкое введение концепций ФП в мэйнстримовые языки. Примерно, как это было сделано с С, С++, и ООП. Важность Немерле с этой точки зрения сложно переоценить.
В общем, то концепции ООП он тоже туда вводит. Тут он конечно не один. Есть скала, да и Шарп подтягивается. Но лично мне ждать пока МС или Сан дорастут скажем до паттер-матчинга или сделает чтобы все стрэйтменты можно было в выражениях использовать я не хочу. Боюсь, что столько не проживу.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Gaperton, Вы писали:
G>>Это верная постановка вопроса. Я говорил не про GC и не про компиящийся в нэйтив лисп, а про JIT и итерпретаторы. GZ>А при чем тут интерпретаторы? JIT — это компилятор.
1) JIT это одна из схем построения эффективного интерпретатора байт-кода.
2) Что такое JIT и как он работает- знает подавляющее большинство присутствующих.
3) В глупый флейм по идиотскому поводу я ввязываться не намерен. Отвечать тебе и комментировать подобные ответы больше не буду.
4) Не можешь ничего сказать по существу вопроса — зачем пишешь вообще, просто чтоб написать? Не понимаю.
___________________________________ GZ>Просто вокруг него есть некоторая среда — VM, которая хотя и ограничивает некоторые действия, но в то же время достаточно универсально решает задачи управления памятью и предоставление некоторых других сервисов. Но в то же время любой native язык — это ограничение некоторых возможностей. Ессно, кроме ассемблера, который мы в расчет не берем.
Здравствуйте, Gaperton, Вы писали:
AVK>>Как показывает практика native совсем не означает быстро работать
G>Есть примеры, когда JIT или интерпретатор обходит native?
Есть конечно. МСовский .NET, например, практически всегда быстрее нативного Delphi.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
Здравствуйте, Klapaucius, Вы писали:
M>>Эта проблема решается в SymADE изначально — программу можно представлять (отображать) как угодно, с разной степенью детальности.
K>Ну так это для любого языка реализовать можно, распарсил исходники, построил AST и отображай в IDE как хочешь. Только так обычно никто не делает.
А не делает потому, что нельзя определить семантически новых понятий — не очень надо. В мета-программировании (языке вроде Lisp-а) это само напрашивается.
Если такое IDE будет, то так станут делать и для традиционных языков. Врядли для Java, а вот для OCaml, Haskel и т.п. — наверняка будут. Потому как сама концепция разного отображения кода уже будет привычной.
M>>Например то, чем так гордятся в FP — вывод типов — в SymADE просто нафиг не нужен, поскольку эти типы в декларации меторов/переменных можно отображать, а можно и не отображать.
K>Сильное заявление. А декларировать?
Аналогично. Можно декларировать, можно не декларировать. Если не декларировать — то некий плагин к IDE будет выводить типы и сам их дорисовывать. Может дорисовывать как автокомплит (то есть предлагать, и вставлять в исходники), а может выводить их уже только на стадии компиляции (то есть не сохраняя в исходном коде). Разумеется, показывать или не показывать эти автовыводимые типы тоже можно.
Здравствуйте, Gaperton, Вы писали:
G>Вот, господа, смотрите внимательно. Мы сейчас наблюдаем практическое, и самое существенное отличие наколенной поделки энтузиастов — пусть даже и удачной технически, от зрелой промышленной платформы.
Здравствуйте, mkizub, Вы писали:
M>Если такое IDE будет, то так станут делать и для традиционных языков. Врядли для Java, а вот для OCaml, Haskel и т.п. — наверняка будут. Потому как сама концепция разного отображения кода уже будет привычной.
Нафига седло корове?
Эти языки достаточно выразительны чтобы обходится без подобных костылей.
Здравствуйте, Gaperton, Вы писали:
G>1) JIT это одна из схем построения эффективного интерпретатора байт-кода.
Just In Time compilation — это интерпретатор?
G>2) Что такое JIT и как он работает- знает подавляющее большинство присутствующих.
Канечно. Разницу между генерацией машинного кода, и непосредственно выполнения байт-кода, я думаю, понимают все. И ты в том числе.
G>3) В глупый флейм по идиотскому поводу я ввязываться не намерен. Отвечать тебе и комментировать подобные ответы больше не буду.
Хотелось бы.
G>4) Не можешь ничего сказать по существу вопроса — зачем пишешь вообще, просто чтоб написать? Не понимаю.
А я тебе и ответил по существу. В данном вопросе существа то нет. Как и смысла. То же время отклика в Java зачастую больше чем в системах C++ из-за культуры построения систем. В Java культура программирования такая, из нескольких универсальных монстроидальных пакетов собрать нужное тебе решение. Монстроидально универсальное всегда медленее, чем специализированное решение. Но это отнюдь не значит что решения C++ всегда опережают по скорости решения Java или Net.
Здравствуйте, mkizub, Вы писали:
M>Здравствуйте, FR, Вы писали:
FR>>Нафига седло корове? FR>>Эти языки достаточно выразительны чтобы обходится без подобных костылей.
M>Особенно меня раздражает в собеседниках неумение следить за ходом разговора, и как следствие — вечное хождение по одним и тем-же граблям.
Непонятна мне претензия.
Алгебраическая нотация — плод нескольких веков развития естественных наук, и она наилучшим образом подходит для сложных абстракций. То есть, если я могу написать
x = что-то очень абстрактное
и в дальнейших доказательствах/рассуждениях/коде/etc. смогу ссылаться на этот x, то все остальные красоты могут идти лесом. Ну разве чтобы финансирование выбивать, можно генератор модных красивых картинок использовать.
Здравствуйте, deniok, Вы писали:
D>Непонятна мне претензия.
D>Алгебраическая нотация — плод нескольких веков развития естественных наук, и она наилучшим образом подходит для сложных абстракций. То есть, если я могу написать D>
D>x = что-то очень абстрактное
D>
D>и в дальнейших доказательствах/рассуждениях/коде/etc. смогу ссылаться на этот x, то все остальные красоты могут идти лесом. Ну разве чтобы финансирование выбивать, можно генератор модных красивых картинок использовать.
Особенно похоже на алгебраическую нотацию нечто вроде
s = [ 2*x | x <- [0..], x^2 > 3 ]
Математическую запись ты годами изучал в школе, а потом в институте. Возьми формулу из физики и попробуй в ней разобраться. Я физфак кончал, и гарантию даю — если ты физику не изучал, хрен ты в этой формуле что поймёшь, кроме значка интеграла.
Ещё раз, медленно и два раза. Есть удобная запись для профессионала, она осваивается годами. Она компактная и выразительная, но тем самым совершенно непонятна начинающему — это неизбежное следствие вытекающее из самых основ теории информации и кибернетики. А понятная новичку запись — будет раздражать своей многословностью и неудобством профессионала. Иметь несколько синтаксисов для одного языка — не спасает положения, так как новичку надо разбираться в уже написанном коде. Единственный варинат — это уметь один и тот-же код (один и тот-же кусок программы) отображать по разному для разных людей. Об этом тут речь и идёт, а не о выразительности или невыразительности языка, красоте или некрасивости математической записи.
Здравствуйте, mkizub, Вы писали:
M>Особенно похоже на алгебраическую нотацию нечто вроде
M>
M>s = [ 2*x | x <- [0..], x^2 > 3 ]
M>
Ага, в точности теоретико-множественное
M>Математическую запись ты годами изучал в школе, а потом в институте. Возьми формулу из физики и попробуй в ней разобраться. Я физфак кончал, и гарантию даю — если ты физику не изучал, хрен ты в этой формуле что поймёшь, кроме значка интеграла.
И зачем человеку, незнакомому с применяемыми в коде абстракциями доступ к этому коду?
M>Ещё раз, медленно и два раза. Есть удобная запись для профессионала, она осваивается годами. Она компактная и выразительная, но тем самым совершенно непонятна начинающему — это неизбежное следствие вытекающее из самых основ теории информации и кибернетики. А понятная новичку запись — будет раздражать своей многословностью и неудобством профессионала. Иметь несколько синтаксисов для одного языка — не спасает положения, так как новичку надо разбираться в уже написанном коде. Единственный вариант — это уметь один и тот-же код (один и тот-же кусок программы) отображать по разному для разных людей. Об этом тут речь и идёт, а не о выразительности или невыразительности языка, красоте или некрасивости математической записи.
Зачем человеку читать некоторый код? Наверное, чтобы его развивать и модифицировать, или, по крайней мере поддерживать, нес па? А это означает, что он должен понимать все программистские абстракции, которые использовались плюс абстракции предметной области. И хорошо понимать, иначе его допускать до любых изменений просто нельзя. И ни язык, ни среда здесь ничем делу не помогут.
Здравствуйте, deniok, Вы писали:
M>>Особенно похоже на алгебраическую нотацию нечто вроде
s = [ 2*x | x <- [0..], x^2 > 3 ]
D>Ага, в точности теоретико-множественное D>
Ну ладно, я дальтоник. Но я же не слепой, чтоб не увидеть разницы между этими двумя картинками
M>>Математическую запись ты годами изучал в школе, а потом в институте. Возьми формулу из физики и попробуй в ней разобраться. Я физфак кончал, и гарантию даю — если ты физику не изучал, хрен ты в этой формуле что поймёшь, кроме значка интеграла.
D>И зачем человеку, незнакомому с применяемыми в коде абстракциями доступ к этому коду?
Вот, ты опять путаешь саму абстракцию и способ её отображения.
Второе, доступ к этому коду человеку нужен когда он только включается в данный проект. Речь изначально шла именно об этом, что при освоении проблемы человеку нужна избыточность информации, а когда он её уже освоил — эта избыточность ему начинает мешать. Я это уже третий раз повторяю — и это тоже пример необходимой избыточности.
D>Зачем человеку читать некоторый код? Наверное, чтобы его развивать и модифицировать, или, по крайней мере поддерживать, нес па? А это означает, что он должен понимать все программистские абстракции, которые использовались плюс абстракции предметной области. И хорошо понимать, иначе его допускать до любых изменений просто нельзя. И ни язык, ни среда здесь ничем делу не помогут.
А с какого бодуна он научится делать эти изменения, если ему их не дают делать?
Это как в анекдоте про психбольницу — вначале мы научимся плавать,а потом нам нальют воду.
Вспомни (надеюсь, есть что вспоминать) себя, когда тебя брали на работу на новый для тебя проект, который уже многие годы разрабатывался другими программистами. Тебе что, не давали его исследовать, и понемногу менять? Давали, но вначале самые простые вещи, и контролировали твои изменения. А через год работы ты уже сам правил код вовсю, и контролировал изменения делаемые новичками.
Повторяю третий раз — человек знаком с абстракцией, но он ещё не настолько автоматизировал свою работу и образ мыслей, чтоб думать в конкретной записи этой абстрации, или вообще привык к другой записи этой же абстракции.
Здравствуйте, mkizub, Вы писали:
M>Ещё раз, медленно и два раза. Есть удобная запись для профессионала, она осваивается годами. Она компактная и выразительная, но тем самым совершенно непонятна начинающему — это неизбежное следствие вытекающее из самых основ теории информации и кибернетики. А понятная новичку запись — будет раздражать своей многословностью и неудобством профессионала. Иметь несколько синтаксисов для одного языка — не спасает положения, так как новичку надо разбираться в уже написанном коде. Единственный варинат — это уметь один и тот-же код (один и тот-же кусок программы) отображать по разному для разных людей. Об этом тут речь и идёт, а не о выразительности или невыразительности языка, красоте или некрасивости математической записи.
А почему ты уверен что развернув абстракцию мы получим нечто более простое и понятное?
Если будет машиная развертка точно получим только лишнюю детализацию без всякого упрощения для понимания, посмотри например сишный код который генерируют ML или Haskell компиляторы.
(то что на другом языке не принципиально если этот си дословно перевести на тот же ML будет не менее страшно)
Здравствуйте, mkizub, Вы писали:
M>Особенно меня раздражает в собеседниках неумение следить за ходом разговора, и как следствие — вечное хождение по одним и тем-же граблям.
А меня раздражет то, что некторые собеседники, предполагают что кругом телепаты
Кстати у тебя грабли тоже одни и те же, так и не можешь никому показать реальные преимущества твоего подхода.
Здравствуйте, mkizub, Вы писали:
M>Здравствуйте, deniok, Вы писали:
M>>>Особенно похоже на алгебраическую нотацию нечто вроде
M>
M>s = [ 2*x | x <- [0..], x^2 > 3 ]
M>
D>>Ага, в точности теоретико-множественное D>>
M>Ну ладно, я дальтоник. Но я же не слепой, чтоб не увидеть разницы между этими двумя картинками
А разницы нет. Они изоморфны
M>>>Математическую запись ты годами изучал в школе, а потом в институте. Возьми формулу из физики и попробуй в ней разобраться. Я физфак кончал, и гарантию даю — если ты физику не изучал, хрен ты в этой формуле что поймёшь, кроме значка интеграла.
D>>И зачем человеку, незнакомому с применяемыми в коде абстракциями доступ к этому коду?
M>Вот, ты опять путаешь саму абстракцию и способ её отображения. M>Второе, доступ к этому коду человеку нужен когда он только включается в данный проект. Речь изначально шла именно об этом, что при освоении проблемы человеку нужна избыточность информации, а когда он её уже освоил — эта избыточность ему начинает мешать. Я это уже третий раз повторяю — и это тоже пример необходимой избыточности.
Нету никакой необходимой избыточности, которую можно автоматически сгенерировать. Для того, чтобы изучить некоторую библиотеку нужно её использовать, то есть дёргать в разных контекстах и смотреть, что получается. А потом думать — почему так получается. "Освоение проблемы" — это активная игра с проблемой в её внутренних терминах, а не пассивное созерцание ее разнообразных эквивалентных интерпретаций.
Здравствуйте, Дм.Григорьев, Вы писали:
G>>Вот, господа, смотрите внимательно. Мы сейчас наблюдаем практическое, и самое существенное отличие наколенной поделки энтузиастов — пусть даже и удачной технически, от зрелой промышленной платформы.
ДГ>А как Вы в этом плане к Scala относитесь?
Коммьюнити вроде как больше. По крайней мере, ссылок в гугле в 10 раз больше, чем на Nemerle — только что проверил. Больше я ничего не знаю про эту сторону Scala — не интересовался.
Здравствуйте, Gaperton, Вы писали:
G>Коммьюнити вроде как больше. По крайней мере, ссылок в гугле в 10 раз больше, чем на Nemerle — только что проверил. Больше я ничего не знаю про эту сторону Scala — не интересовался.
Допустим, я добавлю в качестве дополнительной информации, что десять учёных делают язык на фуллтайме. Теперь, предположим, вам делают предложение (к примеру, ваши же программисты): а давайте сделаем вот этот вот новый проектик на Scala! Ваши действия/реакция?
Здравствуйте, Gaperton, Вы писали:
G>>>Есть примеры, когда JIT или интерпретатор обходит native? C>>HotSpot JVM на некоторых микротестах. G>Ты же понимаешь, что это не совсем "практика". Это спорт.
Все ближе к реальной практике. Я бы сказал, что года через четыре уже будет реально заметно на макроскопических программах.
G>В реальности все знают, что у JVM-приложений хуже отклик и они медленнее — это реально заметно на апликухах.
В реальности хорошие Java-приложения работают без всяких проблем с откликом и не медленнее нативных. Можно сравнить по той же Eclipse и MSVS, Eclipse полностью на Java написана (за исключением небольшого куска нативного кода в SWT), а MSVS по большей части на С++.
Естественно, в некоторых случаях могут быть проблемы из-за сборщика мусора — но он в Sun JVM пока что самый лучший в индустрии не-realtime-коллектор.
G>>Коммьюнити вроде как больше. По крайней мере, ссылок в гугле в 10 раз больше, чем на Nemerle — только что проверил. Больше я ничего не знаю про эту сторону Scala — не интересовался.
ДГ>Допустим, я добавлю в качестве дополнительной информации, что десять учёных делают язык на фуллтайме. Теперь, предположим, вам делают предложение (к примеру, ваши же программисты): а давайте сделаем вот этот вот новый проектик на Scala! Ваши действия/реакция?
1) Зависит от проекта.
2) "десять учёных делают язык на фуллтайме" — этой информации мало. Меня, вероятно, заинтересовали бы их планы лет на 5 вперед, цели проекта Scala, источник финансирования, а также активность сообщества — как много людей кроме авторов имеет реальный доступ к репозиторию.
3) Меня заинтересовала бы ситуация с тулзами, отладчиками, профайлерами, библиотеками, и прочим "обвесом".
4) Еще — мне стало бы интересно, есть ли стандарт языка. И его спецификация.
5) Также, меня заинтересовало бы, есть ли кто-то, кто сделал нечто коммерческое на scala, или я буду первым.
6) Меня заинтересовал бы опыт моих людей со scala.
7) А также, расписание выхода mantenance releases, и насколько оперативно исправляются проблемы.
Если выяснится, что у моих орлов нет толком опыта работы со scala, что я буду первым, кто наступит на грабли при реальном применении языка, что стандарт языка не готов, и спецификация плывет — то ничего, кроме скрипта подсчета строк кода я на scala делать не разрешу.
Дело в том, что работая поверх JVM этот язык не имеет выраженного преимущества, скажем, перед Java, — по сути, это одна и та же платформа. А вот недостатки — серьезные, например, фактически неподдерживаемый код, который я скорее всего получу в результате (с офигенно большой вероятностью). Нужны очень сильные аргументы, чтобы предпочесть его java (назовете?). Поэтому, ничего, кроме скромных пилотных проектов/прототипов (короче, фигни, которую не жалко переписать), я скорее всего делать на нем не дал бы.
Здравствуйте, FR, Вы писали:
FR>А почему ты уверен что развернув абстракцию мы получим нечто более простое и понятное?
Приведённый выше пример можно записать как
s = [ 2*x | x <- [0..], x^2 > 3 ]
а можно как
"S is the list of all 2*x where x is an item in the list of natural numbers, and x squared is greater than 3."
Ты уверен, что для незнакомого с хаскелевским синтаксисом человека, вторая запись не будет более простой и понятной?
FR>Если будет машиная развертка точно получим только лишнюю детализацию без всякого упрощения для понимания, посмотри например сишный код который генерируют ML или Haskell компиляторы.
Это не развёртка, это выражение одной абстракции через другие, более примитивные. При этом первоначальная абстрация уже отсутствует, она теряется. Такой же пример я могу привести из собственного опыта написания компиляторов — развёртка декларативного пролог-подобного кода в императивную state machine. При этом теряется как понятность так и декларативность. Но эти записи не эквивалентны, это потеря информации.
D>>>Ага, в точности теоретико-множественное D>>>
M>>Ну ладно, я дальтоник. Но я же не слепой, чтоб не увидеть разницы между этими двумя картинками
D>А разницы нет. Они изоморфны
Изоморфны — не значит идентичны. И потом, они не изоморфны — они есть разное выражение одной и той-же абстракции, но выражены различным синтаксисом, используют различные соглашения (контекст). Ты ещё скажи, что слово "стул" и реальный стул — изоморфны.
D>Нету никакой необходимой избыточности, которую можно автоматически сгенерировать.
Есть. Форматирование кода — простейший пример. Компьютерю (компилятору) в форматировании нет никакой необходимости, а вот человеку есть. Подумай над этим, может через это ты поймёшь о чём я говорю.
D>Для того, чтобы изучить некоторую библиотеку нужно её использовать, то есть дёргать в разных контекстах и смотреть, что получается. А потом думать — почему так получается. "Освоение проблемы" — это активная игра с проблемой в её внутренних терминах, а не пассивное созерцание ее разнообразных эквивалентных интерпретаций.
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, Klapaucius, Вы писали:
K>>Вообще, "мощность языка" понятие довольно невнятное, для которого у каждого может быть свое интуитивное понимание. Лично я оцениваю мощность языка по сопротивлению, которое он оказывает при попытках думать и говорить на нем.
Т>Ну, про мощность уже выяснили. А по сопротивлению надо оценивать упругость языка.
Отчего же. Сопротивление языка можно выразить через его мощность, причем для этого хватит знаний школьной физики.
I = U / R, P = I U
следовательно
R = U / I = U^2 / P
Ну вот, теперь мысль Клапауция как на ладони — сопротивление, оказываемое языком, пропорционально квадрату напряжения, которое требуется для того, чтобы думать и говорить на нем. Но, при этом, оно обратно пропорционально его мощности.
Метод оценки мощности по сопротивлению языка — это, безусловно, новое слово в инженерной науке.
Здравствуйте, mkizub, Вы писали:
M>Приведённый выше пример можно записать как M>s = [ 2*x | x <- [0..], x^2 > 3 ] M>а можно как M>"S is the list of all 2*x where x is an item in the list of natural numbers, and x squared is greater than 3." M>Ты уверен, что для незнакомого с хаскелевским синтаксисом человека, вторая запись не будет более простой и понятной?
Не будет. Ты здесь реально просто тоже самое выразил в другом синтаксисе (да еще похоже в таком который править будет невозможно) а выше был разговор о том чтобы сложную абстракцию развернуть так чтобы она стала понятной новичку, здесь нет никакой развертки.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, mkizub, Вы писали:
M>>Приведённый выше пример можно записать как M>>s = [ 2*x | x <- [0..], x^2 > 3 ] M>>а можно как M>>"S is the list of all 2*x where x is an item in the list of natural numbers, and x squared is greater than 3." M>>Ты уверен, что для незнакомого с хаскелевским синтаксисом человека, вторая запись не будет более простой и понятной?
FR>Не будет. Ты здесь реально просто тоже самое выразил в другом синтаксисе (да еще похоже в таком который править будет невозможно) а выше был разговор о том чтобы сложную абстракцию развернуть так чтобы она стала понятной новичку, здесь нет никакой развертки.
Наверное в этом и корень непонимания. Я имел в виду под развёрткой — представление той-же абстрации, но в более развёрнутом синтаксисе, более громоздком и более понятном синтаксисе для человека не знакомого с компактным синтаксисом. Именно об этом противоречии и шла речь в изначальном постинге http://www.rsdn.ru/forum/message/2822611.1.aspx
на который я отвечал и вся эта под-ветка началась: Упрощенно: громоздкий синтаксис тяготеет к литературному языку и доступен после окончания первого класса; легковесный — тяготеет к математической нотации, с понятными проблемами — первого класса уже недостаточно!
Здравствуйте, mkizub, Вы писали: M>Приведённый выше пример можно записать как M>s = [ 2*x | x <- [0..], x^2 > 3 ] M>а можно как M>"S is the list of all 2*x where x is an item in the list of natural numbers, and x squared is greater than 3." M>Ты уверен, что для незнакомого с хаскелевским синтаксисом человека, вторая запись не будет более простой и Нпонятной?
Совершенно не факт, что синтаксис хаскеля изучить существенно сложнее, чем понятия "естественных чисел" и "отквадраченный х".
И это еще вырожденный пример — в реальной жизни такие простые выражения — исключения. Ну вот посмотрите в википедии про Exceptionally Simple Theory of Everything. Проблема там не в синтаксисе, а в семантике.
M>Это не развёртка, это выражение одной абстракции через другие, более примитивные. При этом первоначальная абстрация уже отсутствует, она теряется. Такой же пример я могу привести из собственного опыта написания компиляторов — развёртка декларативного пролог-подобного кода в императивную state machine. При этом теряется как понятность так и декларативность. Но эти записи не эквивалентны, это потеря информации.
Ну вот пока непонятно, откуда возьмется недостающая информация.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Gaperton, Вы писали:
G>>>>Есть примеры, когда JIT или интерпретатор обходит native? C>>>HotSpot JVM на некоторых микротестах. G>>Ты же понимаешь, что это не совсем "практика". Это спорт. C>Все ближе к реальной практике. Я бы сказал, что года через четыре уже будет реально заметно на макроскопических программах.
Я понимаю, о чем ты. Я про это читал уже давно — теоретически, у JIT больше информации для генерации оптимального кода, так как ему доступна статистика выполнения, чего нет у компилятора. Теоретически, возможно применять это знание для, скажем, выбора оптимальной схемы компиляции switch или множественных if. Также, JIT может генерировать специализированные версии функций для частных случаев, что радикально поправляет здоровье в случае динамики, как делает, например, Psyco.
Короче, в теории можно много чего. Практически, однако, заметного преимущества пока нет — зато есть видимый глазу просос по времени отклика — неравномено оно (понятно, что здесь и GC оказывает влияние, дело не только и не столько в JIT). Было бы очень интересно посмотреть на работы в этом направлении, демонстрирующие убедительное превосходство JIT перед статической компиляцией. Пока мне такого не известно — если не брать случай динамических языков и Psyco.
G>>В реальности все знают, что у JVM-приложений хуже отклик и они медленнее — это реально заметно на апликухах. C>В реальности хорошие Java-приложения работают без всяких проблем с откликом и не медленнее нативных. Можно сравнить по той же Eclipse и MSVS, Eclipse полностью на Java написана (за исключением небольшого куска нативного кода в SWT), а MSVS по большей части на С++.
Те-те-те. Без всяких проблем с откликом — это сильно сказано. Проблем нет, пока не идет речь хотя бы о мягком реальном времени. Ты много игр FPS знаешь на Java? Я вот одну видел — стратегию в 3D (с расслабленными требованиями к фреймрейту), демку ее можно было скачать с java.com несколько лет назад. Что я могу сказать — налицо просос как минимум раза в 2 по сравнению с нативными играми по отклику при сравнимом уровне графики.
C>Естественно, в некоторых случаях могут быть проблемы из-за сборщика мусора — но он в Sun JVM пока что самый лучший в индустрии не-realtime-коллектор.
Лучший в индустрии коллектор, который дает soft-realtime, пока что в Erlang/OTP, и аналогов ему (пока) в индустрии нет. Он, может быть, и тормознее, чем сановский — все-таки stop-and-copy, зато обеспечивает великолепный и почти постоянный отклик, гораздо лучше явких GC. Еще есть вроде как WebLogic RealTime Edition, но народ кто с ним работал морщится и говорит что добавив в название RealTime они погорячились.
Однако — все течет, все меняется, и я знаю что сейчас очень много усилий тратится на разработку эффективных инкрементальных mark-and-sweep коллекторов. Эти исследования рано или поздно принесут результат.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Gaperton, Вы писали:
AVK>>>Как показывает практика native совсем не означает быстро работать
G>>Есть примеры, когда JIT или интерпретатор обходит native?
AVK>Есть конечно. МСовский .NET, например, практически всегда быстрее нативного Delphi.
Андрей, это казуистика, понятно, что сделать тормозной native элементарно и без помощников . Я, разумеется, имел в виду — лучший JIT против лучшего Native.
Здравствуйте, Gaperton, Вы писали:
G>Короче, в теории можно много чего. Практически, однако, заметного преимущества пока нет — зато есть видимый глазу просос по времени отклика — неравномено оно (понятно, что здесь и GC оказывает влияние, дело не только и не столько в JIT). Было бы очень интересно посмотреть на работы в этом направлении, демонстрирующие убедительное превосходство JIT перед статической компиляцией. Пока мне такого не известно — если не брать случай динамических языков и Psyco.
Легко.
public class Test {
public static final boolean DEBUG = Main.DEBUG;
public int test(int a, int b) {
int result = a + b;
if (DEBUG) System.out.println("add "+a+" to "+b+" is "+result);
return result;
}
}
public class Main {
public static boolean DEBUG;
public static void main(String[] args) {
if (args.length > 0 && "--debug".equals(args[0]))
Main.DEBUG = true;
Test t = new Test();
for (int i=0; i < 10000000; i++)
for (int j=0; j < 10000000; j++)
t.test(i,j);
}
}
Пример с отладочным кодом — самый простой. В реале final поля инициализированные из файлов конфигурации очень хорошо ускоряются программы.
Более сложный пример — изменение call conventions для оптимального вызова методов и т.п.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Gaperton, Вы писали:
G>>Не знаю, не знаю. Нивабиду, но люди говорят, что бабло плохо вас мотивирует в случае сайта. Жалуются, что у вас даже за деньги рекламу разместить проблема. Жалуются, что баннер ваш меняется слишком редко — доходит до идиотизма, скажем, неделями висит баннер с рекламой уже прошедшего семинара, и снять его нельзя.
VD>Это утут совсем офтоп, но по сикрету тебе скажу, что банер менять можно. Можно даже снять, но вот продавать мы может только на фиксированный срок. Иначе ничего не спланируешь.
VD>Ну, и деньги это копеечные. На них даже одному черовеку зарплату платить нельзя.
Этот оффтоп я развел к тому, чтобы наглядно показать, что деньги и прочего рода взятки не являются определяющим фактором для развития мотивации. Я уверен что при желании сделать деньги на RSDN и наличии организованности внутри команды у вас бы все получилось — дело скорее в том, что у вас это никому нахрен не надо, и это первично, а не деньги. То есть дело не в деньгах, а в желании.
Вот я вам, например, предлагал купить лицензию на движок вашего форума. И не только я. Выяснилось, что сделать это невозможно, и всем похрен. При этом, вы жалуетесь на недостаток ресурсов для развития сайта, продавать его не хотите, но и в open source вы ни под какой лицензией его класть тоже не хотите — хотя могли бы выложить его под двойной лицензией — GPL + коммерческая.
Короче, Влад, мне кажется, деньги вам не нужны. И в контексте ситуации вокруг Немерле — это скорее плохо, чем хорошо. Потому, что ваша мотивация не сфокусирована и в большей части определяется сиюминутными интересами учатсников. Хочу подчеркнуть — это мое впечатление, я не собираюсь его никому навязывать и не хочу никого обидеть или обвинять в чем-то. Я в данный момент стараюсь быть честным.
G>>С этим я безусловно согласен. Немерле — это отличный опыт, практически доказывающий, что возможно мягкое введение концепций ФП в мэйнстримовые языки. Примерно, как это было сделано с С, С++, и ООП. Важность Немерле с этой точки зрения сложно переоценить.
VD>В общем, то концепции ООП он тоже туда вводит. Тут он конечно не один. Есть скала, да и Шарп подтягивается. Но лично мне ждать пока МС или Сан дорастут скажем до паттер-матчинга или сделает чтобы все стрэйтменты можно было в выражениях использовать я не хочу. Боюсь, что столько не проживу.
Думаю, кстати, проживешь. Ведь МС зачем-то взял разработчиков Немерле на работу — это не просто так. Языки типа Немерле и Scala являются источником вдохновения для разработчиков C#. Это по сути исследовательские языки, на которых проходят апробацию новые концепции. Единственное — у них есть понятие learning curve. Однако, они теперь могут запускать и параллельные ветки — F# же они включили в список поддерживаемых языков. Я уверен, что Немерле гораздо лучше F# приспособлен к современным реалиям, потому что это не калька с известного языка, а творческая и удачная переработка. По своей значимости он похож на С++ — обеспечивает мягкое введение в новый мир. Однако, без поддержки майкрософта — здесь мне кажется мало что может произойти.
То есть, сценария у нас три, и они не являются взаимоисключающими.
1) Один из поддерживаемых языков платформы С# или F# приобретает наиболее удачные свойства Немерле, приближаясь к нему.
2) Немерле с некоторыми модификациями становится одним из официальных языков платформы .NET
3) Про Немерле все забывают. R.I.P.
При данном раскладе — я бы просто подождал, что произойдет дальше. А на вашем месте — попытался бы получить финансирование данных работ от Microsoft Research, как они делали с F#. Если вы, конечно, серьезно настроены. Возможно, у вас есть другой план действий — так озвучте его, чтобы народ успокоить, вдохновить, и вселить в их сердца надежду. А пока — как очень метко сказал GlebZ, ваш шкаф зело похож на гроб, а его ручка — на красивую ошибку природы.
Здравствуйте, Gaperton, Вы писали:
G>Я понимаю, о чем ты. Я про это читал уже давно — теоретически, у JIT больше информации для генерации оптимального кода, так как ему доступна статистика выполнения, чего нет у компилятора. Теоретически, возможно применять это знание для, скажем, выбора оптимальной схемы компиляции switch или множественных if. Также, JIT может генерировать специализированные версии функций для частных случаев, что радикально поправляет здоровье в случае динамики, как делает, например, Psyco.
В JVM основная выгода получается из-за динамического инлайнинга, всё остальное уже не такое больше преимущество дает.
G>Короче, в теории можно много чего. Практически, однако, заметного преимущества пока нет — зато есть видимый глазу просос по времени отклика — неравномено оно (понятно, что здесь и GC оказывает влияние, дело не только и не столько в JIT).
Время отклика из-за JITа важно только во время старта приложения (с этим тоже борются, кстати), пока оно всё не устаканится.
G>Было бы очень интересно посмотреть на работы в этом направлении, демонстрирующие убедительное превосходство JIT перед статической компиляцией. Пока мне такого не известно — если не брать случай динамических языков и Psyco.
Собственно, при прочих равных — превосходство очевидно, у JITа в запасе больше трюков, чем у статического компилятора.
C>>В реальности хорошие Java-приложения работают без всяких проблем с откликом и не медленнее нативных. Можно сравнить по той же Eclipse и MSVS, Eclipse полностью на Java написана (за исключением небольшого куска нативного кода в SWT), а MSVS по большей части на С++. G>Те-те-те. Без всяких проблем с откликом — это сильно сказано. Проблем нет, пока не идет речь хотя бы о мягком реальном времени. Ты много игр FPS знаешь на Java? Я вот одну видел — стратегию в 3D (с расслабленными требованиями к фреймрейту), демку ее можно было скачать с java.com несколько лет назад.
Классический пример — "ИЛ-2 Штурмовик". Там вся логика в игре на Java была написана с небольшим движком на С++.
В приложениях на Java задержки от JITа вообще не составляют заметной проблемы, после пары десятков секунд все что нужно — уже будет скомпилировано. Основная проблема — это сборщик мусора. Именно он и создает в играх тормоза — в нативных играх используется хорошо оптимизированая ручная работа с памятью.
Если убрать задержки от GC — то Java спокойно держит soft-realtime. Обратись в Azul Systems, они тебе с радостью продадут машину с аппаратным ускорением GC, ликвидирущим GC-паузы — эти машинки многие сейчас используют для всяких трейдерских систем.
C>>Естественно, в некоторых случаях могут быть проблемы из-за сборщика мусора — но он в Sun JVM пока что самый лучший в индустрии не-realtime-коллектор. G>Лучший в индустрии коллектор, который дает soft-realtime, пока что в Erlang/OTP, и аналогов ему (пока) в индустрии нет.
Наоборот, в Erlang'е очень тупой и тормозной GC — просто сам язык устроен так, что хватает и такого тупого GC. Какой смысл тратить кучу человеческих ресурсов на разработку супербыстрого GC, если интерпретатор языка будет работать так медленно, что GC будет простаивать почти все время?
G>Он, может быть, и тормознее, чем сановский — все-таки stop-and-copy, зато обеспечивает великолепный и почти постоянный отклик, гораздо лучше явких GC. Еще есть вроде как WebLogic RealTime Edition, но народ кто с ним работал морщится и говорит что добавив в название RealTime они погорячились.
Есть realtime-сборщики для Java на J2ME, но их особо никому не нужно.
G>Однако — все течет, все меняется, и я знаю что сейчас очень много усилий тратится на разработку эффективных инкрементальных mark-and-sweep коллекторов. Эти исследования рано или поздно принесут результат.
Хахаха. Трехцветный mark&sweep известен где-то с 70-х годов. Все основные изменения в нём уже сделаны, ускорить его сильнее — нельзя в принципе. Кроме того, у mark&sweep есть два фатальных недостатка: фрагментация кучи и зависимость времени работы от количества всех объектов (а не только живых как у stop-the-world).
Поэтому, современные быстрые realtime GC (в том числе с приставкой hard-) используют конкуррентную параллельную упаковку объектов. То есть, они работают как stop-the-world, но только не останавливают приложение, а работают параллельно с ним. Для этого нужно, на самом деле, "не так много" — достаточно быстрых forwarding references и быстрых барьеров.
Могу прислать whitepaper от Azul Systems, если интересно подробнее.
Здравствуйте, mkizub, Вы писали:
M>Наверное в этом и корень непонимания. Я имел в виду под развёрткой — представление той-же абстрации, но в более развёрнутом синтаксисе, более громоздком и более понятном синтаксисе для человека не знакомого с компактным синтаксисом. Именно об этом противоречии и шла речь в изначальном постинге http://www.rsdn.ru/forum/message/2822611.1.aspx
на который я отвечал и вся эта под-ветка началась: M>Упрощенно: громоздкий синтаксис тяготеет к литературному языку и доступен после окончания первого класса; легковесный — тяготеет к математической нотации, с понятными проблемами — первого класса уже недостаточно!
Ну такое просто малоинтересно, так как ничего практически не дает.
C>>>В реальности хорошие Java-приложения работают без всяких проблем с откликом и не медленнее нативных. Можно сравнить по той же Eclipse и MSVS, Eclipse полностью на Java написана (за исключением небольшого куска нативного кода в SWT), а MSVS по большей части на С++. G>>Те-те-те. Без всяких проблем с откликом — это сильно сказано. Проблем нет, пока не идет речь хотя бы о мягком реальном времени. Ты много игр FPS знаешь на Java? Я вот одну видел — стратегию в 3D (с расслабленными требованиями к фреймрейту), демку ее можно было скачать с java.com несколько лет назад. C>Классический пример — "ИЛ-2 Штурмовик". Там вся логика в игре на Java была написана с небольшим движком на С++.
Справедливости ради — в итоге ИМНИП от джавы разработчики избавились совсем (или почти совсем), чем ускорили рантайм раза в два (имеется в виду не только прирост FPS но и более точный обсчёт физики, реально вряд ли ФПС подскочили в 2 раза). Основная причина по которой писали на джаве — чтобы ускорить разработку, т.к. конкуренты не дремали и сроки поджимали и игра нужна была "хоть в каком-то виде но к концу месяца". По мере развития, когда физика более-менее устаканилась — джавовую часть переписали на С++. PS — я там не инсайдер и инсайдерской информацией не владею, но это моё вольное изложение слов директора их конторы на каком-то из авиафорумов.
C>В приложениях на Java задержки от JITа вообще не составляют заметной проблемы, после пары десятков секунд все что нужно — уже будет скомпилировано. Основная проблема — это сборщик мусора. Именно он и создает в играх тормоза — в нативных играх используется хорошо оптимизированая ручная работа с памятью.
Опять же, касаясь примера — поскольку на джаве в основном была физика (т.е. обсчёты), то обьектов создавалось-умирало совсем немного, что в итоге вылилось во вполне приемлимые "лаги" в геймплее.
Здравствуйте, Left2, Вы писали:
C>>>>В реальности хорошие Java-приложения работают без всяких проблем с откликом и не медленнее нативных. Можно сравнить по той же Eclipse и MSVS, Eclipse полностью на Java написана (за исключением небольшого куска нативного кода в SWT), а MSVS по большей части на С++. G>>>Те-те-те. Без всяких проблем с откликом — это сильно сказано. Проблем нет, пока не идет речь хотя бы о мягком реальном времени. Ты много игр FPS знаешь на Java? Я вот одну видел — стратегию в 3D (с расслабленными требованиями к фреймрейту), демку ее можно было скачать с java.com несколько лет назад. C>>Классический пример — "ИЛ-2 Штурмовик". Там вся логика в игре на Java была написана с небольшим движком на С++.
L>Справедливости ради — в итоге ИМНИП от джавы разработчики избавились совсем (или почти совсем), чем ускорили рантайм раза в два (имеется в виду не только прирост FPS но и более точный обсчёт физики, реально вряд ли ФПС подскочили в 2 раза). Основная причина по которой писали на джаве — чтобы ускорить разработку, т.к. конкуренты не дремали и сроки поджимали и игра нужна была "хоть в каком-то виде но к концу месяца". По мере развития, когда физика более-менее устаканилась — джавовую часть переписали на С++. PS — я там не инсайдер и инсайдерской информацией не владею, но это моё вольное изложение слов директора их конторы на каком-то из авиафорумов.
Вот то-то и оно. В реальных аппликухах разница заметна глазом почему-то. И в два раза — это не проблема GC. GC должен давать общий оверхэд процентов в 5 от силы, если специально не стараться его нагрузить.
Здравствуйте, Gaperton, Вы писали:
G>Вот то-то и оно. В реальных аппликухах разница заметна глазом почему-то. И в два раза — это не проблема GC. GC должен давать общий оверхэд процентов в 5 от силы, если специально не стараться его нагрузить.
5% на GC — это больше из области фантастики или очень особых условий. В десктопных приложениях тормоза реально из-за него и бывают, ну и из-за долгого начального запуска.
Кроме того, проблема с GC не в скорости, а в латентности. По скорости даже числодробилки на Java не так уж плохо себя ведут.
Здравствуйте, Cyberax, Вы писали:
G>>Я понимаю, о чем ты. Я про это читал уже давно — теоретически, у JIT больше информации для генерации оптимального кода, так как ему доступна статистика выполнения, чего нет у компилятора. Теоретически, возможно применять это знание для, скажем, выбора оптимальной схемы компиляции switch или множественных if. Также, JIT может генерировать специализированные версии функций для частных случаев, что радикально поправляет здоровье в случае динамики, как делает, например, Psyco. C>В JVM основная выгода получается из-за динамического инлайнинга, всё остальное уже не такое больше преимущество дает.
JFYI: Динамический инлайнинг виртуальных функций на новых процах уже не даст выраженного преимущества JIT, так как мне из достоверных источников известно, что разработчики процессоров уже научились делать предвыборку и предсказания по косвенным джампам. Специально для того, чтобы понизить цену виртуального вызова. Насколько я слышал краем уха, в процах последней линейки эта фича уже есть. Они ведь тоже ориентируются на производительность реальных приложений.
А для инлайна статических вызовов, раскрутки циклов, и распределения регистров (которых в x86 неприлично мало) у нормалного компилятора есть гораздо больше времени, чем у JIT. И на оптимальную кодогенерацию у него также гораздо больше времени, чем у джит. Скажем, IC++ учитывает такое количество факторов при кодогенерации, которое JIT-у в реальном времени учесть просто не под силу.
Так что такие разговоры — скорее умный маркетинговый ход. Когда увижу, что джит убедительно обойдет IC++ на приложениях вроде SPEC — тогда можно будет отнестись к тому серьезно. Я думаю, так.
G>>Короче, в теории можно много чего. Практически, однако, заметного преимущества пока нет — зато есть видимый глазу просос по времени отклика — неравномено оно (понятно, что здесь и GC оказывает влияние, дело не только и не столько в JIT). C>Время отклика из-за JITа важно только во время старта приложения (с этим тоже борются, кстати), пока оно всё не устаканится.
Борись-не борись, а природу не обманешь. Интерпретация кода по любому на порядок тормознее выполнения native. А JIT — чем больше времени тратится на компиляцию, тем оптимальнее получается код, и тем больше выходит задержки. Хочешь учитывать факторы динамики — изволь периодически перекомпилять код.
G>>Было бы очень интересно посмотреть на работы в этом направлении, демонстрирующие убедительное превосходство JIT перед статической компиляцией. Пока мне такого не известно — если не брать случай динамических языков и Psyco. C>Собственно, при прочих равных — превосходство очевидно, у JITа в запасе больше трюков, чем у статического компилятора.
В теории — да.
C>>>В реальности хорошие Java-приложения работают без всяких проблем с откликом и не медленнее нативных. Можно сравнить по той же Eclipse и MSVS, Eclipse полностью на Java написана (за исключением небольшого куска нативного кода в SWT), а MSVS по большей части на С++. G>>Те-те-те. Без всяких проблем с откликом — это сильно сказано. Проблем нет, пока не идет речь хотя бы о мягком реальном времени. Ты много игр FPS знаешь на Java? Я вот одну видел — стратегию в 3D (с расслабленными требованиями к фреймрейту), демку ее можно было скачать с java.com несколько лет назад. C>Классический пример — "ИЛ-2 Штурмовик". Там вся логика в игре на Java была написана с небольшим движком на С++.
Тебе про ИЛ-2 ответили чуть ниже — справедливости ради. Почему логика была на Java, и что произошло, когда ее на С++ переписали. Кроме того, я же тебе говрю — по приложениям заметны тормоза. Я видел это на игрушке своими глазами — полигонов и объектов там было меньше, чем в аналогичных играх в native, а тормозила она больше.
C>В приложениях на Java задержки от JITа вообще не составляют заметной проблемы, после пары десятков секунд все что нужно — уже будет скомпилировано. Основная проблема — это сборщик мусора. Именно он и создает в играх тормоза — в нативных играх используется хорошо оптимизированая ручная работа с памятью.
Он создает не тормоза, а задержки, потому что не является по настоящему инкрементальным. Общее время проводимое в GC на самом деле небольшое — например, спокон веков известно, что mark and sweep GC по сумарному оверхэду эффективнее подсчета ссылок.
C>Если убрать задержки от GC — то Java спокойно держит soft-realtime. Обратись в Azul Systems, они тебе с радостью продадут машину с аппаратным ускорением GC, ликвидирущим GC-паузы — эти машинки многие сейчас используют для всяких трейдерских систем.
Это решение. Но к эффективности JIT это отношения не имеет.
C>>>Естественно, в некоторых случаях могут быть проблемы из-за сборщика мусора — но он в Sun JVM пока что самый лучший в индустрии не-realtime-коллектор. G>>Лучший в индустрии коллектор, который дает soft-realtime, пока что в Erlang/OTP, и аналогов ему (пока) в индустрии нет. C>Наоборот, в Erlang'е очень тупой и тормозной GC — просто сам язык устроен так, что хватает и такого тупого GC. Какой смысл тратить кучу человеческих ресурсов на разработку супербыстрого GC, если интерпретатор языка будет работать так медленно, что GC будет простаивать почти все время?
Можешь называть эрланговский GC тупым и тормозным, если тебе так нравится, но факт состоит в том, что в отличии от мега-умных GC Java, — это настоящий инкрементальный GC, который обеспечивает реактивность приложения достаточную для телеком применений, что ни одна другая платформа со сборкой мусора сейчас дать не способна.
В результате, на Эрланге можно делать такие штуки, как свитчи вроде AXD301, которые не смотря на тормознутость Эрланговского GC — одни из самых производительных в мире соф-свитчей, а на Java с его мегаумным GC — у тебя не получится. Это — факты, уважаемый коллега, а не эмоции или "мнения". Мне от GC нужна именно реактивность, во вторую очередь — производительность на реальных задачах, а на такой параметр как "умность" не совершенно плевать.
G>>Он, может быть, и тормознее, чем сановский — все-таки stop-and-copy, зато обеспечивает великолепный и почти постоянный отклик, гораздо лучше явких GC. Еще есть вроде как WebLogic RealTime Edition, но народ кто с ним работал морщится и говорит что добавив в название RealTime они погорячились. C>Есть realtime-сборщики для Java на J2ME, но их особо никому не нужно.
Для J2ME сборщики такие все из себя рилтайм, что там программерам не рекомендуют объекты шибко активно выделать, и рекомендуют выделенные объекты переиспользовать, а не оставлять их GC. А если надо отдать объект GC — то надо ручками все ссылочки занулить, чтоб бедный GC не перенапрягся. В результате, пишешь такой код, как будто никакого GC и вовсе нет. Писал я под J2ME несколько лет назад для своей мобилы, помню эти рекомендации прекрасно.
Никому не надо, говоришь? Думаешь, это так прикольно — все ссылки нулями затирать, да объекты переиспользовать? Все были бы рады нормальному GC на J2ME, который бы просто работал по человечески, да тока во встроенной системе с ограниченной памятью ты вообще никакого real-time гарантировать не сможешь. Там элементарно создать ситуацию, когда хип забит, после чего он разом освобождается, а твоя программа просит памяти еще. Вот stop and copy коллектор такой проблемы лишен by design, почему он и применяется в Эрланге.
G>>Однако — все течет, все меняется, и я знаю что сейчас очень много усилий тратится на разработку эффективных инкрементальных mark-and-sweep коллекторов. Эти исследования рано или поздно принесут результат. C>Хахаха. Трехцветный mark&sweep известен где-то с 70-х годов. Все основные изменения в нём уже сделаны, ускорить его сильнее — нельзя в принципе. Кроме того, у mark&sweep есть два фатальных недостатка: фрагментация кучи и зависимость времени работы от количества всех объектов (а не только живых как у stop-the-world).
Прежде чем ржать, подумай, может ты чего не понял. Я глупости редко пишу, я думаю ты знаешь, и это не тот случай. Потому, что этой темой я активно интересовался несколько лет назад. Дай поиск в гугле по словам incremental mark-and-sweep GC, поймешь, о чем я говорю. Речь не о скорости, не надо там ничего "ускорять". Речь об "инкрементальности" — гарантированной маленькой задержке на GC, чтобы его можно было прервать в любой момент, и хип остался в целостном состоянии. Это для mark-and-sweep — проблема. А вот для stop-and-copy делается довольно просто.
Вот скажем, в информационном письме IBM от 2003 года они с гордостью писали, что в новом релизе IBM JVM им удалось довести гаранированную задержку на GC до такой малой величины, как половина секунды.
C>Поэтому, современные быстрые realtime GC (в том числе с приставкой hard-) используют конкуррентную параллельную упаковку объектов. То есть, они работают как stop-the-world, но только не останавливают приложение, а работают параллельно с ним. Для этого нужно, на самом деле, "не так много" — достаточно быстрых forwarding references и быстрых барьеров.
Очень многообещающие слова. И много у нас "современных коммерческих realtime GC" для Java? Мне кроме WebLogic RealTime edition вместе с паршивыми отзывами на него не известно ни одного. Список в студию, пожалуйста.
C>Могу прислать whitepaper от Azul Systems, если интересно подробнее.
Аппаратная реализация GC мне, разумеется, интересна, но это не совсем то, что надо.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Gaperton, Вы писали:
G>>Вот то-то и оно. В реальных аппликухах разница заметна глазом почему-то. И в два раза — это не проблема GC. GC должен давать общий оверхэд процентов в 5 от силы, если специально не стараться его нагрузить. C>5% на GC — это больше из области фантастики или очень особых условий. В десктопных приложениях тормоза реально из-за него и бывают, ну и из-за долгого начального запуска.
Тесты консервативного Boehm GC для С++ на реальных приложениях дают 2-3% замедления для одного и того же приложения. Надо иметь в виду, что без GC местами применяются довольно дорогие техники управления памятью, такие как подсчет ссылок, что дороже GC. Второе, что надо иметь в виду — кроме собственно поиска мертвых объектов время тратится на управление хипом, выделение и удаление объектов, и это время никуда не девается при отсутствии GC.
Управляющая программа AXD301 проводит в GC 5% своего времени. Тесты смоллток-программ показывают такую же картину — в среднем 5%. Средние затраты на GC вообще в общественном сознании сильно преувеличены, и оверхэд GC является скорее мифом — специалистам известно, что подсчет ссылок дороже чем GC, и подсчета ссылок при этом почему-то никто не боится. Затраты в случае GC заметнее потому, что современные GC не являются инкрементальными, и копят свои проценты, которые потом зачищают всем скопом. Вот тут-то GC и становится заметным.
C>Кроме того, проблема с GC не в скорости, а в латентности. По скорости даже числодробилки на Java не так уж плохо себя ведут.
Проблема не столько в латентности GC, сколько в его инкрементальности — гранулярности операций GC, а именно — его отсутствии.
Здравствуйте, Gaperton, Вы писали:
G>JFYI: Динамический инлайнинг виртуальных функций на новых процах уже не даст выраженного преимущества JIT, так как мне из достоверных источников известно, что разработчики процессоров уже научились делать предвыборку и предсказания по косвенным джампам. Специально для того, чтобы понизить цену виртуального вызова. Насколько я слышал краем уха, в процах последней линейки эта фича уже есть. Они ведь тоже ориентируются на производительность реальных приложений.
Это еще в вроде бы P4 было, я про это даже сюда как-то писал. Там фича в том, что таблица предсказателя — она не бесконечная, сам предсказатель не идеальный, и сам косвенный вызов становится дешевле, но не совсем бесплатным. Так что инлайнинг помогает.
G>А для инлайна статических вызовов, раскрутки циклов, и распределения регистров (которых в x86 неприлично мало) у нормалного компилятора есть гораздо больше времени, чем у JIT. И на оптимальную кодогенерацию у него также гораздо больше времени, чем у джит. Скажем, IC++ учитывает такое количество факторов при кодогенерации, которое JIT-у в реальном времени учесть просто не под силу.
Только большую часть этих фич можно предрассчитать заранее В частности, это одна из причин почему в Java 7 вводят систему модулей, которые будут работать наподобии сборок в .NET. Модули можно будет заранее слинковать и кэшировать для них оптимизированый код.
G>Так что такие разговоры — скорее умный маркетинговый ход. Когда увижу, что джит убедительно обойдет IC++ на приложениях вроде SPEC — тогда можно будет отнестись к тому серьезно. Я думаю, так.
Еще нужно учесть фичи типа обязательной проверки границы в массивах в Java, отсутствие указателей и т.п.
C>>Время отклика из-за JITа важно только во время старта приложения (с этим тоже борются, кстати), пока оно всё не устаканится. G>Борись-не борись, а природу не обманешь. Интерпретация кода по любому на порядок тормознее выполнения native. А JIT — чем больше времени тратится на компиляцию, тем оптимальнее получается код, и тем больше выходит задержки. Хочешь учитывать факторы динамики — изволь периодически перекомпилять код.
Сейчас с приложениями на Java проблема в том, что они долго запускаются. В Java 7 это частично пофиксили — оно умеет прекомпилировать системные файлы и сохранять их в виде кэшированого исполняемого кода. Поэтому в бэтах JDK7 приложения реально "на глаз" начали запускаться как нативные.
C>>Классический пример — "ИЛ-2 Штурмовик". Там вся логика в игре на Java была написана с небольшим движком на С++. G>Тебе про ИЛ-2 ответили чуть ниже — справедливости ради. Почему логика была на Java, и что произошло, когда ее на С++ переписали. Кроме того, я же тебе говрю — по приложениям заметны тормоза. Я видел это на игрушке своими глазами — полигонов и объектов там было меньше, чем в аналогичных играх в native, а тормозила она больше.
Как создатель видеочата с DIVX компрессией на Java могу сказать, что больше всего проблем было с GC. Скорость вообще проблемой не была.
Ну и ИЛ-2 работал так вполне прилично, когда еще был на Java написан.
G>Можешь называть эрланговский GC тупым и тормозным, если тебе так нравится, но факт состоит в том, что в отличии от мега-умных GC Java, — это настоящий инкрементальный GC, который обеспечивает реактивность приложения достаточную для телеком применений, что ни одна другая платформа со сборкой мусора сейчас дать не способна.
Инкрементальные GC — это фигня. Они есть ВЕЗДЕ, даже JVM можно настроить, чтобы использовался только трехцветный mark&sweep. Проблема с ними в том, что мутатор (т.е. работающая программа) на Java может заполнять кучу намного быстрее, чем ее будет собирать mark&sweep. В результате приложение может вдруг получать OutOfMemory. Не веришь — возьми сложное приложение на Java и поставь только инкрементальный mark&sweep. Потом наблюдай спецэффекты.
В Erlang'е все хорошо из-за того, что объекты иммутабельны — там можно выполнять упрощенный вариант трехцветного mark&sweep.
G>В результате, на Эрланге можно делать такие штуки, как свитчи вроде AXD301, которые не смотря на тормознутость Эрланговского GC — одни из самых производительных в мире соф-свитчей, а на Java с его мегаумным GC — у тебя не получится. Это — факты, уважаемый коллега, а не эмоции или "мнения". Мне от GC нужна именно реактивность, во вторую очередь — производительность на реальных задачах, а на такой параметр как "умность" не совершенно плевать.
Я как раз сейчас с телекомом работаю. Да, там Эрланг идеально подходит — скорость не очень важна, зато важно время отклика.
Но ведь ты изначально про тормознутость говорил! А тут, как ты сам знаешь, Эрланг сливает по полной программе.
G>Для J2ME сборщики такие все из себя рилтайм, что там программерам не рекомендуют объекты шибко активно выделать, и рекомендуют выделенные объекты переиспользовать, а не оставлять их GC. А если надо отдать объект GC — то надо ручками все ссылочки занулить, чтоб бедный GC не перенапрягся. В результате, пишешь такой код, как будто никакого GC и вовсе нет. Писал я под J2ME несколько лет назад для своей мобилы, помню эти рекомендации прекрасно.
J2ME — они разные бывают. В некоторых из них используется (до сих пор !) консервативный GC. Поэтому и такие рекомендации.
G>Никому не надо, говоришь? Думаешь, это так прикольно — все ссылки нулями затирать, да объекты переиспользовать? Все были бы рады нормальному GC на J2ME, который бы просто работал по человечески, да тока во встроенной системе с ограниченной памятью ты вообще никакого real-time гарантировать не сможешь. Там элементарно создать ситуацию, когда хип забит, после чего он разом освобождается, а твоя программа просит памяти еще. Вот stop and copy коллектор такой проблемы лишен by design, почему он и применяется в Эрланге.
Это нужен просто НОРМАЛЬНЫЙ GC, а не realtime.
C>>Хахаха. Трехцветный mark&sweep известен где-то с 70-х годов. Все основные изменения в нём уже сделаны, ускорить его сильнее — нельзя в принципе. Кроме того, у mark&sweep есть два фатальных недостатка: фрагментация кучи и зависимость времени работы от количества всех объектов (а не только живых как у stop-the-world). G>Прежде чем ржать, подумай, может ты чего не понял. Я глупости редко пишу, я думаю ты знаешь, и это не тот случай. Потому, что этой темой я активно интересовался несколько лет назад.
А я ей интересуюсь постоянно. GC — это моя область экспертизы, механизмы работы GC в Java я знаю буквально до ассемблерных команд.
G>Дай поиск в гугле по словам incremental mark-and-sweep GC, поймешь, о чем я говорю. Речь не о скорости, не надо там ничего "ускорять". Речь об "инкрементальности" — гарантированной маленькой задержке на GC, чтобы его можно было прервать в любой момент, и хип остался в целостном состоянии. Это для mark-and-sweep — проблема.
Да нифига это не проблема! Это решается простейшим трехцветным GC (tri-color GC, tri-color mark&sweep), корректность работы которого была доказана Дейкстрой (AFAIR) в качестве примера доказательства параллельных алгоритмов. Год точно не вспомню, но точно раньше 80-х, так как я лично держал в руках вариант Схемы начала 80-х годов с таким сборщиком.
Так что лучше и меня иногда послушай
G>Вот скажем, в информационном письме IBM от 2003 года они с гордостью писали, что в новом релизе IBM JVM им удалось довести гаранированную задержку на GC до такой малой величины, как половина секунды.
Вполне нормально для обычного не-realtime.
G>Очень многообещающие слова. И много у нас "современных коммерческих realtime GC" для Java? Мне кроме WebLogic RealTime edition вместе с паршивыми отзывами на него не известно ни одного. Список в студию, пожалуйста.
Azul Systems это УЖЕ предлагает коммерчески. Их системы УЖЕ успешно используются для realtime-трейдинга. Чисто программные системы — Sun RTSJ ( http://java.sun.com/javase/technologies/realtime/ ), Aonix и еще штук 5 таких же.
Они не распространены из-за того, что за них денег просят.
C>>Могу прислать whitepaper от Azul Systems, если интересно подробнее. G>Аппаратная реализация GC мне, разумеется, интересна, но это не совсем то, что надо.
Именно то — реальный способ сделать realtime-GC без потерь в скорости, Erlang OTP оно и не снилось. Те же техники можно сделать и программно — с заметными потерями быстродействия.
Здравствуйте, Gaperton, Вы писали:
G>Тесты консервативного Boehm GC для С++ на реальных приложениях дают 2-3% замедления для одного и того же приложения. Надо иметь в виду, что без GC местами применяются довольно дорогие техники управления памятью, такие как подсчет ссылок, что дороже GC. Второе, что надо иметь в виду — кроме собственно поиска мертвых объектов время тратится на управление хипом, выделение и удаление объектов, и это время никуда не девается при отсутствии GC.
Я использовал Boehm GC в своих приложениях — ну нет там 2-3% замедления. Реально около 10-15% минимум. Для вещей типа игр оно вообще неприменимо — так как всё время норовит начать обходить графы объектов, составляющих геометрию. А это смерть для GC.
Вещи типа подсчета ссылок обычно можно очень сильно уменьшить.
G>Управляющая программа AXD301 проводит в GC 5% своего времени. Тесты смоллток-программ показывают такую же картину — в среднем 5%.
Да, это вполне реально для скриптовых языков, так как мутатор работает очень медленно. Представь, что у тебя мутатор работает в 10 раз быстрее (нативный JIT-код), а GC работает с той же скоростью. Каким тогда будет соотношение времени работы GC и полезного кода?
Вот.
Поэтому простые GC типа Эрланговского и неприменимы в быстрых нативных системах. Там приходится извращатсья с более сложными алгоритмами, из-за чего очень часто теряется realtime. Просто преимущества от него перевешивают увеличение сложности.
C>>Кроме того, проблема с GC не в скорости, а в латентности. По скорости даже числодробилки на Java не так уж плохо себя ведут. G>Проблема не столько в латентности GC, сколько в его инкрементальности — гранулярности операций GC, а именно — его отсутствии.
А я что сказал?
Здравствуйте, Cyberax, Вы писали:
C>Да нифига это не проблема! Это решается простейшим трехцветным GC (tri-color GC, tri-color mark&sweep), корректность работы которого была доказана Дейкстрой (AFAIR) в качестве примера доказательства параллельных алгоритмов. Год точно не вспомню, но точно раньше 80-х, так как я лично держал в руках вариант Схемы начала 80-х годов с таким сборщиком.
Отвечу сам себе — механизм трехцветного GC и преимущество Erlang'а я как-то описывал в этом форуме: http://www.rsdn.ru/Forum/?mid=2261479
Здравствуйте, Gaperton, Вы писали:
G>Андрей, это казуистика, понятно, что сделать тормозной native элементарно и без помощников
Никакой казуистики — коммерческий компилятор с долгой историей развития и кучей написанного на нем софта. И без особых жалоб от юзеров на производительность.
G>. Я, разумеется, имел в виду — лучший JIT против лучшего Native.
Это тоже не совсем корректно, потому что у лучших native вроде VC или ICC значительно более длинная история и значительно больше бабла вбухано в оптимизатор.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
Здравствуйте, Cyberax, Вы писали:
G>>JFYI: Динамический инлайнинг виртуальных функций на новых процах уже не даст выраженного преимущества JIT, так как мне из достоверных источников известно, что разработчики процессоров уже научились делать предвыборку и предсказания по косвенным джампам. Специально для того, чтобы понизить цену виртуального вызова. Насколько я слышал краем уха, в процах последней линейки эта фича уже есть. Они ведь тоже ориентируются на производительность реальных приложений. C>Это еще в вроде бы P4 было, я про это даже сюда как-то писал. Там фича в том, что таблица предсказателя — она не бесконечная, сам предсказатель не идеальный, и сам косвенный вызов становится дешевле, но не совсем бесплатным. Так что инлайнинг помогает.
Таблицы предсказания не будут большой проблемой, так как это реально важно в циклах. К тому же, таблицы сейчас реально большие — там сотни элементов точно, может быть даже тысяча. Предсказатель сейчас умеют делать очень хороший — у МИПСов которые 64 процент успешных предсказаний более 90%, что говорить о Core Duo.
G>>А для инлайна статических вызовов, раскрутки циклов, и распределения регистров (которых в x86 неприлично мало) у нормалного компилятора есть гораздо больше времени, чем у JIT. И на оптимальную кодогенерацию у него также гораздо больше времени, чем у джит. Скажем, IC++ учитывает такое количество факторов при кодогенерации, которое JIT-у в реальном времени учесть просто не под силу. C>Только большую часть этих фич можно предрассчитать заранее В частности, это одна из причин почему в Java 7 вводят систему модулей, которые будут работать наподобии сборок в .NET. Модули можно будет заранее слинковать и кэшировать для них оптимизированый код.
Ну, оптимальную кодогенерацию, такую ацкую, как в IC++, с учетом параметров конвейра проца, особо не предрасчитаешь. Например , оптимальные алгоритмы распределения регистров сами по себе довольно тормозные. А преварительная компиляция — это уже не совсем JIT.
G>>Так что такие разговоры — скорее умный маркетинговый ход. Когда увижу, что джит убедительно обойдет IC++ на приложениях вроде SPEC — тогда можно будет отнестись к тому серьезно. Я думаю, так. C>Еще нужно учесть фичи типа обязательной проверки границы в массивах в Java, отсутствие указателей и т.п.
Верно, на этом, мне кажется, во многом и получается просос раза в два.
C>>>Время отклика из-за JITа важно только во время старта приложения (с этим тоже борются, кстати), пока оно всё не устаканится. G>>Борись-не борись, а природу не обманешь. Интерпретация кода по любому на порядок тормознее выполнения native. А JIT — чем больше времени тратится на компиляцию, тем оптимальнее получается код, и тем больше выходит задержки. Хочешь учитывать факторы динамики — изволь периодически перекомпилять код. C>Сейчас с приложениями на Java проблема в том, что они долго запускаются.
Ничего, это можно пережить ИМХО.
C> В Java 7 это частично пофиксили — оно умеет прекомпилировать системные файлы и сохранять их в виде кэшированого исполняемого кода. Поэтому в бэтах JDK7 приложения реально "на глаз" начали запускаться как нативные.
Прекомпиляция — это ведь опять не JIT, да?
C>>>Классический пример — "ИЛ-2 Штурмовик". Там вся логика в игре на Java была написана с небольшим движком на С++. G>>Тебе про ИЛ-2 ответили чуть ниже — справедливости ради. Почему логика была на Java, и что произошло, когда ее на С++ переписали. Кроме того, я же тебе говрю — по приложениям заметны тормоза. Я видел это на игрушке своими глазами — полигонов и объектов там было меньше, чем в аналогичных играх в native, а тормозила она больше. C>Как создатель видеочата с DIVX компрессией на Java могу сказать, что больше всего проблем было с GC. Скорость вообще проблемой не была.
Скорость, значит, была достаточной для твоих нужд.
C>Ну и ИЛ-2 работал так вполне прилично, когда еще был на Java написан.
Прилично, но по показаниям свидетеля переписывание дало таки ускорение в два раза, нет?
G>>Можешь называть эрланговский GC тупым и тормозным, если тебе так нравится, но факт состоит в том, что в отличии от мега-умных GC Java, — это настоящий инкрементальный GC, который обеспечивает реактивность приложения достаточную для телеком применений, что ни одна другая платформа со сборкой мусора сейчас дать не способна. C>Инкрементальные GC — это фигня. Они есть ВЕЗДЕ, даже JVM можно настроить, чтобы использовался только трехцветный mark&sweep. Проблема с ними в том, что мутатор (т.е. работающая программа) на Java может заполнять кучу намного быстрее, чем ее будет собирать mark&sweep. В результате приложение может вдруг получать OutOfMemory. Не веришь — возьми сложное приложение на Java и поставь только инкрементальный mark&sweep. Потом наблюдай спецэффекты.
Приведи пожалуйста ссылку, подтверждающую отсутствие проблем с soft-realtime в любой JVM. Это следует из твоего текста.
C>В Erlang'е все хорошо из-за того, что объекты иммутабельны — там можно выполнять упрощенный вариант трехцветного mark&sweep.
Хорошо, я сам поищу эти материалы еще раз, и отпишу сюда.
C>Так что лучше и меня иногда послушай
С удовольствием слушаю, я на проводе.
G>>Вот скажем, в информационном письме IBM от 2003 года они с гордостью писали, что в новом релизе IBM JVM им удалось довести гаранированную задержку на GC до такой малой величины, как половина секунды. C>Вполне нормально для обычного не-realtime.
Более-менее нормально, если не считать, что до этого у них задержка достигала десятки секунд на серверах с большим объемом памяти, что было ни разу не нормально, и они задницу в кровь порвали, чтоб до полсекунды гарантии довести. Эту ссылку я также постараюсь найти.
G>>Очень многообещающие слова. И много у нас "современных коммерческих realtime GC" для Java? Мне кроме WebLogic RealTime edition вместе с паршивыми отзывами на него не известно ни одного. Список в студию, пожалуйста. C>Azul Systems это УЖЕ предлагает коммерчески. Их системы УЖЕ успешно используются для realtime-трейдинга. Чисто программные системы — Sun RTSJ ( http://java.sun.com/javase/technologies/realtime/ ), Aonix и еще штук 5 таких же.
C>Они не распространены из-за того, что за них денег просят.
Посмотрю, спасибо.
C>>>Могу прислать whitepaper от Azul Systems, если интересно подробнее. G>>Аппаратная реализация GC мне, разумеется, интересна, но это не совсем то, что надо. C>Именно то — реальный способ сделать realtime-GC без потерь в скорости, Erlang OTP оно и не снилось. Те же техники можно сделать и программно — с заметными потерями быстродействия.
Плисуевину для GC и к Erlang/OTP можно добавить, я думаю, это будет не слишком дорого. Тока не нужно пока.
Здравствуйте, Gaperton, Вы писали:
G>Таблицы предсказания не будут большой проблемой, так как это реально важно в циклах. К тому же, таблицы сейчас реально большие — там сотни элементов точно, может быть даже тысяча. Предсказатель сейчас умеют делать очень хороший — у МИПСов которые 64 процент успешных предсказаний более 90%, что говорить о Core Duo.
У P4 был что-то около 99% процент успешных предсказаний на некоторых реальных программах. Еще шутки были, что P5 будет предсказывать результат программы еще до ее запуска.
Проблема в косвенном вызове может быть, если код не окажется в кэше, ну и длинные вызовы тоже более медленны. А еще проблемы с регистрами — в случае с inline'ингом компилятор может оптимизировать распределение для всего блока в целом.
Historical note: "Tri-color marking" is the term used to describe an algorithm developed in 1975 by E. W. Dijkstra and others, as an exercise in proving cooperating programs correct. They chose as their problem a parallel garbage collector, with the intent of illustrating cooperating sequential processes with a large shared data space but minimal exclusion and synchronization constraints.
C>>Так что лучше и меня иногда послушай G>С удовольствием слушаю, я на проводе.
Алло, алло! Кто там?
G>Более-менее нормально, если не считать, что до этого у них задержка достигала десятки секунд на серверах с большим объемом памяти, что было ни разу не нормально, и они задницу в кровь порвали, чтоб до полсекунды гарантии довести. Эту ссылку я также постараюсь найти.
Так можешь не искать, у нас задержка примерно в две минуты на сервере с 16Гб хипом после тюнингов. Что еще не так плохо, кстати. Нам это не так важно, так как неотзывчивый сервер у нас просто из кластера блокируется — Oracle Coherence рулит.
C>>Именно то — реальный способ сделать realtime-GC без потерь в скорости, Erlang OTP оно и не снилось. Те же техники можно сделать и программно — с заметными потерями быстродействия. G>Плисуевину для GC и к Erlang/OTP можно добавить, я думаю, это будет не слишком дорого. Тока не нужно пока.
Erlang'у оно пока будет даже вредно — быстрый GC ему просто по причине интерпретируемости нафиг не нужен. Вот когда добавят сильную типизацию и JIT — вот тогда будет веселее
Здравствуйте, Gaperton, Вы писали:
G>Я понимаю, о чем ты. Я про это читал уже давно — теоретически, у JIT больше информации для генерации оптимального кода, так как ему доступна статистика выполнения, чего нет у компилятора. Теоретически, возможно применять это знание для, скажем, выбора оптимальной схемы компиляции switch или множественных if. Также, JIT может генерировать специализированные версии функций для частных случаев, что радикально поправляет здоровье в случае динамики, как делает, например, Psyco.
Это действительно большей частью теория. А вот практика показывает другое — в JIT-платформах характерно все более широкое использование кодогенерации на ходу, что для нативных приложений редчайшая экзотика.
G>Короче, в теории можно много чего. Практически, однако, заметного преимущества пока нет — зато есть видимый глазу просос по времени отклика — неравномено оно (понятно, что здесь и GC оказывает влияние, дело не только и не столько в JIT)
Ты уж определись, проблема в "интерпретации" или все таки в GC? Первое и второе никак не связаны.
G>. Было бы очень интересно посмотреть на работы в этом направлении, демонстрирующие убедительное превосходство JIT перед статической компиляцией.
Решения со статическое компиляцией есть и для Java и для .NET. Только особого успеха они не имеют, несмотря на то, что, теоретически, нет никаких проблем сделать оптимизацию не хуже любого статического компилятора. Опять же, для .NET есть ngen.
G>Те-те-те. Без всяких проблем с откликом — это сильно сказано. Проблем нет, пока не идет речь хотя бы о мягком реальном времени.
А какой процент рынка софта имеет дело с реалтаймом? Ты ведь не говорил, что промежуточный код не годится конкретно для реалтайма, не так ли?
G>Лучший в индустрии коллектор, который дает soft-realtime, пока что в Erlang/OTP, и аналогов ему (пока) в индустрии нет. Он, может быть, и тормознее, чем сановский — все-таки stop-and-copy, зато обеспечивает великолепный и почти постоянный отклик, гораздо лучше явких GC.
Все зависит от задач. Для чего то важнее стабильность времени отклика, для чего то средние показатели.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
Здравствуйте, Cyberax, Вы писали:
G>>Прекомпиляция — это ведь опять не JIT, да? C>Это помощь JITу — оно потом может совершенно стандартным образом в runtime'е перекомпилироваться.
А в чём именно помощь? Там сохраняется какая-то полезная для него информация? Или просто у него будет относительно больше времени на старте и, соответственно, JIT может потратить его на более сложные алгоритмы оптимизации?
Здравствуйте, Delight, Вы писали:
C>>Это помощь JITу — оно потом может совершенно стандартным образом в runtime'е перекомпилироваться. D>А в чём именно помощь? Там сохраняется какая-то полезная для него информация? Или просто у него будет относительно больше времени на старте и, соответственно, JIT может потратить его на более сложные алгоритмы оптимизации?
Проблема в том, что при старте приложения — JIT в полном цейтноте, особенно для десктопных приложений. Нужно быстро запустить хоть что-то, так что просто не до оптимизаций.
Прекомпилированые библиотеки позволяют быстро запустить приложение с приемлимой скоростью, а потом уже вдумчиво все оптимизировать.
Здравствуйте, Gaperton, Вы писали:
G>>>Однако — все течет, все меняется, и я знаю что сейчас очень много усилий тратится на разработку эффективных инкрементальных mark-and-sweep коллекторов. Эти исследования рано или поздно принесут результат. C>>Хахаха. Трехцветный mark&sweep известен где-то с 70-х годов. Все основные изменения в нём уже сделаны, ускорить его сильнее — нельзя в принципе. Кроме того, у mark&sweep есть два фатальных недостатка: фрагментация кучи и зависимость времени работы от количества всех объектов (а не только живых как у stop-the-world).
G>Прежде чем ржать, подумай, может ты чего не понял. Я глупости редко пишу, я думаю ты знаешь, и это не тот случай. Потому, что этой темой я активно интересовался несколько лет назад. Дай поиск в гугле по словам incremental mark-and-sweep GC, поймешь, о чем я говорю. Речь не о скорости, не надо там ничего "ускорять". Речь об "инкрементальности" — гарантированной маленькой задержке на GC, чтобы его можно было прервать в любой момент, и хип остался в целостном состоянии. Это для mark-and-sweep — проблема. А вот для stop-and-copy делается довольно просто.
G>Вот скажем, в информационном письме IBM от 2003 года они с гордостью писали, что в новом релизе IBM JVM им удалось довести гаранированную задержку на GC до такой малой величины, как половина секунды.
Здравствуйте, AndrewVK, Вы писали: AVK>>>Как показывает практика native совсем не означает быстро работать G>>Есть примеры, когда JIT или интерпретатор обходит native? AVK>Есть конечно. МСовский .NET, например, практически всегда быстрее нативного Delphi.
А где можно посмотреть на тесты? (в дельфях есть возможность ассемблерных вставок прямо в основном коде)
Здравствуйте, AndrewVK, Вы писали:
_>>А где можно посмотреть на тесты? AVK>В инете. Здесь на сайте тоже статья была.
Ну, будет время — поищу.
Посмотрим на тесты вроде обработки DOM с десятками тысяч узлов и прочими "могильщиками" GC
_>> (в дельфях есть возможность ассемблерных вставок прямо в основном коде) AVK>И что? Это как то улучшает характеристики дельфового оптимизатора?
Качество оптимизатора в дискуссии не обсуждалось.
Исходный тезис (ваш) был такой: G>>Есть примеры, когда JIT или интерпретатор обходит native? AVK>Есть конечно. МСовский .NET, например, практически всегда быстрее нативного Delphi.
Здравствуйте, s_tarassov, Вы писали:
_>Посмотрим на тесты вроде обработки DOM с десятками тысяч узлов и прочими "могильщиками" GC
При чем тут GC? Речь о native vs JIT.
AVK>>И что? Это как то улучшает характеристики дельфового оптимизатора? _>Качество оптимизатора в дискуссии не обсуждалось.
Именно оно и обсуждалось. Если тебе очень пиписьками померяться захотелось, то на дотнете тоже можно mixed mode сборки делать с нативным кодом. Только о качестве JIT это никак не говорит.
Здравствуйте, AndrewVK, Вы писали:
_>>Посмотрим на тесты вроде обработки DOM с десятками тысяч узлов и прочими "могильщиками" GC AVK>При чем тут GC? Речь о native vs JIT.
При чем? Проведите тесты — узнаете.
AVK>>>И что? Это как то улучшает характеристики дельфового оптимизатора? _>>Качество оптимизатора в дискуссии не обсуждалось. AVK>Именно оно и обсуждалось. Если тебе очень пиписьками померяться захотелось, то на дотнете тоже можно mixed mode сборки делать с нативным кодом. Только о качестве JIT это никак не говорит.
На брудершафт, голубчик, мы с вами не пили.
Необходимость же native-вставок напрямую говорит о качестве JIT
Здравствуйте, s_tarassov, Вы писали:
AVK>>При чем тут GC? Речь о native vs JIT. _>При чем? Проведите тесты — узнаете.
Что мне даст проведение тестов? GC и JIT — разные вещи. Какой смысл нагружать GC для исследования производительности JIT?
AVK>>Именно оно и обсуждалось. Если тебе очень пиписьками померяться захотелось, то на дотнете тоже можно mixed mode сборки делать с нативным кодом. Только о качестве JIT это никак не говорит. _>На брудершафт, голубчик, мы с вами не пили.
Здесь так принято. (Достали)
_>Необходимость же native-вставок напрямую говорит о качестве JIT
Ага, а необходимость ассемблерного кода о крутости Дельфи. Тебе есть что по делу сказать, или пофлеймить захотелось?
Здравствуйте, AndrewVK, Вы писали:
AVK>>>При чем тут GC? Речь о native vs JIT. _>>При чем? Проведите тесты — узнаете. AVK>Что мне даст проведение тестов? GC и JIT — разные вещи. Какой смысл нагружать GC для исследования производительности JIT?
Речь изначально шла о native Delphi vs .NET JIT. Вот такая речь (третий раз) G>>Есть примеры, когда JIT или интерпретатор обходит native? AVK>Есть конечно. МСовский .NET, например, практически всегда быстрее нативного Delphi.
Пример с десятками тысяч недолгоживущих объектов показывает одну из ситуаций, когда это не так.
И ситуаций таких можно предложить немало. Например, если вспомнить immutable у строк. Или отрисовку окошек.
_>>Необходимость же native-вставок напрямую говорит о качестве JIT AVK>Ага, а необходимость ассемблерного кода о крутости Дельфи.
Ассемблерные вставки находятся в рамках native в отличие от.
Здравствуйте, s_tarassov, Вы писали:
AVK>>Что мне даст проведение тестов? GC и JIT — разные вещи. Какой смысл нагружать GC для исследования производительности JIT? _>Речь изначально шла о native Delphi vs .NET JIT. Вот такая речь (третий раз)
Да, речь шла о native vs JIT. Так вот, в большинстве случаев нетовский JIT генерит более качественный код, нежели native компилятор Дельфи. Что тут еще может быть непонятного?
_>Пример с десятками тысяч недолгоживущих объектов показывает одну из ситуаций, когда это не так.
Если в программе куча мелких быстро умирающих объектов в динамической памяти, то GC сделает любой самый навороченный менеджер памяти. Только, опять же, к разговору native vs JIT это не имеет никакого отношения, потому что и JIT может быть без GC, и GC может быть без JIT.
_>И ситуаций таких можно предложить немало. Например, если вспомнить immutable у строк. Или отрисовку окошек.
Да, вот уж immutable у строк и отрисовка окошек, это самый главный недостаток JIT. К твоему сведению, в дотнете есть и mutable строки, и окошки в винформсах отрисовываются в основном операционкой.
AVK>>Ага, а необходимость ассемблерного кода о крутости Дельфи. _>Ассемблерные вставки находятся в рамках native в отличие от.
Здравствуйте, AndrewVK, Вы писали:
AVK>>>Что мне даст проведение тестов? GC и JIT — разные вещи. Какой смысл нагружать GC для исследования производительности JIT? _>>Речь изначально шла о native Delphi vs .NET JIT. Вот такая речь (третий раз) AVK>Да, речь шла о native vs JIT. Так вот, в большинстве случаев нетовский JIT генерит более качественный код, нежели native компилятор Дельфи. Что тут еще может быть непонятного?
Это уже смешно просто )))) AVK>Есть конечно. МСовский .NET, например, практически всегда быстрее нативного Delphi.
Твой базар?
Теперь у тебя появилась новая формулировка: более качественный код
Критерии качества и тесты в студию. Трепать языком — не камни ворочать.
Тесты пионеров в трех сериях "Кто шустрее", найденные на сайте просьба не предъявлять.
_>>Пример с десятками тысяч недолгоживущих объектов показывает одну из ситуаций, когда это не так. AVK>Если в программе куча мелких быстро умирающих объектов в динамической памяти, то GC сделает любой самый навороченный менеджер памяти. Только, опять же, к разговору native vs JIT это не имеет никакого отношения, потому что и JIT может быть без GC, и GC может быть без JIT.
Он имеет отношение к конкретному обсуждаемому JIT. А во-вторых ты опять сказал ерунду, не удосужившись провести хотя бы элементарные тесты.
Все бывай, голубчик. Без дальнейшей конкретики я с тобой базарить завязал.
Здравствуйте, s_tarassov, Вы писали:
AVK>>Да, речь шла о native vs JIT. Так вот, в большинстве случаев нетовский JIT генерит более качественный код, нежели native компилятор Дельфи. Что тут еще может быть непонятного? _>Это уже смешно просто ))))
Это факт
AVK>>Есть конечно. МСовский .NET, например, практически всегда быстрее нативного Delphi. _>Твой базар? _>Теперь у тебя появилась новая формулировка: более качественный код _>Критерии качества и тесты в студию. Трепать языком — не камни ворочать.
Где тесты искать я тебе сказал.
_>Тесты пионеров в трех сериях "Кто шустрее", найденные на сайте просьба не предъявлять.
Пока что, судя по высказываниям, пионер здесь ты.
AVK>>Если в программе куча мелких быстро умирающих объектов в динамической памяти, то GC сделает любой самый навороченный менеджер памяти. Только, опять же, к разговору native vs JIT это не имеет никакого отношения, потому что и JIT может быть без GC, и GC может быть без JIT. _>Он имеет отношение к конкретному обсуждаемому JIT.
Читайте топик с начала.
_>Все бывай, голубчик. Без дальнейшей конкретики я с тобой базарить завязал.
Здравствуйте, GlebZ, Вы писали:
G>>Это верная постановка вопроса. Я говорил не про GC и не про компиящийся в нэйтив лисп, а про JIT и итерпретаторы. GZ>А при чем тут интерпретаторы? JIT — это компилятор.
А это такой подход в дискуссии. Ставим в один ряд, скажем, космонавтов и педераст... конечно между ними никакой корелляции нет, но ведь осадочек то остался!
Та же фигня с JIT и интерпретаторами. Если долго ставить их в общий ряд, то моногие подумают, что связь есть.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Очередные проблемы с логикой? Или на этот раз непонимание разницы в понятиях interoperability и full compatibility?
У тебя Янус смайлы не показывает? Или просто побухтеть охота?
Расскажи, что ты понимаешь под full compatibility применительно к языкам программирования. Очень интересно.
now playing: Boris Brejcha — Electribe Technologie
Здравствуйте, Gaperton, Вы писали:
G>Этот оффтоп я развел к тому, чтобы наглядно показать, что деньги и прочего рода взятки не являются определяющим фактором для развития мотивации.
Вот только не показал ты ничего. Спонсируй разработку (хватит где-то .5 мегабакса) и я тебе покажу, что ты не прав.
G>Я уверен что при желании сделать деньги на RSDN и наличии организованности внутри команды у вас бы все получилось — дело скорее в том, что у вас это никому нахрен не надо, и это первично, а не деньги. То есть дело не в деньгах, а в желании.
RSDN является RSDN-ном не в малой степени потому, что из него не делают коммерческий проект. Ты вот тоже на чем-то деньги делаешь, но боюсь, что они очень небольшие. По крайней мере на команду из 20 человек вряд ли хватет.
G>Вот я вам, например, предлагал купить лицензию на движок вашего форума.
Ну, и куда ты делся после первого вопроса?
G>И не только я.
Что-то про именно купить я больше предложений не слышал. Ну, одно еще разве что.
G>Выяснилось, что сделать это невозможно, и всем похрен.
Это мягко говоря не правда. Просто ради одной-двух продаж никто коммерческий проект делать не будет.
G> При этом, вы жалуетесь на недостаток ресурсов для развития сайта,
Где? Мы не жалуемся.
G>продавать его не хотите, но и в open source вы ни под какой лицензией его класть тоже не хотите — хотя могли бы выложить его под двойной лицензией — GPL + коммерческая.
Слушай, давай ты будешь нас учить деньги зарабатывать когда заработаешь первый миллион баксов. ОК? И все же не в этом форуме.
G>Короче, Влад, мне кажется, деньги вам не нужны. И в контексте ситуации вокруг Немерле — это скорее плохо, чем хорошо. Потому, что ваша мотивация не сфокусирована и в большей части определяется сиюминутными интересами учатсников. Хочу подчеркнуть — это мое впечатление, я не собираюсь его никому навязывать и не хочу никого обидеть или обвинять в чем-то. Я в данный момент стараюсь быть честным.
Мне откровенно говоря нечего добавить. Повторюсь еще раз и замнем этот вопрос.
На доводку Немерла до состояния полного конкурента скажем C# нужно не менее $500 000 и год времени. Денег этих у меня нет. Спонсоров тоже на горизонте нет. Хейльберг просто тупо панически боится таких мощьных вещей как макросов. Так боится, что даже посмотреть на Немерле не захотил.
Так вот... Если найдутся спонсоры, то я тебе гарантирую, что дни C# будут сочтены. Не найдутся, мы будет продолжать развитие языка в меру своих сил.
G>>>С этим я безусловно согласен. Немерле — это отличный опыт, практически доказывающий, что возможно мягкое введение концепций ФП в мэйнстримовые языки. Примерно, как это было сделано с С, С++, и ООП. Важность Немерле с этой точки зрения сложно переоценить.
VD>>В общем, то концепции ООП он тоже туда вводит. Тут он конечно не один. Есть скала, да и Шарп подтягивается. Но лично мне ждать пока МС или Сан дорастут скажем до паттер-матчинга или сделает чтобы все стрэйтменты можно было в выражениях использовать я не хочу. Боюсь, что столько не проживу.
G>Думаю, кстати, проживешь. Ведь МС зачем-то взял разработчиков Немерле на работу — это не просто так. Языки типа Немерле и Scala являются источником вдохновения для разработчиков C#. Это по сути исследовательские языки, на которых проходят апробацию новые концепции. Единственное — у них есть понятие learning curve. Однако, они теперь могут запускать и параллельные ветки — F# же они включили в список поддерживаемых языков. Я уверен, что Немерле гораздо лучше F# приспособлен к современным реалиям, потому что это не калька с известного языка, а творческая и удачная переработка. По своей значимости он похож на С++ — обеспечивает мягкое введение в новый мир. Однако, без поддержки майкрософта — здесь мне кажется мало что может произойти.
G>То есть, сценария у нас три, и они не являются взаимоисключающими. G>1) Один из поддерживаемых языков платформы С# или F# приобретает наиболее удачные свойства Немерле, приближаясь к нему. G>2) Немерле с некоторыми модификациями становится одним из официальных языков платформы .NET G>3) Про Немерле все забывают. R.I.P.
G>При данном раскладе — я бы просто подождал, что произойдет дальше. А на вашем месте — попытался бы получить финансирование данных работ от Microsoft Research, как они делали с F#. Если вы, конечно, серьезно настроены. Возможно, у вас есть другой план действий — так озвучте его, чтобы народ успокоить, вдохновить, и вселить в их сердца надежду. А пока — как очень метко сказал GlebZ, ваш шкаф зело похож на гроб, а его ручка — на красивую ошибку природы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Gaperton, Вы писали:
G>То есть, сценария у нас три, и они не являются взаимоисключающими. G>1) Один из поддерживаемых языков платформы С# или F# приобретает наиболее удачные свойства Немерле, приближаясь к нему.
F# никогда не будет мыэйнстримом. Ну, разве что Хаскель переплюнет.
С# уже получил огромный пинок в перед. Думаю и дальше будет развиваться. Жаль в нем исходно много ошибок из-за идеологического родстава с С.
G>2) Немерле с некоторыми модификациями становится одним из официальных языков платформы .NET G>3) Про Немерле все забывают. R.I.P.
Есть еще 4. Будет постепенно развиваться и станет языком для тех кто не так богат чтобы писать на С++ (т.е. годами и с мылом на заднице), но не так глуп чтобы пытаться забороть индокодеров шапкозакидательством.
G>При данном раскладе — я бы просто подождал, что произойдет дальше. А на вашем месте — попытался бы получить финансирование данных работ от Microsoft Research, как они делали с F#. Если вы, конечно, серьезно настроены. Возможно, у вас есть другой план действий — так озвучте его, чтобы народ успокоить, вдохновить, и вселить в их сердца надежду. А пока — как очень метко сказал GlebZ, ваш шкаф зело похож на гроб, а его ручка — на красивую ошибку природы.
Если у меня будут возможности найти деньги, то я конечно их постараюсь не упустить. Об остальном я уже писал.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, AndrewVK, Вы писали:
AVK>>А native совершенно не обязателен, как показывает практика. Впрочем, mono --aot и флаг вам в руки
VD>Смешно слышать пдобные слова от того кто постоянно пропагандирует интерпретирвемые языки вроде Эрлэнга.
AVK пропагандирует интерпретируемые языки, вроде Эрланга? Добро пожаловать в клуб, AVK!
G>JIT-компилятор Java на моно, транслирующий java байт-код в CLR? Интересный подход. G>1) А как у нас, интересно, будет выглядеть интероп с каким-нибудь Java Application Server, где своя VM? Подмена VM не всегда канает. G>2) Крайне любопытно, правда — неужели там сборщик мусора научился подбирать неиспользуемые Java классы, и у нас будет реально работать свой classloader (гранулярность загрузки/выгрузки — класс)? Что-то сомневаюсь — не умел такого делать CLR by design. А без этой штуки application-сервера и Java приложения с активным скриптингом в продакшне лучше не пускать. А это весьма приятное свойство Java, одно из его основных отличий от .NET.
В дотнете всякие компилируемые скрипты обычно в temporary-доменах гоняют.
G>Так что такие разговоры — скорее умный маркетинговый ход. Когда увижу, что джит убедительно обойдет IC++ на приложениях вроде SPEC — тогда можно будет отнестись к тому серьезно. Я думаю, так.
Не обойдёт никогда. Я плотно занимаюсь процессингом сигналов, так вот, .Net сливает заметно. ИМХО, основная причина слива — это постоянная проверка выхода за границы массива. Т.к. вся обработка сигналов — это переливание из буферов в буфера с обработкой, учитывая, что математическая составляющая обработки тривиальна, и не может быть сильно загублена JIT-ом, то вот в этих проверках выхода за пределы и кроется главный тормоз.
Относительно динамической памяти и задержек GC для таких приложух не критично, т.к. приложения подобного рода обычно оперируют буферами статического характера (т.е. перераспределение памяти происходит в крайнем случае, в устоявшемся режиме не происходит вообще).
Кстати, я в курсе про оптимизацию проверки выхода за границу, но прикол в том, что кол-во элементов в буфере, подлежащих обработке, не всегда соответствует размеру буфера, т.е. хранится в доп. переменной, что делает невозможной подобную оптимизацию.
K>Мне внутренний голос подсказывает, что за этим майевтическим вопросом последует целый квазиплатоновский диалог, в ходе которого сначала мы придем к выводу о том, что лучше было бы представлять AST в синтаксисах разной степени легковесности, а потом перейдем к обсуждению SymADE. Я правильно догадался?
Офигеть, спасибо за упоминание интересного проекта. Еще лет 5 назад с одним известным здесь товарищем пришли к выводу, что программирование должно уходить от конкретных типов в сторону параметризации, от текстового представления в сторону некоего семантического графа. Существовавшая на тот момент Флора была слишком далека от желаемого. Наконец, кто-то решил начать всерьёз.
Здравствуйте, vdimas, Вы писали:
V>Кстати, я в курсе про оптимизацию проверки выхода за границу, но прикол в том, что кол-во элементов в буфере, подлежащих обработке, не всегда соответствует размеру буфера, т.е. хранится в доп. переменной, что делает невозможной подобную оптимизацию.
Не делает невозможным, а затрудняет. Теоретически JIT вполне может определить, что эта самая переменная внутри цикла не меняется, следовательно можно не проверять каждую итерацию.
... << RSDN@Home 1.2.0 alpha 2 rev. 857 on Windows Vista 6.0.6001.65536>>
Здравствуйте, vdimas, Вы писали:
V>Офигеть, спасибо за упоминание интересного проекта. Еще лет 5 назад с одним известным здесь товарищем пришли к выводу, что программирование должно уходить от конкретных типов в сторону параметризации, от текстового представления в сторону некоего семантического графа.
Эта "гениальная" мысль приходит в голову почти всем программерам поначалу.
... << RSDN@Home 1.2.0 alpha 2 rev. 857 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Эта "гениальная" мысль приходит в голову почти всем программерам поначалу.
Во-во... только если еще немного подумать понимаешь что текст + IDE которая все парсит на лету заруливают все эти семантические графы на раз.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Gaperton, Вы писали:
G>>JIT-компилятор Java на моно, транслирующий java байт-код в CLR? Интересный подход. G>>1) А как у нас, интересно, будет выглядеть интероп с каким-нибудь Java Application Server, где своя VM? Подмена VM не всегда канает. G>>2) Крайне любопытно, правда — неужели там сборщик мусора научился подбирать неиспользуемые Java классы, и у нас будет реально работать свой classloader (гранулярность загрузки/выгрузки — класс)? Что-то сомневаюсь — не умел такого делать CLR by design. А без этой штуки application-сервера и Java приложения с активным скриптингом в продакшне лучше не пускать. А это весьма приятное свойство Java, одно из его основных отличий от .NET.
V>В дотнете всякие компилируемые скрипты обычно в temporary-доменах гоняют.
Я это знаю. А в Java — нет, там можно любой класс подгрузить в динамике. Чем активно пользуются все приложения, которые используют скриптинг. Я бы с удовольствием посмотрел, как такое приложение заработает на .NET-машине. Взять, скажем, веб-браузер какой-нибудь.
Уж не говоря о том, что при отдельном домене мы налетаем на маршалинг данных, что для многих сценариев скриптинга очень дорого.
G>Я это знаю. А в Java — нет, там можно любой класс подгрузить в динамике. Чем активно пользуются все приложения, которые используют скриптинг. Я бы с удовольствием посмотрел, как такое приложение заработает на .NET-машине. Взять, скажем, веб-браузер какой-нибудь.
Так и заработает, в отдельном домене. Это в любом случае есть гут, хотя бы из соображений безопасности. Доменная система .Net очень плотно завязана на ту самую безопасность, до которой Джаве еще плыть и плыть. До недавнего времени Джава вообще представляла собой одну сплошную дыру.
G>Уж не говоря о том, что при отдельном домене мы налетаем на маршалинг данных, что для многих сценариев скриптинга очень дорого.
Хе, мы на маршаллинг в любом случае налетаем, т.к. обработка GUI-событий и исполнение скриптов идут в разных тредах. А "внутри" скопиллированного скрипта зачем маршаллинг?
V>>Кстати, я в курсе про оптимизацию проверки выхода за границу, но прикол в том, что кол-во элементов в буфере, подлежащих обработке, не всегда соответствует размеру буфера, т.е. хранится в доп. переменной, что делает невозможной подобную оптимизацию.
AVK>Не делает невозможным, а затрудняет. Теоретически JIT вполне может определить, что эта самая переменная внутри цикла не меняется, следовательно можно не проверять каждую итерацию.
Мы экспериментировали с этим, из поля класса копировали значение в локальную переменную, с которой и сравнивали счётчик цикла — практически никаких результатов, т.е. современный runtime к этому не готов, к сожалению. И такая ситуация, насколько я понимаю, продлится как минимум до 4.0, и то неизвестно как подобный момент будет решён. А он, вообще-то, краеугольный в плане быстродействия. Всё, что не касается доступа к массивам, JIT компиллирует вполне оптимально, и только этот момент мешает делать на дотнете адекватные "числодробилки".
V>>Офигеть, спасибо за упоминание интересного проекта. Еще лет 5 назад с одним известным здесь товарищем пришли к выводу, что программирование должно уходить от конкретных типов в сторону параметризации, от текстового представления в сторону некоего семантического графа.
AVK>Эта "гениальная" мысль приходит в голову почти всем программерам поначалу.
Ну... после 12-тилетнего опыта (на тот момент) и двух десятков используемых языков — это мало похоже на начало. Оно приходит, когда надоедает чувство постоянного дежавю. Причём, не только в своей работе. Одно время я плотно проходился по исходникам всякого опен сорса — не мог избавиться от ощущения, что все делают одно и то же, различия лишь на самом высоком уровне и составляют дай бог 10-20 процентов от общих трудозатрат (а то и меньше). Остальной объем — очень общего плана и слишком похож, даже в проектах на разных языках.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, AndrewVK, Вы писали:
AVK>>Эта "гениальная" мысль приходит в голову почти всем программерам поначалу. WH>Во-во... только если еще немного подумать понимаешь что текст + IDE которая все парсит на лету заруливают все эти семантические графы на раз.
Это ты как определил? Тебе уже было с чем сравнить?
Я вот даже с самым крутым IDE не могу избавиться от ощущения постоянной обезъяней работы, причём везде, начиная от проектирования, и заканчивая кодированием.
Здравствуйте, vdimas, Вы писали:
V>Ну... после 12-тилетнего опыта (на тот момент) и двух десятков используемых языков — это мало похоже на начало.
Человек не машина, у него разброс параметров очень широкий, так что всяко бывает.
V> Оно приходит, когда надоедает чувство постоянного дежавю.
А у меня вот нет такого постоянного чувства. Что я делаю не так?
V>Одно время я плотно проходился по исходникам всякого опен сорса — не мог избавиться от ощущения, что все делают одно и то же, различия лишь на самом высоком уровне и составляют дай бог 10-20 процентов от общих трудозатрат (а то и меньше).
И при чем здесь текстовая форма представления исходников?
... << RSDN@Home 1.2.0 alpha 2 rev. 872 on Windows Vista 6.0.6001.65536>>
Здравствуйте, vdimas, Вы писали:
V>Это ты как определил? Тебе уже было с чем сравнить?
А ты думаешь что такого еще ни разу реализовано не было? Сразу, навскидку — смоллток, GuptaSQL.
V>Я вот даже с самым крутым IDE не могу избавиться от ощущения постоянной обезъяней работы, причём везде, начиная от проектирования, и заканчивая кодированием.
И в этом, конечно, виноваты текстовые исходники. Что то я мысль не уловил.
... << RSDN@Home 1.2.0 alpha 2 rev. 872 on Windows Vista 6.0.6001.65536>>
V>>Я вот даже с самым крутым IDE не могу избавиться от ощущения постоянной обезъяней работы, причём везде, начиная от проектирования, и заканчивая кодированием.
AVK>И в этом, конечно, виноваты текстовые исходники. Что то я мысль не уловил.
Виновата в этом однообразная работа по реализации похожих решений, особенно на среднем уровне реализации. Суть моего недовольства в том, что на существующем инструментарии невозможно достаточно хорошо повторно использовать код, т.е. написание некоей мега-либы — это утопия при нынешнем раскладе. Вот и хочется взамен библиотек кода иметь параметризуемые библиотеки идей/шаблонов. (Rational и прочее смотрю регулярно)
V>> Оно приходит, когда надоедает чувство постоянного дежавю.
AVK>А у меня вот нет такого постоянного чувства. Что я делаю не так?
Ну, может умеешь забывать детали прошлых проектов.
V>>Одно время я плотно проходился по исходникам всякого опен сорса — не мог избавиться от ощущения, что все делают одно и то же, различия лишь на самом высоком уровне и составляют дай бог 10-20 процентов от общих трудозатрат (а то и меньше).
AVK>И при чем здесь текстовая форма представления исходников?
При том, что эта форма наименее параметризуема/модифицируема. Прктически никогда не годится для повторного использования.
Здравствуйте, vdimas, Вы писали:
V>Суть моего недовольства в том, что на существующем инструментарии невозможно достаточно хорошо повторно использовать код, т.е. написание некоей мега-либы — это утопия при нынешнем раскладе.
Это все понятно, идеал недостижим. Но я все еще про текст vs бинарное AST.
V> Вот и хочется взамен библиотек кода иметь параметризуемые библиотеки идей/шаблонов. (Rational и прочее смотрю регулярно)
Все это здорово, но шаблоны это именно идея. Может быть библиотека, помогающая реализовать тот или иной шаблон, инструментарий, образцовый код наконец. Но не может быть библиотеки шаблонов, потому что если такую библиотеку можно написать, то это уже не шаблон проектирования. Ну и главное — совершенно неясно, как все это связано с обсуждаемой идеей.
... << RSDN@Home 1.2.0 alpha 2 rev. 872 on Windows Vista 6.0.6001.65536>>
Здравствуйте, vdimas, Вы писали:
AVK>>А у меня вот нет такого постоянного чувства. Что я делаю не так?
V>Ну, может умеешь забывать детали прошлых проектов.
Скорее научился видеть за деревьями лес.
AVK>>И при чем здесь текстовая форма представления исходников?
V>При том, что эта форма наименее параметризуема/модифицируема.
А вот это неплохо бы и аргументировать. Лично для меня объем трудозатрат по написанию парсера языка средней сложности скорее даже меньше, чем написание своего формата хранения AST (с описанием! устойчивого к небольшим сбоям!) + даже минимальный набор тулзов по его редактированию.
V> Прктически никогда не годится для повторного использования.
А тут вообще непонятно с какой стати.
... << RSDN@Home 1.2.0 alpha 2 rev. 872 on Windows Vista 6.0.6001.65536>>
Предположу, что характер твоей работы изменился со временем, и это может быть связано с кол-вом человек в проекте. Мне же приходится много кодить, не только проектировать.
AVK>>>И при чем здесь текстовая форма представления исходников?
V>>При том, что эта форма наименее параметризуема/модифицируема.
AVK>А вот это неплохо бы и аргументировать. Лично для меня объем трудозатрат по написанию парсера языка средней сложности скорее даже меньше, чем написание своего формата хранения AST (с описанием! устойчивого к небольшим сбоям!) + даже минимальный набор тулзов по его редактированию.
Понятное дело, что общее решение куда как сложнее в разработке. И речь не идёт о синтаксическом дереве, скорее о семантическом. Да, задача сложная, и сложность её в первую очередь в формулировке. Тем не менее, проекты на эту тему создаются регулярно, т.е. народ чувствует такую потребность. Наверно просто обобщение задач не достигло должного уровня.
V>> Прктически никогда не годится для повторного использования.
AVK>А тут вообще непонятно с какой стати.
Например, непригодны для решения аналогичных задач на других языках/платформах, или даже в рамках одного языка/платформы, но с другими типами параметров. Банальные ограничения на арифметические операции в генериках обсуждали уже многократно. Динамические и при этом функциональные языки отвечают части требований, но за это приходится платить серьёзным проседанием эффективности.
Здравствуйте, vdimas, Вы писали:
AVK>>Скорее научился видеть за деревьями лес.
V>Предположу, что характер твоей работы изменился со временем
Естественно. Думаю, это так для 90% здесь присутствующих.
V>, и это может быть связано с кол-вом человек в проекте.
Нет, не связано.
V> Мне же приходится много кодить, не только проектировать.
Мне тоже. Причем иногда то, что сам и спроектирвал. В результате чего я в состоянии оценить общий объем трудозатрат (тот самый лес).
V>Понятное дело, что общее решение куда как сложнее в разработке. И речь не идёт о синтаксическом дереве, скорее о семантическом.
Семантическое дерево уже сейчас присутствует в дотнетной сборке практически в полном объеме. Только наличие такого дерева не устраняет необходимости в исходниках.
V>Тем не менее, проекты на эту тему создаются регулярно
Ага. Я об этом с самого начала и говорил.
V>Наверно просто обобщение задач не достигло должного уровня.
А мне лично кажется, что сама идея не очень, и порождается она чаще всего (ИМХО) слабеньким бекграундом в CS.
AVK>>А тут вообще непонятно с какой стати.
V>Например, непригодны для решения аналогичных задач на других языках/платформах,
А тут все технические моменты уже есть. Ну то есть совместимость по AS(yntactic)T разных языков — чушь, а совместимость по некоей прослойке между фронтендом и бекендом уже имеется в дотнете и джаве (и даже в gcc), но это, естественно, требует бинарной совместимости по формату этой самой прослойки. Совместимость круче этой таки тоже можно представить — да-да, тот самый текстовый формат .
V>Банальные ограничения на арифметические операции в генериках обсуждали уже многократно.
А универсальное решение, которое вообще никакиз ограничений не накладывает это несбыточный миф. Хуже того, чем универсальнее такое решение, тем меньше от него практической пользы.
V> Динамические и при этом функциональные языки отвечают части требований, но за это приходится платить серьёзным проседанием эффективности.
Вот вот. Только это не потому что решения плохие, а их авторы безрукие, это фундаментальный момент.
... << RSDN@Home 1.2.0 alpha 2 rev. 872 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Все это здорово, но шаблоны это именно идея. Может быть библиотека, помогающая реализовать тот или иной шаблон, инструментарий, образцовый код наконец. Но не может быть библиотеки шаблонов, потому что если такую библиотеку можно написать, то это уже не шаблон проектирования.
Шаблон или нет это вопрос филосовский но то что такие библиотеки прекрасно пишутся на томже немерле факт.
AVK>Ну и главное — совершенно неясно, как все это связано с обсуждаемой идеей.
+1
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Шаблон или нет это вопрос филосовский
Вопрос самый что ни на есть практический. Шаблон, он не зря шаблон проектирования.
WH> но то что такие библиотеки прекрасно пишутся на томже немерле факт.
Какие такие? Еще раз — ты можешь написать макрос, упрощающий кодирование некоторой задачи с использованием шаблона ХХХ. Или даже встроить такую фичу в язык. Но макрос от этого шаблоном проектирования не станет. Шаблон это кирпичик дизайна, сущность в высшей степени виртуальная, идея, облаченная в некое полуформальное описание. Ну примерно как кодекс строителя коммунизма.
... << RSDN@Home 1.2.0 alpha 2 rev. 872 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Niovol, Вы писали:
N>Вот хотел спросить совета, лучше пытаться переходить на какой-нибудь другой язык или оставаться программировать на с++?
В общем, по совокупности флейма ты уже все понял: языки — фуфло, алгоритмы с математикой — рулят. И не надо меня убеждать, что есть математики, которые пишут говённый код — бывают такие, но они при этом и математики тоже говённые. А уж язык — C++ или C# или Java — это дело десятое, не стоящее даже обсуждения. Ни одна конкретная программа ни на одном конкретном языке не живет достаточно долго. А вот, скажем, алгоритм поиска маршрута имени Дейксты будет жить вечно. Я не призываю все щас бросить и начать изобретать гениальные алгоритмы — это невозможно, да и не нужно. Но вот изучать алгоритмы — это первейшая задача человека, считающего себя программистом. А языки — это дело наживное.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, Gaperton, Вы писали:
G>Уписаться. Думал, не доживу . Годик-другой назад многие с удивлением спрашивали, почему тут кое-кто (в числе которых был и я) отказывается стартовать промышленные проекты на Немерле. Я говорил, что ни за что не стартую такой проект, что вызывало возмущение прогрессивной общественности.
Я, конечно, понимаю твой цинизм. Но ведь ты же откровенно злорадствуешь — это некрасиво. Мне искренне жаль, что основные разработчики Немерле потеряли мотивацию. Без них проект обречен, увы — это просто такой жизненный факт, с которым не имеет смысла спорить.
Конечно же, ты злословишь по поводу бывших восторгов товарищей VladD2, Wolfhound и прочих, которые пели дифирамбы языку. Я это понимаю. Но я сейчас на их стороне. Ибо если хотя-бы один из тысячи вот таких вот жизнерадостных придурков (включая и меня, конечно же), выдаст хоть одну ценную мысль для развития — это уже будет оправданием для существования всех их (и меня тоже). А ты ведешь себя как патентное бюро в IXX веке — все что можно было изобрести уже изобретено, поэтому все заявки отправляются обратно с пометкой "отказать".
В общем, не надо злословить на поминках. Это нехорошо.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, Klapaucius, Вы писали:
K>Вообще, "мощность языка" понятие довольно невнятное, для которого у каждого может быть свое интуитивное понимание.
Не спорь, Klapaucius. Самый мощный язык — это язык математики. Все компьютерные языки — суть жалкие производные.
Офтоп — меня удивляет диссонанс. Сейчас на компьютере надо очень-очень постараться, чтобы написать статью с формулами. Надо как минимум изучать LaTeX. А раньше? — во времена Энштейна — сдавали рукописи! Эти, блин, издательства — совсем обнаглели, у меня потребовали рисунок в PDF!!! А где я его возьму в PDF, если я его на листочке от руки нарисовал?! — у них там что, нет чертежника? Раньше было принято в научных журналах перечерчивать все рисунки и графики и присылать их на согласование с авторами. А сейчас им PDF подавай, блин. А где я его возьму, если у меня есть только на листочке?!
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
MS>>В общем, по совокупности флейма ты уже все понял: языки — фуфло, алгоритмы с математикой — рулят. AVK>Это в твоей сфере интересов. А в других случаях может быть с точностью до наоборот.
Искренне не понимаю, как в профессии программиста может быть что-то важнее алгоритмов. Алгоритмы — это основа. Это как арифметика. Уж извини — если человек базовых алгоритмов не знает, то это не программист. Может быть быдлокодер или говнокодер. Но базовый набор алгоритмов — это просто некий минимум, примерно так же как физминимум Ландау. Короче, я чувствую мне пора браться за дело. По алгоритмам. Понимашь-ли, когда человек спрашивает — что важнее, C++ или C# — мне хочется дать ему по морде и наставить на путь истинный. И ответить — изучай Фортран, родной.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, Klapaucius, Вы писали:
K>3) Синтаксическое — возникает при больших значениях числа Губанова.
В этом месте пролил сок на клавиатуру! Блин, опять ноут разбирать.
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, Gaperton, Вы писали:
G>>Уписаться. Думал, не доживу . Годик-другой назад многие с удивлением спрашивали, почему тут кое-кто (в числе которых был и я) отказывается стартовать промышленные проекты на Немерле. Я говорил, что ни за что не стартую такой проект, что вызывало возмущение прогрессивной общественности.
MS>Конечно же, ты злословишь по поводу бывших восторгов товарищей VladD2, Wolfhound и прочих, которые пели дифирамбы языку. Я это понимаю. Но я сейчас на их стороне. Ибо если хотя-бы один из тысячи вот таких вот жизнерадостных придурков (включая и меня, конечно же), выдаст хоть одну ценную мысль для развития — это уже будет оправданием для существования всех их (и меня тоже). А ты ведешь себя как патентное бюро в IXX веке — все что можно было изобрести уже изобретено, поэтому все заявки отправляются обратно с пометкой "отказать".
Имхо, Gaperton вообще ничего не говорил о самом языке (как о наборе синтаксических и семантических правил) и идеях, заложенных в нем. Без вопросов, язык хороший и многообещающий, особенно макросистема — я был бы счастлив ее иметь в С++.
Gaperton говорил именно о промышленном применении языка (выделено), и здесь его точка зрения очень сильна, потому что фирмам, принимая решение об использовании той или иной технологии, необходимо в первую очередь оценить сопутствующие риски, в том числе, для молодых технологий, риск ее внезапной смерти (например, в виде утери мотивации основных разработчиков языка). И это проблема не тольно Немерле. Например, в некоторых больших фирмах запрещено использовать Ruby в business-critical applications, поскольку, каким бы Ruby ни был хорошим, совершенно неясно будущее языка, нет нормальной поддержки, нет прописанного roadmap-а развития языка, и очень высок риск его смерти. Короче, то, что входит в понятие mature (зрелость технологии?). Так что какие-нть мелкие скрипты, которые можно при случае быстро переписать на каком-нть перле, можно, но ничего, что могло бы ударить по бизнесу в случае смерти технологии — ни-ни.
Очень разумная позиция.
Сам посуди — вот ты пишешь на таком супер-языке, мотивация к поддержке которого утрачена, а потом раз — и напарываешься на баг в компиляторе — и чего? Подождать следующей версии — а будет ли она, следующая версия? Потребовать hotfix — у кого потребовать? А у тебя эта программа качает миллион баксов ежедневно. Такие программы на высокорисковых языках никто писать не будет. Новый язык сейчас может быстро пролезть в промышленное программирование только если у него сразу есть хорошая поддержка (например, в виде Microsoft или Sun, или в виде огромного community).
Здравствуйте, AndrewVK, Вы писали:
AVK>Не делает невозможным, а затрудняет. Теоретически JIT вполне может определить, что эта самая переменная внутри цикла не меняется, следовательно можно не проверять каждую итерацию.
Ну Андрей, ну я об этом уже писал года два назад.
Теоретически все можно. "Дот-нет — это все можно отимизировать..." (конец цитаты)
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, Niovol, Вы писали:
N>>Вот хотел спросить совета, лучше пытаться переходить на какой-нибудь другой язык или оставаться программировать на с++?
MS>В общем, по совокупности флейма ты уже все понял: языки — фуфло, алгоритмы с математикой — рулят.
+1
MS>И не надо меня убеждать, что есть математики, которые пишут говённый код — бывают такие, но они при этом и математики тоже говённые.
-1
Доводилось видеть хороших математиков, которые не программировали (толи не умели, толи учиться не хотелось); хороших математиков, которые очень здорово программировали; хороших математиков, которые плохо программировали. А так же хороших программистов, плохо знающих математику.
MS>А уж язык — C++ или C# или Java — это дело десятое, не стоящее даже обсуждения.
+1
MS>Но вот изучать алгоритмы — это первейшая задача человека, считающего себя программистом.
Э... Мне вот почему-то кажется, что алгоритмы -- это такая специфическая часть математики, понять которую можно без особого математического склада ума. А вот некоторые разделы математики, которые касаются дифференциального исчисления, интегрирования, комплексных чисел и какой-то там соответствующей теории функций и пр. -- тут далеко не все так просто, как с алгоритмами. Но это так же математика. И я видел математиков, которые решали какую-то задачу, связанную с трением и износостойкостью, где был какой-то хитрый несобственный (вроде так он назывался) интеграл с неким проблемным ядром. Нужно было им находить какие-то функции для этого ядра, при которых интеграл оказывался определенным и решаемым. Они лихо оперировали формулами в MathCad-е, но вряд ли кто-нибудь из них смог бы написать GUI-приложение, осуществляющее диалог с пользователем, использующее решение этого интеграла с некоторым специфическим ядром для получения результатов и отображающее результаты расчетов в графическом виде на экране и принтере. И что бы этой программой было удобно пользоваться, чтобы она не жрала лишних ресурсов, не падала, и не тормозила.
Поэтому, алгоритмы программисту нужны -- это вотчина программиста. А вот математика вообще, с различными чисто математическими мозговыкручивающими наворотами -- это еще вопрос. Мне вот кажется, что людей, хорошо понимающих подобные разделы математики, знающих алгоритмы и хорошо программирующих очень и очень мало. Гораздо меньше, чем сейчас требуется программистов на рынке труда.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, McSeem2, Вы писали: MS>Искренне не понимаю, как в профессии программиста может быть что-то важнее алгоритмов. Алгоритмы — это основа. Это как арифметика. Уж извини — если человек базовых алгоритмов не знает, то это не программист. Может быть быдлокодер или говнокодер. Но базовый набор алгоритмов — это просто некий минимум, примерно так же как физминимум Ландау.
Здравствуйте, McSeem2, Вы писали:
MS>Теоретически все можно. "Дот-нет — это все можно отимизировать..." (конец цитаты)
А практически с 2004 года мы пока еще не видели изменений. Как появятся, тогда и будем говоритью А пока это бессмысленное переливание из пустого в порожнее.
... << RSDN@Home 1.2.0 alpha 3 rev. 878 on Windows Vista 6.0.6001.65536>>
Здравствуйте, McSeem2, Вы писали:
MS>Искренне не понимаю, как в профессии программиста может быть что-то важнее алгоритмов.
Сочувствую.
MS> Алгоритмы — это основа.
Основа чего? И почему? Вот к примеру — какие такие есть алгоритмы в VS, чтобы требовалось какое то суперзнание математики?
MS> Это как арифметика. Уж извини — если человек базовых алгоритмов не знает
Как то у тебя незаметно миграция произошла — то математика самое главное, то уже речь про базовые алгоритмы.
MS>Но базовый набор алгоритмов
А что это за набор такой? И что в него входит?
... << RSDN@Home 1.2.0 alpha 3 rev. 878 on Windows Vista 6.0.6001.65536>>
Здравствуйте, eao197, Вы писали:
E>Поэтому, алгоритмы программисту нужны -- это вотчина программиста. А вот математика вообще, с различными чисто математическими мозговыкручивающими наворотами -- это еще вопрос. Мне вот кажется, что людей, хорошо понимающих подобные разделы математики, знающих алгоритмы и хорошо программирующих очень и очень мало. Гораздо меньше, чем сейчас требуется программистов на рынке труда.
+1, но дискретная математика ИМХО должны быть обязательна.
... << RSDN@Home 1.2.0 alpha rev. 786>>
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Здравствуйте, jazzer, Вы писали:
J>Сам посуди — вот ты пишешь на таком супер-языке, мотивация к поддержке которого утрачена, а потом раз — и напарываешься на баг в компиляторе — и чего? Подождать следующей версии — а будет ли она, следующая версия? Потребовать hotfix — у кого потребовать? А у тебя эта программа качает миллион баксов ежедневно. Такие программы на высокорисковых языках никто писать не будет. Новый язык сейчас может быстро пролезть в промышленное программирование только если у него сразу есть хорошая поддержка (например, в виде Microsoft или Sun, или в виде огромного community).
1)Влад гдето тут считал что на то чтобы немерле довести до по настоящему промышленного качества нужно всего полмегабакса. Так что при таких ресурсах если язык дает преимущество то можно взять и сам язык на поддержку.
2)Вот я нашол баг в рантайме .НЕТ (а такое бывало когда я с ним возился). Что мне делать?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, McSeem2, Вы писали:
MS>Я, конечно, понимаю твой цинизм. Но ведь ты же откровенно злорадствуешь — это некрасиво. Мне искренне жаль, что основные разработчики Немерле потеряли мотивацию. Без них проект обречен, увы — это просто такой жизненный факт, с которым не имеет смысла спорить.
Перечитай это
Здравствуйте, WolfHound, Вы писали:
WH>1)Влад гдето тут считал что на то чтобы немерле довести до по настоящему промышленного качества нужно всего полмегабакса. Так что при таких ресурсах если язык дает преимущество то можно взять и сам язык на поддержку.
Это все слова. А на практике что то я не заметил, чтобы кто то озаботился добыванием этого полумегабакса.
WH>2)Вот я нашол баг в рантайме .НЕТ (а такое бывало когда я с ним возился). Что мне делать?
Здравствуйте, AndrewVK, Вы писали:
AVK>Странный какой то разговор получается. То идут заявления, что кроме математики все фигня, то оказывается, что имелись ввиду базовые знания.
Я это к вопросу о том нужна ли математика программисту. ИМХО дискретка нужна обязательно, и да, это есть базовые знания. Ежу понятно, что кроме базовых знаний нужно еще много чего.
... << RSDN@Home 1.2.0 alpha rev. 786>>
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Здравствуйте, AndrewVK, Вы писали:
AVK>http://connect.microsoft.com/visualstudio
И чем она поможет?
Помнишь например ту багу с EventDiscriptor'ом?
Или багу с 3мя и болие точками в имени таблици?
Ты вроде тогда уже был MVP...
Только толку от этого небыло...
Все что получили это бага подтверждена и все на этом...
Всеравно пришлось искать воркараунды...
Про то что некоторые баги немерла невозможно пофиксить из-за багов в Reflection.Emit я вобще молчу. И то что Михал работает в мелкософте на исправление этих багов тоже както не сильно влияет.
Кстати в MONO этих багов нет...
А в конторе в которой я сейчас работаю просто запрещено использовать компоненты которые нельзя собрать из сырцов.
Ибо в случае чего должна быть возможность исправить багу не дожидаясь пока авторы соизволят выпустить патч.
Именно по этому у нас в продакшене никогда не будет стоять винда... Ибо таки приходится временами патчить ядро, драйверы, стеки протоколов, компилятор, системные библиотеки...
Так что в ситуации когда убытки могут быть мегабакс в день я бы очень сильно подумал, а стоит ли связываться с продукцией мелкософта ибо в случае чего ее нельзя захачить.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
А ты ее репортил?
WH>Или багу с 3мя и болие точками в имени таблици?
Поправили, выслали хотфикс.
WH>Про то что некоторые баги немерла невозможно пофиксить из-за багов в Reflection.Emit я вобще молчу.
Ту багу, про которую мне говорил Влад, я зарепортил и они ее пофиксили.
WH> И то что Михал работает в мелкософте на исправление этих багов тоже както не сильно влияет.
Все вопросы к Михалу.
WH>Кстати в MONO этих багов нет...
Было бы странно, если бы были. Зато других вагон. И Моно, между прочим, поддерживается прежде всего программерами, которые сидят в Новеле на full time. Мои баги, по крайней мере, правили именно они. У вас есть такие в Nemerle, чтобы этим самым Немерле занимались за деньги?
WH>А в конторе в которой я сейчас работаю просто запрещено использовать компоненты которые нельзя собрать из сырцов.
Это имеет какое то отношение к коммерческой успешности Nemerle? Или ты предлагаешь прикладникам фиксить баги в его компилере?
WH>Именно по этому у нас в продакшене никогда не будет стоять винда... Ибо таки приходится временами патчить ядро, драйверы, стеки протоколов, компилятор, системные библиотеки...
То есть в неуспехе Nemerle виновата винда?
WH>Так что в ситуации когда убытки могут быть мегабакс в день
Если у тебя такие убытки могут быть, у тебя будет группа спецов, в том числе и из МС, которые тебе по свисту чего хошь в ядре пропатчат. Тока в тех конторах почему то всякие неопенсорсные оракли и db2 стоят, а не postgres и mysql. Опять же, не улавливаю, какое это имеет отношение к Nemerle.
... << RSDN@Home 1.2.0 alpha 3 rev. 878 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Kisloid, Вы писали:
K>Я это к вопросу о том нужна ли математика программисту.
Вот не было изначально такого вопроса. Было "языки — фуфло, алгоритмы с математикой — рулят".
Это еще, кстати, если не вспоминать, что алгоритм это последовательность шагов и как он рулит в декларативных языках — большой вопрос. А пока что вспоминается изречение про молоток и гвозди.
K> ИМХО дискретка нужна обязательно
Нужна. Но во вполне скромном объеме. И не вся. Залитую в меня в больших количествах теорию вероятности, матстатистику и теорию СМО можно было бы и поурезать.
K>, и да, это есть базовые знания. Ежу понятно, что кроме базовых знаний нужно еще много чего.
В том числе и знание хотя бы основных идей и направлений в языковых технологиях. Иначе все одно получится молоток и гвозди.
... << RSDN@Home 1.2.0 alpha 3 rev. 878 on Windows Vista 6.0.6001.65536>>
Поэтому, алгоритмы программисту нужны -- это вотчина программиста. А вот математика вообще, с различными чисто математическими мозговыкручивающими наворотами -- это еще вопрос. Мне вот кажется, что людей, хорошо понимающих подобные разделы математики, знающих алгоритмы и хорошо программирующих очень и очень мало. Гораздо меньше, чем сейчас требуется программистов на рынке труда.
Только вот относить ли дискретку к мозговыкручивающим наворотам или нет, я незнаю.
AVK>Это еще, кстати, если не вспоминать, что алгоритм это последовательность шагов и как он рулит в декларативных языках — большой вопрос. А пока что вспоминается изречение про молоток и гвозди.
Функциональное и логическое программирование являются частью дискретной математики.
K>> ИМХО дискретка нужна обязательно
AVK>Нужна. Но во вполне скромном объеме. И не вся. Залитую в меня в больших количествах теорию вероятности, матстатистику и теорию СМО можно было бы и поурезать.
Возможно, но в минимальной объеме все же оно должно быть обязательно, опять же ИМХО.
K>>, и да, это есть базовые знания. Ежу понятно, что кроме базовых знаний нужно еще много чего.
AVK>В том числе и знание хотя бы основных идей и направлений в языковых технологиях. Иначе все одно получится молоток и гвозди.
+1, но опять же, знание дискретки тут необходимо. Например, лямбда исчисление, комбинаторная логика, функциональное и логическое программирование это все разделы дискретной математики. Все это лежит в основе тех идей и направлений в языковых технологиях. Без знания этой самой базовой теории и получается не программист, а кодер. Все ИМХО конечно же
... << RSDN@Home 1.2.0 alpha rev. 786>>
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
K>Поэтому, алгоритмы программисту нужны -- это вотчина программиста. А вот математика вообще, с различными чисто математическими мозговыкручивающими наворотами -- это еще вопрос. Мне вот кажется, что людей, хорошо понимающих подобные разделы математики, знающих алгоритмы и хорошо программирующих очень и очень мало. Гораздо меньше, чем сейчас требуется программистов на рынке труда.
K>Только вот относить ли дискретку к мозговыкручивающим наворотам или нет, я незнаю.
Нужно пояснить выделенный фрагмент: когда кто-то говорит "программисту нужна математика", то я считаю, что речь идет о математике вообще, в разных ее проявлениях. И сразу вспоминаю такие разделы, как теория функций комплексной переменной и уравнения матфизики. Т.е. из утверждения "программисту нужна математика" для меня следует и утверждение "программисту нужны ТФКП и УМФ", а вот в этом я вовсе не уверен.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Kisloid, Вы писали:
K>Только вот относить ли дискретку к мозговыкручивающим наворотам или нет, я незнаю.
Нет, не относится.
AVK>>Это еще, кстати, если не вспоминать, что алгоритм это последовательность шагов и как он рулит в декларативных языках — большой вопрос. А пока что вспоминается изречение про молоток и гвозди.
K>Функциональное и логическое программирование являются частью дискретной математики.
Я про алгоритмы, а не про математику вообще.
K>+1, но опять же, знание дискретки тут необходимо. Например, лямбда исчисление
Я не уверен, относится ли оно к дискретной математике. Это во-первых. А во-вторых ламбда-исчисление в математике это та самая мозголомная штука, и, что самое удивительное все эти мозголомства в программировании считай что и не используется. Используется само понятие лямбда-функции и кое какая мелочевка.
K>, комбинаторная логика, функциональное и логическое программирование это все разделы дискретной математики.
Как бы тебе попроще объяснить. Ну вот, к примеру, реляционная алгебра безусловно важный раздел математики. Но в реальных современных РСУБД все очень далеко от теории. Поэтому эту самую реляционную алгебру конечно понимать нужно, но все ее изыски в разработке не нужны, зато нужна масса всего другого, что к математике отношения не имеет. Поэтому да, дискретку в базовом объеме знать нужно, но упираться в ее доскональное изучение, да еще и в ущерб тем же языкам не видтся мне разумн6ой стратегией.
K> Все это лежит в основе тех идей и направлений в языковых технологиях.
Опять же спорно. Главное что там лежит — не математика, а скорее понимание человеческого мышления. Та же теория формальных грамматик помнишь для чего создана была? А уж математика там, постолько поскольку иногда удается ее пристегнуть к той или иной идее.
K> Без знания этой самой базовой теории и получается не программист, а кодер.
Кодер получается что со знанием математики, что без. Ничего в этом плохого нет, как бы не старались тут изрекать всякие приставки вроде быдло-. А не кодер — это уже инженер-конструктор в советской терминологии, и знания там нужны совсем из другой области, с математикой обычно слабо пересекающейся (хотя как средство тренировки мозгов математика прокатывает).
... << RSDN@Home 1.2.0 alpha 3 rev. 878 on Windows Vista 6.0.6001.65536>>
Здравствуйте, eao197, Вы писали:
E>Нужно пояснить выделенный фрагмент: когда кто-то говорит "программисту нужна математика", то я считаю, что речь идет о математике вообще, в разных ее проявлениях. И сразу вспоминаю такие разделы, как теория функций комплексной переменной и уравнения матфизики. Т.е. из утверждения "программисту нужна математика" для меня следует и утверждение "программисту нужны ТФКП и УМФ", а вот в этом я вовсе не уверен.
Ну я считаю, что такая математика программисту явно не нужна.
... << RSDN@Home 1.2.0 alpha rev. 786>>
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, AndrewVK, Вы писали:
AVK>>http://connect.microsoft.com/visualstudio WH>И чем она поможет? WH>Помнишь например ту багу с EventDiscriptor'ом? WH>Или багу с 3мя и болие точками в имени таблици? WH>Ты вроде тогда уже был MVP... WH>Только толку от этого небыло... WH>Все что получили это бага подтверждена и все на этом... WH>Всеравно пришлось искать воркараунды...
WH>Про то что некоторые баги немерла невозможно пофиксить из-за багов в Reflection.Emit я вобще молчу. И то что Михал работает в мелкософте на исправление этих багов тоже както не сильно влияет. WH>Кстати в MONO этих багов нет...
WH>А в конторе в которой я сейчас работаю просто запрещено использовать компоненты которые нельзя собрать из сырцов. WH>Ибо в случае чего должна быть возможность исправить багу не дожидаясь пока авторы соизволят выпустить патч. WH>Именно по этому у нас в продакшене никогда не будет стоять винда... Ибо таки приходится временами патчить ядро, драйверы, стеки протоколов, компилятор, системные библиотеки...
WH>Так что в ситуации когда убытки могут быть мегабакс в день я бы очень сильно подумал, а стоит ли связываться с продукцией мелкософта ибо в случае чего ее нельзя захачить.
естественно, потому что это тоже риск, который нужно оценивать.
У нас тоже на мелкософте только почта, остальное на никсах.
Здравствуйте, WolfHound, Вы писали:
WH>2)Вот я нашол баг в рантайме .НЕТ (а такое бывало когда я с ним возился). Что мне делать?
у тебя есть контракт на поддержку? Если есть — должны пофиксить сразу же, и прислать патч.
Вот у нас контракт есть, так у нас и билд винды специальный (как и линукса, кстати).
И когда я в Дойче работал — было то же самое, только с Саном — когда я нашел баг в компиляторе, я его им отрепортил, они сказали — ну да, баг, пофиксим, как дойдут руки, но скорее всего не дойдут, версия больно старая, а я говорю — я вообще-то из Дойче, номер суппортного контракта такой-то — прислали патч.
Здравствуйте, AndrewVK, Вы писали:
WH>>Или багу с 3мя и болие точками в имени таблици? AVK>Поправили, выслали хотфикс.
Сколько времени прошло?
Если мне не изменяет скалероз при мне его еще небыло.
AVK>Ту багу, про которую мне говорил Влад, я зарепортил и они ее пофиксили.
Где я могу взять зафикшеный рантайм?
Я могу раскатить этот рантайм на кучу машин по всему миру?
AVK>Если у тебя такие убытки могут быть, у тебя будет группа спецов, в том числе и из МС, которые тебе по свисту чего хошь в ядре пропатчат.
Я не могу говорить публично но специ из другой очень не маленькой конторы оказались беспомощьны... при том что у нас стоит их самое дорогое железо.
AVK>Тока в тех конторах почему то всякие неопенсорсные оракли и db2 стоят, а не postgres и mysql.
Вот у нас какраз стоит и оракл и postgres и mysql... меньше всего проблем с mysql.
От оракловых консультантов толку тоже не много...
AVK>Опять же, не улавливаю, какое это имеет отношение к Nemerle.
Такое что нельзя говорить что отсутствие на чемто лычки мелкософт, IBM и тп есть ужос ужос.
Болие того имея компилятор с открытым кодом можно поправить ошибку самому что часто есть очень большой плюс.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AndrewVK, Вы писали:
AVK>Я не уверен, относится ли оно к дискретной математике. Это во-первых. А во-вторых ламбда-исчисление в математике это та самая мозголомная штука, и, что самое удивительное все эти мозголомства в программировании считай что и не используется. Используется само понятие лямбда-функции и кое какая мелочевка.
Относится, ведь там нет понятии бесконечности.
Что там такого мозголомного, там как раз все очень просто.
Лямда-исчисление это мат. формализм описывающий функции, их применение, рекурсию.
AVK>Как бы тебе попроще объяснить. Ну вот, к примеру, реляционная алгебра безусловно важный раздел математики. Но в реальных современных РСУБД все очень далеко от теории. Поэтому эту самую реляционную алгебру конечно понимать нужно, но все ее изыски в разработке не нужны, зато нужна масса всего другого, что к математике отношения не имеет. Поэтому да, дискретку в базовом объеме знать нужно, но упираться в ее доскональное изучение, да еще и в ущерб тем же языкам не видтся мне разумн6ой стратегией.
Я и не говорил, что ее нужно досконально знать, я говорил про базовый объем.
AVK>Опять же спорно. Главное что там лежит — не математика, а скорее понимание человеческого мышления. Та же теория формальных грамматик помнишь для чего создана была? А уж математика там, постолько поскольку иногда удается ее пристегнуть к той или иной идее.
Смотря что понимать под математикой, мне кажется ты математику рассматриваешь лишь как инструмент. А я математику рассматриваю как некий общий базовый формальный язык.
... << RSDN@Home 1.2.0 alpha rev. 786>>
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Здравствуйте, WolfHound, Вы писали:
AVK>>Поправили, выслали хотфикс. WH>Сколько времени прошло?
Не считал.
AVK>>Ту багу, про которую мне говорил Влад, я зарепортил и они ее пофиксили. WH>Где я могу взять зафикшеный рантайм?
Написать в МС вышлют, если оно в SP1 не вошло.
WH>Я могу раскатить этот рантайм на кучу машин по всему миру?
Да.
WH>Я не могу говорить публично но специ из другой очень не маленькой конторы оказались беспомощьны... при том что у нас стоит их самое дорогое железо.
Мы еще про .NET говорим, или про какое то железо от неизвестной конторы? И вы же виндой не пользуетесь.
AVK>>Тока в тех конторах почему то всякие неопенсорсные оракли и db2 стоят, а не postgres и mysql. WH>Вот у нас какраз стоит и оракл и postgres и mysql...
Вот у вас как раз нет миллиона баксов прибыли в день, не то что убытков.
WH> меньше всего проблем с mysql.
Ну так и используйте ее, зачем вам оракл?
AVK>>Опять же, не улавливаю, какое это имеет отношение к Nemerle. WH>Такое что нельзя говорить что отсутствие на чемто лычки мелкософт, IBM и тп есть ужос ужос.
А про отсутствие лычек никто не говорил. Говорили про отсутствие гарантий. Я тебе еще раз повторю вопросы: сколько программистов занимается Nemerle full time за деньги? Сколько человек сейчас занимаются поиском того самого полумиллиона баксов? Почему твоя контора не возъмет Nemerle под свое крылышко? На фоне этого обсуждать недостатки саппорта МС и оракла просто смешно.
WH>Болие того имея компилятор с открытым кодом можно поправить ошибку самому что часто есть очень большой плюс.
Знаешь, я бы тебе денег на проект с использованием Nemerle не дал.
... << RSDN@Home 1.2.0 alpha 3 rev. 878 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Kisloid, Вы писали:
K>Относится, ведь там нет понятии бесконечности. K>Что там такого мозголомного, там как раз все очень просто. K>Лямда-исчисление это мат. формализм описывающий функции, их применение, рекурсию.
Да нет, не все так просто. Там на основе этого формализма столько всего понаворочено. Чисто абстрактно.
AVK>>Опять же спорно. Главное что там лежит — не математика, а скорее понимание человеческого мышления. Та же теория формальных грамматик помнишь для чего создана была? А уж математика там, постолько поскольку иногда удается ее пристегнуть к той или иной идее.
K>Смотря что понимать под математикой, мне кажется ты математику рассматриваешь лишь как инструмент.
Безусловно. Иного прикладного применения математика не имеет.
... << RSDN@Home 1.2.0 alpha 3 rev. 878 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Мы еще про .NET говорим, или про какое то железо от неизвестной конторы? И вы же виндой не пользуетесь.
Контора очень даже известная.
Вот только у нас задачи не типичные.
AVK>Вот у вас как раз нет миллиона баксов прибыли в день, не то что убытков.
Точных цифр я не знаю но порядок примерно такой.
AVK>Ну так и используйте ее, зачем вам оракл?
Есть проекты которые запускаются один раз. И когда этот проект делали кипились на то что оракл это круто .
Перезапустить их на другой технологии нельзя. Ибо там такие объемы данных (RSDN на несколько десятичных порядков меньше) что-то да потеряется при переезде. И очень много людей растроятся.
Так что приходится жить на том на чем запустили.
Кстати на этом проекте очень быстро появилось рукописное хранилище куда из оракла уехали блобы... иначе он вобще не жил.
AVK>А про отсутствие лычек никто не говорил. Говорили про отсутствие гарантий.
1)В немерле багов по крайней мере не больше чем в компиляторе C# от мелкософта.
2)Если будет критичный баг то его можно исправить самому ибо код открыт.
3)Я тут на немерле немного пишу. Мониторинги, утиль и тп так вот ошибок в компиляторе не встречал. Разве что вывод типов иногда работал не слишком интуитивно. Но это решалось уточнением типов.
Короче: Имею Мнение Хрен Оспоришь что риски от использования немерла мягко говоря преувеличины. Как по мне они на уровне рисков при использовании C#. Разве что в случае с немерлом индокодеров использовать трудно. В прочем их лучше вобще не использовать.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Cyberax, Вы писали:
K>>3) Синтаксическое — возникает при больших значениях числа Губанова. C>В этом месте пролил сок на клавиатуру! Блин, опять ноут разбирать.
Искусство требует жертв.
... << RSDN@Home 1.2.0 alpha 3 rev. 880>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, WolfHound, Вы писали:
AVK>>Мы еще про .NET говорим, или про какое то железо от неизвестной конторы? И вы же виндой не пользуетесь. WH>Контора очень даже известная.Вот только у нас задачи не типичные.
Вопрос я выделил
AVK>>Вот у вас как раз нет миллиона баксов прибыли в день, не то что убытков. WH>Точных цифр я не знаю но порядок примерно такой.
Да? А по моим сведениям за 2006 год прибыль — 29,9 млн.
AVK>>Ну так и используйте ее, зачем вам оракл? WH>Есть проекты которые запускаются один раз. И когда этот проект делали кипились на то что оракл это круто . WH>Перезапустить их на другой технологии нельзя.
Круто это все, но никак не приближает нас к ответу на заданные вопросы. Хинт: я по прежнему не обсуждаю какой маздай МС и закрытые исходники.
WH> Ибо там такие объемы данных (RSDN на несколько десятичных порядков меньше)
RSDN в плане объемов не показатель.
WH>1)В немерле багов по крайней мере не больше чем в компиляторе C# от мелкософта.
А вот этого ты знать не можешь в принципе. Потому что компилятор С# тестируют десятки миллионов разработчиков, а Nemerle — крошечная горстка энтузиастов. Андрюша, пойми одну простую вещь, какой бы маздай не был Майкрософ, но если на разработку одного только дотнета тратятся десяток-другой прибылей твоей конторы, а на разработку Nemerle даже с учетом потраченного всеми вами времени максимум десятки тысяч, то сравнивать уровень гарантий просто смешно.
WH>2)Если будет критичный баг то его можно исправить самому ибо код открыт.
А если у меня нет специалиста, способного разобраться в коде компилятора?
WH>3)Я тут на немерле немного пишу. Мониторинги, утиль и тп так вот ошибок в компиляторе не встречал.
Между твоим немного, и full scale проектом в десятки человеколет есть некоторая разница. Size does matter. Вот на шарпе, я точно знаю, написаны гигабайты кода. А на Nemerle? Компилятор, кусочек интеграции и твои утилиты? А инструменты разработки? А решарпер?
И кому теперь принадлежать права на компилятор?
WH>Короче: Имею Мнение Хрен Оспоришь что риски от использования немерла мягко говоря преувеличины.
Твое мнение ничего не стоит увы, покуда оно не подкреплено весомыми аргументами. Твои утилитки на таковые, ты уж прости, не тянут.
WH> Как по мне они на уровне рисков при использовании C#. Разве что в случае с немерлом индокодеров использовать трудно. В прочем их лучше вобще не использовать.
Ну да, проблема всех непонятых языков завсегда в неких абстрактных индокодерах.
... << RSDN@Home 1.2.0 alpha 3 rev. 878 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Твое мнение ничего не стоит увы, покуда оно не подкреплено весомыми аргументами. Твои утилитки на таковые, ты уж прости, не тянут.
Тут где-то рядом пролетал мини-отчет от hi_octane о использовании немерля в боевом проекте. Все довольны, вроде бы
Здравствуйте, AndrewVK, Вы писали:
AVK>Вопрос я выделил
Мы говорим про риски.
И про то что лычка крупной конторы типа сильно снижает риски.
AVK>Да? А по моим сведениям за 2006 год прибыль — 29,9 млн.
Ты пожалуйста не забывай про мягко говоря не меленький зарплатный фонд, про скупку железа тоннами итп
AVK>RSDN в плане объемов не показатель.
Показатель.
Ибо не много баз данных больше чем на RSDN.
AVK>А вот этого ты знать не можешь в принципе. Потому что компилятор С# тестируют десятки миллионов разработчиков, а Nemerle — крошечная горстка энтузиастов. Андрюша, пойми одну простую вещь, какой бы маздай не был Майкрософ, но если на разработку одного только дотнета тратятся десяток-другой прибылей твоей конторы, а на разработку Nemerle даже с учетом потраченного всеми вами времени максимум десятки тысяч, то сравнивать уровень гарантий просто смешно.
Про Решетникова расказывать?
AVK>А если у меня нет специалиста, способного разобраться в коде компилятора?
Я уверен что ты сам сможешь починить компилятор в случае чего.
Там нет ничего такого с чем ты не можешь справится в течении одного двух дней.
AVK>Между твоим немного, и full scale проектом в десятки человеколет есть некоторая разница. Size does matter. Вот на шарпе, я точно знаю, написаны гигабайты кода. А на Nemerle? Компилятор, кусочек интеграции и твои утилиты? А инструменты разработки?
А интеграция типа не инструмент разработки?
AVK>А решарпер?
А что решарпер?
Большая часть фишек решарпера при разработке на немерле просто не нужна. Ибо язык намного болие умный.
Наиболие важные (автокомплит и навигация) уже есть.
Отладчик тоже вполне себе работает.
AVK>И кому теперь принадлежать права на компилятор?
Лицензия BSD вид в профиль.
/*
* Copyright (c) 2003-2005 The University of Wroclaw.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. The name of the University may not be used to endorse or promote
* products derived from this software without specific prior
* written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE UNIVERSITY ``AS IS'' AND ANY EXPRESS OR
* IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
* NO EVENT SHALL THE UNIVERSITY BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
* TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
* PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
* LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
* NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
* SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
AVK>Твое мнение ничего не стоит увы, покуда оно не подкреплено весомыми аргументами. Твои утилитки на таковые, ты уж прости, не тянут.
Есть как минимум компилятор немерла.
Вероятность того что ты сможешь наткнутся на баг класса блокер на который не наткнулись разработчики компилятора пока писали этот самй компилятор около нуля ибо при разработке компилятора использованны паркически все фичи компилятора в очень разных сочетаниях.
Ну и про Решетникова не забывай... ибо миллионам индусов в поиске багов в компиляторе до Решетникова...
Большая часть багов которые он нашол в немерле исправлена. Остальные из серии http://nemerle.org/bugs/view.php?id=955
AVK>Ну да, проблема всех непонятых языков завсегда в неких абстрактных индокодерах.
Ну а что поделать если попадаются вот такие вот фрукты
Здравствуйте, WolfHound, Вы писали:
AVK>>Вопрос я выделил WH>Мы говорим про риски. WH>И про то что лычка крупной конторы типа сильно снижает риски.
Снижает риски не лычка, а бабло. Банальное бабло. Ну и миллионы юзеров, уже поимевших геморой на собственной шкуре.
AVK>>Да? А по моим сведениям за 2006 год прибыль — 29,9 млн. WH>Ты пожалуйста не забывай про мягко говоря не меленький зарплатный фонд, про скупку железа тоннами итп
72 млн. весь оборот, со всеми твоими зарплатными фондами и железозакупками.
AVK>>RSDN в плане объемов не показатель. WH>Показатель. WH>Ибо не много баз данных больше чем на RSDN.
Как бы тебе сказать ... вобщем, много.
WH>Про Решетникова расказывать?
Один в поле не воин, даже он.
AVK>>А если у меня нет специалиста, способного разобраться в коде компилятора? WH>Я уверен что ты сам сможешь починить компилятор в случае чего.
А при чем тут я?
WH>А интеграция типа не инструмент разработки?
Типа пока еще далеко нет. Даже до качества глюковатой студии не дотягивает.
AVK>>А решарпер? WH>А что решарпер?
А нету его.
WH>Большая часть фишек решарпера при разработке на немерле просто не нужна.
Знакомая песня.
WH> Ибо язык намного болие умный.
Ага, а рефакторинг придумали трусы.
AVK>>Твое мнение ничего не стоит увы, покуда оно не подкреплено весомыми аргументами. Твои утилитки на таковые, ты уж прости, не тянут. WH>Есть как минимум компилятор немерла.
Мало.
WH>Вероятность того что ты сможешь наткнутся на баг класса блокер на который не наткнулись разработчики компилятора пока писали этот самй компилятор около нуля
Не верю, уж извини.
WH> ибо при разработке компилятора использованны паркически все фичи компилятора в очень разных сочетаниях.
Шарп третий тоже использовался до релиза во всяких сочетаниях для разработки библиотек 3.5 фрейморка. И тестировали его сильно больше народу. Однако ж, поди ж ты, и после релиза ошибки есть.
WH>Ну и про Решетникова не забывай...
А что про него забывать? Ты уверен что он Nemerle тестировал столь же тщательно, как шарп?
WH> ибо миллионам индусов в поиске багов в компиляторе до Решетникова...
Я бы не был так уверен.
WH>Большая часть багов которые он нашол в немерле исправлена.
А которые не нашел? Еще раз — я не верю твоим уверениям, это слишком слабая гарантия, если я хочу инвестировать суммы минимум в сотни тысяч баксов.
AVK>>Ну да, проблема всех непонятых языков завсегда в неких абстрактных индокодерах. WH>Ну а что поделать если попадаются вот такие вот фрукты
Это великий человек, на деле доказавший свою способность сплачивать в единые ряды (против себя) самых непримеримых RSDN-антагонистов.
Если бы он продвигал Оберон на Корейском полуострове, в Кашмире или секторе Газа, помешать ему получить нобелевскую премию мира могло бы только то, что посмертно ее не присуждают.
... << RSDN@Home 1.2.0 alpha 3 rev. 880>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, AndrewVK, Вы писали:
AVK>>>А если у меня нет специалиста, способного разобраться в коде компилятора? WH>>Я уверен что ты сам сможешь починить компилятор в случае чего. AVK>А при чем тут я?
Ну ты же переживаешь что все пропадет если бага в компиляторе найдется...
Во всем компиляторе есть одно мегахардкорное место которое с наскоку не починить: вывод типов.
Но если выводильщик типов вдруг начинает выводить что-то не то то нужно просто указать гденибуть тип явно и он сразу все начинает понимать. В самом худшем случае придется в приделах одной функции указывать типы как в C#.
Либое другое место спец твоего уровня починит без проблем.
Особенно если он уже успел поработать на немерле. А на багу ты так сразу не налетишь.
Есть еще некоторое колличество неизлечимых багов в которых виноват мелкософт с его мегабабками.
Правда тут можно как вариант использовать мелкософт вей... генерить сборки руками...
AVK>Типа пока еще далеко нет. Даже до качества глюковатой студии не дотягивает.
Это вопрос времени.
WH>>Большая часть фишек решарпера при разработке на немерле просто не нужна. AVK>Знакомая песня.
Я какбы использовал решарпер...
И на C# без решарпера писать не буду.
А вот на немерле вполне.
AVK>Ага, а рефакторинг придумали трусы.
Это конечно недостаток но я бы не сказал что очень сильный.
С другой стороны у немерла есть макры.
WH>>Есть как минимум компилятор немерла. AVK>Мало.
4.5 метра кода ИМХО болие чем достаточно для того чтобы считать компилятор стабильным.
AVK>А что про него забывать? Ты уверен что он Nemerle тестировал столь же тщательно, как шарп?
Этот вопрос можно спокойно перевернуть.
Давай лучше у него спросим.
WH>> ибо миллионам индусов в поиске багов в компиляторе до Решетникова... AVK>Я бы не был так уверен.
Да ладно. Код который пишет Решетников для того чтобы завалить компилятор ни одному индусу просто в голову не придет.
Даже если сильно обкурится.
AVK>А которые не нашел?
А C# 3.5 с багами которые не нашли использовать можно, а немерле с багами которые не нашли использовать нельзя?
AVK>Еще раз — я не верю твоим уверениям, это слишком слабая гарантия, если я хочу инвестировать суммы минимум в сотни тысяч баксов.
Можешь еще вот эту веточку
почитать.
AVK>И из-за них у Nemerle так мало пользователей?
А дело в том что таких вот большинство.
Лично я уверен что ты тот код прочитал вобще не разу не запнувшись.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
AVK>>А при чем тут я? WH>Ну ты же переживаешь что все пропадет если бага в компиляторе найдется...
Я не переживаю, я просто пытаюсь объяснить, почему в текущем состоянии Nemerle не самый лучший выбор для промышленной разработки.
WH>Во всем компиляторе есть одно мегахардкорное место которое с наскоку не починить: вывод типов.
Да пофигу что и как там есть. Я вообще сейчас не обсуждаю его внутренности. Представь себе что я инвестор, не особо разбирающийся в программировании. Попробуй убедить меня в том, что в тебя с твоим Немерле можно вложить 500 килобаксов. Хинт: после слова "вывод типов" скорее всего разговор будет подходить к концу.
WH>Либое другое место спец твоего уровня починит без проблем. WH>Особенно если он уже успел поработать на немерле. А на багу ты так сразу не налетишь.
Это все пока что только твои слова. И ничего более.
WH>Есть еще некоторое колличество неизлечимых багов в которых виноват мелкософт с его мегабабками.
Тут разговор точно будет закончен.
WH>Правда тут можно как вариант использовать мелкософт вей... генерить сборки руками...
Это, кстати, показатель. Выдернуть тот же Cecil из Моно проблем нет, но этого никто, я повторяю, никто не сделал.
AVK>>Типа пока еще далеко нет. Даже до качества глюковатой студии не дотягивает. WH>Это вопрос времени.
Какого? Вы вон LINQ к Nemerle который год прикручиваете?
AVK>>Знакомая песня. WH>Я какбы использовал решарпер... WH>И на C# без решарпера писать не буду. WH>А вот на немерле вполне.
Конечно, потому что аналогичного продукта для Немерле ты не пробовал.
AVK>>Ага, а рефакторинг придумали трусы. WH>Это конечно недостаток но я бы не сказал что очень сильный.
Кирпичик к кирпичику. Это не столько сама по себе проблема, сколько опять же, показатель.
WH>С другой стороны у немерла есть макры.
Ага, и это еще один гвоздь в гроб применимости в промышленной разработке.
AVK>>Мало. WH>4.5 метра кода ИМХО болие чем достаточно для того чтобы считать компилятор стабильным.
ИМХО нет. Два десятка мег шарповского кода в торнаде не поймали в компиляторе шарпа ни одной ошибки, а он, по твоим словам, даже глючнее Немерли. Что то у тебя концы с концами не сходятся. Тока я в шарп верю, потому что помимо моих 20, есть еще сотни тысяч, наверное, по всему миру. А в коннекте есть только несответствие документации да неочевидное поведение в мегаизвратном семпл-коде в небольших количествах.
AVK>>Я бы не был так уверен. WH>Да ладно. Код который пишет Решетников для того чтобы завалить компилятор ни одному индусу просто в голову не придет.
Им и не такое приходит в голову. И, честно говоря, эти баги меня не колышат. Там есть куда более неприятные вещи, которые поймал отнюдь не он.
AVK>>А которые не нашел? WH>А C# 3.5
Нет такого. Есть 3.0.
WH> с багами которые не нашли использовать можно, а немерле с багами которые не нашли использовать нельзя?
Можно. Нельзя. Объем тестирования даже близко не сопоставим.
AVK>>Еще раз — я не верю твоим уверениям, это слишком слабая гарантия, если я хочу инвестировать суммы минимум в сотни тысяч баксов. WH>Можешь еще вот эту веточку
Читал. Тоже не убедило. Непонятные проекты с неясным результатом. Ничего не могу сказать. Слишком мало информации. Я, к примеру, на beta 1 еще первого шарпа тоже проектик в свое время коммерческий сделал. Небольшой. А большой бы не стал делать ни за что.
AVK>>И из-за них у Nemerle так мало пользователей? WH>А дело в том что таких вот большинство.
Если таких большинство, то их надо учитывать, а не гордо игнорировать факты.
... << RSDN@Home 1.2.0 alpha 3 rev. 881 on Windows Vista 6.0.6001.65536>>
MS>>И не надо меня убеждать, что есть математики, которые пишут говённый код — бывают такие, но они при этом и математики тоже говённые.
E>-1 E>Доводилось видеть хороших математиков, которые не программировали (толи не умели, толи учиться не хотелось); хороших математиков, которые очень здорово программировали; хороших математиков, которые плохо программировали. А так же хороших программистов, плохо знающих математику.
Чаще всего видел математиков, которые пишут гавённый код, при этом как математики бывают как плохие так и хорошие. Никакой корреляции не заметил
Здравствуйте, nikov, Вы писали:
AVK>>А что про него забывать? Ты уверен что он Nemerle тестировал столь же тщательно, как шарп?
N>Честно говоря, на тестирование Nemerle я потратил не больше трех дней, что очень мало по сравнению с C#.
Вот о том и речь. Тем более, если я не ошибаюсь, на шарпе ты еще, помимо тестирования, и софт пишешь.
... << RSDN@Home 1.2.0 alpha 3 rev. 883 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>>>Типа пока еще далеко нет. Даже до качества глюковатой студии не дотягивает. WH>>Это вопрос времени.
AVK>Какого? Вы вон LINQ к Nemerle который год прикручиваете?
Да, по моему, никто его не прикручивает. Заглохло на этапе постановки задачи, так как не смогли решить, в каком виде оно нам нужно (в том, как оно есть у MS, или что-то своё\9
Здравствуйте, Сергей Туленцев, Вы писали:
СТ>Да, по моему, никто его не прикручивает. Заглохло на этапе постановки задачи, так как не смогли решить, в каком виде оно нам нужно
Воот. Это тоже показатель.
... << RSDN@Home 1.2.0 alpha 3 rev. 883 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
СТ>>Да, по моему, никто его не прикручивает. Заглохло на этапе постановки задачи, так как не смогли решить, в каком виде оно нам нужно
AVK>Воот. Это тоже показатель.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Сергей Туленцев, Вы писали:
AVK>>>Воот. Это тоже показатель.
СТ>>Показатель чего?
AVK>Обсуждаемого в этом треде.
Правильно ли я понимаю, что обсуждается применимость Nemerle в коммерческих проектах? Если так, то выскажу своё мнение: как единственный язык разработки, он, конечно же, не подходит. Его текущая самая большая слабость — недоразвитость средств разработки, всяких там визардов. Тот же WinForms designer вроде бы как есть, но вроде бы как и нет (кидание на форму стороннего компонента, например, от Syncfusion, рвет ему крышу напрочь). НО! мы работаем над этим, в меру сил.
С другой стороны, слышал из достоверных источников о нескольких успешных продуктах на руби. А там уж вообще никакой инструментальной поддержки нету (вроде интеллисенса. Речь про два года назад, когда я на него смотрел). И ничего, пишут же люди.
Так что, навороты Nemerle могут быть в полной мере использованы в библиотечном коде (ну ладно, не в полной. Наружу кортежи выставлять, значит издвеваться над пользователями. Но внутри — твори что хочешь).
Я, как раз в настоящее время, делаю такой вот гибридный проектик (GUI — C#, остальное — Nemerle), в целях подтверждения моей точки зрения.
Здравствуйте, Сергей Туленцев, Вы писали:
AVK>>Обсуждаемого в этом треде.
СТ>Правильно ли я понимаю, что обсуждается применимость Nemerle в коммерческих проектах?
Да.
СТ> Если так, то выскажу своё мнение: как единственный язык разработки, он, конечно же, не подходит. Его текущая самая большая слабость — недоразвитость средств разработки, всяких там визардов.
Я еще раз повторюсь — у него много слабостей, не только это. По кирпичику вырастает целая стена.
СТ> Тот же WinForms designer вроде бы как есть, но вроде бы как и нет (кидание на форму стороннего компонента, например, от Syncfusion, рвет ему крышу напрочь). НО! мы работаем над этим, в меру сил.
Мера сил ваша только не очень. Это ни в коей мере не означает что вы такие слабые, просто сравнивать объем доступных вам и любой мейнстрим платформы ресурсов просто невозможно.
СТ>С другой стороны, слышал из достоверных источников о нескольких успешных продуктах на руби.
У Руби комьюнити мегабольше вашего.
СТ>Так что, навороты Nemerle могут быть в полной мере использованы в библиотечном коде
Не могут. Библиотечный код тоже надо поддерживать. Nemerle в коммерческом программировании можно пока что использовать только на небольших проектиках, которые, если что, не так уж жалко и выкинуть (единицы человекомесяцев обычно).
СТ>Я, как раз в настоящее время, делаю такой вот гибридный проектик (GUI — C#, остальное — Nemerle), в целях подтверждения моей точки зрения.
И какой бюджет проекта?
... << RSDN@Home 1.2.0 alpha 3 rev. 883 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
СТ>>Я, как раз в настоящее время, делаю такой вот гибридный проектик (GUI — C#, остальное — Nemerle), в целях подтверждения моей точки зрения.
AVK>И какой бюджет проекта?
Ну пока что никакой. Персональный проект. Тут у нас (на работе) весьма строгая политика насчет всяких сторонних вещей. Даже PowerCollections нельзя использовать.
На прошлой работе я на Nemerle написал большиство маленьких полезных утилиток (кажется, это подтверждает твою точку зрения ). Из нашей команды Nemerle нас знало только двое человек, поэтому не успели пролоббировать разрешение его, как официальный язык разработки. Впрочем, как оказалось, было всё равно на чем писать. Всю команду "ушли" после первой фазы внедрения заказчику.
Здравствуйте, Сергей Туленцев, Вы писали:
СТ>На прошлой работе я на Nemerle написал большиство маленьких полезных утилиток (кажется, это подтверждает твою точку зрения ). Из нашей команды Nemerle нас знало только двое человек, поэтому не успели пролоббировать разрешение его, как официальный язык разработки. Впрочем, как оказалось, было всё равно на чем писать. Всю команду "ушли" после первой фазы внедрения заказчику.
Тьфу ты, черт, совсем по русски разучился писать с этими буржуями.
А можно вот такой вопрос задать, раз уж разговор идет о судьбе и применимости Nemerle: в OpenSource разработках (например, Ван Россум в Python, Мацумото в Ruby, Торвальдс в Linux) есть лидеры, которые сейчас не столько сами кодят, сколько являются некой высшей властью. Именно они разруливают конфликты и делают выбор между несколькими альтернативами. Именно это и позволяет проектам сохранять некую целостность и двигаться в каком-то конкретном направлении (том, которое выбрали лидеры проекта). Когда лидеров-диктаторов нет, проекты превращаются в жуткий долгострой (вроде C++0x или Perl 6).
Раньше такими лидерами в Nemerle были, как я понимаю, Камиль и Михал. После их самоустранения из проекта, как решается проблема лидерства?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Раньше такими лидерами в Nemerle были, как я понимаю, Камиль и Михал. После их самоустранения из проекта, как решается проблема лидерства?
Ну я не знаю. Демократия наверное. Тогда, похоже, ты прав, нас ждет жуткий бардак
Насчет лидеров: Камил всё еще может зарубить какую-то идею. Но вот кто покажет пальцем: "Вот там наше светлое будущее"?
Надо выборы чтоли устроить?
Здравствуйте, Сергей Туленцев, Вы писали:
СТ>Тьфу ты, черт, совсем по русски разучился писать с этими буржуями.
Любопытно.
Ну и как по-русски ты бы написал свое сообщение:
СТ>>На прошлой работе я на Nemerle написал большиство маленьких полезных утилиток (кажется, это подтверждает твою точку зрения ). Из нашей команды Nemerle нас знало только двое человек, поэтому не успели пролоббировать разрешение его, как официальный язык разработки. Впрочем, как оказалось, было всё равно на чем писать. Всю команду "ушли" после первой фазы внедрения заказчику.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Сергей Туленцев, Вы писали:
СТ>>Тьфу ты, черт, совсем по русски разучился писать с этими буржуями. CC>Любопытно. CC>Ну и как по-русски ты бы написал свое сообщение: CC>
СТ>>>На прошлой работе я на Nemerle написал большиство маленьких полезных утилиток (кажется, это подтверждает твою точку зрения ). Из нашей команды Nemerle нас знало только двое человек, поэтому не успели пролоббировать разрешение его, как официальный язык разработки. Впрочем, как оказалось, было всё равно на чем писать. Всю команду "ушли" после первой фазы внедрения заказчику.
На прошлой работе я на Nemerle написал большиство маленьких полезных утилиток (кажется, это подтверждает твою точку зрения ). Из нашей команды только двое человек знало Nemerle, поэтому не успели пролоббировать разрешение его как официальный язык разработки. Впрочем, как оказалось, было всё равно на чем писать. Всю команду "ушли" после завершения первой фазы внедрения заказчику.
Здравствуйте, Сергей Туленцев, Вы писали:
СТ>На прошлой работе я на Nemerle написал большиство маленьких полезных утилиток (кажется, это подтверждает твою точку зрения ). Из нашей команды только двое человек знало Nemerle, поэтому не успели пролоббировать разрешение его как официальный язык разработки. Впрочем, как оказалось, было всё равно на чем писать. Всю команду "ушли" после завершения первой фазы внедрения заказчику.
СТ>Мне кажется, так будет более по-русски.
А я то думал...
Пропущенные/лишние слова как то сами при чтении додумываются
Здравствуйте, WolfHound, Вы писали:
WH>Правда тут можно как вариант использовать мелкософт вей... генерить сборки руками...
Можно и не совсем руками. Взять, например библиотечку Mono.Cecil (тоже под BSD лицензией). Я удивляюсь, почему в Nemerle такой подход не был выбран с самого начала. Если бы возникли какие-то сложности, как с Reflection.Emit, всегда можно докрутить исходники.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, WolfHound, Вы писали:
AVK>>>Вопрос я выделил WH>>Мы говорим про риски. WH>>И про то что лычка крупной конторы типа сильно снижает риски.
AVK>Снижает риски не лычка, а бабло. Банальное бабло. Ну и миллионы юзеров, уже поимевших геморой на собственной шкуре.
Совершенно согласен, безотносительно Nemerle и МС.
Вот, к примеру, моя недавняя головная боль — Bluetooth. Стек от MS vs стек от Widcomm четко показывают разницу в размере.
У МС — убогий набор фич. Но работает всё. 100%. Ситуации, когда диалог bluetooth выдает A/V в природе не бывает.
У видкомма — есть всё. Куча сервисов, драйверов, красивости в UI. Банальное переключение языка в винде может сшибить башню UI на раз-два; невосстановление коннекта к девайсу после ухода за пределы действия донгла — только в путь.
Невооруженным взглядом видно, что только на QA bluetooth в winXP было потрачено примерно столько же денег, сколько на весь видкомм вместе с маркетингом.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, Klapaucius, Вы писали:
K>>Вообще, "мощность языка" понятие довольно невнятное, для которого у каждого может быть свое интуитивное понимание.
MS>Не спорь, Klapaucius. Самый мощный язык — это язык математики. Все компьютерные языки — суть жалкие производные.
MS>Офтоп — меня удивляет диссонанс. Сейчас на компьютере надо очень-очень постараться, чтобы написать статью с формулами. Надо как минимум изучать LaTeX. А раньше? — во времена Энштейна — сдавали рукописи! Эти, блин, издательства — совсем обнаглели, у меня потребовали рисунок в PDF!!! А где я его возьму в PDF, если я его на листочке от руки нарисовал?! — у них там что, нет чертежника? Раньше было принято в научных журналах перечерчивать все рисунки и графики и присылать их на согласование с авторами. А сейчас им PDF подавай, блин. А где я его возьму, если у меня есть только на листочке?!
Ну, в список моих Проектов, Которыми Заняться На Пенсии входит в том числе и optical diagram recognition. Ну то есть распознавалка диаграммов — ты типа рисуешь на салфетке/тачскрине/планшете свои каракули, а софтина это превращает в аккуратные Collaboration Diagram, Deployment Model, Class Model, ER Diagram, блок-схемы, Use-Case и прочее.
Существующие тулзы для диаграмминга невыразимо ужасны.
Самый быстрый способ для меня получить диаграмму структуры БД — написать DDL, а потом построить диаграмму через Visio или через SQL Server Management Studio.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
McSeem2,
N>>Вот хотел спросить совета, лучше пытаться переходить на какой-нибудь другой язык или оставаться программировать на с++?
MS>В общем, по совокупности флейма ты уже все понял: языки — фуфло, алгоритмы с математикой — рулят. И не надо меня убеждать, что есть математики, которые пишут говённый код — бывают такие, но они при этом и математики тоже говённые. А уж язык — C++ или C# или Java — это дело десятое, не стоящее даже обсуждения. Ни одна конкретная программа ни на одном конкретном языке не живет достаточно долго. А вот, скажем, алгоритм поиска маршрута имени Дейксты будет жить вечно. Я не призываю все щас бросить и начать изобретать гениальные алгоритмы — это невозможно, да и не нужно. Но вот изучать алгоритмы — это первейшая задача человека, считающего себя программистом. А языки — это дело наживное.
Увы и ах. Когда я придумывал и делал алгоритм расчёта оптимальной проводки в ХХХ — я не знал что это было время, когда я был щаслив. А сейчас (то есть прямо ща для выполнения задач, стоящих передо мной) мне нужно просто много (ОЧЕНЬ МНОГО) памяти, и не той, что в мегабайтах, а той, что в мозговых клетках. И всё для того, чтобы запомнить то, что означает хотя бы часть из 6523 XML-ных тэгов и неявных связей между ними. А также мне необходима НИРИАЛЬНО мощная интуиция, чтобы по стектрейсу в 5 экранов находить причину обвала в чужом коде хотя бы за 1 день.
Математика (в т.ч. дискретная) нужна только в свободное от работы время.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Увы и ах. Когда я придумывал и делал алгоритм расчёта оптимальной проводки в ХХХ — я не знал что это было время, когда я был щаслив. А сейчас (то есть прямо ща для выполнения задач, стоящих передо мной) мне нужно просто много (ОЧЕНЬ МНОГО) памяти, и не той, что в мегабайтах, а той, что в мозговых клетках. И всё для того, чтобы запомнить то, что означает хотя бы часть из 6523 XML-ных тэгов и неявных связей между ними. А также мне необходима НИРИАЛЬНО мощная интуиция, чтобы по стектрейсу в 5 экранов находить причину обвала в чужом коде хотя бы за 1 день.
Ужас какой! Что НИРИАЛЬНО много платят?
LCR>Математика (в т.ч. дискретная) нужна только в свободное от работы время.
AndrewVK пишет: > Здравствуйте, Сергей Туленцев, Вы писали: > > AVK>>Воот. Это тоже показатель. > > СТ>Показатель чего? > > Обсуждаемого в этом треде.
вовсе не для того тред был предназначен, если на то пошло
vdimas пишет: > Виновата в этом однообразная работа по реализации похожих решений, > особенно на среднем уровне реализации. Суть моего недовольства в том, > что на существующем инструментарии невозможно достаточно хорошо повторно > использовать код, т.е. написание некоей мега-либы — это утопия при > нынешнем раскладе. Вот и хочется взамен библиотек кода иметь > параметризуемые библиотеки идей/шаблонов. (Rational и прочее смотрю > регулярно)
OMG вроде этим занимаются
Sinclair пишет: > Ну, в список моих Проектов, Которыми Заняться На Пенсии входит в том > числе и optical diagram recognition. Ну то есть распознавалка диаграммов > — ты типа рисуешь на салфетке/тачскрине/планшете свои каракули, а > софтина это превращает в аккуратные Collaboration Diagram, Deployment > Model, Class Model, ER Diagram, блок-схемы, Use-Case и прочее. > Существующие тулзы для диаграмминга невыразимо ужасны.
Лучше сделать интерактивный распознаватель для таблеток. Например, для
устройств электронная бумага + стилус, а сейчас есть такие. Электронная
бумага удобна для глаз, а стилус — для рук.
McSeem2 пишет: > MS>>В общем, по совокупности флейма ты уже все понял: языки — фуфло, > алгоритмы с математикой — рулят. > AVK>Это в твоей сфере интересов. А в других случаях может быть с > точностью до наоборот. > > Искренне не понимаю, как в профессии программиста может быть что-то > важнее алгоритмов. Алгоритмы — это основа. Это как арифметика. Уж извини > — если человек базовых алгоритмов не знает, то это не программист. Может > быть быдлокодер или говнокодер. Но базовый набор алгоритмов — это просто > некий минимум, примерно так же как физминимум Ландау. Короче, я чувствую > мне пора браться за дело. По алгоритмам.
А как же SWE? Тоже фундаментально. > Понимашь-ли, когда человек > спрашивает — что важнее, C++ или C# — мне хочется дать ему по морде и > наставить на путь истинный. И ответить — изучай Фортран, родной.
Таки хотелось бы услышать пожелания к языку. Что приоритетно, чем можно
пожертвовать. Что было бы неплохо иметь так, чисто для души. Форумом
тоже пользоваться надо уметь. Если так распыляться, чего можно
достигнуть? Ну можно послушать hot topics наших времён.
Так уж получается, что идеала нету. Для языков в своём многообразии
справедлив принцип водяного матраца. Вот взять, например, функции R->R.
Можно взять и рассмотреть все функции, которые можно выразить формулами
без интегралов. Не буду говорить строго формально, ни к чему это сейчас.
Получается довольно большое разнообразие. Из разных функций легко
синтезируются всякие другие. Умножение, сложение, ничто нас не
ограничивает. Но очень скоро может потребоваться решать, назовём их,
обратные задачи. Прямая задача — это синтез функции, а обратная —
распознавание её свойств. И если нам нужны хорошие обратные свойства, то
придётся пожертвовать прямыми. Скажем, если в гравитационном
взаимодействии участвуют три тела, то два из них могут вращаться друг
вокруг друга, пока не встретят третье, и тогда один из них поменяет
спутника. Всё это красиво смотрится, да вот только в общем виде узнать
формулы для координат от времени не получается. А это налагает
ограничения. На количество тел, например. Из–за потребности в обратных
свойствах львиная доля математики оперирует с так или иначе
ограниченными объектами. С многочленами вместо произвольных
дифференцируемых (опять ограничение) функций. Или с матрицами вместо
произвольных функций вектор->вектор.
Вот также и у языков есть роза ветров, набор решений времени
проектирования, которые делают один непохожим на другой. И не только сам
язык, но и методологию разработки. Если поднажать на типизацию, то
выиграем в раннем обнаружении ошибок. Но и потеряем. Интерфейс
типизированных объектов должен быть доступен компилятору, в процессе
выполнения не может меняться. В одних языках можно прозрачно подключать
плагины, в том смысле, что набор доступных возможностей не уменьшается
от того, были ли известен набор модулей на момент компиляции. В
некоторых также можно прозрачно пересекать границы процессов. Конечно,
небесплатно. По разным вопросам приняты разные решения. И думать надо в
терминах этих самых решений времени проектирования, а не в терминах фич
или некоей абстрактной мощности. Если использовать какой–то язык, то для
эффективного использования нужно уловить его дух и работать в гармонии с
ним. Но лучше делать это в другом порядке, сначала определиться, что
требуется или чего хочется, а уже потом попытаться этим эффективно
воспользоваться. Ну тут вторичные факторы вроде набора библиотек да
наличия компиляторов могут сыграть свою роль. Впрочем, это опять вопрос
приоритетов, только уже при более комплексном рассмотрении
язык+компилятор+библиотеки+IDE+GUI builder+... Формально ищется язык, на
фактически–то нужен комплект, я так понимаю. И, что касается комплектов,
то по–прежнему справедлив принцип водяного матраца. Если написание
компилятора сравнительно сложно, то разнообразие компиляторов/платформ
может быть ниже, чем для языка, более лёгкого в реализации. Как правило,
более лёгкие в реализации языки в чём–то проигрывают при написании
програм на них, ничего задаром не даётся.
С другой стороны, поощрительно комбинировать разные языки, особенно со
слабым перекрытием розы ветров. Если впутывать много языков, получается,
гм... наверное, бардак должен получаться. Я считаю, выгоднее
задействовать мало языков, но с бОльшим объёмом кода на каждом из них,
чем наоборот. Вроде очевидно, но утверждать не стану.
С третьей стороны, сам программист волен выбирать, чем заниматься.
Выбирать работу, хотя бы. Занятие любимой работой даёт человеку Позитив
и Душевную Гармонию. И, судя по
Пишу в принципе небольшие программки, в основном для себя
это как раз тот случай. Поэтому аргументы вроде
Сам посуди — вот ты пишешь на таком супер-языке, мотивация к
поддержке которого утрачена, а потом раз — и напарываешься на баг в
компиляторе — и чего? Подождать следующей версии — а будет ли она,
следующая версия? Потребовать hotfix — у кого потребовать? А у тебя эта
программа качает миллион баксов ежедневно.
в изначальном контексте неактуальны.
Я считаю, увлечённый программист так или иначе предрасположен к
чему–либо. Не к языку, к методологии. Становятся же почему–то одни
пекарями, а другие плотниками. И пекарю не нужен рубанок, как бы много
плотников вокруг не пыталось ему этот рубанок продать. А если не искать
себя, подстраиваться, то плотник, может, и получится, но это будет не
довольный жизнью плотник. Впрочем, это не мешает пекарю быть плотником
по совместительству. Да, по совместительству.
Здравствуйте, vdimas, Вы писали:
G>>Уж не говоря о том, что при отдельном домене мы налетаем на маршалинг данных, что для многих сценариев скриптинга очень дорого.
V>Хе, мы на маршаллинг в любом случае налетаем, т.к. обработка GUI-событий и исполнение скриптов идут в разных тредах. А "внутри" скопиллированного скрипта зачем маршаллинг?
В случае Явы на маршалинг мы не налетаем. Данные между тредами маршалить не обязательно. И гуя тут не причем — скрипты идут в одном треде с логикой. Сколько междоменный маршалинг стоит — возьми и померяй. Мы меряли в свое время. Примерно в 10 раз на ровном месте — катастрофа, если кастомный маршалинг не применять. Да и тот не радикально поправляет ситуацию.
Здравствуйте, OCTAGRAM, Вы писали:
OCT>Sinclair пишет: >> Ну, в список моих Проектов, Которыми Заняться На Пенсии входит в том >> числе и optical diagram recognition. Ну то есть распознавалка диаграммов >> — ты типа рисуешь на салфетке/тачскрине/планшете свои каракули, а >> софтина это превращает в аккуратные Collaboration Diagram, Deployment >> Model, Class Model, ER Diagram, блок-схемы, Use-Case и прочее. >> Существующие тулзы для диаграмминга невыразимо ужасны. OCT>Лучше сделать интерактивный распознаватель для таблеток. Например, для OCT>устройств электронная бумага + стилус, а сейчас есть такие. Электронная OCT>бумага удобна для глаз, а стилус — для рук.
Ну, распознавалке более-менее всё равно, с чего работать. Есть два класса алгоритмов — одни работают со статической картинкой (распознавание фото/скана), а другие — интерактивные.
Те, которые вторые, могут работать с тачскрина, электробумаги, планшета, или вот такого whiteboard. Их я и имел в виду.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
MS>В общем, по совокупности флейма ты уже все понял: языки — фуфло, алгоритмы с математикой — рулят. И не надо меня убеждать, что есть математики, которые пишут говённый код — бывают такие, но они при этом и математики тоже говённые. А уж язык — C++ или C# или Java — это дело десятое, не стоящее даже обсуждения. Ни одна конкретная программа ни на одном конкретном языке не живет достаточно долго. А вот, скажем, алгоритм поиска маршрута имени Дейксты будет жить вечно. Я не призываю все щас бросить и начать изобретать гениальные алгоритмы — это невозможно, да и не нужно. Но вот изучать алгоритмы — это первейшая задача человека, считающего себя программистом. А языки — это дело наживное.
Не, алгоритмами далеко всё не исчерпывается. Мне вот интереснее придумывать даже не то, какой алгоритм конкретно здесь применить, а выбрать такие 20% функций, которые покроют 80% потребностей.
Мне твой антигрейн нравится не тем, как ты ловко там обобщаешь брезенхема для произвольных кривых четвертого порядка, а тем, что при помощи него можно делать новый класс пользовательских интерфейсов.
Мне твой подход к сглаживанию шрифтов нравится не математикой, а пониманием того, что вертикальное разрешение менее важно горизонтального, что хорошо совпадает с низкоуровневым устройством современных мониторов.
И вот я считаю в работе разработчика именно это умение важнее даже, чем знание алгоритмов. Все алгоритмы знать всё равно нельзя.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
K>>, комбинаторная логика, функциональное и логическое программирование это все разделы дискретной математики.
AVK>Как бы тебе попроще объяснить. Ну вот, к примеру, реляционная алгебра безусловно важный раздел математики. Но в реальных современных РСУБД все очень далеко от теории. Поэтому эту самую реляционную алгебру конечно понимать нужно, но все ее изыски в разработке не нужны, зато нужна масса всего другого, что к математике отношения не имеет. Поэтому да, дискретку в базовом объеме знать нужно, но упираться в ее доскональное изучение, да еще и в ущерб тем же языкам не видтся мне разумн6ой стратегией.
А самое смешное, что даже знание РСУБД оно опять же подобно флюсу. Я много лет считал, что РСУБД — это наше всё, как механизм эффективного выполнения декларативных запросов.
А потом узнал, что РСУБД даже в самой широкой трактовке работают только с очень узким классом запросов, и что реальные нужды пользователей не исчерпываются where и group by.
Если смотреть на РСУБД с такой точки зрения, то это как бы огромный объем знаний, посвященный узкой тематике. Это всё опять про "сравнение строк на ассемблере".
Это катастрофическая дилемма — как сочетать глубокое знание молотка с умением видеть вокруг что-то, кроме гвоздей. Это не математика, а скорее лингвистика, как умение переводить идеи с одного языка на другой с минимальной потерей информации.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Это катастрофическая дилемма — как сочетать глубокое знание молотка с умением видеть вокруг что-то, кроме гвоздей. Это не математика, а скорее лингвистика, как умение переводить идеи с одного языка на другой с минимальной потерей информации.
Угу. Единственный правильный выход сейчас, ИМХО — замена ручного молотка на автоматический с микропроцессором унутре.
Здравствуйте, Sinclair, Вы писали:
S>Мне твой подход к сглаживанию шрифтов нравится не математикой, а пониманием того, что вертикальное разрешение менее важно горизонтального, что хорошо совпадает с низкоуровневым устройством современных мониторов. S>И вот я считаю в работе разработчика именно это умение важнее даже, чем знание алгоритмов. Все алгоритмы знать всё равно нельзя.
Какой же ты программист? Ты — менеджер или директор типа Билла Гейца. А я — больше инженер типа Джима Блинна.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали: MS>Какой же ты программист? Ты — менеджер или директор типа Билла Гейца. А я — больше инженер типа Джима Блинна.
Не, до Гейца мне еще очень далеко.
К тому же я слишком сильно погружаюсь в детали. Мне недостаточно описать в общем виде требования к API, я начинаю вмешиваться во все эти тонкие детали, всякие 300 Multiple Found, 307 Retry at other location и прочее.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Не, до Гейца мне еще очень далеко. S>К тому же я слишком сильно погружаюсь в детали. Мне недостаточно описать в общем виде требования к API, я начинаю вмешиваться во все эти тонкие детали, всякие 300 Multiple Found, 307 Retry at other location и прочее.
Осторожнее, не попади в засаду микроменеджмента.
V>>Хе, мы на маршаллинг в любом случае налетаем, т.к. обработка GUI-событий и исполнение скриптов идут в разных тредах. А "внутри" скопиллированного скрипта зачем маршаллинг?
G>В случае Явы на маршалинг мы не налетаем. Данные между тредами маршалить не обязательно. И гуя тут не причем — скрипты идут в одном треде с логикой. Сколько междоменный маршалинг стоит — возьми и померяй.
Дык, кто мешает логику в том же домене держать? Не вижу проблемы, учитывая staless-модель масштабируемых приложений. На современном компе в одном домене можно скомпиллировать порядка сотни тысяч уникальных скриптов, перед тем, как сбросить домен и начать новый. У вас всё-равно столько уникальных скриптов не наберётся. После сброса домена единственная задержка — это на заполнение кешей частоиспользуемых данных. Если же ваша "логика" локальных кешей ощутимого размера не хранит, то сброс домена даже и не почувствуется. Например, для сборок, лежащих в GAC, JIT-компилятор работает глобально на процесс, т.е. однажды скомпиллированный джиттером код является общим для всех доменов, поэтому, использование в новом домене однажды проджитенных классов потребует ровно ноль времени на инициализацию. Так что, выделяете свою базовую "логику" в подписанные сборки — и только вперёд.
Здравствуйте, Niovol, Вы писали:
N>Несколько лет программировал на С++. Устал от его корявости. Искал другой язык, более выразительный. Сначала наткнулся на D. Думал — все, нашел, что искал. Но мне не понравились 2 вещи: язык постоянно меняется, стабильности никакой. Ну и нету IDE нормального. Решил, что так дело не пойдет. Потом посмотрел на RSDN, тут расхваливают nemerle. Почитал, попытался вникнуть в примеры. Довольно приличный язык. И как раз узнаю, что разработчики отказались от языка. Никто теперь не продвигает его, он не достиг еще 1 версии, хоть как я понял, язык сформировался, а компилятор неоптимизированный. Плюс к тому интеграции с VS2008 не будет. N>Пишу в принципе небольшие программки, в основном для себя, самое большое — несколько тысяч строк. Но это на С++, на тех же D или nemerle было бы явно меньше. N>Вот хотел спросить совета, лучше пытаться переходить на какой-нибудь другой язык или оставаться программировать на с++?
Судя по размеру треда, вам насоветовали целую кучу всяких разных языков. Помимо всего прочего я бы рекомендовал обратить внимание на старый добрый Си. После Си++ он кажется исключительно цельным и продуманным. Программируешь и получаешь эстетическое наслаждение.
Hello, Sinclair!
You wrote on Fri, 14 Mar 2008 13:38:36 GMT:
S> Ну, в список моих Проектов, Которыми Заняться На Пенсии входит в S> том числе и optical diagram recognition. Ну то есть распознавалка S> диаграммов — ты типа рисуешь на салфетке/тачскрине/планшете свои S> каракули, а софтина это превращает в аккуратные Collaboration S> Diagram, Deployment Model, Class Model, ER Diagram, блок-схемы, S> Use-Case и прочее.
На каком-то уровне подобное есть в Visual Paradigm: можно связать разные "каракули" с определенными объектами и рисовать их мышью — Mouse gestures. По идее никаких препятствий взять сенсорный дисплей и рисовать от руки нет.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Gaperton, Вы писали:
G>>JFYI: Динамический инлайнинг виртуальных функций на новых процах уже не даст выраженного преимущества JIT, так как мне из достоверных источников известно, что разработчики процессоров уже научились делать предвыборку и предсказания по косвенным джампам. Специально для того, чтобы понизить цену виртуального вызова. Насколько я слышал краем уха, в процах последней линейки эта фича уже есть. Они ведь тоже ориентируются на производительность реальных приложений. C>Это еще в вроде бы P4 было, я про это даже сюда как-то писал. Там фича в том, что таблица предсказателя — она не бесконечная, сам предсказатель не идеальный, и сам косвенный вызов становится дешевле, но не совсем бесплатным. Так что инлайнинг помогает.
Это вообще свойство архитектуры IA-32, если не ошибаюсь. В NetBurst просто тупо увеличили размер буфера меток перехода. Что касается
G>>А для инлайна статических вызовов, раскрутки циклов, и распределения регистров (которых в x86 неприлично мало) у нормалного компилятора есть гораздо больше времени, чем у JIT. И на оптимальную кодогенерацию у него также гораздо больше времени, чем у джит. Скажем, IC++ учитывает такое количество факторов при кодогенерации, которое JIT-у в реальном времени учесть просто не под силу. C>Только большую часть этих фич можно предрассчитать заранее В частности, это одна из причин почему в Java 7 вводят систему модулей, которые будут работать наподобии сборок в .NET. Модули можно будет заранее слинковать и кэшировать для них оптимизированый код.
G>>Так что такие разговоры — скорее умный маркетинговый ход. Когда увижу, что джит убедительно обойдет IC++ на приложениях вроде SPEC — тогда можно будет отнестись к тому серьезно. Я думаю, так. C>Еще нужно учесть фичи типа обязательной проверки границы в массивах в Java, отсутствие указателей и т.п.
Операция проверки — одна инструкция, теряющаяся на фоне операций над данной ячейкой, которой получаем доступ в цикле к примеру. За счет Intel C++ может обойти jdk — это за счет использования особых инструкций, например на играх раз уж о них зашла речь использование SSE дает нехилый процент. Но конечно, возможность обсчета графики на проце сегодня уже малоактуальна, особенно с появлением шейдеров четвертой версии.
C>В Erlang'е все хорошо из-за того, что объекты иммутабельны — там можно выполнять упрощенный вариант трехцветного mark&sweep.
Раз объекты не меняются, значит есть возможность использовать конкурентную сборку без синхронизаций, ведь так? Собственно, тут даже не в иммутабельности дело, а в том что они final. GC абсолютно пофигу меняется объект или нет, ему главное знать при параллельной сборке, что ссылки будут указывать на те же объекты, т е чтобы отсеять ситуации типа
obj = new Object1();
obj = new Object1();
А это говорит о том, что если писать с использованием final, то большой разницы нет (при условии что в компиляторе это учитывается).
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Gaperton, Вы писали:
V>Не обойдёт никогда. Я плотно занимаюсь процессингом сигналов, так вот, .Net сливает заметно. ИМХО, основная причина слива — это постоянная проверка выхода за границы массива. Т.к. вся обработка сигналов — это переливание из буферов в буфера с обработкой, учитывая, что математическая составляющая обработки тривиальна, и не может быть сильно загублена JIT-ом, то вот в этих проверках выхода за пределы и кроется главный тормоз.
Никак не пойму, почему эта тривиальная проверка состоящая из одной инструкции cmp, которая теряется на фоне обработки элемента по полученному индексу, должна быть источником замедления? Если нужен повторный доступ, то можно скопировать ссылку на объект, опять несколько инструкций.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, LaPerouse, Вы писали:
LP>Никак не пойму, почему эта тривиальная проверка состоящая из одной инструкции cmp,
+ conditional jump
LP>которая теряется на фоне обработки элемента по полученному индексу, должна быть источником замедления?
Где то давно пробегало — народ тестил. У них замедляло.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, LaPerouse, Вы писали:
LP>>Никак не пойму, почему эта тривиальная проверка состоящая из одной инструкции cmp, CC>+ conditional jump
Ну да, только вот в скольки случаях будет наблюдаться IndexOfBoundsException? В очень и очень редких случаях, так что уже после первой итерации метка на нужный переход будет сидеть в буфере меток процессора. Итого имеем 2 операции.
LP>>которая теряется на фоне обработки элемента по полученному индексу, должна быть источником замедления? CC>Где то давно пробегало — народ тестил. У них замедляло.
На тривиальных примерах может и заметно.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Социализм — это власть трудящихся и централизованная плановая экономика.
LP>>>которая теряется на фоне обработки элемента по полученному индексу, должна быть источником замедления? CC>>Где то давно пробегало — народ тестил. У них замедляло.
LP>На тривиальных примерах может и заметно.
На тривиальных примерах может и не заметно, хотел сказать.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Социализм — это власть трудящихся и централизованная плановая экономика.
LP>Никак не пойму, почему эта тривиальная проверка состоящая из одной инструкции cmp, которая теряется на фоне обработки элемента по полученному индексу,
Не теряется, а выполняется за то же время примерно, если мы умножаем на коеф или прибавляем значение поэлементно, я же сказал, что для тривиальной мат-обработки — это ощутимо.
LP>Если нужен повторный доступ, то можно скопировать ссылку на объект, опять несколько инструкций.
Речь идёт о "числодробилках", мы обсуждали ситуацию обработки чисел в массивах.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, WolfHound, Вы писали:
WH>>Здравствуйте, AndrewVK, Вы писали:
AVK>>>Эта "гениальная" мысль приходит в голову почти всем программерам поначалу. WH>>Во-во... только если еще немного подумать понимаешь что текст + IDE которая все парсит на лету заруливают все эти семантические графы на раз.
V>Это ты как определил? Тебе уже было с чем сравнить? V>Я вот даже с самым крутым IDE не могу избавиться от ощущения постоянной обезъяней работы, причём везде, начиная от проектирования, и заканчивая кодированием.
Eclipse и jdt использовал? Обезьяней работы минимум, если речь идет именно о набивке кода (не принимая в расчет ограничения и недостатки языка). Написал тест, прошелся по нему, нажимая Ctrl+1 на каждой строчке и можешь релизить проект
Все упирается совсем не в представление кода, а в семантику и проблемы предметной области.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Социализм — это власть трудящихся и централизованная плановая экономика.
YК>На каком-то уровне подобное есть в Visual Paradigm: можно связать разные "каракули" с определенными объектами и рисовать их мышью — Mouse gestures. По идее никаких препятствий взять сенсорный дисплей и рисовать от руки нет.
Интересное решение. Действительно, рисовать диаграммки — весьма нудно и непроизводительно, поэтому часто поступают наоборот, через reverese engineering, а тут такая интересная попытка.
AVK>Вот не было изначально такого вопроса. Было "языки — фуфло, алгоритмы с математикой — рулят". AVK>Это еще, кстати, если не вспоминать, что алгоритм это последовательность шагов и как он рулит в декларативных языках — большой вопрос.
Ну дык нужно как минимум понимать алгоритм работы ядра декларативного языка, а для этого некий базис по алгоритмам должен уже быть. К тому же, чисто декларативный язык — это исследовательская игрушка не более, все коммерчесские реализации Пролога, например, имеют императивные ср-ва, без которых банально ни GUI не нарисовать, ни вычислений в цикле не сделать.
K>> ИМХО дискретка нужна обязательно
AVK>Нужна. Но во вполне скромном объеме. И не вся. Залитую в меня в больших количествах теорию вероятности, матстатистику и теорию СМО можно было бы и поурезать.
Как это CMO урезать для программиста?
А первые две области — это как раз базис для последней.
Вот попытался вспомнить, что было лишнее в моём образовании в ВУЗе, и не могу вспомнить, практически всё пригодилось.
Формальные грамматики и теория построения компиляторов — с завидной регулярностью приходится упражняться.
Статистика и тервер — вообще базис для многих прикладных вещей.
СМО — пришлось углубиться гораздо серьёзнее чем давали в ВУЗе, при расчётах и моделировании системы транкинговой связи в своё время.
Обработка сигналов — вот как раз последний проект с аудио-видео конференциями потребовал поупражняться.
Линейное программирование — пригодилось дважды, один раз — для программки раскроя листов жести, другой раз — для модуля управления запасами производственной фирмы.
Единственно, с чем еще не работал всерьез из того, что давали в ВУЗе — это с базами знаний, нечёткой логикой и ИИ, только на уровне развлечений в свободное время, но не факт что не потребуется в очередном проекте, ибо эти темы всё популярнее со временем.
AVK>Как бы тебе попроще объяснить. Ну вот, к примеру, реляционная алгебра безусловно важный раздел математики. Но в реальных современных РСУБД все очень далеко от теории. Поэтому эту самую реляционную алгебру конечно понимать нужно, но все ее изыски в разработке не нужны,
Это если программист позиционирует себя как пользователь SQL-запросов, а если он движок БД пишет, то разбираться в реляционной алгебре придётся.
А вообще спор странный у вас выходит. Понятное дело, что составляющая предметной области в каждом конкретном проекте может сильно отличаться от того, что давали в универе. Но в универе дают самые, на мой взгляд, базовые знания, которыми надо будет пользоваться как инструментом. базовая дискретка — это алфафит, структуры данных и алгоритмы Кнута — это уровень №0, та же реляционная алгебра банально учит работать с массивами структурированных данных через абстракции отношений, и работа с БД тут не при чём, иногда и в памяти надо уметь обрабатывать данные. Без СМО до конца не представить даже суть работы оконной системы Windows, не говоря уже о серверных приложениях и т.д. И вообще, разве много этого даётся в ВУЗе? 40 часов практики на упомянутую реляционную алгебру и столько же практики по СМО — это смешно, тут даже нечего обсуждать. Просто слегка познакомили с предметом и всё.
AVK>Опять же спорно. Главное что там лежит — не математика, а скорее понимание человеческого мышления. Та же теория формальных грамматик помнишь для чего создана была? А уж математика там, постолько поскольку иногда удается ее пристегнуть к той или иной идее.
Да ладно, просто "это" прикладная математика, а "та" — фундаментальная.
DM>>И что подойдет в качестве оного?
AVK>Видимо сильно продвинутый оптимизатор.
Программист и есть тот самый оптимизатор. В идеале, поставновщик задачи выступает спецом по предметной области, программист должен владеть предметной областью на уровне достаточным для общения с постановщиком задачи. Просто зачастую эта модель в софтовых конторах нарушена, поэтому и возникают подобные обсуждения.
Здравствуйте, vdimas, Вы писали:
V>Это если программист позиционирует себя как пользователь SQL-запросов, а если он движок БД пишет, то разбираться в реляционной алгебре придётся.
Тоже по большей части в азах.
V>А вообще спор странный у вас выходит. Понятное дело, что составляющая предметной области в каждом конкретном проекте может сильно отличаться от того, что давали в универе. Но в универе дают самые, на мой взгляд, базовые знания, которыми надо будет пользоваться как инструментом.
Речь, вобще то, не о знаниях в универе, а о математике. Безотносительно универа.
Здравствуйте, vdimas, Вы писали:
V>Ну дык нужно как минимум понимать алгоритм работы ядра декларативного языка, а для этого некий базис по алгоритмам должен уже быть.
А про базис никто и не спорит.
V> К тому же, чисто декларативный язык — это исследовательская игрушка не более, все коммерчесские реализации Пролога, например, имеют императивные ср-ва, без которых банально ни GUI не нарисовать, ни вычислений в цикле не сделать.
Ты кроме Пролога других декларативных языков не знаешь? А вот янус, к примеру, обходится рамками SQL'92, а он полностью, на 100%, декларативный.
AVK>>Нужна. Но во вполне скромном объеме. И не вся. Залитую в меня в больших количествах теорию вероятности, матстатистику и теорию СМО можно было бы и поурезать.
V>Как это CMO урезать для программиста?
Так что СМО для программиста 2 семестра читать не надо, нафик не нужна ему вся эта аналитика, потому что даже примитивный двухуровневый кеш процессора уже аналитически описать практически не возможно. А для численного моделирования и знания базовых характеристик зубрить хитромудрую высшую математику совершенно без надобности.
V>А первые две области — это как раз базис для последней.
Ты думаешь я этого не знаю? Только вот базис это одно, а, скажем, моменты высших порядков и вся тряхомудия вокруг них, это уже немножко другое.
V>> К тому же, чисто декларативный язык — это исследовательская игрушка не более, все коммерчесские реализации Пролога, например, имеют императивные ср-ва, без которых банально ни GUI не нарисовать, ни вычислений в цикле не сделать.
AVK>Ты кроме Пролога других декларативных языков не знаешь? А вот янус, к примеру, обходится рамками SQL'92, а он полностью, на 100%, декларативный.
А как же работа с курсорами в нём? Да и вообще, там важна именно последовательность выражений, так что полностью декларативным его назвать сложно. Просто у него там уровни есть, если не ошибаюсь, на каком-то уровне отсутствуют динамические выражения. Но чуствительность к последовательности всё-равно никуда не девается.
Я читал этот документ, причем очень подробно. Теперь ты почитай, о каких курсорах там речь и что с ними можно делать. Никаких циклов по ним, как в каком нибудь T-SQL, там нет.
Ну и самое главное — в янусе курсоры не используются.
... <<RSDN@Home 1.2.0 alpha 4 rev. 1058 on Windows Vista 6.0.6001.65536>>
AVK>Я читал этот документ, причем очень подробно. Теперь ты почитай, о каких курсорах там речь и что с ними можно делать. Никаких циклов по ним, как в каком нибудь T-SQL, там нет.
Речь об императивности операций:
— открыл курсор
— установил на нужную позицию
— выполнил некоторые операции с курсорами
— закрыл
А еще бывает простая форма CASE выражений, по сути — это функциональный оператор ветвления, и циклы делаются через рекурсивный вызов процедур.
AVK>Ну и самое главное — в янусе курсоры не используются.
Несомненно, относительно к SQL'92 это самое главное.
Здравствуйте, vdimas, Вы писали:
V>Речь об императивности операций: V>- открыл курсор V>- установил на нужную позицию V>- выполнил некоторые операции с курсорами V>- закрыл
Ну и что? Этого недостаточно для императивности.
V>А еще бывает простая форма CASE выражений, по сути — это функциональный оператор ветвления
И по сути и по форме это паттерн-матчинг классический. Декларативность в чистом виде.
V>, и циклы делаются через рекурсивный вызов процедур.
Чистые функциональные языки вобще то являются декларативными. Не знал?
AVK>>Ну и самое главное — в янусе курсоры не используются.
V>Несомненно, относительно к SQL'92 это самое главное.
Это главное относительно практической применимости декларативных языков. Как видишь, все прекрасно работает и без императивных расширений.
... <<RSDN@Home 1.2.0 alpha 4 rev. 1063 on Windows Vista 6.0.6001.65536>>
V>>Речь об императивности операций: V>>- открыл курсор V>>- установил на нужную позицию V>>- выполнил некоторые операции с курсорами V>>- закрыл
AVK>Ну и что? Этого недостаточно для императивности.
У нас есть переменные, которые хранят состояния (не только состояния курсоров, кстати), мы в коде указываем последовательность действий (fetch next .., update .., fetch next .., select into и т.д.), промежуточные результаты можем хранить в обычных переменных и использовать далее, это получился обычный последовательный алгоритм, тут даже обсуждать нечего.
V>>А еще бывает простая форма CASE выражений, по сути — это функциональный оператор ветвления
AVK>И по сути и по форме это паттерн-матчинг классический. Декларативность в чистом виде.
Тогда switch/case в С# тоже декларативный, и даже простой оператор if, я ниже обобщу.
V>>, и циклы делаются через рекурсивный вызов процедур.
AVK>Чистые функциональные языки вобще то являются декларативными. Не знал?
Именно что чистые, не знал? А если в рекурсию можно передать ссылку на некоторое состояние для дальнейшей обработки, то там чистотой и не пахнет, получаем обычный алгоритм, изменяющий по шагам некоторое состояние. Декларативный язык — это тот, в котором задаются факты и правила, и ничего более. Думаешь, иммутабельность переменных в чистых функциональных языках — это следствие лишь повышения верицируемости программ? Иммутабельность переменных в чисто-функциональных языках — это аналог однажды утверждённого факта в логических, без этой иммутабельности не будет никакой декларативности.
AVK>Это главное относительно практической применимости декларативных языков. Как видишь, все прекрасно работает и без императивных расширений.
Угу, а позиции оппонентов весьма принципиальны.
Да, я уже соглашался, что некоторые конструкции из SQL образуют чисто декларативное подмножество, в SQL'92 ему соотвествует начальный уровень (уровни там всё же есть, однако).
Тем не менее, элементы этого языка ты используешь в блоках императивного кода, SQL-запросы — это просто высокоуровневое АПИ к базе данных, подобие контракта. Разумеется, что сами контракты (те же интерфейсы в С#) — это всегда декларативность, более того, простой оператор присваивания в отрыве от контекста — тоже весьма себе такая декларативная конструкция. Вряд ли ошибусь, если предположу, что практически любые высокоуровневые конструкции в языках того самомого высокого уровня — это 100%-но декларативные конструкции. Императивность образует способ использования этих операторов, который выливается в конечном итоге в цепочку действий по изменению некоторого состояния.
В общем, позволю себе остаться при своём, что сами по себе декларативные языки без императивной поддержки пока что мало полезны, и твой Янус — неплохой тому пример.
Здравствуйте, vdimas, Вы писали:
V>У нас есть переменные, которые хранят состояния (не только состояния курсоров, кстати)
В декларативных языках не может быть переменных с состояниями? Это что то новенькое.
V>, мы в коде указываем последовательность действий (fetch next .., update .., fetch next .., select into и т.д.),
Последовательность действий не есть обязазательный признак императивности.
V> промежуточные результаты можем хранить в обычных переменных и использовать далее, это получился обычный последовательный алгоритм, тут даже обсуждать нечего.
То есть MSBuild или там Ant — императивные языки, потому что в них есть переменные с изменяемым состоянием?
AVK>>И по сути и по форме это паттерн-матчинг классический. Декларативность в чистом виде.
Это V>Тогда switch/case в С# тоже декларативный
Да, если убрать императивные конструкции вроде break внутри кейсов.
V>, и даже простой оператор if
Тоже да при том же условии.
AVK>>Чистые функциональные языки вобще то являются декларативными. Не знал?
V>Именно что чистые, не знал?
А рекурсия есть и в чистых тоже.
V> А если в рекурсию можно передать ссылку на некоторое состояние для дальнейшей обработки
Ссылка в SQL??? Курсоры это никакая не ссылка, это лишь твое предположение. Поскольку там не императивный код, что там реально внутри движка будет происходить, еще большой вопрос. В этом и есть главное отличие декларативных языков, ты описываешь что тебе надо, а не как это сделать.
V>Декларативный язык — это тот, в котором задаются факты и правила, и ничего более.
In computer science, a declarative programming language is a high-level language that describes a problem rather than defining a solution — it makes use of declarative programming. A declarative programming language says "what", while an imperative programming language says "how".
Поэтому да, наверное курсоры не очень не очень декларативная конструкция, но их все равно сейчас не используют почти. Так что твое заявление о том, что чисто декларативный язык это игрушка, мягко говоря не очень верное. Не нравится SQL — возьми какой нибудь IDL, он, надеюсь, у тебя не императивный?
V> Думаешь, иммутабельность переменных в чистых функциональных языках — это следствие лишь повышения верицируемости программ? Иммутабельность переменных в чисто-функциональных языках — это аналог однажды утверждённого факта в логических, без этой иммутабельности не будет никакой декларативности.
Это все зависит от точки зрения. Трактуй оператор перемещения позиции курсора не как изменение состояния существующего курсора, а как создание нового курсора с другим состоянием, но тем же именем, и, вуаля, иммутабельность соблюдена. И, заметь, в отличие от какого нибудь С++, такое поведение в случае сиквеля никак стандартом не запрещено.
V>Да, я уже соглашался, что некоторые конструкции из SQL образуют чисто декларативное подмножество
И этого множества вполне достаточно для практического применения.
V>Тем не менее, элементы этого языка ты используешь в блоках императивного кода
Ну и что? Это же не значит, что SQL не применим на практике.
... <<RSDN@Home 1.2.0 alpha 4 rev. 1067 on Windows Vista 6.0.6001.65536>>
AVK>Это все зависит от точки зрения. Трактуй оператор перемещения позиции курсора не как изменение состояния существующего курсора, а как создание нового курсора с другим состоянием, но тем же именем, и, вуаля, иммутабельность соблюдена. И, заметь, в отличие от какого нибудь С++, такое поведение в случае сиквеля никак стандартом не запрещено.
Да при чём тут стандарт? Оператор присваивания в условии иммутабельности можно рассматривать как предикат, как условие, типа пусть А будет равно тому то, т.е. это как упрощение в математических нотациях, не более. А в случае с курсором, мы говорим ему спозиционироваться на одну строку выборки, потом на другую, потом на последнюю или первую — как хотим, мы в любом случае указываем последовательность шагов для получения результата, вместо формулировки задачи. Независимо от реализации курсора в движке точка зрения на него не меняется.
Здравствуйте, vdimas, Вы писали:
V>Да при чём тут стандарт?
При том, что именно он определяет что такое С++, и что такое SQL.
V> Оператор присваивания в условии иммутабельности можно рассматривать как предикат, как условие, типа пусть А будет равно тому то, т.е. это как упрощение в математических нотациях, не более.
С полным сохранением семантики — не получится.
... <<RSDN@Home 1.2.0 alpha 4 rev. 1067 on Windows Vista 6.0.6001.65536>>
Здравствуйте, WolfHound, Вы писали:
WH>Кстати на этом проекте очень быстро появилось рукописное хранилище куда из оракла уехали блобы... иначе он вобще не жил.
Угу, сколько раз ломали тут уже копья и спорили, стоит ли большие бинарные данные хранить в MS SQL или Oracle, меня тут неоднократно опускали ниже плинтуса, когда я приводил пример, что сервер некоей учётной системы запросто стал жить на обычном железе, когда я хранение документов перенёс в ФС (с некоторой обвязкой версионности через БД)
WH>Короче: Имею Мнение Хрен Оспоришь что риски от использования немерла мягко говоря преувеличины. Как по мне они на уровне рисков при использовании C#.
По мне главный риск — это отсутствие инструментов типа решарпера и FxCorp сегодня и неопределённые планы относительно подобной поддержки на завтра. (Я перед началом нового проекта размышлял относительно N, но не решился именно из-за этих "мелочей", ибо дизайнеры и прочая остальная поддержка студии — это как раз относительно легко достижимо собственными силами).
Hello, vdimas!
You wrote on Fri, 25 Apr 2008 09:53:40 GMT:
WH>> Кстати на этом проекте очень быстро появилось рукописное WH>> хранилище куда из оракла уехали блобы... иначе он вобще не жил.
v> Угу, сколько раз ломали тут уже копья и спорили, стоит ли большие v> бинарные данные хранить в MS SQL или Oracle, меня тут неоднократно v> опускали ниже плинтуса, когда я приводил пример, что сервер некоей v> учётной системы запросто стал жить на обычном железе, когда я v> хранение документов перенёс в ФС (с некоторой обвязкой v> версионности через БД)
Хм, занятно (я про опускание). У меня перед глазами две специализированные системы ориентированные на хранение значительных объемов бинарных данных (по нескольку миллиардов объектов). Так вот. Для одной производитель прямо рекомендует использовать файловое хранилище вместо базы, если объекты большие. Другая хранит в базе, но поверх базы есть целая система хитрых кэшей и индексов.
Всякой какой-нить приблудой вокруг него 
!) консервативный GC. Поэтому и такие рекомендации.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
