Goo fun in the new office

Brothel for sale!

Sydney has a (large) number of brothels. Normally one may not be aware of them, but here is one. I haven't seen the sign before, I'm on my way to meditation. Ill be late, but I do have something to meditate on. Yes. Ill be late because I'm eating at the bar nextdoors. Thanks for asking.

It's gay over there...

Now is the parade of the Sydney Mardi Gras. From the street its difficult to see. Here they do it during the evening. I'm in my apartment as is the picture. When I went up to my apartmen there was a line to my building. Ppl lining up to go to friends parties. Wow.

In any case. I've recently spent some time thinking about how poorly all (commonly used) programming languages scale. Scale as in: number of ppl on a project, difficulties in actually using them and getting things done, massiveness of the amount of code, and interactiveness during developement.

I always liked lisp. But I never really use it unless there some interesting combinatorical (symbolic) problem to solve, or a hard algorithm to implement. I use it to verify proof of concept. But there is no lisp I like. Scheme is too limited in that it encourages, and make it too fun to use closures a lot. Roll yout own OO in a minute.

So what am I really looking for? I believe in few simple concepts. Generality. Dataflow thinking. Functionalish. Messaging. Declarative as in sql not as in functional languages.

I may be getting old and forgetful. But I could never keep name of things and ppl in my mind. The fewer named elements there is in the code, i.e., less boilerplate, the easier to use. You can do everything in java, but why would you?  Ever implented a filtering iterator? Are you sure you got it right? Lambda as un anonymous functions is nice. For loops are mostly boilerplate. Mostly not stating intention as it guarantees an order of processing. Even when not needed. Types could help here to glue reauirements together. Most languages will sort an already sorted list. Silly. A list should/could know what it is sorted on and make short a noop. Ah we need programmers to specify more strict types you say. I don't agree. I agree that every value has a type. Variables can be limited to a type too. But that is a constraint. I think a compiler and optimizer and list construction operators could figure it out. Usually order is inherited. This is ordered because of that. Could a compiler figure out that the result of a sort implementation returns data in a certtain order? Think about it!

Loops is another issue. We spend an awful lots of code on explicit looping. Looping over data. Why aren't our languages  more data centric in their implementation than operation centric? It comes from ppl being more facinated with the operations than the purpose of the computation. There is two major languages that are data centric and therefor quite efficient for large data sets. Can you guess? SQL and APL. Yup. Actually, perl is there too. Not as most ppl are using it. Perl is only efficient if you can solve your problem in a single regular expression, s/ something / expression / ge.

Perl is very controverisal among serious programmers. It does one interesting thing in that it may make you think about your problem in terms of extraction, tranformation and reduction. Ever heard about maprduce? Its also data centric. But very limited. But any large problem can in principle be implemented as a series of mapreduces! Possible not the most efficient. But doable.

Back to data. Looping. Consider sql, apl, regexp, mapreduce etc. All of them implicitly process a lot of data elements without in most cases needing to use an explicit looping construct!

Did you know that a supercomputing fortran is very advanced in that it spends most of it resources in trying to figure out the data flow and their depenencies in order to unroll loops and parallellize them? Essentially you could say that it builds a functional lisp program making the dataflow explicitly visible. Any computation that doesn't depend on another one or even its own can be run in parallell on massive amounts of data. Even summation using sum += x; can be easily parallellized as it understands that [in most cases] its communitative. You can easily apply divide and conquer and the sum up the subresults. Now. The compiler figures that out. Why don't most other languages know this about operators?

I once got an interview question.
- Divide a very large integer number w a single digit number.
- What language?
- Any.
- (/ large digit)
- really?
- yes, most lisps have infinite precision integers.
- ok. Fine. What if you need to do it in C?
...
Ill spare you the fun of that code. Feel free to send me your solution. The funny part of this is that that problem is quite efficient to solve in lisp. And why is that? Because it has "scalable arithmetic".

So as a conclusion to these thoughts I'll make a pot of tea.

Then later when the big roar of the crowd is over I may enjoy wandering a bit in the warm night.

Happy Mardi Gras!