Heh, you beat me to it....
Now there's also a blogpost on the main website: https://nim-lang.org/blog/2021/06/11/nim-conference.html, linking to the conf page.
I am actually extremely curious to know what the other talks will be about!
I recorded my talk without knowing who will be delivering talks and about what... kind of a shot in the dark.
This is definitely building up anticipation, but maybe next year we could organize submissions in different tracks? Like "Libraries/Tools" or "Advanced Usage" or "Nim Internals" etc. etc.
Just an idea... but hey, I like surprises too! šš
Any news about the talk list? It has been few days before the conference if you check how many days left on the website.
Some people take the word "deadline" very fluidly so everything is late.... I hope I'll have more details for all y'all later today.
List of talks and their subjects are up: https://conf.nim-lang.org/
Once again I got beaten in the same thread :)
And now, let us implement monads with Nim ... ehm no. Functional Programming is not in the realms of Nim.
You completely missed the point of "... for everything". It is for everything, not for everybody. If you think you need to use more FP in your program, that's not a domain specific requirement, it's your personal requirement. Nim is not a Haskell (best in class for FP) nor an Eiffel (best in class for OOP).
What do you mean by āimplement monadsā? We have sequtils.flatMap and options.flatMap, what are they missing?
It is not a question that you can implement an evaluation of specific monads in Nim ( or C or whatelse). But monads (categorically generalized) belong to functors, themselves being a generalization of functions. Example :
https://eli.thegreenplace.net/2018/haskell-functions-as-functors-applicatives-and-monads/
We can go further than that: composition of monads can be regarded as compositions of continuations. See :
Nim is Nim (best in class for concise imperative programming).
You are just repeating my argument:
Nim shines if a project has limited, well defined scope from the very beginning
So, again, this is not the question. But there are other things:
imperative spill-offs, e.g. GADTs, module abstraction, inferred/reintroduced generics (like Java generics, like Typescript) are not supported by Nim.
Why do these things have a value? Because they allow bindings with a dynamic environment supported by the type system. Something that e.g. Swift can do - and has to do because of ObjC / Cocoa.
Nim shines if a project has limited, well defined scope from the very beginning
I don't agree. The "scope" of a project is its problem domain.
Why do these things have a value? Because they allow bindings with a dynamic environment supported by the type system. Something that e.g. Swift can do - and has to do because of ObjC / Cocoa. Not to forget Javascript : it began as a prototype (closure) based PL but can behave as a FPL as well.
These features you deem so worthwhile do not expand the range of problem domains that a language can target successfully. They are simply "nice to have", nothing more.
Nobody is claiming that Nim is a perfect programming language.. Just that it's good at what it does.
Nim shines if a project has limited,
"limited" is very subjective here. If Nim's only limitation is not having access to monad in the language I wouldn't say you're "limited", quite the contrary.
Also, you don't need monads, they're just intellectually satisfying solution. Having complex-to-implement solution that you find elegant is not a requirement for a programming language.
well defined scope from the very beginning
Starting a project without a well defined scope is a recipe for disaster anyway.
To be blunt, if you don't know the scope of your project you have more pressing problems than monads and pure functional programming.
Nim is not a Haskell (best in class for FP) nor an Eiffel (best in class for OOP). Nim is Nim (best in class for concise imperative programming).
Nice. Very quotable. Might do well on Twitter...