The title of the stackexchange discussion is a little misleading. It really is: '"Hello, World" in what sloc thinks is zero lines of source code'

Most of the top solutions seem to take advantage of bugs in the way sloc tries to parse commented lines. e.g. many are:

    /**/<do_something>/**/

And I'm surprised I don't see a related bug issue in the git repo: https://github.com/flosse/sloc/issues

Still this is a fun read. I'm curious to see what other tricks are out there.

I think it's a bit much to name this a bug. This should have very little to no effect on real-world code, and the only way to fix it for real is to actually parse the languages.

It should in fact have an effect on real-world code. It looks like sloc in general doesn't handle nested block comments, so any source file that uses nested block comments will be counted incorrectly by sloc.

A bug is still a bug even if it's low severity and marked wontfix due to implementation complexity.

I wouldn't call an accuracy-performance tradeoff a bug, rather a design decision

No one is running sloc a million times per second. The performance cost here is trivial.

The accuracy cost is trivial as well, it's a trade-off. I'm pretty sure the implementers were fully aware that regex can't properly handle every case and decided not to care.

No, but you usually run it on a complete codebase which can be humongous.

Humongous what?

..in source size. What I meant was while for a single source file, performance implications aren't noticeable. But usually when we run a tool like this, we happen to do it on an entire project, e.g. imagine running it on Kubernetes repo. If it were to parse entire syntax trees, the performance implications would be significant.

> 17 chars

> //^H^HHello, World!

> After the forward-slashes for the comment, there are two backspace characters which erase them from the output.

Coolest solution in my opinion.

These threads are always such fun ways of seeing exotic features of stacks I don’t work with! Thanks for sharing I enjoyed it

Slightly more entertaining:

http://www.ioccc.org/1994/smr.hint

This is an IOCCC entry for the world's smallest quine, sizing up at 0 bytes of C. Some C compilers will compile an empty source file into a program which does nothing when executed, i.e. ouputs zero bytes, i.e. is a quine.

Reminds me of another 0-byter (not a hello): https://news.ycombinator.com/item?id=5920732

Oh I thought this was Jon Skeet's "hello world" in 1 byte, written in his custom "H" language. Of course he could have done it in 0 bytes but that would just be silly.

Jon Skeet would implement `sloc` in -1 bytes to begin with, and still fix the regex heuristics so that none of the posted solutions in that code golf works. ;)

You can do it in one byte in HQ9+ already. No need to invent a language that's just a feature-constrained subset of an existing one ;-)

Mod the complier to compile files with no code or only comments to produce a hello world executable.

There are quite a few esoteric programming languages used on code golf that use more or less the whole Unicode character set to solve even complicated puzzles in a few characters.

Some esoteric programming languages designed for code golfing do exactly that.

So, this is actually a bug in sloc, eh?

Quote: "NPM's sloc is a moderately popular tool for counting source lines of code in a file".

Never heard of it, personally I use LocMetrics. And it detects correctly that these are sources.

In Fortran, Hello World is just

  print*,"Hello, World"
  end

This is shorter than the way a Hello World program in Java, C, or C++ would be written.

Looks like a job for a fuzzer.

How is the difference between some helper tool's parser vs the corresponding copiler's parser an interesting hackable enterprise?

It's interesting the same way any other code golf is interesting: artifical constraints breeds creativity.

This sort of thing actually does have real-world applicability though: eg security issues caused by different parsing by a validation layer versus the actual execution.

Such a clickbaiting title

I don't think it's quite so bad - seems more playful than manipulative. I briefly added scare quotes around "zero" but it made the title look unusually weird so I took them off.

Looks like sloc is about to get a ton of new test cases for their comment parsing system.

What is the biggest program that could be created this way with zero lines of code?

It works for many langs by exploiting the sloc program not properly parsing multi-line comments. Thus the biggest program would be infinite nops.

As long as you can trigger a block comment you can add as much as you want, for example:

  /**/-->/*
  console.log('Hello World!');
  console.log('You can add as much as you want');
  --> */

No limit, since it needn't even fit on one (real) line, as even in languages with semantic newlines (and no alternative) you can just wrap every line in multiline comments.

The current winner seems to be HTML at 23 bytes, though I would argue it doesn't meet the requirements of the question, which call for a "full program".

Because it requires rendering by a browser? You could make the same argument that the interpreted language answers are also not “full programs”

But stepping back even further why are we talking about this, it’s just a fun exercise against a hello world. The only thing being solved for is fun.

The argument against is that HTML qua HTML is not a programming language, and that it is reasonable in English to say that "0 lines of code" implies the use of something that could have code in it, not something that degenerately contains no code because it is incapable of having any code at all. A text file with "Hello World" wouldn't be a solution either, nor the minimal CSV document with "Hello World", nor a PNG showing "Hello World", etc. These may also have "zero lines of code" in that strict, pedantic sense, but that makes them uninteresting.

The argument for including it even so is that if you think of the underlying challenge as "fooling sloc" and that the original challenge phrased it in terms of "code" simply because sloc mostly deals with code, but as it happens, it also tries to count HTML even though it isn't (necessarily) code, then it's reasonable to include.

I have to qualify HTML qua HTML because once you include Javascript, it goes from trivially not code to trivially being code, or at least capable of carrying code.

But it is important not to blur the lines between a document format and code. There are real and important differences. HTML qua HTML is not a programming language.

Edit: Oh, the solution to the other debate going on is that programming languages ALWAYS execute in the context of a virtual machine of some sort, or in the case of assembly, a real machine (at least in potential). The distinguishing characteristics of a programming language is something along the lines of being at least one of "Turing complete" and "able to read input, change behavior based on it, and write output", although I'm not getting too far down the weeds on that one on purpose. You can't use "whether or not they need a specialized execution environment to function" as a distinction for whether or not something is a programming language, because they all do.

The very straightforward counterargument is that sloc counts non-comment html lines as code-lines. The challenge is "trick sloc into considering something that it counts as code to not counting it as code".

This is way too much to write on the topic of what should and should not count for this goofy code golf challenge.

The much more important point is what is and is not a "coding" at all.

Oh, in that case, I have an even shorter "program":

  Hello world

Run it with `cat`. ;)

I remember seeing a great example of a unix quine somewhere:

#!/bin/cat

software.txt

If you are going down that route you could claim that assembly's use of a bios interrupt to print are not full programs either.

Would have to be a terminal-based browser, since the rules do specify that the message and nothing else must be printed to stdout. Presumably 'links' can do that.

It is slightly disappointing that all the solutions I see for various languages are just different ways to trigger pretty much the same multi-line comment parsing problem in sloc.

You missed the point. All the examples obviously all have at least one line of code, otherwise there would be no program to display "Hello, World!" at all. The goal is to have a program that is _counted as 0 line by the software "sloc"_ even though it is not 0 line.