certainly didn't mean it to come off that way.

i might make a devmode version that has some of this in the far future. but it's not a priority before API stabilization, perf optimization, code golfing, tests, docs, examples and v1.

if anyone wants to contribute this, i would certainly entertain a PR, but no one is paying me to write extra code (or any code, really).

I don't disagree, but good vs bad error messages can be the different between a project that people love and contribute to and a project that people find frustrating and bombard with issues.

Keras is great about error message[1] and it's part of what makes Keras beloved (and heavily contributed to).

[1] https://blog.keras.io/user-experience-design-for-apis.html

honestly, i already maintain too many open source projects (and quickly resolve bug reports) to be worried about people not using more of my free work.

i write open source code primarily for myself. doing anything i dont consider critical takes the joy out of doing it.

if people want features, they can fork and contribute code and then maintain that code, too...forever. of course, once you shift that burden to them, suddenly no one wants to get involved.

sorry for putting it this bluntly but it's the truth. i am one human, with a 9-5 and a life outside of coding. people seem to feel entitled to opinions on free open-source projects having contributed little-to-nothing.

I’m pretty sure the parent was just making an honest suggestion that wasn’t meant to attack or hurt you. And why post on HN if you aren’t willing to listen to others’ suggestions/criticisms of your work?

look, i get it. i'm not offended. but i want to keep lib size minimal and adding validation and error messages will bloat it. a lot.

i typically add them (or update the docs) once users encounter problems and open Github issues (reactively). doing it proactively is a waste of time (for me).

i accept the criticism. i just don't have the necessary free cycles to address it.

> no one is paying me to write extra code (or any code, really)

Fair enough, I understand the mentality, it's not easy developing and maintaining packages in your spare time...

But it's important to remember that thousands of hours of frustrated google searches:

    'error: something not found'

Could be prevented with a single helpful error message for the user...

> But it's important to remember that thousands of hours of frustrated google searches

And don't forget about support requests posted to the "issues" in the repo itself.

As an open-source maintainer, helpful error/debug messages is the key to reduce the number of GitHub issues, mails and all the other way people will track you down to ask for your help.

Ultimately spending an hour writing helpful errors can save you hundred of hours in support.

Of course you can just ignore everybody asking for help, but then if people aren't going to be able to use your project why make it open-source in the first place?

Code golfing >> error messages.

I love it! Having fun with your project is key :)

> read the docs

I would read them if they were linked from the readme :)

this thing is nowhere near finished. once the api is stable i will write them and make more demos. if i did all of that now i would have to do 10x the work on every api change.

the purpose of posting it here is to hopefully get some alpha testing and feedback for more use-cases so it can be polished outside of my isolated purposes.

I see that and thanks for creating it. I just wouldn't put info in the readme that's invalid at the moment.

On the feedback side, a reset zoom button on the demos would be handy.

> On the feedback side, a reset zoom button on the demos would be handy.

it's behind a double-click ;)

Okay, I'd make that more obvious, that's super non-standard.