Alperen Keles

On The Simplicity of Humanness

2026-04-13T00:00:00+00:00

Just yesterday, Bryan Cantrill published a short piece that touches something that I think most of us fundamentally understand, but don't have the words. The article is very short, titled "The peril of laziness lost"</a>. I recommend you all read it. I plucked out one sentence for you:

The problem is that LLMs inherently lack the virtue of laziness. </blockquote>
The essence is, our laziness is the reason we engineer simple systems. LLMs lack this laziness, which results in the fact that they don't have the incentive or the process to simplify, given that we don't externally create such mechanisms. That is why Anthropic had to introduce a separate command (/simplify</code>) to enable such post hoc simplification process.
The thing that touches me the most about this idea is that I have been frequently amazed by the simplicity of human-engineered artifacts. All the algorithms I've ever read seemed simple, perhaps too simple in hindsight. All the codebases, even the gigantic ones, can be broken into simpler modules, sections, abstractions, hierarchies that allow us to understand the system. A great deal of modern advances in computing are due to simplification, malloc made memory allocation simpler, structured programming made control flow simpler, Rust made memory management simpler, typically via removal of our mental burdens.
It's not just computer science, all human-engineered systems are simple, for a very specific meaning of the word; as opposed to emerging structures such as social relationships or physical world that just is, or evolution that just happens. One may object that a plane, or Linux kernel, or the lithography machine of ASML is very complex, and they would be right. But all of those systems can be broken into smaller modules, subsystems, abstractions that allow for understanding them. I can say this confidently without having a concrete idea of what those systems are and how they work, because I believe in a fundamental principle of engineering, we must be able to maintain the systems we build.
When something goes wrong in a system, we must be able to locate where it is, understand the root cause of the problem, make changes in a way that are isolated without regressing on other parts of the system, and validate that the change correctly fixed our problem. Nature has the luxury to simply not care, things break, systems fail, earthquakes happen, it's all part of the plan.
There are escape hatches to this simplicity, complexities that we do not need to understand, when there's an asymmetric relationship between the process and the verification of the result. This has been long known and applied in the field of automated theorem proving, thede Bruijn Criterion</a> separates the proof object, the proof checker, and the proof producer from each other. We must only understand and trust the proof checker, the proof objects themselves are irrelevant for the purposes of understanding the system. Although the generated proofs are irrelevant, I argue that the same engineering principles still apply to the proof producing programs, just not their results. A SAT solver possesses humanness, but the proofs it produces will not. A genetic algorithm possesses the humanness, but its artifact, such as AlphaZero, is akin to a biological organism that we must try to understand and model. We still care about understanding such results, because they allow us to improve on the engineering artifacts that produce them, as well as the outputs themselves, but we can bear not to.
LLMs do not possess the humanness right now, they probably will never do, just as AlphaZero doesn't. This doesn't make their outputs useless, but rather a new challenge we must overcome. In highly verifiable domains</a>, such as translation</a> or optimization</a>, we will continue to see them in high, sometimes autonomous capacities. In other domains, we will find a way to push their limits</a>. We will build more and more tools for analyzing and understanding programs that we previously did not need to, not because we couldn't, but because such understanding now gives us a great deal of leverage</a>.
I didn't really know what I wanted to say when starting to write this one, I do that sometimes. Now that I'm concluding, I am searching for a conclusion, here it is; we are driven to understand the systems we build and maintain, and we find ways to do so. We were able to analyze the world, figure out the rules of the universe, model the human genome to its molecules that we didn't even know existed. I don't think that was primarily due to laziness, but rather the drive to build better, larger, greater systems; and I think we'll find a way to mold the LLM outputs into forms that we can understand too.
Thanks Bryan for lighting a spark that led me to write this, I hope you have enjoyed reading this as much as I did writing.

