Hacker News Reader

Comment by giancarlostoro | Hacker News Reader

One thing that takes away from programming languages is not having code samples on the index. I think this lets someone know immediately if it's interesting to them or not. Show a sample of code with the console output or a screenshot of an UI from the code. I think Racket had it right ages back. They would show everything from a web server, to other things. This is what major programming languages (with some exceptions) basically do and it gives a developer more information than any amount of marketing speak.

That said, I had to dig in the documentation to find code, and it didn't seem as obvious cause the syntax is definitely different from what I'm used to and there's weak syntax highlighting.

View on HN

TBH if you're creating a new language after 2014 you should be thinking about how to get good syntax highlighting and other tooling from the language definition itself, because you're competing with a ton of mature languages that had to do this manually through a ton of effort of their communities.

How do you get it from the language definition? By adding metadata to it?

It can be (kinda) done if your language has a parsing grammar.

It doesn't work in practice, since most languages eventually discard parser generators for custom parsing, and good tooling like syntax highlighters don't rely on the literal grammar but something close enough to the grammar to work and still be useful for programmers.

Classic example is you don't want your parser to be strictly defined and fail at any error. You want it to handle errors gracefully and detect almost correct syntax.

Having written some textmate grammars for syntax highlighting I think the post is ridiculous. I'd be terrified to generate that json from the parser, since a bit of thought and experimentation has to go into getting a good syntax highlighter that works with external tooling.

As well I think an LSP implementation is really important, but writing that in your language or generating it from the compiler is a monumental task for a young language and a terrible idea.

Perhaps this is the reason:

https://www.unisonweb.org/docs/language-reference#a-note-on-...

Thanks for this, I totally missed this nugget. If it's on the front-page it should be made more obvious. Whether it's code or some sort of video, every language should showcase something that tells you what development is like. Code you can interactively compile from a front page is always a plus too.

Interesting. Maybe they should add further representations of the code. This is not the only language where there are mutliple representations of the same "code".

Wolfram Mathematica (or "the Wolfram language") introduced "forms" for that, for instance https://reference.wolfram.com/language/ref/FullForm.html or https://reference.wolfram.com/language/ref/InputForm.html or, quite charming in the math context, https://reference.wolfram.com/language/ref/TraditionalForm.h... or https://reference.wolfram.com/language/ref/TeXForm.html -- See also https://reference.wolfram.com/language/tutorial/EverythingIs...

Also Bucklescript and ReasonML respectively provide OCaml and javascript-like syntax over the same AST and can translate your code between the two (as seen in the try reasonML UI).

That's not exactly how it works: Bucklescript is a JS backend for OCaml, and ReasonML is an alternative syntax for OCaml. Bucklescript is not involved in this translation, it generates the JS output on the top right pane of that UI.

https://forum.nim-lang.org/t/2811

The Nim language in 2008 (when it was known as Nimrod) had originally been planned a similar approach of considering a unified AST with multiple "syntax skins," and as far as I understand there used to be a limited implementation of this. This would theoretically have been a boon for Nim, because an often complaint about Nim from emigrating programmers from languages with a C-style syntax was the (rather superficial) complaint - "no braces? Pythonic syntax? Yuck!"

https://forum.dlang.org/thread/mailman.1427.1428691340.3111....

The problem with this - and why Nim never really committed to the "syntax skin" concept - is that it would have led to far much fragmentation within Nim's own community as some users would prefer one "sub-language" over another. Given as it is the opinion of new languages (Nim included) towards a tool-based unified syntax formatting (e.g. certain naming conventions for identifiers, number of spaces for indent), "syntax skins" have become harder of a sell in favor of lingual consistency.

The original idea was that the same program could be rendered in a variety of different syntaxes in the author's IDE - but the implied maintenance cost of such skins plus that previously mentioned potential for fragmentation led to this idea falling to the wayside. Nim, as a language, grew to be quite flexible within its prime syntax over the years - e.g. the macro system (which modifies the AST directly) made way for a variety of DSLs (e.g. https://github.com/khchen/wNim#code-examples) that remain valid Nim code.

