Tag Archives: coding

2023 Reading list (updated as we go)

Engineering Metrics : https://hybridhacker.email/p/diving-into-engineering-metrics

My next read : http://lawsofsimplicity.com/ John Maeda

System design and the cost of architectural complexity : https://dspace.mit.edu/handle/1721.1/79551

Simplicity was the key for Instagram backend (in 2011) : https://engineercodex.substack.com/p/how-instagram-scaled-to-14-million

Simplicity mindset : https://betterprogramming.pub/3-tips-to-adopt-a-simplicity-mindset-when-designing-software-711b95328062

Fastly supports go on Edge : https://www.fastly.com/blog/announcing-standard-go-support-for-fastly-compute

Go WASI support : https://go.dev/blog/wasi

Any company providing support for a product would want to have something like this https://www.fixie.ai/

Meta Launches AI Code Writing tool https://www.theverge.com/2023/8/24/23843487/meta-llama-code-generation-generative-ai-llm : you can test it here : https://labs.perplexity.ai/

Whats App : https://newsletter.systemdesign.one/p/whatsapp-engineering

Photographs that are like films https://www.rencontres-arles.com/en/expositions/view/1447/gregory-crewdson

I find it so true : https://intenseminimalism.com/2013/conways-law/

Jerome Lanier on music and what Reality is in the end : https://www.newyorker.com/culture/the-weekend-essay/what-my-musical-instruments-have-taught-me

