Можно ли полностью отказаться от динамически типизированых я - Философия программирования

Днем и ночью меня мучает данный вопрос.
Отказаться — это с минимальными потерями заменить все полезные фичи динамики на статику.
Так как на динамике я ничего серьезного не писал, то о полезности того или иного имею достаточно смутное представление.
1) Не нужно явно указывать тип
x = 1
Вроде вывод типов в большенство своем должен решить эту проблему
x = 1
Там где все же придется явто указывать, скорее всего не большая потеря.
2) Утиная типизация
def foo(x)
x.bar + 1
Структурные типы вроде должны эту проблему решать

x::{bar::Num}
3) Работа с динамическими данными
p = getPersonJson(1)
print p.Name
Самое правильное это конечно было бы иметь какое то описание для источника по которому можно было бы сгенерировать обертку, eсли описания нет, тогда выглядет не проблемой использовать те же структурные типы
p::{Name::String}
4) Ну и например изменение классов в рантайме
class Person
property Name
p = Person()
p.Age = 20
Опять же включая воображение, можно что нибудь придумать, например при компиляции p::Persoin,{Age:Int}, или вообще так не делать.

Так как языка с такими фичами скорее всего не сущетсвут, то нельзя с увереность сказать что это все может взлететь.
Соответственно два вопроса.
Что я упустил? Можно ли всетаки отказаться от дт?
Хотелось бы еще услышать стороников дт, какие фичи в дт считаются особенно полезны.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

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

D>Можно ли полностью отказаться от динамически типизированых
в 4й шарп всадили динамическую типизацию (dynamic)/ Видать, без нее — никак

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

...

Сделали бы лучше динамическую генерацию кода. А динамическую типизацию — на помойку.

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

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

D>>Можно ли полностью отказаться от динамически типизированых
W>в 4й шарп всадили динамическую типизацию (dynamic)/ Видать, без нее — никак

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

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

D>1) Не нужно явно указывать тип
Для статики это вредно — лучше явно указать компилятору, что ты от него хочешь, чем отлавливать слишком умный компилятор в рантайме.

D>2) Утиная типизация
Зачем? Шобыбыло?

D>3) Работа с динамическими данными
Для интеропа с DLR есть dynamic.

D>4) Ну и например изменение классов в рантайме
Зачем? Шобыбыло? Тогда — ExpandoObject

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

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

W>в 4й шарп всадили динамическую типизацию (dynamic)/ Видать, без нее — никак

Без неё — как. Dynamic упрощает писанину там, где статикой не обойтись

In most cases, it functions like it has type object. At compile time, an element that is typed as dynamic is assumed to support any operation. Therefore, you do not have to be concerned about whether the object gets its value from a COM API, from a dynamic language such as IronPython, from the HTML Document Object Model (DOM), from reflection, or from somewhere else in the program. However, if the code is not valid, errors are caught at run time.

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

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

W>>в 4й шарп всадили динамическую типизацию (dynamic)/ Видать, без нее — никак

S>Без неё — как. Dynamic упрощает писанину там, где статикой не обойтись
Боян (для меня)

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

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

D>>1) Не нужно явно указывать тип
S>Для статики это вредно — лучше явно указать компилятору, что ты от него хочешь, чем отлавливать слишком умный компилятор в рантайме.
Что значит вредно? var вреден? Про рантайм тоже не понятно.

D>>2) Утиная типизация
S>Зачем? Шобыбыло?
Например у вас есть два класс A B с набором полей Foo Bar, и вы с ним хотите что то сделать
DoSomething(list)
return list.Select(x => x.Foo + x.Bar);
Что будете делать?

D>>3) Работа с динамическими данными
S>Для интеропа с DLR есть dynamic.
Вот от него и хочется отказаться.

D>>4) Ну и например изменение классов в рантайме
S>Зачем? Шобыбыло? Тогда — [url=http://msdn.microsoft.com/en-us/magazine/ff796227.aspx
S>]ExpandoObject[/url]
Суть поста как разв в попытке понять, можно ли от этого всего отказаться. Но эта фича, да, чисто для галочки.

S>Явное исключение — всякие DOM для документов с заранее неизвестной схемой.
Пожете привести пример, зачем там вообще нужна какая либо типизация?

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

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

S>>Для статики это вредно — лучше явно указать компилятору, что ты от него хочешь, чем отлавливать слишком умный компилятор в рантайме.
D>Что значит вредно? var вреден? Про рантайм тоже не понятно.
Чуть-чуть обсуждалось тут.
Сам по себе не вреден, но для долгоживущего кода лучше var не использовать.

D>>>2) Утиная типизация
S>>Зачем? Шобыбыло?
D>Например у вас есть два класс A B с набором полей Foo Bar, и вы с ним хотите что то сделать

DoSomething(list)
{
  return list.Select(x => x.Foo + x.Bar); 
}

D>Что будете делать?

Убъю архитектора. Чтобы не разводил багодром на ровном месте. Если подобное будет действительно оправдано — буду использовать интерфейсы/обёртки, реализующие интерфейсы.

D>>>3) Работа с динамическими данными
S>>Для интеропа с DLR есть dynamic.
D>Вот от него и хочется отказаться.
Зачем?

D>>>4) Ну и например изменение классов в рантайме
S>>Зачем? Шобыбыло? Тогда — [url=http://msdn.microsoft.com/en-us/magazine/ff796227.aspx
S>>]ExpandoObject[/url]
D>Суть поста как разв в попытке понять, можно ли от этого всего отказаться. Но эта фича, да, чисто для галочки.
Можно. Если формализовать задачу вместо сиюминутного решения.

