Earlier quoted context omitted.
Also, Java-YavaScript
It sounds so natural that I immediately started thinking I had actually been saying it wrong all these years.
I think I'm going to adopt this new pronounciation.
The Birth and Death of JavaScript [video]
171–180 of 236 posts
Re: The Birth and Death of JavaScript [video]
#172Earlier quoted context omitted.
http://en.wikipedia.org/wiki/CINT
why not put that in browsers ?
To make a complete platform, you also need APIs, so there's more to it than just picking a language. You also need to figure out how to sandbox it; CINT appears to give programmers access to unrestricted pointers. You also want to get multiple browser vendors to agree, so some kind of specification is desired; CINT targets its own unstandardized subset of C. And you ideally want it to go fast, but CINT appears to be pretty slow:
http://benchmarksgame.alioth.debian.org/u32/compare.php?lang...
So there'd be some work to do. You could also compile the code, but complete C compilers are not fast, in browser terms.
Re: The Birth and Death of JavaScript [video]
#173Earlier quoted context omitted.
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.
It's only WTF because it's not the same as other implementations of map. Once you can internalize the map implementation, it's no longer WTF & actually makes sense.
So much for abstraction if you need to understand the implementation of every function you'll every use in JavaScript.
Re: The Birth and Death of JavaScript [video]
#174Earlier quoted context omitted.
Oh, yeah, especially after Microsoft stopped shipping Java. There was also the version issue to worry about. "Pardon me, Mr./Ms Customer/User -- would you mind terribly going and downloading and installing a 20 MB Java update on your 14.4k dialup connection before using this page?" Nightmarish, it was.
I always found it a bit hilarious how Sun, after getting Microsoft rather onboard the Java train, albeit with their necessary native extensions, decides to sue them and put an end to it. And promptly kills off Java distribution and adoption by the largest software developer in the world. Even stranger is how Sun, a hardware/platform company, decided making a popular platform that's hardware and platform independent w…
The "necessity" of those extensions is debatable, and they meant that code wouldn't be portable to Sun's implementation. There was real cause for concern, and there weren't a lot of other options for fixing it.
Sun probably also realized that they weren't about to compete directly with mighty Microsoft on platform lockin of all things, so they played a different game.
Re: The Birth and Death of JavaScript [video]
#175Earlier quoted context omitted.
It's only WTF because it's not the same as other implementations of map. Once you can internalize the map implementation, it's no longer WTF & actually makes sense.
So much for abstraction if you need to understand the implementation of every function you'll every use in JavaScript.
> understand the implementation of every function
Rather: remember three things that make up the majority of Array iterators' callback functions' signatures:
Element, Index, Array.
Shared by: .map, .every, .forEach, .filter, and probably some that I am forgetting. The exception I think is just .reduce[Right], which by definition requires its previous return value, so you have (retVal, elem, i, arr).
Quite literally, if you remember .map callback, you remember .every callback :)
Javascript deserves shtick for its truly bad parts (with, arguments, ...) and some missing parts, but .map and its friends aren't it.
Re: The Birth and Death of JavaScript [video]
#176> xs = ['10', '10', '10'] > xs.map(parseInt) [10, NaN, 2] Javascript is beautiful.
It's due to parseInt having an optional second parameter, the radix, and map passing the index as the second paramater, hence: xs = [ parseInt('10', 0), parseInt('10', 1), parseInt('10', 2) ]
Thank you. I read many comments to find an explanation.
Re: The Birth and Death of JavaScript [video]
#177Earlier quoted context omitted.
It does for human beings. We use base-10 for basically everything. This is true even for most programmers in most situations. Human beings aren't computers, and we aren't abstract math processing units who by default consider numbers abstracted (e.g. as elements of Rings). This goes double for string representations of numbers--in the majority of cases a number represented by a string is a number meant for human cons…
> It is certainly reasonable to expect "parseInt" to parse an integer out of a string in base-10 by default It does. > and entirely unreasonable to expect to be required to provide a base as anything except an optional argument It is optional. > and certainly it is unreasonable to expect that that second optional argument is treated as not optional in a composition operation I don't understand what you're saying here…
>> ...parse an integer out of a string in base-10 by default
> It does.
Not quite: in some browsers (IE), a string starting with '0' gets interpreted as octal. So parseInt('041') === 33 in IE.
Guess how I found out about that.
Re: The Birth and Death of JavaScript [video]
#178> xs = ['10', '10', '10'] > xs.map(parseInt) [10, NaN, 2] Javascript is beautiful.
A useful function function overValues(f) { return function(x) { return f(x); } } Then you can do ['10', '10', '10'].map(overValues(parseInt)); However, usually you're going to want to do the equivalent of this ['0101', '032'].map(function(s) { return parseInt(s, 10); }) Because Javascript interprets a leading zero as an indicator of base.
I think you accidentally a word...
> as an indicator of base.
As an indicator of base 8 (octal).
Re: The Birth and Death of JavaScript [video]
#179Earlier 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.
Flash and Java also required a compile. Javascript just required that you click refresh. Especially on 1995 technology, that mattered. Compiling Java took a while. I didn't use Flash enough to retain an impression of speed, but it sure wasn't instantaneous.
It's also the reason why Flash was so prevalent until recently and is still installed in 90-something % of desktop computers: it's faster. Significantly faster, and very specially so in the 90s and early 2000s.
Re: The Birth and Death of JavaScript [video]
#180Earlier quoted context omitted.
> Javascript is a bad choice Javascript is great once used in a "good" way. It's flexible & it's almost everywhere. Spending all your time complaining about how "bad" Javascript is kindof pointless. If you use Javascript, learn how to use it well. Master sushi chefs don't sit there complaining how bad knives are because the knives need to be constantly sharpened. If you are cooking spaghetti, learn how to strain the…
With this logic you can defend anything. PHP's great if used in a good way: Zuckerman's a billionaire. Right? Why is anyone even bothering with PL these days? Sushi knives don't decide to cut you because the rice came from a different origin. And I'd guess that most craftsmen, outside of a ritual and tradition would love for their tools to have less disadvantages. If you want to draw an analogy to spaghetti (?), it'd…
The "wat" is a good first step in identifying problems. However, I see is people getting stuck on "wat" and not moving forward. People would rather win an argument than advance knowledge & the practice. Lot's of ego, programmers have.
In the mean time, one can learn to appreciate & use javascript strengths. It can be quite fun, liberating, & useful. Anecdotally, I have not run into these crazy issues, and I program in javascript everyday. I also have a large app and the framework I built is custom.
I liken this to using C++, Unix, & bash as a base. Yes, you could say these tools suck and spend time creating, marketing, & community-building for a new tool. Or you can iterate & improve upon these existing tools. There's no wrong answer. What do you want to accomplish?
> Sushi knives don't decide to cut you because the rice came from a different origin.
That analogy seems like a stretch. Care to explain? Javascript works with different locales. There are many international websites that use javascript.
Also, javascript does not "decide" to create a bug in your program. You create that bug by misusing the tool. You will get further if you take some responsibility and improve your practice.
> And I'd guess that most craftsmen, outside of a ritual and tradition would love for their tools to have less disadvantages.
I agree with that. Usually the improvements are iterative. One could use a laser cutter (which does not need sharpening) to cut sushi, but that would also burn it. Here's a good talk (Clojure: Programming with Hand Tools).
https://www.youtube.com/watch?v=ShEez0JkOFw&safe=active
Ritual & tradition is a social tool to propagate knowledge, idioms, & practices across generations. It makes sense to challenge ritual & tradition to they improve over time. It does not make sense to whine about it without doing anything.
> it'd be like complaining that the only kind of spaghetti you can buy locally cooks only at a specific temperature, and even a bit more turns it to mush
Not getting your analogy. This seems like a stretch, similar to the person who cannot strain the spaghetti noodles on the video. Care to explain?