| Chris Kohlhepp <chris.kohlhepp@gmail.com>: Jul 21 02:44PM -0700 https://chriskohlhepp.wordpress.com/specification-driven-programming-in-common-lisp/ Algorithmic puzzles have become popular among computer programmers. While educational, solutions to these puzzles tend to promote approaches where competing aspects of the puzzle are entangled. Specification Driven or Constraint Based Programming is offered as an alternate approach. We hypothesize that this approach untangles the various aspect of the problem, making it easier to change the specifications of the problem while unifying test and implementation models. We then present four project Euler problems and one NP-hard logic puzzle in support of our hypothesis. We hope the examples show the brevity and declarative power of functional programming combined with meta programming -presented here using Common Lisp. In the epilogue we demonstrate how to selectively effect static typing using Lisp macros as well as implement constraints otherwise known as "Concepts" in C++. |
| red floyd <no.spam.here@its.invalid>: Jul 21 08:19AM -0700 On 7/20/2015 11:59 AM, Richard wrote: > A tautology is a thing that is tautological. https://xkcd.com/703/ |
| Martijn van Buul <pino@dohd.org>: Jul 21 09:28AM * fl: > about programming for embedded RTOS system, although the code may be for the > test bench (less embedded in some sense). I code a lot at the lower level. It > is the first time I know valgrind+callgrind. Programming for an RTOS requires a different mindset every now and then, depending on the real-time restrictions and the platform. For example, the *maximum* runtime requirements of an algorithm is often more important than the *average* requirement, because the first is a limiting factor on response time. Available memory and processor resources often don't scale as easily, and some C++ features (or parts of the standard library) just don't combine well with a hard real-time behaviour. Often, the mere fact that you use an RTOS has implications beyond the obvious. On modern desktop and server operating systems, a stack overflow is almost unheard of, but on RTOS systems, stack space is usually *very* limited, so you need to be aware of deeply recursive routines, or large objects placed on the stack. Deadlocks are often more fatal; if your browser stalls for a couple of seconds it is annoying; if the ECU of a car stalls it can lead to a deadly accident. Granted, this is all about "how to write your algorithm" and "what pitfalls to avoid" rather than "what tricks to use to get a perceived boost", and personally, I don't think "speed improvement" covers anything of the required skills to sucessfully handle real-time programming. -- Martijn van Buul - pino@dohd.org |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment