alxmng

Hmm maybe I misunderstand. All the rules must be applied to fixpoint or elimination, for every input right? And the larger the program (rule set) the worse the performance since more rules must be evaluated at each “tick” of the program, unless you play tricks with ordering rules.

I think the issue is performance. A true term rewriting system has to essentially operate on text, right?

What I've noticed is if there's 1 product, 500 sellers will buy the product on Alibaba, create 500 different "brands", and when searching Amazon it appears there's thousands of products but it's actually a handful of the same product white labeled by many different sellers. The actual number of unique products in many categories is quite low but there's thousands of listings.

This is essentially the RPC vs REST debate. Do you want your API to be a schema of data types (REST), or a list of function signatures (RPC)?

There's plenty of available gardening space in unused yards. Ask your neighbors if you can garden their unused yard in exchange for them getting a cut of the produce or flowers.

Check out the paper "Dedalus: Datalog in Time and Space". It formalizes a Datalog to include time, specifically to handle async behavior. It explores exactly what you seem to be doing here.

Did you consider writing a nicer language that compiles to Nix? A "friendly" tool on the outside with Nix inside.

When I first started the project, URLs needed certain constraints enforced in my business logic. So I thought "Great, let me create a type for URLs". This is the type that parses URLs from user input and gets marshaled/unmarshalled to the DB.

Then I needed to ingest RSS feeds. So I found a library that handled that for me. Except that library uses another type for URLs. Uh oh. What should I do? I could change my URL type to be a wrapper type around both types, or write code to convert between the types. I chose to convert. Now I'm writing code to shuffle between the types where this RSS parsing module is used.

Then I needed to make HTTP requests. So I pulled in a library to handle HTTP requests. Of course, that library uses another type for URLs (from another library it depends on). Great. Now I have 3 types for a URL.

Then I needed to parse XML... and you know where this story is going.

So now my codebase has many different URL types.

The type-a-holics will say: "This is actually good! Each implementation of the URL type might have slightly different constraints, and the type system makes this all explicit. You should be grateful you spend half of your development time fiddling with types. The fact that `unpack . decodeUtf8` is littered around your codebase isn't code smell, it's the splendor of a type system that's saving you from yourself. You should learn to love the fact that you have to deal with String, Text, and ByteString and 4 URL types to fetch and parse an RSS feed. Otherwise your software would be full of bugs! Silly developer."

One day I finally woke up from this type nonsense. There's integers, rationals, strings, lists, and maps. The end.

This is my experience as well. Referential transparency and immutability have many advantages, with few disadvantages (if any). Type checking is great as a way to enforce constraints. However, nominal types create unnecessary incompatibility and endless type shuffling every time you want to make even simple changes. I maintain a web app written in Haskell and there’s 3 or 4 different types for URLs in the codebase, even though there’s no real difference between them. Nominal typing is terrible for code reuse via third-party modules. So many hours wasted wrapping types or shuffling between them.

A functional language with a simple set of structural types would be the sweet spot for me. Clojure is probably the closest to this.

What's productive? Measured in purely financial terms selling cigarettes, junk food, and fentanyl is productive. Figuring out how to get teenagers to scroll TikTok all day is productive.

... What people are suggesting is to take money from some productive enterprises and put it towards other productive enterprises such as education, medicine, public infrastructure, etc. Enterprises which have more benefits beyond simply increasing the bank account of entrepreneurs and fund managers.

One option is to outlaw asking for a tip at a place of business. No screen prompting for a tip, no slot on a receipt to accept a tip, etc. Nothing could be displayed conditional on purchase (such as a receipt, a PoS terminal, etc.)

Any details? What part is AI generated? Which model? What tools? What was the process?

I find it helpful to first assess uncertainty.

1 = I’ve done this before

2 = Someone else in the organization has done this before

3 = Someone outside the organization has done this before.

4 = Nobody has done this before

