Do programming trends just go in circles?

[SlurrerOfSpeech]

Latest buzzwords include "functional programming" and "stateless." What's funny is these are not new, just a reversion from OOP back to procedural programming the way you write code in C. Create objects that are just value bags with no behavior and write functions that modify the values.

Or how about this: Recently I was reading an article by Martin Fowler (the microservice evangelist) and he says that microservice architecture is inconsistent with MVC frameworks and he doesn't believe in MVC. A few years ago, MVC was all the rage.

What this means is that you should program the way that you feel is right. Don't listen to the talking heads.

 

[S.G. Janssens]

Latest buzzwords include "functional programming" and "stateless." What's funny is these are not new, just a reversion from OOP back to procedural programming the way you write code in C. Create objects that are just value bags with no behavior and write functions that modify the values.

While I very much agree that it is good to be critical of hypes and buzzwords, the suggestion that functional programming is (some form of) procedural programming is not at all correct.

(Functional programming was already partially implemented in various Lisps.)

What this means is that you should program the way that you feel is right. Don't listen to the talking heads.

I don't know who the "talking heads" are?

In any case, I believe that it is best to select the paradigm that most closely fits the particular problem you are trying to solve and then solve it in such a way that your solution is readable, and understandable by others who know the paradigm and the language that implements it.

 

[verty]

How can functional programming be a latest buzzword? It hasn't worked out since the 80's. I'm thinking of SICP and books like that that should have led to FP becoming mainstream. But it didn't and it won't and I just don't know why people keep going down that route. Oh well.

 

[QuantumQuest]

Latest buzzwords include "functional programming" and "stateless." What's funny is these are not new, just a reversion from OOP back to procedural programming the way you write code in C. Create objects that are just value bags with no behavior and write functions that modify the values.

The return of functional programming as a part added to mainstream languages (Java, C++ etc.), is around for at least the last six years or so - I mean in wide adoption. Surely, functional programming is not anything new but as @Krylov says, I can't really see what has to do with procedural programming. In order for any programmer to become acquainted with real functional programming, he / she has to deal with pure functional languages and then he / she can use this knowledge to utilize functional features of any mainstream programming language. By the way, the two functional programming languages I recommend is ML and Racket, as two languages of high educational value and also for anyone interested, there is a great course given by Dan Grossman (University of Washington).

Objects as "value bags" are not objects for me in any meaningful sense regarding their real purpose.

Or how about this: Recently I was reading an article by Martin Fowler (the microservice evangelist) and he says that microservice architecture is inconsistent with MVC frameworks and he doesn't believe in MVC. A few years ago, MVC was all the rage.

Microservices, due to their architecture of several loosely coupled services, has several advantages but it is not appropriate for all kinds of applications, so they're not a silver bullet in any way. On the other hand, MVC is present for quite some time and it also have several advantages, again depending on the problem at hand but in general it is a very widely adopted pattern for years.

What this means is that you should program the way that you feel is right. Don't listen to the talking heads.

I agree to the first sentence provided that this is accompanied by a certain level of expertise regarding programmer but for the second sentence, although I don't completely disagree, a word of warning is in order. Putting aside the reasons about why something becomes fashionable or the next buzzword if you will - reasons that are not always in direct correspondence or relevance to the real superiority of a service or product in software development or also in general, in my opinion, we must adopt the better fit for what we're interested at, whether this is old or new. We can listen to talking heads and we can decide according to our knowledge and expertise what it's all about and if this solves our problem(s) or not.

 

[FactChecker]

It's human nature for the newest technology to be over-hyped. Then there is a backlash. That is often because the new technology is applied obsessively in ridiculous ways. The trick is to see the advantages of new technologies in realistic terms and apply them appropriately. This story gets played out repeatedly over time.

 

[S.G. Janssens]

The return of functional programming as a part added to mainstream languages (Java, C++ etc.), is around for at least the last six years or so - I mean in wide adoption.

Yes, I much agree with the idea that the functional paradigm need not be applied in its purest form to be influential.
As far as I know, there are also very few purely OOP languages in mainstraim use.

By the way, the two functional programming languages I recommend is ML and Racket, as two languages of high educational value and also for anyone interested, there is a great course given by Dan Grossman (University of Washington).

Out of curiosity (not wishing to be argumentative - I am not sufficiently informed for that), is there a particular reason why you would recommend ML and Racket over the more purely functional Haskell? Does it have to do with the above? (One of the reasons I am asking, is that in some departments nearby, Haskell is taught to explain functional programming concepts to CS students.)

 

[verty]

Yes, I much agree with the idea that the functional paradigm need not be applied in its purest form to be influential.
As far as I know, there are also very few purely OOP languages in mainstraim use.

