It's one of those days ... https://nim-lang.org/blog/2017/05/17/version-0170-released.html
Enjoy! (Yes, all the concepts enhancements made it into this release!)
Yes, all the concepts enhancements made it into this release!
Could you (or Zahary) please give a short overview of the concept improvements in 0.17.0?
Yay!
When can we expect docker image to be updated?
Thanks.
First of all. Congratulations.
But you're spot on, I hope this feature means we can remove method from the language.
If you do, you may consider put some words into documentation what to do to achieve similar behaviour because there is quite a lot of people that are comfortable with that approach.
If you do, you may consider put some words into documentation what to do to achieve similar behaviour because there is quite a lot of people that are comfortable with that approach.
Agreed on documentation. The VTable section of the manual is short, and there's no tutorial. IMO it would make more sense to rework the tutorial part 2 when the feature is ready.
It would be interesting to have some numbers on the use of method. Can you point to some Nim where the multiple dispatch feature is being used in an essential way? I wrote some 'expression problem' type code to test it but I rarely use dynamic dispatch at all in Nim. Are multimethods widely used, like they are in Julia? You can already simulate single dispatch already without using method.
In Spry I use methods a lot, obviously, since Spry is dynamically typed. I think I use multimethods only a tad, for things like plus, minus etc to properly dispatch on combinations of integers and floats. But nothing that you couldn't solve using a bit of conditionals or double dispatch I guess.
Also, I would like for someone to explain what is so bad about methods and how vtable would be so much better - and that is an honest question since I have no idea.
In Spry I use methods a lot, obviously, since Spry is dynamically typed.
Do you mean, you use them whilst coding in Spry, or while coding the Spry interpreter? Certainly in a Smalltalk like language, or in Java, you'll use methods a lot, as there aren't other options.
Also, I would like for someone to explain what is so bad about methods and how vtable would be so much better - and that is an honest question since I have no idea.
It's a great question, and I'd like to see more language design rationale questions like it on this forum. I'm tempted to start a new thread, but the forum software doesn't make that easy, so I'll continue here. If you want to make a discussion another thread may be better?
I don't think methods are 'bad', by 'methods' here, I mean the (implicit) dynamic dispatch/open recursion that makes a language OO. I don't even think that multimethods/multidispatch are bad. My view, not necessarily shared, is that Nim is a language favoring static/compile time techniques, and that there's some kind of inherent tension with baking higher level dynamic capabilities into the language, in particular, multimethods, which impose costs on the rest of the design. I'd prefer minimalism for the OO part of the language; single dispatch and maybe Go-like interfaces. That's a design space already well explored in statically typed, imperative languages.
Ok, sorry, I mistakenly thought it was obvious that I meant that I use methods in the Spry implementation (Spry is written in Nim). But reading what I wrote I can understand it wasn't clear. The original "obviously" was referring to the fact that since Spry code is dynamic it leads to a lot of dynamic dispatch going on in the Spry interpreter - which is basically implemented using Nim methods.
Now, going back to my question - I am aware that Araq don't like methods, although I never really understood exactly why, apart from his dislike for dynamically typed languages in general :). But I presume he wants some kind of dynamic dispatch mechanism be available, and I also presume this new design (which I know nothing about) then solves some problems with methods. But I would like to understand more.
The original "obviously" was referring to the fact that since Spry code is dynamic it leads to a lot of dynamic dispatch going on in the Spry interpreter - which is basically implemented using Nim methods.
You could implement a dynamically type OOPL in a statically typed one without using OO features at all in the implementation. I've implemented little OOPLs in OCaml and I didn't use the object system. I took a quick look at the Spry source code and it looked like mostly single dispatch.
Now, going back to my question - I am aware that Araq don't like methods, although I never really understood exactly why
I can't answer that question, but I imagine as Nim's implementor he understands the costs of supporting method more than most. Every language feature has costs, implementation and otherwise. I imagine that he doesn't think that cost > benefits.
I also presume this new design (which I know nothing about)
This, which @adrianv pointed to. Read it before it disappears :-( There's not much there (which is why I was anxious for an implementation to play with) but from what I gathered concepts could be turned into a (dispatching) Java-like interface using vtref/vtptr.
Also, thanks @dataman, for
Also bitops module (very useful) added.
How did I miss that? Excellent!
Also, thanks @dataman, for
Also bitops module (very useful) added.
Note, bitops module was provided by Mr Parashurama some months ago:
@bpr
You could implement a dynamically type OOPL in a statically typed one without using OO features at all in the implementation.
Definitely, obviously. I could implement Spry in plain C - if I wanted to write C :) But one of the primary ideas in Spry is to try to leverage as much as possible from standing on the shoulders of Nim, like the GC, dispatch etc. The "atom" of Spry is the AST Node and that is represented as a Nim ref object in order to reap the benefits from all the mechanisms Nim offers for ref objects.
I've implemented little OOPLs in OCaml and I didn't use the object system. I took a quick look at the Spry source code and it looked like mostly single dispatch.
Yes, mostly single dispatch.
I have no idea if Araq has any children but I suspect he would leave any legacy for them. I think this is how much he hates inheritance. :D
On my own behalf, I dont care much, selfishly, if it is methods or vtables/interfaces as long as it will support some kind of polymorphism because I have not used it in any serious way yet. I'm just looking forward when Nim to stop being a running target even before starting to learn it thoroughly. Sooner rather than later, I hope.