Alarming Development

JavaScript is /way/ better than good enough. It's terrific. It's the only programming language many people need to produce really amazing websites and web application that make the world a richer and more promising place for a lot of people.

It's good enough to get you $40-50/hr easily.

It's good enough to build platforms and APIs and tons of libraries given freely to the community by companies including Yahoo, Google, and startups you've never heard of.

It's a beautiful language and /extremely/ powerful. To judge it poorly because hash keys are strings is so short sighted that I doubt the credibility of the author.

If you are new to programming or want to try something out, go for JavaScript. You can build a simple website in HTML and if you know JavaScript, you can plug into a wealth of information just by typing some code into a browser window and hitting save.

Look at what any of the major mapping websites let you do. Entire platforms as a service. And now with the Pre out, you'll be able to build websites with javascript that function natively on the phone. The iPhone makes you jump through hoops to do something like that.

JavaScript is big big big and it doesn't have anything to do with hash keys. It has to do with a network of like-minded individuals pushing it forward. Not for money, not to make it easier, not to win control, but to create a platform on which we can all collaborate and build an Internet that helps us communicate.

Look at the power right…

I agree, the ability to connect widgets is one of my favourite aspects.

It lets you create a customized for your specific needs instant feedback so you can keep changing the source and see how it affects your "calculated view."

I want to be able to answer questions like:

- What is the diff between the output of my program as is and at master^1 commit.

Sure, I can manually copy my repo, check it out at master^1 and save its output to file1.out. Then save the current output as file2.out and do a diff. But since that takes more than 5-10 seconds, the cost outweighs the benefits and I'll say "screw it, I'll just keep going as is."

On the other hand, if I build a tool that makes it possible for me to answer that question in under 10 seconds (and keep answering it as I make relevant changes, if I want to keep getting the feedback), then that will change how I work.

Unix pipes are absolutely great, but there are some areas for improvement.

- It's hard to visualize the output at the intermediate steps of the chain. So if you have "cmd1 | cmd2 | cmd3", you'd have to spend more effort than it has to be in order to see what cmd2 and cmd3 got as input.

- They are limited to text for visualization of output. Most of the time this is good, but what if you want to see a plot of 2D points?

- They're typically executed when you press Enter. Sometimes you might want to say "always execute this whenever source file changes."

The awesome part about software is that you can create and…

[repost from blog] – This is really spot on. I would like to refer you to a couple of things that come to mind that you might find useful for advancing this line of thinking.

(1) I saw a talk by Jonathan Edwards that was very much along the lines of what you wrote here: http://alarmingdevelopment.org/?p=5

(2) Second, Christopher Alexander’s early work on patterns in architecture and urban design have been referenced quite a bit in computer science, but seldom is his ‘magnum opus’, a four-book series on the ‘nature of order’, referenced. These texts move far beyond the early work. You would do well to have a look at the first book, which tries to establish an objective theory of design not based on scientific principles: http://www.amazon.com/s/ref=nb_sb_noss_1?url=search-alias%3Daps&field-keywords=the+nature+of+order&x=0&y=0

(3) You might be interested to read some discussion on the history of music programming languages. Max/MSP and Pd, both dataflow-oriented, offer what I would estimate to be an order of magnitude of productivity gain for certain tasks in building one-off multi-media systems. They’re a bit like a UNIX for real-time multi-media + control signals. This essay reminded me a bit of the anti-academic and organic approach that Miller Puckette took in building them despite being trained as a mathematician and developing them in an academic setting. This serves as a good lesson that successful software isn’t necessarily designed by having good principles, but…

> Yes, there are people who create a mess with abstraction. This happens in every language, in Java people create FactoryFactories, in Haskell people play type tetris, in Ruby, people abuse metaprogramming and in Go, I assume some people go overboard with code-gen.

It's possible in any language and yet some languages' codebases are consistently worse than others ;)

If you create a culture of cleverness, implicitness and metaprogramming, that's what the programmers using your language will do. It's self-selection to an extent.

"I've suffered long from the Ruby ecosystem's mentality of 'look at what I can do!' of self-serving pointless DSL's and frameworks and solemnly swore to myself to stay away from cute languages that encourage bored devs to get 'creative'." [1]

"I worked at a Scala shop about 10 years ago. Everyone had their own preferred "dialect", kind of like C++, resulting in too much whining and complaining during code reviews. IMHO, the language is too complex." [2]

> And all the while, every one of these lines could be mutating some shared state

That's where the obvious code helps.

Let's circle back.

> I still don't know what people mean by "obvious" code.

The Zen of Python is a nice primer: [3]. A beautiful display of taste right there.

A few concrete examples:

- "Explicit is better than implicit."

Explicitly returning errors means we get to see every single point at which something could error out - explicit, as opposed to exceptions that could…

I think the basic issue most people have with Haskell (or rather, with Haskellers) is the fetishization of 100% correctness. For most tasks, it's just not that important, and so the (considerable) extra cognitive load that Haskell imposes is a net negative.

I mean, precise joinery may be superior to hammers and nails when building a house, but it's an expensive proposition, and there are 5 people in the world who can do it properly.

Most of us monkeys, when coding, are aiming to accomplish some task in the notoriously incorrect real world. It is often much better to spend 1/5th the engery get to a 80-90% correct solution very fast, and then patch as necessary, for the very important reason that you don't even know if what you're attempting to do will work. In that mode, like carpenters, sometimes it's helpful to just bang it with a hammer.

If what you do is write compilers, well, OK. The description you're quoting sounds pretty good. But the world doesn't need tons of compiler writers, and those it does need typically have pretty stable specs in front of them, so maybe joinery is the right approach.

I think this guy gets it about right: http://alarmingdevelopment.org/?p=440

This is just bad technical writing. He is unable or unwilling or simply too lazy to produce a single concrete real-world example of the object of his high praise. He says he has found applications ranging from real-time embedded systems to library loans, so how hard would it be for him to to give a simplified version of one of those applications as an example? Heck, I'll settle for a non-real-world example, as long as it's tangible and concrete.

Contrast this with Jonathan Edwards's presentation on schematic tables (a powerful generalization of state charts) which despite its somewhat academic feel makes a strong case to the reader by employing a significant non-trivial example--an example which is admittedly also elegantly solvable in a lazily evaluated language like Haskell, as I pointed out to Jonathan a while ago: http://alarmingdevelopment.org/?p=366