Live data from Hacker News

Interview with Douglas Crockford

evrone.com

61–70 of 107 posts

Re: Interview with Douglas Crockford

#61

Earlier quoted context omitted.

I'm not a academic nor hobbyist but work professionally with JavaScript for more than 10 years. I'm also "against" the constant syntactic sugar that gets added with little to no benefits, just leading to JavaScript having a large syntax. Why introduce "classes" which are just sugar on top of existing syntax? Many examples just like this, where sometimes it feels like JavaScript has changes just to have changes. Altho…

To take your argument to the extreme, why have for loops, when then are syntatic sugar over while loops? I'm generally a fan of syntatic sugar in a language if it's purpose is to simplify what's already there; but it is a balance between developer productivity and ease-of-use. I once saw javscript described as 'pithy', becuase of it's small syntatical footprint, that's probably not true so much now.

Indeed. Just as with real sugar, a little syntactic sugar is great, but too much is icky.

Re: Interview with Douglas Crockford

#62
post #10

I thought this part was rather interesting: > Evrone: You spread the idea that developers should read each other's code regularly… > Douglas: In filmmaking, there is a time in the morning called "dailies", when the previous day's footage is examined. It looks like everyone is just sitting around watching movies and wasting time, but it is critically important in finding problems early and assuring the quality of the…

If you hear advice that’s not prefixed with “we started using it X ago and works great…” - be sceptical as default.

Re: Interview with Douglas Crockford

#64

Earlier quoted context omitted.

"The best thing we can do today to JavaScript is to retire it." I think that's a pretty interesting statement from somebody like Douglas Crockford. Not disagreeing; but still ... I think there are two ways of looking at recent changes in Javascript. Either it's progress or it's just not enough progress. I think what he is saying here is that there it has too much baggage and that there are newer and more interesting…

Javascript has GC and tail calls, and I don't think WASM is getting either anytime soon.

I'm not sure about other engines but V8 the most popular JS engine does not implement tail calls.

Re: Interview with Douglas Crockford

#65

Earlier quoted context omitted.

"The best thing we can do today to JavaScript is to retire it." I think that's a pretty interesting statement from somebody like Douglas Crockford. Not disagreeing; but still ... I think there are two ways of looking at recent changes in Javascript. Either it's progress or it's just not enough progress. I think what he is saying here is that there it has too much baggage and that there are newer and more interesting…

Javascript has GC and tail calls, and I don't think WASM is getting either anytime soon.

Isn't not efficiently implementing tail calls a current JS standard (in that implementing them means your implementation is technically broken) specifically to prevent software from relying on that optimization?

Re: Interview with Douglas Crockford

#66

Interesting. I had no idea he had transitioned from promoting Javascript's good parts to calling for its retirement. I started to get a bad feeling when the class keyword became popular, but all of the old good parts are still there.

> I started to get a bad feeling when the class keyword became popular, but all of the old good parts are still there. I actually like many of the new parts - the class keyword being a notable exception. The other (much much milder) exception is async/await syntax - I love Promises but the async/await sugar on top of it this seems a little too much like magic. At the end of the day, they're still just Promises, just…

I think async/await could perhaps have been better used as more general threading primitives to shift the language more toward multithreading. I do like them in comparison to raw promises though.

Re: Interview with Douglas Crockford

#67

Im the article there is a Google Trends of JSON vs XML: https://trends.google.com/trends/explore?date=all&geo=US&q=x... I'm curious about what caused the sudden down peak?

JSON is much easier to parse with your eyes and there isn't much of a performance difference anymore..

With SIMD JSON parsing, I'd be very surprised if JSON weren't MUCH faster to use than XML. Smaller payloads also translate into less time over the wire too.

Re: Interview with Douglas Crockford

#68

Retire all the things. What makes this industry so…cyberpunk, is that nothing entirely goes away. Linux is probably the last time something was really built from scratch. Most commercial software in use today is dependent on code written in the 80’s and 90’s. So, yes, there is a need for new software to match the new paradigms, but the task of starting from scratch is colossal.

> Linux is probably the last time something was really built from scratch. Linux was started in 1991. Windows NT (whence Windows XP and modern Windows versions derive from) dates from at least 1993 (I don't know when the code internally started, but the first release was 1993). For browsers, Firefox source code originates from Netscape 6, which was a rewrite from scratch and shared little to no code with Netscape 4 o…

Maybe so for Windows NT, but Linux 1.0 was released in 94. It feels strange because I was on the mailing list when Linus announced his project, and I had just gotten out of college when 1.0 became official.

And yes as well on anything serious that deals with modern CPU architectures.

But my point was that the old stuff has not been replaced, it’s still out there and often times you don’t have to dig much to find it. Particularly at the OS level, in memory management, multithreading, networking stacks and hardware drivers.

So the jungle simply becomes more diverse and nothing ever gets retired.

Lord, I came across a jumble of Perl code just a few weeks ago.

Re: Interview with Douglas Crockford

#69
post #10

I thought this part was rather interesting: > Evrone: You spread the idea that developers should read each other's code regularly… > Douglas: In filmmaking, there is a time in the morning called "dailies", when the previous day's footage is examined. It looks like everyone is just sitting around watching movies and wasting time, but it is critically important in finding problems early and assuring the quality of the…

We tried this in a team a few years ago, and the problem we faced was developers literally falling asleep during readings. We found that the Team wasn't really engaging with the process and instead just tuned out until it was their turn. That doesn't mean I think Crockford's "Dailies" model is a poor one, it's just one issue to be aware of. Though I often find the same in Scrum teams. Folks aren't listening, they're…

This has been common in the scrum ceremonies I've participated in in most of my career. The standup is primarily for keeping your manager up to date on how things are going with your estimates and maybe for asking for help from a coworker with a blocking issue.

I think what Crockford outlines here would be fantastic if it worked. Multiparty code review.

Post reply on HN