Здравствуйте, FR, Вы писали:

FR>http://www.digitalmars.com/d/2.0/cpp_interface.html

Use the limited ability described here to connect directly to C++ functions and classes.

Вот этот пункт — это интересно, не знал что такая возможность есть. Но реально она настолько "limited", судя по описанию, что использовать ее практически нереально.

Здравствуйте, Andrei F., Вы писали:

AF>Здравствуйте, FR, Вы писали:

FR>>http://www.digitalmars.com/d/2.0/cpp_interface.html

AF>

Use the limited ability described here to connect directly to C++ functions and classes.

AF>Вот этот пункт — это интересно, не знал что такая возможность есть. Но реально она настолько "limited", судя по описанию, что использовать ее практически нереально.

Практически как раз вполне реально, но это не так важно, важно то что движение есть, раньше насколько я знаю авторы языка с этой проблемоой просто посылали

Здравствуйте, Andrei F., Вы писали:

AF>Здравствуйте, eao197, Вы писали:

E>>Интероп с другими языками в том числе и с C++ в D сделан так же, как и в самом C++ -- через C-шный интерфейс. С-шные библиотеки прозначно цепляются к D, С++ные библиотеки, обернутые в C-шный API спокойно цепляются к D, D-шные библиотеки, обернутые в С-шный API спокойно цепляются к C++.

AF>Иными словами, нужно делать обертки на каждый метод с обеих сторон, в D и в C++. Классы — эмулировать.
AF>Я могу назвать такой "интероп" как угодно, но только не удобным или надежным.

Ну т.е. для Ruby, Python, Eiffel, OCaml и Erlang такой способ интеграции с C/C++ считается нормальным, а для D почему-то нет?

E>>Хотя у .NET/Windows-программистов под интеропом, наверное, понимается что-нибудь другое. Только то, что работает в рамках CLR и только под Windows.

AF>Ну раз ты первый об этом заговорил, мне нравится как сделан интероп в C++/CLI.
AF>А что он реализован только под Windows — не очень хорошо, но мне это проблем не создает.

Ну то есть, вне .NET/Windows жизни ты не видишь. Так и запишем.
А разве C++/CLI -- это C++?
И если уж речь зашла об .NET-е, что в D такого принципиального есть, что не позволяет, при желании, сделать вариант D для .NET-а? Если уж из C++ смогли сделать C++/CLI, то из D почему нельзя?

E>>Вот только не понятно, на основании чего сделан такой вывод. Свидельства подобной ситуации можно увидеть?

AF>Имеющий глаза да увидит.

Дык а куда смотреть-то? Вот сейчас идет разработка Python3K, Ruby 2, D 2.0, Scala 2.7 -- не видать там Nemerle-вых ушей. В прошлом году были новые релизы C#, Erlang, OCaml -- и там не видно.

Зато вот те, кто затеял возню с микроядром и метапрограммированием, потеряли мотивацию к дальнейшей разработке.

E>>Так что быстрая реализация не всегда способна привести к хорошему и юзабельному результату.

AF>Если учесть размер команды, то при разработке на языке без макросов никаких контрактов не было бы вообще.

В Sign# есть, в D есть, в Nice есть такие же контракты. И команды там были не на много больше, чем у Nemerle.

Так что хотелось бы увидеть обоснованный какими-либо фактами и примерами взгляд на то, что только микроядро и метапрограммирование сейчас являются правильным подходом к разработке современных языков программирования.

Здравствуйте, eao197, Вы писали:

E>Ну т.е. для Ruby, Python, Eiffel, OCaml и Erlang такой способ интеграции с C/C++ считается нормальным, а для D почему-то нет?

Может быть — потому что никто не позиционирует Ruby, Python, Eiffel, OCaml и Erlang как замену С++, да и вообще у них ниша совсем другая?

E>Ну то есть, вне .NET/Windows жизни ты не видишь. Так и запишем.

Вижу. Но не вижу смысла тратить на нее усилия. Пока что.

E>А разве C++/CLI -- это C++?

Это его надмножество.