Out of curiosity (not wishing to be argumentative - I am not sufficiently informed for that), is there a particular reason why you would recommend ML and Racket over the more purely functional Haskell? Does it have to do with the above? (One of the reasons I am asking, is that in some departments nearby, Haskell is taught to explain functional programming concepts to CS students.)

Krylov, can one have a doubly-linked list in Haskell? If not, I put it to you that that is a serious deficiency of that language, that it can't have useful data structures, and that therefore one shouldn't get tied into it. Scheme at least allowed one to do that.

 

[S.G. Janssens]

Krylov, can one have a doubly-linked list in Haskell? If not, I put it to you that that is a serious deficiency of that language, that it can't have useful data structures, and that therefore one shouldn't get tied into it. Scheme at least allowed one to do that.

I think the suggestion that Haskell cannot have useful data structures is quite strange.
You could google ("Haskell" AND "data structures") or ("Haskell" AND "doubly linked list") in particular.
Here is one from the Haskell wiki.

 

[clive williams-not]

Latest buzzwords include "functional programming" and "stateless." What's funny is these are not new, just a reversion from OOP back to procedural programming the way you write code in C. Create objects that are just value bags with no behavior and write functions that modify the values.

Perhaps it is coming back then ...

I now live in my own isolated R&D bubble of Sentient Artificial Intelligence Development in Cheltenham (UK) and I just stumbled on this nice topic !

My companies used to provide R&D computers and our own innovative Algorithmic AI development languages to GCHQ, IBM, Intel etc in the 1980's.

1974-1979:
We were a typical top team of about forty programming graduates and Metamathematicians at Marconi Avionics in Borehamwood and were developing the real time brain of the Tornado Fighter (MRCA) and at decision meetings we talked all the time about nothing else other than was OOP or Algorithmic coding going to be the best way forward for humans to program - to us it seemed like OOP was coming from more of a graphic design sort of "real objects" concept and that Algorithmic seemed like it was more based on a manifestation of the real-time nature of the universe ... oh these simple times ... Dijkstra et all - ha ha.

So up until then we (coders) had of course all been Algorithmic by way of Algol60 (1960) and its block-structured subsequent languages Coral66, Algol68, and Ada, with the C people on the side doing mainly science and non leading edge real time as per the Pascal people. Really fast real-time was always coded in Assembler where you could use features like scaled natural integer value range overflow to code for any circular metric (such as degrees or radians or a time sequence) without testing for overflow and instead welcoming it as part of the algorithm (i.e. add a tiny amount to a maximum positive value and it becomes a maximum negative value).

However ...in the UK and US Ada was finally adopted (by the MOD/DOD) to replace Coral66 et all and ADA tended away from algorithmic more towards OOP.

So OOP seemed to be winning ... it was also winning in the C world !

So ... in 1979 I left Marconi and set up my own companies to further develop and sell a new ultra-algorithmic computer language that I had been developing for my use in developing Sentient-AI brains (i.e. my sole interest since my Physics degree during 1968 at University in Edinburgh - then a hotbed of AI development).

That language was called "MTR" i.e. Minimal Textual Representation (of an Algorithm) and circa 1980 onwards we sold about 200 compiler licences in the days when compilers could be sold for between £200 and £5,000 each .. so about £200K of sales ... so not enough to sustain a company of six staff ... so we went bust !

NOTHING ELSE QUITE AS BRUTAL AS MTR HAS EVER APPEARED SINCE THEN !

MTR IS/WAS:
1. Ultra Modular (every module is a program - no distinction between a module and a program - mix and match at any level) .
2. Ultra Non-Typed (there are no types - just values with direction - all values are real vectors with a defined destination called signals).
3. No Numbers (no integer signals and an acceptance that no such a thing exists in the universe - just real values known to a certain accuracy).
5. Infinitely Variable Signal Accuracy (each signal has it's very own allowable value range and accuracy - i.e. it's own bandwidth).
6. No Assumed Underlying Technology (analogue or digital system implementations are equally OK as long as we are still in a Turing Machine).
7. No Data (literally only signals moving towards their destinations - static data is by definition is no longer needed in a Turing Machine).
8. Module Authentication (the intended millions of modules all managed and assessed by authentication of prior uses, and outputs, etc).

The result is/was that we could define programs (algorithms) in MTR and literally just press a button and have that program implemented on any computer in any computer language - and it worked - and we supported C, Pascal, Fortran, Assembly, Coral66, ADA, ASICS, etc without the programmer having to know that target language ... this was good ... I could for example target (at the press of a button) my programs written in MTR into C for a PC or alternatively for a Cray in a wide variety of languages that I did not know, after I had written the program !

