[ Draft ]
More fundamental principles:
- Something about Symbol being a generic way to view the computer & the internet.
I am quite convinced that Symbol can serve as a view on the contents of your computer just like a file system. I'm sure that Symbol, aside its usual symbolic view on the system, accompanied by tree views, list views, data relational diagrams and UML-like diagrams, can serve as a single, completely integrated view on the contents of a computer system.
Software System
It is a database technology turned into an operating system.
It is a programming language turned into a user interface.
It is a programming language turned into a database technology.
I once struggled with the same contemplations, and it's just none of the above. It replaces database technology, programming language, and OS by a single system.
JJ
Space won't have files,
it might have objects
it won't have folders.
It might have objects and collections
What used to be files, might again contain objects.
Software System
Je moet op een of andere manier toch alle inhoud van je computer in een standaard view, waarvanuit alles bereikbaar is hebben, ondanks het flat & structured interchange verhaal. Want anders krijgen veel mensen het gevoel dat het een losvast geheel is, waarin je nooit het totaalbeeld ziet. Goh, computer en internet is hetzelfde, maar een persoon heeft toch z'n persoonlijke spul. Je moet ze een invalshoek geven waar alles dat volgens hun belangrijk is direct of indirect te bereiken is, zonder selecties of zoekopdrachten te doen.
JJ
Software System:
Perhaps if you make user remember:
"You can view any object in the standard way you want to.
If you are at somebody else's computer, and you are unfamiliar with the way the object is presented, just switch to the standard view that you do know, and you might be comfortable with it again."
But then formulated easier. Make any user remember such meta facts, and most of them may be able to handle any digital object.
JJ
Some of these fundamental principles might be user interface, and should have a more general description for a fundamental principle. But that may prove itself later.
JJ
Je moet bedenken dat bepaalde modules van me, geembed raken in de programmeeromgeving. Zo zal security inherent deel gaan uitmaken van de programmeeromgeving. En web objects zal erin geembed raken, voor web functionaliteit.
Waarschijnlijk gaat Graphics erin geëmbed raken om custom user interfaces te ontwerpen.
Er zal dus veel inherent deel uit gaan maken van de programmeeromgeving.
< But this is what fundamental principles is about: most of them are not an element of the system, but something for which multiple elements of the system might collectively provide a solution. >
Objects whose primary task is an action.
Objects whose primary task is data.
Methods that the object performs.
Methods that are performed on the object.
(sounds like patterns)
I WANT any operating system or database I program not to be bothered by having a 10000 simultaneous connections, trouble with all sorts of time-outs or locks.
So I am going to think of a solution for that, without bothering a programmer with it. I only want to be bothered mostly with the structure of the program, and not with too many connections and timeouts and stuff like that.
J Code
Ik weet niet hoeveel programmeurs hebben alleen programmeer technieken van 20 jaar terug, en meer niet. Geen objecten, geen data types aangeven.
JJ
Circular,
I like mechanisms, that control themselves, instead of having to control the mechanism yourself.
JJ
The fundamental principles of other programming languages may not be so fundamental in Circular. For instance basic math may be considered fundamental in other programming languages, but it’s no more than a plug-in module in my own system. Another example: type safety may be considered fundamental in other programming language, but in my own system it is a plug-in aspect, which sees to it an object’s type is checked before it is assigned to an object reference.
Extensibility principles.
Nu ik van code generation af stap en ga voor generieke objecten, die veel makkelijker zijn, is het ook veel makkelijker mogelijk, dat mijn ideeën worden afgejat. Als het grootse Creator dan echt zo veel makkelijker wordt om te maken, dan is het nog makkelijker na te maken. Ik weet het allemaal niet zeker hoor, of het zo makkelijk is.
Perhaps you can’t make clear stories out of the Fundamental Principles yet, because the parts I had not thought about yet turn everything inside out. They require me to go into detail, while fundamental principles was only to give an overview.
Some of the Fundamental Principles are very clear. Some are not clear yet. The articles of the unclear Fundamental Principles might be full of details after you write them. Lateron the details might moved to other articles about the other principles and aspects, that the details are about. The Fundamental Principles should eventually only give a summary and the correlation between other principles and aspects.
Eventually in the explanations of the fundamental principles, everything should fall into place, and everything should be explained in a clear-cut way. It should be a complete introduction to my ideas, so it should make a person acquainted with the material.
- Revise the article Symbol = Creator
- Internet as a single computer has to be revised
- Move details in the articles to specialized articles and turn the Fundamental Principles articles into summaries.
Flat & Structured Interchange,
In Flat & Structured Interchange the flat part is what’s physically stored, while the structured part is imaginary, and derived from the flat part.
JJ
Circular,
Je zou aspecten van de computertaal kunnen in- en uitschakelen, zodat het behapbaarder wordt voor bepaalde mensen: kinderen of echt programmeurs. Je zou kunnen laten zien welke aspecten van de computertaal zichtbaar zijn, en welke er geprogrammeerd kunnen worden. Uitgeschakelde aspecten van de taal, worden of niet weergegeven, of op met een alternatieve, vereenvoudigde notatie weergegeven.
JJ
Automatic diagram metrics is a fundamental principle.
Exchangeability,
Benadruk ook in je Fundamental Principles, dat OO, relationele database, file system, registry are all replaced by a single object system.
JJ
Equality principles,
2008-08-04
Internet is one program
JJ
Aspects / Achievability,
2008-08-08
Denk eens een keer na over, dat een ander je een aspect, bijvoorbeeld Find en een Find Control, moet kunnen vervangen door een betere.
Daarmee creëer ik toch netjes een markt met concurrentie, er niet vanuit gaande dat ik altijd alles het beste programmeer, en niemand ooit met iets beter zal komen.
Hoe kun je het programmeurs makkelijk laten omcoderen om toch nog de oude interface van de oude Find te kunnen gebruiken?
Hoe kun je mensen zelf een systeem laten inheriten, iets disincluden en een aspect erbij zetten, om zo een beter systeem te hebben?
JJ
Circular,
Fundamental Principles,
2008-09-12
- You are always in transition.
You are never completely switched over to the newest technology, because before you are, there already is even newer technology available. - There is always a slight overhead in complexity.
Because the structure of a system always has a legacy of the past. Even when you got rid of the overhead in complexity, you only need to wait a small amount of time, for structuring decisions to become outdated.
JJ
Circular,
2008-09-08
Circular is pretty much the opposite of the tendency towards natural language syntax. It is also the opposite of the tendency towards domain specific languages.
JJ
CL,
2008-09-16
It happens a lot that something that earlier an object was bound to a single other object, and now a single object needs to be bound to a list of objects, with the same function.
n-iffication
JJ
CL,
2008-09-18
"Convention over Configuration" means a developer only needs to specify unconventional aspects of the application. For example, if there's a class Sale in the model, the corresponding table in the database is called Sales by default. It is only if one deviates from this convention, such as calling the table "products sold", that one needs to write code regarding these names. In general, this might lead to less code.
> I actually had trouble with the automatic configuration in the code generator experiment 0.9, that easily lead to ambiguities, and unwanted automatically made decisions. But perhaps it could be made better.
JJ
CL,
2008-09-22
Er gebeurt echt vanalles in die computer en er gebeurt vanalles met allerlei data. En ergens in het systeem zitten van allerlei instellingen en bij sommige kun je niet eens bij met een user interface, omdat ze de user interface erbij 'vergeten' zijn, en je de instellingen alleen via een API functie kunt bereiken.
Ik vind dat echt vervelend. We zijn gewoon blind. En ik probeer een exacte visualisatie te creëren van wat er precies allemaal in die computer zit, en wat er allemaal precies ingebeurt, en wat er allemaal in het netwerk gebeurt, zonder ongewenst te worden afgeschermd voor bepaalde zaken. Je kunt op applicatieniveau kijken, op documentniveau, op machine niveau, op hardware niveau en op netwerkniveau zien wat er aan data is, hoe alle objecten met elkaar verbonden zijn, hoe de commando's hun werk doen, en wat er door een commando of programma geraadpleegd wordt en wat er door een programma wordt weggeschreven.
Je kunt gewoon naar alles wat de computer doet heennavigeren om het te visualiseren. Je kunt zelfs de werking visualisatie zelf visualiseren, door naar die runnende module te navigeren, en de activiteit te bekijken. Als je wil weten hoe de grafische kaart daarbij wordt aangesproken, kun je dieper navigeren naar hardware niveau en zien wat er allemaal in en uitgaat.
JJ
<
I have explained all possibilities of the language, but there simply are things you’ll use more than others. In my former explanations for instance it seems that using object lines is just as common as using type and interface lines. However, you’ll find, let’s say 20 times more object lines that you might find type lines. You might even write a whole module without any interface lines at all.
So some topics of the language might be complex, but used only incidentally.
Exclusion, that is, a container’s exclusion of members of its children, doesn’t need to be used a lot. In fact, other programming languages I know don’t even have this capability at all.
Etcetera. Symbol might become much easier when you find what’s used most and what things are for incidental use, no matter how complex the topics you’ll use incidentally are.
You can write programs in which you have no notice of any system aspect command at all. In programs in which you do work with system aspect commands, you might not notice the presence of all aspect commands, just some.
>
< remember that I can only explain how to program structurally using the systems I’ve programmed as an example >
I’ve called this chapter into existence, because I want to write about programming methodologies.
Fundamental Principles,
2009-08
If people find the notation difficult after all, say: that is what we thought about textual computer code once. But we all got used to it. And now we can read each other’s code. When you make a program with diagram code, the code might be clear to you when you make it, than reading someone else’s code. And just as with textual code, you might learn to read other people’s code.
JJ
Fundamental Principles,
2008-10-16
I am analyzing crap code at work now, and I remember why I ever came up with the diagram notation. I might do vast analyzing to see what calls upon what, and what input is transformed and passed on to which parts of the system. In the diagrams you get that information basically for free. So that might be the background of this language: the code is the analysis, and more specifically put: you can immediately see which parts are linked to each other and make use of each other, and what input and output goes where.
JJ
Fundamental Principles,
2008-11-05
It may be a fundamental principle, that all references are registered. It may also be fundamental principle, that possible bad behavior should not compromise your abilities for good behavior. So the use of your creativity should not be put to a limit by possible bad behavior of others. If you can make a system that completely work following these principles, than that might be great.
The Fundamental Principles can be guarantees the system might give and should not be broken.
JJ
Fundamental Principles,
2008-11-05
The bad behavior principle is why registration of all references SHOULD be designed for good practice to work, without having to consider the bad behavior. Deterring bad behavior should be completely separately addressed, because also in the design of Circular, bad behavior should not might be considered, because it it may not compromise my creativity by having to think about all sorts of possible bad behavior as I try to design a language to do good with. Programming USING the language should be the same: you should only might separately address possible bad behavior, not while you are designing a system that works for good behavior.
JJ
CL,
2008-11-13
Als allerlei dingen aan elkaar gebonden zijn in een systeem, waarom zitten we dan allemaal coderegels te bestuderen en niet gewoon aan elkaar gekoppelde objecten?
JJ
CL,
2008-11-30
It happens a lot, that a design pattern already existed for a long time, but only gets popular, when you make it an actual language element. So all good patterns might be present in the programming language itself, or the whole world of software development might not use it at all and might lag behind on progress that already took place.
JJ
Circular,
2008-12-22
That Aspect construct I want in my programming language seems to have existed forever:
Extensible Compiler Architecture | Examples from JModelica.org | Uses of the JastAdd systems | Görel Hedin | Computer Science, Lund University
newer link 2021-03-06
It seems, that the problem with good concepts, such as Aspect Oriented Programming and design patterns, is that they are not used, because they do not become part of the programming language. Those ideas could be made part of the programming language, but instead they are introduced as methodology. If they are made part of the language, then hobbyists might be more likely to use it.
Many beautiful concepts come up with in the 70's, 80's and 90's are not used, because not enough people know about it. Many of those concepts could be made part of a programming language itself, so that more people, trying out programming, are tempted to experiment with them. If they don't have it available in the language, many concepts might be forgotten about, and the whole proffession of software programming lags behind on itself.
That is why I need to get myself educated about all the ideas, that already existed, so that I know how to give them a place in my own programming language. I need to converge existing ideas, and turn them into new products. That should be my job, rather than just reinventing everything. That might make me more effective in my job. I should be less individualistic. I can do much better work when I use ideas, that already existed before I was born. Those people were not being silly.
JJ
Circular,
2008-12-22
I ask myself if anything original is left to my language, when I orient myself into existing ideas.
It is sort of soothing, though, that I am not doing everything by myself, but are just recombining existing ideas.
JJ
Circular,
2008-12-22
Als hedendaagse programmeertechnieken zo geweldig zijn, waarom is alles dan nog steeds zo'n haperende troep. Met name als je aan het programmeren bent.
JJ
Circular,
2008-12-23
Heel veel van die dingen kom je gewoon niet vanzelf tegen. En dat is jammer. Want zo leren de meesten programmeren: door dingen vanzelf tegen te komen. En dat stimuleer je door het in de taal zelf op te nemen.
JJ
Software Development,
2009-01-16
Dat electronic sheep geeft me echt het gevoel, dat als software niet afgrijselijk mooi is, het eigenlijk geen indruk maakt.
JJ
Circular,
2009-02-12
You can put a breakpoint on members of specific objects, not just a member of a class. Just as well you can put a breakpoint on any data member’s get or set commands or other system commands.
JJ
Circular,
2009-02-12
‘Not too much derivation’ could be a Fundamental Principle, for the same reasons as Lack of Choice = Guarantees.
JJ
Commands / Circular,
2009-03-13
What if you can say: I want a command on that object, that calls that program's this and that command. The reason programming is hard, is because programming languages are too hard. The user knows what he wants. Why is it any more difficult to realize something on the computer, than to just tell the computer what it is you want?
JJ
Circular,
2009-03-13
Folders, containing files and other folders? Presented in a tree structure without it even actually looking like a tree? Why is it you are presenting only the IDEA of containment, and not how containment actually looks?
JJ
Circular,
2009-03-13
Icon display and double clicking on them, showing THEIR contents, is ALMOST what I want to see regarding containment, except, that you might actually see the zooming in animate.
JJ
Circular,
2009
Zodat software ontwikkelaars nog minder weten van wat er op fysiek niveau gebeurt... Op zich wel mooi om je op conceptueel niveau bezit te houden, maar het creëert ook meer afstand ten opzichte van wat er fysiek gebeurt. Dat heb je al met SQL. Dat wordt niet per so nog erger met LINQ, maar dat houdt het wel in stand. Er zijn al tal van programmeurs, die verrotte queries schrijven en daarna de database de schuld geven, omdat ze geen flauw benul hebben van wat er onder water eigenlijk gebeurt. Het beste snap je zowel dingen op conceptueel niveau, als de fysieke uitvoering ervan. Ik zie daar wel een voordeel van mijn eigen taal in. Die verbindt die twee en maakt ze even toegankelijk.
JJ
Circular,
2009-03-31
Who is this guy: http://strlen.com/index.html
Perhaps that guy built a model around the OpenGL library. He's probably just a darn-good programmer too.
JJ
Circular,
Fundamental Principles,
2009-03-31
It is possible to program as simply in assembly as you do in Circular, but in Circular you are more dictated to work within a certain paradigm. You can apply the paradigm in assembly language too, but in assembly you can more easily break those rules. In Circular the rules are more imposed. Actually, in Circular you are also not obliged to do it that way.
In an object oriented language you can still program procedurally, but it is just, that objects and classes are a programming construct of an importance equal to that of commands.
In Circular it is the same way:
relations and aspects are programming constructs of equal importance, but you might not use them. Nevertheless, they are so present as a programming construct, that you start to use them anyway.
Actually a lot of programmers took a long time to realize what they need classes for to program with.
But they have been applying them for years, because they have been USING classes. They just hadn't been programming classes.
In Circular it is the same way: aspects, relations and objects and commands and everything are clearly present in the framework libraries. You might be using them before you start to program them yourself.
In assembly, you could program in an object oriented way with classes. It is a matter of working in a certain fashion and yes, the syntax looks much different, but you are still modeling with classes and objects.
JJ
Circular,
2009-04-08
Just about everything in text code is reference by name. You do not physically see connections between things. The correspondence of names creates the connection. That is what is hard about analyzing existing code.
JJ
Circular Language Spec,
2009-04-16
A user-defined order number of a user-defined sorting, and the use of aliases prevents dead links. You could also do a kind of automatic aliasing: when a link is not found, the history of that link might be stored inside the container of the leaf, and this could be used to offer a suggested new linkage, when the dead link was attempted to be accessed.
JJ
NCL Fundamental Principles,
2009-04-20
Connections between system elements in text code are ALWAYS established purely through name correspondence. That's one of the problems with analyzing text code. You might acquaint yourself with the names, before you can start to understand the connections between things. And through those connections, understanding which are main things, which are less important things, which are big things, which things are unused and what are the first things or prime things, that a program might. An understanding of those things is what the result of such analysis is. Text code alone never reveals such information immediately, so understanding text code is always accompanied by either explanation through documentation or by analyzing the code.
In diagrams, the connections and the prominence of things are already visible to the naked eye, so the connections and hierarchy between things are apparent at a much earlier stage (more or less immediately), when looking at other people's code.
One thing, not apparent from text code OR diagrams is: WHY. Diagrams display the workings of a system, but not what we need those workings for. For that you still need documentation.
Constructing text code to be totally self-documenting in my view is a total lie.
JJ
NCL Fundamental Principles,
2009-04-20
Code along with comment can not easily point out things like the following. Simply: where might the program start? What are the prime things the program might and where might it do it? What prime components is the program composed of and how do they relate to each other?
WHY is the program structured like this? What is the program FOR?
The only way to add this to the code, in my view is to add a txt file, named ReadMe.txt or something and tell those things there.
JJ
CL Fundamental Principles,
2009-05-14
The problem with learning to understand how computer works, by just playing with it, is that what really happens inside the computer is invisible.
JJ
Circular,
2009-06-12
All we are working with is just feedback from what is really going on inside the computer. We are just tapped in and only tap off some of what's going on inside that thing.
JJ
Circular,
2009-05-02
I might not have a good spot or good explanation about how assembly seamlessly integrates into the language. This is part of the achievability principles, but also makes use of the Binaral aspect and the Value aspect too.
JJ
Fundamental Principles,
2009-06-14
Hoeveel van die beloftes worden al waargemaakt in de coding aspects & data aspects?
> Anders denken ze: "Jij praat poep".
Zou je na het uitwerken van Input / Output NOG een belofte kunnen doen, aangaande concurrency resolution?
JJ
Internet,
2009-08-14
"Code is data, and it always has been | Written by Piers on 2008-04-07"
Possible response:
I think you are putting to much effort into answering this question. I might put it more bluntly. 'Code = data' is not an idea. It is a fact.
It is character data or binary data, with a certain format, that can be interpreted by the computer. It is a description of linkages between program elements. Not much different from a spread sheet, which is also contains linkages between data and stuff that can be executed.
Code is merely data, that describes a program.
You do not need reflection or code generation for that to be a fact. It is what it is: data that describes a program.
JJ
Fundamental Principles,
2009-08-18
Data wordt heen en weer geflipperd, en commando's delegeren allemaal naar elkaar door. En soms delegeren en er een beetje veel commando's naar elkaar door, en flippert er een beetje veel data heen en weer. Complexiteit noemen we dat dan. En als er te veel complexiteit is ten opzichte van de functionaliteit, dan noemen we dat spaghetti.
JJ
Ideas,
2009-10-28
The word architecture is something I also do not want to hear.
JJ
Fundamental Principles,
2009-12-02
Of mensen flyers krijgen is afhankelijk van betalingsachterstanden. Het grappige is, dat als je erover rapporteert en je kent de logische verbanden van de twee eigenschappen niet, dan kom je er misschien gaandeweg per ongeluk achter, dat de twee verband houden. In NCL zie je het verband (makkelijker), omdat je de koppeling tussen de afweging en de velden ziet. Je ziet dus een indirecte koppeling tussen de twee velden, omdat je de programma logica ertussen ziet. Is dit zo? Zie je in de diagrammen ook indirecte verbanden snel? Net zoals je directe verbanden snel ziet?
JJ
Fundamental Principles,
2009-12-02
Als dingen in het programma dicht bij elkaar staan, zie je het misschien wel, maar ik zou misschien in de toekomst meer mogelijkheden willen zien om indirecte verbanden zichtbaar te maken.
JJ
Fundamental Principles,
2010-05-07
If everything starts out freely definable, then you make a system by creating restrictions. So systematics are defined through restrictions. If there are not restrictions, you can program anything programmable. After you create a system of classes, someone else may create a system of objects, in which not everything is programmable, but only very specific things are programmable.
JJ
Fundamental Principles,
2010-04-25 ~
How might Aquima impose rules. No, back to Circular. Everything is possible with all the constructs available. But awareness of all the construct should inspire you to pick the right solution in the right situation. And now Aquima. You always might pick one out of 5 first. In a way, in Circular, you always might pick one out of 12 first, or something. You might pick a construct... I am not going to brainstorm more about these fundamental things. I can not get my head around it right now.
JJ
Fundamental Principles,
2010-02-17
To defend the references lines vs. name correspondence you can say that even small programs consist of tens of thousands of references. Each operator, function call or variable reference is a reference. So basically a typical code line consists of between 3 and 20 references.
JJ
Fundamental Principles,
2010-03-25
Take the following question: There is a function. What other functions use it, and which functions use those functions?
This is a question that often needs to be answered when you analyse existing computer code. And this is a difficult question to answer. In most programming environments answering this question requires extensive analysis of the code, even when you have a tool for searching references. It gets worse if there the involved functions are not only used internally by a program, but also used by yet again other programs.
The diagram notation of NCL actually makes this otherwise difficult to extract information visible instantly. This is a big benefit of the NCL.
You might use coloring to make the information pop out of the diagram, but using the diagram notation it is evident how to easily highlight this.
JJ
Fundamental Principles,
2010-03-25
To prove the usability of the diagram language, the best thing to do is to be able to apply the notation inside existing environments and apply it to existing code and programs. Then it becomes evident where the benefits are.
JJ
Fundamental Principles,
2010-03-19
Kwaliteit, correctheid en elegantie de eisen waaraan een computerprogramma moet voldoen? Dat was 50 jaar geleden. Ik ben geen brave volgeling. Ik heb daar een andere visie op. Ik zeg: Bruikbaarheid, effectiviteit en eenvoud. Dat zijn de eisen waaraan een computerprogramma moet voldoen.
JJ
Fundamental Principles,
Low and high coupling,
2010-04-16
> Turns out that the definition of low-coupling I use here is not the one generally used.
I have found two definitions of the term low-coupling: One definition is a system's actually being composed of less connections. Another definition is connecting systems through interfaces, with limited and defined sets of members.
> And I found more definitions later.
A combined (mis)conception is that both are the same thing.
The first definition is actually what it should mean in my view: a system's being composed of less connections. In the story below I try to explain why communication through interfaces might not necessarily mean that the system is composed of less connections.
What low-coupling tries to solve is limitation of (possible) connections to create clarity about how systems interface with each other.
In high-coupled situations any system element could potentially be accessing any other system element, while in low-coupled situations systems only access each other though defined interfaces: a set of accessible system elements, while the rest of the system is not accessible.
This is handy for being able to change the way systems connect to each other, when for instance a piece of the system is discontinued or replaced, or to offer an easy way to connect new pieces of system to existing interfaces.
I think the terms loose coupling or high coupling are inaccurate terms. I think a better way to describe it might be clear coupling or unclear coupling.
The thing with high and low coupling is not necessarily that there are more or less connection points in either situation, but that in case of what is called low coupling, it is clearer to see at what points systems connect and a limit is imposed onto at what points systems could connect.
There is something some programmers might fail to see in case of high-coupling. The argument against it is: any member could be accessing any other member. But the thing is: any member is not accessing any other member, it is just not easy to see which members access which other members.
There is also something some programmers might fail to see in case of low-coupling. Programmers may tend to see the number of interfaces as the absolute number of connections. However, there are many more connections as interfaces also have disparate members, that can be separately connected to.
Each connection to a member of an interface is a separate connection. Each method call, call upon a data member, filling in of a parameter, assignment, indirection, etcetera, is a connection. Those connections are there in either low-coupling or high-coupling situation.
In fact, if you make an interface, but you make it too elaborate, you end up with a highly coupled situation again: any member of the interface could be connected to and you can not easily see which members are used and which are not. In an elaborate interface it is still not clear which which members access what other members. While supposedly there might only be one connection. But not really then is it?
In a finished system in either a high-coupling or low-coupling situation, both situations actually show the same number of connection points between members, variables, etcetera.
So low coupling might not really mean less connection points, just clarity and limitation of the possible points of connection.
Low coupling: the interfacing is clear and constrained. High coupling: the interfacing is not easy to see and it is not defined which members are potentially accessed in later sofware developments.
The problem with allowing more possible connections is that potentially more connections are made, but that might not mean that this is necessarily what is happening.
What's forgotten, is that if you connect to a single interface, you do not really have one connection. There can be many connections to the numerous parts of the interface.
The term low-coupling is even in contradiction with itself. Given a finished system, the supposedly high-coupled version might actually contain less connections, than the low-coupled version. The low coupled version might contain more connections, because on top of the members accessing each other, they are separeted by interfaces, creating more indirections between their connections, and these indirections are connections in itself. You first need to connect to the interface, and then you connect to the member.
Theoretically in a low coupling situation there are actually more connections, because instead of connecting to a data member directly, first there is connected to an interface, and then to the data member, and maybe even not directly with the data member, but with some adapters in between. So actually, in a finished system low coupling may have more connections than the high coupling variation.
So low-coupling and high-coupling are the illusion of having less connections. The situation solved by low-coupling is not having less connections, but having more insight and control over those connections. Insight into the connections in an existing system, and control over the possible connections when a system is changed.
There is another thing that might not work well in low-coupling, while it should actually be the stuff that low-coupling should be solving. If a low-coupled situation changes, you might end up with a lot of unused interface members, of which you can not easily see that they are not required anymore. So that is the inverse of not knowing what is used: not knowing what is not used anymore. So you have a cluttered interface with members that are not used of which you do not know that you could remove them. When you have an interface, and only 5% of the interface is still used, you still have the same problem as in the highly coupled situation: you have a ton of members and you do not know which are accessed by what.
Low-coupling is there in order to be able to know how systems interface and to be able to facilitate controlled changes inside those systems.
It is about readability, not about the actual absolute number of connections.
I think the coupling and cohesion are irrational words, because the number of connections is not less in a supposedly low-coupled situation, the number of connections is actually greater, only the ways systems are connecting to each other are defined in a way clearer for a humans to read and connections are restricted for the sake of future changes. It is actually more about readability than anything else.
Whether you connect to members directly or group the connections into interfaces: all the connections are still there, actually you have increased the number of connections by first having to connect to the interface.
NCL might solve this for a great part and easily show that the low-coupled (high-interfaced) version actually has more connections than the high coupled (low-interfaced) version. In NCL the readability of the highly coupled system might be better than in other languages, especially when the lines might be regroup as they go from sources to targets. I just forgot how valuable that part of the notation could be when it comes to reading how systems interface with each other. Each grouping of lines could potentially be replaced by an interface, only then you might end up with too many interfaces again. NCL with the use of regrouping of lines as they go from sources to targets might make it easier to automatically explicitly define the interfacing points, or make it easier to spot a place in the system in which it looks appropriate to create an interface in between. But if you create a derived interface for each user of an interface you have actually applied to concept of low-coupling, yet you have created more complexity by creating an insane amount of interfaces.
Clearly defined interfaces are still valuable in NCL, and do not all of a sudden become unnecessary, but they DO create more connections, rather than less if you put more interfaces in between. However proper interfaces can make the system more readable.
(Low-coupling is not the same as encapsulation. But both are solved using interfaces. Both low-coupling and encapsulation (data-protection) are concepts that are applied using the concept of interfaces, but they attempt to solve different problems, so they are not the same thing. Low-coupling should be about complexity reduction or complexity tangibility, encapsulation should be about data protection and stability. So one is about understandability of a system, and the other is about how easily we can thump over a system.)
So the technique of low-coupling might not create less connections. So low-coupling it is not an exact science of creating less connections, because putting an interface in between actually creates more connections. It is about limitation of complexibility, tangibility of complexity and prevention of complexity. The low-coupling techniques can help in this, but going too far with it actually create more complexity, people just forget to count the actual connections and only count the interfacing points over which multiple connections can be made. Furthermore, the rules of interfacing are not enforced by the machine, but by human hand. You might not devise a system that prevents complexity, it might be humans that prevent complexity, by making things more readable for himself, making it less likely for humans to break their own rules, and humans imposing rules onto another human beings.
Programmers may get emotional, irrational and upset, when you state that low-coupling is not an exact science and not necessarily required. Someone may irrationally think it is an exact science, because they are selectively forgetting and imagining connections that are or are not there, because in their head they select a set of connections and forget about connections that are still there.
It is a clear case where programmers think they are dealing with an exact science, defend it to the death, while they are only dealing with things that are esthetic and simply make things more readable and tangible through the coding techniques available today.
But a programmer might be yelling: "That is the wrong way to go, because it creates a higher degree of coupling!", while in reality, they are just arbitrarily imagining or ignoring certain connections. For a good cause though.
JJ
Fundamental Principles,
Low and high coupling,
2010-04-16
Actually designing a system in which one component uses a very sober set of member of another component, thus limiting the number of connections in the design.
It is not the interface that solves it, but the fact that you use a sober set of members. The actual low degree of connections from one module to the other makes it low coupling regardless of an interface being in between or not.
JJ
About coupling,
2010-04-16
Reducing Coupling | Martin Fowler
JJ
Coupling,
2010-04-16
There are more definitions to low coupling:
- Using a mutual interface for multiple types of objects, so that the consumer is not bound to the classes, but to the interface.
- To prevent having to change n things, you let them refer to a bridging 1 thing, that connects to the targeted resource.
- You can separate things into layers so that people of different disciplines can work on the layer they specialized in.
- When you want to keep storage separated from presentation, possibly allowing multiple representations of the same data, and you want to be able to change the data model. (At one point the data model changes so much you can not prevent the interface of the bridge to change or even the user interface to change, or you might keep your data model backwards compatible, something that you were trying to work around with the bridge.)
So simply trying to make things that are actually independent on each other, sort of independent of changes to the dependency, you build a bridge between them. It might require additional code, additional connections and wiring, adds complexity. I might not recommend putting a bridge between any two objects. That might create incredible complexity. How is that going to help you change the code? So you might apply this when it is useful.
I can imagine that an ESB allows you to define interfaces / adapters between any two resources. Or offer the same interface to multiple programs or the give multiple resources the same interface, or create bridges between systems.
JJ
Coupling,
2010-04-16
More brainstorming. All this bridging has nothing to do with the cohesion they often talk about.
JJ
Fundamental Principles,
2010-04-20
To analyse if something is used anymore by executing a search, when you an extra data access layer in between you can not easily see if something is no longer used or not.
JJ