I've spend a good day trying to find out a confirmation to this quote, "Some object-oriented languages are not sufficiently modular and require recompilation of superclasses when compiling subclasses."
I've found it in this article where author was talking about OO languages flaws.
I'm trying to find any information regarding this topic. I tried to google, "Recompilation of superclasses when subclass is changed", "compilation process", and many more.
I'm aware of C++ preprocessor/compiler/linker model and i totaly get it. But how about Java, Python, Ruby, Php, smalltalk and so forth.
What language is not sufficiently modular, as the author says?
Related
By searching I have found a similarity that is both import libraries. But unable to point out any other similarities, as everywhere I can see only differences.
Scripting languages are programming languages. Most of the programming languages in use today that once deserved the "scripting" label are complete programming environments from the syntactically, semantically, and library-wise.
At some point "scripting language" may have been used for languages that were suitable only for writing short scripts, but today any language that doesn't require a complex compilation step to run and that provides a read–eval–print loop (REPL) is considered good enough for scripting.
I'm currently working on a project for my class. I'm building a compiler with Flex (lex) and Bison (YACC) and C. I have done just a little bit of semantic an syntax analysis but i have been thinking how im going to implement the object oriented part. That is, how can I handle classes, overloading, polymorphism and heritage.
I can't seem to find something useful on google and the dragon book its just too low level. I mean too focused on building a compiler from scratch. So I was hoping that someone could point me to a good book, tutorials,example, something that can help me to clear my doubts.
Thanks in advance for the help, and im sorry if someone thinks this is asking to have my homework done.
I agree with the first comment that this question is far too broad to be answered. But I'll try anyway.
There are several aspects to your question:
What are the semantics of the commonly used concepts of object-oriented programming?
How can they be implemented in a compiler?
How are they usually implemented in other compilers?
What are good resources for further studies?
Semantics
Varies widely between languages and there also is quite a bit of confusion/controversity about what OOP actually means (a nice presentation on that topic: http://www.infoq.com/presentations/It-Is-Possible-to-Do-OOP-in-Java which also has some examples of implementing OOP-features). Just pick one model and look up a reference that defines the semantics such as a language specification or a scientific paper on the model.
Javascript probably is the easiest model to implement as it very directly maps to the implementation without much of a necessary surrounding framework in the compiler. A static version of the Java model (compile time class compilation instead of runtime classloading) shouldn't be too hard either. More sophisticated models would be C++ (which allows multiple inheritance) and Smalltalk or Common Lisp/CLOS (with Meta-object-protocols).
Possible Implementations
Again a wide range of choices. As the semantics are fixed and mostly rather straightforward the implementation effort most strongly depends on the performance you want to archive and the existing infrastructure of your compiler. Storing everything in lists and scanning them for the first entry that satisfies the rules probably is the easiest implementation.
Usual Implementation
Most programming languages out of the Java/C#/C++ area do static compile-time name/signature lookups to find the definitions of the things referred to and use a http://en.wikipedia.org/wiki/Virtual_method_table to resolve polymorphic calls. They also use the Vtable pointer for instanceof-checks and for checking down-casts.
Resources
While only 30 pages are directly concerned with objects I still think Lisp in Small Pieces (LiSP) is a great book for learning to work at that level within a compiler. It focusses on implementing language features, trade-offs in implementations and fitting the pieces together. (if (you can get over the the syntax used) (it's great)).
I'm thoroughly intrigued by Scheme, and have started with some toy programming examples, and am reading through Paul Graham's On Lisp.
One thing I haven't been able to find is a book or website intended to teach Scheme to "OO people", i.e. people like myself who've done 99 % of their coding in c++/Java/Python.
I see that closures are sort of object-y, in the sense that they have local state, and offer one or more functions that have access to that state. But I don't want to learn Scheme only to port my existing habits on to it. This is why I'm learning Scheme rather than Common Lisp at the moment; I fear that CLOS might just serve as a crutch to my existing OO habits.
What would be ideal is a book or website that offers case studies of problems solved in both an OO language, and also in Scheme in a Schemey way. I suppose I would most appreciate scientific computing and/or computer graphics problems, but anything would do.
Any pedagogical leads would be much appreciated.
I doubt CLOS would serve as a crutch for old habits, I found it to be pretty different from the OO style in C++/Java/Python, and very interesting. I don't understand all the details, but I would recommend Peter Seibel's Practical Common Lisp. If you are reading On Lisp without much trouble, you should be able to dive into the chapters introducing CLOS in PCL. Also, I'd recommend his Google Tech Talk comparing Java and Common Lisp.
Here's a few more recommendations to make this a more full-fledged answer:
The classic text Structure and Interpretation of Computer Programs covers quite a few examples in chapter 3 of building modular systems using closures (and addresses issues with introducing state and mutability). Chapter 2 includes some generic and data/type-directed programming which could be helpful for motivating study of CLOS. This book really needs no introduction though, it's a towering work, and I've only been reading it slowly since the spring. Highly recommended if you are interested in Scheme.
While SICP is a great book, it's not without its flaws: A really interesting look at these is the essay "The Structure and Interpretation of the Computer Science Curriculum" which elaborates on a few criticism of SICP, and is written by the authors of How to Design Programs (I haven't read HTDP but I hear it's very good). While this essay won't teach you specifically what you are looking for - comparing functional and OO programming - it is really interesting anyway. Their freshman undergraduate course starts with a first semester introduction to functional programming using Scheme (I think, PLT/Racket) and is followed by a semester of OO programming with C++ or Java... at least that's the course they describe in the essay.
These slides from Peter Norvig address some of the design patterns common in OO programming and show why they are missing or unnecessary in dynamic, functional languages like Scheme and Lisp: http://norvig.com/design-patterns/
I cautiously recommend the book by the same authors as the Little Schemer books: A Little Java, A Few Patterns. I can't say for sure if this is a really a good book or not, it was incredibly strange and there are some really bad typesetting decisions (italic, serif, variable-width, superscript doesn't belong in a text on programming), but it might be interesting to take a look at. You can probably find it cheap, anyway. Don't take this recommendation that seriously. I think it would be better to stick to the Scheme texts.
p.s. I have to disagree with one comment stating that functional programming is not as complicated at OO programming, I think that's grossly misstating it. Functional programming in all its breadth is truly mind-boggling. When you go beyond map/filter/reduce and first-class functions, and take a look at other things in the functional realm like lazy evaluation, avoiding side effects and mutation, and the strong, static-typed languages, it gets pretty interesting, and is certainly just as complicated as traditional OO programming. I've only just scratched the surface myself but have discovered a great deal of new ideas. Programming is complicated business, whether OO or functional.
Congrat you, my friend ! Love cs, love functional programming.
If you are python developer it takes 3-4 days to think in scheme
Here is the best simple tutorial I have ever met http://www.shido.info/lisp/idx_scm_e.html
I found this course http://cs.gettysburg.edu/~tneller/cs341/scheme-intro/index.html and it may be useful for you
One beginner's resource that is very helpful and geared very much toward the casual reader is "The Adventures of a Pythonista in Schemeland". It's written (obviously) from the point of view of a Python programmer taking first steps with Scheme. One especially nice thing about it is that it includes an overview of the current implementations and compatibility issues between each scheme implementation, which, unfortunately, can cause some headaches when you're just starting out.
With regards to object systems, these two documents (linked from here) give nice examples of very simple toy implementations using closures that I found helpful in understanding their use in capturing state.
If you are starting off with Scheme, have a look at How to Design Programs. This book presents the "Schemey" approach to problem solving. I don't think there is a book that compares OO and functional solutions to the same programming problems. But there is a nice presentation that shows how dynamic languages like Scheme could provide simple solutions to problems that demand complex design patterns in statically typed OOP languages.
OOP is probably the most used programming paradigm in today’s software design. My question is – what other paradigm(s) can compete with it and can stand in the place of OOP? To clarify that question, I’m not asking about what other paradigms there are. There are many of them, but I’d like to know which one…
Has been used in practice, not only in theory.
Can compete with OOP, so it can be used in a large project with a minimum of pain.
Can be used to develop a desktop app with business logic, databases, and so on.
Is not used alongside OOP, but as a replacement for OOP.
And if there is any, what are the pros/cons of it, why it is better/worse than OOP, what languages are the best to use it, what about using it in popular languages, has it any design patterns, and can it totally replace OOP?
Functional programming is another programming paradigm that is popular, mostly in academics. The best example of a functional programming language is Haskell and Standard ML.
The fundamental difference between functional programming and object oriented programming is that you are programming in the sense of data flow instead of control flow. See the presentation Taming Effects with Functional Programming by Simon Peyton-Jones for a good introduction.
A good example of functional programming used in the industry is Erlang. It is mostly used in telecommunication, distributed and fault tolerant systems. See the presentation Erlang - Software for a concurrent World by Joe Armstrong.
There are also newer functional programming languages that combine functional programming with OOP. Two good examples are F# for the .NET platform and Scala for the Java platform; they can often use existing libraries on the platform written in other languages.
The trend of new programming languages now is Multi-paradigm, where multiple paradigms like object oriented programming and functional programming are combined in the same language.
Procedural processing was everything before OOP turned up, has produced some large real world applications (in fact, most of them originally) and many operating systems.
It can certainly be used in large scale products with a minimum of pain, and a maximum of performance
First of all please note that many of the programming languages currently in use (especially "higher level languages") are multi-paradigm. That means you are never building programs which are purely OOP (except if you use Smalltalk or Eiffel to build your big projects maybe).
Have a look at PHP for instance:
Has many elements of OOP (since version 5)
Was mostly procedural before
Has elements of declarative programming (e.g. the array functions)
Implemented many elements of functional programming (since version 5.4)
Basically PHP is gluing a lot of different paradigms together (and is a "glue language" itself).
Also Java implements a lot of concepts which are not from the Object-Oriented paradigm (e.g. from functional programming).
Have a look on the list of programming languages by type in Wikipedia: https://en.wikipedia.org/wiki/List_of_programming_languages_by_type#Imperative_languages (not 100% accurate).
Functional programming (subset of declerative programming)
Wideley used in practice (it became part of glued languages like PHP, also Java and many others have implemented concepts of functional programming)
Many ideas originate in LISP which is definitely worth a look
You can build whole applications e.g. with Haskell therefore it can "replace" OOP
Procedural programming
C (as a mostly procedural language) is still one of the most widely used languages
Many modern glue-languages were procedural in the beginning
Still many programs are mostly procedural (so if you want it can "replace" OOP)
Logical programming
Most prominent example is Prolog. This is used for specific tasks that benefit from rule-based logical queries
Can not "replace" OOP in terms of building a large project but may replace it in other terms
Declarative / Domain-specific languages in general
Using SQL in your projects? Then they are not purely OOP, SQL is essentially declarative.
Many domain-specific languages (like CSS) are declarative
Imperative programming in general
Tons of applications are not "object-oriented" but simply written in imperative style (e.g. assembly)
Look here for a great thread: https://softwareengineering.stackexchange.com/questions/117092/whats-the-difference-between-imperative-procedural-and-structured-programming
This list is not complete it shall just give an idea. Just note that you usually are using a lot of different paradigms when writing a big application and even each language you are using is implementing multiple paradigms.
OOP is usually considered a good choice for structuring large, complex relationships when modelling data. It is not always the paradigm to go with for many other tasks.
Vector Relational Data Modeling is used to create executable information models with domain relevant semantics within the Global Information Network Architecture, a network resident model broker.
FP - Functional Programming is an extremely popular programming paradigm that has been around for a very long time and has, in more recent years, started becoming more and more prominent. FP favors immutability over mutability, recursion, and functions with no side effects. Some examples of popular fp languages are Erlang, Scala, F#, Haskell and Lisp (among others).
There are no paradigms currently that can genuinely replace OOP. The issue with (benefit of) OOP is that it does a vast amount of work for you- automatically releasing resources, validating data, etc, and it makes it easy to validate code- not to mention that the vast majority of the world's existing libraries are written in an OOP language like C++, C# or Java. The reality of getting along without such large-scale libraries and such is exceedingly doubtful.
In niche or academic worlds, you'll find a lot of Functional Programming. However, if you really want to do a large project, OOP is the only way to go.
I think that generic programming is going to come up as a new paradigm. However, it's really still in the development phase and only C++/D offer genuinely good generic programming.
In my ongoing effort to quench my undying thirst for more programming knowledge I have come up with the idea of attempting to write a (at least for now) simple programming language that compiles into bytecode. The problem is I don't know the first thing about language design. Does anyone have any advice on a methodology to build a parser and what the basic features every language should have? What reading would you recommend for language design? How high level should I be shooting for? Is it unrealistic to hope to be able to include a feature to allow one to inline bytecode in a way similar to gcc allowing inline assembler? Seeing I primarily code in C and Java which would be better for compiler writing?
There are so many ways...
You could look into stack languages and Forth. It's not very useful when it comes to designing other languages, but it's something that can be done very quickly.
You could look into functional languages. Most of them are based on a few simple concepts, and have simple parsing. And, yet, they are very powerful.
And, then, the traditional languages. They are the hardest. You'll need to learn about lexical analysers, parsers, LALR grammars, LL grammars, EBNF and regular languages just to get past the parsing.
Targeting a bytecode is not just a good idea – doing otherwise is just insane, and mostly useless, in a learning exercise.
Do yourself a favour, and look up books and tutorials about compilers.
Either C or Java will do. Java probably has an advantage, as object orientation is a good match for this type of task. My personal recommendation is Scala. It's a good language to do this type of thing, and it will teach you interesting things about language design along the way.
You might want to read a book on compilers first.
For really understanding what's going on, you'll likely want to write your code in C.
Java wouldn't be a bad choice if you wanted to write an interpreted language, such as Jython. But since it sounds like you want to compile down to machine code, it might be easier in C.
I recommend reading the following books:
ANTLR
Language Design Patterns
This will give you tools and techniques for creating parsers, lexers, and compilers for custom languages.