Search This Blog

Loading...

Tuesday, September 17, 2013

Haskell: From unicode friendly to unicode embracing

Doesn't λ x ⦁ x  :  α → α look better and communicate more clearly than \ a -> a :: a -> a  ?

What are the problems with the second (current Haskell) form?
  1. The a in the value world is the same as the a in the type world -- a minor nuisance and avoidable -- one can use different names
  2. λ looks like \
  3. The purely syntactic -> that separates a lambda-variable and its body is the same token that denotes a deep semantic concept -- the function space constructor
APL was one of the oldest programming language and is still one of the most visually striking.  It did not succeed because of various reasons, most notable of which is that it was at its heyday too long before unicode.

While APL is the first in using mathematical notation in programming, Squiggol, Bananas and Agda are more recent precedents in this direction.

In short, its time for programming languages to move from unicode-friendly to unicode-embracing

Some stray thoughts incorporating these ideas into Haskell.

Tuesday, September 10, 2013

Computer Science: Technology or Philosophy?

A computer is like a violin. You can imagine a novice trying first a phonograph and then a violin. The latter, he says, sounds terrible. That is the argument we have heard from our humanists and most of our computer scientists. Computer programs are good, they say, for particular purposes, but they aren't flexible. Neither is a violin, or a typewriter, until you learn how to use it.
Marvin Minsky – Programming clarifies poorly-understood and sloppily-formulated Ideas

Computer science is not a science and it has little to do with computers. Its a revolution in the way we think and in the way we express what we think. The essence of this change is procedural epistemology — the study of the structure of knowledge from an imperative point of view, as opposed to the declarative point of view taken by math.
Mathematics provides a framework for dealing precisely with notions of «what is»
Computation provides a framework for dealing precisely with notions of «how to»

Abelson and Sussman — Structure and Interpretation of Computer Programs

Computer Science is no more about computers than astronomy is about telescopes, biology is about microscopes or chemistry is about beakers and test tubes.
There is an essential unity of mathematics and computer science.

Michael Fellows — usually attributed to Dijkstra


The above three quotes are interesting as much in their agreement – the irrelevance of computers to computer-science – as in the difference of emphasis: Minsky sees CS from the intelligence/learning pov, Fellows/Dijkstra as math, Abelson/Sussman as something contrasting to math…

So what actually is CS about??

Following is an article I wrote for a newspaper in 1995 on the wider-than-mere-technology significance of CS — reposting here for historical interest.

Monday, September 9, 2013

The Poorest Computer Users are Programmers

In the old days programmers programmed computers. Period.

Nowadays when everything is a computer, and the traditional computer is about a decade and half behind the curve, describing a programmer as someone who programs computers is narrow and inaccurate. Instead we should think of programmers as working at effecting and improving the human-X interface, where X may be 'computer'. But it could also be IT, or technology or the network and through that last, interaction with other humans.

Now the classic 'nerdy' programmer was (by stereotype) always poor at 'soft' questions like that:  Interaction? Synergy?! What's all that manager-PR talk to do with programming?

And so today…

Programmers are inept as users of computers

Some examples:

Tuesday, August 27, 2013

Apply-ing SI on SICP

Abelson and Sussman wrote a legendary book: SICP. SICP cover The book has a famous wizard cover. Unfortunately the cover misses some key content of the book.  What is it?

If we remove the other wizardly stuff, three main artifacts stand out on that cover:  eval and apply on the crystal ball and a magical λ.  Lets put these into a table

apply eval
lambda

The fourth empty square seems to stand out, doesn't it?  Lets dig a little into this square.

Sunday, June 23, 2013

Functional Programming invades the Mainstream

Kewl-kids in love with their favorite language will often bring up how wonderful is some non-trivial app written in their language.

Kewl, Kewt, Ardent… And the producer of yawns…

So sometimes it is good to invert the perspective and ask about cross-fertilization:  What ideas/features of these fashionable languages are becoming compelling enough to enter the mainstream?

