Java vs Kotlin

Если кто не в теме: http://confluence.jetbrains.net/display/Kotlin/Welcome
Как считаете, взлетит/не взлетит?? ИМХО - шансы есть, ЗА: нормальный язык с тучей приятных плюшек + наличие хорошей IDE + достаточно известная компания за спиной. ПРОТИВ: достаточно инертные потребители (java - это всякие консерватиные банки и тд)

Чесно говоря - очень хочется, чтоб взлетел.

Почему не Scala vs Kotlin? Сами JetBrains именно с ней соревнуются.

Guderian потому что если Kotlin станет на один уровень со Scala - значит он проиграл ;-) не выстрелила скала. только для гиков подходит, собственно потому jetbrains и упрощают Kotlin

Цитата Guderian @ 21.07.11, 10:50

Сами JetBrains именно с ней соревнуются.

ну там есть еще ссылка http://confluence.jetbrains.net/display/Kotlin/Comparison+to+Java - значит соревнуются и с Java -)

Ну а вообще можно переименовать тему в: "Kotlin vs other JVM languages"

еще есть groovy, интересно, почему с ним не сравниваются?

Питон все равно всех порвет

Не понял, зачем это.

Цитата

make it safer than Java, i.e. statically check for common pitfalls such as null pointer dereference,
make it more concise than Java by supporting variable type inference, higher-order functions (closures), extension functions, mixins and first-class delegation, etc;

Ну и что, чтобы не было нульпойнтеров, переходить на новый язык?

Остальных новшеств не понял, поясните плз.

Цитата Машина @ 21.07.11, 13:14

Остальных новшеств не понял, поясните плз.

что конкретно непонятно?? Зачем замыкания нужны???

Ага, вторая строчка из цитаты - все не понятно. В том числе, что за замыкания

Замыкание
гугл такой гугл...

Цитата

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

Охренеть пользы

А вообще, не понял. Значит, это что-то сложное, и все непонятно, что это дает. Пока только лишний гемор

Цитата Машина @ 21.07.11, 13:39

А вообще, не понял. Значит, это что-то сложное, и все непонятно, что это дает. Пока только лишний гемор

вообще, скажем, я над такими сложностями и не задумываюсь
конкретно groovy дает возможность очень просто решить некоторые тонкости, которые на java я бы и решать не стал.

Цитата Машина @ 21.07.11, 13:39

А вообще, не понял. Значит, это что-то сложное, и все непонятно, что это дает. Пока только лишний гемор

Ну бывает. Не каждый программист поймет что такое "функция"..

Цитата Romkin @ 21.07.11, 12:42

Питон все равно всех порвет

Если авторы решат проблемы несовместимости версий. Учитывая, что сейчас они там на каждой минорной версии название главной dll-ки меняют, на нем серьезные программы не очень-то попишешь.

Цитата amk @ 21.07.11, 14:51

Если авторы решат проблемы несовместимости версий. Учитывая, что сейчас они там на каждой минорной версии название главной dll-ки меняют, на нем серьезные программы не очень-то попишешь.

и доведут производительность до уровня джавы...

Ну, интерпретатор обязан уступать в производительности. Вот с VBS (VBA) или JS он мог бы потягаться.
Решение проблемы совместимости обеспечило бы сопровождение многоязычных программ (где критичные части написаны на C, например). Сейчас с изменением версии интерпретатора нужно пересобирать C-часть.

Цитата amk @ 21.07.11, 15:04

Ну, интерпретатор обязан уступать в производительности.

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

динамика идет лесом.

Цитата amk @ 21.07.11, 14:51

Если авторы решат проблемы несовместимости версий. Учитывая, что сейчас они там на каждой минорной версии название главной dll-ки меняют, на нем серьезные программы не очень-то попишешь.

Это да, жесть. Но вроде в 3.3 обещаются сделать универсально.

Цитата jack128 @ 21.07.11, 17:29

динамика идет лесом.

да ну? статика уже научилась определять типы произвольным предикатом?

Цитата korvin @ 21.07.11, 17:43

Цитата jack128 @ 21.07.11, 17:29

динамика идет лесом.

да ну? статика уже научилась определять типы произвольным предикатом?

определение типов в рантайме идёт лесом.

Цитата Повстанець @ 21.07.11, 17:45

определение типов в рантайме идёт лесом.

дык я и спрашиваю статика уже научилась определять такие типы? в компайл-тайме? а раз нет -- то она идет лесом =)

Цитата korvin @ 21.07.11, 18:18

дык я и спрашиваю статика уже научилась определять такие типы? в компайл-тайме?

Как ты себе представляешь определение типа в компил-тайме? Если зависимость поведения от типа -- то научилась.

Цитата Guderian @ 21.07.11, 10:50

Почему не Scala vs Kotlin? Сами JetBrains именно с ней соревнуются.

ИМХО, особых преимуществ перед scala нет. Зачем тогда оно?

Добавлено 21.07.11, 20:08

Цитата zera @ 21.07.11, 11:20

еще есть groovy, интересно, почему с ним не сравниваются?

Цитата Romkin @ 21.07.11, 12:42

Питон все равно всех порвет

У них обоих динамическая типизация.

ИМХО, но "должен" быть некий "стэк языков" - язык для системной части(на случай низкоуровневых взаимодействий, оптимизация и т.п.), язык для прикладных задач(статическая строгая типизация, мощная система типов, богатые средства построения абстракций и т.п.), "скриптовый" язык(динамичный, гибкий, простой, лаконичный и т.п.).

Цитата jack128 @ 21.07.11, 10:58

Guderian потому что если Kotlin станет на один уровень со Scala - значит он проиграл ;-) не выстрелила скала. только для гиков подходит, собственно потому jetbrains и упрощают Kotlin

И на какой рынок они тогда метят? PHP?

Цитата korvin @ 21.07.11, 17:43

да ну? статика уже научилась определять типы произвольным предикатом?

Кто-то уже научился это использовать в практических целях?

Цитата D_KEY @ 21.07.11, 20:00

ИМХО, но "должен" быть некий "стэк языков" - язык для системной части(на случай низкоуровневых взаимодействий, оптимизация и т.п.), язык для прикладных задач(статическая строгая типизация, мощная система типов, богатые средства построения абстракций и т.п.), "скриптовый" язык(динамичный, гибкий, простой, лаконичный и т.п.).

Я ж говорю, .NET рулит)) Для второго есть вагон CLR-языков, для третьего - DLR (втч IronPython).

Цитата Guderian @ 22.07.11, 05:21

Кто-то уже научился это использовать в практических целях?

в Racket довольно широко используется

Цитата korvin @ 21.07.11, 17:43

определять типы произвольным предикатом

А что имеется в виду ?

Цитата IL_Agent @ 22.07.11, 08:18

Цитата korvin @ 21.07.11, 17:43

определять типы произвольным предикатом

А что имеется в виду ?

(define (natural? x)
  (and (integer? x) (positive? x)))
 
(define (make-vector size item-generator)
  ...)
 
(provide/contract
  (natural? (any? . -> . boolean?))
  (make-vector (natural? procedure? . -> . vector?)))

Объяснил

Цитата Romkin @ 22.07.11, 09:18

Объяснил

используем предикат natural? для определения типа

Как я понял. Пишем предикат natural?, который определяет, является ли объект неизвестного типа натуральным числом. И теперь у нас natural? какгбэ тоже тип. Можем объявлять контракт, который требует соответствия параметров этому типу. Так что ли ?

Добавлено 22.07.11, 09:59

Цитата korvin @ 22.07.11, 09:48

используем предикат natural? для определения типа

ну, значит так

Добавлено 22.07.11, 10:04
Написать предикат, который проверяет тип аргумента, во многих языках можно. Вызывай его вначале любой функции для проверки аргументов - вот тебе и контракт

Сообщение отредактировано: IL_Agent - 22.07.11, 10:04

Цитата korvin @ 22.07.11, 05:37

в Racket довольно широко используется

А сам Racket уже научились использовать в практических целях?

Цитата korvin @ 22.07.11, 09:48

используем предикат natural? для определения типа

А почему все время спрашиваешь, не уверен?

Цитата IL_Agent @ 22.07.11, 09:58

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

дык это динамическая типизация =) когда такое будет в статике? =)

http://antilamer.livejournal.com/366341.html?thread=3307013#t3307013

