[Profpatsch]

Here are my thoughts after quickly glancing over the „features“:

1. No formatting rules and verbose „end“

I thought that by now it was universally accepted that having clear rules is a good idea, see Python and golang)

2. OO with inheritance

3. multiple at that

4. Dynamic classes/objects

5. Methods inside the classes

All of these make reasoning about effects very hard/impossible; Interfaces in golang, Multimethods in Clojure, Typeclasses in Haskell, CLOS in CL all provide a better solution to that.

6. Imperative

7. No functional elements (no functions, only methods)

Both mean inherently stateful, which in turn complicates reasoning

8. redef & super

It’s dangerous to have behaviour of single methods spread all over your codebase.

9. nullable

Looks like an interesting idea to eliminate the class of NPE runtime errors, yet it’s a special language (and syntax!) construct. It therefore does not arise out of the type system, but is explicitely built into the type system, so it doesn’t scale. See Haskell’s Maybe type on how to eleminate NPE’s with a small, trivial type that is no more special than any other.

Take it or leave it, these are the things I learned in my study of programming languages. I might be wrong, I might be right, but these are the things that came up as bad design most often in different languages. /me out

[ajuc]

> I thought that by now it was universally accepted that having clear rules is a good idea, see Python and golang)

It is far from being generaly accepted, see Clojure, Scala, Rust, Ruby, ... I'd say more new languages don't follow this than do. And despite general love for Python its most controversial feature is exactly this.

[kibwen]

Rust has had formatting rules in the vein of PEP 8 for years now, and I'm hoping that an automatic rustfmt will emerge sometime between tomorrow's alpha release and the stable release a few months from now.

[steveklabnik]

Yes, we absolutely want a rustfmt. There's just been higher-priority work to do, and some conventions are still settling out. Gotta know what to format to before you can build a formatter!

[mhd]

And the introduction of mandatory fixed formatting for go (in the name of making semicolons optional) wasn't without some opponents either, if I remember correctly, even in that rather obedient fandom.

[baldfat]

After moving from Python and its "clear rules" of having one and only one obvious way of doing things to programming in R.

I like R and the flexibility of have many different ways of doing anything. What you lose you gain with quick evolving libraries and work flows. R is light years past where it was just five years ago and Python is still stuck at trying to go from 2.7 to 3.4. R has gone from R 1983 to a fast adapting language due to the flexibility of how you can do something.

[_pmf_]

> It is far from being generaly accepted, see Clojure, Scala, Rust, Ruby, ... I'd say more new languages don't follow this than do. And despite general love for Python its most controversial feature is exactly this.

Maybe, but the question is whether they are better off or worse off for it.

[kbenson]

No, actually the question was whether it's universally accepted as a good idea. Obviously it isn't (universally accepted). No need to turn this into a discussion of the merits, that's been done here many, many times before.

[Profpatsch]

lel, of course everyone is going to discuss about the smallest critique I stated. Bikeshedding at its best.

[ribs]

You did lead with that one.

[ajuc]

I'm happy with either python-like, lisp-like or c-like syntax, just ban tabs if you use python syntax please.

[kmicklas]

Regardless of the relative merits of tabs vs spaces, tabs make the most sense _specifically in a Python-like language_.

[ajuc]

