Event-Driven Programming Paradigm in Logic Programing - event-handling

I need to write a paper on the Event-Driven Programming Paradigm in Logic Programing. I have been able to find a lot of information on Event-Driven Programming in Object-Oriented and Functional programming, but not for Logic programing. I would appreciate some direction in respect to Event-Driven Programming in Logical Programing.

Event-driven programming should be similar to how it is done in other languages, you would set up some framework to generate the events and you would call a goal to handle the event, possibly using the system's multithreading facilities (which leads to interesting aspects of transactions on the Prolog database, global vs. thread-local storage etc.)
Paulo Moura would certainly provide this link to the Logtalk Manual:
Event-driven programming
Also this paper comes to mind:
How agents do it in stream logic programming - Matthew M. Huntbach , Nick R. Jennings , Graem A. Ringwood (1995).

Related

Preparing for a Scientific Programmer/HPC programmer Interview

Could you recommend sources/literature to prepare for Scientific Programmer/HPC programmer Interview?
Thanks!
"Introduction to High-Performance Scientific Computing" by Victor Eijkhout is a very good book to start with (and is relatively up to date). You can find it freely on his personal home page.
As this book mainly focus especially on quite theoretical/abstract concepts, you probably need to complete the book with practical HPC programming. MPI and OpenMP are two programming standard massively used in HPC applications. As a result, I strongly advise you to learn how to program with both, especially from practical exercises.
There is a lot of resource you can find on internet for both. If you don't now how to start, please look here for MPI and here for OpenMP.

Comparison of Reactive programming and Complex Event processing

I have been reading up on the reactive programming and can understand the programming model and how we can use patterns such as CQRS to build micro services & applications. How is this different from the legacy Complex event processing approach used by traditional middleware.
One can compare apples and oranges yes. And using the word "legacy" for oranges is probably not appropriate. The reactive programming is about general-purpose programming APIs for dataflows, push, pull, threading, backpressure etc.. Such as provided by an actor library. CEP is about analyzing events and provides a language (SQL, rules, XML) to make it easy and concise to detect situations in an event stream. CEP is provided by a CEP engine. For example to find a train-passing event without a train-station-stop event within 10 seconds you can express this situation detection in a CEP engine using just 60 characters. If you write programming language code to detect such a situation in say Java it probably upwards of 20 lines of code and is much harder to read. The CEP engine will do more for you such as being very fast in matching events with which rules they apply to. This for the case when you have many situations to detect. CEP engines and reactive programming can well be used together and are in fully in synergy and do not provide at all the same functionality.

How SVUnit has been used?

I'm looking for reasons to use SVUnit in my projects. As a software engineer I used to write tests before the production code. However, I don't see so much adoption of this initiative. Why? Is it worth it?
Since you mention you used to be a software engineer, I guess you don't need to be lectured on why unit testing is good or why TDD makes sense. Since testbenches are very much akin to software, this means that a lot of software development best practices can be carried over to testbench development, unit testing being one of them.
The fact that it hasn't seen much adoption yet shouldn't be a reason not to use something.
I've written about SVUnit here: http://blog.verificationgentleman.com/2014/05/a-quick-look-at-svunit.html
Any programming language can be interfaced to SystemVerilog by Direct Programming Interface.
By referring quote from Sectioin 35.2 of IEEE 1800 - 2012 it is possible but adopting to it to the environment is based on the programmers understanding of the calls and routines of the language.
DPI is an interface between SystemVerilog and a foreign programming
language. It consists of two separate layers: the SystemVerilog layer
and a foreign language layer. Both sides of DPI are fully isolated.
Which programming language is actually used as the foreign language is
transparent and irrelevant for the SystemVerilog side of this
interface.

Is there a visual modeling tool / language or style which supports Scala profile?

