> But of course aesthetics is subjective. (The term "subjective" here means what looks good to you might not look good to me, and vice versa.)

Bullshit. There's so much that objectively deficient about that piece of code that I'm having trouble taking you seriously. If that comes at all close to being a representative sample of someone trying to make clear, readable code in that language, then the language was clearly deliberately designed to have an excess of visual noise. But I suspect you're not actually trying to make that code look as clean as the language allows.

The semicolons serve no apparent purpose. Having labels like x01 and x01a with no functional relationship between those lines is outright hostile to the reader. Using x as the prefix for almost all of your label names and as one of your variables is mildly confusing, especially when most of those lines don't relate to the variable x and don't appear to need labels at all. "output" seems to be a magic variable for which assignment has side effects, but nothing in the syntax differentiates it from any other variable. Grouping all the conditionals together, then grouping all their consequences together forces the reader to jump back and forth between lines more than if you put the consequence of each conditional immediately after the corresponding test (in this instance, your way does have the advantage of making the conditional fall-through pattern more readily apparent, but on the other hand that wouldn't be as necessary if you could use more than one line of code to write a single line of output).

You can claim all you want that aesthetics is subjective, but at the very least you must recognize that visual noise you've trained yourself to ignore is objectively different from code which doesn't have those distractions in the first place.

> Bullshit. There's so much that objectively deficient about that piece of code

I don't agree the GPs code is more aesthetically pleasing but he's right that it is subjective. All the counterarguments you've given are subjective to you (eg you know what tokens do in over languages, spent zero time learning the tokens of this language and thus you're clearly not going to know what a colon does in this language just by looking at it).

One of the hardest things it seems for a developer to do is accept that their personal opinions are subjective since they spend so much of their career being told there's a correct way of doing things. Your post here is a classic example of that. Arguments about strongly typed and loosely typed languages are another. Debates about functional, stack backed, object orientated, procedural, etc etc... it's all just people like yourself trying to convince others that your subjective view is empirical scientific fact. But it's not, it's just opinions. Some opinions just happen to be more popular.

> All the counterarguments you've given are subjective to you (eg you know what tokens do in over languages, spent zero time learning the tokens of this language and thus you're clearly not going to know what a colon does in this language just by looking at it).

I tried very hard to only bring up problems that were at least somewhat objective. Counting the number of superfluous symbols in the code is not purely subjective. Noting the similarity between "x01" and "x01a" is not purely subjective. Measuring the distance between a conditional test and its consequences is not purely subjective.

And I did figure out what a colon does in this language just by inspecting this code. It's semicolons that serve no apparent purpose in this snippet, and even with the outside knowledge that they serve the same statement separator purpose as in C and many other languages, it's still an objective fact that they are largely redundant. The character count could have been a lot lower if the language made it the default for new lines to start new statements and used a special character for continuing a statement on another line.

Subjective would have been if I complained about the semicolons being at the beginning of the line instead of at the end. That's almost purely a matter of taste driven by prior experience with other languages.

The fact that the OP had a different opinion to yourself about what he found readable is proof enough that it is subjective and it’s laughable how you’ve demonstrated hnlmorg’s point while attempting to debunk it (eg your attempt at providing fact while your evidence is just more illustrations of familiarity which is entirely subjective).

> The fact that the OP had a different opinion to yourself about what he found readable is proof enough that it is subjective

Subjectivity isn't an absolute all-or-nothing question. An issue having some degree of subjectivity doesn't automatically put it into a purely subjective, "all answers are equally valid" realm.

> eg your attempt at providing fact while your evidence is just more illustrations of familiarity which is entirely subjective).

I referred to some quantifiable metrics. Those have nothing to do with familiarity. Whether a number is larger or smaller than another number is a fact unaffected by your level of familiarity with either number.

You're really not responding at all to the substance of my comments, so you really don't have any justification for calling me "laughable" at this point. There are plenty of ways you could try to substantively refute my comments, instead of rejecting everything generally while mixing in insults.

> I don't agree the GPs code is more aesthetically pleasing but he's right that it is subjective.

An easy way to see that these issues aren't subjective in general is to ask why absolutely no-one uses the kind of code given above unless they're forced to because of the platform they're using, e.g. a constrained embedded environment or whatever.

You either have to conclude that effectively all developers have the same subjective take on these issues, or that there's something beyond subjectivity at work. There are very good arguments for the latter.

"output" is a keyword, cannot change it (I guess one could recompile the interpreter and define it as something else)

semicolons separate statements. Dont like them at the beginning, move them to the end.

Dont like the label names. Rename them to whatever suits you.

The thing that you may be misunderstanding is that this is written for me, not you. It is written to please my sense of aesthetics, not yours. I am not employed to write programs for other users or to be read by programmers. Every user is different.

You probably could not write a program I would use. I would find "deficiencies" and reject it for something else.

If programming is objective then why are there thousands of different languages, and the number is constantly increasing. All of them are basically doing the same things.

Honest question. Why are there so many different languages. Whats behind that.

"I am not employed to write programs for other users or to be read by programmers. Every user is different."

