I've noticed there are a [relatively] large number of C++ programmers here, honestly I can't fathom why but I know you have your reasons. For one it's easier to get a job in C++ or Java than in say ASM or even better Lisp – they won't be good jobs but any job is better than none right?

I beg to differ on this statement of course, having a good job is much more valuable to me (and should be to any good programmer). It's not my attempt to start anything here I'd just like to hear your reasons for using such truly indignant languages.

There are other excuses for using C++/Java etc, I've heard them all no doubt but most of them hang around one main concern: money


Ignoring this, because I really can't say anything you don't already know. I was most disturbed (and more than a little amused) to read that some people here believe that C++ and more generally OOP makes better programmers.

This could NOT be further from the truth, C++/Java makes sloppy programmers as evident by the average quality of software in them today. This is because both languages encourage ridged inelegant thinking.

Let me explain:

programming languages are not equal, simply because most [all] languages today are turing compliant doesn't mean that each language is as powerful as the next. If it where then it wouldn't matter which was used.

(A note on power here: power in the sense of programming languages is measured in abstraction and not speed as may be expected.)

Contrary to common belief programming languages are not just tools, they are a medium for expression. Our expression. In order to program in any language well you have to think in that language, when a language imposes limits on the programmers thinking (as do most mainstream languages to varying degrees) the only result can be a bad program which teaches you nothing.

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.

This is rare but there are languages this flexible, which I would urge you all to look at for the obvious reason that, without doubt they will make you better programmers even if you never use them!

An interesting response to this problem in language design is to make languages stricter?! OOP is one such abstraction. In order to program in OOP we make everything an object conceptually (or as much as possible depending on the design of the language/extension) rather than generalizing.

This is done in OOP without any regard for the fact that not everything is in reality an object. Or for that matter represented as an object making the abstraction synonymous with a shackle.

A common reason used to justify OOP as a medium is that it helps prevent errors while protecting data and improving modularity of the code in question, and hence allowing more programmers to work on the same task simultaneously.

Sounds good but in practice it doesn't seem to work very well at all, some of the worst examples of large-scale programming are written in this way. Maybe we should take advice from institutions like MIT here as to what the languages are best? It would make sense.

We should also take into account that the best software is written by small groups of people using more powerful languages, not huge teams using C++ or Java.

OOP does help make C++ and Java programs more modular but only because of flaws present in the initial design of the language – lack of flexibility/polymorphism (see Haskell).

C++ for example was designed to provide a way to work around C's ridged type-system

In more flexible languages the prevention of bugs is done via improvements in the way programmers can express their ideas, not by limiting this as we have shown. We now have a case where the measures put in place to prevent such errors are actually causing them, and self propagated though industry propaganda, usually by people who know no better.

Weather you agree or not OOP as a model for programming is a dead end that will eventually be bread out of us, to be replaced by other more elegant ideas such as meta-programming (programs that write programs) and functional programming to name just two.


That any of you can say that C++ makes better programmers is in a broader sense  a testament to the fact that average programmers program without being exposed to good paradigms because of market influences or god forbid personal choice.

The only way to become a good programmer, or a great programmer if you consider the majority of programmers to be good programmers already is to expose yourself to these ideas. Not hide behind the industries "standard" idea which crawls along literally 50 years behind (see Lisp).

Try thinking for yourself?

Looking forward to meeting you all, Take care,

Mark.

I completely agree.  8)

