Tag Info

Hot answers tagged

56

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.


43

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


28

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


26

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

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


26

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


25

Even though terminology is far from standardized, a common way to is categorize major programming paradigms into Procedural Functional Logical Object-Oriented Generic You seem to already know what procedural programming is like. In functional languages functions are treated as first-class objects. In other words you can pass a function as an argument ...


24

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


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


24

The main reason FP aims for this and C# OOP does not is that in FP the focus is on referential transparency; that is, data goes into a function and data comes out, but the original data is not changed. In C# OOP there's a concept of delegation of responsibility where you delegate an object's management to it, and therefore you want it to change its own ...


21

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


21

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


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


17

I think you've got a point there, but cp, rm, cd and a lot of others change state, so they aren't really functions. The UNIX philosophy is more about doing only one thing but doing it well; often doing it well means allowing functional usage, but not always.


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

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


14

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


14

The main problem with stack-orient programming languages is that they are conceptually quite difficult for humans to understand. The advantage is that they are very easy for computers to evaluate and generate. Which is why it was chosen for PostScript. It wasn't that long ago that printers only had a very small amount of memory and very under-powered CPUs. ...


14

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


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

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


13

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


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

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


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

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



Only top voted, non community-wiki answers of a minimum length are eligible