Đ (Edh) - The next-big-things ought to happen with Haskell not C/C++
- Take A Tour of Đ (Edh)
- Checkout the demo & scaffold project: EdhIm - Đ (Edh) doing Instant Messaging
Đ (Edh) code should be especially more readable/modifiable to average people without a functional mindset (yet), thus development of a software project in Haskell + Edh can be more viable and maintainable by teams with diversified crew members.
One possible division of labour on from the scaffold as a baseline, e.g.
Junior people and New Comers (the Dev), End Users (bugfixers):
Extend Đ (Edh) code with new modules, 3rd party packages for application / business logics, with fast iterations
Establish the world modeling code, then progressively (but may better conservatively) improve the models, for mistakes harder to be made, idiomatics easier to be followed
Architect / Senior Engineering people, Security Experts, the Ops:
Establish and maintain world reifying code, ensure the systems run continuously & securely on a foundation of contemporary technology stack, deal with dependency EOLs, patch CVEs in time, perform regularly the house keeping of backing storage
- What is Đ (Edh)
- The name
- Zen of Edh
- Academic relationship
- A joke
What is Đ (Edh)
Edh code is imperative, runs embedded in Haskell (GHC), interpreted.
The killer feature may be the very Haskell implementation of Software transactional memory brought into an Object layer, together with the Go routine brought from Go, and the Reactor mechanism with Event Sinks, you can:
When coding within an Edh world, you can forget about all kinds of synchronization primitives scattered here, here, and many otherwheres , with every methods you attempt to program concurrency otherwise.
concur() is just an example, it's straight forward for you to write
application logics in similar ways.
Edh competes with Python in aid of Haskell instead of C/C++ to be the breeding ground for next phenomenal pieces of software, after TensorFlow, Pandas, Numpy etc. by providing equaly good or even better language constructs to rivals in Python.
Take the Tour to see what Edh has to offer.
But in the early years of school, we live in a system whereby students are required, from an early age, to learn many formal mathematical methods, such as those used to add, subtract, divide, and multiply numbers. This is the time when students stray from mathematical mindsets and develop fixed, procedural mindsets.
I suppose years still needed for our education system to get that situation straight, and before that -
Edh stands for Event Distributing & Hosting
Đ is a more stylish, single letter, symbolic name of Edh the language
Everything is a value, the object is a type of value among other (mostly immutable) types
This is part of the reason why Edh is not an Object Oriented language (see next section), to be contrasted with Python, where:
Everything is an object, a value is an object of some type among other types
Object? - Yes, Oriented? - No
Many don't consider Go (GoLang) an
Object Oriented programming language, neither is Edh in similar
respect. Edh does pointer-wise
in Go spirit, while it takes a small step further to offer
reference, which refers to a descendant record from an ancestor
method, in addition to
this reference which refers to the lexical
Functional? - Try not to abuse this concept
In a pure functional language like Haskell, everything is a computation, Referencial Transparency is an intrinsic (and really fundamental) property. Bearing the world-changing potential, a procedure in Edh can never qualify as a function.
But if you ask about Functional programming as a possible paradigm you DIY, Edh is supportive as well as other mainstream languages.
Edh struggles to dig performance improvements majorly out of the human aspect from the human:machine pair, offer wider tolerance, therefore better leverage, over diversified skill sets/levels among all crew members onboard.
And raw machine performance squeezing is offloaded to GHC who has been undescribable good at it since inception.
Zen of Edh
Under certain circumstances, there are sweet spots balanced between imperative and declarative stylish, when put together, Edh code can be made even more concise than Haskell code ( see proof here ). Do Edh programming around such sweet spots when you can find them, and when you do, be Edhic, that to be Edhic, is to be more Pythonic than being Pythonic
Whenever you're not sure how to get a job done, think about how a Gopher would do it
I (Compl Yue) choose to distribute Edh related code under BSD, I believe BSD license is proper, it is even permissive for you to re-license it under GPL etc. given the BSD clauses kept distributed together. Though I sincerely hope no one is to attack me by patent infringement.
No academic background relevant so far, but I (Compl Yue) do feel some ideas here worth further exploration, to be consolidated or even formalized on theoretical ground. If you are doing relevant CS researches, Edh is yet another piece of friendly BSD licensed software at your hand, PRs updating information here, including citation requests for your relevant work are welcomed.
Finally let me tell you a joke:
So what's good on Edh the programming language?
Edh is good because it's arguably a three star language (
***argspk), as Python is arguably a two star language (
**kwargs), while others are at most one star languages or even no star ones.