tvink

I think calling opencode the trend is naive. This not what is being run on company time.

Idunno. I think you end up teaching them nothing and just doing it for them. I mentor plenty folks without learning more than basics of vscode/cursor, and the most important lesson for them is always how to figure out how to do stuff (which has never been easier than today).

I'm unsure why you point this out. It's also a non issue if you're trying to drive a unicycle. Isn't it more interesting to talk about the cases where it applies? Or do you reckon all programs should be microservices?

There truly is not. Software engineering is not different in any meaningful way. Sure 30 years ago in waterfall land we were emulating the project management of engineering, with miserably expensive results. But it's all the same now. It's like differentiation between coding and programming, it's different in everyone's head.

You don't think the rest of the world is doing funded research?

Yeah this is copium. Everyone is sprinting to adopt everything that is useful, and it just haven't happened with MCP.

Also, what's the hold up? If they all are building one, presumably using AI, shouldn't they all be done already?

If it is verifiable, please show us. What if clear to you reeks delusion to me.

That is what too expensive to be an option for most.

You're on to something. It's the lisp machine of it all. Hot reloading is nothing that requires anything special, so you can redefine a callback or dependency with ease in the repl and the system chugs along. You can theoretically do something similar in ruby, but it's the opposite of elegant, you'd be forced to re implement methods with different dependencies etc. It's also a function of being "functional" in the lisp sense, that things are lists, and lists can be replaced, functions or otherwise.

The fun way to get a feel for lisp machines is emacs, it's so easy to fall of a language and especially hand-coding in a language if you don't have to.

Looks cool, but the phrase 'build applications with the flexibility and power of go' made me chuckle. Least damn flexible language in this whole space.

You're not wrong, for sufficient simple cases it's at a disadvantage. But once things get complicated, it wins by being the only thing that you can get to work without going insane.

And yeah, any serious use completely assumes a Max sub.

You'll be back :)

Honestly if we could have we would have, we can't even tax the people destroying our world, how are we going to create utopia

It's definitely an approach. I do think in true democratization of the internet, teaching people some tech is inevitable. We just can't have equal access if we retain the classes of user and maker as completely distinct.

This is the complete opposite of my experience.

The point of MCP is discoverability. A crud app is better, except you have to waste context telling your LLM a bunch of details. With MCP you only put into it's context what the circumstances are where it applies, and it can just invoke it. You could write a bunch of little wrapper scripts around each api you want to use and have basically reinvented MCP for yourself.

If only you could reach out of your own experience and ponder what might cause otherwise reasonable people to do so. Young people peer pressure, current marketing landscape, you're forced there if you want to make money as a creative, so many reasons. Great, you can live your life without. Can you live your life without assuming everyone has the privilege of your situation?

https://www.wheresyoured.at/costs/

Their AWS spend being higher than their revenue might hint at the same.

Nobody has reliable data, I think it's fair to assume that even Anthropic is doing voodoo math to sleep at night.

For sure not

Sure you can say consumers refusing the ad-ridden paywalled experience killed it, or we could say the lack of adaptation and finding better business models did. I think a lot of players killed themselves off fighting to preserve rather than adapt, or worse have digital content subsidize analog (to this day I keep running into ebooks that cost more than the physical books, and they wonder why people pirate)

utilitarianism is when you add up the suffering. stalin made number go up, mother teresa made number go down. these are also not the only options.

I guess you.. ask them a bunch of recommendations? I would imagine this would not be incredibly hard to test as a community

Unfortunately the have abysmal design sense for TUI and an inability to recognize the good feature requests they are getting

Probably because you didn't include the content type header?

You can scaffold a crud resource we with a single CLI command, as far as I know we don't have that in phx?

Solid cable is quite a bit of setup though,compared to Liveview. The way LiveView manages the rendering for your is leaps ahead of how actual rails SolidCable development feels.

One of the arguments is how noisy the languages are. Elixir is without a doubt more powerful, more scalable and more sophisticated than Ruby.

What Ruby has though is ability to express what you are doing in a clear syntax. Elixir has a lot of ritual (albeit less than erlang) to set up your most used things like GenServer - you don't abstract away the concurrent flow (which is good, concurrency should be obvious), but you also wouldn't write elixir without it, so code inevitably becomes filled with technical concerns.

I'm biased, I write elixir for a living after a decade in Ruby, and I'm happy with that tradeoff. But there are times where you need to do an imperative thing and make it clear as day, and Ruby often does a better job here.

Rails is also somewhat more ergonomic for fast prototyping than phoenix. ActiveRecord is a blessing and curse, it's insanely productive for making things do things in minutes, but lacks composition later on.

In terms of competition it's really the same. Whether you fight with a team of 1 for 5 businesses or a team of 10 for 1 business that is 50x bigger, on average as long as you have equal competition in each segment you walk away with the same. But you get very different customers, for better or worse.

A segment of a customer base is hardly a buffer, if you underserve them they will leave, and you will have wasted effort making an inclusive sales and support process to them.

That's not how you define either of those things.

Granted, software engineering is a pretty ill-defined term, but I'm pretty sure most would agree that agile project management is not software engineering.

"Being able to be picky about what to learn" being programming is also a really confusing idea. Programming is writing programs, it's not some learning philosophy, and it's certainly not some liberated opposite to software engineering.

I guess you're confusing having a job with software engineering, and spare time coding with programming.

It's wild how all the huge successful applications written in it manage to stay alive eh