T-R

9 ms·

61.
by T-R 9y ago
> First, literacy isn't completely related to the writing system. Look at Spanish speaking countries, where the alphabet is more phonetic than the English alphabet. Perhaps more to the point, Japan, which uses Chinese characters for
62.
by T-R 9y ago
Practically speaking, things are more nuanced than the article would imply, though - they're not 3000 completely unique characters, and at least for a lot of nouns, the radicals do serve to broadly categorize things as, e.g. "rela
63.
by T-R 10y ago
They seem to be restocking in small batches and selling out immediately, at least online. According to nowinstock.net, in the US, Best Buy's been getting shipments most consistently, and received one as recently as last week. Some peop
64.
by T-R 10y ago
It's certainly reasonable for a studies across fields with hourly pay or, e.g., including both part-time and full-time (such as the BLS survey cited by the Forbes article), but I'm not sure we can make that assumption for software
65.
by T-R 10y ago
> they didn't control for hours worked Are the programmers in question being paid by the hour? Does programmer pay within each gender correlate closely to hours worked?
66.
by T-R 10y ago
Sure, Korean is phonetic, and so learning it phonetically makes sense, since you won't be forced to re-learn it again to be able to use your knowledge. Speaking from experience studying Korean, though, attaining a useable vocabulary th
67.
by T-R 10y ago
They're not reasonably separable. Memorizing romaji, or even strings of hiragana, removes the associations between root-words that are related, like those radicals that let you identify menu items, and removes the visual aid for identi
68.
by T-R 10y ago
> pay little or no attention to memorizing characters I'm not usually one to speak bluntly, but, at least for Japanese, speaking from a lot of experience, this is flat out the wrong approach. Older books like the romanzied "Jap
69.
by T-R 10y ago
"standard 12pt font" is biased for latin characters, though - at the larger font size, the Chinese characters are still getting much better information compression than the latin characters, which need to expand horizontally by us
70.
by T-R 10y ago
Kanji isn't so bad - most of the more complex characters are built up out of smallers ones, and even the smaller ones, as the article breifly hints at, have a primary radical that roughly categorizes it - learn the radical for "wa
71.
by T-R 10y ago
Thanks for the link. I'm actually under the impression that the situation in Haskell will be changing in the near future with the project called "Backpack"[1][2], which Simon Peyton Jones and Simon Marlow are both involved wi
72.
by T-R 10y ago
Distributed Programming was one of the things flagged "Immature" in State of the Haskell Ecosystem [1]. Just out of curiosity, was that a motivation behind the project, or do you have any other thoughts on that post-project? [1]
73.
by T-R 10y ago
That's more or less it. Some things you can do: - Dataflow analysis, to get an idea of the types/range of values you're working with - Pattern matching to try to identify higher level constructs from math to loops to jump tab
74.
by T-R 10y ago
This is maybe true, given that Rust is intentionally multi-paradigm, but it's a pretty unfair comparison: My FP-style version deliberately made almost no changes to the original code aside from adding names - I even stated in the comme
75.
by T-R 10y ago
Oh, it definitely pops up a fair bit, but it really is just not-well-factored code. It's a direct parallel to having long boolean expressions, or long equations without breaking out any sub-expressions and storing them in named variabl
76.
by T-R 10y ago
I think the issue with procedural loops (not to be critical, just in general) is that there's no abstraction - it's not clear what's getting mutated, or what the result is (or its type), it's harder to look at the indivi
77.
by T-R 10y ago
> a closure works fine, so `|fname| to_buff_reader(check_err(open_file(fname)))` would work Ah, yes it would. Clearly I'm a bit too tired to be writing code, if I've overlooked function application . I suppose it doesn't
78.
by T-R 10y ago
Please, please, please don't associate inlining everything with functional programming. Lambda-lift and name those functions. If you name them, you can ditch most of those comments, too (by moving that information into the names). Not
79.
by T-R 10y ago
The grandparent brought up the concept of a community problem where members from a community actively seek out and mock members of another, completely unprovoked. I won't argue whether members of the Haskell community do it or not - I
80.
by T-R 10y ago
I think that's changing. A lot of the over-proliferation of operators came from missing functions (like Data.Function.(&)), missing typeclasses (Like with Data.Lens or other generic operators), or missing sugar (like Applicative Do
81.
by T-R 10y ago
Lazy IO's an issue, but Lazy Evaluation? It's not that different from writing SQL, and the places where it is, it's a lot more consistent, predictable, and tuneable. It's usually just bad defaults like Lazy IO, or String
82.
by T-R 10y ago
I like that Data.Sequence bypasses this whole issue by just not doing anything special: empty |> ("one" , 1) |> ("two" , 2) |> ("three", 3) Edit: It's interesting that
83.
by T-R 10y ago
Satisfying theorems is generally for the purpose of friendliness, by ensuring consistency. In this case, they had two options: (a) be consistent as if the language had type-level literals, which resulted in nicer code in the usual case, but
84.
by T-R 11y ago
Explicit use of recursion in functional programming is widely considered to be low level and bad form, like writing all your loops with gotos in a procedural/OOP language (as was the primary argument of the Bananas, Lenses, Envelopes,
85.
by T-R 11y ago
Looking at the Japanese and Korean, it seems there's some over-romanticization here.It's a little odd seeing the Japanese "nakama", the word Monkey D. Luffy constantly throws around to refer to his crew, described like i
86.
by T-R 11y ago
I've been working on a functional/event sourced postgresql database for the past few years. The approach in general is great, but we're currently investigating alternatives for implementation (whether going to something like
87.
by T-R 11y ago
Sure, we can have a perfectly reasonable debate as to whether or not lazy-by-default is the best choice for a language. I personally like the laziness, but if Scala, or Closure, or ML, or Elm, or maybe by some act of god COBOL "wins&qu
88.
by T-R 11y ago
The theory is for getting consistent/composable APIs, and trust in the code - trust that you can optimize it, parallelize it, or just that it behaves the way it's supposed to, without having to read every line of it. You don'
89.
by T-R 11y ago
It's definitely relevant that my complaints are from a Haskell perspective (as this is a Haskell thread). If I'm working in just about any procedural/OOP language, sum types are a completely foreign concept. If I'm worki
90.
by T-R 11y ago
SQL is incredibly low level - Modelling Sum Types requires giving up correctness guarantees, performance, or both. - It's not expressive enough to get performance or abstraction - I can't communicate "this is a one-to-one rel

More ›