Имхо, компиляция по большому счету нужна только для проверки целостности проекта и релиза.
Существует ли язык который был бы статически типизированый, но его можно было бы просто запустить на выполнение без компиляции?
ЗЫ Или может я делаю что то не так и постоянная компиляция это добро?

>echo let x = 2*2 in print_int x > hi.ml
>ocaml hi.ml
4

Здравствуйте, dotneter, Вы писали:

D>Существует ли язык который был бы статически типизированый, но его можно было бы просто запустить на выполнение без компиляции?

есть интерпретатор С++

You will always get what you always got
  If you always do  what you always did

Здравствуйте, dotneter, Вы писали:

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

D> Существует ли язык который был бы статически типизированый,
D> но его можно было бы просто запустить на выполнение без компиляции?
выше уже сказали, что существуют интерпретаторы плюсов, правда с какой скоростью они будут работать и сколько ошибок выявлять — вопрос отдельный. а так — существует очень много верификаторов кода, статически отлавливающих явные и потенциальные ошибки, которые "прозевал" компилятор.

D> ЗЫ Или может я делаю что то не так и постоянная компиляция это добро?
трудно себе представить постоянную компиляцию даже маленькой программы в несколько тысяч строк, даже с учетом разбиения ее на кучу файлов. даже если это действительно компиляция, а не линковка.

Здравствуйте, dotneter, Вы писали:

D>Существует ли язык который был бы статически типизированый, но его можно было бы просто запустить на выполнение без компиляции?

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

Здравствуйте, D. Mon, Вы писали:

DM>А зачем это нужно? Так мы переносим тормоза из стадии создания программы на стадию ее выполнения.
Пишут же как то люди на динамически типизированых языках, у них там всегда такое состояние.

Здравствуйте, D. Mon, Вы писали:

DM>

>>echo let x = 2*2 in print_int x > hi.ml
>>ocaml hi.ml
DM>4
DM>

И насколько эта фича востребована? Насколько падает производительность?

Здравствуйте, dotneter, Вы писали:

D>Имхо, компиляция по большому счету нужна только для проверки целостности проекта и релиза.
D>Существует ли язык который был бы статически типизированый, но его можно было бы просто запустить на выполнение без компиляции?

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

Здравствуйте, dotneter, Вы писали:
D>Существует ли язык который был бы статически типизированый, но его можно было бы просто запустить на выполнение без компиляции?
http://www.haskell.org/ghc/docs/6.10-latest/html/users_guide/runghc.html

Здравствуйте, Lloyd, Вы писали:

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

Здравствуйте, dotneter, Вы писали:

L>>"статически типизированый" — это когда проверки типизации производится при компляции. Если программу предполагается запускать без компиялции, то о статической типизации речи быть не может.
D>Примеры которые были приведены?

А фик знает. Для меня "компиляция" — это трансляция из текста на определенном языке в машинный язык или в какой-то другой формат (байткод). Если маш. кода нет на выходе, то это уже не компиляция, а что-то другое, анализатор кода.

Здравствуйте, Lloyd, Вы писали:

L>Если маш. кода нет на выходе, то это уже не компиляция, а что-то другое
Интерпретация. Очевидно что один и тот же код можно скомпилировать или синтерпретировать.

Здравствуйте, dotneter, Вы писали:

L>>Если маш. кода нет на выходе, то это уже не компиляция, а что-то другое
D>Интерпретация.

Интерпретация — не антоним к компиляции. Тот же питон/перл компилируется (в байткод), но при этом программы интерпретируются, т.е. этап компиляции все равно присутствует. Думаю приведенные примеры хаскеля/окалма относятся к той же категории.

Здравствуйте, Lloyd, Вы писали:

L>Интерпретация — не антоним к компиляции.
Я бы предпочел под компиляцией понимать стандартную вариант, когда анализируется весь код программы.
Интерпретация — выполнение программы построчно. Есть там дальше компиляция или нет, сугубо личное дело интерпретатора.

