The best tool for a balanced life is the clock. Like a hunter’s dog, the clock will be your best ally. It will guard you, keep your impulses in check, and protect what’s important to you. Schedule everything to ensure balance of your time and effort. Scheduling prevents procrastination, distraction, and obsession. A schedule makes you act according to the goals of your highest self, not your passing mood.
Как стать новым человеком? В первую очередь нужно думать. Думать, думать и думать.
Every programmer’s been there, you’ve grown as a developer because you wrote code and somehow managed to wrestle your chaotic thoughts into something coherent. But here’s the kicker: why stop at code? Writing articles or other works takes those same brain-boosting benefits and lets them spill over into the rest of your life. It’s about organizing chaos, finding clarity, and creating something functional, elegant, and, dare I say, beautiful, for yourself and for others who will eventually read or use what you've created.
Why you need your own company We all need a place to play. Kids need playgrounds and sandboxes. Musicians need an instrument. Mad scientists need a laboratory. Those of us with business ideas? We need a company. Not for the money, but because it’s our place to experiment, create, and turn thoughts into reality. We need to pursue our intrinsic motivation. We have so many interesting ideas and theories. We need to try them! The happiest people are not lounging on beaches. They’re engaged in interesting work! Following curiosity is much more fun than being idle. Even if you never have to work a day in your life. That’s the best reason to have a company. It’s your playground, your instrument, your laboratory. It’s your place to play! Get the ideas out of your head and into the world.
When you sign up to run a marathon, you don’t want a taxi to take you to the finish line.
https://www.lua.org/doc/cola.pdf
Nice
In the middle of the journey of our life I found myself within a dark woods where the straight way was lost. Dante Alighieri, Inferno
https://www.lua.org/doc/jucs05.pdf
🫥
Four Cut Sunflowers, 1887 by Vincent Van Gogh
Sony C60 Cassette Tape
https://erlang.org/download/armstrong_thesis_2003.pdf
Tempelhof Airport, Berlin, 1987
one two three ... infinity
Sharp MZ-700 (1984)
- “медитируйте, или не медитируйте, но найдите способ вникнуть в происходящее, не цепляйтесь за него, не отпирайтесь от него”, будьте здоровы
got it
finish line
/|\
Tiki-100
generator_a
.zip(generator_b)
.take(5_000_000)
.map(|(a, b)| ((a ^ b) & 0xFFFF == 0) as usize)
.sum()
Columbo
dream
Lorem Gibson Shibuya assault kanji knife fetishism nano- neon. crypto- A.I. man city corrupted A.I. rain. tank-traps network digital advert uplink free-market garage. BASE jump plastic bicycle narrative singularity free-market pen. nano- range-rover euro-pop RAF plastic warehouse cyber-. car Chiba hotdog tube pistol Kowloon corrupted. dolphin RAF man artisanal nano- bomb uplink.
NASA
repeat
https://github.com/aldanor/aoc-2021 https://en.wikipedia.org/wiki/Hacker's_Delight https://github.com/astral-sh/uv/pull/13469
Keypro II, 1982
Epson HX-20
yeah
Schneider CPC 464
hehe
IBM Selectric I
Arts_et_Metiers_Pascaline_dsc03869.jpg
DEC Digital VT100
Connection Machine (1985)
The idea of balancing a search tree is due to Adel’son-Vel’skiĭ and Landis, who introduced a class of balanced search trees called AVL trees in 1962. Another class of search trees, called 2-3 trees, was introduced by J. E. Hopcroft in 1970. A 2-3 tree maintains balance by manipulating the degrees of nodes in the tree. Bayer and McCreight later generalized 2-3 trees to form B-trees. Red-black trees were invented by Bayer under the name symmetric binary B-trees. Guibas and Sedgewick studied their properties in detail and introduced the red/black color convention. Andersson proposed a simpler-to-code variant of red-black trees, which Weiss later called AA-trees. An AA-tree is similar to a red-black tree except that left children may never be red. Treaps were proposed by Seidel and Aragon. They became the default implementation of a dictionary in LEDA, a well-known collection of data structures and algorithms. Other variations on balanced binary trees include weight-balanced trees, k-neighbor trees, and scapegoat trees. One of the most intriguing is the splay tree introduced by Sleator and Tarjan, which is self-adjusting. Splay trees maintain balance without any explicit balance conditions. Instead, splay operations involving rotations are performed within the tree every time an access is made. The amortized cost of each operation on an n-node tree is logarithmic. Skip lists provide an alternative to balanced binary trees. A skip list is a linked list augmented with additional pointers, allowing dictionary operations to run in expected logarithmic time.
reasonable
Lana_Del_Rey_Cannes_2012.jpg Elizabeth Woolridge Grant
macro_rules! box_it {
($value:literal) => {
Box::new($value)
};
}
fn main() {
let stuff = box_it!("hello, world");
println!("{stuff:?}");
}
fn main() {
println!("hello, world");
}
N.Wirth. Algorithms and Data Structures. Oberon version Harold Abelson, Gerald Jay Sussman, Julie Sussman. Structure and Interpretation of Computer Programs
ken-and-den.jpeg
«Мы постоянно меняемся и очень важно помнить о том, что ты был положительным персонажем» Бараш
First, we want to establish the idea that a computer language is not just a way of getting a computer to perform operations but rather that it is a novel formal medium for expressing ideas about methodology. Thus, programs must be written for people to read, and only incidentally for machines to execute. Second, we believe that the essential material to be addressed by a subject at this level is not the syntax of particular programming-language constructs, nor clever algorithms for computing particular functions efficiently, nor even the mathematical analysis of algorithms and the foundations of computing, but rather the techniques used to control the intellectual complexity of large software systems.
Start ridiculously small (a single pushup or one minute of meditation) Attach new behaviors to existing routines (meditate after brushing teeth) Celebrate immediate small wins to reinforce the behavior Focus on consistency rather than perfection Design your environment to make good habits easier and bad habits harder
Cultivating positive habits provides a powerful mechanism for life improvement. Regular exercise represents a classic example—initially challenging to establish but relatively easy to maintain once integrated into your routine. This principle applies equally to reading, writing, meditation, or other beneficial practices. With exercise specifically, I personally reject the concept of scheduled rest days because they tend to multiply into extended inactivity periods. Instead, I find daily movement more sustainable, even if it’s minimal, adjusting intensity according to energy levels and recovery needs.
This book is dedicated, in respect and admiration, to the spirit that lives in the computer. ``I think that it's extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customers got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don't think we are. I think we're responsible for stretching them, setting them off in new directions, and keeping fun in the house. I hope the field of computer science never loses its sense of fun. Above all, I hope we don't become missionaries. Don't feel as if you're Bible salesmen. The world has too many of those already. What you know about computing other people will learn. Don't feel as if the key to successful computing is only in your hands. What's in your hands, I think and hope, is intelligence: the ability to see the machine as more than when you were first led up to it, that you can make it more.'' Alan J. Perlis (April 1, 1922-February 7, 1990)
Wega
IBM System/360
Embrace object-oriented patterns for organization. For organizing larger parts of your application, consider object-oriented constructs. Using structs or enums can encapsulate related data and functions, providing a clear structure without worrying about the details. Leverage functional patterns for data transformations. Especially within smaller scopes like functions and closures, functional methods such as mapping, filtering, or reducing can make your code both concise and clear. Use functional programming when you can phrase your problem as a series of transformations over some data.} Use imperative style for granular control. In scenarios where you’re working close to the hardware, or when you need explicit step-by-step execution, the imperative style is often a necessity. It allows for precise control over operations, especially with mutable data. This style can be particularly useful in performance-critical sections or when interfacing with external systems where exact sequencing matters. However, always weigh its performance gains against potential readability trade-offs. If possible, encapsulate imperative code within a limited scope. Prioritize readability and maintainability. Regardless of your chosen paradigm, always write code that’s straightforward and easy to maintain. It benefits not only your future self, but also your colleagues who might work on the same codebase. Avoid premature optimization. Don’t prematurely optimize for performance at the cost of readability. The real bottleneck might be elsewhere. Measure first, then optimize. Elegant solutions can be turned into fast ones, but the reverse is not always true.
«Как правило, одиночество вокруг нас — это плод нашего воображения, а на самом деле жизнь вокруг нас бьет ключом, в ожидании когда мы вольемся в её шумный поток» КарКарыч
108. Проектируйте структуры данных в последнюю очередь. Добавление полей данных выполняется в процессе проектирования в последнюю очередь. Другими словами, после того, как вы разработали сообщения, вам нужно понять, как реализовать возможности, запрашиваемые этими сообщениями. Вероятно, это труднейшая часть процесса объектно-ориентированного проектирования для структурного программиста: заставить себя не думать о лежащей в основе структуре данных до тех пор, пока не будет готовы полностью система обмена сообщениями и иерархия классов. В этот момент процесса проектирования вы также добавляете закрытые (private) "рабочие" (или "вспомогательные") функции, которые помогают обработчикам сообщений справиться со своей работой.
Still, the history of mainstream programming languages is essentially a story of programmers vocally and emphatically rejecting what eventually proved to be some of the most incredibly successful innovations in the history of the field. Assembly programmers largely laughed at FORTRAN, but just a few decades later, there were nevertheless very few remaining assembly programmers. First-class functions were widely derided as needlessly complicated and confusing until programmers were forced to finally take the time to learn to use them once JavaScript became a load-bearing language by historical accident, and within a decade, they became a required feature for every major programming system. Sophisticated type systems largely retain a perception of overengineered, ivory-tower elitism, but many of the programmers who hold those very opinions have enthusiastically adopted Rust, a language that features a type system so complex that idiomatic Rust code can easily put Haskell programs to shame.
The essential, most stubborn problems in programming languages come from unavoidable tensions between conflicting desires and requirements. We want loosely coupled software components that can be easily reused, but we also want the performance benefits of tight coupling and specialization. We want flexible programming languages that do not impose upon our freedom of expression, but we also want the benefits of static program analysis and powerful safety guarantees. We want sophisticated type systems that allow specifying ever more complex invariants, but we also want readable type signatures that won’t regularly end up longer than the code itself.
https://en.wikipedia.org/wiki/Sales_(band)
Functional programming allows a programmer to express ideas in an inherently mathematical way. This makes FP great for things like mathematical proofs, or great for people with a mathematical background who struggle to think like a programmer. It also simplifies code - if I'm reading a function with zero side-effects, or zero mutation of some data structure, then I can very clearly see the input, transformation and output. This style of function should be prioritised where appropriate, even in a procedural language like C. Reducing cognitive load for a programmer is clearly a bonus.
The difference may not seem drastic, but the compounding performance returns will be vital in applications like simulations, games, and real-time systems where each CPU cycle is gold-dust, and each cache miss a deterrent to having a great product. So, in a well-written program, an engineer may make use of SoA for field-wise operations, and AoS for entity-wise operations.
Feeling stronger
$ python benchpop.py Size: 1000 - With: 0.0015s, 10318 comps | Without: 0.0018s, 16850 comps Size: 2000 - With: 0.0048s, 22672 comps | Without: 0.0042s, 37745 comps Size: 5000 - With: 0.0110s, 63319 comps | Without: 0.0120s, 107652 comps Size: 10000 - With: 0.0206s, 136634 comps | Without: 0.0276s, 235294 comps Size: 20000 - With: 0.0454s, 293288 comps | Without: 0.0583s, 510657 comps Oh, there it is. 🙄
$ python bench.py With siftdown inlined: 3.995546 seconds, Comparisons: 1648612 Without siftdown: 3.329431 seconds, Comparisons: 1882563 🫣
$ python bench.py With _siftdown: 6.305621 seconds, Comparisons: 1649692 Without _siftdown: 5.422437 seconds, Comparisons: 1880839 🤔
I am confused. 🧠
Ok, chat. Write a python script that must benchmark some code.We will benchmark two slightly different implementations of the heap data structure. In Python. As reference we will take heapq.py module of the Python standart library which contains this code def _siftup(heap, pos): endpos = len(heap) startpos = pos newitem = heap[pos] # Bubble up the smaller child until hitting a leaf. childpos = 2*pos + 1 # leftmost child position while childpos < endpos: # Set childpos to index of smaller child. rightpos = childpos + 1 if rightpos < endpos and not heap[childpos] < heap[rightpos]: childpos = rightpos # Move the smaller child up. heap[pos] = heap[childpos] pos = childpos childpos = 2*pos + 1 # The leaf at pos is empty now. Put newitem there, and bubble it up # to its final resting place (by sifting its parents down). heap[pos] = newitem _siftdown(heap, startpos, pos) There is possible another implemetations of siftup routine, withou calling _siftdown function. We need just on each iteration compare if value at pos index is bigger than children. If not we must break the loop, stop iteration. Create two functions to heapify list, one using siftup which breaks the loop, another one using snippet I gave. Timeit and benchmark the best way possible agains both implementations, format the out put. give me the script https://github.com/fuzz88/rust_stuff/blob/master/heap/bench.py fuzz@workstation:~/code/rust_stuff/heap$ python bench.py Heapify Performance Comparison (10 runs on list of 10,000 items): With _siftdown: 0.030211 seconds Without _siftdown: 0.011579 seconds Result: Alternative implementation without _siftdown is faster. 🫠
Yeah. I guess swapping two elements of slice is just faster than assigning one to another through = and pointing this values by index. No matter how many compare operations we can avoid.
Ok, here is the trick in Python's heap structure implementation that allows us to cut amount of comparison when sifting up items in the heap. https://github.com/python/cpython/blob/3.13/Lib/heapq.py#L278 We don't compare parent value with the children when sifting it up, assuming that item which is taken from the leaf will end up somewhere near the leaf. The idea (D.Knuth, Art of Programming, Volume 3) is to sift item through smallest of the children (and shifting smallest child towards the root on each step) to the leaf without swapping it in a process, then assign it to the leaf, and then sift it down to the proper place. Doing it this way must reduce amount of "compare" operations, because sifting item down to it place from the leaf is shorter path than the sifting it up to its location towards the leaf. It is low price to don't stop ("break" the loop) on proper location, but go down to the leaf with low cost operations and then go a little bit up comparing values. I know I have formulated this idea twice already. :-) Here is the third time: we make long path cheaper, according the heuristics about nature of the value we are sifting through the heap. Now, here is my research. I had wrote a little bit of code in Rust, playing with the heap. I am 37 years old programmer, but never played with the heap data structure. Oh, boy, brothers. Just having some fun here. And I've tested and benchmarked some code. And... idk, but my benchmarks in Rust said that "non-optimized" version when we swapping items towards the leaf and breaking the loop when we arrived is faster. Is this compiler optimizations? Some low-level stuff? I am not really into that. Maybe I made a mistake. https://github.com/fuzz88/rust_stuff/blob/master/heap/src/main.rs#L73 test tests::bench_heapify_not_optimized ... bench: 2,796.01 ns/iter (+/- 54.45) test tests::bench_heapify_optimized ... bench: 6,668.45 ns/iter (+/- 182.72) Just a memo to myself: benchmark critical parts, make decisions based on the data. Or just use "good enough" stuff for the task. I will call it a day.
"Be patient. Your future will come to you and lie down at your feet like a dog who knows and likes you no matter what you are."
...And Justice for All (1979)
What is good style? Good style in any language consists of code that is: Understandable Reusable Extensible Efficient Easy to develop and debug It also helps ensure correctness, robustness, and compatibility. Maxims of good style are: Be explicit Be specific Be concise Be consistent Be helpful (anticipate the reader's needs) Be conventional (don't be obscure) Build abstractions at a usable level Allow tools to interact (referential transparency) Know the context when reading code: Who wrote it and when? What were the business needs? What other factors contributed to the design decisions?