User loginNavigation |
LtU ForumAbstractions considered harmful?
Note: Ah, sorry to see this is perhaps belabouring the point (although I hope it is a slightly different facet of abstractions). News: The wiki has started. Please contribute. What is Intuitive?[$0.02 in the category of 'perhaps we can get past the silly holy wars and into interesting ones'] I've seen it come up a few times in discussions: the claim that something is more intuitive than something else. I have a passing interest in usability, UI, and visualization, so the term 'intuitive' is something I come across a lot. I think Jef Raskin had it right: it is not an absolute, it heavily depends on individual experience. Thus, this is a request for folks to avoid getting sucked into the 'is too' 'is not'. You have to say 'to whom' and 'when' and 'under what circumstances'. For PL evangelists, I think this is good to keep in mind. Logix: Multi-Language ProgrammingI just came across Logix, which appears to be a language for building (and freely intermixing) DSLs. It is similar to Lisp in many ways (a point the website makes several times), but with a substantially different syntax, and an approach based more on objects than lists. From the website: Logix is more than a programming language. It is multi-language programming system. With Logix, each part of your program can be developed in a language that is finely tuned to the task.The "60 second intro" provides a couple of brief examples of the way syntax enxtension works. There is also a more extensive tutorial that discusses the base Logix language (which is somewhat like Python), as well as providing more detail on how to extend the language. Logix as presently implemented generates Python byte-code, but the designers are investigating other platforms (Mono, Parrot, LLVM). mondo bizarroc-jump looks harmful to children. Time for a Scheme board game? I think I've found a good name for it. Ruby: Language of the Programming Übermensch?I spent a couple of hours this evening writing my first real Ruby code for the Lexical Semantics course I am taking this fall. It's excellent. The syntax is very appealing. Tokens are strangely verbose, replacing "{" and "}" of C descent with "def" or (insert block starting token here) and "end". For the first 30 seconds after encountering this on page 1, I wasn't sure how I felt about it. It seemed verbose. But now I see that "end" is much easier to type than "}", whose presence in Java forces me to reach and twist for basic program vocabulary. Maybe it would be different if I weren't on Dvorak, but words as delimiters rather than punctuation is a definite win. And while the tokens are fat—in a good way—they are also few. The syntax is remarkably terse, but not at the peril of clarity as I feel is the case with Perl. Ruby makes me understand the power of judicious syntactic support for common tasks. String interpolation is an obvious and immediately addictive feature. Built-in regular expression literals are also a plus. And there is an elegant interplay between these syntactic features on both a functional and visual level. As syntax is concerned, Scheme has represented a year-long exile in the wilderness. The bare minimalism of S-expressions was good for me. Scheme's uniform and parsimonious syntax let me focus on concepts that are fundamental to high-level programming: recursion, higher order procedures, and data abstraction. Scheme taught me by giving me only a handful of powerful tools and then training me to use them well. Now I think that Ruby can empower me by equipping that sharpened outlook with richer facilities for the completion of common tasks. Its assumptions are friendly to my most cherished and hard-won programming intuition, but they also cater to the harsh realities of programming in an imperative world. Paul Graham says that languages are evolving ever-closer to Lisp, and he asks, why not skip directly to it? And I think that I finally have an answer. Perhaps the ideal programming experience is purely functional, and the mainstream's gradual adoption of features pioneered by functional languages reflects this truth. But there are other truths. Tim O'Reilly presents another point. He says that as new computing paradigms emerge, new languages seem to rise with them, suggesting that from a pragmatic standpoint, a language's "goodness" is sensitively dependent on the world in which it is used and with which it must interact. Every time I have programmed functionally for practical applications, I am keenly aware of how imperative the world outside my program really is. The operating system doesn't behave functionally, and I/O operations certainly never could. There has to be a reason why these languages are so popular, beyond the simple fact that they are easier to learn for programmers whose first language was C. My conclusion is this. In the real world of computing, one finds explicit notions of state; one finds assignment. The computing hyperscape is not (yet, perhaps) very functional. State-oriented computational objects seem a natural complement to our false intuition of objects existing in the real world as well. Nietzsche would say that there are no objects, and, indeed, there aren't even any facts. There is only "will to power". Sounds remarkably similar to me trying to explain to C programmers that there is no data, and there isn't, in fact, any need for assignment. There is only Lambda. I think Nietzsche is right and I think Steele and Sussman were right, but that truth does not mean that the illusion of objects is an utterly worthless one. If we actually cognized the outside world as consisting only of "will to power" rather than tables and chairs and people, we'd never get anything done. And perhaps, similarly, when we pretend that everything is a Lambda, we face similar difficulties in interfacing this remarkably beautiful, completely true notion with an ability to do anything about it. These ideas, are, I guess, nothing new. Haskell's monad system, from the cursory understanding I have of it, is a formalization of them, a clean interface between the rough and tumble outside universe and the sublime purity of Haskellspace. But if I'm not going to use an airlock, maybe a clever, elegant, and even artistic bridge between functional wisdom and imperative truth will suffice. For now, Ruby seems to be a pretty decent attempt. Lambda may be vulgarized into a quirky codeblock, but in a language in which shell commands are syntactically supported, at least it exists. Categories for Software Engineering - recommend?Have any of our mathematically inclined readers browsed Categories for Software Engineering and would they recommend it to a not-so-theoretical software developer? By Isaac Gouy at 2005-09-22 01:16 | LtU Forum | login or register to post comments | other blogs | 7813 reads
Table Oriented ProgrammingI have written an article on in which i was able to write a domain specific language using SQL when the database is modelled using "Table Oriented Programming" techniques.You can find the article here.One notable advantage of this technique is that we do not have to write seperate parser/grammar to get a DSL,we just use TOP and SQL syntax. I am not a TOP fanatic(ala TopMind), but have found the technique pretty useful at work which prompted me to write this article. Also note that this article was intended to be published in a magazine for general developers, so the terminology is a little loose. However Corrections, flames and opinions are always welcome. Live update of source with inferred type?(A pie-in-the-sky wish.) Personally, I love automatic type inference and generics a la ML, Haskell etc. I wish such systems would go one step further and offer an optional means of annotating the code I'm writing after the type inference happens; that way when reading code for the first time one would get the benefit of knowing what things are when they are first introduced, without having to divine it from how they are then used. I do not know of anything that does this, but would love to hear if there is such a system (or if there are evil Emacs hack ideas along such lines). Dynamic vs. Static Typing - A Pattern-Based Analysis
In some cases, static typing is more error-prone than dynamic typing. Some statically typed languages force you to manually emulate dynamic typing in order to do "The Right Thing".
The writer takes on Java. He mentions three problems:
SeaFunc meets Tues. Sept. 27thSeaFunc is Seattle. SeaFunc is functional. Functional language. The Mothership lands at 8 pm on Tuesday, Sep. 27th at: Ruby Restaurant Ruby's is in the U. District on "The Ave," near 43rd St. Good, To receive timely meeting announcements by e-mail, including where we For the uninitiated: "Functional Programming" (FP) treats computation The merits of the FP approach are highly debateable. Much more clear, "Make my func the SeaFunc, I wants to get funked up." - Parliament |
Browse archives
Active forum topics
|
Recent comments
11 weeks 17 hours ago
15 weeks 2 days ago
16 weeks 6 days ago
16 weeks 6 days ago
19 weeks 4 days ago
24 weeks 2 days ago
24 weeks 2 days ago
24 weeks 5 days ago
24 weeks 5 days ago
27 weeks 3 days ago