[quote author=netytan link=topic=14070.msg143938#msg143938 date=1138744101]
I've noticed there are a [relatively] large number of C++ programmers here, honestly I can't fathom why but I know you have your reasons. For one it's easier to get a job in C++ or Java than in say ASM or even better Lisp – they won't be good jobs but any job is better than none right?[/quote]
It is interesting that you raise this point.  Are you trying to say that it is better to program in ASM or Lisp than C++ or Java?  Perhaps for small-scale jobs or drivers.  But ASM is unwieldy and will quickly grow too large to manage effectively.

[quote author=netytan link=topic=14070.msg143938#msg143938 date=1138744101]Ignoring this, because I really can't say anything you don't already know. I was most disturbed (and more than a little amused) to read that some people here believe that C++ and more generally OOP makes better programmers.
[/quote]
I think OOP *can* make better *programs*.  If the programmer is broken, though, no technology is going to fix him (or her).

[quote author=netytan link=topic=14070.msg143938#msg143938 date=1138744101]This could NOT be further from the truth, C++/Java makes sloppy programmers as evident my the average quality of software in them today. This is because both languages encourage ridged inelegant thinking.
[/quote]
I disagree again.  I think many environments in which these languages are used is what encourages rigid and inelegant thinking.  I sit back right now and work on my projects when I can, asking myself, "is this the best way I can do this?  Is there something more I can add for my end-user here?"  These kinds of questions are difficult if not impossible to ask in the commercial world; businesses depend on timetables to stay competitive.  

[quote author=netytan link=topic=14070.msg143938#msg143938 date=1138744101](A note on power here: power in the sense of programming languages is measured in abstraction and not speed as may be expected.)
[/quote]
If I am correct in interpreting your above statement about assembly and Lisp, I think you just contradicted yourself.  C++/Java are far better than ASM at abstraction.

[quote author=netytan link=topic=14070.msg143938#msg143938 date=1138744101]
Contrary to common belief programming languages are not just tools, they are a medium for expression. Our expression.
[/quote]
I think that depends on whom you ask.  That's true for hobbyist programmers.  But even for us, I sometimes make a tool program just for something really quick.  When I do so it's just a tool.

[quote author=netytan link=topic=14070.msg143938#msg143938 date=1138744101]In order to program in any language well you have to think in that language, when a language imposes limits on the programmers thinking (as do most mainstream languages to varying degrees) the only result can be a bad program which teaches you nothing.
[/quote]
I disagree again.  I don't think you have to think *in that language*, but it is necessary to be able to deconstruct an algorithm in your mind from the starting point and end point.

[quote author=netytan link=topic=14070.msg143938#msg143938 date=1138744101]
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.
[/quote]
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]
typedef unsigned long int COLOR;
[/code]
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.

[quote author=netytan link=topic=14070.msg143938#msg143938 date=1138744101]
This is rare but there are languages this flexible, which I would urge you all to look at for the obvious reason that, without doubt they will make you better programmers even if you never use them!
[/quote]
So, since C++ and Java are this flexible, we *should* use them?

[quote author=netytan link=topic=14070.msg143938#msg143938 date=1138744101]Sounds good but in practice it doesn't seem to work very well at all, some of the worst examples of large-scale programming are written in this way. Maybe we should take advice from institutions like MIT here as to what the languages are best? It would make sense.
[/quote]
Define "worst."  What OOP aims to accomplish, you said yourself:
* Easier maintenance.
* Faster development.
* Presents easier-to-understand abstract objects to us
All of these work in tandem.  You can really screw up an OOP program by, for example, making a class 10 layers deep without meaningful functionality added at each layer.  But I don't think I've ever seen an object more than 4 or 5 layers deep that didn't make sense to have at that place.

It doesn't take a good programmer to make an overbloated windbag of a program.  That's why design is a crucial step prior to the actual coding of a project.

[quote author=netytan link=topic=14070.msg143938#msg143938 date=1138744101]We should also take into account that the best software is written by small groups of people using more powerful languages, not huge teams using C++ or Java.
[/quote]
Hrm....  That's an EXTREMELY bold statement with nothing to back it up.

[quote author=netytan link=topic=14070.msg143938#msg143938 date=1138744101]
OOP does help make C++ and Java programs more modular but only because of flaws present in the initial design of the language – lack of flexibility/polimorphism (see Haskell).
[/quote]
Uhh....  Java not being directly descendent of anything doesn't make up for any flaws present in the initial design of the language, because it was initially designed with polymorphism and "flexibility."

[quote author=netytan link=topic=14070.msg143938#msg143938 date=1138744101]
C++ for example was designed to provide a way to work around C's ridged type-system
[/quote]
C does NOT have a rigid type system.  C's type system is incredibly weak, in fact; C++ added many more type restrictions.

[quote author=netytan link=topic=14070.msg143938#msg143938 date=1138744101]
In more flexible languages the prevention of bugs is done via improvements in the way programmers can express their ideas, not by limiting this as we have shown. We now have a case where the measures put in place to prevent such errors are actually causing them, and self propagated though industry propaganda, usually by people who know no better.
[/quote]
You're starting to sound like a conspiracy theorist, and you're not backing up your claims with any reliable sources or even examples (such as a "more flexible programming language").

[quote author=netytan link=topic=14070.msg143938#msg143938 date=1138744101]
Weather you agree or not OOP as a model for programming is a dead end that will eventually be bread out of us, to be replaced by other more elegant ideas such as meta-programming (programs that write programs) and functional programming to name just two.
[/quote]
I don't believe it's a dead-end, although I do agree that it may eventually be replaced by a more sophisticated programming paradigm.  It would not surprise me in the least if we shifted to an object-functional hybrid, as there are simply some times when you want to explicitly define what you're expressing.

[quote author=netytan link=topic=14070.msg143938#msg143938 date=1138744101]
That any of you can say that C++ makes better programmers is in a broader sense  a testament to the fact that average programmers program without being exposed to good paradigms because of market influences or god forbid personal choice.
[/quote]
As I said before, I don't think that any particular language or technology can make someone a better programmer.  Some people simply cannot program; they can instruct a computer what to do, but they can't dialogue with the computer.

[quote author=netytan link=topic=14070.msg143938#msg143938 date=1138744101]
The only way to become a good programmer, or a great programmer if you consider the majority of programmers to be good programmers already is to expose yourself to these ideas. Not hide behind the industries "standard" idea which crawls along literally 50 years behind (see Lisp).

Try thinking for yourself?
[/quote]
All told, this was a fairly forward, possibly rude first post.  I hopefully have gotten past that in my replies, which absolutely reflect my opinions about what you've said.  Still, a lot of what you said sounds analogous to "We shouldn't use Windows because it's made by Microsoft, and they are a big company driving the most of the industry, so whatever they say must be bad."

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.

[quote author=MyndFyre link=topic=14070.msg143957#msg143957 date=1138745619]
I disagree again.  I think many environments in which these languages are used is what encourages rigid and inelegant thinking.  I sit back right now and work on my projects when I can, asking myself, "is this the best way I can do this?  Is there something more I can add for my end-user here?"  These kinds of questions are difficult if not impossible to ask in the commercial world; businesses depend on timetables to stay competitive.[/quote]

You've missed the point in more than one aspect. However, this one was the biggest. Sure, C++ (just using this as an example) makes you thick more elegantly. But if we had more stable languages, this wouldn't be necessary in the first place.

So until someone writes a "Stable" language ...OOP is necessary..

[quote author=Warrior link=topic=14070.msg143970#msg143970 date=1138746643]
So until someone writes a "Stable" language ...OOP is necessary..
[/quote]

And we have "stable" languages. Take a look at Common LISP and Scheme.
Why should OOP be necessary if there are better solutions?

[quote author=Yegg link=topic=14070.msg143969#msg143969 date=1138746531]
[quote author=MyndFyre link=topic=14070.msg143957#msg143957 date=1138745619]
I disagree again.  I think many environments in which these languages are used is what encourages rigid and inelegant thinking.  I sit back right now and work on my projects when I can, asking myself, "is this the best way I can do this?  Is there something more I can add for my end-user here?"  These kinds of questions are difficult if not impossible to ask in the commercial world; businesses depend on timetables to stay competitive.[/quote]

You've missed the point in more than one aspect. However, this one was the biggest. Sure, C++ (just using this as an example) makes you thick more elegantly. But if we had more stable languages, this wouldn't be necessary in the first place.
[/quote]
I didn't miss any point.  I addressed precisely what he'd said in the first place: that it isn't the language itself that promotes rigid thinking, but the environment in which it is used.

Nor did I say in that quote that C++ makes you thick (or even think) more elegantly.  I'm sorry if that quote wasn't what you were addressing, but I took the time to delineate what I was responding to of the original post, and I think it's only polite for you to do the same.

What is a "more stable" language, by the way?

I would also like to point out that it would be nice if we were on the Starship Enterprise and could say "Computer, run a multispectral compositional analysis on the sample we just retrieved with the tractor beam."  However, at some point, someone had to program the computer how to understand that language, tell it what an analysis is, AND what a specialized multispectral compositional analysis is.  Some things you can't just meta-program without first programming the core.  Like assembly provides a necessary layer between object-oriented programming and hardware, so will OOP provide a necessary layer between meta-programming and lower-level access.  But that is some time off, yet.

[quote author=Yegg link=topic=14070.msg143973#msg143973 date=1138746730]
[quote author=Warrior link=topic=14070.msg143970#msg143970 date=1138746643]
So until someone writes a "Stable" language ...OOP is necessary..
[/quote]

And we have "stable" languages. Take a look at Common LISP and Scheme.
Why should OOP be necessary if there are better solutions?
[/quote]

Stable by what standards? Not by what you think I hope. Not a List programming language or something based of it..cmon..

[quote author=Warrior link=topic=14070.msg143987#msg143987 date=1138748260]
[quote author=Yegg link=topic=14070.msg143973#msg143973 date=1138746730]
[quote author=Warrior link=topic=14070.msg143970#msg143970 date=1138746643]
So until someone writes a "Stable" language ...OOP is necessary..
[/quote]

And we have "stable" languages. Take a look at Common LISP and Scheme.
Why should OOP be necessary if there are better solutions?
[/quote]

Stable by what standards? Not by what you think I hope. Not a List programming language or something based of it..cmon..
[/quote]

IMO, which does not matter at all, because no opinion matters, list manipulation is the most efficient technique for storing data. And I also beliebe that LISP, and languages based off of it (Scheme), use it to its full potential, far more elegantly than any other language. But remember, this is opinion and it does not matter (except to me).

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" ?

[quote author=Warrior link=topic=14070.msg143990#msg143990 date=1138748794]
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" ?
[/quote]

I never said anything about any language's being "unstable". However I believe some languages are more "stable" than others. What I mean by "stable":
  1) A dynamicly typed language (personal opinion).
  2) A language that uses macros to their fullest capability.
  3) A language where recursion can be taken advantage of more efficiently.
  4) A language without the forceful use of pointers. (more of an opinion, again).
  5) A non-platform-dependant language where code can run, unchanged, from platform to platform.
  6) A language that is fast (not that speed is our most important concern).

That's most of what I consider "stable". I should have mentioned this before, rather than just using "stable" with really didn't make sense. Sorry. :P

[quote author=Yegg link=topic=14070.msg143989#msg143989 date=1138748494]
IMO, which does not matter at all, because no opinion matters, list manipulation is the most efficient technique for storing data. And I also beliebe that LISP, and languages based off of it (Scheme), use it to its full potential, far more elegantly than any other language. But remember, this is opinion and it does not matter (except to me).
[/quote]

Define efficient, then I'll take up argument against list manipulation being the most "efficient" way of storing data.

LISP and Scheme are nice languages with some very neat constructs, but I am a believer of using the most appropriate tool (language) for the task at hand. Sometimes that is Java, sometimes that is C, sometimes that is Scheme, sometimes that is assembly.

Hi MyndFyre,

Thanks for the reply my intent wasn't to be controversial for the sake of being controversial, merely to express what I've learned though my experiences with languages not considered to be industry standard :). And the paradigms used in those languages, the good bits of which I recognize have followed over into how I use more standard languages.

[quote author=MyndFyre link=topic=14070.msg143957#msg143957 date=1138745619]
It is interesting that you raise this point.  Are you trying to say that it is better to program in ASM or Lisp than C++ or Java?  Perhaps for small-scale jobs or drivers.  But ASM is unwieldy and will quickly grow too large to manage effectively.
[/quote]

I was saying here that writing programs in ASM is preferable to C++ because of the control that you are given over the system, the flexibility, however this IMO should only be used when you want this control.

An ideal application for ASM would be for building domain specific languages.

Lisp is obviously preferable to C++ or Java because of the flexibility it's design allows, flexible languages allow flexible thought and new abstractions to be added to Lisp in moments which are indistinguishable to built-in concepts, while remaining comparable in speed to C for most (none number intensive) applications.

[quote author=MyndFyre link=topic=14070.msg143957#msg143957 date=1138745619]
I think OOP *can* make better *programs*.  If the programmer is broken, though, no technology is going to fix him (or her).
[/quote]

I don't think this is true for the most part due to the fact that in order for a program to be good it's design should be as elegant as possible while maintaining efficiency and clarity of purpose.

I think it is possible to become a better programmer, however it takes a lot of work and exposure to appropriate way of thinking, this is what I proposed in this thread. There is a certain amount of talent involved but surely this could be overcome.

[quote author=MyndFyre link=topic=14070.msg143957#msg143957 date=1138745619]
I disagree again.  I think many environments in which these languages are used is what encourages rigid and inelegant thinking.  I sit back right now and work on my projects when I can, asking myself, "is this the best way I can do this?  Is there something more I can add for my end-user here?"  These kinds of questions are difficult if not impossible to ask in the commercial world; businesses depend on timetables to stay competitive.  
[/quote]

Not to second guess you but you are not thinking "is this the best way I can do this?". What you're thinking is and I don't think you could deny it is: "is this the best way I can do this in this language?".

By definition the best solution to a problem would be the first, because in a well abstracted language the solution should run [fairly] parallel to the way you think, rather than You conforming to the mindset of the language you're being made to think in.

This is the difference here and in my experience it's a valuable one.

What you think is an elegant solution in one language is likely a very poor solution in another i.e. classes for instance are a less generalized and so less flexible closures.

[quote author=MyndFyre link=topic=14070.msg143957#msg143957 date=1138745619]
If I am correct in interpreting your above statement about assembly and Lisp, I think you just contradicted yourself.  C++/Java are far better than ASM at abstraction.
[/quote]

You weren't, I was talking above about the quality of jobs available in the languages.

[quote author=MyndFyre link=topic=14070.msg143957#msg143957 date=1138745619]
I think that depends on whom you ask.  That's true for hobbyist programmers.  But even for us, I sometimes make a tool program just for something really quick.  When I do so it's just a tool.
[/quote]

By that thinking a hobbits programmer must also be a bad programmer (at least this is how it sounds to my mind) and this simply isn't true, there are many fine hobbyist's out there. Many better than me :).

You can't use any language without thinking in it, at least not well enough to accomplish anything real or good so I have to insist on this point because it's very important.

Learning your first language wasn't just about memorizing in keywords as you may be able to do now, it was about learning the languages concepts – learning to think in it.

[quote author=MyndFyre link=topic=14070.msg143957#msg143957 date=1138745619]
I disagree again.  I don't think you have to think *in that language*, but it is necessary to be able to deconstruct an algorithm in your mind from the starting point and end point.[/quote]

I'm taking this to mean that you need to understand the algorithm in a general sense, which I agree with entirely. But you need both to think in the language and to understand what you're trying to accomplish, in this case the algorithm.

[quote author=MyndFyre link=topic=14070.msg143957#msg143957 date=1138745619]
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]
typedef unsigned long int COLOR;
[/code]
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.
[/quote]

This isn't expressing a new idea though, you're taking the color example to literally. When I speak of adding new concepts to the language I was talking more along the lines of say adding OOP to a language that didn't support it already using that language, as can be done in Lua.

defining a related type in this way doesn't do anything of value it's merely syntactic sugar. Haskell provides a much richer type system that you may be interested in looking at :).

[quote author=MyndFyre link=topic=14070.msg143957#msg143957 date=1138745619]
So, since C++ and Java are this flexible, we *should* use them?
[/quote]

I thought it was clear I wasn't referring to C++ and or Java here which are at the low end of what I consider flexibility, will be more explicit :).

[quote author=MyndFyre link=topic=14070.msg143957#msg143957 date=1138745619]
Define "worst."  What OOP aims to accomplish, you said yourself:
* Easier maintenance.
* Faster development.
* Presents easier-to-understand abstract objects to us
All of these work in tandem.  You can really screw up an OOP program by, for example, making a class 10 layers deep without meaningful functionality added at each layer.  But I don't think I've ever seen an object more than 4 or 5 layers deep that didn't make sense to have at that place.

It doesn't take a good programmer to make an overbloated windbag of a program.  That's why design is a crucial step prior to the actual coding of a project.[/quote]

I agree that design is important however industry doesn't take into account that this design is done by people, who are liable to make just as many mistakes doing this as they are while implementing the design.

OOP may help to a small extent however it's a feeble hack over anything truly useful against such a large task. A way of limiting damage control and proving without a doubt that your programmers are working... hence all the bloat ;).

[quote author=MyndFyre link=topic=14070.msg143957#msg143957 date=1138745619]
Uhh....  Java not being directly descendent of anything doesn't make up for any flaws present in the initial design of the language, because it was initially designed with polymorphism and "flexibility."
[/quote]

Java while not a direct decedent of anything was obviously influenced by languages before it, to assume it wasn't is just wrong. It's primary goal as expressed by sun was to fix the problems inherent in C++, targeting C++ programmers it made sense to include a C like syntax.

However you can't fix a bad concept by re-implementing it.

[quote author=MyndFyre link=topic=14070.msg143957#msg143957 date=1138745619]
C does NOT have a rigid type system.  C's type system is incredibly weak, in fact; C++ added many more type restrictions.
[/quote]

When taken on its own C's type system doesn't get in the way, you get used to it and when you naturally use what it gives you. When compared to more flexible type systems C doesn't look do loose or so attractive.

I think you may have pegged me wrong on another point, I don't hate M$. Good on them for making a good run of a lucky break however I wont say that they write good software when they obviously don't.

Their personal philosophy is of only a passing interest but they're a bad model to base a company on. Sadly many do.

Hopefully not too offense :),

Mark.[quote][/quote]

[quote author=dxoigmn link=topic=14070.msg143993#msg143993 date=1138749802]
[quote author=Yegg link=topic=14070.msg143989#msg143989 date=1138748494]
IMO, which does not matter at all, because no opinion matters, list manipulation is the most efficient technique for storing data. And I also beliebe that LISP, and languages based off of it (Scheme), use it to its full potential, far more elegantly than any other language. But remember, this is opinion and it does not matter (except to me).
[/quote]

Define efficient, then I'll take up argument against list manipulation being the most "efficient" way of storing data.

LISP and Scheme are nice languages with some very neat constructs, but I am a believer of using the most appropriate tool (language) for the task at hand. Sometimes that is Java, sometimes that is C, sometimes that is Scheme, sometimes that is assembly.
[/quote]

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.

[quote author=Warrior link=topic=14070.msg143987#msg143987 date=1138748260]
[quote author=Yegg link=topic=14070.msg143973#msg143973 date=1138746730]
[quote author=Warrior link=topic=14070.msg143970#msg143970 date=1138746643]
So until someone writes a "Stable" language ...OOP is necessary..
[/quote]

And we have "stable" languages. Take a look at Common LISP and Scheme.
Why should OOP be necessary if there are better solutions?
[/quote]

Stable by what standards? Not by what you think I hope. Not a List programming language or something based of it..cmon..
[/quote]

Why not a Lisp? For over 50 years programming languages have steadily been progressing towards including Lisps feature set. Take modern "scripting" languages (and many other programming languages) for instance, of some 9 features that made Lisp unique only about half have managed to find their way into modern languages as of yet. Why?

Because including these in a language would make it a Lisp, and to paraphrase paul graham: the language designer could no longer claim to have invented a new language, just a Lisp dialect.

Lisp, designed 50 years ago is still ahead of the game in pretty much every way. With a good implementation Lisp code can run as fast as C code and yet has all the advantages of a so called scripting language (which it is not).

It supports multiple paradigms; functional programming seamlessly (as I'll describe in my next reply) and unrivaled extensibility.

Other languages of note being other functional languages such as Haskell and ML, Lua is also interesting in that it's also fairly extensible.

Mark.

[quote author=Yegg link=topic=14070.msg144000#msg144000 date=1138750285]
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.
[/quote]

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.

[quote author=dxoigmn link=topic=14070.msg144008#msg144008 date=1138751738]
[quote author=Yegg link=topic=14070.msg144000#msg144000 date=1138750285]
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.
[/quote]

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.
[/quote]

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."

[quote author=Warrior link=topic=14070.msg143990#msg143990 date=1138748794]
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" ?
[/quote]

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.

[quote author=Yegg link=topic=14070.msg144011#msg144011 date=1138751923]
[quote author=dxoigmn link=topic=14070.msg144008#msg144008 date=1138751738]
[quote author=Yegg link=topic=14070.msg144000#msg144000 date=1138750285]
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.
[/quote]

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.
[/quote]

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."
[/quote]

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.

[quote author=Yegg link=topic=14070.msg144011#msg144011 date=1138751923]
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."
[/quote]

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

[quote author=netytan link=topic=14070.msg144012#msg144012 date=1138752053]
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.
[/quote]

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

[quote author=dxoigmn link=topic=14070.msg144014#msg144014 date=1138752480]
[quote author=Yegg link=topic=14070.msg144011#msg144011 date=1138751923]
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."
[/quote]

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.
[/quote]

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.

[quote author=netytan link=topic=14070.msg144018#msg144018 date=1138753056]
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.
[/quote]

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

[quote author=dxoigmn link=topic=14070.msg144019#msg144019 date=1138753349]
[quote author=netytan link=topic=14070.msg144018#msg144018 date=1138753056]
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.
[/quote]

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

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.

[quote author=netytan link=topic=14070.msg144012#msg144012 date=1138752053]
[quote author=Warrior link=topic=14070.msg143990#msg143990 date=1138748794]
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" ?
[/quote]

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.
[/quote]

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

[quote author=Warrior link=topic=14070.msg144024#msg144024 date=1138753983]
[quote author=netytan link=topic=14070.msg144012#msg144012 date=1138752053]
[quote author=Warrior link=topic=14070.msg143990#msg143990 date=1138748794]
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" ?
[/quote]

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.
[/quote]

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

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.

[quote author=MyndFyre link=topic=14070.msg143957#msg143957 date=1138745619]
[quote author=netytan link=topic=14070.msg143938#msg143938 date=1138744101]
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.
[/quote]
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]
typedef unsigned long int COLOR;
[/code]
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.
[/quote]

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.

[quote]
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.
[/quote]

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".

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.

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

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.