Lecture 1: Introduction to Research — [📝Lecture Notebooks] [
Lecture 2: Introduction to Python — [📝Lecture Notebooks] [
Lecture 3: Introduction to NumPy — [📝Lecture Notebooks] [
Lecture 4: Introduction to pandas — [📝Lecture Notebooks] [
Lecture 5: Plotting Data — [📝Lecture Notebooks] [[
I'll preface this with three things. 1. I prefer schemes over Common Lisps, and I prefer Racket of the Schemes. 2. There is more to it than the points I raise here. 3. I assume you have no previous experience with Lisp, and don't have a preference for Schemes over Common Lisp. With all that out of the way... I would say Common Lisp/SBCL. Let me explain
- SBCL Is by far the most common of the CL implementations in 2021. It will be the easiest to find help for, easiest to find videos about, and many major open source CL projects are written using SBCL
- Download a binary directly from the website http://www.sbcl.org/platform-table.html (even for M1 macs) to get up and running (easy to get started)
- Great video for setting up Emacs + Slime + Quick Lisp https://www.youtube.com/watch?v=VnWVu8VVDbI
Now as to why Common Lisp over Scheme
At the beginning of 2030, I found this essay in my archives. From what I know today, I think it was very insightful at the moment of writing. And I feel it should be published because it can teach us, Rust developers, how to prevent that sad story from happening again.
What killed Haskell, could kill Rust, too
What killed Haskell, could kill Rust, too. Why would I even mention Haskell in this context? Well, Haskell and Rust are deeply related. Not because Rust is Haskell without HKTs. (Some of you know what that means, and the rest of you will wonder for a very long time). Much of the style of Rust is similar in many ways to the style of Haskell. In some sense Rust is a reincarnation of Haskell, with a little bit of C-ish like syntax, a very small amount.
Is Haskell dead?
| #!/usr/bin/awk -f | |
| # This program is a copy of guff, a plot device. https://github.com/silentbicycle/guff | |
| # My copy here is written in awk instead of C, has no compelling benefit. | |
| # Public domain. @thingskatedid | |
| # Run as awk -v x=xyz ... or env variables for stuff? | |
| # Assumptions: the data is evenly spaced along the x-axis | |
| # TODO: moving average |
See also List of materials about Software Design in Haskell
| Junior | Middle | Senior | Architect | |
|---|---|---|---|---|
| Haskell level | Basic Haskell | Intermediate Haskell | Advanced Haskell | Language-agnostic |
| Haskell knowledge scope | Learn you a Haskell | Get programming with Haskell | Haskell in Depth | Knows several languages from different categories |
| Get programming with Haskell | Haskell in Depth | Functional Design and Architecture | ||
| Soar with Haskell | [Soar |
WARNING: Article moved to separate repo to allow users contributions: https://github.com/raysan5/custom_game_engines
A couple of weeks ago I played (and finished) A Plague Tale, a game by Asobo Studio. I was really captivated by the game, not only by the beautiful graphics but also by the story and the locations in the game. I decided to investigate a bit about the game tech and I was surprised to see it was developed with a custom engine by a relatively small studio. I know there are some companies using custom engines but it's very difficult to find a detailed market study with that kind of information curated and updated. So this article.
Nowadays lots of companies choose engines like [Unreal](https:
Testimonies
The thing in CL I miss most doing Clojure as my day job? CL's compiler. I like having a compiler tell me at compile time about the mistakes I've made. Bogus arguments. Unreachable code because of unhandled exceptions, and so on. CL saves me round after round of bugs that in clojure aren't found until you run the code. If you test well, it's found when testing, if you don't it's found in production. "Clojure compiler" almost demands air quotes.
CL's optional but oh-so-useful model of type declarations is also infinitely more useful (to me) than Clojure's use of "spec", and instrumentation that happens only at test time because of the cost. Depending on the OPTIMIZE declarations, other type defs are a floor wax and dessert topping. Want checks for argument types? Lower optimizations. Want most efficient machine code? High optimizations.
/u/Decweb, March 2023 https://www.reddit.com/r/lisp/comments/11ttnxk/the_rise_fall_of_lisp_too_good_for_the_rest_of/jczpysp/
The counters that are the easiest to understand and the best for making ratios that are internally consistent (i.e., always fall in the range 0.0 to 1.0) are the mem_load_retired events, e.g., mem_load_retired.l1_hit and mem_load_retired.l1_miss.
These count at the instruction level, i.e., the universe of retired instructions. For example, could make a reasonable hit ratio from mem_load_retired.l1_hit / mem_inst_retired.all_loads and it will be sane (never indicate a hit rate more than 100%, for example).
That one isn't perfect though, in that it may not reflect the true costs of cache misses and the behavior of the program for at least the following reasons:
- It appplies only to loads and can't catch misses imposed by stores (AFAICT there is no event that counts store misses).
- It only counts loads that retire - a lot of the load activity in your process may be due to loads on a speculative path that never retire. Loads on a speculative path may bring in data that is never used, causing misses and d

