TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

An Object-Oriented Language for the '20s

179 pointsby ar-nelsonabout 4 years ago

41 comments

wongarsuabout 4 years ago
&gt; But, if we made a new statically-typed OO language from scratch in 2021, something in the vein of Java or C#, taking everything we&#x27;ve learned from functional programming and a decade-plus of scathing OO criticism, could we fix this?<p>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&#x27;s basically &quot;Java done right&quot;). And of course there&#x27;s also Scala and F# if you want something more functional than OO.<p>I think the author summarizes it best at the end: &quot;I realize there&#x27;s not much need for a language like this—the space is crowded enough as it is—but it&#x27;s fun to dream.&quot;.
评论 #26447734 未加载
评论 #26447615 未加载
评论 #26447745 未加载
评论 #26452820 未加载
评论 #26447741 未加载
alkonautabout 4 years ago
I love how rust does interfaces (traits) and allows implementing <i>outside</i> the type. It feels much more natural to create a subsystem on the side without tangling it into other subsystems. E.g. to create a separate rendering subsystem for a game entity you simply<p><pre><code> impl Drawable for MyEntity void Draw(MyEntity self, Canvas... </code></pre> Which feels quite natural compared to anemic-entity ECS or naive Composition-over-inheritance like so:<p><pre><code> class MyEntity { EntityDrawingComponent drawer EntityMovingComponent mover; </code></pre> and of course, over the standard Java&#x2F;C# OO way<p><pre><code> class MyEntity : Drawable, Movable, ... void Move(Vec..) void Draw(Canvas..) </code></pre> With this type of declaration, I&#x27;m forced to mix the code for my different subsystems making it not just likely but inevitable that someone eventually ties these subsystems together.<p>In general, if I were to design a &quot;better&quot; OO language now; i&#x27;d make sure to make it almost not OO at all. I&#x27;d allow subclass polymorphism, but no virtual methods or classes. Only interfaces&#x2F;traits and abstract classes. I&#x27;d very clearly separate data types from identity types at the language level (which aren&#x27;t just a difference betweeen stack and heap as with C# structs and classes).<p>I&#x27;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 <i>completely</i> different cases: open and closed polymorphism sets. OO is great when you don&#x27;t know what variants might exist, but it&#x27;s useless when you DO want to control it. If I as a developer know that the set of Payment options are Credit&#x2F;Cash&#x2F;Invoice - then I want it exhaustively checked. I deliberatel <i>do not want to leave that open</i>. 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).
评论 #26447092 未加载
评论 #26449064 未加载
评论 #26446979 未加载
评论 #26446976 未加载
评论 #26447057 未加载
评论 #26463284 未加载
评论 #26451101 未加载
throwaway4goodabout 4 years ago
&quot;First, a few obvious, non-negotiable things any new OO language should have: ...&quot;<p>Well, that&#x27;s like your opinion, man ...
评论 #26447827 未加载
评论 #26448249 未加载
评论 #26446923 未加载
foucabout 4 years ago
I&#x27;m fine with implementing another static Object-Oriented language, but please learn from some of the best non-static Object Oriented languages out there like Ruby and to a lesser extent Erlang&#x2F;Elixir.
评论 #26453085 未加载
评论 #26448161 未加载
评论 #26448044 未加载
srikuabout 4 years ago
Erlang is perhaps the best OO lang out there that doesn&#x27;t look like one but it&#x27;s principles are the heart of OO.<p>PS: I admit I lost the author at &quot;scala is my favourite language&quot; and so am biased.
评论 #26447181 未加载
transfireabout 4 years ago
CLOS (<a href="https:&#x2F;&#x2F;lispcookbook.github.io&#x2F;cl-cookbook&#x2F;clos.html" rel="nofollow">https:&#x2F;&#x2F;lispcookbook.github.io&#x2F;cl-cookbook&#x2F;clos.html</a>)
mikewarotabout 4 years ago
It seems to me that you could do almost everything you want (except for the immutable thing) in Free Pascal.<p>Pascal doesn&#x27;t have the kingdom of nouns problem. It supports good old fashioned procedures and functions.<p>Pascal can deal with nulls in strings, because we always know how long they are.<p>Or perhaps you meant null pointers. Pascal avoids unnecessary pointers, but supports them in a sane manner when you need them.<p>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&#x27;ve heard about in C++, etc.<p>Free Pascal has generics there are libraries that let you do dictionaries and lists and trees of your type &lt;T&gt;.<p>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.<p>As far as &quot;pattern matching&quot; I assumed you were talking about regex (which can be addressed in a library)... but you&#x27;re talking about RTTI, or &quot;reflection&quot; where you can get type information at runtime, which is a thing in Pascal and many other languages.<p>I don&#x27;t understand the obsession with immutable variables.<p>[Edit: I think I understand... in Pascal, parameters are passed by value as the default, but <i>can</i> be passed by reference, it depends on how you declare the function or procedure. It has nothing to do with variables that you can&#x27;t assign new values to, if I&#x27;m correct]<p>Did I miss anything?
评论 #26447239 未加载
评论 #26447330 未加载
评论 #26447200 未加载
dale_glassabout 4 years ago
Can we get rid of &#x27;sealed&#x27;? I really hate that keyword. Sometimes there&#x27;s a good reason for it, sure, but sometimes it&#x27;s used gratuitously, and then I have to work around it for no good reason.<p>Eg, in C#, SqlDataReader is sealed. Which means I have to do this:<p><pre><code> reader.GetString(reader.GetOrdinal(&quot;FirstName&quot;)); </code></pre> When I just want to skip the verbosity and be able to do this:<p><pre><code> reader.GetString(&quot;FirstName&quot;); </code></pre> So the logical thought there would be just to inherit from it, add an extra overload to those functions, and life got more comfortable, plus you can still pass it to anything that wants a SqlDataReader. But oops, you can&#x27;t do that, because somebody at Microsoft decided the interface for this thing was perfect is not to be messed with.<p>If there&#x27;s something that really gets me annoyed is when I run into a limitation that seem completely arbitrary but intentional. It&#x27;s not there because of the technical limits of the hardware, or because the compiler isn&#x27;t clever enough, but purely because somebody intentionally decided &#x27;nope, you don&#x27;t get to do this particular thing you can do all day otherwise&#x27;.
评论 #26447991 未加载
评论 #26447868 未加载
评论 #26452497 未加载
评论 #26449836 未加载
评论 #26448531 未加载
vanderZwanabout 4 years ago
Regarding the &quot;Kingdom of Nouns&quot;, I always thought Lobster[0][1] had a really cute idea: x(a, b, c) and a.x(b,c) are equivalent. Don&#x27;t know if that is original to the language, but it&#x27;s where I saw it first. It only really makes sense with the other features of the language, though.<p>(Also, I just discovered that it now targets WASM. Maybe I should give it another go!)<p>[0] <a href="http:&#x2F;&#x2F;strlen.com&#x2F;lobster&#x2F;" rel="nofollow">http:&#x2F;&#x2F;strlen.com&#x2F;lobster&#x2F;</a><p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;aardappel&#x2F;lobster" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;aardappel&#x2F;lobster</a>
评论 #26448641 未加载
评论 #26449148 未加载
评论 #26448604 未加载
评论 #26448558 未加载
评论 #26449569 未加载
评论 #26449005 未加载
seanalltogetherabout 4 years ago
Am I wrong or is OP describing most of what swift currently offers. Optionals, extension where syntax, Result&lt;&gt; monads, exceptions collapsed to a single line with try? syntax, safe casting with as?, etc...
评论 #26447176 未加载
ajaniabout 4 years ago
Most of what he mentions as features needed in this new language have existed in common lisp for a long time. CLOS.
brianbernsabout 4 years ago
F# is functional-first, but also fully supports OO. It’s a good balance for the 20’s, or any other decade.
评论 #26447354 未加载
评论 #26447233 未加载
TeMPOraLabout 4 years ago
Hard disagree on exceptions. Passing sum types types along with every call is annoying - in a good codebase, probably upward of 50% of your code might be returning some kind of Result&#x2F;Expect type. Exceptions can be done right, and there are solutions to the main objections (implicit, hard to recover from) in various languages - but somehow nobody seems to have managed to put all of them in the same language.<p>Here&#x27;s what I want from a new OO language, exception-wise:<p>- 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 <i>baked into type system and enforced at compile-time</i>.<p>- If the language is driven with IDE use in mind, allow &quot;auto&quot; 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&#x27;t be able to make an actual mistake here.<p>- A <i>condition</i> system, not <i>exception</i> system. Extend the out-of-band signalling mechanism to be used for arbitrary things, not just &quot;exceptional situations&quot;. 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&#x27;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.<p>- 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.<p>- Separating signalling, handling and recovery, both conceptually and in code. Again, from CL&#x27;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 &quot;restart&quot; 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.<p>- All the other stuff from Common Lisp&#x27;s condition system.<p>So basically, a statically typed blend of C++, Java and Common Lisp, mashing together their best features into a coherent and powerful system.
评论 #26449428 未加载
vips7Labout 4 years ago
Personally I&#x27;d keep exceptions. Result&lt;T&gt; is boiler plate hell.
评论 #26447249 未加载
评论 #26447270 未加载
评论 #26447224 未加载
michaelbraveabout 4 years ago
what the author is proposing sure sounds an awful lot like Swift to me.
toolsliveabout 4 years ago
multiple inheritance.<p><pre><code> c++ : both sides can bring state. has diamond issues. Java : one side can bring state. other just signatures. too restrictive. </code></pre> What you want is: both sides should be able to bring behaviour, but only side can bring state. (iirc, ruby does it like that... )
alfiedotwtfabout 4 years ago
Brain: haha why would they need a programming language for the 19OH THEY’RE TALKING ABOUT THIS DECADE
brokencodeabout 4 years ago
I think this is really cool, and it elegantly brings together some pretty advanced features from FP and OO into one purely OO language. The only thing I’d like to see more about is how immutability would be handled, because that is harder than it sounds in OO.<p>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.
rini17about 4 years ago
It seems to me more a syntactic sugar than really tackling the main problem with OO: state that tends to get scattered into many interdependent objects, hard to manage, hard to refactor.
评论 #26447291 未加载
raspasovabout 4 years ago
An Object-Oriented language for the &#x27;20s: don&#x27;t do it.
FpUserabout 4 years ago
&gt;&quot;Object-oriented programming is out of fashion now&quot;<p>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&#x27;s problems is very naive at least.
评论 #26448472 未加载
dw-im-hereabout 4 years ago
I think this is a well written post, but I&#x27;m incredibly puzzled at eschewing scalas syntax for type parameters and instead having parentheses do double duty. Other than freeing up brackets for indexing what is gained from this? Other than that I actually think this is a language that deserves to exist so the ideas can be tried out in practice, if nothing else to influence the current OO languages to be better.
评论 #26452486 未加载
lostmsuabout 4 years ago
I love C#, but they seriously fucked up Span&lt;T&gt; and Range by restricting them to 32 bit length, which by the time when the features were concepted was already extremely niche.<p>Now language is very clunky to work with in ML&#x2F;&quot;big&quot; data space.<p>Technically, that is the fault of the runtime, which does not support 64 bit arrays, but naturally teams must be working together.
PaulHouleabout 4 years ago
Bring back Turbo Pascal!
a0-prwabout 4 years ago
Oh the humanity, and all the passengers!<p><a href="https:&#x2F;&#x2F;www.airships.net&#x2F;hindenburg&#x2F;disaster&#x2F;oh-the-humanity-herbert-morrison-and-the-hindenburg&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.airships.net&#x2F;hindenburg&#x2F;disaster&#x2F;oh-the-humanity...</a>
acjohnson55about 4 years ago
One of my favorite parts of functional languages like Scala and ML is the compact notation for defining algebraic data types. They provide an incredible amount of mileage for writing maintainable and reliable business logic. Scala 3 really nails this, IMO.
JulianMorrisonabout 4 years ago
&gt; Interfaces are a subset of classes.<p>If you&#x27;re thinking like Java.<p>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 <i>decoupled</i> from the classes it matches.
评论 #26452677 未加载
ncmncmabout 4 years ago
&quot;<i>Object-oriented programming is out of fashion now</i>&quot;<p>For reasons. So, no, we <i>do not need</i> a new language whose chief organizing principle is inheritance--a poor match for the majority of problems. We know better.<p>In fact, we don&#x27;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.<p>If you imagine your new language will be better than any of the already existing languages, think again. A language that doesn&#x27;t exist has no flaws. Once it starts to exist, you will need to make <i>choices</i>. Sometimes the right choice will not be obvious, with valid arguments for both alternatives. Sometimes there will not <i>be</i> a &quot;right&quot; choice; each alternative leads the language in a different and objectively valid direction. And sometimes a <i>previous</i> choice will box you into the objectively wrong choice, later.<p>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.<p>So, right now your language is perfect, like all others that don&#x27;t exist. Make it, and it joins a large crowd of variously imperfect languages competing for painfully limited attention.<p>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?<p><i>Maybe</i> 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.<p>And, who knows? You might even choose right and make a difference.
booleandilemmaabout 4 years ago
<i>Object-oriented programming is out of fashion now</i><p>What world does this person live in?
mangopiabout 4 years ago
You basically want Go, but you haven’t learned it yet.
clankyclankerabout 4 years ago
If you’re going to handle errors like Go:<p>&gt; 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.<p>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.
评论 #26451805 未加载
maxekmanabout 4 years ago
How are Optional named arguments and Generics obvious choices for a new OO language? Good to have, sure, but obvious?
cutlerabout 4 years ago
In the HN echo chamber OO may well be out of fashion but in the job market it&#x27;s a different story.
nesarkvechnepabout 4 years ago
No mention of message passing? Shame.
评论 #26448623 未加载
评论 #26448805 未加载
Traubenfuchsabout 4 years ago
Swift? Typescript? Both fairly new and object oriented. Go? Somewhat object oriented.
评论 #26448105 未加载
评论 #26447915 未加载
Graffurabout 4 years ago
why no nulls? and no exceptions? I am no language designer but as a user they seem ... usable.
评论 #26447677 未加载
评论 #26450860 未加载
评论 #26447113 未加载
评论 #26447226 未加载
snidaneabout 4 years ago
I&#x27;ll bite.<p>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&#x27;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&#x27;t provide first class support for them.<p>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.<p>OO gets lots is the kingdom of nouns, as the article points out. You often can&#x27;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&#x27;t even start programming before you type your data or provide schema for it.<p>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.<p>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.
fit2ruleabout 4 years ago
All of this can be done in Lua.
enriqutoabout 4 years ago
why is OOP still a thing?
评论 #26448989 未加载
gigatexalabout 4 years ago
Ugh. Another reminder that high level OO languages and things make my head hurt.
howinterestingabout 4 years ago
One of the fundamental issues with OO subtyping continues to be how variance works. I wish the author spent more time talking about how they envision variance.<p>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.
评论 #26446803 未加载
评论 #26446767 未加载