Groovy - опциональная статическая типизация, синтаксический сахар. Только вот он JVMный.

go, boo..

python-psyco

на счет groovy - исходя из этого:
http://groovy.codehaus.org/Runtime vs Compile time, Static vs Dynamic
показалось, что статическая типизация в нем не слишком поможет качеству кода

вообще, groovy и boo не нравятся наличием слишком громоздкой vm со совими особенностями

насчет go: удачно его использовать именно как скриптовый язык, например, как альтернатива python?

хз, так и недошли руки пробовать. Но у питона 100% шире набор библиотек. Поэтому прогать на go будет в общем случае сложнее.

perl6… :(

python-psyco

а можно какую-нибудь ссылку на описание стат. типизации в нем?

по поводу 6-го перла в первую очередь интересует опыт его использования в реальных проектах

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

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

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

Сатическую типизцию хочется не для скорости, а для удобства.
Вроде, например, в F# (и наверное Boo) объекты могут быть со статическими проверками и без.

Насколько я понял, psyco типо-безопасности не добавляет.

Сатическую типизцию хочется не для скорости

А, ну тогда конечно да, psyco не катит.

> по поводу 6-го перла в первую очередь интересует опыт его использования в реальных проектах

ты не заметил грустного смайлика? единственная на данный момент более-менее рабочая реализация — rakudo — работает на два-три порядка (т.е. в 100-1000 раз) медленнее 5-го перла на примитивнейших задачах. о каких реальных проектах может быть речь… но опциональная типизация присутствует, да :)

заметил, поэтому и спросил, хх.

http://www.perlmonks.org/?node_id=908165
вроде и типизации пока нет, а жаль.

собственно, язык с типизацией как в 6 перле я и ищу.

бери луа и не дури себе головы.

> вроде и типизации пока нет, а жаль.

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

ясно

бери луа и не дури себе головы

не очень-то он статический

зато встраивается на ура

зато встраивается на ура

http://julien.danjou.info/blog/2011/why-not-lua

http://www.angelcode.com/angelscript/

anonymous deliveres

Внезапно, C.

Есть языки Coffe Script и Roy. На лету преобразуются в ява-скрипт.

Pike.

Unlike many other dynamic languages, Pike is both statically and dynamically typed, and requires explicit type definitions.

Внезапно, C.

C

Статическая типизация.

/0

А почему никто не предложил OCaml, тем более после упоминания F#?

Ээ.. WUT?

Когда это C перестал быть статически типизируемым? В новом стандарте, что ли?

• C# (можно использовать как скриптовый язык)
• Ocaml
• Haskell
• C/C++ (с этой штукой http://root.cern.ch/drupal/content/cint)

Почему в теме ещё tcc никто не упомянул?

Я для питона в свое время написал декоратор, к-й проверяет типы аргументов ф-ии (правда не пользуюсь из за лени).

«скриптовый ЯП со стат типизацией» - дурацкий вопрос, это вообще как? Т..е. контроль сразу при задании новой ф-ии, и только в рамках кода этой ф-ии?

декоратор, к-й проверяет типы аргументов ф-ии (правда не пользуюсь из за лени).

Это не статическая типизация.

Привет, implicit conversions.

Пойди почитай, чем различается деление типизаций на статические/динамические и строгие/слабые.

Я намекнул, собственно :)

Я в курсе;-) Но отчасти позволяет ее заменить.

Dart же ну

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

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

Действительно. В военное время ведь и π равно четырем бывает.

ActionScript 3

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

Странно, что ещё никто не упомянул Racket.

теперь это тред о ЛИСПе!

За angelscript, pike, dart и racket спасибо.
Под текущую задачу по разным причинам видимо не подходят, но надо их посмотреть.

lua не очень хочется использовать, лучше уж python.
tcc да, офигительная штука, но совсем из другой оперы =)

В чем «скриптовость» ocaml, haskell и c++ на cint - не ясно.

go

А как его встроить то?

Т..е. контроль сразу при задании новой ф-ии, и только в рамках кода этой ф-ии?

Этого не понял.

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

За CoffeScript и Roy тоже спасибо. Смысл изначальный - более интересный язык для браузера?

В моем воспаленном мосгу скриптовые ЯП прочно ассоциируются с интерпретируемыми. Как в интерпретируемом ЯП можно сваять полноценную стат.типизацию мосг понимать отказывается (если исходник на момент запуска до конца неизвестен), но в рамках одной ф-ии (поск. код заводится все таки некими кусками, и ф-ю запустить до того момента как она сформирована не выйдет) такое видимо возможно.

Что касается Ваших хотений... опять таки что есть частичная стат типизация не оч понятно. Вот я где то указываю, что этот объект должен быть int. Но этот объект формируется на основе каких то других объектов (кроме тривиальных случаев к-е неинтересны), а тип этих других объектов до момента исполнения неизвестен. Если указываем тип этих других объектов, то для проверки перед запуском нужно знать типы объектов из которых они получаются и т.д. Т.е. в рамках одной ф-ии такое наверное опять таки возможно (с точностью до глобальных переменных и пр. фигни), но как то оно мутно очень выглядит... типа беременности наполовину;-)

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

А как его встроить то?

пардон, не дочитал пост. Хотя, по логике, он на выходе даёт обычные либы по ABI совместимые с сями (через gcc фронтенд). А значит он без проблем подцепится.

Но я щас почитал про это go и понял что я его с чем-то перепутал. boo каким-нить.

Как в интерпретируемом ЯП можно сваять полноценную стат.типизацию мосг понимать отказывается

Точно так же как C это делает на этапе компиляции. Хедеры как раз для этого ему и нужны.