I reckon it is meant in a "opportunity cost" kind of way.
327 karma · joined December 6, 2013
There exists libraries that do provide an ORM, but since the declarative side of golang is limited compared to languages, say Python, I find them unwieldy. Also, the current trend shuns the usage of an ORM in golang and encourages directly or indirectly writing SQL queries and interacting with the database through database/sql and its extending libraries, like jmoiron/sqlx.
You may want to take a look at Bison/Flex. While they don't suit the tastes of everyone, it's good to know how to work with them. For example, BASH parser is written using those tools.
I'd also object NT kernel being more "powerful". Sure unixy kernels and NT has their differences but I don't think either one is superior.
cat /dev/urandom | hexdump -v -e '/1 "%u\n"' | awk '{ split("0,3,5,6,7,10,12",a,","); for (i = 0; i < 1; i+= 0.0001) printf("%08X\n", 100*sin(1382*exp((a[$1 % 8]/12)*log(2))*i)) }' | xxd -r -p | aplay -c 2 -f S32_LE -r 24000[0]: http://eu.wiley.com/WileyCDA/WileyTitle/productCd-EHEP000711...
This experience made me think in what state my mind will be at later ages. I'm quite young now, and I've heard from so many people that at later ages one's thought process is not as fluid or creative as it is in youth. It made me think of all these moments of brillance I've had the pleasure of experiencing will vanish as I age. I'm speaking of arriving at solutions to problems without consciously thinking about them, like all of the sudden the solution just pops in your head and, comparing to the state that you are in, moments ago, having no clue what to do with the problem at hand, suddenly you precisely know what to do. I have done nothing to achieve or deserve this trait, but still, knowing that it will be taken away some time later and having no control over the process, is depressing.
I will probably never have enough time to go through this, which is sad.
This principle goes in programming, as well as in writing. But not all writing is done to transmit ideas, there is also aesthetic side of it.
Another thing, a visa broker in Turkey had a so ridiculous password rule and gibberish error message, I had to read the source code and parse the regex by hand. Only then I was able to type in a valid password.
It would be naive to think that getting along with people well, while being a remarkable trait, isn't the only thing that leads to success. There are a lot of variables controlling that. It's just common sense that if you are good with people, you are more likely to be successful.
Lastly, I believe a lot of people will be spraying this thread with counterexamples as you did, but the greatest example of PG's argument is the one of the people who gave the world the Silicon Valley [1]. He could have been one of the most cherished person of the past century, he could have all the wealth he wanted, but instead he practically died alone, leaving many people with hatred towards him. Because he was "mean".
On one of his seminars Andrew Ng talks about "the algorithm": he pointed out that human brain may re-wire itself to handle different tasks, for example one part of the brain which is responsible for sight might take up the task for hearing. The idea of ANN undisputedly inspired from research investigating how brain actually works, and now it has set the state-of-the-art on many areas it has been applied, but to do this we had to resort to "ugly hacks" in the perspective of "the algorithm", to name some of them would be Autoencoders and Restricted Boltzmann Machines. It works, yes it works very well, but we had to pay a price of taking a detour from finding "the algorithm".
In my opinion, such banterings as in OP should not be taken as an aggressive stance against deep learning. Just because it is not "the" method doesn't mean it has no value whatsoever, but it has a point; after the limitations of deep learning is explored well, we will need a new idea to push the field further.
I began by trying to run the program in GDB, got SIGSEGV'd. Afterwards I inspected the faulty address and tried to avoid it by changing its value, instead it crashed at somewhere else. After trying this hopeless catch-and-run for several hours, I decided I needed a better disassembly tool and went on to IDA Pro.
This particular program contains a trick that intrigued me very much, and it is the reason why I was getting SIGSEGV'd at different locations when altering the program code.
The main payload of this program is simply XOR-encrypted by some key. The whole thing begins by decrypting the payload and then begins its execution as normal. The gist is, the particular key that encrypted the main payload is the decryption code itself (for the unacquainted, assembly code is also just a byte stream). Here, this exact part:
0x804762d: mov $0xaa,%dl
0x804762f: mov $0x8048480,%edi
0x8047634: mov $0x8048cbc,%ecx
0x8047639: mov %edi,0x80476f3
0x804763f: mov %ecx,0x80476f7
0x8047645: sub %edi,%ecx
0x8047647: mov $0x804762f,%esi
0x804764c: push $0x80476c1
0x8047651: pusha
0x8047652: mov $0x55,%al
0x8047654: xor $0x99,%al
0x8047656: mov $0x8047656,%edi
0x804765b: mov $0x80476e5,%ecx
0x8047660: sub $0x8047656,%ecx
0x8047666: repnz scas %es:(%edi),%al
0x8047668: je 0x804770a
0x804766e: mov %edi,0x80476eb
0x8047674: popa
0x8047675: add 0x80476eb,%edx
0x804767b: ret
At the end of every iteration (of something involving this loop which I can't precisely recall now) the program checks whether it is running under debug mode (essentially makes a PTRACE call and reads its output, the OP also talks about it) If this is the case, it makes a jump to random address, so even if you are just neatly watching the program run under debug mode, you weren't going to achieve anything.
The next thing that occured to me is to manipulate how PTRACE returns its value, but I thought it would involve some kernel code fiddling and running the program under the modified kernel, which is WAY beyond my ability for now. I didn't know how to do it, but later by some very stupid trick I managed to pass this decryption part and the program made a jump to something like "__glibc_start". I needed to save the altered program and run it under gdb again (I don't remember why), but I was using the trial version of IDA Pro which prohibits me of such a thing. After making a few more desperate attempts I gave up.
But this "using the code as the key".. I think spending 14 hours to see this done was well worth it.
Alright, some basics; Everything that has to access persistent information frequently is bound by disk/network/whatever IO, and web programming is no different. The reason why languages such as Python and Ruby are very viable options for this task is they are quite a lot abstracted away from bare metal to hasten the development process. The wait for IO is quite long compared to logic execution, so even though we are executing more instructions to get the same job done, the resulting overhead isn't very significant.
CPU-Bound computations are most definitely will execute faster in statically compiled languages such as C/C++, D, golang relative to interpreted languages but in the context of web programming this is not the case. Even though; if rendering HTML is such a big pain in the ass that it is slowing you down a lot you can always use a library that is implemented in a language that's fast, say C, and use its wrappings in your scripting language of choice. I am not sure about to what extent this is supported in other languages but I know you can do this in Python, heck you can do this in golang, even though it is a relatively new language [1]. I wonder how the author will move to C10M world by optimizing the wrong thing.
Regarding artificial systems, I think more data is the only way to reach super-performing classifiers. The data you supply doesn't have to be big but at least the data you extract from raw data should be big. For example, a method called Integral Channel Features [2] is designed to act in such a way.
[1] http://en.wikipedia.org/wiki/Sensory_deprivation
[2] http://pages.ucsd.edu/~ztu/publication/dollarBMVC09ChnFtrs_0...