www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Exploring the philosophy of objects

reply forkit <forkit gmail.com> writes:
This is certainly not another thread about private to the class 
;-)

Please, don't try to make it into one.

But I'd encourage everyone, to a least consider, exploring the 
nature of 'objects' from a purely 'philosophical' approach (i.e. 
outside of your programming interests).

If it's not your thing, don't do it ;-)

If you come to the conclusion, its complete nonsense, that is 
your right.

For me, I have a particular understanding of objects (as many 
will now know).

i.e. I have a firm view in the 'autonomous existence' of objects.

It's the basis of my view, of the real world (nothing to do with 
programming).

That understanding though, while completely separate from 
programming, is well intergrated into my approach towards 
programming, and I personally believe, my programming is better 
for it, nor worse.

Here is something to get you started, on your journey:

'undermining, and overmining, objects'

https://youtu.be/P6yWc7ccb7g

There's also a great discussion about this, if you can get your 
hands on it ;-)

The Object Strikes Back: An Interview with Graham Harman.

https://www.tandfonline.com/doi/abs/10.2752/175470813X13491105785703

If you don't know who he is:

https://en.wikipedia.org/wiki/Graham_Harman
Jun 23
next sibling parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Friday, 24 June 2022 at 00:45:11 UTC, forkit wrote:
 But I'd encourage everyone, to a least consider, exploring the 
 nature of 'objects' from a purely 'philosophical' approach 
 (i.e. outside of your programming interests).
https://en.wikipedia.org/wiki/Object-oriented_ontology After careful consideration, I believe you've taken oo too far if you think it should affect anyone's meta physics.
Jun 23
next sibling parent forkit <forkit gmail.com> writes:
On Friday, 24 June 2022 at 01:00:06 UTC, monkyyy wrote:
 On Friday, 24 June 2022 at 00:45:11 UTC, forkit wrote:
 But I'd encourage everyone, to a least consider, exploring the 
 nature of 'objects' from a purely 'philosophical' approach 
 (i.e. outside of your programming interests).
https://en.wikipedia.org/wiki/Object-oriented_ontology After careful consideration, I believe you've taken oo too far if you think it should affect anyone's meta physics.
that is your right. a right, btw, that comes about, because of your autonomous existence as an object ;-) Also, what you read or hear in your exploration into the philosophy of objects, is not necessarily refective of what I believe, or don't believe. Like you, as an object that exists autonomously, I have my own views ;-)
Jun 23
prev sibling parent reply forkit <forkit gmail.com> writes:
On Friday, 24 June 2022 at 01:00:06 UTC, monkyyy wrote:
 https://en.wikipedia.org/wiki/Object-oriented_ontology

 After careful consideration, I believe you've taken oo too far 
 if you think it should affect anyone's meta physics.
Actually, I think in reverse. That is, its metaphysics, that ultimately drives the nature of software development, and programming languages. But the ending of Moore's Law is pushing us in the opposite different at the moment. And understandably. That's why newer languages are having a much greater focus on performance, perhaps at the expense of the abstract type?? But as Arnold once said: "I'll be back" (says the autonomous existing object). The movie 'The Terminator', is a movie about 'a possible future where mankind has been oppressed by artificially intelligent machines, lead by the rebellious computer system Skynet.' Nonetheless, we continue on that very path towards creating these very same AI 'objects'. I'd argue, that more than ever, software engineering focus is being directed towards the creation of 'autonomous existing objects'. Some of you already have them on your phones, in your TV, on your tablet, on your wrist....in your car...... Why? Well, as Timothy Morton once said: "We are caught in object-ive existence whether we like it or not." i.e. It's natural to think about our reality in terms of autonomous existing objects, so it's natural this will find it's way into other areas of our thinking, including programming. If you don't know who he is: https://en.wikipedia.org/wiki/Timothy_Morton Once this necessary refocus on extracting greater performance becomes less relevant in programming (some technological breakthough perhaps), we'll all be back focusing on creating automous existing objects again. It's how we think. Well, not all.
Jun 23
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 24 June 2022 at 01:59:07 UTC, forkit wrote:
 i.e. It's natural to think about our reality in terms of 
 autonomous existing objects, so it's natural this will find 
 it's way into other areas of our thinking, including 
 programming.
