yyyk2's comments

yyyk2 | 3 years ago | on: From Common Lisp to Julia

> how come math notation relies heavily on infix operators and even subscripts, superscripts and more?

"Mathematical notation" is an ad-hoc compilation of a huge number of historical accidents, conventions and personal preferences. For each function in math, there's at least 3 different notations for it, and somehow each of your professors ends up using a different one. And to counter your argument, prefix operators appear very frequently in mathematics, including the most common function notation (although of course there's also a postfix and an infix notation), sigma notation, quantificators, roots, and many other common operators.

By the way, your second example should be (print a b c d), I'm not sure why you made a,b,c,d functions there.

yyyk2 | 3 years ago | on: Guix for Development

It's written in Guile, which is a variant of Scheme. #: is used as the keyword indicator, not an uninterned symbol like in CL.

> Why does gnu-build-system use %standard-phases (a symbol with %)

AFAIK %symbol indicates a constant in Scheme.

It's unfortunate that it isn't written in Common Lisp. CLOS would've been immensely useful there instead of the ad-hoc object system via Scheme records.

yyyk2 | 3 years ago | on: Mozilla reaffirms that Firefox will continue to support current content blockers

> If Google wanted to get rid of ad blockers they would make them against the rules in their extension store.

You fail to understand the grand strategy. Outright banning ad blockers would be quite radical and may push people away from using Chromium. Simply progressively gimping ad blockers increases Google's revenue from advertisements while keeping all those users.

I do not use Chrome. I use Mozilla Firefox, since it supports a better webRequest API so that uBlock can block ads despite things like CNAME cloaking.

yyyk2 | 3 years ago | on: Guix for Development

That's not true. I've never subscribed to the mailing list and all patches I've sent were applied.

yyyk2 | 3 years ago | on: Mozilla reaffirms that Firefox will continue to support current content blockers

> While ublock origin may be trustworthy there are many extensions that are not. It would be better to find a more privacy preserving replacement compared to having to trust extensions to be good actors

By running arbitrary code on your computer you are inherently trusting the author of the code to be a good actor.

> Typically the code doesn't blocking the page from loading though.

Tens of megabytes of bloat block pages from loading all the time.

> And again if this change results in faster loading speeds for users ecosystem wide this change is a win.

uBlock speeds up loading because it blocks useless bloat such as advertisements. MV3 restricts the ability to block content, ergo it will slow down loading speeds.

It's not actually designed for privacy or whatever, it's simply a way to gimp adblockers so that Google (one of the largest online advertisement companies) can get more money from their advertisement business. You must be really naive if you don't understand this simple concept.

yyyk2 | 3 years ago | on: Mozilla reaffirms that Firefox will continue to support current content blockers

I want uBlock to get access to the full contents of requests. It actually helps my privacy, as it can perform tracker blocking.

> The second is that it ensures that poorly optimized web extensions can't slow down the performance of loading sites.

This is true for any code that is running on the browser. Luckily, uBlock Origin and the webRequest API allows me to block arbitrary Javascript and assets so that poorly written websites can't slow down the performance of loading sites.

There is an inferior port of uBlock to MV3: https://github.com/gorhill/uBlock/commit/a559f5f2715c58fea4d...

Are you paid by Google?

yyyk2 | 3 years ago | on: Hacking anything with GNU Guix

Guix has a mechanism called search-paths which is defined for any package like Python that searches for things based on envars; it exports the relevant search paths into the environment. Though it also has shell wrappers, which are essentially a hack around non-propagating dependencies: it allows you to expose things that would normally be visible to everyone, like executables, to just the specific program.

yyyk2 | 3 years ago | on: Hacking anything with GNU Guix

Well, all it says that you shouldn't promote it on the "official channels" (i.e. the mailing list and the #guix libera.chat channel). Guix, the package manager itself, does not make installing non-free packages any more difficult than free packages. I suppose it could be said that Guix (the project) makes finding non-free packages harder, although anecdotally I will say that nonguix is the first thing I've heard about guix, since it seems to be the most controversial part of it.

yyyk2 | 3 years ago | on: Hacking anything with GNU Guix

Guix does not make non-free software "intentionally more difficult", it just excludes it from the main repository. There is a nonfree repo that you can add to your guix channels.

yyyk2 | 3 years ago | on: uBlock Origin Lite: Description

Why even pretend like MV3 isn't meant to cripple adblockers so Google can extract more revenue from their advertisement business?

yyyk2 | 3 years ago | on: Common Lisp vs Racket

Is it really? I haven't read many papers where new algorithms or techniques were demonstrated using Scheme.

> Being easy to implement from scratch is a must for both uses cases.

If you are teaching how to write a compiler or an interpreter, yes. Otherwise I would have to disagree.

yyyk2 | 3 years ago | on: Common Lisp vs Racket

Simple languages tend to be very unportable. This has been a plague on Scheme since the beginning, and which the R6RS / R7RS standards have tried to rectify (it's debatable how successful this effort has been). This is one way in which simple languages are limited. (The fact that there are many different Scheme standards certainly doesn't help).

Another part is stripping of useful features to ease implementation. The Scheme language is full of uncomfortable, low-level constructs for the sake of simplicity. In contrast, Common Lisp is far from simple but it contains many high-level constructs which are nonetheless simpler to use.

yyyk2 | 3 years ago | on: Common Lisp vs Racket

> I'd argue that the brightest minds in computer science understand what makes lisp great perfectly.

That is your personal opinion. Personally, I consider the design of Common Lisp to be much superior.

> In the lisp tradition, they made a lisp geared towards their use case, specifically. It's called Scheme...

If by "their use case" you mean teaching CS, then I would agree.

> which sports much more than 'a pseudo-macro system'.

Well, Scheme doesn't really have many features. It's meant to be a simple (and by extension limited) language. I mentioned their pseudo-macro system since it's one of the parts where Scheme (badly) disconnects from its Lisp lineage.

yyyk2 | 3 years ago | on: Common Lisp vs Racket

The GUI situation in Common Lisp is pretty pitiful. AFAIK the best you get is ECL+QT5 or cffi-cl-gtk (which is GTK 3). I don't see a very favorable comparison for Racket at all in anything else though. When people talk about the benefits of Lisp, they are usually talking about the benefits of /Common/ Lisp. Other languages often misunderstand what makes Common Lisp so great, like in the case of Scheme's overly complex pseudo-macro system.
page 1