zainhoda

There’s an exercise that some people do when learning programming, which is to write down the steps to make a sandwich. Then the teacher follows the exact instructions to make a sandwich and most people don’t put enough detail for a computer to follow (I.e. open the fridge etc) and the teacher will run around bumping into things. That used to be a teaching exercise to show people the amount of precision required when telling a machine what to do.

Now with LLMs, I think one of the great leaps is the idea that it’s no longer necessary to be “pedantic” when giving computers instructions because LLMs have somehow learned to fill in the blanks with a similar shared “understanding” of the world that we have (I.e. cheese is stored in the fridge so you have to go open the fridge to fetch the cheese for the sandwich).

Same for me. I wonder if this is going to follow a similar pattern that we went through with C vs. Assembly. There was a period where everyone coded in assembly and then C came along but people still hand-coded certain parts of applications in assembly to make them more efficient. Then eventually when C compiler optimizations got good enough and computers got faster, few people bother with assembly.

Exactly. If I were in charge of Slack I would double down on 100% remote and also not allow any other third-party remote collaboration tool. The team would be forced to build out all the remote tooling they need and then eventually incorporate it into the core product.

These days I just ask ChatGPT: “What is the best way to do X in Python?”

I suspect that in the era of GPT, unit tests are going to be more important as GPT can generate plausible-looking code.

In fact, I could see a future where humans only write tests and GPT writes the bulk of the code. For the tests that don’t pass, the human fixes the code.

My first thought was that it was a No Big Deal server akin to Python’s simple HTTP server

I was very disappointed in Bard. For most complex coding tasks it returns: “I am a language model…” and doesn’t perform the task.

I’m not sure why anyone would use Bard at this point.

I’m shocked that kids isn’t the number 1 answer. If I don’t have my kids within my line of sight, I need to have my phone accessible.

“past several years”

Umm… I went to Stanford from 2002-2006 and this policy was in place back then. Why is this news now?

Python and JavaScript you say? Would you be interested in contributing to PyVibe?

https://github.com/pycob/pyvibe/blob/main/src/pyvibe/__init_...

https://github.com/pycob/pyvibe

Omg, they could have literally just solved all of this by choosing Cloud Run (a thin wrapper on top of Knative) rather than running GKE directly.

Here's a quick example of how Websocket components might work:

https://websocket.pycob.app/

Let me know what you think! We can discuss more on our Discord: https://discord.gg/uQWPfyP6z4

I think the RTO is somewhat of a temporary condition. The big companies are telling workers to come back into the office and they’re complying because the job market has softened and people don’t want to lose their jobs.

Companies haven’t realized the detriment that RTO is having on their recruitment because most of the big names are doing layoffs rather than hiring.

It’s pretty evident that companies that are posting remote roles get orders of magnitude more applicants.

Once the economy picks up, the RTO companies are going to have to reassess as their applicant pools will be smaller than WFH companies.

So for now client-server interaction would be via forms. So you’d have a form, the user inputs something into the form, then that goes to the server as a query parameter. Then your endpoint would construct the appropriate response to those particular inputs.

For fully client-side interactions, the components are typically bundled with some JavaScript code to make that component interactive. So for example, you can include a datagrid, which has built-in sorting and filtering capabilities by doing page.add_datagrid(df)

I think if you need a lot of client-side dynamic capabilities, then that would be custom JavaScript that you’d either have to write or include a JS library from somewhere.

Hey there! So it’ll be a Python-first PaaS focused on running data apps. So it’ll include storage for pickle files, a simple NoSQL database, identity aware proxy so you can configure specific routes as being authenticated, secrets manager, and the ability to run background jobs on a schedule (usually some sort of ETL process or model training).

I go back and forth on the REPL. We built a REPL but then a lot of the beta users preferred the power of GitHub Codespaces so right now I’m thinking that no, it’ll not contain the REPL.

If you have a use case, would you like to beta test the hosting?

I hear you folks. I’ll add an option for local assets.

Very interesting! I’ll check it out — it looks quite promising as a solution

What’s your timeline? As it happens, we’re also working on a Python hosting solution with a generous free tier.

That’s correct. Perhaps I should add some documentation around this. Untrusted user input needs to be sanitized before using it in the page.

I haven't tried it yet but I was planning on using this library to do most of the heavy lifting: https://pypi.org/project/treeshake/

It looks like it's calling C code via Cython so if it works, you could probably use the same underlying C code via CGo for your project.

Cool! I'd love to check it out!

Yeah, the reason for that recommendation is mostly to reduce file size. For now I don't want to have an npm dependency since this is geared towards Python developers. I'll eventually build in the tree shaking directly into the Python library.

Apologies for this confusion. Pycob was my original project that included the UI components as well as a web server, user auth, cloud services, and hosting.

I've decided to split the UI components from the rest of it because I've realized that they don't need to be bundled. The UI components are in a library called PyVibe.

Pycob will just be Cloud Services for Python Web Apps

PyVibe will be the Python -> HTML library

I'll give this some thought and I'll DM you on Mastodon if I can come up with a working example

Exactly! The use cases I've been hearing about are:

- You're a data analyst and you did some work in a Jupyter Notebook and now you need to give it a front-end so that other people at your company can view/interact with what you've built

- There's a Python library that's runnable as a command-line tool or importable but you want to give it a front-end

Sorry about that! Where is the broken link? I can't seem to find it

Oh! What's the hackathon? If you're looking for teammates, I'd be down to participate depending on the project.

I agree for simple examples there isn't much difference but I personally find this much easier to read and write: https://github.com/pycob/pyvibe/blob/main/generator/docs/abo...

than the output, which is this: https://github.com/pycob/pyvibe/blob/main/docs/about.html

It's true, I could hand code an HTML page but I never remember what meta tags to include, how to make it mobile responsive, or do things like set up a grid. I don't normally create front-ends since most of my work is in data so I'd have to look all this stuff up every time I come back to it.

I think the market for this is Python developers who want to build quick front-ends to something useful that's written in Python without having to re-learn or look up the front-end stuff.

Thank you!

Thank you!