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.
Interview with Douglas Crockford
11–20 of 107 posts
Re: Interview with Douglas Crockford
#12I 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 just waiting for their turn to speak.
Re: Interview with Douglas Crockford
#13Why aren't the links in the body text... links? Really screws with accessibility.
They are for me, chrome desktop.
Re: Interview with Douglas Crockford
#14Retire 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 or earlier. This rewrite happened in 1998. IE dates from 1994, per Wikipedia. KHTML, whence Safari and Chrome ultimately derive, is itself from 2000.
Let's talk about programming languages. Java dates its early work to 1991. .NET Framework is the late 90s (Wikipedia is exceptionally poor with dates here). The LLVM framework dates to 2000 in the earliest. Accelerator programming languages like CUDA and OpenCL are deep into the 2000s in their genesis, and the development of more fully heterogeneous programming languages obviously postdates that.
That's a lot of significant projects that date way later than Linux.
Re: Interview with Douglas Crockford
#15I 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…
Yeah, I'm curious how common this is. If anyone has done it/is doing it successfully, could you share more about the approach? It sounds valuable in theory but it also sounds like a ton of time during which people can half-listen and say "Sure sure, looks good", especially on a larger team.
Re: Interview with Douglas Crockford
#16I am surprised he doesn’t like the more recent additions to JavaScript. I liked ES6 features quite a lot.
Re: Interview with Douglas Crockford
#17Why aren't the links in the body text... links? Really screws with accessibility.
It seems that they only work properly if JavaScript is enabled...
Re: Interview with Douglas Crockford
#18I am surprised he doesn’t like the more recent additions to JavaScript. I liked ES6 features quite a lot.
ES6 is what makes JS bearable to write modern day. Totally don't understand his point here. Who wants endless nested promise chains?
Re: Interview with Douglas Crockford
#19I 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…
[deleted]
Re: Interview with Douglas Crockford
#20I 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…
Yeah, I'm curious how common this is. If anyone has done it/is doing it successfully, could you share more about the approach? It sounds valuable in theory but it also sounds like a ton of time during which people can half-listen and say "Sure sure, looks good", especially on a larger team.
I tried it with my team about 4-5 years ago and found it, while useful, to be too much overhead for the benefit it provides, especially when compared to normal ad-hoc code review.
I will do something similar as part of big product releases though: I'll get the team together and we'll do a once over walk through over everything end to end. Normally this produces about an additional sprint (two weeks) of work ahead of the launch as you uncover problems and people see things with fresh eyes. So make sure to build that time into your schedule.