Здравствуйте, dotneter, Вы писали:

L>>Интерпретация — не антоним к компиляции.
D>Я бы предпочел под компиляцией понимать стандартную вариант, когда анализируется весь код программы.

В какой момент должны отлавливаться ошибки типизации?

D>Интерпретация — выполнение программы построчно. Есть там дальше компиляция или нет, сугубо личное дело интерпретатора.

Выполнение — последний этап, дальше него ничего быть не может.

Здравствуйте, Lloyd, Вы писали:

L>В какой момент должны отлавливаться ошибки типизации?
В момент интерпретации. И не отлавливаться, а падать с ошибкой.

D>>Интерпретация — выполнение программы построчно. Есть там дальше компиляция или нет, сугубо личное дело интерпретатора.

L>Выполнение — последний этап, дальше него ничего быть не может.
Дальше не после выполнения, а после прочтения строки кода.

Здравствуйте, dotneter, Вы писали:

L>>В какой момент должны отлавливаться ошибки типизации?
D>В момент интерпретации. И не отлавливаться, а падать с ошибкой.

Понятно. Ну так это не статическая типизация. Вот цитата из википедии:

A programming language is said to use static typing when type checking is performed during compile-time as opposed to run-time.

Здравствуйте, Lloyd, Вы писали:

L>Понятно. Ну так это не статическая типизация. Вот цитата из википедии:
L>

L>A programming language is said to use static typing when type checking is performed during compile-time as opposed to run-time.

У нас есть ровно две кнопки.
1) Скоприлировать проект со статической проверкой типа.
2) Запустить программу и упасть в рантайме в случае чего.
Было приведено три языка с такой функциональностью, и я все не пойму что мы обсуждаем.

Здравствуйте, dotneter, Вы писали:

D>У нас есть ровно две кнопки.
D>1) Скоприлировать проект со статической проверкой типа.
D>2) Запустить программу и упасть в рантайме в случае чего.
D>Было приведено три языка с такой функциональностью, и я все не пойму что мы обсуждаем.

Вы их проверили? Как минимум 2 из них не удовлетворяют вашим требования (ocaml и haskell):
test.ml:

print_int 0;
print_int "0";

Результат:

lloyd@lloyd-pc:~$ ocaml test.ml
File "test.ml", line 2, characters 10-13:
Error: This expression has type string but an expression was expected of type
int

test.hs:

main = do putStrLn "0" 
          putStrLn 0

Результат:

lloyd@lloyd-pc:~$ runghc test.hs

test.hs:2:19:
No instance for (Num String)
arising from the literal `0' at test.hs:2:19
Possible fix: add an instance declaration for (Num String)
In the first argument of `putStrLn', namely `0'
In the expression: putStrLn 0
In the expression:
do putStrLn "0"
putStrLn 0

Как видишь в этих примерах анализ всей программы перед запуском происходит, а не построчно.

Здравствуйте, dotneter, Вы писали:

D>Было приведено три языка с такой функциональностью, и я все не пойму что мы обсуждаем.

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

Чистых интерпретаторов, которые не делают предварительной компиляции в байткод, сейчас почти не осталось. При этом многие интерпретируемые языки имеют динамическую типизацию и на этапе компиляции в байткод ошибки типов почти не отлавливают. Как вариант, близкий к запрашиваемому — старый Ruby (1.8.x) и утилиты статического анализа для него (типа DiamondBack Ruby).

Здравствуйте, dotneter, Вы писали:

D>Имхо, компиляция по большому счету нужна только для проверки целостности проекта и релиза.
D>Существует ли язык который был бы статически типизированый, но его можно было бы просто запустить на выполнение без компиляции?

Тебе нужен REPL?

Здравствуйте, Lloyd, Вы писали:


L>Вы их проверили? Как минимум 2 из них не удовлетворяют вашим требования (ocaml и haskell):

Я стараюсь верить людям на слово.
Что интересно тогда подразумевали авторы.
runghc allows you to run Haskell programs without first having to compile them.
Сокращение двух комант (compile, run) до одной?