I once took a course that had the book «Computers in Context: The Philosophy and Practice of System Design» in the curriculum, which looks at systems development from the angle of a philsopher and a system development angle. Sadly, I don’t remember what it said about objects. But yes, both objects and class hierarchies are reflections of human thought processes. Functions too, and math. Mathematicians talk of «mathematical objects».
Jun 23
prev sibling parent reply Zoadian <no no.no> writes:
On Friday, 24 June 2022 at 00:45:11 UTC, forkit wrote:
 This is certainly not another thread about private to the class 
 ;-)

 Please, don't try to make it into one.

 But I'd encourage everyone, to a least consider, exploring the 
 nature of 'objects' from a purely 'philosophical' approach 
 (i.e. outside of your programming interests).

 If it's not your thing, don't do it ;-)

 If you come to the conclusion, its complete nonsense, that is 
 your right.

 For me, I have a particular understanding of objects (as many 
 will now know).

 i.e. I have a firm view in the 'autonomous existence' of 
 objects.

 It's the basis of my view, of the real world (nothing to do 
 with programming).

 That understanding though, while completely separate from 
 programming, is well intergrated into my approach towards 
 programming, and I personally believe, my programming is better 
 for it, nor worse.

 Here is something to get you started, on your journey:

 'undermining, and overmining, objects'

 https://youtu.be/P6yWc7ccb7g

 There's also a great discussion about this, if you can get your 
 hands on it ;-)

 The Object Strikes Back: An Interview with Graham Harman.

 https://www.tandfonline.com/doi/abs/10.2752/175470813X13491105785703

 If you don't know who he is:

 https://en.wikipedia.org/wiki/Graham_Harman
No disrespect, but this is a programming language forum, i'd really appreciate if it stayed that way. And to add something to the topic. objects are a great why to think about things. they are, as it turned out, not they great in programming. OOP leads to slow, hard to reason about code. it encurages mutable state, spread across the whole programm. it's essentially global variables all over again, just hidden behind a layer of obfuscation. It also makes testing a lot harder to actually implement. That being said, there are cases where it's ok to use, but imho they are incredibly rare. - Someone who works on hard realtime systems
Jun 24
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 24 June 2022 at 13:48:35 UTC, Zoadian wrote:
 And to add something to the topic. objects are a great why to 
 think about things. they are, as it turned out, not they great 
 in programming.
 OOP leads to slow, hard to reason about code. it encurages 
 mutable state, spread across the whole programm. it's 
 essentially global variables all over again, just hidden behind 
 a layer of obfuscation.
 It also makes testing a lot harder to actually implement.
 That being said, there are cases where it's ok to use, but imho 
 they are incredibly rare.

 - Someone who works on hard realtime systems
What you are describing is not the nature of OO-modelling, but the consequences of people not knowing what they are doing, using the wrong implementation strategy, tooling etc. Objects are appropriate also in real time systems. Actors are objects on steroids and represents one valid approach to creating reliable real time systems. Coroutines have a strong relationship to objects and greatly reduces bug inducing tedium of creating state machines, again an improvement for real time systems if used by a critical thinker. Objects also makes it easier to create transactional systems that allows you to roll back, again a reliability advantage. No matter what domain you are in, if you deal with uncertainty then also you need a proven methodology and tools that suits the application domain you are working with. With no proven methodology, especially geared towards what you are doing, quality will become less predictable. If you have no need to maintain state modelling the environment, then of course, you would also not need objects and can choose dedicated tools with 100% verification of the implementation. Is that better? Yes clearly, when you can get away with it. The OP is relevant to D, because how people thing about objects and their representation affects language design and usage. You confirmed this yourself by stating that you dislike OOP because people are idiots and mess things up (which is the only reasonable interpretation of what you stated). But that is not a consequence of OO-modelling as a concept. It is a result of poor modelling or poor implementation or poor tooling.
Jun 24
next sibling parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
What's your use case? without this answer, object has no meaning

Programming computers have no concept of "objects", it is pure 
programmer's religion, something sold by scholars and forgotten 
companies to produce cheap engineers

Unity is back to  data oriented design because "objects" was 
found to be inefficient

D doesn't need them, metaprogramming, struct, function is all we 
need, it's our strength, and we should capitalize on that, and 
show the world that if they need alternative to "objects, they 
can find the right tools with D!


and a new compiler "Burst", Unity should have picked D long time 
ago, i still try to lobby for them to add support for proper C 
FFI, so we can properly use D there, but it's hard..
Jun 24
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 24 June 2022 at 14:30:05 UTC, ryuukk_ wrote:
 What's your use case? without this answer, object has no meaning