E>И если уж речь зашла об .NET-е, что в D такого принципиального есть, что не позволяет, при желании, сделать вариант D для .NET-а? Если уж из C++ смогли сделать C++/CLI, то из D почему нельзя?

Можно. И полноценный интероп с С++ в нем тоже можно сделать. Когда сделают — тогда и будет о чем говорить

E>Так что хотелось бы увидеть обоснованный какими-либо фактами и примерами взгляд на то, что только микроядро и метапрограммирование сейчас являются правильным подходом к разработке современных языков программирования.

А он не является "единственным правильным". Он просто самый перспективный. Но это нельзя доказать. Никак. Единственный способ — это подождать и проверить.

Здравствуйте, Andrei F., Вы писали:

AF>Здравствуйте, eao197, Вы писали:

E>>Ну т.е. для Ruby, Python, Eiffel, OCaml и Erlang такой способ интеграции с C/C++ считается нормальным, а для D почему-то нет?

AF>Может быть — потому что никто не позиционирует Ruby, Python, Eiffel, OCaml и Erlang как замену С++, да и вообще у них ниша совсем другая?

Т.е. вы хотите сказать, что ни Eiffel, ни OCaml ну ни капельки не претендуют на нишу C++?

E>>И если уж речь зашла об .NET-е, что в D такого принципиального есть, что не позволяет, при желании, сделать вариант D для .NET-а? Если уж из C++ смогли сделать C++/CLI, то из D почему нельзя?

AF>Можно.

Уже прогресс.

AF> И полноценный интероп с С++ в нем тоже можно сделать.

Нельзя. Если бы вы внимательно посмотрели бы на ссылку, данную вам FR, то вы бы увидели:

C++ Templates

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.

This means that the C++ STL, and C++ Boost, likely will never be accessible from D.

Без поддержки STL никакой интероп с C++ не будет полноценным.

E>>Так что хотелось бы увидеть обоснованный какими-либо фактами и примерами взгляд на то, что только микроядро и метапрограммирование сейчас являются правильным подходом к разработке современных языков программирования.

AF>А он не является "единственным правильным". Он просто самый перспективный. Но это нельзя доказать. Никак. Единственный способ — это подождать и проверить.

Т.е. все ваши категоричные заявления выше по ветке нужно было воспринимать, как вашу личную точку зрения и все?

Здравствуйте, eao197, Вы писали:

E>В Sign# есть, в D есть, в Nice есть такие же контракты. И команды там были не на много больше, чем у Nemerle.

Над статической проверкой контрактов в Spec# работала команда специалистов, превышающая, насколько мне известно, количество основных разработчиков D, Nice и Nemerle вместе взятых. При этом, их статический верификатор можно подключить к Nemerle просто как библиотеку. И работа эта была проделана сторонним контрибьютером без изменений компилятора Nemerle.
Можно ли подключить этот статический верификатор контрактов к D или Nice? Вопрос риторический, конечно.

Здравствуйте, Klapaucius, Вы писали:

K>Здравствуйте, eao197, Вы писали:

E>>В Sign# есть, в D есть, в Nice есть такие же контракты. И команды там были не на много больше, чем у Nemerle.

K>Над статической проверкой контрактов в Spec# работала команда специалистов, превышающая, насколько мне известно, количество основных разработчиков D, Nice и Nemerle вместе взятых.

Поэтому для Spec# нужно грузить отдельную написанную на Java библиотеку, которая доказательством и занимается? Причем, насколько я помню, написана она была как раз не командой Spec#, а в Hewlett-Pakard.

Тем не менее, вопрос был в другом. Для нормальной поддержки Design By Contract в постусловиях нужно реализовать доступ к значениям, которые некоторые атрибуты/методы имели до запуска метода. В Eiffel для этого даже специальное ключевое слово в постусловиях используется -- old. Можно ли это ключевое слово поддержать в Nemerle, где контракты реализованы на макросах?

Здравствуйте, Курилка, Вы писали:

К>Может всёж Хейлсберг?
Скорее, Хайльсберг

Здравствуйте, eao197, Вы писали:

AF>>А что он реализован только под Windows — не очень хорошо, но мне это проблем не создает.
E>Ну то есть, вне .NET/Windows жизни ты не видишь. Так и запишем.
Демагог млин.
Из того что сказал Andrei F. это не слудет.

