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

use strict;

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

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

Юзать pylint.

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

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

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

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

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

да

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

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

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

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

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

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

>Юзать pylint.

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

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

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

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

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

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

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

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

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

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

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

Карринг?

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

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

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

http://www.lispworks.com/documentation/HyperSpec/Body/d_type.htm

defun f (x y)
   (declare (type fixnum x y))
   (let ((z (+ x y)))
     (declare (type fixnum z))
     z))

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

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

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

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

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

a = int()

b = str()

c = list()

...

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

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

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

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

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

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

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

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

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

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

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

А чем он лучше Ocaml?

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

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

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

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

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

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

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

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

>А чем он лучше Ocaml?

Мне больше нравится :)

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

Хм...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ocaml, Nemerle?

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

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

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

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

А что тут непонятного? Демон, тестирующий изменённые участки кода.

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

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

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

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

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

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

Спасибо, не надо.

Зачем тебе ошибки, раз ты понял.

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

http://www.scala-lang.org/docu/files/ScalaByExample.pdf Hindley/Milner Type Inference

Какой только питон и руби не подбирают, "лишь бы Java не учить"©

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

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

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

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

повторюсь http://xlr.sourceforge.net/ проект сырой и с неясными перспективами, но имхо весьма интересный

А какие задачи вы на всем это решаете ? %-I

s/это/этом/

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

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

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

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

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

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

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

"Regression testing"? What's that? If it compiles, it is good, if it boots up it is perfect. (c) Linus Torvads

Статика не спасет ИМХО.