Earlier quoted context omitted.
Yep. It was on the schedule.
I think you'll find that the python ecosystem is very large and varied.
apropos, Bokeh.
The Birth and Death of JavaScript [video]
81–90 of 236 posts
Re: The Birth and Death of JavaScript [video]
#82Earlier quoted context omitted.
Because Java, Flash, etc. couldn't easily manipulate the DOM . Javascript won for this reason.
There were other advantages. To write JS you just need a text editor, and it's easy to pick up. To write Flash requires spending several hundred dollars. To write Java requires the JDK and to learn Java.
Used to to do a good amount of flash development - you could actually do it with just a text editor and a compiler (which was free). There were also quite nice free IDEs, like FlashDevelop.
Re: The Birth and Death of JavaScript [video]
#83> xs = ['10', '10', '10'] > xs.map(parseInt) [10, NaN, 2] Javascript is beautiful.
There are so many good WTFs in JS, but this is not one. parseInt expects 2 arguments and Array.prototype.map provides 3 to the callback it is given. Both of these facts are very well documented and known. var mappableParseInt = function(str){ return parseInt(str, 10); }; ['10', '10', '10'].map(mappableParseInt); I'd suspect this snippet is more a snipe at people who don't know JS very well and expect parseInt to be b…
I don't think `parseInt` accepting an optional second argument is the surprising behavior there. The real WTF is `map` passing more than one argument, and the loose behavior of JS regarding argument passing overall.
Re: The Birth and Death of JavaScript [video]
#84> xs = ['10', '10', '10'] > xs.map(parseInt) [10, NaN, 2] Javascript is beautiful.
There are so many good WTFs in JS, but this is not one. parseInt expects 2 arguments and Array.prototype.map provides 3 to the callback it is given. Both of these facts are very well documented and known. var mappableParseInt = function(str){ return parseInt(str, 10); }; ['10', '10', '10'].map(mappableParseInt); I'd suspect this snippet is more a snipe at people who don't know JS very well and expect parseInt to be b…
Alternatively, if a function expects two arguments, the language could take exception at the fact that three were handed in. Quietly accepting arbitrary arguments could be considered breaking contract. It does have a wtf-ey whiff.
Re: The Birth and Death of JavaScript [video]
#85Earlier quoted context omitted.
The thing is, good language design means you don't have to read the docs. The number one thing taught at user interaction / usabillity courses is that users don't read the documentation. Or skim it and go directly to one or two parts they want to check (Sure, some bizarro outliers do read it all). Besides, a golden rule from the UNIX era is the "principle of least surprise". Don't define stupid behavior as default, a…
Both behaviors make sense in isolation. It's not always so easy.
Arguably the issue is not with the behavior but rather a deeper design problem within the language itself. Notice that in Obj-C no one would ever get confused regarding the second parameter of parseInt:withRadix:.
Re: The Birth and Death of JavaScript [video]
#86I wish some of those talks were available for purchase on their own and not in the season packets. Definitely a few I'd buy since I liked this talk and the demo on the site. Guy has good vim skills for sure.
The pricing model used to be different -- $8/mo. He changed it when he stopped producing the series. I agree the current pricing doesn't make sense. I feel slighted for having subscribed for several months, but would now have to pay _more_ for content that I used to have access to. Ach, schade. That said, the material was compelling enough to buy at the time!
Re: The Birth and Death of JavaScript [video]
#87> xs = ['10', '10', '10'] > xs.map(parseInt) [10, NaN, 2] Javascript is beautiful.
There are so many good WTFs in JS, but this is not one. parseInt expects 2 arguments and Array.prototype.map provides 3 to the callback it is given. Both of these facts are very well documented and known. var mappableParseInt = function(str){ return parseInt(str, 10); }; ['10', '10', '10'].map(mappableParseInt); I'd suspect this snippet is more a snipe at people who don't know JS very well and expect parseInt to be b…
with a function named "parseInt" anyone would expect the inputs as base 10.. otherwise this shoud be called "parseHex" for 15 or at least "parseBytes(input, base)"
The programmers are not the ones to blame on that.. this is really a bad contract between the language and the programmer
Its the equivalent of a function named "getStone()" to return you a " Paper{} " :)
Re: The Birth and Death of JavaScript [video]
#88Earlier quoted context omitted.
I didn't want to go into this level of detail in the talk, but... I think you still want the MMU enabled, just not used for process isolation. With virtual memory totally disabled, a 1 GB malloc takes 1 GB physical memory even if it's not touched, you can't have swap at all, memory fragmentation kills you dead, etc. It still has a lot of utility outside of isolation. I don't have a good sense of how the performance c…
On linux, system calls don't result in a TLB flush - kernel data structures and code are in a different portion of the virtual address space (starting from the top of VM memory, if I remember right) that is tagged as not being available from ring 3. So system calls are quite fast. EDIT: Kernel memory begins at PAGE_OFFSET, see here: https://www.kernel.org/doc/gorman/html/understand/understand... Kernel memory lacks t…
I didn't know that! It certainly makes sense. Context switches still thrash the TLB, though. The performance cost of that has gotten better as time has gone on, but I wonder how many transistors (and how much power) CPUs are burning for that mitigation. The "how computers actually work" digression originally had a section on context switches, but I removed it early on because I felt like that section was dragging.
To try to paint a very rough picture of the larger thoughts from which this talk was taken: I think that microkernels and the actor model are both the right thing (most of the time). When implemented naively, they both happen to take a big penalty from context switch cost. But Erlang can host a million processes in its VM, and we're using VMs for almost everything now anyway.
The obvious (to me) solution is to move both the VM and an Erlang-style, single-address-space scheduler into the kernel. Then you can have a microkernel and a million native processes without the huge overhead of naive implementations. There are surely many huge practical hurdles to overcome with that, and maybe some that can't be overcome at all, but it sure sounds right when written in two paragraphs. ;)
Re: The Birth and Death of JavaScript [video]
#89Earlier quoted context omitted.
There were other advantages. To write JS you just need a text editor, and it's easy to pick up. To write Flash requires spending several hundred dollars. To write Java requires the JDK and to learn Java.
Used to to do a good amount of flash development - you could actually do it with just a text editor and a compiler (which was free). There were also quite nice free IDEs, like FlashDevelop.
We're talking late 90s/early 2000s here. If anything like that existed during Flash's heyday, I certainly wasn't aware of it.
Re: The Birth and Death of JavaScript [video]
#90Earlier quoted context omitted.
There are so many good WTFs in JS, but this is not one. parseInt expects 2 arguments and Array.prototype.map provides 3 to the callback it is given. Both of these facts are very well documented and known. var mappableParseInt = function(str){ return parseInt(str, 10); }; ['10', '10', '10'].map(mappableParseInt); I'd suspect this snippet is more a snipe at people who don't know JS very well and expect parseInt to be b…
with a function named "parseInt" anyone would expect the inputs as base 10.. otherwise this shoud be called "parseHex" for 15 or at least "parseBytes(input, base)" The programmers are not the ones to blame on that.. this is really a bad contract between the language and the programmer Its the equivalent of a function named "getStone()" to return you a " Paper{} " :)
"int" doesn't imply anything about the base.