Ну, там правильно пишут: непонятно на кой он.

Добавлено 22.07.11, 19:22
korvin, а в статике нельзя определить тип во время исполнения что ли?

Цитата MyNameIsIgor @ 22.07.11, 19:22

korvin, а в статике нельзя определить тип во время исполнения что ли?

можно, только это не статика будет =)

Цитата korvin @ 22.07.11, 19:52

можно, только это не статика будет =)

Нуууу... Имелась то ввиду, так скажем, типизация по умолчанию. А так и в сисярпе есть dynamic

Цитата korvin @ 22.07.11, 14:33

дык это динамическая типизация =) когда такое будет в статике? =)

Динамическая типизация - это когда тип переменной определяется во время выполнения, а не задаётся при написании или выводится при компиляции. Так ? А проверить тип, а затем выполнить определённые действия в зависимости от него, можно и при статической типизации. См. dynamic_cast, например.

Цитата korvin @ 22.07.11, 14:33

дык это динамическая типизация =) когда такое будет в статике? =)

Блин, есть уже. Хз сколько раз показывал.

template<typename T>
void fun(T p);
 
template<>
void fun<int>(int p)
{
    std::cout << "реализация для int" << std::endl;
}
 
template<>
void fun<float>(float p)
{
    std::cout << "реализация для float" << std::endl;
}
 
template<>
void fun<std::string>(std::string p)
{
    static_assert(true, "реализация для строк запрещена");//ошибка на этапе компиляции
}
 
template<typename T>
void fun(T p)
{
    std::cout << "реализация для всего остального" << std::endl;
}

Сообщение отредактировано: Повстанець - 22.07.11, 21:57

Цитата Повстанець @ 22.07.11, 21:55

Блин, есть уже. Хз сколько раз показывал.

А для int, который > 0 ?

Цитата IL_Agent @ 22.07.11, 22:04

А для int, который > 0 ?

template<int i>
void fun()
{
    static_assert(i > 0, "только больше нуля");//скомпилится только при i>0
}

Цитата Повстанець @ 22.07.11, 22:10

Цитата IL_Agent @ 22.07.11, 22:04

А для int, который > 0 ?

template<int i>
void fun()
{
    static_assert(i > 0, "только больше нуля");//скомпилится только при i>0
}

и где здесь выделение типа? =)

#include <iostream>
 
template<int i>
void fun () {
    static_assert( i > 0, "natural" );
    std::cout << "Natural: " << i << std::endl;
}
 
template<int i>
void fun () {
    std::cout << "Integer: " << i << std::endl;
}
 
int main () {
}

фиг с ней с ошибкой про ассерт, но переопределение шаблона -- вот, что важно:

[ ~/devel/c++ ] g++ test.cpp
test.cpp: В функции «void fun()»:
test.cpp:5:34: ошибка: «static_assert» не имеет аргументов, зависящих от параметра-шаблона, поэтому должна быть доступна декларация «static_assert» [-fpermissive]
test.cpp:5:34: замечание: (с ключом «-fpermissive», G++ примет данный код, но разрешение использовать недекларированные имена будет отменено в дальнейших версиях)
test.cpp: At global scope:
test.cpp:10:11: ошибка: redefinition of «template<int i> void fun()»
test.cpp:4:11: ошибка: «template<int i> void fun()» previously declared here

Цитата korvin @ 23.07.11, 07:28

фиг с ней с ошибкой про ассерт, но переопределение шаблона -- вот, что важно:

Не, это не важно. Повстанець написал пример просто шаблонной функции, которая компилируется только в случае, если её аргумент больше нуля. Если нужно выбрать реализацию, то можно так.

Цитата MyNameIsIgor @ 23.07.11, 08:50

Не, это не важно. Повстанець написал пример просто шаблонной функции, которая компилируется только в случае, если её аргумент больше нуля. Если нужно выбрать реализацию, то можно так.

ой ли? http://ideone.com/h9xG7

Цитата

fun<i>();

И где тут статика?

Цитата Повстанець @ 23.07.11, 11:30

Цитата

fun<i>();

И где тут статика?

вот я вас и спрашиваю, господа фанатики статики =)

http://ideone.com/nnlJ7

все типы известны на этапе компиляции, так как мне объявить i чисто статично, чтоб шаблон сработал?

Добавлено 23.07.11, 11:37

Цитата Повстанець @ 23.07.11, 11:36

http://ideone.com/nnlJ7

э не, не катит, мне нужна переменная, а не константа

Цитата korvin @ 23.07.11, 11:35

вот я вас и спрашиваю, господа фанатики статики =)

Про статику спрашивал ты, а сам норовишь передать динамическую переменную.

Добавлено 23.07.11, 11:38

Цитата korvin @ 23.07.11, 11:36

мне нужна переменная

Зачем тогда спрашивал про статику?

Правильно, как ты в статике проверишь значение переменной, не константы?
Удали 19 строку.
Или объяви i константой.

korvin, ой ли.

Цитата amk @ 23.07.11, 11:38

Правильно, как ты в статике проверишь значение переменной, не константы?
Удали 19 строку.
Или объяви i константой.

известно как: определив тип переменной как (int > 0)

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

Цитата MyNameIsIgor @ 23.07.11, 11:39

korvin, ой ли.

см. выше. мне не нужна константа

korvin, теперь так модно троллить? Что-то лоровских аналитегов напоминает... Т.е. сделать if на значение int'а и в зависимости от его результата вызвать нужную функцию - это не судьба?

Цитата amk @ 23.07.11, 11:42

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

какие еще фокусы сопоставлением? я лишь прошу продемонстрировать, как статически определить тип (int > 0). (это лишь для простоты, не нужно тыкать unsigned'тами =) )

Цитата korvin @ 23.07.11, 11:42

см. выше. мне не нужна константа

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

Цитата MyNameIsIgor @ 23.07.11, 11:43

korvin, теперь так модно троллить? Что-то лоровских аналитегов напоминает... Т.е. сделать if на значение int'а и в зависимости от его результата вызвать нужную функцию - это не судьба?

не я заикнуля, что "динамическая типизация не нужна"

Добавлено 23.07.11, 11:45

Цитата Повстанець @ 23.07.11, 11:43

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

задача изначально была одна: определить тип (int > 0) средствами статической типизации. если ты ее как-то не так понял, не зачем возмущаться =)

Сообщение отредактировано: korvin - 23.07.11, 11:45

Цитата korvin @ 23.07.11, 11:43

какие еще фокусы сопоставлением? я лишь прошу продемонстрировать, как статически определить тип (int > 0). (это лишь для простоты, не нужно тыкать unsigned'тами =) )

Маразм крепчал. Шиза косила наши ряды. Вот уже статически выбрать реализацию в зависимости от значения в рантайме.
И да, не надо говорить, что это динамическая типизация. Это обычный if. Если это - прелести динамики, то мне её искренне жаль: она убога вплоть до обычного if'а.

Добавлено 23.07.11, 11:46

Цитата korvin @ 23.07.11, 11:44

не я заикнуля, что "динамическая типизация" не нужна

А я здесь типизации не вижу.

Цитата MyNameIsIgor @ 23.07.11, 11:45

Маразм крепчал. Шиза косила наши ряды. Вот уже статически выбрать реализацию в зависимости от значения в рантайме.

ой лол, тебе система типов на что дадена?

Цитата korvin @ 23.07.11, 11:44

задача изначально была одна: определить тип (int > 0) средствами статической типизации. если ты ее как-то не так понял, не зачем возмущаться =)

Кинь ка мне ссылочку на изначальное определение задачи.

Добавлено 23.07.11, 11:47
Может я чего упустил.

Цитата MyNameIsIgor @ 23.07.11, 11:45

А я здесь типизации не вижу.

как это нет? integer -- один тип, natural -- другой. у них есть определенные различия

Добавлено 23.07.11, 11:49

Цитата Повстанець @ 23.07.11, 11:46

Кинь ка мне ссылочку на изначальное определение задачи.

Может я чего упустил.

