A full tutorial for learning Prolog, using an interactive fiction game for it's basic example. In the course of the tutorial you will also build an expert system and a business application.
"""
Not too sure how that fits with the restrictions in the download page
Looks like a standard case of "the source is OSS and you can use it for free if you build from source, but if you want pre-built binaries, you have to buy them from us". That's basically what Red Hat does with RHEL... you can get the source and build yourself, or you can buy RHEL binaries from them (for the sake of argument, for the moment lets forget about support and indemnification and all the 'other' stuff buying a subscription gets you).
Of course, one difference with RHEL is that there's a vibrant community of people who take the RHEL source and rebuild it and release things like CentOS. Presumably you could do the same kind of thing with the Amzi source, so long as you respect their trademarks and what-not.
I hate to pick nits too much, but I kinda dislike when people use this kind of phrasing. "Open source" and "commercial" are not antonyms. Something can be both open source and commercial at the same time. RHEL is a good example.
I mean, I get the point they're trying to make (I think) but I wish people would be a little more precise when talking about this topic.
I agree. I posted an essay on Schneier's blog countering the false dilemma between open source and proprietary. I'm modifying next version to say "shared source" as "open source" has specific meanings. Yet, many needs can be met with shared-source, proprietary software that are thought to be OSS-only.
Proprietary and free software are a dichotomy. It's commercial and free software that's a false dichotomy. It doesn't matter if you can "see the source" if you don't have the four freedoms when using the software.
You can have all of the key freedoms with the restriction that they're paid for. This continues development, maintenance, and support. I'm not speculating as there's software with source available developed through commercial licensing.
So, "free as in Stallman" software might be a dichotomy with proprietary but not "free as in free enough for many people." That exists and can flourish further with right mix of organizations, charters, licenses and so on. Just little work in it.
> You can have all of the key freedoms with the restriction that they're paid for.
None of the four essential freedoms mention price. I work for a free software company which sells that software. I don't know what you're referring to. I clearly said that "free and commercial software are a FALSE dichotomy" -- meaning that you can have commercial free software.
> So, "free as in Stallman" software might be a dichotomy with proprietary but not "free as in free enough for many people."
Again "free as in Stallman" doesn't have anything to do with whether you pay for the software (in fact, he used to sell copies of GNU Emacs for $100). Proprietary software is software that takes away your freedom to use, modify and distribute the software. You can pay for free software and you can pay for proprietary software. But you can't get proprietary software that respects your freedom. That is a dichotomy.
Free doesn't refer to price it refers to freedom. Please stop spreading misinformation.
"I clearly said that "free and commercial software are a FALSE dichotomy" -- meaning that you can have commercial free software."
Oh, I apologize. I clearly misread that exact statement. I bet it's because free, commercial, and false in same sentence almost always are arguing against what you said. That the two can't be combined. Whereas, we're arguing in different ways that they can. I must have skimmed it with my brain jumping right past the actual words to its intuitive guess of what they meant. At least I see how I failed. :)
"Proprietary software is software that takes away your freedom to use, modify and distribute the software. You can pay for free software and you can pay for proprietary software"
What firms are bringing in billions licensing or selling free software? I need a list of successful companies longer than Red Hat that can compete in both investment and lawsuits with big, proprietary firms. You can sell truly free software but almost nobody will buy it w/ you being super-niche in revenue. Whereas, useful and proprietary software can bring in significant money from customers esp in enterprise or government scenes. The proprietary ones just tend to scheme on customers, disappear, and other stuff. The free ones often aren't developed much, maintained, and so on.
My concept is to give you all the freedoms except for free distribution for a given project. You can use, modify, whatever the software as long as you pay the non-profit that develops, maintains, and supports it. You can also re-distribute that to other paying customers of the project. If non-profit stop supporting or distributing it, it goes BSD or Apache immediately per terms of the license or charter.
What are you missing other than widespread, free distribution in this model? As in, the availability of freeloaders that rarely contribute crap back. Do note that the project can give free copies in exchange for testing/feedback to get many eyeballs effect. Can also give discounts or free copies to academics to get their improvements.
What's left? Seriously, as I'm trying to see how close proprietary, shared source can get to FOSS without loosing the "sustainable, cash flow" part.
> What firms are bringing in billions licensing or selling free software?
I work for SUSE, which is a free software company. Red Hat is another, as you mentioned. I found a list on Wikipedia[1] which has quite a few entries (though quite a few of those companies either no longer exist or were bought out by companies that don't exclusively work on free software).
> You can sell truly free software but almost nobody will buy it w/ you being super-niche in revenue.
That depends on your business model. The SUSE (and Red Hat) business model is to sell you a complete operating system which you are guaranteed to have support for. This is paid for by license costs for the base system and "modules" which are other pieces of software. If a user decides to install software which they didn't pay for, we don't support such a configuration if it breaks. Support in this case is not just support in setting up the system, it's also security updates and bug fixes (which are sometimes written by us and contributed back to the community). This sort of business model allows you to sell completely free software, because you're not selling the actual software you're selling licenses and support.
> My concept is to give you all the freedoms except for free distribution for a given project.
That would then be considered proprietary software in the strict sense of the word. It's better than nothing, but you have no practical freedom in that case because you cannot share your improvements to create a community -- one of the goals of the free software movement. The main thing to know is that free software is meant to mean that you cannot become entirely dependent on a company to support you. If you don't have the freedom to distribute modified and unmodified copies then you're (practically) at the mercy of the company that gave you the software.
> Seriously, as I'm trying to see how close proprietary, shared source can get to FOSS without loosing the "sustainable, cash flow" part.
Personally, I would never buy such software. I understand why it seems to be valuable to you to remove the free distribution freedoms of your users, but I don't agree with the logic. The problem is that you're still trying to "just sell the damn code", which doesn't guarantee you revenue with free software licenses (you can still sell it, but it's possible for a user to share the code with others without you knowing about it). Now, it's not very likely that many users would actually share the code (unfortunately), but it is possible. So, now you have to ask the question "what should I be selling". If you sell support (clients pay for you to develop new features for them, providing security fixes, bug fixes, etc) then you can make money selling completely free software. If you're scared of someone making money from your code, make it GPL and then you can take their changes back into your software.
Free software and proprietary software have only one difference which is how their distributed. Proprietary software is distributed in binary form only. Free software is usually distributed in binary and source form, but you can also distribute it in binary form with a link to where the source code is (and you can make it only be available to your customers -- that's still free software).
Thanks for a thorough reply. I'll try to address the concerns.
"I found a list on Wikipedia[1] which has quite a few entries (though quite a few of those companies either no longer exist or were bought out by companies that don't exclusively work on free software)."
Appreciate the list. A bunch of those, including yours, are proprietary software companies that also GPL stuff. Or hybrids were a huge chunk of the revenue is support or GPL-component consulting instead of licensing proprietary addons. Still worth considering but not a "free software" company if issuing paid licenses.
" it's also security updates and bug fixes (which are sometimes written by us and contributed back to the community). This sort of business model allows you to sell completely free software, because you're not selling the actual software you're selling licenses and support."
That's true. It's also the model that rarely makes any real money. Red Hat and SUSE are exceptions to the rule, esp Red Hat. That they both license proprietary software on top of that model clouds the issue further. We'd have to have companies with only FOSS offerings plus support and services matching those or proprietary revenues to make the argument. I'll look at your link to see if I find those plus if there's financial data on app/feature vs support licensing to see what split of the revenue/profit they make.
"but you have no practical freedom in that case because you cannot share your improvements to create a community -- one of the goals of the free software movement."
You can do that exactly how I described. You underestimate how powerful of communities that can develop around proprietary software. Microsoft and IBM are extreme examples that had more to do with monopolistic practices. So, maybe Borland's Delphi or even early Solaris are better examples. The community is just limited to those that are willing to pay. That's FOSS's advantage.
" If you don't have the freedom to distribute modified and unmodified copies then you're (practically) at the mercy of the company that gave you the software."
This is a huge problem. It's why I'm working to eliminate it but FOSS has clear advantage here. We saw this with Oracle dropping OpenSolaris followed by others picking it up.
"Proprietary software is distributed in binary form only."
That's not true at all. MCP, the villain in Tron & brilliant OS for Burroughs, was distributed in source form to clients in the 60's with their modifications/fixes often going into new releases. Many proprietary software since were similarly shared source. The high-assurance security kernels even mandated vendors supplying source so you could meet A1-class requirement of inspecting and building it yourself. Even Windows source is available to some partners. There's also dual-licensed model where free software is a byproduct of licensing proprietary, shared-source software. So, proprietary and source available are not contradictory in any way. It's just distribution part as you said where distinctions must be made.
"If you sell support (clients pay for you to develop new features for them, providing security fixes, bug fixes, etc) then you can make money selling completely free software."
This is true. The question is "Do I make the same money at same market share as if I license it for low pricing?" I can imagine a database that cost even $5,000 per organization that's competitive with popular RDBMS on common usage with better reliability or security will probably break even on its development cost after first few dozen or so customers. That's plenty for development with enough left for support and administrative stuff. A $1,000/yr support agreement will take substantially more customers to cover all costs, especially development. Only exception I could see is if the developers were the admins and suppo...
So, PROLOG people, how excited should anyone be about this? This vs SWI, Visual Prolog, Prolog in a LISP like Allegro, or alternatives like Mercury. Is this significant in general or just for their community of users?
I worked at a place a handful of years ago that used SICStus (https://sicstus.sics.se/) because it was quite a bit faster than the other implementations.
I'd like to revisit prolog, I think it is an underused language in industry.
I work in academia, where SICStus is usually the most popular besides SWI Prolog. If SICStus went open source, that would be big news for me/us. This not so much.
If SICStus went open source or free for academic use, I would probably use that in my research/courses over SWI Prolog. Mostly because of familiarity, performance, and compatibility reasons.
Prolog has some nice advantages for such knowledge-based language processing:
- With relatively little work, terms can be used to represent linguistic feature structures. You can build a small type system using meta programming and define operators on feature structures.
- Unification can be used build larger structures, check syntactic constraints, etc.
- Backtracking makes handling ambiguity in parsers/generators much easier
There are two quite elaborate chapters in my PhD thesis about the system mentioned above and the generator:
Not an expert, but certainly an amateur "Prolog person."
Frankly, SWI gets all the action. There are times where it isn't the most efficient Prolog, but the toolset you're going to get from AMZI is much more limited, and that in the end is going to be a bigger deal. Does AMZI have ODBC, CLP, CHR, and a web framework? Probably not. SWI has the biggest community, the largest built-in library, the most 3rd-party packages, and is the easiest to install. Everything else is basically tied for second place. Except Visual Prolog, which comes last. :)
It's kind of a shame, because my earliest exposure to Prolog was through AMZI; they had a nice Windows IDE you could try for free (30 minutes at a whack). I went through their "Nani Quest" tutorial and that gave me positive memories of Prolog that I revisited later.
Mercury is an interesting language, but not having a REPL is a huge problem for me. The language mixes in some good ideas from Haskell and Clean. The tutorial comes off as sort of condescending towards Prolog users and fans though. Having to furnish modes and effect types is a bit of a burden.
Allegro is a pretty compelling product, but when I want to do Prolog, I want to do Prolog. core.logic in Clojure seems like it would be more interesting to me, because Clojure is enough better than Common Lisp. I believe core.logic is based on miniKanren, which is also interesting.
The Prolog implementations I sometimes wish I knew more about are B-Prolog, YAP and XSB. But I don't really have the kinds of performance problems that would benefit from tabling or a more sophisticated compiler.
>> I went through their "Nani Quest" tutorial and that gave me positive memories of Prolog that I revisited later.
Yeah, that's a great tutorial to the language, I learned a buttload from that when I was doing my degree. Not to look down on Learn Prolog Now! and others, but this is how to teach Prolog to university students.
Just a note on Nani Quest/Adventure in Prolog: it doesn't work in SWI-pl. I gave it a shot about 6 months ago and got to chapter 7 before stuff stopped working right. It was an excellent tutorial up to that point though.
Well you can find versions on github (that's how I realized it was incompatible, instead of me being incompetent) but it's not terribly great pedagogy to have a text book explaining things piece meal and then having to sort of eyeball some one else's full source code and try to guess which bits are necessary changes and which are that persons idiosyncrasies.
Note that Swi Prolog introduced some very big changes in version 7.0, that break interfaces left and right. It's to (Swi) Prolog what 3.4 is to Python. So if you were trying to follow Nani Quest with Swi 7.x and it gave you trouble, I'd try installing an earlier version.
I was on LPA Prolog when I did Nani Quest and I don't remember having issues, but it's been a while so I'm not sure.
I'm first of all excited by the fact that this made first page on HN. I didn't realise there was that much interest in Prolog news (as in more than two or three people).
Also, having more open-source Prolog engines is a very good thing, both for the language and for the project itself. For the project, it's good because it makes it easier for a community to grow around it. Swi has benefited enormously from its popularity (Jan Wielemaker has commented on this occasionally). For the language, it's good because the more healthy Prolog communities we have, the more we can hope to get new people interested in the language.
Comparing to other Prologs (and Prologs-ish'es) the problem with having closed-source and only for-pay Prolog engines is mainly one of portability, which in the Prolog world is a bit shit (and that's a vast understatement).
Frex, I wrote my degree dissertation using Win-LPA Prolog in 2010-11. LPA is commercial and I don't have a licence anymore (I had a student one) so now I can't run my dissertation. I tried (and tried (and tried)) to make it work on Swi but failed (and failed (and failed))[1].
The problem is there are subtle differences between implementations that bite you in ways you never thought possible, and it's just aaaargh hard to get the same program running in the same way on two different Prologs.
Apparently the exception to this portability hell is Yap and Swi, who have worked together to maintain some compatibility with each other. I don't have experience of this myself (after getting burned I've stuck to Swi) but if Amzi open-sourcing their stuff also means they'll be more open to this sort of working with others, then that's really, really amazing news.
The problem is there are subtle differences between implementations that bite you in ways you never thought possible, and it's just aaaargh hard to get the same program running in the same way on two different Prologs.
Or even between versions of the same implementation. E.g., I know of one project that sticks with SICStus 3, because in SICStus 4 findall/3 removes blocked goals from copied variables. This system relies quite heavily on blocked goals and working around this change turned out to be too expensive.
(If I recall correctly ;).)
Another example is SWI Prolog diverging from the ISO standard in version 7 (e.g. double quoted strings are now a type on their own, rather than a list of character codes). Luckily, there is a --traditional flag for older code.
In both cases, there are good reasons for the changes, but it makes portability hard.
Edit: wanted to add that this is not intended to be a critique of these particular (great) implementations of Prolog.
>> Or even between versions of the same implementation. E.g., I know of one project that sticks with SICStus 3, because in SICStus 4 findall/3 removes blocked goals from copied variables. This system relies quite heavily on blocked goals and working around this change turned out to be too expensive.
That sort of thing? Anyway yeah, sounds typical :/
With Swi I hurt a little recently when an update screwed up some of my stuff but then that was my fault for doing hacky tricks and trying to use modules as they're not meant to be.
>> In both cases, there are good reasons for the changes, but it makes portability hard.
Oh indeed. I started using 7.x the moment it was out pretty much, knowing that
it means I'm tied to Swi for good and bad, but there's much more good than bad
and so far I haven't regretted it.
That makes sense. Ensuring compatibility and network effects were key attributes successful software in Gabriel's Worse is Better essays. That Prolog implementations have inadvertently sabotaged that effect probably contributes to them being less niche than they would be.
Btw, have you tried Mercury? My last foray into logic programming made it seem like it was killing Prologs in quite a few fronts. Prover work moved onto HOL, Coq, etc. Some people still use it for type-checking and queries. Yet, seems hard for me... not a logic programmer btw... to justify Prolog given capabilities and results from other tools. Any ideas on why it's worth keeping around or would you use an alternative today?
Regarding dissertation, I lost most of life's work when three HD's (main + 2 backups) all died within short time of each other. Encrypted with custom crypto that also fried haha. You can't run something you spent years on and is referenced in your degree. I feel your pain or irritation on that. ;)
Note: Oh shit, it's a Magic the Gathering interpreter! I used to play that every day with friends like a decade ago to pass time at school/work. I even wrote some GUI's and game engines for it but really alpha stuff. Probably would've wrote an AI for it if I didn't discover Starcraft. Might try to read some of it this week if I get spare time even though idk Prolog anymore. Maybe I'll learn something anyway or get some nostalgia at the least. :)
>> Regarding dissertation, I lost most of life's work when three HD's (main + 2 backups) all died within short time of each other. Encrypted with custom crypto that also fried haha
Ouch. Oh dear, that sounds horrible.
>> Btw, have you tried Mercury?
I've picked it up a few times but I keep coming back to vanilla Prolog. It's great but I'm a bit scared by the tiny amount of adoption. I know it's kind of ironic: low adoption feeds back on to itself.
>> Any ideas on why it's worth keeping around or would you use an alternative today?
I do a lot of nlp for university, and although I use Python for all the machine learning stuff, the text processing capabilities of Prolog are beyond any comparison with anything else.
For instance, everyone uses regular expressions for tiny bits of parsing and string manipulation. Prolog uses a sort of pattern matching, unification, that is like regular expressions except without any special syntax and Turing-complete.
For language processing, most interpreters have something called Definite Clause Grammars. In short, it's syntactic sugar that lets you declare a grammar, except the grammar is also a parser, that recognises and generate strings (because Prolog). They make developing a parser a piece of cake.
Also, Prolog runtimes are essentially fast, in-memory relational databases, with added reasoning (and no SQL). I can think of many applications that could use that sort of thing. Plus, the language itself is the database, so there's no object-relational impedance mismatch and whatnot.
>> Might try to read some of it this week if I get spare time even though idk Prolog anymore
Thanks, I appreciate that. But please keep in mind: 5 years ago and embarrassing :)
Shows it's still useful for sure. But, Watson uses a lot of techniques for it's operation with several languages integrated together w/ Prolog just one. And it does it on this hardware: "Watson employs a cluster of ninety IBM Power 750 servers, each of which uses a 3.5 GHz POWER7 eight core processor, with four threads per core. In total, the system has 2,880 POWER7 processor threads and 16 terabytes of RAM." (Wikipedia)
My house might burn down haha. It would be interesting to know a complex, useful, performant application coded entirely in PROLOG that wasn't a Visual Prolog IDE or something. ;) A list of those with what advantages and headaches Prolog gave the developers would be a nice start.
A superficial inspection of the engine files seems to say most of them have not changed since 2006-2009 timeframe. Did they run out of ideas, or enthusiasm, or money, I wonder?
I'm not an AI specialist, but to my limited understanding: AI today is mostly machine learning, which means letting an algorithm build classifications from data, and deducting (more like just matching) things from the data that was gained from the learning (basically statistically). Prolog is about writing rules/matches/classifications manually, and then deducting logically from these (not statistically, but precisely). Prolog and other logic languages aren't playing in the same area, and their approach will remain relevant in the future in the areas where they already fit (e.g. expert systems with rules written by humans, writing machine checked mathematical proofs).
Now I should probably recommend you to play a bit with both approaches and do the same myself.
Very helpful. Prolog is more of an expert system(my classmate used that for smart navigation for big city traffic when GPS was not available then, not sure how that can be done though). AI is more of neural network nowadays that is learning from some sample data set and then make decisions out of that.
I would say that AI eventually went entirely different direction, instead of trying to specify some set of symbolic rules encoding knowledge, we currently throw lots of data at layered neural networks.
So, if prolog has future, it probably is outside of AI research.
I would say, that verifying is one of the places where logic programming never went away. I.e if you ever wanted to write type checker of protocol verification, you might write an embedded prolog first.
Prolog and erlang are not the same, or even particularly similar. Some features (such as unification, which is what erlang uses, not assignment, with the = symbol) are present, and inspired by, prolog. But the underlying computational models aren't the same. Erlang is functional/concurrent/procedural (procedural meaning you write an explicit sequence of steps). Prolog is functional/declarative. You don't (normally) write explicit steps. Rather, you describe the solution you want to find, describe the configuration of a system (essentially propositions and axioms), and let prolog search for your solution. You can do a lot more than that with the operators (declaring order of execution, terminating early, etc.), but the underlying computational model is this search. You would not use them for the same domain.
You can because they're both turing complete and thus capable of expressing the same computations. You won't because erlang excels in its concurrency model (and performance with many concurrent processes), and prolog excels in its declarative/search model. I believe there are some other languages (Oz/Mozart?) that might be suitable if you want a hybrid of erlang's concurrency and prolog's declarative model.
49 comments
[ 3.0 ms ] story [ 96.4 ms ] thread[edit: for v9] Not too sure how that fits with the restrictions in the download page, http://www.amzi.com/AmziPrologLogicServer/store.php
But I do get a small itch to try the http://www.amzi.com/AdventureInProlog/advtop.php
""" Adventure in Prolog ™ — Prolog Tutorial
A full tutorial for learning Prolog, using an interactive fiction game for it's basic example. In the course of the tutorial you will also build an expert system and a business application. """
Looks like a standard case of "the source is OSS and you can use it for free if you build from source, but if you want pre-built binaries, you have to buy them from us". That's basically what Red Hat does with RHEL... you can get the source and build yourself, or you can buy RHEL binaries from them (for the sake of argument, for the moment lets forget about support and indemnification and all the 'other' stuff buying a subscription gets you).
Of course, one difference with RHEL is that there's a vibrant community of people who take the RHEL source and rebuild it and release things like CentOS. Presumably you could do the same kind of thing with the Amzi source, so long as you respect their trademarks and what-not.
I mean, I get the point they're trying to make (I think) but I wish people would be a little more precise when talking about this topic.
https://www.schneier.com/blog/archives/2014/05/friday_squid_...
So, "free as in Stallman" software might be a dichotomy with proprietary but not "free as in free enough for many people." That exists and can flourish further with right mix of organizations, charters, licenses and so on. Just little work in it.
None of the four essential freedoms mention price. I work for a free software company which sells that software. I don't know what you're referring to. I clearly said that "free and commercial software are a FALSE dichotomy" -- meaning that you can have commercial free software.
> So, "free as in Stallman" software might be a dichotomy with proprietary but not "free as in free enough for many people."
Again "free as in Stallman" doesn't have anything to do with whether you pay for the software (in fact, he used to sell copies of GNU Emacs for $100). Proprietary software is software that takes away your freedom to use, modify and distribute the software. You can pay for free software and you can pay for proprietary software. But you can't get proprietary software that respects your freedom. That is a dichotomy.
Free doesn't refer to price it refers to freedom. Please stop spreading misinformation.
Oh, I apologize. I clearly misread that exact statement. I bet it's because free, commercial, and false in same sentence almost always are arguing against what you said. That the two can't be combined. Whereas, we're arguing in different ways that they can. I must have skimmed it with my brain jumping right past the actual words to its intuitive guess of what they meant. At least I see how I failed. :)
"Proprietary software is software that takes away your freedom to use, modify and distribute the software. You can pay for free software and you can pay for proprietary software"
What firms are bringing in billions licensing or selling free software? I need a list of successful companies longer than Red Hat that can compete in both investment and lawsuits with big, proprietary firms. You can sell truly free software but almost nobody will buy it w/ you being super-niche in revenue. Whereas, useful and proprietary software can bring in significant money from customers esp in enterprise or government scenes. The proprietary ones just tend to scheme on customers, disappear, and other stuff. The free ones often aren't developed much, maintained, and so on.
My concept is to give you all the freedoms except for free distribution for a given project. You can use, modify, whatever the software as long as you pay the non-profit that develops, maintains, and supports it. You can also re-distribute that to other paying customers of the project. If non-profit stop supporting or distributing it, it goes BSD or Apache immediately per terms of the license or charter.
What are you missing other than widespread, free distribution in this model? As in, the availability of freeloaders that rarely contribute crap back. Do note that the project can give free copies in exchange for testing/feedback to get many eyeballs effect. Can also give discounts or free copies to academics to get their improvements.
What's left? Seriously, as I'm trying to see how close proprietary, shared source can get to FOSS without loosing the "sustainable, cash flow" part.
I work for SUSE, which is a free software company. Red Hat is another, as you mentioned. I found a list on Wikipedia[1] which has quite a few entries (though quite a few of those companies either no longer exist or were bought out by companies that don't exclusively work on free software).
> You can sell truly free software but almost nobody will buy it w/ you being super-niche in revenue.
That depends on your business model. The SUSE (and Red Hat) business model is to sell you a complete operating system which you are guaranteed to have support for. This is paid for by license costs for the base system and "modules" which are other pieces of software. If a user decides to install software which they didn't pay for, we don't support such a configuration if it breaks. Support in this case is not just support in setting up the system, it's also security updates and bug fixes (which are sometimes written by us and contributed back to the community). This sort of business model allows you to sell completely free software, because you're not selling the actual software you're selling licenses and support.
> My concept is to give you all the freedoms except for free distribution for a given project.
That would then be considered proprietary software in the strict sense of the word. It's better than nothing, but you have no practical freedom in that case because you cannot share your improvements to create a community -- one of the goals of the free software movement. The main thing to know is that free software is meant to mean that you cannot become entirely dependent on a company to support you. If you don't have the freedom to distribute modified and unmodified copies then you're (practically) at the mercy of the company that gave you the software.
> Seriously, as I'm trying to see how close proprietary, shared source can get to FOSS without loosing the "sustainable, cash flow" part.
Personally, I would never buy such software. I understand why it seems to be valuable to you to remove the free distribution freedoms of your users, but I don't agree with the logic. The problem is that you're still trying to "just sell the damn code", which doesn't guarantee you revenue with free software licenses (you can still sell it, but it's possible for a user to share the code with others without you knowing about it). Now, it's not very likely that many users would actually share the code (unfortunately), but it is possible. So, now you have to ask the question "what should I be selling". If you sell support (clients pay for you to develop new features for them, providing security fixes, bug fixes, etc) then you can make money selling completely free software. If you're scared of someone making money from your code, make it GPL and then you can take their changes back into your software.
Free software and proprietary software have only one difference which is how their distributed. Proprietary software is distributed in binary form only. Free software is usually distributed in binary and source form, but you can also distribute it in binary form with a link to where the source code is (and you can make it only be available to your customers -- that's still free software).
[1]: https://en.wikipedia.org/wiki/Category:Free_software_compani...
"I found a list on Wikipedia[1] which has quite a few entries (though quite a few of those companies either no longer exist or were bought out by companies that don't exclusively work on free software)."
Appreciate the list. A bunch of those, including yours, are proprietary software companies that also GPL stuff. Or hybrids were a huge chunk of the revenue is support or GPL-component consulting instead of licensing proprietary addons. Still worth considering but not a "free software" company if issuing paid licenses.
" it's also security updates and bug fixes (which are sometimes written by us and contributed back to the community). This sort of business model allows you to sell completely free software, because you're not selling the actual software you're selling licenses and support."
That's true. It's also the model that rarely makes any real money. Red Hat and SUSE are exceptions to the rule, esp Red Hat. That they both license proprietary software on top of that model clouds the issue further. We'd have to have companies with only FOSS offerings plus support and services matching those or proprietary revenues to make the argument. I'll look at your link to see if I find those plus if there's financial data on app/feature vs support licensing to see what split of the revenue/profit they make.
"but you have no practical freedom in that case because you cannot share your improvements to create a community -- one of the goals of the free software movement."
You can do that exactly how I described. You underestimate how powerful of communities that can develop around proprietary software. Microsoft and IBM are extreme examples that had more to do with monopolistic practices. So, maybe Borland's Delphi or even early Solaris are better examples. The community is just limited to those that are willing to pay. That's FOSS's advantage.
" If you don't have the freedom to distribute modified and unmodified copies then you're (practically) at the mercy of the company that gave you the software."
This is a huge problem. It's why I'm working to eliminate it but FOSS has clear advantage here. We saw this with Oracle dropping OpenSolaris followed by others picking it up.
"Proprietary software is distributed in binary form only."
That's not true at all. MCP, the villain in Tron & brilliant OS for Burroughs, was distributed in source form to clients in the 60's with their modifications/fixes often going into new releases. Many proprietary software since were similarly shared source. The high-assurance security kernels even mandated vendors supplying source so you could meet A1-class requirement of inspecting and building it yourself. Even Windows source is available to some partners. There's also dual-licensed model where free software is a byproduct of licensing proprietary, shared-source software. So, proprietary and source available are not contradictory in any way. It's just distribution part as you said where distinctions must be made.
"If you sell support (clients pay for you to develop new features for them, providing security fixes, bug fixes, etc) then you can make money selling completely free software."
This is true. The question is "Do I make the same money at same market share as if I license it for low pricing?" I can imagine a database that cost even $5,000 per organization that's competitive with popular RDBMS on common usage with better reliability or security will probably break even on its development cost after first few dozen or so customers. That's plenty for development with enough left for support and administrative stuff. A $1,000/yr support agreement will take substantially more customers to cover all costs, especially development. Only exception I could see is if the developers were the admins and suppo...
Good catch, thanks. I did read that bit, and promptly overlooked it.
http://www.swi-prolog.org/
I'd like to revisit prolog, I think it is an underused language in industry.
If SICStus went open source or free for academic use, I would probably use that in my research/courses over SWI Prolog. Mostly because of familiarity, performance, and compatibility reasons.
http://www.let.rug.nl/vannoord/alp/Alpino/
Prolog has some nice advantages for such knowledge-based language processing:
- With relatively little work, terms can be used to represent linguistic feature structures. You can build a small type system using meta programming and define operators on feature structures.
- Unification can be used build larger structures, check syntactic constraints, etc.
- Backtracking makes handling ambiguity in parsers/generators much easier
There are two quite elaborate chapters in my PhD thesis about the system mentioned above and the generator:
http://danieldk.eu/Research/Publications/phd-thesis.pdf
Though for the time being, I am working on dependency parsing using deep neural nets (like everyone else ;)).
Frankly, SWI gets all the action. There are times where it isn't the most efficient Prolog, but the toolset you're going to get from AMZI is much more limited, and that in the end is going to be a bigger deal. Does AMZI have ODBC, CLP, CHR, and a web framework? Probably not. SWI has the biggest community, the largest built-in library, the most 3rd-party packages, and is the easiest to install. Everything else is basically tied for second place. Except Visual Prolog, which comes last. :)
It's kind of a shame, because my earliest exposure to Prolog was through AMZI; they had a nice Windows IDE you could try for free (30 minutes at a whack). I went through their "Nani Quest" tutorial and that gave me positive memories of Prolog that I revisited later.
Mercury is an interesting language, but not having a REPL is a huge problem for me. The language mixes in some good ideas from Haskell and Clean. The tutorial comes off as sort of condescending towards Prolog users and fans though. Having to furnish modes and effect types is a bit of a burden.
Allegro is a pretty compelling product, but when I want to do Prolog, I want to do Prolog. core.logic in Clojure seems like it would be more interesting to me, because Clojure is enough better than Common Lisp. I believe core.logic is based on miniKanren, which is also interesting.
The Prolog implementations I sometimes wish I knew more about are B-Prolog, YAP and XSB. But I don't really have the kinds of performance problems that would benefit from tabling or a more sophisticated compiler.
Yeah, that's a great tutorial to the language, I learned a buttload from that when I was doing my degree. Not to look down on Learn Prolog Now! and others, but this is how to teach Prolog to university students.
Note: Your alias is hilarious. Nice one.
Note that Swi Prolog introduced some very big changes in version 7.0, that break interfaces left and right. It's to (Swi) Prolog what 3.4 is to Python. So if you were trying to follow Nani Quest with Swi 7.x and it gave you trouble, I'd try installing an earlier version.
I was on LPA Prolog when I did Nani Quest and I don't remember having issues, but it's been a while so I'm not sure.
Also, having more open-source Prolog engines is a very good thing, both for the language and for the project itself. For the project, it's good because it makes it easier for a community to grow around it. Swi has benefited enormously from its popularity (Jan Wielemaker has commented on this occasionally). For the language, it's good because the more healthy Prolog communities we have, the more we can hope to get new people interested in the language.
Comparing to other Prologs (and Prologs-ish'es) the problem with having closed-source and only for-pay Prolog engines is mainly one of portability, which in the Prolog world is a bit shit (and that's a vast understatement).
Frex, I wrote my degree dissertation using Win-LPA Prolog in 2010-11. LPA is commercial and I don't have a licence anymore (I had a student one) so now I can't run my dissertation. I tried (and tried (and tried)) to make it work on Swi but failed (and failed (and failed))[1].
The problem is there are subtle differences between implementations that bite you in ways you never thought possible, and it's just aaaargh hard to get the same program running in the same way on two different Prologs.
Apparently the exception to this portability hell is Yap and Swi, who have worked together to maintain some compatibility with each other. I don't have experience of this myself (after getting burned I've stuck to Swi) but if Amzi open-sourcing their stuff also means they'll be more open to this sort of working with others, then that's really, really amazing news.
____________________________
[1] It's here: https://github.com/stassa/Gleemin But it will hurt you.
Also, graduate dissertation, 5 years ago: embarrassing.
Or even between versions of the same implementation. E.g., I know of one project that sticks with SICStus 3, because in SICStus 4 findall/3 removes blocked goals from copied variables. This system relies quite heavily on blocked goals and working around this change turned out to be too expensive.
(If I recall correctly ;).)
Another example is SWI Prolog diverging from the ISO standard in version 7 (e.g. double quoted strings are now a type on their own, rather than a list of character codes). Luckily, there is a --traditional flag for older code.
In both cases, there are good reasons for the changes, but it makes portability hard.
Edit: wanted to add that this is not intended to be a critique of these particular (great) implementations of Prolog.
When you say "blocked goals" do you mean it like:
:-block(a_block). % ... stuff ... :-end_block(a_block).
That sort of thing? Anyway yeah, sounds typical :/
With Swi I hurt a little recently when an update screwed up some of my stuff but then that was my fault for doing hacky tricks and trying to use modules as they're not meant to be.
>> In both cases, there are good reasons for the changes, but it makes portability hard.
Oh indeed. I started using 7.x the moment it was out pretty much, knowing that it means I'm tied to Swi for good and bad, but there's much more good than bad and so far I haven't regretted it.
These:
https://sicstus.sics.se/sicstus/docs/latest4/html/sicstus.ht...
https://sicstus.sics.se/sicstus/docs/4.0.7/html/sicstus/Bloc...
Btw, have you tried Mercury? My last foray into logic programming made it seem like it was killing Prologs in quite a few fronts. Prover work moved onto HOL, Coq, etc. Some people still use it for type-checking and queries. Yet, seems hard for me... not a logic programmer btw... to justify Prolog given capabilities and results from other tools. Any ideas on why it's worth keeping around or would you use an alternative today?
Regarding dissertation, I lost most of life's work when three HD's (main + 2 backups) all died within short time of each other. Encrypted with custom crypto that also fried haha. You can't run something you spent years on and is referenced in your degree. I feel your pain or irritation on that. ;)
Note: Oh shit, it's a Magic the Gathering interpreter! I used to play that every day with friends like a decade ago to pass time at school/work. I even wrote some GUI's and game engines for it but really alpha stuff. Probably would've wrote an AI for it if I didn't discover Starcraft. Might try to read some of it this week if I get spare time even though idk Prolog anymore. Maybe I'll learn something anyway or get some nostalgia at the least. :)
Ouch. Oh dear, that sounds horrible.
>> Btw, have you tried Mercury?
I've picked it up a few times but I keep coming back to vanilla Prolog. It's great but I'm a bit scared by the tiny amount of adoption. I know it's kind of ironic: low adoption feeds back on to itself.
>> Any ideas on why it's worth keeping around or would you use an alternative today?
I do a lot of nlp for university, and although I use Python for all the machine learning stuff, the text processing capabilities of Prolog are beyond any comparison with anything else.
For instance, everyone uses regular expressions for tiny bits of parsing and string manipulation. Prolog uses a sort of pattern matching, unification, that is like regular expressions except without any special syntax and Turing-complete.
For language processing, most interpreters have something called Definite Clause Grammars. In short, it's syntactic sugar that lets you declare a grammar, except the grammar is also a parser, that recognises and generate strings (because Prolog). They make developing a parser a piece of cake.
Also, Prolog runtimes are essentially fast, in-memory relational databases, with added reasoning (and no SQL). I can think of many applications that could use that sort of thing. Plus, the language itself is the database, so there's no object-relational impedance mismatch and whatnot.
>> Might try to read some of it this week if I get spare time even though idk Prolog anymore
Thanks, I appreciate that. But please keep in mind: 5 years ago and embarrassing :)
My house might burn down haha. It would be interesting to know a complex, useful, performant application coded entirely in PROLOG that wasn't a Visual Prolog IDE or something. ;) A list of those with what advantages and headaches Prolog gave the developers would be a nice start.
Binaries: https://github.com/AmziLS/distribution
Earlier: https://news.ycombinator.com/item?id=11509451
My classmate used it for his master-degree paper, and I just want to know its status when AI is starting to really catch up these days.
Now I should probably recommend you to play a bit with both approaches and do the same myself.
So, if prolog has future, it probably is outside of AI research.
I would say, that verifying is one of the places where logic programming never went away. I.e if you ever wanted to write type checker of protocol verification, you might write an embedded prolog first.
Prolog and erlang are not the same, or even particularly similar. Some features (such as unification, which is what erlang uses, not assignment, with the = symbol) are present, and inspired by, prolog. But the underlying computational models aren't the same. Erlang is functional/concurrent/procedural (procedural meaning you write an explicit sequence of steps). Prolog is functional/declarative. You don't (normally) write explicit steps. Rather, you describe the solution you want to find, describe the configuration of a system (essentially propositions and axioms), and let prolog search for your solution. You can do a lot more than that with the operators (declaring order of execution, terminating early, etc.), but the underlying computational model is this search. You would not use them for the same domain.
You can because they're both turing complete and thus capable of expressing the same computations. You won't because erlang excels in its concurrency model (and performance with many concurrent processes), and prolog excels in its declarative/search model. I believe there are some other languages (Oz/Mozart?) that might be suitable if you want a hybrid of erlang's concurrency and prolog's declarative model.