As I point out to inexperienced softies, when building systems neither top-down nor bottom up is sufficient. Both are necessary - and they should meet each other in the middle 
Quite! To me, it is analogous to the modular approach, where one constructs the solution from modular pieces, instead of trying to define the solution beforehand (top-down) or just throw stuff together and see what comes out (bottom-up).
For me, the typical application design process starts with a lot of thought, and some unit tests to see what kind of modules I have for the lowest-level key parts. Often it is an iteration, with my overall design changing and evolving, until I have a full plan. Even then, I typically end up needing a full rewrite later on, when I have some experience using the application, and can find ways to optimize the workflows.
With such an approach, things like combining proprietary computation (in a dynamically linked library) and an open-source, user-modifiable user interface (written in e.g. Python), is no longer "strange": you look at the licenses and their intent (and possibly existing case law) to define the generally accepted division, also defining the API between the two sides. You then start developing each side modularly/piecewise, hopefully refining (or even redefining) the API as needed by both sides. For web-based services, you have a very similar situation, with server-side logic never revealed to end users, but client-side logic (run within the browser) always is (although Javascript/WebAssembly code obfuscation and minimization tries to do just that).
(To see the industrial technology behind a "black-box voter and its redundant system" can be much worse, [...])
I'm not actually
disagreeing with you, just explaining the reasons for my current opinion/stance.
I'm taking the hobbyist approach here, because a thing like a new programming language will take something like a decade before it is ready to be widely used in industrial applications. Much less, if you create a variant like you did with my-c, of course; but here, we're talking about an event-oriented language, designed basically from scratch. Indeed, I've been talking more about how I'd like that design process to go, instead of what the resulting design should be!
The problem with vendor-created programming languages or programming toolchains is a three-edged sword. On one hand, the development is limited to the resources the company can afford to put into its development. On the other hand, for any for-profit company, such spending must be explained to the shareholders, and essentially have to generate income. If we consider language development, things like ease of use and portability, the company interests and the client developer interests, do not align too well. On the gripping hand (it's a reference to Moties), the vendor is in full control of the language, and if you are big enough, you can get the vendor to extend/modify the language so that solving a particularly intractable detail becomes easier; rather than having to convince basically unpaid volunteers that such change is better for
everybody (or at minimum, harms nobody),
and do the hard work needed to implement the change as well.
Open source development is not cheap, it is just ... different. The rules are different, I mean.
considering the psychological cost of that training, it was a rather insanely bizarre experience of which I'm not even allowed to talk about because of what I had to sign (worst negative).
So even before I got home, I felt quite emotionally and logically understand Cypher, when in the first Matrix movie, he betrayed his friends to re-enter the Matrix.
I do know how weird NDAs can get; that's why I included "(properly written)" when mentioning those.
As to Cypher, I always perceived him as overly naïve; like the people who are ardent proponents of one political system and another, believing that it would make life all roses and butterflies, with everyone happy (and those who disagree silenced without messing up the clean world).
Yes, he was put into a hard position without asking him whether he wanted it or not. Thing is, easy answers don't make people happy. You might think you'd be happier if you didn't know or did not have a specific impactful experience –– they do say "with knowledge comes pain" –– but fact is, it is experience and knowledge that shapes us. That unknowing person would be a different one than you are now, so it is making a decision for someone else. There is no guarantee that other you wouldn't be even more miserable, for example because they never got to make the choice in the first place.
This relates very closely to programming languages and software development. It seems that one truly has to work with difficult and painful projects before they understand the importance of maintainability and readability –– and even then, some just never grasp it.
In this analog, one might wish they never had to encounter a specific project –– like me with certain Perl project by authors I like, but who definitely were not suited for creating that project back then at least; causing me to avoid Perl to this day! ––, but it is exactly those painful experiences that teach us the cost of doing things that way.
Red Pill always has a price to pay.
Yup. Put more generally:
There ain't no such thing as a free lunch.(Definitely also applies to open source, as well. The costs and payments are just measured using a completely different yard stick.)
Home
Help
Search
Login
Register
