@dhromed said:
@Joeyg said:
But eval() and friends can take functions or strings,
But you don't use eval(), and you will only use function refs in interval and timeout. If I catch you using eval(), you'll get a stern slapping of the forehead with a brick. Stop even mentioning eval().
Oh, I know it. "eval() and friends" is how I describe the timeout functions, and even those make me nervous.
@Joeyg said:
Booleans and Numbers are (almost) always interchangable
But you don't use 'em that that way, normally. The only time I treat nums as bools is when getting data from HTML/XML, which is a string '0' or '1'. Don't use them interchangeably. No good comes of it. Be explicit.
@Joeyg said:
whenever one part of an expression becomes a String, it ruins the + operator and can often promote other parts of the expression to String.
Add some parens or parseInts. It's not a difficult thing to control. It hardly bears mentioning unless you're a novice.
The point is that even when I [i]am[/i] being explicit, every so often I slip up and a type gets promoted in an insane way without my noticing. There's no other language in which that has happened to me. I don't think it's happened to me in a number of years, but early experience (and some truly awful "Javascript" books as a child) (you can imagine the sort) have made me always on edge while using the language.
@Joeyg said:
my boss told me that EMCAscript was "basically like Lisp"
Don't treat it like LISP. LISP is something else. Proficiency in one does not qualify you for the other.
@Joeyg said:
the next guy was not impressed with the resulting code..
Might I be so presumptuous to say that you blame your boss' "tip" for messing up your own code?
Oh, no, the real reason my code was crap was much worse :) my boss wanted me to drop all the jQuery because he didn't trust it (and with good reason - the guy who had implemented it somehow used it to slow the site by 50 times, and wrapped it up in dozens of SQL vulnerabilities, and globally scoped every variable, and generally made the whole codebase an unreadable mess). It was easy enough to drop it and rewrite the entire site - its functionality was simple enough, anyway - and add in all the original useful features. ie, you could double-click text fields to edit them if you were an administrator, but if you tried to select text it would no longer start folding and unfolding crap and wrecking the site layout.
That was also fine, because it was still pretty easy Javascript, even without a library. But the problem was that the code was way faster, looked better, behaved correctly, handled edge cases, handled permissions and was quite a bit easier to use for all that. [b]And[/b] the CEO (this was a small company, but he was a [i]big[/i] douche) called me up and realized that I could change stuff and extend features while he was talking to me. The last guy would start to whine and blubber and insist these things were impossible, then take up 12 hours of my boss's time demanding help for the tiniest things. And the result would be an impossible pile of crap. Sadly, I destroyed all of the old code when I was done and ran away from the company (who I think has backups), or I'd show it to you guys.
At this point, my boss was free to work on the backend and implement all his insane ideas - this company was not a pyramid scheme, per se, but they never quite convinced [i]me[/i] of that - so that should give you an idea about how he thought of cash and stock. (We did have [i]stock[/i], by the way - we filled an entire abandoned leaky mall with old shit and we were working in the spaces between the shit. So in that respect we weren't just pyramid-ing money. There were sales happening. It was weird. I tried to learn as little as possible, for liability reasons.) Meanwhile, the CEO thought I was the smartest programmer I had ever met. In fact, I had only ever done Javascript according to my rules:
1. It had better be accessible. [b]Period.[/b] No javascript links or sound clips or "unhiding" things that should never have been hidden.
2. It had better work if Javascript is disabled. Or broken. Period.
3. It had better not get in the way or be irritating. If possible, the user shouldn't have to know or care about it. Don't override clicks on [i]any[/i] UI component, and don't override right-clicks. Double-clicks are usually okay, except that that's how people select text, so try not to even do that.
Assuming I stuck with these rules, I would be okay even though I'm no Javascript expert (hell, I don't claim to [i]know[/i] Javascript unless directly asked). However, needless to say, my CEO thought all of these rules were stupid and unnecessary, and would spent four consecutive hours on Skype each day trying to micromanage me into breaking them all. And since most of what he was suggesting would only affect administrators, I couldn't complain about it - after all, it's not like real users will see this shit. How bad can it be?
The my boss jumped on and started suggesting I do things to the front end that the last guy couldn't even imagine. I rewrote the search page to actually search items, I implemented Back/Forward buttons that actually remembered the search results, I implemented a "back to search" button that could figure out which page of results you had backed/forwarded to, I wrote a checkout system even though I had never touched written e-commerce code in my life, plus a ton of other little stuff regarding item listings and display and aggregating and blah blah blah. Also I redid the entire database schema - which again, wasn't too complicated, but was absolutely [b]filled[/b] with cruft - and ported it from MySQL to Postgres (which was good, except I had never used Postgres in my life). And I did all this to the best of my understanding of his "grand vision" for the site, or the company, or whatever he was getting at. Ironically, the Lisp tip helped me out more than anything here.
[i]And even then[/i], I might have been okay. Except I had six weeks to do it. That was when I was going back to school, and I was ready for [i]any[/i] excuse to run away from this company. (Later I deleted them from my resume, so it turned out I didn't need an excuse, but c'est la vie.) So I did all this in six weeks, with constantly-changing requirements, 4-6 hours of Skype each day, no clue what the company or I was doing. But they all thought I was fucking brilliant, and I got a raise every day for the last week as they begged me to stay, so I did it.
The net result wasn't too bad, as I recall. There were a lot of callbacks and prototypes, which often scare people who don't know Javascript that well, but other than that I thought it was okay. But I talked to the guy after me and he said he was "slowly redoing it all" and that there was a lot of "creative stuff he'd never seen before". I don't know if he was the idiot or I was, but given the above story, I'm pretty sure I was to blame. This is the first time I've admitted to writing that code.
Some automatic type conversion is normally unwanted*. But it's not 'ludicrous' and all very easily understood and controlled. Its quirks are no graver crimes than any other language's.
*) Examples: the number 0 should convert to true, I think, because it's an existing
number. If you want a bool, then Boolean() it. Also, parseInt('08') is a trap! because any number preceded with 0 is treated as octal.
I'm an embedded developer. 0 to me is all-bits-zero, which is also how false (and usually NULL) is represented. I'm happy for it to be equivalent to true - it's just not as intuitive to me.
But if true might then also become "true" or 1 or even "1" depending on what happens to it, when it started as "0", that's when things start to get scary. Especially when I asked the user (or backend, or frontend) for a numeric 0 and get a string "0". And every so often I find a browser who uses a different type. Or maybe I'm just imagining that. I dunno.
But again, my Javascript philosophy involves doing as little of it as possible. So I'm not one to talk.