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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

не парься

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

determined by the type of the expressions

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

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

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

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

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

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

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

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

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

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

"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."

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 ]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

http://ideone.com/nnlJ7