It is a classic book and a great reference if you are optimizing for the 80386. But almost totally irrelevant for modern hardware. Its probably still a fun read for reminiscence purposes - Michael Abrash was a great writer.
It goes into pentium architectural points as well which is far more modern than 386. Built-in math coprocessors, Glorious! Though your point remains.
I am guilty of having a fair bit of nostalgia for this book. Memories of sitting in the back seat of my parents car in middle school. Pouring through this book. Fascinated by these inner secrets of machines I knew so little about at the time. Presented in a way even a 12 year old could mostly understand.
Why doesn't Windows drop the purported compatibility with CP/M and get rid of control-z being a special file marker at this point? Lots of legacy code relying on it?
FWIW it's generally advised to not open files in text mode on Windows anyway. The handling of \x1A is one reason. The automatic mangling of newlines into Windows newlines is another.
Edit: And while cmd's type does process it, modern stuff like PS's Get-Content does not.
There should also be a Latex library (?) that makes your documents look like they were photocopied, so you can use the coffee stains and the photocopy to make it look like you spent long nights working on your assignments.
Haha that first one's great, addresses (what is sadly) a real need.
I've seen that cthulhu-worshipping madman one before, but the results are disappointing. I'm sure much better can be done in that direction. e.g. (is this the most famous SE answer of all-time?) https://stackoverflow.com/questions/1732348/regex-match-open...
Because one day you might need to, and you'll write a 100 lines of code to do it. If you had known what a BFS is and how to write it, you'd be able to accomplish the same task in 10 lines of code.
Counter argument: I could google it, read about it, and implement it. All of it in 1/2H with a computer with internet.
Not on a whiteboard. Which is a fucking stupid interview process.
Very unlikely in my opinion. Either you’re told about it beforehand, inherit a project that’s using it, or introduced to it during your PR. Especially in places that ask about them during an interview...
I don’t think it’s about the BFS, it’s about attitude.
For example, blaze has integration with Google's build cache. Most of the time it takes 0 seconds to compile a given file, when someone else has compiled it before with the exactly same contents, dependencies and compiler flags.
This would be really useful if it can be run offline. Much easier to use than writing code, compiling it with -S to produce assembly, then trawling through the assembly to look for the code you're interested in.
It's open source, so you can just clone the source code and run the server locally on your computer. I've been running it like this for a long time :-)
How hard was it to set up for you? Is it a small standalone thing or a beast with complex dependencies? Did you configure it to run everything locally or is it still requesting a web service to compile the programs?
> Much easier to use than writing code compiling it with -S to produce assembly
In any real-world, production use cases, I will vastly prefer to "objdump -d" or "objdump -S" the executable image (which is formed from dozens, hundreds or thousands of source files, with specific compiler flags and so on). I'm not going to be feeding these source inputs into some dialog box on a website.
What you might benefit from would be a browser which can parse the output of "objdump --line-number -S <yourexecutable>" and present it in a nicer way.
E.g. all the implicated source files could be identified and loaded into multiple views/tabs, with two-way navigation between those and the disassembly tab.
Idea: massage the "objdump --line-number -S <executable>" output into a vim quickfix list (errors.err file).
Then run vim -q.
The idea would be that all those file:line entries become navigable quickfix items: we can navigate through the quickfix items (thereby browsing the source code), and the assembly is in the quickfix window as context.
If you're interested in the code, put a breakpoint and launch with a debugger. In Visual C++ that literally two keypresses, F9 and F5. As a nice side effect, you can step over the assembly instructions observing how they change registers and memory.
Who cares about the payoff? Startups will still pay you a good enough salary, and if they don't why would you even consider working there? It's not like startups don't pay a salary at all.
And if a startup does pay well, why is it risky to join? Worst case scenario it folds and goes bankrupt in a year. It's not like there's a shortage of software jobs that you'll be unemployed for a long time. Also, for people who want to become founders in the future, joining a startup is their best option to learn about how businesses are built and what mistakes to avoid in building said businesses.
So not everyone is joining startups just for the payoff or to make it big. People are way more realistic than that.
Html was literally invented for sharing academic research. The fact that it can also be used for shopping, banking and showing your friends your holiday slides is an happy accident.
http://www.jagregory.com/abrash-black-book/