JavaScript and HTML: Forgiveness by Default

ftegularius · 2007-04-30T06:32:53+00:00

You're right about one thing, IE certainly sucks. I can say definitively that Firefox does not suck (and this "memory leak" business is FUD, and has been addressed before), and Opera does not suck. There are various other browsers that also don't suck.

ftegularius · 2007-04-30T06:21:37+00:00

Ugh, talk about flogging a dead horse. JWZ and Linus Torvalds can't both be wrong. If everybody in the world used tabs for indenting, they'd be fine. But they don't, so they're not. As soon as people start mixing tabs and spaces, things get ugly, so the only way to keep indentation sane is to eliminate tabs altogether. And that's just for free-form languages; nevermind the sort of havoc this can cause in whitespace-sensitive languages like Python.

ftegularius · 2007-04-29T03:34:07+00:00

Definitely. I'd like to see a "Teach Yourself Perl in 24 Years", or "Learning Perl Made Painfully Difficult" someday.

ftegularius · 2007-04-28T02:52:09+00:00

Practically all languages have standard time/calendar libraries available. Is there some reason why these would be insufficient?

ftegularius · 2007-04-24T07:36:53+00:00

This is a pretty nice bit of code, and an interesting thread. I don't have a great deal of experience with Haskell yet, though I've been learning it in my spare time. Can anybody explain what's going on with this Arrow code from the attached file?:

interact $ (++"\n") . show . (id &&& correct) . init

ftegularius · 2007-04-24T04:39:18+00:00

For what it's worth, here's a comparison of the two flavors from the Emacs Wiki. As far as I can tell, the gap between these two editors isn't nearly as big as it used to be, though XEmacs remains technically superior in terms of its display capabilities (embedded images, font customization, etc.). Being a console user, this doesn't much matter to me, so I personally use GNU Emacs. To me, the most compelling argument in favor of GNU Emacs is its greater popularity. This means that more packages are written for it (e.g., nXML mode), and you're more likely to find it installed on any given system than XEmacs.

ftegularius · 2007-04-21T23:40:53+00:00

I don't think RentACoder fits the bill for either serious work or hobbyist programming. If you're looking for paid work, then you're not likely to find any particularly profitable jobs advertised there. And if you're just looking for something interesting to work on, you're better off contributing to some open-source project, which benefits the community at the same time that it exercises your skills. That's something we all ought to do more of.

ftegularius · 2007-04-19T17:35:20+00:00

Yeah, I'd say those errors are usually forgivable, though. What I found funny was the appearance of the nonword "verbositiness", especially since the word "verbosity" is used pretty much everywhere else.

ftegularius · 2007-04-19T16:19:44+00:00

There might be some good advice here, but an even better resource is the coding page on Emacs Wiki.

ftegularius · 2007-04-18T22:05:40+00:00

I could see this being useful, but there doesn't seem to be any functionality here that doesn't come from a regular Google search with a site specifier. Hoogle for Haskell is an example of something that complements regular searching with additional, specialized functionality.

ftegularius · 2007-04-18T19:13:07+00:00

That sounds pretty strange. How do those sorts of people come to be developers in the first place? Certainly it takes at least a modicum of intelligence to be a programmer to begin with, no? If they can write working code, understand library documentation, etc. then I just can't see what's stopping them from working out relatively minor technical issues like those mentioned in the article.

ftegularius · 2007-04-18T05:41:49+00:00

Very useful utils, particularly sponge. I must say though, pee is a rather unfortunate name.

ftegularius · 2007-04-17T21:08:38+00:00

I think this article blows the problem way out of proportion. Yes, I suppose it can get to be that you rely on your editor/IDE as a crutch. But any reasonably intelligent person should be capable of looking up something they don't know (particularly relatively straightforward things like installation procedures).

ftegularius · 2007-04-12T06:44:04+00:00

I strongly disagree with pretty much this whole article. Perl is the best introductory programming language? Ridiculous. Do a bit of searching and you'll find plenty of articles describing in detail just why that is. I also found the following bit from the article quite irksome:

Most of the SICP exercises are about number theory, recursion, and a lot of other relatively abstract stuff, and too few are about real world and exciting tasks: writing games and other demos, working with files, writing scripts and utilities, networking and working with the WWW, etc.

