4 ms·
Looks like Dhall would be a perfect fit for you. > Dhall is a programmable configuration language that you can think of as: JSON + functions + types + imports
by karlicoss 7y ago
Looks like Dhall would be a perfect fit for you.
> Dhall is a programmable configuration language that you can think of as: JSON + functions + types + imports
https://dhall-lang.org https://dhall-lang.org
- pron 7y agoIt's hard to take Dhall seriously because it seems like its authors don't take it seriously, and work on it for entertainment. They went through the trouble of creating bindings for five (!!) different languages, and the most popular of them, by a pretty wide margin, is Ruby. I assume Fortran, Delphi, and Idris are next on their list.
- Gabriel439 7y agoDhall now has bindings to Rust and Go and Java/Python bindings are currently in progress We also do take things seriously, including: * Creating a language server (do any other configuration languages have this?) * Soliciting donations to fund high priority work (https://opencollective.com/dhall https://opencollective.com/dhall) * Working on a book (https://github.com/Gabriel439/dhall-manual https://github.com/Gabriel439/dhall-manual) * Maintaining a formal language semantics (https://github.com/dhall-lang/dhall-lang/tree/master/standard https://github.com/dhall-lang/dhall-lang/tree/master/standar...) If you think we're still missing something please let us know as we are responsive to user feedback
- anderspitman 7y agoHas there been any work to get a native browser implementation, either in JS or Wasm?
- Gabriel439 7y agoNot native JavaScript, but the closest thing we have is PureScript (still in progress): https://github.com/MonoidMusician/dhall-purescript https://github.com/MonoidMusician/dhall-purescript PureScript corresponds pretty closely to JavaScript in terms of the code it generates, so once we have a PureScript binding it shouldn't be hard to generate lean JavaScript bindings from that. Also, more people requested the PureScript bindings over the JavaScript bindings anyway in our most recent yearly survey: http://www.haskellforall.com/2020/02/dhall-survey-results-2019-2020.html http://www.haskellforall.com/2020/02/dhall-survey-results-20...
- pron 7y agoRust and Go are even less popular than Ruby but glad to hear about Java and Python. Either one of them has at least 5x the market penetration of all currently supported languages combined, and at least 10x of all of them but Ruby combined.
- Gabriel439 7y agoOverall language popularity is only one input into how we prioritize programming languages. The best way I can summarize our prioritization process is that we prioritize in descending over: * What people are willing to spend their free time to build (I can't order other people to build high-priority bindings and my own free time is already accounted for by improving Haskell bindings that power a lot of shared tooling such as the language server) * Bindings specific to DevOps use cases (e.g. Go / Python / Ruby / Nix / JSON / YAML), since they are the dominant languages and formats in this space) * Bindings that can be used to create derived bindings (e.g. Rust, which can then be used to create a binding in any language that can bind to C. In fact, this is how the upcoming Python bindings work. See: https://pypi.org/project/dhall/ https://pypi.org/project/dhall/) * Bindings that users request (We have a yearly survey where we ask users to inform the direction of the ecosystem. Python was the most requested language in the most recent survey) * Overall language popularity (as the final tiebreaker) So I hope this illustrates that there is a lot more that goes into these decisions beyond just which language is the most popular and we're not being obtuse or dilettantes just because we haven't gotten to a specific language, yet.
- anderspitman 7y agoI've looked at Dhall before, and never come away with a desire to try it. It's interesting, and definitely has a lot of the right ideas. I'm not convinced functions are necessary. Also, any language without an official browser JavaScript implementation obviously wasn't created to solve the same problems I'm interested in.