I am trying to research the use of Prolog now, outside of Academia and am struggling. I was hoping somebody could point me to some real- world applications. Especially outside the field of NLP or speech processing would be really apreciated.
On 2009-10-16, John North <john.nor...@gmail.com> wrote:
> I am trying to research the use of Prolog now, outside of Academia and > am struggling. I was hoping somebody could point me to some real- > world applications. Especially outside the field of NLP or speech > processing would be really apreciated.
Its an interesting topic, but hard to get hard evidence. Quite a few commercial users do not admit they use Prolog openly. These users are likely to have good reasons for that, but for the LP community this is an unfortunate situation.
> On 2009-10-16, John North <john.nor...@gmail.com> wrote:
> > I am trying to research the use of Prolog now, outside of Academia and > > am struggling. I was hoping somebody could point me to some real- > > world applications. Especially outside the field of NLP or speech > > processing would be really apreciated.
> Its an interesting topic, but hard to get hard evidence. Quite a few > commercial users do not admit they use Prolog openly. These users are > likely to have good reasons for that, but for the LP community this is > an unfortunate situation.
> Cheers --- Jan
I've heard that before: that many companies using Prolog commercially want to hide (or at least not openly state) that they use the language. This puzzles me - do they believe they are keeping a trade secret or competitive advantage or something like that?
> On Oct 16, 10:05 am, Jan Wielemaker <j...@nospam.ct.xs4all.nl> wrote:
> > On 2009-10-16, John North <john.nor...@gmail.com> wrote:
> > > I am trying to research the use of Prolog now, outside of Academia and > > > am struggling. I was hoping somebody could point me to some real- > > > world applications. Especially outside the field of NLP or speech > > > processing would be really apreciated.
> > Its an interesting topic, but hard to get hard evidence. Quite a few > > commercial users do not admit they use Prolog openly. These users are > > likely to have good reasons for that, but for the LP community this is > > an unfortunate situation.
> > Cheers --- Jan
> I've heard that before: that many companies using Prolog commercially > want to hide (or at least not openly state) that they use the > language. This puzzles me - do they believe they are keeping a trade > secret or competitive advantage or something like that?
It's probably because the language a program is written in is incidental to the user of the program, and of interest only to a technically minded audience. For instance, I'm in the middle of moving a commercial application to CLP, but few of our customers would be interested in the details. They care about things like that it will in the future be easier (= cheaper) to write custom constraints. So you won't find the info anywhere that the application uses a solver that's written in a variant of Prolog.
> On Oct 22, 5:49 am, contingencyplan <contingencyp...@gmail.com> wrote:
> > On Oct 16, 10:05 am, Jan Wielemaker <j...@nospam.ct.xs4all.nl> wrote:
> > > On 2009-10-16, John North <john.nor...@gmail.com> wrote:
> > > > I am trying to research the use of Prolog now, outside of Academia and > > > > am struggling. I was hoping somebody could point me to some real- > > > > world applications. Especially outside the field of NLP or speech > > > > processing would be really apreciated.
> > > Its an interesting topic, but hard to get hard evidence. Quite a few > > > commercial users do not admit they use Prolog openly. These users are > > > likely to have good reasons for that, but for the LP community this is > > > an unfortunate situation.
> > > Cheers --- Jan
> > I've heard that before: that many companies using Prolog commercially > > want to hide (or at least not openly state) that they use the > > language. This puzzles me - do they believe they are keeping a trade > > secret or competitive advantage or something like that?
> It's probably because the language a program is written in is > incidental > to the user of the program, and of interest only to a technically > minded > audience. For instance, I'm in the middle of moving a commercial > application to CLP, but few of our customers would be interested in > the > details. They care about things like that it will in the future be > easier (= cheaper) to write custom constraints. So you won't find the > info anywhere that the application uses a solver that's written in a > variant of Prolog.
> Cheers, > Thorsten
My overall thinking is that Prolog should (and needs to) have more "market presence" than it currently possesses -- my sense is that it possess next to none. I have no hard evidence to reach this conclusion; it is simply a general sense / gut feeling from looking at projects on the Internet (e.g., SourceForge and Freshmeat) and talking with friends who are industry programmers, so certainly not a sufficiently wide sampling.
So I'm curious whether my assessment is correct -- how much is Prolog being used for programming outside of academia? I also like the restrictions that Mr. North put on this question; NLP is a natural strength for Prolog, but as a result, we cannot use NLP as a basis for estimating the use of Prolog in other programming areas.
If we assume that I'm wrong, and that Prolog has a more than negligible presence, then it would be useful to understand why the perception is to the contrary. I can understand that the underlying programming system is of little importance to the end-users -- that could certainly be part of it. However, by the same token, the end- user has the same level of non-interest if the system is implemented in Python / Ruby / Perl or the C family, and yet most industry programmers (dare I say "almost all"?) will have used at least one of those languages in their work and will have heard of several others. So I would (respectfully, of course) disagree that end-user indifference is a major reason for Prolog having a notable market presence without having a similar level of notoriety.
So I am still left with my questions. Does anybody have any hard[er] evidence for the use of LP in commercial settings, such as surveys and demographics?
On Oct 22, 4:26 am, Tom Schrijvers <tomenanne...@gmail.com> wrote:
Applied, thanks! Is this group also going to engage in discussions on general commercial use of LP, or is it simply an organizational group for the CULP workshops?
On Oct 27, 12:49 am, contingencyplan <contingencyp...@gmail.com> wrote:
> My overall thinking is that Prolog should (and needs to) have more > "market presence" than it currently possesses.
I suppose the proponents of any language that is not 'mainstream' could argue the same thing about the language that they favour. The fact is that there is an eco-system of languages out there, some sharing similar genetic make up, and others more fringe mutations. The world of commercial IT acts as a fitness function on this language evolution and has for multiple reasons given imperative OO the centre ground. This is not because imperative OO is the absolute best way to work. The reasons are many; things just turned out that way, thats where the skill base is and companies need employees already skilled up, the pace of evolution cannot be too fast, real world systems must have good GUI libraries and interfaces to relation databases and to each other, speed used to be a major factor less so nowadays but that coloured the evolutionary process earlier on, programming used to be done at a lower level and is gradually evolving to higher levels but languages derived from C built on the low level ancestry more directly than languages that did not, code re-use, modularity, and many more reasons that I have not thought of.
You're not wrong but consider what other fringe languages should have greater commercial presence? How about OCaml, Haskell, Mercury, Erlang to name some of the more obvious ones. Working in Prolog I do sometimes miss what functional languages have to offer.
I use LP in a commercial setting, though not as the runtime system. I use it as a modeling language for 'model driven engineering', as I have found logic to be the most natural language for describing the models in. No business that I have encountered so far would accept a switch to running their systems entirely on Prolog, but are quite happy to accept generated Java code on the basis that it looks like idiomatic Java and can be created faster than by hand.
I have not shared what I have created so far, partly because I do not want to give my advantage away and using LP in this way is an advantage for me. The real reason is that my ideas are still half baked and I am not yet ready to have them scrutinized by others; if great ideas should be shared perhaps mediocre ones should be held back and worked on to increase their chances of greatness.
There are some real advantages to Prolog and they are not being taken advantage of partly due to ignorance. I think most universities do not teach Prolog as part of Computer Science any more.
I enjoyed looking at the CULP papers on the link posted. Particularly the financial trading system developed in New Zealand/Australia.
>So I am still left with my questions. Does anybody have any hard[er] >evidence for the use of LP in commercial settings, such as surveys and >demographics?
If you consider this "hard evidence": I am using Prolog for commercial applications, and I am using Prolog this way since year 1999. It is being used for programming kernels of quite serious applications. Overall, we have about 200K lines of Prolog.
If you ask "why", then the answer is simple: we are using CLP(FD), and doing CLP(FD) in Java or C++, although possible, has little sense. Prolog is the best platform.
If you ask about problems:
1. Having One More Language within the company is pain in the butt
2. Prolog is small part of larger system(s) written in Java, therefore there is a problem with going across the boundary between these two worlds. This cost time and performance as well as requires extra work,
3. Software engineering aspects of Prolog locate it in more or less 30 years ago. Using vi or emacs is like living in stone age. Situation is improving a bit, but majority of Prologs are lacking modern IDE, profilers and other stuff making life easy
4. I don't know ANY single college/university in the USA where Prolog is the subject of separate, semester long course. What is even worse, on majority of universities there is nothing like course in mathematical logic. What is even more worse, there is general perception that mathematics is not longer needed for computer scientists/engineers. Read few last issues of the Communications of the ACM. In terms of mathematics. logic and formal methods, fresh graduates are totally dumb.
5. Result of the above is that there are no Prolog programmers. I feel like a dinozaur.
A.L.
P.S. Regarding item 4: This doesn't mean that such universities don't exist. However, during last 10 years of interviewing poeple I was able to dectect only one guy who knew the word "Prolog". He was from Egypt
> 3. Software engineering aspects of Prolog locate it in more or less 30 > years ago. Using vi or emacs is like living in stone age. Situation is > improving a bit, but majority of Prologs are lacking modern IDE, > profilers and other stuff making life easy
ECLiPSe has some profilers and debuggers. Although much better than what Sicstus offers but still far from tools for Java or C# languages. Any news about Sicstus' IDE? They claim they are working on it. Also ECLiPSe is working on some IDE (Saros).
> On 28 Paź, 01:40, A.L. <alewa...@aol.com> wrote:
> > 3. Software engineering aspects of Prolog locate it in more or less 30 > > years ago. Using vi or emacs is like living in stone age. Situation is > > improving a bit, but majority of Prologs are lacking modern IDE, > > profilers and other stuff making life easy
> ECLiPSe has some profilers and debuggers. Although much better than > what Sicstus offers but > still far from tools for Java or C# languages. > Any news about Sicstus' IDE? They claim they are working on it. Also > ECLiPSe is working > on some IDE (Saros).
To my point of view, there are also big problems in the language itself, not only the IDE. It is good to write small pieces of code for constraint programming, etc. But it is not easy to use methodologies from software engineering to write large programs. Even worse, once programs are written they tend to look more obfuscated than in other languages.
Prolog should widen its field, the language should be revamped with new features that make programs easier to write. But I do not believe that it can be done in the current way. Most of the best Prolog (or logic) programmers are developers of their own implementation, and the economical support and development comes from the academy: research projects and papers. That divides the community and isolate language improvements on separate implementations. That does not encourage people to learn a language that, as a general purpose language, is artifically kept alive.
I spent my last years programming compilers in Prolog and I often find that algorithms that are a child's play to write in other languages, become incredibly complicated in Prolog. Reusing code is a pain if compared with O.O. languages. There has been a great effort in improving the small details of the language (such as performance, or expressive power), but little to build and support large programs in its whole lifetime. I believe that there is often a misconception that separates software engineering from declarative programming.
Haskell seems a more mature language in those aspects. There is a strong implementation with a large number of contributors, optional experimental features, the language has a nice semantics, and they care about real world applications. For example, they use monads as abtractions to write typically imperative programs declaratively (indeed, they integrate imperative and declarative worlds). But they do not lose the pure nature of their language. That widens the application area of the language, and that keeps it alive: more programmers become interested in it. Also, I do not think that the language is hard to learn (you can even teach a high-school student to write usable code).
The problem I see is that, even if there are people with great ideas, there is not a strong effort (mainly, the economical push) to improve the language. I have seen many good programmers and researchers moving away from Prolog development (programming, implementation, analysis) to more productive fields (paying your mortgage is sometimes more important...).
>On Oct 28, 11:56 am, Wit Jakuczun <wit.jakuc...@gmail.com> wrote: >> On 28 Pa?, 01:40, A.L. <alewa...@aol.com> wrote:
>> > 3. Software engineering aspects of Prolog locate it in more or less 30 >> > years ago. Using vi or emacs is like living in stone age. Situation is >> > improving a bit, but majority of Prologs are lacking modern IDE, >> > profilers and other stuff making life easy
>> ECLiPSe has some profilers and debuggers. Although much better than >> what Sicstus offers but >> still far from tools for Java or C# languages. >> Any news about Sicstus' IDE? They claim they are working on it. Also >> ECLiPSe is working >> on some IDE (Saros).
>To my point of view, there are also big problems in the language >itself, not only the IDE. It is good to write small pieces of code for >constraint programming, etc. But it is not easy to use methodologies >from software engineering to write large programs. Even worse, once >programs are written they tend to look more obfuscated than in other >languages.
Prolog is good within its own applicability area. It is good where it is good. I don't see any reason to write large programs that could be written in other languages more easily.
> On Oct 28, 11:56 am, Wit Jakuczun <wit.jakuc...@gmail.com> wrote:
> > On 28 Paź, 01:40, A.L. <alewa...@aol.com> wrote:
> > > 3. Software engineering aspects of Prolog locate it in more or less 30 > > > years ago. Using vi or emacs is like living in stone age. Situation is > > > improving a bit, but majority of Prologs are lacking modern IDE, > > > profilers and other stuff making life easy
> > ECLiPSe has some profilers and debuggers. Although much better than > > what Sicstus offers but > > still far from tools for Java or C# languages. > > Any news about Sicstus' IDE? They claim they are working on it. Also > > ECLiPSe is working > > on some IDE (Saros).
> To my point of view, there are also big problems in the language > itself, not only the IDE. It is good to write small pieces of code for > constraint programming, etc. But it is not easy to use methodologies > from software engineering to write large programs. Even worse, once > programs are written they tend to look more obfuscated than in other > languages.
Exactly, I use Prolog to write computational kernels (mainy CLP(FD) based solvers). Such kernel is not large (say few thousand LOC) comparing to Java/C# parts of the application. Using modules, Sicstus objects (or Logtalk) helps me in developing Prolog's code. Having good IDE would make me more productive.
On Oct 28, 10:56 am, Wit Jakuczun <wit.jakuc...@gmail.com> wrote:
> ECLiPSe has some profilers and debuggers. Although much better than what Sicstus offers
Good point. What in particular are we lacking here?
> Any news about Sicstus' IDE? They claim they are working on it.
It has kept us busy indeed. The SICStus Prolog 4.1 beta release is scheduled for 1 November. It will feature an Eclipse-based IDE with working name SPIDER. Some members of our development team, die-hard Emacs users throughout their carreers, have switched to SPIDER.
> On Wed, 28 Oct 2009 04:26:22 -0700 (PDT), jfmcjf <jfm...@gmail.com> > wrote: >>To my point of view, there are also big problems in the language >>itself, not only the IDE. It is good to write small pieces of code for >>constraint programming, etc. But it is not easy to use methodologies >>from software engineering to write large programs. Even worse, once >>programs are written they tend to look more obfuscated than in other >>languages.
For Prolog `in the wild', that may be true, I see a lot of really ugly Prolog around, using poor layout, poor naming conventions and weird control-structures. That is mostly a matter of education, in particular learning design patterns. As long as people follow shared design patterns, the code remains accessible for others. If they follow their own creativity you end up with lots of hard-to-understand control-structures. That is not new and not unique to Prolog. Therefore, I don't think that is a real issue with the language. There is a need for good teaching material in these areas. The Craft of Prolog is a `must-read', but it would be much nicer if it was more up-to-date.
In my view, the most serious missing piece is good support for refactoring. Notably adding/deleting arguments and changing datastructures can be a nightmare. Good IDEs have tools for such operations, but I'm not aware of any that supoorts Prolog. Some languages have type-support, which at least helps finding the problems. Prolog has none of these, although quite many implementations can warn about inconsistent arity (by means of undefined or discontiguous predicates or as Ciao does by complaining about reusing the same name with different arity in general).
Tom (and Mycroft/O'Keefe, Mercury, Visual Prolog, ...) has already proposed a type-system that might be of some help here.
> Prolog is good within its own applicability area. It is good where it > is good. I don't see any reason to write large programs that could be > written in other languages more easily.
One reason has been mentioned here before: adding another language comes at a (big) price. So, a dedicated language has to offer something very special before people are convinced they need to take it on board. If they can get away with a half-as-good solution with twice the efford in the language they use for their daily work, they will (rightfully) ignore the dedicated language. I think the 1/2 and 2 are conservative estimates.
So, in my view, to be a language of choice you have to offer a comprehensive environment in which you can program solutions.
There is also a bright side to all of this: those that take the trouble to master the language can use it as a secret weapon :-)
> On Wed, 28 Oct 2009 06:55:31 -0700 (PDT), Mats Carlsson ><ma...@sics.se> wrote:
>>On Oct 28, 10:56 am, Wit Jakuczun <wit.jakuc...@gmail.com> wrote:
>>> ECLiPSe has some profilers and debuggers. Although much better than what Sicstus offers
>>Good point. What in particular are we lacking here?
> SICStus debuggers are fine. This what is missing is high resolution > time profiling. But I am not sure that ECLiPSE has one...
It depends on the platform whether or not you can do that and on the amount of effort you are willing to spend getting the best option for your platform. I guess Prolog falls behind in the sense that its developers have less resources to look into the non-portable tricks of each platform to get the best results. Some platforms only offer a good API for profiling native code. Prolog isn't the only victim here.
Roughly, you have two options: statistical profiling and actual measurement. Both have their pros and cons, but in my experience statistical profiling gives very acceptable results on modern OSes (often with higher frequencies for ITIMER_PROF) if your program runs at least few seconds.
Surely, a profiler is a must-have tool. If it is lacking, don't blame the language. There are enough implementations that offer one.
On Oct 28, 11:26 am, jfmcjf <jfm...@gmail.com> wrote:
> I spent my last years programming compilers in Prolog and I often find > that algorithms that are a child's play to write in other languages, > become incredibly complicated in Prolog.
The reverse is also true. Is easy to find algorithms that are trivial in Prolog and cumbersome in other languages. Hard for a programming language to cover all bases without loosing itself.
> Reusing code is a pain if > compared with O.O. languages.
That pain can be greatly relieved if you take advantage of Logtalk instead of using plain Prolog. Moreover when Logtalk provides you with code encapsulation and code reuse features that go beyond your average OOP language (and without changing any of the fundamentals of logic programming). But, as already discussed in this thread, you also need tools to go along with the language. E.g. cross-referencers tools, refactoring tools, documenting tools, profilers, and debuggers.
> There has been a great effort in > improving the small details of the language (such as performance, or > expressive power), but little to build and support large programs in > its whole lifetime.
True but things are improving. A number of recent implementations, both open source and commercial, are investing in better tools and IDEs.
> I believe that there is often a misconception that > separates software engineering from declarative programming.
Fully agree. Software engineering and declarative programming are a perfect fit. Logtalk/Prolog code is often high-level and can be read as executable specifications. Is also compact compared with code written in other programming languages, helping minimizing the distance between the problem domain and the solution domain.
> 4. I don't know ANY single college/university in the USA where Prolog > is the subject of separate, semester long course. What is even worse, > on majority of universities there is nothing like course in > mathematical logic. What is even more worse, there is general > perception that mathematics is not longer needed for computer > scientists/engineers.
There are universities in US that offer both undergraduate and graduate courses in logic and logic programming (including Prolog). I can only give you examples from my university.
Undergraduate level courses: Artificial Intellicence course (50% of the course describes logic and resolution): http://www.cs.sunysb.edu/~cse352/ Logic course: http://www.cs.sunysb.edu/~cse371/ Principles of Programming Languages (includes logic languages and Prolog homeworks; every couple of years the course is taught by Dr Warren and the project for the semester was to implement WAM): http://www.cs.sunysb.edu/~cse307
Graduate level courses: Computing with Logic course (Prolog, the hw was to implement interpreters in Prolog for stable and well-founded models; offered every year either in spring or fall): http://www.cs.sunysb.edu/~cse505 Logic in Computer Science course: http://www.cs.sunysb.edu/~cse541 Advanced Logic in Computer Science (a semester long course on implementation of WAM and tabling; last time it was offered in the spring of 2009): http://www.cs.sunysb.edu/~ces641 Seminar in languages (most papers are based on logic programing): http://www.cs.sunysb.edu/~cse645/ Theory of Database Systems (also describes Datalog): http://www.cs.sunysb.edu/~cse532
On 28 Oct 2009 14:00:23 GMT, Jan Wielemaker <j...@hppc323.few.vu.nl> wrote:
>On 2009-10-28, A.L <alewa...@aol.com> wrote: >> On Wed, 28 Oct 2009 04:26:22 -0700 (PDT), jfmcjf <jfm...@gmail.com> >> wrote:
>>>To my point of view, there are also big problems in the language >>>itself, not only the IDE. It is good to write small pieces of code for >>>constraint programming, etc. But it is not easy to use methodologies >>>from software engineering to write large programs. Even worse, once >>>programs are written they tend to look more obfuscated than in other >>>languages.
You are responding to my post, but commenting jfmcjf post :)
> There is a need >for good teaching material in these areas. The Craft of Prolog is a >`must-read', but it would be much nicer if it was more up-to-date.
Craft of Prolog is pretty old and actually not that good as giude for good, large scale programming. And is out of print for years.
>In my view, the most serious missing piece is good support for >refactoring. Notably adding/deleting arguments and changing >datastructures can be a nightmare. Good IDEs have tools for such >operations, but I'm not aware of any that supoorts Prolog. Some >languages have type-support, which at least helps finding the problems. >Prolog has none of these, although quite many implementations can warn >about inconsistent arity (by means of undefined or discontiguous >predicates or as Ciao does by complaining about reusing the same name >with different arity in general).
Yes, lack of good IDE is THE problem. I have one Prolog application that con sits of over 100 Prolog files. Making changes is really hard. I am using PowerGrep and EditPadPro from JGSoftware to do development, and this is far from being fun. Doing the same with Java application consisting of almost 1000 files with Eclipse is no problem. Especially using "refractor" option and such.
Cannot wait for Eclipse for SICStus :)
>Tom (and Mycroft/O'Keefe, Mercury, Visual Prolog, ...) has already >proposed a type-system that might be of some help here.
>> Prolog is good within its own applicability area. It is good where it >> is good. I don't see any reason to write large programs that could be >> written in other languages more easily.
>One reason has been mentioned here before: adding another language comes >at a (big) price. So, a dedicated language has to offer something very >special before people are convinced they need to take it on board. If >they can get away with a half-as-good solution with twice the efford in >the language they use for their daily work, they will (rightfully) >ignore the dedicated language. I think the 1/2 and 2 are conservative >estimates.
Actually, factor is MUCH bigger. Before using Prolog CLP(FD), we made attempt to use some expensive commercial constraint libraries in C++. This project was abandoned after about a year, because it was obvious that it would be never completed on time and within budged. Comparing the results of this unfinished C++ project and (successful) Prolog project it was estimated that development time was reduced by factor between 20 to 50.
The same regards computing time. I am constantly evaluating available Java constraint solvers. They are extremely slow. In last attempt, some Java solver needed more time to create domain variables only than Prolog needed to solve the complete problem
At this moment, I don't see any other platform than Prolog that could be used efficiently for large scale real time constraint programming
>So, in my view, to be a language of choice you have to offer a >comprehensive environment in which you can program solutions.
Yes - but as I stated above: advantages of Prolog are such that I will be using it even with "stone age" development environment. No question that it would be good to have something better than emacs - but there is always the possibility to create the environment using available tools (PowerGrep and EditPadPro in my case)
> >> ECLiPSe has some profilers and debuggers. Although much better than what Sicstus offers
> >Good point. What in particular are we lacking here?
> SICStus debuggers are fine. This what is missing is high resolution > time profiling. But I am not sure that ECLiPSE has one...
ECLiPSe has a profiler that gives you information about time spent in a particular predicate. In Sicstus you can only get information about times a predicate has been called. I can not say much about resolution in ECLiPSe. It was good enough for me to detect bottlenecks.
> >> ECLiPSe has some profilers and debuggers. Although much better than what Sicstus offers
> >Good point. What in particular are we lacking here?
> SICStus debuggers are fine.
ECLiPSe provides its user with GUI for debugging. It is quite useful. In Sicstus there is only console-based debugger. Nevertheless, both Prologs do not provide out of box tools for debugging CLP(FD) codes. There is debugger for clpfd in Sicstus (fdbg module) but I mean something like CLPGUI (but integrated with for example IDE).
>On 2009-10-28, A.L <alewa...@aol.com> wrote: >> On Wed, 28 Oct 2009 06:55:31 -0700 (PDT), Mats Carlsson >><ma...@sics.se> wrote:
>>>On Oct 28, 10:56 am, Wit Jakuczun <wit.jakuc...@gmail.com> wrote:
>>>> ECLiPSe has some profilers and debuggers. Although much better than what Sicstus offers
>>>Good point. What in particular are we lacking here?
>> SICStus debuggers are fine. This what is missing is high resolution >> time profiling. But I am not sure that ECLiPSE has one...
>It depends on the platform whether or not you can do that and on the >amount of effort you are willing to spend getting the best option for >your platform. I guess Prolog falls behind in the sense that its >developers have less resources to look into the non-portable tricks of >each platform to get the best results. Some platforms only offer a good >API for profiling native code. Prolog isn't the only victim here.
>Roughly, you have two options: statistical profiling and actual >measurement. Both have their pros and cons, but in my experience >statistical profiling gives very acceptable results on modern OSes >(often with higher frequencies for ITIMER_PROF) if your program runs at >least few seconds.
I am using third option: I am doing profiling on Java side. However, this is "profiling in the large". I would like to have "magnifying glass" and check time within Prolog.
In principle, Java offers nanosecond resolution - with restriction that the platform makes it possible, However, I believe that most platforms offers millisecond resolution
>Surely, a profiler is a must-have tool. If it is lacking, don't blame >the language. There are enough implementations that offer one.
When I asy "Prolog", usually I have in mind specific implementation and environment - unless I say otherwise :)
On Wed, 28 Oct 2009 08:06:20 -0700 (PDT), fodor <fodor.p...@gmail.com> wrote:
>> 4. I don't know ANY single college/university in the USA where Prolog >> is the subject of separate, semester long course. What is even worse, >> on majority of universities there is nothing like course in >> mathematical logic. What is even more worse, there is general >> perception that mathematics is not longer needed for computer >> scientists/engineers.
>There are universities in US that offer both undergraduate and >graduate courses in logic and logic programming (including Prolog). I >can only give you examples from my university.
Good to know. However, as I said, during last 10 years I was unable to detect candidate who would know what "Prolog" means.
If these courses are not mandatory, how many students will select them?
Once I was teaching Real Time Programming using Ada. Students collected all job ads from "Classified" section of local newspaper (this was in large city with a lot of industry) and when semester completed, wrote complain to the Dean about my course. They attached all Classified newspaper section and asked the Dean to find one single job opening that required Ada.
Obviously, he ignored the complain, but later had long and friendly discussion with me. After this discussion I found myself working all summer converting course from Ada to C.
I am afraid that the same paradigm works with regard of Prolog. Once again, read CACM discussion about "Java Schools"
> [...] > control-structures. That is not new and not unique to Prolog. Therefore, > I don't think that is a real issue with the language. There is a need > for good teaching material in these areas. The Craft of Prolog is a > `must-read', but it would be much nicer if it was more up-to-date.
I still believe that there is a real issue with the language... I do not understand why a language as powerful a Prolog does not include by default user-defined functions, loops, object-orientation, declarative IO, type systems, analysis, etc. I know that all those things have been around in papers for a long time, with different proposals, but none is widely accepted.
> In my view, the most serious missing piece is good support for > refactoring. Notably adding/deleting arguments and changing > datastructures can be a nightmare. Good IDEs have tools for such > operations, but I'm not aware of any that supoorts Prolog. Some > languages have type-support, which at least helps finding the problems. > Prolog has none of these, although quite many implementations can warn > about inconsistent arity (by means of undefined or discontiguous > predicates or as Ciao does by complaining about reusing the same name > with different arity in general).
Refactoring is hard because the language makes it hard. I can add and remove arguments and change data structures in C with minor pains, even in emacs :)
> > Prolog is good within its own applicability area. It is good where it > > is good. I don't see any reason to write large programs that could be > > written in other languages more easily.
I disagree here. Prolog is a general purpose language. Do Haskell programmers think the same about their language?
On Oct 28, 6:46 pm, jfmcjf <jfm...@gmail.com> wrote:
> > > Prolog is good within its own applicability area. It is good where it > > > is good. I don't see any reason to write large programs that could be > > > written in other languages more easily.
> I disagree here. Prolog is a general purpose language. Do Haskell > programmers think the same about their language?
Haskell programmers consider their language to be general purpose. That does not mean that Prolog programmers should think that. There are many special purpose languages that are much better at what they do than general purpose languages. For instance, Haskell programmers sometimes find a need for Prolog. They then use a library that provides Prolog as an embedded Domain Specific Language within Haskell. So while they don't turn to a Prolog system for their Prolog needs, but they're using Prolog nevertheless.
