Comment by mechanical_fish | Hacker News Reader

Comment by mechanical_fish | Hacker News Reader

Parent Full thread

mechanical_fish

Here's Yegge on the topic:

http://steve-yegge.blogspot.com/2007/02/next-big-language.ht...

... though he doesn't explicitly say he's talking about Javascript, it's pretty likely that he's talking about Javascript.

1) It's got C-like syntax.

2) It's got the dynamic- and functional-language features that make people happy.

3) We're stuck with it no matter what. Changing the world's installed base of web browsers takes about a decade; such is the lesson of IE6. The only universally-supported client-side language on web browsers is Javascript. Its successor, should it exist, hasn't even been sighted on the horizon. [1] So we're in for at least another decade in which every web developer needs to know Javascript.

4) Because of #3, lots of folks are working to make Javascript fast and reliable. There are several JS interpreter projects in active competition. That kind of focus has already paid off in spades, and is going to pay off even more over time. Those of us who remember the days when Java was considered painfully slow, to the point where people complained about how crippled it was, understand what happens when the bulk of the world's compiler wizards spend a decade optimizing a language's runtime: It tends to become better. Much better.

---

[1] The only serious challenger, Flash, is not only proprietary, widely loathed, suffering from a PR slump, and under direct attack from Apple but is also... based on ECMAscript, a.k.a. Javascript. Or so I understand. So it's more of an alternative runtime than a real alternative language.

ActionScript may be based on ECMAScript, but they look very different:

  package com.example
  {
      import flash.text.TextField;
      import flash.display.Sprite;

      public class Greeter extends Sprite
      {
          public function Greeter()
          {
              var txtHello:TextField = new TextField();
              txtHello.text = "Hello World";
              addChild(txtHello);
          }
      }
  }

Also, Flash is more than ActionScript.

The difference in appearence is because it's based on what was going to be ES4, you can actually write it like Javascript for the most part if you want to.

In a talk Yegge gave some time later he did confirm that he was talking about JavaScript. http://vodpod.com/watch/395703-steve-yegge-at-oscon-2007 (at the very end, "NBL is JavaScript 2")

Of course, the language that is now called Javascript 2 is not the same language that Yegge was referring to.

I have to completely disagree with IE 6 being the model for future browser upgrade timelines. That's a very limited data sample and the willingness to upgrade your browser is going to be significantly faster as time goes on.

IE6 continues to be a pain for sure, but the mindset behind this is changing as the web and it's users evolve.

the willingness to upgrade your browser is going to be significantly faster as time goes on.

You may be right. And then again maybe not. It's going to be fun to find out!

I would note that IE6 persisted until now not because anyone wanted it to -- Microsoft hates IE6 more than anyone, since every IE6 user is both a support timesink and a potential paid upgrade that hasn't happened yet -- but because it sits in a niche. There are people who bought old machines that haven't worn out yet. And there are businesses that built a bunch of stuff on IE6 and see no reason to upgrade.

And the nature of the universe is: Things diverge over time. (Yet another side effect of the second law of thermodynamics.) The number of niches and their diversity is growing now, and they will continue to grow. In ten years there will still be people, somewhere, running IE6. There will also be people running all sorts of other things: Old iPod Touches running obsolete versions of Mobile Safari, eleven-year-old car navigation systems, smart phones and book readers of every description, obsolete gaming hardware (have you noticed that you can still buy a brand-new Playstation 2, ten years after it launched? Have you considered the implication: There will certainly be many PS3 units in use ten years from today?)

The good news is that, thanks to ubiquitous Internet, companies are increasingly able to force customers to use the latest-and-greatest browser technology by pushing upgrades out over the net from on high. But is (e.g.) Sony really going to officially support the PS3 forever? What about the manufacturers who go bankrupt? And, if the market ends up demanding that manufacturers support multiple decades worth of their legacy hardware, is that really going to tend to encourage innovation in web standards, or is it just going to make such innovation that much more costly to implement, encouraging the tendency to embrace the status quo because it is "good enough"? We'll see.

Everything you say makes sense. Let me rephrase my statement into 2 separate statements then, as I should have initially.

1. Future browser upgrade timelines should not be based on the IE6 fiasco. It's too small a sample size to use as corroborating evidence in these predictions. It may end up being an anomaly.

2. In my own opinion I think the upgrade timeline will grow shorter. I don't have any hard evidence I can cite, it's just my impression as someone who's been involved in web development for the last 12 years or so. The points you mention are all valid, and I'm not saying there won't be new and different pains we'll enjoy ;)

I don't think people should take Yegge seriously without a grain of salt.