This post is about how the boring mainstream is giving in – feature-by-feature – to Functional Programming
  • Almost every modern language supports garbage collection. Origin Lisp
  • From that followed the fact that any value not just scalars can be first-class.
  • As widely disparate systems as Python, R, Groovy, VBA, Mathematica share a common idea – using the interpreter interactively as an exploratory tool. Started with Lisp's REPL.

Wednesday, May 1, 2013

Friday, April 26, 2013

Functional Programming Scratchbook

Concepts of FP – Mindmap

Please note this is a scratchbook, ie Work-in-progress
Lambda MindMap
A mind map of how to approach the concepts of FP

Saturday, February 2, 2013

C in Education and Software Engineering – Retrospective

Its more than 20 years ago that I wrote C in Edu and SE[1]  I had mostly forgotten about it until I saw Mahesh's review. So thanks Mahesh for your kind words.  The trouble is I dont exactly agree with myself from 22 years ago ;-)  You see even in 1991 what I was saying was that C is a stupid language to teach programming with – education – unlike say C++ which is a stupid language – period.

IOW what I was trying to say back then was that if learning to program is the goal, then a path that goes through C-land is going through bad-lands.  In short an argument not against C but against an ill-conceived learning-curve.

What has changed now?

Thursday, November 1, 2012

Imperative Programming: Lessons not learnt

We like to believe that Computer Science (or Information Technology) has advanced and keeps on advancing.

But has it?
What was called programming 60 years ago would today be called Imperative programming.  And it remains the mainstream (but see 7. below).

In short our field has a definite resistance to learning from our past.

A few examples will illustrate:

Thursday, October 18, 2012

Layout Imperative in Functional Programming

How long should program lines be?

But wait! Is this question even meaningful without specifying which programming language?

Monday, October 8, 2012

Functional Programming – the lost booty

Lisp was conceived in 1958 and already implemented by the early 60s.  One of its strange features was something called 'garbage-collection' … which took 35 years to enter the mainstream in Java.

Which is to say that for 35 years:
  • CS researchers did whatever they were doing for their tenure, (sorry) publications
  • Programming teachers righteously beat their students on their knuckles for getting pointer-errors/core-dumps/segfaults etc… 

Saturday, August 4, 2012

Functional Programming – Philosophical Difficulties

All the currently competing programming paradigms have serious philosophical problems.
FP probably less than the others but it too has its little share, which I deal with here.

Equality

Haskell programs look beautiful. You just write equations and everything magically just works. What could be a prettier dance between declaration (equations) and imperation (works)?

However the equations of Haskell hide a fundamental problem – equality is undecidable in general. Lets look at this from different angles.

Saturday, July 28, 2012

We dont need no Ooooo-Orientation – 4

The Grandeur of The Absolute

From the time – probably millenia ago – when humans first learnt to think ahead of their animal neighbours, we've been able to make certain statements that (presumably) animals can never conceive – abstract generalities.

So for example, a baby calf can recognize its mother cow with a greater unerring precision than a human baby's, yet when the human baby grows up, it can make distinctions out of the reach of our bovine brethren: eg
  • my mother vs motherhood
  • motherhood vs love
  • cheap love poetry vs hi-class love poetry
  • etc
In short, humans are very comfortable

dealing with abstractions as though they were concrete.


Now I have a conjecture, viz. that grand generalities have some hormonal trigger for making us feel elated (a grande-generality-pheromone maybe?) so that statements like
  1. Nothing in the universe can go faster than the speed of light
  2. Every pair of bodies in the universe attract each other according to a trivial-to-state mathematical law irrespective of their distance or relative size
  3. Anything that can be computed by any computer whatever (invented or yet to be invented) can be computed by a Turing machine
create a certain tickling feel-good that a 'normal' (non-general) statement like say: My tea has less sugar does not produce.

Friday, July 27, 2012

We dont need no Ooooo-Orientation – 3

In my earlier posts Ive discussed some context around why OO has been one of the more dismal failures in the history of IT/CS.
Here I talk of the error in thinking 'inheritance'.
And this gives the philosophical separation between those drawn to OOP and those not.

Before I come to the meat of the matter – why OO sucks – it would be good in all fairness, to deal with the