Sure, although I guess forkit means that we cannot avoid modelling in terms of objects (or classes) as the human brain is essentially a rather slow abstraction machine that to a large extent has a tendency to create broad sterotypes of what is needed to understand the real world (or in the case of simulation or game, a fictional world). Stereotypes ≈ classes.
 Programming computers have no concept of "objects", it is pure 
 programmer's religion, something sold by scholars and forgotten 
 companies to produce cheap engineers
I would rather say, whenever you encapsulate something you have a defacto object. Even in a relational database you have entities, which are corresponding to objects (you can also group them as classes). Those table entries for entities (keys) are defacto object representations. I don't see a contradiction between object-oriented-modelling, component-based-modelling or entity-relationship modelling, I view it as facets of the same. You can mix. The more modelling knowledge you have, the more cogntitive aids you have, the more likely you are to arrive at a good model. Then you can choose an implementation strategy that suits your use case (one important decision factor is whether you believe that the model has to change later or not). What is certain is that you need a model of the world you want to represent, be it the real world or a gaming world. And a strategy to represent it your chosen language/database.
 Unity is back to  data oriented design because "objects" was 
 found to be inefficient
Ok, so when you design a framework for others to use, and don't want them to know the inner workings of the framework, then you are willing to pay a rather high efficiency price to begin with. OO-models do not require you to put everything in the same record though. You can split off physics in a game from avatar and soforth. Also, component based design, which decouples entities by giving them identities (e.g. a number) instead of using the address, has some advantages over using pointers; you can more easily split the system and distribute it over many computers for instance. And if you create many similar systems, then it can make some reuse cases easier as you only deal with an integer-id. But it has a price. In terms of efficiency it can become worse or it can become better… it all depends on wether the decoupling makes sense or not. But the key point is that you don't have to choose between classic OO implementation or components. You can mix.
 D doesn't need them, metaprogramming, struct, function is all 
 we need, it's our strength, and we should capitalize on that, 
 and show the world that if they need alternative to "objects, 
 they can find the right tools with D!
Well, but surely structs would be more intuitive to use if they could inherit rather than using alias this? Even if you never go further than one level of inheritance, it is still beneficial. E.g. have one abstract Node struct that takes care of book-keeping and a bunch of structs that inherit from the Node that does the real work that your game cares about. Many ADT implementations use this strategy, and it is OOP. You can use other strategies, but they tend to become clunky and/or verbose. (I would also argue that template composition can be viewed as a form of object-model implementation, btw)

 and a new compiler "Burst", Unity should have picked D long 
 time ago, i still try to lobby for them to add support for 
 proper C FFI, so we can properly use D there, but it's hard..
Unity sound like fun, I don't know much about it, unfortunately.
Jun 24
prev sibling parent reply Zoadian <no no.no> writes:
On Friday, 24 June 2022 at 14:11:51 UTC, Ola Fosheim Grøstad 
wrote:
 On Friday, 24 June 2022 at 13:48:35 UTC, Zoadian wrote:
 And to add something to the topic. objects are a great why to 
 think about things. they are, as it turned out, not they great 
 in programming.
 OOP leads to slow, hard to reason about code. it encurages 
 mutable state, spread across the whole programm. it's 
 essentially global variables all over again, just hidden 
 behind a layer of obfuscation.
 It also makes testing a lot harder to actually implement.
 That being said, there are cases where it's ok to use, but 
 imho they are incredibly rare.

 - Someone who works on hard realtime systems