вот основной вопрос: Java vs Kotlin (сообщение #2941949)

в качестве примера я выбрал определение типа (int > 0)

Цитата korvin @ 23.07.11, 11:46

ой лол, тебе система типов на что дадена?

Явно не для того, чтобы ветвления устраивать, ага.

Цитата korvin @ 23.07.11, 11:47

в качестве примера я выбрал определение типа (int > 0)

Что выбрал, то и получил. Хотел в статике -- получил в статике.

Цитата MyNameIsIgor @ 23.07.11, 11:50

Явно не для того, чтобы ветвления устраивать, ага.

какие ветвления? о чем ты? я всего лишь хочу тип natural

Цитата korvin @ 23.07.11, 11:44

задача изначально была одна: определить тип (int > 0) средствами статической типизации

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

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

Цитата Повстанець @ 23.07.11, 11:52

Что выбрал, то и получил. Хотел в статике -- получил в статике.

нет, не получил

Цитата korvin @ 23.07.11, 11:56

нет, не получил

Да ну... Статика? Статика... Всё что меньше нуля отбрасывает? Отбрасывает.

Все дальнейшие условия появились после решения этой задачи.

Сообщение отредактировано: Повстанець - 23.07.11, 12:00

Цитата amk @ 23.07.11, 11:55

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

я уже показывал:

(define (natural? x)
  (and (integer? x) (positive? x)))
 
; или используя контракт and/c:
 
(define natural? (and/c integer? positive?))

все

Цитата amk @ 23.07.11, 11:55

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

я знаю, проверка в конструкторе. только в динамике и так все в динамике, поэтому противоречий с системой типов не происходит. и таки в динамике применяются.

Добавлено 23.07.11, 12:01

Цитата Повстанець @ 23.07.11, 11:57

Да ну... Статика? Статика... Всё что меньше нуля отбрасывает? Отбрасывает.

пример с переменными, а не константами, будет? или вы всю программу в константах пишете?

Цитата korvin @ 23.07.11, 12:00

пример с переменными, а не константами, будет?

Ты не просил переменных и рантайм. Ты просил статику и этап компиляции.

korvin, вам бы научиться изъясняться... Желательно по-русски...

Цитата korvin @ 23.07.11, 12:00

я знаю, проверка в конструкторе.

Жаждите увидеть такое? Тогда к чему вопросы, если понятно, что это реализуемо?

Нифига не понял.

template <bool> Bool2Type{};
 
template <typename T> T f(T t, Bool2Type<false>);
template <typename T> T f(T t, Bool2Type<true>);
 
template <typename T> T f(T t)
{
  return f(t, Bool2Type<std::numeric_limits<T>::is_signed>());
}

Цитата Повстанець @ 23.07.11, 12:02

Ты не просил переменных и рантайм. Ты просил статику и этап компиляции.

угу, статику с переменными, или что, статическая типизация этого не позволяет? константы я и в CL/Racket могу в compile-time проверять.

Добавлено 23.07.11, 16:47

Цитата MyNameIsIgor @ 23.07.11, 12:06

Жаждите увидеть такое?

нет, такой ад не жажду увидеть

Добавлено 23.07.11, 16:47

Цитата Qraizer @ 23.07.11, 14:55

Нифига не понял.

template <bool> Bool2Type{};
 
template <typename T> T f(T t, Bool2Type<false>);
template <typename T> T f(T t, Bool2Type<true>);
 
template <typename T> T f(T t)
{
  return f(t, Bool2Type<std::numeric_limits<T>::is_signed>());
}

аналогично

Цитата korvin @ 23.07.11, 16:46

нет, такой ад не жажду увидеть

Жалкий ниасилятор

Цитата MyNameIsIgor @ 23.07.11, 17:19

Цитата (korvin @ Вчера, 19:46)
нет, такой ад не жажду увидеть
Жалкий ниасилятор

Пример был реально аццкий)) Недетерминированный тип простым фабричным методом... оригинально. А если условие чуть усложниться? Надо будет, скажем, отдельный тип для простых чисел. На что unsigned заменишь, чтобы контроль не потерять? В этом плане пример korvin'а, конечно, рафинирован гораздо лучше.

Цитата Guderian @ 24.07.11, 15:54

Пример был реально аццкий))

Кто-то однажды показывал колбасню из тернарных операторов - вот это был пейзаж ада. А здесь всё банально и очень просто.

Цитата Guderian @ 24.07.11, 15:54

Недетерминированный тип

Какой? Определение недетеминированного типа?

Цитата Guderian @ 24.07.11, 15:54

простым фабричным методом... оригинально

Именно - простым. Как задача поставлена, так она и сделана.

Цитата Guderian @ 24.07.11, 15:54

А если условие чуть усложниться? Надо будет, скажем, отдельный тип для простых чисел. На что unsigned заменишь, чтобы контроль не потерять?

Ни на что. Проверка просто будет в конструкторе с выбросом исключения если не пройдёт. Как, кстати, надо было и здесь сделать с проверкой >0 для натуральных чисел, я просто торопился.

Цитата Guderian @ 24.07.11, 15:54

В этом плане пример korvin'а, конечно, рафинирован гораздо лучше.

А никто и не утверждал обратного. korvin повёлся на банальнейший вброс, но для демонстрации преимуществ динамической типизации выбрал из рук вон плохой пример - вот и всё, что тут было.

Сообщение отредактировано: MyNameIsIgor - 24.07.11, 20:05

Цитата MyNameIsIgor @ 24.07.11, 19:53

Кто-то однажды показывал колбасню из тернарных операторов - вот это был пейзаж ада. А здесь всё банально и очень просто.

Простота разная бывает. Если речь о лаконичности, то это скорее относится к примеру korvin, поскольку с ростом сложности приложения, сложность поддержки его natural типа не меняется. Если же речь идет о простоте, когда сортир - это яма и доска с дырками, то да, на данном этапе все выглядит просто. А стоит заглянуть на несколько ходов вперед - на каждом шагу заботливо положена грабелька))

Цитата MyNameIsIgor @ 24.07.11, 19:53

Какой? Определение недетеминированного типа?

Забавный каламбур в форме диалога получается. Учитывая, что детерминированный - суть определенный (даже и в мыслях не было, что этот термин нуждается в трансляции) выходит:
Guderian: ...неопределенный тип...
MyNameIsIgor: Какой? Определение неопределенного типа?
Просто термин динамического типа претерпел уже такую инфляцию, что язык не поворачивается его активно использовать. Взять хотя бы упоминавшийся dynamic из шарпа. Назвали динамическим прокси-тип который транслирует запросы к... опять же "статическим" типам.

Цитата MyNameIsIgor @ 24.07.11, 19:53

Именно - простым. Как задача поставлена, так она и сделана.

Не простым, а сильно редуцированным. Как только приложение начинает свой рост и возникает необходимость в перегрузке кастингов/операторов, аксессорах и т.п. - начнутся проблемы. If-ами на каждом шагу будешь в землю вгрызаться. Как думаешь, сколько девелоперов из 100 забудут при реализации операции вычитания проконтролировать натуральность ее выхлопа?

Цитата MyNameIsIgor @ 24.07.11, 19:53

А никто и не утверждал обратного. korvin повёлся на банальнейший вброс, но для демонстрации преимуществ динамической типизации выбрал из рук вон плохой пример - вот и всё, что тут было.

Пока даже на такой плохой пример не нашлось достойной альтернативной реализации.

Цитата Guderian @ 25.07.11, 06:10

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

Глухой write only mode...

Цитата MyNameIsIgor @ 24.07.11, 19:53

Цитата Guderian @ 24.07.11, 15:54

В этом плане пример korvin'а, конечно, рафинирован гораздо лучше.

А никто и не утверждал обратного.

korvin ни словом не обмолвился о лаконичности решения. Он поставил под сомнение саму возможность решения.

Цитата korvin @ 21.07.11, 17:43

статика уже научилась определять типы произвольным предикатом?

И для тех, кто не читает тему, в которую постит, сообщаю, что вот это

Цитата jack128 @ 21.07.11, 17:29

динамика идет лесом.

говорил не я.

Цитата Guderian @ 25.07.11, 06:10

Забавный каламбур в форме диалога получается. Учитывая, что детерминированный - суть определенный (даже и в мыслях не было, что этот термин нуждается в трансляции) выходит:
Guderian: ...неопределенный тип...
MyNameIsIgor: Какой? Определение неопределенного типа?

Да, забавно. Оказывается, вы неплохо работаете в роли текстового препроцессора - смысла не понимаете, но find & replace работает "на ура".

