HN user
I’ve actually implemented a TUI in Prolog (because there wasn’t anything in the space and I wanted to make sure it respected the relational/logical nature of Prolog). I’m happy with performance and developer ergonomics. But before I publish it, I want to firm up some opinions on how TUIs should behave for end users. Do you have any suggestions other than “use Vim/Emacs and think about it”?
So, the S and P in LSP stands for Server and Protocol. The Protocol is to exchange JSON-RPC messages with a server. So to add a new language to Zed, we should just be able to direct Zed to the server to talk to right? No. You have to write an extension in Rust. https://zed.dev/docs/extensions/languages#language-servers.
Or am I missing something?
Thank you! I've recently become a bit obsessed with the work of Blaise Agüera y Arcas and his BFF experiments (self-replicating (Brainfuck) programs emerging spontaneously from random noise). This got me thinking about running a similar experiment with Cellular Automata (efficiently on GPUs). So I'll definitely be playing with this.
Intense. I thought “lose it all” meant wiping your phone.
I tried exactly this idea a few years ago (inspired by how Bear app did Markdown at the time). But I never solved all the issues to get it working 100%.Eventually I just gave up and moved on. So bravo and thank you for making it work!!
When is a good time (in the timeline of mankind) to stop being adversarial with AI?
Apparently I'm a super smeller (always the first to detect gas leaks, food that's off, know the brand of shampoo a person uses if I'm 200ft down wind, know if you use scented dish soap to clean the bowl you used to make cookies in when I eat the cookie). And I just think the idea that adding smells to the world is absolutely insane. Can I beam my favourite colours directly into your eyes with a laser from across the room? What if I know you like that colour too?
I’m realized years ago I have full blown aphantasia. But I don’t suffer from autobiographical memory deficiencies. For me it’s akin to what happens when you close your eyes for a moment then open them again. I’m not shocked by everything in the room “appearing” suddenly. I knew it was all there, but not because I visualized it while my eyes were closed. So when I remember past events, it’s with that same sensation of being there but just having closed my eyes to it. I do dream with full imagery.
After spending a lot if time in Prolog, I want a nice way to implement and compose nondeterministic functions and also have a compile time type check. I’m eyeing all of these languages as a result. I’ll watch Ante as well. (Don’t forget developer tools like an LSP, tree-sitter or other editor plugins).
A Prolog TUI library that sticks to relational/logical programming, is conceptually simple, complete, and performant. Only requires some core ansi features that exist or are easily implemented in most Prologs. Currently have stuff like nested scrollable areas, toggles, frames, buttons, layouts working.
Also, a visual programming language implemented as a PICO-8 script, where the "programming" is done fully in the sprite editor.
Ok I’m genuinely convinced I’d be happier using Fennel than using Lua in instances where I need to use Lua. I’m not currently using Lua for anything. Maybe if I write a Pico-8 app…
As a proficient Elm developer with industry experience, I’m wondering what are the biggest challenges in hiring devs? Is it the paradigm, learning the ecosystem, lack of interest? Are you currently hiring?
Readability is a property of the reader, not the language.
Similarly, the inability of a person to write machine code directly is a property of the person, not the hardware. Yet some of these people admit their limitations and use K.
if they haven't surpassed SWI in some performance metrics yet I'd be surprised
I was/am also anticipating performance gains from Scryer. Which is why I made a point to request up to date Scryer benchmarks in the SWI forums. Still, for free/open Prolog, SWI-Prolog is hard to beat: https://swi-prolog.discourse.group/t/porting-the-swi-prolog-...
Implementing and using a miniKanren was fun and enlightening. And it helped me appreciate how incredibly optimized and fast SWI-Prolog is for relational/logical programming. If someone knows of a miniKanren/language combination that outperforms SWI-Prolog and has good developer ergonomics for relational/logical programming, I’d love to hear about it.
Not at all creative or interesting. Literal and uninspired.
I’ll add my vote for Roux in terms of pure fun. And there is more freedom to play between fastest solves and fewer moves with more planning.
For example: the logical core of Prolog along with it's resolution model (for the logical part) are non deterministic (something can have none, one, many solutions) but only one solution is explored at a time. So it's a "meta logical" thing to express something like "the set of solutions for ...". Given that the core of Prolog is Turing complete, you can still get Prolog to compute anything, you might just not have a nice way of declaring it in pure Prolog.
Prolog has an interesting history of people discovering ways to express things that are simple, powerful and elegant. And yet despite the simplicity, these ways of expressing things were not immediately evident. DCGs are a prime example.
Hah! Hello fellow PCEmacs >> vim user :D
That made my day! Hello!
How do you debug DCGs? I get "false." instead of "syntax error at line 23", which is unacceptable for bigger inputs.
I also sympathize. "false" as the default failure mode is a challenge with Prolog. Most Prologs I've used have good debugging/stepping features (see spy and trace predicates), logical debugging of pure monotonic Prolog can often help (explained by Markus Triska), you can easily write (use existing) meta predicates that assert a called predicate must not fail otherwise throw an exception. For example: here the ./ is supposed to look like a checkmark. So `./ true.` is true. `./ false` throws an exception.
:- op(920, fy, './').
:- meta_predicate './'(0).
'./'(X) :- call(X) *-> true ; prolog_debug:assertion_failed(fail, X).What is some of your most hard-earned knowledge?
1. If you find yourself straying too often from coding in relations, and instead coding in instructive steps, you're going to end up with problems.
2. Use DCGs to create a DSL for any high level operations performed on data structures. The bi-directionality of Prolog's clauses means you can use this DSL to generate an audit trail of "commands executed" when Prolog solves a problem for you, but you can also use the audit trail and modify it to execute those commands on other data.
So first, let's keep in mind that with no execution model, Prolog is still a "syntax" for Horn clauses. It's still a way to document knowledge. Add SLD resolution and we can compute. The paper (intentionally I presume) orders clauses of a simple predicate to illustrate (cause) a problem in Prolog.
But what I actually find is the more time spent in Prolog, the more natural it is to express things in a way that is clear, logical and performant. As with any language/paradigm, there are a few gotchas to be experienced. But generally speaking, SLD resolution has never once been an obstacle (in the past 2 years) of coding.
The general execution model of Prolog is pretty simple. The lack of functions actually makes meta-programming much clearer and simpler. A term is just data, unless it's stated as a goal. It's only a valid goal if you've already defined its meaning.
So I'd be concerned that Curry gives up the simplicity of Prolog's execution model, and ease of meta-programming. I struggle with the lack of types in Prolog, but also know I can (at least in theory) use Prolog to solve correctness problems in Prolog code.
I'm currently using SWI-Prolog. Performance is excellent, it has excellent high-level concurrency primitives[0] (when was the last time you pegged all your cores solving a problem?), and many libraries. I might be one of the few people who has committed to using the integrated editor (PceEmacs) despite being a Vim person. PceEmacs is just too good at syntax highlighting and error detection.
At the same time, I'm a huge fan of Markus Triska. His Youtube[1] stuff is mind-expanding (watch all of it, even if you never write Prolog). He has an excellent book online[2]. I admire the way he explains and advances pure monotonic Prolog, and I appreciate the push for ISO conformance and his support for Prologs that that do the same (SWI is not on that list).
If you want to learn Prolog, watch all of Markus Triska's videos, read his book, and learn what Prolog could be in a perfect world. Then download SWI-Prolog, and maybe break some rules while getting things done at a blazing speed. Eventually you'll gravitate to what makes sense for you.
The Art of Prolog is a classic "must have". Clause and Effect is a good "hit the ground running" (on page 70 you're into symbolic differentiation via term rewriting).
0 https://www.swi-prolog.org/pldoc/man?section=thread
I'm surprised at how readable Prolog is.
I've played with and seriously used many languages in my career. My experience is that pure functional (done Elm style) is productive and scales well to a larger team. Dynamic stuff like Ruby/Javascript always has more bugs than you think, even with "full" test coverage. I'm not smart enough to make sense of my own Scheme meta-programming when I revisit it months later. I have loads (but dated) experience with Java and it (and peers) are relatively easy to read and maintain.
Prolog is very surprising, because it is homoiconic and immensely powerful in metaprogramming, BUT ... the declarative style and execution model reigns in the complexity/readability. A term is just a term. Nothing happens when you create a term. If/when a term is a goal, then you match it with the head of an existing predicate (something you've already coded). So it never gets too messy. Now, the biggest problem with Prolog is that it's so flexible, you'll perpetually be realizing that you could have coded something much more cleanly. So you do that, have less, code, it's nicer, etc. Doing this on a large team might not scale without effort.
i've come to appreciate, over the past 2 years of heavy Prolog use, that all coding should be (eventually) be done in Prolog.
It's one of few languages that is simultaneously a standalone logical formalism, and a standalone representation of computation. (With caveats and exceptions, I know). So a Prolog program can stand in as a document of all facts, rules and relations that a person/organization understands/declares to be true. Even if AI writes code for us, we should expect to have it presented and manipulated as a logical formalism.
Now if someone cares to argue that some other language/compiler is better at generating more performant code on certain architectures, then that person can declare their arguments in a logical formalism (Prolog) and we can use Prolog to translate between language representations, compile, optimize, etc.
I really appreciate how readable the Privacy Policy is. https://againstdata.com/privacy
I do think there should be more details about security. This is all that was mentioned:
DAD constantly evaluates and upgrades the security measures implemented as to ensure a secure and safe personal data processing.
I have to use XQuartz for some apps I run in macOS. Magnet (and other apps I've tried) don't understand those windows. ShiftIt does, but it's buggy and no longer maintained.
Luck. Model an agent that has some odds of doubling wealth, maintaining wealth, or halving wealth per iteration of some game. It's easy to generate downward trends.
Nevermind the quantity of news read. What about the quality and variety of news read?
In theory, Prolog is the king of languages. Simultaneously a logical formalism, and (with a resolution system) a language for computation, AND the ultimate meta-programming language as its homoiconic but only goals are evaluated (there is no eager/lazy evaluation fuss - a term is just a term), and goals can only succeed (and have any consequence) if there is already a matching clause.
In practice, there are some very performant and maintained implementations with small but helpful communities.
Also in practice. With all of this power, it's clear that anything could be done (well) in Prolog, but it's not always clear what that way might be. DCGs are an example of a beautiful, elegant, simple, powerful way of building parsers (or state machines) that was not immediately evident to the Prolog community for some time. The perpetual conundrum as a user will be "I could do it this way, but there are certainly better ways of doing this, and I have many avenues I could explore, and I don't know which might be fruitful in what timeline".
I've been using Prolog daily for the past 1.5 years. I've also implemented and used a Kanren in Elm, and there is simply a world of practical difference.