Hi all, I have tried googling but could not find an answer to this question.

Relational Databases are based on Relational Algebra. Do programming languages have any such Mathematical concepts behind them? I know about the formal languages but besides that- e.g.,Does OOP have any mathematical basis? [ July 09, 2008: Message edited by: Padmarag Lokhande ]

The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus

This is like asking why does Computer Science undergraduates "must" study discrete math and maybe calculus to balance things out?

Set theory stuff is indeed part of discrete math, along with graph theory, logic etc. Even the a for loop require math especially outputting complex stuff with collections say, which sometime does make me loose count of the index.

I think the point is that there is no mathematical model for how OO languages work in principle - that is, there is no mathematical model behind the principles of inheritance, polymorphism etc. As a consequence, you can't really apply mathematical theorems to reason about the correctness of your OO code.

This is quite different for other programming languages such as Prolog and many functional programming languages, which have a very strong mathematical foundation.

Well most of the formal studies of type systems (which form the basis for inheritance systems) do get to the level of formal proofs. The LSP for instance came out of this kind of analysis...

"object-oriented" is an adjective that is used to describe the "style" of the programming. It is a design concept. There can be good designs, bad designs, and very bad designs. There are no mathematical principles that can verify if a design is good or better or worse.

UML or flow charts don't have any math involved. But it does require logic of how the intended program should work (or flow), which is common sense for the person who designs the program.