serhart

I'm not who you replied to, but no, no, I don't think that's an "opposition" to writing in the sense that it's making us stupid or replacing oral traditions.

From my limited understanding of history and Greek philosophy, Socrates valued dialogue, a "back and forth" for understanding. Basically a scientific method of probing to understand something or someone. This needs to exist to be fully sure you understand something. Sort of what we are doing now.

A static piece of literature or a speech can't be probed for more clarity. You may read something and come off with a completely different understanding from the author. You might even pervert or "abuse" the original intent since words can have multiple interpretations.

I don't think there was opposition in the sense that you shouldn't write. My understanding is just that in order to truly understand something, you need a dialogue. It allows you to actually arrive at what was meant to be conveyed.

It actually seems sort of ironic that people are saying this about Socrates because of what was written about him….

A FLAC encoder/decoder written in Guile scheme. I struggled to get the decoder working with most test files for a while until recently. It's more or less a fully functional decoder now. It's also 1:1 with the reference meta-flac command currently as well.

https://github.com/steve-ayerhart/guile-flac

Relax, it's just a play on https://www.poetryfoundation.org/poems/43291/sailing-to-byza...

The code is a mouse wheel scroll down.

Yes, that is very much what they were. However, they used the term compiler in very much the same way it's used today. It didn't mean something different. The concept of the "compiler" was to translate mathematical symbols (or predefined machine code representing that math) and later English like words into programs a machine could execute.

That is absolutely not true. Just because early compilers acted more like linker/loader doesn't mean they used the word compiler to mean "linker". When the term was coined it absolutely meant translating mathematical formulas into machine code. Compiler very much had the same meaning it has today.

Use a good text parsing library. Regexes are probably not enough for your use case. In case you are not aware of the limitations of regexes you may want to learn about Chomsky hierarchy of formal languages.

Most programming languages offer a regex engine capable of matching non-regular languages. I agree though, if you are actually trying to _parse_ text then a regex is not the right tool. It just depends on your use case.

How is it not a matter of familiarity? Just because it's not intuitive to you doesn't mean it's bad. I find anything not in an S-expression to be atrocious. Doesn't mean I can't learn and understand "horrible" syntax where I have to separate things with semicolons...

I don't agree at all. I don't find it less "readable". You just have to be used to it. If you understand English, German isn't that hard of a language to learn. Japanese would probably be a little bit harder to pick up though. Doesn't mean Japanese is unreadable

Sure, but bash only has certain language constructs. This implementation is using parameter expansion and some other built ins. It's definitely more complex than yours, but that's what bash has to offer.

Yes, but I think that's antithetical to what languages like bash and perl are trying to do. Someone well versed in the language can do some pretty complex operations in a few keystrokes.

I'm in no way defending bash as a language. There are lots of gotchas and weird constructs. I avoid bash too. It's just that trim function isn't that cryptic or "unreadable" if you know the syntax.

Just because you seem to be unfamiliar with bash doesn’t mean it’s unreadable. Almost any language will look cryptic if you don’t know it. That function is mostly just parameter expansion and very common in most bash scripts. I bet if you read the manual you would easily be able to figure it out. You just have to learn the language.

It is implemented in Guile. The language is just syntactic sugar via macros and utilizes WISP.

https://git.savannah.gnu.org/cgit/gwl.git/tree/gwl/sugar.scm https://srfi.schemers.org/srfi-119/srfi-119.html

If you aren't trying to be Unix I would imagine you aren't thinking that. GNU probably doesn't subscribe to that notion.

I'm pretty curious on how you conclude that GNU is "intentionally obfuscating code" from [1]. I read [1] as good advice to avoid inadvertently getting code into GNU that could be claimed by copyright. Focus on speed instead of memory; simplicity instead of speed. I don't see "make it different for difference sake."

I also conclude the opposite from the cat implementations. I really don't see how the BSD cat is a more "pure" or straight forward implementation. I find the GNU cat to have way more options and easier to read source code. My guess is that novice programmers would find the GNU version easier to grok, which also probably aligns more to the goal of GNU. Or I just like to read obfuscated code.

I don't think it has Nvidia drivers, but there is work being done for Guix and HPC. https://guix-hpc.bordeaux.inria.fr/

It's definitely not trivial to do. I have the Guix system installed on my mid 2013 MBP. I installed the mainline Linux kernel and drivers along with the proprietary Broadcom wireless module. Everything seems to be running fine.

The official Guix channels do not package proprietary software. However, nothing is stopping someone from doing it.

By definition, if you're programming Emacs Lisp, you're an Emacs user. Emacs is the interpreter.

That's not necessarily true. Guile supports Elisp as a language. You can write Elisp sans Emacs.

Here is a gist of the relevant packages and configs I have for my MBP.

https://gist.github.com/steve-ayerhart/81c9dfc773472e08002cd...

I don't have access to it now. When I do I can put the package definitions and OS config up somewhere.

When you first boot GuixSD most of the core stuff should work fine. Wireless will not work but you should have ethernet. I created mainline linux kernel and firmware packages [1]. Then you need to get the broadcom b43 firmware to get wireless support. I think I made 2 packages. One for b43-fwcutter and one the broadcom-wl firmware which uses b43-fwcutter to cut and install it. I think just about everything on my MBP was working after that.

[1] example linux package https://github.com/wingo/guix-nonfree/blob/master/gnu/packag... [2] http://linuxwireless.sipsolutions.net/en/users/Drivers/b43/

None that I know of currently. The OS is version 0.15.0. It's very young and doesn't have a huge user base. I'm sure there will be non gnu repositories that will eventually spring up. I've even toyed with the idea of setting one up.

Not true. You can write your own packages in the same high level interface. Including the mainline Linux kernel and broadcom drivers. I have GuixSd running on my 2013 MBP