It's not just for myself, but I'm primarily creating it for myself - it's a browser for designers. I work in code but I often want a figma-type interface to explore different ideas without having to branch or litter my codebase with a bunch of demo components/files.
Normal browsers have built-in dev tools - this has built-in design tools. so I can visit my app, open up a surrounding canvas, pull fragments into the canvas, do some design-ish stuff, and merge it back into code. All in the same UI. It was cool enough that I'm going to release it, but for now it's very useful for myself.
I know I must be underthinking this, but I really don't know why native toolkits can't just implement some codegen thing that takes XML and produces the above.
To be fair, "excited by the promise only to be disappointed by the reality of the implementation" describes ~95% of my experiences with all software over the last 20 years. In fact only a few exceptions really come to mind - git, treesitter, ffmpeg, and sqlite.
Yeah, maybe it's rose coloured glasses on my behalf. Those examples you mentioned, I would 100% agree with. It's some of the best software out there. And yeah, there's probably always been rubbish about.
I guess I hope that the good stuff keeps coming and the dross falls away. More signal, less noise.
I do agree with you though. It feels like the industry has steadily been getting worse, AI is just like pouring kerosine on the fire. I'm almost embarrassed to call myself a software engineer now.
On a small bright note, I've gotten AI to help me produce some of my best work over the last couple of months. It may enable sloppy behavior, but it doesn't require it. I have hope that serious work will win out in the end, and that sheer human effort is still the differentiator.
Yeah, there was a good article on here the other day where the author suggested going slower with AI and using it to help produce higher quality output. I think the idea is to be quite "hands on", coding much in the old way, but to use AI to help with, for example, test coverage, error mode detection and handling, refinement of the solution/feature, etc.
At least that's how I read it. :-) I'm learning that there's a place for the LLM but it's the sandpaper, not the chisel.
lol I'm more speaking to reliability than the quality of the interface. git and ffmpeg are not exactly known for the most intuitive API surface, but I don't think I've ever encountered a bug with them in my 17 years. That's a pretty extraordinary thing when you think about it.
Fair point. My problem with git is actually mostly the flaw in the object model itself, more than the dismal API. The fundamental mismatch between "to get a clean history you have to edit/destroy history with squashes and rebases and whatnot" and "editing history destroys the ability to do comparisons of two branches, which basically ruins half of git's functionality from top to bottom when you encounter that problem".
Like even the basic question of "hey did I already merge this branch?" becoming unknowable if you autosquash-on-merge is just nasty.
I've got a million ideas on what the "correct" fix for that problem might be, but imho it's a flaw deep in the heart of git that creates a massive amount of pain.
But I'll give it credit for being rock solid and blazing fast, as you say.
That's all true - I taught myself how to code from 2009-2012 so I remember what it was like. However, around that time there was also deep focus on architecture, an obsessive focus on rendering performance and page weight. Everyone could recite the loading sequence that HTML pages used, we knew how many requests could be downloaded in parallel, how to best bundle assets for the fastest time to render, etc. So it was a mix of both pain and frustration on one hand, and a pride in one's work on the other hand.
Both have been lost; good riddance the former, but I miss the latter.
I hate it so much. It's one thing to lean on AI for complex or toilsome work, but to openly supplant your own ability to interact thoughtfully with another person. It should be embarrassing.
I remember being a junior engineer in 2015, and being asked to render a clickable link within a paragraph in an iOS app. Swift had just been released so we were still entirely on the ObjC/UIKit stack. It was an absolute nightmare. I _barely_ managed to make it work. I haven't really touched iOS since about 2016, so I assumed the new SwiftUI stuff would have this stuff built in. Obviously. Kind of insane that it wasn't.
When I say "this stuff" I'm not talking about a link, I'm talking about the overall markdown/text capabilities that the post is talking about. I meant that I expected more parity with what you'd encounter on the web.
You expected highly capable, generic GUI toolkits to show parity with a development environment that has specifically targetted text above all else (though with lots of other stuff and great depth too) for decades?
Even in an era of PWAs and highly reactive UIs, the web is still fundamentally a document presentation mechanism. No generic GUI toolkit fits that description (even if they can be coerced into being one).
"Qt comes with Dual Licensing, which includes both commercial and open source options. To build a proprietary mobile application, you need the Commercial Qt license, within which Qt for Application Development is sufficient for pure mobile and desktop app development."
I vaguely remember doing this with attributed text for iOS 4.
That said, I also had quite a lot of success on iOS 4 using HTML as the layout engine for the main screen of the app, though the place ran out of money before that went anywhere.
HTML can be really good, the blockers back then were it not being exactly the same as the Apple UI guidelines unless you put in a huge amount of extra work that nobody wanted to spend. I'm not sure when Apple's own guidelines stopped mattering exactly (iOS 7's invisible buttons necessarily had to be ignored, but there was already a decent level of custom UI before them and it was already essentially irrelevant even before Apple became extra-inconsistent with Liquid Glass), but I think we're now at the point where you only follow those guidelines if you (a) don't have your own UI team, and/or (b) want to try to aim for a shout-out from Apple.
Do not know about "forever", at the moment it works okay, I guess. But for a long long time most of the iOS apps were using this https://github.com/TTTAttributedLabel/TTTAttributedLabel to have proper support for links & other basic attributes.
Between this and blipped-CAIPI in 2011, there hasn’t been much change from an acquisition perspective in the industry. Mostly everyone shifted to AI reconstruction, workflow improvements, and reducing helium use. Those are the low-hanging fruit. I’d be happy to be proven wrong but I don’t see any major breakthroughs coming from advanced math in the near future. ISMRM was this week though so maybe something came out of it.
I've spent the last few months reading a lot of AI-generated code. It's extremely difficult.
It's like how psychopaths are eerie because there's nothing behind their eyes. AI-generated code is eerie because there's nothing between the lines. Code is in some sense theory building, and when you read a humans code you can (mostly) feel their theory working in the background. LLMs have no such theory, the code is just facts strewn about. Very weird experience to try and understand it.
My company is moving to a workflow where we only write Jira tickets, the LLM writes all the code and submits a PR. Then we are supposed to review the code the LLM wrote.
that doesnt seem particularly horrible, as long as you as the engineer can still go change things in the code package and surrounding infrastructure to improve the output, and make sure that the agent is actually making the right stuff the first time you see the outputs
eg. setting up better feedback loops, improving CI/CD, breaking changes up at the right scale, etc.
you i assume also can then put in more work up front, doing simulations of solutions, lean proofs, and so on?
The change is turning me from someone who writes pretty good reliable code, to someone who has to read and review pretty bad code. If you think this is an improvement, you're nuts.
It is inserting a pretty unreliable middle-man know for errors and hallucinations, that often just goes down and stops working for reasons we can't control into a workflow that has worked well for a decade, and we're paying extra to really break-even on the time spent creating new code.
Just because "everyone else is doing it". Not because it's proving to be a boon in productivity.
Literally anyone can write a Jira ticket. US engineers are expensive. What do you think will happen when the powers that enacted this policy decide that the ticket to merged into prod rate is acceptable to them?
Normal browsers have built-in dev tools - this has built-in design tools. so I can visit my app, open up a surrounding canvas, pull fragments into the canvas, do some design-ish stuff, and merge it back into code. All in the same UI. It was cool enough that I'm going to release it, but for now it's very useful for myself.
https://matry.design/
reply