LtU Forum

Seeking succnict thoughts on pros/cons of hl language styles

Assuming 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 Project

Hi,

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.
2. Purely functional data structure - This is based on the thesis of Chris Okasaki http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf . I am considering asking students to implement a variation of queue data structure such as "Hood - Melville real time queues".

I would be really glad if I could get some ideas/comments.

Thanks

Subsumption at all costs

Gilad 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 system

If I am addressing the wrong forum, then apologies in advance.
I wish to compare Haskell's type classes with CafeOBJ's module system. I realise that these constructs were originally designed to address different issues (ad-hoc polymorphism V system structuring) but they can both be used for constructing specifications. My current understanding is as follows:
In CafeOBJ the module is the basic unit for structuring both specifications and programs.
A module can denote either a theory (loose denotation) in some logic or denote the initial algebra (tight denotation) in some logic(s) (e.g. equational logic or preorder logic). See: http://crab.rutgers.edu/~pjohann/tlca07-rev.pdf
My interpretation is that a loose module in CafeOBJ roughly corresponds to a Haskell class, while a tight module corresponds to a Haskell instance. CafeOBJ modules can be parameterised by other modules whereas Haskell class/instances are parameterised by types. CafeOBJ modules can also import other modules. This importation includes facilities to rename elements (sorts and functions). Importation also allows the user to construct logically valid mappings between elements in the imported module and the importing module. Haskell type classes do not import in this sense, their only structuring mechanisms are parameterisation and inheritance. Importing in Haskell is handled by Haskell's own module system which operates above the type class system.

Question 1:
Is my rough mapping from CafeOBJ modules to Haskell type classes reasonable? Obviously, I am not talking at a very detailed or formal level.

Question 2:
Notwithstanding my current understanding of Haskell set out above, is there any way of 'importing' type classes into type classes or instances into instances.

Question 3:
Lutz Schroder talks about type classes being a 'pre-institution' for polymorphism.
My understanding of his paper is that type classes do not support 'model expansion', because expanded models may have more types. Is this due to the lack of an import facility in Haskell's type classes?
See: http://www.informatik.uni-bremen.de/~lschrode/papers/Summary.ps

Question 4: What are the strengths, weakness of Haskell type classes and CafeOBJ's modules for specifying systems? (as opposed to programming)

Regards,
Patrick Browne

Eliminating fuzziness of access modifiers

For a while I am puzzled by the unsuitability of public and protected - e.g. default access modifiers in many object oriented languages - for design and especially maintenance of APIs. They are so natural in OOP, yet so harmful for anything that needs to be compatible for more than one version that I have to ask: why there are no better alternatives?

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 died

I 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 out

After a few years in the works, Parrot VM v1.0.0 was finally released a few days ago.

Parrot is a virtual machine designed to efficiently compile and execute bytecode for dynamic languages. Parrot currently hosts a variety of language implementations in various stages of completion, including Tcl, Javascript, Ruby, Lua, Scheme, PHP, Python, Perl 6, APL, and a .NET bytecode translator.

XML feed