Esoteric programming paradigms
ybrikman.com
Esoteric programming paradigms
1–10 of 149 posts
Re: Esoteric programming paradigms
#2Shame not to see factor in the concatenative list, it addresses some of the pain points there with locals
Re: Esoteric programming paradigms
#3I'd recommend to everybody (but especially those involved in either embedded systems or a lot of concurrent state) to try out HSM / state chart programming (note: this has basically nothing to do with "flat" FSMs). It's as close to a silver bullet as you'll ever get for these kinds of systems.
Stateflow or QP/QM, all other systems suck.
Re: Esoteric programming paradigms
#4Will Eve ever take off? I like the thoughts behind it.
https://youtu.be/VZQoAKJPbh8 very good talk about the background of eve. When he finally talks about eve you might want to switch to a more recent talk about it.
Re: Esoteric programming paradigms
#5There seems to be and old discussion over here https://news.ycombinator.com/item?id=7565153
Re: Esoteric programming paradigms
#6To this I would add synchronous programming[1], which is particularly suited for interactive or concurrent programs and formal reasoning, and has had success in industry in safety-critical realtime systems. Examples include Esterel[2] and SCADE, and outside realtime, Céu[3] and Eve[4] (the latter is based on Dedalus[5], which combines SP with logic programming).
As someone who loves formal methods and believes most mainstream software systems today are mostly interactive and/or synchronous, I think this paradigm has a lot of untapped potential, and I'm glad to see it slowly move out of safety-critical systems into the mainstream, in languages like Eve.
[1]: https://en.wikipedia.org/wiki/Synchronous_programming_langua...
[2]: https://en.wikipedia.org/wiki/Esterel
[4]: http://witheve.com/
[5]: https://www2.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-...
Re: Esoteric programming paradigms
#7Isn't Lua supposed to be an example of a concatenative language?
Re: Esoteric programming paradigms
#8ANI reminds me of HDLs [1] - I'm assuming that's the inspiration with terminology like "latch"?
Hardware is also concurrent by default. Coding some hardware logic will also change the way you approach coding. Anyone who's interested get an FPGA demo board and write some verilog or VHDL - I highly recommend it.
1. https://en.wikipedia.org/wiki/Hardware_description_language
Re: Esoteric programming paradigms
#9Curious. ANI seems to me like an abstract form of graph-parallel programming, where the language itself is the scheduler.
There are some production-ready schedulers for GPP, like Intel's TBB[1] (C++), but learning to be effective with this requires a major shift in thinking about code - essentially thinking in graphs.
[1] - https://www.threadingbuildingblocks.org/tutorial-intel-tbb-f...
Re: Esoteric programming paradigms
#10I'd recommend to everybody (but especially those involved in either embedded systems or a lot of concurrent state) to try out HSM / state chart programming (note: this has basically nothing to do with "flat" FSMs). It's as close to a silver bullet as you'll ever get for these kinds of systems. Stateflow or QP/QM, all other systems suck.
Is it useful in writing drivers ? or mostly for application code ?
And what are the drawbacks? Why aren't everybody using it?