Indeed, like people stating something is a deferred or a future instead of promise, and then pointing out a minor difference in their approach that justifies a whole new taxonomy.

Exactly. All those talks are always going to tell you the same things:

- limit side effects to your program boundaries

- abstract boundaries with utility functions

- mock program boundaries for integration tests in those utility functions

And then they pretend they didn't see the mock part.

Alright, so you get numbers from a json file in a ftp servers, you use scipy.newton to perform root finding on it, but needs the number of steps to be outputted as well (which newton() doesn't return), and you will save the result in a postgres table.

All this should be send to a task queue, triggered by a call to your REST API.

Good luck with purity.

"Railway Oriented Programming"[1] is a (functional) technique to achieve purity despite steps that could result in error states. The error states are hidden/pushed to the very edges/end of your code. So you can focus on the "happy state" for the main business logic:

> Many examples in functional programming assume that you are always on the “happy path”. But to create a robust real world application you must deal with validation, logging, network and service errors, and other annoyances.

> So, how do you handle all this in a clean functional way?

> This talk will provide a brief introduction to this topic, using a fun and easy-to-understand railway analogy.

Functional programming keywords/shorthands: option/either/monads

[1]: https://fsharpforfunandprofit.com/rop/

> Good luck with purity.

Most of your counter example needs integration tests to test properly anyhow - not really a good point.

If you can give up encapsulation (which IMO isn't actually that useful in practice) and in return, your program becomes 95% functional, that seems like a really good tradeoff.

1. code that listens to a REST API and puts a request on a task queue

2. code that listens to the task queue for new jobs

3. code that fetches a file from the FTP server

4. code that converts the JSON file to a format appropriate for the root finding

5. code that performs the root finding

6. code that converts the result of (3) to a format appropriate for insertion into a table

7. code that inserts the result into a Postgres table

Steps 4, 5 and 6 seem easy enough to implement in a pure fashion.

Yeah, just reading their description I was like "the middle part seems easily done as its own thing".

"Functional Core, Imperative Shell" was just posted too, this is the perfect example of where that structure works: https://news.ycombinator.com/item?id=34860164

You’re describing a bad API to begin with. Those are too many steps to test at once too.

As a side note, if you want an efficient python REPL and you don't need custom commands like offered in the project above, you can do the following:

- install ipython and rich

- set PYTHONSTARTUP to auto load whatever you like on start up

- call rich.pretty.install() in your startup script for a boosted repr()

- set %autocall to 1 to benefit from optional parentheses

- use ! to call shell commands

This covers most people needs for a non-custom REPL.

Still no reload() though, but python really doesn't like that.

I was actually intending for it to be custom commands, since I think it would be hard to beat even the vanilla python repl if we are talking about writing python.

But I just couldn't find much about small projects that enable quick custom command repl building. Either the package is enormous and a swiss army knife or they cater to a specific language (e.g. SQL). I'd like this package to be a small building stone for custom command cli of any kind.

2.4 billions is not enough for such a project given the EU overhead in cost. Espacially since the deadline is 2027, so 2030 with delays really, that means 350 millions a year for paying satellite design, build them, send them to space.

Antidote is a great commercial product for that, it's the best I could find in a the market and professionnally the ROI is fantastic.

But if you don't want or can't pay for it, gpt3 is actually also a good proof reader!

Useful doesn't mean it should be done. There are a ton of useful things for me I don't do because it's not right to do them.

Apparently as soon as a company becomes big enough, the line between convenience and ethical becomes very blurry.

> Useful doesn't mean it should be done.

I never said anything about what should be done. I'm just saying it is useful, as the previous commenter said it's not.

When did I say it isn't useful? I said they didn't need it. They also don't need to install a kernel module that records every keystroke and memory access, but it would certainly be useful data.

And this is why trio got it right, and why I think the task groups (nurseries from trio) can't arrive soon enough in the stdlib.

Because not only you must maintain a reference to any task, but you should also explicitly await it somewhere, using something like asyncio.wait() or asyncio.gather().

Most people don't know this, and it makes asyncio very difficult to use for them.

> task groups (nurseries from trio) can't arrive soon enough in the stdlib

Please, no. Asyncio is horrible, and bodging it to make it less horrible just means we will be forced to live with the remaining horror. Far better to replace it with something that works properly (yes, Trio).

Unfortunatly most stdlib don't have a peg module, and peg libs are complicated.