An Object-Oriented Language for the '20s
adam.nels.onl
adam.nels.onl
Modern C# is already a statically-typed OO language that takes lots of lessons from functional programming and decades of scathing OO criticism (after all it's basically "Java done right"). And of course there's also Scala and F# if you want something more functional than OO.
I think the author summarizes it best at the end: "I realize there's not much need for a language like this—the space is crowded enough as it is—but it's fun to dream.".
Backend engineers seem unaware of the problems async/await solves.
The right approach is what JavaFX or Swing do: make it easy to schedule a lambda onto the UI thread from any background thread. Whilst that lambda executes, events are not dispatched. Where things get painful is where you try to make a single chunk of code look blocking whilst it's actually not. The user can insert arbitrary events into the middle of your code the moment you do an 'await' and you have to plan for that.
In practice, I've not found the typical UI toolkit paradigm to ever be a problem. If your UI starts to stutter, it's time to move something to a background thread. It forces you to admit that the UI and work are genuinely running in parallel and consider cancellation semantics, work/results handoff, etc. And of course you properly use multi-core systems.
Async/await solves the problem of posting execution to another thread, getting a result, and easily and efficiently waiting for that result on exactly the thread you need.
It'll be interesting when or if someone uses Loom in the UI space.
Async/await in the browser at least is unrelated to threading (unless you mean hypothetical helper threads inside the browser). You don't get any choice about where the handle the callback. It's always on the single rendering thread.
And you are forgetting the ML -> F# / Scala part.
Also despite all its high and lows, the .NET story regarding desktop frameworks is much better than Swing/JavaFX, and whatever Google has butchered Java with.
However I have never been a X Developer, I always have used both at my employers since they exist, alongside C++, depending on the project and customer requirements.
Java and .NET are still catching up to what it offered in 2000.
Sadly it never got a big name sponsor to push it.
So for C it was ok, but for OCaml a reason not to use the language.
It makes it slower to approach than curly brace languages or even lisps, but once you learn it, it’s a secret weapon of conciseness.
Has Eiffel had a high-quality open source implementation? My recollection is that Eiffel Studio's software is proprietary and expensive.
> If you wish to earn a commercial benefit from your application and not release its source code, you must purchase the number of licenses you need for your development from Eiffel Software. After you purchase licenses, you are free to use and distribute your application the way you want (see the end user license agreement).
> If you select the Open Source license, you must release your development under an Open Source license for the benefit of the community at large.
So I'm still confused about the licensing. For the open source license, is a GPL runtime embedded in the compiled program or something?
Back in the day, MySQL had a license like that.
It still should be fine for free software development.
As much as I like the open source encouragement, this is no way to inspire industry-wide adoption.
Are there are free tools for becoming a mechanic? No, they got to be paid, either new or used in some form.
And yes, nowadays there is a community version for the free beer crowd.
When it comes to adoption, an area where Eiffel has clearly lagged, the availability of implementations can't be an afterthought; not when you have good, free implementations for Python, Ruby, Go, Rust, Julia, and many more.
Objective-C and Swift are interesting languages that are held back by the fact that the best environment is Xcode on a Mac. Similarly, Qt has been plagued by license anxiety for years (first the QPL, and now the delayed LGPL releases). Therefore, I would say that one of the "obvious, non-negotiable things any new OO language should have," to quote the article, is a good open source implementation.
Even UNIX's license had to be paid in some form, although symbolic.
We are speaking about the adoption of languages, though ("Sadly it never got a big name sponsor to push it."), not languages in abstracto, and for that available implementations matter.
>Are there are free tools for becoming a mechanic? No, they got to be paid, either new or used in some form
Which is neither here, nor there. Things are different for programmers, where there are free and/or libre tools, and people have come to expect them and even prefer them.
I will love to see the world where such programmers get paid 100% the same way they are willing to pay for their tooling.
Exactly the same way.
Yeah, but not for Eiffel :-)
>I will love to see the world where such programmers get paid 100% the same way they are willing to pay for their tooling.
Aside from those language devs getting paid (which core dev teams for otherwise given for fre/ FOSS languages like Java, C#, Swift, Go, etc also are), what else would change?
Paid/proprietary is orthogonal to better languages/tooling. If popular compilers/apis were paid, we could just as well get the same commercial crap, lack of interest, bloat, needless novelty, etc. that we get with most paid proprietary software and hardware.
And even worse, since they would be both out of reach for amateurs/students/developing world/etc, and crappy "enterprise level" for the rest, driven by what sells to pointy hair bosses, not programmers.
But if there were widely available free tools for mechanics, the people making paid ones would have a lot of difficulty getting mechanics to pay for them.
They should repair my car for free as well.
Feeling happy that someone left the garage with a working car is a good enough reward.
Meyer's book where pretty highly ranked in the canon of OOD, so at least a few people knew the language from there. But similar things could be said about Smalltalk. Eiffel was a bit in a weird place, though. C++ and later Java ate a lot of its customers, it didn't enter a smaller niche like Delphi and on the safe & secure side, you had Ada.
Doesn't Meyer now have the professorship that Wirth had before? Apparently the place for the Cassandras of programming language design.
C# with monads would be great.
public readonly struct Option<T>
{
public static readonly Option<T> NONE = new Option<T>();
//
public T Value { get; }
public bool HasValue { get; }
public Option(T value)
{
Value = value;
HasValue = value is { };
}
public Option<TR> Select<TR>(Func<T, TR> selector) => HasValue ? new Option<TR>(selector(Value)) : Option<TR>.NONE;
public Option<TR> SelectMany<TR>(Func<T, Option<TR>> selector) => HasValue ? selector(Value) : Option<TR>.NONE;
public T OrElse(T defValue = default) => HasValue ? Value : defValue;
}
If you just need some ready-made monads, language-ext is the way to go: https://github.com/louthy/language-ext
We tried to bring some functional ideas into our Unity3D codebase with help of these resources, it's hard but doable.
C# 1.0 was based on Java 1.3 and modern C# has inherited a lot of its warts and added some of its own, like delegates and events.
Though nowadays I think maybe language support for monadic Result<T, X> is the way to go.
Really, error types are only a small step above what C uses. That approach was tossed in favour of exceptions for good reasons that the industry now seems to be collectively forgetting, often with poorly reasoned arguments. FP languages like Haskell use them as if they were C because of laziness and insistence that everything be modelled as a mathematical function, not because they result in a better developer experience. Exceptions have many usability benefits that I'd be loathe to give up on.
Why?
> Really, error types are only a small step above what C uses. That approach was tossed in favour of exceptions for good reasons that the industry now seems to be collectively forgetting, often with poorly reasoned arguments.
Your assertion makes no sense at all. Exceptions were designed with the explicit goal of brushing potentially unrecoverable exceptional errors under the rug. This is by no means the only use for return values. Take, for instance, HTTP requests, and the whole classes of different results that can be returned and how they are completely orthogonal to the data being returned. It would make no sense to handle this usecases with exceptions.
Another thing that it seems you're entirely missing is that using a Result monad to express results allows you to explicitly discretize and define the codomain if your function, and through dimensions that help you reason and thus test about the input and output of any function.
Using monad semantics to handle return types also provides a convenient way to implement what is often referred to as railway-orientrd programming
That's what I meant by poorly reasoned arguments. Do you really think the designers of C++, Java, C#, Delphi etc all sat around and explicitly said to themselves "how can we brush errors under the rug"? Of course they didn't. They didn't even imply it, let alone state it explicitly, so that whole argument is just nonsense. They all argued, quite explicitly, that exceptions are a better way to handle errors than C style error codes. And their arguments were correct.
Using monad semantics to handle return types also provides a convenient way to implement what is often referred to as railway-orientrd programming
Again, this is what I mean by poorly reasoned arguments. "Railway oriented programming" is something FP languages made up to try and get closer to how imperative languages work, it's not something that's useful if you're already in an imperative language, exactly because exceptions already give you that and a lot more in addition.
Exceptions give the imperative programmer a lot of highly useful features:
1. Errors can be handled at the appropriate layer of the program, instead of all pieces of code having to be polluted with boilerplate propagation logic. Yes you have that problem even in FP languages. The right place to handle most errors is often at the outermost loop of your application or server, by logging it and discarding that unit of work or returning a description of the error to the user.
2. Exceptions come with stack traces and structured data about the error. I've often been able to fix bugs by just looking at the stack trace and nothing else. Error types usually don't have this information.
3. Exceptions can be abstracted without losing information, when chaining is used (as in Java). You can catch an error, rethrow it as a type appropriate for the abstraction level of your library, and do so without losing the original exception. Error types almost never have this kind of functionality.
4. Because exceptions are by definition exceptional, the compiler can safely assume those paths will rarely be taken and optimise accordingly. Error handling code can be moved entirely off the hot paths and out of the i-cache. Error types on the other hand are opaque to the compiler and result in branching everywhere, which hits performance.
5. When writing code that doesn't actually need to programmatically handle all possible errors e.g. prototypes, quick one-off tools you're writing for yourself, you can just let errors propagate to the top of your program and be handled automatically. You don't need to be constantly unwrapping Result/Either types, or propagating them, or handling them. You can just forget about it and still have useful diagnostics if something goes wrong. With error types, you either do the work by hand or you lose all insight into errors that doesn't make it into logs.
By all means, try and convince people that giving up all these features lets them "discretize and define the codomain of your function" and that this somehow substitutes for the pain of only using error types. It'll just make them slower than I am.
Checked exceptions were introduced by CLU, adopted by Modula-3 and C++, two big influences in Java design.
"obvious, non-negotiable things any new OO language should have":
> No nulls
C# has null. It looks like after C# 8.0 there is a way to require annotating types are nullable. But it isn't as elegant as a true Option type, and looks like there may still be some gotchas.
> No unsafe cast
It isn't entirely clear what is meant by "unsafe", but casts in C# can throw an exception if the type doesn't match at runtime, which I suspect fails to meat the criteria here.
> Optional named arguments
C# has this
> Generics
C# has generics, and while I don't have a whole lot of experience with it, it seems pretty good.
> Immutability by default
Fields and variables in C# are mutable by default (but can be marked as immutable with `readonly`).
"less obvious choices":
> Class based discoverability
I think C# has this
> Multiple inheritance
C# does not have multiple inheritance. However default interface methods give some of the benefits.
> Minimal syntax
I'm not entirely sure what is meant by this, but from the comparison with scala, I think C# satisfies this.
> Higher kinded types
AFAICT, C# does not currently have Higher kinded types
> No Exceptions
C# definitely has exceptions
> Unified classes and Typeclasses
C# doesn't have an equivalent of typeclasses. In part because of the absence of higher kinded types (see above).
> Pattern matching without destructuring
C# switch statements do this.
So, C# has some of what the author is looking for, but is also missing a lot. Yes, C# did take some inspiration from functional languages. Yes it did learn from some of the mistakes of earlier OO languages (notably Java). But C# is itself over a decade old and constrained by backwards compatibility. If it had been created today, would probably be substantially different.
Disclaimer: I haven't used C# very much, so this is mostly from what I remember when I learned C# years ago, and what I was able to find with simple searches online.
impl Drawable for MyEntity
void Draw(MyEntity self, Canvas...
class MyEntity {
EntityDrawingComponent drawer
EntityMovingComponent mover;
class MyEntity : Drawable, Movable, ...
void Move(Vec..)
void Draw(Canvas..)
In general, if I were to design a "better" OO language now; i'd make sure to make it almost not OO at all. I'd allow subclass polymorphism, but no virtual methods or classes. Only interfaces/traits and abstract classes. I'd very clearly separate data types from identity types at the language level (which aren't just a difference betweeen stack and heap as with C# structs and classes).
I'd want the bare minimum of functional niceness: enumerations and pattern matching which check for exhaustion. Having that in a lanugage easily lets the developer use different implementation for two completely different cases: open and closed polymorphism sets. OO is great when you don't know what variants might exist, but it's useless when you DO want to control it. If I as a developer know that the set of Payment options are Credit/Cash/Invoice - then I want it exhaustively checked. I deliberatel do not want to leave that open. I want to be able to switch on the closed set of 3 cases, and be warned if I fail to check a case. I want to be able to do this without inverting the logic like and calling into the unknown like paymentMethod.HandlePayment(order).
Few of the things I use inheritance or composition for can be implemented without storing some extra data.
As an example, say a buffered Stream, that takes a Stream instance and adds buffered access. This BufferedStream would need to store the buffer data somewhere.
I was just curious what OP was using these traits for, as in my non-Rust experience seldom have the need to compose stuff without storing additional data.
[1]: https://doc.rust-lang.org/src/std/io/buffered/bufwriter.rs.h...
struct MyEntity {
cache: RenderingCache,
}
impl Drawable for MyEntity {
fn draw(&self, canvas: &mut Canvas) {
self.cache.draw_cached(canvas, |cache_canvas| {
cache_canvas.render(ASSET);
});
}
}
const ASSET: Asset = load_asset("foo.png");Think Rust differs enough that it's a bit hard for me to draw direct comparisons with my primary languages, but with the emphasis on interfaces like that it does seem like a nicer way to implement extension methods.
If you know haskell, Rust's traits are very similar to type classes, except it also has c++-like generics (templates) and is primarily expression-based like ocaml.
traits vs haskell type classes:
trait -> class struct -> data instance -> impl
class MyEntity {
RenderingCache cache;
}
now MyEntity implements Drawable {
void draw(Canvas canvas) {
this.cache.draw_cached(canvas ...);
}
}Nitpick: C# struct can be on the heap (when it's "boxed").
The fundamental difference between C# class and struct is how they treat assignment operation. The class has "reference semantics" (assignment creates a new reference to the same object) and struct has "value semantics" (assignment creates a new object).
C# uses terms "reference types" (of which "class" is one) and "value types" (of which "struct" is one) to make the difference clear.
Structs being on the stack (most of the time) is just a consequence of their value semantics, and should be treated mostly as an implementation detail.
I’d like my language to be extremely explicit about whether an object has identity or not. It ties into things like ownership, move vs. copy, disposal etc too.
class DrawSystem{
Draw(DrawComponent)
}
Or you can put the DrawComponents on the Draw system and simply track mapping back to the MyEntity instance they correspond to. New code lives in the systems.
In a game you'd have some kind of scene system that could track what entity has what components and then you don't even need a MyEntity class at all. You wouldn't track that composition in a class.
The sugar that Rust is bringing is that it feels like the implementation is being added to the instance instead of an external system outside it, but you can make that work in C# with some extension methods. It would be nicer if/when C# gets extension interfaces.
The disconnect I think is that part of the ECS design is that you have the freedom to break that guarantee. Entities are no longer types but collections of components. The soft coupling is the goal.
I think you mean "class oriented"
Then it might be interesting for you that Rust copied this (like a few other things) from Haskell, where they are (somewhat confusingly) called type classes.
Well, that's like your opinion, man ...
Both Google and DuckDuckGo give me no results so an example would be appreciated.
(Hope I'm not caught up in a prototype joke :)
They don't have the proper expertise and will break something, because it's not possible to enforce data consistency well enough. (Apple's modern OO database is called CoreData, has a pedigree from WebObjects, and its consistency features are pretty hard to use in practice.)
The only connection to editing someone else's data was the ability to add fields to soups for things like Contacts which allowed an easy expansion. Given how many programs on UNIX can alter each other's data, I don't agree with Conway in the context of the file system or soup.
If you like Ruby and wish it had types, check out Crystal. It's basically Ruby with Go's concurrency model, and it's as fast as Go.
{Edit: repetition}
The author says there should be no Exceptions and there should be multiple inheritance... I mean, these seem like pretty extreme positions to have when talking about an OO language... if I remember correctly, multiple inheritance, in particular, was one of the features the languages from the late 90's had actually stayed clear of as it had been shown by the previous generation of languages that it was a mostly bad idea. I think even inheritance as done in Java is not the best of ideas, and there seems to be evidence extension methods or, similarly, type classes, are better suited to add behaviour to data structures.
IMO languages like Kotlin and Swift are much more like what modern OOP languages should be than what the author proposes.
My personal take is that implementation inheritance is a bad idea, and, by extension, Object Oriented programming is a dead end.
In Kotlin extension methods are best used as a nice way to add utility methods to code you don't directly control, and as part of the 'extension lambda' system that lets you make DSLs. The way Kotlin defines language integration features using methods with magic names makes it easy to add a thin layer on top of a Java API that makes it much nicer to use, without needing to fork or patch the actual library itself.
It has not solved the “minimum set of primitives that make OO tenable” problem.
C++ is likely the worst OO language in common usage and C++ developers rightfully avoid using its native OO functionality as much as possible. They will literally jump through hoops and write tons of additional boilerplate code to avoid exposing the language's OO functionality (doing what C++ developers call type-erasure).
C++11 didn't improve OO in C++, it gave programmers many features to avoid having to use it altogether.
Common C++ libraries like boost have an entire library dedicated to type erasure:
https://www.boost.org/doc/libs/1_75_0/doc/html/boost_typeera...
Facebook's Folly library also provides type erasure functionality:
https://github.com/facebook/folly/blob/master/folly/docs/Pol...
Google's Abseil is full of type erasure:
Here is Adobe's C++ library for type erasure:
https://stlab.adobe.com/group__poly__related.html
And here's a talk by Sean Parent about how Adobe uses type erasure to emulate runtime polymorphism without using C++'s native OO features:
https://www.youtube.com/watch?v=QGcVXgEVMJg
I suppose these are just some people somewhere...
classes, polymorphism, some level of inheritance, delegation, composition, builders, method dispatch, ....
What they are doing is implementing an ad-hoc version of OOP that forgoes using C++'s native OO feature-set. Native C++ OO clashes with modern C++, often creating a dialect that does not play well with resource management and common C++ idioms.
The type erasure libraries provide many of the traditional benefits of OO but allow you to retain value semantics (which native C++ OO does not).
My argument was never about OO as a general concept, it was strictly that C++'s native OO feature set is very poor and modern C++ allows developers to move away from that feature set.
To humor you... if I have a base class of type Animal and a derived class of type Cat, then making a copy of a Cat through a pointer or reference to an Animal results in object slicing which is not what you expect when you make a copy of a polymorphic object. Basically you only end up copying the Animal instead of the entire Cat.
https://en.wikipedia.org/wiki/Object_slicing
One of the motivating reasons to use type erasure is precisely to solve this issue, so that one can copy an Animal or assign Animals and treat an Animal as a value and copies work as expected.
When one copies a std::function or any of the type erased classes provided by the standard library, it just works as expected, without needing to consider lifetime issues, object slicing, C++'s complex rules about inheritance vs. virtual inheritance, and a host of other problems that don't mix well with other parts of the language.
The cost of type erasure is that it requires a lot more work on the part of the author. The libraries I linked to help alleviate most of the boilerplate, but as the examples demonstrate, there's still a lot of work that needs to be done to get it right.
First: I've done professional C++ development since 1996. Fulltime, with just a smidgen of Java in a couple of places. So your guess is completely mistaken, as is your opinion of where I'm coming from.
Second: The post I replied to never mentioned "polymorphic", so I interpreted "value" as your claiming that you couldn't treat a pre-C++11 class as a value type, which is clearly a bogus claim.
I do mostly embedded systems. I do use polymorphism, but most of my objects cannot be cloned (private, unimplmented copy constructor and assignment operator), and the only collection they live in is a fixed-sized array.
If I had to do your Cat example, I'd probably have Animal's copy constructor call a protected pure virtual clone() method. I understand the slicing problem, and that a slice is not what you want.
I confess that I don't understand how type erasure helps with the copying problem, nor how std::function uses type erasure.
>private, unimplmented copy constructor and assignment operator
If you're using C++11 or better, then avoid doing that. In modern C++ you declare those as deleted.
>If I had to do your Cat example, I'd probably have Animal's copy constructor call a protected pure virtual clone() method.
This would do absolutely nothing and once again, despite you claiming to have 25 years of professional experience in C++, I must shake my head to even hear such a thing.
All I get from this conversation is that you have a very antiquated idea of how to use C++ and have not kept up to date with modern standards. You mention the rule of 3, which is a pre-C++11 idiom and superseded by the rule of 5 with the advent of move constructors (or the rule of 0). Yet despite this you felt it appropriate to claim that since you personally have never encountered any recent advancement in C++ in the past decade, that it must be me who is distorting the situation.
It could not possibly be the case that the C++ of today is much different from the C++ back in 1996 when you started using it, nor could it possibly be that using C++ for embedded development represents only a tiny subset of how C++ is used, or that maybe you just aren't familiar with something because no one is an expert in everything and we have to prioritize what we spend our time learning. No... the conclusion you chose to go with is that I'm distorting reality because you happen to lack any modern knowledge about a technology that you claim to have 25 years of experience with.
Hate to break it to you... but it's not the 90s anymore.
I think there’s room for kitchen sink languages and also opinionated, minimalist languages.
Big if there. Most people do not mean Kays OO when they say OO.
I would suggest that if you asked people to define the term, Kay’s definition would likely be the single most common (even after normalizing variations in wording).
It would still only be a plurality, sure, but the remaining majority doesn't share a common understanding, either.
An example would be non-fragile ABIs (ObjC has this, C++ doesn't) or typestate/built in state machines (so you can't call methods if the object is in an invalid state for them). There's encapsulation at least, it's a start.
Fragile ABI is basically a C++ problem. Java has had a stable OO ABI for 25 years now. The .NET ABI has gone through a few iterations, but is stable now. Of course Microsoft also had COM, which is/was a stable OO ABI accessible to many languages including C++ and was arguably just a subset of the C++ ABI without templates.
In the AOT compiled work Swift now has a stable OO ABI (sort of). Rust is interested in getting one. Lack of a stable ABI is not an OO problem but more a problem of languages that are designed to compile ahead of time to native code and use native formats as their primary artifact format.
Most features OO has reduce complexity and bugs, that's why people use them. There's no comparison between a clean OO API and the de-facto standard state before that, e.g. POSIX, Win32, Carbon.
Why the past tense, when COM is the main way Windows APIs have been introduced since Windows Vista, as COM took over Longhorn OO ABI ideas?
Nowadays we just call it WinRT.
I haven't kept up much with Windows programming so lost track at some point of what their current-gen tech is and how it works. WinRT isn't just COM is it. It's custom languages, new app metadata formats and stuff. I don't see IUnknown in any modern Windows code samples.
C++ is more of a multi paradigm language where the designers (eg Alexandrescu) actually publish books telling you to focus on algorithms and generic programming rather than object trees. KDE/Qt reinvent messaging on top of the default OO, don’t they? There’s something about slots.
> There's no comparison between a clean OO API and the de-facto standard state before that, e.g. POSIX, Win32, Carbon.
Don’t know about Windows but POSIX and Carbon were as OO as they needed to be - a function where the first parameter is a “file” or “context” is being object oriented. There were actually several attempts to replace Carbon with more OO APIs, that used heavy implementation inheritance, like Taligent and MacApp and they failed because they were too complicated. Cocoa succeeded by using messaging and composition instead like Alan Kay wanted.
Don’t know about Windows but POSIX and Carbon were as OO as they needed to be - a function where the first parameter is a “file” or “context” is being object oriented.
Honestly I don't know of anyone, including the people who defined those APIs, who would call them object oriented. POSIX functions aren't even namespaced and routinely don't even take a struct as the first parameter. Implicit state is everywhere in POSIX, Win32 and I think also Carbon.
Cocoa succeeded by using messaging and composition instead like Alan Kay wanted.
Cocoa "succeeded" by being the official API of the first non-failed attempt at resurrecting macOS. On Windows, the API that "succeeded" was .NET which is a classical C++ type of OO. In practice, Objective-C caused a lot of problems for Apple. They would have junked it years earlier but Steve Jobs was wedded to it and couldn't understand why anyone wanted anything else. The moment Jobs died Swift was started as a project, and Swift does not have objc_msgSend at its centre, at least not if I understood the Swift ABI correctly.
The "messaging" concept caused problems in the following ways:
* Performance, despite objc message sending being heavily optimised.
* Bizarre semantics that led directly to horrible bugs, like sending a message to null being "valid" but returning junk if the return value was meant to be a struct.
* Difficult to optimise due to the dynamic language features, which are nonetheless hardly used (e.g. ability to redefine methods on the fly).
The latter problem is shared with languages like Ruby.
There's (at least) a third model IMO from CLOS & friends, such as Dylan, S4, and I'd argue Haskell Typeclasses. Not sure what I'd call it but it's the idea where you define data classes, generic functions, and then provide linkages between those data classes and the generic functions to give you methods on the state
Actually, if not for some historical accidents, we could have Dylan in place of Java today... I sometimes dream about such a world: functional core, CLOS-like generic functions and multimethods, sane multiple inheritance, syntax-case-like macros, native AOT compiler, sane module system... OpenDylan - the implementation I played with - is slow as molasses, but with even a tiny fraction of the work put into Java it could be made fast enough to rival C++. It's one of the most striking wasted chances in the history of programming.
Edited to add: Kay also frequently says he's a proponent of object oriented, not class oriented programming. Classes are just a means of organizing the code, objects and their relationships is what matters. In that way, modules in Elixir are not inferior to classes in single-inheritance OO languages: they offer the same level of sharing and composing code (via macros, defoverridable, and defdelegate). Add to it protocols, which can extend arbitrary types (modules) and you get quite nice OO toolbox to use in Elixir.
One source: https://hillelwayne.com/post/alan-kay/
Still, the definition Kay gave as late as in 1998 resonates with me the most:
OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.
And this is almost exactly what Erlang implements: just add "asynchronous" before "messaging" and it fits perfectly.
- Main abstraction are classes (of objects).
- Concept of self-initializing data/procedure objects Internal ("concrete") view of an object vs an external ("abstract")
- Differentiated between object instances and the class
- Class/subclass facility made it possible to define generalized object classes, which could be specialized by defining subclasses containing additional declared properties
- Different subclasses could contain different virtual procedure declarations
- Domain specific language dialects
As that article clearly shows, at least once you’re past its clickbait title, Kay acknowledges his influences. That isn’t a lack of clarity, it’s an awareness that we all build on the effort of our peers and predecessors, that ideas do not spring forth fully formed from the void.
This does not discredit anyone’s work, far from it; context is an aid to understanding.
What I mean by lack of clarity is that Kay in 1998 thinks that messaging is the key idea, and suggests that was always the key idea. But none of the historical sources I've seen suggest he was clearly and consistently saying that in the 70s.
That's really a minor point, it does nothing to invalidate Kay's contributions. You can design a system that has value, and only later find the best way to talk about its value. That happens constantly: people create something and then end up saying "in hindsight, I got X right and Y wrong" or "back then, I knew this worked, but it was only later that I knew why".
It doesn't disprove the idea that focusing on messaging gives you the best version of OOP. It doesn't even disprove that "real" OOP is about messaging (though I think that argument has a high bar to clear--most terms are messy).
What it does disprove is that messaging has a right to be the core of OOP because Alan Kay defined it that way back in the 70s.
P.S. Maybe the title isn't ideal, but Hillel was literally reacting to someone who said Alan Kay invented objects: https://lobste.rs/s/8yohqt/alan_kay_oo_programming#c_5xo7on. Actually, that might be a better source than what I linked to, because it marshals more evidence that Kay was not consistently saying "messaging is what matters" during the 70s. He may have believed it, he may have said it sometimes, but he wasn't consistent about it.
Again, that's not a criticism of Kay, except the super mild one that his 90s/2000s memory of what he said 20 years earlier wasn't perfect. But I forget shit I said last week, so I'm not gonna judge.
Well, I think "messaging" is an abstract concept. It doesn't have rights, so there was nothing to prove.
Nevertheless, credit matters, because people matter, and do have rights. One of those rights is to have an opinion, including the opinion that messaging is the core of OOP.
> clearly and consistently saying that in the 70s
This is indeed a preposterous and unhealthy standard to expect of anyone, on any topic. It's the kind of thing that two-bit politicians like to dig up on each other, to nobody's edification.
We agree. No idea how I screwed up that sentence. The intent was "that messaging is the right core of OOP because", but it was awkward, and I spliced something together.
> It's the kind of thing that two-bit politicians like to dig up on each other, to nobody's edification.
This is a discussion of what a word means, not an attack on someone's character.
you can find his various comments here: https://news.ycombinator.com/threads?id=alankay
PS: I admit I lost the author at "scala is my favourite language" and so am biased.
Elixir looks like the more promising approach. I love its pipe forwarding operator.
The JVM runtime is a runtime. BEAM/OTP/ERTS is a full fledged collection of middleware, libraries, and tools written into/as apart of the Erlang programming language. You can not separate one form the other.
Pascal doesn't have the kingdom of nouns problem. It supports good old fashioned procedures and functions.
Pascal can deal with nulls in strings, because we always know how long they are.
Or perhaps you meant null pointers. Pascal avoids unnecessary pointers, but supports them in a sane manner when you need them.
Pascal can deal with multiple inheritance in a sane manner, by composition. Objects can have other objects as properties, and it just works... no weird restructuring of everything horror stories I've heard about in C++, etc.
Free Pascal has generics there are libraries that let you do dictionaries and lists and trees of your type <T>.
I disagree about exceptions... proper handling of exceptions is a good thing. A function should always return the type you expect, not some weird value you have to test for.
As far as "pattern matching" I assumed you were talking about regex (which can be addressed in a library)... but you're talking about RTTI, or "reflection" where you can get type information at runtime, which is a thing in Pascal and many other languages.
I don't understand the obsession with immutable variables.
[Edit: I think I understand... in Pascal, parameters are passed by value as the default, but can be passed by reference, it depends on how you declare the function or procedure. It has nothing to do with variables that you can't assign new values to, if I'm correct]
Did I miss anything?
Exceptions are an invisible, out-of-band mechanism that will crash your program because you forgot yet another try...catch. Sum types with pattern matching are a much better approach for writing safe and robust code.
The “proper handling of exceptions” panacea I keep hearing about sounds a lot like “OOP done right”... it’s supposed to exist, yet no one seems to know what it actually is.
Any way of dealing with errors has to be out of band, we just disagree on the mechanism.
But just for the sake of argument, the type of 'sqrt' isn't:
sqrt : R -> R
sqrt : R+ -> R+
But either way no, you only need an "out of band" mechanism when the type system isn't strong enough or isn't being properly leveraged.
In my opinion it is far better to throw an exception that can be explicitly handled, rather than cause some math error at some random point later because NaN or some infinity snuck by as a number.
But again for the sake of argument, the return type of tan() could be "Either<Error, double>".
In Pascal tan(pi/2) or tan(3pi/2) causes an overflow. The way to deal with that is out of band, to handle an exception of type E_Overflow.
There is no type change. The function "tan" would return a value of type "Either<Error, double>". An expression such as:
double x = Math.tan(Math.PI / 8)
It would be the responsibility of the caller to prove to the type system that the error has been handled, with either a built-in language facility a la ML, or with ad-hoc code such as a Bohm-Berarducci construction.
Let's just agree to disagree.
Compilers can find all sorts of things they couldn't in the past, which is amazing.
What happens at run-time if an overflow happens?
again... I'm sorry if I didn't express myself clearly enough. I'm coming at this from a Pascal programmers perspective... I've missed the past 20 years of compiler improvements.
pub enum Result<T, E> {
Ok(T),
Err(E),
}
https://play.rust-lang.org/?version=stable&mode=debug&editio...
I'm not entirely sure what you're asking about regarding runtime behaviour, but here's two guesses.
As a user of a function that returns a Result type, at runtime the function returns a result that has a flag and a payload, where the flag specifies whether the payload is your value or an error. The only ways to get a value out of the result are either to check the flag and handle both possibilities, or to check it and crash the program if it's an error.
As someone writing a function that returns a result type, you write whatever logic you need to determine whether you've successfully produced a value, or which error you've produced, and then you either return(Ok(my_value)); or return(Err(my_error));. If you're doing floating point math, this might be checking an overflow flag, or looking at your inputs, or checking for NaN after operating, or whatever makes sense for your task.
Using a variant/product/discriminated union like this is orthogonal to the details of floating point operations at runtime. What it lets you do is have the compiler enforce that users of your function must check for errors, as it's a type error to assign a Result<f64,E> to a variable of type f64.
I hope that helps! Do you have any more questions about this, or things I didn't address, or topics where you'd like more explanation or examples?
In my experience, proper exception handling is more difficult than advanced topics like lock free data structures, with the disadvantage that junior programmers have been taught to use exceptions and avoid lock free primitives.
Checked exceptions solve this problem. Checked exceptions vs. result sum types aren’t a black and white dichotomy, however. They are rather two points on a design spectrum, where one design axis is how you want to syntactically handle error escalation up the call chain, another axis is how you want to handle destructuring/restructuring of the results, etc.
Unchecked exceptions are still useful for notifying bugs (e.g. precondition violations) instead of aborting the OS process on failed assertions.
Out-of-band is the point. It lets you write your code for the correct path, without having to explicitly string a bunch of error types along (or do something annoying like mandating all errors are of type Error, which is a string).
The problem is with invisibility, which is the case with most exception-using languages. Java had it solved right, though, with checked exceptions. Of course back in the 2000s we were a bunch of lazy children and said "checked exceptions are bad because they make us declare stuff up front", which was actually a good thing, but we couldn't understand that, so they became optional in Java.
(On the other hand, exception handling is just a poor shard of proper condition system, like in Common Lisp.)
try
foo()
catch ExceptionX
...handle X...
catch ExceptionY
...handle Y...
catch ExceptionZ
...handle Z...
match foo() {
ExceptionX => ...handle X...
ExceptionY => ...handle Y...
ExceptionZ => ...handle Z...
}
In particular, you can have:
def quux():
xkcd = frob(foo(), zomg())
...lots of code...
def bar():
try
quux()
catch ExceptionX
...handle X...
def baz():
try
bar()
catch ExceptionY
...handle Y...
auto a = foo();
auto b = bar(a, quux());
return frob(xkcd(a), b);
Recently, I've been dealing with a C++ codebase that uses tl::expected in lieu of exceptions, and while the "main flow" becomes more readable - return doThis(x, y).and_then(do_that).map(sth).map_error(logErrors); - the side effect is that the codebase is littered with trivial functions and closures to make that interface work. It's much less readable than a bunch of catch blocks every now and then. Maybe it's a limitation of C++? I feel like a syntax for partial application would remove half of the boilerplate I have to write when chaining tl::expected-returning functions.
On semantic separation, I alluded to using a "nested" sum type like (Result1 + Result2 + ...) + (Err1 + Err2 + ...) instead of Result1 + Result2 + ... + Err1 + Err2 + ... - while mathematically equivalent, they aren't syntactically equivalent in code. Grouping possible return value types separately from possible error type values improves reasoning about code - the groups tend to change independently from function to function. And if you squint, this is what exceptions give you: they separate the error sum type from return sum type, and give the former a completely different control path. This means you can think about them separately, and don't have to force-fit the success path into shape that satisfies the needs of the error path.
See Swift's error handling design: https://github.com/apple/swift/blob/main/docs/ErrorHandlingR...
(Also, exceptions/nonlocal returns are a pain because the invisible control flow is hard to reason about and hard to implement in a compiler.)
Exceptions that can fly out of a library are just as much a part of its public interface as the error types it uses for return values. Adding a checked exception Exception is equivalent to turning your Foo return value into Result<Foo> - the code will no longer work if it doesn't handle it.
> in particular the API of other libraries they use internally.
The library can make a choice between handling the internal exceptions at the interface boundary, rewrapping them, or exposing them as a part of its public interface. That's no different than a library considering returning a type that's defined in another library it uses internally.
> (Also, exceptions/nonlocal returns are a pain because the invisible control flow is hard to reason about and hard to implement in a compiler.)
I'm not a compiler guy so I'm not going to dispute the issues with implementing exceptions, but on the readability flow, I strongly disagree. There's nothing hard in exception-based control flow. The rule is simple: a given function either succeeds, returning what it declares, or fails - a failure cause the caller to enter the appropriate exception handling block if it has one, or exit immediately, propagating the exception up the stack.
An error type is for any deviation from the happy path that can be reasonably expected to occur during normal operation, and which my program must be able to handle. For a HTTP request, this would be something like "connection reset by peer" or "expected 200, got 404".
An exception is for any deviation from the happy path that a reasonable program cannot be expected to handle. For a HTTP request, this would be something like "malloc for send buffer failed".
Error types should be very visible in your function signature and their handling should be enforced or at least linted by the tooling, since failure to handle them very likely is a bug.
Exceptions, on the other hand, should be mostly invisible since most code cannot do anything when an exception occurs. In fact, if I had to design a language, I'd probably try to get by with reducing the try-catch-finally triad to try-finally or even just finally. Sometimes it's really useful to clean up after yourself before continuing to die, but if you can recover from an exception, you probably should have had an error value in the first place.
> Or perhaps you meant null pointers.
A major problem in languages like Java is that objects can always be null. A better solution would be to force strict null checks a la Typescript, where if you want to take or return an optionally null reference, you have to explicitly encode that property in the type of the variable.
NullPointerExceptions are frankly a really stupid thing we have to deal with. A proper type system could check for that at compile time.
> but you're talking about RTTI, or "reflection"
OP is talking about ML-style type destructuring, which is kind of the opposite of this.
> I don't understand the obsession with immutable variables.
Mutating variables leads to all kinds of invisibile problems and makes the code a lot harder to reason on. When I write Java, most of my variables are final, the author is right that we should be taking the opposite convention a la Rust, variables should be immutable by default with mutability explicitly annotated.
Am I correct in interpreting that as when you pass a variable to a function by reference it causes problems? Pascal defaults to passing them by value.
There's also the problem of internal mutation of state, with hashtables/collections being again primary examples. It's not always avoidable to have internal mutation, but it shouldn't be the default, in most cases it's just wrong.
Why do you even bother with static types if you seriously believe that?
procedure Foo(constref Something: SomeType);
procedure Foo(var Something: SomeType);
Similarly
const NiceFeature = $01; NeatFeature = $02; GoodFeature = $04;
var Features: Byte;
{$packset 1}
type Feature = (Nice, Neat, Good);
var Features: set of Feature;
These are cases where Free Pascal helps you from shooting yourself in the foot.
I can see the value of making sure you don't end up with invalid values.
And "weird corner case"? Really?
What else are you going to do? If you want to insert a value but also have access to the hashtable without the change, then you need to copy it. (Or use a data structure with history tracking, like RCU or finger trees.)
If you don't need the old value, then you can optimize out the copy - this isn't too hard.
Eg, in C#, SqlDataReader is sealed. Which means I have to do this:
reader.GetString(reader.GetOrdinal("FirstName"));
reader.GetString("FirstName");
If there's something that really gets me annoyed is when I run into a limitation that seem completely arbitrary but intentional. It's not there because of the technical limits of the hardware, or because the compiler isn't clever enough, but purely because somebody intentionally decided 'nope, you don't get to do this particular thing you can do all day otherwise'.
That was something I was recalling from a very old project though. I'm not sure right now when that was exactly. Maybe it wasn't in the language yet at the time, or was a new feature still and I didn't find about it, or it wasn't in Mono yet.
I've not done C# in a long time, so no doubt I missed a lot of developments.
Fyi... this stackoverflow Q&A has opinions on why 'sealed' is a rational default for the person who designed the class: https://stackoverflow.com/questions/268251/why-seal-a-class/
It doesn't mean the programmer thinks the base class is "perfect". Instead, the author has not deliberately designed the particular class for inheritance and the "sealed" keyword expresses that.
Looks like my issue with that got fixed with extension methods, which should let me tack on such improvements whether the original designer of the class thought that would be a good idea or not.
This issue might not seem relevant in your own projects, where maybe you want to seal a class so a junior developer doesn't break something.
But it's disastrous for library and framework development. Here's an open question of mine related to this:
https://stackoverflow.com/questions/65852139/listen-for-chan...
In that case, I'm trying to write a script that people can attach to a game object to rebuild metadata after a mesh is changed. I need the metadata for my shader, since it needs info about neighboring vertices, which would only be available in geometry shaders (which have fallen out of fashion since they run at the wrong stage of the rendering pipeline).
That way my shader would "just work" without making the user have to remember to set a flag or send an event when something changes (which is not future-proof).
Normally I would just inherit from the Mesh class, override/extend methods like Mesh.SetVertices(), and then explain how to use my class in the readme. Better yet, I would use something like inversion of control (IOC) to replace the project's global Mesh class with my own (this is how frameworks like Laravel work, or try to work). In fact, there are half a dozen ways of accomplishing this, perhaps more.
But with sealed and final, I'm just done. There is no workaround, by design. Because C# inherited this kind of opinionated thinking (anti-pattern) from Java. And Unity uses C#, so unwittingly fell into this trap since so many of their classes are sealed. Which all reduces languages like C# and Java to being toy languages, at least for someone like me working from first principles under some approximation of computer science.
Maybe I should write to Unity and explain that all of this happened during the very first interesting thing I tried to do. Or maybe we could get rid of this concept altogether and avoid the problem in the first place.
Even the gospel of Martin Fowler tends to agree with my stance on this:
Just... exactly this. Hate that so much. I cannot articulate how much I agree with what you have said here.
(Also, I just discovered that it now targets WASM. Maybe I should give it another go!)
[1] https://tour.dlang.org/tour/en/gems/uniform-function-call-sy...
I mean, Lobster has classes, or at least something that it calls classes:
https://aardappel.github.io/lobster/language_reference.html#...
So you couldn't write `f(a, b, c)` as `a.f(b, c)`, because `f` as a free function couldn't exist to begin with. Either it would already be `a.f`, or `f` would be a method of the current class or a static method imported via `import static`, in which case using the `a.f` syntax could deceive readers about what class `f` is a member of.
That's what I'm going for with this language, for uniformity and discoverability. If you want to add a new method that takes type `A` as its first argument, you should add it as an extension method on type `A`.
(also, to be clear, I'm not the one who downvoted you)
https://learn.adacore.com/courses/intro-to-ada/chapters/obje...
Having higher kinded types and type classes like Haskell would be nice though. I think there are definitely things in the article which could be even better, but we've definitely moved that way, and the next generation of language designers will probably have even more insight into how to elegantly combine those features as well.
Don't have to leave the JVM, already there in Scala. And Kotlin Arrow may get merged into the compiler, so Kotlin may have first class support for these language features one day...
At some point, I realized Java code tends to have many more runtime type errors (in particular, NullPointerExceptions and ClassCastExceptions) than similar C++ code (segfaults). Things like rust should be even better than C++, but that’s practical largely thanks to performance optimizations from llvm. Other than Java compatibility, I don’t see any advantage to the JVM at this point.
Here's what I want from a new OO language, exception-wise:
- Checked exceptions only. Every function that can possibly throw, must declare what it throws. Supertypes may be used in declarations to cover a whole family of exception types. Every function must either handle or explicitly declare exceptions that can be thrown from its callees. This is to be baked into type system and enforced at compile-time.
- If the language is driven with IDE use in mind, allow "auto" for checked exception declarations. Will cut down on line noise, at the expense of readability (as type deduction always does). But since exception declarations are resolved at compile time, you won't be able to make an actual mistake here.
- A condition system, not exception system. Extend the out-of-band signalling mechanism to be used for arbitrary things, not just "exceptional situations". I.e. just as I can say `throw SomeError{someData, someMessage}`, I want to also be able to do e.g. `throw Progress{percentage, total}` to feed a progress bar that's declared few layers above in the stack (which would just execute its code and return control to the thrower; no stack unwinding). This is what you have in Common Lisp.
- Stack winding, not just stack unwinding. Also from Common Lisp, I want the exception (condition!) handler to happen prior to stack unwinding, in a way that would allow me to truly recover from the problem and resume execution where the condition was thrown, or somewhere in the middle of the call stack, between the handler and the thrower.
- Separating signalling, handling and recovery, both conceptually and in code. Again, from CL's condition system. A thrower throws an exception (condition), a handler decides what to do (or rethrows), and one of the things it can do is pick a "restart" declared down the call stack - then stack is unwound only to the point of that restart, and control resumes from there. Note the programmatic ability to choose a restart. Not 100% sure how to handle it in a type-safe way, but I believe it could be done.
- All the other stuff from Common Lisp's condition system.
So basically, a statically typed blend of C++, Java and Common Lisp, mashing together their best features into a coherent and powerful system.
Many "problems" that people have with functional programming occur because they are trying to use FP techniques in a language that isn't really equipped for functional programming (JavaScript, C#, Java, Go...).
Exceptions end up being an elegant way to represent this, you can choose how much you handle and where and match against the types of errors. Everything else I have tried has been worse, forcing me to handle errors I don't care about at that point in the code with a boilerplate response to send it upwards, something exceptions do automatically. I don't get more robust code with explicit error handling I get more verbose code for errors I can't do anything about. In practice it also changes the interface of my methods far more with maintenance and propagates error handling code throughout.
Try not to bubble up errors. Many subsystem interactions can be unidirectional. If an error occurs, it is stored right there. The caller might not even care. The situation can be handled later.
In more complex systems, this won't work out. Imagine a software that controls sensors and motors, for example. What if one of these devices fails? There is no way any automatic system (like exceptions) could come up with the right way to handle this situation.
In this way, the client code is basically required to think -- oh, wait, what happens if I'm not getting updates for some time beyond what is acceptable for me? Also, in this way, the situation can be handled in a single central location.
Imagine a situation as simple as:
foo = ComputeSomething()
The most obvious idea is: instead of retrieving something 4 layers down, get the information first at the top level, and if there was no error push it down.
I've stopped thinking that syntactic features can solve structural problems. That applies to algebraic types just as it applies to exceptions.
What I found really, really nice for error handling is dataflow-style programming, because the main flow only has to deal with the happy path. If you don't have a result, you simply don't send anything to the next filter in the pipeline.
And you report errors using a stderr style mechanism, so error handling can be centralised and at a high-level, where you actually know what to do with the errors.
That's suitable for batch programs and other short running things where you can just scrap the incomplete computation and re-try with a blank slate. I'm sure that can be productive for webapp code that sits between a database and the frontend.
For longer running processes and more complex systems, exceptions are not so great. It's almost a given that you will have a hard time tracking down all the error scenarios in your system.
I disagree. I absolutely love throwing exceptions from lower levels of my web apps and letting them bubble to be handled by exception mappers that will formulate the correct http response from them.
Because the stack unwinding cleanup is the same when an exception occurs or when an operation completes normally this app could recover from anything.
> It's almost a given that you will have a hard time tracking down all the error scenarios in your system.
You don't need to track down all the error scenarios. The only thing you need to worry about is things that you can recover from to retry and things you can't.
Passing errors around places too much emphasis on where errors occur. For recovery you only need to know what you can recover from and where you can do that recovery. This is usually no where near where the error occurs.
This is actually the best argument why exceptions do not "scale": Because in larger systems, the place where you handle the error is almost certainly not up the call stack, but in a different subsystem.
> Passing errors around places too much emphasis on where errors occur. For recovery you only need to know what you can recover from and where you can do that recovery. This is usually no where near where the error occurs.
In a way, errors are just data, like everything else. There is not much sense in making them something special - as I said, with the exception of smaller script-like programs, where you usually want to jump out of a larger subprogram immediately, and rely on the garbage collector / stack unwinding to clean up (hopefully, everything) for you.
The reason you treat them as special is because at the point an error/exception occurs you are saying that your function (or program) can no longer do any more meaningful work, forward progress is now impossible, and you can't return anything meaningful.
We've gone backwards in making error returns explicit because the most common and intelligent thing to do is pass the error back up the chain or right out of the subsystem entirely. The lazy approach is the correct one with exceptions.
> Because in larger systems, the place where you handle the error is almost certainly not up the call stack, but in a different subsystem.
If your subsystem is network connected then the most likely cause of an re-startable operation is a minor network issue. There's no need to inform another subsystem immediately. I don't really see how it's an argument that exceptions don't scale. If you need to inform another subsystem you can do that.
c++ : both sides can bring state. has diamond issues.
Java : one side can bring state. other just signatures. too restrictive.
And for all of you saying this is basically just Kotlin or Swift.. do those languages have higher-kinded types or true multiple inheritance? Not as far as I can tell. And you could argue those aren’t needed, but that does mean this is a different language with potentially different pros and cons.
Care to elaborate what you mean by that?
Start with this one. It is not out of fashion. Supported by many languages. Also languages do not exist to be cool and admired. They are just a tools that help build things. Concepts like OOP or any other style are not universal. Good for doing some things, not so good for doing other things. Hoping that some concept will magically solve world's problems is very naive at least.
If you're talking about classes, methods, inheritance, and so on, then it's just a syntax equivalent of training wheels. If you want to progress to biking downhill at full speed, most of this needs to come off at some point since the structure is not suitable for more complex situations. This kind of OOP strongly encourages componentization at the smallest level, much much more than is beneficial from an organization standpoint (subsystems).
Everything above microcode is. Abstractions / paradigms when applied adequately help to see the forest beyond the trees.
When I see an object-oriented codebase that makes me jump between 5 or more files to understand the simplest codepaths (because inheritance), and that is not browseable without a properly setup IDE and jump-to support (because of heavy namespacing and non-telling method names), it makes my shy away.
On the other hand for example, larger open source projects written in C are often really easy to read. Local ("coherent") code paths, fully qualified function names in calls, no extra foo that gets executed implicitly on data data declaration or cleanup. Nothing hidden, every line just works to solve the actual problem.
Yep, and also even though OOP was designed as a way to model simulation systems, it isn't the best thing for actual popular simulation systems (video games). They use more flexible patterns like entity-component systems.
OOP also wants to always layout data as array-of-structures, which can be less efficient than structure-of-arrays. Data layout is the most important thing for efficient programs, since memory access is so slow.
I wonder if there is a divide between people who programmed before OOP was commonplace and those first experience is learning it in school.
For me the idea that OOP is not suitable for more complex situations betrays it's very conception.
https://en.wikipedia.org/wiki/Entity_component_system (game-style C++)
https://en.wikipedia.org/wiki/AoS_and_SoA (Jai)
https://en.wikipedia.org/wiki/Relational_model (SQL)
https://en.wikipedia.org/wiki/Logic_programming (Prolog and Mercury)
The goto critique of OOP used to be http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom... (as seen in the article) but I think OO languages have managed to steal enough good ideas from functional ones by now that it doesn't apply so much.
Being contrarian to the massive success of OOP is great way to get upvotes but it doesn't reflect reality. The success of OOP is so huge that it's boring.
Also I think SQL is pretty popular!
But there's a huge variety of programmer personalities; different programmers like different things about programming. We tend to gravitate towards tools that fit our own personality.
The problem is thinking because you found the tool that's the perfect fit for you, and what you're trying to accomplish, that it's a superior tool in general.
I understand why some developers love LISP and think it's the greatest programming language ever. They wonder why nobody else would use a tool so powerful. But it's really not for me -- it's just not what I like about programming. I feel the same about pure functional languages. I've used them enough to understand the appeal. But for me, I find it constrains my creativity. I found the same with Test-driven-development. I can't just can't work by building the tests first -- and I tried. But I can imagine other programmer personality types find that TDD helps their creativity.
>"Test-driven-development"
I would normally offer them to write tests to test their tests.
Now language is very clunky to work with in ML/"big" data space.
Technically, that is the fault of the runtime, which does not support 64 bit arrays, but naturally teams must be working together.
https://www.airships.net/hindenburg/disaster/oh-the-humanity...
If you're thinking like Java.
Go says: interfaces come after classes, not before. They describe the features you want, and any class can match them if it has the features. Therefore an interface is decoupled from the classes it matches.
For reasons. So, no, we do not need a new language whose chief organizing principle is inheritance--a poor match for the majority of problems. We know better.
In fact, we don't need a new language. We have lots of languages already, enough so that the few newer ones that have above-average merit are failing to attract enough users to become viable, and bad old languages (C, Javascript, Java, C#) maintain their lead.
If you imagine your new language will be better than any of the already existing languages, think again. A language that doesn't exist has no flaws. Once it starts to exist, you will need to make choices. Sometimes the right choice will not be obvious, with valid arguments for both alternatives. Sometimes there will not be a "right" choice; each alternative leads the language in a different and objectively valid direction. And sometimes a previous choice will box you into the objectively wrong choice, later.
For every existing language, those have all happened, over and over again. Languages are products of humans, and each is riddled with imperfections and compromises. That is the human condition.
So, right now your language is perfect, like all others that don't exist. Make it, and it joins a large crowd of variously imperfect languages competing for painfully limited attention.
Being wrong at the outset on the desirability of a new O-O language (with functional crossover features!), what are the odds it will be even nearly as good as any of the half-dozen best in its target category?
Maybe a better choice would be to join in making the current best in that category more viable. That one will probably still fizzle--it is the natural fate of any language, save a miracle--but its odds are a hundred times better than yours.
And, who knows? You might even choose right and make a difference.
What world does this person live in?
> Go and Rust provide two alternate approaches to error handling. Both treat errors as values, but Go uses multiple return values to return error states, while Rust uses a Result monad.
Then they should consider fixing Go’s greatest oversight: the ability to make exceptions hard and crash your program. I don’t care if the error variable gets set, but I really care if it gets set again before I’ve reset it. That means an error has passed on unnoticed. If “—-hard-errors” could be a compiler flag, that would be perfect.
Gleam is a statically typed language on the BEAM, early implementations the messages between processes were not typed, Im not sure if that still the case.
Pony is a OO language thats based on the Actor model that has a strong static type system, where typed message passing is central to the language.
Additionally you can no longer say Thing is Thing, it's always Thing or null - which results in special handling
if (foo === null){} everywhere and when you don't boom NullPointerException.
Exceptions cause problems in other ways (especially when they are allowed to escape up the stack), business logic shouldn't be handling FileNotFoundException that was thrown 6 layers away.
So instead all 6 layers should have to know about it in addition to business logic? In most cases you can't really ignore the fact that a file didn't exist in your business logic.
It's easier to be adaptive with error handling with exceptions, and who's going to (correctly) test for all possible errors on every call?
I would have the same question.
No, that's the job of whoever requests a file to be read. But what they may do in reaction to this, or discovering the file is empty, or has malformed data, is to throw a DataUnavailable exception, a subtype of RequestError. This is something appropriate places of the business logic up the stack may be interested in. Maybe some code few layers up the call stack can recover from DataUnavailable by attempting to pull from an alternate data source. Maybe not. Maybe that too will fail. Further up still, something else will intercept RequestError and report a problem to the user.
But, unlike with Result types, only those three places in this piece of business logic have to ever care about some file not being read. Everything else can just assume the operation succeeded.
Exception types follow the same rules as "regular" user-defined types: they're relevant in a subsection of a program, and shouldn't propagate beyond that subsection.
Sounds nice.
Java tried to fix that, but doesn't let you generalize over exceptions, "my method throws FooException and whatever exceptions method Bar on the instance of Glorbable you're passing me throws".
Nulls have the same problem. Every time you get an instance of Foo you don't know if it's a null or an object. C# is trying to migrate to explicit nullability, but it's hard to convert an established ecosystem with idiosyncratic nullability rules.
Dart has just done that, though admitedly, it did not have an ecosystem as large as C#'s.
Whether a method throws an exception or not doesn't matter as much as people think it does. You can rarely recover from an exception in the immediate parent calling method anyway. More than likely the error will occur in a stack 20 layers deep and recovery is to restart the entire operation from the start.
Nulls are useful but I totally agree that they should be opt-in in the type system.
Nope, Java picked the idea from CLU, Modual-3 and C++, in what seemed the way forward to declare exceptions.
It does provide both checked and unckecked exceptions, unfortunely it suffers from bad learnings and quick hacks to shut the compiler instead of thinking it through when designing class libraries (yes even the std suffers from this).
Except nothing else in the language forces you to handle the optional case, so you end up with either null checks everywhere, or your code blows up with NullPointerExceptions, or sometimes both.
Ever been deep in a Java call stack, and wondered if you've already checked for null in all cases? In a language with (only) Option types, you can simply declare that variable to be T, and if it's actually Option<T> (i.e. you haven't checked for absence along some path) you'll get an error. A good compiler will even tell you where in the code the None is sneaking in, so you can fix it there, or pattern-match on Some and None where the error is, depending on which is correct for your logic.
I'm ignoring the exceptions question, because the post doesn't even consider a condition/restart system, which means it's not-even-wrong.
An Option type means you must specify Some (pointer) or could-be-None (null, NULL pointer) and the compiler will enforce the distinction. Generally this comes with exhaustive pattern matching, so you can turn Some<T> into <T>, and handle None by raising an error or assigning a default or blowing demons out your nose.
None and null are the same thing, the name isn't the important part. Zig, for example, has optional types as ?*Foo, and calls the null pointer "null".
I believe the consensus for the 20s for error handling is to have both exceptions and error types (or just error pairs). Without exceptions the code starts to bloat up with various try's, ?s, unwraps, pattern matches on sum and option types and nonstandard do notations. You start writing a nice and simple code when prototyping, only to end up with unreadable piece of mess when productionizing and wrapping everything with error handling. Most modern languages which boast for not using exceptions have them anyway, but call them panics or aborts and don't provide first class support for them.
I believe the next paradigm beyond OO and FP is data oriented programming. One could argue that it is what FP is, but modern FP means more Type Oriented programming than Functional Programming. In contrast with Lisp and APL family, which are also considered FP, but whole another class.
OO gets lots is the kingdom of nouns, as the article points out. You often can't even use a stupid function without wrapping it in some class. Type programming makes a type for everything and gets lost in the kingdom of types. You often can't even start programming before you type your data or provide schema for it.
In Data Oriented Programming, you try to limit the number of objects or types to minimum, such as simple linked lists (Lisp) or multidimensional vectors (APL, numpy, tensorflow), json dicts (python, jq), streams of text (shell), tables (sql) or primitives - strings, ints, etc. The big benefit is that you can start coding immediately without defining any classes or types and most operations are already defined for you in a performant way. Once you introduce your custom classes or types, you lose the benefit of carefully designed operations on the language primitives that allow you to stay within the algebra of those language primitives. Eg. in APL you have arrays and numbers and they combine in infinite amount of ways which have been carefully explored and designed over decades for very ergonomic use.
I believe the future is to have small amount of versatile types, not to create languages which promote complexity by introducing tons of non-interoperable custom types.
My other big problem with OO is the spaghetti code that results once you start mixing overloads and hooks across superclasses and subclasses. The OO model really seems to be a little too low-fidelity overall.
What do you think are the major problems with variance in OO?
If you have subtyping you need to think about variance. That's led me to believe that subtyping's simplicity is deceptive, and that it should be avoided as much as possible. (Rust has subtyping but only for lifetimes, and it's confusing enough there.)
In short, I use OO because everyone else does. Now in my 40s, I’m not going to change merely because another language is more expressive.
But yeah, if I could do it all over again, I’d probably choose Clojure.
OO is a way to bundle a structure with the methods to manage it.
Inheritance is a way to manage the need to customize an object.
Composition is a way to bundle objects.
Why wouldn't you do both? That's what Delphi did back in the 1990s when they built the Visual Component Library. (VCL)
You build your forms in the GUI builder, which composed a form object out of various components which were all eventually derived from tObject. It still lives on, and Lazarus implements something similar for Free Pascal.
According to Alan Kay, the essential ingredients of OOP are: Message passing, Encapsulation, Dynamic binding.
> OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I’m not aware of them.
* https://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_ka...
* https://medium.com/javascript-scene/the-forgotten-history-of...
* https://softwareengineering.stackexchange.com/questions/4659...
Though it's recognized that Simula invented objects:
At a gig in my college cs lab, teachers talked about OO, 3 teachers, no answer the same.
"The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be."
Typeclasses are a much better way to do polymorphism.
As a high-level app developer, one has much less use for is-a relationships but what we do sits on top of that well-tread inheritance filled OOP environment.