HN user

andrezsanchez

25 karma

Software Engineer at Zoox.

Posts3
Comments25
View on HN

so you can begin a (regex) search with / and hit n to go to the next result or N to go back.

His point of that being slower still stands. I also find that just googling generally what I want can more quickly lead me to a stack overflow post with exactly what is needed, while MAN pages can be rather cryptic at times without reading the whole thing.

I think it would be interesting if there were a Latin equivalent of Chinese characters. Different roots could be represented as different characters, some could be used for each of the suffixes like "ly", "tion", etc., and the characters would be joined together to create words like in Chinese.

Different Romantic languages could be represented this way. In the same way that Mandarin and Cantonese use the similar character sets with different pronunciations, and with some characters specific to each one, different languages that have Latin roots would have a few of their own characters specific to their own language, but mostly drawing from the Latin pool.

The pronunciation for each would have to be memorized of course.

To be fair, you can also "come up with something" in Chinese. Since there aren't all that many sounds, you can write in generic characters for the sound of the word that you can't remember.

I did something like this a long time ago in a little competition for beating others' rock paper scissors programs, except I used the other players' moves relative to my own (e.g. my program could catch on to the other player choosing the move that would beat my last move) as well as their current pattern of winning or losing.

I personally like the idea of tabs better, but prefer spaces because it makes navigating the text less awkward when traversing tabs. It may sound stupid, but for my own stuff it's just more comfortable.

"Using pinyin as you suggest is actually hopelessly slow"

Everyone I've encountered in China seems to do it just fine. It is only hopelessly slow if you type one character at a time.

"adopting an input method based on the character radical composition or handwriting recognition is much faster"

What character radical input method are you talking about? I can't imagine any input method using radical composition being faster, it would be comparable to using Latin roots to type out English words; there are just too many to be practical. You can actually do this on Pleco, but it takes forever, even longer than typing one character at a time in pinyin.

Handwriting could work assuming you can handwrite Chinese quickly (I would be deathly slow as I can't read a typical handwritten cursive note, much less write one). I think handwriting recognition is already pretty good, people just use pinyin because it's the easiest.

There are also a lot of phrases that can be typed with just the first letter from each word, eg typing "bth" gives "不太好", "zmy" gives "怎么样", and there are endless more combinations like this.

I'm studying abroad in Beijing right now, and my throat began to hurt even at lower levels of PM2.5 simply because I wasn't wearing a mask. I'm very surprised at the number of people who don't wear a mask; they either don't value their health or don't know how bad the air is because they've been accustomed to it.

Vue.js 1.0.0 11 years ago

Emphasis on "implemented" haha. At least this makes it more open since someone can come in and make their own implementation. As it currently stands I don't think you can use Facebook's implementation to transform JSX to a framework-agnostic object.

Vue.js 1.0.0 11 years ago

It would be neat if Facebook had implemented JSX as a framework-independent transform rather than a React-only one, that way other frameworks could use the pretty XMLish syntax rather than strings or JS objects.

You're correct that there is probably more excitement for them then there ought to be, considering the simplicity of bash. People ought to create more programs following the UNIX philosophy, which can be chained together using simple pipes.

There are, however, cases where you simply need to use code. In these cases I'd rather use the language I'm developing in rather than bash. I haven't used Brunch for more than a simple project, so I can't really comment on it too much. I have used Gulp though, and I commend its authors for creating great abtractions following the UNIX philosophy in this context.

Lodash v3.0.0 11 years ago

I remember trying this a while ago and being disappointed at the amount of dependency code brought in for a rather trivial function, but the modularization is looking much better than it was last time I took a look.

Lodash v3.0.0 11 years ago

That's an interesting perspective. I don't have any inherent problems with large libraries, but my problem with some of these 'monoliths' is that other libraries start to depend on the entire library when they only need a small piece of functionality that the library provides.

Substack wrote an article [1] explaining some of the problems that monolithic libraries cause in an ecosystem.

[1] http://substack.net/many_things

Lodash v3.0.0 11 years ago

I've tended to avoid both underscore and lodash because they're both in the slew of monolithic pre-npm libraries, however the lazy evaluation looks interesting. I wouldn't be surprised to find a library that handles lazy eval without all the extra features Lodash brings.

Imperative DOM manipulation is a pain one way or another. React does a great job of alleviating this pain by allowing for declarative DOM manipulation, but it would be great to be able to do this without needing the rest of React.

I have a hard time seeing what exactly the point of having another package manager is. We already have a very established way of managing front-end packages: NPM and Browserify. I don't see why you would want any of the features that are advertised in this package manager, namely using Github repos vs. npm packages, and manifestless packages. All it gives you is a more fractured ecosystem and code that won't run on the server.