Well, unless you are the only programmer that company will ever has, you should write code that others can read and understand. Or if you are working in academia, then you can write as you like, but as a professional, you should write readable code for those coming after you.

Devils advocate:

GP might work for a company working on a niche application (be it software or hardware) that requires code to be written like the aforementioned and anyone who specialises in that field is already adept in reading and writing code like that.

I'm not going to defend that choice of programming style for everywhere but software development is a broad industry where you do get pockets of people working on code that looks totally alien to others who are used to see C or ALGOL derived languages. Take LISP for example, there is LISP code in half of all European TVs shipped in the 90s. Forth is used in loads of places, even FreeBSD's bootloader is written in Forth. Machine code is almost completely unreadable for humans yet a massive chunk of software in the 80s was written using it.

My point is the industry might have standardised on a subset of syntax styles that seem readable to the lowest common denominator of developers but it's a massive industry with developers using all sorts of exotic languages effectively. Let's not go down the rabbit hole of saying they're doing it wrong because their code looks alien to you before you've understood the field in which that code is running in.

You’re losing karma for this but you’re right. It’s a massive industry and there are specialties out there writing code in languages that would look unreadable to your average web developer yet the code is well written and perfectly readable to those in the same specialty.

Sometimes I wonder if the only people who browse this site are JavaScript monkeys and Rust fanboys. There’s a whole spectrum of languages out there that looks nothing like C.

Check your assumptions. What if someone is not working as a programmer, not working in academia and not sharing programs with others, except in HN comments/submissions.

There was a story that appeared on HN many years ago and I wish I could find it again. It described a gentleman in Japan who did not work in the computer industry but did some sort of (let's call it) "optimisation work" on his own as a hobby. The story told that the work was being used by companies within the computer industry, I think it was hardware manufacturers. If I recall correctly he did not have any formalised education in computer science or mathematics. I am probably getting some details wrong; need to find this story again.

> Honest question. Why are there so many different languages. Whats behind that.

1. Personal pride.

2. Personal or corporate need for control

3. Personal or corporate need for visibility/fame.

4. Licensing unfit for desired use.

5. Technical or social impossibility to extend existing language to fit target space.

And plain old ... personal/group preference?

Some people like different tools for reasons other than pride, ambition, need for control, etc.

Some things are more enjoyable for some people. Chocolate vs vanilla kind of thing.

You’re way off the mark!

1. Might happen occasionally but rarely would anyone adopt a vanity language

2. Nope

3. Lol this is just a rehash of 1.

4. Languages can’t be licensed, compilers can. And that’s why we often have multiple different compilers.

5. Now you’re getting close.

The actual reason is:

Trying to solve a different problem

Believe it or not, problems can vary massively from one field of IT to another. Some require low level hardware access, some need mathematical compatibility, others might be optimised for text parsing, and sometimes you just care about developer throughput. There’s macro scripting, web development, games development, server side software, OS development, and firmware. And entire industries using their own specialist tools that most people don’t even know about unless you happen to already work in it.

Some languages are designed to be bullet proof and used in aviation or other domains where failure isn’t an option, some are the electronic equivalent of duct tape designed to allow people to quickly stick operations together.

Programming is such a massive industry that you need different languages for different problems.

Ever heard of C#, J#, Typescript, Kotlin, Go?

Yes and only C# was created because of NIH syndrome:

C# - Created by Microsoft after Sun sued them over Java. But C# (or rather .NET) did still solve several problems with Java’s JVM (eg it’s much easier for end users to work with, it supports native widgets, first class Windows support) and personally I find C#’s syntax a little more grown up too. It’s also worth noting that C# has since evolved into its own language (rather than just being a Java knock off).

J# - there isn’t any other functional language that targets .NET so there is a distinct problem J# seeks to solve.

TypeScript - That language clearly aims to solve several short comings of JavaScript, such as type safety.

Kotin - I don’t know much about this language personally but the Wikipedia article answers my point for me:

> In July 2011, JetBrains unveiled Project Kotlin, a new language for the JVM, which had been under development for a year.[17] JetBrains lead Dmitry Jemerov said that most languages did not have the features they were looking for

Go - this filled a massive hole at the time: languages that had the guarantees of a statically compiled language while being as quick to learn and develop on as a JIT compiled language and which were cross platform. I actually adopted Go in version 1.0 for a personal project specifically because it solved problems with the other mainstream languages - problems that were very relevant to the project I was creating.

I’m an old fart with 30 years of software development experience across well over a dozen different languages (you could easily treble that if you want to include machine or compiler specific dialects too). The problem many have when they see the term “general purpose” is they assume it means “best suited for all purposes” but actually it just means “can solve most problems with some degree of success”. Thus there will naturally be specific domains where even the most versatile languages are superseded by another language. And that’s fine. Good programmers can adapt to using the right tools. Whereas bad programmers will reach for the same tools regardless of the problem because they’re too lazy or too ignorant to learn anything else.

"Structured programming" has a very specific meaning. Or at least, it did in Dijkstra's goto paper. It's not that all uses of goto are terrible, it's that if you restrict goto's uses to specific types of control flow, you can make provable statements about the behaviour of the code, which other uses blow up.

The goto's you've used here are within the set of allowable uses, so can be mapped directly onto structured constructs. There's literally no advantage either way, other than introducing the possibility to the reader that there could be something weird going on in your code.

> Would love to see a faster version in some popular, "structured" scripting language in the same number of characters.

How's this?

    #include <stdio.h>

    void main(){
      for(int a=1; a<100; a++){
        int y = a % 3;
        int z = a % 5;
        int x = y + z;
        if(!x) puts("fizz");
        else if(!y) puts("buzz");
        else if(!z) puts("fizzbuzz");
        else printf("%d\n",a);
      }
    }

Same technique, give or take some unimportant details. Not particularly golfed. 240 characters to your 312. I have no idea if it's faster because I don't know how good the spitbol interpreter is, but I do know that because I've used "structured programming" structures, the compiler (or interpreter, whichever you prefer) can in principle make more safe optimisations to my code than to yours.

If C doesn't meet the "scripting language" constraint (which I find arbitrary, but not insurmountable), I'd throw Julia or FORTH at it and probably shave a considerable number of bytes off.

"How's this?"

Unoptimised, it's already roughly 3x faster than the spitbol script.

Moving the "int" specifier out of the for loop allows this to compile under -std=C89. How does one suppress the warning about the non-int return value for main().

The easiest way is to `return 0;`. We've got the character budget for it.

I really don't understand the comparison you're trying to make. I learned SNOBOL from a university library book in the early 1980s, and used it on the university mainframe - but it's baffling to me that someone might want to continue using it today for anything other than nostalgic reasons. (If you're trolling, good one!)

