The Nit Programming Language(nitlanguage.org)
nitlanguage.org
The Nit Programming Language
http://nitlanguage.org/
78 comments
Our Curl module is due for an overhaul. A recent example of the FFI would be the bindings of OpenGL ES 2.0 at https://github.com/privat/nit/blob/master/lib/glesv2/glesv2....
The partial bindings to the Google Cardboard Java API may also be of interest: https://github.com/privat/nit/blob/master/lib/android/cardbo...
The partial bindings to the Google Cardboard Java API may also be of interest: https://github.com/privat/nit/blob/master/lib/android/cardbo...
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
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
> 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.
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.
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.
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!
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.
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.
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.
> 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.
Maybe, but the question is whether they are better off or worse off for it.
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.
lel, of course everyone is going to discuss about the smallest critique I stated. Bikeshedding at its best.
You did lead with that one.
I'm happy with either python-like, lisp-like or c-like syntax, just ban tabs if you use python syntax please.
Regardless of the relative merits of tabs vs spaces, tabs make the most sense _specifically in a Python-like language_.
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.
Also you cannot forbid spaces in code, but you can easily forbid tabs.
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.
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.
Just Seattle. Members of Seattle.rb do a lot of Ruby infrastructure work, and were around before Ruby really blew up in the states.
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...
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...
> 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.
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.
> 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.
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.
> 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.
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.
> 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.
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.
> 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.
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.
> 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.
[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.
"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.
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.
> 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.
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
> 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.
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.
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.
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.
> 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.
Well, I haven't seen real need for neither of them. Both seem to only make things worse, not better.
Exactly. It’s what I commented about super after 8.
You spread your (probably stateful, imperative) logic over several files and classes.
You spread your (probably stateful, imperative) logic over several files and classes.
> 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.
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.
>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.
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.
Don’t you just love some good ol’ Nitpicking …
Clearly an attempt at a better, but still-not-functional Java.
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).
Static typing does not say "a better Ruby" to me, Ruby is extremely dynamic.
I would appreciate if the home page provides the real incentive behind inventing this language. "a robust statically typed programming language where structure is not a pain" is a bit vague and not a unique thing that hasn't been achieved by other existing languages.
My current hunch is something like "let's have a static typed language with Ruby syntax," but I am really not sure.
My current hunch is something like "let's have a static typed language with Ruby syntax," but I am really not sure.
I also find it kind of ironic, because one would think they would achieve structure not being a pain with a solid type system, but it seems to be based on multiple inheritance, with no union types. That's fine and everything, but it's hardly going to win any medals around structuring the resulting programs.
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.
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.
> let's have a static typed language with Ruby syntax
InfraRuby (at http://infraruby.com/live) is a statically typed Ruby compiler: valid InfraRuby programs are valid Ruby programs.
InfraRuby (at http://infraruby.com/live) is a statically typed Ruby compiler: valid InfraRuby programs are valid Ruby programs.
The page only mentions JVM does it also compile to native binaries?
No. You could use a bytecode compiler (Excelsior JET or RoboVM, for example).
Mr. Munroe's comments on competing standards comes to mind. http://xkcd.com/927/
Good lord, this is so tired. I really don't think that Randall Monroe penned that comic so that any time anyone tried something new people could trot it out to poke fun at them for doing so. Please stop.
Examples? Found some.
https://github.com/privat/nit/tree/master/examples
https://github.com/privat/nit/tree/master/examples
http://nitlanguage.org/manual/genericity/
> 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?
That's spooky action at a distance. It breaks modularity, could cause packaging hell.
> 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.
Variance: I suspect it's a subject to similar restrictions as in Haxe: http://haxe.org/manual/type-system-variance.html
> 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.
> 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.
Nope. In is_subtype:
> # 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.
> # 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.
> Nope. In is_subtype [...]
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.
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.
IIUC refinements are module-local so they are modular and don't break anything.
module-local as in, creating a new type that can't be exchanged with the outside? Or converting the value's type on the fly when it gets passed somewhere else? I doubt either would be very usable.
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.
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.
my understanding is that the method call is statically dispatched, and the dispatch is tweaked per module.
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.
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.
It is going to take a lot to convince me that the world needs yet another statically typed OO programming language that looks just like any other.
too many languages to learn...
elixir, nim, golang, clojure, haskell, elm, rust......there is no end...
elixir, nim, golang, clojure, haskell, elm, rust......there is no end...
Do you happen to speak German, Japanese, Mandarin, Spanish and French?
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.
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.
That's utterly wrong comparison! Overall complexity of natural languages is probably HUNDREDS times the one of programming languages. Excluding C++, maybe. And also, with time you begin to be much more efficient in learning languages (that's true for natural languages too!), when it makes no sense really not to learn new languages.
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.
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.
Better than getting a glimpse on (a random, probably hyped-driven) few, is go to the fundamentals and select them paradigmatically.
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)
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)
Just learn the language for the project based on requirements and tooling.
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.
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.
Vala and Haxe are very promising too.
Looks nice. Some ideas are very similar to those of Crystal ( http://crystal-lang.org ) like the automatic type flow. But it seems not to support union types and types are required everywhere (which some might like).
I tried Crystal a while back, found it quite addictive.
chuckles
chuckles
I like that I can start hacking right away after reading the 'not a manual' once.
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.
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.
Glad to see another language that has chosen to avoid NullPointerExceptions. Some of you might take issue with the way it is implemented (special syntax vs general type), but IMO it is still much better than having NPEs.
[deleted]
I was in a class last year, and one of the grad students was working on Nit and gave us a presentation of the language. It was extremely interesting and seemed quite well designed.
As Ph.D student I have had the fortune to work with people who participated in seminal research on elements of the language, and also have met the author in person. These people are truly brilliant and the learning experience has been great.
The documentation in one big PDF:
http://nitlanguage.org/manual/nitreference.pdf
http://nitlanguage.org/manual/nitreference.pdf
Altough I like the idea of writing yourself own language for learning purposes and fun, I don't think it's anyhow better than available toolbox.
seeing < and > html escapes here: http://nitlanguage.org/refinement/
The sales pitch makes it sound like I can have the Java experience without the JVM, with junk like multiple inheritance, using syntax from ALGOL.
Where is the "fun" and "painless" and "bug-free" going to come from?
Where is the "fun" and "painless" and "bug-free" going to come from?
I stopped reading at "object oriented".
And how is this interesting to anyone other than you?
Suit yourself, remain ignorant.
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
[3] https://github.com/privat/nit/tree/master/lib/sdl2
[4] https://github.com/xymus/nit/tree/gammit