That sounds interesting, but I'm suspicious. Do you have any examples of such macros and maybe some statistics or ideas how often they are actually seen in the wild?
I can only speak for the Emacs capabilities of readline: all commands which would usually change the line (previous/next-line, beginning/end-of-buffer) will use the history as the buffer. All of them preserve the line you are currently typing, which will be the end of the buffer.
Ascending single or double ropes is most often practiced in rope access, tree climbing, caving or technical climbing. Ascending a single rope will often involve a Jumar [1] and a camming device placed on your foot or chest. Ascending a doubled rope can be done with just the rope using Blake's hitch or some extra material and a Prusik knot.
Hell it's valid for everything period. Even vectors! Splitting struct a into hot/cold chunks is pretty common. Minimize the sise of data being iterated on to maximize cache usage. Can result in big wins.
It is. The Go language devs should just own it and say "No". Will the arguments shift somewhere else? Maybe but maybe the "Go needs generics" folks will just go away.
>The Go language devs should just own it and say "No"
Which is the grown up, honest, thing to do.
But I'm not sure about the other thing you mention:
"Maybe but maybe the "Go needs generics" folks will just go away."
Why would they go away?
They ask for Generics because they have found some use for Go (say, because it has a OK standard library, or decent tooling and momentum compared to alternatives), but also found a need this feature.
Neither the "use of Go" they found, nor their need for generics will disappear if the language devs say "no". If anything, as stakeholders in the languge (a user is a stakeholder) they'd be even more pressed to change the language dev's mind -- down to the fork point.
How many years to go before go users/developers outside of google will fork "go lang" the way node.js users/developers did ?
the go-lang team at google is very smart. It's not that they have a huge amount of high-priority work other than generics. Why don't they address a summary of the sentiment on hacker news on generics ?
If you're a programmer, your life is made easier if you have access to generics.
If you're a language developer, your life is made harder if you have to add generics.
And if your language gets all the people that are easily satisfied with something "static and faster to write than C" why go the extra mile?
Especially if your goal is not building a commercially succesful language, or an advanced language, or a language to solve 2014's problems, but just to hack on what you have created.
Besides, being a great programmer and a great language designer are two different skills. Would a language created by Linus be that good?
You are being downvoted because the language comes with well-defined and specifically designed ways to customize allocation/deallocation. Your approach choses to ignore those facilities and even adds a runtime decision to code that absolutely has no need for it. You are reinventing the wheel and it is not even round.
It is easy to forget that this is just a report and up to this point it hasn't had any real consequences yet. If this will ever lead to anything (be it criminal charges, convictions or change in policy) is still open.
I don't think it will lead to anything, not more than the 11th september 1973, or the whole Operation Condor. There is no balance of powers around the CIA.
That is the kind of magic thinking of C++ programmers sometimes exhibit that drives me insane.
Yes, compilers have become excellent at optimizing code, but they aren't magical. The generated code will have some semblance to the code we write. Eliding dynamic allocations is just not possible statically. Heck, we aren't even able to emit warnings for missing deallocations reliably and have to use run-time instrumentation for it.
Even in C++ or C, even with good compilers, we still have to go the extra mile if we want fast code.
That is the kind of magic thinking of C++ programmers sometimes exhibit that drives me insane.
I dunno. I've run into too many programmers on the other end of the spectrum. They're reluctant to take advantage of the genuinely zero-cost abstractions that today's excellent optimizing compilers for C++ enable.
I can't find the reference now, but I thought I had seen some discussions at one of the ISO C++ meetings (from Google?) about potential standards changes to allow allocations to be elided when they're limited to some known scope.
> I dunno. I've run into too many programmers on the other end of the spectrum. They're reluctant to take advantage of the genuinely zero-cost abstractions that today's excellent optimizing compilers for C++ enable.
Performance wise it might give a false impression of being zero-cost if you micro-benchmark or are very selective what you consider as a cost. Handy for developer effort wise, sure.
Yes, it's often cheap or even 'zero-cost'. But you can't assume that to be always the case.
In an actual system it might be not so zero-cost when there are multiple concrete instances of generated code of the template. Each consume require actual generated machine code. Larger code size can have a significant performance cost. TLB and L1C cache misses are far from free. Neither is loading the larger executable for short life time processes. Extra page fault, caused by larger memory requirements, that goes all the way to disk is also rather expensive.
The whole picture is simply way too complicated to make blanket statements like that.
I think the right approach is to get a decent high level understanding of how compilers work. Some surprising optimizations and failures to optimize become a lot clearer. For example, SSA makes it obvious why there's absolutely no penalty for using lots of named temporary register-sized variables.
Then learn your particular compilers' abilities by research and reading your assembly output. If you're depending on an optimization, always read the output. You might be pleasantly surprised as often as you're disappointed.
Understanding the rules of the language are important too. In C++, pointer aliasing and the worthlessness of 'const' are huge obstacles to some seemingly easy optimizations.
I was immediately reminded of Robinson's work a few seconds in. There is so much to discover out there and the extremes of physical state and sheer size make it so hard to imagine it all. His writing offer a window into that world and this short was a great visualization of it.
Robinson is a fantastic author at conveying "a sense of place" - particularly Mars, of course. I fell in love with Mars because of Robinson, unrequited love of course - Blues for the Red Planet indeed....
Also, I also loved his book Antarctica which is effectively "White Mars" - at least there is a chance of visiting incredible places like the Airdevronsix icefall - arguably the largest waterfall on this planet (5km wide and 400m high):
