ristos

Oh ok, you're referring to assignment as one expression, not the PLT definition of expression, which for that example would be like 3-6 expressions depending on whether you consider x, list, and 1 to be expressions. Yeah, a complicted formula might be more verbose in prolog because there's no return statements, it's all unification, but I think that's a feature not a bug, because it allows you to create bidirectional formulas and also naturally extends to "multiple return values" in a sense, because everything is a relation.

No functions:

You can't do length + 1 as a single expression in any language though, in python for example len(ls) + 1 is two expressions, but I get what you mean, it is a little less terse. But those commas in prolog are super useful. And you can make your example bidirectional too:

``` :- use_module(library(clpfd)).

foo(List, X) :- length(List, Out), X #= Out + 1. ```

``` ?- foo(X, 3). X = [_, _] .

?- foo(X, 3), X = [a,b]. X = [a, b] . ```

-----

No standarized collection types:

I think that's a feature rather than a bug. The ability to just use infix and compound terms in a generic way without it being tied to a clause or operator is a huge feature. For example:

``` pets(dog-rex-poodle, dog-fluffy-bishon). ```

That defines the collection in a semantic or mathematical sort of way, then you can pass that into whatever data structure you want, whether it's a ordered map or a hashmap or whatever.

----

No boolean values:

That's also a feature in prolog, same as having no null. It's the same sort of motivation for Haskell's Maybe and Either types or Rust's Option and Result types, same kind of usefulness.

----

Cuts are confusing:

Conditionals don't need to use cuts, the modern prolog way of doing it is using the reif library:

``` :- use_module(library(reif)).

if_(Cond, Then, Else) ```

For example:

``` :- use_module(library(clpfd)). :- use_module(library(reif)).

sign(X, S) :- if_(X #> 0, S = pos, S = nonpos). ```

---

Non-cuts are confusing:

This isn't doing what you're thinking:

``` \+ (A = B) ```

It's unifying A with B, `A = B` unifies. You want `dif(A, B)`.

----

Straying outside of default queries is confusing:

It might be tempting to use bagof, but it's not monotonic. You should try to write as much prolog code as you can in a pure, monotonic way, so your code can take advantage of prolog's unique advantages, like monotonic debugging.

Check out the SWI prolog discourse group, there's a lot of good stuff in there and everyone's very supportive to newbies. And Markus Triska's website and youtube channel Power of Prolog is a super useful resource for all this stuff, a good place to go if you want to know what sets prolog apart. A lot of prolog's usefulness doesn't show up as an embedded language either, like minikanren isn't "pretty much prolog", it lacks a lot of stuff that prolog offers. Multiparadigm programming languages are also really popular now, but a lot of what sets programming languages apart isn't what they can do, it's what they can't do, what sort of paradigm or way of thinking they force you to adopt.

I'm not sure how you would handle your specific situation, but my general take on interviews is that the interviewer isn't just screening you, in the sense that they want to know what you did and your skillset and skill level, they're also trying to figure out how well you can navigate interpersonal politics. And the problem is that for a lot of people those two things seem contradictory, because with interpersonal politics we'll intentionally spin things just slightly, not like a politician but just to maintain a good vibe and keep everyone comfortable and engaged. Like imagine if you were in a social gathering, and there's also a girl you like in there that you're trying to impress, and someone asked you about that previous role, you wouldn't drift off into a rant or anything negative because you don't want to kill the vibes of the meeting, you want to look your best because there's a girl you like there, so maybe you'd say something like "ah, it just wasn't a good fit". And if that came up while you were dating that girl you like, and she wanted to dig deeper on it, you wouldn't just repeat the same thing, because it would look like you're being evasive and she would then be on the defensive because she would've felt like she's prying too much, and it would kill the vibe, you'd just say something a little bit more, also keeping it short, and maybe mention something good about working there that you learned, and then not forcefully but try to make some room to move to another subject, or if you can do it slickly without making it feel awkward then you just shift to some other topic that feels engaging without making it look evasive. Again, it's all about maintaining a good vibe. And companies want to know the ins and outs about you, but they also just want to know that you have some social skills in doing stuff like that, because they're running a company with different kinds of people, sometimes from very different backgrounds, and they need the team to work together and feel cohesive. The company and the management are already trying to keep the company afloat and profitable, it's own engineering problem, on top of marketing, on top of operational concerns, they don't want to have concerns around political drama in the office, they want to know that you can be cool. Unless you're a boy genius from Southie, then maybe they'll tolerate a lot of weird shit from you, but you aren't a boy genius from Southie.

