www.sixfingeredman.net
..................................................
::. .  .   .     .       .          .

programming

I realized why I like programming so much; it's totally abstract, yet instantly verifyable. It's like philosophy, but you can test it. It's impossible to be completely wrong because you can always write a program and see if you're right. Computer Science: Grounded Philosophy.

On the GPL: the trick is to ask, at what point is something provided for the benefit of the user, and at what point is it provided for the benefit of the developer? If an application runs on an OS, then the OS is provided for the benefit of the user to run that application. If the application uses a library, then the library is provided for the benefit of the application to provide functionality. But is the line really clear? In any case, the writer of the code should make it clear whether they are providing a USER service or a DEVELOPER service. In this sense, the LGPL and the GPL correspond to those roughly. (Although they mix some things up based on implementation issues like linking.)

Interconnections can be characterized on three axes; flexibility, complexity, and abstractness. If two programs communicate by passing text messages, this is abstract but probably inflexible. It may or may not be complex, depending on the grammar. In practice these are not orthogonal, but it is possible to construct examples of each extreme. [I'm thinking this whole thing makes no sense, actually.]

The docs say you don't have to understand monads to use the monadic system. I disagree. Either the manifestation is simpler than the theory and therefore requires a simpler theory, or they are equal in which case trying to understand the manifestation by any other theory will result in inconsistencies. The nature of my learning also reflects that; my intelligence enables me to spot apparent inconsistencies which show I haven't learned something thoroughly, but this also prevents me from utilizing anything less complex.

Python achieves an excellent balance between no-syntax-lisp and all-syntax-perl, I believe. That's why the code is so easy to read.

Design is about maximizing abstraction at every level. Any levels which are not abstracted are useless. For example, SQL. Normal code which just reads from the database is useless abstraction because your code is tied inflexibly to the structure of the database. Ideally if you wanted that you'd design your code to get all structure information from the database itself, with none hard-coded. Or, you should create a layer which lets you completely isolate the database abstraction.

Here's the problem with TMTOWTDI: there's one best way to do it, and the job of the language is to funnel you towards it.

By definition an abstraction is a reduction of information. It inherently limits what you can do. But the point is that very rarely do you need to do everything you can. For example, the abstraction of a programming language eliminates programs that look like "oetwotn2tt39420h2vv23-3", but then what good is such a program? Similarly, the abstraction of php arrays keeps you from referencing memory outside of the array like you can in C, but when would you ever do that? The ideal abstraction lets you do one thing and one thing only, and that thing is what you want to do.