Edgars Brokans’ Post

"Functions Are Objects: A Gentle Introduction to Functional Programming - Stanley Okonkwo You may be hearing a lot about functional programming lately; contrary to popular trends, it is one of the oldest programming paradigms around, being an application of the lambda calculus by Alonzo Church (of the Church-Turing hypothesis), with the discovery of the Y-combinator by Haskell B. Curry (who has a programming language for every name he has). It is also perhaps a little unintuitive if you are a self-taught programmer or perhaps a little alien if you are used to mathematical functions, but don't worry, it is, in my opinion, simpler than object orientation, and way more fun. A few terms to help us here with functional programming: Variables declared in a function signature are called "bound variables," and variables declared inside a block are called "free variables": def fn(a, b): c = a + b d = a  a In the example above, a and b are bound variables where c and d are free variables. This helps distinguish between what variables are in the mechanism of calling a function and which are used in implementing the function. Functions, as they relate to functional programming, are special because… They are not special! They behave just like any other object with properties and can be passed around as other objects, like lists, dictionaries, or numbers can be. To prove that functions are objects, like lists or dictionaries, you can assign properties to functions! >>> def my_function(): ...      return 'Hello world' ... >>> my_function.data = 'I bet no one will go looking for this!' >>> my_function.data 'I bet no one will go looking for this!' >>> print(my_function.data) I bet no one will go looking for this! >>> print(my_function()) Hello world The Journey Ahead Functional programming isn't just a trend; it's a fundamental way of thinking about code that has stood the test of time. Whether you're working with Python, JavaScript, Haskell, or any modern language, understanding functional concepts will make you a better programmer.

Some notes on "modern C++". The C++ programming language was first released in 1985. There have been multiple updates to it that are labeled by the year, C++03, C++14, C++20, etc. With a few tiny exceptions, a newer compiler that defaults to a newer version of C++ will still compile code written based on the original release. Some of the additions to C++ have been things every code could benefit from. An example is RAII (Resource Acquisition Is Initialization), which prevents memory leaks. The big change in C++ over the years is the ability to make template libraries and a rich set of template library functionality that comes with C++. Templates are generic functions. For example, numeric functions where you write one function and it automatically converts to float, double, or integer data types. Many of the additions to C++ have been designed for writing template libraries. Along with the changes to the language, we have gotten changes to the way books recommend using the language which are called "Modern C++". Modern C++ coding styles typically utilize features in C++14. Modern C++ coding style relies heavily on using the included template libraries, and writing code like it were a template library. I recently looked at a piece of open source scientific simulation software that was heavily templated. Much of their coding style didn't give any benefit to their purpose of writing good simulation software, and indeed made the code harder to follow and modify. It had more complex syntax and layers of code. This is a coding style I call "smart but not wise". Unfortunately, some books on C++ are written assuming everyone is writing template libraries. These books don't show wise choices for writing applications software using C++. Part of good software development is making wise choices for your application, not just copy and pasting examples designed for a different type of software.

Agentic coding (read: "vibecoding") becomes easier to digest once you think of it as a higher-level programming language. C was an abstraction of assembly and sped up development times by some amount. Then higher-level languages like C++, Rust, Javascript, Python etc. came along as an even higher-level abstraction that sped up development times. At each level, you are writing out the exact specification of the program you want to build. And with each increasing level, you are able to omit more and more details from those specifications. Instead of writing out every single machine code the cpu has to run, you write out variables and functions. Then instead of writing out variables and functions, you write out classes and methods. Then LLMs came in and gave an even higher level of abstraction that nobody anticipated would exist. Now instead of writing out classes and methods, you write out natural language that specifies the behavior and logic of your program. The better your specification is defined, the better your program will be. This is true even at all layers of abstraction. Agentic coding tools are just compilers for a new type of programming language, but they're not built to be used that way. Planning out and writing detailed specifications in the terminal and in markdown files everywhere feel clunky and messy and everyone has their own opinions on what the best workflow is.

people are still very uncreative imo when it comes to building vibecoding tools. the most they can think of is connecting the agent to their phone or some other mobile device. it's still the same clunky experience, just from a different device. what we need is a higher-level DSL for writing requirements for an agent to build. pair that with an LSP that highlights each requirement based on its completion. how the agent turns those requirements into code and how the LSP derives completion progress from the code is an implementation detail. been thinking a lot about this, I might just build it out myself.

