Killer App

[Anniepoo]

It would be useful to build an application that has wide usefulness and encourages lots of users to buy into the ecosystem, as Rails and Redmine did for Ruby and applets did for Java.

This is distinguished from the 'cool app', one or more programs that would entice beginners to start programming in Prolog.

[wouterbeek]

The OpenEASE robotics programming and learning environment is completely SWI-Prolog/Semweb based.

[TeamSPoon]

Good example Wouter.

The OpenEASE robotics programming and learning environment
http://www.open-ease.org/getting-started/ is completely
SWI-Prolog/Semweb based.

[TeamSPoon]

What this reminds me of is the fact that most all persons and programmers
come to prolog believing it was was certain programming language. Then
we start to learn it wasn't the language we thought we signed up for. In
fact that language we thought prolog was doesn't exist..? I like many of
you was OK with that..

XSB-Prolog's ideal was to create that language people thought was prolog.
But it encountered all the difficulties in implementing that language.
That language is documented in a couple few places: One is the SNARK
language guide another is the user manual of Knowledge machine. I am
going to say the "Killer app" is to implement in prolog a meta-interpreter
that is the prolog that everyone thought prolog was before they learned it.

[Anniepoo]

Douglas, I agree - many non academics at least come to Prolog looking for 'an AI language', perhaps something closer to Chatscript.
I think a lot of the people we see on ##prolog for a while who drift off are language tourists. They just enjoy learning new languages. You'll never hook them on a language because their whole orientation is towards learning a new language every nn months.

Certainly a 'killer app' can't be esoteric. It has to be something with "wide usefulness and encourages lots of users to buy into the ecosystem"

[wdiestel]

May be it could help the discussion when I tell how I came back to SWI-Prolog after 20 years. This time I just tried it out a bit for programming a word analysis tool and afterwards forgot the language because it was too difficult to interface with other programming tools.
Two years ago I looked for a tool chain for my daily work as an IT architect on information models which are weaker then relational models. I tried out OWL+SPARQL but found this too complicated for daily work between all the other task. I don't know why, but somehow in this situation remembered Prolog and got fast to a point where I could really use this, where other spreads out the information in 20+ Excel files juggling with them all around and never get them halfway consistent.
The usual way I use Prolog now in my professional work is extracting fact lists by formulas from Excel files, then writing all the predicates to check consistency, join those facts to new views or generate additional information structure by rules and finally output to Excel again via CSV or generate DOT graphics for dependency analysis.
To get it even better integrated into daily work I miss an easy option to work on facts and predicate output using a tabular interface like in Excel. May be best option would be directly to call Prolog from a spread sheet application like Excel. I'm convinced that a lot of people would better understand how they could use Prolog to improve there working results when they don't had to use it from a normal code editor, but more like a database or spread sheet application like MS Access or Excel. What do you think about?

[wouterbeek]

@wdiestel Heterogeneous data/information/knowledge integration is indeed a place where SWI shines!

I'm not sure how Prolog could be used through a spreadsheet UI / I have no experience with that. The only thing that comes to my mind in this area is also DES, which is at least related to SWI/Prolog.

ClioPatria does provide Web UIs for query editing, data browsing, and such.

Also take a look at SWISH. You could build Web UIs for data entry on top of SWISH. You could visualize results of SWISH in UI tables, DOT graphs for visualization, etc. Also check Nicos' Real for the latter. The benefit of building on top of Pengines/SWISH is that code will not be tied to specific proprietary tools that some of us cannot run, so reach and impact may be bigger.

[Anniepoo]

Another area where reactive programming excels (no pun intended!) is building data driven GUI's, like React and Elm languages. I once did some VBA on Excel programming professionally, and reactive functional and logic paradigms often go together.

A start would be a pack to add reactivity to SWI-Prolog, probably with some support to make it work on the browser side as well.

Coincidentally, that's something somewhat like what I've started on for some proprietary code just this week.