E>Зато вот те, кто затеял возню с микроядром и метапрограммированием, потеряли мотивацию к дальнейшей разработке.
Они сделали компилятор продакшен качества в отличии от остальных. Даже в C# с их ресурсами багов как минимум не меньше.
И это при том что в nemerle один из самых мощных алгоритмов вывода типов.

        public Init(configPath : string) : void
        {
            def config = FastcgiDaemonsWatcherConfig.ParseFile(configPath);
            logPath_ = config.LogPath;
            def gates = Hashtable();
            mutable port = config.StartPort;
            foreach (gate in config.Gates)
            {
                mutable argCount = 0;
                mutable args = "";
                def startPlink()
                {
                    when (argCount > 0)
                    {
                        def plink = System.Diagnostics.Process();
                        plink.StartInfo.FileName = config.PlinkPath;
                        plink.StartInfo.Arguments = $"-ssh $args -pw $(gate.Password) $(gate.Login)@$(gate.Host)";
                        plink.StartInfo.UseShellExecute = false;
                        plink.StartInfo.CreateNoWindow = false;
                        plink.StartInfo.RedirectStandardError = true;
                        plink.StartInfo.RedirectStandardInput = true;
                        plink.StartInfo.RedirectStandardOutput = true;
                        when (!plink.Start())
                            throw Exception("Can't start plink.");
                        plinks_ ::= plink;
                        args = "";
                        argCount = 0;
                    }
                }
                def addPlinkArg(daemonHost, daemonPort)//*1*
                {
                    def localPort = port;
                    def localHost = "localhost";
                    args += $" -L $localPort:$daemonHost:$daemonPort ";
                    ++port;
                    ++argCount;
                    when (argCount >= 20)
                        startPlink();
                    (localHost, localPort);
                }
                gates.Add(gate.Name, (addPlinkArg, startPlink));
            }
            daemonsStatusGetters_ = config.Daemons.Map(daemon =>
            {
                def makeTCPGetter(name, host, port)
                {
                    () => (name, FastcgiDaemon.GetFastcgiDaemonStatusTCP(host, port))
                }
                match (daemon.GateName)
                {
                | null | "" =>
                    makeTCPGetter(daemon.Name, daemon.Host, daemon.Port);
                | gateName =>
                    def (Some((addPlinkArg, _))) = gates.Get(gateName);
                    def (host, port) = addPlinkArg(daemon.Host, daemon.Port);//*2*
                    makeTCPGetter(daemon.Name, host, port);
                }
            });
            gates.Values.Iter((_, startPlink) => startPlink());
        }

Типы в строке *1* были выведены из строки *2*.
Нука покажи мне язык с системой типов не Hindley–Milner который на такое способен.
Да и вобще обрати внимание на то с каким цинизмом написана данная функция.

Кстати это кусок мониторинга продакшен кластера.

using System;
using System.Console;
using SCG = System.Collections.Generic;
using Nemerle;
using Nemerle.Utility;
using Nemerle.Collections;

/*
Consider the number 45656. 
It can be seen that each pair of consecutive digits of 45656 has a difference of one.
A number for which every pair of consecutive digits has a difference of one is called a step number.
A pandigital number contains every decimal digit from 0 to 9 at least once.
How many pandigital step numbers less than 10^40 are there? 
*/

public class Problem178
{
    [Memoize]
    step(cur : int, len : int, bits : int) : Int64
    {
        match (len - 1, bits %| (1 << cur))
        {
        | (0, 0x3ff)  => 1L
        | (0, _)      => 0L
        | (len, bits) =>
            def rec(cur)
            {
            | _ when cur < 0 || cur > 9 => 0L;
            | _ => step(cur, len, bits)
            }
            rec(cur + 1) + rec(cur - 1)
        }
    }

    public Solve() : string
    {
        $[1..40]//max 66
        .Map(len =>
        {
            $[1..9]
            .Map(s => step(s, len, 0))
            .Sum64()
        })
        .Sum64()
        .ToString()
    }
}

