Programmable Concurrency in a Pure and Lazy Language. Programmable Concurrency in a Pure and Lazy Language, Peng Li's 2008 PhD dissertation, is a bit more implementation focused than is common on LtU.
The paper does touch on a wide range of concurrency mechanisms so it might have value to any language designer considering ways to tackle the concurrency beast. First, this dissertation presents a Haskell solution based on concurrency monads. Unlike most previous work in the field, this approach provides clean interfaces to both multithreaded programming and event-driven programming in the same application, but it also does not require native support of continuations from compilers or runtime systems.
Then, this dissertation investigates for a generic solution to support lightweight concurrency in Haskell, compares several possible concurrency configurations and summarizes the lessons learned. Lazy lexing is fast. BibTeX @INPROCEEDINGS{Chakravarty99lazylexing, author = {Manuel M.T.
Chakravarty}, title = {Lazy Lexing is Fast}, booktitle = {In Aart Middeldorp and Taisuke Sato, editors, Proceedings of the 4th Fuji International Symposium on Functional and Logic Programming, Lecture Notes in Computer Science}, year = {1999}, pages = {68--84}, publisher = {Springer-Verlag}} Bookmark OpenURL Abstract. Founds-FP.pdf (application/pdf Object) Why Functional Programming Matters. Homer, God and Beautiful Code. Homer, God and Beautiful Code There's a new Riley book called 'Beautiful Code'.
It full of, wait for it, code. And the code is supposed to be beautiful. It may well be beautiful. I can't tell. But it does raise the interesting question about beauty. Well perhaps it's in the shortness. Well sadly, it seems only to work for code and things like that. All of which shows how elusive beauty is and how those who seize on one criterion of it, often end up destroying the very thing that they seek to create. Now I believe that this is the wrong question. That doesn't mean that the language in which we write the solution has no impact on whether the code is beautiful or not; it does. Focussing on the nature of the beautiful solution rather than focussing on the code doesn't mean that the question becomes easier. The Monkey and the Bananas Problems and solutions are one-many related. So what is the good solution; the Right Thing? Make it easy for yourself.
Why I Dislike C++ For Large Projects. By Mark Roulo 12-June-2001 My primary complaint against C++ is that the language is so complicated, and has enough booby-traps, that average and above-average programmers have a difficult time writing code without serious bugs. In a large program with raw pointers, the quality of the program will largely be driven by the least talented members of the team. This makes it highly dangerous to select a language that requires all the programmers to be in, say, the top 25% of the talent pool. Given a team with 10 developers (and my projects typically have more like 40-50), this seems to be asking for lots of long term trouble. Things become even more unstable when one considers that the average turnover of software developers in Silicon Valley (where I live and work) is something like 20-25% and that many large projects also use contractors. I have worked on a project with both C++ and Java components (roughly 50% each) that communicate via CORBA.
Hey Language Snobs: Don’t Pinch Pennies. Programming language snobs are penny pinchers.
That’s a tough sentence to write for some that just finished holding a workshop to help people learn Lisp of all languages. Why would I make such a bold, inflammatory statement? (No, not to troll. Most of the criticisms in this article are aimed at myself, based on my own actions over the last few years.) I had an unpleasant realization after listening to two excellent talks that developed this idea planted in my head by Raganwald with this post he quoted a few months ago: “…you can count the number of games written in a purely functional style on one hand.
Programmers Should Trust Their Instincts. People are either cut out to be programmers or they’re not.
How to know, what to do if you’re not, and where to go from there is a huge issue and not the subject of discussion. But one of the signs of a good programmer is good programming instincts. The right instincts can save hours of work and provide creative solutions to even the most difficult problems; and “gut feelings” in programming are not something you should ignore lightly. One of the first thing Computer Science teachers drill into the heads of their students is that it’s important to map everything out beforehand. Design the algorithm. For instance, the other day I sat down to write a simulator for a MIPS datacache, with different replacement policies.
While mulling things over for a minute or two in my head to gather my thoughts, I found myself scribbling three phrases on the PostIt note in front of me: Access times -> FIFO Access times defined by unique tag Reading memory == dequeue item. AIM-453 - Art of the Interpretter.