1
\$\begingroup\$

We shall first define AutoCompletion as being the addition of any code segments to the code before either compile or run time as the direct result a keystroke and independant of outside information.

Note that this is not the same as typing or using autoformatting (which has been designated as valid by the community).

To further explain this, consider the following Segment of VBA code which uses AutoCompletion:

Sub H(): Debug.Print "Hello World"

After pasting this code into the VBE (Visual Basic Enviornment) and upon upon pressing Enter, , or (Iff the cursor is not on the first line of editor) this is AutoCompleted to

Sub H(): Debug.Print "Hello World"

End Sub

Of Note, this can and often is combined with autoformatting, for instance, the below shall also AutoFormat and AutoComplete to the above.

Sub H:Debug.?"Hello World

However, in this case, the addition of the terminal " is AutoFormatting whereas the addition of \n\nEnd Sub is AutoCompletion.

So, with this information is AutoCompletion Valid for CodeGolf?

Note that this question has been asked not so that this may be done, but becasue I have observed it several times in the past.

| |
\$\endgroup\$
  • 6
    \$\begingroup\$ IMO an IDE is not a language. \$\endgroup\$ – Magic Octopus Urn Nov 2 '17 at 20:59
9
\$\begingroup\$

No, it is not valid.

Code completion is a feature of the IDE which modifies the code before running. The byte count should be the code after modification - the code that is actually run.

Not only does this make sense as it counts the bytes of the actual code being run, but it also prevents a loophole where a user could create an IDE that 'autocompletes' to the extreme, adding several utility functions and other additional code before running, to greatly reduce the byte count.

| |
\$\endgroup\$
  • \$\begingroup\$ I agree with this, but the danger of the creation of an autocompleting IDE is really the same of the creation of an interpreter for a new language wich is a golfed version of an older one (which is a perfectly fine thing to do) \$\endgroup\$ – Leo Nov 3 '17 at 2:25
  • \$\begingroup\$ What a poor argument. Code itself is a form of auto-completion. Should we only count the size of the compiled code? It's the amount of code that was typed in that is the metric in all other cases. \$\endgroup\$ – Joffan Nov 3 '17 at 3:37
  • \$\begingroup\$ @Joffan so you think it's fine for someone to create their own Python IDE which expands 1-byte chunks into large portions of code, and then submit Python, 1 byte, automatically beating all other proper Python answers? \$\endgroup\$ – FlipTack Nov 3 '17 at 6:58
  • \$\begingroup\$ @FlipTack I think we're smart enough to know the difference between a task-specific cheat and a general-purpose interface. \$\endgroup\$ – Joffan Nov 3 '17 at 7:04
  • 6
    \$\begingroup\$ @FlipTack Creating your own IDE to reduce bytes is exactly the same as making your own language to reduce bytes. We've already got rules that cover that. If that's the basis of your argument then, -1. \$\endgroup\$ – Nathan Merrill Nov 3 '17 at 14:58
  • \$\begingroup\$ Usually the language standard allows that code to execute, but IDE completes it for "beauty". E.g. VB allows "If x<2 Goto y", but IDE just change it into "If x < 2 Then GoTo y". \$\endgroup\$ – l4m2 Dec 1 '17 at 8:24
  • 1
    \$\begingroup\$ For 'Sub H:Debug.?"Hello World', if I directly put it in a file and execute, that's an error, thus it's not allowed; but for 'Sub H:Debug.?"Hello World[LF]End Sub',it just work fine whenever the text is placed, thus allowed \$\endgroup\$ – l4m2 Dec 1 '17 at 8:26
4
\$\begingroup\$

An IDE can be a perfectly valid language:

There are effectively two ways to do this:

  1. The input/output is the file you are operating on, the language is the keystrokes it takes to convert it. We're already doing this.

  2. The language is the keystrokes to create the file, and the input/output is done by the execution of the said file. The language in this case is the IDE + Language being executed.

However, in both of these cases we need to be able to measure the bytes of the user interaction.

This means that we should be able to:

  1. Save to take your keystrokes to a file
  2. Measure the file size (to score the program)
  3. Replay the keystrokes on the IDE

Both Vim and Emacs keystrokes can be saved to a .vimrc or .emacs file, which can then be later replayed.

Other notes:

  • When I say keystrokes above, other forms of user interaction is acceptable as well (but I suspect that keystrokes will be far more efficient in bytesize)
  • Using a 3rd party library (such as Robots or AutoHotkey) to replay the keystrokes is perfectly acceptable. However, your language is now LibraryName + IDE + Language, and your language is measured by the size of the script used.

So, using VBA/VBE as a concrete example:

Can VBE execute keystrokes automatically from a file?

  • Yes: Your byte size is the size of the keystroke file, and your language is VBE + VBA.
  • No: Do you want to use a scripting program?
    • Yes: Say you use AutoHotkey. Your byte size is the size of the .ahk file, and your language is AutoHotkey + VBE + VBA
    • No: Too bad. This is not a valid programming language.
| |
\$\endgroup\$
  • \$\begingroup\$ I think that this is an interesting but I wonder about the specific labeling that you are proposing - that is, in the case of closed source languages that have only one dev environment is it necessary to include the name of the dev environment? Specifically sticking with VBA, the only way to execute VBA code is through the VBE - is there really a need to include the environment in such cases? \$\endgroup\$ – Taylor Scott Nov 3 '17 at 18:21
  • \$\begingroup\$ @TaylorScott The difference here is that you are using the VBE to autocomplete. You can have a VBA script that already exists on a file that executes without the VBE. \$\endgroup\$ – Nathan Merrill Nov 3 '17 at 18:36
  • \$\begingroup\$ I am not convinced that that is strictly true for a couple of reasons - 1. VBA code is recompiled and autoformatted by the VBE every time it is executed, and to my knowledge there is no way around this 2. One of the STDIN/STDOUTS for VBE is directly via the VBE immediate window \$\endgroup\$ – Taylor Scott Nov 3 '17 at 18:45
  • \$\begingroup\$ I just think that it is more accurate, in the specific case of VBA, to say that the VBE is more a part of VBA than a spearate entity - I mean, it is literally an object that can be directly interacted with from VBA code, but perhaps I am getting a bit too wrapped up in the exact implementation of your suggestion \$\endgroup\$ – Taylor Scott Nov 3 '17 at 18:46
  • 1
    \$\begingroup\$ If it is true that if you paste VBA code into your VBE editor and save it without letting the editor auto-complete, AND the VBA code runs just fine, then that's an acceptable form of golfing. TI calculators do the same thing, and we allow them to golf that way as well. \$\endgroup\$ – Nathan Merrill Nov 3 '17 at 18:59
  • \$\begingroup\$ This seems to be a near ideal manner of separating the two behaviors - as saving the file seems to trigger AutoFormatting but not AutoCompletion. \$\endgroup\$ – Taylor Scott Nov 3 '17 at 19:15
-7
\$\begingroup\$

Yes, AutoCompletion is Valid

AutoCompletion is valid and shall incur a byte count deficit, in bytes, that is exactly equal to the number of key presses that were necessary to make the AutoCompletion occur.

This means that for the first example in the question statement above the byte count shall be 35 Bytes ( 34 Bytes of Code + 1 Byte for a trailing Enter key press)

| |
\$\endgroup\$
  • 3
    \$\begingroup\$ I'd agree to this if the language of the answer was the IDE (which is whole another question), but otherwise this doesn't make sense \$\endgroup\$ – dzaima Nov 2 '17 at 21:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .