Javascript department

re the ongoing poll...

Personally, I don't like departments limited to a single language, unless I feel some serious language innovation is taking place, or some seriously cool hacking.

Application specific scripting languages belong to the DSL department. Internet applications usually go in the XML department (which was never restricted just to XML).

I don't want a scripting department (I don't really like the term "scripting languages").

But JS may warrant a department even after considering these reservations. Opinions?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

lightweight languages?

How about "lightweight languages?" It's a somewhat controversial term, but it embodies the spirit of many so-called scripting languages, if not a precise definition.

I agree about language-specific departments -- it doesn't scale up, but otherwise perhaps unfairly favors some languages over others.

The term "scripting language" may actually be accurate in practice: they tend to capture small snapshots of imperative actions such as animations or user interactions (think VB macros). But of course these kinds of programs shouldn't have to be specified imperatively.

Maybe a better focus is languages aimed at a high level of abstraction and tailored to rapid prototyping/implementation. Of course, "high-level languages" tries to get at this, but it's a relative term; what people consider high level changes over time.

Oh God...

lightweight languages? I predict someone will suggest "dynamic languages" next. Oh, the horror... ;-)

I Know It's a Joke

But let me be the first to agree anyway. I need to take some time off from O'Caml and work through CTM anyway, since I promised myself to become fluent in Oz. Maybe that will bring some perspective that I need right now.

fuzzy ideas demand fuzzy terminology!

Well, "dynamic" is awful because the term is so incredibly overloaded. That's not a fair comparison.

"Lightweight" is less overloaded but is still imprecise enough (not a wholly bad thing!) to encompass many things: languages that are easy to write quick prototypes in, languages that are themselves easy to implement, or easy to specify, or even languages that are restricted enough that they are easy to make super-efficient.

I won't fight you on this argument, though.. it's pretty hard to be both precise and general.

Defuzzification

it's pretty hard to be both precise and general.

I'll take that as a challenge...

We have three terms — lightweight, dynamic, and scripting — whose meaning and precision are in question. Individually, their definition is pretty fuzzy, but perhaps by combining the terms we can add precision. These terms describe types of languages, so to help define the terms, we can look for languages which inhabit these types.

We've recently seen Haskell being used as a scripting language. Now I hope Haskell fans won't be too offended if I point out that Haskell can't really be called either lightweight or dynamic (if it can, then those terms really have no meaning whatsoever). So this demonstrates that Haskell is (or can be used as) a "heavyweight static scripting language".

Now, I think most people would agree that Common Lisp is a dynamic language, and it's very effective in a scripting role. But it can't be called lightweight in the sense used by the LL workshops, i.e. "easy to acquire, learn, and use", so Common Lisp is a "heavyweight dynamic scripting language".

The LL workshops considered languages like Python, Ruby, Javascript, Lua and Scheme as lightweight. Are all these languages also dynamic? We could quibble about R5RS Scheme, which is not dynamic in the sense of having namespaces or built-in objects being hash tables that can be modified at runtime, as in many of the other lightweight languages. But Scheme has other dynamic behaviors, and can easily be extended (and often is) to behave like its dynamic cousins. The scripting credentials of these languages are also well-established, so these languages are all "lightweight dynamic scripting languages".

A lesser analysis might be forgiven for concluding that all lightweight languages are dynamic. However, Boo uses Pythonic syntax with type inference, so is statically typechecked, and thus can certainly be described as a static language. I haven't used Boo, but a peek at the Boo primer shows that it's superficially pretty similar to Python, not only in syntax but also in scope, so I hereby classify Boo as a "lightweight static scripting language".

Finally, just to make sure that the term "scripting language" is not meaningless, we can observe that languages like C or Pascal are not well-suited to scripting tasks. I won't speculate as to the "weight" of these languages — perhaps we need more than a light/heavy binary scale here — but they're both static, non-scripting languages.

I have thus shown that while the terms "lightweight", "dynamic", and "scripting" are fuzzy when used on their own, they gain precision when used in combination. The bad news is that in light of this analysis, LtU now needs three new departments, and many previous stories need to be reclassified.

But in lieu of that, I think just adding a Javascript department would be fine. :)

You should either work for

You should either work for Jay Leno or for the government, I am not sure which...

Jay Leno? Ouch!

That stings!

Jon Stewart then...

Jon Stewart then...

I actually think of Haskell

I actually think of Haskell as a lightweight language with a heavyweight type system. One of the Impure Thoughts articles I had semi-planned was going to expand on that somewhat, with the idea that both Haskell as a language (admittedly stripped of syntactic sugar somewhat) and most Haskell programs have "few moving parts" and the effect that has.

After sleeping on it...

After sleeping on it, I still prefer items on lightweight languages and the like to go to the appropriate department (e.g., if the item is on an OOP construct it should go in the OOP department etc.). I think they are more different than alike.

It seems to me that the reason Javascript deserves a department is the amount of interesting stuff happenning around it. Thus, I think we should simply add JS to the languages in the spotlight (currently Python and Ruby), instead of openning up a more general department.

Chris concerns about dead departments are on point, but I think that's ok for spotlight departments (e.g., Python gets much less attention here these days than a couple of years ago which isn't surprising).

Opinions?

Well?

Well?

Sounds good

Should be some interesting JavaScript work coming down the line, so a spotlight on those developments should see some interesting stories.

Sounds reasonable

Sounds like a reasonable approach to me.

sure

That sounds fine.

I have one small story I can post as soon as the JavaScript department exists.

Done

The Javascript spotlight department is open for you use...

I am not sure I am going to post an introductory message, so let me just clarify that the department is the Javascript and related developments (e.g., languages are compiled to JS) and not for the entire hierarchy Anton described ;-)

Late commentary

Just how important is it to categorize posts into departments? What are the use cases for these departments? Are people actually using the department features?

My guess is that most users do not use the department features. Creating a Javascript department is probably harmless, with the exception that it makes the site a bit more complex and people waste time agonizing on the very hard problem of putting stuff into "proper" categories.

I think categories would make more sense if LtU was posting the same number of stories as Slashdot. They have "Sections", and not all stories make the front page, so if you are interested in a certain topic it makes sense to visit the different Sections.

Departments

Yes, people are actually using the department features — grepping the logs shows plenty of accesses, other than those by robots.

If you're interested in a particular department, browsing that department's pages can be useful, giving a view of the site that you can't get any other way (searching on keywords is much more general). It's also possible to get an RSS feed for departments — see the XML icon at the bottom each department page. This makes it possible to get alerts about particular kinds of stories.

Since items can be multiply categorized, the departments are really more like tags. For a category like Javascript, it's easy to tell when it's appropriate for a story, and it doesn't prevent a story from being put in other categories as well.

not linked under Departments

The Departments page doesn't appear to include a link to the new JavaScript department.

Fixed

Fixed.

I usually wait a couple of

I usually wait a couple of weeks to see how things go (don't want to jinx it, you know)...

Blame me

If I've jinxed it, at least you have a scapegoat now!