Цитата Guderian @ 25.07.11, 06:10

Просто термин динамического типа претерпел уже такую инфляцию, что язык не поворачивается его активно использовать. Взять хотя бы упоминавшийся dynamic из шарпа. Назвали динамическим прокси-тип который транслирует запросы к... опять же "статическим" типам.

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

Цитата Guderian @ 25.07.11, 06:10

Не простым, а сильно редуцированным. Как только приложение начинает свой рост и возникает необходимость в перегрузке кастингов/операторов, аксессорах и т.п. - начнутся проблемы. If-ами на каждом шагу будешь в землю вгрызаться. Как думаешь, сколько девелоперов из 100 забудут при реализации операции вычитания проконтролировать натуральность ее выхлопа?

Какие сто программистов? Которые будут операторы юзать? А на кой им проверять то? Проверку пишут один раз в реализации оператора и кидают исключение, если она не прошла. А для ста программистов оператор либо выполнился и вернул заведомо валидный результат, либо не выполнился вовсе - никаких проверок.

Цитата Guderian @ 25.07.11, 06:10

Пока даже на такой плохой пример не нашлось достойной альтернативной реализации.

Возможно, не нашлось реализации, которая удовлетворила бы вас... Но это только ваши проблемы, меня никак не касающиеся.

Сообщение отредактировано: MyNameIsIgor - 25.07.11, 15:30

Цитата MyNameIsIgor @ 25.07.11, 15:21

Глухой write only mode...

Цитата MyNameIsIgor @ 25.07.11, 15:21

И для тех, кто не читает тему, в которую постит

Цитата MyNameIsIgor @ 25.07.11, 15:21

вы неплохо работаете в роли текстового препроцессора - смысла не понимаете

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

Цитата MyNameIsIgor @ 25.07.11, 15:21

korvin ни словом не обмолвился о лаконичности решения. Он поставил под сомнение саму возможность решения.

Единственная цитата korvin, которую я прокомментировал - это:

Цитата korvin @ 23.07.11, 16:46

нет, такой ад не жажду увидеть

Потому как код… никакой. Но Ваше желание его защитить любой ценой мне вполне понятны и простительны. С нетерпением жду следующего выброса эмоций на вентилятор))

Цитата MyNameIsIgor @ 25.07.11, 15:21

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

"Под детерминированностью процессов в мире понимается однозначная предопределённость" (с) Вика. Встает вопрос, почему я не мог использовать этот термин применительно к типу, который не "предопределен однозначно"?

Цитата MyNameIsIgor @ 25.07.11, 15:21

Какие сто программистов? Которые будут операторы юзать? А на кой им проверять то? Проверку пишут один раз в реализации оператора и кидают исключение, если она не прошла. А для ста программистов оператор либо выполнился и вернул заведомо валидный результат, либо не выполнился вовсе - никаких проверок.

Под "реализацией операции вычитания" подразумевалась именно реализация, а не использование. Сто программистов были упомянуты для статистики, ибо на одном статистику не меряют. Если бы меряли, то она была бы 0% валидного кода, ибо Вы же даже не задумались над тем, чтобы проконтролировать вход конструктора. И так, наверняка, поступило бы больше половины. Доведись мне поддерживать такой класс, писанный другим человеком, и поставь передо мной задачу добавить ему операцию умножения на константу, я бы прошляпил проверки запросто. А если бы не прошляпил , то совершил бы ошибку, поскольку в какой-то момент времени меня подвела память и я было подумал, что натуральные=неотрицательные))

Цитата MyNameIsIgor @ 25.07.11, 15:21

Возможно, не нашлось реализации, которая удовлетворила бы вас... Но это только ваши проблемы, меня никак не касающиеся.

Я знаю, что это мои проблемы. Мои и моих заказчиков, которые частенько приходят ко мне с таким кодом, что без слез и не взглянешь. А все потому, что некие кодеры до меня решили, что проблемы, с которыми они не столкнулись сейчас - это проблемы тех разработчиков, что будут потом. И дальше одного хода в это программной партии они не видят.

Цитата korvin @ 23.07.11, 16:46

аналогично

Что именно? Тот же "неосилимый" полиморфизм, только в статике. Что пояснить?

Цитата Guderian @ 25.07.11, 16:30

Опаньки... трололо понеслось))

Т.е. перевернуть всё с ног на голову и сделать вид невинной овечки "я не понял, что с меня просят определение термина" - это "трололо понеслось))" в вашей терминологии. Продолжайте в том же духе, я начинаю запоминать ваши термины.

Цитата Guderian @ 25.07.11, 16:30

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

Цитата Guderian @ 25.07.11, 16:30

Потому как код… никакой.

Ах, так вы, оказывается, вовсе не про возможность решения разговариваете, а про мой код? Впрочем, после кухонных терминов я должен был догадаться... Ну, давайте обсудим мой код, но прежде реализуйте заявленный вами функционал (т.е. с операторами) на любом языке программирования, я не настаиваю на статически типизированном.

Цитата Guderian @ 25.07.11, 16:30

"Под детерминированностью процессов в мире понимается однозначная предопределённость" (с) Вика. Встает вопрос, почему я не мог использовать этот термин применительно к типу, который не "предопределен однозначно"?

Защищать свой родной кухонный термин - ведь так это называется в вашей терминологии. Ну, что же, разжёвываю. Во-первых, термин "недетерминированный тип" не общепринятый, вы его сами придумали, и я не собираюсь предполагать, что именно вы под ним подразумевали. Во-вторых, он вполне определён однозначно, просто проверяется во время исполнения, а не компиляции. Как вам пришла мысль, что динамическая типизация недетерминирована, я даже предположить боюсь.

Цитата Guderian @ 25.07.11, 16:30

Под "реализацией операции вычитания" подразумевалась именно реализация, а не использование. Сто программистов были упомянуты для статистики, ибо на одном статистику не меряют. Если бы меряли, то она была бы 0% валидного кода, ибо Вы же даже не задумались над тем, чтобы проконтролировать вход конструктора. И так, наверняка, поступило бы больше половины. Доведись мне поддерживать такой класс, писанный другим человеком, и поставь передо мной задачу добавить ему операцию умножения на константу, я бы прошляпил проверки запросто. А если бы не прошляпил , то совершил бы ошибку, поскольку в какой-то момент времени меня подвела память и я было подумал, что натуральные=неотрицательные))

Об этом мы поговорим после того, как вы покажете свою реализацию как я просил выше.

Цитата Guderian @ 25.07.11, 16:30

Я знаю, что это мои проблемы. Мои и моих заказчиков

Так вот и идите... решать их.

Сообщение отредактировано: MyNameIsIgor - 25.07.11, 21:38

Эх, холивары, они такие холивары)) Приступим к утренней разминке)

Цитата MyNameIsIgor @ 25.07.11, 21:37

Т.е. перевернуть всё с ног на голову и сделать вид невинной овечки "я не понял, что с меня просят определение термина" - это "трололо понеслось))" в вашей терминологии. Продолжайте в том же духе, я начинаю запоминать ваши термины.

Поделюсь своими наблюдениями. Есть несколько категорий людей. Первые - самые мудрые, они быстро расшифровывают определение термина и дальше рубят по сути вопроса, не останавливаясь на мелочах. Вторым нужно объяснить, но после этого они уже берут быстрый старт. Третьим - сколько не объясняй. Из ваших пяти абзацев три касаются в той или иной степени термина. Это ж какое отсутствие аргументов надо иметь, чтобы так увлечься этим вопросом))

Но коль скоро он так Вас беспокоит, то каюсь. Использовал уродливый неологизм. Видимо, на это повлиял тот факт, что техническую литературу приходиться читать исключительно на англицком, а там фраза "determin{e|ed|ing|etc} type" в порядке вещей. Тот же драфт на C++0x - это ж пытка для моего неопытного ума:

Цитата

"Some objects are polymorphic (10.3); the implementation generates information associated with each such object that makes it possible to determine that object’s type during program execution. For other objects, the interpretation of the values found therein is determined by the type of the expressions (Clause 5) used to access them."

Знакомая ситуация, правда? Кто-то недавно использовал полиморфизм в своем примере, чтобы "determine that object's type". Хотя хотелось бы, чтобы тип "determined by the type" выражения. А уж в разделе declarations/declarators от determine просто спасу нет:

