Show HN: Céu, Structured Synchronous Reactive Programming
1–10 of 48 posts
Re: Show HN: Céu, Structured Synchronous Reactive Programming
#2Although Céu is about 5 years now, this is the first time I post to "Show HN".
In this new version, we are trying to surpass the academic fences with a more polished work (docs, build, etc).
All feedback is welcome.
Francisco
Re: Show HN: Céu, Structured Synchronous Reactive Programming
#3Hi, I'm the author of the programming language Céu. Although Céu is about 5 years now, this is the first time I post to "Show HN". In this new version, we are trying to surpass the academic fences with a more polished work (docs, build, etc). All feedback is welcome. Francisco
That's pretty cool!
Re: Show HN: Céu, Structured Synchronous Reactive Programming
#4Hi, I'm the author of the programming language Céu. Although Céu is about 5 years now, this is the first time I post to "Show HN". In this new version, we are trying to surpass the academic fences with a more polished work (docs, build, etc). All feedback is welcome. Francisco
https://github.com/fsantanna/ceu-arduino That's pretty cool!
Re: Show HN: Céu, Structured Synchronous Reactive Programming
#5Earlier quoted context omitted.
https://github.com/fsantanna/ceu-arduino That's pretty cool!
Thank you! I'm enthusiastic with the Arduino binding, it provides a friendly way to handle events without much bloat. These characteristics fit well in this domain of non specialists programming constrained embedded systems.
Re: Show HN: Céu, Structured Synchronous Reactive Programming
#6Re: Show HN: Céu, Structured Synchronous Reactive Programming
#7Hi, I'm the author of the programming language Céu. Although Céu is about 5 years now, this is the first time I post to "Show HN". In this new version, we are trying to surpass the academic fences with a more polished work (docs, build, etc). All feedback is welcome. Francisco
Re: Show HN: Céu, Structured Synchronous Reactive Programming
#8Hi, I'm the author of the programming language Céu. Although Céu is about 5 years now, this is the first time I post to "Show HN". In this new version, we are trying to surpass the academic fences with a more polished work (docs, build, etc). All feedback is welcome. Francisco
It would be helpful if you could provide a high-level explanation of what "Structured Reactive Programming" means and what problem you are trying to solve with current solutions? How is it different from current reactive environments?
In summary:
Reactive: code executes in reactions to events
Synchronous: reactions run to completion, i.e., there's no implicit preemption or real parallelism (this avoids explicit synchronization: locks, queues, etc)
Structured: programs use structured control mechanisms, such as "await" (to suspend a line of execution), and "par" (to combine multiple awaiting lines of execution)
Structured programming avoids deep nesting of callbacks letting you write programs in direct/sequential style. In addition, when a line of execution is aborted, all allocated resources are safely released.
In comparison to FRP/dataflow, it is more imperative supporting sequences/loops/conditionals/parallels. The notion of (multiple) program counter is explicit. Also, everything is lexically scoped, there's no GC involved.
In comparison to promises/futures, it provides lexical parallel constructs, allowing the branches to share local variables and, more importantly, supporting safe abortion of code (with the "par/or").
Re: Show HN: Céu, Structured Synchronous Reactive Programming
#9Re: Show HN: Céu, Structured Synchronous Reactive Programming
#10What are the advantages of Céu over other synchronous programming languages such as Esterel and Lustre?
1. Dynamic abstractions with lexical scope (vs. mostly static language). You can dynamically spawn code into a lexically-scoped pool.
2. Internal/fine-grained determinism (vs. external determinism). All statements execute in a deterministic order. E.g., if you have two printf's in parallel awaking from the same event, they will execute in lexical order.
3. Safe integration with C. When calling a C function that returns a pointer (e.g., "malloc"), Céu forces you to write a finalization clause (in which you can call "free"). If this code is somehow aborted, the "free" is called automatically.
4. Timers as first-class events (e.g., "await 1s"). Besides the convenience, Céu adjusts timers in sequence, e.g., if a first timer awakes a little bit late (due to system overhead), the timer in sequence will compensate.
5. Internal events are stack-based (vs. queue based). This allows co-routine-like functionality, resumable exceptions, and some other mechanisms.
6. Event-based logical notion of time (vs. tick based). A single event can occur at a logical time (related to #2).
[EDIT] Didn't mention that these are "advantages" depending on the context. Esterel targets hardware synthesis and also hard real-time systems. Dynamic abstractions might be irrelevant, fine-grained/sequential determinism in hardware might be inefficient, a tick is closer to a hardware clock, etc...
In comparison to Lustre:
Very different programming mindset. IIRC, in Lustre you define equations and the system is responsible for keeping them up-to-date/correct. It is a data-flow language (vs control-flow), closer to FRP than Céu/Esterel.