EDSL for hardworking IT programmers

Dear all,

This is my first post to this site. So hi everyone. As a tiny bit of context, I've only recently started to look into functional programming, understanding some of the foundations and writing some simple Haskell.

I came across this article on entitled "An EDSL for hard working IT programmers". It only has a few comments on the Haskell Reddit and Hacker News.

To my unexperienced eyes, the approach proposed in the article - despite the strange title and somewhat disorienting writing - is quite significant and maybe profound which is why I'm asking this community whose expertise I deeply respect. The lack of echo anywhere makes me wonder if I might be wrong and if this is in fact a fairly common approach? Could you point me to equivalent solutions or explain more about why its not significant?

Thanks a lot for helping me understand more about the state of the art in functional programming!

Jun

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Functional reactive programming

Welcome to the website!

Are you familiar with the area of functional reactive programming? At some point (in a linked article) the author says that's the area he's in, so you might want to take a look at material on that — there are both research papers and more practical implementations, including the rather well-known Elm: http://elm-lang.org/.

To be sure, I didn't read the articles in detail. And I fear I won't have the time; I have already enough well-written articles I should be reading. In fact, I'll speculate some (many?) others will think the same. Even if somebody has a good idea, if he presents it badly he can still ensure he'll be ignored.

To be sure, I'm not sure I should be posting without having read the article — I only answer because you ask about the lack of impact.

Yup

Hi yes, I've tried elm and read on the origins of FRP with Conal Elliot's material. From what I understand from the article linked, it is a more generic concept that can be applied to the FRP domain (though probably not the arrow based version, and I don't understand how the continuous/discrete time issue applies), but also to other asynchronous and parallelism problems and loftier goals with regards to programming in a style that is closer to the level of specifications.

Yes you're right, bad writing (and the OOP bashing, and the difficult to read API) will have probably turned off a lot of potential readers. Anyway, I'll copy paste the list of "big claims" about the problems addressed by the approach in the article, hoping it might draw some interest:

  • something for multithreaded event handling without inversion of control.
  • something for paralelization of processes: async without the wait
    for automatic thread control
  • for alternative and applicative composition of parallel IO actions
  • for indeterminism and asynchronicity effects
  • for high level programming at the specification level
  • for creating and composing applications by means of a single expression
  • for overcoming futures and promises of Scala and JavaScript making them unnecessary

All of these ideas, and using monads to address them, don't necessarily seem new, but I haven't seen them combined within a single abstraction like that elsewhere. But then again, I didn't know (maybe still don't know deeply) what a monad was just a few months ago :)