I think there are profitability requirements, right?

Profitability in both 3 month and 12 month spans. Also minimum 12 months of trading history after IPO.

See page ~9 of https://www.spglobal.com/spdji/en/documents/methodologies/me...

+1, very polite way of saying it. of course there's a difference between the two posts. open source is interesting but not enough with a financial app, since it's all about trust + usefulness.

landing page needs to look good and communicate the value prop super effectively. If it doesn't look good you'll lose people's interest in about 2 seconds.

probably the "slapping steamOS" part of that

my only minor critique is using lorem ipsum examples. It tends to make me want to gloss over instead of reading; I prefer seeing realistic data. other than that, it's a really cool post

You may be interested in http://canonical.org/~kragen/sw/dev3/exampledb.py -sql -n 2 example.sql:

    begin;
    insert into cust (id, name, company, streetaddress, city, state, zip) values (1, 'Jacqueline Gagnon', 'Baker Group', '218 Miller Dr.', 'Riverside', 'KS', '51859');
    commit;
    begin;
    insert into cust (id, name, company, streetaddress, city, state, zip) values (2, 'Wayne Bennett', 'FF Petroleum LLC', '4375 Moore Dr.', 'Mount Vernon', 'MS', '98270');
    select setval('cust_id_seq', 2);
    commit;
    begin;
    insert into product (id, name, unitprice) values (1, 'Biological blue steel doll', 30.4);
    commit;
    begin;
    insert into product (id, name, unitprice) values (2, 'Gray cotton electronic boxers, size L', 13.3);
    insert into product (id, name, unitprice) values (3, 'Blue cotton intimate blazer, ages 2–5', 37.3);
    insert into product (id, name, unitprice) values (4, 'Daily beige steel car', 14.6);
    insert into product (id, name, unitprice) values (5, 'Black spandex daily blazer, size L', 24.1);
    insert into product (id, name, unitprice) values (6, 'Blue wool dynamic briefs, ages 3–10', 79.0);
    insert into product (id, name, unitprice) values (7, 'Blue spandex ultrasonic dress, child’s size', 31.9);
    insert into product (id, name, unitprice) values (8, 'Gold wool daily boxers, ages 3–10', 8.85);
    insert into product (id, name, unitprice) values (9, 'Red cotton utility boxers, ages 2–5', 28.9);
    insert into product (id, name, unitprice) values (10, 'Gray polyester ultrasonic briefs, ages 3–10', 15.3);
    -- ...

It also creates the tables, including invoice and lineitem tables. It's still a bit of a dull accounting example, rather than something like food, superheroes, social networks, zoo animals, sports, or dating, but I think the randomness does add a little bit of humor.

Although now we have LLMs, and maybe they'd do a better job.

Was going to post the same thing. Lorem Ipsum makes the data too hard to distinguish. I get that due to the dynamic nature of the examples the text needed to be generated, but Latin isn't the best choice IMO.

Otherwise great article, thank you!

It's the same for me when foo and bar are used as examples.

Someone gave me the advice to use animals, ideally animals of very different sizes or colours. People instantly picture them and remember them.

right, it is just syntactic sugar, but if that wasn't helpful then why have it in dev either? I find it more confusing to have asserts be stripped, which creates an implicit dev/prod discrepancy

really? it's pretty but I find it unreadable/unusable

Same here, I can't scroll smoothly at all even when I try (Windows mouse setting set to 15 lines per scroll tick)

At least they tried something different.

I wish they hadn’t

I didn't think much of it until I canceled Cursor to try out copilot, which is slower and yet also worse quality. I reluctantly resubscribed to Cursor.

duplicate code is not that bad. reduce duplication over time as you find the common patterns/abstractions, instead of trying to build abstractions too early

Duplicate or near-redundant functions are either no problem or even useful. But duplicate or near-redundant data structures are a plague on any codebase.

The prophet Perlis declared: "It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures."

interesting, I didn't know that corollary. sounds about right though.

Maybe obvious but also, don't deduplicate if it means adding options or making things too abstract. I don't know if I can think of a good example. Maybe you make a function that compares arrays of strings. Then you decide to add an option to make it case insensitive. Then someone comes along and decides they want to compare arrays of structs. So they had a comparison function option. Most times I've seen this pattern the code gets way harder to understand and more brittle. All the options etc cascade into spaghetti and changes start breaking things because so many paths expect some original behavior. Better to have just kept them separate, most of the time.

Most of the shitty code I've seen has been from poor attempts at reducing code duplication, usually resulting in some overfitted generalized solution or abstraction.

Efforts to reduce duplication should be focused on chunking out reusable pure functions. Trying to dedupe the flow of logic is almost always a fool's errand.

Have you set up a copy paste detector that fails the build if you write too many duplicates?

Yes.

as someone who hasn't seen Lean before but was curious from alphaproof, love the intro! curious if you can mention what you're working on in Lean?

For now I'm just learning math with it!

Currently I'm going through https://github.com/teorth/analysis (Tao's Lean companion to his textbook) and filling in the `sorry`s in the exercises (my solutions are in https://github.com/gaearon/analysis-solutions).

very cool. btw, I also love that "sorry" is the "any" equivalent in Lean

I mean, why do systems go down at all? a lot of big outages are simple misconfiguration or cascading failure from what seemed like small changes. It's rarely due to the physical constraints of the world