Java vs Kotlin

Да тебя в общем-то никто не собирался топтать, я по крайней мере. Дело в том, что слово 'детерминированный' к объектам в программировании почти не применяется. Недетерминированность языковых конструкций (А именно она скрывается за словосочетанием "неопределенное поведение", хотя в оригинале и пишется "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

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

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