Thanks for the link @jdubray , I will read it latter
@jdubray Regarding your last question: You might want to have a look at the paper "Out of the Tarpit". Here an introduction blog post with the necessary links. And a (long) video explaining it on DDD Norway.
@robsiera I didn't see the video (just try to cut through the intro, but the guy is really slow to get started). I'd say with statements like this:
By using Value Objects, the states in your system are reduced and therefore it reduces the complexity of your system.
I'd be surprised if there is anything of value in the talk. In general I have not been impressed with DDD, again, something that looks good on paper but they have no notion of state, just type/model. I'll try to watch it this week, I always curious about the DDD community but always disappointed each time I look. Type is easy, State is hard.
@robsiera I reached the hour mark, I just can't stand it. Really, my take on software complexity (sorry to repeat myself) and the why software engineering is hitting a wall at this point in time is because of the structure of event handlers. Event handlers are coded in a completely random way. SAM introduces a decoupling that makes sense to me, if I am the only one so be it, but complexity seems to vanish when you decompose your handlers along the SAM conceptual model.
I can even model orchestrations along these lines (that's where I started). I after spending 18 months building real solutions with it (in Angular2 and ES6) I'd never go back to something different. Any kind of conceptual framework that is "monadic" (single concept), such as DDD which focuses on "Types" is a dead end, it never made sense to me, I can now illustrate why it doesn't make sense.
I can even add that each time I bended the SAM semantics because I thought it was ok, I regretted it.
I can even model orchestrations along these lines (that's where I started). I after spending 18 months building real solutions with it (in Angular2 and ES6) I'd never go back to something different. Any kind of conceptual framework that is "monadic" (single concept), such as DDD which focuses on "Types" is a dead end, it never made sense to me, I can now illustrate why it doesn't make sense.
I can even add that each time I bended the SAM semantics because I thought it was ok, I regretted it.
@jdubray In that case make sure to make good use of the Youtube video speed config option. It really helps :-). Or maybe skip the video and look at this review. I suggested it because when you wrote "we focus on programming languages, not the programming model" it reminded me of this paper. It states that the our programming languages are Turing Complete, meaning they "can do too much", they "allow us several ways to approach a problem", while a program consist of Core-Complexity (which needs FP), State (which need a programming language which doesn't exist yet (they explain the specific characteristics of such a language)) and Accidental-Complexity (which needs ... I don't remember). The original paper is 66 pages long.
But that's not a conceptual model
Dr. Lamport is the Einstein of our industry and in TLA+ he defines very precise semantics, aligned with mathematics. "Accidental" and "Essential" mean nothing conceptually.
I think even the screen is tired of the guy speaking. :-)
@robsiera People always aim for a "poor" conceptual model. Here in the paper they develop the idea of FRP (function relational programming) and for them a piece of code like this is not really shocking (p25):
procedure int doCalculation(int y)
// ’subsidaryCalcCache’ is declared and initialized
// elsewhere in the code
if (subsidaryCalcCache.contains(y) == false) {
subsidaryCalcCache.y := slowSubsidaryCalculation(y)
}
return 3 * (4 + subsidaryCalcCache.y)Using a pure function is not going to help much, when mutations are required, well, they need to happen, it's not because you use a store or "declarative effects" that magically the code will be better, au contraire!
I too was impressed at first with DDD and FRP. Data Context Interaction (DCI) also sounded interesting, but it would require additional language features to support it well. http://www.artima.com/articles/dci_vision.html
@robsiera If you want to know more about FRP, I found this video nice
https://www.youtube.com/watch?v=Agu6jipKfYw
@sladiri this is a different FRP (not RFP), it's functional relational programming!
@sladiri see, Computer Science is littered with "a priori" conceptual foundation such as "In fact, the goal of object-oriented programming pioneers was to capture end user mental models in the code. " (from your article). How about returning at the foundation of computer science? why would this kind of ad hoc thinking yield anything good? we'd be incredibly lucky if it did. Functional Programming is no better, it's foundational premise is that "pure functions" are a good programming model. Good luck with that.
I just don't get it why people would invest years of work without ever questioning if the foundation of that work is correct. It's like trying to build a skyscraper without any kind of science and wonder why it's not working.
Here is a good presentation on FRP: https://www.infoq.com/presentations/elm-functional-reactive-programming
Everything is just a building blocks, I dont think if there exists global theory which could allow to solve everything
Im mixing many dialects in an application and see one thing fits better in certain sitiations than another
It depends on applications, e.g. for enterprise LOB where 90% is crud, direct callback bindings on buttons is sufficient
On top of some MVP/MVVM pattern with data binding on forms/listgrids.
Yes, gui will become a mess to test every interaction, but main deal is on backend which could be done differently
I see systems like they are electronic circuits with strict defined signal flows, each chip could contain and be made by anything, but must have pins with clearly defined protocols and specifications, max voltage/freq. etc.
Complexity of the system depends of how much states / flipflops it contain which produces non linearity, instabilities
If components are linear then it simpler to reason about interaction between these components in a system
But yes, some components should have state, and I'd better explicitly put that state on some chip dedicated for state persistence, so it's possible to see clearly where they are.
But I think it's biased thinking because my dad and grandfather is electronic engineers so was grown up in circuits :)
I beg to disagree, there ought to be a basic model of computation from which we can compare optimizations, again, it's a bit like saying there is absolutely no science whatsoever that describes computing and statements such as "the goal of object-oriented programming pioneers was to capture end user mental models in the code" are just fine. (FP and RP have similar ad hoc foundations).
Because, once you pick such direction, then gravity kicks in and that's when things get ugly.
Lots of dust get swept under these beautiful blanket statements.
But it depends on what level we'll look, if Im engineer and composing systems from lets say components
I rarely care in algorithms and computations in that case
But if I'm in some boundaries of "component" then it's different perspective
I dont think that real system can be described somehow formally and in simple way
Maybe actor model is closest to reality
To describe interaction between components and can get large.
But OOP is good in code structuring, packages dependency rules etc. I know that they don't have any mathematical fuondation, but it works, maybe it's not for math, but for social sciences?
or biology
I don't know, I must be coming from another planet. I don't understand how computation can be structured arbitrarily. Every other "science" is looking for its foundation except Computer Science.
It looks to me that every programming paradigm was inspired from some peripheral views, for instance the actor model: "According to Carl Hewitt, unlike previous models of computation, the actor model was inspired by physics, including general relativity and quantum mechanics. "
Hehe
But is it bad?
well, again look at all other science, there is not a single discipline that would follow our approach, not one. Alchemy maybe?
Should be programming expressed only i math and with strict proofs? Physics also was discovered thru observing a nature
After all lots of people have been able to convert (bad) code into gold!
But there is foundation - von neuman?
I am not saying that, I am saying that the structure of the code should be somehow tied to some real science, not user mental model.
well that's what I am saying Von Neuman = Newton, Lamport = Einstein?
Hm @jdubray , but the guy in the video created ELM, he did mean Functional Reactive, it's in his title slide.
Could be :)
@sladiri yes, but in the paper it's functional relational programming, nothing to do with reactive.
I agree that we have to improve the way we write UIs, at least from my limited experience. It is just tough, there are so many applications with bad UI or UX rather.
@jdubray did not know that
But do OOP / FP cotradicts Lamport's theories? Or we should expand on Lamport's theories and build
Other paradigms?
@sladiri never heard of it before too
Would be they differ from outlook of oop/fp, and what's the benefits will it carry to software construction, or it would be only CS related?
@antanas-arvasevicius I'd say yes, but I am biased. Perhaps it would be more accurate to say that because of the misalignment lots of (unnecessary) boilerplate is needed to get to a working program
The programming model of OOP/FP is clearly not aligned with TLA+, no question about it, but since programming languages are designed to be turing complete, you can achieve computation.
What I know that it's most important thing in software engineering is to align code within business specification / domain experts language which languages is not in math field
If not then it's unmaintainable mess
And if requirements changes you can alter code without a problem, no need to translate in minds between concepts
So maybe future is good specific DSL
DSLs on specific domain with its own theoretical proofs
Maybe these dsls could map to tla+, but programmers should write code in these DSLs.
Think of specific "mathematical" domains
well I spent 20 years in MDSE, it appears to me as a dead end. I don't know a DSL that's more than a toy, unless your data model is logic free (say a CRM solution where things are just pure CRUD or thereabout)
What's MDSE?
Model Driven Software Engineering
Maybe I should spend ten years more on that to understand you :smile:
It's hard to let go then it just works fine
E.g. Akka dsl on actor model, akka stream on pipe architechture they are useful
Annotations are not technically a DSL
I am not really familiar with Akka, but a DSL is pretty much 100% declarative (I call it anemic).
They are more of a stereotype (a reification of a concept behind another, for instance a message can be reified as a class, an API as a class method...)
In general this kind of reification is not a good thing, they introduce a semantic loss because a message structure is not a class structure or a API is not a method, in some constrained cases yes, but in general no.