Hacker News new | past | comments | ask | show | jobs | submit login

You can make Tcl as non-Turing complete as you wish. Stripped of most or all builtin commands, it becomes a flexible configuration language. You can add back power in small controlled doses as it becomes necessary. You can also make it more palatable to the cool kids by adding infix assignment and expression evaluation with a few simple helper procs.



This was a big part of what motivated me to create OTPCL [1]; using full-blown Erlang or Elixir for configuration files feels dangerous and heavy-handed, and I want to be able to readily define DSLs for configuration files instead to offer better control/safety/ergonomics. Plus, I happen to like Tcl ;)

Imagine being able to go from a foo.app like this:

    {application,otpcl,
                 [{description,"Open Telecom Platform Command Language"},
                  {vsn,"0.1.0"},
                  {modules,[otpcl,otpcl_env,otpcl_eval,otpcl_init,otpcl_parse,
                            otpcl_shell,otpcl_stdlib,otpcl_stdmeta]},
                  {registered,[]},
                  {applications,[kernel,stdlib]},
                  {licenses,["ISC"]},
                  {links,[{"Bitbucket","https://bitbucket.org/YellowApple/otpcl"},
                          {"GitHub","https://github.com/YellowApple/otpcl"}]}]}.
to something more like a foo.app.otpcl:

    application otpcl {
        description "Open Telecom Platform Command Language"
        vsn 0.1.0
        modules otpcl otpcl_env otpcl_eval otpcl_init otpcl_parse \
                otpcl_shell otpcl_stdlib otpcl_stdmeta
        registered
        applications kernel stdlib
        licenses ISC
        links {
            Bitbucket "https://bitbucket.org/YellowApple/otpcl"
            GitHub "https://github.com/YellowApple/otpcl"
        }
    }
I dunno about you, but I like the latter a lot better :) It ain't a 1:1 representation, but it'd be straightforward to define each of those parameters as commands that emit the corresponding Erlang forms that make up an actual app spec.

While OTPCL's by no means ready for primetime yet, I'm hoping it'll eventually be good enough to fill that niche in the Erlang/OTP ecosystem the same way Tcl was meant to fill that niche for software in general.

[1]: https://otpcl.github.io / https://github.com/otpcl/otpcl


There's a reason MacPorts[1] uses Tcl for its package definitions. The packages for the most part look just like structured data, but it's just a Tcl DSL that allows them to e.g. write hooks in Tcl instead of having to embed a shell script[2].

[1]: https://www.macports.org

[2]: https://guide.macports.org/#development.examples




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: