objective-c

[Alex_3112]

Нет, есть сервисы наподобие exceptional.io.

Я с такими не работал. Насколько я понимаю, эти сервисы облегчают работу с большим количеством ошибок для работы в команде. Но насколько они помогают в работе с одной конкретной ошибкой?

Еще раз повторю свою мысль: это зависит не от того статический язык или динамический, а от того как написан код.

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

Был проект где с полдюжины, разные Линуксы, HPUX, AIX, Solaris, Windows, Mac OS X. Сборка дистрибутива 2 часа.

В таком случае парк разных машин нужен в любом случае, верно? И компилировать в разные среды нужно для QA/Release, но не для программиста, так?

[crazy-mike]

kstati. kak jazyk piton kruche vsex! da! da! da!
piton ochen' krutoy!

Ага - язык , который сам по себе является глюком.

[crazy-mike]

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

В "статическом коде" ещё легче "накосячить" ( operating environment , в котором работает такой "код" , ведь очень даже "динамическая" хреновина ). А в динамическом намного проще всё исправлять.
И "программы" там совсем не на честном слове работают. Именно компиляторы ( особенно оптимизирующие" ) делают такой "статический код" , который и в самом деле часто работает на честном слове. "Динамический код" практически никогда не столкнётся с проблемой "переполнения таблицы виртуальных методов" или ещё чего-то такого.

[Alex_3112]

В "статическом коде" ещё легче "накосячить" ( operating environment , в котором работает такой "код" , ведь очень даже "динамическая" хреновина ).

Для динамического кода этот environment не становится ведь менее динамичным?

А в динамическом намного проще всё исправлять.

Возможно это субъективно, но я трачу на локализацию ошибки в статическом коде в 10-20 раз меньше времени, чем в динамическом.

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

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

[crazy-mike]

Для динамического кода этот environment не становится ведь менее динамичным?

Возможно это субъективно, но я трачу на локализацию ошибки в статическом коде в 10-20 раз меньше времени, чем в динамическом.

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

В динамическом просто каждый "фрагмент кода" можно запускать(отлаживать) по отдельности. И не нужно заморачиваться так сильно с "отладочной версией проекта".
Динамический код как раз от прихотей исполняемой среды зависит намного меньше. Просто "исполняемую среду" нужно "отконфигурировать". У компилируемых всё намного хуже. Там кроме "настройки исполняемой среды" ещё и "глюки самого генератора кода" ( особенно для объектно-ориентированных и у оптимизирующих компиляторов. ).

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

[реднек]

Я с такими не работал. Насколько я понимаю, эти сервисы облегчают работу с большим количеством ошибок для работы в команде. Но насколько они помогают в работе с одной конкретной ошибкой?

Как минимум говорят как часто эта конкретная ошибка происходит.

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

Ты слышал о duck-typing? Он неплохо справляется с задачей. Если тебе надо записать объект в базу, то тебе нужно пара методов: save и validate. И не надо все остальное (ну например). В статическом языке, чтобы добится этого тебе нужно иметь четко выделеный интерфейс с этими методами, как отдельную сущность, например Storable. А в куске кода, который читает объект из строки и записывает его в базу, нужен еще метод: load_from_string. Со Storable этот кусок уже работать не может и ему либо надо кросскастать, либо работать с более конкретными классами. Это я все к тому, что типизация на словах хорошо, а на практике приводит к порождению дробных типов, которые не нужны. Другой подход, который часто можно встретить - это запихать все в базовый Object. Вот там и лежат 100 методов мертвым грузом, без всякой реализации, зато избавляют от кросскастинга, и при этом дают "ощущение" проверки типов параметров.

В таком случае парк разных машин нужен в любом случае, верно? И компилировать в разные среды нужно для QA/Release, но не для программиста, так?

Так у меня программа на Руби или Питоне будет работать на Mac OS (в среде разработки) так и на Linux (продакшн).
На Java тоже, наверное, не знаю не пользую. На плюсах, надо перекомпилять под каждую платформу, часто еще под разную архитектуру процессоров.

[Alex_3112]

В динамическом просто каждый "фрагмент кода" можно запускать(отлаживать) по отдельности. И не нужно заморачиваться так сильно с "отладочной версией проекта".

А как же ситуации, когда фрагмент кода отлично работает по отдельности, но в реальных ситуациях выдает ошибки? Мы не можем "в пробирке" предусмотреть все возможные случаи.

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

При условии, что нам всегда гарантируется стандартная исполняемая среда.

У компилируемых всё намного хуже. Там кроме "настройки исполняемой среды" ещё и "глюки самого генератора кода" ( особенно для объектно-ориентированных и у оптимизирующих компиляторов. ).

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

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

[crazy-mike]

Другой подход, который часто можно встретить - это запихать все в базовый Object. Вот там и лежат 100 методов мертвым грузом, без всякой реализации, зато избавляют от кросскастинга, и при этом дают "ощущение" проверки типов параметров.

Мы об этом ведь уже говорили.
Но там ещё одна очень смешная вещь есть - "очень правильная объектно-ориентированная программа" со всей своей очень строгой типизацией довольно часто компилируется в просто неработающий код. ( там все эти наследования и конструкторы перепутаются так - что исполняемый код сведётся к единственной команде ret в лучшем случае ).
От таких вещей никакая строгая типизация не защищает вообще.

[crazy-mike]

А как же ситуации, когда фрагмент кода отлично работает по отдельности, но в реальных ситуациях выдает ошибки? Мы не можем "в пробирке" предусмотреть все возможные случаи.

При условии, что нам всегда гарантируется стандартная исполняемая среда.

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

По-моему опыту - у клиента практически не бывает "кривого браузера". Клиент только кеш забывает очищать. А в самом языке Java именно глюки наблюдались при переходе от одной версии к другой ( swing и awt чуть по-разному работали после перехода с 1.3 на следующую. А после появления Java FX с этой всей Java-чертовщиной лучше вообще не связываться. ). А вот у javascript всё сохранялось при обновлениях и просто чуть быстрее работать начинало.

[Sixteen]

джава ваще пазорный интерпретатор п-кода. который для красоты обозвали байт-кодом.