HN Books @HNBooksMonth

Counterpoint, I wish there were more resources for new languages that assume you already know how to program.

Professional Javascript for Web Developers[1] is a favorite of mine, because it doesn't waste time teaching you to program and teaching you the language. Instead it points out things that will surprise you if you come from C-like languages, and things you need to watch out for.

Now, since I effectively learned to program in C and later C#/Java, ___ for node developers isn't what I'm after, especially if it spends a bunch of time talking about static typing or fixed size arrays and such. But if you're going the opposite way as I did, learning the high level and transitioning to the low level, something like that could be very useful indeed.

[1]: https://www.amazon.com/Professional-JavaScript-Developers-Ni...

⬐ oei829ejenk3

I know it’s not a popular opinion with some, but all code looks like to me anymore is math with whatever symbols the language in question needs to work

For example:

(singleton)

(tu,ple)

def func1(singleton):

def func2(tu,ple):

^ python function declarations

So after 20 yrs of this, I try to keep in mind the math and just look up the bits to wrap it in.

Also, I avoid custom frameworks and all this industry react/angular, or whatever is cool like the plague, by avoiding front end for a while now

But I do consulting which affords me the luxury. Many may not have the flexibility.

I’ve a set of macros in vim to scaffold boiler plate and go from there

Boom, programming in any language

When I do that, I miss the details that can catch you off guard.

If I had done that with Javascript, I can assure you that function based scoping would have destroyed my brain in trying to debug. But since I read a book on Javascript[1] that assumed familiarity with other languages, I was prepared for it.

[1]: https://www.amazon.com/Professional-JavaScript-Developers-Ni...

>Personally, I’m a big fan of simplicity and minimalism in programming language design. I think that smaller languages have the potential to be easier to implement, optimize, teach, debug and understand.

After reading hundreds of blogs and articles about this or that programming language being supposedly "simple", sentences like the above have come to mean nothing.

I wish a had a succinct meme to describe what actually happens in the real world around "simple" languages but the concepts are:

If there's a "small" or "simple" FORMAL language specification, it means there's a "large" INFORMAL language out in the wild. The "informal" will include things like idioms, patterns, macros, code generators, industry practices, "utility" javascript libraries, etc.

For example, take the concept of "classes" that supposedly nobody needs in Javscript (because protoype chains are superior). What is the longest most complicated chapter of Nicholas Zaka's Javscript books[1]?! It's the long chapter on manually simulating classes using prototypes! Same situation with other books that describe home-grown "modules". Even if one chooses to avoid simulated classes in his own js code, one still has to understand the different variations that others write. If classes are not formally specified in the language spec, it's informally specified in everyone else's books, stackoverflow answers, blog articles, and youtube videos explaining js simulated classes. If Javascript had "classes" earlier than ES6, perhaps the over abundance of informal adhoc "class objects" would have been completely avoided.

Another example would be "optional default" function parameters. Since javascript's formal language spec doesn't have a feature for default params, it is "simpler" and "easier to learn". (Hey, if one doesn't have to memorize the keyword "optional", that's one less thing to worry about, right?) Hmmm... really?! Look again more closely.[2] The "optional" feature is simply moved into an idiom (multiple idioms!) that all competent javascript programmers must learn. The "smaller" language hasn't saved any complexity -- it does the opposite -- it made JS usage more complex overall.

Any language that's used for non-trivial purposes will not be "simple" if looked at holistically by combining both the formal and informal real-world uses of it.

However, within that unavoidable complexity, there can be limited subset cases of "simple" for certain scenarios. What does one want a "simple" Javascript language spec for and what can it do? Make the monkey dance?[3] Ok, that's one mapping of "simple" to an end goal and 1995 Javascript specification is probably enough. However, people want to do much more complex apps with Javascript without having to mess around with Typescript, Babel transpiler, etc.

To blog writers: please stop characterizing languages as "simple" without any qualifications of use cases. That adjective is no longer convincing on its own.

[1]http://www.amazon.com/Professional-JavaScript-Developers-Nic...

[2]http://stackoverflow.com/questions/148901/is-there-a-better-...

[3]http://programmers.stackexchange.com/a/221658

⬐ masswerk

JS used to be a language that was easy to understand. Once you grasped the concept of how object references and scopes were handled (which everyone could who invested a few days in understanding the language and read the specs), you were able to understand any of the user-land implementations. Now there are popping up more and more essentially parallel paradigms, mainly to pull some of the user-land implementations back into the language. As a side effect, the language eventually becomes more and more complex, and, as more concepts are integrated, it becomes less obvious, on what kind of tradition a new feature builds. (E.g., there are now two notions of scopes and two notions of object construction and inheritance — and I'm quite confident that we'll see some new features borrowing from both.) As in CISC vs RISC, there are valid arguments on both sides. But there's a lot of cultural change involved, when venturing from a quite spartanic but powerful definition of the language to a multiple concepts definition. Ironically, it will be the user-land implementations, again, that will force everyone into the new notion of the language and there will be no option of avoiding the migration (like sticking to C and avoiding C++, as some have preferred to do in the past). Libraries will be still with us, but it will be more difficult to understand what's really going on, and eventually, the dependency on them will grow. Still, opinions are opinions and there are probably more than two on it as far as developers are concerned.

