111–120 of 125 posts
https://wiki.debian.org/DebianBootstrap
Also the Guix and Bootstrappable Builds folks are working on this too, at a different layer:
https://bootstrappable.org/ https://bootstrapping.miraheze.org/wiki/
Earlier quoted context omitted.
TCC 0.9.27 can build GCC 2.95.3. You can build TCC using GNU Mes, which itself can be built using M2-Planet, which is written in a subset of C. https://www.gnu.org/software/mes/
Furthermore, M2-Planet can be built by another C compiler written in assembly, all the way down to hex instructions. https://github.com/oriansj/mescc-tools-seed/
https://bootstrappable.org/ https://bootstrapping.miraheze.org/wiki/
Language constraints aside, the real world is not something that can be cleanly modeled without the notion of circular dependencies between things. Not very many real, practical activities can be truly isolated from other closely-related activities and wrapped up in some leak-proof contract. Consider briefly the domain model of a bank. Customers rely on Accounts (I.e. have one or many). Accounts rely on Customers (i.…
Earlier quoted context omitted.
This is almost exactly the motivational example that Codd used when originally describing relational algebra. He described 5 different data organization schemes for a single problem and designed relational algebra to work with all of them. This ability for the same program logic to work with many different data storage layouts should make changes like you describe less painful to implement. (see page 2) E. F. Codd. 1…
My dream, when I'll have a few years of free time, is to design a language were the relational table is the primary data structure abstraction.
Earlier quoted context omitted.
No, you don’t need reflection or annotations to use dependency inversion. Why do you think so?
The question was "what has reflection got to do with it". I've used reflection for dependency inversion, so I think that's what it's got to do with it. If you can do dependency inversion without reflection, more power to you :-) We can't do classpath scanning in the project I'm working on because of the size of the classpath, and compile time configuration using direct imports would introduce cycles, so reflection it…
class Customer implements ICustomer { ... } // Customer Class can be created after Account above
createAccount(new Customer()) // Use of both, with dependency injection
Scanning for classes dynamically using reflection has nothing to do with above. And you certainly don't need any xml or framework to do it either.
Earlier quoted context omitted.
> and then a Bank which is a mapping of Account to Set The problem is that this only lets you get customers from accounts, and not vice-versa. And if you add a Map > to the Bank, you now have to ensure the mappings are synchronized at all times. Which, to be fair, is very straightforward as long as Bank is immutable, but still kind of annoying. But considering how incredibly common many-to-many relationships are in b…
Sure, but you wrap that up if you want. A Bank can contain both maps, if you want, and you hide the methods that would update individual maps, only exposing your wrappers that update everything together.
Earlier quoted context omitted.
In F#, you would naturally approach this by defining a Customer independent of the Account (e.g. just containing a name and address), and an Account independent of the Customer (e.g. just containing an ID), and then a Bank which is a mapping of Account to Set . What you see as a cyclic dependency, I see as a data type that you haven't reified.
> a data type that you haven't reified Insightful. Once you learn to see dependencies as implicitly revealing abstract data types you haven't yet teased out into existence, you start seeing all kinds of places where behavior that ought to be explicit and handled by an abstraction is smeared across multiple other concepts.
Earlier quoted context omitted.
Sometimes I read conversations about software engineering concepts by career developers and I get this sense that there is this entire hidden world of other engineers that I have somehow managed never to encounter. Every engineer I've ever met who has been doing it for more than a couple years universally decries circular dependencies. Every one of them has come to that opinion via hard won experience dealing with re…
To me, the parent is describing a functional circular dependency that we all have to live with, but when we’ll design the system it will be masqueraded in a many to many association in a third object/table and we’ll proudly say “we have no circular dependencies”. To me both are technically true, reality is messy, and we hide the mess under imaginary constructs.
Earlier quoted context omitted.
Sure, but you wrap that up if you want. A Bank can contain both maps, if you want, and you hide the methods that would update individual maps, only exposing your wrappers that update everything together.
Yeah, I'm not saying it's difficult, I'm just saying that it's weird that there isn't a standard ManyToMany class in most programming languages, even though a functional (if perhaps not performance-optimal) implementation is straightforward and should be very useful at least for DB mappings.
Earlier quoted context omitted.
My dream, when I'll have a few years of free time, is to design a language were the relational table is the primary data structure abstraction.
Starting from the other end, what is missing in SQL to make it more general purpose?
This type of relation shows up quite a bit, and either leads to application-level workarounds, or having to add many duplicate tables for the same "thing".