> One thing that takes away from programming languages is not having code samples on the index. I think this lets someone know immediately if it's interesting to them or not.

Because when I see Chinese characters I know immediately if it's interesting to learn Mandarin or not.

Small code samples tell me next to nothing. How could they. I want a clear explanation of the foundational aspects.

I want both.

That's the ideal amount of information.

A reasonable example of a good page that is informative and provides lots of examples (enough at least!) is the one for D:

https://dlang.org/

I also like the "Ecosystem" part of Julia: https://julialang.org/ Sadly, for some reason code samples are lacking.

Julia is a language I love that I don't see myself using sadly. It does some amazing things that leave me shocked, like it can show you the assembly you generate while using a REPL. That's impressive to me. However, I'm not the target developer for Julia.

Edit:

Course after clicking your link, I am wondering how wrong I am since it is still technically general purpose capable. Wow Julia has grown so much!

Out of curiosity, what sort of development do you do? Julia is a very flexible language. The majority of its community is still focused on numerical scientific computing, but it's great for all sorts of usecases these days.

The way I think of it, in order to build a language that was flexible enough to cover all these different weird needs you find in the scientific computing community, they ended up needing to build a general purpose language.

How can you choose a language without knowing the syntax? It's not arbitrary. Some languages have elegance or gotchas in how the syntax is laid out

How can you tell the elegance or gotchas from a 6 line Hello World?

It's how I picked my favorite Python web framework, I compared all the hello world samples they all had, and wound up with CherryPy. The rest had too many decorators and it just looked silly to me.

You can also figure out if it's C-like or Lisp-like, and so on from looking at syntax.

From what you describe, sounds to me you picked your framework mostly at random, like one would pick a car for its color.

you can infer a lot; is it LISPy, is it C-ish, or one of the Haskell family, etc. I think you can tell a lot from just which family of syntax.

No, take Reason as an example: it is basically Ocaml. Despite having a C-like syntax, it is quite different from it. The syntax barrier is usually much smaller than the language itself.

And yet... someone trying to “sell” me a language while seemingly refusing to show me any code samples feels like someone trying to sell me a car based entirely on a spec sheet with no pictures and without actually seeing, touching or experiencing the car. They both provoke a reaction of suspicion - “what are they trying to hide?” As if they don’t trust me, the customer, to be able to understand the very thing they want/expect me to buy.

I’m perfectly fine with a page that says, “here’s a code sample - notice that it looks similar to C, but here’s a list of reasons / an explanation of why/how it’s actually quite different from C.”

One of my favorite programming books of all time is K&R, from back before ANSI, even. It said, “here’s a simple problem to solve, and here’s how you solve it in our language.” Repeatedly. Explaining how the features helped to solve the problem at hand. It was revelatory. And it assumed its audience to be knowledgeable programmers. It didn’t spend the first chapter just describing all the features or how great the language is without showing any code.

For many programming languages the line count of "hello, world!" program is exactly one.

So you can deduce something just from a line count of simple program alone - for one such deduction is an answer to a question "are there at least some attempts to provide useful defaults?"

I agree that a Hello World is fairly useless example for anyone already familiar with programming languages. Perhaps something like a Fibonacci function should be the de facto short syntax example, as is common in functional languages. More useful though would be to have an example of how composition data structures work in the language - standard example could be a binary tree.

Syntax is easy to show, but ultimately rather unimportant. If the big idea of a language is something substantial, starting by showing the syntax arguably just creates a distraction.

Syntax stops me from even considering some languages, because to a lot of us it is important. I spend most of working hours reading code; as a result how easy it is to read is important not just for my productivity, but for my overall happiness in life.

A small sample on the front page will not tell me if a language is good enough, but it can give me an idea if it's worth spending more time reading up on it or not.

Syntax is something you become used to in a few hours. But it's not what's the most important and will make your time more efficient in the end.

> Syntax is something you become used to in a few hours.

This is completely subjective and not at all universal.

Maybe you do. I don't. Syntax is something that has a substantial impact on how I think and work. Presentation overall matters immensely.

