i love that you can require modules in node.JS functions. Having functions that dont depend on outside variables makes programming so much faster and easier. Being able to name functions also makes the code easy to understand and debug.
Beautiful JavaScript – Functional JavaScript
51–59 of 59 posts
Re: Beautiful JavaScript – Functional JavaScript
#52Earlier quoted context omitted.
OK, so "Haskell > Scheme", or some such. Any specifics beyond "ADTs", which I assume means Abstract Data Types - interfaces/polymorphism. If IDEs ever get good enough to do near complete type inference, including reading through partial function application, and perhaps an "extract/move function" refactoring that converts closures to parameters, most of the class/type bondage and discipline may look a bit like a wast…
> Any specifics beyond "ADTs", which I assume means Abstract Data Types No, I meant algebraic data types, although interfaces/typeclasses are great as well. > If IDEs ever get good enough to do near complete type inference, including reading through partial function application, I don't use any IDEs, but Haskell does this. I imagine various Haskell plugins do as well. > and perhaps an "extract/move function" refactor…
Thanks for the response. Alas, here in "fly-over country" (Sacramento), it's all Java and some Javascript (or .NET, if you've been naughty). There's scarcely any Scala, let alone Haskell work to get or see here.
So, my background tends to be that I'd much rather do JS than Java. The JetBrains IDE's actually do a pretty good job at analyzing JS, despite JS's assumed inferiority. One day Java the language/syntax will be dead, and I will recover from the trauma it has inflicted upon me the last 10 years or so :-)
Fortunately, BS-CS programs still taught other languages beside C -> C++ -> Java in the early 80s, so I at least got to learn some Common Lisp back then (among other things), though not Scheme. Consequently, I'd like to move on from 1960s tech (e.g. - Simula 67) to 70s tech (e.g. - Scheme). Never learned me a Haskell yet. I suppose I should since it's got interesting stuff like currying built into the language itself rather than duct-taped on the side.
Re: Beautiful JavaScript – Functional JavaScript
#53Earlier quoted context omitted.
> Everyone understand JavaScript, so being exposed to functional programming there is not a big deal. (GHC) Haskell and Clojure are pretty big languages, so it's not surprising that learning them requires a lot of effort, but are you seriously suggesting that learning JavaScript (all quirks included) is easier than learning Scheme or Standard ML (all quirks included)? I've honestly tried to learn JavaScript (in depth…
JavaScript has a lot of really weird/bad aspects to it no doubt, but you kind of have to ignore those parts and keep it simple. I actively avoid using "this" and it makes it so much simpler. There are four cases when "this" won't be what you expect, and the only common one is when it's in a callback, so it's not a huge deal, but I think the language is great when you just avoid it and all its other shitty parts.
That's how I feel. It's an otherwise pretty good language saddled with a bunch of misfeatures that the pointy-haired management wanted. (starting with the name itself)
Ignoring this/prototype and just using literals and closures goes a long way in simplifying JS, even if it's not as "performant" (formerly, "fast") at firing off that REST call when the user clicks that button. I'm not in a situation to use something like Node on the server, so I'd rather save my development time than a few nanoseconds of the computer's. (managing load times on web clients seems to be 95% of the bottlenecks for what I'm doing lately)
Re: Beautiful JavaScript – Functional JavaScript
#54Earlier quoted context omitted.
> Everyone understand JavaScript, so being exposed to functional programming there is not a big deal. (GHC) Haskell and Clojure are pretty big languages, so it's not surprising that learning them requires a lot of effort, but are you seriously suggesting that learning JavaScript (all quirks included) is easier than learning Scheme or Standard ML (all quirks included)? I've honestly tried to learn JavaScript (in depth…
JavaScript has a lot of really weird/bad aspects to it no doubt, but you kind of have to ignore those parts and keep it simple. I actively avoid using "this" and it makes it so much simpler. There are four cases when "this" won't be what you expect, and the only common one is when it's in a callback, so it's not a huge deal, but I think the language is great when you just avoid it and all its other shitty parts.
I didn't make any value judgments. Note the absence of the words “good” and “bad” in my previous comment.
Back on the original topic. What I said is that JavaScript is complex, not that it's bad. It may well be the case that JavaScript's complexity is essential for solving the problems it tries to solve. But you can't deny that the complexity exists. And you can't just wish existing language features out of existence, because the meaning of your code is given by what others can do with it.
In short: JavaScript probably has some simple subset. But, then, so does C++, famously.
Re: Beautiful JavaScript – Functional JavaScript
#55Author/editor of Beautiful JavaScript here. I'm very confused by this website. It appears somebody took one chapter (Functional JavaScript) and re-published it as a book.
If you want to purchase the complete book do it from the O'Reilly website or from Amazon. All proceeds go to EFF.
Re: Beautiful JavaScript – Functional JavaScript
#56Earlier quoted context omitted.
Sorry for being an idiot, but when you reducers you don't mean the native .reduce do you?
I'm not even sure it's reducers or transducers. It's mostly a type of functions, not the Array.reduce method. These function don't operate directly, they're meant to be recomposed later by the library. You can [].map(f).map(g).filter(h) and the system will "merge" f, g and h as a one step function that iterate once over the original data and without multiple array allocation. That's my partial understanding, there mi…
I think you're talking about shortcut fusion.
Re: Beautiful JavaScript – Functional JavaScript
#57Earlier quoted context omitted.
Mind sharing the code you were testing this with? I have actually seen map perform better than for loops in Chrome in some cases (see https://www.measurethat.net/Benchmarks/Show/1096/0/map-vs-fo... ).
It's very trivial (this is the bulk of it -- not showing everything to spare people from jumping over a huge message): var f = function f(num) { return num + 5; } var immutable = function immutable(arr) { return arr.map(f); } var mutating = function mutating(arr) { var i = 0; var l = arr.length; for(; i In my actual code, arr is a array of ascending numbers from 1 to 10,000 (different sized array each set of calls).…
Interesting. I did add a return to that benchmark and it didn't seem to affect the results. I would think your test would be identical to mine in performance characteristics, I wonder if it's just the benchmarking methods leading to the difference. I might just go write my own benchmarking like yours since I don't really know what measurethat.net is doing.
It seems intuitively obvious that map would be less efficient, but who knows what V8 is doing to optimize under the hood.
Re: Beautiful JavaScript – Functional JavaScript
#58Earlier quoted context omitted.
"As I’ve often said, and as others at Netscape can confirm, I was recruited to Netscape with the promise of “doing Scheme” in the browser."[0] I guess what you're confusing is that he disclaims that it is inspired mostly on scheme: "I still think of it as a quickie love-child of C and Self."[0] [0] https://brendaneich.com/2008/04/popularity/
«I’m not proud, but I’m happy that I chose Scheme-ish first-class functions and Self-ish (albeit singular) prototypes as the main ingredients. The Java influences, especially y2k Date bugs but also the primitive vs. object distinction (e.g., string vs. String), were unfortunate.» So JS got ideas from Scheme, Self, and Java.
That's what I meant by "mostly". Indeed it does have influence from scheme but it is not "scheme in c clothing" as people have put it.
Re: Beautiful JavaScript – Functional JavaScript
#59Earlier quoted context omitted.
It's very trivial (this is the bulk of it -- not showing everything to spare people from jumping over a huge message): var f = function f(num) { return num + 5; } var immutable = function immutable(arr) { return arr.map(f); } var mutating = function mutating(arr) { var i = 0; var l = arr.length; for(; i In my actual code, arr is a array of ascending numbers from 1 to 10,000 (different sized array each set of calls).…
Interesting. I did add a return to that benchmark and it didn't seem to affect the results. I would think your test would be identical to mine in performance characteristics, I wonder if it's just the benchmarking methods leading to the difference. I might just go write my own benchmarking like yours since I don't really know what measurethat.net is doing. It seems intuitively obvious that map would be less efficient…
Given that they are so close in your example, I was thinking that it's possible that both sides are being optimised out, but that since the map side is smaller, it runs faster (i.e. the optimisation is at run time and so it still has to interpret the code -- smaller code interprets faster).
I haven't had time to revisit this since, but I think it's important. It is also possible that the profiling support in Chromium and Firefox is broken and I would very much like to know that if it is true.