OOP is a dead end (for all your C++ and Java programmers)

[dxoigmn]

I don't find the need to define efficient, look it up. I'm also not about to start an argument with you. Notice how I said "I believe", and that it was *my opinion*. You also said that you are "a believe of using the most appropriate tool". We both have our own opinions. But I also agree with you, I use the appropriate tool, whatever it may be, as well.

Yes you do because efficient can be refering to space, time or something else. But fine, if that's what you want to believe that then you can blindly believe that.

[Yegg]

I don't find the need to define efficient, look it up. I'm also not about to start an argument with you. Notice how I said "I believe", and that it was *my opinion*. You also said that you are "a believe of using the most appropriate tool". We both have our own opinions. But I also agree with you, I use the appropriate tool, whatever it may be, as well.

Yes you do because efficient can be refering to space, time or something else. But fine, if that's what you want to believe that then you can blindly believe that.

Why do you say that I "blindly believe" in something because I will not define a term for you, that shouldn't have to be defined in the first place?

From Dictionary:
    "Acting or producing effectively with a minimum of waste, expense, or unnecessary effort."

[netytan]

Well the opinion of the person making the accusations, not the one supporting him should be t he most relevant. Also what is a "Stable" language and what makes the current languages "Unstable" ?

I would define a language (or its paradigm) as unstable if it allowed bugs to hide away in the code.  This is in stark contrast to functional languages do this by avoiding side-effects in code, in these languages the state of the program doesn't change though assignment, in fact it's bad practice (and impossible in some functional languages) to use assignment.

Instead state changes though the evaluation of functions which in some sense flow like a river from the inner most expressions to the outermost.

It has been proven in many white papers and other programming text discussing the subject that most programming errors (those which use assignment) come form variables inadvertently picking up the wrong value during execution, or an unexpected value in some cases.

This simply doesn't happen I functional languages so right away we've avoided the number one cause of errors, and made the program easier to follow in the process – because you can be sure at each point of the program the value you are working with .

Google for more info,

Mark.

[netytan]

I don't find the need to define efficient, look it up. I'm also not about to start an argument with you. Notice how I said "I believe", and that it was *my opinion*. You also said that you are "a believe of using the most appropriate tool". We both have our own opinions. But I also agree with you, I use the appropriate tool, whatever it may be, as well.

Yes you do because efficient can be refering to space, time or something else. But fine, if that's what you want to believe that then you can blindly believe that.

Why do you say that I "blindly believe" in something because I will not define a term for you, that shouldn't have to be defined in the first place?

From Dictionary:
    "Acting or producing effectively with a minimum of waste, expense, or unnecessary effort."

I think he means all of the above by that. And Lisp (assuming thats what you're talking about and OOP) is very effectively implement now adays. Memory managment is very well done and well worth the reduction in development time. Especially when you consider that Lisps speed is roughly equivilent to C's depending on the task so for most cases?

It's efficient . But this wasn't ment to be a Lisp thread lol.

Mark.

[dxoigmn]

Why do you say that I "blindly believe" in something because I will not define a term for you, that shouldn't have to be defined in the first place?

From Dictionary:
    "Acting or producing effectively with a minimum of waste, expense, or unnecessary effort."

Because in computer science, "efficient" explicitly means something. If you ever take an algorithm's course, then your professor may ask you to find an algorithm that is time efficient to solve some problem. Likewise, the professor may ask for another algorithm that is space efficient for that very same problem. The solutions for both of these problems are not necessarily the same.

Edit: Response

I would define a language (or its paradigm) as unstable if it allowed bugs to hide away in the code.  This is in stark contrast to functional languages do this by avoiding side-effects in code, in these languages the state of the program doesn't change though assignment, in fact it's bad practice (and impossible in some functional languages) to use assignment.

Instead state changes though the evaluation of functions which in some sense flow like a river from the inner most expressions to the outermost.

It has been proven in many white papers and other programming text discussing the subject that most programming errors (those which use assignment) come form variables inadvertently picking up the wrong value during execution, or an unexpected value in some cases.

This simply doesn't happen I functional languages so right away we've avoided the number one cause of errors, and made the program easier to follow in the process – because you can be sure at each point of the program the value you are working with .

Google for more info,

Mark.

Of course the argument against these types of languages is that they are horribly inefficient with respect to space.

[netytan]

Why do you say that I "blindly believe" in something because I will not define a term for you, that shouldn't have to be defined in the first place?

From Dictionary:
    "Acting or producing effectively with a minimum of waste, expense, or unnecessary effort."

Because in computer science, "efficient" explicitly means something. If you ever take an algorithm's course, then your professor may ask you to find an algorithm that is time efficient to solve some problem. Likewise, the professor may ask for another algorithm that is space efficient for that very same problem. The solutions for both of these problems are not necessarily the same.

As with quicksort, which is fast but not as space effcient as some other sorts because it has to maintain multiple sequences – though I've seen a nice implemenation which overwrote the array it was passed, don't know where I saw it though?

Mark.

[dxoigmn]

As with quicksort, which is fast but not as space effcient as some other sorts because it has to maintain multiple sequences – though I've seen a nice implemenation which overwrote the array it was passed, don't know where I saw it though?

Mark.

Yes. The problem with an in-place implementation of quicksort is that it is not stable which is sometimes desireable.

[netytan]

As with quicksort, which is fast but not as space effcient as some other sorts because it has to maintain multiple sequences – though I've seen a nice implemenation which overwrote the array it was passed, don't know where I saw it though?

Mark.

Yes. The problem with an in-place implementation of quicksort is that it is not stable which is sometimes desireable.

Should start a thread for quick sort examples in different languages, it would be a nice way to show different techniques off. What do you think?

Mark.

[Warrior]

Well the opinion of the person making the accusations, not the one supporting him should be t he most relevant. Also what is a "Stable" language and what makes the current languages "Unstable" ?

I would define a language (or its paradigm) as unstable if it allowed bugs to hide away in the code.  This is in stark contrast to functional languages do this by avoiding side-effects in code, in these languages the state of the program doesn't change though assignment, in fact it's bad practice (and impossible in some functional languages) to use assignment.

Instead state changes though the evaluation of functions which in some sense flow like a river from the inner most expressions to the outermost.

It has been proven in many white papers and other programming text discussing the subject that most programming errors (those which use assignment) come form variables inadvertently picking up the wrong value during execution, or an unexpected value in some cases.

This simply doesn't happen I functional languages so right away we've avoided the number one cause of errors, and made the program easier to follow in the process – because you can be sure at each point of the program the value you are working with .

Google for more info,

Mark.

So you're going to blame the LANGUAGE and not the PROGRAMMER for having bugs in his code?
What.the.fuck.

[netytan]

Well the opinion of the person making the accusations, not the one supporting him should be t he most relevant. Also what is a "Stable" language and what makes the current languages "Unstable" ?

I would define a language (or its paradigm) as unstable if it allowed bugs to hide away in the code.  This is in stark contrast to functional languages do this by avoiding side-effects in code, in these languages the state of the program doesn't change though assignment, in fact it's bad practice (and impossible in some functional languages) to use assignment.

Instead state changes though the evaluation of functions which in some sense flow like a river from the inner most expressions to the outermost.

It has been proven in many white papers and other programming text discussing the subject that most programming errors (those which use assignment) come form variables inadvertently picking up the wrong value during execution, or an unexpected value in some cases.

This simply doesn't happen I functional languages so right away we've avoided the number one cause of errors, and made the program easier to follow in the process – because you can be sure at each point of the program the value you are working with .

Google for more info,

Mark.

So you're going to blame the LANGUAGE and not the PROGRAMMER for having bugs in his code?
What.the.fuck.

I'm going to say, as I have said that the quality of the language you're using influences the quality of your solutions. This is obvious, of course it must otherwise everyone would program at the same level under different languages and paradigms.

The fact is that different languages allow different degrees of abstraction and expression, these contribute to how the problem is reasoned about by the programmer i.e. manipulating Arrays in C is much harder than in say Python, ignoring any memory allocation and types the two languages would be at pretty much the same level when it comes to accessing elements of an array/list but because Python has an abstract called a slice list manipulation is considerably easier.

The same can be said of OOP, it's an attempt to take responsibility away from the programmer however the abstraction is flawed [primarily] because not everything IS an object/type, and so isn't best represented as such.

As dxoigmn said, he uses the different languages for different tasks. When all of these languages are based on the same paradigm the difference is relatively minimal. When we have different paradigms involved it's like looking at a program though a microscope instead of a magnifying glass.

What I proposed is that OOP is the paradigm for the exception (if at all), not the rule as it is used now. In this way OOP will likely never get used because areas where it is better than other paradigms are rare. As I said this makes it a dead end, caused by people thinking theres no better way, or not knowing any different.

So of course, the language being used effects how programs can be written in it. Prolog, a logical language can express in a few lines what would take OOP programmers several pages.

I can't believe this idea is so hard to grasp?

Mark.

[Banana fanna fo fanna]

Like a natural language student; how can a programmer express for example, the color of table in a language that doesn't have any concept of what color is or how to describe it, or any way of expressing a new concepts within it's design.

Are you suggesting that C++ is limiting in this fashion?  There is no natural construct for color in C++; however, it is usually typified in code:

Code Select Expand


typedef unsigned long int COLOR;

This works for us because the device we use to emit this abstract idea (color) in the physical world is a bitmapped projection tube.  It just so happens that there are 256 levels at which this tube can emit each of three colors.  When you combine a fourth color channel, Alpha, you come up with a nice structure that fits beautifully into a 32-bit numeric value like we have.

You totally missed the point. He's saying that several languages cannot express macros, closures, code-as-data and first-class procedures, such concepts that languages like LISP variants can. This is what he means by color; he means color in a metaphorical sense, not in a concrete RGB value sense.

Going against the grain for the sake of going against the grain is stupid.  It's why I don't respect Eminem, for example -- he works to be controversial for the sake of being controversial, not because he has anything relevant to say in his lyrics.

Agreed. This kid just read SICP and is trying to spread the gospel. Soon, he'll try to write a real-world application with it and realize how awful it is to interface with the "outside world".

[netytan]

I haven't read that book however I've read many books & white papers on these subjects (inc. functional programming and language design), I'll get around to this once but I have other things to keep up with as well .

I'm not claiming to be an expert.

Most of my opinions are in fact gained though exposure to these types languages while at Uni and in my free time because I get great pleasure from tackling new language concepts.

It seems to me that everyone is taking this way to seriously; like I've walked into a church and taken a shot at god before of the decibels. This isn't the case guys .

Also, I'm not going against the grain for the sake of it. There are obvious merit in the use of these concepts in programming as many papers have justified over the years. Just because the large majority of the industry doesn't take advantage of these ideas doesn't make them bad ideas in any sense, which I what I dislike about the "real world" as you referred to it.

Interfacing with real world applications really shouldn't cause problems Banana, if we're just talking about Lisp then there are well defined and well tested interfaces to natively compiled libraries which can be imported and used as is – aside from this there is also the possibility of interface via middle-ware and or webservices, have to get around to reading more into this too.

Either way this is what I think and I've seen nothing to change my mind, believe it's very open to change . You don't have to take them seriously or even listen.

Mark.

[Skywing]

I wonder how much luck you'd have using something like lisp in a kernel driver on a mainstream operating system...

[netytan]

Considering that in the 1980s one of the most powerful and widely used OS's (though not by todays standards) was written entirely in Lisp.  This OS was and is today considered by some to be the most flexible and safe OS we've yet come up with, I suspect because of full runtime debugging. So all in all I think it'd go pretty well with the right backing.

Google Lisp-Machines, though I am aware that these computers used hardware execration for Lisp programs I'm sure any speed increase has been well offset since then.

As an example of the longevity of Lisp programs take emacs. It is still one of the most popular, and without doubt the most flexible editor available as the usage stats and fan gathering suggest. It was written A LONG time ago though I'm sure you knew that .

There is actually a project aimed at producing a Lisp "on the metal" which can be used to write these kinds of things called Movitz. It's actually very impressive design wise but it's not being used for anything serious right now.

I didn't really want this to turn into a Lisp thread but apparently it's going that way,

Have fun Sky,

Mark.