The Nit Programming Language
nitlanguage.org
nitlanguage.org
One of the nicest part of Nit in my opinion is their foreign function interface (FFI). It currently supports C and Java out of the box, and Objective-C and C++ are being worked on. I had the chance to work with the FFI a few years ago when it was still a student's master project, and I really had a blast with it. Some librairies such as libcurl[1], curses[2] and sdl[3] were implemented with this FFI.
Another great part of this language is a project being worked on by the same guy that built the FFI, and it's a cross-compiler for mobile applications called Gammit[4]. You write your app in Nit and compile to Java and Objective-C natively for Android and iOS application. The iOS part isn't ready yet, but the Android one is quite advanced with a few great examples such as a small Minecraft clone working with Google Cardboard and having multiplayer functionality.
[1] https://github.com/privat/nit/tree/master/lib/curl
[2] https://github.com/privat/nit/tree/master/lib/curses
The partial bindings to the Google Cardboard Java API may also be of interest: https://github.com/privat/nit/blob/master/lib/android/cardbo...
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
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.
Also you cannot forbid spaces in code, but you can easily forbid tabs.
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.
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.
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...
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.
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.
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.
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.
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.
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.
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.
Well, I haven't seen real need for neither of them. Both seem to only make things worse, not better.
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.
[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.
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
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.
My current hunch is something like "let's have a static typed language with Ruby syntax," but I am really not sure.
Also, redefining classes elsewhere is cool and everything until you lose your IDE, and your productivity drops to 0 because your code isn't indexable by rationality.
InfraRuby (at http://infraruby.com/live) is a statically typed Ruby compiler: valid InfraRuby programs are valid Ruby programs.
> Unlike many object-oriented languages, generic classes in Nit yield a kind of sub-typing. For example, Pair[Int] is a subtype of Pair[Object].
Sounds completely broken. What if Pair[E] is contravariant on E?
class Pair[E]
fun contains(E): Bool
fun clamp(E): Bool
end
That's spooky action at a distance. It breaks modularity, could cause packaging hell.
> That's spooky action at a distance. It breaks modularity, could cause packaging hell.
Swift, Ruby, Nimrod and Smalltalk are a few languages - out of many, many more - which disagree with you here.
> # If `sub` is a formal type, then it is accepted if its bound is accepted https://github.com/privat/nit/blob/2323b17d46c873e8c6c41b75d...
Ruby is dynamic and the interpreter is feature-rich. People are just exercising self-discipline. Nit intends to be “a robust statically typed programming language” which is very different.
Also, could you point me to the Nim feature? All I see is overloading.
Oh, ok. So it does look a bit broken then :)
> Also, could you point me to the Nim feature?
That follows from the fact that `something.method()` is just a syntactic sugar for `method(something)` and that you can write methods for any type anywhere. The example I specifically had in mind was strutils module, which extends a string type with many useful methods.
Now that I think about it I'm not sure how Nim would handle two methods of the same name for the same type defined in different places. I think it would refuse to compile such code? But that's a guess only, I'd need to check.
EDIT: oh, and I see you complained about redefinition specifically, not about the ability to extend classes in general. Sorry, I somehow missed it.
Edit: the page refers to open classes, and I think the idea is that you can redefine methods on Object and have it apply to every object.
So, if I pass a String to your api and you invoke method X it will invoke the one redefined in your module, while outside it stays the same (more like scala implicits than ruby's open classes).
EDIT:
to clarify how I understand this: the authors have basically decided that the module is the element of behavior specialization, and method calls are basically static functions with syntax sugar, and a class is only a data container with some default implementations for the functions.
elixir, nim, golang, clojure, haskell, elm, rust......there is no end...
You don't need to learn all the programming languages, either.
Get a glimpse of a few to discover new ways of thinking, but specialize in a handful only.
Do something in each paradigm: Object Oriented, Functional, Logical.
Non-paradigmatic languages are strange creatures that will hurt the brain for no real good reason (only a epoch-dependent self-serving one)
That being said you don't really need more than a handful languages (selected for their adherence to various paradigms, as my sibling suggest) if you're not interested in inventing your own language.
For example, SQL when required to use databases, Objective-C when coding for iOS, Java on Android, JavaScript on the browser, C on UNIX, ...
Alternatively, take a CS degree in a good university and enjoy up to 5 years of multiple languages, usually one per CS area/paradigm.
On my university we had to program in Pascal, C, C++, Caml Light, Prolog, Java, Smalltalk, Algol, depending on the assignment.
chuckles
I don't like the 'do' - it's either redundant or inconsistent. Why does 'while' get a 'do' but 'if' doesn't?
Or the 'end', especially as it could be a 'while-end' or an 'if-end'.
And 'isa' (what was wrong with 'is')? Blech!
I like that 'var' is an attribute and the 'fun' is a method.
Android support is intriguing.
Maybe this seems like small things and I don't know about what the rest of you are talking about. 'contravariant'? huh?
But it looks cool to me and I don't think you can ever have too many cool things.
for i in [0..width[ do
for j in [0..height[ do
if foo(i, j) then break label outer_loop
# The 'break' breaks the 'for i' loop
end
end label outer_loop
the for loop could be then
∀ x in [0..height[:
if foo(i, j): break outer_loop.
Where is the "fun" and "painless" and "bug-free" going to come from?