А в этом случае макрос [Memoize] превращает алгоритм из экспоненциального в линейный.
Сколько времени нужно просить автора D чтобы он добавил [Memoize]?

E>В Sign# есть, в D есть, в Nice есть такие же контракты. И команды там были не на много больше, чем у Nemerle.
Те контракты что в немерле сделаны чисто по приколу.
Если они тебе не нравятся ты можешь сделать правильные контракты.
Это тебе позволяет микроядро и метапрограммирование.

Здравствуйте, WolfHound, Вы писали:

AF>>>А что он реализован только под Windows — не очень хорошо, но мне это проблем не создает.
E>>Ну то есть, вне .NET/Windows жизни ты не видишь. Так и запишем.
WH>Демагог млин.
WH>Из того что сказал Andrei F. это не слудет.

А что из его слов следует?

E>>Зато вот те, кто затеял возню с микроядром и метапрограммированием, потеряли мотивацию к дальнейшей разработке.
WH>Они сделали компилятор продакшен качества в отличии от остальных. Даже в C# с их ресурсами багов как минимум не меньше.
WH>И это при том что в nemerle один из самых мощных алгоритмов вывода типов.

WH>Нука покажи мне язык с системой типов не Hindley–Milner который на такое способен.
WH>Да и вобще обрати внимание на то с каким цинизмом написана данная функция.

Прошу простить мне мою неграмотность, но я ничего не понял ни в приведенном примере. Да и про систему Hindley-Milner я знаю лишь то, что она есть.

Однако, из виденных мной исходников, наиболее читабельными при сопровождении оказывались программы на Eiffel, где никакого вывода типов нет вообще, ну т.е. в принципе. Так что я рад за мощность системы вывода типов в Nemerle и вообще желаю этому языку не помереть тихой смертию. Но время должно доказать состоятельность Nemerle для использования в самых обычных проектах.

WH>Кстати это кусок мониторинга продакшен кластера.

WH>А в этом случае макрос [Memoize] превращает алгоритм из экспоненциального в линейный.
WH>Сколько времени нужно просить автора D чтобы он добавил [Memoize]?

ХЗ. По моему опыту, автор D делает то, что он сам считает нужным.
А что, этот алгоритм ну никак без Memoize запрограммировать нельзя?

E>>В Sign# есть, в D есть, в Nice есть такие же контракты. И команды там были не на много больше, чем у Nemerle.
WH>Те контракты что в немерле сделаны чисто по приколу.
WH>Если они тебе не нравятся ты можешь сделать правильные контракты.
WH>Это тебе позволяет микроядро и метапрограммирование.

Вообще-то это странный подход к пользователю -- вот тебе конструктор и делай из него что тебе нужно. Нафиг мне этот конструктор? У меня своих задач хватает, а вокруг полно более качественно сделанных инструментов, которые позволяют их решать. А когда я беру инструмент, мне фиолетово, как он сделан, мне его качества важны. И если кто-то предоставляет инструмент нужно качества, но сделанный не по "передовой" технологии, то по мне это скорее опровергает "передовость" той самой технологии.

Здравствуйте, eao197, Вы писали:

AF>>Это вероятное будущее для динозавров вроде D и ему подобных. И даже не вероятное, а практически гарантированное.
AF>>А настоящее будущее — за Немерле или другими языками, которые будут устроены по тому же принципу.

E>Мосье оракул?

E>А языки типа Scala или Nice вы куда вписываете?

Скала как раз намного ближе к Немерлу нежели к Ди. Приделать ей макросы и скорости добавить, будет то же Немерле вид в профиль.

Здравствуйте, eao197, Вы писали:

E>Тогда нужно определиться в критерии "иметь будущее". Если под этим понимается "стать мейнстримом", то это одно, а если "применяться кое-где" -- то совсем другое.

E>Lisp мейнстримом не стал.

Солгасен. Но Лисп вряд ли мог стать мэйнстримом, хотя возможно при некотором маркетиге...