What you are describing is not the nature of OO-modelling, but the consequences of people not knowing what they are doing, using the wrong implementation strategy, tooling etc. Objects are appropriate also in real time systems. Actors are objects on steroids and represents one valid approach to creating reliable real time systems. Coroutines have a strong relationship to objects and greatly reduces bug inducing tedium of creating state machines, again an improvement for real time systems if used by a critical thinker. Objects also makes it easier to create transactional systems that allows you to roll back, again a reliability advantage. No matter what domain you are in, if you deal with uncertainty then also you need a proven methodology and tools that suits the application domain you are working with. With no proven methodology, especially geared towards what you are doing, quality will become less predictable. If you have no need to maintain state modelling the environment, then of course, you would also not need objects and can choose dedicated tools with 100% verification of the implementation. Is that better? Yes clearly, when you can get away with it. The OP is relevant to D, because how people thing about objects and their representation affects language design and usage. You confirmed this yourself by stating that you dislike OOP because people are idiots and mess things up (which is the only reasonable interpretation of what you stated). But that is not a consequence of OO-modelling as a concept. It is a result of poor modelling or poor implementation or poor tooling.
I'm not claiming objects are generally bad. But OOP in general is a bad design strategy if you want efficient programs. objects bundle too many different variables together, so cache access is most certainly suboptimal. multithreading is another thing that's much harder to do when you start with an OOP model in mind. All these problems can be solved, at least to some extend, but IMHO it's not a good strategy for implementation. it's fine to model a system as OOP at first, restructure it to something more performant. But I don't think i have to reiterate the points against OOP here, there are numerous articles on the internet talking about it. Just to give you one example of a hilariously bad OOP implementation where you'd expect them to know better: chromium.
Jun 24
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 24 June 2022 at 14:30:54 UTC, Zoadian wrote:
 I'm not claiming objects are generally bad. But OOP in general 
 is a bad design strategy if you want efficient programs.
The Simula class concept is to a large extent meant to support changing the model later. So it is sensible for simulation where you experiment (programming cost being higher than hardware costs). This is basically where inheritance comes in. You have a working model, then someobody tells you: we actually need to model not only Doctors, but also Nurses, AmbulanceDrivers etc. How quickly can you accomodate that wish? This is also a strength of relation-based databases, just add more tables.
 All these problems can be solved, at least to some extend, but 
 IMHO it's not a good strategy for implementation.
I don't think existing languages have good support for hardware. C++/C requires the compiler to use the same layout for fields in a record as the source. That is a bummer for inheritance in terms of cache-lines, but that is not an OO weakness, it is a language weakness. If we talk high level OO, then there should be no hard relationship between the code and the layout (e.g. it could broken down to structs of arrays or arrays of structs or components etc by the compiler based on hints or analysis). Main stream languages are very primitive still… Outside of Rust, many languages seems to be satisfied by adding a thin layer over LLVM…
 it's fine to model a system as OOP at first, restructure it to 
 something more performant.
Sure, you can implement an OO-model in C or assembly. Most games of the 80s probably had some ad hoc OO-model implemented in clever ways in assembly to pack it into 32/64K RAM :-)
Jun 24
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 24 June 2022 at 15:14:44 UTC, Ola Fosheim Grøstad 
wrote:
 The Simula class concept is to a large extent meant to support 
 changing the model later. So it is sensible for simulation 
 where you experiment (programming cost being higher than 
 hardware costs). This is basically where inheritance comes in. 
 You have a working model, then someobody tells you: we actually 
 need to model not only Doctors, but also Nurses, 
 AmbulanceDrivers etc. How quickly can you accomodate that wish? 
 This is also a strength of relation-based databases, just add 
 more tables.
On a personal note: I also use have a default preference for OO when that makes it possible to avoid documentation because the implementation has a 1-1 correspondence with the model. Then you don't have to deal with out-of-date documentation and the boring task of writing documentation. This is also desirable when you evolve software rather than plan it (experimental prototyping or simulation). If you expect a lot of successive changes then documentation becomes a real burden.
Jun 24
prev sibling parent reply user1234 <user1234 12.de> writes:
On Friday, 24 June 2022 at 15:14:44 UTC, Ola Fosheim Grøstad 
wrote:
 I don't think existing languages have good support for 
 hardware. C++/C requires the compiler to use the same layout 
 for fields in a record as the source.
Please show me an alternative that allows to respect the substitution principle.
Jun 24
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 24 June 2022 at 18:08:15 UTC, user1234 wrote:
 On Friday, 24 June 2022 at 15:14:44 UTC, Ola Fosheim Grøstad 
 wrote:
 I don't think existing languages have good support for 
 hardware. C++/C requires the compiler to use the same layout 
 for fields in a record as the source.
Please show me an alternative that allows to respect the substitution principle.
The simple approach is to reserve space for the fields you want to be on the same cache line. The root cause for the C++ model is separate compilation. If the compiler knows the full class hierarchy then it can choose a different layout. That is obvious.
Jun 24
prev sibling next sibling parent reply forkit <forkit gmail.com> writes:
On Friday, 24 June 2022 at 13:48:35 UTC, Zoadian wrote:
 No disrespect, but this is a programming language forum, i'd 
 really appreciate if it stayed that way.
