Существует ли язык мечты, который объединяет преимущества динамического контроля типов и строгого контроля типов?

Maybe the new dynamic type in C# 4.0. look at this: http://blogs.msdn.com/cburrows/archive/2008/10/27/c-dynamic.aspx

It rather depends on what you intended by having the Lion type implement a non-virtual method.

Extension typing ( the set of objects which are of a given type are those which have the properties of the type, which is close to being a static equivalent of duck-typing ) requires that the structure of an object implies its type, but your Lion type has no structure - it only says that anything which is a lion has that particular Roar method. So for your example, I can't see any way you can cast your cat to be a Lion, since it doesn't have the only structural property you have said that Lions have.

If on the other hand you intended by saying that anything you say is a Lion may have either its own Roar method or will use the method in Lion, it's not saying anything about the type of objects which are Lions, and AFAIK you could get the same behaviour with an extension method on object ( though I don't know enough C# to know whether self methods override extension methods in C# ).

In a dynamic IDE, there's no reason that you need to cast to a Lion before the IDE can work out that myCat has a Roar property - that information is statically deducible.

The reason IDE support is hard in languages with dynamically constructed types, such as JavaScript, is that you can do this:

let myCat = {}

if ( locale.name == 'en' )
    myCat.roar = function () { alert ( "Miauew" ); }
else
    mCat[ resources.getString( 'roar' ) ] = 
        function () { alert ( resources.getString ( 'Miauew' ) ); }


// the structure of the type of myCat depends what locale the code
// is running in, so you can't deduce the Intellisense
myCat.

Such situations of course mean that you can't predict whether the code will work either, without much deeper analysis ( for example, checking that your French cat is always asked to roar in French ).

If Intellisense can't deduce the structure of objects whose structure is statically deducible, then that's a weakness in Intellisense, not of dynamic typing.

What would you consider the benefit of strong typing in your example?

Каждый раз, когда я пытался что-то спланировать, проблема заключалась в гипсе. Конечно, вы можете просто поверить на слово программисту, но это объединяет худшие особенности обеих систем набора текста. Возможно, приведение может проверить во время выполнения, реализует ли объект интерфейс Lion, но это в принципе невозможно. В данном случае это выглядит правдоподобным, поскольку все, что вам нужно, - это наличие функции void (*) () . Но в общем, что, если у Lion есть метод getHabitat , который возвращает объект, который должен быть другого интерфейса? Строго типизированный язык должен иметь возможность точно сказать, что это действительно так, но без фактического вызова метода вы, как правило, не можете сказать, возвращает ли нетипизированный код Habitat, и, следовательно, в терминах строгой типизации вы можете ' Я не могу решить, является ли это Лев.

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

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

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

Статические типы в динамических языках

Проблема возникает, когда вы смотрите на то, как объекты используются в языках сценариев - все они типизированы уткой. Это означает, что имя типа ( номинальная типизация ) бесполезно. Все современные императивные языки (Java, C #, C ++, C) используют системы именных типов. Итак, в C ++ вы можете сказать, что ожидаете Duck , но в Python вам действительно нужно что-то похожее на quack () .

Так что подумайте о добавлении статической типизации в язык с утиным типом . Поскольку функция будет передавать параметр в quack () , но не может сказать, что ожидает Duck , объединение этих двух параметров затруднительно. Вы можете определить интерфейс с именем quacks , который может quack () , и использовать его в качестве типа. Но на самом деле это немного многословно, что убивает преимущества динамической типизации. Хотя, возможно, что-то в этом роде (какая-то система структурных типов ) может это сделать.

Альтернативой было бы просто потребовать от программиста указать Duck , и в любом случае, черт возьми, этот бизнес по утиному набору текста - никто не использует его, не так ли? Но тогда вы просто пишете Java на Python, и как человек, который однажды пробовал это, позвольте мне сказать вам, что это очень контрпродуктивно.

Динамические типы в статических языках

Так что давайте посмотрим на это с другой стороны. Какие преимущества получит C # от ключевого слова dynamic ? Простой ответ - не будет. Честно говоря, я не вижу красоты и свободы, которые вы получаете от Python в динамическом C #. Единственное, что я знаю об этом, - это выступление Джона Скита, но у меня сложилось огромное впечатление, что это многословно и неизящно. И я думаю, что это не ошибка реализации со стороны C # людей. Я думаю, это потому, что проблемы, которые решает динамическая типизация в Python, уже решены в C # (хотя и подробно), а динамический просто ничего не дает.

Исследования по статическим / динамическим вещам

Посмотрите наверх Постепенная типизация Джереми Сика - это самое продвинутое статическое / динамическое исследование. Хотя это немного сложно читать, и я сам только бегло посмотрел, поэтому не могу резюмировать. Тем не менее, интересно пролистать его работы в одиночку, и конференция STOP , вероятно, будет полезной.

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

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