Yeah, he's a good writer and I've read all of its blog-posts ... but he seems like the kind of programmer that's always discontented with the status-quo, always looking for that next big language, always relentlessly looking for tools that will make programming fun again ... and that particular article seems to me a lot like wishful thinking.

And guess what ... you won't find much happiness in switching languages, unless the culture around it favors simplicity and getting things done (and your previous community didn't). That's why Lisp is almost dead.

Also, Javascript may become popular on the server-side, but that's only because browsers are stuck in the past, while becoming more and more relevant to the future.

But give developers the choice of multiple languages ... and I'm pretty sure Javascript will fade away to a niche. Incidentally, you can play with Ruby and Python in the browser right now ... it requires Silverlight/Moonlight, but it's pretty cool and gives some glimpse in what the future should look like.

I know that not a lot of people would agree with me on that one, but i'd argue that JavaScript is a better designed language than Python or Ruby on a lots of points.

It's simpler than both regarding the core language features, and is also the only one of the three to have real anonymous functions.

I'm not fond of C syntax, but i can live with it

> is also the only one of the three to have real anonymous functions

What are you talking about?

I'm talking about that :

http://news.ycombinator.com/item?id=1171471

Arguably i took a bold step regarding Ruby, which has them, but is confusing in this regard since blocks are not anonymous functions, and are the idiomatic and preferred construct in ruby. The problem is deeper than that , but Paul Canter does a much better job than me explaining why

I actually like the approach in Ruby, because the syntax for passing a single anonymous block (which corresponds to 90% of all cases) is really light and people have used it practically for adding syntax to Ruby.

What differentiates Ruby from Javascript (or Python for that matter) is that when defining a function using regular syntax, its name is not a variable referring that function in the scope it was declared ... what Python and Javascript are doing. And that's a trade-off that some people like it, because in Ruby you can call a function without parens and it doesn't really get in your way when wanting to do crazy shit with already declared functions.

On Python, it may not have anonymous functions, but it has true first-class functions and true closures. It's only a problem for async code because you want to have the declaration of a closure after you see the call-site that's using that closure, not before it. But in practice that's not so awful ... and if you really really want multi-line anonymous blocks there are hacks you can do with the "with" block.

In this regard Javascript is cleaner, but it is messier in other places. I don't like that its a loosly-typed language for instance (haven't we had enough of that?).

I don't like that it doesn't provide class-based OOP ... and while you can build it on top of prototypes, it's a PITA not having a standard. And class-based OOP is mapped better to the way we think, having a bad reputation only because a couple of popular languages have plagued us with bad implementations ... but people should really take a look at Smalltalk before throwing the baby out with the bathwater.

> it doesn't really get in your way when wanting to do crazy shit with already declared functions

That's something i don't like about ruby. You can do crazy shit but it leads to code wich is opaque for somebody that doesn't truly know ruby inside out. The language is full of tricks. But i don't want a full of tricks language. I want a simple language that doesn't get in my way, and doesn't provide 7 ways and 3 different mechanisms to do closure like constructs (numbers are not made up)

> On Python [...] if you really really want multiline anonymous blocks, there are hacks you can do with [...]

Well yeah i really really want them, and no i don't want to resort on hacks to use them.

I really have trouble understanding the rationale behind all those half baked constructs. The way Lua/Javascript/Scheme does it is the way to go IMHO : provide one mechanism that is simple and works well. You may loose some convenience or conciseness in the process (compared to ruby blocks for example), but what you gain is one consistent way to do things.

About javascript OO, i admit that it doesn't bother me as much as it seems to bother you, and that it may be linked to the uses i have had for javascript yet, but i have to say i indeed had more pleasure working with python/ruby object models than with javascript at the moment. I can't say if that is due to a superior mechanism or to familiarity with class based models though.

When was "C-Like Syntax" ever a good reason? I want something I can read naturally, like Ruby or Python.

He means that there's a critical mass of developers who will take one look at a syntax and move on if it doesn't have curly braces and semicolons. It's not that they're enamored with having a needlessly awkward syntax for function pointers, it's just that a syntax that isn't 95% of the way to Java just looks freaky weird to them, end of story.

I don't disagree that syntax matters, but C's is hardly a shining example. There's a network effect with programming languages, though (libraries, documentation, community, etc.), and there's a certain amount of realpolitik in designing with "C-Like Syntax" in mind.

I'm more worried about languages with ugly semantics. Odd syntax is only skin deep, but bad design goes straight to the bone.

Sigh. You're right and I hate it. :(

Reply on news.ycombinator.com