Sometimes a certain program would run 100x faster in one language/compiler than another ... i.e. depending on how good that compiler & it's target machine were at handling the things that I had particularly used in that program - the key thing being here that I did not know before which language would produce the fastest executable code for that program - in effect the programs written in MTR were "preserved for all time" as there was no assumption made other than that we are in a Turing Machine (which could be a digital computer or an analogue light much faster future machine).

PS ... why on Earth have we not yet perfected general purpose ultra-fast Analogue light photon processing Turing Machines (computers) ?

anyway ... after reading this i will now think about resurrection of Inferix-MTR ... the problem is ... "no money in languages".

btw ... future Sentient AI entities were always intended as the customers for MTR anyway (even in 1968) - i.e. for their AI-entity brains .. as who would want their brain to be locked into one old technology when it could be free if coded in Inferix-MTR to be implemented on any upcoming new technology.

However .. In any case AI now seems disappointingly to be stumbling blindly towards just replicating the human errors of learning (machine learning) instead of leveraging model reference by algorithm (aka post-Kalman models) for which MTR was originally intended - this will be bad for the future of the Universe !

"so it goes".

anyway ... good luck all ... it's all fun ... but life will throw crap at you ... so be forewarned !

 

[wle]

Out of curiosity (not wishing to be argumentative - I am not sufficiently informed for that), is there a particular reason why you would recommend ML and Racket over the more purely functional Haskell?

I was wondering how Haskell compared with Standard ML a while back and found opinions like here. I didn't get the impression one language was unambiguously more interesting than or superior to the other.

For someone who wants to get a taste of functional programming that isn't too theory-oriented, I think probably the main thing Haskell has got going for it is Learn You a Haskell for Great Good rather than any specific language feature. I'm not aware of a similarly accessible tutorial for ML.

I'd separately recommend learning Lisp for reasons that have little to do with functional programming. If you know Lisp and you know basic functional programming concepts (from Haskell/ML or elsewhere) you should be able to pick up Scheme (which Racket is a variant/derivative of) very easily.

 

[SlurrerOfSpeech]

I just remembered another example: "NoSQL" or "non-relational" databases. This is the natural/original idea of a database and now we're going back to it.

 

[QuantumQuest]

Out of curiosity (not wishing to be argumentative - I am not sufficiently informed for that), is there a particular reason why you would recommend ML and Racket over the more purely functional Haskell? Does it have to do with the above? (One of the reasons I am asking, is that in some departments nearby, Haskell is taught to explain functional programming concepts to CS students.)

My recommendation is mainly for programmers beginning functional programming or in any case, not well acquainted with it. I have no argument against Haskell; it's just that I followed this way to essentially recap pure functional programming myself (ML and Racket) when I was in need for it - as I hadn't use functional programming in any professional way for quite a number of years. I did this recap through the course I recommend at Coursera, devoting sufficient time for everything needed (exams definitely included) and my impressions are very positive, so that's why I recommend all this. Now, I'll agree to @wle that - as much as I'm also aware of, there are not so accessible tutorials for ML, like the one he presents in post #10 for Haskell but I think that this is a decent ML book freely available ( Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 United States License). Also, this is a good tutorial for Racket.

Now, all the above, reflect just my personal opinion by knowing the educational value of this approach first- hand. No doubt that another approach through some other functional programming language(s) may work equally well but ML and Racket's set(s) of features are very representative for the gist of functional programming, if worked out patiently and intensively enough.

 

[clive williams-not]

yeaaaa ... I also prefer "flat" databases ... basically just arrays and cubes, and cubes of arrays, and cubes of cubes !

Borland had one just like a cube (i.e. lots of cubes) - for n dimensions - it failed too - everything eventually fails .. yeaaaa ...

But admittedly you could not build or maintain an airliner with a flat non-relational database (well i would not be flying in one) - i.e. a relation database was (and is) a good invention for advanced complex systems and sub-parts identification and also the tools are needed to search and identify revisions - but it's all so complicated - but it's what humans do - we instinctively complicate things to the very limit of human understanding so that only a few can understand and then we stay there in the happy fuzz of half understanding (for most of us) !

PS ... anybody still using Lotus 123 ?

It's still way better than Microsoft Excel !

I am hoping that I am the last person left on the planet using it !

 

[QuantumQuest]

I just remembered another example: "NoSQL" or "non-relational" databases. This is the natural/original idea of a database and now we're going back to it.

Not a silver bullet as well. NoSQL databases have gained popularity due to their scalable structure and their speed, which is a good reason to be used in a large number of applications but there is also a lot of situations where a structured database (SQL) might be preferable, a better fit or even the only way to go. The first very well known reason is ACID compliancy. A second reason has to do with the structure of data: will they change regarding their data types, volume etc. in some remarkable way, so, effectively, does a NoSQL need arise? On the other hand, if we have to store a large volume of unstructured data and / or work using cloud resources, NoSQL databases is the way to go. Also, if a NoSQL database is appropriate for our needs, its use can save us development time.

 

