tsunami
log in
email
password
links
newest items
tag list
syntax reference
tag:time
history
pointed to by
Thoughts on Assumptions and Programming
Java Pros and Cons
add
item name
tags
==Links & Notes - "Levine the Genius Language Designer"[1] - "The Quest for the Holy Programming Language"[2] - "How to Design (Declarative) Programming Languages"[3] - "Growable Language Manifesto"[4] - "Boilerplate code says a lot about a language…"[5] - "I want a programming language that..."[6] (kind of funny) - "Smart language => dumb parser?"[7] - "Programming language theory texts online"[8] - "Intuition is not a valid goal"[9] (well, certain kinds of intuition) - "Cobra .NET language"[10] (some of the syntax, like `0 .. 100`, is nice) - "What does lisp syntax have to do with writing reusable libraries?"[11] - "Keywords, Magic and (E)DSLs"[12] - "A Modest Proposal: C++ Resyntaxed"[13] - "on learning new languages"[14] - "Alarming Development The future of programming"[15] [1]http://www.zafar.se/bkz/Articles/GeniusLanguageDesigner [2]http://blogs.concedere.net/blog/discipline/software+engineering/?permalink=The-Quest-for-the-Holy-Programming-Language.html [3]http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg04323.html [4]http://blog.robjsoftware.org/2007/12/growable-language-manifesto.html [5]http://lispy.wordpress.com/2007/10/01/boilerplate-code-says-a-lot-about-a-language/ [6]http://hcoding.blogspot.com/2007/12/i-want-programming-language-that.html [7]http://glomek.blogspot.com/2007/12/smart-languages-and-dumb-parsers.html [8]http://www.cs.uu.nl/wiki/Techno/ProgrammingLanguageTheoryTextsOnline [9]http://weblog.raganwald.com/2008/01/programming-language-cannot-be-better.html [10]http://cobra-language.com/docs/python/ [11]http://lua-users.org/lists/lua-l/2008-02/msg00247.html [12]http://peripateticaxiom.blogspot.com/2006/04/keywords-magic-and-edsls.html [13]http://www.csse.monash.edu.au/~damian/papers/HTML/ModestProposal.html [14]http://falafel-on-coc.blogspot.com/2008/04/new-languages-considered-wonderful.html [15] From "Too Much Code"[1]: - "Part 1: Programming and the Metaphorical Mind"[2] - Haskell is cool but its code isn't very readable (same with other functional languages) - "Part 2: Languages and the Lesser-Skilled Developer"[3] - Bjarne Stroustrup quotation - politics is a big decision maker in language choice - "The problem is highly skilled developers are often forced to use the languages accessible to their less competent colleagues." - "A language should encourage good code -- but make quick and dirty code possible." - on Ruby and Python: "Inexperienced developers can quickly get code working, and more advanced developers have access to powerful features drawn from the functional world." - "Part 3: Building a Firewall Against Complexity"[4] - it's nice to have abstractions, but we must deal with the "leaky abstractions"[5] - "Every variable added must be tracked with every other variable." - We must either stop building complex software or "build airtight firewalls around complexity." - Haskell builds a firewall with its functions-without-side-effects. - "local impurity, but global purity" - "Can we live without state?" - Erlang's messaging-based model - "Part 4: The Killer App"[6] - We want to eliminate undefined behavior, such as that cause by race conditions. The problem is when such code _succeeds_, hiding the failure mode. [1]http://toomuchcode.blogspot.com/ [2]http://toomuchcode.blogspot.com/2007/02/part-1-programming-and-metaphorical.html [3]http://toomuchcode.blogspot.com/2007/02/part-2-languages-and-lesser-skilled.html [4]http://toomuchcode.blogspot.com/2007/02/building-firewall-against-complexity.html [5]http://www.joelonsoftware.com/articles/LeakyAbstractions.html [6]http://toomuchcode.blogspot.com/2007/02/part-4-killer-app.html Steve Yeggie on "The Next Big Language"[1] (Javascript) Paul Graham on "The Hundred Year Language"[2] From "Bjarne Stroustrup"[3]: "The idea of programming as a semiskilled task, practiced by people with a few months' training, is dangeous. We wouldn't tolerate plumbers or accountants that poorly educrated. We don't have as an aim that architecture (of buildings) and engineering (of bridges and trains) should become more accessible to people with progressively less training. Indeed, one serious problem is that currently, too many software developers are undereducated and undertrained." From "Philip Wadler"[4] (emphasis added): "Instead, experience shows that users will be drawn to a language if it *lets them conveniently do something that otherwise is difficult to achieve*. Like other new technologies, functional languages must seek their killer app." In talking about the "Y combinator"[5], Reginald Braithwaite makes a very insightful comment: "Others have suggested that learning Lisp is beneficial to your programming skills in its own right. That’s one good way to sharpen your saw. But I add to that an important caveat: to obtain the deepest benefit from learning a new language, you must learn to think in the new language, not just learn to translate your favourite programming language syntax and idioms into it." At least, this drove my thoughts into "Sapir-Whorf"[6] territory. In response to: "figure out what you want to say before you figure out how to say it" I had the following thought: "To reconnect the "what" with the "how", I would say that if the two are separated by too many layers of abstraction, the "what" must be reformulated at a lower level of abstraction before the "how" becomes clear." [1]http://steve-yegge.blogspot.com/2007/02/next-big-language.html [2]http://www.paulgraham.com/hundred.html [3]http://www.technologyreview.com/Infotech/17868/page1/ [4]http://citeseer.ist.psu.edu/wadler98why.html [5]http://weblog.raganwald.com/2007/02/but-y-would-i-want-to-do-thing-like.html [6]http://en.wikipedia.org/wiki/Sapir-Whorf_hypothesis ==Key features - code is easy to read - Is this reasonable? Haskell isn't easy to read, at least for beginners. - it must be usable by mediocre developers - this is required for it to become widespread, which is required for most developers to be able to use it in their day jobs - object literal notation, à la [[http://json.org/:JSON]] - named parameters - minimal boiler-plate code - from Too Much Code: has physical metaphors - there must be a plethora of examples _written well_ - functional components - first class functions - complexity must be managed well - namespaces are probably required - how to keep the state-space manageable? - there must be excellent library support with standard interfaces - differences in memory management in C and differences in state management in Haskell are obstacles to this - the .NET and Java platforms offer many libraries if one of their byte codes is used
some permissive license goes here
contact