We lost Kevin (The Condor) Mitnick ( https://www.dignitymemorial.com/obituaries/las-vegas-nv/kevin-mitnick-11371668 ) : TCP is a much more secure protocol also thanks to him.

Yoshua Bengio (CA) and John Bunzl (UK), moderated by Nico A. Heller on strengths and limitations of current artificial intelligence, why it may become a dangerous instrument of disinformation, why superintelligent AI may be closer (years) than most previously expected (decades) and how this could yield to catastrophic outcomes – from AI-driven wars to the extreme risk of extinction. https://www.youtube.com/watch?v=07c1ZRUQOeY. Notes, general concepts from Bengio talk :


AI currently perceive the world and make sense of it with images, sound and text, generating content in all 3 areas.
Current systems are not at the level of human intelligence, they master what psychologist call system 1 intelligence (intuition) : react to any question/context, no reasoning (or little reasoning) – arithmetic : simple operations with numbers ok, more complex (of the type we will need paper and pencil) they make mistakes.
System 2 intelligence : explicit reasoning, you can plan, imagine. Ex:
driving left hand roads after having driven right hand all life. We take 1 hour to adapt because we don’t use intuition but reasoning. AI will get there : how much time will take to bridge the gap between s1 and s2 ? nobody knows, could be close or take 10 years.
Training data currently needs to be filtered to remove data that appears to be insulting, homophobic or racists, dangerous, inadequate. AI will get there too to avoid the need of preparing training material.
Machines that are as intelligent as we are will be inevitably more intelligent than us because they are machines : immortal, don’t sleep, can exchange info at high speeds like if they were a huge brain. Humans have culture to try to simulate this.

  • pure intelectual power, completely detached from the goal. The goal will make the difference between a “good” AI and an “evil” one.
  • humans cannot turn off compassion (or just most people can’t) as it has been hardwired into us by evolution; machines can

Stating a goal in a precise way is probably impossible so even AI with good goals might behave evil.

Goals are not expressable, we can only give partial specifications

We’ll get to the point where the game will be : who’s AI is bigger/better/faster ?

Most important thing to reduce the probability of bad behavior connected to AI is to reduce the actors, materials, information, proliferation (like we did for atomic bombs)
Regulatory frameworks are necessary.

Go : inside map implementation https://www.youtube.com/watch?v=Tl7mi9QmLns and https://phati-sawant.medium.com/internals-of-map-in-golang-33db6e25b3f8

Go 10 years after : https://blog.carlmjohnson.net/post/2023/ten-years-of-go-good-bad-meh/ and why we can live without subclassing https://hynek.me/articles/python-subclassing-redux/

Extreme readability https://www.moderndescartes.com/essays/readability/

AI can’t create software, only code : https://stackoverflow.blog/2023/06/26/the-hardest-part-of-building-software-is-not-coding-its-requirements

Some WASM Stuff :
– cloudflare wasm runtime https://github.com/cloudflare/workerd
– wasmtime runtime : https://github.com/bytecodealliance/wasmtime
– wasi-libc : still no thread support (june 2023) https://github.com/WebAssembly/wasi-libc

Ping Pong Programming : TDD + Pair Programming : https://www.agileconnection.com/article/ping-pong-programming-enhance-your-tdd-and-pair-programming-practices

Using AI in Ping Pong programming : https://www.mechanical-orchard.com/post/can-ai-play-the-tdd-pairing-game

AI Technology map : https://a16z.com/2023/06/20/emerging-architectures-for-llm-applications/

You build it, you own it : https://blog.alexewerlof.com/p/you-build-it-you-own-it

AI generated sort algorithms make it into LLVM/C++ https://www.nature.com/articles/s41586-023-06004-9

Superfast hash https://github.com/wangyi-fudan/wyhash

Google leaked internal document on AI : https://www.semianalysis.com/p/google-we-have-no-moat-and-neitherkkjhnmmmm

Compression algorithms benchmarks : https://github.com/inikep/lzbench

What’s inside training data for LLM https://arxiv.org/pdf/2101.00027.pdf

Cache Optimization Models and Algorithms : https://arxiv.org/pdf/1912.12339.pdf

ChatGPT Is a Blurry JPEG of the Web https://twitter.com/paulborile/status/1647640363555758083

Ordinals https://docs.ordinals.com/overview.html

NO Pause on AI development : https://medium.com/enrique-dans/a-pause-on-the-development-of-ai-its-not-going-to-happen-d4f894816e82

Cheatsheet for golang test, benchmarks, profiling https://github.com/samonzeweb/profilinggo

Yet another browser https://mullvad.net/it/browser promising to minimize tracking and fingerprinting.

everything cli https://www.commandlinefu.com/commands/browse

Amazon Is Making a New Web Browser ? https://gizmodo.com/amazon-prime-new-web-browser-survey-1850224922?utm_source=tldrnewsletter

Interview with OpenAI’s Greg Brockman: GPT-4 isn’t perfect, but neither are you https://techcrunch.com/2023/03/15/interview-with-openais-greg-brockman-gpt-4-isnt-perfect-but-neither-are-you/?utm_source=tldrnewsletter&guccounter=1

On jpeg-XL https://cloudfour.com/thinks/on-container-queries-responsive-images-and-jpeg-xl/#jpeg-xl-the-holy-grail-image-format
https://cloudinary.com/blog/the-case-for-jpeg-xl

On crypto and thieves :
“In February 2022, a hacker stole 120,000 wrapped Ethereum from Wormhole, a cross-blockchain bridge” https://newsletter.mollywhite.net/p/oasis-defi-centralization – subscribe to Molly White newsletter for unbiased crypto news.

B Corporation Certification : https://en.wikipedia.org/wiki/B_Corporation_(certification) “As of September 2022, there are 5,697 certified B Corporations across 158 industries in 85 countries.” https://www.bcorporation.net/en-us/
https://www.positive.news/economics/five-trends-sustainable-business/

https://lumalabs.ai/ : acquire 3d assets anywhere with a phone

https://roaringbitmap.org/ compressed bitmaps

Code RED in google : https://medium.com/@ignacio.de.gregorio.noblejas/can-chatgpt-kill-google-6d59742ee635

Node.js is aging like milk https://javascript.plainenglish.io/node-js-is-aging-like-milk-now-whats-next-a4e726ae668f :

Ryan Dahl, creator of Node.js moved to Go.

TJ Holowaychuk, creator of Express.js framework moved to Go.

Boston dynamics showing off https://youtu.be/-e1_QhJ1EhQ

Chat GPT4 talk https://www.theverge.com/23560328/openai-gpt-4-rumor-release-date-sam-altman-interview

Fyne IDE, currently work in progress https://github.com/fyne-io/defyne

1995 paper by the Niklaus Wirth “A Plea for Lean Software” https://cr.yp.to/bib/1995/wirth.pdf

Yes, I like go programming language

Yes, I like Go programming language. I’m liking it so much that I have to resist from being a fan boy. I’m trying to understand where all this enthusiasm is coming from (I’m a seasoned coder)  so here’s an attempt to find why :

  1. Code readability — and maintainability — first, language features second
  2. Integrated test environment : go test <package> executes all tests for the package. Unit testing features are builtin.
  3. Code Coverage is builtin (with some limitations, for example if you use cgo it will not work).
  4. Integrated tool chain : no need to have makefile at the cost of rigid hierarchy of data.
  5. Exhaustive standard library containing everything you need to do server-side/network programming
  6. Good Multi-threading features/model included in language (sync package, goroutines, channels), fast goroutines thanks to segmented stack implementation.
  7. Basic set of OOP features, centered on composition, not inheritance : you won’t be able to mess up your code at the cost of not being perceived as an OO language by OO fanboys. For more details on whether go is oo or not go here.
  8. Go is backed by some Famous Names in computing, and this inspires confidence.
  9. CamelCase 🙂 ? Naaah, I hate camel case but I like the choice of having standard style, comments, indent; all supported by the language via go fmt package so that all code will look coherent.

So basically I like the fact that Go is a very opinionated language. You might like the single decisions or not but what I like most is that someone took care of taking them for you (so you don’t have to enforce them team wide or company wide)
Interesting read also on how and why go was born : quoting from Rob Pike speech at go conference SF 2012 :

“To put it another way, oversimplifying of course:

Python and Ruby programmers come to Go because they don’t have to surrender much expressiveness, but gain performance and get to play with concurrency.

C++ programmers don’t come to Go because they have fought hard to gain exquisite control of their programming domain, and don’t want to surrender any of it. To them, software isn’t just about getting the job done, it’s about doing it a certain way.

The issue, then, is that Go’s success would contradict their world view.

And we should have realized that from the beginning. People who are excited about C++11’s new features are not going to care about a language that has so much less.  Even if, in the end, it offers so much more.”

Top software coders bad mental habits :-)