Very few successes of OOP

Tuesday, July 24, 2012

Linux and the cloud

With the current buzz (hype?) about cloud-computing it is natural that there will be nay-sayers.
How many people realize that cloud is old wine in new bottles? Here's rms raving against clouds:
The interesting thing about cloud computing is that we've redefined cloud computing to include everything that we already do. The computer industry is the only industry that is more fashion-driven than women's fashion. Maybe I'm an idiot, but I have no idea what anyone is talking about. What is it? It's complete gibberish.
And so are many others

Tim O'Reilly's views in this matter are more nuanced and interesting. His original seminal paper Paradigm Shift. Summed up in slightly more modern language Hw Sw Infoware
The market, in is no longer for software, open source or proprietary. Tomorrow's market is all about data.
from Wrong question
And yet it seems to me that both the yea and the nay sayers miss an important point, viz. that debian's apt has been a cloud service before cloud had become a buzzword

Here's a transcript of something I recently posted on python list.  The context is a question about why it is hard to write to /etc.

Modern linuxes are SOAs (service oriented architectures) or cloud architectures even if we dont like the buzzwords.

This means that when I install debian/ubuntu on my personal computer there is some kind of contract-ing that goes on between me and debian.  Some of it legal, some semi-legal some entirely informal/conventional but still very important.

Legal:
For example it may be 'my very own computer' but if I take sources under a certain license and use them in violation of that license I could get into legal trouble.

Semi-legal:
Free and not-free software can coexist in ways that are at least legally nebulous

Conventional:
Debian must not use the machine (and file-system in particular) in
ways that disrespect me.
Note I am not talking of obvious legal gaffes like stealing my private data but of more 'conventional' problems like strewing my home directory with meaningless temporary files.

Likewise:
I must respect Debian's area.
For example I cant go messing about in /usr/bin [the name 'usr' is misleading and unfortunate] and expect support from debian.
So
$ sudo rm /usr/bin/foo
is improper whereas
$ sudo apt-get purge foo
is proper.

And its improper because you are not to mess around in debian's area – except for officially approved channels like apt-get purge… just as debian is not to mess around in yours.

And writing into /etc constitutes messing with debian (or whatever is your distro).

So yes, as earlier suggested read the FHS.

And consider using a 'public-messable' area like /usr/local instead
of /etc.

Actually the situation is more complicated: the deal is not between
just ordinary users like you/me and the distro. There's
- ordinary users like you/me
- packagers
- the distro
- upstream

each with their own rights and responsibilities.
What these are and how to navigate them is best discussed in your
distro's fora eg
http://forums.debian.net/
http://ubuntuforums.org/forum.php


And further in response to

Denis McMahon
If you don't have root access, you probably shouldn't be trying to write in /etc. If you need to write in /etc, explain to the sysadmin why you need root access.
The OP is evidently working on a macbook pro.
From which I infer its his own personal notebook.
So explain to the sysadmin amounts to explain to oneself!!

40 years ago, on the first Unices, with machines millions of times weaker and costlier than today, 'sysadmin' and 'normal user' were usually different. Today they are usually the same.

So we old Unix-heads need to change our explanations from explain to the sysadmin to change hat from normal-user to superuser.  And then why simplifying life by having only one hat –
$ sudo bash # and do everything there
is not such a good idea!

To the OP:
One thing that has not changed in 40 (or rather 60) years is the concept of

Binding Times

eg C programmers cannot get off the ground if they do not distinguish
compile-time from run-time.

In the current context, it is probably good to distinguish system-administering time from system-use time.  So as sysadmin, you can pretty much do as you please (though remember my comments earlier on respecting your distro's space), make a directory under /etc, chmod, chown, chgrp it to your taste, so that the (group of) ordinary users can write into it.

And then in normal user mode you should be able to write to it.

However... as I said above it may be preferable to use /usr/local (for programs) or /var (for data) rather than mess in /etc. [Think of /etc as windows' registry – not the ideal mucking-ground!]  And study the FHS to make the right choice.

And finally, if you are the only guy involved, why are you not doing everything under $HOME?