Interesting video. I would like to see video about Prologs robustness or security. I think Prolog is more resilient to cyber attacks maybe?! It's code maybe has less errors, and so less attack surface?
Sharing immutable data is about as secure as you can get. Also it can be made to run in parallel very easily, which will become important when multicore technology goes mad, which it will.. :)
I think security vulnerabilities in most cases come from an actual implementation of a system and not from the theory of how it works. You can have extremely secure keys storage, which is completely useless if an attacker can have direct access to memory where it's placed to unlock some secret. If you want to crack something you have to think out-of-the-box. Nevertheless, I think any system that can help programmer to write correct code, is automatically more robust. It would be interesting to learn about common practices to write robust Prolog code or maybe even about provable correctness.
This is very interesting. I was wondering if the null terminated string causes performance issues. If the partial strings know their own length, wouldn't you be able to have better performance under the hood? I guess you would need one more value per reference, so it would depend on the number of references you would expect to have.
One nice advantage of this string representation is that identical suffices can be shared internally, so that for example "abcd" and "bcd" can share the suffix "bcd" in memory. So, a string may not only consist of contiguous raw bytes, but also point to other structures. There is a dedicated video that explains the string representation in more detail, please check it out! The major attraction is the compactness of the representation.
@@ThePowerOfProlog I'll give it another look ^^ I've been learning some Prolog in my free time when I need a break from learning Rust, and I'm really interested in getting to know it better. Do you think you could make a video on how to avoid boilerplate in prolog? I kind of find: human(tom). human(bill). human(mia). human(farris). to be a little repetitive and it also makes code harder to read. I get the feeling that a term might be written in any old place instead of being well organized. in rust I have a similar issue with constants, but I made a macro to solve the issue so pub const X:i32=4; pub const Y:i32=5; pub const Z:i32=6; turns into PUB_CONST!( X i32 = 4 Y i32 = 5 Z i32 = 5 ) I figure there must be some way to do this without writing "human" every time. something similar like % this does not work I believe. human(X):- X = ( tom; bill; mia; faris ).
@@remyclarke4020 You can use member/2: human(X) :- member(X, [tom,bill,mia,faris]). Once you have this, you can generate the intended facts with: ?- human(X), portray_clause(human(X)), false. human(tom). human(bill). human(mia). human(faris). false. This gives you argument indexing for very efficient lookup if the argument is instantiated, essentially independent of the number of facts. You can define a term expansion rule to generate these facts at compilation time from the shorter description: user:term_expansion(gen_facts, Facts) :- findall(h(X), human(X), Facts). gen_facts. Then compare for example ?- h(tom). with ?- human(tom). The former benefits from argument indexing, whereas the second uses member/2 and is not deterministic in addition to the linear scan over all elements in the list.
You can rent a remote server with more than 100GB RAM for ca. 120 EUR per month, and one with 512GB RAM for slightly more. If that does not suffice for processing your data in memory, I recommend you ask your Prolog vendor for more efficient internal data representations. For example, lists of characters - which are ideally suited for processing large amounts of text with Prolog - can be very compactly represented in memory as a sequence of raw bytes, or by transparently mapping file contents to memory via the operating system, using the system call mmap.
Interesting video. I would like to see video about Prologs robustness or security. I think Prolog is more resilient to cyber attacks maybe?! It's code maybe has less errors, and so less attack surface?
Sharing immutable data is about as secure as you can get. Also it can be made to run in parallel very easily, which will become important when multicore technology goes mad, which it will.. :)
I think security vulnerabilities in most cases come from an actual implementation of a system and not from the theory of how it works. You can have extremely secure keys storage, which is completely useless if an attacker can have direct access to memory where it's placed to unlock some secret. If you want to crack something you have to think out-of-the-box. Nevertheless, I think any system that can help programmer to write correct code, is automatically more robust. It would be interesting to learn about common practices to write robust Prolog code or maybe even about provable correctness.
This is very interesting. I was wondering if the null terminated string causes performance issues. If the partial strings know their own length, wouldn't you be able to have better performance under the hood? I guess you would need one more value per reference, so it would depend on the number of references you would expect to have.
One nice advantage of this string representation is that identical suffices can be shared internally, so that for example "abcd" and "bcd" can share the suffix "bcd" in memory. So, a string may not only consist of contiguous raw bytes, but also point to other structures. There is a dedicated video that explains the string representation in more detail, please check it out! The major attraction is the compactness of the representation.
@@ThePowerOfProlog I'll give it another look ^^
I've been learning some Prolog in my free time when I need a break from learning Rust, and I'm really interested in getting to know it better.
Do you think you could make a video on how to avoid boilerplate in prolog?
I kind of find:
human(tom).
human(bill).
human(mia).
human(farris).
to be a little repetitive and it also makes code harder to read. I get the feeling that a term might be written in any old place instead of being well organized.
in rust I have a similar issue with constants, but I made a macro to solve the issue so
pub const X:i32=4;
pub const Y:i32=5;
pub const Z:i32=6;
turns into
PUB_CONST!(
X i32 = 4
Y i32 = 5
Z i32 = 5
)
I figure there must be some way to do this without writing "human" every time.
something similar like
% this does not work I believe.
human(X):- X = (
tom;
bill;
mia;
faris
).
@@remyclarke4020 You can use member/2:
human(X) :- member(X, [tom,bill,mia,faris]).
Once you have this, you can generate the intended facts with:
?- human(X), portray_clause(human(X)), false.
human(tom).
human(bill).
human(mia).
human(faris).
false.
This gives you argument indexing for very efficient lookup if the argument is instantiated, essentially independent of the number of facts. You can define a term expansion rule to generate these facts at compilation time from the shorter description:
user:term_expansion(gen_facts, Facts) :- findall(h(X), human(X), Facts).
gen_facts.
Then compare for example ?- h(tom). with ?- human(tom). The former benefits from argument indexing, whereas the second uses member/2 and is not deterministic in addition to the linear scan over all elements in the list.
A consideration I keep returning to in my mind is "what if my data does not fit in memory" e.g. if I have 100Gb of data
You can rent a remote server with more than 100GB RAM for ca. 120 EUR per month, and one with 512GB RAM for slightly more. If that does not suffice for processing your data in memory, I recommend you ask your Prolog vendor for more efficient internal data representations. For example, lists of characters - which are ideally suited for processing large amounts of text with Prolog - can be very compactly represented in memory as a sequence of raw bytes, or by transparently mapping file contents to memory via the operating system, using the system call mmap.