LINUX.ORG.RU
ФорумTalks

Динамическая типизация это прекрасно, но...


0

0

..но блин, надежную большую программу написать совершенно невозможно. Если что-то зарефакторить, так и вовсе наступает полный песец; глюки можно вылавливать месяцами. Писать тесты, покрывающие 100% кода? Тоже невесело, да и тесты не могут быть идеальными...

Чё делать, товарищи? Подумываю уже завязывать со Схемой и прочими питонами, и валить на что-то со статической типизацией...


Завязывай с рефакторить и писать тесты. Общепринятый процесс проектирования таки рулит, да.

bugmaker ★★★★☆
()

> Чё делать, товарищи?

Юзать pylint.

> Подумываю уже завязывать со Схемой

Правильно. И переходить на CL

eugine_kosenko ★★★
()
Ответ на: комментарий от bugmaker

> Подумываю уже завязывать со Схемой

а некоторые таки никогда и не связывались

kto_tama ★★★★★
()

> Писать тесты, покрывающие 100% кода?

да

> Тоже невесело, да и тесты не могут быть идеальными.

ничто не может быть идеальным. Но Test Driven Development в определённых условиях очень рулит.

А где есть поддержка рефакторинга для питона или схемы? Или ручками?

Legioner ★★★★★
()
Ответ на: комментарий от bugmaker

>Завязывай с рефакторить и писать тесты. Общепринятый процесс проектирования таки рулит, да.

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

Что "общепринятый процесс" вовсе не подразумевает автоматических тестов, первый раз слышу.

tche
() автор топика
Ответ на: комментарий от eugine_kosenko

>Юзать pylint.

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

>Правильно. И переходить на CL

А как там проблема решается?

tche
() автор топика
Ответ на: комментарий от tche

> А как там проблема решается?

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

> Сейчас мучаюсь с довольно большим проектом на Схеме.

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

eugine_kosenko ★★★
()
Ответ на: комментарий от Legioner

>> Писать тесты, покрывающие 100% кода? >да

Тесты-то дело хорошее, но: там где в той же Java после очередной правки кода хватало перекомпиляции чтоб отловить все косяки, в Схеме/Питоне надо постоянно прогонять тесты. Тесты не всегда тривиальные и не всегда полностью автоматические. Задолбало.

Может вообще ну нафиг подобные языки, там где кода много и цена ошибок большая...

tche
() автор топика
Ответ на: комментарий от tche

> изменить число, порядок ... параметров функции

Карринг?

stassats ★★★★
()
Ответ на: комментарий от eugine_kosenko

>Там есть возможность статической типизации аргументов

Там, насколько знаю, вывода типов нет, что не очень хорошо. То есть даже очень плохо. Или есть?

Вообще, подумываю об Ocaml, но пока слишком мало с ним знаком.

tche
() автор топика

Всё так и есть :/

> Чё делать, товарищи?

Выходов два: 1) писать ядро на статически типизированном языке: а динамический использовать для скриптования поверх этого ядра; 2) написать нормальную программу статической проверки кода (не галимый pylint).

Хотя 100% тесты всё равно нужно писАть :)

tailgunner ★★★★★
()

Если писать правильно и чётко, то такие проблемы с тобой не случатся.

a = int()

b = str()

c = list()

...

troorl ★★
()
Ответ на: комментарий от troorl

Кроме того, такие проблемы возможны только с простыми типами. Можно делать обёртки для них и будет тебе строгая типизация.

troorl ★★
()
Ответ на: комментарий от troorl

> такие проблемы возможны только с простыми типами. Можно делать обёртки для них и будет тебе строгая типизация.

Вооще-то речь идет о статической типизации vs динамической. А так и Питон, и Схема - языки со строгой типизацией :D

tailgunner ★★★★★
()

Вообще-то статическая типизация ОЧЕНЬ помогает писать тесты...

Miguel ★★★★★
()

> Писать тесты, покрывающие 100% кода?

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

> Тоже невесело, да и тесты не могут быть идеальными...

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

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

Ну вали, только чур на Haskell ;)

CrazyPit ★★★
()
Ответ на: комментарий от tche

> Тесты не всегда тривиальные и не всегда полностью автоматические.

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

CrazyPit ★★★
()
Ответ на: комментарий от tche

>>Правильно. И переходить на CL

>А как там проблема решается?

отностиельно решаемая. можно задать типизацию для своих функций, но для стандартных она же не прописана, поэтому если передаёшь неправильный тип в стандартную функцию то это при компиляции не отловится.

CrazyPit ★★★
()
Ответ на: комментарий от tche

> Тесты-то дело хорошее, но: там где в той же Java после очередной правки кода хватало перекомпиляции чтоб отловить все косяки, в Схеме/Питоне надо постоянно прогонять тесты.

А в Java тесты писать не надо? Тесты проверяют бизнес логику. Но и в 99% автоматически ловят ошибки связанные с типизацией. Так что разницы нет, всё равно тесты писать, просто в динамических языках они ещё и такие ошибки проверяют.

