atilaneves

22 ms·

91.
by atilaneves 7y ago
> C++ was always much more into the functional programming paradigm. (See the STL, for example.) Always? The STL was a last-minute addition to the standard library before C++98. Just a few years before, template implementations in compil
92.
by atilaneves 7y ago
> I agree, but C (the language) doesn't even have the concept of a 'string' It has string literals, so yes it does. > The C++ std::string type is neither intuitive to work with Many would disagree. > nor does it allo
93.
by atilaneves 7y ago
Sure - my personal rule #0 of programming is "use your head", the longer form being "understand the trade-offs and make an informed decision". I'm not advocating for always using auto, but I am wondering out loud wh
94.
Type inference debate: a C++ phenomenon?(atilaoncode.blog)
1 points by atilaneves 7y ago|2 comments
95.
Build Systems Are Stupid(atilaoncode.blog)
7 points by atilaneves 8y ago|2 comments
96.
by atilaneves 8y ago
I, a unit test aficionado, posit that sometimes unit testing is a bad choice for your code. AMA.
97.
When you can't (and shouldn't) unit test(atilaoncode.blog)
2 points by atilaneves 8y ago|1 comments
98.
by atilaneves 8y ago
I find Python easy to use. I don't think Go is easy to use at all. Boilerplate, boilerplate, boilerplate. I don't have to write for loops in Python. Go makes me.
99.
by atilaneves 8y ago
Yes, it's the case in practice: I've written a lot of @nogc code. Some parts of the standard library require the GC, but not all of it, and the parts that I usually use are fine (std.algorithm, std.range, ...). Since allocators la
100.
by atilaneves 8y ago
> they feel that generics are a good fit for this language Or that it's ludicrous for any statically typed language to not have generics. > It’s small and simple, and every detail is carefully thought out > Nearly all of Go’s
101.
by atilaneves 8y ago
If I had the time, I'd love to apply the C to C++ diff on top of Go (templates, overloading, etc.), release it as Go++, and watch the world burn. Just for the lulz.
102.
by atilaneves 8y ago
> Isn't D memory unsafe by default? Yes, but it only takes this to guarantee it: void main() @safe { // ... }
103.
by atilaneves 8y ago
Rust achieves memory safety without a tracing GC. D has traditionally relied on the GC for that, but now there's [DIP1000]( https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md ). D can howe
104.
by atilaneves 8y ago
C++ 11, 14 and 17 have all closed the gap with D in terms of features, but IMHO even when those features exist in C++ they're a lot harder to use and a lot easier to shoot oneself in one's foot. You _can_ get things done in modern
105.
by atilaneves 8y ago
> AFAIK, the back-end, not the front-end/parsing, takes most time when compiling C++ Is there a reason why you believe that to be true? > So in case of GCC or LLVM based D compilers, the time should be similar? They are not: htt
106.
by atilaneves 8y ago
> as opposed to passing large byte slices or strings around. In theory, this should be more efficient Why would passing a "large" slice be inefficient?? Maybe on x86 due to a lack of registers, but on 64-bit?
107.
by atilaneves 8y ago
> The first example is not at all good No, it's not, but in my opinion not because of any of the reasons you just stated. Unless you're writing Go, that code should have been a fold over addition, or a `sum` function if availab
108.
by atilaneves 8y ago
I don't know a lot about Nim, but I do know D, and there `string` is just an alias to `immutable(char)[]`. String literals are of this type. But one can manipulate mutable arrays of char all day long if needed.
109.
by atilaneves 8y ago
The usual problems with making things mutable: that mutable state is the root of all evil.
110.
by atilaneves 8y ago
> > * Mutable strings > I love these! No need for messing around with `StringBuilder` and the like. D has immutable strings and no StringBuilder. Same with Python. Concatenating isn't exactly hard.
111.
by atilaneves 8y ago
Try the gold or lld linkers.
112.
by atilaneves 8y ago
I wrote the blog post and I definitely think ranges are worth using, and said as much in the link. I just don't think they're worth it in this particular case. The code is usually clearer and more reusable with ranges, and if by c
113.
by atilaneves 8y ago
It's valid C++ and requires no external dependencies.
114.
by atilaneves 8y ago
Update: The Rust versions can all be made to run faster with a simple edit. I've updated the timings and edited some of the text.
115.
Comparing Pythagorean triples in C++, D, and Rust(atilanevesoncode.wordpress.com)
135 points by atilaneves 8y ago|116 comments
116.
by atilaneves 8y ago
The main takeaway is that this isn't necessary with mutable structures. Nobody would think of even trying to write a generic solution to a problem that doesn't exist in C++.
117.
by atilaneves 8y ago
> How do you pass a member identification as a parameter to a function that may receive any kind of structure, and then update that member? You don't. You just update that member.
118.
by atilaneves 8y ago
You can overload operator new to not use the heap. You can use allocators.
119.
by atilaneves 8y ago
> you do not have fully understand Monads and their underpinnings to be productive in Haskell I don't think that's true. Most programming is done in a team, and someone will have written a transformer stack. I was told to use t
120.
by atilaneves 8y ago
And that would prove what, exactly? That no language is perfect we already know. My assertion is that, for the vast majority of programmers, Haskell is fundamentally harder than the languages they already know or could learn instead.

More ›