Đ (Edh) - maybe a competitor, or can it make friends with Julia?

Offtopic
1

I’m author of Đ (Edh), just released it to public.

I have long been watching on Julia (since 0.4.x I roughly remember), I’m sincerely happy to see it reaches 1.3 nowadays! But I regret to have had no enough materials gathered to persuade my management of Julia adoption.

But my org started doing Haskell recently, and one of my pieces of work appears interesting to general public in the programming domain and fortunately I can release it open sourced there at GitHub - e-wrks/edh: Đ (Edh) - The next-big-things ought to happen with Haskell not C/C++ .

I said there:

Julia is an alternative all-in-one solution for the next-big-things , but has a learning curve not too less steep than Haskell , Edh is faithful to get people with just Python / JavaScript / Go knowledge and skills started with a world in Haskell .

I’d never mean offensive, and I do believe there can be an Edh interpreter running embedded in Julia as well, when there’s a decent STM implementation to be based on.

So I’d take the chance to notify your Julia folks here and talk about Edh if you are interested to ?

2 Likes
2

Thanks for your note here about Edh. I really appreciate any news about new programming concepts. And welcome to this community.

Not yet too much to say about Edh, but something I struggle with:

Julia … has a learning curve not too less steep than Haskell

I would say that Haskells learning curve isn’t particularly steep, and Julias one even less steep. It is more like the learning curve of Julia is flat but long but you can just start right on and you will already get good results from the very beginning.

And on the other side:

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.

For me it is already steep to read what you write about Edh.
The first reading about Edh on the github repository should be a little bit more comfortable to read, more inviting. For me currently it is difficult to comprehend what you want to say about Edh.

Anyways maybe later I can say more about Edh itself.

2 Likes
3

um, I think Edh is aiming for something totally different than Julia.

For one:

All numbers in Edh are Data.Lossless.Decimal from lossless-decimal , by default and by all means:

2 Likes
4

Thanks for your kind advice, all taken!

I really enjoy the communication with people in the Haskell/Julia community, very concise.

And please forgive my English skills, definitely need improvement …

Looking forward to talk more!

2 Likes
5

I agree and not, Edh doesn’t seek to be performant in machine performance respect, but that doesn’t mean it cares nothing about performance overall. TensorFlow won’t be so popular and productive if only C++ people can use it.

6

After some thoughts, I figured out some other concerns than learning curve, so I rephrased the following section in home page:
(seems GitHub flavored Markdown not displayed very well in discourse, I have no clue how to format it better, sorry for the mess atm)

The Mission

Edh competes with Python to help 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.

Julia is an alternative all-in-one solution

for the next-big-things, but as well as Haskell, Julia carries

high impedance to average people without highly developed

Mathematical Mindsets

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 is faithful to get people with just Python/JavaScript/Go

knowledge and skills started with a

procedural

world

with objects

in Haskell (and in Julia too I sincerely hope for chances).

– Advices and critics welcomed.

1 Like
7

A general observation: it is beneficial to all to have many languages doing similar things.
It gives much scope for cross-pollination of ideas, and for choosing the right language for a particular problem.

Some languages have whole families that are broadly similar.

  • Objective C, C++, Java, C# all have a bunch in common.
  • Perl, Python, Ruby, Roku
  • Haskell, Purescript, Elm
  • Standard ML, OCAML, F#
  • Pascal, C, PL/I,

But also more boardly languages don’t have to have a lot in common to benefit from other languages having 1 idea that is similar.

Noone gets unhappy to see another language with a Hindley–Milner type system – even if that language is something that looks completely procedural.

Its a great boon to the people working on julia AD, that there are people working on the same kind of AD in Swift. Such opportunities to borrow ideas (and terminolgy).

5 Likes
8

It is still unclear to me what and how this language improves on existing programming languages.

I have read the tour, but it is a collection of things that can be implemented in library code in most contemporary languages (eg infinite precision arithmetic), or somewhat baroque design elements with unclear motivation (six different kinds of “procedures”).

Designing computer languages is really hard. Even large teams, composed of experienced people, with sufficient funding, sometimes fail at it.

Moreover, a language that is merely a bit better is not enough: the incremental improvement over existing languages has to be large enough to convince a critical mass of people who help create the foundations of the ecosystem. 100k person-hours can easily go into creating something like Julia had (including third-party packages for basic functionality) when transitioning from 0.3 to 0.4, and Julia is an extremely succinct and powerful language.

You should reflect on your goals:

  1. Do you want to experiment and learn about compilation, type systems, and language design? Then this could be a fun project, but may not actually attract an audience (this is fine — the gain is what you learn doing this). There are, for example, zillion tiny Lisp implementations available that people just wrote as a fun project (some of them, like femtolisp, end up being very useful for practical purposes).

  2. Do you want to improve on language X (= Python, Ruby, Go, …) because you are using X in production but ran into some limitations that are relevant in practice? First, you should explore other languages, and see if they can are addressed. This takes a lot of time because you have to learn the other language at some reasonable level of expertise. Pick a language that is really extensible (it may not surprise you on a Julia forum, but I would recommend Julia). Even if you end up designing your own language, this is a valuable learning experience.

If you end up going with your own language, I would advise that you are cautious with overhyping the result, and comparing to other languages, because it can easily make people dismiss the whole thing upon first reading. Honestly, I don’t think that at this point Edh is a competitor to Julia or Python (which, again, is natural; the first commit was 2 days ago). Also, you may want to avoid comparisons which are not supported by facts: in particular, it is hard to make sense of

Julia carries high impedance to average people without highly developed Mathematical Mindsets

Julia can be used for higher level math, but it does not require any more math than other modern languages (and of course none of it is higher level).

Finally, while it is fine to announce your language in the offtopic category here, I don’t think this is the ideal place for discussions unless they have something (however tangential) to do with Julia.

8 Likes
9

Um, besides the tour, please have a look at this demo & scaffold project, Edh can help me build up a hybrid team with majority of junior crew members being productive while they growing up in knowledge and skills, it’ll be easier for my org to recruit junior people to do the job as for this part: [ Full Đ (Edh) code (95 LoC) , while senior members do World modeling code in Haskell (190 LoC) and World reifying code in Haskell (193 LoC)

One of the road block for my management to agree on adoption of Julia (what a pitty that is) is hiring and onboard performance. Actually I blame myself for not able to put Julia for some quick, visible yield to the management.

But I don’t agree that great things have always to be costly, sometimes creativity just happens out of expectation. Quoting what I’ve said at: https://gitter.im/e-wrks/community?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge

I had started this work in order to write an interpreter for my Haskell client to talk to my array database controller in house (this part not open sourced), via GitHub - complyue/hbi: Hosting Based Interface unified (Python3.7 Go1), but the outcome turns out far beyond what I had imagined. I’m releasing it to public and hope you can have fun with it.

I’m not saying I just wrote all code line by line and it’s done, the pre-release development history is archived here GitHub - complyue/edh-early-history: Đ - (Edh) early development history in case you want to have a look into it.

10

I added a section to the home page and demo project, hope to make clearer what real problem Edh sets to solve.

Đ (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
  • Thinkist people: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