Note that this enables you to use the bash 'forward search', CTRL+R's forgotten twin.
I use CTRL+R and CTRL+S often in emacs and was frustrated that CTRL+S would not work on a command line terminal. As the article mentions, CTRL+S is typically interpreted as XON. Turning that off will enable forward search.
The biggest impact of the T20 incident referred to here was on EVE-politics rather than CCP's policies.
Context: The T20 incident happened during a three year long galaxy-spanning conflict that erupted which pitted numerous smaller players against a dominant feudal-like political entity. As implied in the article, this war was not about resources or territory, but about ideology: "roleplay and serious business" vs. "we are bad at this, let's have fun". The T20 event was seen by many as evidence of corruption and organisational rot within the "serious business camp", bolstering the opposing camp's numbers and morale significantly.
It should be clear from the article which side has won in the end.
In the post above, tinfoilman is giving a fine example of five year-old political spin of the aforementioned great war. Figuring out which side he was on is left as a trivial exercise to the reader.
Not to mention streetcars as a possible vehicle (no pun intended) for alternative power plants or fuel sources. Some of the arguments against alternatives for the internal combustion engine fall away if you do not have to deal with the needs that consumer cars have.
The thing is that there is already a Lisp that is a viable, modern and competitive language for nontrivial applications. One that has incorporated the institutional knowledge and hindsight of two decades pragmatic programming practices.
I love Scheme as a first-boat language, but dread every new R(+1 N)RS for the inevitable shift towards the rest-boat language design.
SBCL doesn't generate LLVM code. My primary goal was Common Lisp with C++ interoperation. It seemed easier at the time to start from the ECL Common Lisp code base and write a new C++ core and a Common Lisp interpreter that always interoperated with C++. As I wrote the compiler and expanded the system I maintained C++ interoperation all the time. There were a hundred problems that I had to discover and solve along the way to maintain a Common Lisp that interoperated with C++. You can get some level of interoperation between ECL and C++ up in a weekend but it won't work with C++ exceptions and RAII and there are dozens of other problems. In retrospect I don't think I would have gotten here starting from ECL because I never really understood the ECL code.
Yes, the Memory Pool System by Ravenbrook (https://www.ravenbrook.com/project/mps/) is a proper, moving garbage collector. It uses precise GC on the heap and conservative GC on the stack, as does the garbage collector in Steel Bank Common Lisp on x86 chips. I need it because I need my code to run on 100,000 CPU supercomputers with a controlled memory footprint to develop organic nano machines (seriously).
To be honest I was just kind of thinking "oh great another language implementation," before I read what you're actually doing and why you needed to create clasp. I appreciate the difficulty of writing precisely GC'd C/C++. It's pretty awesome that you were able to use clang to (I assume this is mainly what the analyzer does) track roots in C & C++ code.
Thanks - yes the analyzer tracks roots through about 300 C++ classes. It also finds global variables and builds C++ code to interface with the MPS library. I exposed the Clang libraries to search the AST and describe the AST in Common Lisp and then wrote the static analyzer in Lisp. I shudder at the thought of doing this all in C++ and I write a lot of complicated stuff like Common Lisp implementations in C++ :-). Common Lisp is the language of trees and pattern recognition. Common Lisp is the perfect tool for this job.
I would like to point out that there are classes of laziness. Haskell's laziness guarantees that an expression will not be evaluated if it is not used. e.g. take_first(42, 42/0) will not return an error. This enables you to construct infinite lists of primes and such.
Some classes of functional languages had lenient evaluation, evaluation is still lazy, but all expressions will be evaluated at some point in the program. You cannot do the infinity tricks, but you can still write the nice recursive functions, those that are used to show off the benefit of laziness.
The Haskell type of laziness bites you in the ass when trying to do parallel evaluation, which is why you need the rpar/rseq constructs to avoid opening the nasty trapdoors that regular evaluation will not hit.
Even besides I/O and parallelism the laziness can bite you. Mainly, it can make it hard to predict memory/processing use, unless you are intimately acquainted with the innards of Haskell.