[Similarly sounding question currently active on SO is " Is there a visual modeling language or style for the functional programming paradigm? " which is different then this question because another is focusing only on Functional programming paradigm and my question is looking for a modeling tool which supports combination of Object Oriented Paradigm (which independently has many well established visual modeling UML tools) and Functional Programming Paradigm together.
Is there a visual modeling tool / language or style which supports Scala profile (provides and includes all Scala language artifacts) or can say that it supports the object oriented programming paradigm and the functional programming paradigm, together.
For an Enterprise scale Scala project, with what modeling tool - the business analyst prepare Visual Models or any other type of model(s) for Logical (conceptual) view and Development view?
The logical view is concerned with the functionality that the system provides to the end-users.
The development view illustrates a system from a programmer's perspective and is concerned with software management.
In certain circles of software development, formal modeling is a requirement, no matter how bureaucratic you consider this to be. There are several levels of involvement from different teams on the conclusion of a project and many of the people involved have no idea about the code. They don't need to have, it'd be a major hassle if that was asked of them. The formal modeling is there to assure that they'll get a better view of how things work so that they can perform their roles in the development.
(This paragraph is taken from: https://stackoverflow.com/users/166802/codnik)
Unfortunately there doesn't seem to be one available.
I have a PhD student friend who is working on formalising modelling techniques, however he is not building a PoC.

Design patterns for Agent / Actor based concurrent design [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Recently i have been getting into alternative languages that support an actor/agent/shared nothing architecture - ie. scala, clojure etc (clojure also supports shared state).
So far most of the documentation that I have read focus around the intro level. What I am looking for is more advanced documentation along the gang of four but instead shared nothing based.
Why ? It helps to grok the change in design thinking. Simple examples are easy, but in a real world java application (single threaded) you can have object graphs with 1000's of members with complex relationships. But with agent based concurrency development it introduces a whole new set of ideas to comprehend when designing large systems. ie. Agent granularity - how much state should one agent manage - implications on performance etc or are their good patterns for mapping shared state object graphs to agent based system. tips on mapping domain models to design. Discussions not on the technology but more on how to BEST use the technology in design (real world "complex" examples would be great).
Even if I cannot come up with any good real world examples that provide you with design
patterns straight up, there are a few places to start.
The first is getting your head wrapped properly round the concepts. One book helping
you do this is Making reliable distributed systems in the presence of software errors
written by an Erlang Guru Joe Armstrong where explains Concurrency Oriented Programming
in a very accessible way. It is in fact a Ph.D. thesis, but do not let that scare you.
It is by far easier to read, and pleasant into the bargain, than most common text books.
Looking at actual systems normally means that you have to learn too much about the actual
language for it too make sense just to evaluate things. For Erlang the documentation
provides design methodology and behaviours(Erlang speek for design pattern libraries).
This will illustrate the design patterns most commonly used in this setting. And these
have proved to be effective in building large scale systems, i.e. millions of lines of code (comparable to a factor 4 to 10 of other languages such as Java) and milloins of concurrent processes running on one machine in distributed clusters of machines.
A recent example of a real live system is Facebook Chat.
For the other frameworks I cannot really help you I am afraid.
An "actor" is itself the unifying pattern for concurrent programming (an asynchronous message queue plus an execution context for processing it), but there are many design patterns which assist in specifying aspects or elements of agent-based systems. Many of the most common can be found in Wikipedia's article on Concurrency Patterns. Some highlights:
Reactor Pattern
Mediator Pattern
Scheduler Pattern
Observer Pattern
If you haven't come across it already, Akka may be of interest to you -- it is a "purely" event-driven actor framework running on the JVM.
I asked a similar question here which had some reasonable answers that may help. I'm watching yours carefully. I haven't yet found something which has really helped me, but I am very actively looking.
I think the mind-shift is the single largest barrier to stepping to concurrent architectures and languages and until that is cracked developers are going to stick with easy to learn MS style paradigms. For it to really become mainstream it needs to find its way into schools and be taught alongside C# and VB.
My answer to the 2080 programmers question is "concurrently".