S>>Явное исключение — всякие DOM для документов с заранее неизвестной схемой.
D>Пожете привести пример, зачем там вообще нужна какая либо типизация?
Чтобы проверять схему(если она известна на этапе компиляции). Не знаю как вам, но мне бы сэкономило немало нервных клеток

Кстати, полная цытата меня:

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

Вам не кажется, что я говорил как раз об обратном — что dynamic хорош для работы с DOM?

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

D>>Что значит вредно? var вреден? Про рантайм тоже не понятно.
S>Чуть-чуть обсуждалось тут.
S>Сам по себе не вреден, но для долгоживущего кода лучше var не использовать.

Как человек который пишет на немерле где вывод типов нааамного круче чем var могу сказать что данное утверждение не верно.
Те вывод типов не создает проблем совсем.
За то очень сильно сокращает код и убирает массу визуального шума.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

S>Убъю архитектора. Чтобы не разводил багодром на ровном месте. Если подобное будет действительно оправдано — буду использовать интерфейсы/обёртки, реализующие интерфейсы.
Вот что бы на каждый чих не создавать интерфейсы, и существую ут.

S>Зачем?

Вы не знаете какие плюсы у статика по сравнению с динамиком?

D>>>>4) Ну и например изменение классов в рантайме
S>>>Зачем? Шобыбыло? Тогда — [url=http://msdn.microsoft.com/en-us/magazine/ff796227.aspx
S>>>]ExpandoObject[/url]
D>>Суть поста как разв в попытке понять, можно ли от этого всего отказаться. Но эта фича, да, чисто для галочки.
S>Можно. Если формализовать задачу вместо сиюминутного решения.
Да, но есть задачи для которых сиюминутные решения предпочтительны(прототипирование, быстро сделать что нибудь полезное но не особо важное).

S>Чтобы проверять схему(если она известна на этапе компиляции). Не знаю как вам, но мне бы сэкономило немало нервных клеток

S>Кстати, полная цытата меня:
S>

S>Я пока не видел явной пользы от динамика, перевешивающей все прелести статической типизации. Явное исключение — всякие DOM для документов с заранее неизвестной схемой.

S>Вам не кажется, что я говорил как раз об обратном — что dynamic хорош для работы с DOM?

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

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

D>Что я упустил? Можно ли всетаки отказаться от дт?
D>Хотелось бы еще услышать стороников дт, какие фичи в дт считаются особенно полезны.

Нельзя в результате просто получим работающую иллюстрацию разновидности десятого правила Гринспена:

Любая достаточно сложная программа на Си или Фортране содержит заново написанную, неспецифицированную, глючную и медленную
реализацию половины языка Common Lisp.

С заменой "Common Lisp" на "динамику".

Что та же например явишная любовь к XML уже и демонстрирует.

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

D>Днем и ночью меня мучает данный вопрос.

Не верю. Про ночь, по крайней мере.

Особенно после того, как только что отшумела дискуссия.

D>Что я упустил? Можно ли всетаки отказаться от дт?

Можно. В камне жизни нет, только кто-то слово из трёх иероглифов нацарапал.

On 18.11.2010 11:54, dotneter wrote:

> 1) Не нужно явно указывать тип
> 2) Утиная типизация
> 3) Работа с динамическими данными
> 4) Ну и например изменение классов в рантайме
> Так как языка с такими фичами скорее всего не сущетсвут, то нельзя с увереность
> сказать что это все может взлететь.

Существуют языки с такими фичами. Common Lisp, Python
как минимум.

> Что я упустил?

полиморфные операции, навероне, но они есть и
в языках со статической типизацией.

Можно ли всетаки отказаться от дт?

Так в языке это либо есть, либо нет.

Posted via RSDN NNTP Server 2.1 beta

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

MZ>Существуют языки с такими фичами. Common Lisp, Python
MZ>как минимум.
Имелся в виду ст язык.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

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

D>Так как языка с такими фичами скорее всего не сущетсвут, то нельзя с увереность сказать что это все может взлететь.

Казалось бы...

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

WH>Как человек который пишет на немерле где вывод типов нааамного круче чем var могу сказать что данное утверждение не верно.
WH>Те вывод типов не создает проблем совсем.

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

Так что все хорошо в меру.

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

H>Казалось бы...

В Nemerle разве есть structural typing?
Вот в Scala точно есть (с поддержкой всевозможного variance). Наподобие такого:

val x : { def foo[T](y : T) : String; val y : Integer }
val y : { def foo[T <: C](y : T) : Any; }

y = x
y.foo(new C)

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

N>Вот в Scala точно есть (с поддержкой всевозможного variance). Наподобие такого:

N>

N>val x : { def foo[T](y : T) : String; val y : Integer }
N>val y : { def foo[T <: C](y : T) : Any; }

N>y = x
N>y.foo(new C)
N>

Круто

А для чего это можно использовать?

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

H>Круто

А для чего это можно использовать?

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

	От:	dotneter
	Дата:	18.11.10 08:54
	Оценка:

	От:	Wolverrum
	Дата:	18.11.10 09:01
	Оценка:

	От:	любой
	Дата:	18.11.10 09:09
	Оценка:

	От:	dotneter
	Дата:	18.11.10 09:13
	Оценка:

	От:	Sinix
	Дата:	18.11.10 09:35
	Оценка:

От:	netch80	http://netch80.dreamwidth.org/
Дата:	18.11.10 17:52
Оценка:

От:	hardcase	http://nemerle.org
Дата:	18.11.10 20:41
Оценка:

От:	nikov	http://www.linkedin.com/in/nikov
Дата:	18.11.10 23:00
Оценка: