Another newLISP-like language :)

[Jeff]

Don't confuse my defense of lexical scope as advocating OOP :).  Arc and newLISP have different aims.



That being said, I was skeptical about FOOP, too.  After playing with it a bit, I found I was able to model types like I do in OCaml (which has very expressive types).



There was certainly overhead, but it was not atrocious.  I think that it was certainly worth the enhanced readability in my code.



I wouldn't use it for everything, especially applications creating large numbers of prototyped contexts.  But some things really lend themselves to the object model, like ORM.

[m i c h a e l]

I believe the various styles of programming (FP, OOP, SP, FOOP) appeal to different mindsets. OOP, for instance, appeals to creative types, while FP appeals to the mathematically minded. No approach, unless fundamentally flawed, should be considered "wrong," as this implies that a person's way of thinking is "wrong" if they prefer a style different from our own.



Is vanilla ice cream the "One True Way"? Or chocolate? How about Strawberry? Neapolitan, perhaps? The answer is: all of them! One for every taste. And in the case of programming, one for every mindset.



FP and OOP exist at opposite ends of the programming style spectrum. If the OOP part of FOOP can develop sufficiently enough to handle its side of the spectrum (newLISP already handles the other side), then any style in between should be possible. Even future styles!



Then again, this could turn out to be a big pile of FOOP ;-)



m i c h a e l

[Jeff]

I disagree with the statement that OOP is for creative types and functional is for mathematical types.  I'm not mathematical.  I find functional languages to be much more elegant than that majority of OOP languages.  I think that OOP can easily become a crutch and that many programmers try to model *everything* at the expense of logic, efficient and elegant algorithms, and overall program design.



I do like FOOP, though.  It reminds me of the clarity of syntax of OCaml types.

[m i c h a e l]

My use of "creative types" and "mathematically minded" was perhaps a bad choice of words. Maybe "non-programmers" and "programmers" would have been better? In fact, let's throw out the entire sentence all together. What's important is that you have a preference, and that your preference should be respected.



The impression I've received over the last 16 years is that programmers tend to hate OOP with a capital "H," and that artists and children seem to prefer playing with objects. I've never understood the disdain programmers have for OOP. (In fact, it reminds me of the disdain Common Lispers have for newLISP!) As I said in the above post, I assume it stems from having a mindset at odds with the OOP style.



m i c h a e l

[Jeff]

Nope.  My problem with OOP is that it tries to force round pegs through square holes and it leads to a lot of poor programming practices.  It's a way of trying to fix the maintainability of procedural code, and as an abstraction it can be very inefficient.



I like Python's balance of functional and OOP as well as newLISP's.  Neither require it, but they both have it available for problems that are best solved by modeling.



My feeling is that OOP is best used as an expressive way to model data types.  The reason lisps generally look down on OOP is that most data can be just as easily represented as a nested list (which can also store functions that act upon that list).



Modeling the logic of the program as objects is trying to force a verb to be a noun.  Functional programming or plain procedural code is best for this.  I dislike Python's ", ".join(some_list) syntax where it becomes difficult to tell what is acting on what.

[cormullion]

As for Arc ... I liked the tutorial, although I didn't download the software. It's interesting that they wrote a tutorial aimed at "readers with little programming experience and no Lisp experience", given Arc's natural audience. I might borrow a few passages for my own tutorial.



At first glance, to my non-technical eye, the Arc language looks a bit like newLISP for people who don't like typing. I prefer the more English-like style of newLISP - I'm a fairly fast touch-typist and my reading's not too slow, so I can handle the extra characters required...

[itistoday]

If it's so similar to newLISP then why even bother writing it in the first place when newLISP is so much more mature?

[Jeff]

A lot of its popularity is due to this being Paul Graham's big project and the anticipation that has built up over the years it's been in development.

[Fanda]

To me, it's a great thing to have a language allowing you to use both OOP and FP techniques. That's why I wanted to have OOP in newLISP so much. I can actually model some interesting things with it.



My guess is that languages like Python and Ruby are so popular, because they also allow both.



I see a great beauty in declaring class with methods written in functional style. It looks so much better than imperative for/while loops.



[Warning: commercial follows]

I have also been searching and found interesting language called Scala. It is compiled, runs on the JVM, can import Java libraries, supports OOP and FP in a new way (pattern matching on objects/types) and has interesting ways how to extend it. I don't understand it yet and it seems much more complex than newLISP, but I think it's worth looking into :-)



Fanda



PS: It is funny, but after some programming using my OOP framework, I came to understanding that FOOP has some interesting properties, which I would like to add to OOP framework :-)

[Jeff]

Scala is an interesting language.  I played with it for a while, but my implementations in it always ended up being very slow (which may or may not say something about the language).

[newBert]

And what about CloJure ? I think it is a competitor to newLisp far more daunting than Arc ... among other things, because of its lexical scoping (by default).



This issue of "dynamic vs. static scoping" concerned me a lot these days, probably because I finally realized what it was ;) ... and I tried some comparisons between Scheme and newLisp :

Code Select Expand

(define foo
  (let ((a 10)) ; private environment of the lambda
    (lambda (x) (+ x a))))

(define a 1000)

(foo 1)
=> 11   ; with Scheme, what seems logical
=> 1001 ; with newLisp, what is surprising at first glance


And I tried to find a way in newLisp to approach the Scheme's way, I found :

Code Select Expand

(define foo
  (letex ((a 10))
    (lambda (x) (+ x a))))

(set 'a 1000)

(foo 1)
=> 11 ; as in (lexically scoped) Scheme

But I don't know if this is the correct solution ?



I have also tried other things :

Code Select Expand

;; NewLISP
(define x 1)

(define (f) x)

(f) ; => 1

(define (g x) (f))

(g 0) ; => 0

;; SCHEME
(define x 1)

(define (f) x)

(f) ; => 1

(define (g x) (f))

(g 0) ; => 1

I can't get equivalent results in Scheme and in NewLisp, due to different scoping, and 'letex' is of no use to me here.



Has this question of "scoping" a real importance when programing with NewLISP ? What are the inconvenients of dynamic scoping ?

[Jeff]

Dynamic scoping is much faster and simpler to implement, meaning faster execution times and less memory usage.  Lexical scoping requires quite a bit of analysis and makes lookups slower (in interpreted languages).



Dynamic is more difficult to debug, because you have to track down where a function was called from to find the failure, and because a function may be called in so many different environments.



However, if you use properly decoupled functions, utilize throw-error with useful messages, and do not use "spaghetti code", dynamic scope is not difficult to maintain.



Particularly in web programming, where requests are stateless, combining dynamic scope with the save function means you can implement continuations by reinstating the entire environment as it was on the last request (to recreate the last state on each page load and continue from there).



Lexical scoping is very nice, though, especially for large applications.

[Elica]

In dynamic scope (especially if there are many functions calling each other) you must be very careful when you give names to local entities. Otherwise you may shadow some global entity and confuse the functions which rely on it.

[Jeff]

newLISP has contexts which provide lexical closures to prevent namespace litter.

[xytroxon]

Here is  link to help understand the concepts involved.



http://en.wikipedia.org/wiki/Scope_%28programming%29">//http://en.wikipedia.org/wiki/Scope_(programming)

As such, dynamic scoping can be dangerous and almost no modern languages use it. Some languages, like Perl and Common Lisp, allow the programmer to choose lexical or dynamic scoping when (re)defining a variable. Logo is one of the few languages that use dynamic scope.