I read Kyle's book, and I found it really informative.
But I am a little confused on the discussion in "You Don't Know JS: this & Object Prototypes".
That series say that Object Linking to Other Object design pattern is cleaner and simpler then object oriented design pattern. I do agree with this.
But I notice that many react code snippet prefer using ES6 class keyword which represents object oriented code style.
First and foremost you don't have to teach programmers that you introduce to your project to OOP pattern as it is by far the most popular one and people are used to it. Teaching someone consumes time and money - two things that business value the most.
Second thing would be that it is hard to prove that one programming paradigm is better than the other - especially if you can count on one hand implementations of OLOO when OOP has hundreds of thousands.
Just because something is better (I also agree with Kyle) doesn't mean it will be the most popular choice.
Related
I did a search on this topic, but I do not know what keyword to search for so I post this question.
I wondered why the name reduce was chosen in javascript even though the name has been used, such as fold or accumulate, which is more traditional and meaningful(this is my personal opinion).
I've spoken about this topic with someone close to me (one of the people I know who has been dealing with Javascript for a long time and who has also worked with functional languages like Scheme, Racket, and Clojure). He cautiously speculated that this might be an effect of Python.
If you have any traditional context that I do not know, or someone you know about the background of this name, I would be very grateful if you could answer.
If you look at https://en.wikipedia.org/wiki/Fold_(higher-order_function)#Folds_in_various_languages, you can see that the most common names for this operation are fold, reduce, and inject. reduce is by no means an unusual name. In particular, reduce is used in Perl (which JavaScript copied many features from), and Perl probably got it from Lisp (like many other features). The earliest reference I can find is REDUCE in Common Lisp (which was developed in the 1980s and standardized in 1994).
I'm reading the book Structure and Interpretation
of Computer Programs, and I'd like to code a scheme interpreter gradually.
Do you knows the implementation of the scheme most easy to read (and short)?
I will make a JavaScript in C.
SICP itself has several sections detailing how to build a meta-circular interpreter, but I would suggest that you take a look at the following two books for better resources on Scheme interpreters: Programming Languages: Application and Interpretation and Essentials of Programming Languages. They're both easy to read and gradually guide you through building interpreters.
I would recommend the blog series Scheme from scratch which incrementally builds up a scheme interpreter in C.
Christian Queinnec's book Lisp In Small Pieces is superb. More modern that EoPL. Covers both Lisp and Scheme, and goes into detail about the gory low-level stuff that most books omit.
I would recommend reading Kent Dybvig's dissertation "Three Implementation Models for Scheme". Not the whole dissertation, but the first part (up to chapter 3) where he discusses the Heap-Based Model is very suitable for a naive implementation of Scheme.
Another great resource (if I understood it correctly and you want to implement it in C) is Nils Holm's "Scheme 9 from Empty Space". This link is to Nils's page, and there's a link at the bottom to the old, public domain, edition of the book and to the newer, easier to read, commercially available edition. Read both and loved 'em.
I can give you an overview on how my interpreter works, maybe it can give you an idea of the general thing.
Although the answer is pretty late, I hope this can help someone else, who has come to this thread and wants a general idea.
For each line of scheme entered , a Command object is created. If the command is partial then its nest level is stored(number of remaining right brackets to complete the expression). If the command is complete an Expression Object is created and the evaluators are fired on this object.
There are 4 types of evaluator classes defined , each derived from the base class Evaluator
a) Define_Evaluator :for define statements
b) Funcall_Evaluator :for processing other user defined functions
c) Read_Evaluator :for reading an expression and converting it to a scheme object
d) Print_Evaluator :prints the object depending on the type of the object.
e) Eval_Evaluator :does the actual processing of the expression.
3.-> First each expression is read using the Read Evaluator which will create a scheme object out of the expression. Nested expressions are calculated recursively until the expression is complete.
->Next, the Eval_Evaluator is fired which processes the Scheme Expression Object formed in the first step.
this happens as so
a) if the expression to be evaluated is a symbol. Return its value. Therefore the variable blk will return the object for that block.
b) if the expression to be evaluated is a list. Print the list.
c) if the expression to be evaluated is a function. Look for the definition of the function which will return the evaluation using the Funcall_Evaluator.
->Lastly the print evaluator is fired to print the outcome , this print will depend on what type the output expression is.
Disclaimer:
This is how my interpreter works , doesnt have to be that way.
I've been on a similar mission but several years later, recommendations:
Peter Michaux's scheme from scratch: http://michaux.ca/articles/scheme-from-scratch-introduction, and his github repo: https://github.com/petermichaux/bootstrap-scheme/blob/v0.21/scheme.c. Sadly his royal scheme effort seems to have stalled. There were promises of a VM, which with his clarity of explanations would have been great.
Peter Norvigs lis.py: http://norvig.com/lispy.html, although written in python, is very understandable and exploits all the advantages of using a dynamic, weakly typed language to create another. He has a follow up article that adds more advanced features.
Anthony C. Hay used lis.py as an inspiration to create an implementation in C++:
http://howtowriteaprogram.blogspot.co.uk/2010/11/lisp-interpreter-in-90-lines-of-c.html
A more complete implementation is chibi scheme: http://synthcode.com/scheme/chibi/ which does include a VM, but the code base is still not too large to comprehend.
I'm still searching for good blog posts on creating a lisp/scheme VM, which could be coupled with JIT (important for any competitive JS implementation :).
Apart from Queinnec's book, which probably is the most comprehensive one in scheme
to C conversion, you can read also literature from the old platform library.readscheme.org.
I've noticed many languages like Ruby and CofeeScript (well a transcompiler) support everything being an expression.
Now it makes the language somewhat simple to understand and definitely seems neat at the surface, but I was looking maybe for some scholarly publications about the positives and negatives of the two approaches.
It would be beneficial if the publications had clear examples that compared the benefits of having everything be an expression vs., well, not.
Examples in CoffeeScript vs Javascript would be nice, but not required.
The concept is definitely cool, but I'm still slightly unsure how revolutionary the whole idea really is (obviously something being revolutionary is somewhat an opinion).
Thanks!
There is nothing revolutionary about this per se. The expression-oriented approach is a functional programming technique.
Expression-oriented code is simpler and less cluttered than statement-oriented code, because of fewer assignments and no explicit return statements. The lack of distinction between expressions and commands enables conceptual uniformity (see Referential transparency) and bottom-up structure.
Some modern languages have adopted functional programming concepts (e.g. C#, Python, Ruby).
Some scholarly insight on the benefits of functional practices:
Can Programming Be Liberated from the von Neumann Style? A Functional Style and Its Algebra of Programs - John Backus
Interesting articles:
Why Functional Programming is Important in a Mixed Environment
Is C# becoming a functional language?
As to the comment about performance concerns, the possible overhead related to choice of paradigm is probably negligible. Even in C, most statements evaluate as an expression - however, a comparison between a compiled language (C) and an interpreted language (CoffeeScript) is rather useless.
On a theoretical note, an imperative language represents the control flow in more of a machine-oriented way, which may allow for easier hand-optimization than a functional language.
Language performance and its significance depend heavily on the use case. Concerning JavaScript and whatever code transformation on top of it, this performance discussion is completely irrelevant. The gains in productivity outweigh any slight performance hit.
By "everything is an expression," I assume you mean what is described at http://jashkenas.github.com/coffee-script/
It kinda sounds like what you're asking about are functional languages. Consider, for example, Lisp, which did this sort of thing back in the '50s. This ultimately comes out of the Lambda Calculus, in which code and data are really the same thing, and you can pass code around as though it were data (because it is).
I don't know of any scholarly articles discussing this specifically, but now you at least have some more keywords to search for.
Douglas Crockford makes reference to Simplified JavaScript in this article about Top Down Operator Precedence. Unfortunately he only makes references to it in this article. The best explanation I found here. But I still don't have a clue what it actually is.
What is Simplified JavaScript?
In the context of the Top Down Operator Precedence article, "simplified" means "easier to write a parser for". That is, he wanted to demonstrate how to write a Javascript parser in Javascript, without overcomplicating things by trying to support all the full specfications loveable quirks.
Yes, the features supported in "Simplified Javascript" are very close to those listed as "Good Parts", but the point of that article was not to promote Crockford's world view or book, but to show how to write a language parser (no easy task).
From the article:
We don't have time in this short
chapter to deal with the whole
JavaScript language, and perhaps we
wouldn't want to because the language
is a mess. But it has some brilliant
stuff in it that is well worth
consideration. We will build a parser
that can process Simplified
JavaScript.
This is probably a reference to Crockford's book Javascript: The Good Parts. In this book, he describes which features of Javascript he feels are "good", as well as those that are "bad" and shouldn't be used.
Simplified JavaScript is not quite a language (yet), but it could be. There is Pratt's/Crockford's Simplified Parser TDOP, and that is a first step, but you would need either a code generator or an interpretor to process the parser's output "tree" into working JavaScript. IMHO that will be a good thing. Then an IDE that would help anyone learn and write this proposed language "Simplified JavaScript", will follow.
When should object literals be used in javascript, sometimes I get confused I am trying to apply oop concepts and pattern to the language. I am trying to not just use procedural programming concepts because I know the language has amazing capabilities.
Object literals are most commonly used as:
a type of associative array; and
a way of passing many arguments to a function.
The second is particularly important and common in libraries like jQuery.
That's how they're commonly used. As for when you should use them, that's a difficult question to answer because it's a bit like asking when should arrays be used. Object literals are a tool. They're a means to an end not an end in itself.
The subtext of your post suggests you're trying to imprint some non-Javascript concepts onto Javascript. I see this a lot (particularly where people try and make everything OO in PHP as the most egregious example). Javascript has its own strengths and weaknesses. Play to those. Don't try to make it something it isn't.
One common mistake is that people confuse OO with Classical language design. You really don't want to be thinking in terms of classes when it comes to javascript, you want to be thinking in terms of functions, duck typing, and prototypes.
This may seem obvious but Javascript object literals are also commonly used for data exchange with other systems. JSON after all is just a subset of Javascript object literal syntax.
Object literals also play an important role in JSON. Though it is important to note JSON is language independent.