Лисп действительно сложен для постижения и реального применения. К тому же он варился в очень обособленной среде. Одно время "обычными" программистами считалось, что этот язык пригоден только для обработки списков и работ в области ИИ. Потом у Лиспа появилось море диалектов. Потом появился ДОС под которым интерпретаторы были не в почете, а компиляторов приличных не было. Да и сейчас найти приличную реализацию компилирующего Лиспа в купе с IDE не просто. Емаксы это все же не для мэйнстрима.

Немерле же имеет одну особенность. Он практически является сабсэтом C#-а. А уж для него налажено обучение по полной программе.

Здравствуйте, VladD2, Вы писали:

VD>Немерле же имеет одну особенность. Он практически является сабсэтом C#-а. А уж для него налажено обучение по полной программе.

А плюс ли это вообще?
Объем знаний и умений чтобы хорошо писать используя функциональную парадигму гораздо больше чем объем нужный чтобы освоить еще один язык с новым синтаксисом.

Здравствуйте, eao197, Вы писали:

E>Прошу простить мне мою неграмотность, но я ничего не понял ни в приведенном примере. Да и про систему Hindley-Milner я знаю лишь то, что она есть.
И что там не понятно?
Не считая System.Diagnostics.Process() и компанию.
ИМХО простейшей код из серии что вижу то пою.

E>Однако, из виденных мной исходников, наиболее читабельными при сопровождении оказывались программы на Eiffel, где никакого вывода типов нет вообще, ну т.е. в принципе.
Ну а моя практика показывает что из всех языков на которых я писал проще всего править код на немерле.
Причем вывод типов одна из главных причин этого.
В принципе примерно тоже самое можно делать при динамической типизации но у нее есть большой недостаток: нет контроля типов во время компиляции. А это важно ибо ловит довольно много ошибок.

E>Так что я рад за мощность системы вывода типов в Nemerle и вообще желаю этому языку не помереть тихой смертию.
Ну ему точно будет не хуже чем Eiffel'ю...

E>Но время должно доказать состоятельность Nemerle для использования в самых обычных проектах.
А что тут доказывать то?
Он заведомо не хуже C#.
Единственное что интелисенс пока слабее.

E>ХЗ. По моему опыту, автор D делает то, что он сам считает нужным.
А тут я могу сделать то что я считаю нужным.

E>А что, этот алгоритм ну никак без Memoize запрограммировать нельзя?
Можно.
Но код будет далеко не таким прозрачным.
Почитай условие и решение. И увидишь что решение практически переписанное на языке программирования условие.

E>Вообще-то это странный подход к пользователю -- вот тебе конструктор и делай из него что тебе нужно. Нафиг мне этот конструктор? У меня своих задач хватает, а вокруг полно более качественно сделанных инструментов, которые позволяют их решать. А когда я беру инструмент, мне фиолетово, как он сделан, мне его качества важны. И если кто-то предоставляет инструмент нужно качества, но сделанный не по "передовой" технологии, то по мне это скорее опровергает "передовость" той самой технологии.
Дело в том что нет инструментов на все случаи жизни.
Ну нету.
Иногда приходится под задачу делать и вот тут то что язык предостовляет конструктор (и кучу уже готовых инструментов которые можно использовать, а можно и нет) дает большие преимущества.

Здравствуйте, WolfHound, Вы писали:

E>>Так что я рад за мощность системы вывода типов в Nemerle и вообще желаю этому языку не помереть тихой смертию.
WH>Ну ему точно будет не хуже чем Eiffel'ю...

Ну, когда средства разработки для Nemerle будут продаваться и окупать вложенные в них усилия, тогда и можно будет сравнивать успешность Nemerle и Eiffel-я.

E>>А что, этот алгоритм ну никак без Memoize запрограммировать нельзя?
WH>Можно.
WH>Но код будет далеко не таким прозрачным.
WH>Почитай условие и решение. И увидишь что решение практически переписанное на языке программирования условие.

Не могу сказать, что я понял условие, а уж что делает решение...
Где нибудь эта задача еще описана с тестовыми данными?

WH>Дело в том что нет инструментов на все случаи жизни.
WH>Ну нету.
WH>Иногда приходится под задачу делать и вот тут то что язык предостовляет конструктор (и кучу уже готовых инструментов которые можно использовать, а можно и нет) дает большие преимущества.

