Talk:Interactive programming (repl)

Did I see some sort of "omit" template a while ago for tasks that are impossible in some languages? How do you use that? This task can't be done in a couple languages I know of. --Mwn3d 18:39, 21 February 2009 (UTC)

Do you intend to add the omit tag to all tasks that cannot be done in all languages?

Languages can be grouped together just as tasks can. This is a task to be done by those languages that have a CLI to show how to start the CLI in that language. --Paddy3118 05:07, 22 February 2009 (UTC)

I just want to say that this task is un-implementable in some languages (Java, C , C++). I thought I had seen a template that marked it as such for the unimpl bot. --Mwn3d 05:47, 22 February 2009 (UTC)

My apologies Mwn3d, I thought you were wanting to delete the page altogether. --Paddy3118 06:19, 22 February 2009 (UTC)

I don't think the template has been created yet. Check User:ImpleSearchBot/Code the bot's code to see what it uses. (I believe I have it set to check "Category:Langname/Omit" to see if a task is in that category.) There's currently no way to categorically drop a language or task from the listings short of removing the language from Category:Programming Languages or the task from Category:Programming Tasks. (I realize that's not what you had in mind, but it should help clarify how the bot's behavior can be manipulated.) --Short Circuit 10:56, 22 February 2009 (UTC)

It looks like putting it in Category:language/Omit does it:

<lang perl> my %omitted = map {$_, 1} $editor->get_pages_in_category("Category:$language/Omit");</lang>

Does that seem right? --Mwn3d 16:00, 22 February 2009 (UTC)

Yup. That should do it. I don't think I've created a template to add tasks to that category, but it shouldn't be difficult. (And it's preferable to adding the pages to the category directly, as using a template allows the check mechanism to change in the future.) --Short Circuit 18:59, 22 February 2009 (UTC)

I fail to see what concatenation of strings has to do with an interpreter and the latter with the language in which the task is to be implemented. I see a solution, but what was the task? --Dmitry-kazakov 19:03, 21 February 2009 (UTC)

Just starting up a CLI doesn't show enough. I added what I thought would be a simple and achievable 'sub-task' so people would get some comparison of what working in the CLI of each language is like. (Which is hard to do as the feel of a CLI can depend a lot on the editing facilities that it supports). --Paddy3118 05:07, 22 February 2009 (UTC)

Interpreter or not?

Interactive execution does not imply the system is an interpreter. I propose that this task be renamed to "REPL". --Kevin Reid 23:57, 21 February 2009 (UTC)

Interactive execution is most commonly supported by an interpreter and does not mislead. REPL is a less familiar acronym (for acronyms sake)? --Paddy3118 05:07, 22 February 2009 (UTC)

Please expand the acronym before renaming the page. (Thinking of which...The vast majority of the editors on RC right now are folks I'd trust with more privileges than the current default for logged-in users. I should probably create an "extended privileges" group that users can nominate and second each other for, and redefine the "Bureacrats" group back to its original purpose: Assigning user rights.) --Short Circuit 06:55, 22 February 2009 (UTC)

I believe that "REPL" is more recognizable than its expansion, but I can't say for certain. All I care about is that the word "interpreter" not be in the task name and description. --Kevin Reid 13:40, 22 February 2009 (UTC)

Please DO NOT change the name of the page. REPL, even as its expansion is change for changes sake. --Paddy3118 07:16, 22 February 2009 (UTC)

From 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. --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.

Most fun is the fact that googlefight gives CLI as overwhelmingly the more popular term:  :-)

- --Paddy3118 15:23, 22 February 2009 (UTC)

But the common definition of "CLI", which makes it so frequent, is "command-line interface", not "command-line interpreter". (Which, by the way, I would have no objection to the use of as the name of this task, if others see it as fitting. My goal here is entirely to promote terminology which does not propagate the impression that Anything Interactive is Interpreted (and therefore also seen as Inefficient). --Kevin Reid 22:02, 22 February 2009 (UTC)

CLI is the common acronym, but the full phrase is used as the page title so there should be no confusion.

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 ... ? --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... --Dmitry-kazakov 08:40, 23 February 2009 (UTC)

Hi Dmitry, some argue that programmer productivity is worth more than execution speed in most situations and in their eyes an interpreter may well be much more 'efficient' for them. Don't automatically equate efficiency with speed of execution - there can be other concerns. --Paddy3118 12:20, 23 February 2009 (UTC)

Hi! Well, overall economic efficiency depends on many things, and software developing process plays the major role here. If you had to develop a certified software you would find that tighter modification - execution circle would become less efficient because it does not well fit into V-model with requirements of traceability, roles separation etc. On the opposite pole there is so-called TDD. But that again does not very suited for interpreters, as you need to maintain a large base of tests, rather than test-as-you-type-and-forget. Further if we consider tools mounted above the code with languages of their own, I mean UML et al, we will find that present models of software development rather tend to deeply layered translations, than to direct interpretation. My take is that interpreters will survive as GUI, which brings us to back interactiveness. --Dmitry-kazakov 13:33, 23 February 2009 (UTC)

I'm not saying we should use "CLI", I'm saying that the usage which makes "CLI" popular googlewise is "command-line interface", not "command-line interpreter", so "CLI" being popular is not an argument for "command-line interpreter" being an appropriate term. Also -- I suppose I should have just not mentioned inefficiency; it's irrelevant. --Kevin Reid 11:13, 23 February 2009 (UTC)

Can we agree to use "Command Line Interpreter" as spelled out in full then? --Paddy3118 12:20, 23 February 2009 (UTC)

Interpreter behaves like...

If an interpreted language is by design able to read the standard input and to interpret it, this is considered like a "command line interpreter", or is just a side effect...? ... E.g. "awk -f -" starts AWK reading the source from standard input... and when the input is "finished", it executes the code... it seems like command line interpretation... can it be considered so? --ShinTakezou 23:00, 11 April 2009 (UTC)

I don't think Awk has a CLI. I would draw the line here and look for a bit more support from the language. Perl's use of its debugger I think would qualify, but both Perl and Python could be called in such a way that they read their program file from standard input. Merely using pseudo-files and/or redirection to enable compilers/interpreters to use standard input in place of a program file name should not be taken, in this task, to be using a CLI. --Paddy3118 10:24, 12 April 2009 (UTC)

CLI or line editor

I don't quite understand this task. First it talks about command line interpreter, and then requires creating a function. Command line interpreters do not create functions, they interpret and execute commands. If you are creating a function into a program, you are using an editor. For example, a traditional Basic interpreter uses a command mode which also acts as line editor. You can enter a direct command, and it is executed when you press enter. But if you precede the command with a line number, it is entered as a line in the program. In that case, you are using the editor. --PauliKL 21:02, 12 April 2009 (UTC)