artpar
Joined 14 years ago
Karma
425
Submissions
221
Member since
Feb 22
https://github.com/daptin/daptin
View on Hacker NewsRecent submissions
Comment · 7 days ago
Thanks for the tip, I did not know about contain: strict. position absolute ofcourse everyone knows. Will checkout contain. But doesnt sound like worth trying out html based canvas again just for contain. I feel like I have come quite far ahead with the native canvas approach.
Comment · 8 days ago
I wanted to implement a whole canvas native workspace, I started with a html only implementation and "fake canvas" approach but even for moderate number of panels (~50) the responsiveness dropped quite a lot. So I went with a new implementation with "real canvas" and worked out the panels/interaction.
In terms of performance this approach worked out much better (able to easily handle 1000+ panels/nested panels at 60+ fps) but the complexity goes very high in the implementation of each panel. As in I cant just use for eg a markdown rendering js library or any third party ui component. And frequently make a change would result in massive performance degradation.
Currently I have text/markdown/image/audio/video and pdf panel (you can drag and drop files)
I wonder if i should take another go at it and implement using html-in-canvas api. Afraid of the api being not maintained if they dont see benefit or usage?
Comment · 17 days ago
i just found out about this. any thoughts why isn't this more main stream ? i was trying to make a in place replacement for google services on android (to begin with) but apparently just implement the protocols doesn't "work out of the box" for android.
Comment · 19 days ago
I mean imagine if a (expert) human was just writing code for 3 years straight without doing any of the other things you mention like review/testing/refining. I would expect that app also to be performing/behaving poorly. So kind of like a worse waterfall sdlc. So perspective is okay ?
Comment · 19 days ago
> A vibe coded app is, in human hours, not only a few days old but closer to two or three years old.
I think that's an interesting way to put the quality of vibe coded apps in perspective. A human developing a software will definitely notice the obvious issues if they are using it in much less time frame (6 weeks? 6 months?).
It feels like the waterfall style software projects which would be just built for years and when delivered turn out to be mostly useless.
Comment · 22 days ago
I am not expecting any consistency. I am expecting a claim of consistency NOT to be made for keyboard shortcuts either on osx or windows.
Comment · 22 days ago
Consistent but optional, sounds inconsistent to me. Anyways that was 1 example, here's some more.
⌘R Reload in Safari; reply in Mail; reveal an alias's original in Finder
⌘L Address bar in browsers; message filter in Mail; clear to previous mark in Terminal.
⌘I File info in Finder; italics in text; inspector in Terminal.
I can keep going. This is not to say windows/osx is worse or better, just that claims of consistency are not suitable on either
Comment · 22 days ago
> I love that on macOS all in-app shortcuts are consistently Command+Something, like Q for Quit, W to close a window
Yeah consistency is great, similarly cmd+t closes a tab, wait cmd+w closes a tab not a window. and cmd+w in vlc does not close vlc, cmd+w in finder does close the window.
Comment · 25 days ago
> because writing code used to be the slow part
I don't understand how people have that stated as a fact. Coding was never the slow part. Neither pre-llm, nor now. How it needs to be done is software engineering. And that corresponds now to the "thinking" part of llms, so unless you are making the llm "think in lisp" its not useful. How would that even work. training data to be completely in lisp ?
> Lisp programs are often much more concise because macros let you abstract away recurring patterns and make them part of the language itself
functions ?
> So the bigger the program gets, the bigger the difference. In my own experience the apps I've built in Common Lisp end up about six to seven times shorter than the Python versions
By that logic writing code in this concept language made up completely of symbols would take you even further ( https://github.com/artpar/guage ) but in practice it doesnt because llms arent trained to that extent on this.