Здравствуйте, WolfHound, Вы писали:
E>>Ну, когда средства разработки для Nemerle будут продаваться и окупать вложенные в них усилия, тогда и можно будет сравнивать успешность Nemerle и Eiffel-я. WH>Сравнивать успешность языков можно только по колличеству проектов на них сделанных.
Ну по этому показателю Nemerle до Eiffel-я еще расти и расти, и расти, и расти...
E>>Не могу сказать, что я понял условие, а уж что делает решение... E>>Где нибудь эта задача еще описана с тестовыми данными? WH>http://projecteuler.net/index.php?section=problems&id=178 WH>Легче стало?
Не-а, тестовых данных нет, проверять не на чем
E>>Если под инструментом понимать язык, то я не согласен с тем, что сложные задачи нужно модифицировать хост-язык собственными силами. Будь то Lisp или Nemerle. Кому-то этот подход может нравится, но я не из их числа. WH>Дело в том что в случае с немерле в отличии от лиспа в подавляющем большинстве случаев язык модифицировать не надо. WH>Лично я пока еще по делу не написал ни одного макроса. (ибо пока не писал на немерле ничего действительно большого) WH>Но скажем на прошлой работе если бы тот проект делался на немерле, а не на C# то по крайней мере одну макру я бы написал. Тем самым избавив себя и окружающих от кучи гемороя. WH>В томже компиляторе немерла есть несколько макросов которые добавляют к AST кучу тупых но весьма объемных методов. Писать их руками это полный звиздец. Генерить текст еще больший геморой.
Тогда в чем смысл вообще всей этой шумихи -- микроядро, расширяемость и пр. Если подавляющее большинство разработчиков используют готовые вещи в языке, то какая разница, на макросах эти вещи сделаны или нет?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Ну по этому показателю Nemerle до Eiffel-я еще расти и расти, и расти, и расти...
Напомни когда там Eiffel появился...
E>Не-а, тестовых данных нет, проверять не на чем
Если ты залогинен там есть такое маленькое окошечко куда ответ скормить можно...
В любом случае можно откомпилить мой пример заменив Sum64() на болие длинный аналог Fold(0L, (n, s) => s + n)
E>Тогда в чем смысл вообще всей этой шумихи -- микроядро, расширяемость и пр. Если подавляющее большинство разработчиков используют готовые вещи в языке, то какая разница, на макросах эти вещи сделаны или нет?
Проблема в том что когда вдруг стандартных вещей не хватает (а это иногда случается) то только микроядро с макросами и спасает.
Иначе куча траха на ровном месте.
В любом случае немерле сам по себе гораздо болие приятный язык нежели всякие там C#пы.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Но скажем на прошлой работе если бы тот проект делался на немерле, а не на C# то по крайней мере одну макру я бы написал. Тем самым избавив себя и окружающих от кучи гемороя.
Расскажи подробнее о проблеме.
Здравствуйте, EvilChild, Вы писали:
WH>>Но скажем на прошлой работе если бы тот проект делался на немерле, а не на C# то по крайней мере одну макру я бы написал. Тем самым избавив себя и окружающих от кучи гемороя. EC>Расскажи подробнее о проблеме.
Жестокое скрещивание ежа с ужом и моржом. Изменить дизайн было нельзя ибо это выходило боком в гаааааааааараздо болие большом объеме кода.
Короче copy&paste в промышленных объемах...
Если бы были макросы то этот копипаст сделали бы макросы.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Жестокое скрещивание ежа с ужом и моржом. Изменить дизайн было нельзя ибо это выходило боком в гаааааааааараздо болие большом объеме кода. WH>Короче copy&paste в промышленных объемах...
Проблему нельзя описать коротко или влом это делать?
Спрашиваю без всякого стёба. WH>Если бы были макросы то этот копипаст сделали бы макросы.
Моих ясновидческих способностей нехватило, чтобы вкурить о чём ты...
Здравствуйте, EvilChild, Вы писали:
EC>Проблему нельзя описать коротко или влом это делать? EC>Спрашиваю без всякого стёба.
Коротко нельзя да и НДА.
EC>Моих ясновидческих способностей нехватило, чтобы вкурить о чём ты...
В кучу классов пришлось скопировать кучу кода с минимальными переделками от класса к классу.
Если бы были макросы то этой тупой работой занимались бы они.
Причем сам понимаешь поддерживать такой код куда проще ибо для того чтобы что-то поменять нужно менять в одном месте, а не в паре десятков.
Благо этот ужос удалось локализовать в одной сборке.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Коротко нельзя да и НДА.
Тогда как аргумент в пользу макросов это звучит малоубедительно.
Давай лучше так — если есть время глянь здесь и скажи позволят ли макросы как-то улучшить решение там описанное.
Или можно ли на них реализовать это?
Здравствуйте, eao197, Вы писали:
E>Т.е. вы хотите сказать, что ни Eiffel, ни OCaml ну ни капельки не претендуют на нишу C++?
"C++ successor" их точно не называли.
E>Нельзя. Если бы вы внимательно посмотрели бы на ссылку, данную вам FR, то вы бы увидели: E>
E>C++ Templates
E>D templates have little in common with C++ templates, and it is very unlikely that any sort of reasonable method could be found to express C++ templates in a link-compatible way with D.
E>This means that the C++ STL, and C++ Boost, likely will never be accessible from D.
E>Без поддержки STL никакой интероп с C++ не будет полноценным.
В данном случае, автоматический маршалинг данных между основными типами коллекций STL и соответствующими типами D — этого было бы достаточно для большинства случаев.
E>Т.е. все ваши категоричные заявления выше по ветке нужно было воспринимать, как вашу личную точку зрения и все?
Правильно, это моя точка зрения. А какие могли быть другие варианты? Божественное откровение, выбитое на каменных скрижалях?
Здравствуйте, Andrei F., Вы писали:
AF>Здравствуйте, eao197, Вы писали:
E>>Т.е. вы хотите сказать, что ни Eiffel, ни OCaml ну ни капельки не претендуют на нишу C++?
AF>"C++ successor" их точно не называли.
А что, звание "С++ successor" автоматически подразумевает совместимость с C++?
Sun в свое время Java рекламировал как "исправленный C++", тем не менее, об прозрачном интеропе с C++ ни тогда, ни сейчас речи не было.
E>>Нельзя. Если бы вы внимательно посмотрели бы на ссылку, данную вам FR, то вы бы увидели: E>>
E>>C++ Templates
E>>D templates have little in common with C++ templates, and it is very unlikely that any sort of reasonable method could be found to express C++ templates in a link-compatible way with D.
E>>This means that the C++ STL, and C++ Boost, likely will never be accessible from D.
AF>В данном случае, автоматический маршалинг данных между основными типами коллекций STL и соответствующими типами D — этого было бы достаточно для большинства случаев.
Вы хоть сами-то представляете во что это выльется?
Если у меня C++ный класс возвращает ссылку на std::map с 30000 значений внутри, какая польза будет от маршалинга?
E>>Т.е. все ваши категоричные заявления выше по ветке нужно было воспринимать, как вашу личную точку зрения и все?
AF>Правильно, это моя точка зрения.
Если бы вы сразу написали:
А настоящее будущее, по-моему, — за Немерле или другими языками, которые будут устроены по тому же принципу.
то вопросов бы не было.
AF> А какие могли быть другие варианты?
Например, ссылки на высказывание авторитетных в этой области разработчиков. Например, если бы в каком-нибудь интервью об этом сказал Гослинг, Страуструп, Хёйсберг, Ксавье Лерой, Мартин Одерски Бертран Мейер или еще кто-нибудь из разработчиков языков программирования. Или какая-нибудь инсайдерская информация в блоге кого-нибудь из разработчиков C# или Java, или Scala, или Eiffel или OCaml о том, что "блин, забабахались мы с последним релизом языка, чуть живы остались, пора что-то в консерватории править". Тогда хоть какая-то объективная информация к размышлению была бы.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>А что, звание "С++ successor" автоматически подразумевает совместимость с C++? E>Sun в свое время Java рекламировал как "исправленный C++", тем не менее, об прозрачном интеропе с C++ ни тогда, ни сейчас речи не было.
Занять нишу С++ у них и не получилось. Ни тогда, ни сейчас. Успех Явы произошел совсем не в той области, где ожидали ее разработчики.
E>Вы хоть сами-то представляете во что это выльется? E>Если у меня C++ный класс возвращает ссылку на std::map с 30000 значений внутри, какая польза будет от маршалинга?
А никто не говорит, что эти значения обязательно надо копировать. Сделать обертку, которая будет перенаправлять вызовы оригинальному объекту — не проблема. Во всяком случае, для автора компилятора, у которого все карты в руках.
E>Например, ссылки на высказывание авторитетных в этой области разработчиков. Например, если бы в каком-нибудь интервью об этом сказал Гослинг, Страуструп, Хёйсберг, Ксавье Лерой, Мартин Одерски Бертран Мейер или еще кто-нибудь из разработчиков языков программирования. Или какая-нибудь инсайдерская информация в блоге кого-нибудь из разработчиков C# или Java, или Scala, или Eiffel или OCaml о том, что "блин, забабахались мы с последним релизом языка, чуть живы остались, пора что-то в консерватории править". Тогда хоть какая-то объективная информация к размышлению была бы.
Мнение авторитетов — это информация как раз субъективная, а не объективная. Особенно когда ты сам выбираешь, каких авторитетов слушать, а каких нет.
Здравствуйте, Andrei F., Вы писали:
AF>Здравствуйте, eao197, Вы писали:
E>>А что, звание "С++ successor" автоматически подразумевает совместимость с C++? E>>Sun в свое время Java рекламировал как "исправленный C++", тем не менее, об прозрачном интеропе с C++ ни тогда, ни сейчас речи не было.
AF>Занять нишу С++ у них и не получилось. Ни тогда, ни сейчас. Успех Явы произошел совсем не в той области, где ожидали ее разработчики.
Т.е. по вашему получается, что D планирует занять нишу C++ и чтобы у него это получилось, ему нужно иметь прозрачную интеграцию с C++? По другому никак?
А как же такой способ: то что написано на C++, останется на C++. Но новый софт будет разрабатываться на D и конкурировать с C++ным?
Например, в истории были случаи, когда С/C++ был вытеснен Eiffel-ем из "родной" для них ниши -- встроенного ПО.
E>>Вы хоть сами-то представляете во что это выльется? E>>Если у меня C++ный класс возвращает ссылку на std::map с 30000 значений внутри, какая польза будет от маршалинга?
AF>А никто не говорит, что эти значения обязательно надо копировать. Сделать обертку, которая будет перенаправлять вызовы оригинальному объекту — не проблема. Во всяком случае, для автора компилятора, у которого все карты в руках.
Вы думаете, что перенаправление вызовов что-то решит? В D есть сборка мусора. Это означает другие подходы к разработке. Так, в D можно получить ссылку на элемент map-а и эта ссылка останется валидной даже в случае изъятия элемента из map-а. В С++ это не так. Поэтому, если в D будет создана обертка над C++ным map-ом, то придется считаться с проблемами, которых в D просто нет. Так зачем же их получать?
E>>Например, ссылки на высказывание авторитетных в этой области разработчиков. Например, если бы в каком-нибудь интервью об этом сказал Гослинг, Страуструп, Хёйсберг, Ксавье Лерой, Мартин Одерски Бертран Мейер или еще кто-нибудь из разработчиков языков программирования. Или какая-нибудь инсайдерская информация в блоге кого-нибудь из разработчиков C# или Java, или Scala, или Eiffel или OCaml о том, что "блин, забабахались мы с последним релизом языка, чуть живы остались, пора что-то в консерватории править". Тогда хоть какая-то объективная информация к размышлению была бы.
AF>Мнение авторитетов — это информация как раз субъективная, а не объективная. Особенно когда ты сам выбираешь, каких авторитетов слушать, а каких нет.
Не важно, что я выбираю. Когда авторитет говорит что-то об области, в которой он занимается, у меня есть основание полагать, что он обладает информацией и знаниями, которыми я не располагаю. Более того, есть возможность спросить у них об этом напрямую. И, что характерно, свои ответы они аргументируют. В отличии от.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, eao197, Вы писали:
E>>Ну по этому показателю Nemerle до Eiffel-я еще расти и расти, и расти, и расти... WH>Напомни когда там Eiffel появился...
В 1986. И умудрился прожить больше 20 лет, да и сейчас развивается.
Вот я и говорю -- поживет Nemerle столько же, сколько Eiffel уже прожил, тогда и можно будет какие-то выводы делать.
E>>Не-а, тестовых данных нет, проверять не на чем WH>Если ты залогинен там есть такое маленькое окошечко куда ответ скормить можно...
Понял. Боюсь, что не найдется времени на такую забаву, а жаль ((
WH>В любом случае немерле сам по себе гораздо болие приятный язык нежели всякие там C#пы.
Собственно, против этого я и не спорил (по крайней мере здесь ). Изначально я хотел узнать, почему это будущее есть только у языков, построенных по принципу Nemerle.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>И даже знаменитого C-шного синтаксиса, который сейчас является чуть ли не ключем к успеху языка, тогда еще не было.
C++’s success in real-world use also led to influences that are less beneficial. The frequent use of the ugly and irregular C/C++ style of syntax in modern languages is not something I’m proud of.
Здравствуйте, eao197, Вы писали:
E>Я таки услышу ответ на вопрос о том, к пределу какой сложности приближается разработка современных языков программирования?
Я по секрету сознаюсь, что этот компилятор с Модулы уже на пределе допустимой сложности, и я бы чувствовал себя совершенно неспособным создать хороший компилятор для Ады.
Н. Вирт
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, eao197, Вы писали:
E>>Я таки услышу ответ на вопрос о том, к пределу какой сложности приближается разработка современных языков программирования? Т>
Я по секрету сознаюсь, что этот компилятор с Модулы уже на пределе допустимой сложности, и я бы чувствовал себя совершенно неспособным создать хороший компилятор для Ады.
Т>Н. Вирт
Ну вот, хоть что-то.
Тем не менее, со времен создания компиляторов Модулы и Ады что-то же изменилось, раз существуют такие вещи, как С++ и C# 3.0.
И еще вопрос, смогли бы на ядре Nemerle создать компилятор Ады.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, EvilChild, Вы писали:
EC>Тогда как аргумент в пользу макросов это звучит малоубедительно.
Они как парашют... нужны редко но если нужны...
EC>Давай лучше так — если есть время глянь здесь и скажи позволят ли макросы как-то улучшить решение там описанное.
Потом посмотрю.
EC>Или можно ли на них реализовать это?
Можно.
Но для этого не нужно ни менять язык ни макросы.
Просто нужна библиотека.
private GetStatuses () : void
{
def futures = daemonsStatusGetters_.Map(getter => //Запускаем асинхронные запросы в пуле и возвращаем список Future
{
def getStatus()
{
def (daemonName, status) = getter();
(daemonName, status, DateTime.Now);
}
Futures.Future.Spawn(threadPool_, getStatus);
});
def results = futures.MapFiltered(result => // Проходимся по списку Futures и достаем результаты отфильтровывая неудачные запросы.
{
match (result.GetValueOrException())
{
| Futures.FutureValue.Value(result) =>
Some(result);
| Futures.FutureValue.Exception =>
None();
}
});
SpawnFutureInGUIContext(() => UpdateRows(results)).Wait(); // Запускаем обовление ГУИ и ждем завершение операции
}
Все что для этого нужно это библиотека и нормальный вывод типов который понимает перегруженные генерик функции.
F# к таким языкам не относится... а немерле вполне...
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, eao197, Вы писали:
E>В 1986. И умудрился прожить больше 20 лет, да и сейчас развивается.
Да где он этот Eiffel? Кобол и фортран и то больше распространены...
E>Собственно, против этого я и не спорил (по крайней мере здесь ). Изначально я хотел узнать, почему это будущее есть только у языков, построенных по принципу Nemerle.
По тому что их:
1)Проще писать. Ибо писать нужно маленькое ядро. Остальное наворачивается простейшими макросами.
Болие
2)Проще на них писать. Ибо если вдруг в языке чегото не хватает это можно добавить макросом.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, eao197, Вы писали:
E>Т.е. по вашему получается, что D планирует занять нишу C++ и чтобы у него это получилось, ему нужно иметь прозрачную интеграцию с C++? По другому никак?
Нет, это не по моему так получается, это разработчик языка поставил перед собой такую задачу. И да, нормальный интероп с существующим кодом здесь необходим. В С++ был интероп с тем языком, для замены которого он был предназначен. В D такого интеропа не было. Сейчас что-то появилось, судя по ссылке которую дал FR, но до реальной применимости еще далековато.
E>Вы думаете, что перенаправление вызовов что-то решит? В D есть сборка мусора. Это означает другие подходы к разработке. Так, в D можно получить ссылку на элемент map-а и эта ссылка останется валидной даже в случае изъятия элемента из map-а. В С++ это не так. Поэтому, если в D будет создана обертка над C++ным map-ом, то придется считаться с проблемами, которых в D просто нет. Так зачем же их получать?
О да. Лучше вообще сделать вид, что решать задачу не нужно, и никаких проблем не будет.
E>Не важно, что я выбираю. Когда авторитет говорит что-то об области, в которой он занимается, у меня есть основание полагать, что он обладает информацией и знаниями, которыми я не располагаю. Более того, есть возможность спросить у них об этом напрямую. И, что характерно, свои ответы они аргументируют. В отличии от.
Главное, правильно выбрать подходящих авторитетов и проигнорировать остальных.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, eao197, Вы писали:
E>>В 1986. И умудрился прожить больше 20 лет, да и сейчас развивается. WH>Да где он этот Eiffel? Кобол и фортран и то больше распространены...
Ну аргументы классные, конечно. Если об Eiffel-е не кричат на каждом углу и он не считается мейнстримом, то это не значит, что его нет вообще. Живет себе потихоньку, за большие деньги продается, новые релизы два раза в год выпускают, ECMA стандарт не так давно был принят, сейчас EiffelStudio движется в сторону его полной реализации.
Я думаю, приверженцы Nemerle могут только мечтать оказаться когда-нибудь в такой же ситуации, в которой Eiffel пребывает сейчас.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Andrei F., Вы писали:
AF>Здравствуйте, eao197, Вы писали:
E>>Т.е. по вашему получается, что D планирует занять нишу C++ и чтобы у него это получилось, ему нужно иметь прозрачную интеграцию с C++? По другому никак?
AF>Нет, это не по моему так получается, это разработчик языка поставил перед собой такую задачу.
А кстати, где именно Брайт поставил перед собой такую задачу? Где он декларировал, что D является непосредственной заменой C++?
AF>И да, нормальный интероп с существующим кодом здесь необходим. В С++ был интероп с тем языком, для замены которого он был предназначен.
Полного интеропа, кстати, все равно не было.
E>>Вы думаете, что перенаправление вызовов что-то решит? В D есть сборка мусора. Это означает другие подходы к разработке. Так, в D можно получить ссылку на элемент map-а и эта ссылка останется валидной даже в случае изъятия элемента из map-а. В С++ это не так. Поэтому, если в D будет создана обертка над C++ным map-ом, то придется считаться с проблемами, которых в D просто нет. Так зачем же их получать?
AF>О да. Лучше вообще сделать вид, что решать задачу не нужно, и никаких проблем не будет.
Если эта задача кажется важной только вам, это не значит, что кто-то другой ее вообще видит.
E>>Не важно, что я выбираю. Когда авторитет говорит что-то об области, в которой он занимается, у меня есть основание полагать, что он обладает информацией и знаниями, которыми я не располагаю. Более того, есть возможность спросить у них об этом напрямую. И, что характерно, свои ответы они аргументируют. В отличии от.
AF>Главное, правильно выбрать подходящих авторитетов и проигнорировать остальных.
Да я готов выслушать любого авторитета, вне зависимости от того, нравится он мне или нет. Вы ссылки-то дайте. Ну хоть что-то конкретное.
Пока за вас это Трурль делает.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
В D есть сборка мусора. Это означает другие подходы к разработке. Так, в D можно получить ссылку на элемент map-а и эта ссылка останется валидной даже в случае изъятия элемента из map-а. В С++ это не так. Поэтому, если в D будет создана обертка над C++ным map-ом, то придется считаться с проблемами, которых в D просто нет. Так зачем же их получать?
((
). Изначально я хотел узнать, почему это будущее есть только у языков, построенных по принципу Nemerle.