Цитата

First, the decl-specifier-seq determines a type. In a declaration
T D
the decl-specifier-seq T determines the type T. [ Example: in the declaration
int unsigned i;
the type specifiers int unsigned determine the type “unsigned int” (7.1.6.2). —end example ]

От такого засилия фраз, что тип детерминирован, я невольно привык его употреблять равно как и термины дефинитивный, декларативный, императивный и еще вагон других. Извиняюсь за свой, как Вы выразились "кухонный термин", навеянный прочтением стандартов и искренне надеюсь, что я был исчерпывающ в своем извинении))

Цитата MyNameIsIgor @ 25.07.11, 21:37

Ах, так вы, оказывается, вовсе не про возможность решения разговариваете, а про мой код?

Я искренне полагал, что только я в "глухом write-only", как Вы изволили выразиться... А то, что я Вам адресовал, начиналось с цитаты korvin касающейся конкретного кода и моей фразы "Пример был…". Постараюсь в следующий раз сопровождать дополнительными указателями, подсказками, сигнальными флажками и т.п.

Цитата MyNameIsIgor @ 25.07.11, 21:37

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

Если я буду реализовывать на привычном мне шарпе, то у меня получится та же херня с теми же проблемами. И как я говорил ранее, не поможет даже dynamic. Так что, как бы это ни было для меня унизительно, я не смогу написать код лучше чем Ваш)) Я бы даже сказал по-другому. Это не столько проблемы того самого кода, поскольку он, по сути, выжимает все возможное из имеющихся средств и попросту аккумулирует классику ООП - полиморфизм + идея паттерна Factory Method. Проблема в самом ооп. А как на ооп-языках со статической типизацией написать лучше - я не знаю. Может быть я и сделал немного по-другому, но это больше нацелено на то, чтобы застелить все соломой и дизайн стал bulletproof. А концептуально - такая же херня))

Цитата MyNameIsIgor @ 25.07.11, 21:37

термин "недетерминированный тип" не общепринятый

Не в защиту термина, а просто лингивистических размышлений цепочка: "тип" - общепринятый, "детерминированный" - общепринятый, а "не детерминированный тип" - не общепринятый)) Интересно, является ли общепринятым "синий икосаэдр"...

Цитата MyNameIsIgor @ 25.07.11, 21:37

Во-вторых, он вполне определён однозначно, просто проверяется во время исполнения, а не компиляции. Как вам пришла мысль, что динамическая типизация недетерминирована, я даже предположить боюсь.

Полиморфный костыль под названием number - это "определен однозначно"? Тогда в шарпе/яве "object x = любая_херня_хоть_число_хоть_строка" - это тоже однозначное определение. Ну и что, что всё есть object, использован тот же принцип. Ввели предка (Ваш класс number), определили его наследников (Ваши же integer, natural) и решили, что тип number, лежащий в корне иерархии наследования (не его ли вычислит auto?) - это однозначное определение. Т.е. неоднозначности integer это, или natural вообще не возникнет? Тогда добавьте, плиз, в natural метод foo и вызовите number->foo(). Посмотрим, так ли се "однозначно".

Цитата MyNameIsIgor @ 25.07.11, 21:37

Так вот и идите... решать их.

Не бздеть, у меня все под контролем))

А вообще, если отвлечься немного от холивара, то мне кажется имеет смысл говорить не о статическом и динамическом определении типов, а о декларативном и императивном. Если предикат вычислим во время компиляции, то это суть константа и здесь плюсЫ со своими возможностями метапрограммирования будут биться на равных. Значит плавно перетекаем в рантайм, где осуществляется вычисление предиката со всеми сопутствующими механизмами контроля. Но в случае с декларативным определением, транслятор имеет генеративные возможности по самостоятельному формированию необходимого контроля. А императивно мы сами должны его обеспечить, что не есть гут.

Цитата Guderian @ 26.07.11, 07:15

Видимо, на это повлиял тот факт, что техническую литературу приходиться читать исключительно на англицком, а там фраза "determin{e|ed|ing|etc} type" в порядке вещей. Тот же драфт на C++0x - это ж пытка для моего неопытного ума: <и далее по тексту>

Ваш ум действительно неопытный, если вы так и не поняли, что в приведённых цитатах нигде нет термина "детерминированный тип". Там есть только глаголы, относящиеся к прилагательному "тип": "определить тип", "определяется типом", "определяет тип". Надеюсь, вашего опыта использования русского языка хватит, чтобы понять разницу.

Цитата Guderian @ 26.07.11, 07:15

Полиморфный костыль под названием number - это "определен однозначно"?

А при чём тут моя реализация? Тип вполне однозначно определён и в примере korvin'а. Просто потому, что он однозначно определён уже в задании: это либо натуральные числа (надеюсь, не будете спорить, что это однозначное определение), либо целые (так же искренне надеюсь, что разночтений не возникнет).

Цитата Guderian @ 26.07.11, 07:15

Тогда в шарпе/яве "object x = любая_херня_хоть_число_хоть_строка" - это тоже однозначное определение. Ну и что, что всё есть object, использован тот же принцип. Ввели предка (Ваш класс number), определили его наследников (Ваши же integer, natural) и решили, что тип number, лежащий в корне иерархии наследования (не его ли вычислит auto?) - это однозначное определение. Т.е. неоднозначности integer это, или natural вообще не возникнет? Тогда добавьте, плиз, в natural метод foo и вызовите number->foo(). Посмотрим, так ли се "однозначно".

Вы в очередной раз путаете Божий дар с яичницей. Вы говорите не об определении типа, а о типизации. Во-первых, динамическая типизация вполне себе детерминирована. Во-вторых, по вашему выходит, что любой класс, который имеет (может иметь) наследников, является неопределённым типом, что есть явная чушь.

Цитата Guderian @ 26.07.11, 07:15

Но коль скоро он так Вас беспокоит, то каюсь. Использовал уродливый неологизм.

Цитата Guderian @ 26.07.11, 07:15

Извиняюсь за свой, как Вы выразились "кухонный термин", навеянный прочтением стандартов и искренне надеюсь, что я был исчерпывающ в своем извинении))

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

Цитата Guderian @ 26.07.11, 07:15

Третьим - сколько не объясняй.

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

Самое интересное, что спор на самом деле не имеет отношения к статической или динамической типизации.
Ясно, что независимо от вида типизации значение неизвестное во время компиляции, можно проверить только в рантайме.
С другой стороны, чтобы выполнить проверку при компиляции транслятор должен поддерживать глубокую интерпретацию константных выражений (в том смысле, что должен уметь вычислять не только простые выражения, но и доступные для интерпретации функции/процедуры). Опять же, независимо от вида типизации язык может при этом иметь или не иметь средства для прерывания компиляции в таком случае. В общем дело упирается в наличие нужных средств управления компиляцией, а не в статическую/динамическую типизацию.

Цитата MyNameIsIgor @ 26.07.11, 16:27

Ваш ум действительно неопытный, если вы так и не поняли, что в приведённых цитатах нигде нет термина "детерминированный тип". Там есть только глаголы, относящиеся к прилагательному "тип": "определить тип", "определяется типом", "определяет тип". Надеюсь, вашего опыта использования русского языка хватит, чтобы понять разницу.

Не знаю, насколько опыт русского языка применим к документации на английском, а вот опыт последнего мне подсказывает, что форма инфинитива, на которую вы ссылаетесь, применительно к той ситуации в которой я этот термин употреблял, находится в форме страдательного залога и звучит как determined (в примерах, что я приводил - "determined by the type of the expressions"). И тут на арену выходят правила русского языка, ибо страдательный залог трансформируется в страдательное причастие, которое в русском языке звучит как "детерминированный". Вот такая адъективация получилась. Надеюсь, я не очень сложно объяснил мыслительные процессы своего неопытного ума?))

Цитата MyNameIsIgor @ 26.07.11, 16:27

А при чём тут моя реализация?

Потому что, как я сказал предыдущие пятьдесят четыре раза, я обсуждал именно этот пример реализации.

Цитата MyNameIsIgor @ 26.07.11, 16:27

Вы в очередной раз путаете Божий дар с яичницей. Вы говорите не об определении типа, а о типизации. Во-первых, динамическая типизация вполне себе детерминирована.

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

