4 ms·

> Lots of small little quirks that weren't greatly documented. For instance? > But most languages are designed to constrain the programmer to a way of thinkin

by progman 10y ago

> Lots of small little quirks that weren't greatly documented. 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.

shakna 10y ago
> Lots of small little quirks that weren't greatly documented. > 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 https://github.com/nim-lang/nimble/issues/166 [1] Hence why things like this exist: http://docs.python-guide.org/en/latest/writing/structure/ http://docs.python-guide.org/en/latest/writing/structure/ [2] http://cvs.savannah.gnu.org/viewvc/slib/slib/alist.scm?revision=1.6&view=markup&pathrev=MAIN http://cvs.savannah.gnu.org/viewvc/slib/slib/alist.scm?revis...
- dom96 10y ago
  > 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. 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 https://github.com/nim-lang/nimble#the-new-nimscript-format
- qwertyuiop924 10y ago
  As I said last time this argument came up, you can write INTERCAL in any language. And ultimately, and language that tries to make it hard to write bad code (ada, Java, Pascal, etc.) merely walls off one option. There are always other ways to write code badly (frequently, by making it overly baroque. My rule of thumb as to make the code as simple as you can get away with, avoid doing anything obviously stupid, and fix anything that goes wrong. I'm not in industry yet, so I can get away with it).
codygman 10y ago
> Haskell requires an extreme amount of discipline. 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.
- progman 10y ago
  You need a lot of discipline in the overall design of your application so that you can add code and data at any time without messing up the design. 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.

by progman 10y ago

shakna 10y ago

> Lots of small little quirks that weren't greatly documented. > 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 https://github.com/nim-lang/nimble/issues/166 [1] Hence why things like this exist: http://docs.python-guide.org/en/latest/writing/structure/ http://docs.python-guide.org/en/latest/writing/structure/ [2] http://cvs.savannah.gnu.org/viewvc/slib/slib/alist.scm?revision=1.6&view=markup&pathrev=MAIN http://cvs.savannah.gnu.org/viewvc/slib/slib/alist.scm?revis...

dom96 10y ago
> 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. 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 https://github.com/nim-lang/nimble#the-new-nimscript-format
qwertyuiop924 10y ago
As I said last time this argument came up, you can write INTERCAL in any language. And ultimately, and language that tries to make it hard to write bad code (ada, Java, Pascal, etc.) merely walls off one option. There are always other ways to write code badly (frequently, by making it overly baroque. My rule of thumb as to make the code as simple as you can get away with, avoid doing anything obviously stupid, and fix anything that goes wrong. I'm not in industry yet, so I can get away with it).

codygman 10y ago

> Haskell requires an extreme amount of discipline. 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.

progman 10y ago
You need a lot of discipline in the overall design of your application so that you can add code and data at any time without messing up the design. 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.