Just a random "vagus nerve story". A while back, I started having weird heart flutters that turned out to be extra heartbeats (doctors call them PVCs and PACs). Sometimes I'd be fine for days or even weeks, but then they'd come back pretty bad. After a bit, I noticed these flutters were linked to what I ate, which seemed really strange. I couldn't figure out how my food could make my heart skip beats.
I saw a bunch of heart doctors for almost a year before I found one who knew what was up. He told me I had something called "gastrocardiac syndrome." Apparently, not many heart doctors know about it. It's basically when acid reflux in your stomach messes with the vagus nerve. The doctor gave me some medicine to stop the acid (PPIs), and just like that, my weird heartbeats went away completely.
OSTEP by Remzi and Andrea Arpaci-Dusseau is a great read for anybody interested in operating systems (https://pages.cs.wisc.edu/~remzi/OSTEP/). The projects in their class at the University of Wisconsin-Madison were mainly making edits to the xv6 OS.
For those of you that are not familiar with Roger Hui, he is the author of "An Implementation of J"[0]. Which is a fantastic resource if you want to know how to implement an array programming language.
You're 2 clicks away from having a fully-featured clojure environment + an interactive clojure tutorial, thanks to Calva (vscode clojure plugin) running in the browser:
- click here[0]
- click on SSO provider
More information here[1]. Of course, it'd be better to just use the Calva plugin with VSCode. That's a bit more than 2 clicks, maybe about 5.
On another hand, I don't mean to say that it's easy to start programming on Clojure, merely that it's now easy to try it out. There's a steeper learning curve than python or JavaScript, specially on the tooling side.
Hello! PhD student on quantum computing here. While it's cool that the field of QC raises excitement and there are efforts to promote QC to a more general public, it's always a little frustrating to see these approaches that, in a sense (and in my opinion), seriously underplay the difficulty and distance of the field from computer engineering. While it's true that it's an incredibly interdisciplinary field, which can be studied from a Physics, CompSci, EE, etc., perspective, it's definitely its own field, and not a new framework or programming language. I think this reflects heavily on the fact that a lot of QC programming languages peddled by the main industry players hide a lot of stuff behind opaque API calls.
The thing is (again, imho!) it wouldn't have made sense to talk about frameworks when the first classical computers appeared --- and you'd better have knowledge about the hardware and theory. (These are still a good idea to know but not really a requirement anymore.)
Likewise, I think that for the next decades, anyone who wants to meaningfully contribute to QC (rather than call a few API functions) will have to read some technical stuff (my recommendations are [1] as a semi-informal approach, [2] for a CS approach, [3] for an algorithm overview, and [4] as the reference book).
Lots of info about Lambda Calculus itself, the closely-related Combinatory Logic, and how Tromp arrived at his tiny little BLC. Pretty much a tour de force of mathematical logic.
Fluoroquinolone antibiotics like cipro, levaquin, (and generally anything ending in -ofloxacin), can cause permanent nerve damage and one of the presentations is demyelination of the nerves. [1][2][3]
Permanent nerve damage (neuropathy, pins and needles, tingling, muscle weakness, spasms, muscle twitches, heart palpitations) is a known side effect. There's been no attempt made to study if there's any long term delayed brain effects from fluoroquinolones. "Brain fog" is a commonly reported symptom of those who experience fluoroquinolone side effects. I hope there will be more studies on long term brain health from these drugs, as they're given out liberally.
Stanford's experimental operating systems course[0], where you buy a Raspberry Pi and write your operating system on the bare metal by using the reference specifications.
"You should take this class if: 1. You write code well OR (you don't yet write code well AND have a lot of time to devote to the class); 2. AND you find these systems topics interesting.
The people that found the class valuable in the past were entirely drawn from this demographic. (In particular: I would not take this course if you were looking for an easier way to satisfy a cs140 requirement.) We are trying to go as far as possible as quickly as possible with a group interested in doing so." [emphasis mine]
I recently ventured into the Campervan world. A friend gave me a couple of older nice waterproof Polk audio speakers. Mounted them in the back of the van on a custom rubber shock mount I build from random pieces at the hardware store.
I wanted a way to power the speakers and send music via bluetooth 5. All powered off my 12v solar system. Looked around at all the 'commercial' offerings and found nothing attractive. Everything was over priced or just didn't have modern features.
So... I searched around on Amazon for the right keywords. Ended up getting one of these little class D 100w+100w amps with treble and bass knobs off Amazon for $30 [1]. Got a 12v->24v step up for $16 [2] to give the amp a bit more power and less distortion.
Works amazingly well for a fraction of the price of anything else.
The most popular kind of quant trading is using a factor model. The first step is developing some alpha factor, a number that is predictive of how much money you'll make from each stock. So let's say my alpha factor is "companies with good earnings per share will go up." So I first take the EPS for all the stocks in my universe and maybe rank, then zscore. Now I have some positive numbers and some negative numbers. These represent the weights of my portfolio. The positive weighted companies I go long, the negative ones I go short. The bigger the number, the larger my allocations.
Now that I have my alpha factor I backtest it and whatever. Since the mean of a zscore is zero, I know I'm market neutral, so (ignoring some stuff) my factor should have little exposure to the market.
If I think it's good, I add it to my other alpha factors and combine them somehow. Could be as simple as adding them all up, or maybe something like using random forests to figure out the best way to combine them, or whatever. Now that I have a bunch of alpha factors all combined, I can run them through the optimization engine.
The optimization engine will adjust the weights of my "ideal" portfolio in order to reduce exposure to various risk factors (thus lowering volatility). My optimizer will also figure out how often I need to rebalance. There's generally a bunch of terms in there that try to reduce trading costs and zero out exposure while not diluting the "ideal" portfolio too much (or else the alpha could be wiped out).
Now, after all of this, I'm ready to trade.
In short, what we're trying to do is reduce our exposure to as many factors as possible and just get exposure to our alpha factor. We don't want the market, price of oil, sex scandal of a CEO, or anything else affecting our portfolio. We are trying to dig up this latent, unearthed, alpha that exists in the market, but doesn't belong to one company or asset.
Rigetti Computing is a company that builds quantum computers.
We have used Common Lisp in production at Rigetti Computing for 4 years both in cloud deployment as well as for a downloadable SDK. Common Lisp is used to build what is currently the best free optimizing compiler for quantum computing [1, 2] as well as one of the most flexible quantum computer simulators [3]. They’re both open source, so you can actually see for yourself how we version, deploy as binaries, and deploy in Docker containers.
> If you are using lisp in production for non-trivial cases, do these issues still exist?
Before getting into the specifics, any large, non-trivial product that customers use will need tweaking. Especially languages that have runtimes, including languages like C. This is usually a result of leaky abstractions that just have to be dealt with in The Real World (TM).
> * poor ecosystem of libraries - few gems, most other half-baked
You have libraries for most things you need. Some are lacking, like in scientific computing. But all your usual stuff to glue things together is there and works.
Some people confuse “half-baked” with “no commits for 5 years”. Lisp libraries are older than many in vogue languages, and Lisp doesn’t change, so “5 years no commits” shouldn’t be worrisome.
At Rigetti, the biggest weight we had to pull that we wouldn’t have needed to do in, say, Python, is bind to a bunch of FORTRAN code, specifically LAPACK. That was a pain because you need to do FFI with complex double floats.
* poor community coordination
The community all agrees on one thing: Lisp is standardized.
Lisp lacks a sort of “centralized community” like Go or Clojure. I like to think that Common Lisp is more “democratic”. We have a “constitution” (the Common Lisp standard) that we all agree on and we all make our own contributions atop that.
With that said, #lisp on Freenode is attentive. SBCL, for example, responds to bug reports almost immediately. Several library ecosystems are kept up to date, etc.
> * Dependency management limitations with quicklisp
With Quicklisp, I personally realized a lot of other dependency management solutions are overblown and don’t actually solve problems. Maybe QL gets away with it because the ecosystem is smaller than others.
Xach, the creator of QL, does a lot of community diligence for free to ensure things work.
For production code, I’ve had 0 issues.
> * poor support for json
We use YASON [4] and it works fine.
> * poor support for async
This is true now but wasn’t true years ago. Lisp implementers have not been interested in implementing a runtime supporting async programming. Little in the Common Lisp language itself prohibits it. Before the world of threads and SMP, Lisp implementers did implement async runtimes.
Why aren’t Lisp implementers interested in async? I’m not sure. Maybe they see it as a passing fad?
> * have to restart the server every 20 days because of some memory leak
Memory leaks can happen but they’re usually the programmer’s fault for not understanding symbol interning, weak pointers, or finalizers. Writing long-running applications does require know-how.
> * hack to tune GC
I don’t consider it hacking. In SBCL we tune the GC to our application. This seems reasonable; different programs have different allocation patterns. But you wouldn’t need to do this out of the box.
> is there a way you can quantify effort is resolving them, and if yes, what is it?
Big applications that are customer products require care and feeding. The benefits of writing in Lisp in the first place largely outweigh some of the extra work needed to productionize it.
I will say that writing production Common Lisp code is greatly benefited by having at least one experienced Lisper on the team. If a team would, for some reason, write an application in Lisp but not really have a good understanding of the language, then productionizing and hardening will be difficult.
> and, finally, if you had to re-do your project, would you chose lisp or something else?
Common Lisp allows something that never existed before (a completely automatic, optimizing quantum compiler) to exist. If Lisp weren’t there, that wouldn’t exist.
My parting advice is this: The biggest difficulty in writing an application is to actually write it. It takes a lot of hard work to get requirements, listen to feedback, articulate a direction, etc. In Common Lisp, SBCL or LispWorks or whatever else, dumping an executable is so easy and you can have a deployable “production app” in 5 minutes. So the good news is that you won’t be held up trying to figure out how to dockerize your Python app.
I definitely agree that before embarking, doing an objective and relevant comparative analysis would be good (we did this at Rigetti), but ultimately you just need to sit down and write.
Almost every programming problem is solvable these days with enough glue and elbow grease. I wouldn’t be too worried.
He designed a 29 state cellular automata architecture to implement a universal constructor that could reproduce itself (which he worked out on paper, amazingly):
He actually philosophized about three different kinds of universal constructors at different levels of reality:
First, the purely deterministic and relatively harmless mathematical kind referenced above, an idealized abstract 29 state cellular automata, which could reproduce itself with a Universal Constructor, but was quite brittle, synchronous, and intolerant of errors. These have been digitally implemented in the real world on modern computing machinery, and they make great virtual pets, kind of like digital tribbles, but not as cute and fuzzy.
Second, the physical mechanical and potentially dangerous kind, which is robust and error tolerant enough to work in the real world (given enough resources), and is now a popular theme in sci-fi: the self reproducing robot swarms called "Von Neumann Probes" on the astronomical scale, or "Gray Goo" on the nanotech scale.
>The von Neumann probe, nicknamed the Goo, was a self-replicating nanomass capable of traversing through keyholes, which are wormholes in space. The probe was named after Hungarian-American scientist John von Neumann, who popularized the idea of self-replicating machines.
Third, the probabilistic quantum mechanical kind, which could mutate and model evolutionary processes, and rip holes in the space-time continuum, which he unfortunately (or fortunately, the the sake of humanity) didn't have time to fully explore before his tragic death.
p. 99 of "Theory of Self-Reproducing Automata":
>Von Neumann had been interested in the applications of probability theory throughout his career; his work on the foundations of quantum mechanics and his theory of games are examples. When he became interested in automata, it was natural for him to apply probability theory here also. The Third Lecture of Part I of the present work is devoted to this subject. His "Probabilistic Logics and the Synthesis of Reliable Organisms from Unreliable Components" is the first work on probabilistic automata, that is, automata in which the transitions between states are probabilistic rather than deterministic. Whenever he discussed self-reproduction, he mentioned mutations, which are random changes of elements (cf. p. 86 above and Sec. 1.7.4.2 below). In Section 1.1.2.1 above and Section 1.8 below he posed the problems of modeling evolutionary processes in the framework of automata theory, of quantizing natural selection, and of explaining how highly efficient, complex, powerful automata can evolve from inefficient, simple, weak automata. A complete solution to these problems would give us a probabilistic model of self-reproduction and evolution. [9]
[9] For some related work, see J. H. Holland, "Outline for a Logical Theory of Adaptive Systems", and "Concerning Efficient Adaptive Systems".
I started with a $25 RTL-SDR v3 kit that includes two antennas (for VHF and UHF, approximately). That allowed me to listen in on 2m and 70cm band repeaters, and familiarize myself with the language, etiquette, modes, etc. I recommend that to anyone that is interested in amateur radio, and you can still make good use of that stick once you get a transceiver, by using it as a spectrum scope / waterfall. From there, a $40 Baofeng will allow you to get used to the feel and operation of the radio, just don't transmit until you get your Technician license. You can sometimes get the Technician study book for free from ARRL by signing up for their welcome packet, or check it out from your library. The exam costs $15 or less, and you can cram study for it at hamstudy.org. (The few-dollar HamStudy mobile app is also worth the cost.)
That gets you a SDR with spectrum scope and waterfall, a portable HT UHF/VHF transceiver, and your Technician license, for ~$80. From there, you can look into getting your General license to transmit on HF, and a cheap HF radio and antenna, for less than $500 total. A higher quality HT like an Icom or Yaesu would be money well spent for VHF/UHF, as the Baofeng is notoriously hard to program and allows you to transmit outside the legal band limits.
(Note: the RTL-SDR works best for VHF and UHF. For an HF SDR, you'll want to check out something like the Airspy HF+ Discovery and perhaps a cheap $30 magnetic loop antenna from eBay, which is what I use.)
Edit: My apologies for the acronyms. SDR is software defined radio, allowing you to receive radio signals on your computer. HT is "handy-talkie" or handheld transceiver. HF/VHF/UHF are defined in the parent post.
Start with the basics. Read a business writing book, articles, or take a course on it. Even a one-hour course will teach you something new. Beyond that, some things that help me address my weak spots:
1. Make sure your first paragraph or executive summary answers the questions: Why does this doc exist? Who is the expected audience? What actions or decisions does the author expect from the audience after reading the doc?
2. Run things through an analyzer like Hemingway[1]. It'll point out obvious things to fix.
3. Do a reverse-thesaurus editing pass. Remove adjectives and flowery language where possible. Challenge yourself to lower the reading level. Even if your audience has PhDs they'll read and comprehend simple language faster.
4. Do an editing pass for missing numbers. Vague language, unsupported assertions, and missing quantities make arguments easy to refute. Look for words like "many", "most", "a lot", "major" "severe" "large" and replace them with hard numbers where possible.
5. Do an editing pass for "So, what?" and remove anything that isn't necessary to support your core argument or purpose. Assume your audience is smart but has very little time. Too much detail will make them start to skim and miss things. Appendixes are your friend here. Leave links to appendixes for readers that have questions or want more detail.
6. Nothing beats a human reviewer. Professional writers have editors too.
RIP Professor
Best teacher I've ever had, he let me audit all his classes and took me/my ideas seriously at all times. And would grade my papers even though I was never an official student, or his his words "a paying customer."
First Minsky now Patrick. RIP and perhaps they are both back in touch. ;(
