Well, everything is defined by the sequence of program counter states!
Until one starts thinking about parallel systems, where the program counters exhibit not merely different sequences but might be subject to vastly different clock rates.
And without intending to imply any cause-or-effect relationship, that's particularly the case in an OO system or one where different subproblems can be "farmed out" (e.g. multithreaded searching in the logic programming domain).
That's a separate can of worms
Most languages have multithreading (let alone multicore) as a bolt-on afterthought. I like xCORE processors plus xC (modern Occam
) because they
start by presuming multicore systems.
Prolog is very powerful in a limited domain. Two fundamental problems are side effects (e.g. I/O) and the closed world assumption. The former also arises with pure functional languages.
I agree, but one problem is that there are always people who are prepared to push a paradigm or a language implementation far beyond what is reasonable. I remember once settling down to read a paper discussing the use of APL for astronomical calculations expecting that the author had hit upon some way of describing planetary orbits in matrix form, only to find that it was a transcpt of Meeus's standard numerical methods which could have been better done in BASIC... or even COBOL.
Oh, yes indeed.
Too many people only have hammers in their toolkit
There is certainly grey areas between the various paradigms, and the pure academics can have fun debating them. And that's without considering that they are , like C++ Templates, Turing complete
...and the water is muddied enormously when a fairly pure initial implementation is polluted by extensions which depart far from the original paradigm since the implementor considers it easier to tack in a bit of OO or procedural parsing than to be able to link with other languages. A classic example of that was Turbo Prolog.
MarkMLl
Oh, yes indeed.
Too many languages have become cancerous growths
I never used Turbo Prolog but I remember seeing it announced and I'd written a few Prolog programs before that. I don't know anything about cancerous growth, but what I do remember from the announcement was that it was missing at least one absolutely fundamental standard Prolog feature! Was it assert & retract?
I never used Turbo Prolog but I remember seeing it announced and I'd written a few Prolog programs before that. I don't know anything about cancerous growth, but what I do remember from the announcement was that it was missing at least one absolutely fundamental standard Prolog feature! Was it assert & retract?
I'm no Prolog guru, but from what I know about the internals that would sound like the obvious bit for a naive implementation to sweep under the carpet.
I have, however, sold and supported a fair number of development tools, and have always been disappointed by how many companies attempted to have cross-language linkability and how quickly they folded afterwards. MS was one of the first to pull it off with .NET, which suffered from starting big leaving people who wanted to get it working truly cross-platform an almost impossible job.
I'd suggest that the fact that companies were allowed to get away with having multiple incompatible languages- or sometimes multiple incompatible implementations of the same language- was a symptom of the compartmentalisation of users' application domains. And I think that's still a major problem. The situation wasn't helped by the fact that separate compilation with a final linkage stage wasn't universally available until (depending on the platform... lots of handwaving here) the late 70s or early 80s: having to structure your modularisation around file inclusion is obviously extremely limiting.
MarkMLl
I have, however, sold and supported a fair number of development tools, and have always been disappointed by how many companies attempted to have cross-language linkability and how quickly they folded afterwards. MS was one of the first to pull it off with .NET, which suffered from starting big leaving people who wanted to get it working truly cross-platform an almost impossible job.
DEC did a pretty usable job on VAX/VMS by (among other things) making the compilers for every language (BASIC, Pascal, FORTRAN, COBOL) able to create and accept function arguments using all the calling conventions native to any of the other languages. Providing high level machine code procedure call instructions probably helped that too, even if it meant the actual performance was not as good as the older PDP 11/70 -- or for that matter using the VAX instruction set in a more RISCy way.
DEC did a pretty usable job on VAX/VMS by (among other things) making the compilers for every language (BASIC, Pascal, FORTRAN, COBOL) able to create and accept function arguments using all the calling conventions native to any of the other languages. Providing high level machine code procedure call instructions probably helped that too, even if it meant the actual performance was not as good as the older PDP 11/70 -- or for that matter using the VAX instruction set in a more RISCy way.
From my limited exposure I think Multics did a fairly good job as well. But it quite simply didn't appear to be a high priority to most people, and those companies that tried it generally went TITSUP **
MarkMLl
** El Reg would come up with something like Totally Incapable To Support Unexpected Paradigms to explain that.
Prolog is pretty dead nowadays. Why?
** El Reg would come up with something like Totally Incapable To Support Unexpected Paradigms to explain that.
Since you mention that filthy rag ... ahhh, the old days of Magee and Lettice ... back when I was a 3rd year university student in Hamilton NZ in 1983 I got friendly with a 1st year student called Simon in one of the programming classes I was tutoring. Simon, myself, and a masters' student (Lawrence D'Oliviero) ended up having lunch together most days. Simon didn't get along with studies and dropped out and later got a job as a trainee operator on the university VAXes. (As I recall, he worked in retail at Dick Smith Electronics in between) He also started writing a satirical column for the student newspaper about the frustrations of the operator job. The rest is history.
Prolog is pretty dead nowadays. Why?
One-trick pony.
As is multiple layers of non-linear matrix multiplication.
Prolog is pretty dead nowadays. Why?
One-trick pony.
In slightly more detail: people realised that a program needed to be able to do more than one specialist job, so even if it was desirable for it to be able to handle logical inference internally it also needed a decent user interface and so on. And despite the way that multiple Prolog implementations were enhanced with procedural extensions, eventually they concluded that it was easier to format the rules to suit a general-purpose language such as Python (which I consider utterly despicable, but that's another subthread) than it was to design a language from scratch which as well as being usefully procedural could also express the inference rules in a way that would be familiar to specialists in that area.
I consider that to be unfortunate, but languages with arbitrarily-extensible notation are notoriously difficult to get right.
The same applies to e.g. matrix handling: it can be expressed elegantly in APL and decent implementations can be remarkably time-efficient (often at the cost of memory space). It just /isn't/ any more.
One thing that surprises me is the scant amount of attention that Smalltalk gets these days, since it's shipped as standard on hundreds of thousands of computers every year.
MarkMLl
I'd like to learn and use Ruby. Unfortunately, I haven't yet found a book with Ruby examples. Maybe it depends on my domain of interests.
** El Reg would come up with something like Totally Incapable To Support Unexpected Paradigms to explain that.
Since you mention that filthy rag ... ahhh, the old days of Magee and Lettice ... back when I was a 3rd year university student in Hamilton NZ in 1983 I got friendly with a 1st year student called Simon in one of the programming classes I was tutoring. Simon, myself, and a masters' student (Lawrence D'Oliviero) ended up having lunch together most days. Simon didn't get along with studies and dropped out and later got a job as a trainee operator on the university VAXes. (As I recall, he worked in retail at Dick Smith Electronics in between) He also started writing a satirical column for the student newspaper about the frustrations of the operator job. The rest is history.
Back in the 90s I used to work with John Lettice at Dennis and I've drunk in most of London's pubs with Mike Magee. Everybody who knows Mike has at least two drinking stories about him: the one where Mike nearly/actually started a full scale pub fight and the one where they woke up in a cell/ditch/basement of a five star hotel/wherever. John himself was not un-averse to the traditional journalist's liquid lunch/dinner/supper/breakfast but was much quieter about it. I'd often go to the pub just around the corner from Dennis Towers to find him nursing a pile of copy to edit and a pint in the corner on his own.
Mike Magee:
You can almost hear him saying to the photographer "
What did ye say,
pal?"
I can't find any pictures of John, the rumour that he doesn't show up on film or in mirrors is, I'm sure, just that.
Prolog is pretty dead nowadays. Why?
Have you taken a look? IMHO, with a certain amount of professional experience, merely looking at the language is enough to answer this question. It's interesting, but definitely not made for doing anything really useful except a few toy examples, and possibly the kind of "expert systems" that were done in the 80's.
I'd like to learn and use Ruby. Unfortunately, I haven't yet found a book with Ruby examples. Maybe it depends on my domain of interests.
What would you like to implement with it?
I'd like to learn and use Ruby. Unfortunately, I haven't yet found a book with Ruby examples. Maybe it depends on my domain of interests.
What would you like to implement with it?
At the moment, a web-application (Ruby on Rail)
I'd have thought there would be hundreds of Rails examples around. It's still used a lot. It's used in the back end by the company I'm working for now.
The shortage might be non-Rails examples with Ruby. I don't know ... I'm the kind that tens to just grab the reference manual and look at some existing code (that I have to modify, often) and go for it. I like Ruby a lot more than Python and shoul be using it for my quick-and-dirty stuff, but my fingers still effortlessly flow out Perl for that.
Prolog is pretty dead nowadays. Why?
Have you taken a look?
Yes, and the only professional use I am aware(1) of is Stood-2010 (written in C++ and Prolog)
-> about 12 years old software.
(1) because I use it at work.
What is Stood-2010, and what part was written in Prolog?
What is Stood-2010, and what part was written in Prolog?
The one related to the project design and constraints analysis , but I am not expert, and I cannot publish sources. Basically, the Prolog modules are
- the software requirements analysis module
- the software design core module, the GUI is written in C++, there is also a module that reads external files in order to prepare a system requirements table { hardware, operating System, ... } and a realization constraints table { team organization, technical choices, quality standards, ... } .... there is also a C++ module that processes UML 2.0
- the software unit testing module, it generates C code + ICE scripts
- the software functional testing module, it generates C code + ICE scripts
- the documentation framework, it calls a C++ module that calls a kind of Office module that calls Microsoft World and generates a document ... kind of light solution for trace-ability requirements
80% is written in Prolog. All the processing core.
C++ is used as wrapper, to read/write text files and for the GUI.
edit:
there is also a "C-code reverse engineering" module written in Prolog, but it doesn't compile.
I like Ruby a lot more than Python and shoul be using it for my quick-and-dirty stuff, but my fingers still effortlessly flow out Perl for that.
The Perl community got the language a terminally-bad reputation by being excessively clever: uncommented one-liners for the sake of it.
Python is an abomination.
MarkMLl
... shoul be using it for my quick-and-dirty stuff, but my fingers still effortlessly flow out Perl for that.
You do know you can get medication for that nowadays?
The Perl community got the language a terminally-bad reputation by being excessively clever: uncommented one-liners for the sake of it.
It's possible to go overboard, of course, but here's one I use frequently when posting code to online forums that use markdown rather than bbcode (e.g. Redit):
perl -pe '$_ = " $_"' foo.c
Ok, you could use sed or awk just as well for that one, but I prefer to know perl well than all of them poorly.
What is Stood-2010, and what part was written in Prolog?
The one related to the project design and constraints analysis , but I am not expert, and I cannot publish sources. Basically, the Prolog modules are
(snip)
80% is written in Prolog. All the processing core.
OK. I'd guess it's essentially a rule-based system. So it pretty much falls into the category I was talking about, such as good old expert systems.
Sure Prolog is not bad for that, although I think there are better solutions these days for rule-based systems and logic proofing.
edit:
there is also a "C-code reverse engineering" module written in Prolog, but it doesn't compile.
there is also a "C-code reverse engineering" module written in Prolog, but it doesn't compile.
Yes, essentially it's a rule-based system, but ironically, that is the most interesting part for me
I mean, I don't know anything about Prolog, and I don't need to recompile Stood, I use Stood at work to create projects' skeleton with a plan for their trace-ability; Stood for me is a program that runs on a workstation; on my little laptop I only wanted to use that reverse-engineering-module coupled with IDA to analyze a couple of ROMs, but no dice, it doesn't even compile.
The Chapter 2 tries to make the point:
PL/I -> E/PL (created to be simpler than PL/I)
BCPL created to simpler than PL/I and its dialects
BCPL ->B (created to run on a machine with limited RAM)
B -> C (created to be portable and with types)
So, I should also be able to understand E/PL, BCPL and B examples
(I hope
)
Although BCPL is more often described as being a descendant of CPL, hence of ALGOL, making it a sibling of PL/I rather than a descendant.
Considered as a system implementation language, BCPL was also a contemporary of Wirth's PL/360 at Stanford.
MarkMLl