Цитата MyNameIsIgor @ 26.07.11, 16:27

Во-вторых, по вашему выходит, что любой класс, который имеет (может иметь) наследников, является неопределённым типом, что есть явная чушь.

Согласен. Ваша фраза "класс является неопределенным типом" - полная чушь, ибо класс является вполне определенным типом. Я бы даже сказал, что он и есть тот тип, которым является)) А есть также экземпляр этого класса и он тоже вполне определенного типа. Типа этого же класса. А есть декларация, которая принудительно указывает экземпляру этого класса некий полиморфный тип. Это может быть number, а может вообще абстрактный указатель. Так что вы получите в результате? Определенный тип или декларированный тип с некоторым контрактом number, который вы хотите получить от значения, тип который вам доподлинно неизвестен? Если вы уверены, что тип определен, то вызовите foo() специфицированного в natural, как я предложил. Лисп это может (он, правда, и крякать натуральное число может заставить, но это отдельная тема), а вы без дополнительного определения через кастинг? Я бы все-таки различал определение типа и декларирование.

Цитата MyNameIsIgor @ 26.07.11, 16:27

Не обижайтесь, но надоедает даже такое увлекательное занятие, как кидать горох в стену.

Какие у вас, однако, странные увлечения)) Может заменить на что-то более полезное для дальнейшего развития и роста?)

Guderian

Цитата Guderian @ 26.07.11, 19:11

determined by the type of the expressions

Вообще-то более близкий по смыслу перевод для determine - определять, determined - определенный, определяемый. То есть "determined by the type of the expressions" переводится на русский язык скорее, как "определенный по типу выражения", "определяемый типом выражения" (тип - в смысле тип значения)

Статическая типизация тоже позволяет вычислять предикаты в рантайме.

KISS
Если считать, как я привык делать, что by обозначает творительный падеж, то...

Цитата amk @ 26.07.11, 19:39

"определяемый типом выражения"

Сообщение отредактировано: Qraizer - 26.07.11, 20:12

Цитата amk @ 26.07.11, 19:39

determine - определять, determined - определенный

Я и сказал, что отсылка шла к форме инфинитива, т.е. determine = определять/детерминировать, а страдательный залог determined становится страдательное формой причастия - определенный/детерминированный. Или речь идет о том, что я использовал англицизм? Так он давно используется. Детерминированные функции, детерминированная машина Тьюринга и т.п. Никто же не говорит "определенная функция", когда подразумевает ее детерминированность. Так и я, стараюсь избегать терминов, которые могут вызвать разночтение. Ибо typedef тоже дает определенный тип, но смысл этой определенности другой. Декларация T D, тоже дает определенный тип, уже третьего смысла. В общем одно наше "определять" с тремя их determine/declare/define не всегда справляется))

Цитата amk @ 26.07.11, 19:39

Статическая типизация тоже позволяет вычислять предикаты в рантайме.

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

Цитата amk @ 26.07.11, 17:21

В общем дело упирается в наличие нужных средств управления компиляцией, а не в статическую/динамическую типизацию.

Моё имхо, что за управляемой компиляцией будущее.

Цитата Qraizer @ 26.07.11, 20:11

Если считать, как я привык делать, что by обозначает творительный падеж, то...

Если быть точным, то фраза была "is determined by". Форма глагола "be" + Participle II - это классическое определение passive voice, "by" в passive voice указывает действующее лицо. Сам по себе voice/залог - это форма глагола, поэтому и переводить ее лучше в глагольно/причастной форме. Адъективация же глагола до прилагательного "определяемый" теряет семантику приложения, которое повествует о совершённом действии и низводит его до характеристики объекта. Чтобы не терять смысла, обычно осуществляется трансформация английского страдательного залога в наше страдательное причастие, в нашем случае определять->определен(краткая форма причастия)->определенный(полная форма причастия).

Цитата Guderian @ 27.07.11, 05:01

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

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

Цитата Guderian @ 27.07.11, 05:01

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

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

Цитата Guderian @ 27.07.11, 05:01

за управляемой компиляцией будущее

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


И слово "определяемый" в том контексте - не прилагательное, а причастие - форма страдательного залога настоящего времени.
определенный - страдательный залог прошедшего времени
определяющий - действительный залог настоящего времени
определивший - действительный залог прошедшего времени
определявший - несовершенный вид действительного залога прошедшего времени

Адъективации причастия (не глагола) в данном случае не происходит. так что с переводами все в порядке. Правда, без учета окружения, возможно, что перевод выпал из контекста.

Цитата amk @ 27.07.11, 12:42

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

Да я уже раз десять сказал, что неудачный для данного высокого общества подобрал термин)) По наивности думал, что у людей, которые с молоком матери (детерминированными алгоритмами, детерминированными машинами Тьюринга, детерминированными функциями и т.п.) должны были впитать принцип детерминированности, не будет проблем даже с такой непривычной формулировкой, которая поголовно встречается в англоязычной литературе. В том же упомянутом драфте я могу спокойной прочитать в разделе declarators про indetermined value и очень четко различается определение с дефинитивной точки зрения, декларативной и определение, как процесс (как дефинитивные, декларативные и оперативные нормы права, например). Читаю про auto - все четко: "determining the type specified for the contained declarator-id by such a declaration". Декларатор - отдельно, дереминирование - отдельно". Так что я, естественно, выбрал неудачные термин, ну а вы можете использовать "определенный" для typedef'ов, деклараторов, функций вычисления и еще чего угодно.

Хотите дам вам обоим подсказку, чтобы меня окончательно растоптать в части этого термина и публично выпороть, но математически грамотно?)) Как известно, типизация осуществляется двумя способами - перечислением и предикатом принадлежности. Перечисление детерминировано по определению. Предикат - это функция, для функции определение детерминированности существует, значит детерминированность предиката и логичней рассматривать в первую очередь. А в примере с натуральными числами предикат является детерминированной функцией. Написал и прям сам расстроился, какое фиаско потерпел)) Что за жизнь, вот так и холиварь сам с собой))

Цитата amk @ 27.07.11, 12:42

Не хочешь же ты сказать, что в языке с динамической типизацией ты можешь проверить значение до рантайма.

Я хочу сказать то, о чем писал уже пару раз до этого. В языке со статической типизацией я не могу получить доступ к методу foo, специфицированному в natural через контракт number. А в языке с динамической - запросто. Пусть сегодня это будет на Io.

// Модифицируем существующий числовой класс
Number do (
    isNatural := method(if(self > 0, true, false))
    // Здесь и будет реализован наш предикат
    auto := method (
        if (
            isNatural == false,
            // Для ненатуральных чисел добавляем специфичный метод
            self negative := method(self * (-1))
        )
        return self
    )
)
 
x := 2 auto
x isNatural println
>> true
 
y := (-3) auto
y isNatural println
>> false
 
// Как бы язык со статической типизацией достучался до negative через полиморфный тип, если он у него не определен?
// И где у меня здесь контракт?
y negative println
>> 3
 
// А вот и некоторого рода негативная сторона, о которой я говорил
x negative println
>> Number does not respond to 'negative'

Цитата amk @ 27.07.11, 12:42

И слово "определяемый" в том контексте

Возможны ты и прав.

Да тебя в общем-то никто не собирался топтать, я по крайней мере. Дело в том, что слово 'детерминированный' к объектам в программировании почти не применяется. Недетерминированность языковых конструкций (А именно она скрывается за словосочетанием "неопределенное поведение", хотя в оригинале и пишется "Undefined behavior") там считается одним из самых страшных грехов. Даже случайные числа в программировании детерминированные (потому и псевдослучайные). Недетерминированность разрешается только по заказу. Ну и входные данные могут обладать строго дозированной недетерминрованностью. И все.
Согласись, говорить, что сущность, которая просто обязаны быть детерминированной - детерминирована - это то же самое, что говорить, что масло является маслянистым.

Кстати тип может изначально обладать полиморфным поведением на основе свойств. Это конечно не то же самое, что полиморфизм потомков, но работает. Именно этот вариант, похоже, ты и реализовал (что это за язык, кстати). И такой полиморфизм динамически реализуем и в языках со статической типизацией (с одной поправкой - в языке со СТ нельзя в динамике проверить существование метода или атрибута, но можно проверить тип объекта).
По-моему интереснее был бы пример с фабрикой, на основе свойств создающей объект нужного типа. Этот вариант тоже работает при любом виде типизации. Причем, в случае статической типизации без дополнительных накладных расходов при работе с объектом.