CrazyPit ★★★
()
Ответ на: комментарий от ero-sennin

Хм...

% ls -lh xmonad
-rwxr-xr-x 1 stas users 868K 2007-09-16 19:36 xmonad*

stassats ★★★★
()
Ответ на: комментарий от CrazyPit

>Если тесты не тривиальные срочно нужно переписовать то что тестишь либо сами тесты

Не совсем ясна логическая цепочка: сложные тесты => что-то неправильно.

Почему тесты должны быть простыми, если по своей сути проверку результата работы программы очень сложно формализовать? (конкретно мой случай -- из области САПР для разработки печатных плат).

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

tche
() автор топика
Ответ на: комментарий от CrazyPit

>Ну вали, только чур на Haskell

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

tche
() автор топика
Ответ на: комментарий от ero-sennin

> В OCaml хоть natdynlink делают, а GHC так и создаёт статические бинарники по пицот мег. :P

Ну да для продакшена конечно окамл лучше развит, но как язык хаскель всё таки рульнее)

CrazyPit ★★★
()
Ответ на: комментарий от tche

> Не совсем ясна логическая цепочка: сложные тесты => что-то неправильно.

> Почему тесты должны быть простыми, если по своей сути проверку результата работы программы очень сложно формализовать? (конкретно мой случай -- из области САПР для разработки печатных плат).

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

> То что тесты нужны не отрицаю; я немного о другом сказал -- что при использовании языка с динамической типизацией в большом проекте шибко задолбался эти тесты прогонять по каждому чиху.

1. А в случае со статическим языком приходится прогонять компиляцию :P

2. Можно юзать чтуку типо autotest, которая весит демонам, дифает проект и прогоняет тесты кажды раз когда что-нибудь изменено, но только на изменнённом участке кода.

CrazyPit ★★★
()
Ответ на: комментарий от tche

> но со статической типизацией. И выводом типов, как в том же Haskell.

Ocaml, Nemerle?

CrazyPit ★★★
()
Ответ на: комментарий от CrazyPit

> Ну да для продакшена конечно окамл лучше развит

С его обратной совместимостью пытаться что-то собрать... если это продакшн...

stassats ★★★★
()
Ответ на: комментарий от CrazyPit

> 2. Можно юзать чтуку типо autotest, которая весит демонам, дифает проект и прогоняет тесты кажды раз когда что-нибудь изменено, но только на изменнённом участке кода.

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

tailgunner ★★★★★
()

>Чё делать, товарищи? Подумываю уже завязывать со Схемой и прочими питонами, и валить на что-то со статической типизацией...

www.linux.org.ru/jump-message.jsp?msgid=2129413 www.linux.org.ru/view-news.jsp?section=1&group=26 Java, martinfowler.com, eclipse.org, www.visual-paradigm.com/product/, gzip.rsdn.ru/Forum/group/java.aspx www.sql.ru/forum/actualtopics.aspx?bid=38

Добро пожаловать в мир промышленного программирования.

anonymous
()
Ответ на: комментарий от stassats

> А что тут непонятного?

А я сказал, что не понял? Прикола ради - посчитай ошибки и не-слова в том предложении.

tailgunner ★★★★★
()
Ответ на: комментарий от tche

>(смесь функциональщины + императивщины без излишне заумных сущностей :), но со статической типизацией. И выводом типов, как в том же Haskell.

www.scala-lang.org/ www.artima.com/scalazine/articles/stepsP.html blogs.sun.com/sundararajan/entry/scala_for_java_programmers scala.sygneca.com/code/start

anonymous
()
Ответ на: комментарий от anonymous

Рецепт счастья: прочитать М.Фаулера и кодить на Java, обязательно в Eclipse.

Я бы, может, и не против. Но Java со своей чрезмерной заточенностью под ООП в моём проекте как собаке пятая нога...

tche
() автор топика
Ответ на: комментарий от anonymous

> лишь бы Java не учить

Упаси Патрег. Как сказал Перлис, «Не стоит изучать язык, который не меняет вашего представления о программировании.» Вот и зачем учить Java?

stassats ★★★★
()
Ответ на: комментарий от stassats

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

Legioner ★★★★★
()
Ответ на: комментарий от anonymous

Уже говорил: текущая задача из области САПР для разработки печатных плат. Меньшая часть -- парсинг и генерация различных форматов файлов, большая часть связана с автоматической расстановкой компонентов.

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

tche
() автор топика
Ответ на: комментарий от stassats

Дорогой Зтазег! Есть еще такое слово - "куфать". К сожалению рынок труда для языков аля Lisp, Haskell, Scheme, Smalltalk, Icon, Forth стремиться к нулю.

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

anonymousI
()
Ответ на: комментарий от anonymousI

> Дорогой Зтазег! Есть еще такое слово - "куфать".

Тогда давайте сразу обозначим тему --- не программирование, а добыча пропитания.

stassats ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.