But there's another side to it: JS is essentially a language to write code to be run on a foreign machine with quite a vague permission to do so. There's an interest in understanding what some piece of code is actually doing, in order to evaluate, whether the permission should actually be granted or not. (E.g., I might prefer not to use a WebApp, if I find me tracked in a way that doesn't conclude with the nature and value of the service. Even, if a free service, the price might be too high. Or, I could find me integrated into some kind of ad-hoc P2P network [WebRTC] that is far exceeding my planned investment in resources and which's use might not converge with my intentions.) The actual chance of doing so correlates with the learning curve of the language used. IMHO this is quite a strong argument for using a language that is both high level (as opposed to Emscripten + ASM) and of a quite scarce formal definition.

⬐ chrisseaton

> What does one want a "simple" Javascript language spec for and what can it do?

To write proofs? You don't need to worry about the larger idiom of how the language is used for that.

And to write a correct implementation of a language you don't need anything except a correct simple spec. To perform well for idiomatic code you may need to know about idiom.

⬐ qznc

> To perform well for idiomatic code you may need to know about idiom.

To enforce idioms you include them in the language. This makes the language easier but less simple. It also means people will use exactly one idiom instead of lots of variants. This improves performance and makes it more predictable.

To perform well for idiomatic code you must know about idiom and have consensus about it and teach it to everybody.

⬐ espadrine

The contrast between simple and complete languages was best (imho) expressed in Guy Steele's convoluted 1998 OOPSLA talk, Growing a Language.

The whole talk is expressed in terms of words of one syllable.

https://www.youtube.com/watch?v=_ahvzDzKdB0

⬐ jasode

I'm familiar with that talk and it's a good one but Guy Steele's main thesis is not showing the difference between small/simple and large/complex.

Instead, his main point is that a successful language can start small and it is inevitable[1] that it will grow into a larger one. Therefore, let's plan on its growth from user feedback. To help the thinking, he defines a sort of "meta framework" for the directions a language can grow. The idea is that the growth can be more systematic instead of a random chaos of adding keywords and syntax (e.g. PHP).

My message is orthogonal from Steele's. I'm saying that evangelizing that a "language X is simple" in terms of a formal language spec is not useful to real-world programmers. The working programmers actually care about holistic simplicity/complexity that combines Formal specs and Informal idioms.

[1](my description not his because he used 1-syllable words)

⬐ phpnode

> If there's a "small" or "simple" FORMAL language specification, it means there's a "large" INFORMAL language out in the wild.

This is exactly right, pushing language features into user-land just leads to a load of competing equivalent solutions that developers must learn. The language is simpler but it becomes harder to actually use.

I'd recommend this one http://www.amazon.com/Professional-JavaScript-Developers-Nic... And also, keep a beginner's mind :)

⬐ hackerboos

Tombstone of a book but it will do the job.

⬐ None

None

What're your goals? It can help to direct you to the best place for what you're looking for out of JavaScript. I think it's useful to learn vanilla JavaScript well before learning libraries and frameworks.

Useful books. The first is online and free (the other two are as well, somewhere): http://eloquentjavascript.net/

http://www.amazon.com/Professional-JavaScript-Developers-Nic...

http://www.amazon.com/JavaScript-Patterns-Stoyan-Stefanov/dp...

Solve toy problems to solidify knowledge of methods and syntax: http://coderbyte.com/CodingArea/Challenges/

Good material- lots of video and problems. Not free but worth it: https://www.codeschool.com/ (makers of the jQuery videos below)

Bootstrap - popular front-end framework: http://getbootstrap.com/

Actually build something! A To Do List, a website, a game.

See some different frameworks do the same things: http://todomvc.com/

jQuery: http://try.jquery.com/

Here is a good free node tutorial: http://nodeschool.io/

Some tracks to learn, and get connected with non-profits to make useful things: http://www.freecodecamp.com/

Contributing to open source projects is another route.

⬐ 404error

Thanks, this is really helpful. My goal is to learn as much as possible about various things to open up more job opportunities.

I can highly recommend books written by Nicholas Zakas.

http://www.amazon.com/Professional-JavaScript-Developers-Nic...

There is one shorter book that he wrote recently: https://leanpub.com/oopinjavascript