Witch of this programming style Top-down or buttom-up is the best ?

[pmasiar]

And how is that different than any other language?

Because language **are** different (don't pull Turing completeness on me). Just try creating simple mock-up of any object in Java or C++, and compare it to Lisp, Forth, Perl or Python. Only then you will know what you are talking about.

[CptPicard]

And how is that different than any other language?

Well, it is. I can't think I could approach problems similarly in, say, Java, where architecture comes first much more. IDE refactorings help some, but in general, one needs to identify the objects and classes first. Static types reinforce this requirement.

I suspect this is one of those vague "you have to try it for yourself" issues, but when you have two things at your disposal -- functional-style programming tools (higher-order functions, lambda expressions) and a turing-complete all-encompassing macro system (that is, you can do any syntactic mangling within the language itself before compilation), you can both assume a lot from the little bits you expect to eventually have, and write those little bits in whatever way you please when you have to actually come up with them.

But, in a sense I do agree with you -- competent developers approach things from both directions as necessary in most languages.

[hoboy]

Thanks guy for lots of instrutives responses.

[Simian Man]

Because language **are** different (don't pull Turing completeness on me). Just try creating simple mock-up of any object in Java or C++, and compare it to Lisp, Forth, Perl or Python. Only then you will know what you are talking about.

I know all of the languages you mentioned there -except Forth - in addition to Haskell, ML, and Erlang. I know these languages are different, but all have the capacity for modular design in some manner. In some languages objects are the primary tool and others its functions, but you can still create stubs and work from the top down, adding functionality as you go. You can also write modules from the ground up building on previous layers. I don't think language of choice really affects this all that much directly.

Well, it is. I can't think I could approach problems similarly in, say, Java, where architecture comes first much more. IDE refactorings help some, but in general, one needs to identify the objects and classes first. Static types reinforce this requirement.

Well I for sure see your point here. Java definitely seems to want you to have the scaffolding up before you really get cracking. That's one of the reasons I hate Java, I end up fighting with the language and stupid inheritance hierarchies more than I am coding.

[CptPicard]

Well I for sure see your point here. Java definitely seems to want you to have the scaffolding up before you really get cracking. That's one of the reasons I hate Java, I end up fighting with the language and stupid inheritance hierarchies more than I am coding.

IMO it is a problem of the static-typed OOP paradigm in general and not just an issue of Java. I never was a huge object-believer; when I was learning in the late 90s and OOP was all the rage, I always felt like all this UML-bureaucracy was mostly bs. You end up having to create truly contrived concepts-in-terms-of-objects just to satisfy the ideology, and static typing is, in general, mostly an aid to the compiler, not to the programmer.

Now, objects do certainly exist in code... you have data, and data may, and often will, have type-system hierarchies. And operations need to be specialized according to the type of the data item. But to assume that all operations actually belong to some data item subtype is a trivialization. See Common Lisp's CLOS for an object-oriented system done right -- functions do not belong to data, but they get selected correctly based on specific types of *all* inputs.

Hmmh.. ok, that was offtopic. Anyway, add to that the flexibility you get from closures and the ability to do essentially any symbolic transformation before compilation (in terms of Lisp lists), and Lisp just... wins.

[Simian Man]

IMO it is a problem of the static-typed OOP paradigm in general and not just an issue of Java. I never was a huge object-believer; when I was learning in the late 90s and OOP was all the rage, I always felt like all this UML-bureaucracy was mostly bs. You end up having to create truly contrived concepts-in-terms-of-objects just to satisfy the ideology, and static typing is, in general, mostly an aid to the compiler, not to the programmer.

Well, I agree with you about the UML-OOP-Everything-must-be-in-a-class-hierarchy nonsense. I hate that many CS departments seem to have taken up this tack in teaching the discipline. The buzzwords may help get jobs, but it stifles thought in my opinion.

I don't agree with you on static typing, however. I find that, if I make a mistake about what type something is, it's going to screw me up sooner or later. Having the compiler checks in place make the error apparent at compile time as opposed to run time. I like dynamic languages like Python and Lisp (I mostly just use Scheme) for small stuff, but for anything large enough, static typing is worth it in my opinion. If you combine it with ML-style type inference, its a win-win .

Now, objects do certainly exist in code... you have data, and data may, and often will, have type-system hierarchies. And operations need to be specialized according to the type of the data item. But to assume that all operations actually belong to some data item subtype is a trivialization. See Common Lisp's CLOS for an object-oriented system done right -- functions do not belong to data, but they get selected correctly based on specific types of *all* inputs.

Yeah, I love Common Lisp's multiple dispatch system. In some ways Java and C# are actually pretty bad at OOP - what they are so highly touted for.

Hmmh.. ok, that was offtopic. Anyway, add to that the flexibility you get from closures and the ability to do essentially any symbolic transformation before compilation (in terms of Lisp lists), and Lisp just... wins.

Maybe I just need to play with Lisp more then. Whenever I use it I'm impressed with it, but I just can't see myself using it for anything serious.

[pmasiar]

Having the compiler checks in place make the error apparent at compile time as opposed to run time. I like dynamic languages like Python and Lisp (I mostly just use Scheme) for small stuff, but for anything large enough, static typing is worth it in my opinion.

For anything large, you will write tests suite, I would hope? The first and simplest one would be to check the type info?

Utility of static typing in application programs (as opposed to system utilities) is vastly oversold, IMHO. Just a thought.

[CptPicard]

The buzzwords may help get jobs, but it stifles thought in my opinion.

Fully agreed. In particular when it comes to CS, one should focus on the core concepts that relate formal logic, computability, languages and algorithms and mathematics... and it is such a pity that undergrads do not generally even get taught what a closure is, although it is such a fundamental concept!

I don't agree with you on static typing, however. I find that, if I make a mistake about what type something is, it's going to screw me up sooner or later. Having the compiler checks in place make the error apparent at compile time as opposed to run time.

Well, this is the big debate about static vs. duck typing, and I guess we can read about it elsewhere. The core point from my POV is of course that 99% of the errors you talk about are totally trivial, and are essentially apparent right after you first try to run your program... benefits of genericity outweigh the risk. I do however fully acknowledge the simple runtime speed issue of checking types at runtime.

If you combine it with ML-style type inference, its a win-win .

Now, type inference with a (pure) functional language really is a huge win, agreed.

Maybe I just need to play with Lisp more then. Whenever I use it I'm impressed with it, but I just can't see myself using it for anything serious.

I would suggest you do so -- it really bends to your will nicely and *you* are the limit (things like SBCL in particular). When it comes to typing btw, you should be aware that CL allows for type declarations as assertions -- you simply state that X is of type Y, and the compiler will make use of that information to produce better code -- and if the statement does not hold, you either get an error or a crash, depending on your safety level.

[Simian Man]

I would suggest you do so -- it really bends to your will nicely and *you* are the limit (things like SBCL in particular). When it comes to typing btw, you should be aware that CL allows for type declarations as assertions -- you simply state that X is of type Y, and the compiler will make use of that information to produce better code -- and if the statement does not hold, you either get an error or a crash, depending on your safety level.

Well that's a pretty nice compromise . What CL implementation do you recommend?

[CptPicard]

Well that's a pretty nice compromise . What CL implementation do you recommend?

SBCL, definitely.

I really like it how you can move easily between levels of abstraction -- as it is in the end native-compiled, at points where you really need speed you can write imperative-style code with strict type-declarations all you want, and hide that behind macros. On the other hand, when you don't need the speed and can make do with generic types, the compiler will just compile in type-checks and function dispatching and what have you. It is really very flexible. And of course all the time you have the really strong basic fundamentals of the language available... in particular, you can just grab any environment into a lambda and shove it away for later invocation. I really love closures

If only there were decent GUI bindings, I would consider becoming a 100% lisper really... it is remarkable that in 50 years, there is nothing new under the sun.