[harborsparrow]

Functional programming is not hype nor fad. It has been available in Java (Scala extensions) and C# for several years now and is widely used by those who have learned what its power can do, and ignored by everyone else.

 

[harborsparrow]

MVC is an important concept in programming. It is not necessary to use any sort of framework to benefit from understanding it. Separating out code which just decides how to display things to users from code which actually has your program intelligence in it is simple good sense. Anyone failing to learn that concept will be a terrible programmer.

But of course, as in any field, people like to blather on about these concepts, and they are definitely overused and overplayed sometimes. There was an MVC craze in programming, credited to webdev frameworks such as Rails, which is silly because Microsoft had been doing MVC type designs in Visual Studio for years before Rails was invented.

Just because some writers blather on doesn't mean the core concepts are buzz words or not of value.

 

[verty]

Just because some writers blather on doesn't mean the core concepts are buzz words or not of value.

I agree but I think you must agree that sometimes the ideas get whittled down until they don't look that much like how they used to. Inheritance, for example, went from something you should use whenever it's convenient to something that should obey Liskov's principle, to something that is best used in recognized patterns. The idea was good, let's inherit functionality, but look how it got whittled down. In a way, good ideas take a long time to become fully tested and we have to be aware of that.

Functional programming had its heyday with languages like Lisp and Logo, and I remember a time in the 80's when Logo was very popular in the media. The idea was that you could do anything, even go to the moon, with a language like Logo. But now we use stuff like Visual Basic and the C languages. It's this idea that I think is bunk, that the world forgot and somehow went backwards, and if we only realize the power of the functional style or monads or closures, we could do so much better.

But I do agree that we have plentiful processing power and memory now, so we don't need the level of control we had over memory allocation or struct packing or whatever it is. We can use higher-level abstractions. But I feel like functional programming is hobbled by the same old problems and it can't shake them.

1. Recursive functions are more dangerous than goto in the sense that it can be not obvious what the result will be and difficult to implement change.
2. Lists are not that great as a data type versus arrays. When they get big, they get slow. Arrays are pretty much the same regardless although they don't work with immutability (do they?)
3. Data structures are a level of abstraction and they don't really fit well into the functional paradigm. I suppose Haskell does attempt this but it's too confusing for me to follow. (The answer to every question about Haskell is yes but the how is the killer.)
4. I think in languages like Scheme, mutability can break things. In Haskell, nothing can be mutated. Perhaps that is an improvement but a bank account for example is difficult to code with immutability. You pass in a bank account frame and get a new bank account frame after the update? Too confusing. How do you handle concurrency then?

Until functional programming can mitigate these issues and do what OOP does well, I will remain convinced that OOP is the thing to learn and do. Speaking of cycles, ideas come and go but the really good ones are honed and shaped and remain effective for years to come. The waterfall methodology for example, it has never officially come back but it is tried and tested and it works. So this is a nuance on the idea of cycles.

 

[wle]

Not that this is really the topic of this thread, but Lisp is a multiparadigm programming language, not a functional language. It supports functional programming better than most languages, although not as well as some languages that put functional programming on a pedestal like Haskell. It also supports procedural programming, OOP, and metaprogramming as well as or better than other programming languages. It has built-in single and multidimensional arrays and hash tables as well as lists and the only really sensible way to use these is to mutate their contents.

Lisp even supports the spaghetti programming paradigm:

(defun factorial (n)
  (prog ((k 1)
         (r 1))
   10 (go 40)
   20 (setf r (* r k))
   30 (incf k)
   40 (unless (> k n) (go 20))
   50 (return r)))

 

[Carpe Physicum]

My favorite is ASP. When MS came out with Active Server Pages (vs dumb lazy ones I guess) we were told how cool it is to mix code and markup. And everyone ran that way. Then MS wanted to push another product, .NET, and then we were told, don't be stupid. Mixing markup and code on the same page is ugly and only backwards coders do it. Use Code behinds, they're what's cool now. Web Forms everybody, web forms. Guess what? MS wanted to push MVC so now web forms are uncool, and we should all switch to...wait for it...Razor! Ya razor is cool, like a knife, like the cool kids back in school used. And mixing markup and code in Razor based pages, now THAT's cool. Btw, go to our conference, buy our book, hire our consultants. Be cool.

 

[FactChecker]

In large programs with managers and government contracts, there is very real danger associated with a new software technology. The people who understand the new technology might make very reasonable recommendations on when and how to use it. But the program management often hates to leave decisions up to the programmers. They write hard and fast rules into the contract and procedures. The result can be a nightmare.