Tag Info

Hot answers tagged

57

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


46

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


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.


45

I personally find it somewhat sad that functional languages aren't taught as predominantly as they used to be. I think that at the very least comp sci students should be exposed to a language from all of the major paradigms: procedural, object-oriented, functional, and dynamic.


42

Haskell is a completely different way of programming, if you're not used to it. Here's a good free online reference.


33

I think a well balanced CS student should be taught a language in each of the 4 programming language types: Functional - Lisp/Haskell/PostScript. I don't have much experience with Haskell, but I've heard other programmers who do rave about it. Understanding the constructs of functional programming and why they're useful in many situations will help a ...


32

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


27

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


27

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


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

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


26

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


25

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


25

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

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


22

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

I'm going to give a list: Assembly (a relatively simple dialect): It's important to understand at least a little of the fundamentals C: Procedural language, used in many places. Does not burden new students with whole new concepts like OOD all at once. Java / C# / Eiffel / C++: Something Object-Oriented is good, any one of these would accomplish the goal ...


20

If you don't mind leaving the crowded road of hype languages, you can try Postscript/PDF with its stack based programming paradigm. Lisp, Prolog, Occam are other languages with more or less exotic paradigms. APL is known for its unconventional character set. All of these have at best a niche value on the market but they provide fresh air to the brain.


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

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


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

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


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

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


14

Real-time embedded programming is all about the side effects. Interacting with digital and analog io, timers, serial and parallel ports, everything interesting is done by calling functions with side efffects.


14

Very small programs When ever a program does something extremely simple and doesn't last long (think quick command line programs), the overhead of OOP and the OOP spaghetti you must use becomes too much of an overhead. Half your code shouldn't be OOP baggage.


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



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