Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
c0de517e
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
6 ms
·
31.
▲
by
c0de517e
12y ago
Good suggestion, I'll maybe write a follow up with a specific example. Thanks! I've included a few pictures of stuff I recently used, maybe it can help to give more context. - http://1.bp.blogspot.com/-YA10ftXFFQ0&
32.
▲
by
c0de517e
12y ago
What I've found is that nowadays most of the resources on datavis are not about scientific/continuous functions but about categorical/statistical visualization. I've added a few (well many) links at the bottom of the art
33.
▲
by
c0de517e
12y ago
gnuplot is fine but one of the best features of visualization is interactivity imho, without interactivity you lose a lot of the power that comes from visualization... That's why unfortunately I still recommend something like processin
34.
▲
by
c0de517e
12y ago
Fortan is -undoubtedly- thought as a HPC. That doesn't mean it's great or I would use it today, but yes, without a doubt it is one of such languages. That's not to say that if today I had to write, as I do, a tight CPU kernel
35.
▲
by
c0de517e
12y ago
To both comments - it's not JUST because the lack of threads, don't take an example as the entire extent of the critique. It lacks threads. It lacks SIMD. It lacks control over pointer aliasing (restrict), something that FORTRAN d
36.
▲
by
c0de517e
12y ago
Really I don't often use classes, unless they are providing a benefit. Just using them to group some state with some functions is not great because they have lots of drawbacks for that, I find an opaque pointer and C functions to be be
37.
▲
by
c0de517e
12y ago
The question you should ask yourself is - what other languages I do know to compare C++ to? Do you know about hygienic macros in scheme? Standard ML parametric polymorphism? Haskell type classes? But even more mundane stuff like D's te
38.
▲
by
c0de517e
12y ago
The lack of GPU support is indeed widespread and really quite forgivable today. Threads, SIMD and restrict are not. And you're right about C++11, my bad. It's funny how C is actually pioneering a lot of the changes actually requir
39.
▲
by
c0de517e
12y ago
In fact I argue that a strict C++ replacement won't really cut it. But it's very wrong to say that "you'll end up with the same complexity and rules as C++", that's the justificationist argument that says that
40.
▲
by
c0de517e
12y ago
I might have written too much about the languages I intended just to bring forward as example. D is not high-performance (I clarified that in the post) the same way as C and C++ are not. They are not meant for HPC, they are meant to be &quo
41.
▲
by
c0de517e
12y ago
Nowadays most of the code I have to deal with and that I write myself is very "c-like" C++. For personal projects I usually use C# instead.
42.
▲
by
c0de517e
12y ago
The solution is - more objects wrapping more objects. I can already imagine people doing exactly that. Dependency injection is the name of the game right? That's what videos on youtube are advocating... But it's also a pain to pas
43.
▲
by
c0de517e
12y ago
There is an appropriate application of almost any tool, what's wrong is the hype behind certain ones. By abandoning the fad I don't mean that now everybody will never use OO again, but that OO had become the -default- paradigm for