Actually, I was under the impression a moderator had locked this thread, as they decided it was off topic. But before they do that again, let me say this: (1) Philosophy is not a religion. It is a tool. (2) Philospohy and Programming/Programming Languages, are deeply 'entangled' whether you have the capacity to see to that level of detail, or not ;-) (3) the statement item (2) above is demonstrated throughout academic literature on computing. It's not something I just made up ;-) I was watching this fascinating talk by Matt Godbolt last night. 'CppCon 2018: Matt Godbolt “The Bits Between the Bits: How We Get to main()' https://www.youtube.com/watch?v=dOfucXtyEsU It's like he's deep within the quantum world of computing ;-) Of course, it gets even more quantum than that too... and seemingly, just keeps going... to what end .. I do not know.
Jun 24
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 25 June 2022 at 00:24:08 UTC, forkit wrote:
 (2) Philospohy and Programming/Programming Languages, are 
 deeply 'entangled' whether you have the capacity to see to that 
 level of detail, or not ;-)

 (3) the statement item (2) above is demonstrated throughout 
 academic literature on computing. It's not something I just 
 made up ;-)
There is a lot truth to that. The reason being, of course, that the users of the software are more important than the programmers… so you need to extract what users' needs are, communicate about it and turn it into something that is implementable (by whatever means). And you invariably end up with focusing on objects, processes and communication. When I went to uni we were trained to do relational modelling with NIAM, also known as… [Object-Role Modelling](https://en.wikipedia.org/wiki/Object-role_modeling)! Yes, you read that right, we deal with *objects* when modelling tables. To quote that wiki page: «An object-role model can be automatically mapped to relational and deductive databases (such as datalog).» It can of course also be translated into an OOA model. One key difference is that OOA "clusters attributes", but Object-Role modelling is "free" of attributes and focus on relations.
Jun 25
parent reply forkit <forkit gmail.com> writes:
On Saturday, 25 June 2022 at 20:06:45 UTC, Ola Fosheim Grøstad 
wrote:
 ....
 There is a lot truth to that. The reason being, of course, that 
 the users of the software are more important than the 
 programmers… so you need to extract what users' needs are, 
 communicate about it and turn it into something that is 
 implementable (by whatever means). And you invariably end up 
 with focusing on objects, processes and communication.
Actually the concept of programming is really, really simple: (1) You have objects (big and quantum size, they're all objects!). (2) You have interactions between objects (no object is an island) (3) You have processes whereby those interactions come about. (4) You have emergent behaviour (side effects if you will) - the program itself. The bigger the object, the more difficult it becomes to model it using quantum physics. The easier it becomes to understand the interactions, cause they're more visible (encapsulted if you will). The easier it becomes to identify the processes by which those interactions come about, cause they're more visible. And the easier it becomes to model what the emergent behaviour looks like, because it too is more visible. On the otherhand, the smaller the object, the harder it becomes to model it using the same object decomposition used with larger objects, the harder it becomes to understand the interactions, the harder it becomes to identify the processes by which those interactions come about, and the harder it becomes to model what the emergent behaviour looks like. The smaller the object gets, the less chance you have of understanding item (1), let alone items (2), (3), and (4). In the end, you end up with something like the linux kernel! It's just works. But nobody really knows why.
Jun 25
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 25 June 2022 at 23:11:18 UTC, forkit wrote:
 The bigger the object, the more difficult it becomes to model 
 it using quantum physics. The easier it becomes to understand 
 the interactions, cause they're more visible (encapsulted if 
 you will). The easier it becomes to identify the processes by 
 which those interactions come about, cause they're more 
 visible. And the easier it becomes to model what the emergent 
 behaviour looks like, because it too is more visible.