1 and 2 can be quickly estimated by referring to past work.

3 and 4 must be broken down into small tasks that are estimated.

And when breaking things down into tasks to estimate, keep in mind coding is only around 1/4 of the work to produce software. There’s tests, documentation, revisions, planning, and communication.

I enjoyed “Endurance” by Alfred Lansing, and would recommend it if anyone wants to read a riveting and mostly accurate account of Shackleton’s famous voyage.

You might enjoy Sabine Hossenfelder's video exploring this "I recently learned that waste heat will boil the oceans in about 400 years": https://www.youtube.com/watch?v=9vRtA7STvH4

It turns out we can probably solve this by building planetary chimneys 5km tall that move heat to the outer atmosphere.

“I Am That” by Sri Nisargadatta Maharaj

"Individual Contributor" is corporate speak for non-managers (someone who does not manage others).

Someone could take ownership of the project and make decisions instead of letting a monkey run around.

Everything. Rails, Haskell, Rust… I care about speed/performance above all and Helix is just faster than everything else. Zero config is icing on the cake.

Thank you. I love Helix. It’s my daily driver.

Yes, I've done this for my clients. Any of the leading LLMs can power the natural language part. But SQL is typically too open-ended to integrate into a product. You'll need a more constrained query interface to hit 100% accuracy and deal with access control.

Basically, instead of text-to-SQL you do text-to-function-arguments, where that function does the analysis and the LLM translates natural language to your DSL instead of SQL or raw DB queries.

Shoot me an email if you want to explore this further (website in profile).

PG&E has also done everything they can to stop San Francisco from providing its own power. But hopefully that's finally coming to an end:

San Francisco is taking the biggest steps in history toward creating a full public-power system.

In filings with the California Public Utilities Commission, the city has established that PG&E’s local property is worth about $2.3 billion—and if the commission agrees, the city can move to seize those assets under the power of eminent domain.

https://48hills.org/2024/03/after-111-years-sf-is-finally-mo...

You’re correct that to get clients you need to prospect, and one of most effective ways to prospect is networking.

You can start now with your existing network. Just let everyone know you’re available for work, and see what comes your way.

real high leverage networking is done at the job, in my experience.

What do I mean by networking on the job? I mean establishing good relations with others at your current gig - not just your contact that hired you. Treat whoever you work with well and make sure they have your contact info.

My best clients came from people at previous gigs that I didn’t know at first and weren’t my contact. But they would remember “the contractor my boss hired at the last company I worked at was great and was so nice to me and I have his number” and then bam you have a new gig. People start their own companies and need help, they get a new job and are put in charge of hiring, or someone asks them for help and they drop your name.

Everyone you work with is a potential future gig. So don’t just focus on the work, also focus on getting to know everyone you work with.

“To the extent that the business takes place in software, designing the software is designing the business.” @mulegirl from Twitter

This looks very polished, and a more self-serve experience than what some other companies have built.

Seeing what has happened with Assistants API, do you expect OpenAI to soon introduce an SQL API as well?

As someone in the position to evaluate integrating a text-to-SQL pipeline in our product, I'm left wondering "why not just wait until OpenAI does this?" Especially when you consider the pipeline ends at OpenAI's model anyway. How long will the current crop of productized text-to-SQL pipelines really be around for?

This 1000%.

At some point you have to decide, “do I work for my team and the people I’m supposed to lead, or do I work for the business?”

Great managers choose their people over the business. Ironically, this best serves both in the long-run.

Putting in 6 days to get 3 is a -50% ROI, not much better than -60% ROI of the five-day work week.

I propose Profito: A 3-day week for a profitable life. For every 3 days you work, you get 4 days free.

Does this explain why bugs seem to swarm at sunset? Because the sun is lower towards the horizon it brings the bugs towards the ground?

The challenge in my experience is getting buy-in to use the system for everything, consistently. None of the benefits of a design system and UI library matter unless it's used, and used consistently.