Вообще, пример с целыми и натуральными числами выглядит несколько надуманным. Вдобавок ведущим к серьезным ошибкам.
В реальной практике эти числа не смешиваются в одном (атрибуте) объекте. То есть если по контракту атрибут должен быть целым числом, то, даже если присвоить ему натуральное значение, он должен принять положительное целое значение, к которому операция смены знака будет применима. А в обсуждаемом примере произойдет исключение.

Цитата amk @ 28.07.11, 13:59

Вообще, пример с целыми и натуральными числами выглядит несколько надуманным. Вдобавок ведущим к серьезным ошибкам.
В реальной практике эти числа не смешиваются в одном (атрибуте) объекте. То есть если по контракту атрибут должен быть целым числом, то, даже если присвоить ему натуральное значение, он должен принять положительное целое значение, к которому операция смены знака будет применима. А в обсуждаемом примере произойдет исключение.

никакого исключения:

#lang racket
 
(define natural? (and/c integer? positive?))
 
(define/contract (f x)
  (-> integer? integer?)
  (- x))
 
(define/contract (g)
  (-> natural?)
  1)
 
(define (test)
  (f (g)))

Добро пожаловать в DrRacket, версия 5.1 [3m].
Язык: racket; memory limit: 4096 MB.
> (test)
-1
>

korvin

Я так понял, здесь определяется:
предикат natural?, проверяющий, что переданное ему для проверки является целым положительным числом
потом определяется функция f(x), и проверяющая что переданный ей параметр является целым, и что возвращаемое ей значение тоже целое
определяется функция g проверяющая, что возвращаемое ей значение является натуральным числом.
и определяется тестовая функция test, которая вызывает функцию f с параметром выданным функцией g.

И что мы имеем.
Функция g возвращает число один, проверив, что оно является натуральным
Функция f проверяет что переданное ей число целое и возвращает его с обратным знаком, проверив, что возвращаемое значение не поменяло тип.

А теперь объясни пожалуйста, где тут тип натурального числа, если ты все время работаешь с встроенными в язык целыми?
Просто твой пример на уровне процедурного языка года так 70-80, только, благодаря мета-возможностям языка, с встроенной проверкой контракта. В том же C++ три проверки из твоих четырех будут обеспечены статической системой типов, а оставшаяся будет выполнена еще при компиляции. Впрочем при включенной оптимизации и результат будет вычислен еще при компиляции.

Цитата amk @ 28.07.11, 19:21

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

контракт и есть тип

Цитата amk @ 28.07.11, 19:21

В том же C++ три проверки из твоих четырех будут обеспечены статической системой типов, а оставшаяся будет выполнена еще при компиляции. Впрочем при включенной оптимизации и результат будет вычислен еще при компиляции.

ок, чуть изменим:

(define natural? (and/c integer? positive?))
 
(define/contract (f x)
  (-> integer? integer?)
  (- x))
 
(define/contract (g)
  (-> natural?)
  (read))
 
(define (test)
  (f (g)))

Добро пожаловать в DrRacket, версия 5.1 [3m].
Язык: racket.
> (test)
1
-1
> (test)
-1
. self-contract violation: expected <(and/c integer? positive?)>, given: -1
  contract on g from (function g), blaming (function g)
  contract:
    (-> (and/c integer? positive?))
  at: unsaved-editor620:9.18
>

покажи мне аналог на С++, выполняющий _все_ проверки до рантайма

Цитата korvin @ 29.07.11, 06:05

ок, чуть изменим:

(define natural? (and/c integer? positive?))
 
(define/contract (f x)
  (-> integer? integer?)
  (- x))
 
(define/contract (g)
  (-> natural?)
  (read))
 
(define (test)
  (f (g)))

Что есть "->"?

Цитата

покажи мне аналог на С++, выполняющий _все_ проверки до рантайма

Каким образом ты собираешься до рантайма проверить значения, получаемые в рантайме?

Добавлено 01.08.11, 21:19

Цитата Guderian @ 28.07.11, 06:25

В языке со статической типизацией я не могу получить доступ к методу foo, специфицированному в natural через контракт number. А в языке с динамической - запросто.

Ты уверен, что ты получаешь доступ к методу foo, именно через контракт number? Ведь в этом контракте о foo ничего не сказано
Получаешь ли ты печеньки на работе согласно своему "контракту" с работодателем?

Сообщение отредактировано: D_KEY - 01.08.11, 22:23

Цитата D_KEY @ 01.08.11, 21:15

Что есть "->"?

контракт-функция. емнип amk все правильно понял

Цитата korvin @ 02.08.11, 03:57

Цитата D_KEY @ 01.08.11, 21:15

Что есть "->"?

контракт-функция. емнип amk все правильно понял

В таком случае твой пример реализуется в С++ через вызов функций проверки, который, например, кидают исключение. Для примитивных типов можно сделать на шаблонах проверку в статике. Но это будут, естественно, константы, которые тебе по какой-то причине не нравятся(что выглядит странно на фоне требования работать исключительно во время компиляции).

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

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

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

Проверка атрибутов/методов, в связи со статичностью типов, в "статических" языках не требуется. При использовании типов в шаблонах проверяется при компиляции. В случае если приспичит динамически добавлять/удалять атрибуты элементарно моделируется посредством отображений (map), как это делается и в языках с динамической типизацией и в общем-то с той же эффективностью. Единственно, не будет синтаксического сахара, вместо
var.someattribute
придется писать
var.attr("someattribute")
var["someattribute"]
или что-то подобное
Думается, можно даже исхитриться и получить указатель на такой атрибут/метод класса, который будет вести себя подобно настоящему атрибуту/методу,

Цитата amk @ 02.08.11, 17:15

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

это потому что питон -- убогий недоязычек =)

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

Цитата korvin @ 02.08.11, 17:43

питон -- убогий недоязычек

Ну твои примеры (кстати, что за язык) тоже показывают не бог весть какой крутой язык. Что-то вроде LISP'а, которым никто кроме тебя похоже и не пользуется.

Цитата amk @ 02.08.11, 18:52

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

ничего интересного, довольно избито и примитивно

Что мне в питоне понравилось, так это его итераторы и генераторы. А что не понравилось - авторы слишком долго шли к идее стабильного API. И хотя они вроде решили наконец его закрепить, подозреваю еще пара версий выйдет, пока они смогут это толком реализовать, а до тех пор серьезную библиотеку для него не напишешь, а значит и программы будут подтормаживать.

Цитата amk @ 02.08.11, 18:52

Ну твои примеры (кстати, что за язык) тоже показывают не бог весть какой крутой язык.

(Racket, "подмножество" Scheme) мы ведь и не о бог весть каких крутых вещах разговариваем.

Добавлено 02.08.11, 18:59

Цитата amk @ 02.08.11, 18:52

Что-то вроде LISP'а, которым никто кроме тебя похоже и не пользуется.

Franz.com, ITA Software, Lispworks.com, правда это CL, про Scheme была статья в журнале FP. Контора, в которой работает тов. mv с LOR'а, активно юзает CL, тов. Archimag (Lisper.ru) юзает CL в своей работе. вообще на LOR периодически всплывают темы поиска примеров практического использования CL

Добавлено 02.08.11, 19:00

Цитата amk @ 02.08.11, 18:55

Что мне в питоне понравилось, так это его итераторы и генераторы.

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

Добавлено 02.08.11, 19:01

Цитата amk @ 02.08.11, 18:55

а значит и программы будут подтормаживать.

требующие производительности модули пишут для питона на Си так-то...

Сообщение отредактировано: korvin - 02.08.11, 19:01

Цитата korvin @ 02.08.11, 18:56

Franz.com, ITA Software, Lispworks.com, правда это CL, про Scheme была статья в журнале FP. Контора, в которой работает тов. mv с LOR'а, активно юзает CL, тов. Archimag (Lisper.ru) юзает CL в своей работе. вообще на LOR периодически всплывают темы поиска примеров практического использования CL

Просто глаза разбегаются от обилия вакансий

Добавлено 02.08.11, 19:52

Скрытый текст