2000 years ago, they didn't have spaces or punctuation in writing. We could try dropping them again, and people would adjust after a few hours, but that doesn't mean that the spaces and punctuation don't provide value.

The problem is that readability is largely a matter of naming conventions, organization, and adherence to known patterns. The language becomes more readable as you use it. Anything that isn't a C derivative is unreadable if you only know C.

There are of course actual blockers to readability, like usage of similar-looking sigils and poor system library naming, but otherwise the syntax really doesn't tell you any useful information. It's the semantics that tell you how it'll all fall apart

I couldn't disagree more. Syntax changes whether I can look at a page of code and get an idea of structure and which elements to focus attention on, or whether I need to read everything in detail.

It doesn't matter that much when I have found a piece of code that I need to read and understand every detail of, but that is a tiny proportion of the amount of code reading I do - most of the time reading code is about grasping overall structure to learn a codebase well enough to find the points you need to focus on and read.

A clean syntax makes the difference between always having to read each token vs. being able to speed-read by pattern matching high level structure when you don't need the details of that specific piece of code.

I've worked with dozens of languages, with wildly differing syntax, and I'll say that once you reach a certain base capability-level, syntax matters more to me than semantics.

You can paper over a lot of semantic difference.

I can (and have, and so have many others) build libraries to do object-oriented programming in C, for example, and I have implemented closures in C too [1]. So the reason I don't do much C any more is not semantics, but that there is no mechanism for plugging those semantic gaps that creates readable code.

There are languages where the semantics paints you into a corner and makes plugging the holes too hard, so it's not that semantics doesn't matter at all. But it's usually easier to paper over semantic gaps than unreadable syntax.

[1] http://hokstad.com/how-to-implement-closures

What makes a program easy to read is not its syntax but its semantic, that dictates how much context one has to keep in mind to be able to understand a small fraction of code.

For instance, C and Go are easy because they do not hide anything and what one sees is pretty much unaffected by what one does not see. On the other hand, because those languages do not permit to build efficient abstractions they are also harder to read because each given sample, although unambiguous, perform very little.

Other languages like C++ (despite a syntax that is close to that of C) or Haskell, allow the behavior of the simplest operators, including the application and the sequencing operators, to behave in unfamiliar way or hide subtle but meaningful details, which makes understanding any small bit of code like a gamble (one has to assume some behavior for operators, constructors...). On the other hand, they allow to build abstractions that make programs more terse and therefore easier to read.

In this trade of, none of the alternatives depends significantly on the syntax.

I think a lot of people have associated obscure syntax with bad programming experience because of perl, the language which syntax became synonymous for bad. Indeed, this is a case where the syntax can be teacherous, but still the language is made more problematic by its semantic, that tries hard to give a meaning to any use of any variable in any context, this delaying runtime errors even more than other runtime typed languages and even masking them entirely (then performing something else than intended).

I think this mental association must be done away with.

Arguably, the syntax is the simplest thing one can change in a language, by creating a wrapper (like there are, as evoked in this thread, such wrappers around OCaml for instance.)

Francky, syntax has little to no incidence about how well a given language fits a domain problem, and in my experience the only thing syntax is really important to, is how attractive the language is to programmers who judge languages by their cover.

I remember having read somewhere that the initial versions of lisp where missing an actual syntax, and that it was planned to add one later, but that until then users would have to write directly the AST in an ugly syntax full of parentheses and devoid of familiar syntactic landmarks. Well, time passed, an nobody cared enough to add that user friendlier syntax :)

Little code snippets are nice to get a quick feel of the language. A good "Get Started" page is also a must have. I love languages or frameworks that have a step by step clear instructions on how to get started.

It's almost like taking test drives when you go car shopping. You don't want to open the hood and check what's inside right away you just want to be able to drive the car.

I don't want small code samples. I want well defined problems that this particular language is well suited for, as demonstrated by a dozen (or a few dozen) line program which uses the core features of the language to elegantly solve that problem. That gives me a feel for what the language is, and if interested, I'll learn about the foundations.

have a look if you want some example and what dev process looks like https://dev.to/petets/palindromes-with-unison-5h9o

Reply on news.ycombinator.com