I was thinking recently about a Lisp general purpose OS. I'm aware that Mezzano exists but it seems really generic - it's just an "OS in Lisp", not really a Lisp OS. Here are some concepts I think a Lisp OS could explore well:
- instead of a filesystem, keep all data simply as Lisp objects in memory : then the filesystem is simply a sort of a cache for Lisp objects. I think this would be far superior to your regular filesystem - e.g. instead of saving an "image.jpg" in your ~/images directory, you would make an JPEG CLOS object (that inherits from the image class and the binary-object class) and add it to some sort of index. Add a display generic function that when called, renders the image on screen and call it when inspecting (= viewing) the object (= file). This would make the filesystem far more sensible than the absolute mess that is e.g. Unix or Windows filesystems (which are just hashmaps of string keys to binary values).
In a Lisp OS, the entire system runs as a single process, so we can view the disk as simply a cache for the process memory.
CLOS is an advanced type of OOP which has failed as a concept long time ago.
That aken into account, your concept slightly reminds me of Phantom OS.
>>2
Retard.
>>3
Why?
>>4
Not only OOP is just fine, it's braindead to claim that a programming paradigm has "failed". It's a useful tool for problems that can easily be solved with OOP, e.g. GUIs or in general dealing with structured data.
>>5
Can you give a sound definition of what OOP is?
For term projects in uni, may be. For real world software there can always be found more suitable and more advanced paradigms.
>>6
Your software architecture is divided into discrete objects that manages its own internal state. Each object communicates with one another by passing messages through the object's interface.
>>9
What problems does such dividing solve?
>>10 those of the mental kind.
>>10
None. It is just an obvious and naive extension of structural paradigm. It was never even used in the canonical form described in >>9 (well, may be in one or two languages, but they didn't get popular).
>>9
OOP is a failure in most use cases. GUI, sure. But people try to use it for literally everything, which then causes eldritch horrors to be created.
Maybe you would be interested in pilos. https://picolisp.com/wiki/?PilOS
Mezzano?
Oh, didn't know OOP is pointless, thought it's widely used.
>>17
Depends on the definition. Is OOP the same thing as the actor model, or modular programming, or procedural programming with type directed name resolution? OOP advocates tend to say "yes, all of the above" which is no use to anybody.
sorry, don't know how to reply here, mb.
I feel like there's also inconsistency between what it's meant to be and what it usually is, so even when on paper it sounds useful it could be of no use in the real world. Are programming paradigms even worth it? I mean things are different therefore should require different approach, or am I missing something?(I'm not really a programmer)
>>19
If you want to reply, just type some angle brackets and the post number.
Programming paradigms can be worth it when they clearly define their objectives, rules, and limitations. OOP sucks because it caught on as a buzzword without ever actually doing those parts. The first three attempts to make object-oriented languages all had totally different interpretations of the idea, and when you go back and examine what the goals are, they amount to modeling the problem domain with code, which describes literally all programming. Thus, the scope of OOP grew to encompass all programming, and its cult went around calling things OOP like wistful weebs amid sakura blossoms whispering "this, too, is yuri."
>>18
OOP is not either of those things, but a set of points at the intersection of them. Languages implement a point somewhere in the space delimited by those three axes according to the goals of the implementor.
What I've read about OOP is usually about structuring a project for a large team of programmers: `The nature of object-oriented programming is such that it is most beneficial for large programs written by multiple authors and are expected to last a long time. The ease of implementing a small, simple program does not much depend on what programming methodology is employed, and onewho has dealt with only small programs may not see any point to the object-oriented discipline.` (David Moon preface to Keene, 1989).
So the scope or OOP isn't really for structuring the way your program behaves, but for structuring how it is put together by a team much in the way that organiations (of people, such as afirm that develops software) do. In fact, OOP reflects the organization of the team that puts it together. Whether you think such an organization ought to exist in the first place is beyond the point, the case is that they do and so OOP has prevailed to solve that organizational need. If it were, as you said, nothing but a buzzword, it would have faded into obscurity decades ago.
>>21
I am >>18,20.
Again, the problem is not that OOP has no ideas. The problem is that it lays claim to all ideas. When programmers succeed, OOP advocates say it's because they were doing OOP correctly. Conversely, when they fail, it's because they're doing OOP wrong, even if their methodology was precisely what these same OOP advocates were preaching the previous day. Inheritance vs. composition is one example that comes up all the time, but they have the same problem with state, concurrency, and fucking if/then statements. They have an answer for everything, but they can't actually help you with anything.
The modular programming people have their heads bolted on much tighter, as do the actor model and CSP people. They clearly defined the scopes of their methodologies and were transparent about their weaknesses. OOP people can't tell you what weaknesses OOP has, because it doesn't have any, because it's everything. If there's a dot in your code, it's OOP. If there's not a dot, it's still OOP. It was never a coherent idea. A few languages took over the world by attaching themselves to the hype, and as soon as anyone stopped to examine it, it dissolved like an optical illusion. It was never much more than that anyway.
>>22
You've been drinking the kool-aid even though you despise it. I've read my share of programming books and seldom have I seen such claims as you adjudicate to the OOP crowd. Even if they do make such empty claims, why do you bother paying attention to them? It's like having the option to read Djisktra vs some dudejeet's programmming blog, and you choose to read the blog despite knowing better.
It has to be either masochism or just punching down for an easy win.
and you choose to read the blog
I don't read blogs. I just work with other people. There are morons and cultists everywhere.
Instead of continuing this stupid fight, let's focus on Lisp interpretations of OOP. CLOS, for example, is opinionated in ways that most OOP advocates hate, but it's also much more flexible than the greatest common denominator "single dispatch + single inheritance" model. Say something about that instead, if you want. I'll go post about something else altogether.
>>24
Fight? Was my reply confrontational? If so I didn't mean to.
Still, do you think lisp OOP is somehow good despite OOP in general bad?
>>25
I found your racist remark distasteful. Does that count?
Regarding CLOS (etc.) I meant "let's keep the OOP talk Lisp-related if we must mention it at all." But where it really belongs is some other thread.
>>26
Oh, apologies. I have yet to shed some of the remaining habits I got on imageboards at some point.