I don't care about tabs vs spaces, I just don't want to have the "inconsistent identation" problem, and spaces are more fundamental (you can convert arbitrary tabs to spaces, you can't convert arbitrary spaces to tabs).

Also you cannot forbid spaces in code, but you can easily forbid tabs.

[steveklabnik]

Ruby effectively has a standard format, the only significant diverging style is Seattle Style. It's true that there might be some edge cases, but the vast, vast majority of Ruby code looks the same.

[vorg]

Ruby has different styles named after cities, does it? A standard (Tokyo ?) style and a Seattle style? Perhaps we should add the London style, named after Groovy because Groovy's essentially a carbon clone of Ruby except for syntax.

[steveklabnik]

Just Seattle. Members of Seattle.rb do a lot of Ruby infrastructure work, and were around before Ruby really blew up in the states.

[xymus]

I'm a developer on the Nit project, I would like to clarify a few points.

Classes and types are definitely static in Nit. Class refinement is applied at compilation and any ambiguity is reported at that time.

After using this language for a few years, I'm now convinced that class refinement is an improvement to manage preoccupations in projects of any size. It adds an additional layer to the classic object oriented languages. Nit uses classes to encapsulated data only, and modules to separate preoccupations. It saves us from using services classes and instead we can organize our methods in the real receiver of each behavior.

Let's take the example of a game. In module `game_logic`, we define the `Game` class with all the required methods and attributes for the full logic. In another module `graphics`, we reopen `Game` to add the `draw` method and the attributes to store the images. We end up with two modules, one that is simple to read and easy to test, and the other with only graphical preoccupations. We can even use class refinement to apply optimization without complicating the base game logic.

See the Hunted Dino project for an example of such a structure: https://github.com/privat/nit/tree/master/examples/mnit_dino...

[klibertp]

> I might be wrong, I might be right, but these are the things that came up as bad design most often in different languages.

Yes, you are wrong. For every feature you listed and condemned as "bad design" there are examples of languages which implemented this feature in a way that actually makes sense.

What I learned from my study of some 40 PLs to date (I actually started counting and documenting this not long ago, which is why I know the exact number) is that there is no such thing as "bad feature" or "feature that results in bad design". No, even straight "goto" is not such a feature.

You should either list the features of this language and stop at that or describe the design of the language as whole; saying that a language "has multiple inheritance and therefore is [insert anything here]" is simply unfair.

[Profpatsch]

> is that there is no such thing as "bad feature" or "feature that results in bad design". No, even straight "goto" is not such a feature.

Yet, there are features that lead (with a high probability) to bad program code (see goto) Of course it’s always basically the same once a language is turing-complete, so we have to rate languages by how they do certain things.

There is the widely-known term of “code smell” or even “antipattern“, I’m pretty certain such a thing exists for language design, too. I did list those features I found lead to “design smell”.

By the way, comparing penises by writing out numbers w/o any reference is silly at most.

[klibertp]

> Yet, there are features that lead (with a high probability) to bad program code (see goto)

No, I disagree. It's feature usage - or rather misusing it - that leads to "bad code". And that's even before we start talking about what is a "good" or "bad" code, which is OK to discuss on a high-level, but invariably leads to flame wars when it comes to details.

> I’m pretty certain such a thing exists for language design, too.

What I'm saying is that I didn't see this in action, ie. I found no obvious correlation between any single feature and good or bad language design, across all the languages I learned/investigated (EDIT: where the sample size is 40, also see below). Also, saying that a particular language design is "good" or "bad" is utterly meaningless: the only way of judging PL designs is on how well they suit to some purpose. Take a look at J or Forth - these are beautiful designs, yet you probably wouldn't want to use them to code a basic CRUD app.

> comparing penises by writing out numbers w/o any reference is silly at most.

My VPS hosting is dead for some reason, but you can see - incomplete, work in progress - list of those languages here: https://klibert.pl/articles/programming_langs.html (when it comes back EDIT: should be working now).

Also, thanks for assuming so much about my mentality from a simple comment; in reality I'm just happy and excited about my new side project, which happens to be about documenting my experience with various languages and their usefulness in polyglot setting.

[Profpatsch]

> It's feature usage - or rather misusing it - that leads to "bad code".

I still don’t agree with this. There are features that invite misusing them, or pose a greater risk of being misused. For example, with operator overloading developers often leave out some cases, causing possible dangerous behaviour afterwards. Or goto, which has a very big risk of being misused (compare the possible useful cases against the many, many cases where it’s not).

> Also, thanks for assuming so much about my mentality from a simple comment

Indeed, that’s what happens when such a comment is first impression.

[klibertp]

> There are features that invite misusing them, or pose a greater risk of being misused

Of course, that's true! But, depending on a language, including such risky features may be a sign of good design, too. I mean, if 'goto' is that bad a feature, how come it persists in C for so long and shows no signs of going away? Similarly:

> For example, with operator overloading developers often leave out some cases, causing possible dangerous behaviour afterwards

is certainly true, but it doesn't mean that including operator overloading in a language design is a "design smell". Julia users would probably kill anyone who'd try to take operator overloading from them, for example.

Some language features are more risky - in the sense of encouraging misuse - than other; however, mere inclusion (or absence) of a feature says nothing about how good or bad particular language design is. You need to evaluate language design by taking into account all of its features taken together at the very least, and preferably consider them in the context of language goals and intended uses too. Otherwise it's unfair to the language and its creators.

[zak_mc_kracken]

> Looks like an interesting idea to eliminate the class of NPE runtime errors, yet it’s a special language (and syntax!) construct. It therefore does not arise out of the type system, but is explicitely built into the type system, so it doesn’t scale.

[Citation needed]

Groovy, Ceylon and Kotlin prove that this approach has a lot of merits.

> See Haskell’s Maybe type on how to eleminate NPE’s with a small, trivial type that is no more special than any other.

Your claim that `Maybe` solves this better is dubious. Yes, it's nice to have this support emerging naturally from the type system but the downside is that you are now wrapping all your nullable values in monads, and if these values are already monads, you enter monad transformer hell (and it spreads to all the function signatures in your entire code base). Of course, there's also the fact that because all these values are now monads, you can only interact with them through layers of flatMaps, which generate a lot of nested and then unnested values along the way. It's quite inefficient.

The approach used by Nit and the other three languages I gave above is much more lightweight and, in my opinion, a much more reasonable compromise.

[dllthomas]

"if these values are already monads, you enter monad transformer hell (and it spreads to all the function signatures in your entire code base)"

In addition to dragonwriter's objection, this is basically wrong. You can deal with wrapped maybes without touching monad transformers. Further, MaybeT is quite convenient when you have a lot of operatons that may fail, and you want to give up on the chain if they do. It doesn't spread arbitrarily far, though - at any point you can runMaybeT to turn (MaybeT m a) into (m (Maybe a)), for any Monad m.

In general, monad transformers don't propagate crazy far unless they need data that's only available crazy far away.

[dragonwriter]

> Of course, there's also the fact that because all these values are now monads, you can only interact with them through layers of flatMaps

I can easily (and without using any monad specific operations, bind/"flatMap" or otherwise) write a function that interacts with values wrapped in a Maybe monad.

  isJust :: Maybe a -> Bool
  isJust (Just _)  = True
  isJust (Nothing) = False

Of course, I can use monadic operations with any type that is a member of the Monad typeclass, but that doesn't preclude having other alternatives.

[zzzcpan]

> Interfaces in golang ... provide a better solution to that

Hm. What exactly are we talking about here? What problems inheritance and interfaces attempt to solve?

I mostly see abuse and overuse of interfaces in golang. It takes way too much time to understand what's going once you have an interface somewhere. The code starts to feel awfully OOish. You start guessing and assuming things, because you get that virtual thingy and finding what's behind this thingy and where is too much effort, you also have to get out of context. OO programmers have IDEs to help with that, but golang is anti-IDE. As a bonus you get that evil OOish style of manipulating internal state from a whole bunch of different methods that call other methods that change state. I guess they like to follow DRY dogma or whatever. Anyway, I don't see how interfaces are better than OO.

[bunderbunder]

In my experience, implementation inheritance always makes the problems you complain about worse, not better. With implementation inheritance you've got to go and trace a class's entire inheritance hierarchy all the way back to the root if you want to reason about a method's behavior. With interface inheritance the number of implementations you need to look at is always 1.

More generally, interfaces give you a way to provide an absolute minimum in semantic guarantees down toward the root of your inheritance hierarchy. This is critical if you want to follow the Liskov substitution principle. And you should always want to follow LSP.

[zzzcpan]

> With interface inheritance the number of implementations you need to look at is always 1.

Well, I haven't seen real need for neither of them. Both seem to only make things worse, not better.

[Profpatsch]

Exactly. It’s what I commented about super after 8.

You spread your (probably stateful, imperative) logic over several files and classes.

[zzzcpan]

> You spread your (probably stateful, imperative) logic over several files and classes.

It's just as awful in Go code that uses interfaces. State changes are still scattered all over the place. You still have to keep a model of everything in your mind to understand what some method does and what states it changes and what effects those changes have on other methods and so on. My point is: interfaces don't offer noticeable improvements over inheritance.

Building abstractions around state changes instead would be much better way, especially considering that Go supports function literals and closures. But nobody does that :( People prefer to abuse interfaces.

[Gurkenmaster]

>5. Methods inside the classes

Isn't that the point of methods? Or do you mean there is no way to define functions outside of classes?

Yeah that's terrible because redef will encourage you to add them to the class of the first parameter.

[Profpatsch]

Don’t you just love some good ol’ Nitpicking …

[kyllo]

Clearly an attempt at a better, but still-not-functional Java.

[MadcapJake]

Umm this is definitely not an attempt at a better but still-not functional Java. This is an attempt at a better Ruby. Not sure of how much they've really differentiated themselves (performance-wise or feature-wise).

[kyllo]

Static typing does not say "a better Ruby" to me, Ruby is extremely dynamic.