D is trying to position itself as a language where you start with a prototype and evolve it into a product. So you should ideally be able to start by composing generic (flexible and inefficient) components that give you an approximation of the end product. Yet representative enough to give the end user/developer enough of an idea of the final product to make judgments. Is D there yet? Probably not. It has ranges in its library and not a lot more. What is the core strategy for problem solving? Divide and conquer. Start with the big object (what you want the user to see) and then divide (break down) until you end up with something you have ready-mades to build an approximation of. The D eco system lack those ready-mades, that is ok for now, but there are two questions: 1. Can the D abstraction mechanisms provide ready mades that are easily configurable? 2. Is it easy to replace those ready mades with more performant structures? Can we say yes? Can we say no? Or maybe we just don't know. What is needed is a methodology with patterns. Only when we collect experience of developers using the methodology trying to apply those patterns can we judge what D is lacking with absolute clarity. What we have now is people with different unspoken ideas about development methodology based on personal experience and what they read on blogs. There is no "philosophy" for systems development that can drive the language evolution to something coherent. As such language evolution is driven by a process of replicating other languages by taking bits and pieces with no unifying thought behind it. Ideally a language would be designed to support a methodology geared to a specific set of use cases. Then you can be innovative and evaluate the innovations objectively. With no such methodology to back up the language design you end up randomly accruing features that are modified/distorted replications of features from other languages and it is difficult to evaluate if new features are supporting better development processes or if they create «noise» and «issues». It is also difficult to evaluate when your feature set is complete.
 On the otherhand, the smaller the object, the harder it becomes 
 to model it using the same object decomposition used with 
 larger objects, the harder it becomes to understand the 
 interactions, the harder it becomes to identify the processes 
 by which those interactions come about, and the harder it 
 becomes to model what the emergent behaviour looks like.

 The smaller the object gets, the less chance you have of 
 understanding item (1), let alone items (2), (3), and (4).

 In the end, you end up with something like the linux kernel!

 It's just works. But nobody really knows why.
Software development is basically an iterative process where you go back and forth between top-down and bottom-up analysis/development/programming. You have to go top down to find out what you need and can deliver, then you need to go bottom-up to meet those needs. Then you have to go back to the top-down and so on… iteration after iteration. So you need to both work on the big «objects» and the small «objects» at the same time (or rather in an interleaving pattern). Linux is kinda different. There was an existing well documented role model (Unix) with lots of educational material, so you could easily anticipate what the big and the small objects would be. That is not typical. There is usually not a need for a replica of something else (software development is too expensive for that). The only reason for there being a market for Linux was that there were no easily available free open source operating systems (Minix was open source, but not free). Interestingly, Unix is a prime example of reducing complexity by dividing the infrastructure into objects with «coherent» interfaces (not really, but they tried). They didn't model the real world, but they grabbed a conceptualisation that is easily understood by programmers: file objects. So they basically went with: let's make everything a file object (screen, keyboard, mouse, everything). Of course, the ideal for operating system design is the microkernel approach. What is that about? Break up everything into small encapsulated objects with limited responsibilities that can be independently rebooted. Basically OO/actors. (Linux has also moved towards encapsulation in smaller less privileged units as the project grew.)
Jun 26
parent reply forkit <forkit gmail.com> writes:
On Sunday, 26 June 2022 at 07:37:01 UTC, Ola Fosheim Grøstad 
wrote:
 D is trying to position itself as a language where you start 
 with a prototype and evolve it into a product.
