← Back to context

Comment by blain_the_train

7 years ago

Are you suggesting that oop allows programmers to understand the assembly output?

Did you watch the video? The most popular language is JavaScript, which is only not functional but a quirk of history.

The video makes an argument for marketing being the reason.

7 comments

blain_the_train

Reply
goatlover  7 years ago

JS isn't really a functional language, it's an imperative, prototype-based language with partial functional support that allows multiple coding styles, like most of the popular scripting languages.

cr0sh  7 years ago

The fun, and funny, and maybe (probably) even terrible, thing about javascript is that while it -is- functional, and (IIRC) always has been, historically it wasn't originally used that way!

Only relatively recently have programmers embraced its functional aspects; prior to that it was mostly used as a procedural language.

Then people started to used functional aspects of it to "shoehorn" it into allowing a quasi-OOP form of programming style, and this form has been baked (in no small part) into the latest version of ECMAScript.

But people following this path, coupled with (I believe) using JQuery, NodeJS, and other tools (and now React) have led most of them (raising hand here) to more fully embrace it as a functional language.

But here's the thing:

You can still use it as a procedural language - and an OOP language - and a functional language! All at the same time if you want - it doesn't care (much)! It's like this weird mismash of a language, a Frankenstein's Monster coupled to Hardware's killer robot.

Yes - with today's Javascript you can still write a unicorn farting stars that follows your mouse on a webpage while playing a MIDI file - and do it all procedurally. In fact, there's tons of code examples out there still showing this method.

You can mix in simple class-like constructs using anonymous functions and other weirdness - or just use the latest supported ECMAScript OOP keywords and such - go for it!

Want to mix it up? Combine them both together - it don't care!

Oh - and why not pass a function in and return one back - or an entire class for that matter! It's crazy, it's weird, it's fun!

It's maddening!

And yes - it's a crazy quirk of history - a language that was created by a single programmer over the course of a weekend (or so legend goes) at Netscape has and is seemingly taking over the world of software development.

Not to mention Web Assembly and all that weirdness.

I need to find an interview with that developer; I wonder what he thinks about his creation (which is greatly expanded over what he started with, granted) and it's role in software today - for good or ill...

  • nybble41  7 years ago

    > Oh - and why not pass a function in and return one back

    The "function" in "functional programming" is a reference to mathematical functions. Mathematical functions do not have side effects, and consequently are referentially transparent (the result doesn't depend on the evaluation order or on how many times the function is evaluated). Code with side effects is not a function in the mathematical sense, it's a procedure. The defining characteristic of functional programming is the absence of side effects. That isn't something you can just tack on to an imperative (or "multi-paradigm") language. No matter how many cosmetic features you borrow from functional languages, like closures and pattern-matching and list comprehensions, you still have the side-effects inherent in the support for imperative code, which means your program is not referentially transparent.

    Haskell manages to apply the functional paradigm to real-world programs by essentially dividing itself into two languages. One has no formal syntax and is defined entirely by data structures (IO actions). This IO language is an imperative language with mutable variables (IORefs) and various other side-effects. The formal Haskell syntax concerns itself only with pure functional code and has no side effects. IO actions are composed by applying a pure function to the result of one IO action to compute the next action. Consequently, most of a Haskell program consists of pure code, and side-effects are clearly delineated and encapsulated inside IO data types at the interface between the Haskell code and the outside world.