xscott

57 ms·

691.
by xscott 7y ago
I think Linus is very focussed on the stuff he cares about, and that shows by his complaint about PAE, which is pretty invisible to use userland folk. > the people who actually buy Intel kit basically want a faster 8088/80386/P
692.
by xscott 7y ago
I never got to play on a Cray, but I remember working on a Convex for a couple semesters in school. I had no idea what I was doing back then. Nowdays, it's pretty clear GPUs are the winner, but like I said, they just don't feel l
693.
by xscott 7y ago
> I don't think x86 compatibility mattered. I'll admit I had a limited worldview, but not running Excel as quickly seemed like the kind of criticisms I saw in the trade rags at the time. > the idea that a massive array of ch
694.
by xscott 7y ago
I recently worked with another company trying to solve the same problem, but I suspect I should keep my mouth shut due to NDA crap. Regardless, I suspect we're easily another decade out before anyone makes FPGAs accessible to the mass
695.
by xscott 7y ago
> There is one exception though, and that is floating point code. I wish I had read to the end before replying (and then deleting) responses to each of your items. :-) I think we're mostly in agreement, except for the following min
696.
by xscott 7y ago
If anyone stood a chance to compete against x86, I'd think Intel would be it :-)
697.
by xscott 7y ago
Agner is obviously brilliant, but I think maybe he's looking at general purpose applications. If I'm doing a million point FFT, I can easily give you 2 million operations in a row without a loop/branch. Maybe 1000 of those a
698.
by xscott 7y ago
Heh, I suspect hardware folks would like a CPU which programmed well with Verilog or VHDL, and I know that trying to make a hardware description language accessible to software folks has been a pipe dream for at least 25 years. However, I
699.
by xscott 7y ago
I loved working on DEC Alphas. They seemed to me like the best of breed conventional 64 bit machines, and it was sad when we quit buying them because x86 boxes were cheaper. > it seems to me that almost all the innovations Intel brought
700.
by xscott 7y ago
I'm not a computer architect (so my opinion shouldn't count in this thread), but as someone who did a lot of numerical programming over the years, I really thought Itanium looked super promising. The idea that you can indicate a
701.
by xscott 7y ago
What we need is a compiler flag that says, "give me the good parts of C++11/14, but leave out the bad stuff from C++98, and fix some of the inconsistency quirks from trying to be compatible with C89".
702.
by xscott 7y ago
Which is kind of interesting considering how removed the assembly which was written is from what is actually executed. You'd think x86 would be even less likely to notice you changed the plan out from underneath it.
703.
by xscott 7y ago
I suspect it falls under the "discourage truthful comments" umbrella... Beware of misguided incentives.
704.
by xscott 7y ago
I'm not sure what your point is about Python 1.4. Maybe it's that you're past the point where these things trip you up. However, there are plenty of cases where Python won't give an error message too. Make a typo somew
705.
by xscott 7y ago
What's the symptom and what's the cause? Python's lambdas aren't very good, so they're frequently not a very good solution...
706.
by xscott 7y ago
JavaScript is far from perfect, but at least it's clear you declared two variables.
707.
by xscott 7y ago
The other three lines are not unrelated. If you just take the first three lies (and the last one), it's fine: a = 0 def f(): print(a) f() Maybe this is all obvious to you, but I'll bet you can't name
708.
by xscott 7y ago
I bet neither will go down, but the human race will improve! Seriously, things are getting better - it's just that paying attention to what needs fixing is how engineers contribute to the progress.
709.
by xscott 7y ago
I suspect it's healthier to judge a few misfeatures in a programming language than to judge all developers, or people as a whole. I'm really very optimistic about the future of humanity, but less so about the future of Python :-)
710.
by xscott 7y ago
Is that what you expected from such a simple piece of code?
711.
by xscott 7y ago
I understand why people are willing to defend it or make apologies for it, but there really are some lessons to be learned from the mistakes it made, and dismissing legitimate criticism just ignores the opportunity.
712.
by xscott 7y ago
Yeah, that certainly fits.
713.
by xscott 7y ago
Even more fundamental is the nonlocal/global stuff required in order to avoid declaring your variables. Many people are surprised by what this snippet does: a = 0 def f(): print(a) a = 1 f() f()
714.
by xscott 7y ago
Yeah, current versions of Python feel like Guido and the rest changed their minds about what they wanted.
715.
by xscott 7y ago
I worked on a project where the (large) customer had some legacy requirements about percentage of "CPU" our application was allowed to use. The requirement was written back in the days when a single computer really only had one c
716.
by xscott 7y ago
What language? Unless it's Ocaml, I'll be surprised if addition isn't overloaded for ints and floats at the least. Most people are fine with some overloading... To each their own though.
717.
by xscott 7y ago
I think your point is to emphasize there is no additional cost to method syntax. I wasn't trying to imply there was, only that when you want dynamic dispatch, you can only get it from method syntax. Another interesting asymmetry, whic
718.
by xscott 7y ago
> only one finger on your "out" hand I think Python's way isn't amazing, but it's not too bad either: d, r = divmod(100, 3) It's a bit uglier in C++, but you could make this work: int d, r;
719.
by xscott 7y ago
I misunderstood then. However, if you just meant that people prefer method syntax because method syntax is infix, then it seems to come full circle to asking why they like infix syntax for methods... Doesn't really matter - it is wha
720.
by xscott 7y ago
I don't understand what you mean by "causal" in this context. A.f(B) is just a syntax sugar around f(A, B) unless dynamic dispatch comes into play. Then it's usually syntax sugar around something like: A._vtable[f

More ›