Hacker News new | ask | show | jobs
by throwaway894345 1828 days ago
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.
3 comments

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

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.

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

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.
All of your comments are just spamming this library that nobody uses.