Another very useful addition to SWI-Prolog would be a web standards based boxes and arrows editor - which would address a lot of applications like wdiestel is speaking about.
pceDraw has some such functionality, but suffers from the small developer base for xpce applications.

And I built essentially these same two things, or parts of them, for a previous employer as well. So I think we're seeing a common application area emerge (a bit) from the mist.

@wdiestel , sounds like we're struggling with wanting a somewhat similar tool. Suggest you contact me at [email protected] and lets explore possible ways to help ourselves by some common project.

[wouterbeek]

@Anniepoo I hope you're not making XPCE part of the *killer app", that would be the "killed app" section :-P

On a serious note: drawing graphs is a generic enough UI paradigm that many would be eager to use it (I would use it in the SW realm). When I looked into this 2 years ago, there was no good, out-of-the-box JS lib that could do it. I'm not sure whether it does exist today.

[Anniepoo]

There isn't a box and line editor, but there's an interactive component lib, http://fabricjs.com/
that would be pretty suitable. I just finished looking a lot at this area for EModelWorks in July.

Building the editor from that would be relatively easy.

No, obviously I don't want to build on xpce. But I do think that many of the things we're good at are graphs, and having the end visualization point be the completely static graphviz isn't serving us as well as it could.

[Anniepoo]

I'm writing a separate comment here - Is this really a 'killer app', or just 'something we would like'?

Here's the Merriam Webster dictionary definition of a 'Killer App':

In marketing terminology, a killer application (commonly shortened to killer app) is any computer program that is so necessary or desirable that it proves the core value of some larger technology, such as computer hardware, gaming console, software, a programming language, software platform, or an operating system.

A killer app has to be "so necessary or desirable" - which means it needs to impact the lives of a lot of people who are not currently SWI-Prolog users.

That eliminates:

• Academic projects (unless they have huge practical application - if any of you invents an AGI, that'd count.)
• Internally interesting projects (eg the IDE)
• Projects that don't depend on anything unique to SWI-Prolog (or Prolog in general)
• Projects that already have a viable alternative. "You should use X", should not be answered with "that doesn't run on the JVM, so we're using Y"
• Proprietary projects where Prolog's not visible (even if it says 'powered by SWI-Prolog somewhere on an 'about us' page).

There are people who spend their days thinking about OS community development. Most of what they've written makes some assumptions about how such projects are structured that don't really apply to us, but I'm thinking there must be somebody out there who can help us think up something.

[Anniepoo]

An example of how applications can drive infrastructure.

I recently needed a GUI based JSON client, a tool to test a REST server by handing it JSON, where I could set the content, the headers, etc.

2 minutes search came up with a Java based one that seemed OK. I downloaded it and discovered I had the sources, but found a d/l link to the jar, so I downloaded the jar and ran that, and I have my tool running.

If I'd had to install the JRE to do so, that would have been a big enough barrier that I'd have gone looking for another solution.

Now, if I'd had to hack on the tool to get what I want, the cost would have been higher. Do I know Java? Do I have a JDK and suitable IDE installed? Well, predictably, and sadly, yes, I do.

So the costs of using Java based tool are fairly low for me.

So for X to be a killer app, it has to be so valuable that people, lots of them, install SWI-Prolog (or it has to be something with SWI-Prolog installed) and prefer to program this particular application type in SWI-Prolog.

In that sense, the last killer apps we've seen have been the Android and iOS operating systems, and their surrounding ecosystem, including in iOS's case, Objective-C., and node.js .

[wouterbeek]

@Anniepoo Thanks for the illustrative example! Having a user run a SWI Prolog program is indeed a problem on Windows/Linux and possibly more so on iOS/Android where I have no experience. From colleagues I know that it is also difficult on the Apple/Mac/OS-X side but I have no direct experience there either (I refer to this as 'Apple' since I do not know how they call their OS and whether OS-X = Mac = iOS these days).

Current steps for running a SWI application:

