Yes, but the full on experience is the translation to full color images.
That's how the Japanese use them in their mobiles, no?
4,147 karma · joined January 17, 2012
That's how the Japanese use them in their mobiles, no?
Your comment does not make sense.
1) When "you've used these characters" where? On a webpage?
2) They ARE raster icons. What did you expect them to be? Fonts don't have multiple colors.
3) How does "Windows and Linux" handle them better? Most apps there don't handle them AT ALL.
Most people on earth are not defined by their jobs. They work because they have to. So he could be doing it for the money. Or the girls. Or the publicity. Or the lifestyle. Or the travel. He doesn't have to do it for the sport itself.
The "do something you love and you don't have to work a day in your life" is feel-good BS for relatively affluent or generally lucky in their life path people.
In any case, it only applies to "likable" jobs: a pilot, a manager, a doctor, an artist, a chef, a journalist, a teacher, a programmer etc. E.g jobs that a lot of people CAN find interesting and fulfilling.
But most of the world goes round by the non-likable jobs. Maybe some people like those jobs too --but they are bizarro outliers. The vast majority of people doing them do not like them.
E.g I don't think many people "love" flipping burgers at a McDonalds, washing dishes, or working 16 hour shifts in a mine, or cleaning the streets from garbage. But they do because they have to --until something better comes along. And a lot of them have kids and such dependent on them, they cannot leave it all behind and go chase some Hollywood dream or whatever.
Actually those are called "capital letters" or "capitals".
>and don't want them in a computer language
This is a BS and capricious statement that has nothing to do with programming.
Try the arts.
And idiomatic Java code (Factory of proxies of singletons) is laughed at.
And not a lot of people are fond of idiomatic Ruby code, which tends to rely on "magic" (or "action at a distance").
Sometimes idiomatic is good, sometimes it's bad. Let's not cargo cult.
Yes, they weren't. The first Android phone appeared one year after the iPhone (HTC Dream, released on October 22, 2008).
That 2005 acquisition didn't automatically make the two companies competitors...
It's not like Apple "usually reverts in quality" either. This was a business decision, probably forced. They had to create something of their own for maps from what they could license and buy quickly.
Goes to show that you should not depend on your competitors for core technology. Which Apple always tries to avoid, but probably in 2007 (when the iPhone come out) the didn't think of Google as a competitor. They weren't in the phone business back then...
And it's plain wrong.
Steve was alive when the G3 iBooks had thousand units recalled for logic board problems. Steve was alive when the Mac Pro oozed some green cooling liquid. Steve was alive when they had problems with (Sony) batteries and have to recall them. Still was alive when the created Ping. Steve was alive when they made the menubar translucent. Steve was alive when Lion had several problems to lots of users. Etc etc...
It's a BS notion that anything wrong with Apple is because somehow Steve isn't here. Especially when the Maps have a perfectly valid explanation: Apple had to prepare something quick, because the couldn't use Google Maps anymore for political/contractual/competitive whatever reasons...
It's not as if mapping the planet electronically and with information that changes is an easy job, else somebody else besides Google would have also done it. It takes years, tons of money, cutting edge tech and the like.
(1) them not believing that Go has design issues
for my argument to not make sense. It would need both (1) and
(2) them being right about said belief
for my argument to be invalid. And while (1) might hold, (2) is highly debatable.
I never would have guessed. Oh, wait...
>And yes, you're right, those sites all look great. In fact I might just print out screenshots of them and hang them on my wall.
It's not the "hang on my wall" looking great that matters, it's "I can find what I need with minimum fuss" looking great...
Google's Android? As in Google, the inventor of the "perpetual beta"?
So, Revel not being in line with the Go philosophy could also be a great thing.
Are you a graphic designer or something? You must surely speak for some very superficial, cosmetic issues.
Those websites you mention are mighty fine, especially Go's is very well organized.
By your logic "for some people, Earth is flat".
They are surely not mediocre programmers (or mediocre contributors to computing).
They are however mediocre in their modern language design skills. What are their language credentials?
Lars Bak is a compiler/language guy. Wirth was a compiler/language guy. Hejlsberg is a compiler/language guy.
The Go guys? Not so much.
Having designed the best systems language 40 years ago is not a sure sign that you can also design a good systems (or not) language 40 years later. Compiler design has changed a lot since then, but it's not like Go has a lot to show for it (ok, they also wrote 1-2 other ho-hum languages, like the Plan9 one).
Plus, beside the language specs, there is also the compiler. Did those guys ever wrote a top-notch compiler? The original C compiler wasn't the state of the art in the language. It took lots of efforts and different companies to get to the advanced optimized C compilers we have today.
Plan 9 was far more impressive a feat than Go was, and much closer to where the team's skills are.
But, as Go advocates will tell you any Generics related discussion in the golang list: "just try programming in Go for a while and you'll find you don't need Generics".
Why do they assume that people complaining haven't used the language "enough", is beyond me.
Plus it seems they believe that there is some amount of time of using a language, after which fundamental issues and well understood design issues disappear...
But, by that logic, why abandon C in the first place?
"Just use C long enough, and you'll find out you don't need garbage collection, built-in collections, closures and memory safety".
Or:
"Just use assembly long enough, and you'll find out you don't need all those fancy functions, and variables, and looping constructs, and stuff".
a) writing in C for performance (and having to setup glib et al to make it comfortable)
and:
b) carrying the JVM with me to run something.
(And, no, I won't consider AOT compilers for Java. I want to deal with reasonably mature and widespread technologies and tooling).
So, there are my constraints. Given those, maybe C++ is the ticket. D is not mainstream enough, and Rust I've played with and I like very much but is still in flux.
It is correct, just slightly misleading. The size is made to look like the browser default size taking display density into account. It is adaptive.
The 16px font, in the screenshot you send, is not "browser default size". Or, it is, but not as it was intended by browser makers. See, when it was chosen as default, we used 14" 1024x768 monitors or worse. Anybody who wants to show this as it was intended, needs to take account the DPI of a modern screen and increase the 16px accordingly.
Trust me, those guys have gave a lot of thought into readability and font sizing.
>Such huge text is definitely not easy to read for me on any of my devices.
Actually it is. You are just not used to it. Whereas you are used to fonts of exactly the same size (or very near) when reading books. Some people have been conditioned to stare at tiny fonts (a 12-14px font is a monstrosity on a modern display) and proper type jumps at them. Check also Zeldman's reasoning:
http://www.zeldman.com/2012/05/18/web-design-manifesto-2012/
A quick solution for you might be to use a third party GPS app/maps. Usually they are better than Google Maps (you do miss the integration with the other iOS apps though).
I wonder how much of the low quality is due to Apple (bugs of the new Maps app, which can be easily fixable) and how much is due to Open Street Map data being subpar (which needs much more time and work to fix)?
I, for one, found that for some kinds of work I do, Go doesn't give that much of a performance advantage, so I'm exploring other languages.
That said, even if Java gives you 2x, that doesn't mean that you shouldn't complain about Go.
E.g you might like Go's semantics and syntax, or it might have other benefits for you. That you like those things about Go, doesn't mean you don't get to say "shame about the performance".
Which is very common in modern business, but shouldn't happen when you have "science" in there. Lives a bad taste.
Science is all about clarity and SPECIFIC fields of study. Nobody does "science" in general.
Oh, don't worry about that. I'm an equal opportunity insulter! I didn't even care that she is a woman or not while making my point. Nor do I think that women in tech need special treatment. We all get what we all get. Do you see exchanges between males being any more courteous?
Notice also how I avoided to speak about their opinion on Yahoo at all -- they might or might no be 100% correct.
I only responded to the statement by some parent poster, that her CV "proves" that she is especially knowledgable in the ads field.
[I'm not saying this about the L1i cache case specially, which is a good point, but rather for the prevalent response to any benchmark in Go-land, a defensive attitude which I have not witnessed in any other language community. Usually Python, JS, Ruby, Rust etc guys get on to fixing such microbenchmark behavior or explain why it's as it is. Go guys just propose you forget about it and rewrite your code in another way].
I don't care about a specific real world case of getting from A to B, or how it can be done faster in another way. I care about measuring sprinters. The case that's important here is benchmarking itself. How fast each and every instruction of a similar type executes in a language.
E.g if I do:
for i in range(10): print i
and
for i:=0; i<10; i++ { fmt.Print(i); }
I don't care if this kind of code is not representative of an actual program, I don't care if the code inside the loop might take more time in most cases, I don't care if I can write some particular program using some other structure.
I only want to know why this takes X time in Python and c*X time in Go, and if the c factor can be improved.
Suggestions about "real world programs" and "write this another way and then measure" in this regard are counter-productive, because they focus not on raw benchmarking the language but on specific cases.
Even if that's the case, one would assume that would hold for ALL languages, so you get a fair comparison at that...
That's what Go advocates always say, but, for a static language with tight memory structures, it's not that fast at all.
Now, he does compile with gcc go, which is faster, but using the go tool I frequently find for lots of use cases it's about 50-100% faster than Python, or 2-5 times slower than Java.
Not every impressive -- it probably needs a better compiler with more optimizations and a better GC.
When you point that out the the golang mailing list, it's mostly met with la-la-hands-in-the-ears denial, and suggestions to rewrite your program in a smarter way and micro-optimize it. But I don't want to find the optimal algorithm for something -- I want to compare speed, and for that same-ish algorithms in same-ish languages are fine.
(Though, Russ Cox said the current HEAD has a lot of optimizations and is quite faster, so things might be improving there).
It will never stop being English/Latin alphabet dominated for the English (Americas, Australians, etc) though.
So, it's not like english web designers will see any major change in their work, or english web users...
What "ample evidence"? The USSR? For one, they had a mighty fine space program.
Second, one example of central planning, that also carried other kinds of rubbish with it (cutthroat politics at the top level, being enforced on a backwards, non adequately industrialized country, dogmatic ideology, and having to fight a foreign superpower) does not "ample evidence" constitute.
Central planning != 20th century communism. We have much better examples of central planning, successful ones, in the western world.