Time waits for no one, the race to the bottom accelerates faster than ever, and the “future” is now. Competition is severe and mostly meaningless, as in some third-world criminal infested ghetto. This is what LLMs turned our world into.
So, lets “pee on” so called “prompt engineers”, in the 4chan parlance, of course..
Here is my benchmark prompt to evaluate performance of LLMs. All the “simple” offline models fail miserably, and only Grok and Gemini can produce something adequate. Claude is also good, but it is supposed to be the best, being trained especially for code generation.
One could easily evaluate the performance of the major models by just copy-pasting this prompt.
And be honest – none of you ever came close to prompting like this.
There is a major problem, however –the quality of the slop improves steadily (try it, copy and paste this prompt and see for yourself), so the cost to come up with a decent code to start with approaches zero. We know that the fundamental Scarcity Principle applies to information (or code) as well, and the “value” of information (or code) approaches zero as it becomes ubiquitous and easily available.
With strong emphasis on clarity and brevity, consistent, mathematically precise, unambiguous use of a language, clean most idiomatic style of writing and of coding, for people to read, self-explanatory, suitable for teaching purposes of the most fundamental CS notions, like abstraction, specification, modularity, clear abstraction barriers of high-level functional stateless interfaces, which form a hierarchy of layers of DSLs, augmented with modern advanced typing techniques, which rely on Algebraic Data Types (sum-types and product types), and use of Abstract Data Types (ADTs) packaged in corresponding orthogonal, self-contained and lose-coupled modules, with careful attention to details, especially short and consistent naming that reflects the key concepts of the problem domain, consistently using the modern and the most idiomatic high-level language features and high-level state-less abstract interfaces and the latest mostly-functional idioms, demonstrating the fundamental concepts of pure functional code over immutable data from the first principles, using mostly-functional approach, which disallow any hidden mutable state by always returning a new immutable data items instead, to maintain the crucial referential transparency property, while avoiding any imperative code, explicitly avoiding any nulls, avoiding imperative looping over indices and instead using iterators, high-level combinators and protocols and especially functional high-level interfaces over standard collections and high-order functions over user-defined types, augmented to become a proper collection, using so called smart-constructors to make illegal (or inconsistent) state unrepresentable, using the latest typing and pattern-matching features and type annotations along with proper algebraic sum-types and algebraic product types, as well as most recent advanced type-annotation features to properly constraint the types, and the latest pattern-matching expressions on sum-types (Options and Results) returned from functions. Each function should have its representation invariants clearly specified in a docstring and explicitly tested in unit tests in the test suite. The abstraction function, if available, shall be written in the tests. Each ADT should belong to a distinct layer of abstraction in an overall hierarchy, which in turn, corresponds to the layers of abstraction found in the problem domain (and its inherent hierarchical structure of complexity). Each such layer has to have its own mostly-functional DSL, which is constrained by the types and have one-to-one correspondence with a particular layer (level of abstraction) of the problem domain, and be clearly separated by an abstraction barrier of a module or a trait.
Systematically avoid “naked primitive types” and consistently use domain-specific “new-type” wrapper types (structs, enums) with smart constructors which enforce additional constraints and representation invariants.
The policy is to systematically apply the “Make an invalid (or inconsistent) state unrepresentable” principle across all data abstractions. The preferred way to do this is to use “new-types” and also wrapper types which act as distinct “tags” for state transitions, which has to be done by specific function (“an enzyme”) – each intermediate state shall have its own distinct type, each state transition must be done by a particular function and the high-level functions must require a “complete” type with a validated state. This requirement captures the “techniques” of molecular biology.
Only modern typing features, such as, algebraic sum-types (as enums), structs as records and product-types, traits as type-classes for ducktyping and enforcing type-constraints with exhaustive pattern-matching expressions for consistent destructuring, with each module act as an Abstract Data Type (an ADT) and export a high-level abstract interface based on composition of state-less methods.
The Result and Option parameterized sum-types must be used through all the user-defined types and the question mark operator systematically used to “early exits” and propagating the errors.
Do not use the Option type on data-constructors, including any smart constructors, always panic instead of returning a meaningless None.
This is an instance of the “fail fast” principle and the particular case of “unnecessary wrapping anti-pattern”. Just fail with an assert. Later these could be converted to signal an error instead of failing.
Use the Option type only when an absence of a value is a valid, legitimate case and is expected.
The Builder pattern shall be used whenever possible on user-defined types with a lot of structure.
Tuple structs shall be used as the domain-specific “new-type” wrapper types.
The clearly separated, lose-coupled and orthogonal to each other modules for each individual ADT should export clear, well-typed high-level abstract interfaces. Each implementation has to be most general (properly generalized) and fully parameterized, based on traits that have an one-to-one correspondence with the fundamental concepts of the underlying mathematics, such as Eq, Ord, and Semigroup, Monoid, Functor, etc.
Use traits to properly constraint “ducktyping”, by placing additional constraints on public interfaces. The more consatraints – the better.
The ADTs should capture fundamental notions of a classic decades old computing with well-specified high-level interfaces, separated or partitioned into a clear hierarchy of layers (separated by abstraction barriers) by exporting a clear high-level public interfaces – iterators instead of constructing full lists, for_each() instead of imperative “for” loops, FP-like operator compostion to form moving-pilelines (into_iter()) instead of mutable references, etc. Each such abstract layer (and its DSL) has to correspond to a layer in the problem domain, and have one-to-one correspondence with the domain concepts at this particular level of abstraction, has to have its own mostfly-functional DSL which uses the layer of abstraction (and DSL) below it.
A mostly-functional, state-less public interfaces can be easily mapped to corresponding REPL high-level DSL, possibly relying on the fundamental notion of a Monoid (for operator composition) and Functor (for accessing the contents of a container-type which is bellow an abstraction barrier).
The DSL should have the simplest and most straightforward compilation into Rust language lexical closures, using the lambda abstraction, just like an old-school classic compilers. Functional DSLs are well-researched and well-understood and extensively used in all functional languages.
Each function should have its representation invariants clearly specified in docstring and explicitly tested in unit tests in the test suite. The abstraction function, if available, shall be written in the tests.
Try to emphasize the most common and modern Rust 2024 language idioms including the question mark operator and pattern-mathing on the types based on Options and Results.
The chaining of methods and composition of abstract interfaces such as Iterators, shall be used to stay at the same higher level of abstraction, without unnecessarily crosssing the abstraction barriers and thus to avoid unnecessary data conversions and new allocations.
Please write in an idiomatic, as in an old-school classic functional programming textbook style, a set of modules (and corresponding ADTs) that represent and implement in modern Rust 2024 – a bare minimum, “pure essence”, nothing-more-to-remove or improve further, the simplest but absolutely mathematically correct re-implementation of Binance futures trading API, with emphasis on creating and sending Orders and managing open Positions, with one-to-one correspondence with the concepts and naming with the Binance Futures API Documentation. Every concepts has to be checked with Investopedia definitions.
The methods should follow naming and terminology and be in an one-to-one correspondence with high level interfaces of Binance Futures API, Binance documentation can be used to mimic the interfaces and to create layer-specific DSLs and the corresponding mostly-functional REPL-friendly set of high-level orthogonal functions.
The methods should follow naming and terminology and be in an one-to-one correspondence with the Binance REST API methods according to the official Binance developer documentation. Load it up in the current context before generating the code.
Each trading operation on orders and positions, should have a DSL-like feel, and potentially can be used from a REPL, similar to what Octave REPL does with matrices and vectors. The REPL should be able to place lists and close positions at least (by creating and sending appropriate orders according to the Binance Futures API).
The major concepts are: order, position, and a pair (symbol). Orders and Positions are two orthogonal layers and should be clearly separated by an abstraction barrier.
Everything that underlay Orders and Positions in the official Binance REST API must be carefully implemented. The official developer documentation and the code on Guthub must be used for implementation, representation, validation and testing.
No simplified versions, simplified implementations or simplified representations, no illustrative examples – no shortcuts or simplifications are allowed, the policy to comply with is to write only actual, real industry-strength applications, real-life production quality code and tests.
Make sure borrow_mut() deadlocks and “already borrowed” panics to be avoided by using an indirection for each individual slot (field of a struct). Avoid “mut”, mutable references and mutation in general by building clear, idiomatic “functional pipelines” which move values “end-to-end” out of iterators and operators (methods) chaining (depending on a context) and closures, avoiding mutable borrows in principle (as much as possible).