L>Как видишь в этих примерах анализ всей программы перед запуском происходит, а не построчно.
Тогда вопрос открыт.

Здравствуйте, D. Mon, Вы писали:

DM>Здравствуйте, dotneter, Вы писали:

D>>Было приведено три языка с такой функциональностью, и я все не пойму что мы обсуждаем.

DM>Ответы приводились еще до уточнения вопроса. Реально там прога перед запуском быстро компилируется целиком в байткод и потом выполняется. Просто со стороны это похоже на интерпретацию (не надо отдельно компилять, а потом запускать), при этом есть статическая типизация.
Тоесть если ей подсунуть тысячу файлов, она их все будет компилировать?

DM>Чистых интерпретаторов, которые не делают предварительной компиляции в байткод, сейчас почти не осталось. При этом многие интерпретируемые языки имеют динамическую типизацию и на этапе компиляции в байткод ошибки типов почти не отлавливают. Как вариант, близкий к запрашиваемому — старый Ruby (1.8.x) и утилиты статического анализа для него (типа DiamondBack Ruby).
Вопрос не про устройство интерпретаторов, а про отсутствие компиляции всех файлов программы.
Грубо говоря, имеется 1000 файлов на С# и на Ruby.
После изменения одного файла, для С# придется перекомпилировать всю тысячу, для руби же в этом необходимости нет.

Здравствуйте, nikov, Вы писали:

N>Тебе нужен REPL?
Нет, мне нужно избавление от ожидания компиляции для того что бы увидить результат работы измененого кода.

Здравствуйте, dotneter, Вы писали:

L>>Вы их проверили? Как минимум 2 из них не удовлетворяют вашим требования (ocaml и haskell):

D>Я стараюсь верить людям на слово.
D>Что интересно тогда подразумевали авторы.
D>runghc allows you to run Haskell programs without first having to compile them.
D>Сокращение двух комант (compile, run) до одной?

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

L>>Как видишь в этих примерах анализ всей программы перед запуском происходит, а не построчно.
D>Тогда вопрос открыт.

Вопрос некорректен. Статическая типизация подразумевает наличие компиляции.

Здравствуйте, Lloyd, Вы писали:

L>Вопрос некорректен. Статическая типизация подразумевает наличие компиляции.
Допустим у нас есть код на python'e
x = "1"
y = 1
z = x + y
Будет ошибка рантайма.
Представи что в языке появилась статическая типизация и компиляция.
string x = "1"
int y = 1
int z = x + y
Будет ошибка компиляции. Но я не вижу причит что бы этот же код нельзя было запустить по старинке.
Итого имеем статически типизированый язык без компиляции.

Здравствуйте, dotneter, Вы писали:

D>Будет ошибка компиляции. Но я не вижу причит что бы этот же код нельзя было запустить по старинке.
D>Итого имеем статически типизированый язык без компиляции.

Нет, не будет. Будет просто строго типизированный язык.

Здравствуйте, Lloyd, Вы писали:

L>Нет, не будет. Будет просто строго типизированный язык.
string x = "1"
int y = 1
int z = x + y
Почему это код нельзя запустить без компиляции, что бы он упал в рантайме как это делает старый вариант?

Здравствуйте, dotneter, Вы писали:

D>string x = "1"
D>int y = 1
D>int z = x + y
D>Почему это код нельзя запустить без компиляции, что бы он упал в рантайме как это делает старый вариант?

Можно. Но статически типизированным он не будет. "Статический" означает, что проверки производятся во время компиляции.

Здравствуйте, Lloyd, Вы писали:


D>>Я стараюсь верить людям на слово.
D>>Что интересно тогда подразумевали авторы.
D>>runghc allows you to run Haskell programs without first having to compile them.
D>>Сокращение двух комант (compile, run) до одной?

L>А фик их знает. Возможно имелось в виду, что откомпилированный код не пишется на диск, а сразу скармливается интерпретатору.

Из документации GHC:

