Динамическая типизация - логическое продолжение ООП!

Выкладывай пароль, ты уже поехавший, все, понимаешь?

Нет я поехавший, да я не понимаю.

Таки да. Замена кода на ходу и легче писать тесты.

Говорит человек, мало смыслящий в теме.

Но как он умеет вбрасвать!

ТС, научи!

Внимательно следи за моей авой. Смотри на нее, думай о ней, мысли, сын мой. За гранью критической концентрации саморазрушения и аморализма и находится Высший Разум.

Тонны - это сколько? 400.000 строк каждый день дебажу.

УМВР.

400.000 строк каждый день дебажу

В том-то и дело, что приходится каждый день и по тонне кода...

Нет ни какого knotri. Тебя нет. Меня нет. Есть пустота. Всеобъемлющая.

Делать нефиг

Ибо идеальный полиморфизм! Все скриптовые языки прекрасны, особенно ПИТОН!

а что в нём идеального, и чем он не идеален, например, в жабе?

Вот бы хоть одним глазком увидеть это:

www.linux.org.ru/forum/development/10397435

Только он остается в программе до момента выполнения, или даже до момента выполнения с определенными параметрами.

Тут же подправил и всё ОК, не надо полностью перекомпилировать, перезапускать, повторно вводить параметры.

Ага, со 100% покрытием. И даже они - не гарантия.

Как будто статическая типизация дает 100% гарантии.

Вот проверка сайд-эффектов - это да, здорово. Но опять же в итоге упирается в статическую типизацию :(

Только он остается в программе до момента выполнения, или даже до момента выполнения с определенными параметрами.

Тут же подправил и всё ОК, не надо полностью перекомпилировать, перезапускать, повторно вводить параметры.

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

Как будто статическая типизация дает 100% гарантии.

Против несовпадения типов - дает. Правда, от изобретательных идиотов она не зашитит.

по поводу динамической типизации какой то лютый батхерт на LOR, почему так?

все реально считают что все значимые ошибки в программе связаны с типами данных?

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

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

ну и тестировать больше надо, да

но все это не слишком значительно, что бы пердак разрывало так сильно местным, код то на динамике пишется в целом быстрее, ошибок больше потом, зато работает %)

все реально считают что все значимые ошибки в программе связаны с типами данных?

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

ну и тестировать больше надо, да

Отличный совет, независимый от дисциплины типизации.

http://img0.joyreactor.cc/pics/post/java-песочница-921057.jpeg

Смотри, что говорит самый левый петухан на заборе

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

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

вполне сносный подход, как показывает современная экономика в развитых странах

О, Господи, упокойте его уже кто-нибудь.

Динамическая типизация появилась задолго до OOP.

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

Мощно, внушаить.

Кря-кря.

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

Ящитаю что если ООП, то инкапсуляция должна быть.

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

динамическая скриптодрисня прекрасна

толсто

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

И из чего ты сделал вывод, что я так считаю? И в С++, и в Java можно так поразвлечься, хотя, как по мне, там инкапсуляция на высоком уровне. Поразвлечься, но не более. Ибо костылями такими писать что-то серьезное невозможно. А в питоне это реализуется на примитивном уровне, заменой имени...
Я не спорю что инкапсуляция нужна для других разработчиков, в этом и идея ООП: предоставлять интерфейс для оперирования сокрытыми данными. Но если я делаю метод private, то логично, что я не хочу, что бы его вызывали из вне? Питон такой возможности не предоставляет.

как по мне, там инкапсуляция на высоком уровне

Инкапсуляция - она в головах

Уж действительно

Ты проект доделал? Исходники выложил? Или тебя уволили?

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

PHP?

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

Erlang?

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

Где адепты, там религия. Внезапно.

Чего там смотреть-то?.. но если очень хочется: http://jsbin.com/fivekuye/1

Но если я делаю метод private, то логично, что я не хочу, что бы его вызывали из вне?

Питонщики и не вызывают извне (разве что, если очень припрёт), у них en masse высокая самодисциплина, в отличие от, для которых приходится повсюду ставить перегородки, чтобы не залезали, куда ни попадя.

Слабая типизация - от где полиморфизм то.

Да я ж говорю, мой начальничек в отпуске. Как придет - я с ней поговорю.

К сожалению не знаком, прошу уточнить два пункта: private члены там действительно private или __каквпистоне();

Есть возможность сделать действительно private.

Отсутсвует ли возможность изменения/добавление полей вне класса?

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

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

C#, же. Ключевое слово dynamic.

От рефлексии, конечно, не защитишься, но это уже средство рантайма, а не языка.

C#, же. Ключевое слово dynamic

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

Сам язык то все равно статически типизируемый, так что не подходит.

Ибо идеальный полиморфизм! Все скриптовые языки прекрасны, особенно ПИТОН!

где тег «я познаю мир»? Питоны и пхп как раз и придуманы для таких неосиляторов ООП, как ты.

который говорит что проверять это значение на тип в компиляции не нужно

..., а нужно определить тип в рантайме. Это не есть динамическая типизация?

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

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

А для чего еще может потребоваться динамическая типизация?

Сам язык то все равно статически типизируемый, так что не подходит.

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

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

Например JavaScript.

в неполноценном ЯП может быть что-то полноценное?

Все скриптовые языки прекрасны...

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

Не знаю, думаю может. А причём тут JavaScript?

А причём тут JavaScript?

а он стал полноценным?

А причём тут JavaScript?

а он стал полноценным?

он им был с появления.