🔹 Big Ideas in Programming Languages – Understanding How Languages Shape the Way We Think & Code --- • Programming Languages (PLs) are not just tools to instruct computers; they are powerful mediums for expressing ideas, logic, and problem-solving approaches. This document explains how different programming languages evolved and why new languages keep emerging to solve modern challenges. • It highlights the core components of programming languages—syntax (structure), semantics (meaning), and pragmatics (implementation). These define how programs are written, interpreted, and executed efficiently. • The content explains static and dynamic semantics, showing how errors, types, and program behavior are analyzed before and during execution. This helps developers write safer and more reliable programs. • A major focus is on programming paradigms such as imperative, functional, object-oriented, and logic-based programming, emphasizing that modern languages often combine multiple paradigms for flexibility. • The document also introduces metaprogramming, interpreters, compilers, and language translation concepts, explaining how programming languages are built on top of each other. • Finally, it explains why studying programming languages is important—to become better problem solvers, understand software design deeply, and choose the right language for the right task. ✅ Overall, this content builds a strong foundation for understanding how programming languages influence software development, thinking patterns, and system design.

Back then, "real programming" was synonymous with lower-level languages such as Assembly, or even C, C++, Java; tools that demanded a deep grasp of memory management, performance tuning, and machine-level fundamentals. JavaScript, by contrast, was viewed as a high-level scripting language intentionally designed with a very low barrier to entry. It allowed non-specialist developers to add interactivity to pages without needing to manage pointers, compilation steps, or low-level resource control. For many experienced engineers, it felt too far removed from the underlying machinery to be considered "real programming", and it was more of an accessible layer for quick enhancements than a "real" engineering discipline. Yet that very abstraction and accessibility became its greatest advantage. By eliminating much of the low-level complexity and friction, JavaScript let people focus on higher-order concerns: responding to user interactions in real time, composing dynamic experiences, and iterating on complex applications at a pace that was simply impractical in more rigid, lower-level environments. Over time, the problems worth solving expanded dramatically in scope and ambition, making JavaScript not just viable, but essential. Programming languages themselves carried the prestige and mystique back then that AI holds now. Assembly was once considered essential knowledge for any serious developer. Today, very few of us touch it regularly, not because we became worse engineers, but because the problems we solve and the systems we build have moved to entirely new layers of abstraction. The real shift isn't that some technology "killed" programming. The change is in the nature and scale of what we can (and need to) build. AI is doing the same. It won't eliminate programming. It will redefine what counts as fundamentals in this era, and it will dramatically expand what individuals and small teams can realistically create. The skill ceiling isn't disappearing; it's moving upward. The barrier to building ambitious, meaningful things is dropping again.

“Coding is to programming what typing is to writing.” — Leslie Lamport When I programmed LEGO robots as a kid, my goal wasn’t to write code. It was to make the robot move. Later, building an online magazine, I learned PHP, HTML, CSS. Again, the goal wasn’t syntax. It was to publish content, shape structure, tell a story. The PHP was just the ink; the magazine was the message. Coding was just typing. Programming is closer to writing a book: you start with an idea, then chapters, then structure, and only then the words. Small tasks are short stories. Bigger ones become novels. Whole systems? Books with multiple authors. Understand what you want to build. What story the system should tell. How data flows between chapters. After that, coding is the easy part.

So, you wanna know the hilarious story of how programming came to be? It's crazy. Then, out of nowhere, we got the number 1 - and later, 0. People thought these numbers were pretty useless, to be honest. But then, electricity happened - and it was like a switch flipped, literally. It's all about being ON or OFF, which is basically like 1 or 0. This combo created the binary system, and computers were all about voltage, not words - it's like they spoke a different language. A single binary digit is called a bit, by the way. Bits make a byte, and a byte can represent numbers from 0 to 255 - it's like a secret code. In the early days, computers used vacuum tubes and punch cards, which sounds like something out of a sci-fi movie. Programming was done using pure 0s and 1s, which was super difficult and error-prone - like trying to solve a puzzle blindfolded. Then, assembly language came along, using human-readable mnemonics - it was a game-changer. It was still hardware dependent, but way easier than machine code - like the difference between a map and a GPS. Next up, compilers and high-level languages were created, and it was like a whole new world opened up. A compiler converts readable code into machine code, so programmers never have to deal with machine code again - it's like having a personal translator. Some of the first high-level languages were FORTRAN for scientific computing, and COBOL for business and government systems - they were like the pioneers of the programming world. LISP introduced new ideas like lists and garbage collection, which was pretty revolutionary. Structured programming focused on readable and maintainable code - it's like building a house, you want it to be sturdy and easy to navigate. The C language was fast and powerful, with direct access to memory - it was like a sports car. It was used to build operating systems like UNIX, which is still around today. C++ added object-oriented programming concepts like classes and objects, and it was like a whole new level of programming was unlocked. This led to a language boom, with BASIC, Pascal, Ada, Erlang, and Smalltalk - it was like a programming party. And then, Python came along, which is readable and uses indentation - it's like the programming equivalent of a warm hug. Innovation and creativity were key to the development of these programming languages, and strategy played a big role in their implementation. So, that's the humorous history of programming in a nutshell - it's been a wild ride. https://lnkd.in/gGvevan2 https://t.me/GyaanSetuAi #ProgrammingHistory #Innovation #Creativity #Strategy #Tech

