Hot answers tagged paradigms
47
I was a professor and, just like programmers, professors are always looking for the Next Big Thing. When they think they've found one, they make it a bandwagon, and everyone piles on. Since they are preaching to students who think professors must be really smart, else why would they be professors, they get no resistance.
Functional programming is such a ...
45
The problem is that most common code inherently involves state -- business apps, games, UI, etc. There's no problem with some parts of an app being purely functional; in fact most apps could benefit in at least one area. But forcing the paradigm all over the place feels counter-intuitive.
38
I suggest learning both, Haskell first, then Common Lisp. My experience with Haskell was that the static typing seemed to be a restricting annoyance at first, but once I got used to it, I noticed that most of my type errors had logic errors hiding behind them. When you get to this point, and the next milestone, which is learning to think in types and define ...
27
I would say that one of the reasons that functional programming is not more prevalent is the lack of knowledge base. My experience is that corporations are very risk averse in terms of implementing technologies that are not main stream and would rather invest in tried and true frameworks (java, c++, c#). It's only when there is a business need (like in ...
26
It is easier to list domains for which OOP fits well. There are not that many. All the other domains can't be properly expressed in terms of OOP.
To name a few exceptionally unfit areas:
Compilers - representing ASTs and graphs; Pattern matching does not go well with OOP.
Most of the numeric and symbolic mathematics - functional approach fits better.
...
25
One of the major innovations in FP that has resulted in the "explosion" of interest is monads.
In January of 1992, Philip Wadler wrote a paper called The Essence of Functional Programming which introduced monads into functional programming as a way to deal with IO.
The major problem with pure, lazy, functional programming languages was utility in ...
24
The main thing to keep in mind is that good practice in procedural code is very similar to good practice in OO code, you just have slightly different tools to get there with.
You should still be thinking in terms of building your program out of clearly thought out and well-isolated data types with clearly defined sets of operations on each one -- the ...
23
AND please.
Haskell teaches you the purest of FP, as far as I'm aware at least, just like Smalltalk teaches the purest of OO. (I mention this not to suggest that OO and FP can't marry, but because both these languages are "gem" languages - a core idea taken to extremes.)
Lisp is really a family of languages, so I'll talk about Common Lisp because that's ...
22
Because the biggest problem in software development these days is the ability to manage complexity. This is not the focus of most functional programming languages. As such, languages that do make that a priority (namely the more popular OOP languages) tend to just steal some of the cooler features that come out of the more academic functional languages and ...
20
The problem with functional programming isn't functional programming itself -- it's most of the people who do it and (worse) most of the people who design languages in which to do it.
The problem stems from the fact that despite being very smart (sometimes downright brilliant) far too many of the people are just a little too fanatical about purity, ...
19
The term "orthogonal" comes from maths, where it has a synonym: "perpendicular". In this context, you could understand it as "the two things have nothing to do with each other."
When people compare FP and OO they often confuse two separate axes.
On the one hand you have functional programming versus imperative programming. Jonas gives a good comparison of ...
18
Many of the terms can be reused (often miss-used) about programing languages especially those other than Object oriented ones.
Here are some small descriptions on the terms.
Imperative programming -
In good old days, when programming was broadly in assembly, code would have tons of GOTOs. Even higher level languages like FORTRAN and BASIC begun to use ...
16
If OOP is the only paradigm you know, maybe you should learn more. But really, what's OOP actually mean? Does it mean Java or C++? Does it mean Smalltalk? Does it mean settable value slots and closures? (Hi, Scheme!) Does it mean message sending? (Hi, Erlang!)
In short, it seems an uninteresting question to ask. "Is OO useful?" is a better question. And, ...
16
A few reasons I can think of, off the top of my head:
The traditional web stack is pretty mature these days; modern browsers have very few quirks left, and designing web sites for them is relatively pleasant, compared to a mere 5 years ago
While there are differences between browsers, they are less relevant than differences between the underlying OS and ...
14
I recomment using Test-Driven-Development, it takes some getting used to especially when working with a good IDE such as eclipse, but the advantages are great.
Basically what you do is write the tests to your code before you write the code itself. So you are forced to look at your code from the point of view of how it will be used, which means your ...
13
In the late 80ies/early 90ies computers became powerful enough for Smalltalk-style OOP. Nowadays computers are powerful enough for FP.
FP is programming at a higher-level und thus often - while more pleasant to program in - not the most efficient way do solve a certain problem. But computers are so fast that you don't care.
Multi-core prorgamming can be ...
13
From experience, I never found a situation where OOP is not appropriate, but I did found places were overused or misdesigned OOP was not appropriate. OOP, deep down and roughly put, is syntactic sugar and a code organization schema. Overusing it may, in some cases, trigger a sense of frustration and complexity that is uncalled for. You may point out that ...
13
Holy * * * *. There is no silver bullet. Step down. Relax, take a deep breath.
Just because you have a tool in your toolbox, it doesn't mean you are bound to use it. Concentrate on the task at hand, i.e. writing a program that works, and refactor when code smells bad. Don't encapsulate and abstract every little detail just because it might change some day ...
12
Yes, every programmer should learn new languages, and particularly languages that uses a different programming paradigm e.g. functional programming or concurrency oriented programming.
Even if you will not use the language, you will be a better programmer in the language you use by learning different concepts and see alternative solutions.
There is an ...
12
I think that the reason functional programming isn't used very widely is because it gets in your way too much. It's hard to take a serious look at, for example, Lisp or Haskell, without saying "this whole language is one big abstraction inversion." When you establish baseline abstractions that the coder can't get beneath when necessary, you establish ...
12
You can pick up F#. It is .NET functional language, which will allow you to use Visual Studio and reuse a lot of your .NET knowledge. It's assemblies of course integrate with C# assemblies seamlessly (allowing you to easily combine C#, C++/CLI and F# in one project). F# support comes with VS Pro or better, I'm not sure whether it is enabled by default ...
12
One major problem is that if you start with a language like Haskell everything else will seem just substandard.
Honestly I think starting with a language like Haskell or scheme would be a great idea.
(I admit I am functional language addict)
EDIT:
OK what I like about both languages:
Scheme takes a very simple language and build out of it a ...
12
If you havn't read the C programming language yet then I recommend you read that book.
It's a great introduction to C and learning C is a great way to learn procedural code.
I havn't read C traps and pitfalls myself, but this should show you good procedural code patterns and show you shouldn't write bad C code.
Note that there is a lot of overlap between ...
12
Obviously you can do functional programming in C. In theory, you can also learn functional programming principles in C, but the language doesn't make it easy.
I assume you have at least a bit of a background in OOP; if you do, you should be aware that OOP can be done in C, including polymorphism, getters/setters, visibility rules, etc. etc., but it's fairly ...
12
For the previous take, see Revision 1 of this answer. However, the comments and edits to the question further clarify what the question is seeking and allow me to be more clear.
Yes, evidence based software engineering (EBSE) is a thing. There appears to be a few efforts toward EBSE databases, such as this one at Durham University and SEED, which was ...
11
Applications that are very stateful in nature. Video games are a good example because they model the real world. It makes much more sense to think about modifying the state of the world instead of rebuilding from the previous state every time something changes.
A concrete example would be changing the health of a monster after it gets shot. It's a lot more ...
11
Functional programming is definitely starting to catch on - slowly but surely.
For example, the startup I am building is using a functional language (Clojure) as the primary development language for the following reasons:
Productivity - learning FP is hard, but once you get the hang of it it is very hard to beat in terms of power and expressiveness. I'm ...
11
IMHO one, would consider refraining from OOP, and look towards plain structured C for instance, would be in projects where constraints are imposed e.g. memory constraints in embedded systems for example or real-time constraints.
In this case one would weight the "overhead" of polymorphism and virtual inheritance to gain as much possible.
Having said that, ...
Only top voted, non community-wiki answers of a minimum length are eligible