New year is time for self-examination; one of the most frustrating things for a coder is writing code with bugs and bugs are almost always directly related to bad mental habits imho. This is not a complete list of any kind, it is a set of well known and widespread ones that you for sure have already encountered in your coder life. I’m writing them down just as a reminder for myself :

  1. The “Let’s do it this way for now (I know this cannot be the final way of doing it), because I don’t want to stop 5 minutes and think about it” attitude. This is the worst of all bad habits in my opinion. It is this attitude that generates the most of production bugs because the only moment you had to focus on that specific issue you decided to skip over it, for the sake of continuity in your mental path (which is a good thing by itself but bad if not derogable ). That moment will never come again, that “preliminary” code will go strait to production and that issue will never ever be taken into account again until it generates a bug.
  2. Using the “quick and dirty” way to do things even when there is no real need for that type of approach. This is related to the fact that we are almost always pushed to deliver fast and after time the “quick and dirty” approach becomes the standard one, always, regardless of requirements.
  3. Unreadable code : this does not necessarily generate bugs but makes it difficult to fix them.It is caused by :
    1. coder EGO : “nobody will ever be able to understand my code unless spending an hour over 10 lines”. I will be the only able to maintain it.
    2. “This way is faster, (probably) ” (note probably, because nobody is ever measuring code speed). Modern compilers/cpus do things that we can’t imagine in terms of optimization, but “I can do better”.
  4. Comment out unused code, or worse, gate it with a feature flag. Code that has no purpose is a major source of distraction and confusion. Today’s version control systems make it easy to revert any changes; there’s no reason not to remove dead code and other bloat.
  5. Over engineering code or overdoing features : this one is so big that needs a separate post to handle it but we might try to summarize it with
    1. more code, more bugs
    2. more code, more tests to make, more time
  6. “I’m gonna do this in 10 minutes” attitude

Code performance myths

One if my main tasks from 2015 on has been optimizing performance on various languages api (mainly C/C++). This post tries to recap best practices in this area.

For those like me who work in IT since the z80 let me say that cpu have changed, a lot; variability in computing time in modern computer architectures is just unavoidable; while we can guarantee the results of a computation we cannot guarantee how fast this computation will be : 

“Computer can reproduce anwsers, not performance” : Bryce Adelstein Lellback, https://youtu.be/zWxSZcpeS8Q?t=6m45s

Reasons for variance in computation time can be recap in :

  • Hardware jitter : instruction pipelines, cpu frequency scaling and power management, shared caches and many other things
  • OS activities : a huge list of things the kernel can do to screw up your benchmark performance
  • Observer effect : every time we instruments code to measure performance we introduce variance.

Also warming up the cpu seems to have become necessary to get meaningful results. Running hot instead of cold on a single piece of code is well described here https://youtu.be/zWxSZcpeS8Q?t=18m51s

You have to measure. There is no other way; things that by your experience might look faster if done in a certain way reveal to be slower when measured so put away all your preconceptions and prepare to A/B test your code for performance. Here’s are some hints, not a complete list at all :

1) make sure your code is doing what you expect. Profile your code compiled without the optimizer and check that your are not calling unwanted code (valgrind/kcachegrind for profiling)

2) measure/time your code : I use linux/c this code for duration, gnu scientific library (libgsl) for related math. Check out chrono for c++ and/or google benchmark for a complete framework.

3) as mentioned above warm up the cpu with your code before measuring by running your code a large number of times. Measure the execution time average of a large number of runs. Ideally your measure is good when results have “normal” distribution. Narrow the code you measure until you get normal distributed results.