D, by design, defaults to 'flexibilty' (as Andrei Alexandrescu says in his book - The D Programming Language. I don't think it's unreasonable, for me to assert, that flexibiltiy does not exactly encourage 'structured design'. But for a language where you want to 'just write code' (which seems what most D users just want to do), then D's default makes complete sense. 2 examples: If safe were default, it would make it harder for people to 'just write code'. If private were private to the class, instead of private to the module, it would make it harder for people to 'just write code'. I'm not against the defaults, necessariy. Valid arguments can be made from different perspectives. I much prefer to focus on advocating for choice, rather than focusing on advocating for defaults. But in the year 2022, these defaults don't make sense any more - unless as stated, your aim is 'to just write code'. I think this is what D is grappling with at the moment. To do structured design in D, you have to make the conscious 'effort', to not accept the defaults. btw. Here's a great talk on 'A philosophy of software design', by John Ousterhout, Professor of Computer Science at Stanford University. The talk is more or less based on the question he asks the audience at the start of this talk. Having not studied computer science (I did psychology), I was surprised when he mentioned 'we just don't teach this' :-( https://www.youtube.com/watch?v=bmSAYlu0NcY
Jun 26
next sibling parent bauss <jj_1337 live.dk> writes:
On Monday, 27 June 2022 at 01:35:59 UTC, forkit wrote:
 If  safe were default, it would make it harder for people to 
 'just write code'.
I don't think it would be necessarily harder, you'd just have to get used to a different starting point, but it should be fairly smooth. Just like today if you start your first module in your project with safe: then you essentially won't face many issues initially. Most issues will stem from things that aren't finished in D, but not from the general gist of safeD.
Jun 27
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 27 June 2022 at 01:35:59 UTC, forkit wrote:
 I don't think it's unreasonable, for me to assert, that 
 flexibiltiy does not exactly encourage 'structured design'.
Well, max implementation flexibility is essentially machine language. The 68000 instruction set is surprisingly pleasant. You can invent your own mechanisms that can make some tasks easier… but a nightmare for others to read. The more flexibility, the more chaos programmers will produce. You see this in JavaScript, TypeScript code tends to be much more structured. You see this in D code bases that allow string mixins too.
 To do structured design in D, you have to make the conscious 
 'effort', to not accept the defaults.
I don't think the defaults matter much.
 btw. Here's a great talk on 'A philosophy of software design', 
 by John Ousterhout, Professor of Computer Science at Stanford 
 University.

 The talk is more or less based on the question he asks the 
 audience at the start of this talk.

 Having not studied computer science (I did psychology), I was 
 surprised when he mentioned 'we just don't teach this' :-(
Too long… Are you suggesting that he said that they don't teach OO? OO is more tied to modelling/systems development than strict Computer Science though. Computer Science is a «messy» branch of discrete mathematics that is more theoretical than practical, but still aims to enable useful theory, e.g. algorithms. In Europe the broader umbrella term is «Informatics» which covers more applied fields as well as «Computer Science».
Jun 27
parent reply forkit <forkit gmail.com> writes:
On Monday, 27 June 2022 at 12:18:10 UTC, Ola Fosheim Grøstad 
wrote:
 ...
 Too long… Are you suggesting that he said that they don't teach 
 OO? OO is more tied to modelling/systems development than 
 strict Computer Science though. Computer Science is a «messy» 
 branch of discrete mathematics that is more theoretical than 
 practical, but still aims to enable useful theory, e.g. 
 algorithms. In Europe the broader umbrella term is 
 «Informatics» which covers more applied fields as well as 
 «Computer Science».
No. He specifically is against promoting any 'particular' methodology. His 'philosophy' of programming (like mine), is 'try them all' (or at least try more than one, and ideally, one that is radically different to the other), so you can better understand the weakness and strengths, of each. Only by doing this, can you put yourself in a position to make better design choices. The talk (and his book) is about getting programmers to not just focus on code that works, because that strategy is very hard to stop once it starts ('tactical tornadoes' he calls those programmers, as they leave behind a wake of destruction, that others must clean up). This (he argues) is how systems become complicated. And sooner or later, these complexities *will* start causing you problems. I think what he is saying, is that most programmers are tactical tornadoes. He want to change this. The long-term structure of the system is more important, he argues. He is saying that CS courses just don't teach this mindset, which I found to be surprising. That's what he's trying to change. I like this comment from his book: "Most modules have more users than developers, so it is better for the developers to suffer than the users.".
Jun 27
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 27 June 2022 at 22:48:35 UTC, forkit wrote:
 No. He specifically is against promoting any 'particular' 
 methodology.
Yes, you choose methodology based on the scenario. A method uses many different techniques. The point of a method is to increase the successrate when faced with a similar situation, not to be generally useful.
 He is saying that CS courses just don't teach this mindset, 
 which I found to be surprising. That's what he's trying to 
 change.
Well, they do say it. You cannot teach beginners everything at once. Most students are beginners. So you need many different angles, spread over many courses. Given the amount of theory the time for practicing skills is very limited. You can teach students techniques, but you cannot teach them intuition, which takes decades.
 I like this comment from his book:

 "Most modules have more users than developers, so it is better 
 for the developers to suffer than the users.".
Yes, the common phrase is that code is read more frequently than written. Students however, feel they are done when the code runs. Only a small percentage are mature enough as programmers to refine their skills. And that top 10% doesn’t need the teacher... only the book and the assignment. Or rather, there are not enough resources. It takes time to mature ( measure in decades ) and in that time people will develop patterns. Only 5% of students are at a high level in programming IMHO. Anyway, in the real world projects are delayed and code is written under time pressure. To get a module «perfect» you need to do it more than once. Very few projects can afford that kind of perfection, nor do they want programmers to rewrite modules over and over. Perfection is not a goal for applications. Only libraries and frameworks can try to achieve perfection.
Jun 27
prev sibling parent reply forkit <forkit gmail.com> writes:
On Friday, 24 June 2022 at 13:48:35 UTC, Zoadian wrote:
 ...
 And to add something to the topic. objects are a great why to 
 think about things. they are, as it turned out, not they great 
 in programming.
 OOP leads to slow, hard to reason about code. it encurages 
 mutable state, spread across the whole programm. it's 
 essentially global variables all over again, just hidden behind 
 a layer of obfuscation.
 It also makes testing a lot harder to actually implement.
 That being said, there are cases where it's ok to use, but imho 
 they are incredibly rare.

 - Someone who works on hard realtime systems
I think if we put these claims to the test, they would be found wanting. I'd also love to see, what a non-OOP program would look like, if one were completing this assignment, with the use of objects. Certainly possible, no doubt. You could do it in C. Hell, you could do it in Assembly. But would you? https://solidsoftware.com.au/Tool/Software/AI/Agents/TrafficAgents.html That assignment, is minisule, compared to software projects being untaken everyday, all around the world.
Jun 25
next sibling parent forkit <forkit gmail.com> writes:
On Saturday, 25 June 2022 at 09:29:09 UTC, forkit wrote:
 I'd also love to see, what a non-OOP program would look like, 
 if one were completing this assignment, with the use of objects.
Correction: The previous post should say 'without the use of objects' ;-)
Jun 25
prev sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Saturday, 25 June 2022 at 09:29:09 UTC, forkit wrote:
 I think if we put these claims to the test, they would be found 
 wanting.

 I'd also love to see, what a non-OOP program would look like, 
 if one were completing this assignment, with the use of objects.