Кстати, господа, а встречал ли кто-то из вас книжку по Scala на великом и могучем? Про басурманские говорить не надо, я про них знаю

Цитата MyNameIsIgor @ 02.08.11, 19:47

Просто глаза разбегаются от обилия вакансий

тебя туда никто не возьмет, не парься =)

Цитата korvin @ 02.08.11, 20:07

тебя туда никто не возьмет

Ещё бы! Нельзя взять того, кто не пойдёт.

Цитата korvin @ 02.08.11, 20:07

не парься

А если я люблю баню?

Цитата MyNameIsIgor @ 02.08.11, 20:17

А если я люблю баню?

так баня и парилка -- не одно и то же вроде, не?

Цитата amk @ 28.07.11, 13:59

Дело в том, что слово 'детерминированный' к объектам в программировании почти не применяется.

Что подразумевается под объектами? Инстансы? Так это экземпляры конкретных классов с конкретным же способом инициализации. С какой стороны термин применить? А вот к типам, переменным - почему нет. В том же драфте индекс четко содержит variable indeterminate и активно оперирует термином (не)детерминированности как к процессу вычисления типов, так и к процессу инициализации переменных.

Цитата amk @ 28.07.11, 13:59

Даже случайные числа в программировании детерминированные (потому и псевдослучайные).

А текущая дата - у вас псевдотекущая и пользовательский ввод - псевдопользовательский?

Цитата amk @ 28.07.11, 13:59

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

Если этот паттерн переложить на то, о чем я говорил, то number является integer'истым, number является natural'истым и т.п. Является полиморфный тип тем, чем он является? Или мы не можем определить наверняка, что он в данный момент представляет и смотрим сквозь замочную скважину контракта? А если я использую в качестве предиката недетерминированную функцию? Полиморфный тип все равно всех детерминирует не смотря ни на что?

Цитата amk @ 28.07.11, 13:59

Именно этот вариант, похоже, ты и реализовал (что это за язык, кстати).

Это Io, как я и писал.

Цитата amk @ 28.07.11, 13:59

И такой полиморфизм динамически реализуем и в языках со статической типизацией (с одной поправкой - в языке со СТ нельзя в динамике проверить существование метода или атрибута, но можно проверить тип объекта).

Можешь показать на примере первой же строчки, которая модифицирует штатный тип Number и модифицировать похожим образом int?

Цитата amk @ 28.07.11, 13:59

По-моему интереснее был бы пример с фабрикой, на основе свойств создающей объект нужного типа. Этот вариант тоже работает при любом виде типизации. Причем, в случае статической типизации без дополнительных накладных расходов при работе с объектом.

Фабрика - это один из самых скучных паттернов, как она может быть интересней динамического изменения (не вычисления) типа переменной в момент ее инициализации.

Цитата amk @ 28.07.11, 13:59

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

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

Цитата D_KEY @ 01.08.11, 21:15

Ты уверен, что ты получаешь доступ к методу foo, именно через контракт number? Ведь в этом контракте о foo ничего не сказано

Я как раз уверен, что не получу

Цитата D_KEY @ 01.08.11, 21:15

Получаешь ли ты печеньки на работе согласно своему "контракту" с работодателем?

С точностью до наоборот. Я хочу печеньки, а мне дают контракт с работодателем, который решил полиморфно эти печеньки у меня спереть и выдавать в конвертах, которые мне надо раскрывать, то бишь кастить, чтобы наконец насладиться кондитерским изделием.

Цитата amk @ 02.08.11, 17:15

В случае если приспичит динамически добавлять/удалять атрибуты элементарно моделируется посредством отображений (map), как это делается и в языках с динамической типизацией и в общем-то с той же эффективностью.

Динамика - это тебе не ассоциативные массивы прикрутить Как методы вместе с их телами будешь конструировать? Как новые типы создавать? А способом неизвестным на этапе компиляции?

Цитата amk @ 02.08.11, 18:52

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

Тогда тебе прямая дорога в Smalltalk, Self, вышеупомянутый Io. Вот там воистину все объекты.

Цитата Guderian @ 03.08.11, 13:26

Цитата D_KEY @ 01.08.11, 21:15

Ты уверен, что ты получаешь доступ к методу foo, именно через контракт number? Ведь в этом контракте о foo ничего не сказано

Я как раз уверен, что не получу

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

Цитата

Цитата amk @ 02.08.11, 18:52

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

Тогда тебе прямая дорога в Smalltalk, Self, вышеупомянутый Io. Вот там воистину все объекты.

А с Ruby что не так? Мне smalltalk понравился(правда опыта мало), но вот синтаксис просто ужасный.

Цитата D_KEY @ 03.08.11, 13:36

Так в том и дело, что в случае динамики у тебя вообще нет этого контракта.

А кто сказал, что он мне нужен? Разные парадигмы - разные подходы. ООП:
1. Копать умеешь?
2. Тогда переоденься в спецодежду.
3. Копай.
Динамика:
1. Копай.
2. Не умеешь - не копай.
Как-то так

Цитата D_KEY @ 03.08.11, 13:36

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

На мой взгляд, их не надо сводить вместе. Да и не получится. Статика опять же захочет иметь "пред- и пост- условия" загодя, а динамика "да ну их, потом разберемся"

Цитата D_KEY @ 03.08.11, 13:36

А с Ruby что не так?

Попробуй определи на нем новый метод в классе, потом его переопредели, а потом удали. У меня не получилось. В расово чистых языках, где все есть объект, это естественные операции, ибо класс - есть тоже объект. В Руби же, даже возможность добавления нового метода объясняется тем, что якобы определение класса просто не закрыто.

Цитата D_KEY @ 03.08.11, 13:36

Мне smalltalk понравился(правда опыта мало), но вот синтаксис просто ужасный.

Попробуй Io/Ioke. Из Smalltalk'а он взял, пожалуй, больше всех, но при этом подмешано функциональное, которое в большей степени "подсластило" синтаксис и он уже не такой зубодробительный.

Цитата Guderian @ 04.08.11, 04:09

Цитата D_KEY @ 03.08.11, 13:36

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

На мой взгляд, их не надо сводить вместе. Да и не получится. Статика опять же захочет иметь "пред- и пост- условия" загодя, а динамика "да ну их, потом разберемся"

Думаю, что это возможно разрулить.

Цитата

Цитата D_KEY @ 03.08.11, 13:36

Мне smalltalk понравился(правда опыта мало), но вот синтаксис просто ужасный.

Попробуй Io/Ioke. Из Smalltalk'а он взял, пожалуй, больше всех, но при этом подмешано функциональное, которое в большей степени "подсластило" синтаксис и он уже не такой зубодробительный.

Спасибо за совет
Вроде не пробовал.

Ну как, кто-нибудь попробовал kotlin в реальной жизни и может поделиться впечатлениями?

Цитата D_KEY @ 14.07.12, 21:01

Ну как, кто-нибудь попробовал kotlin в реальной жизни и может поделиться впечатлениями?

А уже вышла реализация? Я бы попробовал, хотя пока не в "продакшене", а то мало ли чего там недопричесали =)

А между тем, он действительно вышел, хотя и пока не «production-ready» версия.

http://www.youtube.com/watch?v=BhCDeCKdsGU...be_gdata_player

а котлин for javascript там работает??

Цитата jack128 @ 27.07.12, 09:59

а котлин for javascript там работает??

Вот не пробовал, т.к. было уже поздно, да и JS мне не интересен. =)
Может сегодня позже гляну.

Вообще у них есть Web demo, где можно попробовать компиляцию в JS.

Сообщение отредактировано: korvin - 27.07.12, 10:14

Цитата korvin @ 27.07.12, 10:08

JS мне не интересен

эх-хе-хех... Если бы мне был бы интересен js, я б kotlin for js и не не смотрел :-(

Цитата jack128 @ 27.07.12, 10:34

Цитата korvin @ 27.07.12, 10:08

JS мне не интересен

эх-хе-хех... Если бы мне был бы интересен js, я б kotlin for js и не не смотрел :-(

А, ну я имею в виду, что он мне не интересен как целевая платформа в данном контексте.
Хотя теперь можно писать веб-сервер и серверное ПО под Node.JS на Kotlin.

Цитата jack128 @ 21.07.11, 10:44

Как считаете, взлетит/не взлетит??

Таки взлетел

Ещё и Ceylon похоронил