I have read the book "Asynchronous Programming in Python" by Nicolas Bohorquez, and I can recommend it to those who want to expand or enhance their toolset for working with asynchronous programming. The book starts by introducing operating system fundamentals, threads, and scheduling, and only then moves on to coroutines and event loops. It clearly explains ideas like concurrency vs. parallelism, blocking vs. non-blocking I/O, or why async does not magically speed up CPU-bound code. The best thing about this book is that the author uses fun, real-world problems as examples: distance calculations, web scrapers, protocol implementations, graph-based datasets, and even agent-based simulations. These examples demonstrate the performance trade-offs, especially when using modern tools and libraries. I especially enjoyed the following parts: contrasting synchronous and asynchronous execution using sports metaphors (chess vs. soccer); explaining "embarrassingly parallel workloads"; web-scraping the characters of "My Little Pony"; working with the graph of etymology data and visualizing it. I had the most fun with the Boltzmann Wealth Model simulating the weight inequality, as I'm an economist by education. The only downside I can mention is that the book covers "too much" - there are many domains and libraries (some niche). As I'm not a Python developer (but just an MLE), I sometimes felt lost and a bit overwhelmed. Overall, this is a modern book aimed at intermediate Python developers who already know the basics and want to learn more about async behavior. It does a great job explaining not just how to write asynchronous code, but when it actually makes sense and when it does not. It provides theoretical explanations, practical advice, and modern tools. It can help you prepare for the actual state of asynchronous programming. It's currently available at 9.99 $ on packt's site for a limited time: https://lnkd.in/dXYhnhNQ

Why I’m ditching traditional coding methods for Java 8 Streams. Coding can feel tedious. The endless loops. The endless lines of code. But what if I told you there’s a better way? Java 8 Streams changed everything for me. Imagine handling collections like never before. Filtering, mapping, and reducing with ease. Each operation flows smoothly, like music. Here’s why I’m sold: 1. 𝗟𝗲𝘀𝘀 𝗕𝗼𝗶𝗹𝗲𝗿𝗽𝗹𝗮𝘁𝗲: Goodbye clutter. Less code means fewer bugs. More focus on what truly matters. 2. 𝗥𝗲𝗮𝗱𝗮𝗯𝗶𝗹𝗶𝘁𝘆: Your teammates will thank you. Code that reads like a story. Collaboration becomes a breeze. 3. 𝗣𝗮𝗿𝗮𝗹𝗹𝗲𝗹 𝗣𝗿𝗼𝗰𝗲𝘀𝘀𝗶𝗻𝗴: Why settle for one core when you can use them all? Streams let you leverage multi-core architectures effortlessly. Speed and performance? Yes, please. 4. 𝗟𝗮𝘇𝘆 𝗘𝘃𝗮𝗹𝘂𝗮𝘁𝗶𝗼𝗻: Only compute what you need. No more unnecessary processing. Efficiency at its finest. 5. 𝗙𝘂𝗻𝗰𝘁𝗶𝗼𝗻𝗮𝗹 𝗣𝗮𝗿𝗮𝗱𝗶𝗴𝗺: It’s a mindset shift. Write code that captures intent. Say goodbye to side effects and embrace purity. When I discovered Streams, I felt like I had unearthed a hidden gem. No longer bound by old practices. Are you ready to transform your coding experience? With more productivity, better collaboration, and cleaner code? Take the leap. Explore Streams today. You won’t regret it. Drop a comment if you’ve tried Java Streams, or send me a DM to dive deeper!