It's sad to see a relatively new language replicating the mistake that is the class/inheritance model. That plus a lack of modern convenience features like if/else and block expressions leave me struggling to think of who might use this.
In Virgil you can write in a very object-oriented style, or not. There are first class functions, partial application, ADTs, proper type parameters, and so on. Heck, you can write C style with just functions and basic structs if you want; there aren't built-in classes or methods, so nothing forces you into any particular paradigm.
My own style has evolved as I've learned over the years. I use classes less and make them smaller. I use enums and ADTs a lot more these days. But I rarely go whole-hog functional unless it is in tests.
“ Languages are becoming increasingly multi-paradigm. Subtype polymorphism in statically-typed object-oriented languages is being supplemented with parametric polymorphism in the form of generics. Features like first-class functions and lambdas are appearing everywhere. Yet existing languages like Java, C#, C++, D, and Scala seem to accrete ever more complexity when they reach beyond their original paradigm into another; inevitably older features have some rough edges that lead to nonuniformity and pitfalls. Given a fresh start, a new language designer is faced with a daunting array of potential features. Where to start? What is important to get right first, and what can be added later? What features must work together, and what features are orthogonal? We report on our experience with Virgil III, a practical language with a careful balance of classes, functions, tuples and type parameters. Virgil intentionally lacks many advanced features, yet we find its core feature set enables new species of design patterns that bridge multiple paradigms and emulate features not directly supported such as interfaces, abstract data types, ad hoc polymorphism, and variant types. Surprisingly, we find variance for function types and tuple types often replaces the need for other kinds of type variance when libraries are designed in a more functional style.”
> Features like first-class functions and lambdas are appearing everywhere.
Smalltalk the proverbial Object Oriented language already had first-class functions a.k.a lambdas (called BlockClosures in Smalltalk). So it's not like you should choose between OOP-classes OR lambdas. Having them both is better than having just one of them.
Ironically, Smalltalk syntax for lambdas/closures remains my favorite. No “trailing closure” hack that doesn’t scale and looks ambiguous (looking at you swift). No one line limitation (looking at you Python). No ambiguity between function/method bodies and closures (looking at all of you members of the curly brace Algol descendents). No “you have to reference all of the arguments or you can’t use it” (looking at you Elixir).
There were two capital ironies with Smalltalk’s free functions (closures). Smalltalk USED them. It may have been “objects all the way down”, bit they drank closures the whole way. Both the extensive class library and your own code. I coded and invoked more closures in Smalltalk for a given unit of functionality than I have in any other language to date.
What’s even more ironic to me is that closures/functions in most compiled languages are a semantic facade. You see them in your mental model, but the language/library doesn’t model them for you to interact with. In Smalltalk, you could send messages to closures, AND you could add your own.
I have always found it ironic that in Smalltalk, the “only objects ultimate”, I was actually exposed to closures/functional patterns more than I have been in many other systems that supposedly were more about just that.
Right, in a language where "everything is an Object" it only makes sense that closures should be Objects as well, and that you can interact with them by sending messages to them. Then add a little bit of syntactic sugar, to make the code more succinct.
Another innovation of Smalltalk which may not be familiar to everybody is that all control structures in Smalltalk are implemented by passing closure-objects as arguments to methods like ifTrue:ifFalse .
Good point. But that's a technical implementation optimization, which the programmer does not need to be aware of.
It's like saying that functional languages implement tail-recursion as iteration in order to "get rid of" recursion.
But the programmer can still think in terms of recursive calls in their program, and can reason about the correctness of the program by assuming it works by recursion.
I think Python does allow you to play with closure itself by accessing __closure__. Although it is immutable by default, it is still easy to construct another function from code object and closure directly.
I don't know this language but I assume that using the class/inheritance model is optional, like in JavaScript. If you think it helps with your problem domain then use it.
