Alternatively, the people who wax lyrical for 60 or so pages don't understand much either, and are compelled to pad out their document.
I remember seeing this a while ago, but I didn't pay much attention to it then, because punishing those who understand the problems with a lengthy verbose soliloquy isn't a good strategy for disseminating information.
:-)
The other problem is that something 60 pages long without any references or citations beyond an occasional casual link to wikipedia, smacks of reinventing the wheel. This would be why he can go for 60 pages without mentioning known terms like "Cybil Attack", or "Onion Routing".
This white paper smells more of bikeshedding - there was no code and right at the bottom of the document, you can see the caveat & apology "This white paper is in no way a complete protocol specification, far from it actually. Its main goal is rather to provide suggestions for solutions for several typical problems [...] which could hopefully work as some kind of reference point for any discussions that may be inspired by it."
I think my favourite part of the paper is where he handwaves PKI & Voting atop of a DHT to 'solve' lots of problems, without realising those are the genuinely hard problems people are still working on.
A close runner-up is in the slides he talks about "no central point of failure" and then explains his "Manual Override Command Support", which is a central point of abuse.
It is nice to see that someone is finally writing code for it, and I wish them luck working out all of the details left out in the paper, especially the organisation and management of addresses.
Because depression doesn't work that way. It isn't a general feeling of malaise, it's somewhat a lack of positive value on everything (ish).
It is a lack of momentum and a heavy inertia to stay miserable and avoid change. It becomes a sunk cost where it's almost impossible to change something small in your life, let alone something big or huge.
Your advice is naive, and tantamount to asking "Have you thought about not being depressed, I hear that could work". If it were as simple as thinking your way of depression, it wouldn't be such a problem.
The best advice I've ever encountered is to take care of the little things, like sleeping on time, remembering to eat every day, doing laundry and getting out of the house. These are often the first things to go and often the hardest to get back into the routine of doing. Once you can manage a day at a time, it's easier to start to try managing a week at a time.
Large changes won't matter if you can't take care of the smaller things in life that support you. Depression isn't one of those things you can snap out of, but one that you can gradually work yourself out of.
i've found smaller companies are much more tolerant & flexible with nutters (like me).
there seems to be more focus on results than politics. in larger places I've felt more pressure not to rock the boat, and produce the illusion of work, rather than actually delivering things on time. it doesn't seem to matter if you actually do anything as long as you look like you're not doing /nothing/.
and I don't mean a startup. even startups can grow into kafkaesque nightmares because it's the only way they've ever thought to run a company. really, you have to be in a small, autonomous group if you want to get away with not being that normal.
the moral is: being a startup in and of itself is no guarantee of tolerance for off kilter people, the people and culture within the company are important. there is a correlation between small companies/startups and tolerance, but it isn't causation.
prolog is an interesting take on programming and by comparison, the style in which you write code is still significantly different to approaches in other languages.
sadly, most people when taught barely get past the 'parents and grandfathers' stage of programming.
why not something else? sure! erlang is actually pretty neat (otp is golden) and was originally implemented in prolog. why not learn a term re-writing language? what about snobol?
why prolog? well,
prolog for me has just been one of the most fun and interesting experiences I have had while programming. good prolog code is elegant in a way i've never seen in other languages and it's a big rush when you crack the puzzle of expressing your problem.
prolog was also used in ibm's watson and shipped as part of nt too :-)
''' The printed book contains only the about 400 literature references that are referred to in the book itself, all of them with annotations. The complete list of literature references comprises about 1700 entries of which around 1100 are annotated. It can be found here. It consists of augmented versions of the Table of Contents, Chapter 18, the Authors' Index, and the Subject Index, each reflecting in its way the added entries. '''
If you want that sort of succinctness, it is already covered in many compiler text books.
This is to complement the existing literature with a broad and deep coverage of parsing in specific. There is most to parsing than just the front end of a compiler :-)
ambiguity is useful for error recovery/error detection. also, some languages have ambiguity in their syntax (ML). I don't buy the 'optimization' argument. there is no reason we cannot have our cake and eat it - ambiguity and incremental parsing.
I think parser-generators are unpopular because people would prefer to just write code, rather than compile something else to automatically generated code that is nigh on unreadable.
I think the popularity of regexes is due in part to the ease of which they can be embedded or used within the host language - either with syntactic sugar, or simply as a library.
combinators (parsec especially) hit a sweet spot of being able to write code that handles parsing succinctly, without having to conflate your build or auto-generate source.
i'd really prefer a library I can load and manipulate the grammar from, over yet another syntax and compiler in my tool chain.
(ps. (i'm saddened by the lack of left recursion support in gazelle))
regular expressions (ala cs) are equiv to finite state machines. regular expressions can't count or match ()'s. ragel allows you to mix in code within the state machine, so it is actually far, far more powerful than a finite state machine.
in http, handling things like 'Content-Length: %d' and then reading a subsequent length is a little harder. as is handling transfer-chunked encoding. http is quite fiendish in places :-)
these are 'data dependent' - the parse stream contains information (i.e length) on the subsequent tokens - although some regexps have back references, these aren't common place in parsing tools/formalisms like LR,LL,LALR,CFG or PEGs.
my point is simply that a lot of the parsing drama of late has revolved around the simple task of parsing a language, rather than parsing network protocols.
there is a larger class of parsing problems that are still to be tackled.
http://www.cs.toronto.edu/syslab/pubs/demkea_context.ps
The gist is you can structure your interpreter to improve branch prediction by keeping your vm & hardware in similar states.