There does seem to be a sort of sampling bias thing that I've only recently noticed, that I think does come from being older now. I started to get back into old retro games I used to play, and I can't help but realize how many games back then were really bad, like not worth playing at all, and I just cherry picked the good ones. And being older, I'm not into gaming anymore, or really much of a consumer at all besides essential goods, being younger you do consume more entertainment products, like games. So I think there's definitely some sampling bias going on here where things look like they're getting worse. Or it could be both things, like it could actually be getting worse, but also not as much as it looks like because of this sort of sampling bias thing. Like having to have multiple accounts, like a Switch account plus some special Switch account and/or another account to play a game, or you buy a game and then there's an online store as well, or you buy a game in person but you can't get a copy digitally, or you buy a digital copy and you can't get a physical copy made for you for a flat fee, or that increasingly people don't actually literally own things anymore and it's all subscriptions or some sort of permission to use, or that a lot of games are just remakes of older games, or that you can't play single player offline, or that you can't transfer or give your digital game that you "bought" and "own" to someone else (less it be a physical copy, obviously), etc.

I don't know, the problem with that mentality is that you can't just separate the art from the artist, right? unless we're talking about historical figures, on some level it's validating and enabling those people and their ideology, even if you explicitly disagree with it.

I'm pretty bummed out to hear about all of this. I thought the suckless style software was pretty cool, easy to grok, minimalist. I use a lot of it. Granted, I've been planning on translating all of the minimalist C software I've been using to R7RS scheme, so maybe this just gives me more motivation to get started on porting my stack to that.

Someone in an earlier thread said something like, if he avoided software written by assholes then he would have a hard time using his computer, something like that. I think that's kind of true, but there are definitely red lines when it comes to violent ideologies.

Maybe that's not a horrible argument in general though, everyone and every body is different. Some things are more therapeutic and medicinal to some people because of their unique physical and mental composition, and other things are more toxic.

I found out I'm a slow metabolizer of caffeine, a cup of coffee will last like 16-18 hours for me, even though the half-life is supposed to be 3-7 hours for adults, which makes coffee a more dangerous drug for me because it'll disrupt my sleep more than the average joe. I still like coffee but I have to be more careful than most people.

That being said I'm pretty sure cannabis is horrible for the developing brain. I remember one anecdote of someone who told me they would get really high when they were 14, and would get so high that they would literally black out, like have no idea what just happened. Probably best to be avoided until adulthood. Nobody when I was in college or older ever experienced anything like that, just the usual report of infrequent users forgetting what they were just talking about or what someone else just said to them, the whole short term memory loss thing.

Idk, popular people and probably influencer types look cool with a phone. They look like a VIP, people are constantly texting them, it looks like they're constantly socializing, networking, etc. Same with social media, they have like 5 million friends and it looks like a lot's going on in their lives.

That's probably the difference between how cool people use technology vs nerds or dorks. When I use my phone, it's either to look something up, study or learn something new, read the news, or talk to my mom. I would imagine I probably don't look cool using my phone.

Joking aside, I think one thing that I really don't like about smartphones and texting entering our lives is that when you're out for food or coffee people get on their phones, and it feels antisocial, like you can't talk to them now without interrupting them from whatever they're doing on their phone. In the past, I remember, if people had nothing to say, they would just sit there and look off into the distance. It all felt way more social back then, when people got together they interacted more.

Nice! is it R7RS compatible? or just specific to Guile?

Intentionally leaving out important or key information is still lying and deception, and is harmful, and can be really harmful if it's a big thing, even in cases when it's done with good intentions.

Nobody is going to fix the problem without fixing the culture, which isn't easy to do.

The issue isn't around tasks that are predictable in nature and therefore easy to estimate with a small margin of error, it's around complexity in software, unforeseen things, bugs, etc, which can compound for larger long term projects.

