There's a similar opposition between the use of lists to represent things and the use of "objects" with named, typed fields. I went through a stage, after I'd been programming in Lisp for 2 or 3 years, where I thought the old way of using lists to represent everything was just a hack. If you needed to represent points, surely it was better to declare a proper structure with x and y fields than to use a list of two numbers. Lists could contain anything. They might even have varying numbers of elements.
I was wrong. Those are the advantages of using lists to represent points.
Over the years my appreciation for lists has increased. In exploratory programming, the fact that it's unclear what a list represents is an advantage, because you yourself are unclear about what type of program you're trying to write. The most important thing is not to constrain the evolution of your ideas. So the less you commit yourself in writing to what your data structures represent, the better.
Name:
Anonymous2011-02-01 8:31
It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures. -- Alan Perlis
>>2 your quote is invalid
your sage is invalid
and so is your argument
Name:
Anonymous2011-02-01 9:22
the fact that it's unclear what a list represents is an advantage, because you yourself are unclear about what type of program you're trying to write. The most important thing is not to constrain the evolution of your ideas.
That might be true but I think you're mistaking indecision and lack of formal structure with a range of freedom. The actual creative benefit of starting from a Spartan environment is not always fully utilized because the programmer has already limited his own program by speculating about it. On the other hand, if you can provide a more quantitative explanation of this advantage I'd be interested in hearing it.
Name:
Anonymous2011-02-01 9:27
>>8
And everybody else went and chased static. And they've been doing it like crazy. And they've, in my opinion, reached the theoretical bounds of what they can deliver, and it has FAILED. These static type systems, they're WRONG. Wrong in the sense that when you try to do something, and they say: No, category theory doesn't allow that, because it's not elegant... Hey man: who's wrong? The person who's trying to write the program, or the type system?
>>4
What about returning multiple (values) vs a list of values?
To represent points, I'd use (cons x y), you a list and someone a struct, in Lisp there's no ``right way to do it'', all the ways are right ways.
Name:
Anonymous2011-02-01 9:36
Monad is just one of typeclasses. And a typeclass is a some abstract entity, that allows concrete types to use some functions. And the nature of these functions depends on a typeclass of a concrete type, and how these functions implemented for a concrete type depends on the embodiment of typeclass of that type. For example, monad Maybe is a type, computations, embedded in a monad of which, return either result, embedded into one of its data constructors, or a second data data constructor - Nothing.
Hey man: who's wrong? The person who's trying to write the program, or the type system?
You sound like that guy who complained that the single call to write doesn't close the file handles. If you are doing things wrong then don't expect everything else to bend over to you.
Name:
Anonymous2011-02-01 18:22
I remeber running VisualWorks Smalltalk some 8 years ago. It was (is?) the fastest Smalltalk environment around, with bleeding edge dynanic OO language optimization tecniques, and it was still sort of slow. Slower than Java, even. Then I wondered, what if all applications in my computer were written in Smalltalk? Well, shit would be even slower. Then I thought of how slower machines were at the time Smalltalk-80 came around. It's all about performance, man. No one likes to see hourglasses when interacting with programs. Static languages have the performance advantage, and that's leverage (comercial) software makers can't ignore (even if they really want to).
Name:
Anonymous2011-02-01 18:41
>>16
Write doesnt close files because the underlaying operating system is crappy Unix like. We should develop a new OS in Lisp, the ultimate OS that would have persistent files, implemented as finger trees, that dont need to be closed.
Name:
Anonymous2011-02-01 18:43
>>18
And, people, dont forget, that most of evil in our world was spawned by the ugly Unix and its jewish inventors - Thomson and Richie with their C/C++. These bastards should be executed by gas chambers
Name:
Anonymous2011-02-01 18:51
Unix/Linux is the embodiment of pure refined evil.
>>21
Oh please, ObjC is no more verbose than C++, even if its dynamic binding mechanism is basically the same as Smalltalk's. If you want a nice static language with an OOP layer with Smalltalk-style dynamic binding, OCaml is really the way to go. But seriously, if you're going to call some brand of OOP "true OOP", please realize that it is Common Lisp's brand (or Dylan's).
>>30
Well if you don't like types, then you probably should only program in Assembly and Forth. Just try that out for a while and then tell me how well that works out for ya.
>>18
Yes! It would be amazing! Running 2 processes at the same time in O(n*n*n*n*n*n) on an Octocore 8Ghz Extreme because of the superior LISP technologies! How about online videos? Sorry, no hardware video acceleration in 5 decades. etc.
>>31
It will not happen because the world is full of assholes such as >>34.
Name:
Anonymous2011-02-01 19:48
>>33
I program in LISP. In there is no need to differentiate various lists by type. Their structure determines their "type", so every list has its own unique type.
Name:
Anonymous2011-02-01 19:49
And, yes, I have a deep hatred for other languages and their types in particualr.
>>36
You don't have to declare/restrict their types because their elements' types are dynamically checked. Serioulsy, try Forth or Assembly to see what "typeless" actually means.
Name:
Anonymous2011-02-01 20:03
>>39
"Their elements' types" are also lists. No need for checking.