What is a property? 2026-04-05T00:00:00+00:00 When talking about Property-Based Testing, we typically talk in very abstract terms. There are properties, which define the correctness; there are generators, which define the domain; the PBT framework gives us APIs for writing property-based tests that combine the properties with the generators to find bugs. It's all very nice and simple. A (surprisingly) large chunk of my time goes into exploring different PBT frameworks, many times porting an existing PBT workload to use a new one instead of the other. This requires me to build abstractions on what a PBT framework is, which should have been very easy if the simple definition I gave in the first paragraph captured what PBT is. Unfortunately it doesn't, so let's see what the issue is. A property is a universally quantified computation that must hold for all possible inputs. The simplest model of a property in a programming language is a function that returns a boolean, such as the one below: property :: a -> Bool </code></pre> For instance, \l -> reverse (reverse l) == l</code> is a property, it asserts double reversion leads to the original list. This gets slightly complicated with preconditions, which are rules that state if an input is valid or not. So we can write things like: data Database = ... execute :: Database -> Query -> Database query :: Database -> Query -> [[Value]] (==>) :: Bool -> Bool -> Maybe Bool (==>) precondition property = if precondition then Just property else Nothing prop_insert_select :: Database -> String -> [Value] -> Maybe Bool prop_insert_select db table values = let insert = Insert table values select = Select table "*" in hasTable db table ==> (values `elem` query (execute db insert) select) </code></pre> Where ==></code> is the implication operator, which states that if the precondition (the left-hand side) is not satisfied, then the property cannot be tested. In our case, the precondition is hasTable db table</code>, which checks if the database has the specified table. If it doesn't, then we don't care about the result, we just discard it. If the database has the table, then we execute the insert and check if the select query returns the values we inserted. Now that we have a property at hand, we need some random generators for it. We can write Arbitrary</code> instances for all the input types and let QuickCheck handle the rest. data Value = Number Int | String String | ... instance Arbitrary Value where arbitrary = oneof [Number <$> arbitrary, String <$> arbitrary, ...] instance Arbitrary Database where arbitrary = ... </code></pre> Well, not really. When we write these instances, what do you think QuickCheck does? It generates a random database, a random string, a list of random Value</code>s, and then runs the prop_insert_select</code> function. In what percent of cases do you think a random string is a valid table name that exists in the database? What we want is a dependent generator, where some values can depend on the others: -- Randomly generate a table genTable :: Gen Table genTable = ... tableName :: Table -> String tableName = ... genValuesFor :: Database -> String -> Gen [Value] genValuesFor db table = ... gen :: Gen (Database, String, [Value]) gen = do -- Decide how many tables we want to create numTables <- choose (1, 10) -- Randomly generate the tables tables <- vectorOf numTables genTable -- Create an empty database let db0 = emptyDatabase -- Populate the database with the generated tables let db = foldl createTable db0 tables -- Now we can generate a valid table name and values let tableNames = map tableName tables table <- elements tableNames values <- genValuesFor db table return (db, table, values) </code></pre> Now we don't need to worry about the precondition failure because the inputs are valid by construction. The table is selected from the already existing list of tables in the database, so it will never fail. How do we run the tests? Here's a conceptual API for it: quickCheck :: Gen t -> (t -> Maybe Bool) -> Int -> Gen (Maybe t) quickCheck gen property n = if n == 0 then pure Nothing else do -- Generate a random input using the provided generator input <- gen -- Check the property with the generated input case property input of -- Test passed, generate another input Just True -> quickCheck gen property (n - 1) -- Test failed, return the failing input Just False -> pure (Just input) -- Precondition not satisfied, generate another input Nothing -> quickCheck gen property (n - 1) </code></pre> This is not how QuickCheck actually works (for instance, it ignores shrinking and the actual test runner machinery), but the details of that are probably left best to another post, because I want to focus on something different. The fact that the generator is not independent from the property. To be fair, that is a common requirement, you cannot just randomly sample data in the hopes of running into interesting inputs, you need to be aware of the system under test. But we have a more pressing situation here, the generator runs computations that are seemingly not related to the random generation itself. The foldl createTable ...</code> call runs with the database to add the generated tables to it. This is in contrast to our usual mental model of a random generator which makes some random decisions to construct some datatype. Instead here, the Database</code> is too complex to generate from scratch, so we generate a really simple version and use its own API for constructing it. While we're at it, we could go even further. The generator already returns the (db, table)</code> pair, which then the property checks if hasTable db table</code> to detect validity. We know that for this specific generator, the db</code> always has the table</code>, so we can just remove it. For other generators, we could just add it as a check within the generator and make the generator partial instead of total, make the property total instead of partial. In the example below, the generator returns Gen (Maybe ...)</code> instead of plain Gen</code>, and the property returns Bool</code> instead of Maybe Bool</code> because the hasTable</code> check has moved into the generator. gen :: Gen (Maybe (Database, String, [Value])) gen = do db <- arbitrary :: Gen Database table <- arbitrary :: Gen String if hasTable db table then do values <- arbitrary :: Gen [Value] return $ Just (db, table, values) else return Nothing prop_insert_select :: (Database, String, [Value]) -> Bool prop_insert_select (db, table, values) = let insert = Insert table values select = Select table "*" in values `elem` query (execute db insert) select </code></pre> If we can move some part of the property into the generator, can't we do that with the rest? gen :: Gen (Maybe Bool) gen = do db <- arbitrary :: Gen Database table <- arbitrary :: Gen String if hasTable db table then do values <- arbitrary :: Gen [Value] let insert = Insert table values select = Select table "*" in return $ Just (values `elem` query (execute db insert) select) else return Nothing </code></pre> Voila, we're now back to the original property-only version of the code, only now we're in the generator land, so we can actually change the generation inline without separating it into two parts and rewriting something from scratch. QuickCheck already has support for this style of property-based test writing without making you write your property under Gen</code>: prop_insert_select :: Property prop_insert_select = forAll arbitrary $ \db -> forAll arbitrary $ \table -> hasTable db table ==> forAll arbitrary $ \values -> let insert = Insert table values select = Select table "*" in values `elem` query (execute db insert) select </code></pre> In this style, every forAll</code> combinator takes a generator and produces a context with access to the generated value, which while hiding the fact that you're working with generators, allow you to write dependent generators without hassle. Here, the property is not a function that returns a boolean, it's the test that captures the generation as well as the assertion. To be fair, nothing I wrote here is revolutionary, forAll</code> has been a part of QuickCheck for the past 26 years, every person writing PBTs is aware of the fact that property-based tests aren't properties and generators completely separated from each other, but rather a combination of the two. The Hypothesis intro</a> puts it especially well from a practical perspective: you write tests which should pass for all inputs in whatever range you describe, and let Hypothesis randomly choose which of those inputs to check </blockquote> Essentially, Property-Based Tests leverage properties as universally quantified statements about the program under test, but many times, they cannot use them without breaking the abstraction boundaries. Thinking about this is especially important as we implement libraries, for instance, the Rust port of Haskell's QuickCheck, quickcheck</a> gets the abstraction boundary wrong. Its quicktest</code> expects a Testable</code> instance, which has a function fn result(&self, _: &mut Gen) -> TestResult</code>. This instance is implemented for tuples of up to 8 elements as follows: impl<T: Testable, $($name: Arbitrary + Debug),*> Testable for fn($($name),*) -> T { #[allow(non_snake_case)] fn result(&self, g: &mut Gen) -> TestResult { let self_ = *self; let a: ($($name,)*) = Arbitrary::arbitrary(g); let ( $($name,)* ) = a.clone(); let mut r = safe(move || {self_($($name),*)}).result(g); if r.is_failure() { let mut a = a.shrink(); while let Some(t) = a.next() { let ($($name,)*) = t.clone(); let mut r_new = safe(move || {self_($($name),*)}).result(g); if r_new.is_failure() { { let ($(ref $name,)*) : ($($name,)*) = t; r_new.arguments = Some(debug_reprs(&[$($name),*])); } // The shrunk value *does* witness a failure, so remember // it for now r = r_new; // ... and switch over to that value, i.e. try to shrink // it further. a = t.shrink() } } } r } </code></pre> Where the line let a: ($($name,)*) = Arbitrary::arbitrary(g);</code> calls the arbitrary for the input tuple and passes it to the property that computes the result in let mut r = safe(move || {self_($($name),*)}).result(g);</code>. The design here assumes the exact boundary we just said was inadequate because computations might need to be interleaved with the generation. Proptest, as far as I can tell, makes the same decision. The comparison against QuickCheck</a> mentions differences that I personally do not find that much impactful, while not mentioning the capability that this blog post focuses on. The newly introduced Hegel</a> keeps the tc: TestCase</code> argument that allows for mixing generation with the test case that allows the original functionality in Haskell via a different mechanism that Hypothesis has been using for some time. The article wasn't really meant to lead to a particular result, but rather to explore what we need expressible in a PBT library in general. I hope it's been fun to read and insightful, if you have any objections, I would love to discuss them over at akeles@umd.edu</a>. My related work on the topic: Programmable Property-Based Testing </a> </li> Database-Integrated Random Testing </a> </li> </ul> Closing the verification loop: Observability-driven harnesses for building with agents 2026-03-09T00:00:00+00:00 This is a mirror entry of an article I co-authored published in Datadog AI Blog</a>. AI agents can now produce software faster than any team can verify it. The bottleneck has moved from writing code to trusting what was written. </blockquote> We have seen this pattern before. Early programmers resisted compilers because they could write better assembly by hand. Often they were right. Compilers earned trust because the languages they translate have precise semantics: The programmer defines what the program does; the compiler has freedom over how it is implemented. Automation has consistently won only when paired with verification. </blockquote> With AI agents, building trust is more challenging than in the case of compilers. AI agents ingest unrestricted natural language, sometimes from untrusted sources, and translate it into running code. We must find new ways to verify the outputs of these new program synthesis engines. </blockquote> Seeing types where others don't 2026-03-06T00:00:00+00:00 This is a mirror entry for my article published in The Consensus</a>. Welcome to a snapshot of my multi-year long journey of inferring types from jq programs in order to produce better, understandable errors messages. Programmers are peculiar people, they, actually we, develop odd affections to otherwise impersonal concepts, such as programming languages, such as types. I am guilty of this affection, I love my types. I love the ability to construct a concrete domain model, build relations between the types, and fearlessly refactor my code as I refine my domain model... Specifiability is the Leverage 2026-02-24T00:00:00+00:00 Almost a year ago, I wrote my first ever blog post on AI-assisted programming, Verifiability is the Limit</a>. The core idea was a push against the school of thought that AI-assisted programming would scale to an infinite productivity level, because someone had to verify that the outputs conform to the given specification, the prompt. I predicted that this had, and would, give rise to uneven levels of productivity in different domains; in UI development, it would make human-in-the-loop development much faster, because UIs are very easy to verify via looking, checking, inspecting the changes. If we could construct a perfect oracle, a computational verifier that has the ability to reject or accept any artifact produced by the model, we could get autonomous improvements comparable to those we got in games such as Chess or Go, which I've further explored in Breaking Verifiable Abstractions</a>, Test, don't (just) verify</a> and The Mechanics of Autonomous Software Translation</a>. This time, I've come back to reframe these ideas from a new lens, I don't know how useful these lenses are, perhaps both of them separately don't lend any usefulness to anyone, but if they are of interest to you, here's the thesis. The gap between the specification and the task is the leverage. There's an important component here, which is that this new thesis isn't really that different from how verifiability is the limit. Rather, instead of framing a limit based on the verifier, be it subjective personal judgement or a perfect computational oracle, it recognizes that the verifier is the specification. So, it gives us a tool to answer the question, "how much productivity gain can we get from using an LLM", which is that the difference in time to specify the task versus executing it. This is an upper limit to the productivity gain that we're far away from because these systems are far from perfect, they make mistakes, and we also make mistakes on how we think about specifying systems, so we've a lot to improve on. The rest of this post is talking about different domains, different ways to specify, how to gain leverage, how people have been gaining leverage, what are we still missing. The simplest form of specification is a reference. Imagine you take a screenshot of a webpage, and you ask the model to keep generating code until it recreates it. You gain immense leverage from this interaction, because you have left much of the specification of the details to your reference with a minimal requirement, the page must look the same. There are, however, millions of different ways to fulfill this request. For instance, nothing prevents the model from literally making the page a canvas and putting the picture there, objective achieved! That is probably not you want, you want a reasonable approximation of the screenshot in a usable manner. So something that looks like a button should probably be a button, something that resembles a textbox should be a text area, etc. You also want reasonable behavior on scrolling, resizing, reloading... You see how this is somehow damaging on the leverage, we started with a simple reference as the specification of what to generate, but we see that's not really enough, the specification is much more nuanced in practice. This isn't really a groundbreaking discovery, we started from a static 2D reference image, which captures (maybe) a moment in the life of a webpage, so the model has to infer, or guess, or ask, every decision beyond the reference. This isn't really so bad, because models are not blind followers of instructions, they generalize them in the context of training data. So when we ask the model to generate a webpage based on a screenshot, I am certain that it will not just print it on a canvas, it will infer that you want DOM elements organized in such a way that it resembles the screenshot, and that's a very nice behavior we certainly want when using the models, because if we wanted to be that precise, we lose the leverage we get by using a generative model of programming, at the limit without contextual inference, the specification can be equivalent to the implementation. In practice, we are advantageous in two ways. The first is, lots of times people don't have very specific requests. A simple book club app might be fine the way the model infers what it should be. The second is, we don't need have a precise specification in mind, we're using the model interactions as a way to iteratively refine the specification, as we would when developing without model assistance. We can even use the model to help us with the refinement, you can get the model to quiz you, ask you questions to refine the specification you gave, in order to produce software that is a better fit to your intent. You can, as is the typical development workflow, check the output to refine the specification by correcting a piece of it. You might've realized in the screenshot example that references themselves are not the specifications, they are anchors, targets to adhere to. We have to also specify the gadgets, the tools, the platform to produce the artifact to conform to the reference, which would be a standalone HTML page or a React application in the screenshot instance. In other instances we might specify using specific programming languages, testing strategies, implementation tricks, dependencies... The highest leverage, however, comes with the ability to remove the human from the loop. If we could only produce a computational verifier that completely specifies our program, we could just let the model evolve the program in an autonomous loop, I've outlined a rough economic function of the cost for such an autonomous loop in my latest post, The Mechanics of Autonomous Software Translation</a>: total cost ≈ (inference cost per iteration) × (expected iterations until “good enough”) + (harness engineering + oversight)</code> </blockquote> So, what is leverage? leverage ≈ traditional engineering cost - (harness engineering + oversight)</code> </blockquote> The leverage we acquire via generative programming is the effort we spend on building the harness and maintaining it subtracted from the total engineering effort we would have spent if we didn't have the computational verifier. What does the computational verifier look like? It's a random testing loop! Produce random inputs, pass them in the new and the old implementation, assert that their results are the same, or at least equivalent. We once again rely on the generalization capacities of the model here, trusting that it won't keep adding new if</code> statements for every single input it gets wrong until the testing loop is exhausted. Within this framework, we get increasingly higher leverage as models get better and harnesses are better engineered, we should get increasingly better results in translation. The current demos with the C Compiler</a>, the browser</a>, SimCity</a>, Javascript Compiler</a>, or the recent news of COBOL modernization</a> are the footsteps of what's to come, they mark what we can achieve with high leverage using these computational verifiers. Well then, we get to the gist of the important question. Where else do we have this type of leverage? A simple answer is, any domain or scenario you can construct robust, expressive, and extensive Property-Based Testing harnesses. The core idea of Property-Based Testing is, users write executable specifications using first order logic. Properties are universally quantified predicates that must hold true for any given input, and they are implemented as predicate functions from such inputs to booleans, letting the testing harness decide on how the inputs are produced. For instance, we can write and test the following properties in Python: Program translation: def translation_preserves_semantics(program: PythonProgram, input: Input): translated_program = translate_to_rust(program) return execute_python(program, input) == execute_rust(translated_program, input) </code></pre> Program optimization: def optimization_preserves_semantics(program: Program, input: Input): optimized_program = optimize(program) return execute(program, input) == execute(optimized_program, input) </code></pre> Preservation of momentum in physics simulations: def momentum_preservation(mass1: float, vel1: float, mass2: float, vel2: float): initial_momentum = mass1 * vel1 + mass2 * vel2 final_vel1, final_vel2 = simulate_collision(mass1, vel1, mass2, vel2) final_momentum = mass1 * final_vel1 + mass2 * final_vel2 return initial_momentum == final_momentum </code></pre> Serialization and deserialization consistency: def serialization_consistency(protobuf_message: ProtobufMessage): serialized = serialize(protobuf_message) deserialized = deserialize(serialized) return protobuf_message == deserialized </code></pre> All of these examples denote universal truths. A program optimizer must not change the output of any program for any input. A physics simulation must preserve the momentum for all possible physical worlds, a serialize/deserialize pair must not lose information for any type of message. Once we have such universal expectations about the implementations, it is possible that we no longer need to worry about the implementation. Write the specification, run sufficiently long random testing campaigns, keep feeding counterexamples back to the model until there are none. That would be hell of a way to develop software, but unfortunately real life is messier. None of the examples I gave are complete. Program optimization must not just preserve the semantics, it must also optimize the program. We tested momentum preservation with only two rigid bodies, but the simulation might have more. We made sure serializing and deserializing any protobuf message leads to the same message, but not that broken serialized messages could not be deserialized, or parsed, into the wrong messsage. We checked that the translations are functionally equivalent, but not that of compatible in memory usage or runtime performance; we also did not account for nondeterminism or concurrency that might not be well suited for random testing to test for. We have another way to check specifications, namely formal verification, but I will just name drop a previous blog post of mine, Test, don't (just) verify</a>, if anyone is interested in how and when LLM-assisted formal verification can and can't provide similar or even better leverage to random testing. So are we back to the beginning? Do we not get any leverage from the random tests, of course not! We must merely be very careful. As we move away from the implementation to the specification, we start to use the LLM as some kind of compiler</a>, we relinquish control of every detail we choose not to specify, or not to test for. This means the model has free reign to do as it pleases as long as the tests pass. Universally quantified properties aren't the only way to specify software at scale. Temporal logic formulas as in TLA+</a>, or the newly announced Bombadil</a> allow users to specify behavior of a program temporally, as formulas over traces of the program, reasoning if a property holds all the time, for all possible paths in the program; or that all paths in the program eventually lead to some supposed destination such as a cleanup routine. These types of specifications are especially crucial in distributed settings because many distributed algorithms as expressed as temporal logic formulas and proven in model checkers like TLA+. These formulas, unsurprisingly, have to be combined with finer level details we expect from the implementations too, after all, many concepts in theoretical computing such as eventuality have to be bounded by certain limits to be practical in real life settings. Let's talk about what I see we're still missing. For starters, we lack the expressivity in our specification languages to specify many useful aspects of the software. All of the harnesses people use in OpenEvolve</a> style systems are still programs, programs that are written as bespoke, potentially buggy specifications for evolving code for some metric. We talk about faster software without talking about the distribution of inputs, we talk about software security without talking about properly defining the threat model. We're also missing proper harnesses for autonomous programming. There are a multitude of impressive products such as Codex, Claude Code, Cursor, Open Code for programming via prompting, they take care of context management, tool calling, model selection, prompt caching, sandboxing, checkpointing and many other useful feature for AI-assisted programming, but I don't know of any such polished product for building fully autonomous loops. Last but not least, we are missing the mindset to look for the leverage. I don't see us identifying potential gaps to open up between the specification and the implementation and focusing on exploiting those gaps. It's not that there aren't people working on these problems, as I mentioned in my previous posts, BitsEvolve</a>, ShinkaEvolve</a>, ADRS</a>, Glia</a>, AlgoTune</a>, there are many people working on finding opportunities to produce autonomous tasks, but the leverage is still in the niche. If you have any comments, feedback, or (especially) criticisms, please feel free to reach out to me at akeles@umd.edu</a>, and share with others if you found this interesting. (I think this will be the last one of this line of posts, because I feel like I told all I wanted to say in this topic, wish me luck on getting back to writing about testing databases and type systems!) The Mechanics of Autonomous Software Translation 2026-02-11T00:00:00+00:00 2026 started with a boom of AI-assisted autonomous translations, on 14th of January, Cursor published their post on Scaling long-running autonomous coding</a> in which they created translations of a browser, Java LSP, Windows emulator and Excel. This was followed by an Anthropic post on Building a C compiler with a team of parallel Claudes</a>, which has only further fanned the flames of the hype. Both of these posts have garnered lots of positive attention but have failed to stand to the expectations of the demos, Cursor browser got lots of well-deserved critique, and people had their good laughs when the C compiler that could compile the Linux kernel failed on a Hello World example. I view both of these as initial attempts at translating production grade software products using an immature translation engine, and getting broken results. It seems from a speculative point of view that the models are capable enough to do this translation, so my position is that the translation harnesses themselves aren't good enough, or the total budget required is much higher. I'll go into the economics of translation in the translation as a function of money</a> section. To make my position clear, I think we'll get better and better demos of these autonomous translations throughout 2026, and maybe even have some decent autonomous translation products by the end of the year. This article starts with a technical dive into how these translations even work in How does AI translate software?</a>, followed by my personal analysis of the question of "is translation capability really useful, and if yes, how so?" in How can we derive value out of translations?</a>. In the next frontier</a> I'll start making some more predictions, and finish with a discussion of a world where ubiquitous translation of software is possible. How does AI translate software?</a></h2> I should start this section with a disclaimer to its title, AI currently does not translate software. If AI translated software, it would be like waving a magic wand, we would say "give me a Rust version of Doom", and voila, we would get one. What instead happens right now is, people use LLMs as neural search engines, AI proposes translations, which are then rejected by a translation harness, a concrete evaluator that decides if the translation has succeeded or not, that is designed by a human, in these cases experts that understand the mistakes LLMs make, and know how to create a robust testing loop with continuous improvements. This may change in the future where the harnesses themselves good enough for translation are written by the models, which is I think the point where the terminology should shift, not at this point in the history. The fundamental current change is that these translations are now economically viable because of the model capabilities. I feel the need to say this because whenever one of these translations drop to the timeline, the vendors hype it up to suggest this indicates a larger ability in the context of software engineering, which I fully disagree. As such, let's build a very dumb translation loop without LLMs: def translate(source_code): while True: # Randomly generate some strings target_code = "".join(random.choices(string.ascii_letters + string.digits, k=random.randint(1, 1000000))) equivalent = True for i in range(1000): # Randomly generate some bytes test_case = random.randbytes(random.randint(1, 1000000)) if run(source_code, test_case) != run(target_code, test_case): equivalent = False break if equivalent: return target_code </code></pre> There's a very cool mathematical theorem in combinatorics that is called the infinite monkey theorem</a>, which states that a monkey hitting keys at random on a typewriter keyboard for an infinite amount of time will almost surely type any given text, such as the complete works of William Shakespeare. We don't really care about Shakespeare's complete works right now, but we might care about translating an old COBOL software into Java without changing its semantics, so it would be immensely useful if we had these infinite monkeys with some infinite time at hour hands to produce modern Java equivalents of some old COBOL programs. Translation as a function of money</a></h3> While we don't have infinite randomized labor coupled with infinite time, we have something that comes close to it, we have AI models that can generate code that are astonishingly good at following instructions. These models unsurprisingly cost a decent amount of money to run, but they make it so that we can now sample from a much better distribution of possible translations than was previously possible. We can even guide this sampling by augmenting our instructions with feedback from the testing harness, so the suggestions of the model is self-improving within this translation loop. We can modularize the software into multiple units or modules, each of which is separately validated, which means that the doesn't even have to generate the whole thing, it can generate each smaller unit and compose the whole thing together. There's an economic balance here: translation cost ≈ (cost per iteration) × (expected iterations until “good enough”) + (harness engineering + oversight)</code> </blockquote> As models and harnesses get better, the expected number of iterations to reach equivalence do and will get lower, and assuming that the cost to generation itself doesn't increase too much, we should expect the cost of translation to drop significantly, expecting to see many more of these results. There are two significant developments from the model side here, one is that they are getting better at following specifications, the two is that they are getting better at being in the control plane. In addition to doing the translations themselves, we can trust the model to make better judgements within the harness such as invoking subagents to translate a logical module and producing a smaller random test for it, essentially letting the model dictate how much of the translation is successfully completed. I'm not aware of any current demos that are doing this, but I would also expect this to happen. Verifying Translations</a></h3> The loop we saw at the beginning of the section is a differential test, where two systems must be observable equivalent. It's the most popular form of Property-Based Testing in software engineering, because it is one of the simplest properties we can express about a piece of software. Traditionally it's used for validating ports across languages (translations), refactors, optimizations, and there's an even interesting method of software development where when implementing a new system, you first build a model, a naive, simpler version that defines the observable correct behavior of the system is, and use that to test your production grade system that can be much more complex. Testing researchers have been using differential tests to find bugs in compilers, databases, browsers and many other types of software for many years, and now differential testing is becoming mainstream thanks to its ability to produce shiny demos for new AI models. There's a larger technical debate here, which is what does it mean for a translation to be correct, because observable equivalence is my definition is doing a heavy lifting. What do we observe to make it equivalent? Test cases! So the strength of the test case generation directly affects the strength of the equivalence we can ensure. There are some important ramifications of this, one is namely that our translations are laser focused on functional equivalence because that's the easiest to test for, and fails to account for equivalence in performance, equivalence in security, equivalence in any scenario we cannot test our systems for. For any sufficiently complex language, be it C, Rust, SQL or Brainfuck, it's impossible to produce all possible inputs to the system, so we must do the next best thing and try to reach as many states of the underlying system as possible. I suspect a large part of the bottleneck of the translations today is how we generate the test cases, how much of the system we are able to test quickly enough, and how much information are we able to give back to the model as feedback when there's an equivalence failure, how easy it is to localize failures, how much time is spent on tracing the root cause of each failure, how much of the token budget are we spending that we could just solve with other, much faster techniques. There is another large debate, which is that is this really useful? Let's say the model is able generate a browser from scratch, a GCC equivalent, or rather it really just replicates any software with the same exact input output structure across language ecosystems, how much value do we produce here? What good is it to produce translations across languages? How can we derive value out of translations?</a></h2> The answer here isn't really obvious. Let's say we have a perfect translator from JavaScript to Rust, and we give it the following JavaScript program: function add(a, b) { return a + b; } </code></pre> Here's a potential Rust translation of it: fn add(a: i32, b: i32) -> i32 { a + b } </code></pre> Of course this is completely wrong, because we are translating a JavaScript function, which can take any JS object, so the correct translation would be something like: enum JsValue { Number(f64), String(String), Object(HashMap<String, JsValue>), // and so on for all JS types } fn add(a: JsValue, b: JsValue) -> JsValue { match (a, b) { (JsValue::Number(x), JsValue::Number(y)) => JsValue::Number(x + y), (JsValue::String(x), JsValue::String(y)) => JsValue::String(x + &y), (JsValue::Number(x), JsValue::String(y)) => if let Ok(y_num) = y.parse::<f64>() { JsValue::Number(x + y_num) } else { JsValue::String(x.to_string() + &y) }, // handle other cases and type coercions _ => panic!("TypeError: Invalid types for addition"), } } </code></pre> There's immensely less value in this translation compared to the previous one, because staying true to the semantics without any type of restriction on the existing types hardly produces readable, maintainable, or faster code. This is more true for translation of libraries where input types are necessarily host language objects, so making a strictly equivalent translation gives us very little wiggle room. On the other hand, if we are translating an application, we have much more freedom to change the underlying types as long as the public interface, which is usually a simpler object model we can easily serialize and deserialize, is preserved. Therefore, it is in my opinion more possible to make an application more readable, maintainable, or faster via translation as opposed to libraries. Another point we can derive value is platform dependence. For instance, on web, we could only run JavaScript as a scripting language for a while, although nowadays WASM is changing this, but if it had not, we could use translation to run arbitrary languages on the web, as older symbolic translation methods such as ghcjs, emscripten had done. This type of platform dependence also exists in other ecosystems such as smaller embedded devices, where we might want to run a Rust application in a language that Rust compilation isn't yet possible; or moving out of a dying ecosystem such as COBOL, where it's very hard to find developers, or the language doesn't evolve with modern hardware to take advantage, so moving to a modern language with an active ecosystem can be a huge win. The next frontier, optimization</a></h2> Translation has emerged as a powerful use case for LLMs due to its convenience in testability, so it's natural to ask what's next? If we master translation, what would be the next emerging capability? I view optimization as a natural next step after translation because (1) it already includes a valid translation as its requirement, so it isn't surprising we haven't seen much advances on it without mastering translation first; (2) there are forms of optimization that are as easily tested as translation even though optimization is much more nuanced. The simplest form of optimization is a dominant optimization, where the new program is strictly better than the old one across all dimensions, for all possible inputs. This type of optimization is typically possible by doing less, meaning we remove allocations, extra pointer chasing via indirections, push ifs up and loops down to make our programs do less work. Given a program where it's possible to have such optimizations, we can once again treat the model as a neural search engine that proposes possibly optimized programs we can reject via benchmarks with little changes to the testing harness we had for translations. There are other forms of optimization that aren't necessarily dominant, these might be optimizing for specific types of known input distributions or focusing on absolute wins where making a small input run on 2x is deemed less important than making a very large input run on 0.9x time. I think for these types of optimizations it's harder to automate the harnesses as it requires subjective judgement on the acceptable bounds on different input types and distributions. We are already seeing examples of these, I myself have worked on one we called BitsEvolve Datadog</a>, there is ShinkaEvolve</a> by Sakana, Algotune</a>, ADRS</a>, Glia</a> and a bunch more I probably have been missing on. Can we copy behind closed windows?</a></h2> A futuristic application going forward in this technology is not just translating open source applications we have unlimited access to with the ability to run hundreds of millions of side by side equivalence tests, but rather reconstruct existing closed source software, perhaps even behind servers we have limited access to. This would be possible by essentially building a mirror model of the state machine implemented by the server that is refined across time as assumptions of the mirror model is broken. I wonder what this would do to the existing SaaS ecosystem, what does on choose to build when it's possible to build autonomous copies of simpler architectures, how do businesses defend their competitive advantage... Future of programming languages</a></h2> I wrote a bit earlier that translation between languages themselves isn't straightforward because faithful translations can be hardly useful. There's a bit of intellectual dishonesty here, because such as translation also gives us the ability to specify types of the software too. We can take programs that are initially too liberal with their types and progressively cut down those overly permissive types into simpler forms, just as how the V8 JIT compiler dynamically computes when JavaScript function types can be pruned and simplified based on existing input profiles. Our translation units also don't have to be aligned at functions, which might again force us to use patterns that are at a disadvantage in one language but useful in the other, such as memory management patterns in C that isn't expressible in safe Rust, but could have been avoided if we draw the translation unit at a higher point in the code. In an environment we are able to do such translations, what would we do? Which types of languages would become more likely translation sources, which would become more likely translation targets? What kind of properties of existing programming languages would shine in this ecosystem, which would become obsolete? I would like to think that, in such a scenario, we would look for more declarative, but precisely specified paradigms as opposed to natural language that I outlined the problems in my last post</a> where I talk about the topic of LLMs as compilers. Instead of picking a specific implementation of a map, we could define an abstract map object that upholds certain properties; similar for sets, lists, queues, heaps... Given the ability to translate at will, we could conjure programs that conform to these declarative specs which we can refine in time, taking back the control we relinquish whenever necessary. LLMs could be, but shouldn't be compilers 2026-02-06T00:00:00+00:00 I’ve been going round and round in my mind about a particular discussion around LLMs: are they really similar to compilers? Are we headed toward a world where people don’t look at the underlying code for their programs? People have been making versions of this argument since Andrej Karpathy’s “English is the hottest new programming language.” Computer science has been advancing language design by building higher and higher level languages; this is the latest iteration: maybe we no longer need a separate language to express ourselves to machines; we can just use our native tongues (let alone English). My stance has been pretty rigid for some time: LLMs hallucinate, so they aren’t reliable building blocks. If you can’t rely on the translation step, you can’t treat it as a serious abstraction layer because it provides no stable guarantees about the underlying system. As models get better, hallucinations become less central (even though models still make plenty of mistakes). Lately I’ve been thinking about a different question: imagine an LLM that never “hallucinates” in the usual sense, one that reliably produces some plausible implementation of what you asked. Would that make it the next generation of compiler? And what would that mean for programming and software engineering in general? This post is my stab at that question. The core of my argument is simple: Specifying systems is hard; and we are lazy. </blockquote> Before getting to what that means in practice, I want to pin down something else: what does it mean for a language to be “higher level”? Programming is, at a fundamental level, the act of making a computer do something. Computers are very dumb from the point of view of a human. You need to tell the computer exactly what to do, there's no inference. A computer fundamentally doesn't even have the notion of a value, type, concept; everything is a series of bits, which are processed to generate other bits, we bring meaning to this whole ordeal. Very early on, people have started by building arithmetic and logical instructions into computers, you would have 2 different bit sequences each denoting a number, you could add, subtract, multiply them. In order to make a computer do something, you could denote your data in terms of a bunch of numbers, map your logical operations onto those ALU instructions, and interpret the result in your domain at the end. Then, you can define a bunch of operations on your domain, which will be compiled down to those smaller ALU instructions, and voila, you have a compiler at hand. This compiler is, admittedly, kind of redundant. It doesn't do anything you would be able to do because you essentially have a direct mapping between your two languages, your higher level language desugars into a bunch of lower level ALU instructions, so anyone would be able to implement the same mapping very easily, and even go further, perhaps just write the ALU instructions themselves. What real higher level languages do is they give you an entirely new language that is eventually mapped to the underlying instruction set in non-trivial mechanisms in order to reduce the mental complexity on the side of the programmer. For instance, instruction sets do not have the concept of variables, nor loops, nor data structures. You can definitely build a sequence of instructions that amount to a binary search tree, but the mental burden of the process is orders of magnitude higher than any classic programming language. Structs, Enums, Classes, Loops, Conditionals, Exceptions, Variables, Functions are all properties that exist in higher level languages that are compiled away when going down the stack. There's a crucial aspect of compilation, which is that the programmer gives away some control, that's essentially what removes the mental burden. If a programming language doesn't give away any control, it arguably isn't a very useful abstraction layer, because it did not absolve you of any responsibility that comes with that control. One of the first examples of this type of control we gave away is code layout. If you are writing handwritten assembly, you control where the code lives in the program memory. When you go into a language with structured control flow with callable procedures, you now don't have exact control over when the instructions for a particular piece of code is fetched, how basic blocks are arranged in the memory. Other examples are more common, the runtime of a language works in the background to absolve you of other responsibilities such as manual memory management, which itself was an abstraction for automatically managing how your data is organized in memory in the first place. This loss of control raises a question: how do we know the abstraction is implemented correctly? More importantly, what does it mean for an abstraction to be correct? There are a few layers to the answer. First, mature abstractions are defined against some semantics: what behaviors are allowed, what behaviors are forbidden, and what guarantees you’re meant to rely on. In C, malloc</code> gives you a pointer to a block of memory of at least the requested size (or NULL</code>), suitably aligned, which you may later free</code>. It doesn’t give you “exclusive ownership” in the language-theoretic sense, but it does define a contract you can program against. Second, we validate implementations with testing (and sometimes proofs), because these guarantees are at least in principle checkable. Third, in practice, guarantees are contextual: most programs care that allocation works; only some care deeply about allocator performance, fragmentation behavior, or contention, those are the cases where people swap allocators or drop down a level. This highlights a critical point: abstraction guarantees aren’t uniform; they’re contextual. Most of the time, that contextuality is dominated by functional correctness: “does it do what it says?” Programming languages made enormous progress by giving us abstractions whose functional behavior can be specified precisely and tested relentlessly. We can act as if push/pop on a Python list has the same semantics as a vector in C++ even when the underlying implementation differs wildly across languages and runtimes. LLM-based programming challenges this domination because the “language” (natural language) doesn’t come with precise semantics. That makes it much harder to even state what functional correctness should mean without building a validation/verification suite around it (tests, types, contracts, formal specs). This gets to my core point. What changes with LLMs isn’t primarily nondeterminism, unpredictability, or hallucination. It’s that the programming interface is functionally underspecified by default. Natural language leaves gaps; many distinct programs can satisfy the same prompt. The LLM must fill those gaps. Just as a garbage-collected runtime takes control over how and when memory is reclaimed, “programming in English” relinquishes control over which exact program gets built to fulfill your requirements. The underspecification forces the model to guess the data model, edge cases, error behavior, security posture, performance tradeoffs in your program, analogous to how an allocator chooses an allocation strategy. This creates quite a novel danger in how we write programs. Humans have always written vague requirements; that part isn’t new. What’s new is how directly an LLM can turn vagueness into running code, inviting us to outsource functional precision itself. We can leave meaningful behavioral choices to a generator and only react to the outcome. If you say “give me a note-taking app,” you’re not describing one program, you’re describing a huge space of programs. The LLM can return one of a billion “reasonable” implementations: something Notion-like, Evernote-like, Apple Notes-like, or something novel. The danger is that “reasonable” choices can still be wrong for your intent, and you won’t notice which commitments got made until later. This pushes development toward an iterative refinement loop: write an imprecise spec, get one of the possible implementations, inspect it, refine the spec, repeat until you’re satisfied. In this mode, you become more like a consumer selecting from generated artifacts than a producer deliberately constructing one. And you also lose something subtle: when you hand-build, the “space of possibilities” is explored through design decisions you’re forced to confront. With a magic genie, those decisions get made for you; you only see the surface of what you ended up with. I don’t think this point is widely internalized yet: hallucinations aren’t the only problem. Even in a hallucination-free world, the ability to take the easy way out on specification plays into a dangerously lazy part of the mind. You can see it in the semi-conscious slips (I’m guilty too): accept-all-edits, “one more prompt and it’ll be fine,” and slow drifting into software you don’t really understand. That’s why I think the will to specify is going to become increasingly important. We already see LLMs shine when they’re given concrete constraints: optimization, refactors, translations, migrations, tasks that used to be so labor-intensive we’d laugh at the timeline, become feasible when the target behavior is well specified and backed by robust test suites. It’s been true for a long time that specifying a piece of software is often harder than building it. But we may be entering a world where: if you can specify, you can build. If that’s right, then specification and verification become the bottleneck</a>, and therefore the core skill. This isn’t my most polished post, but I wanted to get the idea out. I do think it’s possible to treat LLMs as compiler-like, in the loose sense that they translate a specification into an executable artifact. But the control we relinquish to that translation layer is larger than it has ever been. Traditional compilers reduce the need to stare at lower layers by replacing low-level control with defined semantics and testable guarantees. LLMs also reduce the need to read source code in many contexts, but the control you lose isn’t naturally bounded by a formal language definition. You can lose control all the way into becoming a consumer of software you meant to produce, and it’s frighteningly easy to accept that drift without noticing. So: I don’t think we should fully accept the compiler analogy without qualification. As LLMs become a central toolchain component, we’ll need ways to strengthen the will to specify, and to make specification and verification feel as “normal” as writing code used to. Test, don't (just) verify 2025-12-22T00:00:00+00:00 AI is making formal verification go mainstream. AI-assisted mechnical proving companies are raising funds on billion dollar valuations</a>, new people are trying proof assistants, overwhelmingly Lean, at unprecedented rates. Models achieve fascinating results in competitions previously considered to contain some of the hardest problems in the world, such as IMO, ICPC, Putnam; as well as open problems in mathematics such as Erdös Problems. It's not just the hobbyists that are excited about AI-assisted proofs, from Terry Tao</a>, to Martin Kleppman</a>, to Ilya Sergey</a>, prominent researchers around the world are excited and hopeful about the effects. Formal Verification: The Goods</a></h2> Let me quickly give you a run down of the argument: There are multiple complex challenges in formal verification. The first one, and the one that is very hard to solve technically, is that most software in the world does not have a formal specification. A formal specification is a simpler mathematical description of the system we build. Algorithms have formal specifications. Data structures, protocols, data formats, safety-critical systems typically have formal specifications. The majority of the programs in the world doesn't have a formal specification, hell, most of them don't even have informal specifications. At the limit, which is where we actually are, the specification of a program is itself, the implementation is the specification. The lack of a formal specification makes it very hard to formally verify some piece of software, because what would you even verify? The second issue is, proof engineering, the practice of writing proofs for theorems about your systems, is very hard. The proofs have many domain specific elements to them, a proof of a mathematical theorem will be very different from a proof about a programming language, and a proof about the programming language will highly depend on the underlying constructs of its theoretical framework. The widest taught proof engineering book is Software Foundations</a>, and every chapter has a different style of proofs. Someone that went through Volume 2: Programming Language Foundations will not find the problems in Volume 6: Separation Logic Foundations intuitive or obvious. There are other problems such as the tooling for proof automation, brittleness of proofs, reusability of proofs etc. but I don't find them particularly fundamental to proof engineering itself but rather problems of the current generation, so we can leave those aside for now. The rise of LLMs in programming vastly affects both of these points. It affects point number 1 because AI-assisted programming is a very natural fit fot specification-driven development. AI-assisted programming pushes the limits of programming from what you can implement to what you can specify and what you can verify</a>. This is a great incentive for writing executable specifications, because then you can put the LLM inside a loop until it achieves the said objective, irrespective of the means of the achievement. I predict that</a> this will give rise to program optimizers and translators that will be transformative of our work in those domains. However, tests are, as infamously they are, incomplete. Tests are great at finding bugs (actually they are not so great most of the time, but that's another discussion), but they cannot prove the absence of bugs. SQLite famously has millions of tests, but researchers still find bugs in SQLite, similar situations arise in almost all software. The only way to prove the absence of bugs is formal verification, and industry has seen great examples of this. Highly cited formal verification projects include CompCert C Compiler, the random testing of which against GCC and Clang</a> has led to finding 79 bugs in GCC and 202 bugs in Clang, and only 2 bugs in CompCert in its unverified parser, finding no bugs in its verified compilation pass, a striking win for formal verification. (Thanks to A. Jesse Jiryu Davis</a> informing me, I learned that researchers have studied</a> the source of failures in formally verified distributed systems, and found that wrong assumptions about the unverified parts of the system are the likely culprit.) This makes formal verification a prime target for AI-assisted programming. Given that we have a formal specification, we can just let the machine wander around for hours, days, even weeks. If it comes back with a solution, we shall trust not to the probabilistic predictions of the so-called artificial intelligence, but the symbolic proof checker that verifies the solution. This idea has always been at the core of formal verification, the ability to have unsound proof generation coupled with sound proof checking has given rise to complex tactics, algorithms that produce proofs by searching them, to enable proof engineers in great capacity. This is not the end of the good news. AI is also very good at writing proofs, at least much better than the average software engineer. Given that we have a perfect oracle, we can also turn the problem into an RLVR (Reinforcement Learning with Verifiable Rewards), which means we should expect the models to get even better at it as time goes on as they did in chess, go, and many other similar problems. This is the promise behind the billion dollar valuations, the companies started with impressive autoformalization techniques and automated provers for tackling competition problems and open conjectures, but the real industrial value is at the core of automating software engineering by letting the engineer write a verbal description, autoformalized into a Lean theorem, proven by the automated prover, and voila, we have our program that we can fully trust. or do we? Formal Verification: The Bads</a></h2> I see the appeal, I like the idea, I trust the researchers building these systems, but I don't love the overarching promises. This blog post is my attempt at building a reasonable middle ground by laying out the goods (as I already did), and the bads (as I now will), and make my closing remarks by reiterating the position of testing in this space, and in the future. Autoformalization is a shaky ground</a></h3> I started this post by stating most programs in the world do not have formal specifications, followed by how AI is incentivizing us to write specifications, and autoformalization takes the specifications, and makes them formal. In formal verification, there's this concept of a trusted computing base (TCB). TCB is your Achilles' Heel, it's the bottom of the ladder, where layers over layers of verification is built on, trusting a small core without verifying it, because there must be a bottom of the ladder, we cannot build a circular verification argument, and the system cannot verify itself. (please fact check me on this if I'm wrong, which is possible) Autoformalization is part of the TCB in this AI-assisted verified programming paradigm, because one cannot mechanically verify that the verbally stated specification indeed corresponds to the formalized one. There are several modes of usage, one issue is soundness, there might be mechanically verified scenarios that would be rejected by the verbal specification. Another issue is completeness, the formalized model might reject valid scenarios in our descriptions. Autoformalization part of the process requires and deserves our special attention as it's one of the crucial points of failure in this verification process. Proof assistants are slow</a></h3> In a proof assistant, the primary goal is reasoning about programs and ease of verification. For instance, proof assistants, traditionally, don't use our classic two's complement integers packed into words in our memory, they use Peano numbers, an encoding of natural numbers as inductive data structures: Inductive Nat : Type := | zero : Nat | succ : Nat -> Nat. </code></pre> This encoding doesn't possess the concept of an integer overflow. Its inductive structure allows us to build theorems that hold for all natural numbers, not just the ones that can fit in a word. It is also painfully slow, the computational complexity of a + b</code>, an operation so fast in CPU that it's literally an instant, is O(a + b)</code>, addition is linear in time to the added values instead of a constant operation. However, we would like to run verified code on real life workloads, so we cannot wait for a million cycles to add 1M + 1M = 2M. There are 2 solutions to this problem, the first one is that you build a more efficient encoding in the proof assistant, prove equivalence of the efficient but hard to reason encoding to the inefficient but simpler to reason one, and use the efficient one in your computations. The other is once again, axiomatization, or broadening the TCB. Proof assistants offer a mechanism called extraction that allows for extracting a piece of code in the language of the proof assistant (e.g Rocq) to a language with a larger ecosystem optimized for running production workloads (e.g OCaml). Much of the extraction is a one-to-one correspondence between the languages via syntactic transformations, but we can hijack the extraction to axiomatize our own types. We can turn Nat into unsigned integers, where Nat.add</code> becomes u64 + u64</code>. For instance, in Rocq, Nats are extracted to BigInts, which should have the same semantics, but the "should" in this sentence carries the heavyweight. Without an accompanying proof of correctness, we just put BigInt into the TCB. Without broadening the TCB, the speed of a proof assistant will be limited by the large amount of pointer chasing that arises naturally with the use of inductive types and their tree-inducing characteristics. There are many domains in which speed isn't that big of a deal, but I think there's also a concern between speed and the requirement for correctness, as faster code tends to involve more complex language constructs such as concurrency, bit manipulation, layout awareness, which leads to more bugs than their simpler counterparts. If we cannot reason about programs that are more likely to have bugs, how much of the overarching problem are we tackling? Verification requires models, and models are very hard to come by</a></h3> In order to verify some property of a system, one needs a model of the system. These models don't grow on trees, they are crafted by domain experts over a number of years. People have been building models for programs with pointers (separation logic), as well as programs with concurrency, programs with randomness, programs with algebraic effects, and perhaps many more that I haven't even heard of. In proving a property of the system, we need a foundation for our reasoning process, which these theories give us for their respective domains. However, there are many domains we don't have good models for, one example is runtime performance. This has been a contentious issue in the computer science curriculum, the asymptotic complexity does not translate to program behavior in real hardware. Modern CPUs have cache lines, speculative execution, branch prediction that makes the plain old abstract machine used in asymptotical analysis obsolete for many scenarios. We do not even have a single hardware to conform our model to, we have tens of different configurations of hardware, each of which will give different results in our measurements. If we tried to prove that some piece of code has a better result for a specific memory/processor pair than another one, we would have a massive job on our hands, I personally don't even know where I would start with. Contrast this to testing, where you can just spin up the same algorithm on both machines, run our benchmarks, which will be our final ground truth. Testing is almost universally considered inferior to formal verification, it is what you do when you don't have the resources to justify verification, because if you had the opportunity to spend the time, proving absence of bugs, or universal facts about your system, would be much more valuable than codifiying the results of singular measurements. I am here to tell you that there are tests we can write that could not be formally verified, because while building the underlying models for verification might be hard, just using the real hardware for our measurements can be much easier. Verification doesn't tell you that you are going down the wrong path</a></h3> In games, there are clear winners and losers. In verification, you can prove that your theorem is correct, you can prove that your theorem is incorrect, but absence of a proof for a theorem does not imply that the theorem is incorrect, it is possible that you just haven't found the proof. This means the feedback you get when writing a proof is limited as you cannot rely on your inability to progress as a signal about your theorem, it is plausible that you are the problem. This is why QuickChick, a testing tool descending from the famous QuickCheck of Haskell that introduced Property-Based Testing to the world, exists in Rocq ecosystem as one of the three most popular packages. If verification was strictly superior to testing, QuickChick would have no reason to exist, but it serves a very crucial role that the verification process needs, falsification. I had said that the absence of a proof does not imply that a theorem is wrong, but the witness of a violation of the theorem definitely does. Random testing is the prime suspect for finding such counterexamples, pulling the verifier out of the rabbit hole of going through many useless paths in the proof search before giving up, because the theorem is ultimately wrong, there is no proof to be found. Random Testing and Formal Verification</a></h2> I have given examples of tests that formal verification is incapable of modeling, and examples of tests that complement formal verification process by creating a short that falsifies false theorems instead of trying to prove them in vain. The synergy between testing and formal verification doesn't end here, I am a firm supporter of Verification-Guided Development (VGD)</a>, which in addition to leveraging this synergy, solves the problem of proof assistants being too slow. In verification guided development, we implement two versions of the same system, one is the simpler to reason, verified version, the other is the complex, production one. We then test the property that the production system conforms to the reference implementation that is verified by running them with the same inputs and asserting that the result is the same every single time. VGD lifts the proof to the production implementation from the slower one implemented in the proof assistant by leveraging differential random testing, which allows for building a best-of-both-worlds system that is both correct and fast. Below is an image taken from the paper</a> that (as far as I know) introduced the notion of VGD, explaining their workflow. VGD doesn't solve all the issues I mention in the rest of the post, but it removes the slowness out of the mix. As we have a production implementation ready to be tested thoroughly, we can make all kinds of measurements that fall out of the purview of verification, but into the realm of testing. It levels the playing field between the verified realm of computing and the unverified one, reducing the downsides of the verification leveraging testing. Closing Remarks</a></h2> I would like to state it once more for everyone: I see the appeal, I like the idea, I trust the researchers building these systems, but I don't love the overarching promises. This blog post is my attempt at building a reasonable middle ground by laying out the goods, and the bads, and make my closing remarks by reiterating the position of testing in this space, and in the future. I believe random testing plays as important of a role as formal verification in the future of software engineering. We will not have magically formally verified systems in many domains, but as autoformalization tools get better, we will have many, many more formal specifications. Random testing benefits from these formal specifications in different ways than formal verification, but both have their places. Proof systems will be incomplete without the accompanying testing tools, and the testing tools will be incomplete without proofs of correctness, it is only possible via some combination of verification and testing that we can achieve our ideals of the future of software engineering, live in a world where bugs are considered anomalies instead of the norm, where correctness is a virtue, and the bugs in our systems are as old and as forgotten as the diseases we learned to cure and put away. Formal Metotlar ve Kanıtlı Programlama Hakkında 2025-12-18T00:00:00+00:00 Hatalar, günümüzde programlamanın ve yazılım mühendisliğinin ayrılmaz bir parçası. Yazdığımız programlarda hatalar olacağını, bu hataların kaçınılmaz olduğunu, bu kaçınılmazlığın değiştirilemez olduğunu kabul ediyoruz, programlama etrafındaki kültürü bu şekilde geliştirdik. Linux Kernel'ından kullandığımız tarayıcılara, tarayıcılarda ziyaret ettiğimiz web sitelerine, bu sitelerin mobil uygulamalarına kullandığımız her yazılım ürününde hataların olmasını bekliyoruz. Diğer yanda, bilgisayar bilimlerinin niş bir köşesinde formal metotlar adında, yazdığımız programların doğruluğunu arttırmak ve geliştirmek üzerine kurulu bir alan var. Formal metotlar, programlama dillerinin ve onları kullanarak yazdığımız programların teorisini ve anlamını inceleyen, yeri geldiğinde programlarımızı analiz ederek onlardaki hataları keşfedebilen, yeri geldiğinde bizim amaçlarımıza uygun programları sentezleyen, yeri geldiğinde ise yazdığımız programlarda hiçbir hata olmadığını matematiksel olarak kanıtlayabilen metotlar. Bu yazıda bunların sonuncusundan, yazdığımız programların doğruluğunu kanıtlayabildiğimiz yöntemlerden, teknolojilerden, programlama dillerinden bahsedeceğim. Buna girmeden önce, bu yazının neden bugünün bağlamında önemli olduğuna dair küçük bir dipnot açayım: Formal metotlar ve kanıtlı programlama, tarihin çok büyük bir kısmında kullanım olarak zor ve niş bir pozisyonda kaldı. Bugün bu alanlarla uğraşan insanları incelediğinizde belki %90'ının akademik ortamlarda, akademik projelerde bununla uğraştığını görebilirsiniz. Bugün, bu gerçekliğin hızla değişebileceği bir ortama giriyoruz, Martin Kleppman'ın geçtiğimiz hafta "Yapay Zeka Formal Doğrulamayı Anaakım Hale Getirecek"</a> yazısıyla, kanıtlı programlama yapabildiğimiz Lean programlama dilinde yapay zekayla matematik kanıtlama üzerine ürünler geliştiren Harmonic</a>, Axiom</a>, Nous</a> gibi girişimlerin yaygınlaşmasıyla, Claude Code</a>, Kiro</a> gibi yapay zeka destekli kod editörlerinin hafif formal metotlar (lightweight formal methods) adıyla anılan Property-Based Testing özelliğini eklemesiyle, yapay zekanın ürettiği kodları doğrulama probleminin</a> çözümüne giden yolun formal metotlar olduğuna dair ciddi belirtiler görüyoruz. Ben şahsen bu gidişatın devam edeceğine, ve kanıtlama programlamanın önemli bir rol oynayacağına inanıyorum, o yüzden bugün formal metotları ana akıma taşımak her zamankinden daha kolay, ve belki de her zamankinden daha değerli. Basit Gözüken Programların Tehlikelerine Bir Örnek</a></h2> Programlama dillerindeki numerik tipler (int</code>, uint</code>, float</code>, double</code>, number</code>) programlamaya başladığımız günden itibaren elimizin altında olan yapılar. Doğal sayılarla yapılacak işlemleri int</code>/uint</code> gibi tamsayı ve doğal sayıları temsil eden tiplerle, reel ya da rasyonel sayılarla yapılacak işlemleri ise float</code>/double</code> (bundan sonra Javascript'teki versiyonuna sadık kalarak number</code> diyeceğim) tipleriyle yapıyoruz. Bu tipler, her ne kadar matematiksel objeleri temsil etmede kullanılsa da o objelerin tüm özelliklerine sahip değiller. Bunun en klasik örneklerinden birisi number</code> tipinin toplamada alttaki reel sayıdan beklenmeyen sonuçlar üretmesi. 0.1 + 0.2 === 0.3 // false 0.1 + 0.2 // 0.30000000000000004 </code></pre> Bu örnekte matematiksel olarak 0.1 + 0.2 = 0.3</code> olmasını beklerken, modern bilgisayarların kullandığı IEEE-754 Floating Point standardı beklediğimiz sonuca yakın, ancak farklı bir çıktı veriyor. Bu çok da büyük bir problem değil gibi gözükebilir, daha ciddi bir sıkıntıyı inceleyelim. Klasik, okul yıllarında ilk yazdığımız algoritmalardan birini, İkili Aramayı (Binary Search) inceleyelim: public static int binarySearch(int[] a, int key) { int low = 0; int high = a.length - 1; while (low <= high) { int mid = (low + high) / 2; int midVal = a[mid]; if (midVal < key) low = mid + 1 else if (midVal > key) high = mid - 1; else return mid; // key found } return -(low + 1); // key not found. } </code></pre> İsterseniz bu noktada bir durun, bu koddaki hatayı görmeye çalışın. Hata, 6. satırdaki iki tamsayının ortalamasını hesaplayan kodda (int mid = (low + high) / 2;</code>). Problem, int</code>'in tamsayı olmaması, int</code> bilgisayarımızın hafızasında herhangi bir noktada yer alan 32 bitlik bir sekansın tamsayı olarak okunması. 32 bitlik bit sekansı bize 2^32 farklı değeri temsil etme fırsatı veriyor, bunlar da int</code> tipi için [-2^31, 2^31 - 1]</code> aralığı. Eğer ki low + high</code> 2^31'den daha büyükse, üste taşma (overflow) dediğimiz fenomen ortaya çıkıyor, işlemin sonucunda ortaya çıkan bit sekansı matematiksel hesaplama ile bilgisayarlı hesaplamanın birbirinden ayrışmasına sebep oluyor. Bu hata basit, tecrübeli birinin yapmayacağı bir hata gibi görünebilir, ancak Java standard kütüphanesinde</a> bile karşılaşılan bir hata bu. Peki, formal metotlar bu problemi çözebilir miydi? Önceklikle cevap, evet. Bu problemi çözebilecek birkaç farklı yöntem mevcut. Ancak problemi keşfetmeden önce, problemi tanımlamamız gerekiyor. Bu örnekteki problem, tamsayı taşması (integer overflow). Neye ihtiyacımız var? Programda herhangi bir noktada tamsayı taşması ihtimali varsa bunu keşfeden, bize raporlayan bir metodolojiye. Hadi gelin bunun için programdaki tüm tamsayıları alabilecekleri aralıklarla işaretleyelim. int low = 0; // (low : [0, 0]) // Burada `a.length: int` aslında bize [-2^31, 2^31 - 1] değerini verirdi, // ancak uzunluğun hesaplanma yönteminden dolayı hiçbir zaman negatif // olamayacağını biliyoruz, o yüzden elimizde [0, 2^31 - 1] var. int high = a.length - 1; // a.length : [0, 2^31 - 1] => high : [-1, 2^31 - 2] </code></pre> Sıradaki işlem daha kompleks, çünkü elimizde 2 farklı seçenek var. While döngüsündeki kontrole göre içine girip işleme devam edebiliriz, ya da döngüyü geçip fonksiyonun sonuna atlayabiliriz, kolay olduğu için sona atladığımız duruma bakalım. Bunun için elimizdeki araçlardan bir tanesi, döngü açımı (loop unrolling). Döngünün bir iterasyonunu bir if</code> olarak açıp, aynı anlamı (semantic) koruyabiliyoruz. if (low <= high) { // Döngünün 1. iterasyonuna giriş yaptık. int mid = (low + high) / 2; int midVal = a[mid]; if (midVal < key) low = mid + 1 else if (midVal > key) high = mid - 1; else return mid; // key found // Döngünün 1. iterasyonu bitti, 2. iterasyondan devam ediyoruz. while (low <= high) { int mid = (low + high) / 2; int midVal = a[mid]; if (midVal < key) low = mid + 1 else if (midVal > key) high = mid - 1; else return mid; // key found } } // Döngü 1 ya da daha fazla iterasyon sonrasında bitti. return -(low + 1); // key not found. </code></pre> Elimizdeki bir diğer araç ise if</code> için. if</code> gördüğümüz noktada, 2 ihtimal var, ya if</code> içindeki kontrol doğrudur ve içerideki hesaplamayı yaparız, ya da değer yanlıştır ve if</code> den bir sonraki hesaplamayla devam ederiz. Öncelikle 0 döngü durumundan, yani if</code> içerisindeki kontrolün ilk iterasyona girmeden yanlış olmasından başlayalım. // Var olan değişkenleri hatırlayalım int low = 0; // (low : [0, 0]) int high = a.length - 1; // (high : [-1, 2^31 - 2]) if (low <= high) { // kontrol yanlış olmalı, demek ki (!low <= high), bu da demek ki (low > high) ... } // (low > high) olan tek bir durum var, o da low = 0, high = -1. return -(low + 1); // dolayısıyla (- low + 1) = -1, taşma yok. </code></pre> Tüm detayları vermeye çalıştığımda burası çok uzayacak, dolayısıyla buradan itibaren biraz hızlı gideceğim. Diğer durumda low <= high</code> olmalı, dolayısıyla low: [0, 0]</code>, high: [0, 2^31-2]</code> ile devam ediyoruz. int mid = (low + high) / 2; // Aralıklar üzerinde toplama ve bölme işlemi: ([0, 0] + [0, 2^31-2]) / 2 = [0, 2^30 - 1] int midVal = a[mid]; // Dizinin elemanları hakkında bir bilgi sahibi değiliz, dolayısıyla midVal: [-2^31, 2^31 - 1] // Eğer buraya kadarki hesaplamalarımız bizi bir kontrolün yanlış olduğu sonucuna ulaştırırsa, // o dalı atlayabiliriz. Şu anda böyle bir sonuca ulaşamadığımız için 3 daldan ilerlemeleri ayrıca incelememiz gerekecek. if (midVal < key) // midVal: [-2^31, 2^31 - 1], key: [-2^31, 2^31 - 1], midVal < key = ?? low = mid + 1 // midVal < key = true, mid: [0, 2^30], dolayısıyla low: [1, 2^30 + 1] else if (midVal > key) // midVal: [-2^31, 2^31 - 1], key: [-2^31, 2^31 - 1], midVal < key = false, midVal > key = false high = mid - 1; // midVal > key = true, mid: [0, 2^30], dolayısıyla high: [-1, 2^30 - 1] else // midVal: [-2^31, 2^31 - 1], key: [-2^31, 2^31 - 1], midVal < key = false, midVal > key = false // (midVal < key) ve (midVal > key) yanlış, geriye yalnızca (midVal = key) kalıyor, dolayısıyla aradığımızı bulduk. return mid; // aradığımızı bulduğumuz için fonksiyondan çıktık, bu dalın devamında incelenecek bir şey yok, ilk // iki dala devam etmeliyiz. </code></pre> Bu hesaplamanın sonucunda, elimizde artık 3 farklı evren var. Birisinde birinci iterasyonda aradığımız elemanı bulduk, dolayısıyla işimiz bitti, devam etmemiz gerek yok. Diğerinde aradığımız eleman ortanın solunda, diğerinde sağında. Hadi gelin aradığımız elemanın ortanın sağında olduğu midVal < key</code> dalında, low = mid + 1</code> sonucunda elimizdeki aralıkların midVal: [-2^31, 2^31 - 1]</code>, key: [-2^31 + 1, 2^31 - 1]</code>, low: [1, 2^30 + 1]</code>, high: [0, 2^31-1]</code> evrenine gidelim. Bu evrende, yine yukarda yaptığımız While döngüsünü açma, ikiye bölme, if</code> kontrolünün içerisinde girme işlerini yapacağız. Bunlar sonucunda // low: [1, 2^30 + 1]`, high: [0, 2^31-2] int mid = (low + high) / 2; // low + high = [1, 2^30 + 1] + [0, 2^31-2] = [0, 2^31 + 2^30 + 1] </code></pre> 32-bit tamsayılarla ifade edebildiğimiz en büyük tamsayının 2^31-1 olduğunu daha önce söylemiştik, ancak fark ettiyseniz bu işlem sonucunda ortaya çıkan aralık bu sınırı aştı [0, 2^31 + 2^30 + 1]</code>. Dolayısıyla bu analiz ile kullanıcıya geri dönüp, senin bu işlemin potansiyel olarak senin tipinin sınırlarını aşıyor diyebiliriz. Burada yaptığımız analiz bir tip statik kod analizi (static code analysis), bu tarz analizler yalnızca tamsayı taşmalarına mı yarıyor, hayır. Mesela Facebook Infer</a> benzer analizleri milyonlarca satır C++ koduna uygulayarak koddaki hafıza güvenliği hatalarını otomatik bir şekilde keşfetmeye, NULL</code> işaretçileri (pointer) statik olarak keşfetmeye çalışıyor. Tahmin edebileceğiniz üzere bu yöntemlerin hepsinin sınırları var, yoksa bugün Rust diye bir dile ihtiyacımız olmazdı, statik olarak C++'daki tüm hafıza güvenliği problemlerini çözebilirdik, ancak çözemiyoruz. Dilin tasarımı, bizim o dil ile ilgili yapabileceğimiz analizleri kısıtlıyor. Dilde yapabildiğiniz her dinamik işlem, statik olarak keşfedebileceğimiz bilgi miktarını azaltıyor. Bu sebepten ki Rust derleyicisinin reddedeceği hafıza güvenliğinden yoksun programları C++ kabul ediyor, ya da herhangi bir statik programlama dilinin derleme zamanında engelleyeceği hatalar ile Python, Javascript gibi dillerde çalışma esnasında karşılaşıyoruz. Java dilinin üzerine yazılan statik analiz araçlarının en büyük kısıtlamalarından birisi Java'daki yansıma (reflection) özelliğinin analizin kesinliğini düşürüp analizi faydasız hale getirmesi. Buraya kadar daha üst-seviye (meta level) doğruluk kavramlarından bahsettik, programın her noktasında tutması gereken, programlama dilinin kendisi ile direkt olarak bağlı nitelikler bunlar, aynı zamanda bunlara bir çeşit güvenlik niteliği (safety property) diyoruz, çünkü hiçbir zaman bozulmaması gereken nitelikler belirleyip, programımızın aldığı herhangi bir yol bu nitelikleri bozabiliyor mu onu arıyoruz. Formal metotların programlamanın tamamına etki etmesi için, çok daha çeşitli niteliklere (properties) ihtiyacımız var, ve dahası programcıların bu nitelikleri yazabilmesi için bir dil sağlamalıyız ki, doğruluk yalnızca bizim düşündüğümüz ve tasarladığımız niteliklerden ibaret olmasın. Tip-Odaklı Geliştirme</a></h2> Bu dillerden ilki, daha önce de bahsettiğim üzere, tipler. Tip sistemleri</a>, bizim yazdığımız programları kısıtlayabilmemizi, tipleri kullanarak programların ulaşmaması gereken durumlardan kaçınmamıza izin veriyor. Bundan bazen tip-odaklı geliştirme (type-driven programlama) olarak bahsedildiğini görebilirsiniz, bu yaklaşımın mottosu "Hatalı durumları temsil edilemez yap" (Make invalid states unrepresentable</a>). Çoğu zaman, programlarımızda tip sisteminin izin verdiği, yani derleyicinin bir hata vermeyeceği, ancak aslında mümkün olmaması gereken ihtimaller var. Tip-odaklı geliştirme bunları ortadan kaldırabiliyor. type Insan = { isim: string, okul?: string, sirket?: string, } </code></pre> Yukarıdaki tip, bir kişiyi tanımlarken, okul</code> ya da sirket</code> alanlarının undefined</code> olmasına izin veriyor. Alttaki veri modeline göre bunun doğru olduğu noktalar vardır, ancak şu anda tartıştığımız evrende bir kişi ya okula, ya da şirkete gidebiliyor olsun. Yani bunların ikisi de aynı anda var olamaz, ikisi de aynı anda boş da olamaz, ancak veri modelimiz buna izin veriyor. {isim: "Alp"} as Insan</code> yazmak tip hatası vermeyecek. Alternatif olarak, bu tipi aşağıdaki gibi tanımlayabilirdik: type Insan = { isim: string } & (Ogrenci | Calisan) type Ogrenci = { okul: string } type Calisan = { sirket: string } </code></pre> Bu örnekte, Insan</code> ya bir öğrenci olup okula sahip olacak, ya da bir çalışan olup şirkete; hiçbirisine sahip olmadığı durumlarda tip sistemi bize hata verdiği için o ihtimal çalışma zamanında var olmayacak. Kontrat Bazlı Dizayn (Design by Contract)</a></h2> Kontratlar fikir olarak nereden çıktı emin değilim, ancak benim şahsen bildiğim en eski popüler örnek Eiffel programlama dili. Kontratlar bizim alttaki programa dair ne tarz varsayımlarımızın olduğunu (assumptions, preconditions), ne tarz sonuçlar beklediğimizi (postconditions), programın hangi nitelikleri koruduğunu (invariants) tanımlamamızı sağlıyor. Aşağıda, Dafny programlama dilinde Max</code> fonksiyonunun tanımı var: method Max(a: int, b: int) returns (m: int) ensures m >= a ensures m >= b ensures m == a || m == b { if a >= b { m := a; } else { m := b; } } </code></pre> Kontrat diyor ki, metodun ürettiği m</code> değeri hem a</code> hem de b</code> parametrelerinden büyük eşit olmalı, hem de ikisinden birisine eşit olmalıdır. Kontratın kendisi, fonksiyonun implementasyonundan bağımsız olarak neyin doğru olduğunu tanımlıyor, Dafny ise derleme zamanında implementasyonun bu kontrata uyduğunu kanıtlıyor. Eğer implementasyonda bir hata varsa, mesela tüm fonksiyonu silip yalnızca m := b</code> yazarsak, ensures m >= a</code> şartı kanıtlanamadığı için Dafny programı derlemeyecek. Gelin bir de yukarıda bahsettiğimiz midpoint</code> örneğine bakalım: method Midpoint(low: int, high: int) returns (mid: int) requires low <= high ensures mid * 2 >= low + high - 1 ensures mid * 2 <= low + high { mid := (low + high) / 2; } </code></pre> Dafny'de int</code> çoğu anaakım programlama dilinin aksine 32 bitlik değil, dolayısıyla bu örnekte taşma konusunda endişelenmemiz gerekmiyor. Onun yerine requires</code> bize bu fonksiyonun hangi şartlar altında çağırılabildiğini söylüyor, ancak low <= high</code> durumunda bu fonksiyonu çağırabildiğimiz için içerde if a < b</code> kontrolünü tekrar yapmadan sonucu hesaplayabiliyoruz, midpoint</code>'i ise çarpma işleminin sonucu üzerinden tanımlıyoruz. Burada küçük programlardan bahsettiğime bakmayın, AWS yeni yazdığı Yetkilendirme Politikaları Dili (Authorization Policy Language) olan Cedar</a>'ı önce Dafny'de geliştirdi, benzer şekilde şifreleme kütüphanesini</a> Dafny'de kanıtladı. Dafny'deki kontratlar statik kontratlar, pek çok programlama dilinde çalışma zamanında kontrol edilen dinamik kontrat kütüphaneleri de var, Python'da Deal</a> var, Racket</a> ise kontratlara dil seviyesinde bir özellik olarak sahip. Bazı programlama dillerinde ise Dafny tipi statik kontrat sistemleri geliştiriliyor, Rust'ta Verus ve Flux, Haskell'da Liquid Haskell ile programlarımızın belli özelliklerini statik olarak kanıtlayabiliyoruz. Bugün bu sistemleri kullanmak, bu sistemlerin üzerine kanıtlı programlar ve kütüphaneler geliştirmek bugün için çok ciddi uzmanlık ve zaman gerektirdse de asıl soru şu aslında, yarın ne olacak? Yapay zeka yardımıyla kanıtlamalı programlama yapabildiğimiz bir dünyada bu tarz teknolojileri kullanarak yazdığımız programların doğruluğunu arttırabilir miyiz? İnteraktif Teorem Kanıtlama (Interactive Theorem Proving)</a></h2> Buraya kadarki bahsettiğim metotlarda kanıtlama işleminin kendisini biz yapmadık. Tip sistemleri programların bizim onlara verdiğimiz sınırlamalarını otomatik olarak kanıtlıyor, kanıtlayamadığında bize tip hatası veriyor. Statik kontrat sistemleri Hoare Mantığı (Hoare Logic) ile programların yazdığımız kontratlara uyduğunu otomatik olarak kanıtlıyor, sistemin otomatik kanıtlamada zorlandığı noktalarda biz biraz yardımcı olabilsek de elle kanıt yazılması için tasarlanmamış bir sistemde kanıt yazmak, kanıt yazılması için tasarlanmış sistemlerde yazmaktan çok daha zor, şimdi bu sistemlerden, interaktif teorem kanıtlayıcılardan (interactive theorem prover) bahsedeceğim. İnteraktif teorem kanıtlama araçları kendi içerisinde teknik detaylarına göre farklı kollara ayrılıyor, misal Isabelle/HOL görece daha eski, bizim alışık olduğumuz klasik mantık üzerine kurulu bir kanıt sistemi kullanıyor. Ben, bağlama da uygun olması için, görece yeni bir kanıtlayıcı olan Lean'e odaklanacağım. Lean, bizim alışık olduğumuz matematiksel modellerden uzak, CIC (Calculus of Inductive Constructions) adında bir matematiksel temel üzerine kurulu. Bu temelin bize sağladığı ana fayda ise, Curry-Howard Denkliği (Curry-Howard Correspondence). Curry-Howard Denkliği bize diyor ki, bizim yazdığımız programlardaki tipler aslında teoremler, o tiplere uyan programlar ise o teoremlerin kanıtı. Dolayısıyla, biz bir teoremi dilimizde bir teorem olarak yazarsak, yazdığımız programın bir tip hatası vermemesi o teoremi kanıtladığımız anlamına geliyor. Gelin biraz pratik örneklerle bakalım: Bir tipi aşağıdaki gibi tanımlıyoruz, aşağıdaki tanım diyor ki, tümevarımsal olarak, bir doğal sayı ya sıfırdır, ya da bir doğal sayının ardılıdır (successor). Inductive Nat : Type | zero : Nat | succ : Nat -> Nat </code></pre> Bu tip üzerinde toplama işlemini aşağıdaki gibi tanımlayabiliriz: def add : Nat -> Nat -> Nat | Nat.zero, m => m | Nat.succ n, m => Nat.succ (add n m) </code></pre> Burada add</code> fonksiyonu, ilk parametresi Nat.zero</code> (0) ise sonucu ikinci parametreye eşit yapıyor, yani 0 + x = x</code> işlemini tanımlıyor, ikinci parametresi Nat.succ n</code> (n+1) ise sonucu add n m</code>'nin ardılı yapıyor, yani (n + 1) + m = 1 + (n + m)</code> işlemini tanımlıyor. Klasik toplama işleminde sahip olduğumuz bazı özellikler var, bunlardan bir tanesi toplamanın değişme özelliği (commutativity), yani a + b = b + a</code>. Gelin bunu Lean'de teorem olarak tanımlayalım: theorem add_comm : ∀ (n m : Nat), n + m = m + n </code></pre> Bu teorem diyor ki, her n</code> ve m</code> doğal sayısı için add n m</code> ifadesi add m n</code> ifadesine eşit. Şimdi bu teoremi kanıtlamamız gerekiyor. theorem add_comm : ∀ (n m : Nat), n + m = m + n | n, 0 => Eq.symm (Nat.zero_add n) | n, m+1 => by have : Nat.succ (n + m) = Nat.succ (m + n) := by apply congrArg; apply Nat.add_comm rw [Nat.succ_add m n] apply this </code></pre> Bu kanıtı tüm detaylarıyla anlamanıza gerek yok, bir noktada bu yazıyı bugün yazmayı geçtiğimiz yıllardan ayıran en büyük fark bu. Yazının başında da bahsettiğim gibi bugünün iddiası, yapay zekanın bu kanıtları bizim için yazabileceği bir geleceğe doğru yol aldığımız. Bu varsayımsal yolun devamında bizim teoremleri yazmamız yetiyor, çünkü arka plandaki kanıt kontrolcüsü (proof checker) bizim sırtımızı tamamen dayayabildiğimiz, başka hiçbir programlama dilinde, hiçbir ortamda sahip olmadığımız bir garantiye sahip olduğumuz bir ortam sağlıyor. Programlamanın temeline işlemiş, her ortamda, her zaman bizi sınırlayan varsayımlarımızı ortadan kaldırabiliyor. Herhangi bir testten, her türlü kod incelemesinden daha güçlü bir garanti bu kazandığımız. Hatta bu işle ilgilenen şirketlerin iddiaları, yapay zekanın bu teoremleri de bizim sözlü olarak yazdığımız tanımlardan otomatik olarak oluşturabileceği yönünde (ben buna katılmıyorum, bu konudaki argümanlarımı okumak için Verifiability is the Limit</a>, Breaking Verifiable Abstractions</a>, ve Verification is Not the Silver Bullet</a> yazılarımı okuyabilirsiniz). Lean ile teorem kanıtlama üzerine kendinizi geliştirmek için Theorem Proving in Lean</a> kitabını okuyabilirsiniz. Bu dillerin belli sınırları var. Her şeyden önce kullandığımız programlama dilini değiştirmemizi, yeni bir ekosisteme sırtımızı dayamamızı gerektiriyor. Lean gibi dillerde yazdığımız programların performansının anaakım dillerde yazdığımız programların performansına kıyasla çok daha kötü olmasını bekliyoruz, çünkü teoremleri kanıtlamak için yazdığımız programlar çok daha deklaratif, teoremin şeklini andıracak şekilde yazılmalı, kanıt mühendisliğinin (proof engineering) klasik prensiplerinden birisi teorem, kanıt ve programı birbirinden ayırmanın çok zor olması. Bir diğer zorluk ise, bu dillerde ifade edebileceğimiz teoremlerin o dillerdeki matematiksel modellere dayalı olması. Mesela, hiçbir zaman bir programın diğerinden daha optimize olduğunu Lean'de kanıtlayamayız, çünkü fiziksel bilgisayarların performansı bizim matematiksel olarak modelleyip kanıtlar yapabildiğimiz kadar basit değil, en azından bugün. Deterministik olmayan, rastgelelikler içeren ya da eşzamanlı programlar (concurrent programs) hakkında kanıtlar yazmak da bugün çok zor, ancak zaman içerisinde gelişiyor, dolayısıyla belki de birkaç seneye bunları da kanıtlayabilir hale geleceğiz. Bu problemlerin bir çözümü var, o da nitelik-bazlı test etme (property-based testing -- PBT). Nitelik-Bazlı Test Etme (Property-Based Testing -- PBT)</a></h2> PBT, temelde buraya kadar yazdığımız metodolojiler ile ayrık değil, hatta barışık ve bağlı. PBT, bir nitelik, ya da kanıtlama bağlamında bir teorem gerektiriyor. Bu teoremin ardından, teoremi test etmek için teoremde bahsi geçen tüm değişkenlerin rastgele örneklerini üretebilmemiz gerekiyor. Bunun sonucunda az önce yazdığımız add_comm</code> teoremini PBT ile test etmek istersek, bunu Typescript'te aşağıdaki gibi yazabiliriz. type Nat = { kind: 'zero' } | { kind: 'succ', pred: Nat }; function add(a: Nat, b: Nat): Nat { if (a.kind === 'zero') { return b; } else { return { kind: 'succ', pred: add(a.pred, b) }; } } function natEqual(a: Nat, b: Nat): boolean { if (a.kind === 'zero' && b.kind === 'zero') { return true; } else if (a.kind === 'succ' && b.kind === 'succ') { return natEqual(a.pred, b.pred); } else { return false; } } function toNat(n: number): Nat { if (n <= 0) { return { kind: 'zero' }; } else { return { kind: 'succ', pred: toNat(n - 1) }; } } function generateNat(): Nat { const n = Math.floor(Math.random() * 100); // 0 ile 99 arasında rastgele bir sayı return toNat(n); } function testAddComm(iterations: number) { for (let i = 0; i < iterations; i++) { const a = generateNat(); const b = generateNat(); const left = add(a, b); const right = add(b, a); if (!natEqual(left, right)) { console.error(a, "+", b, "=", left, " ile ", b, "+", a, "=", right, " eşit değil!"); return; } } console.log('Tüm testler geçti!'); } </code></pre> Burada, teoremimizi natEqual(add(a, b), add(b, a))</code> fonksiyonuyla test ediyoruz. generateNat</code> fonksiyonu ise rastgele doğal sayılar üretmek için kullanılıyor. Geçtiğimiz yıllarda Cardano ve AWS PBT ile kanıtlı programlama yaklaşımlarını birleştirerek Lean'de geliştirdikleri kanıtlı programları Rust'ta geliştirdikleri üretim sınıfı (production grade) programları test etmek için kullandılar. Bu yaklaşımda, Lean programı ile Rust programının her girdi için aynı çıktıyı vermesi gerektiğini bildiğimiz için, Lean programını bir referans model olarak kullanıp, Rust programını Lean programına karşı test ettiğimizde Lean'de kanıtlanan teoremlerin Rust programında da geçerli olduğunu garanti edebiliyoruz. PBT'nin faydalı olması için yalnızca kanıtlı programlamayla birlikte kullanılmasına gerek yok, bugün PBT daha müdahale etmeden kod yazılan yapay zeka yaklaşımlarında (Agentic AI), kodun doğruluğunu test etmek için kullanılabiliyor. Daha gün, Claude Code'da majör bir yenilemenin</a> PBT ile yapıldığının örneğini gördük. Benzer şekilde BitsEvolve</a> gibi yaklaşımlar da PBT'yi kullanarak otomatik optimizasyon sistemleri inşa ediyor. Kapanış</a></h2> Formal metotlar, programlarımızın doğruluğunu arttırmak için kullanabileceğimiz güçlü araçlar. Bu araçlar bugüne kadar niş olsa da, yapay zeka yardımıyla daha erişilebilir hale geldiklerini görüyoruz, ben şahsen gelmeye devam edeceğine dair işaretler görüyorum. Türkçe'de böyle bir kaynağın eksikliğini gördüğüm için yazmak istedim, eğer eksik gördüğünüz ya da yanlış olduğunu düşündüğünüz bir nokta varsa bana akeles@umd.edu</a> adresinden ulaşabilirsiniz. Bir sonraki yazıda görüşmek üzere! Temporal Shrinking 2025-11-22T00:00:00+00:00 Random testing, in isolation, is a stupid idea. You take a program, which has a practically infinite amount of possible inputs, you randomly pick one of those infinite possibilities in the hopes of breaking the program, or some assertion about the program, and it actually works (discovers bug) in even the most naive form possible, which is essentially the following loop: while True: input = generate_random_input() if not property(input): report_bug(input) </code></pre> Over the years, people have developed many different improvements on this naive form I described. The most famous example is coverage guidance, which led to the rise of fuzz testing in the last decade, finding thousands, perhaps millions of different bugs across systems. In coverage guiding, the random inputs are biased towards inputs that increase the code coverage of the system under test, leading to better exploration of the input space. The modified loop looks like this: pool = initialize_pool() while True: input = mutate(select_from_pool(pool)) if not property(input): report_bug(input) if increases_coverage(input, pool): pool.add(input) </code></pre> As we found more and more bugs, it became more and more apparent that finding bugs was, and is, not sufficient. Someone must validate and fix the said bugs. Hence, the "counterexamples", inputs that trigger the alleged bugs, must be legible, inspectable, managable. Ideally, the tester should receive the simplest possible form of the input, isolated from any noise, only providing the minimal necessary structure for the reproduction, and the eventual fixing, of the bug. The solution emerged in different names, but in similar shapes, minimization, delta-debugging, or shrinking. Shrinking is one of these ideas that immediately make sense once you hear about it. Let's say that we generated some random input for some program, perhaps a random PNG image for an image processor. Once a bug is triggered in some part of the system, we would like to get the simplest PNG possible that retriggers the input. For this, we can designate some simplification procedures. We can dim each pixel independently, making the picture darker, turning as much of the pixels as possible into #000000</code>. We can also remove some parts of the image completely by cropping the image. As it turns out, many times these simplifications are equivalent to making the values smaller, such as reducing the size of the image, or converging pixels to white as the smallest hex coded color, hence the name shrinking. In shrinking, we start from a bug-triggering input case, and we repeatedly produce smaller (shrunk) versions of the input as long as there is a smaller input that still retriggers the bug. If we cannot find a smaller instance, we report the original input to the user. Given some input I</code> that triggers a bug, we can define a shrinking function shrink(I) -> [I_1, I_2...I_n]</code>, we can write a version of the shrinking algorithm as follows: def shrink_input(input): for smaller_input in shrink(input): if triggers_bug(smaller_input): return shrink_input(smaller_input) return input </code></pre> Enters temporality. The default perspective into random testing is that it produces many inputs from scratch, you may conjure up PNGs from thin air, produce balanced binary trees, generate network topologies, create virtual physical environments or write texts with grammatical faults, all depending on your domain. However, there are many systems where generating inputs from scratch is not an option, you cannot first generate an entire well-formed SQLite database from scratch, and then a SQL query over the database, only to test the result of a simple query. Therefore, instead of trying to generate such complex structures from scratch, random testing have mostly converged to using stateful generation. In stateful generation, we add a notion of time to random testing. We start from an initial state S_0</code> at time t=0</code>, and generate an interaction against a system based on its API. For a SQL database, these can be SQL statements, for a key-value store, these are insert</code>, delete</code>, get</code>... After every interaction, the state of the system possibly changes, affecting the next input we generate. Assuming we're lucky (the system itself is not affected by the physical time), every action will be another tick, going from t=0,1,2...n</code> until we discover a bug. We already know the logical next step, shrinking, but how do we shrink these actions that have these potential linear dependencies with each other, every action possibly depending on all prior actions to be valid? Below is an example of such a dependency chain: CREATE TABLE t0 (c0, c1); INSERT INTO t0 VALUES (0, 0), (1, 1), (2, 2); SELECT FROM t0 WHERE c0 >= 1; -- @bind r -- @assert r = (1, 1), (2, 2) </code></pre> The language depicted here is a small augmentation of SQL for binding results of intermediate queries and asserting facts about them, this specific example highlights a containment assertion, we expect to find the values we inserted when we search for them. If we go about removing parts of this structure, similar to what we did for PNGs in the stateless instances, it is possible that we render the test invalid. If you remove the first line (CREATE TABLE...</code>), you expect that all the following interactions fail, hence the assertion will fail, but the test itself will be invalid. There are some solutions to this scenario, the first of which is to restrict the shrinking by slicing the input we have at hand. Take the following alternative sequence of interactions: CREATE TABLE t0 (c0, c1); CREATE TABLE t1 (c0, c1, c2); -- (2) INSERT INTO t0 VALUES (0, 0), (1, 1), (2, 2); INSERT INTO t1 VALUES (NULL, 'why', 'not'); -- (4) SELECT FROM t1 WHERE c0 != 1 OR c1 != 'how'; -- (5) SELECT FROM t0 WHERE TRUE; -- (6) SELECT FROM t0 WHERE c0 >= 1; -- @bind r -- @assert r = (1, 1), (2, 2) </code></pre> We can slice this program up into 2 parts, the parts that are relevant to the failure, and the parts that are irrelevant. This relevancy is of course a heuristic, perhaps what seems irrelevant is the cause of a failure we see, hence we need to make sure our assumptions are sound. The slicing heuristic I'll use is table-based slicing, where we only care about the interactions with the tables related to the failing assertion. r</code> is computed by a query over t0</code>, hence we remove all interactions that do not read or write to t0</code>. In the example above, this slicing allows us to eliminate queries (2), (4), and (5) as they do not mention t0</code>, but rather only t1</code>. Another heuristic is to remove as many reads as possible, as they (hopefully) do not affect the state of the database, which allows us to remove query (6) as well. After slicing, we are left with the original example, which is much smaller. We can, however, have another type of shrinking, one that leverages the temporal generation instead of trying to work through the limitations it imposes. What do we do, we time travel! Instead of starting shrinking from the large structure that triggered the bug, we start from the random seed that produced the structure in the first place. We start generating the input at t=0</code>, but at some point in time t=j</code>, we manipulate our decision, we generate a smaller input. It must be noted that every single action we take after t=j</code> is now possibly changed, because we went back in time and changed the past, affecting every future decision from that point on. The good thing about this approach is that we preserve the original invariants that the generator respected, because we did no actual shrinking, we only manipulated the generation process into generating a smaller structure. The first approach of going from a large structure to smaller ones by using a reproducer</code> for detecting if the fault continues to occur is typically called external</code> or type-based</code> shrinking, although I like to call it structural shrinking.</code> The second approach is called internal</code>, or integrated</code> shrinking; Property-Based Testing libraries are typically divided in the ways they pick the shrinking methodology, Hypothesis famously uses</a> integrated shrinking, whereas many of the QuickCheck descendents use structural shrinking. Fast forward to DST. The discussion of integrated vs structural shrinking is a long one, one which I'll not take sides at the moment; but there's a special flavor of random testing that structural shrinking is not really an option, deterministic simulation testing. I won't go into the very specific details of DST in this post, I think there's already some great resources such as Phil's blog post </a> that are sufficient for it. In short, DST is what you need when testing systems where you are not lucky enough that you can remove the notion of time from your system, violating the assumption of the previous section. Many times, especially in distributed systems or concurrent programs, physical time is an important part of how your system works, and you cannot abstract over it, you need to work with the physical time. In such cases, you cannot naively shrink your inputs, because you cannot even reproduce them most of the time. When testing a time-aware system, running the same sequence of interactions twice doesn't guarantee the same outputs or results, let alone preserving the error if you change them. In DST, the execution layer is perfectly deterministic, meaning that physical time and effects are abstracted from the system, so your tests are perfectly reproducible, and that's a great thing, because it gives you the ability to debug previously undebuggable bugs as you can reproduce the same exact sequence of interactions, solving the infamous pain of Heisenbugs, but does it? The central issue with perfect reproducibility is that you cannot change anything in the system because of the temporality. You can go back in time, but you cannot change anything, you can only observe. The moment you change something, every next decision is out of your control, so you cannot know the exact affects of your change. Did you actually fix the bug, or did the scheduler just make a different choice that removed the bug? Engineers at Antithesis, the company pioneering DST at the moment, have found a very cool method for overcoming this problem, which I like to call temporal shrinking, or rather temporal fault localization. The idea is as follows: You have a temporal test, some sequence of inputs spanning some amount of time. As I said, you can change any decision at any point in time, which will affect possibly everything from that point on. Let's assume that some decisions at arbitrary points in time j_0, j_1...j_k</code> are the triggering conditions of the bug. If you change anything after t=j_k</code>, the reproduction of the bug must not change, so all 100% of the decisions after j_k</code> must be irrelevant. So, we can pick random points in time, change the decisions at such points, and check how they affect the percentage of bugs found afterwards. In a very rare bug, namely one that only reproduces under conditions j_0...j_k</code>, if you change any of the j_0...j_k</code>, you would get a 0% retrigger rate. This core idea of retrigger percentage allows Antithesis to localize the bug temporally, identifying key pieces in time that are crucial to the retriggering of the bug, which is ultimately a form of shrinking, hence the name of the article. It also feels somewhat descendent of the spectrum based fault localization techniques that identify differences between positive and negative inputs, but moving it into the temporal realm. A potential analysis built on this capability leads to the following bug probability graph shown below. The exact details of the computation for producing the graph can be found in Antithesis docs</a>, as well as how to interpret the results of the graph. It should be noted that I'm not affiliated with Antithesis (although I collaborate with them on different topics), and temporal shrinking is not limited to Antithesis, but rather applicable for any Deterministic Simulation Environment. I posit that in a few years, we will probably see similar tools built on concurrency testing libraries such as Shuttle</a> or Fray</a>, because they are in a similar design space and have the same challenges with respect to shrinking and debugging. Verification is Not the Silver Bullet 2025-11-18T00:00:00+00:00 This post is a sequel to my thoughts on "What are the limits of LLMs" (Verifiability is the Limit</a>) and "What are the domains I believe LLMs will shine at autonomously" (Breaking Verifiable Abstractions</a>). As I see verifiability as part of the mainstream discussions more and more, I decided to break down on the limits of verifiability, focusing on how verification as a general principle isn't sufficient, and what more do we need. In my original post, I posed verification as a human endeavour, as opposed to the mainstream usage of the term that usually means computational verification. Computational verification is a procedural activity, it is the act of asserting facts about programs by stating the facts in the form of tests that can be run, or factual statements that can be mechanically checked. Humans use computational verification as part of their workflows, but they typically go beyond, because the facts checked by the machine are subjective to the human verifier. If you would think about contesting this statement, think about any system you previously worked on, would two people come up with the same exact tests for the same system in any of those cases? Unfortunately for us, correctness is ultimately subjective, so we must be bothered with defining it. This reveals a crucial limitation of the autoformalization approaches like Harmonic AI's Aristotle, Math Inc's Gauss, and a number of similar efforts throughout the industry. The fact that you have perfect prover does not mean you have perfectly good theorems about your systems. The fact that you have perfectly good theorems also doesn't mean your autoformalization procedure, which takes your perfectly good theorems expressed in natural language, will translate them by preserving their semantics. At any point where the semantics of your specification is not precise, the systems need to "guess" your intent, which is prone to failures on both sides, you might have ill-defined, or the system might have ill-guessed the specification. This is exactly the point I touch in Breaking Verifiable Abstractions</a>, we can go above a traditional programming language but still have precise semantics, or we can break the traditional flows of compilation by leveraging the perfect verifiers without relying on imprecise specifications. Nothing I wrote so far has been in contrast to anything I wrote prior to this, so let's get to the new rather interesting bit I've been thinking about. There's an opinion that gets more mainstream by the day, the more verifiable a task is, the better the models will get at it, we see this fact in games, mathematics, programming. When taken to the limit, this statement implies that any perfectly verifiable task should be completely solvable my the models. The point of this post is to falsify this implication, and put a framework for the limits of verifiability, what are the properties of verifiability of a domain that helps models get better in solving problems in it? The example I'll use is prime factorization, the mathematical definition is very straightforward. n = p_1 * p_2 * ... * p_k </code></pre> Where n</code> is a natural number, and p_1, p_2, ..., p_k</code> are prime numbers. The solution to the problem is the list of prime numbers that multiply to n</code>. The verification of the solution is also very straightforward, you multiply the list of prime numbers, and check if the result is n</code>. Prime factorization is one of the foundations of today's cryptographic systems as scientist haven't been able to find any patterns for reducing the problem space into something that's essentially asymptotically better than brute force trials. If we were to accept the original overly generalized statement that anything verifiable can be solved, we would reach to the conclusion that one could train a model to the point it can automatically decide the prime factorization of any given number. A possible critique of this position is that an LLM could indeed do that by learning to do arithmetic. There's nothing that prevents the model from learning to perfectly divide numbers, do this in a loop that simulates the algorithm we currently run on the CPU. My response to the critique would be that this isn't what we mean when we say that the model gets better at X. A model getting better at chess doesn't necessarily learn Alpha-beta pruning, it learns patterns at higher levels than the low level mathematically descriptive operations we traditionally have. So we differentiated chess from prime factorization using "something", which we haven't really defined. What I would like to propose here is "progress" as an augmentation to "Verifiability is the Limit", I would like to revise myself to say "Verifiable Progress is the Limit". The problem with prime factorization is that there aren't "to the best of our knowledge" patterns to discover and exploit. There's no information about "how wrong" the result is. In games and in programming, it is possible to compare two solutions to the same problem and produce information based on their comparison; therefore repeated play produces more and more information by providing a compare and contrast style of learning based on how different actions affect the outcomes. What are the implications of this fact, if it is indeed a fact? The first is that it would mean you cannot target AI at an NP problem for repeatedly running a verifier on the problem and hoping that the model will become better in time, assuming that the model doesn't capture new patterns that we previously haven't been able to uncover or realize. The second is that, building verifiers isn't sufficient, because we now have a measure of how useful a verifier is for a model based on the amount of information it produces. We must discuss what types of feedback can be incorporated in the result of the verifier, and how that affects the process of learning. That was it! As I think more on this issue, it becomes harder to differentiate between sound claims and personal bias, so it is entirely possible that I'm missing some crucial points of the discussion. If you find such missing links, please let me know at akeles@umd.edu</a>, I would love to know about the deficiencies of these arguments. Designing A Digital Restaurant 2025-10-10T00:00:00+00:00 I had the second system design interview of my career last week, the first one was 7 years ago, I was a junior at college, the question was boring, and I fumbled it quite bad. That just made me scared of system design interviews, so I was pretty nervous, little did I know, it was actually very fun, so I wanted to write about it. The question, roughly put, is as follows: You walk into a restaurant, there's a kiosk. You select some items, maybe a menu with some drinks, and you hit order</code>. A few minutes later, you get the order. Assume that the kitchen is tracked entirely through a digital system, where individual workers can only communicate through a digital interface, design the kitchen. </blockquote> As this is a 45 minute interview, there's of course lots of handwaving, but we went through a sequence of discussions I will now describe. At a very high level, there's a set of states an order will be in. When an order is taken, the restaurant can accept or reject the order, which will be first queued, then cooked, served, and finally accepted or rejected by the customer. The simplest idea would to have a one person kitchen, where the kitchen worker has the ability to look at an order, plan</code> some series of actions (picking up items, putting items on counters, grilling, cutting...). Anytime an order is in, the worker receives the order, plans how to cook and serve it, all other orders are queued in the meantime. This, of course, is completely impractical and not a very useful mental exercise. A next step, while still keeping a single worker, is to move planning offline</code>, where the worker isn't required to do the planning but rather the system deconstructs the order into pieces and gives the worker a sequence of actions. This is useful because it allows us to later scale the system into multiple workers by centralizing the planning. There are perhaps multiple mechanisms for doing this, the one I came up with is building a dependency graph for an order, essentially a DAG that represents the preparation of a particular item, linearize it by topologically sorting the dependency graph and sending each step to the worker in that order. Below is an example DAG for preparing a cheeseburger. Each item in the graph has a set of prerequisites as well as a set of steps that I hid in the graph. The black circles are the DONE</code> items that were completed. The orange circles are IN PROGRESS</code> items that had their prerequisites DONE</code>, but their internal set of steps haven't been done yet. The white circles are WAITING</code> for their prerequisites to be DONE</code>, so their steps can be performed. You might have realized there's an inefficiency here, maybe some of the internal steps of a particular item only depend on some of its dependencies, so for instance even before having the cheeseburger ready, the worker can put the fries and the drink in the brown bag, optimizing some of the steps. That is possible to do within this framework by further decomposing circles into smaller circles that represent each step, so instead of viewing the DAG at the items level, we can see view it at the steps level, getting rid of such inefficiencies. Once we have offloaded the planning to our digital system, we get to create a job queue that workers can just pick the next job to work on, getting a fair bit of parallelism in the way the kitchen is operated without any type of coordination between workers. This assumes workers are indistinguishable from each other, meaning any step can be performed by any worker, an assumption far from reality. To make our scenario a bit more realistic, let's assume that each step is associated with some required capabilities, and that each worker has some capabilities. We can slightly modify our job queue for giving each worker the next job in the queue that they have the capability to do. Based on the worker distribution, this can approximate a realistic environment. Trivial tasks such as moving item from the shelf to a counter or from storage to the shelf are capabilities all workers possess, but other tasks such as grilling are more specialized, allowing only certain workers to perform them. A dimension we currently ignore is that there is a cost to performing operations, and this cost depends on the current circumstances of the worker. If there are 2 available workers at stations A and B, and the next job in queue is at some other station C, picking which worker will perform the job requires measuring the cost of moving between station A-C or B-C, as well as the next jobs in the queue requiring one of the workers due to their capabilities. Instead of handling such complexity, I picked a simpler one where I gave each job a certain amount of time to perform. So grilling meat takes 3 minutes but cutting the lettuce takes 15 seconds. We can also invent the notion of a time-sensitive task, for instance after grilling a meat it should be served in less than 5 minutes so that it doesn't get cold, or that after 3 minutes it should be taken from the grill in a minute so that it's not burnt. We can achieve this by making the job queue time-aware, where the time-sensitive tasks are placed based on the timing requirements. We can tag each task with a cost function based on the time of execution. Aside from hard timing requirements I mentioned before, a basic cost function is just a measure of how much each customer waits. When picking a task, older tasks are more likely to be picked. Another issue is fairness; if I come in with a 100 unit order, should the next 50 people with smaller orders wait for me, or should I wait for them? My suggestion in the interview was to be unit-fair, the expected wait time should be proportional to the size of my order. People with small orders should be prioritized over people with large orders, so that one client cannot choke the system. There are plenty of more complexity to add if you have time, you can design recovery/mitigation schemes in the cases of faulty orders, you can define failsafe mechanisms for synchronizing the real state with the digital one, because perhaps the worker failed to properly sync the digital system as they worked on their tasks. You can add contention over resources, where instead of having N queues (different work stations) that are entirely isolated from each other, some resources (perhaps knives or pans) are shared across workers, so we need to remove contention over them. It is of course important to remember that this is all just a mental exercise, we aren't really designing restaurants, I'm sure anyone who spent more than 10 minutes at a kitchen will laugh at many of the assumptions I make. The idea is to start from a vague definition with minimal requirements, gradually grow the system into something that resembles the problems we face in computing and software engineering. I'm glad I got to think about the question, it was a fun 45 minutes, maybe it'll be an inspiration to other companies in how they could design their interview questions, or to candidates on how to think about system design questions. How can we secure Package Managers? 2025-09-18T00:00:00+00:00 Package managers, however prevalent, feel as if they are still infants in terms of security, considering the various supply chain attacks we have seen in the previous few years. The few solutions I see as a response are (1) securing the producers of the packages via account security practices such as multi-factor authentication, (2) advocating against using external packages for convenience by sometimes not having a package manager</a>, or making it harder to create packages</a>, and (3) which feels to me is a sensible direction, is reducing the attack surface by adding a delay in consumptions of the package updates</a>, hence securing some of the consumers, because if all users used the same delay, we probably would have ended up in similar scenarios, albeit a bit safer. This option also has the problem of not taking into account when you need imminent updates specifically because you need to escape from a known vulnerability. I argue that even though the idea of securing the consumers instead of making it harder to create or consume packages, or securing the producers is the right direction, time is not the right axis, it's a faulty proxy. When we wait a day for updating a package, we trust the social process that is supposed to execute within those 1440 minutes, which is the results of the package audits, user reports, perhaps the account owner that got exploited in the first place realizes the issue. As our trust in time is a reflection of our trust in the social process, why not just codify our trust in the social process in the first place? I propose a HITS like graph ranking algorithm that users can define trust metrics based on the characteristics of the diffusion of the package. Users should be able to set queries like only if 60% of the users updated the package, I want to update too</code>, or only if users X and Y updated the package, I want to update too</code>. This allows for the package auditers to be a central part of the package management, because users can now use them as package authorities in their queries. The caveat, of course, is that the package management is now a complex system with a distributed state, which can have bugs of its own, in addition to opening up a whole lot of different questions such as the trustworthiness of the user-provided metrics, which is why I think an authoritative approach of assigning users some measure of trustworthiness is a useful addition. Though I don't have a good background in this domain, I found the idea to be stupidly simple while it has the potential to be very effective, which means I might actually be catastrophically wrong. I wanted to keep the idea in some long living form, which is why this blog post exists. If you have some criticisms, I would love to hear them (akeles@umd.edu</a>). From Hand-Tuned Go to Self-Optimizing Code: Building BitsEvolve 2025-09-18T00:00:00+00:00 This is a mirror entry of an article I co-authored published in Datadog Engineering Blog</a>. At Datadog, cost-aware engineering is more than a principle; it’s a performance challenge at scale. We’ve published how we saved $17 million by rethinking our infrastructure, and we’ve built Cloud Cost Management to help customers do the same. But scaling deep, expert-level code optimization across a fast-moving engineering organization presents its own challenge. </blockquote> Our journey didn’t start with a grand AI design. It began as a mission to trim CPU usage in several critical hot-path functions in our most expensive services. For the hands-on performance engineer, we’ll dig into the gritty work of optimizing Go code: eliminating compiler bounds checks, restructuring loops, and rewriting functions for maximum efficiency. For those building agentic systems with LLMs, we’ll share how those human-driven optimizations seeded the heuristics behind BitsEvolve, our internal agentic system for self-optimizing code. </blockquote> Whether you’re here for the nanoseconds saved in Go or for a way to scale deep optimization work beyond a handful of experts, we’ll share what worked, what surprised us, and how the art of manual optimization provided the blueprint for an automated system. </blockquote> Programlama Dilleri Hakkında 2025-09-04T00:00:00+00:00 Programlama dilleri, programcı ile bilgisayar arasındaki en temel iletişim kanalı. Yazdığımız programlar derleyiciler (compilers) ve yorumlayıcılar (interpreters) ile bilgisayarların onları çalıştırabileceği formlara dönüşüyor, sonrasında ise kullanıcılar yazdığımız programları kullanabilir hale geliyor. Her ne kadar günümüzün büyük bir kısmını bilgisayara istediklerimizi yaptırabilmek için programlama dillerini kullanarak geçirsek de, programlama dillerinin hem teorisini hem de pratiğini anlamak programcılar için bir beklentiden ziyade bir anomali, nadide bir uzmanlık. Bunun popüler kültürde yansımalarını görmek çok kolay; Bir programlama dilini öğrenince diğerlerinin yalnız sözdizimini (syntax) öğrenerek onları yazabileceği inancı.</li> JavaScript'in gariplikleriyle ilgili şakalar</li> Python'ın in</code>, is</code> gibi İngilizce kelimeleri kullandığı için daha basit ya da kolay olduğu iddiası.</li> </ul> Yazının kalanında programlama dillerinin yerleştirildiği bu mistik, anlaşılmaz noktadan onları biraz da olsa çıkarabilmek için kendi gözümden programlama dillerini nasıl değerlendirdiğimi, farklı dillerin nasıl özelliklere sahip olduğunu, ana akımın dışına çıktığımızda programlama dillerinin nasıl farklılaşabildiğini anlatmak istiyorum. Bu yazı bir nevi geçtiğimiz yıl yazdığım Tip Sistemleri Hakkında</a> yazısının bir devamı, bütünleyicisi olacak, o yüzden eğer bu yazı ilginizi çekiyorsa onu da okumanızı tavsiye ederim. Programlama Dili Nedir</a></h2> Benim gözümde programlama dilleri, en temelde sözdizimi (syntax) ve anlamı (semantics) olarak iki teorik bileşenden oluşuyor, bu bileşenlerin üzerine bir pratik implementasyon (derleyici ya da yorumlayıcı), bir takım araçlar (Dil Sunucusu - LSP, Kod Formatlayıcı, Paket Yöneticisi, Paket Kayıt Sistemi), ve bir kütüphane ekosistemi ile en başta matematiksel bir obje olan programlama dilleri sosyal objelere dönüşüyor. Bu yazıda programlama dillerine mümkün olduğunca matematiksel bir obje olarak yaklaşacağım, yalnızca yer yer dilin tasarımındaki belli özelliklerin implementasyonu, araçları ya da ekosistemi nasıl etkilediğini tartışacağım. Sözdizimi - Syntax (Sentaks)</a></h3> İlk paragrafta programlama dillerinin programcı ve bilgisayar arasındaki iletişimi sağlayan kanal olduğundan bahsetmiştim, burada bir köprüye ihtiyacımız var, bu köprü de sözdizimi. Bir dilin sözdizimi o dilin metinsel halini tanımlıyor, yani teknik olarak aynı dil için dilin anlamını değiştirmeden farklı farklı sözdizimleri kullanmak mümkün. Bunun en iyi örneklerinden birisi programlama dillerindeki makrolar. Makrolar bize dilin ifade edemediği ya da sahip olmadığı sözdizimlerini ifade etme imkanı sağlıyor. Bunun en basit örneklerinden birisini C makroları ile görüyoruz, üzücü ki pek çok programcının makrolarla etkileşimi bunları hiçbir zaman geçmiyor. Gelin küçük bir örnek verelim, C programlama dilinde biliyorsunuz ki çok tiplilik yok, bu da demek oluyor ki Java ya da C++'da yazabildiğiniz gibi Vector<String></code> gibi bir ifade yazamıyorsunuz, bu problemi çözmenin bir yolu C tip sistemini yoksaymak, bunun için koleksiyonunuzun elemanlarının tipini void*</code> olarak tanımlıyorsunuz, kullanıcı hangi tip değerleri koleksiyona koyduğundan kendisi sorumlu. Benzer bir problemi makrolar kullanarak da çözebiliyorsunuz. Aşağıdaki örnekte DEFINE_VECTOR</code> makrosu bir anlamda sizin dilin sözdizimsel limitlerini aşmanıza izin veriyor, dili büyütmenizi sağlıyor. // Define a type-safe vector for any element type #define DEFINE_VECTOR(T, Name) \ typedef struct { T *data; size_t len, cap; } Name; \ static inline void Name##_init(Name *v){ v->data=NULL; v->len=v->cap=0; } \ static inline void Name##_push(Name *v, T x){ \ if(v->len==v->cap){ v->cap=v->cap? v->cap*2:4; \ v->data=realloc(v->data, v->cap*sizeof(T)); } \ v->data[v->len++]=x; \ } \ static inline void Name##_free(Name *v){ free(v->data); } // Example: make IntVec and StrVec DEFINE_VECTOR(int, IntVec) DEFINE_VECTOR(char*, StrVec) int main(void){ IntVec iv; IntVec_init(&iv); for(int i=0;i<5;i++) IntVec_push(&iv, i*i); for(size_t i=0;i<iv.len;i++) printf("%d\n", iv.data[i]); IntVec_free(&iv); StrVec sv; StrVec_init(&sv); StrVec_push(&sv, "hello"); StrVec_push(&sv, "world"); for(size_t i=0;i<sv.len;i++) printf("%s\n", sv.data[i]); StrVec_free(&sv); } </code></pre> C makroları farklı dillerdeki makro ailelerine göre güçsüz ve güvensiz bir makro tipi. LISP makroları size neredeyse sıfırdan yeni bir dil tasarlama fırsatı veriyor, LISP dil ailesinden çıkmış "Dil Odaklı Programlama" mottosunu temel alan Racket ile farklı problemler için farklı "diller" yazabiliyorsunuz, ancak aslında hepsi Racket makroları ile yazılmış sözdizimleri, yani aslında alttaki dilin semantikleri hala Racket, hatta son 2 yılda yayınlanan Racket ile yazılmış ama sözdizimi neredeyse tamamen Python'ı andıran Rhombus adında bir "dil" de mevcut. Sözdiziminin önemi bir dilde kodu doğru yazdığınızda değil, yanlış yazdığınızda daha çok ortaya çıkıyor. İyi tasarlanmış bir sözdizimi alacağınız hataların lokalize olmasına önem verir, eğer ki siz 17. satırda yaptığınız bir yazım hatası için 42. satırda hata alıyorsanız, programlama dili sözdizimi anlamında size ihanet etmiş demektir. Benzer şekilde programlama dilinin sizin yaptığınız hataları sessizce yok etmesi de sözdizimsel bir hata, bunun en iyi örneklerinden birisi JavaScript'teki ASI (Automatic Semicolon Insertion): function getObject() { return { value: 42 } } console.log(getObject()); // undefined </code></pre> ASI JavaScript'in sözdizim dizaynının bir parçası, eklenebilecek herhangi bir ifadenin sonuna noktalı virgül (;</code>) ekleyerek dili yeni başlayanlara daha yakın hale getirme çabasının bir sonucu, ve benim gözümde kötü bir dizaynın iyi bir örneği. Dilin sözdiziminin parçası olan başka örnekler Python'ın tarihsel olarak popüler olan kıvırcık parantez ({}</code>) blok sözdizimini reddedip girinti (indentation) bazlı bloklar oluşturması, ki daha geçmişe baktığımızda kıvırcık parantez öncesi BEGIN END</code>, IF FI</code>, FOR ENDFOR</code> gibi farklı sözdizimsel tercihler de görüyoruz. Tabii en ünlü sözdizimsel tercih, bu tarz bloklar, işaretçiler, operatör öncelikleri vb. gibi tercihleri bir kenara bırakıp S-ifadeleri (s-expressions) kullanmak, LISP dil ailesini s-ifadeleriyle dolu bol parantezli kodlarından tanıyabiliyoruz. (progn (defmacro thr (x &rest fs) `(reduce (lambda (a f) (funcall f a)) ',fs :initial-value ,x)) (labels ((fib (n) (if (< n 2) n (+ (fib (- n 1)) (fib (- n 2)))))) (let* ((xs '(1 2 3 4)) (ys (mapcar (lambda (x) ((lambda (k) (+ (* x x) k)) 7)) xs)) (sum (reduce #'+ (remove-if-not #'evenp ys))) (t3 (thr 3 (lambda (x) (+ x 5)) (lambda (x) (* x 2))))) (format t "~&YS=~a SUM=~a FIB(10)=~a THR=~a~%" ys sum (fib 10) t3)))) </code></pre> Her ne kadar bu şekilde görmesek de, sözdizimini bir kenara bırakmanın bir başka örneğini devops ailesinde JSON</code> veya YAML</code> bazlı sözdizimlerinin popüler olmasında görüyoruz. Github aksiyonlarınızı yazdığınız YAML dosyası aslında bir programlama dili. Aynı dilin semantik olarak değişmeyen ancak sözdizimsel olarak değişen 2 halinden bahsediyorsak, o zaman popüler "programlama dili fark etmez, sözdizimini öğrenince hepsi aynı zaten" algısı doğru olabilir, ancak ben o halde bile doğru olduğunu düşünmüyorum, çünkü sözdizimi bizim için dilin bazı parçalarını kullanmayı daha kolay, bazı parçalarını kullanmayı daha zor hale getiriyor, eğer dilde bir veri yapısı için özel sözdizimi varsa, programcıların onu kullanma ihtimali çok daha artıyor. Python ve JavaScript'in ikisi de sonradan üstüne eklenmiş statik tip sistemlerine sahip, ancak TypeScript MyPy'dan çok daha popüler, benim bu konudaki görüşüm TypeScript tiplerinin yazmanın sözdizimsel olarak Python tip tüyolarından (type hints) çok daha kolay olması. JavaScript'te çok benzer kullanım şeklillerine sahip olmalarına rağmen objelerin Map'e göre çok daha popüler olduğunu görüyoruz, çünkü obje oluşturmak için özel sözdizimi varken, ve bu dilin çok temeline yerleşmişken, Map fonksiyonlarının dilde yazılmış farklı bir veri yapısından bir farkı yok. Sözdizimi dile olan sosyal algımızı etkiliyor, bu da sonrasında sosyal bir obje olan programlama dilini değiştiriyor, ekosistemi, araçları, dilin kullanımını ve gelişimini yönlendiriyor. Semantik - Semantics (Anlambilim)</a></h2> Programlamanın bilgisayar ve programcı arasındaki iletişim olduğunu söylemiştik, sözdizim bu iletişimin "nasıl" olduğunu belirliyorsa, semantik de bu iletişimin ne anlama geldiğini belirliyor. Bunu daha derin anlatmak için biraz matematiğe girmemiz gerekecek, onun için kemerlerinizi bağlayın, koltuklarınıza sıkı tutunun. Programlama dillerini yorumlarken, kullanıcıdan bir metin olarak gelen kodu dilin sözdizimine uygun bir şekilde ayrıştırıyoruz (parsing). Bu ayrıştırmanın sonunda elimizde dilin soyut bir temsili ortaya çkıyor, bu temsile "Soyut Sözdizim Ağacı" (Abstract Syntax Tree) diyoruz. Bu noktadan itibaren diller arasındaki semantik farklılıklardan</a> bahsetmeden önce küçük bir teorik sapma yapacağım, dil semantiklerinin formal olarak nasıl tanımlandığını UMASS Amherst Programlama Dilleri</a> dersinden aldığım bir örnekle açıklayacağım. Eğer matematiksel notasyonlardan sıkılıyorsanız, korkuyorsanız, ya da ilgilenmiyorsanız önümüzdeki kısmı atlayabilirsiniz. Dilimiz aritmetik ve ikili (boolean) ifadeler içeren basit bir hesaplama dili. Dilin yapısını ifade etmek için EBNF (Extended Backus Naur Form) kullanıyoruz. e ::= true | false | n | e1 + e2 | e1 * e2 | e1 > e2 | if e1 then e2 else e3 | (e) v ::= true | false | n </code></pre> Aynı tanımı TypeScript'te yapmak istersek type Expr = | { t: "Number", n: number } | { t: "Bool", b: boolean } | { t: "Add", lhs: Expr, rhs: Expr } | { t: "Mul", lhs: Expr, rhs: Expr } | { t: "Gt", lhs: Expr, rhs: Expr } | { t: "If", b: Expr, then: Expr, else: Expr } type Value = | { t: "Number", n: number } | { t: "Bool", b: boolean } </code></pre> Programcının sözdizimine uyarak metinsel olarak ifade ettiği programları ayrıştırma (parsing) ile soyut sözdizim ağaçlarına çeviriyoruz. Aşağıda bu dönüşümün bir örneğini görebilirsiniz. Eğer parantezi sola alsaydık, çok farklı bir ağaca ulaşırdık, tabii bu ağacın anlamı da farklı olurdu. Artık dilimizin bir şekli var, ama hala bir anlamı yok. Şu noktada seneler boyunca tekrar tekrar gördüğümüz konseptleri tekrar tekrar gördüğümüz için dilin ne yapması gerektiğini hayal edebiliyoruz tabii ama, gelin matematiksel olarak nasıl tanımlandığını görelim. Burada göstereceğim notasyonu okumak için önce uzun yatay çizginin altından başlayıp, çizginin üstündeki ifadeleri altındaki ifadenin doğru olması için "gereksinimler" gibi görebilirsiniz. Burada önemli olan nokta, ⇓</code> operatörünün solundaki değişkenler e1, e2, e3</code> gibi dilimizin ifadelerini temsil ederken, operatörün sağındaki n1, n2, v</code> gibi değişkenlerin dilimizin hesapladığı sonuçları temsil etmesi. Yani buradaki her bir kural bize dilimizdeki o ifadenin anlamını belirtiyor. If-True</code> kuralını incelersek eğer, kuralın alt tarafı bize diyor ki if e1 then e2 else e3</code> sonucu hesaplandığında v</code> değerine ulaşırız, kuralın üstündeki gereksinimler de diyor ki bu ancak e1</code>in sonucu true</code> ve e2</code>nin sonucu v</code> olduğunda gerçekleşir. Kısaca örnekleyelim: if (1+2 > 2*1) then 5 else 9 ⇓ 5</code> 1 ⇓ 1 2 ⇓ 2 3 = 1 + 2 2 ⇓ 2 1 ⇓ 1 2 = 2 * 1 ────────────────────────Add ─────────────────────────Mul 1 + 2 ⇓ 3 2 * 1 ⇓ 2 3 > 2 ────────────────────────────────────────────────────────────────Gt-True ───────Num 1 + 2 > 2 * 1 ⇓ true 5 ⇓ 5 ───────────────────────────────────────────────────────────────────────────────If-True if (1+2 > 2*1) then 5 else 9 ⇓ 5 </code></pre> Resme dışardan bakınca karmaşık gelebilir, ancak her çizgi aşağıda tanımladığımız kuralların bir uygulaması olduğu için isterseniz yukarıdan aşağıya doğru adım adım küçükten büyük parçalara, isterseniz de aşağıdan yukarıya doğru büyükten küçüğe parçalara ayırarak okuyabilirsiniz. Bu kuralların her birine "Doğruluk Kuralı" (Inference Rule) diyoruz, ve bu kuralların tamamına da "Büyük Adım Semantiği" (Big Step Semantics) diyoruz. Kuralları bir araya getirdiğimizde de "Türetim Ağacı" (Derivation Tree) elde ediyoruz. Aritmetik operatörler gibi basit ifadeler için bu kuralları yazmanın çok fazla farklı yolu yok, zaten aritmetik ifadeler de dil semantiklerinin tasarımında önemli bir rol oynamıyor. Ancak özellikle fonksiyon çağrıları (function calls), referanslar ve işaretçiler (pointers), bellek yönetimi (memory management), paralel programlama (concurrency) gibi daha karmaşık konseptler için yazdığımız kurallardaki küçük farklılıklar dilin anlamını büyük ölçüde etkileyebiliyor. Bu tarz kompleks semantikler için benzer kuralları yazmak bir blog post için fazla detay olacağı için buradan itibaren diller içerisinde farklılıklar gösteren semantiklerden, ve nasıl farklılıklar gösterdiğinden sözlü olarak bahsederek devam edeceğim. Değerlendirme Stratejileri</a></h3> Ana akım programlama dillerindeki önemli bir ortak dizayn noktası sıkı değerlendirme (strict evaluation) kullanmaları, bunun dışına çıkan benim bildiğim tek popüler örnek sıkı-olmayan değerlendirme (non-strict evaluation) kullanan Haskell. Sıkı değerlendirmede, fonksiyonların girdileri fonksiyonlar çağırılmadan önce hesaplanıyor. Bir sayının karesini alan square</code> fonksiyonunu ele alalım: function square(n: number) : number { return n * n; } </code></pre> Bu fonksiyonu square(1 + 2)</code> ile çağırdığımızda TypeScript'teki değerlendirme aşağıdaki gibi yaşanıyor: square(1 + 2) // 1 + 2 -> 3 square(3) // square(3) -> 3 * 3 3 * 3 // 3 * 3 = 9 9 </code></pre> Aynı fonksiyonu Haskell'da çağırsaydık aynı sonuca varacak olmamıza rağmen çok farklı bir yol izleyecektik: square(1 + 2) // square(1 + 2) -> (1 + 2) * (1 + 2) (1 + 2) * (1 + 2) // (1 + 2) -> 3 3 * 3 // 3 * 3 = 9 9 </code></pre> TypeScript'te fonksiyonu çağırmadan önce argümanların değerlerini hesapladık, ancak Haskell'da fonksiyonu bir değer (value) yerine bir hesaplama (computation) ile çağırdık, ve ancak değerin kendisine ihtiyaç duyduğumuzda hesaplamayı yaptık. Bu örnek için "bu neden önemli, aynı şeyi hesaplıyoruz işte" diyebilirsiniz, ancak sıkı-olmayan değerlendirme bizlere programları çok farklı şekillerde yazma fırsatı veriyor aslında. Bunun klasik örneklerinden birisi Haskell'daki "sonsuz veri yapıları". Dilde bir değer ancak ona ihtiyaç duyulduğunda hesaplandığı için sonsuza kadar giden seriler yazabiliyoruz mesela 1, 4, 9...</code> gibi. Bu serilerin elemanları ancak onları hesaplamamız gerektiği noktada hesaplandığı için teoride sonsuz olan bu seriyi programımızda oluşturup, manipüle edip, istediğimiz şekilde kullanabiliyoruz. Mesela aşağıda sonsuz bir dizi kullanarak Fibonacci sayılarının hesaplandığı bir örneği paylaştım. -- Sonsuz fibonacci listesi fibs :: [Integer] fibs = 0 : 1 : zipWith (+) fibs (tail fibs) -- İlk 10 fibonacci sayısını al main = print (take 10 fibs) </code></pre> Sıkı ve sıkı-olmayan değerlendirme stratejileri kendi içinde pek çok alt kategoriye ayrılıyor, mesela Haskell yalnızca sıkı-olmayan değerlendirme değil, aynı zamanda tembel değerlendirme (lazy evaluation) dediğimiz sıkı-olmayan değerlendirmeyi aynı hesaplamayı defalarca yapmamak için değer paylaşımı yapan bir metodoloji ile uyguluyor. JavaScript'in ==</code> ve ===</code> işaretlerinin, Python'ın ==</code> ve is</code> karşılaştırmalarının farklı olmasının sebebi olan "referans" ve "değer" ayrımı da dilleri birbirinden ayırıyor. C programlama dilinde bir fonksiyona gönderdiğiniz her girdi bir değer (call by value), o yüzden fonksiyonu çağırdığınız her bir obje kopyalanıyor. Eğer bir fonksiyonu büyük bir obje ile çağırırsanız o obje kopyalandığı için performans sıkıntısı yaşayabilirsiniz hatta, bu yüzden fonksiyonu objenin kendisi ile değil, objeyi işaret eden bir işaretçiyi (pointer) ile çağırıyoruz. Diğer yandan Java, JavaScript, Python gibi dillerde ise sayılar, karakterler gibi belli girdi tipleri değer olarak gönderilip kopyalanırken objeler referans ile gönderiliyor, bu stratjinin adına ben de bu yazıyı yazarken öğrendim ki "paylaşarak çağırma" (call by sharing) deniyor. Diğer yanda Rust programlama dilinde taşıma semantikleri (move semantics) var, eğer ki siz bir fonksiyonu çağırırken girdinin açık bir şekilde referansını kullanmadıysanız Rust o objeyi o fonksiyona "taşıyor", dolayısıyla o nokta itibariyle o değere erişiminizi kaybediyorsunuz. Bellek Yönetimi</a></h3> Objelerden, değerlerden, kopyalardan, taşımadan bahsediyoruz, peki bunlar nasıl yaşanıyor? En temelde bilgisayarlar mimarilerinin izin verdiği birtakım işlemleri yapabilen basit makineler, derleyiciler ve yorumlayıcılar programlama dillerindeki kompleks semantikleri bu işlemlerin üzerine kurgulayarak bilgisayara yaptırıyorlar, bu aşamada programlarımızın oluşturduğu objeleri tutmak için bilgisayarın belleğini kullanıyoruz. Bu belleği kullanırken dikkatli olmamız gerekiyor, çünkü her ne kadar kullandığımız cihazların donanımları her gün gelişse de hiçbir şey sınırsız değil. Belleği kullanırken bir miktar belleğe ihtiyacımız olduğunda bunu alttaki işletim sisteminden istemek, o belleğe artık ihtiyacımız olmadığında ise işletim sistemine bunu geri bırakmak istiyoruz, bu işlem esnasında hata yaparsak, yani aldığımız belleğin bir kısmını geri bırakmayı unutursak, özellikle uzun süreli çalışan programlar bir noktadan sonra işletim sisteminden bellek isteyemeyecek, dolayısıyla program hata verip kapanacak, buna bellek sızması (memory leak) diyoruz. Buraya kadar tasvir ettiğim süreç "manuel bellek yönetimi" (manual memory management) dediğimiz, C, Zig, Odin gibi programlama dillerinde kullanılan bellek yönetim stratejisinin bir parçası. Bellek yönetimi arayüzünün 2 temel fonksiyonu var, ilki işletim sisteminden yeni bir bellek parçası istemek için kullandığımız malloc</code>, ikincisi ise bir bellek parçasını geri vermek için kullandığımız free</code>. Manuel bellek yönetimi stratejileri kullanan dillerde programcılar işletim sisteminden istedikleri bellek miktarını malloc</code> ile açık bir şekilde isteyip, free</code> ile açık bir şekilde geri bırakmak zorundalar. Tarihsel olarak bellek yönetiminin manuel yapılmasının programların güvenliği de dahil olmak üzere pek çok dezavantajı ve zorluğu olması dolayısıyla, pek çok programlama dili otomatik bellek yönetimi stratejileri izliyor. Bu stratejilerin ilki RAII (Resource acquisition is initialization), RAII kullanırken bellekte yer kaplayan tüm objelerin oluşturucu (constructor) ve yıkıcı (destructor) fonksiyonları esnasında bellek yönetimini yapıyoruz. Bu sayede spesifik objeler için malloc/free</code> çiftlerini ayrıca takip etmeden bellek yönetimini basitleştirebiliyoruz, C++ ve Rust bellek yönetimi için RAII kullanıyor. Bir diğer strateji ise dinamik referans sayaçları (dynamic reference counting) kullanmak. Referans sayacı tarafından takip edilen bir objeye herhangi bir anda kaç farklı noktadan erişilebildiğini program arka planda takip ediyor, bu takip esnasında objeye olan referans sayısı 0'a inerse, yani obje artık programda erişilebilir değilse, arka planda otomatik olarak o objenin kullandığı belleği işletim sistemine geri veriyor. Dinamik bellek yönetimi için son bahsedeceğim metot ise Çöp Toplayıcı (Garbage Collection) algoritmaları. Çöp toplayıcılar genelde referans sayaçlarına göre daha kompleks algoritmalar ve programın performansını kötü etkilememek için gerekli sezgisel hesaplamaları içeriyor. Rust/C++ gibi dillerde RAII'ın üzerine dinamik referans sayaçları sağlarken, Swift tüm bellek yönetimi için referans sayaçları kullanırken Java ve Go çöp toplayıcıları tercih ediyor, Python ise araştırabildiğim kadarıyla RC/GC hibrit bir metodoloji kullanıyor. Bellek yönetimi de değerlendirme stratejisi gibi dilden dile geçişlerde programlama stilinizi değiştirmenizi ve yeni metotlar öğrenmenizi gerektiren semantik bir bileşen. Bunun en dramatik örneği buraya kadar çok da detaya girmediğim Rust programlama dili. Rust kendisini diğer dillerden tip sistemini kullanarak statik bellek yönetimi yaparak ayrıştıran bir dil, Sahiplik (ownership), Ödünç alma (borrowing), ve Statik Obje Ömürleri (lifetimes) üzerine kurulu statik bellek yönetimi sistemiyle Rust dinamik bellek yönetiminin performans problemlerinden kaçınırken bir yandan da manuel bellek yönetiminin sonucunda ortaya çıkan bellek hataları gibi problemleri dilde yazabildiğimiz programları kısıtlayarak çözmeye çalışıyor, bu sebepten ana akım diller arasında öğrenmesi en zor dillerden birisi olarak görülüyor. Eşzamanlı Programlama (Concurrent Programming)</a></h3> Her ne kadar bugün karşımıza çıkan programların çok büyük bir kısmı tek-akışlı (single-threaded) programlar olsa da, aslında bugün bilgisayarlarımızda çalışıp CPU'larımızı yoran programların çok büyük bir kısmı çok-akışlı (multi-threaded). Eşzamanlılık (concurrency) programlama için "batch programming" günlerini geçtiğimizden beri önemli bir konsept, çünkü işletim sistemi, tarayıcı gibi programlarda farklı işleri yapacak alt-programlar arasında işlemcinin zamanını bir şekilde bölmemiz gerekiyor elimizde tek işlemci bile olsa. Çok çekirdekli işlemcilerle birlikte eşzamanlılığın üzerine parallellik (parallelism) ayrı bir konsept olarak ortaya çıktı, bilgisayara yaptırmak istediğimiz hesaplamaları daha küçük birimlere bölüp her birimi farklı işlemci ile işleyerek problemleri daha hızlı çözebiliyoruz. Geçtiğimiz 40 senede farklı programlama dillerinin tek-akışlı semantikleri her geçen gün birbirlerine yaklaştı, o yüzden bugün bir programlama dilinden diğerine neredeyse sadece sözdizimini öğrenip geçebiliyor, yüzeysel düzeyde benzer işler yapan benzer programlar yazabiliyorsunuz. Eğer 1980'e geri dönseydiniz, her dil farklı problemlere çözmeye, farklı alanlarda kendini optimize etmeye çalıştığı için bu şekilde hızlı geçişler yapmanız çok daha zor olurdu. Bu 40 yılda programlama dilleri bir evrim sürecine girdi, yapılı programlama (structural programming) popülerleşti, alternatif kontrol akışı dinamikleri yavaş yavaş birkaç ortak konseptte birleşti, goto</code> ortadan kayboldu; bu evrimi etkileyen faktörlerin bir kısmı nasıl daha anlaşılır programlar yazarız, nasıl daha az hata yaparız, nasıl büyük projeleri daha hızlı geliştiririz gibi daha sosyal problemlere cevap olarak yaşansa da, ciddi bir kısmı da kullandığımız donanımlara göre şekillendi. Bugün ondalık sayılarla programlama için IEEE-754 modelini kullanıyor olmamızın, programlama dillerinin 0.1 + 0.2 != 0.3</code> gibi kafamızdaki matematiksel modellere uymayan semantiklere sahip olması IEEE-754'ün donanımlarda hızlı bir şekilde çalıştırılabilmesinin mümkün olması, yoksa aslında ondalık sayılar yerine rasyonel sayıları kullanarak aklımızdaki ideal matematiksel semantiklere çok daha yakın sonuçlar alabilirdik (hatta çoğu dilde bunu sağlayan kütüphaneler var), ancak donanımın izin verdiği sınırlamalar altında bu şekilde çalışabiliyoruz. Uzuuunca bir alakasız bilgi yığınının ardından eşzamanlı programlamaya geri döneyim. Bugün neredeyse her programlama dili bir şekilde eşzamanlı programlama kabiliyetlerine izin verse de, elimizdeki durum biraz daha 80'lerdeki tek-akışlı programlama günleri gibi, her dil farklı mekanizmalar, farklı metotlar sağlıyor. En popüler paradigmalardan birisi async/await</code>, bu paradigmada async</code> olarak işaretlenen fonksiyonlar asenkron semantiklere sahip, yani bu fonksiyonları çağırdığımızda onların sonuçlarını bekleyerek işlemci vaktini boşa harcamak istemiyoruz senkron fonksiyonlarda yaptığımız gibi. Programlama dilleri async</code> fonksiyonları bir "sonlu durum makinesine" (finite-state machine) derleyerek programcının gözünde çok-akışlı programların karmaşıklığını saklayıp basit bir şekilde eşzamanlılığa erişim sağlayabiliyor. Bir diğer paradigma aktör modelleri, aktör modellerinde asenkron aktörler birbirlerine mesajlar göndererek (message passing) bilgi aktarımı yapıyor, programlama dili bu mesajların gönderilmesini ve alınmasını organize ederek eşzamanlılığı sağlıyor. Diğer yanda bellek-paylaşımlı eşzamanlılık (shared-memory concurrency) eşzamanlı akışların (threads) programın erişebildiği kaynakları okumak ve o kaynakları değiştirmek için kilitleme (locking) mekanizmalarını kullanmasını sağlıyor, mutex, rwlock, semaphore gibi veri yapılarını kullanarak erişimi kontrol ediyor. Diğer yanda atomik operasyonlar ile kilit kullanmadan da farklı akışların ortak erişebildiği kaynaklar ile programlar yazabiliyoruz. Ben var olan eşzamanlı programlama metotlarının yalnızca çok küçük bir kısmından bahsettim, literatüre gerçekten hakim birisi farklı seçenekler üzerine saatlerce konuşabilir, ve farklı programlama dilleri farklı metotları uyguluyor, optimize ediyor, onları kolayca kullanmanıza izin verecek ekosistemlere ya da dil seviyesinde desteğe sahip. Bu başta da bahsettiğim "dilden dile sözdizimi öğrenip geçebiliyorsun" mitini ciddi bir şekilde yıkıyor, eşzamanlı programlama paradigmaları tek-akışlı paradigmaların yaşadığı evrimsel süreci daha aynı derecede yaşamadı, diller benzer özelliklerde tamamen birleşmedi, hala ciddi ayrımlar, aktarılması zor, bazen de imkansız semantikler var. Tip Sistemleri</a></h3> Yazının başında da bahsettiğim gibi, tip sistemleri hakkında</a> uzun ve detaylı ayrı bir yazı yazmıştım. Yine de programlama dillerini birbirinden ayırmasına kısaca da olsa değinmek istedim. Dinamik ve statik tip sistemlerinin dilleri birbirinden nasıl ayırabildiğinin aslında pek çoğumuz farkındayız, mesela aşağıdaki Python programının eşleniği bir kodu pek çok dilde yazmak mümkün değil. if x is not str: return False else: return x </code></pre> Her şeyden önce program çalışırken x is not str</code> kontrolünü yapabilmek için dilin dinamik tipli bir dil olması gerek. İkinci olarak da programımız x: str</code> durumu için x</code>, diğer durumlarda false</code> dönüyor, dolayısıyla bu fonksiyonun tipini hesaplamayı denersek karşımıza gelecek olan tip (str -> str)&(Any -> bool[False])</code> gibi kompleks bir tip olacak, pek çok tip sistemi bu tarz tipleri ifade edecek kadar kompleks değil. Yine de sosyal olarak programlama dillerinin kullanımına baktığımızda ana akım tip sistemleri diller arasında geçiş yapmak için ciddi bir bariyer değil gibi duruyor. Python -> Java, C++ -> JavaScript gibi dil geçişlerinde kullanıcıların çok büyük şikayetler ettiklerini duymuyoruz, en azından ben şahsen bununla çok karşılaşmadım. Dolayısıyla bu yazının temasına uygun olarak tip sistemlerinin dilleri birbirinden kullanıcı geçişini engelleyecek şekilde ayırdığı durumları kısaca incelemek istiyorum. Kaynak Tipleri (Resource Types)</a></h4> Klasik tip sistemlerinde tipler sınırlı kaynaklar olarak görülmez, yani a + b</code>'nin tipini hesaplarken a: int, b: int -> a + b: int</code> şeklinde hesaplamalar yapabilirsiniz, ve bu değişkenleri tekrar tekrar kullanabilirsiniz, yani aşağıdaki programda x: bool</code> ve y: bool</code> sonuçlarına varabilirsiniz. let a = "alp".to_string(); let b = "keles".to_string(); let f : fn(string, string) -> bool = |a, b| a > b; let x = f(a, b); let y = f(a, b); </code></pre> Ancak Rust'ın tip sistemi gibi kaynak bazlı bir tip sistemi kullanıyorsanız, o zaman her değişkeninizi sınırlı defa kullanabilirsiniz, çünkü değişkenler "kaynak" olarak görülür, siz bir değişkeni bir noktada kullandığınızda değişkeni "transfer" edersiniz, dolayısıyla tekrar kullanamazsınız. Eğer ki bu programı Rust'ta çalıştırmaya çalışırsanız, let y = f(a, b)</code> hata verecek, çünkü let x = f(a, b)</code> yazdığınızda a</code> ve b</code> değişkenleri f</code> fonksiyonuna taşındı (moved) ve artık onlara erişiminiz yok. Dolayısıyla kaynak tiplerini kullanırken klasik ana akım tip sistemlerine göre çok daha farklı bir zihinsel modelle çalışmanız gerekiyor. Bağımlı Tipler (Dependent Types)</a></h4> Klasik tip sistemlerinde programların tipleri değerlere bağımlı olmaz, tiplere bağımlı olur. Yani bir fonksiyona girdi olarak 0</code> geldiğinde bool</code> dön, başka bir sayı gelince int</code> dön diyemezsiniz. Tip sistemleri kısmının başında Python'da yazdığınız gelen değere göre farklı tipler dönen bir fonksiyonu başka dillerde yazamayacağınızdan bahsetmiştim, bağımlı tipler bu tarz fonksiyonları statik tip sistemleriyle yazabilmenize izin veriyor, yani Python'daki gibi program çalışırken gelen tip üzerine kontrol yazmak yerine, statik olarak gelen değere göre farklı tipler dönecek programlar yazabiliyorsunuz. Yazıyı çok uzatmamak adına bağımlı tiplerine kabiliyetlerini gelecek bir yazıya saklayacağım, ama bağımlı tipleri kullanarak yazdığınız kod üzerine teoremler yazıp onları kanıtlamak, klasik tip sistemlerinde mümkün olmayan "Parmak Ağaçları" (Finger Trees) gibi veri yapılarını yazmak mümkün. Akışkan Tipler (Liquid Types)</a></h4> Klasik tip sistemlerinin en büyük eksilerinden bir tanesi yaptığımız hesaplamaların tiplere işlenmemesi. Örnek vermek gerekirse, filter(|x| x % 2 == 0)</code> fonksiyonu bize hiçbir zaman tek sayı dönemeyecekken, klasik tip sistemlerinde bu ifadenin tipi yine int</code> olacak, yani değerimizin sahip olduğuna emin olduğumuz bazı özellikler o değerin tipine işlenmeyecek. Bizler bu özellikleri kafamızda tutmak zorunda kalacağız. Tek, çift oyuncak bir örnek gibi olmuş olabilir, o yüzden gelin TypeScript'in kontrollerinin bizi tip güvenliğini (type safety) kırmaya ittiği bir örneği inceleyelim. TypeScript'te normal şartlar altında daraltma (narrowing) dediğimiz bir mekanizma biz değerimizi kontrol ettikten sonra tipi o kontrole göre güncelliyor, ancak bu mekanizmanın limitleri var. type A = { a: string | null }; type B = { b: number | null }; type U = A | B; function pick(u: U, k: 'a' | 'b') { if (k in u && u[k] !== null) { // güvenli, ancak TypeScript tarafından reddediliyor. return u[k]; } return undefined; } </code></pre> Tabii bu TypeScript için uzun vadede düzeltilebilecek bir implementasyon eksikliği de olabilirdi, ancak akışkan bir tip sistemi olmadığı sürece bu tarz tip güncellemeleri her zaman belirli şartlar altında çalışmayı hedefleyerek yapılacak, dolayısıyla çalışmadıkları örnekler üretmek her zaman mümkün olacak. Akışkan tip sistemlerinde tipler üzerinde yapılan işlemlere göre güncellendiği için tip güvenliğine zarar vermeden bu tarz programlar yazmak mümkün olabiliyor. Efekt Tiplemesi (Effect Typing)</a></h4> Efekt tiplemesi çevresindeki kavramları belki de EffectTS</a> gibi teknolojiler bağlamında duymuş olabilirsiniz. Programlama dillerinde bir "efekt" programın sahip olduğu bir kabiliyet demek. Bu efektler dosya okumak, hata vermek, konsola yazı yazmak, rastgele sonuçlar vermek, sonsuz döngüye girmek gibi farklı farklı kabiliyetler olabilir. Efekt tiplemesi kullanan programlama dillerinde fonksiyonların sahip olduğu efektler o fonksiyonun tiplerinin de bir parçası oluyor, bu sayede bir fonksiyona belli bir kabiliyeti vermek için onu açık bir şekilde tipin parçası yapmanız gerekebiliyor, ve bir adım ötede her efekt için ayrı çözümleme stratejileri (effect handling) geliştirip programın çalışma mekanizmalarını bunlarla yönlendirebiliyorsunuz. Diğer</a></h3> Yazı fazlaca uzadı, yoksa aslında farklı dillerdeki özyineleme optimizasyonları (tail call optimization), tanımsız davranışlar (undefined behavior) gibi konulardan da bahsetmek, makro sistemlerinin o dilde yazılan programları nasıl değiştirebildiğini açıklamak, defer</code>, yield</code> gibi ana akımın dışında kalan yapıların dillerde farklılıklar gösterebildiğini tartışmak da istemiştim, artık onları sonraki yazılara bırakıyorum. Dilleri Anlamak</a></h2> Yazıyı bitirmeden önce en başta bahsettiğim bir probleme geri dönmek istiyorum, kullandığımız programlama dillerini anlamıyoruz. Dillere kapalı kutular gibi baktığımız, dilin sözdizimini öğrenip de derleyici ve yorumlayıcıyı şikayet etmeden çalıştırmayı başardıktan sonra o programın gerçekten ne yaptığını anlamaya çalışmak yerine atari oynar gibi doğru cevabı görene kadar farklı konfigürasyonlar deneyerek programlamaya çalışıyoruz, bu özellikle programlamaya yeni başlayanlarda çok daha yaygın. Halbuki kullandığımız programlama dillerinin hepsinin, yer yer garip ve ilginç de olsa, kesin semantikleri var. Bir programı yazdıktan sonra onu incelediğimizde ne yapacağının kesin bir tanımı var, bunları öğrenmek de çok zor değil. Bunun için klasik 2 tane örneği alıp onları demistize etmeye çalışacağım. JavaScript: "b" + "a" + +"a" + "a"; // -> 'baNaNa'</code></a></h3> JavaScript'in gariplikleri popüler kültürde bir şaka malzemesi haline gelmiş durumda, ben en azından şahsen birkaç ayda bir bunlarla ilgili yorumlar görüyorum, insanlar genelde çok şaşırıyor, ya da dilde bir saçmalık olduğuna inanıyor, halbuki oturup biraz incelediğimizde semantikler hiç de zor değil. JavaScript'in en önemli dizayn hedeflerinden bir tanesi programların mümkün olduğunca hata vermemesi, çalışabildiği her durumda çalışması. Bunu dilin tip sisteminin dinamik olmasıyla birleştirdiğimizde görüyoruz ki bunu yapmanın en iyi yolu "gizli tip çevirileri" (implicit type conversions). JavaScript pek çok dilin tip hatası vereceği durumlarda değerleri otomatik olarak string</code> tipine çevirerek bu operasyonların hata vermek yerine yanlış da olsa sonuç vermesini sağlıyor. "b" + "a" + +"a" + "a"</code> kodu JavaScript için şu şekilde parçalara ayrılıyor: "b" + "a" + (+"a") + "a" </code></pre> Sonrasında programı değerlendirmeye başlıyoruz, +"a"</code> aslında bir "açık tip çevirisi" (explicit type conversion), +</code> operatörü sağındaki değeri number</code> tipine çeviriyor. string -> number</code> çevirisi için JavaScript parseNumber</code> fonksiyonunu kullanıyor, dolayısıyla +"123"</code> bize 123.0</code> veriyor, benzer şekilde +"a"</code> da not a number</code>, yani NaN</code> olarak değerlendiriliyor. "b" + "a" + (+"a") + "a" "b" + "a" + NaN + "a" </code></pre> İki string arasında +</code> operatörü onları arka arkaya bağlıyor, yani "b" + "a" = "ba"</code>. "b" + "a" + NaN + "a" "ba" + NaN + "a" </code></pre> Ancak bu noktada bir tip uyumsuzluğuyla karşılaşıyoruz, toplama operatörü string + number</code> bağlamında tanımlı değil, o bağlamda JavaScript önce number -> string</code> dönüşümünü yapıp sonra string + string</code> operasyonunu uyguluyor. "ba" + NaN + "a" "ba" + "NaN" + "a" "baNaN" + "a" "baNaNa" </code></pre> Sonucumuza varmış olduk, baktığımızda aradaki tüm adımlar aslında kavranabilir ve basit adımlar, anlaşılması zor olan dilin neden ve nerede gizli tip çevirilerini yaptığı. Python</a></h3> Yazıyı kapatmadan önce bir de Python'la ilgili konuşmak istedim, bu sefer JavaScript'in tam tersi şekilde. Genelde dilde operatörler İngilizce kelimelerle tanımlandığı için Python'un yeni başlayanlar için daha kolay olduğu, İngilzice gibi yazılabildiği bir mit var, baktığınızda aslında Python JavaScript'ten çoğu konuda çok farklı değil. Gizli tip çevirileri konusuna bakarsak Python da if "a" + "b" then 1 else None</code> gibi durumlarda tip çevirileri yapıyor, "a" + "b"</code> ifadesini önce bool</code> tipine çevirip sonrasında sonucu hesaplıyor. Brown Üniversitesinden çıkmış Python semantiklerinin problemlerini ve garipliklerini çalışan çok detaylı bir makale</a> de var hatta. Dolayısıyla programlama dilleriyle ilgili yorum yaparken yalnızca yüzeysel seviyede sözdizimlerini ya da anahtar kelimelerin kullanımını değil, dilin semantiklerini değerlendirmek gerektiğine kısaca değinmeyi mantıklı mantıklı gördüm. Kapanış</a></h2> Bazı yazılarımı biraz daha toplu, düzenli, birkaç haftada yavaş yavaş düzenleyerek, geri bildirim alarak yazıyorum, bazıları ise o an aklıma gelenleri arka arkaya döktüğüm, düzensiz pek çok farklı fikir ve bilginin bir araya geldiği yazılar oluyor, bu yazı bunlardan ikincisine biraz daha yakın oldu, dolayısıyla yer yer hatalar olabilir, mantıksız gelen noktalar olabilir, sonuca bağlanmayan tartışmalar olabilir. Eğer bunlar gözünüze çarptıysa bana yorum olarak akeles@umd.edu</a>'ya email atabilirseniz mutlu olurum, hataları düzeltmeye, soruları cevaplamaya çalışırım. Sevgiler. Breaking Verifiable Abstractions 2025-08-31T00:00:00+00:00 Abstractions are one of the central ideas of computer science as well building and engineering complex systems in general. In essence, an abstraction is an interface over a system or process, somehow enhancing the mechanisms in which we interact with the underlying system. A famous example of abstraction is a programming language, which abstracts details of how the underlying machine executes the provided code. Loops and function calls are compiled into lower lever primitives of comparisons and jumps, the memory allocators takes care of storing and loading data from the memory, a majority of the programmers in 2025 has never seen a single line of the instruction set architecture of the machines their code works on, and the majority of code today does not run on physical machines, but virtual machines like browsers we built on top of them. An important aspect of an abstraction is its leakiness, which, when I think about it, does not really do justice to the abstractions. Wikipedia page</a> on Leaky Abstraction states: A leaky abstraction in software development refers to a design flaw where an abstraction, intended to simplify and hide the underlying complexity of a system, fails to completely do so. This results in some of the implementation details becoming exposed or 'leaking' through the abstraction, forcing users to have knowledge of these underlying complexities to effectively use or troubleshoot the system. </blockquote> Followed by the Law of Leaky Abstractions by Joel Spolsky: All non-trivial abstractions, to some degree, are leaky. </blockquote> Given that all abstractions are leaky, I feel that we should not really talk about what an abstration leaks, but rather what it hides, because that is the point we really care about. I think I came close to this idea when writing The Lies About Abstraction</a> but failed to grok, or articulate it at the time. Abstractions really only ever preserve the properties we measure. Let's take SQL as an example, it is an abstraction for communicating with a storage system, we use it to instruct the system to store and load data. SQL engines make strong guarantees on the "functional correctness" of the engine, it should not matter if we are using 2.12 or 3.71, SQLite strongly tries to ensure that the same set of queries would result in the same set of answers. It does not make strong guarantees on the time of the query though. If the underlying model changes, it is possible that your query is slower or faster now. If you, adhering to Hyrum's Law</a>, relied on observable but not guaranteed behavior, you might find yourself at odds with the users of your service. Such as scenario is prevalent in virtually all domains of software engineering. Software systems are typically evolving systems with a set of primary objectives, and in the process of this evolution any behavior that is not explicitly tested or guaranteed is subject to changes. Consider the concept of semantic versioning</a>, which states that a MAJOR version is when you make incompatible API changes</code>, which assumes a specific definition of compatibility that boils down to the fact that the new version will not throw a compile error, at least from the perspective of the user. More concretely, the secondary condition over compilation is "documented behavior shall not change", which is a social condition that is far from machine checkability, hence the truly guaranteed behavior is always the tested ones. With that, let me get a step closer to the point. A few months ago, I wrote my ever favorite blog post on the limits of AI-assisted programming which I promptly gave away the answer in the title, Verifiability is the Limit</a>. I won't reiterate it all here, but the central idea is "what you can verify marks the limit of what you can create" regardless of the method of creation, albeit human, LLM, or magic, the genie of the magic oil lamp was a cautionary tale for all of us. Closer to the end of the blog post, I posed a question, and gave some preliminary thoughts on possible answers. If verifiability is the limit, if it’s the bottleneck of using LLMs for programming, the natural question is how do we raise the limit, how do we make it easier to verify? ...We should rely much more on declarative random testing methods such as property-based testing, where the programmer defines a predicate that should hold over all possible inputs, and this predicate is tested by generating random inputs and passing them to the program. Such methods have been used to enhance the reliability of programs in many domains, but they haven’t caught up with the software engineering community. The advantage of such methods is that having one general predicate is much easier to inspect and understand than many unit tests, in addition to the added testing strength... </blockquote> For the past month, I have been at Datadog working on an LLM-guided continuous optimizer called BitsEvolve (see the linked blog post</a>) powered by observability and random testing, and day by day I became more convinced that the future holds crazy possibilities for combining LLMs with verifiable abstractions, which I see surprisingly little. The industry as a whole has been spending an insane amount of time and effort making it easier to program by prompting, because prompting solves a multitude of problems where programmers traditionally have to specify many details they do not really care, such as what type of container to use for a specific scenario, and instead only convey their intent, which the LLM acts as the programmer making such decisions, letting the programmer only focus on high level details. Similar to how "higher-level languages" abstract away memory management, prompting abstracts away anything and everything you don't specify. This property of prompting, which is its central value proposition, is also its greatest weakness even without hallicunations, because there are no executable semantics of a prompt. Given the context, the temperature, the model, the random number generator, the mood of {{insert your favorite CEO}}, the prompt will lead to different execution semantics. Programs on the other hand, have testable semantics, they are executable, analyzable, are quite strict in what they do, and how. Shortly, the prompt-to-program abstraction is not a verifiable one, which is what stirred up the discussion in the first place. Well I already gave away the spoiler, why are we fixating so much on prompts when we could just use programs instead? People already use LLMs for translating code between languages, but they still rely on the LLM to correctly do the translation even though the translation has one of the most popular correctness properties of all the time, equivalence that we can programmatically test for. This problem is traditionally called translation validation, and is far from being solved, we definitely do not have the capability of proving two programs will behave exactly the same way for every single input (it's undecidable, so we will never have that capability). We, however, have the capability of doing differential testing, which has given rise to some of the greatest testing successes of the industry by finding bugs in C compilers and SQL engines, as well as being a central piece of modern practices for developing high assurance software. I posit that some of the most interesting use cases of AI will emerge from using programs as sources instead of focusing on prompts. Translating entire libraries and programs across ecosystems through a continuous feedback loop that is based on counterexample guided program synthesis.</li> Optimizing programs for cache friendliness or memory consumption, securing them against side channel attacks, automatically switching between equivalence programs with different characteristics of readability or density, auto-parallelization of single-threaded programs.</li> Breaking existing abstractions at lower levels by switching them with verifiable translations, instead of accepting the bytecode or assembly emitted by the compiler as a given, using the instrumentation and observations from the program for doing machine-level verifiable optimizations similar to what a JIT compiler would do.</li> </ul> Let's make no mistake, there are already people out there claiming they can do these things, or that LLMs will be able to do these things, I do not believe such claims without the accompanying translation validation. Verifiability is the limit, even if LLM capabilities increase a 1000x from today, it is impossible to trust that a change in your machine executable would fit your intent, or that you could even specify such changes in many cases. "Machine go brrr" is not the specification we should be using, tests and measurements with concrete results are. The bottleneck of these approaches today are not just LLMs being unable to apply such changes, but also the fact that random testing still has a long way to go. The translations I mentioned rely on fast feedback loops to be operational, while getting the fuzzers to generate complex inputs are still research projects. Catching concurrency bugs is still a relatively developing area, building testing targets for comparing functions or programs across languages is non-trivial, deterministic simulation testing is here to stay, but it's history is a very short one with a few promising companies pushing it through. Programming languages are as impure as they come, hurting the testability at all costs, as much as possible, although functional programming community as well as effect systems are pushing for explicit impurity, I am not sure how to test two unordered hash maps in two languages acting with the same characteristics. Let me tie the two parts of the article as I finish. Although all abstractions are leaky, the measure of an abstraction is its testability. If we can test some behavior, we can guarantee it. Such guarantees allow us to look beneath the abstraction and break it while keeping the guaranteed behavior intact. I hypothesize that given sufficient improvements in random testing, this break the abstraction, optimize what you can observe has the potential to become a major appraoch in optimizing programs and being a centerpiece of programming. A Better Vocabulary for Testing 2025-08-16T00:00:00+00:00 Contemporary vocabulary for talking about software testing has bothered me for a long time. The concept of a unit in unit test is not really defined, integration tests are integrating arbitrarily scoped modules, the concept of an E2E test makes sense, but it very much underspecifies the actually tested behavior as well as methods for testing it, are you using automated agents, human supervision, predefined set of actions, random exploration... it's all sweeped under the rug. On the other side you have your stress tests, load tests, peneration tests etc. but there is no proper classification in the wild, it all seems to be based on "vibes". A short web search reveals a "level" based classification as seen below, as well as an "ad" from Atlassian that gives you 7 "types" of software tests</a>. Can we go beyond this, definitely. Should we, I think yes. We should have a vocabulary that is actionable, you should be able to upgrade or downgrade your tests based on the availability of resources, there should be a recipe for the available set of options given your situation. Of course, this article will be very much biased towards a certain category, random testing which I happen to be working on for a while now. My view is as follows, we can roughly create 5 different categories, some of which are orthogonal to each other, some of which "branch" within. Scopes of Testing</a></h2> The first category is a the scope of the test unit, this is similar to what the classic unit/integration/e2e testing classification tries to vaguely define, but I think it fails at it. There are two axes to the scope, one of them is based on the constructs of the programming language we use, we might test a function, a class/struct/type, a module, or a system. The secondary axis is if the scope is a stateful, or a stateless one. You might have stateful functions, and you might have stateless systems, although we expect most functions to be stateless and most systems to be stateful. It should be noted that these scopes also vary a lot, one could argue that the entry function of a large system is the same as the system itself, but here is why the scopes are useful; When talking about testing anything, we typically talk about inputs and outputs, but the space of inputs are actually very different. Functions, especially stateless ones, consume arbitrary structures in your programming language. Systems receive interactions or directives, which is typically some serialized piece of data that is parsed and validated. This actually allows system testing to be much more restrictive in the list of inputs because it includes a natural discriminator that can shrink the input space, while function signatures in programming are very often too relaxed, the input type of the function includes many potential inputs that the function will never consume. When state comes into play, your testing can be made isomorphic to the previous one by turning a test of function f</code> with state s</code> consuming input x</code> and producing output y</code> and transforming the state to s'</code> into another stateless function g</code> that either produces initial the state s</code> or the state pair (s, s')</code> becomes a part of the input-output. This type of state(ful/less)ness transformation depends on the complexity of your system, because testing an input requires you to produce it. Simple states can be turned into inputs that you can construct, but creating a complex state that represents a realistic workload of your system is non-trivial, and for many systems outright impossible. In such scenarios, instead of transforming your test to be stateless, you treat your system as a simulation. You pass in messages that contain directives or interactions based on the public API of your system and get answers or confirmations in multi-message scenarios, you can check intermediate states of the system as well as the initial and final ones, ensuring your invariants, preconditions and postconditions hold. Similarly for making the testing of your functions more tractable, you can employ Design by Contract (DbC)</a> which is natively supported in C++26, D, Kotlin, and Racket, with library support in Python and Rust, and many others I probably haven't heard. In DbC, we can write the assumptions we make on the inputs to the functions, which might come up as unchecked pointer dereferences or code comments promising that such inputs are not possible, as annotations to our functions, which can be checked on runtime, and sometimes even compile time through static analysis. DbC allows us to constraint the input space to the functions, which as I said are at many times much larger than the reality. Imagine creating a dictionary of items you read in your system, along with a list of keys that were created alongside the initial hashmap. To the view of your programming language, every lookup in your hashmap is fallible, when in reality we know all of them should succeed. This creates a tension between you and the programming language, where you feel like you are fighting with it. Using DbC, more expressive type systems, and better domain modeling solves much of these issues. Purposes and Hypotheses of Testing</a></h2> Testing, at some level, evaluates or measures "something". It creates a hypothesis that can be falsified by running the test, and the purpose is to falsify this hypothesis. There are different domains that we can express some hypotheses on; the simplest one is functional correctness, which evaluates if the function produces the right output given some set of inputs. There are other domains such as time of execution, which we can test the performance of our system under test, or security, which we can check if the system is resistant to potential attack vectors. Most large scale systems are distributed systems that are bound by the laws of physics that can cause delays, drops, faults in the network, and even single machine systems experience file system fauls, disk corruptions etc. which we can test our system's resilience against. The concept of chaos testing mostly refers to testing the robustness of a system in the case of unexpected faults. Based on the domain of interest, such purposes or hypotheses varies a lot. In a security scenario that tests a potential timing side channel, the hypotheses is that the test will constuct an environment in which the attacker will be able to extract information out of the time to execute two different inputs. When testing for accessibility of a system or a webpage, the hypothesis is that a user with some disability that prevents them from leveraging the full set of system interactions will not be able to perform an action they would need or want to. Each test, of course, requires a domain specific oracle based on the scenario. Oracles of Testing</a></h2> Once we have an hypothesis at hand, we need an oracle for it. The natural oracle is a human. Although it's an understatement to say that this is the job of QAs in software companies (they also program oracles by creating automated scenarios), it's also very much they excel at. They hand-craft scenarios to test against the system in the hopes of discovering an "unusual" or "unwanted" scenario. Some of these scenarios may be more formal, for example it is commonplace that your software should not be stuck or unresponsive at any moment, but some others will be based on intuitions like "this page transformation is weird compared to the others". I like to call this type of testing where the oracle is the judgement of a human user "tinker testing". Although it's not typically included in the discussions of testing, tinker testing is a major part of programming, because a traditional software test is ultimately a codification of tinker tests. If you are not doing test-driven development (I mostly don't), it is very probable that you start by implementing a piece of functionality, create a small test where you can change the parameters very easily, maybe by changing them by hand if the compilation is very fast, or by using some functionality for reading inputs from the command line or web user interface. We play around with the artifacts the software produces for understanding it better, because not every piece of functionality in software is intentional, or explicit. Many code has unintended consequences, which is partly why we test it. The tinkering allows for (1) checking that the artifact conforms to the intended consequences, and (2) finding out what kind of unintended consequences we ended up sneaking into the artifact. The more "dense" the code is, the higher the possibility of introducing unintended consequences, which increases the requirement for tinker testing as well as testing in general, including applying TDD, but that's a discussion for another day. The second type of oracle is examples. When you write your unit tests with a concrete set of values to say add(3, 5) == 8</code>, you are doing example-based testing, as you were doing tinker testing when you were typing 10 + 32</code> to your calculator for checking that it indeed tells you the result is 42</code>. You can write example-based oracles for all kinds of hypotheses, even though we mostly think of them useful for functional correctness. You can say measure the time of the execution of a function for specifying upper bounds such as time(f(1337) < 0.5)</code>, or time(sort([])) < time(sort[10, 9, 8, 7, 6, 5, 4, 3, 2 1])</code>. You can check if your SQL sanitizer is indeed catching specific SQL injections you can conjure. However complex the scenario is, there is typically a way to create an example for it. Some approaches has taken this idea very far and that is why we have expect testing</code>, golden testing</code>, or snapshot testing</code> in the testing literature today, where the testing workflow evolves by verifying that the output conforms to the expectation of the tester for the given user, and the testing framework saves the snapshot to a file by codifying the current state of the program as the correct behavior. Although the primary use case for expect testing seems to be catching regressions, it also gives us a way to create more examples very easily, which actually possesses many hidden or unexpressed semantics of our program within, so they make for interesting oracles. For more on expect testing, this blog post</a> from Jane Street is a nice read. A third type of oracle is inline assertions, which actually ties back to DbC I've talked at the end of the scopes. A precondition is an assertion at the beginning of a block, a postcondition is an assertion at the end of a block, an invariant is an assertion that should hold both at the beginning and end of the block, although it may be broken in the middle. An inline assertion is an assertion you can put anywhere in your program, there are companies in high-assurance part of the industry that advocate for aggressive use of inline assertions even in production, I advise everyone to read the Tiger Style</a> documentation, they have very good principles for writing robust and safe software. Inline assertions are not really coupled with a testing method by themselves, as opposed to the other oracles I mentioned so far, both of which are oracles and testing methods at the same time. Tinker Testing couples human intuition and tinkering as the testing method with human judgement as the oracle, and Example-Based Testing couples input-output examples as both the oracle and the testing method, because the user is producing the input (the method of testing) alongside the expected output (the oracle). Expect testing somewhat couples these approaches, the user still provides the input, but the oracle is now their judgement at first, and the state of the program at the time of snapshotting later. Inline assertions can be used alongside other methods of testing, because they are a method of specification but not a method of producing inputs for the system under test. The fourth type of oracle is properties, which brings us to Property-Based Testing. Properties are universal statements that talk about the code under test in abstract terms rather than concrete inputs in the case of example-based testing. Some properties may be global invariants, which means they are like inline assertions you check at the end of each unit of execution. Examples of these are "program never crashes" in many languages (maybe not Erlang I guess?), or "never dereference a null pointer", or if you are running a physics simulation it may be that you want to conserve momentum at each time step, or you may have any other type of global consistence metric based on your domain. Other properties are more local, they are metamorphic properties that relate the outputs of two programs/functions to each other. For instance, the associativity of addition tells us that a + (b + c) = (a + b) + c</code> (which doesn't hold for IEEE-754 floats, so be careful), or the UNION</code> of two SQL queries should be a subset of their UNION ALL</code>. We have other canonical properties like roundtrip properties which tells us that two functions that are the inverse of each other result in the original input, for instance a lossless compression algorithm should always have the property that decompress(compress(bytes)) = bytes</code>, or adding and subtracting the same quantitity should result in the original quantity a + x - x = a - x + x = a</code>, which also amounts to some sort of cancellation effect. Compatibility is another sort of canonical property, different procedures that are functionally equivalent should always return the same results given the same inputs, so all sorting algorithms should always return the same result on the same list quicksort(l) = bubblesort(l)</code>, or parallelizing some functionality should not change its observable behavior par(f, x) = f(x)</code>, or your very complex distributed system should provide the same observable behavior as its simpler, single-node version. This type of compatibility, sometimes called differential testing, or other times model-based testing, is immensely powerful. It has found rendering bugs in browsers, compiler bugs in GCC, optimization bugs in SQLite, it has been used to test large scale systems like S3 object storage or the recently released verified permissions engine Cedar by AWS. The last bit of canonical property I'll mention is idempotency, which shows up on sorting a list, sort(sort(l)) = sort(l)</code>, but is generally considered a core property of many distributed systems due to its ability of creating a logical "always once delivery" layer on top of the physical world. Similar to inline assertions, properties also do not specify a specific method of testing. So given some property p</code>, you can actually use it in Tinker Testing, that is why React is running your effects twice, so that you can realize you are invalidating the React property that effects should not mutate the state, but rather create a new one. You can use it in your example based tests by just supplying the inputs and letting the oracle be the property. Property oracles also give you more automated, much more powerful methods for testing your systems. So far I have only talked about first-order oracles, those that are manifestations of first-order logical propositions that talk about our code. In fact you can write properties in more powerful logic systems such as modal logics that can express temporal specifications about your program, some of these are equivalent to properties we already mentioned, a global invariant is the same as an ALWAYS([]) modality in linear temporal logic, which LTL people say is a "safety property", but they can also express "liveness properties" that can talk about events that should happen every once in a while or at some indefinite point in the future. I don't have much of a background here, I suggest you check out Hillel Wayne's writings</a> on TLA+ for learning more about these specifications, which are again very much used in distributed system specifications. Methods of Testing</a></h2> In the previous section, I have made a distinction between a method of testing (providing inputs to a test) and an oracle of testing (how to decide if a test fails), and already reveal Tinker Testing and Example-Based Testing as two methods of testing. What are the other ones, which you can use for testing properties or inline assertions? I will start from another type of testing we typically don't count as tests in software, which is static analysis. A static analysis tool analyzes a piece of code and decides if it passes a certain "test". A type system is in fact a "test", it tests if your program is well typed, meaning that no execution will lead to a type level failure. There are two ways to see a type system as a test, for one you can use dynamic typing in "mostly statically typed" languages using std::any</code> in Rust, Dynamic</code> in Haskell, void*</code> in C. These mechanisms allow you to bypass the type system, which means your program can now actually have type errors in runtime if you don't maintain them correctly and cast to an incompatible type. On the other side, you can plug a static analysis tool on top of your statically typed language such as Infer on C++ or add a static type checker on top of your dynamically typed language such as mypy/ty on Python and see that they reject programs that your looser system would accept. Well which property are these type systems holding? The reason I wanted to put them into discussion is to sneak in a discussion of a new generation of type systems that use refinement types (please read more on these) that can statically prove your properties, invariants, or contracts. So you still write the same properties or contracts as your oracles, but the method of checking is now static, Liquid Haskell, Flux in Rust, Dafny programming language are those I can think of, I highly advise checking them out. There are also model checkers like CBMC and Kani that can statically check some of your invariants and properties when expressed in terms they can process. You can also use enumeration, which theoretically is complete (if you have infinite time and compute), because it enumerates your types. So enumerating integers would look like 0, 1, -1, 2, -2...</code>. It is possible to write enumerations for practically all types in our programs, although cyclic types like graphs may make it very hard, I believe it should be possible to have a complete ordering of a type, which gives you the enumeration (some very clever PL person is going to pull out an example that makes me wrong here, please do so I can add a small note on it, or better write the note for me and I'll just insert it here). Or, and this is a pretty big category on its own, you can use randomness. Instead of going through an order like 0, 1, -1...</code> you can be crazy and do 42, -1337, 22222222...</code>. Randomness makes testing properties very scalable, because you can generate many small structures very fast, and can generate large structures that can reveal many interactions with your in a slower fashion. You also don't need to be completely random, because instead of generating, you can also mutate existing structures. So you can start by generating a few inputs, and once you have enough of them, instead of generating from scratch you can start using the old ones you had already generated by tweaking them. Imagine you have a large list, you can just remove some of it, add some more items to it, or swap out a part in the middle. When selecting which inputs to mutate, it would be really really nice if you had a measure of how "good" they are, so that you could prioritize those inputs. Well people have been thinking about this for a long time, and one of the best measures we have right now is called branch coverage, existing random testing systems look at how many branches or basic blocks your program hits, and prioritizes inputs that lead to new, unexplored paths. Congratulations, you have now learned about Coverage Guided Fuzzing. A great group of fuzzing researches have created one of the best fuzzing resources in the internet, the Fuzzing Book</a>, if this concept sounds interesting to you, please check it out. I have mentioned that the differential testing has found many correctness bugs in production systems such as GCC before, similarly, researchers and security engineers have found thousands of bugs in especially C/C++ programs but across a wide variety using coverage guided fuzzing, if you check the trophies section of any fuzzer (AFL</a>, AFL++</a>, OSS-Fuzz</a>) you will see a ton of names you know. Even without smart randomness, a well-written data generator coupled with strong properties lead to many bugs, CSmith testing GCC and Clang is one example, SQLancer finding hundreds of bugs across production DBMSs is another. Not all testing has to be at the scale of a system as I mentioned at the beginning, you can test functions, modules, systems in different ways. When testing a function, you write random data generators for your inputs types, randomly generate inputs in a loop trying to falsify your properties. In most languages there are already methods for "deriving" random generators, so writing a property is most of your work. You can try to pattern match on the canonical properties I mentioned in the previous section or try to abstract your already written example-based tests to general patterns that can be tested with random data. There are popular Property-Based Testing libraries in virtually any language, Hypothesis in Python, fast-check in Typescript, jqwik in Java, proptest in Rust, and of course the root of all, QuickCheck in Haskell. This page</a> has a very comprehensive list if you are curious. These libraries take a lot of work away from you and let you focus mostly on expressing your properties. When testing a system or a module, you need to build a "simulation environment". A module is going to have a set of APIs, and a system is going to have a set of possible interactions, and they will very much possibly be stateful. There are two methods of testing your properties against these stateful artifacts, (1) is to maintain an internal simpler model of the system, which we are actually using for testing Turso</a>, a rewrite of SQLite from scratch, and use the model for making decisions on what to generate, what to expect from the system and so on. (2) is to use the system's internal model for making those decisions by querying the system, which is what SQLancer actually does for testing a variety of DBMSs, but is prone to dark points in the system in case the problem you are testing is correlated with the internal model the system under test keeps. When testing the DBMS, we keep a list of properties we expect the DBMS to have, and generate random SQL statements that will check for those properties. Taking a simpler module at hand, for example if we were testing a stack, we would just keep a small set of interactions (pop, push x, empty?</code>) that we would continuously pick from to discover an interaction we hadn't before. I had already mentioned that in real physical systems your inputs are not just user messages to the system, the whole physical environment is, so testing for inputs the user sends is not enough, you also need to test what happens when one of your machines shut down, or when you have some file system fault, or when you experience network degradation. The throttling option in your browser, chaos testing that shuts down some of your machines, killing a process from outside, are all examples of how you can provide those physical inputs. High-assurance systems need these tests because the users are paying for the assurance alongside the functionality. A prominent approach in this space is called Deterministic Simulation Testing (DST), which artifically injects faults in your system for testing such inputs we normally don't. To my knowledge this approach has been popularized by FoundationDB, but currently TigerBeetle and Antithesis are the two places you can learn more about these, so I will leave it at that. With that, I conclude my new vocabulary proposal mashed with some advertisement of random testing. I believe software testing has a long way to go, and that we have only scratched the surface of the set of behaviors we are testing, and that random testing is going to be a key part of this future. I hope you had fun reading this, if you have any comments or suggestions please shoot me an email at (akeles@umd.edu</a>). Note: If you liked this post, I highly recommend this post on Unit and Integration Tests</a> by Matklad. Bilgisayar Mühendisleri için Hafif* Ekonomi 2025-08-09T00:00:00+00:00 Yazılım endüstrisi inanılmaz büyük, dağınık, neredeyse her endüstrinin içerisine kendisini anahtar bir oyuncu olarak yerleştirmiş bir endüstri. 2011 yılında A16Z'nin kurucularından Marc Andreessen "Why Software Is Eating The World" (Yazılım Dünyayı Neden Ele Geçiriyor)</a> yazısında sırtını yazılıma dayayan Amazon, Netflix, Spotify gibi devlerin nasıl ortaya çıktığını ve büyüdüğünü benim anlatabileceğimden çok daha iyi anlatıyor. Bugün benzer bir soruyu "Yapay Zeka Yazılımı Ele Geçirecek Mi?"</a> ekseninde soruyoruz, yazılım endüstrisine ne olacak, sektördeki işler nasıl değişecek, 2030'da hala kod yazıyor olacak mıyız onu anlamaya çalışıyoruz, ancak bu tartışmaların altında yatan ekonomik dengeleri yeterince iyi anladığımızı düşünmüyorum. Bu sebeple oturup biraz sektörün ekonomisi nasıl işliyor, kim kime, niye para veriyor bunu araştırmak, araştırırken de yazmak istedim. Özellikle işlerimize ne olacak, bilgisayar mühendisliği yazdığıma pişman olmalı mıyım diyen öğrenci arkadaşlara faydası olmasını hedefledim. En azından ben bölümü okurken okusam faydası olacak şekilde yazmaya çabaladım. Konuyu birkaç eksende ele alacağım: Endüstriyi Resmetmek</li> Omurga Yazılımlar</li> Açık Kaynak</li> Maaşlar</li> Yapay Zeka</li> </ul> Endüstriyi Resmetmek</a></h2> Girişte bahsettiğim gibi yazılım endüstrisi büyük ve dağınık, detaylı sektörel analizler</a> yüzlerce farklı alanda binlerce şirketi farklı segmentlere ayırıp onların sektördeki pozisyonlarını inceliyor. Ben çok daha basit bir harita çizmeye çalışacağım. Endüstriyi önce 2 temel parçaya bölelim, ön-yüzü (buraya tüketici yazılımları diyeceğim), ve arka yüzü (buraya da omurga yazılımlar diyeceğim). Tüketici yazılımları bizlerin günlük hayatta karşılaştığı yazılım ürünleri. Bu ürünler bizim gündelik problemlerimize, ihtiyaçlarımıza, isteklerimize dijital çözümler üretiyor, bir noktada ben bu ürünleri bir çeşit "dijital dönüşüm" olarak görüyorum. Word, Google Docs gibi editörlerin daktilonun yerini alması, Wikipedia'nın geleneksel ansiklopedilerin geniş, çeşitli, elimizin altında anlık erişilebilir dijital bir hali olması, sosyal medyanın mahalle meydanlarındaki, kahvelerdeki, günlerdeki konuşmaları dijital ortama taşıması, Netflix, Spotify gibi platformların sinemalar, tiyatrolar, konserler gibi eğlence mekanlarının alternatifi olarak görev görmesi, öğrencilerin ChatGPT'yi özel ders hocası gibi kullanması... Bu uygulamaların neredeyse hepsi bizlerin günlük tecrübelerimizi dijital ortamda yeniden oluşturma, yazılım ürünlerinin ekonomik dinamikleri sayesinde çok daha ucuz fiyatlara "benzer" tecrübeler sunma peşinde. Bu uygulamalar için yazılım, ya da kod, aslında bir araç, bir amaç değil. Nitekim Netflix benzer hızda benzer tecrübeyi daha ucuza CD'leri kargolayarak evimize kargolayarak sunmaya devam edebiliyor olsaydı, dünyanın en büyük veri merkezlerini kurmak için uğraşmazdı. E peki tüketici yazılımları için yazılım bir amaç değil de araçsa, yazılımın hangi özellikleri onu alternatif çözümlere göre ekonomik olarak daha makul kılıyor? Netflix'i düzenli örneğimiz olarak elde tutalım. Bir tarafa kullanıcıların fiziksel bir katalogdan film seçip, telefonla Netflix'i arayıp, İş bankasını arayınca karşınıza çıkan robotun yerine sizi bir müşteri temsilcisi müsait olana kadar bekleten, müşteri temsilcisine istediğiniz filmi söyledikten sonra onun o filmin CD'sini kargolatıp size 2 gün sonra gönderdiği bir dünya düşünelim. Diğer tarafta da hepimizin bildiği, sevdiği, çaktırmadığımızı düşünerek arkadaşlarımızla kurduğumuz aile grubundan 1 dakika içerisinde binlerce film ya da diziden birisini seçip izlemeye başlayabildiğimiz Netflix'i. Aslında baktığınızda bu ürünler birbirinin direkt karşılığı değil, güncel Netflix hayal ettiğimiz geçmiş Netflix'ten üstün değil. Bir CD aldığınızda artık ona sahip oluyorsunuz, pratikte o CD'yi arkadaşlarınızla paylaşabilirsiniz, hatta belki kopyalayıp satmaya bile çalışabilirsiniz, CD artık sizin mülkünüz. Günümüzdeki video/müzik yayın platformları sahipliği ortadan kaldırarak abonelik bazlı bir sistemle bizleri aydan aya hangi ürünlerin içinde olduğunu bile bilmediğimiz bir ürün kümesine erişim ile sınırlandırıyor, kendilerini ekonomik olarak karlı hale getirdikleri iş modeli bu çünkü, yani teknoloji tek başına bir süreci iyileştirmeye yetmiyor, dijital olarak yeniden hayal ettiğiniz tecrübelerin iş ve gelir modellerini tasarlamanız, bu aşamada bu tecrübelerin bazı eksenlerini kötüleştirebileceğinizi kabul ettmeniz gerekiyor. Benzer bir analizi pek çok tüketici yazılımında görebiliyoruz, mesela yazılımlaştırılmış süreçler geleneksel alternatiflerine göre çok daha az esnek olabiliyor, nüfus müdürlüğündeki çalışanın sizin için yapabileceği değişiklikleri E-Devlet'te yapamayabiliyorsunuz. ChatGPT herhangi bir özel ders hocasından çok daha ucuza çok daha fazla bilgi sağlayabiliyor size, ancak o bilgilerin doğru olduğuna dair bir kesinlik sunmuyor, hatta çoğu zaman sizin yanlış ön yargılarınızı beslemeye devam ediyor. Linkedin sizi fiziksel olarak karşılaşamayacağınız pek çok kişiyle "bağlıyor", ancak bir konferasnta yüz yüze görüşüp el sıkışmanın, muhabbet etmenin yerini alamıyor. Ancak yazılım ürünleri, geleneksel alternatiflerine göre çok daha ucuz, hızlı, ve sürekli. Netflix size fiziksel CD'ler göndermeyerek hem her CD'nin materyal maliyetinden, hem de o CD'yi üretip size göndermesi gereken lojistik ihtiyacından kurtuluyor, teknoloji sayesinde anlık hizmet sunabiliyor. Bunun yanında sizden düzenli geri dönüt alabiliyor, A/B Test</a> gibi geleneksel hizmetlerde mümkün olmayan ürün ve süreç optimizasyonları uygulayabiliyor, kullandığınız uygulamayı, o uygulamayı destekleyen sistemi her gün geliştirebiliyor. Buraya kadar görece makro tüketim yazılımlarından bahsettim, Netflix gibi, Wikipedia gibi hayatımızın her yerine girmiş, neredeyse her demografiğe hitap eden yazılımlardan. Tüketim yazılımlarını bir spektrum olarak ele alırsak bir de diğer uçtaki mikro tüketim yazılımları var, çok daha küçük demografiklerin spesifik ihtiyaçlarına cevap vermek üzerine kurulu yazılımlar. Kilo vermek isteyenler için diyet uygulamalarından yeni anneler için tavsiye uygulamalarına, fotoğraf filtreleme ve işlemeye, Forest gibi odaklı çalışma uygulamalarına, alıcısı olan her alanda uygulamalar var. Tüketim yazılımlarını sadece bilgisayar ya da telefonda kullandığımız web ya da mobil uygulamalar gibi düşünmek de doğru değil, evimizdeki otomatik ışıktan buzdolabımızın sıcaklığını ayarlayan gömülü sistemlere kullandığımız fiziksel elektronik sistemleri güçlendiren programlar da aslında tüketim yazılımları. Peki bu ayrımların bize faydası ne? Temelde varmak istediğim nokta şu, tüketim yazılımlarında ana uzmanlık ve odak aslında programlama ya da yazılım değil. Diyet uygulamasında diyetisyenin, fotoğraf uygulamasında fotoğrafçının hedef kitlemize nasıl bir çözüm sunmalıyız sorusuna verdiği cevabın dijital var oluşunun bir gereksinimi yazılım, bu uygulamaların çözdüğü problemlerin yazılımın ucuz, hızlı, sürekli olma özellikleriyle daha geniş bir kitleye daha karlı bir şekilde sunulmasına izin veren mekanizma yazılım. Bu tarz bir uygulamanın yazılmasında ana işler (1) yazılımın hangi özelliklere sahip olacağına karar vermek, (2) bu özelliklerin tamamını içerebilecek bir alan modellemesi (domain modeling) yapmak. İşin yazılımsal zorluluğu alanın ne kadar zor modellenebildiğine göre değişiyor. Bazı alanlar o kadar fazla kez modellendi ki, teknolojiye biraz yatkınlığı olan birisi neredeyse 15 senedir Wordpress kullanarak programlamayla hiçbir ilgisi olmadan e-ticaret sitesi açabiliyor kendi ürünlerini satmak için, ya da Bubble/Wix gibi no-code/low-code platformları kullanarak bir web platformu oluşturabiliyor insanlara belli hizmetleri sunan. Diğer yanda bazı alanları modellemek doktora seviyesinde araştırmacıların uzmanlıklarını gerektirebiliyor. Örnek olarak fizik simülasyonları inşaat ve mimarlıkta, otomotiv sektöründe, savunma sanayiinde kullanılıyor, kullanılan materyallerin fiziksel özelliklerini modellemek ayrı bir iş, bu modellemelerin insanların kullanabileceği seviyede performanslı olmasını sağlamak ayrı bir iş, bu modellerin doğrulanmasını yapmak ayrı bir iş. Sosyal sistemleri modelleyen yazılımlar için de dünyanın sürekli değiştiğinin farkında olarak modelleme yapmak ayrı bir zorluk. Ülkelerle ilgili verileri işlediğiniz bir sistem düşünün, bir ülkenin adının değişebileceğini (Turkey -> Türkiye), bir ülkenin ortadan kaybolabileceğini (Yugoslavya, SSCB) ve bunun sonucunda ortaya yeni ülkeler çıkabileceğini, ülkenin farklı veri tabanlarında farklı adlara sahip olabileceğini hesaba katmak zorundasınız. Latin alfabesinin sizin hayal ettiğiniz kadar basit ya da yaygın olmadığını</a> fark edip buna göre sisteminizi daha geniş bir yelpazede tasarlamanız gerektiğini düşünmeniz gerekiyor. Tabii ki bu kompleks alan modellemelerinin de ayrı performans ve karmaşıklık maliyetleri var, dolayısıyla bunları da hesaba katmanız gerek. Modellediğimiz alanın karmaşıklığını bir kenara bıraktığımızda, daha çok makro uygulamalarda karşımıza çıkan ölçek problemiyle karşılaşıyoruz. 300 kişinin kullandığı bir uygulama ile 300.000 kişinin kullandığı, 30.000.000 kişinin kullandığı uygulamalar çok temel düzeylerde birbirinden farklı. Her şeyden önce uygulamanın kitlesi büyüdükçe bahsettiğim modelleme problemleriyle karşılaşma ihtimaliniz artıyor. Belki ilk 1 milyon kullanıcınızda Kiril alfabesi kullanan kimse ile karşılaşmamış olabilirsiniz, ancak kullanıcı ölçeği büyüdükçe daha çeşitli arka planlardan insanlarla karşılaşacaksınız. Farklı diller konuşacaklar, farklı alfabeler, işletim sistemleri, zaman dilimleri, ödeme entegrasyonları, cihaz boyutları, internet hızları kullanacaklar. Bu çeşitlilik sizin modelleme ihtiyaçlarınızı kat be kat arttıracak. İkinci tip bir kompleksite ise uygulamanız sağladığı özellikler anlamında büyüdükçe yazılımınız da büyüyecek. Bugün ortalama bir yazılım ürününün arkasındaki sistemin birkaç yüz bin satır kodu olması hiç şaşırtıcı değil. Bu büyüklük size karmaşıklık olarak geri dönüyor, yeni bir özellik eklemek istediğinizde onu eklemeniz zorlaşıyor, uygulamada bir hata keşfettiğinizde onun sebebini tespit etmek saatler, günler sürebiliyor, özellikle de yazılımınızın mimari dizaynı bu büyüklüğü hesaba katacak şekilde yapılmadıysa. Üçüncü tip kompleksite ise kullandığımız cihazların fiziksel limitlerini algoritmik çözümlerle aşma çabasından geliyor. Mesela bilgisayarlarımızda 2 tip hafıza olduğunu düşünelim, geçici ve hızlı RAM, kalıcı ve yavaş disk. Eğer ki kullanıcı RAM'e sığmayan bir dosyayı yüklemek isterse ne yapmalıyız? Benzer şekilde, bir web uygulaması yazdığımızı varsayalım, bu web uygulamasını kullanıcılara sunmamızı sağlayan bir sunucu uygulamamız (application backend) var. Bu sunucunun fiziksel kapasitesi saniyede 100 kullanıcıya cevap vermesine izin veriyor ise, saniyede 120 kullanıcı aldığımızda ne olacak? Ya kullanıcıların bir kısmını düşüreceğiz, mesela sınav sonuçları açıklandığı gün ÖSYM sitesine giremediğinizde ÖSYM sizin isteklerinizi düşürüyordu... Diğer bir ihtimalde ise kodumuzu daha fazla kullanıcıya aynı hizmet verebilmesi için optimize edebiliriz, daha güçlü ve pahalı bir makineye geçebiliriz, ya da pek çok makineyi aynı anda kullandığımız dağıtık bir sistem kurgulayabiliriz. Burada en başta bahsettiğim bir soruya geri döneyim, kim kime neden yazılım ürünü geliştirmesi için maaş ödüyor? Yazılımcının en temel işi alan uzmanlarının ortaya koyduğu gereksinimleri sağlayacak bir yazılım ürünü oluşturmak. Bu gereksinimler bir uygulamanın nasıl gözükmesi gerektiğinden kullanıcının aldığı aksiyonların uygulamada nasıl bir akışa yol açtığına, aynı anda desteklenmesi beklenen kullanıcı sayısına, kullanıcının bir aksiyonu sonucunda aldığı cevabın kaç saniyeyle limitli olduğuna... çok farklı şekiller alabilir. Tabii ki bu kararlar bir vakumda değil, bir yandan da kısıtlı kaynakların olduğu finansal bir denklemde alınıyor. Mühendislik de, en temelde kısıtlı kaynakların matematiksel modellemeler sonucu optimizasyonu aslında. Yazılım ya da bilgisayar mühendisliğinin objesi ise önceki paragraflarda bahsettiğim süreçleri optimize etmek. Bu optimizasyon projenin ilerlemesini hızlandıracak kararlar sonucunda projenin alacağı toplam insan saatini azaltmak da olabilir, projedeki fiziksel kaynaklara yapılan harcamalar ile algoritmik geliştirmelerin ya da dağıtık sistem tasarımlarının arasındaki dengenin kurulması da olabilir, projede kullanılacak olan dış kaynaklara ve hizmetlere karar verilmesi de olabilir. Ürün sahipleri bu kararları alabilecek, bu kararların sonuçlarının sorumluluğunu alabilecek mühendislik ve takım liderlerine, bu gereksinimlere uyabilecek uygulamalar geliştirebilen yazılım mühendislerine maaş ödüyor. Bir uygulamanın bir saatliğine kapalı kalmasının</a> şirkete bir maliyeti var. Bir isteğin saniyenin 100 milisaniye daha uzun sürmesinin</a> şirkete bir maliyeti var. Bir uygulamada kullanıcıyı etkileyen hatalar olmasının</a> şirkete bir maliyeti var. Dolayısıyla yazılım mühendisinin daha hızlı, dayanıklı, okunabilir, anlaşılabilir, büyütülebilir, güvenli yazılımlar geliştirebiliyor olmasının şirkete direkt olarak finansal faydaları var, bu faydalar yazılım endüstrinin var olmasını ve büyümesini sağlıyor. Uzuuunca bir şekilde tüketici yazılımlarından, bu yazılımların nasıl ihtiyaçları neden çözdüğünden, yazılım mühendislerinin bu yazılımları geliştirmedeki rollerinden bahsettik. Peki bu ürünlerin tüm parçalarını şirketler sıfırdan mı geliştiriyor? Tabii ki hayır. Nasıl araba şirketleri yeri geldiğinde basit parçaları, yeri geldiğinde ise motor gibi kritik bileşenleri güvendikleri üçüncü parti şirketlerden alıyorsa, yazılımda da benzer mekanizmalar var, bunlardan iki paragraf önce dış kaynaklar ve hizmetler olarak kısaca bahsetmiştim, şimdi omurga yazılımlar adı altında bu dış kaynak ve hizmetlerin ekonomik mekanizmalarını inceleyeceğim. Omurga Yazılımlar</a></h2> Not: omurga kullanmak istediğim asıl terim için --"backbone"-- çok iyi bir çeviri değil, daha iyi bir çeviriniz varsa iletirseniz sevinirim. </blockquote> Bahsettiğim optimizasyon problemlerini, ölçekle ortaya çıkan karmaşıklığı okuduğunuzda bilgisayar mühendisliği yazdığınıza pişman olmuş, acaba başka bir mühendislik mi yazsaydım daha mı kolay olurdu diye düşünmüş olabilirsiniz, ancak şimdi sizi biraz daha endüstrinin realitesiyle tanıştıracağım, ve aslında yaptığımız işin çok büyük bir kısmının mühendislik olmadığını göreceksiniz, çünkü kullandığımız makineler çok ucuz, "compute is cheap". Geçtiğimiz 70 senede yazılım endüstrisi donanım endüstrisinin üssel gelişiminden fazlasıyla yararlandı, ortalama her 18 ayda bir kullandığımız makineler iki kat daha güçlü hale geldi (Moore Yasası</a>). Bugün cebimizdeki telefonun Apollo 11'den 100.000 kat daha fazla hesaplama gücü, 7 milyon kat daha fazla hafızası var, ve biz onunla 2048 oynuyoruz. Tabii ki şaka bir yana, günümüz bilgisayarları ekrana harfleri gözümüze güzel gelen bir şekilde çizmek için Apollo'nun çalıştırdığı fizik simülasyonlarından daha karmaşık hesaplamalar yapıyor, ortalama bir sosyal medya uygulaması 1970 yılındaki tüm veriden daha fazla veriyi tek bir günde telefonumuzda işliyor, dinlediğimiz bir müzik klibi 1990'lardaki 100 albüme eşdeğer miktarda veri saklıyor. Cihazlarımızda çok daha fazla veri tutuyor, çok daha fazla veri işliyoruz, bunları çok daha kompleks algoritmalarla ve protokollerle yapıyoruz; eğer ortalama bir yazılım mühendisi yazdığı uygulamanın tam anlamıyla ne yaptığını öğrenmeye kalkarsa bunun için birkaç yılını sadece okuyarak ve araştırarak harcaması gerekebilir. Dolayısıyla nasıl Aston-Martin motorları için Mercedes'e güveniyorsa, yazılım firmaları da kritik, bugün kurduğumuz sistemlerin omurgası haline gelmiş pek çok kendini kanıtlamış, hazır yazılım ürününü kullanıyor. Omurga yazılımların bize verdiği garantileri kullanarak, hesaplama gücünün ucuzluğuyla da birlikte yazılım ürünlerini özellikle ilk aşamalarda minimal mühendislik yüküyle geliştirebiliyoruz. Alan modellemelerini basit tutarak geliştirilen yazılımın karmaşıklığını sınırlayabiliyor, ortalama tek bir makine ile saniyede binlerce isteği karşılayarak dağıtık sistemlerin ve optimizasyonun yükünden kurtulabiliyoruz, klasik bir yazılım ürününün ihtiyaç duyduğu veri tabanı(SQLite, PostgreSQL, MongoDB, Firebase), kuyruk (Kafka, RabbitMQ, SQS), önbellek (Redis, Memcached), yük dengeleyici (NGINX, HAProxy), konteyner (Docker, Kubernetes), izleyici (Prometheus, Grafana), nesne deposu (S3, R2), içerik dağıtım ağı (Cloudflare, Akamai) gibi pek çok ihtiyacı çoğunluğu açık kaynak, yüksek yük altında kendini kanıtlamış, matematiksel modellerle desteklenmiş, çeşitli hata senaryolarına karşı dirençli omurga yazılımlar ile yazılım geliştirme sürecini hızlandırabiliyoruz. Yalnızca yüksek yükü karşılaşayabilmek ya da optimizasyon için kullanmıyoruz tabii ki dışarıdan yazılımları. Programlama dilleri çoğu zaman yüz binlerce kütüphanenin olduğu büyük ekosistemlerden oluşuyorlar. Bu ekosistemler bize bir web sitesi oluştururken kullanabileceğimiz Django gibi tam paket (batteries-included) çözümler de sunuyor, yetkilendirme (authorization), kimlik doğrulama (authentication) gibi bir uygulama oluşturmak için temel faydalı paketler de sağlıyor, aviyonikten</a> robotiğe</a>, yapay zekaya</a>, burada say say bitiremeyeceğim çok farklı alanlarda kullanabileceğimiz, bahsettiğimiz algoritmik problemleri, alan modellemelerini çözen, bize hazır çözümler sunan kütüphaneler var. Sırtımızı bu koskoca ekosisteme taşıyarak son tüketim uygulamasını neredeyse sadece ekosistemden paketleri birbirine bağlayarak oluşturabiliyoruz çoğu zaman, en azından küçük ölçeklerde, basit modellerle. Ancak birilerinin de bu omurga yazılımları yazması gerekiyor, bu yazılımlar kendileri bir anda ortaya çıkmıyorlar. Bu yazılımların sırtını dayayabileceği ekosistem çok daha küçük, yapılan hataların maliyeti çok daha büyük, geliştirme süreçleri geleneksel mühendisliklere çok daha yakın. Son tüketim yazılımlarında yazılımcının ana işinin ürün sahibinin ürettiği gereksinimleri programlara dönüştürmek olduğundan bahsetmiştim, omurga yazılımlarda artık yazılımcının ana uzmanlığı kod yazmak değil, alttaki sistemi anlamak, nasıl geliştirebileceğini keşfetmek, kod artık bir araç değil, aynı zamanda bir amaç haline geliyor. Buraya kadar adını vermeden etrafından dolaştığım bir konsepte gelelim, soyutlama (abstraction). Bahsettiğim "sırtını dayama" konsepti aslında sırtımızı dayadığımız yazılımların bizim için belli detayları soyutlaması sayesinde mümkün oluyor. Her soyutlama katmanı bize belli garantiler sağlıyor, veri tabanları koyduğumuz veriyi tekrardan geri alabileceğimizi garantiliyor, PDF yaratmak için kullandığımız kütüphane en son ürettiği dökümanın geçerli bir PDF dosyası olduğundan emin oluyor, uçuş kontrolü için kullandığımız modül uzayda X-Y-Z yönüne doğru ilerlemek istediğimizde fiziksel olarak o yönde ilerlememizi sağlıyor. Soyutlama katmanlarının bize sağladığı garantiler sayesinde büyük yazılım projeleri üretebiliyoruz, mesela iki cihaz arasında tüm mesajların kesin bir şekilde problem yaşanmadan gitmesini sağlayacak fiziksel bir altyapı oluşturmak mümkün değil, ama var olan fiziksel altyapıların üstüne mantıksal olarak mesajların kesin bir şekilde iletimini sağlayan TCP gibi protokoller sayesinde mesaj iletimini bir problem olarak düşünmekten kurtulabiliyoruz. TCP'nin kendisini geliştiren kişiler bizim sahip olduğumuz soyutlamalardan faydalanamıyor, alttaki fiziksel dünya modelinin üzerine bir ağ protokolü kurmak zorundalar. Benzer şekilde veri tabanları, derleyiciler, döküman editörleri, ağ protokolleri, gerçek zamanlı video işleme modülleri... gibi başka uygulamaların onlara sunacağı soyutlama katmanlarından yararlanamayan, makinenin önbellek yapısını, hafızasını, bir programın makine kodunda nasıl gözüktüğünü anlaması gereken pek çok yazılım sınıfı var. Bu endüstrilerde maaş artık yalnızca gereksinimleri koda dönüştürebilmenin yanında gereksinim üretebilmeye dayanmaya başlıyor, tüketim yazılımlarında daha çok alan uzmanlarının ürettiği gereksinimlere uyulmasından sorumlu olan yazılımcılar artık kendileri de alan uzmanı oluyorlar, çünkü dizayn edilen sistemin güvenebileceği soyutlama katmanları yok, makineyi, algoritmaları, protokolleri anlamak zorundasınız, nasıl ki bir otomotiv mühendisi matematiksel modellemeler yapıyorsa, bir inşaat mühendisi yaptığı binanın yıkılmayacağından emin olmak zorundaysa, siz de veri tabanınızın veri kaybetmediğinden, kullanıcılara verdiğiniz garantilerin gerçekten garantiler olduğundan emin olmak zorundasınız. Dipnot: Burada kendimi yanlış anlaşılmalara karşı biraz korumak istiyorum. Bir işin mühendislik içermiyor ya da gerektirmiyor olması o işin önemsiz olduğu ya da kolay olduğu anlamına gelmiyor. Demek istediğim şey matematik ve optimizasyon gerektirmediği. Benim de günlük hayatımda yazdığım kodların çok büyük bir kısmı matematik gerektirmiyor, hatta bilgisayar mühendisliği eğitimi de gerektirmiyor, kendime programlama öğretsem yapabilirdim çok büyük bir kısmını. İşin geri kalan küçük kısmında matematik bilmeye ihtiyacım var, eğitimimi de onun için kullanıyorum, bu yazıyı okuyacak öğrencilerin de aynısını yapacaklarını, aldıkları eğitimin boşa olmadığını, endüstride karşılığını olduğunu bilmeleri için bu yazıyı yazmak istedim biraz da. </blockquote> Açık Kaynak</a></h2> Yazılımın ekonomisini konuşurken açık kaynağın buradaki rolünü konuşmamak olmaz, çünkü yazılımı diğer endüstrilerden ayıran en önemli faktörlerden birisi açık kaynak kültürü. Çoğu endüstride ticari sır olarak nitelendirilecek uygulamalar, ürünler, fikirler açık olarak paylaşılıyor, geliştiriliyor. Linux, SQLite, Chromium, Kubernetes gibi endüstrinin çok büyük bir kısmını güçlendiren ürünlerin yanı sıra popüler tüm programlama dillerinin derleyicileri, editörler, TensorFlow/PyTorch gibi endüstri standardı makine öğrenmesi kütüphaneleri, internetteki sitelerin çok büyük bir kısmının arkasında olan Wordpress, Netflix ve Youtube'un video işleme için kullandığı ffmpeg gibi yüzlerce inanılmaz değerli uygulama ve kütüphane açık kaynak, çoğunun lisansları üstlerine iş kurulabilecek esnek lisanslar. Açık kaynakla ilgili tartışmaları çoğu zaman ekonomiden bağımsız görsem de, benim gözümde açık kaynak her projenin ekonomik olarak da sürdürülebilir olması gerekiyor, çünkü ekonomik olarak sürdürülemeyen bir sistem ancak öğrenciler, tam zamanlı çalışmak zorunda olmayan gönüllüler, ya da tam zamanlı işinin üzerine açık kaynak projeleri bir şekilde devam ettirebilen inanılmaz özverili insanlar sayesinde devam edebiliyor. Çoğu zaman, eğer proje insanlara finansal fayda sağlayabiliyorsa şirketler üzerine ücretli bir ürün kurarak projenin açık kaynak kısmını fonlayabiliyorlar, benzer şekilde büyük açık kaynak projelerde yer almanın getirdiği endüstrideki sosyal kredi hem şirketlerin alım süreçlerinde hem de endüstrideki çalışanların verdikleri kararlarda etkili oluyor. Şahsen ben açık kaynak bir projede çalışabileceğim bir şirketi kapalı bir projeye tercih edebilirim. Tabii bunun üzerine açık kaynağın manevi bir tarafı olduğunu da yadsımamak önemli, pek çok insana direkt olarak faydası olan bir proje üzerinde çalışmanın şahsi bir tatmini de var. Açık kaynağın yazılımda popülerleşmesinin tarihsel geniş bir bağlamı var, ancak ben yine ekonomik taraftan yaklaşmak istiyorum. Yazılım ürünlerinin üretim ve bakım masraflarının neredeyse tamamı emekten oluşuyor, geleneksel endüstrilerdeki materyal veya lojistik masrafları kendilerini farklı şekillerde yazılım endüstrisinde ortaya çıkarsa da çok daha küçük ve göz ardı edilebilir kalıyorlar. Ana masrafın emek olması sebebiyle herhangi birimiz kendimizin, çevremizin, ya da toplumun bir kesiminin problemini çözecek bir çözüm üretip bunu yayabiliyoruz. Bugün özellikle programlamada bize yardımcı olması için kullandığımız pek çok mini araç 2-3 kişinin kendi problemlerini çözmek için üzerine çalışmaya başladığı araçlar, zaman içerisinde endüstri geneline yayıldıkları için her cihazda, her an, ücretsiz bir şekilde kullanabiliyoruz bunları. Maaşlar</a></h2> Buraya kadar endüstrinin farklı parçalarının ne gibi işler yaptığını, farklı alanlarda yazılımcının hangi kabiliyetlerinin onu iş sahibi yaptığını konuştuk. Peki farklı segmentlerdeki maaş dengeleri nasıl ortaya çıkıyor? Tabii ki genel geçer belli bilgilerimiz var, Amerika'daki ortalama maaşın yüksek olduğunu biliyoruz, bunun ülkedeki yazılım endüstrisine yapılan yatırımın ve edilen dudak uçuklatıcı karların bir sonucu olduğu çıkarımına varabiliyoruz. Peki Avrupa'da, Türkiye'de nasıl ortaya çıkıyor maaş dengeleri? Benim endüstrisindeki maaşlarla ilgili gördüğüm en iyi araştırmayı ve modeli</a> 2021 yılında Gergely Orosz pragmatic engineer</a> adlı bloğunda yayınladı. Gergely bu yazıda endüstriyi 3 parçaya ayırıyor, T1 şirketleri en fazla pozisyona sahip, en az maaşları veriyorlar, maaşları için kendi alanlarındaki lokal şirketler ile yarışıyorlar. T2 şirketleri maaşları için tüm lokal şirketler ile yarışıyor, T3 şirketleri ise en az miktarda çalışan alıyor, bölgesel ve küresel şirketler ile yarışıyor. Analizin detayı için asıl yazıyı okuyabilirsiniz, ancak ben biraz daha kendi perspektifimden sunmak istiyorum. Tek kişilik bir şirket hayal edelim, aylık belirli bir miktarda geliri var, giderleri var, günün sonunda karı da X lira olsun. Bu şirketi büyütmek için kişinin ya yeni büyümeyle birlikte uzun vadede daha fazla satış yaparak karını arttırabileceğine, ya da yapmak istemediği işleri karının belli bir miktarını keserek başkasına yaptırabileceğine inanıyor olması gerek. Buradaki seçeneklerden ilki çalışanı yeni kar üretiminin bir parçası olarak görürken, ikincisinde çalışan bir maliyet, işveren her zaman çalışanı ortadan kaldırarak yapmak istemediği işleri yapıp maliyetini eski haline düşürebilir. Benim endüstriye bakışım bu ikilemde her zaman kar üretiminin bir parçası olmaya çabalamak yönünde, bu da büyüyen, büyümek isteyen şirketlerde yer almak, kendini endüstrinin kalanından mümkün olduğunca ayrıştıracak şekilde kabiliyetler edinmek, şirketlere o ayrıştırdığım yönü bir artı olarak sunmak, birinin yapmak istemediği işleri yapmak yerine yapamayacağı işleri yapabilmeye çalışmak oldu. Tabii ki endüstri 1 kişiden 2 kişiye çıkacak şirketler ekseninde tartışılabilecek kadar basit değil. Savunma sanayii, bankalar gibi kurumsal şirketler taşa yazılmışcasına sabit maaş aralıkları sunuyor, pek çok şirket Gergely'nin T3'ünde yer alabilecek kadar büyük bir ölçekte çalışmıyor, o şirketlerle yarışmasına gerek kalmıyor, ülkedeki genel ekonomik durumla uyumlu seviyede maaşlar veriyorlar, ancak Türkiye'de de küresel ölçekte çalışan, küresel yarışın bir parçası olan, T3 grubunda şirketler var. Yapay Zeka</a></h2> Yazının başında bu yazının "yapay zeka işimi alacak mı" korkusunu yaşayan öğrencilere faydalı olmasını umduğumdan bahsetmiştim. Bitirmeden önce biraz ona değineyim. Fark etmiş olabilirsiniz, yazı boyunca endüstriyi farklı şekillerde kategorize ettik, tüketici yazılımlarından, bu yazılımları destekleyici konumda olan omurga yazılımlara bir geçiş yaptık, bunun haricinde T1-3 eksenlerinde şirketlerin yarıştığı ölçekleri kategorize ettik. tüketici yazılımlarını da kendi içerisinde spesifik problemlere odaklanan mikro yazılımlardan makro yazılımlara bir spektrum olarak niteledik. Bu mikro-makro skalasında ilerledikçe nasıl problemlerin ortaya çıktığını, yazılımcıların spektrumun farklı noktalarında farklı problemleri çözdüğünü tartıştık. Bundan birkaç ay önce Yeni Sınır Doğrulanabilirlik (Verifiability is the Limit)</a> adında, temele yapay zekanın yeni kabiliyetlerinin endüstriyi nasıl etkileyeceğini düşündüğüm bir yazı yazmıştım, burada tamamını tekrarlamayacağım, ama ana argümanı tekrarlamak yararlı. Yazdığınız her türlü program, ürettiğiniz her türlü ürün, birilerinin işine yaramak için var. Dolayısıyla onun sizin kabul edilebilir bulduğunuz sınırlar içerisinde "doğru" olduğunu doğrulamanız gerekiyor. Bir nükleer santral, araba ya da apartman, ya da bir omurga yazılım için bu doğrulama çok daha fazla mühendislik gerektirebilir, çok daha fazla matematiğe ve efora ihtiyaç duyabilir, ancak bir web sitesi için de sizin bakıp istediğiniz gibi gözüktüğünden emin olmanız gerek. Doğrulama sizin yapay zekaya atayabileceğiniz bir görev değil, çünkü ne olursa olsun en son noktada sizin modelden doğal dille istediklerinizin modelin anladığıyla aynı şey olduğundan emin olmanız mümkün değil. </blockquote> Yazıda doğrulamanın farklı alanlarda nasıl olduğu, bunun yapay zeka kullanımını nasıl etkilediğine dair başka tartışmalar da var, en sevdiğim yazılarımdan birisi, okursanız sevinirim. Buradan endüstri analizine geri dönebiliriz. Yapay zeka öncesi dönemde programlama yeteneği bir ek değerdi. Yani maaşlar kısmında bahsettiğim şirkete maliyet olmak yerine daha fazla para kazandırma fırsatı verdiğiniz bir pozisyonda oluyordunuz kod yazan kişi olarak, çünkü "kod yazabilenler" ve "kod yazamayanlar" olarak ikiye ayırabilirdik toplumu. Artık "kod üretmenin" kolaylaşması ile birlikte bu ayrım ortadan kalktı, ancak "kod doğrulayabilenler" ve "kod doğrulayamayanlar" ayrımı hala var. Yeni Sınır Doğrulanabilirlik yazısında bahsettiğim gibi, doğrulama her alanda farklı şekillerde yapılıyor, bazı alanlarda doğrulama yapmak için bugün QA (Quality Assurance) alanında çalışlanların yaptığı tarzda program ile çeşitli interaksiyonlara girerek programın tepkilerini ve cevaplarını inceleyip izlemek yeterliyken, diğer alanlarda bir programı doğrulamak için yine farklı programlar yazmanız, sistemin matematiksel modelini anlamanız gerekebiliyor. Benim gözümde artık doğrulama yapmak için programla yalnızca interaksiyona girmenin yeterli olduğu alanlarda programcı olmak bir maliyet haline geldi bir değer olmak yerine, bu da bu pozisyonların ortadan kalkacağını, maaşlarının düşeceğini gösteriyor bana. Endüstrinin bunun dışında kalan kısımlarına bakarsanız üretilen değerin doğal dille ifade edebileceğiniz problemleri koda dökmek olmadığını görebilirsiniz. İlk başta o problemleri keşfetmek, anlamak, çözüm yöntemi üretmek bir değer, ürettiğiniz kodun diğer kişiler tarafından okunabilir, geliştirilebilir, büyütülebilir olduğundan emin olmak bir değer, ürettiğiniz kodun fonksiyonel olmanın yanında performans, güvenlik gibi gereksinimlere uyduğundan emin olabilmek bir değer, bu değerlerin çok ciddi bir kısmı "doğrulama" ile geliyor, "üretim" ile değil. Krediler</a></h2> Yazıya dair yorumları, eleştirileri ve tavsiyeleri için Ahmet Öğreten, Ahmet Yüksel, Arda Çelik, Barış Aşkın, Cemil Vahapoğlu, Doğaç Eldenk, Emre Güllü, Göktuğ Ekinci, Ozan Erdem, Türker Akpınar, ve Umut Güloğlu'na teşekkürler. Kapanış</a></h2> Biraz dağınık bir yazı oldu, endüstrinin farklı taraflarındaki benim biraz geç fark ettiğimi düşündüğüm bakış açılarımı ortaya dökmeye çalıştım. Belki de ben biraz naifimdir, bilgisayar mühendisliği öğrencileri ya da endüstri ile daha iç içe yazılım mühendisleri bunların daha çok farkındadır, belki de benim farkındalıklarım çok da doğru değildir. Kısaca toparlamak gerekirse, dünyadaki en büyük endüstrilerinin bir tanesinin içerisindeyiz. Çok farklı iş kolları, çok farklı pozisyonlar, çok farklı şirketler var, hepsinin çeşitli dinamikleri, beraber iş yaptıkları farklı şirketler, hizmet sağladıkları çeşitli sektörler var, toplu bir şekilde baktığımızda milyarlarca doların döndüğü inanılmaz kompleks bir endüstriden bahsediyoruz. Bu endüstrinin içerisinde bir birey olarak yer alırken ekonomik dinamikleri anlamaya çalışmak bana eğlenceli geliyor, bir yandan da şirketlerle olan iletişimlerimi yönlendiriyor, hangi tip şirketlerle nasıl iletişim kurmalıyım, bu şirketler için ne değerli, yapacağım iş bundan nasıl etkilenecek onu anlamak için bana faydalı olduğunu düşünüyorum, bence endüstride yer alıyorsanız sizin de bunları düşünmeniz sizin için de faydalı olacaktır, kolay gelsin. *: Bilgisayar bilimi ve mühendisliğiyle ilgili ilginç başka fikirleri takip etmek istiyorsanız Hafif Programming</a>'i kaçırmayın. </blockquote> Filling in the Missing Bits 2025-08-02T00:00:00+00:00 The world is full of gaps, missing opportunities, unfinished projects, and unfulfilled potential. We walk around every day complaining about the problems we see in the world. We don't like the height of a shelf, the color of a wall, the shape of a doorknob, the line at the DMV, the length of the traffic light, the taste of our morning coffee, the feed our our social media, on, and on, and on. Much of the world is set in stone, or at least feels like it, so 9 out of 10 cases the solution is to change our preferences; we change the route to our work, the brand of our coffee, the position of the twitter app on our phone, and we just decide never to go to DMV ever again. Perhaps this is why open source software is so misunderstood, so asymetric on the expectations of the people who create it, versus those who use it. You see this kind of divide in the discussions in open source projects, the user, whose modus operandi in life is to be a customer, asks for a change in a project that fits their requirements. The already burnt out open source maintainer responds by asking the "customer" to go to hell, or better yet just open up a PR, which the discussion more often than not dies, because customers do not fix, they consume. There are perfectly valid explanations for each behavior in this scenario, it is expected, it is common, it is normal. The question is, who breaks this pattern, and how? How do we turn from powerless customers to the grumpy maintainers? What's the shift in mindset, what does it entail, how does it empower us, and why should you care? I argue that you should care, because looking at problems in the world and having the audacity to try to fix them is quite empowering, because you can start by solving your own problems. In terms of a weird traffic lights that don't make sense, the best you could do is perhaps calling your local municipality and fighting against a bureaucracy of conformity in order to move the status quo. In terms of software, the limit becomes the sky. If you don't like how a website looks, you can just create a browser extension for automatically changing it. If you don't like ads, you can write or install a kernel level ad blocker. If you don't like your file manager, you can write one from scratch</a>. Software is malleable, it is not set in stone, we get to play, change, update, upgrade, evolve, and contribute to it. That is not to say that changing software is any more easier than changing your traffic lights in terms of technical difficulty, most software is cimplex, and contributing to it requires time, effort, and domain expertise. The important difference of software is its zero-cost distribution, open source culture that allows for you to tinker with, play around, discover, understand and modify software. Creating a large project from scratch is like creating a whole new apartment, scratch that, it's like designing a whole new city; but adding a specific feature you want, or need, for solving your own problems is more likely akin to changing your doorknob with the major difference that you don't need to order a new doorknob from Amazon, but you just need your time and effort. Once we are out of the customer mentality, such a large surface of possibilities opens up in front of us. You don't like how slow Rust compiler is, perhaps you should check out what is making it slow, remove or upgrade it. If you want Excalidraw to support more shortcuts, you can spend a few hours figuring out how to do that, whereas you have direct access to the people who write the software from very open communication channels, something we almost never have for other problems in our life. In contrast to so many of those responsible for our problems building up layers of bureaucracy to shield themselves from complaints and requests, open source software communities are inviting, open, and surprisingly well accustomed to newcomers like yourself, or myself. World is far from complete, and it is far from being set in stone. The systems we interact change every day, and I personally would like to be the change I would like to see in the world, which open source software allows me to do. Let's open up a personal parantheses here, the project that inspired me to write this post is called tjq, or typed jq. tjq</a> is a novel algorithm for better error reporting for jq</a>, a popular scripting language for processing JSON. What is so interesting about tjq is that the core of the idea is very simple, many people would have thought of it, and I'm sure many asked themselves why that did not exist. You use the information already available in the program for understanding it better and use it for better, informative, surgical error messages. The only reason I started this project is I was writing jq scripts and got fed up with the error messages I got. In a customer mindset, I would have either complained to the maintainers or switched to a better product. The filler mindset instead tries to understand what the missing bit is, and conjectures how to fill it. It is possible that filling gaps is a lot of work, tjq is still incomplete, and it will remain so for a long time, so arguably I haven't been able to fill it, and perhaps I won't ever be able to finish the project. Yet, the mentality of looking at the same world as many, but seeing something else, a possibility for change many others have ignored seems to have an exceptional satisfaction. Almost no problem in the world is unique, if you are experiencing it, others are too. If you fix it, many will benefit, perhaps even those who are ignorant to the problem today, and you will have filled a gap in the world, raising the bar for everyone, and lifting the world up to be a better place for us all. Time Budget as a Software Constraint 2025-08-01T00:00:00+00:00 Software performance is a contentious topic among programmers. On one hand, you'll see Jonathan Blow arguing programmers should spend their valuable time bikeshedding small details to cut down a few CPU instructions, and on the other you'll see people running an electron app that runs on a hypervisor that runs on a VM, claiming everything's just fine. Ultimately, a large portion of this discussion comes to opportunity costs and incentives, which are domain and case specific, which I believe isn’t particularly fruitful to rehash in this essay. I will, however, propose a framework for discussing what to optimize, and why. I have heard similar arguments in discussions before, so there's certainly some folk knowledge on this, although I don't have any formal citations, Martin Fowler</a> seems to have influenced some of these ideas, so I thank him for that. The core thesis I propose is that, performance, and performance requirements, fundamentally change the way software is used. The faster we can run a program, we can run it more. A program that takes a fraction of a second can be run without disrupting the user at all, while a program that takes a few seconds must require explicit user approval and action to run. If it takes a minute, the user will probably run it while checking their social media in the background, a 10 minute program will only run at coffee breaks, a 30 minute program will probably run in the CI or overnight. The best example of this is perhaps textual analysis of code. State of the art type checkers are fast and incremental, and they can provide almost immediate feedback to the users in most cases. These systems are now fundamental parts of the activity of programming, to the point it is expected for new languages to have LSP integrations and type inference to be counted as "usable". Another important example, which is in fact related to my research, is in random testing. Random testing has many flavors, the most common is no doubt fuzz testing, which is roughly defined as generating random bytes as inputs to the system under test, using many heuristics, mainly coverage information acquired by instrumenting the system, in an effort to find crashes. My research focuses on Property-Based Testing, which, in contrast to fuzz testing, focuses on very short time horizons in the order of milliseconds, seconds, or at most a few minutes; while you'll see fuzz testing running in continuous integration systems for hours or days. It is no doubt both approaches are useful on their own, and they have been used interchangeably in many cases</a>, but the focus, the incentives, the evaluations of PBT and fuzz testing differ vastly, which I believe the budget plays a big role in, because the budget changes the trade-offs we need to make, hence the maneuvers we can take to explore new possibilities in the design space. This view of performance gives us another avenue to think of, other than the classical "faster is better" mantra. Of course, given everything is constant, faster is better, but you can also think of what are the interesting possibilities with a larger time budget? Imagine a game engine that can run 60 FPS in real time for a given configuration. For anything that does not require real time processing, you can increase the FPS, or give it a much better rendering quality that you wouldn't have the opportunity to do otherwise. Same thinking follows the other way. For any given software, and what you do with it, you can at many times conjure new possibilities with a lower time budget. Today, we're used to grammar checkers or type checkers running in the background, giving us instant feedback, but our unit tests are running only when we explicitly run them, because they are not instant. What if you had an environment where any relevant test would automatically run as you type, could that lead to higher-quality software? Our core assumptions on what we can do with software are limited by our assumptions on how fast we can run it. Coming from the land of WYISYG (what-you-see-is-what-you-get) editors, it is actually very weird to realize that writing LaTex documents require you to explicitly compile them, because LaTex has not been designed with the goal to be that fast. I see the problem from the other direction in many cases. People see how slow something is, and they asssume that is the normal speed, that's the way things were, are, and will be; but that doesn't have to be the case, the underlying hardware we use are immensely powerful, to the degree that software engineers have been blessed with ignorance that they can just not care about performance, but those that care can create great things. Figma has broken the mold of what a web app can do, and it is today worth 70 billion dollars, although I'm sure for reasons far beyond what I understand, or could discuss. This type of thinking gives us a framework to think about software optimization that exceeds serving more users with less resources, it lets us think about how we can run a process more often, or how we can run more processes at the same time. It, on the other hand, gives us a simple way of cost reduction and preservation of resources. If you want to spend less money or compute, you can just do less, and you will compute less. For instance you can take your realtime system that updates 100 times per second and turn it into a system that updates every 2 minutes, you will be running 1/200th of what you previously did. Although this type of thinking is very very simple, I find having to remind myself that user experience is not set in stone, and every part of your software is a trade-off between implementation time, execution time, and user experience. You can either spend more time to optimize, or more time to run, or you can just degrade the user experience by running less often or with less quality. Before concluding, I will mention LLMs as they seem to consume so much of our daily discussions. I think of LLMs today a bit similar to LaTex in their usage. I think we have taken their current velocity as given, but they are slow. I think so many new avenues would explore if they were 10x, or perhaps a 100x more performant. You could instantly generate 5 different potential results to a user and allow them to choose, as if they are picking options from a dropdown in a form. You could feed much larger data, increase the amount o information both the system providess, and also consumes, creating a real assistant that can run seamlessly alongside your tasks instead of constantly breaking your flow, marketed by "let your agent run for 30 minutes while drinking your coffee" that is the common sentiment today. Faster internet has given us constant connectivity, streaming, real-time video calls, even real-time robotic control in medical operations, I imagine faster models will change the way technology is used in similar ways, and we are still at the beginning of what is possible. Perhaps I was naive, thinking most software engineers were as clueless as I am on thinking about the ramifications of performance and how it can change the systems we build, but if not, I hope this essay has given you a new perspective on how to think about performance, and how it can be used as a constraint to design better software. The next time you are faced with a performance problem, I encourage you to think not just about how to make it faster, but also about what new possibilities a different time budget could open up for your software. Verifiability is the Limit 2025-03-09T00:00:00+00:00 LLMs have created an enormous turmoil within the software engineering community within the past 5 years, much of it revolving around one central question, what is the future of our profession? A set of competing paradigms with various degrees of human intervention and control has emerged, on the one side agents with little to no humans in the loop, recently popularized “vibe coding” that discourages manually modifying code and instead interacting with the codebase over LLMs, the chatbots implementing standalone modules or functionalities, sometimes even running code using code interpretation feature, and on the other side coding assistants that predict what the user would like to implement, acting as “autocompletes on steroids”. There are many beliefs in terms of the limits, usefulness, and potentials of these models. Some believe the models will ascend into human level capabilities with unprecedented levels of time and resources and will be able to automate the construction of production grade software systems, while skeptics belittle the models, claiming their code will be mediocre and trivial, unable to scale up to any kind of production. I am not here to argue about the limits or capabilities of the models themselves, there are much better experts out there with deep theoretical knowledge and practical experience than I do. I, however, will argue the following. Every piece of software in the world has to be “correct” with respect to some notion of correctness. Before LLMs, our time was split between writing, reading and verifying code. With LLMs, we are able to offload code writing phase to LLMs, but the verification process cannot be offloaded, only pushed up to a different layer. Out there, you will see people arguing correctness is only a thing in a small set of domains, such as rockets or cryptography. Make no mistake, the degree to which correctness requires rigor changes, but the requirement for correctness does not. Software is always created with a purpose, whether it is to consume and transform some data, or provide some information to a user, or allow a user to interact and create some new data. Correctness is the notion that the created software conforms to the intent of the creator, and the creator has to verify such conformance. In less critical applications and domains, correctness is a matter of trial. If I’m making a website to present some information regarding a party I’m throwing, I will check that the website shows all the relevant information I wanted it to. If the party's just with some friends, that is probably fine to have. If the party is for work, I will try it on my phone in addition to my computer, perhaps even ask a few friends with different devices to check it out and make sure everything looks good. Even in the example above, the importance of correctness is contextual. With changing domains and scale, the mechanisms we verify correctness also changes. When we are creating software as a business application, experts on “trying” (QAs) are hired to test many paths in the program to discover unexpected behavior, a.k.a. bugs. A typical company spends a great deal of time on testing their code in addition to trying it, where the rigor of testing changes with respect to the scale of the number of users, money at stake, criticality of the application domain at hand. A small SaaS company might only write some integration tests checking out some scenarios or implement unit tests for some of their components, whereas AWS will mathematically prove the correctness of the S3 implementation that serves petabytes of data every day. So, basing our argument on the discussion so far, it should be possible for an LLM to generate a codebase that does not require rigorous correctness. Perhaps it even could generate tests, or perhaps even write proofs on the code it writes, right? Maybe LLMs could really remove humans from the process and work on their own as a set of agents working together; if not now, perhaps when they’re better. I’ve heard this argument multiple times during discussions. The problem is, we have not taken into account verifiability of the code. We have talked about rigor and scale, but rigor is not enough as a parameter on the LLM-ability of a domain, we need to talk about how the code LLM generates is verified, and that includes testing code too. Let’s take a step back and take UI programming (mostly connotated with frontend development) into consideration. Anecdotal evidence from many practitioners state that LLMs are able to generate entire frontend applications in one prompt, or even drawings on a napkin. We see specialized tools such as V0 that focuses solely on UI generation. Yet, they are not that successful, or at least popularized in other domains. A popular folk sentiment regarding this phenomenon is that LLMs are trained over public domain repositories, and UI programming makes up a great portion of such code. Yet, that does not explain why LLMs are not that popular in web server applications (mostly connotated with backend development), which are perhaps almost as prevalent as UI programming, and has even less diversity and more structure in its code. Although there is some psychological explanations regarding this discrepancy between frontend and backend popularity, mainly that creating UIs that are shiny and impressive is easier than creating backends that could attract the same level of attention, hence anecdotal evidence regarding the popularity or usability of backend/frontend comparison should not be given much credit, I hypothesize that UIs are much easier to verify than any other domain we write code for. Verification of UI is almost literally “looking”. When we look at a web page, we almost instantly recognize how the generated code diverges from our intent and can provide instant feedback back to the LLM. Verification of a web server requires setting up a set of test inputs, sending them to the server, perhaps creating some ephemeral state, and checking that the outputs conform to our expectations. This is, in fact, so much easier to write tests for than trying, whereas writing UI tests is a 30 year old long pain point that has not yet been solved. The rise of “vibe coding games” last week seems to stem from the same root. The generated games are nonetheless impressive, but their verification is possible via trial. Typically implemented over a single server with no persistent state, the games look over complex networking or performance problems by degrading user experience or removing features that cause those problems rather than solving the problems themselves. This is not to say this is not a valid choice, but the reason for this choice is not that those things do not matter, it is that they are harder to verify correctness for, require custom testing infrastructures or domain knowledge for verification. Going back to the title, verifiability is the limit. It is the limit that tells us what we cannot implement via LLMs, and it cannot be solved with agentic approaches. A security agent might in theory add security checks to an application, but such a check is worthless without verifying it as the person who intends to produce the code. A testing agent might add tests to a program, but the tests themselves are meaningless until we check to see they correspond to our intent. So far, I theorized about the LLMs and the way we produced software to make my point. Now, I shall preach about what I think we should do. If verifiability is the limit, if it’s the bottleneck of using LLMs for programming, the natural question is how do we raise the limit, how do we make it easier to verify? I believe the first step we need to take is to concede defeat on the infinitely powerful and scalable software agents ideology. If verifiability is really the limit, no amount of agents is going to solve the problem. The way I see it, we need better tools and interfaces for verification. For example, instead of the programmer reading the tests LLM generates, it could be possible to summarize the generated tests into a human readable format, while of course the summarization also poses a threat of information loss. We should rely much more on declarative random testing methods such as property-based testing, where the programmer defines a predicate that should hold over all possible inputs, and this predicate is tested by generating random inputs and passing them to the program. Such methods have been used to enhance the reliability of programs in many domains, but they haven’t caught up with the software engineering community. The advantage of such methods is that having one general predicate is much easier to inspect and understand than many unit tests, in addition to the added testing strength. We need to increase the vocabulary we’re using when talking about correctness. We need to have a wider understanding of performance, security, accessibility, flexibility, and how to measure such qualities of programs so that we know what we are looking for in our applications, and we have mechanisms for verifying these qualities. In status quo, correctness is typically attributed as functional correctness, where it mostly means “input-outputs are as expected”, and most other expectations from an application is bundled under “non-functional properties” and the software engineering community has ignored to properly measure and verify them at large. Let me sum up with a prediction. For a very long time, I have believed LLMs would not be good coders, even with further improvements. My views have shifted after their success in competitive programming, perhaps as a reformed competitive programmer, that was my Lee Sedol moment. I now, although tentatively, believe that LLMs can indeed succeed in all domains with perfect oracles. It is important to understand that this does not mean LLMs will be gods producing 100x code, because virtually no domain that software engineering is useful has a perfect oracle. A perfect oracle is a type of feedback where you are given a “correct/incorrect” answer every single time, and they almost only appear in games as real world typically doesn’t have perfect models of correctness. Winning or losing a game is a perfect oracle, as well as creating a program that can pass the judge in a competitive programming contest. Even the most formalized aspect of programming, the theorem provers where users can prove their code correct, are not perfect oracles, as they cannot tell you if you are on a good path at an intermediate point in the proof, but only give you information if your proof is correct or if you are stuck. I hope that this imperfect oracle will be enough to win the game of proving, and that LLMs will be better than us in automated proofs. If such a day comes, our next job could be creating new theorems, asking LLMs to produce code and proofs, and scaling such systems into production grade codebases safely and securely. Please let me know what you think of this at akeles@umd.edu</a>, and share with others if you found this interesting. Tip Sistemleri Hakkında 2024-12-01T00:00:00+00:00 Tip sistemleri(type systems), programlama aktivitesinin temelinde yer almalarına rağmen gözümüzün önünden kaçan, programlama dillerinin özellikleri arasında çoğu zaman düşünmediğimiz, en az konuştuklarımızdan birisi. Bu yazıyı tip sistemlerinin günlük programlama pratiklerimizi nasıl yönlendirdiğini merkeze alarak yazmaya çalışacağım. Tip Sistemi Nedir?</a></h2> Her programlama dili, bazen dikkatli bir matematiksel dizaynın sonucunda oluşturulmuş, bazen de yaratıcısının tercihlerini yansıtacak şekilde bir tip sistemi içerir. Tip sistemleri, programlama dilindeki işlemlerin geçerliliğine dair yargılarda bulunmamızı sağlar, geçersiz işlemler sonucunda bizlere hata mesajları verir. Tip sisteminin dizaynı yazdığımız programların ne kadar jenerik olabildiğini, kullandığımız kodun içerisinde yazmamız gereken tip işaretçilerini(type annotations), kullandığımız editörden aldığımız tip ipuçlarını(type hints) etkiler. Küçük bir aritmetik dili ile yolumuza başlayalım. Dilin yapısının tanımlanmasına BNF(Backus-Naur Form) adı verilen, programlama dillerinin gramerlerini ifade etmek için kullanılan bir notasyondan faydalanacağız. e ::= e + e | e - e | e && e | e < e | e > e | 1 | 2 | 3 … </code></pre> Sırada, bu dildeki işlemlerin anlamına(semantics) karar vermek gerekiyor. Sırasıyla elimizdeki işlemler toplama(+</code>), çıkarma(-</code>), mantıksal ve(&&</code>), küçüktür(<</code>), ve büyüktür(></code>) işlemleri. Peki (3 < 5) + 2</code> bize nasıl bir anlam ifade etmeli? Böyle bir işleme izin vermeli miyiz? Yoksa hata mı vermeliyiz? İzin verirsek nasıl bir sonuç vermeliyiz, hata verirsek nasıl bir hata vermeliyiz? Hadi gelin bu tarz bir işlemle karşılaştıklarında şu anki popüler programlama dillerinin neler yaptığını inceleyelim. Python, Javascript, C: 3 </code></pre> Typescript: Operator '+' cannot be applied to types 'boolean' and 'number'. </code></pre> Rust: error[E0369]: cannot add `{integer}` to `bool` --> error.rs:8:13 | 8 | (3 < 5) + 2; | ------- ^ - {integer} | | | bool </code></pre> Java: error.java:6: error: bad operand types for binary operator '+' ((3 < 5) + 2); ^ first type: boolean second type: int </code></pre> Gördüğümüz üzere, Python, Javascript ve C (3 < 5) + 2</code> programını gördüklerinde 3 < 5</code>’i toplama bağlamında 1 olarak yorumlayıp cevabı 3 bulurken, Typescript, Rust ve Java toplamanın mantıksal bir ifade(boolean) ile bir sayı(number, integer ya da int) arasında geçerli olmadığına karar verip, buna dayanarak programımızı reddediyorlar. Diller arasındaki bu farklılıklar, tip sistemlerinden kaynaklanıyor. Yazdığımız programlardaki her bir ifadenin bir tipi var, tip sistemleri ise programın içerisinde yer alan farklı ifadeleri programlama dilimizdeki yapıları kullanarak bir araya getirme aşamasında bizim hatalarımızı keşfetmemize imkan sağlıyorlar. Peki Python, Javascript ve C aynı tip sistemini mi kullanıyorlar, basit bir örnekle görebiliyoruz ki hayır. Dilimize sicimleri(string) eklediğimizde Python ve Javascript arasındaki farkı görebiliyoruz. Yeni işlemimiz ”alp” + 3</code>. Python: Traceback (most recent call last): File "<python-input-0>", line 1, in <module> "alp" + 3 ~~~~~~^~~ TypeError: can only concatenate str (not "int") to str </code></pre> Javascript: "alp3" </code></pre> Burada yaşanan farklılıkların sebebi otomatik tip çevirisi(implicit coercion) kurallarının dilden dile farklı olması. Popüler kültürde bunu bazen zayıf/güçlü tipleme(weak/strong typing) olarak duysak da, bu terimler dilleri kategorize etmek için yeterince kesin değil. Daha ziyade tip sisteminin içerisine yerleştirilmiş tip çeviri kuralları. O zaman, başta bahsettiğimiz (3 < 5) + 2</code> işleminin reddedildiği bir tip sistemi tasarlayalım. Burada tip teorisi(type theory) notasyonunu kullanarak tip sistemini yazabiliriz. Notasyonu aşağıdan yukarıya okumak gerekiyor. Sayı sabitlerinin tipi ile başlayalım. ----------------------(integer) Γ, 0,1,2… : integer </code></pre> Bu kural, bize şunu söylüyor. Γ(Gamma)</code>: Şu anda programdaki diğer ifadelerin tiplerini tutan bir mapping.</li> (0,1,2… : integer):</code> 0, 1, 2… sayı sabitlerinin tipinin tamsayı(integer) olduğunun ifadesi.</li> Uzun çizgi(----</code>): Altta verilen tip yargısının(typing judgement) geçerli olması için gerekli tip yargıları.</li> </ul> Bu örnekte çizginin üstünde bir gereksinim olmadığı için, programdaki herhangi bir sayı sabiti gördüğümüzde o sabitin tipinin integer</code> olduğunu söyleyebiliyoruz. Γ, e1 : integer Γ, e2 : integer ---------------------------------------(+) Γ, e1 + e2 : integer </code></pre> İkinci baktığımız kural ise bize şunu söylüyor, iki ifadenin toplamı, eğer toplamın sağ ve sol kollarının tipi tamsayı ise tamsayı olur. Bu kuralı programdaki herhangi bir toplama işleminin doğru tiplere sahip olduğunu kanıtlamak için kullanabiliriz. Bunun için de türetim ağacı(derivation tree) adını verdiğimiz kuralları üst üste koyarak büyük ifadelerin tiplerine karar verdiğimiz bir metot kullanıyoruz. 1 : integer 2 : integer ------------------------------ 1 + 2 : integer 3 : integer --------------------------------------------------- (1 + 2) + 3: integer </code></pre> Bu kuralı aşağıdan yukarıya doğru okursak, (1 + 2) + 3</code>ün tipinin tamsayı olması için, 1 + 2</code>nin tipinin tamsayı olması gerekir, onun için de 1 ve 2’nin tiplerinin tamsayı olması gerekir, diğer yanda da 3’ün tipinin tamsayı olması gerekir. Bir türetim ağacı yazdığımızda ağacın tüm yapraklarının(leaf) en başta bahsettiğimiz ek gereksinimi olmayan kurallardan birisi olması gerekir. Aşağıda, sırasıyla çıkarma(-</code>), küçüktür(<</code>), büyüktür(></code>) ve mantıksal ve(&&</code>) kurallarını okuyabilirsiniz. Γ, e1 : integer Γ, e2 : integer ---------------------------------------(-) Γ, e1 - e2 : integer Γ, e1 : integer Γ, e2 : integer ---------------------------------------(<) Γ, e1 < e2 : bool Γ, e1 : integer Γ, e2 : integer ---------------------------------------(>) Γ, e1 > e2 : bool Γ, e1 : bool Γ, e2 : bool ---------------------------------------(&&) Γ, e1 && e2 : bool </code></pre> Eğer ki yazılan bir program için bir türetim ağacı üretemiyorsak, o halde o programa biz hatalı-tipli(ill-typed) deriz. Misal, yukarıdaki tip sisteminde (3 < 5) + 2</code> programı için bir türetim ağacı yok, çünkü (e1: bool + e2: integer)</code> için kullanabileceğimiz herhangi bir kural yok, dolayısıyla türetim esnasında sıkışıyoruz(stuck). 3 : integer 5: integer -------------------------- (3 < 5): bool 2: integer ----------------------------------------- (3 < 5) + 2 : ?? </code></pre> Dolayısıyla eğer ki bu ifadenin makul-tipli(well-typed) olmasını istiyorsak tip sistemine bu ifadenin tipini belirleyecek yeni kurallar eklememiz gerekiyor. Bunu yapmanın birden fazla yolu var, ilki de şu. Γ, e1 : bool -----------------(b->i) Γ, e1 : integer </code></pre> Bu kural sayesinde, (3<5): bool</code> tiplemesini (3<5): integer</code> tiplemesine çevirebiliyoruz. Diğer ihtimalde ise herhangi bir bool tipinde değeri integer’a çevirmek yerine, bu çeviriyi yalnızca toplama işlemi esnasında yapabiliriz. Γ, e1 : bool Γ, e2 : integer ---------------------------------------(b+i) Γ, e1 + e2 : integer </code></pre> Ancak bu durumda tek bir kural bizim için yeterli değil. Çünkü bu kural (3<5)+2</code> için yeterliyken, 2+(3<5)</code> için değil. Dolayısıyla kuralın ters versiyonuna ihtiyacımız da var. Γ, e1 : integer Γ, e2 : bool ---------------------------------------(i+b) Γ, e1 + e2 : integer </code></pre> Burada bu kuralların hepsinin sözdizimsel(syntactic) olduğu gerçeğini net bir şekilde görebiliyoruz. Bizler kendi kafamızda a+b</code> ile b+a</code>yı birbiri ile ilişkilendirsek de, üzerinde çalıştığımız sisteme bu tarz kuralların hepsini tek tek kodlamamız gerekiyor. Hem i+b</code> hem de b+i</code> şeklinde 2 kural yazmak yerine, ikinci kuralı daha genel bir kural olan toplamın değişebilirliği (commutativity) olarak da yazabilirdik. Γ, e2 + e1 : T ---------------(commutative) Γ, e1 + e2 : T </code></pre> Fark ettiyseniz, ilk kez e1, e2</code> gibi ifade değişkenlerinin(expression variable) yanı sıra bir tip değişkeni(type variable) olan T</code>’yi kullandık. Elimizdeki toplama, karşılaştırma ve mantıksal ifadelerin üzerine programlama dillerinde kullandığımız if-else</code> ya da fonksiyon uygulaması(function application) gibi yapılar işin içerisinde girdiğinde bu tarz tip değişkenleri tip sisteminin çok daha içerisinde oluyor. Mesela, aşağıda dile if-else</code> ifadesi(expression) eklediğimizde kullanacağımız kuralı inceleyelim. Γ, e1 : bool Γ, e2 : T Γ, e3 : T ---------------------------------------------------(if-else) Γ, if e1 then e2 else e3 : T </code></pre> Bu kuralı okursak, if-else</code> ifadesinin makul-tipli olması için e1</code> ifadesinin bir boolean olması, e2</code> ve e3</code> ifadelerinin de aynı T</code> tipine sahip olması gerek. Bir diğer genel kural ise fonksiyon çağrısı(function call). Γ, e1 : T1 Γ, e2 : T2 … Γ, en : Tn Γ, fn : (T1, T2…Tn) -> T --------------------------------------------------------(fn-call) Γ, fn(e1, e2…en) : T </code></pre> Bu kuralı okumak için de, (T1,T2, … Tn)</code> tiplerinde girdileri kullanarak T</code> tipinde bir çıktı üreten bir fonksiyonu çağırmak için, fonksiyona sağladığımız girdilerin sırasıyla T1, T2…Tn</code> tiplerine sahip olması gerek. Bu kurallar ile birlikte, bir tip sistemi nasıl yazılır hakkında kısa bir giriş yapmış olduk. Şimdi, tip sistemlerinin nasıl kullanıldığını tartışalım. Statik ve Dinamik Tip Sistemleri</a></h2> Tip sistemleri ile ilgili ilk tartışma statik ya da dinamik olmaları. Bu yazıda bu tartışmayı mümkün olduğunca ileri atmak istedim, çünkü statiklik ve dinamiklik bir programın bir tip sistemince makul-tipli kabul edilip edilmemesine katkıda bulunsa da, tip sisteminin kendi dizaynı çok daha etkili. Sistemin statik veya dinamik olması bir programın kabul edilip edilmemesinden ziyade, hangi noktada reddedileceğini etkiliyor. Statik tip sistemi implementasyonları programın derleme zamanında(compile time) tip bilgisini kullanarak programın tipini kontrol ederken, dinamik tip sistemleri programın çalışma zamanında(run time) tip bilgisini kullanarak programın tipini kontrol ediyor. Tabii ki bu farklılık, tip sisteminin kendi dizaynını da yeri geldiğinde etkileyebiliyor, çünkü statik bir sistemde tip bilgilerini taşıyıp programın herhangi bir girdi için makul tipli olduğunu kanıtlamak gerekirken, dinamik bir sistemde programın çalışması esnasında sahip olduğumuz tip bilgilerinden yararlanabiliyoruz. Statik ve dinamik sistemler arasındaki en büyük fark if-then-else</code> gibi şartlı(conditional) ifadelerde ortaya çıkıyor. Yukarıda örnek verdiğim tip sisteminde if-else</code> ifadesi için yazdığımız kuralda hatırlıyorsanız then</code> ve else</code> kollarının tipleri aynı olmalıydı. Bu kural, statik tip sistemlerinde sıkça gördüğümüz bir kural, çünkü statik bir tip sistemi programa hangi kol ile devam edileceğini bilmediği için programın devamında iki kolun da tip bilgisini taşımak zorunda. Buna bir alternatif birlik tipleri(union types) kullanmak, örneğini Typescript'te görebiliriz. let a: string | number = Math.random() > 0.5 ? "alperen" : 3; </code></pre> Yukarıdaki kod içerisinde kullandığımız üçlü-şart-ifadesi(ternary if-expression) içerisinde then</code> ve else</code> kolları farklı tipler dönüyor, dolayısıyla bizim sonuçta elde ettiğimiz tip string | number</code> (string veya number) oluyor. Bu kuralı şu şekilde yazabiliriz. Γ, e1 : bool Γ, e2 : T1 Γ, e3 : T2 --------------------------------------------(if-else-union) Γ, if e1 then e2 else e3 : T1 | T2 </code></pre> Bu iki kuralı dinamik tipli bir tip sisteminde yazmamıza gerek bile yok, ileriye doğru taşımamız gereken tip bilgisini programın çalışma zamanında elde edebiliyoruz. Bu durumda, programın sonucunu hesaplarken(evaluation) hangi kolun seçildiğine göre ileriye doğru ileteceğimiz tip bilgisini değiştirebiliriz. Γ, e2 : T --------------------------------------------(if-true) Γ, if True then e2 else e3 : T Γ, e3 : T --------------------------------------------(if-false) Γ, if False then e2 else e3 : T </code></pre> Aşağıda, girdi alperen</code> olmadığı sürece tip hatası verecek bir Python programını görebilirsiniz. Aynı programı statik bir tip sisteminde yazdığımızda tip kontrolcüsü derleme zamanında hata verecektir, çünkü a</code> değişkenininin alperen</code> olmadığı koşulunda a</code> değişkenine makul bir tip atamak mümkün değil. a = input() if a == “alperen”: return 3 + 5 else: return “a” + 3 </code></pre> Dinamik tip sistemlerinin bir diğer farkı da tip denetimi(type inspection). Statik tip sistemlerinin sağladığı en büyük artılardan birisi programdaki tipler derleme esnasında belirli olduğu için derleme zamanında(compile time) tip bilgisinin kullanılması, ancak programın çalışması zamanında(run time) tip bilgisinin silinmiş olması. Bu sayede dinamik tip sistemlerinde ortaya çıkan tip bilgisinden kaynaklı performans kaybından kaçabiliyoruz. Diğer yanda, çalışma zamanında tip bilgisine erişimimizin olması da dinamik tip sistemlerinde heterojen listeler (heterogeneous lists) gibi veri yapılarını yazıp kullanabilmemize imkan sağlıyor. Teoride statik bir tip sisteminde de heterojen listeler oluşturabilsek de, bu listenin elemanları üzerinde herhangi bir işlem yapabiliyor olmamız mümkün değil. Yine bir Python programıyla örnekleyelim. l = [1, True, “alperen”] for elem in l: if type(elem) == int: print(“Element bir tamsayı”) elif type(elem) == bool: print(“Element mantıksal bir değer”) else: print(“Element tipini bilmiyoruz”) </code></pre> Aynı programı, Rust gibi bir programlama dilinde yazmamız mümkün değil, çünkü Rust listenin tipinin heterojen olmasına izin vermiyor.</del> E peki statik tipli bir programlama dili implementasyonunda farklı tipten değerleri içeren bir liste oluşturamaz mıyız? Bu sorunun cevabını vermek için gelin çok-tiplilikten(polymorphism) bahsedelim.

Alperen Keles

On The Simplicity of Humanness

What is a property?

Closing the verification loop: Observability-driven harnesses for building with agents

Seeing types where others don't

Specifiability is the Leverage

The Mechanics of Autonomous Software Translation

LLMs could be, but shouldn't be compilers

Test, don't (just) verify

Formal Metotlar ve Kanıtlı Programlama Hakkında

Temporal Shrinking

Verification is Not the Silver Bullet

Designing A Digital Restaurant

How can we secure Package Managers?

From Hand-Tuned Go to Self-Optimizing Code: Building BitsEvolve

Programlama Dilleri Hakkında

Breaking Verifiable Abstractions

A Better Vocabulary for Testing

Bilgisayar Mühendisleri için Hafif* Ekonomi

Omurga Yazılımlar</a></h2> Not: omurga kullanmak istediğim asıl terim için --"backbone"-- çok iyi bir çeviri değil, daha iyi bir çeviriniz varsa iletirseniz sevinirim.</p> </blockquote>

Filling in the Missing Bits

Time Budget as a Software Constraint

Verifiability is the Limit

Tip Sistemleri Hakkında