Hacker News Reader

Comment by throwaway894345 | Hacker News Reader

I love these little embedded languages, but I really want one that supports type annotations. I'm specifically want something that can generate large configuration structures (e.g., Kubernetes YAMLs, CloudFormation YAMLs, Terraform HCLs, etc) and I want some static typing because the iteration loops can be quite long (minutes) which is too long to test every branch and writing and maintaining unit tests to catch type errors is a huge waste of time.

View on HN

Sounds like https://dhall-lang.org/

It's close. I also want something that is going to be syntactically familiar to humble programmers (my target users, myself, etc); Dhall's syntax is clearly Haskell-adjacent which is an obstacle for many of us. I'll probably just roll my own using a Rust-like syntax.

If you don't mind, what is it about the syntax of Dhall that you find hard?

In my experience, Haskell's syntax is much simpler than the syntax of any of the popular languages. The "hard" parts of Haskell come with all the abstractions people make (esp. how it encodes side effects), the laziness, and the language extensions. Dhall has none of those.

It seems to be a very polarizing topic. People who like Haskell's syntax find it very readable, others don't. In my estimation, there are a lot more in the "others" category than in the Haskell category. Whether my target audience has trouble with Haskell syntax because of some inherent property of the syntax or merely because their background isn't in Haskell doesn't ultimately matter--the requirement is that my users can quickly be productive (minimal learning curve, etc).

To be very explicit, I'm dodging the question because it's ultimately subjective and people come out of the woodwork with the same predictable talking points ("syntax doesn't matter", "but it's VERY readable! look how few characters!") and I don't have the energy this morning.

> it's ultimately subjective... and I don't have the energy this morning.

Fair enough, but I've never seen anyone make either of the talking points that you claim are common, and they would be very silly things to say.

Did you just ask for someones opinions on the syntax just so you could call them silly?

I think you misread, but maybe I should've worded it more clearly: the silly people are those hypothetical people who say that "syntax doesn't matter" and "fewer characters means better syntax".

> I've never seen anyone make either of the talking points that you claim are common

Count yourself lucky

> they would be very silly things to say

I tend to agree

Would your users be ok with something like this? Python syntax, rust concepts and transpiles to rust (and 6 other languages)

https://twitter.com/arundsharma/status/1407229297392115713

All of your comments are just spamming this library that nobody uses.

The syntax seems generally fine (Python's type annotation syntax is shoe-horned to minimize changes to the parser--if you're allowing yourself to rewrite the parser, why not improve the type annotations? Indeed, why not stick to a more Rust-like syntax in general?). I would want the ability to restrict the standard library and builtins (no I/O) a la Lua. Also, if the type system involves a borrow checker, I'll pass (borrow checking is cool but it doesn't make sense in what is ultimately intended to be a configuration language).

I'm open to having another syntax, another parser that produces the same AST. Let the market decide. No borrow checker concepts in the source, but transpiled rust code of course uses the borrow checker.

The python standard library is where I think the strength of this approach lies. Was reading some history on why reddit was rewritten in python (after initially implemented in LISP).

Transpiling python stdlib is a significant task in itself and could use more love.

Having a stdlib is fine, but it’s incompatible with an embedded scripting language where we want to provide and control the APIs that are available to the user. It sounds like you’re building a general purpose application programming language which is fine, but the tradeoffs differ.

I frankly think that alternative syntaxes for the same languages ought to be a thing. Case in point: OCaml and Reason.

I can imagine a curly-braced syntax for Dhall (BTW Haskell does have curly-braced syntax when you need it), curly-braced syntax for Python, etc. Indent-based syntax for HTML was implemented (but I forgot the name).

Also, RTL syntax and Arabic / Hebrew keywords for languages have also been implemented; this must be a huge help to those whose native writhing systems are RTL. Try writing your code right-indented and with all expressions backwards.

It sounds like CUE - https://cuelang.org/docs/about/ may be useful to you.

I've tried Cue, it gives you a type system for static JSON, but the support for functions seems either absent or very, very convoluted. I want to expose this configuration language as an interface to my tools, so the configuration language needs to be somewhat familiar (no need to reinvent functions poorly).

I guess no one mentioned jsonnet yet, but it's probably the most popular thing in use (along with ksonnet). But really, it's the most awful of the lot - where you have to program using a strange bastardization of JSON (Hello XML nightmares of the 90s/00s). Try using that for a while, and you'll be begging to use dhall-lang.

Wildly underrated libTCC[1] might be a good fit.

[1] https://bellard.org/tcc/

Reply on news.ycombinator.com