There's an enormous amount of accidental/inessential complexity in the code you provided, and that's a big part of the reason no-one seriously uses SNOBOL or similarly primitive languages for anything serious today. Code like the above can't remotely scale to larger programs, and attempts to do so were notorious for their failure.

Here's a version of FizzBuzz in e.g. Haskell:

    fizz n | n `mod` 15 == 0  = "FizzBuzz"
           | n `mod` 3  == 0  = "Fizz"
           | n `mod` 5  == 0  = "Buzz"
           | otherwise        = show n
 
    mapM_ putStrLn $ map fizz [1..100]

Even the already rather simple control flow is abstracted away by the 'map' function, so there are no visible loops or gotos. Compare that to your program with a dozen labels and seven gotos, where the actual logic is buried in irrelevant cruft.

Even versions with more explicit control flow (i.e. without map) can be similarly readable, but if your goal is to minimize complex control flow, then rather than reverting to intractable gotos, go read "Lambda: The Ultimate GOTO" (http://dspace.mit.edu/handle/1721.1/5753), published in 1977, and learn to use functions for control flow.

Better than Haskell and faster, too:

    fizzbuzz:{v:1+!x;i:(&0=)'v!/:3 5 15;r:@[v;i 0;{"Fizz"}];r:@[r;i 1;{"Buzz"}];@[r;i 2;{"FizzBuzz"}]};`0:$fizzbuzz 100

You're wasting your own time.

This is the opposite of aesthetically pleasing to my eye.

Aesthetically, it bothers me that you compute x by calling remdr two extra times, as opposed to computing it as the sum of y and z... or the bitwise OR of y and z...

What's the difference between :(label) / :s(label) / :f(label) / :s(label1)f(label2) ?

> What's the difference between :(label) / :s(label) / :f(label) / :s(label1)f(label2) ?

Looks like it’s unconditional, conditional (success), and conditional (failure) jumps.

:s(A)f(B) is how you tell it to jump to A on success and B on failure.

There is also an "indirect goto" where B is a variable to be appended to string A to compute a label that is defined somewhere else in the program.

   :($('A' B))

   s and f are different conditions
   s=success
   f=failure
   default is unconditional

Is bitwise OR a built-in or would it require writing a separate function.

Based on the documentation, there do not appear to be any bitwise operations available in SNOBOL.

It looks like computing x as remdr(3) + remdr(5) is a pure mistake. You only care about the case where remdr(15) is 0, and it's true that remdr(3) + remdr(5) is 0 if and only if remdr(15) is 0. But you're calling remdr twice where you should only be calling it once.

(Or, really, you can keep the weird calculation of remdr(3) + remdr(5), which is conceptually incorrect but correct in every case that matters, but stop computing it with two extra calls to remdr. You're already calculating those values and storing them in the variables y and z; compute x as y + z, which must be much faster than calling remdr two additional times.)

As a side note, why do you want to use "a language for non-numeric computation" for this purely numeric problem?

I think the term "non-numeric" probably refers to another popular language of the era from which SNOBOL comes called FORTRAN. The purpose of fizzbuzz as I understand it is to test a person's aptitude for programming, but not necessarily a person's ability to select the "right" programming language.

If the purpose of fizbuzz is to test for programming language selection, and fizzbuzz is a "purely numeric problem", then should the proper choice be FORTRAN.