Tag Info

Hot answers tagged

38

You are approaching this from the wrong side. In most companies, management is not responsible for "choosing the programming paradigm", they are (or at least should be) responsible for making the team work efficient. If your whole team is convinced functional programming will improve the speed or quality of your work, it should not be too hard to convince ...


18

The basic data is structured the same in pretty much any paradigm. You're going to have a Student, a Course, etc. whether it's an object, a struct, a record, or whatever. The difference with OOP isn't how the data is structured, it's how the functions are structured. I actually find functional programs much more closely match how I think about a problem. ...


16

To understand why Functional Programming hasn't taken over the world, you have to understand the corporate thinking behind programming language decisions. To pick on Java for a moment: There are armies of programmers available that can write reams of ordinary Java code. This is not true of Lisp or Haskell (or even Scala) programmers. Everyone else is ...


9

When I took my Java class years ago, we were expected to show our solutions to the entire class, so I got to see how people think; how they solve problems logically. I fully expected the solutions to cluster around three or four common solutions. Instead, I watched as 30 students solved the problem in 30 completely different ways. Naturally, as fledgling ...


9

In my (somewhat cynical) experience, having worked for a shop where we did use functional programming, and interviewed at several others: There was always a CTO and other high-level technical people who had experience with functional programming and managed to convince the non-technical executives of it. (And incidentally, these folks are better qualified ...


7

There is one very simple argument, which might at least amuse the management. It is well known that the modern computers are not becoming "faster" like they used to be, because frequency scaling, for now, hit the limit. They increase their potential productivity by adding cores. This implies that to benefit most from this architecture, the programs have ...


7

I would like to stress an aspect that I find important and that has not been covered in the other answers. First of all, I think that the representational gap between problems and solutions can be more in the mind of the programmer, according to their background and to the concepts they are more familiar with. OOP and FP look at data and operations from ...


5

Most functional languages are not Object-Oriented. That does not mean they have no objects (in the sense of complex types which have specific functionality associated with them). Haskell, like java, has Lists, Maps, Arrays, all kinds of Trees and many other complex types. If you look at the Haskell List or Map module you will see a set of functions very ...


4

Although this can be a good idea at one level, you want to avoid passing monads around all over the place if you can. It's easier to read, write, compose, and reuse if you write your functions normally, then modify them into a monadic context as needed: insert x (Buffer before after) = Buffer (x:before) after insertList xs (Buffer before after) = Buffer ...


4

FP does indeed strive for a reduction in the representational gap: Something you'll see a lot of in functional languages is the practice of building the language up (using bottom-up design) into an Embedded Domain Specific Language (EDSL). This lets you develop a means of expressing your business concerns in a way that is natural for your domain within the ...


3

When deciding between throwing an exception or returning an error-code, there are a few considerations to take into account. The primary one is how exceptional is the situation. Is receiving data with voids in them something that should not happen (and an indication that somewhere else something went really wrong), or is that something that your algorithm ...


3

One good approach would be to show that it's shown good results in the industry and adopted. You can get some data from: http://www.quora.com/What-companies-use-a-functional-language-as-an-official-language http://pchristensen.com/blog/lisp-companies/ Ideally, try to talk to the managers at some listed companies, especially if in your industry, and get ...


3

Things to consider for upper management when/if upper management is involved in selecting programming languages (which is odd, they should leave it to trusted, knowledgeable people (both technology and business savvy): Productivity Both current and future employees All roles (architects, developers, testers, OPs, ...) Supported platforms Operating ...


3

There's a survey conducted in September 2014 which shows that Java 8 has already been widely adopted: Survey of More Than 3,000 Developers Reveals Java 8 Adoption Ahead of Previous Forecasts. The report shows that 27% of those who filled out the survey have already upgraded to Java 8, with a further 36% planning to upgrade within the next 12 months (from ...


3

I don't think arguments or facts will help. And certainly not without stating the problems you want to solve. Against common believe and typical self evaluation many decisions are made based on gut feeling. And often these decisions are very good decisions, because they incorporate on a subconscious level a lot of experience of the individual making the ...


2

You're coming at this from the wrong direction. You're trying to convince management of a switch to a functional paradigm for your own amusement and you're trying to rake in arguments to support this that have got nothing to do with the real reason why you want it. Otherwise you wouldn't need to ask the question, because you'd be able to list your arguments ...


2

As Niklaus Wirth put it, "Algorithms + Data Structures = Programs". Functional programming is about the way to organize algorithms, and it does not tell a lot about ways to organize data structures. Indeed, there exist FP languages both with mutable (Lisp) and immutable (Haskell, Erlang) variables. If you want to compare and contrast FP with something, you ...


1

It sounds like the crux of the problem is: For a lot of functions in the dispatch table, they obviously know best how to calculate and return the appropriate value. However, for a few items, it is the caller of the function who best knows the value. What solution you should use depends entirely on why the caller knows best, which you haven't ...


1

I wouldn't call the first approach functional. One of the key aspects of the functional paradigm is to avoid mutable state. So any kind of reassignment is not in the functional style. Once you've defined input is, you wouldn't change it. This might be more functional: const validatedInput = { url: validate(input.url), path: convert(input.path), ...


1

Senior management with no technical skills shouldn't care about technical aspects such as the usage of functional paradigms. This is not their domain of expertise, and smells micromanagement. Why aren't they delegating those decisions to persons who actually have required skills? This being said, here are some hints to convince people with technical ...



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