If engineers give estimates close to what it would be if everything goes right, then they risk overpromising and underdelivering if something goes wrong (hofstader's law). They might've just wanted to do the right thing by saving the company money and time, but in the end they footgunned themselves.

Or engineers intentionally over-estimate in order to manage the complexity, but then you end up with a lot of padding and parkinson's law. Because as soon as the engineer starts underpromising and overdelivering consistently, management will pressure them to lower their estimates because they have a track record of doing that, so instead they're incentivized to pad and then fill up the entire time they estimated even if it took less time.

Sprints were probably invented in order to deal with some of these issues, so that people just work with a bunch of smaller tickets that are much easier to estimate, with the more complex long term estimates going to management, which are incentivized to get it right because they're shareholders. That often leads to micromanagement and burnout, and it doesn't fix the padding/overestimation issue either, it might even amplify it in a lot of cases.

People here mention giving ranges or probability distributions, and have also equally mentioned that they don't work because management wants a single number, or management just assumes the best-case or middle-case of the range as the actual estimate, and then they still get in trouble for giving ranges and it didn't solve anything. It also doesn't solve the problem of unanticipated setbacks, the whole you don't know what you don't know thing, which can only really be solved culturally in some way.

While there are certainly bad managers that want to squeeze their workers, a lot of the time management is probably also pressured to give estimates and that's why they want and need that accuracy, because they're pressured by investors and clients that want to know how much time and money something will cost.

Overall the entire problem is a system cultural issue around managing complexity.

I could see that working well for managers, if they incentivize estimates as biweekly or monthly bonuses going to the most accurate one, and each person gives a detailed estimate of ballpark plus probability of what sorts of things can go wrong and how that impacts the estimate.

The arrow and page up/down keys don't work in any predictable pattern for me, it's really weird. Like I thought it only scrolled up and down with the arrow keys if I press it 4 times, but then page up/down keys don't work no matter how many times I press it, then I focus on the page and it works, but then the arrow keys take 6 times to press before moving, and then I tried the same pattern again, and the arrow keys now take 11 presses before they start moving. Usually a lot of modern apps predictably break the back/forward history buttons and tab focus, but I've never seen anything quite like this. I guess it must be still delivering value though even if the product isn't polished.

Companies aren't incentivized to eliminate false negatives in hiring (talented people getting overlooked), they just need to make sure there are no false positives (bad hires). I'm guessing it's probably rare for companies to think about the bigger picture, like the long term health of the economy and nation, where it's actually really bad if there are a bunch of really talented people that are being underutilized.

If I were interviewer, I'd probably do a coding assignment that builds on an already existing mini codebase, quarter or half day assignment (2-4 hours), with a strict time limit to turn it in by the end of the allotted time. It would test for someone's ability to read unfamiliar codebases, with the codebase being reasonably small for the little time that's available, and the ability to build features on top of it, to write clean readable code compatible with the codebase, etc. And an a 30-60 minute more open-ended informal knowledge interview to gauge how knowledgeable the candidate is and where their strengths and weaknesses are. And previous work would probably be a good indicator, like open source work and/or previous job experience.

I wish it were built with a very small, minimal core, that was just the TUI with the lisp machine like functionality, scriptable using R7RS scheme instead of elisp. And then everything else is built on top in a more modular fashion, with "battery packs" that install many modular components into one higher level functionality, like an IDE.

I'd like to eventually write something like this, there are a lot of things it would enable that you just can't do with emacs. It would be an emacs killer if implemented well, but it would also open up a whole new set of possibilities.

I don't know how far I'd get just working on it on my free time, which is competing for time with other projects. I'm looking for funding for these sorts of projects. If anyone reading this is an investor and interested in funding this sort of thing, please reach out.

There already is a pretty major effort around the prolog community to build everything as much as possible around pure, monotonic prolog, and to provide a means to support multiple search strategies depending on the best fit for the problem. CLP libraries are also pretty common and the go-to for representing algebraic expressions relationally and declaratively.

I wouldn't say that the logic or relational way of describing effects is a bad thing either. By design it allows for multiple return values (foo/1, foo/2, ...) you can build higher level predicates that return multiple resources, which is pretty common for many programs. It makes concatenative (compositional) style programming really straightforward, especially for more complex interweaving, which also ends up being quite common. Many prolog implementations also support shift/reset, so that you can easily build things like conditions and restarts, algebraic effects, and/or debugging facilities on top. Prolog is also homoiconic in a unique way compared to lisp, and it's quite nice because the pattern matching is so powerful. Prolog really is one of the best languages I ever learned, I wish it was more popular. I think prolog implementations need a better C FFI interop and a nicer library ecosystem. Trealla has a good C FFI.

I think logic programming is the future, and a lot of these problems with prolog are fixable. If it's not going to be prolog, it'll probably be something like kanren and datalog within a lisp like scheme or clojure(script).

This is a great resource for getting a good feel of prolog: https://www.youtube.com/@ThePowerOfProlog/videos

Very nice!

I'm looking to use prescheme for low level code that needs more precise control where chibi scheme or guile isn't a good fit. I'm also hoping at some point that I have the time to write a borrow checker on top of prescheme, which might be a subset of prescheme but would still fit many use cases, so that it can be used instead of Rust. And also to create a transpilation step that creates optimizations, that would then ideally be proved. And then that way the borrow checked code with optimizations can be all transpiled by prescheme into C, and then tiny c compiler can compile it unoptimized into straightforward assembly. The goal would be to have verified code that can also be easily hand audited as well. LLMs just make all this stuff so much more possible because of how much faster we can iterate. Fun times for coding!

I feel like the hype around LLMs replacing dev work is similar to what happened years ago when they were saying the same thing about scripting languages and WYSIWYG editors like Dreamweaver...

What ended up happening in practice is just that time was saved on grunt work, and really engineers just ended up working on composing and debugging higher level components, optimization, or low level work.

Deprecating an API doesn't mean you have to break work already done. It can just mean that _newer_ apps can't use the deprecated API.

Would you need every single version of Android? or just a much thinner compatibility layer for deprecated APIs? Newer apps wouldn't be able to use the deprecated API but older apps don't just disappear either

> Now the new API adds fine-grained access and removes complete access. > What are they gonna do? Give the old gallery app fake file access, making it completely useless?

Can you elaborate on your example here? Couldn't they just do something like replace oldGalleryAppOpensOrWritesToAnyPlace() to askPermissionsForWhichFilesAndFoldersCanBeWrittenTo() or ifSensitiveDirIsNoLongerAccessibleAskPermissionOnWhichFolderToUseForCompat() ?

The monomorphic vs polymorphic argument is an interesting one, I'm wondering if you wrote generic versions of these functions using multimethods, like add, append, etc, if the conditional check for the dispatch is enough for the compiler to automatically unbox the type and apply the optimization. So that, for example, the multimethod call for (add <float> <float>) would dispatch to the function that uses fadd on those operands

I was strongly in the static typing camp for a long time, with Haskell, Purescript, Idris, OCaml, and Typescript, but over time I realized that the costs mostly outweigh the benefits.

> The problem is that you invariably have to think about types. If you mistakenly pass a string to a function expecting an integer, you better hope that that is properly handled, otherwise you risk having type errors at runtime, or worse—no errors, and silent data corruption.

The silent data corruption is really only a problem with weak dynamic typing, that usually automatically coerces types. A lot of dynamically typed languages still have strong typing and will immediately error out. And usually in practice you end up testing all of the code you're writing anyone, so this almost never happens in practice except when someone is refactoring without thoroughly testing what they did, which should be done anyway whether there are types or not.

> Primarily that if specifying types is optional, most programmers will not bother, or will just default to `any` to silence the type checker.

They probably do bother when it's an important module, or a an edge boundary that needs to be documented with a contract, or during times of significant refactoring. And these days LLMs can generate the specs, optional types, and tests pretty easily for any sort of self-contained, modular, reasonably well written code.

So now with LLMs I think there's even better reasons to use dynamic typing. And type completion in an IDE still exists for a bunch of dynamically typed languages anyway, like javascript.

Yeah prescheme is really interesting, I really liked the SystemCrafters exploration of it:

https://www.youtube.com/watch?v=QqKuHylIqBs

> What is a variable in C? A register? A memory location?

Wouldn't it depend on the type? Something like:

int p; p = &x;

MOV @R1, R2 ; R1 contains the address of x, move it to pointer p in R2

int p; int value = *p;

MOV @R2, R0 ; Dereference pointer p (in R2), load the value into R0 (int value)

int x = 5;

MOV #5, -(SP) ; Push the value 5 onto the stack (stack-allocated int)

int x = 10; int y = x + 5;

MOV #10, R0 ; Load the immediate value 10 into register R0 (for x)

ADD #5, R0 ; Add 5 to the value in R0 (x + 5), store result in R0

or

MOV #10, -(SP) ; Push 10 onto the stack for x

MOV (SP), R0 ; Load x from stack into R0

ADD #5, R0 ; Add 5 to x

Whether a variable gets stack-allocated or register-allocated, it's still a pretty close mapping afaict. From my understanding the original C mapped closely to PDP-7 and then PDP-11 assembly. The original implementation and how it maps to PDP-11 could be used as a reference implementation.

The left-pad issue isn't related, it was more related to having a lot of dependencies from untrusted or unverified sources. There's nothing stopping you from following what the author is calling a "microprogramming" paradigm and pulling in a single dependency that has a lot of smaller programs in it from a single trusted source, such as core-utils, or a trusted dependency that aggregates a curated and audited set of tools

I don't think this is the case with your comments and a lot of other comments, I think there's genuine confusion and misunderstanding, but I definitely also feel like at this point a decent number of people are intentionally trolling and acting as thought they don't understand what's being said when people make the case for lots of small composable programs, and why that might be provide additional benefits over just having a bunch of small composable pure functions.

I get that GCC and Clang does all sorts of optimizations, but doesn't unoptimized C map closely to 1:1?

I've heard it being called a high level assembly that maps closely to assembly many times at this point, it makes sense to me why people would say that.

> If C maps 1:1 to assembly in your view, then (unsafe) Rust does; if Rust doesn't map 1:1 to assembly, nor does C. It's as simple as that.

I thought the mapping issue was unrelated to the borrow checker, and that it's possible to write a borrow checker for a restricted subset of C. I thought the thing that was making it not map 1:1 was actually all of the extra features in Rust, like the ADTs and async and all of that. Is that not actually the case?

Can anyone explain to me why these two issues aren't considered deal breakers for introducing Rust into the kernel?

1. It doesn't map almost 1:1 to assembly the way C does, so it's not inherently clear if the code will necessarily do what it says it does. That seems questionable for something as important as a kernel and driver.

2. Only one real Rust compiler, that's a recursive compiler, which reminds me of the Trusting Trust problem: https://dl.acm.org/doi/abs/10.1145/358198.358210

Can you be more specific what you view as hacks or idiocies? Besides the criticism of .PHONY targets, which I don't think is a hack nor particularly ugly. When I mean shell I'm referring to a family of shell languages that are used run commands, change directories, etc. Fish is a shell, for example. Babashka can be considered to be a shell. It doesn't even need to be those, someone using make could use python or javascript for the scripting part if it works better than a shell language.

Not satire, sorry I didn't clarify. They want make to have a builtin scripting language rather than using shell scripts, and a dependency tracking system that more complex and less tooling agnostic rather than leveraging the appropriate tool (like `npm ci`).

My 2c: Makefiles are excellent tech, just that a lot of people haven't learned to use it properly and use it as it was intended. I'm sure I'll get pushback, that's ok.

- Too basic: At least half of the software I use just uses plain makefiles and maybe a configure script. No autotools. I optionally run ./configure, and then make and make install, and it just works. I definitely wouldn't consider my setup to be a toy by any stretch of the imagination. It's built out of smaller programs that do one thing and one thing well.

- Too complicated: I don't know, I think make and how it works is really easy to understand to me at least. I guess everyone's had different experiences. Not necessarily your case, but I think usually it's because they had bad experiences that they probably blamed make for, when they were trying to build some complex project that either had a bad build setup itself (not make's fault), or without the requisite knowledge.

- No standard library: It's supposed to be tooling agnostic, which is what makes it universally applicable for a very wide range of tools, languages, and use cases. It's viewed as a feature, not a bug.

- Too constricting: I'm not sure what you mean here, it's designed to do one thing and one thing well. The simple layer is the dependency tracking.

- Too much magic: Cryptic or inconsistent syntax: See 'Too complicated'