User loginNavigation |
LtU ForumSeeking succnict thoughts on pros/cons of hl language stylesAssuming one can choose among: Imperative, Functional, Object-Oriented, Declarative styles (or anything else important I've missed, including sub-categories thereof e.g. is Relational a sub-category of Declarative?) of programming language, what are the pros and cons of each? Yes, I have my copy of CTM, and I'm making my way through it, but I'm hoping to find/make a list that is more succinct. :-) I'd break that down into 3 perspectives: the theoretical; the pragmatic; and the current state-of-the-art. (E.g. "Theoretically, Haskell should be able to do XYZ, but the current compiler + runtime doesn't, although a first take on it is slated for 6.13.") The main thing I'm trying to do is get a feeling / mental model for whatever "iron triangle/polygon" there is among the pros-cons of language style at a high level. A small example of a factoid in this realm: OO vs. FP: OO pro is adding a new data type, con is adding a new method, whereas FP's pro is adding a new function, and the con is adding a new data type. thank you and yes i will try to re-dig-in to CTM. Functional Programming ProjectHi, I am TAing an undergraduate course on Programming Languages and the instructor has asked me to conduct my discussion on functional programming. The students would also be required to implement a project using a functional language (Erlang). I am looking for ideas about what the project should be. The timeline for the project is 5 weeks. I have come up wih the following two and welcome any critical remarks about these ideas: 1. Mapreduce - Implementation of mapreduce and then an application based on mapreduce. I thought it would be interesting to ask the students to do a sequential implementation and then parallelize and then compare the results. I would be really glad if I could get some ideas/comments. Thanks Subsumption at all costsGilad Bracha gives a pretty compelling argument with good examples on why we should favor subsumption over other things (ADT/inheritance) in "Subsuming Packages and other Stories". Onward!As conferences get older, they tend to require a greater burden of proof. Program committees reject papers as "too early", and want more demonstrations that the ideas are sound. This is why conferences tend to lose the excitement of the early days. Onward! is a conference that focuses on innovative ideas about software. The program committee is looking for ideas that, if they succeed, will make a big impact. Though the committee has to be convinced that the idea is reasonable, it is less concerned with proof than other program committees. Essays and full papers are due April 20, and short papers are due June 26. Onward! is also looking for workshop proposals and films. See http://www.onward-conference.org/ Essays are an unusual and noteworthy part of Onward! An Onward! essay is a thoughtful reflection about some aspect of sofftware technology. Its goal is to help the reader to share a new insight, engage with an argument, or wrestle with a dilemma. Some of the essays that have appeared at Onward! are
Although Onward! was originally a part of OOPSLA, and is being colocated with it this year, you can see from these papers that it is not restricted to object-oriented programming, or even programming languages. However, it gives a welcome reception to new ideas in programming languages, so if you have something new that you'd like to promote, I urge you to consider submitting it to Onward! Haskell's type classes and CafeOBJ's module systemIf I am addressing the wrong forum, then apologies in advance. Question 1: Question 2: Question 3: Question 4: What are the strengths, weakness of Haskell type classes and CafeOBJ's modules for specifying systems? (as opposed to programming) Regards, By Patrick Browne at 2009-03-26 00:41 | LtU Forum | login or register to post comments | other blogs | 6439 reads
Eliminating fuzziness of access modifiersFor a while I am puzzled by the unsuitability of I've summarized my thoughts in Clarity of Access Modifiers essay and I'd like to bring it to attention of LtU readers as I am sure some of you will know the reason why we have these fuzzy modifiers. Also some of you may know about languages that offer better alternatives with more clarity. I am looking forward to hear your opinion. Feel free to comment here or at the page's discussion tab. Automatic data structure / layout selection?I'm looking for any research on compilers which automatically select different data layouts or structures in order to improve efficiency. For example, changing an array of structures to a structure of arrays to make it easier to use vector operations. However I don't just mean selecting one data layout and using it throughout the program but converting between different layouts at appropriate points such as a sequence which could be implemented as a linked list or an array depending on which operations were being performed on it. I also wonder if something like this could be integrated with a copying garbage collector. Tiered approaches to higher order programming?I am looking for examples of what I call a "tiered" approach to higher order programming. At the base, you'd have objects (numbers, strings, etc). Above that, you'd have functions which map objects to objects. At the top, you'd have functionals which map functions to functions. Neither functions nor functionals would be first class objects, nor could you pass a function to a function or a functional to a functional. My thinking is that this approach would offer most of the benefits of the typical higher order approach while making reasoning easier. For example, certain forms of type inference become practical that would be undecidable in a language with first class functions. Does any language like this currently exist? Backus's FP is similar but it does not allow the definition of new functionals. FL lifts this restriction but adds first class functions. I'm looking for something in the middle. To put it another way, I'm looking for a higher order language like Lisp or ML but with the restriction that functions can only be constructed and passed statically. Edit: I should note that because all functions provided to functionals are statically known, programs in such a language would be trivially reducible to first order programs. The 'functionals' would be acting very much like glorified macros. J. Schwartz diedI learned just today that Jacob Schwartz, a mathematician and computer scientist, has died on March 2. He was the designer of SETL. Here is an obituary. Parrot 1.0.0 is outAfter a few years in the works, Parrot VM v1.0.0 was finally released a few days ago.
By vieiro at 2009-03-19 07:22 | LtU Forum | login or register to post comments | other blogs | 4892 reads
|
Browse archives
Active forum topics |
Recent comments
9 weeks 6 hours ago
9 weeks 13 hours ago
9 weeks 1 day ago
9 weeks 1 day ago
9 weeks 4 days ago
9 weeks 4 days ago
9 weeks 6 days ago
9 weeks 6 days ago
9 weeks 6 days ago
9 weeks 6 days ago