When you load a Haskell source module into GHCi, it is normally converted to byte-code and run using the interpreter. However, interpreted code can also run alongside compiled code in GHCi; indeed, normally when GHCi starts, it loads up a compiled copy of the base package, which contains the Prelude.

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

Здравствуйте, dotneter, Вы писали:

DM>> Реально там прога перед запуском быстро компилируется целиком в байткод и потом выполняется. Просто со стороны это похоже на интерпретацию (не надо отдельно компилять, а потом запускать), при этом есть статическая типизация.

D>Тоесть если ей подсунуть тысячу файлов, она их все будет компилировать?

Да. Для больших проектов этот режим малоприменим, его используют на мелких скриптах, например, вместо шелла.

DM>>Чистых интерпретаторов, которые не делают предварительной компиляции в байткод, сейчас почти не осталось. При этом многие интерпретируемые языки имеют динамическую типизацию и на этапе компиляции в байткод ошибки типов почти не отлавливают. Как вариант, близкий к запрашиваемому — старый Ruby (1.8.x) и утилиты статического анализа для него (типа DiamondBack Ruby).

D>Вопрос не про устройство интерпретаторов, а про отсутствие компиляции всех файлов программы.
D>Грубо говоря, имеется 1000 файлов на С# и на Ruby.
D>После изменения одного файла, для С# придется перекомпилировать всю тысячу, для руби же в этом необходимости нет.

Тогда Руби, Питон и куча других спасут российскую демократию. А когда захочется перед релизом проверить код статически, нужно будет воспользоваться анализатором кода, вроде упомянутого diamondback или pylint.

Здравствуйте, Lloyd, Вы писали:


L>Можно. Но статически типизированным он не будет. "Статический" означает, что проверки производятся во время компиляции.

http://rsdn.ru/forum/philosophy/3658780.1.aspx

Автор: dotneter
Дата: 02.01.10

Здравствуйте, dotneter, Вы писали:

L>>Можно. Но статически типизированным он не будет. "Статический" означает, что проверки производятся во время компиляции.

D>http://rsdn.ru/forum/philosophy/3658780.1.aspx

Автор: dotneter
Дата: 02.01.10

Я не понимаю, что ты хочешь сказать это ссылкой?
Определение статической типизации я тебе привел. То, что ты хочешь — не статическая типизация. Это все что я хотел/могу сказать.

Здравствуйте, dotneter, Вы писали:

D>Здравствуйте, Lloyd, Вы писали:

D>Интерпретация — выполнение программы построчно. Есть там дальше компиляция или нет, сугубо личное дело интерпретатора.

Построчно -- это васик. Причём тот самый, с номерами строк.
Большенство интерпретируемых языков проводят анализ программы до её выполнения (по крайней мере, часть программы).
В твоём определении питон не является интерпретатором, поскольку:

>cat test.py
print "Hello"
def dfdfdfdfd
>python test.py
  File "test.py", line 2
    def dfdfdfdfd
                ^
SyntaxError: invalid syntax

Здравствуйте, SolVolkov, Вы писали:

Но строчно, по файльно, не суть.

Здравствуйте, dotneter, Вы писали:

D>Здравствуйте, SolVolkov, Вы писали:

D>Но строчно, по файльно, не суть.

В питоне модуль является обьектом первого класса. Это и только это позволяет анализировать программу пофайлно. К динамической\статической типизации это не имеет никакого отношения.

"import" -- это инструкция, выполняемая в рантайме, означающая условно следующее:
1 проанализировать файл
2 возможно скомпилировать файл в байткод
3 выполнить байткод, создав обьект "модуль"

Примерно то же самое можно сделать и в статически типизированном языке.
К примеру на си это будет что-то типа
1 скомпилировать файл в динамически подгружаемую библиотеку (не любой файл, конечно, а специально подготовленный; или даже группу файлов)
2 загрузить подгружаемую библиотеку (LoadLibrary в винде)
3 достать из библтотеки нужные функции

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

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