For instance?
> But most languages are designed to constrain the programmer to a way of thinking, a series of patterns. Lisp was the opposite.
Lisp is still the opposite. Exactly this is the problem of Lisp: It is too powerful. I admire Lisp for its power, and there actually is no other language with such a freedom. Everyone can write his own DSL to simplify his task. Writing DSLs is extremely easy in Lisp.
However, this doesn't profit maintainability, and it makes sharing code with others difficult. You actually need a lot of discipline that you code in such a way that it remains maintainable. In teams you need to constrain the way of thinking otherwise you can quickly run into chaos.
Java is the opposite of Lisp. You cannot code productively in Java unless you use a sophisticated framework. Such frameworks force you to a certain style of coding which profits maintainability. That is one factor which explains the huge success of Java in business.
Nim and Rust combine both paradigms. They provide a certain degree of freedom, and they require a certain degree of discipline. Haskell requires an extreme amount of discipline. In case of Haskell's freedom I am not convinced.
> For instance?
Nimble file naming [0]. It must end in '.nimble', and must have at least character in front of that suffix, but the prefix doesn't actually matter.
I'm not convinced on the maintainability argument. Many, many projects have a coding style guide. LISPs require one too. Once you have one, maintaining the code becomes as difficult as any other language. I've encountered unmaintainable Python code [1], and insanely well documented Scheme code [2]. I'm not sure the language has much to do with it, apart from supporting a wide range of paradigms and patterns.
I'm not sure black-boxing through use of a sophisticated framework is any better than the way you work in more flexible languages.
Here's my take:
* Nim is great. The use of the 'auto' keyword let me be productive using it.
* Scheme is great. It lets me do insane things, and the compiler will optimise it to work, and well. (Rather than breaking three similar function into pieces, I can make one function that generates all three functions using their commonalities).
* Java is the smart kid at college who always answers questions in the form of a thesis. He isn't wrong, but you don't really remember what he was saying.
[0] https://github.com/nim-lang/nimble/issues/166
[1] Hence why things like this exist: http://docs.python-guide.org/en/latest/writing/structure/
[2] http://cvs.savannah.gnu.org/viewvc/slib/slib/alist.scm?revis...
It does now. The new NimScript .nimble format[1] uses this prefix to determine the name of the package.
1 - https://github.com/nim-lang/nimble#the-new-nimscript-format
Does it? With the type system guiding me if feels like it requires less discipline.
As far as freedom is concerned, I can't offhand think of something I'd want to do but can't in Haskell.
It's easy to add code in most languages, even for unexpected features which were not considered at first place. In Haskell it can be painful to do that.
1 - https://github.com/nim-lang/Nim/issues
2 - irc.freenode.net #nim
Snappy responses to Github Issues, with really clear, really polite responses. Even when I was an idiot.
However, once I started a reasonably sized project, getting Nim to compile it became difficult. Lots of small little quirks that weren't greatly documented.
However, when it did build, it was reasonably fast, and allowed me to tweak the C code when I disagreed with the compiler.
Macros were still getting developed, last I played with Nim, but I'm not sure comparing with Lisp is fair.
I adore Lisp, and its macros. (Both CL style and Scheme).
But most languages are designed to constrain the programmer to a way of thinking, a series of patterns.
Lisp was the opposite.
Even in languages that try to give the programmer flexibility, they miss the power of Lisp's homoiconity.
That being said, I think Nim is trying to find a middle ground between Python's "only one way to do it" and Lisp's "get out of the programmers way".
Its a decent language, albeit with a tiny, rather opinionated, development team.