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

b> AB>Для mercurial термин server-side не совсем корректен. Хотя, смотря что считать сервером.
b> Где он диффы считает? На локальной машине в локальном репозитории?

Типа того. Моя ремарка была к тому, что у меркуриала нет сервера — каждый клон репозитория самодостаточен (а уж способ работы — локально или SSH, хранилище — локально или SSHFS, вещи достаточно вариабельные). Ремарка не имеет отношения к спору C++ vs Delphi.

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

I>>Ну да, полиморфизм к ООП никакого отношения не имеет

G>ООП обычно использует довольно слабый вид полиморфизма: ad-hoc полиморфизм по неявному аргументу.

Обычно, но это не значит что это единсвенно возможный вариант

G>Шаблоны и генерики не относятся к ООП вообще никак.

Это всего лишь реализация тех возможностей, которые динамически типизируемые ОО-языки умеют "искаропки"

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

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

b>> AB>Для mercurial термин server-side не совсем корректен. Хотя, смотря что считать сервером.
b>> Где он диффы считает? На локальной машине в локальном репозитории?

AB>Типа того. Моя ремарка была к тому, что у меркуриала нет сервера — каждый клон репозитория самодостаточен (а уж способ работы — локально или SSH, хранилище — локально или SSHFS, вещи достаточно вариабельные). Ремарка не имеет отношения к спору C++ vs Delphi.

ИМХО, он не сильно сложные там расчёты... подветка таки про производительность и применимость сипласплас.

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

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

I>>>Ну да, полиморфизм к ООП никакого отношения не имеет

G>>ООП обычно использует довольно слабый вид полиморфизма: ad-hoc полиморфизм по неявному аргументу.

I>Обычно, но это не значит что это единсвенно возможный вариант
Для самого ООП — единственно возможный. Остальные способы полиморфизма не имеют отношения к ООП никак.

G>>Шаблоны и генерики не относятся к ООП вообще никак.
I>Это всего лишь реализация тех возможностей, которые динамически типизируемые ОО-языки умеют "искаропки"
Вот только динамическая типизация не делает программы надежнее, а нам надо повышать уровень абстракции без снижения надежности кода.

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

I>>Обычно, но это не значит что это единсвенно возможный вариант
G>Для самого ООП — единственно возможный. Остальные способы полиморфизма не имеют отношения к ООП никак.

Открой принципы Алана Кея, там полиморфизма столько надо, сколько во всем с++ не накопаешь

G>>>Шаблоны и генерики не относятся к ООП вообще никак.
I>>Это всего лишь реализация тех возможностей, которые динамически типизируемые ОО-языки умеют "искаропки"
G>Вот только динамическая типизация не делает программы надежнее, а нам надо повышать уровень абстракции без снижения надежности кода.

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

Даже "укушеные Александреску" и те внагрузку к с++ используют какую динамику по мелочи.

А вообще ты в курсе, какие проекты пишутся на js, питоне, эрланге ?

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

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

I>>>Обычно, но это не значит что это единсвенно возможный вариант
G>>Для самого ООП — единственно возможный. Остальные способы полиморфизма не имеют отношения к ООП никак.
I>Открой принципы Алана Кея, там полиморфизма столько надо, сколько во всем с++ не накопаешь

G>>>>Шаблоны и генерики не относятся к ООП вообще никак.
I>>>Это всего лишь реализация тех возможностей, которые динамически типизируемые ОО-языки умеют "искаропки"
G>>Вот только динамическая типизация не делает программы надежнее, а нам надо повышать уровень абстракции без снижения надежности кода.

I>Статическая типизация тоже не делает программы надежнее.
Да ну?

I>Приходится писать в разы больше кода, приседать вокруг депенденсов, выдумывать всякие конструкции, и в итоге код имеет ровно те же проблемы.
Докажешь?

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

Но вот самое интересное получается когда надо править код.
Например есть цепочка вызовов A=>B=>C=>...=>Y=>Z и внезапно в Z сменился тип параметра. В статике перестанет компилироваться, ты поправишь, потребуется поменять параметры Y, и так далее. В итоге скомпилируется у тебя программа только если ты поправишь все несоответствия.
Если есть вывод типов, то картина еще радужнее. Типы сами автоматически выведутся кроме тех мест, где возникнут конфликты. В итоге тебе надо будет править только те места, где изменится семантика.

А в случае динамического языка у тебя будет в рантайме выпадать ошибка. Причем выпадать она может не всегда.

Чтобы получить надежность кода на уровне статического варианта тебе нужно написать для этого дела тест.

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

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

G>>>>>Шаблоны и генерики не относятся к ООП вообще никак.
I>>>>Это всего лишь реализация тех возможностей, которые динамически типизируемые ОО-языки умеют "искаропки"
G>>>Вот только динамическая типизация не делает программы надежнее, а нам надо повышать уровень абстракции без снижения надежности кода.

I>>Статическая типизация тоже не делает программы надежнее.
G>Да ну?