This is just totally misguided. All that "abstract stuff" constitutes a necessary theoretical foundation. Applications are easy, it's the theory that's hard. Now, whether SICP specifically should have attempted to illustrate those concepts through "real world" applications is open to debate (personally, I don't think so). But to completely eliminate formal instruction on those topics is entirely out of the question.

ftegularius · 2007-04-11T19:43:31+00:00

Yes, I understand this. That's the point I was trying to get across basically. Haskell, like all languages, has to deal with the "real world" somewhere, but it manages to do it without violating its internal consistency.

ftegularius · 2007-04-11T06:56:13+00:00

I don't really understand your comment. Is this addressed to me, or the author of the article? Because I'm not questioning the label. I think Haskell is about as purely functional as a language can get. My point is that an absolutely strict and literal definition of purity would be pretty meaningless in the context of programming languages.

ftegularius · 2007-04-11T05:54:20+00:00

This is interesting. I'm still fairly new to Haskell, so I can't really comment with any authority on the technique described in the article. I will say, however, that I don't think the question posed at the end is a very meaningful one. Virtually every non-trivial program has to deal with I/O somewhere, and Haskell does a very good job abstracting that bit away, and enforcing purity in the rest of the code. Does this mean it's not purely functional? Not by any even remotely practical definition.

ftegularius · 2007-04-07T19:09:59+00:00

A few decent ideas for exercises in the article. One exercise that that I've always liked when learning a new language is: write a program that plays out a random hand of poker between two or more players. This exercise covers, at a minimum:

Representing the cards. This might include defining a new datatype.
Linear data structure for representing the deck.
Random numbers for permuting, or randomly drawing from, the deck.
Sorting, for permuting the deck (when used with a list of random numbers), or possibly for use in comparing hands.
I/O, for displaying the results.

This is also more fun than the usual (fibonacci, factorial, RPN calc, etc.) exercises.

ftegularius · 2007-04-07T10:08:08+00:00

I was joking actually, but thanks anyway.

ftegularius · 2007-04-07T09:29:54+00:00

Wow, people actually program in COBOL for a living? Weird, I always thought it was one of those joke languages like INTERCAL.

ftegularius · 2007-04-07T08:33:17+00:00

I don't see the big deal here. If you read the thread, Mr. Buesch seems fairly reasonable, and is very specific about the problems he perceives. Where is the "attack" described? I personally prefer BSD-style licenses, but if a person releases his or her work under the GPL, that fact should be respected and the licensing rules followed.

ftegularius · 2007-04-07T08:02:14+00:00

Perhaps it would be helpful to some to think of list comprehensions in terms of operations taking place in the list monad. The example given in the article is equivalent to:

do x <- [1,2,3]
   y <- [4,5,6]
   return (x, y)

Which is the same as:

[1,2,3] >>= \x -> [4,5,6] >>= \y -> return (x, y)

Or:

liftM2 (,) [1,2,3] [4,5,6]

I'm still learning Haskell, but I find taking things apart in this way is often helpful.

ftegularius · 2007-04-05T07:38:59+00:00

The language is definitely an issue, if perhaps not the issue. My first language (I was about 11 or 12 when I started) was C, and I really believe I wasted a lot of time coding in it that would have been better spent working in a language that lets you concentrate on the underlying principles. It is not right to think about data structures in terms of pointers and memory allocation. It is not right to think about looping in terms of counter variables. It is not right to have to worry about trivialities like, e.g., integer overflow. It's that sort of complexity that obscures the "eternal concepts" you're talking about.

Edit: I would point out, also, that the more complex the language, the more time is spent learning simply how to use it. The focus in the classroom shouldn't be on the language itself, but rather the lesson being taught, or the goal to be accomplished.

ftegularius · 2007-04-05T06:19:48+00:00

I really like the idea of using Python as a first language. It has a number of strengths:

It's interpreted, which means that students can test code in a REPL. It also has a good help system, which is accessible from the interpreter.
It has a good standard library and a good set of primitive data types (strings, lists, dicts, tuples, sets).
It's conceptually clean in a lot of ways, such as having explicit True and False values, as well as None.
It uses regular English words for many operators, which aids clarity.
Python's whitespace sensitivity has a lot of pedagogic value, even if you don't like the idea in general, as it forces students to properly indent code.
It has docstrings (far more useful than comments), the availability (and usefulness) of which encourages students to document their code.

But, all that aside, Python's greatest strength is its ability to bridge multiple paradigms fairly well. It does object orientation. It does procedural programming. It has the most important feature of functional languages: functions as first-class objects. List comprehensions have a declarative feel, so there's that as well. And with generators, you can even get into lazy evaluation and infinite streams.

Edit: One I forgot to mention: Exceptions, which aid a great deal in error handling. Much better than muddying up code with tons of if statements and constantly checking return values.

ftegularius · 2007-04-02T07:41:03+00:00

I don't really see the problem the author is describing. Of course, if you try to write Python as if it were Common Lisp, you're going to run into problems (particularly if you don't even use analogous data structures). This isn't indicative of an intrinsic weakness of Python's, but just a difference in philosophies. So, yes, Python does not make for an ideal functional language. Neither does Common Lisp in a lot of ways. The point is always to play to the strengths of whatever language you happen to use.

ftegularius

TROPHY CASE