fnl

42 ms·

391.
by fnl 16y ago
check PEP-261
392.
by fnl 16y ago
Well, I am neither black-and-white with the topic. Both have valid reasons for use; UTF-8 in general is more efficient in space for any use where ASCII characters are predominant. UTF-16 is more efficient if non-Latin-1 characters are predo
393.
by fnl 16y ago
256 char ASCII is called "8-bit", "high", or "extended" ASCII. So, pure (7-bit) ASCII is the only thing you can hold in a "one-byte UTF-8 array". The 8th bit (or the first, depending on how you see it) is used to mark multibyte characters,
394.
by fnl 16y ago
Quite on the contrary; I work in data mining and need to count characters on many different occasions. Probably for web development you don't need to care about that stuff, right (but read the second paragraph first!). So if character count
395.
by fnl 16y ago
Oh, and another thing is your argument only holds for ASCII - I hardly ever encounter pure ASCII data nowadays when I work with text. On the other hand, I never have encountered a Surrogate Character except in my test libraries, either. N
396.
by fnl 16y ago
The important fact lies in the last sentence; in all of my apps, I could so far safely and soundly ignore the fact that Surrogates are two characters long to establish character lengths. So by using UTF-16, all those apps are significantly
397.
by fnl 16y ago
As I posted there, too, he also missed one very important plus in UTF-16: character counting. If you ensure there are no Surrogate Chars (which is a simple byte-mask comparison using every second byte (only!) as in: "0xD800 & byte == 0
398.
by fnl 16y ago
Would anybody mind to actually read the table and numbers? At the very bottom of the tiny table, in the second-last row: After all considerations, people that would still switch ("No, I still plan to switch") is 21% (Ad) and 28% (BB) - that
399.
by fnl 16y ago
Crystallographic studies? What is wrong with simply doing the gradient suggested by two commenters in the blog entry? If that turns up negative, you can immediately get an answer and scrap the whole paper. (Which in itself leads to quite so
400.
by fnl 16y ago
That probably much depends on what you are doing or want to do, and to chose a language that best complements what you already know. If you want to make safe bets, pick one from the "most popular" chart that you did not list (JavaScript, Py
401.
by fnl 16y ago
But there is a minute, yet important difference: the App Stores are entirely controlled by Apple, whilst Microsoft never restricted or controlled your access to their platform as a software provider. So, maybe they "dominated" because of Of
402.
by fnl 16y ago
If I may ask - why is that so that you don't want to switch? The best reason IMO for following your model might be the increasing amounts of DRM we are seeing in the two big desktop alternatives. It honestly makes me think that there is no
403.
by fnl 16y ago
And, if I may add, ever since Ubuntu (not that I like it, personally, but whatever) I've seen more people using Linux than ever before. Give it another ten years and they might have something really competitive on the end-user side, especia
404.
by fnl 16y ago
Well, I sort of tried to say that - although, my impression is that it was harder to develop for Apple than DOS because of the unavailability of developer tools for Mac OS. Although I must admit I stuck to Atari to the bitter end and direct
405.
by fnl 16y ago
Well, for us back then the only ways to lay hands on a good C compiler - except buying some extremely expensive proprietary software we could not afford (we all were under 20 and w/o regular income) - would have been via not-so-official cha
406.
by fnl 16y ago
As an update: Python 3k solves the namespace issue you mention. (And I hope more and more dev's will finally move on, I love it and only can say it is 100% worth the switch! I'll never again code in pre-3k if not forced to.) And no, I am no
407.
by fnl 16y ago
Another bump for the emacs/vi couple; I use emacs.
408.
by fnl 16y ago
This blog speaks from my heart: maybe I managed to wrap my head around OOD and even tried some AOP, but in the end, as I am - in the most general sense - a data miner, I always crave for high-throughput and low resource consumption. Every l
409.
Ask HN: Is Apple repeating the same mistakes it made 25 years ago?
8 points by fnl 16y ago|14 comments
410.
by fnl 16y ago
Well, I do not quite agree with your argument that Python is "always memory-hungry". As a matter of fact, writing "good" Python code is a very seldom observed art and most performance issues can be gotten rid of if you know enough about the
411.
by fnl 16y ago
Well, following the advice I got here I started out with Erlang - where you have much of the same issues you describe, too. However, having immutable variables also allows for some pretty nifty stuff in Erlang (and I guess in Haskell even m
412.
by fnl 16y ago
Followed the advice I got here from you and others and am now studying the language. And, so far, I must say, Erlang rocks. Naturally it will be a few weeks before I can write something real and make more of an educated decision, but it rea
413.
by fnl 16y ago
Ah, well, I should have a closer look at times... Thanks for the hint ;)
414.
by fnl 16y ago
So far, your reply about Haskell seems the only promising alternative to C. Could you imagine to develop in Haskell and use, e.g., HaskellDirect, for C libraries that are not available in Haskell for certain tasks? And, it seems you can eve
415.
by fnl 16y ago
To sum up what you so far have responded: For data distribution it seems, OpenMP and MPI are still the best implementation if you expect to have a constant runtime for each of these tasks. On the other hand, for task distribution (say, ms &
416.
by fnl 16y ago
Nice pointer to a MPI library I wasn't aware of - thanks!
417.
by fnl 16y ago
nope - I want to work on my machine - same reason why I don't know how to use Windows :)
418.
by fnl 16y ago
Impressive admin work you have there :) Thanks, that is I think the most concise answer summing it up. So, as you are even in the "right environment" for that - one question might be left another guy raised: got any thoughts on Haskell abou
419.
by fnl 16y ago
Second that question, too! Actually, in terms of what can be gained, Haskell might be even more interesting to learn in terms of the increasing need of MP than thinking about go or Clojure.
420.
by fnl 16y ago
Hmm, so you would not say that Clojure's or Go's approaches are worth it in terms of programming ease? The plots you point to looks at least seems worrying: Python is smacked on the concise 0-axis, C on speed. Clojure at least makes no espe

More ›