Probably the most common "non-OOP" way of organizing data is to use tables. You see tables most commonly in relational databases, but also in data science (where they go by the name "data frame" [1]) and in low-level code using so-called "data-oriented design" (where they go by the name "structure of arrays" [2]). Whether tables or objects are a better way of organizing data is a decades-old debate that I have no intention of wading into here. Regardless of which you prefer, you must admit that both tables and objects have a long history of successful use in real-world software. [1] https://www.oilshell.org/blog/2018/11/30.html [2] https://en.wikipedia.org/wiki/AoS_and_SoA
Jun 25
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 25 June 2022 at 18:05:31 UTC, Paul Backus wrote:
 Whether tables or objects are a better way of organizing data 
 is a decades-old debate that I have no intention of wading into 
 here.
What debate? You can easily represent objects in a relational database. One table for the superclass, another one for the subclass extension. The main discussion has really been about whether you want relational or hierarchical structure. The latter is better for performance. It is fairly easy to distribute objects or hierarchical, but relational is harder, yet very flexible. Keep in mind that XML databases often are implemented as relational tables, and you can represent objects as XML with ease… The real clash is really with lower level languages adding OOP, really improve a whole lot on the runtime organization over Simula. Which is sad. Still primitive in other words.
Jun 25
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 25 June 2022 at 18:23:20 UTC, Ola Fosheim Grøstad 
wrote:
 The real clash is really with lower level languages adding OOP, 

 really improve a whole lot on the runtime organization over 
 Simula. Which is sad. Still primitive in other words.
In other words, C++ messed up OOP by exposing the implementation and thereby depriving the compiler from optimization opportunities. OOP does *not* dictate a particular organization in memory.
Jun 25
prev sibling parent forkit <forkit gmail.com> writes:
On Saturday, 25 June 2022 at 18:05:31 UTC, Paul Backus wrote:
 ...
 Whether tables or objects are a better way of organizing data 
 is a decades-old debate that I have no intention of wading into 
 here. Regardless of which you prefer, you must admit that both 
 tables and objects have a long history of successful use in 
 real-world software.
When people see something as challenging their belief, they do tend to dig in, and turn it into a lonnnnggg debate ;-) But really, OO decompostion is just a tool. It's not an idealogy (although many throughout computing history have pushed it as such). It's just a tool. That is all it is. Nothing more. It's a tool you should have the option of using, when you think it's needed. A screw driver makes for a lousy hammer. Just pick the right tool for the job. If you're trying to model a virtual city, you'll almost have to use object decomposition. I mean, it makes complete sense that you would. Of course, you could model it using logic chips - but why would you? On the otherhand, if your writing a linker, it doesn't seem like OO decomposition would have any value whatsoever. People need to be more pragmatic about this. Programming paradigms are just tools. They should not be used as the basis for conducting idealogical warfare against each other ;-)
Jun 25