Ну да.

I>>Приходится писать в разы больше кода, приседать вокруг депенденсов, выдумывать всякие конструкции, и в итоге код имеет ровно те же проблемы.
G>Докажешь?

Запрограммируй на С#/С++ конечный автомат какой. Сравни с его реализацией скажем на Питоне или Руби. Сделай выводы.

G>Если уж на то пошло, то большая часть того что пишется в динамике может быть выражена и в статике. Ну конечно зависит от языка.

Может и что ?

G>А в случае динамического языка у тебя будет в рантайме выпадать ошибка. Причем выпадать она может не всегда.

G>Чтобы получить надежность кода на уровне статического варианта тебе нужно написать для этого дела тест.

Зато в с#, C++ придется городить всякие визиторы

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

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

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

I>Запрограммируй на С#/С++ конечный автомат какой. Сравни с его реализацией скажем на Питоне или Руби. Сделай выводы.

Давай, показывай код на питоне, сравним с тем, как это в nemerle будет выглядеть.

I>Зато в с#, C++ придется городить всякие визиторы

В nemerle не придется

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

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

G>>>>>>Шаблоны и генерики не относятся к ООП вообще никак.
I>>>>>Это всего лишь реализация тех возможностей, которые динамически типизируемые ОО-языки умеют "искаропки"
G>>>>Вот только динамическая типизация не делает программы надежнее, а нам надо повышать уровень абстракции без снижения надежности кода.

I>>>Статическая типизация тоже не делает программы надежнее.
G>>Да ну?

I>Ну да.

I>>>Приходится писать в разы больше кода, приседать вокруг депенденсов, выдумывать всякие конструкции, и в итоге код имеет ровно те же проблемы.
G>>Докажешь?

I>Запрограммируй на С#/С++ конечный автомат какой. Сравни с его реализацией скажем на Питоне или Руби. Сделай выводы.
А в чем проблема на C# сделать функцию из IEnumerable<T> в IEnumerable<V> на yield return?
На C++ все плохо.
Только причем тут динамика?

G>>Если уж на то пошло, то большая часть того что пишется в динамике может быть выражена и в статике. Ну конечно зависит от языка.
I>Может и что ?
То что утверждение про "писать в разы больше кода" несостоятельно.

G>>А в случае динамического языка у тебя будет в рантайме выпадать ошибка. Причем выпадать она может не всегда.
G>>Чтобы получить надежность кода на уровне статического варианта тебе нужно написать для этого дела тест.
I>Зато в с#, C++ придется городить всякие визиторы.
И часто тебе приходится их городить? Я визиторы писал пару раз в жизни всего. Еще несколько раз пользовался готовыми.
Если уж касаться темы обхода сложных структур, то я лучше F# (статически типизированный однако) возьму, там pattern-matching есть.

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

I>а основная логика в динамическом языке будет гораздо проще читаться.
Опять-таки большая часть логики будет практически одинаково выражаться что в статике, что в динамике.
За счет чего получаются эти "гораздо" и "в разы".
Желательно на конкретном примере. Только не надо сравнивать голый C c Ruby.

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

I>>Запрограммируй на С#/С++ конечный автомат какой. Сравни с его реализацией скажем на Питоне или Руби. Сделай выводы.

KV>Давай, показывай код на питоне, сравним с тем, как это в nemerle будет выглядеть.

class SampleMachine
  include StateMachine
  state_machine :states => [:a_state, :b_state, :c_state, :d_state], :events => [:w_event, :x_event, :y_event, :z_event]
  state_transition :state=>:a_state, :event=>:x_event, :next=>:c_state
  state_transition :state=>:a_state, :event=>:y_event, :next=>:a_state
  state_transition :state=>:a_state, :event=>:z_event, :next=>:b_state
                                                            
  state_transition :state=>:b_state, :event=>:w_event, :next=>:b_state
  state_transition :state=>:b_state, :event=>:y_event, :next=>:c_state
  state_transition :state=>:b_state, :event=>:z_event, :next=>:a_state
                                                            
  state_transition :state=>:c_state, :event=>:x_event, :next=>:b_state
end

sm = SampleMachine.new
assert_equal(:a_state, sm.current_state)
sm.send_event(:x_event)
assert_equal(:c_state, sm.current_state)

I>>Зато в с#, C++ придется городить всякие визиторы

KV>В nemerle не придется

В F# тож не придется. и что ?

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

KV>>Давай, показывай код на питоне, сравним с тем, как это в nemerle будет выглядеть.

I>[code]
I>class SampleMachine
I> include StateMachine
I> state_machine :states => [:a_state, :b_state, :c_state, :d_state], :events => [:w_event, :x_event, :y_event, :z_event]
I> state_transition :state=>:a_state, :event=>:x_event, :next=>:c_state
I> state_transition :state=>:a_state, :event=>:y_event, :next=>:a_state
I> state_transition :state=>:a_state, :event=>:z_event, :next=>:b_state

