Talk:Interactive programming (repl): Difference between revisions

Line 24:
From [[wp:Command_line_interpreter|Command-line interpreter]]:
:''A command-line interpreter (also command line shell, command language interpreter) is a computer program that reads lines of text entered by a user and interprets them in the context of a given operating system or programming language.''
 
::According to this definition CLI executing a batch file is not a CLI. --[[User:Dmitry-kazakov|Dmitry-kazakov]] 08:40, 23 February 2009 (UTC)
 
The above applies to the task. Even if the text you wrote was saved in a file, compiled, executed then the execution results presented on the console, CLI would still apply, as the term applies to how you interact and you would, in effect, be be wrapping a compiler and separate execution to look like an interpreter.
 
Line 35 ⟶ 38:
 
As an aside, you should be wary of equating interpretation with inefficiency without further explanation. Forth for example is interpreted, gives very small executables, and can beat C compilers on speed. Inefficiency in programmer productivity, speed, memory footprint ... ? --[[User:Paddy3118|Paddy3118]] 06:08, 23 February 2009 (UTC)
 
:Interpreting is inefficient because it does not use machine language code as an intermediate layer before ultimate execution. Interpreter deals exclusively with the source language. This puts some obvious constraints on the language, especially when further limitation is an ability to interpret line-by-line. You cannot factor out and manipulate the machine code as compilers usually do. In fact modern compilers have more than just one intermediate code layer. To compensate inefficiency an interpreted language must be of a lower level in order to bridge the gap to the machine language. [[Forth]] perfectly illustrates this point. Well, some interpreters do precompilation stuff, to become more efficient and less interpreters... --[[User:Dmitry-kazakov|Dmitry-kazakov]] 08:40, 23 February 2009 (UTC)