I find it curious how programmers are so poor at naming their projects. This could've easily been named pokésay. That said, it's a cool project!
Well, it's one of the hardest things, along with cache invalidation.
Don’t forget off-by-one errors!
Pokemonsay: Pokemon Version of Cowsay
41–50 of 54 posts
Re: Pokemonsay: Pokemon Version of Cowsay
#42Imagine installing node.js and a json parser and 10+ other things just for a cowsay clone. I can't imagine what a clean install of all this crap would be just for this project.
Can we not do this? It's just as valid to have this kind of little thing written in node as it is to have it written in Perl. One person's complaint about a json parser being too heavyweight is just as valid as the complaints that the arcane one-off cow template syntax is hard to use and understand. Not to mention that this has different features than cowsay, and it's just a fun little project. It parses image files…
I think we should do this. When writing a tiny, trivial utility, it doesn't make sense to bring in a ton of dependencies. Disk space, memory usage, and download size all matter, especially to those of us who use old hardware on rural satellite connections.
Your final paragraph had a good point, though. It's not just cowsay.
Re: Pokemonsay: Pokemon Version of Cowsay
#43Imagine installing node.js and a json parser and 10+ other things just for a cowsay clone. I can't imagine what a clean install of all this crap would be just for this project.
Can we not do this? It's just as valid to have this kind of little thing written in node as it is to have it written in Perl. One person's complaint about a json parser being too heavyweight is just as valid as the complaints that the arcane one-off cow template syntax is hard to use and understand. Not to mention that this has different features than cowsay, and it's just a fun little project. It parses image files…
No, we can't not do this. This is the same problem I have with react
Re: Pokemonsay: Pokemon Version of Cowsay
#44While it does support a few additional options according to the README, I think this whole project could have consisted of no code at all and just cowsay template files that you’d copy to the cowsay template directory. Typically /usr/share/cows/ Here is an example of a third-party template for cowsay: https://github.com/lochsh/alpacasay/blob/master/alpaca.cow
Do cowsay templates allow you to set the color for each character?
I tested and indeed you can use ANSI escape sequences in cowsay templates.
Re: Pokemonsay: Pokemon Version of Cowsay
#45Earlier quoted context omitted.
Can we not do this? It's just as valid to have this kind of little thing written in node as it is to have it written in Perl. One person's complaint about a json parser being too heavyweight is just as valid as the complaints that the arcane one-off cow template syntax is hard to use and understand. Not to mention that this has different features than cowsay, and it's just a fun little project. It parses image files…
I think we should do this. When writing a tiny, trivial utility, it doesn't make sense to bring in a ton of dependencies. Disk space, memory usage, and download size all matter, especially to those of us who use old hardware on rural satellite connections. Your final paragraph had a good point, though. It's not just cowsay.
Developer time is valuable too, if you feel strongly about efficiency, feel free to write one in C++ or Rust. As an industry we have come to accept that developers are not cheap, that a multitude of open source libraries is good for everyone regardless of perceived deficiencies in quality, whether this is due to supply/demand is besides the point. The thing is, there are limits to "artisan, handcrafted software". If you want your GUI or app to look good, ship without license restrictions, build quickly, not resort to sweatshop labour, then you have to use stuff like Electron or Node.js. You can't have all of your cake and eat it too. Artisanal handcrafted software is nice to build when you have exited a startup or has a trust fund and nothing better to do with your time.
(If you are a Lisp developer and you are reading this, I challenge you to build one in your favourite Lisp. Let's see how HN's favorite "secret weapon" fares against the entire ecosystem of JavaScript. The hypocrisy is unreal here, people would espouse Lisp in one breath and go back to coding their startup in Rails in another.)
Re: Pokemonsay: Pokemon Version of Cowsay
#46Earlier quoted context omitted.
Can we not do this? It's just as valid to have this kind of little thing written in node as it is to have it written in Perl. One person's complaint about a json parser being too heavyweight is just as valid as the complaints that the arcane one-off cow template syntax is hard to use and understand. Not to mention that this has different features than cowsay, and it's just a fun little project. It parses image files…
I think we should do this. When writing a tiny, trivial utility, it doesn't make sense to bring in a ton of dependencies. Disk space, memory usage, and download size all matter, especially to those of us who use old hardware on rural satellite connections. Your final paragraph had a good point, though. It's not just cowsay.
I agree. Fat shaming for software. Otherwise you'll end up with a terminal emulator written with electron. Oh wait, that already exists.
But seriously. If you don't tell people politely and explain what and why it's wrong, they'll never know that what they're doing could be better. Just ranting and shaming might not be the best way. Still I agree with all the NodeJS hate.
Re: Pokemonsay: Pokemon Version of Cowsay
#47While it does support a few additional options according to the README, I think this whole project could have consisted of no code at all and just cowsay template files that you’d copy to the cowsay template directory. Typically /usr/share/cows/ Here is an example of a third-party template for cowsay: https://github.com/lochsh/alpacasay/blob/master/alpaca.cow
Most of the code here is for scraping images from a 3rd party and converting them into colored blank spaces to display in the terminal. The actual code used to pick a random Pokemon and display it is only a few dozen lines.
Where does the conversion from .png to tiles happen? Is it part of boxen? I can't seem to locate it within the source.
Re: Pokemonsay: Pokemon Version of Cowsay
#48Earlier quoted context omitted.
Can we not do this? It's just as valid to have this kind of little thing written in node as it is to have it written in Perl. One person's complaint about a json parser being too heavyweight is just as valid as the complaints that the arcane one-off cow template syntax is hard to use and understand. Not to mention that this has different features than cowsay, and it's just a fun little project. It parses image files…
I think we should do this. When writing a tiny, trivial utility, it doesn't make sense to bring in a ton of dependencies. Disk space, memory usage, and download size all matter, especially to those of us who use old hardware on rural satellite connections. Your final paragraph had a good point, though. It's not just cowsay.
The complaint about "bringing in Node" and all the other dependencies is silly. Developers familiar with Node will already have it on their system - notch. Then the dependencies are just part of the ecosystem since this stuff ain't compiled. So, pointing it out is just being pedantic - that's all.
Re: Pokemonsay: Pokemon Version of Cowsay
#49I really like this module and love the idea. The images are far too big though especially compared to cowsay/cowthink.
This might be a bit off topic, but what are your options for putting images or "image like" drawings in the terminal now days? This seems to just use blank spaces with terminal background color codes to draw things, which means your smallest "pixel" is the size of a terminal line. Are there ways of getting higher definition in a terminal with fairly widespread support and keeping full color? The hacker part of me is…
Those ones use half-height blocks I think, which goes a loooong way already.
Re: Pokemonsay: Pokemon Version of Cowsay
#50Earlier quoted context omitted.
I think we should do this. When writing a tiny, trivial utility, it doesn't make sense to bring in a ton of dependencies. Disk space, memory usage, and download size all matter, especially to those of us who use old hardware on rural satellite connections. Your final paragraph had a good point, though. It's not just cowsay.
I agree. Fat shaming for software. Otherwise you'll end up with a terminal emulator written with electron. Oh wait, that already exists. But seriously. If you don't tell people politely and explain what and why it's wrong, they'll never know that what they're doing could be better. Just ranting and shaming might not be the best way. Still I agree with all the NodeJS hate.
What hate do you refer to, and why do you agree with it?
What's wrong with having a rapid development ecosystem within which to build that is fairly simple to install, run, and cycle? JavaScript, and NodeJS by extension, are just as viable as languages as any other out there. There are languages, such as Rust or Go, that people tout their benefits. However, I see no simple way to get an env set up, learn the language, and turn around anything of meaning in the time I could in JavaScript. There are some deficiencies in the platform, surely, but those (as I would expect) get resolved over time.
I could make the same argument about having to get a JRE or a Python interpreter. Each language is going to have its deficiencies and bonuses.