DEV Community

Cover image for We Should Get Rid of HelloWorld Forever💩
Maxi Contieri
Maxi Contieri

Posted on • Edited on

We Should Get Rid of HelloWorld Forever💩

Every tutorial I've read for the last 30 years starts with the infamous 'Hello World' example. This could be one of the reasons we write crappy software.

"Hello World" is the first program we make in every language.

We can measure the complexity of language by counting the lines it takes to produce the desired output.

We can also time how much does it take to a newbie to figure out the solution (this is also known as Time to hello world" (TTHW)).

These two metrics are uncorrelated to productivity.


Many sites compile different Hello World programs in a lot of languages.

The Problems

The Hello Word example has a lot of problems introduced early when developers are making their first steps in programming.

  1. It uses globals in many languages. Global functions are a code smell. Teaching them to newcomers in theirs first example is conflicting.
  1. Hello World yields side effects (on the console, file system, printers, etc.).

  2. We write the code and we cannot test if it is working. We can manually check for the output but our software cannot assert it our outcome was right.

  3. If our HelloWorld works today we cannot ensure it will keep working tomorrow.

The Solution

All developers should start with:

function testFalse()
{
    Assert(1==2)
}
Enter fullscreen mode Exit fullscreen mode

Advantages

  1. We start with a broken test. This is the first step to start developing software according to test driven development technique.
  1. We introduce developers to a Continuous Integration/Continuous Development pipeline with their very first instruction.

  2. We use no Globals or side effects.

  3. We show the importance of early testing.

  4. We stress how important is to have working code and automated tests from the very first second.

Conclusion

We need to stop writing HelloWord as the first sentence of a language.

Next time you come across a new fancy language, please start with a broken test.

Top comments (7)

Collapse
 
phlash profile image
Phil Ashby

While I generally agree with your point, I find writing a very simple (shortest valid) program helps when setting up tooling for a new language ecosystem, sometimes it doesn't 'just work' after the bloatware/setup wizard has done it's worst to your file system!

There is always '99 bottles' for a little variety ;)
rosettacode.org/wiki/99_bottles_of...

Collapse
 
valeriavg profile image
Valeria

Thank you for the article, I've enjoyed it. And I have couple of thoughts on the subject, that I'd like to share.

"Hello world" is more of a teaser than an actual introduction. Something to make you want to read "The book of {language}", which explains the pros and cons and the process in depth.

A generic "Hello world" example sets a simple task and gives you an immediate feedback, giving you a taste of the flow.

One more thing to add is that globals, monkey patching and side effects are not to be demonized. Instead we should promote right use for the right tool, expanding the possibilities and creativity of the newcomers.

Why do we write crappy code? Because we're tired, lazy or there was no time for the tests (hint: there's always time for the tests)

Collapse
 
mcsee profile image
Maxi Contieri

Interesting. I agree with you

Collapse
 
dhains33 profile image
Dave

Completely agree, a thought I've been pondering put into words

But there's the issue of scaring people off, over more in certain language that are more convoluted to start with...

Definitely something that can be thought from day one in simpler language like Python for say.

Collapse
 
hb profile image
Henry Boisdequin

Maybe we can do this:

function testFalse() {
     Assert("Hello" == "World")
}
Enter fullscreen mode Exit fullscreen mode
Collapse
 
mcsee profile image
Maxi Contieri • Edited

Yes. I try to write my articles in pseudo code. So everyone understand it
Of course i could have chosen any real language. But i write for humans, not for compilers.
If you see my code smell series their code is written in 12 different languages. I deliberately choose not to use a real one on this article.

But i agree maybe checking strings will be better than checking numbers

Collapse
 
ricobrase profile image
Rico Brase

From a conceptual point of view, it's irrelevant if we are comparing numbers/ints or strings. It's the same thing.