1. Install SWI. Easy on Windows but difficult on Linux/Apple where compilation from sources is sometimes needed due to out of date package managers.
2. Configure the application to know where SWI is installed. E.g., ClioPatria does this with the following script: https://github.com/ClioPatria/ClioPatria/blob/master/configure. Windows and Linux/Apple users run different scripts here.
3. Start the application. This is now relatively easy because it's the same on Windows, Linux and Apple!

Most users will not get through these three steps as indicated by Annie.

I see the following solutions:

1. Allow SWI programs to be compiled into executables. This skips step 1 but may not be technologically possible yet.
2. Do not skip step 1 but make it easier to install (recent versions of) SWI. This is difficult due to many different OS distros and versions. This is the reason why the SWI Web site does not have one download button but multiple download pages.
3. Unify the Windows and Linux configuration scripts in step 2. This may not be technologically possible yet since there is no shared scripting language.
4. Integrate steps 2 and 3 so that running an application configures it (only) if this has not happened yet. This may imply that the Windows/Linux distinction in step 2 is now replicated into step 3: there must be two run scripts now.
5. Disseminate SWI programs through a Web UI.

Solutions 1 through 4 all depend on significant innovations that may be years away. Solution 5 is here today. This implies that no user need even consider installing SWI.

Am I missing something here?

[JanWielemaker]

Well ...

1. Possible, but the technique to do so depends a lot on the OS and dependencies and the result still suffers from the poor binary compatibility of Linux and MacOSX.

2. I think is the most promising way. There are some issues:

   • Get Linux distros to be more up-to-date. What we can do is make
     life easier for the distro managers and establish better
     communication with them. Alternatively, make the compilation
     instruction really Linux-distro specific, so people can just
     copy-paste.
   • Resolve MacOS binary compatibility issues. El Captain broke
     nearly everything. I'm afraid we only get that if we turn it into an
     all MacOS binary that uses all the MacOS development tools. That is
     a lot of work. Macports and Homebrew are popular among programmers
     and provide recent versions with little hassle.

3. Do the configuration in Prolog. That is what ClioPatria does as
   well. The config.exe is just a small C program that figures out how to
   start Prolog by examining the Windows registry. The configure shell
   script does exactly the same, while the real config is a Prolog
   program used by both. We could turn some of the ClioPatria config
   stuff into a library to make it easier to write such scripts.

   Note that many applications do not need any configuration.

4. Some people like auto-configuring applications and some not. I
   don't as I typically want to do installation using a different user
   than running the result.

5. Is great for some applications. Not for all.

[JanWielemaker]

And, (6), we could provide a docker recipe. That is particularly useful for web enabled applications such as ClioPatria or SWISH.

[Anniepoo]

Agreed, anything we do to lower the hassle factor of installing SWI-Prolog lowers cost of adoption.

I notice that we're losing ground to Jena/fuseki/etc. from the Apache community in the semantic web world. Having recently (with Douglas) worked on a semantic web in Java application, and then (EModelWorks) done the same in Prolog, the Prolog solution's glaringly better.

Returning to Douglas' comment - One way to have a killer app opportunity is what Apple did to make Objective C 'grow up'. Make it critical to using a compelling platform.

ROS is a candidate for competition. ROS (the Robot Operating System) from Willow Garage has a lot of issues. In short, it's extremely heavy.

So, imagine an AI and robotics stack built around SWI-Prolog that is accessible to people who aren't professional software engineers. That's a lot more accessible playground than ROS. (And I'm reminded that Snap! has accumulated an interesting ecosystem of hardware interfaces - all that's missing are the NLP/CV bits)

Perhaps something that should be added to the roadmap for the relatively near term is a capable, compelling implementation of a pceDraw style arcs and sticks model editor, as a first small step towards many of these possibilities? I think this was vaguely in the back of my mind with my bit of futzing with the drawing program.

[Anniepoo]

Another thought. Perhaps we're not the right people to be doing this work. Maybe we should recruit someone with a background in marketing or product development who would be willing to look at the many fun toys we have and help us come up with a killer app.

[wouterbeek]

@JanWielemaker Good point! Docker may be an easy install option. Does someone have experience with this?