I> state_transition :state=>:b_state, :event=>:w_event, :next=>:b_state
I> state_transition :state=>:b_state, :event=>:y_event, :next=>:c_state
I> state_transition :state=>:b_state, :event=>:z_event, :next=>:a_state

I> state_transition :state=>:c_state, :event=>:x_event, :next=>:b_state
I>end

Это Руби а не питон.

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

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

I>>Запрограммируй на С#/С++ конечный автомат какой. Сравни с его реализацией скажем на Питоне или Руби. Сделай выводы.

KV>Давай, показывай код на питоне, сравним с тем, как это в nemerle будет выглядеть.

generator stateA
loop
while condition
do something
yield stateB

generator stateB
loop
while condition
do something
yield stateA

subroutine dispatcher
var d := new dictionary〈generator → iterator〉
d[stateA] := start stateA
d[stateB] := start stateB
var current := stateA
loop
current := next d[current]

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

I>Здравствуйте, kochetkov.vladimir, Вы писали:

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

I>>>Запрограммируй на С#/С++ конечный автомат какой. Сравни с его реализацией скажем на Питоне или Руби. Сделай выводы.

KV>>Давай, показывай код на питоне, сравним с тем, как это в nemerle будет выглядеть.

generator stateA
    loop
        while condition
            do something
        yield stateB

generator stateB
    loop
        while condition
            do something
        yield stateA

subroutine dispatcher
    var d := new dictionary〈generator → iterator〉
    d[stateA] := start stateA
    d[stateB] := start stateB
    var current := stateA
    loop
        current := next d[current]

Nemerle:

#pragma indent
using Nemerle.Fsm;

[FsmDef(
    SampleMachine
    {
        default stateA;

        state stateA
            | eventX => stateC;
            | eventY => stateA;
            | eventZ => stateB;
            
        state stateB
            | eventW => stateB;
            | eventY => stateC;
            | eventZ => stateA;
            
        state stateC
            | eventX => stateB;
    }
)]

def sm = SampleMachine;
Assert.Equal(sm.States.stateA, sm.CurrentState);
sm.Event(sm.Events.eventX);
Assert.Equal(sm.States.stateC, sm.CurrentState);

Также есть возможность определять ДКА через события:

[FsmDef(
    SampleMachine
    {
        default stateA;
    
        event eventW
            | stateB => stateB;
            
        event eventX
            | stateA => stateC;
            | stateC => stateB;
        
        event eventY
            | stateA => stateA;
            | stateB => stateC;
            
        event eventZ
            | stateA => stateB;
            | stateB => stateA;
    }
)]
// Далее, код идентичен

I>Это Руби а не питон.

P.S: Я конечно не программист, но не до такой же степени. Руби от питона в состоянии отличить, по крайней мере

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

KV>Nemerle:

Боже... Дай, думаю, посмотрю, что пишут в "Дельфи против СИ++"...

You will always get what you always got
  If you always do  what you always did

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

I>>Запрограммируй на С#/С++ конечный автомат какой. Сравни с его реализацией скажем на Питоне или Руби. Сделай выводы.
G>А в чем проблема на C# сделать функцию из IEnumerable<T> в IEnumerable<V> на yield return?

Покажи пример автомата.

G>>>Если уж на то пошло, то большая часть того что пишется в динамике может быть выражена и в статике. Ну конечно зависит от языка.
I>>Может и что ?
G>То что утверждение про "писать в разы больше кода" несостоятельно.

В разы. Относительно С++ с его указателями так и вовсе в десятки раз.

G>>>А в случае динамического языка у тебя будет в рантайме выпадать ошибка. Причем выпадать она может не всегда.
G>>>Чтобы получить надежность кода на уровне статического варианта тебе нужно написать для этого дела тест.
I>>Зато в с#, C++ придется городить всякие визиторы.
G>И часто тебе приходится их городить? Я визиторы писал пару раз в жизни всего. Еще несколько раз пользовался готовыми.

мне вот обходы всякие приходится писать чуть не постоянно

I>>В итоге и там и там придется тесты писать
G>В динамических языках придется писать больше тестов для получения того уже уровня надежности кода.

теоретически

I>>а основная логика в динамическом языке будет гораздо проще читаться.
G>Опять-таки большая часть логики будет практически одинаково выражаться что в статике, что в динамике.

теоретически

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

J>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>Nemerle:

J>Боже... Дай, думаю, посмотрю, что пишут в "Дельфи против СИ++"...

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

I>>Это Руби а не питон.

KV>P.S: Я конечно не программист, но не до такой же степени. Руби от питона в состоянии отличить, по крайней мере

Я на всякий, что бы особо быстрые на руку не нагенерили мессагов что я руби от питона не в состоянии отличить

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

Можешь описать как в точности работает subroutine dispatcher или привести эквивалентный код на питоне?

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

KV>>>Nemerle:

J>>Боже... Дай, думаю, посмотрю, что пишут в "Дельфи против СИ++"...

Минусы за немерле, а примеры — хорошие.