Если под инструментом понимать язык, то я не согласен с тем, что сложные задачи нужно модифицировать хост-язык собственными силами. Будь то Lisp или Nemerle. Кому-то этот подход может нравится, но я не из их числа.

Здравствуйте, VladD2, Вы писали:

VD>Лисп действительно сложен для постижения и реального применения.

Не сложнее любого "обычного" языка. Просто для тех кто уже испорчен бейсиком си или паскалем он "сложен". Тот же Smalltalk также считается "сложным" однако дети его без проблем осваивают.

Здравствуйте, FR, Вы писали:

VD>>Немерле же имеет одну особенность. Он практически является сабсэтом C#-а. А уж для него налажено обучение по полной программе.

FR>А плюс ли это вообще?

Несомненно плюс. Если конечно нет дикого желания во всем видеть минсв.

FR>Объем знаний и умений чтобы хорошо писать используя функциональную парадигму гораздо больше чем объем нужный чтобы освоить еще один язык с новым синтаксисом.

Тут есть два соображения:
1. Объем знаний требуемый для использования ФП сильно приувеличен. Просто учить ему не умеют. Раньше ФП учили близкие к математике и вообще науке люди. Резльтат получался плачевным. Из простешей вещи они сразу же учудили мозголомство.
2. В том то и дело, что если знать Шарп (а таких программистов очень много), то фунциональные вещи осваиваются довольно легко и, что не маловажно, прямо во время работы над каким-нибудь проектом. Желательно только чтобы при этом рядом с новичком работал кто-то кто уже прошел этот пукть и может потихоничку направлять новичка в нужное русло.

Здравствуйте, VladD2, Вы писали:

VD>Тут есть два соображения:
VD>1. Объем знаний требуемый для использования ФП сильно приувеличен. Просто учить ему не умеют. Раньше ФП учили близкие к математике и вообще науке люди. Резльтат получался плачевным. Из простешей вещи они сразу же учудили мозголомство.

Объем знаний чтобы хорошо программировать и проектировать в русле ФП никак ни меньше такового для ООП. Скорее даже больше.
Я вот не могу сказать что освоил ФП, локально да, применяю легко, а вот проектирование и решения в духе парадигмы со скрипом.

VD>2. В том то и дело, что если знать Шарп (а таких программистов очень много), то фунциональные вещи осваиваются довольно легко и, что не маловажно, прямо во время работы над каким-нибудь проектом. Желательно только чтобы при этом рядом с новичком работал кто-то кто уже прошел этот пукть и может потихоничку направлять новичка в нужное русло.

Угу только по моему в резулmтате получаются больше "пользователи сахара"

Здравствуйте, Трурль, Вы писали:

К>>Может всёж Хейлсберг?
Т>Скорее, Хайльсберг

Ну это вряд ли. Сам он произносит примерно как Хёйлсберг.

Здравствуйте, eao197, Вы писали:

E>Ну, когда средства разработки для Nemerle будут продаваться и окупать вложенные в них усилия, тогда и можно будет сравнивать успешность Nemerle и Eiffel-я.
Сравнивать успешность языков можно только по колличеству проектов на них сделанных.

E>Не могу сказать, что я понял условие, а уж что делает решение...
E>Где нибудь эта задача еще описана с тестовыми данными?
http://projecteuler.net/index.php?section=problems&id=178
Легче стало?

E>Если под инструментом понимать язык, то я не согласен с тем, что сложные задачи нужно модифицировать хост-язык собственными силами. Будь то Lisp или Nemerle. Кому-то этот подход может нравится, но я не из их числа.
Дело в том что в случае с немерле в отличии от лиспа в подавляющем большинстве случаев язык модифицировать не надо.
Лично я пока еще по делу не написал ни одного макроса. (ибо пока не писал на немерле ничего действительно большого)
Но скажем на прошлой работе если бы тот проект делался на немерле, а не на C# то по крайней мере одну макру я бы написал. Тем самым избавив себя и окружающих от кучи гемороя.
В томже компиляторе немерла есть несколько макросов которые добавляют к AST кучу тупых но весьма объемных методов. Писать их руками это полный звиздец. Генерить текст еще больший геморой.