User login

Navigation

Most web developers prefer dynamic languages

I am the creator of the Opa programming language. As we target web developers, we get an enormous amount of feedback from developers who often don't know much about functional programming and strong static typing.

Here is a tool we have built to please the "dynamic crowd": opa-watch.

Seems unrelated. So I guess I should add a more substantial comment. How do you deal with errors? I wasn't sure, but it sounds like you would switch from a working view of the program to a box that says "error! ...". Do you think it might be better to keep the last successfully compiled server around and somehow indicate that it's stale, rather than replacing it with an error message?

I think the point of this is that you use it during development. Programming web applications in dynamic languages goes like this: (1) you edit some file of your application (2) you refresh the page in your browser (3) you see the result, or an error message if it was an error. There is no need to recompile or restart the server, the changes get loaded into the server automatically just because a file was saved. This seems to be about bringing the same streamlined workflow to Opa. The error message itself could use someinspiration as well :)

Was it characteristics of the language itself--including the static typing model (and the relatively unpowerful type system in the early days)? Obnoxious corporate behavior from Sun and/or from competitors like MS? The need to download a plug-in in many cases, rather than having an interpreter built into the browser? Terrible JVM start-up times? Came about too early--on machines and networks where a VM was a performance bottleneck? Poor integration between applets and the page HTML? Applet sandbox too restrictive (something which can be argued is a feature, not a bug)?

I suspect that the type system wasn't the biggest issue in Java's demise in the web-client space.

Java failed, at least for me personally, because it did not enhance the web browsing experience and created risks.

I discovered that if I had Java installed, web pages would squirm under my eyes while I was trying to read them. Sound files in tabs or windows unrelated to the one I was reading would play when pages loaded -- often unexpectedly and loudly. The performance of the browser slowed to an "ants stuck in honey" level when I went to load the (usually approximately 160) "news" pages I read daily (I load all of these in the background, while reading the first one), and dynamically generated requests would suck bandwidth on an ongoing basis rather than downloading something and then stopping. The security policies were hamfisted, not configurable, and pages generally had no version that respected any security policy other than their own, which usually amounted to "rip off as much performance and spy as much personal information as possible out of every client."

So, not installing Java was a simple defensive move. The browser became literally unusable if it were installed, because at the start of my morning news trawl 160 separate instances of a Java runtime would all compete for memory, CPU, and bandwidth, and attempt to grab the same sound hardware etc.

These days I actually have to go to considerably more trouble to stop the above bad effects from happening, because you can't just not install Javascript. Now I have to actively block unwanted scripts, which requires a lot more work.

That said, web page designers have at least noticed that people DONT prefer pages that squirm under their eyes while reading, even when scripts are enabled -- so there has been *some* progress.

Turning javascript off entirely is a bit radical, and breaks a lot of sites. I find a combination of noscript (which allows turning off js on a site-by-site basis) and, above all, adblock, makes the web far more tolerable.

That's it exactly. I'm *forced* to use javascript, because now that web designers have in their fevered little hands something they think they can *rely* on they feel free to build sites that don't work at all without it. If you call that "succeeding as a site scripting language", go ahead.

Which, in practical terms, means I have to use noscript, specifically enabling hosts that use javascript for some *useful* purpose, usually one site at a time. If I enable javascript globally, loading the morning news trawl still amounts to just crashing the browser. I mean, it doesn't actually crash, but it freezes for minutes at a time between accepting any input -- even to scroll, or open/close a tab.

One thing; with javascript on, I was forced to block every ad server in the world because they *all* want to use it. With noscript, I don't have to block them all. So, perversely, having javascript disabled is probably actually better for the web's "revenue model."

More worrying, I think is the trend towards more basic web functionality being exposed through procedural JavaScript APIs, eg various HTML 5 features. The semantic web seems to be fading before it really took off, and a procedural web is taking over. Google seems to be actively encouraging this with frameworks like GWT. I wonder if this is a deliberate strategy to raise the technical bar to entry for any wannabe search engine/web scraping startups?

Developers prefer ecosystems where they can learn skills needed to survive in that ecosystem.

For example, go to a New York City Drupal Users Group. Drupal is a content management system that powers most of the Web, including this blog. Really, go check it out. You will learn a lot about such ecosystems from people a lot dumber than you. Just observe what it is like. From the blog post linked, these factors seem to fly over the group's head.

Nobody is going to flock to opa because of opa-watch. You are solving a problem that doesn't need solving. In essence, opa as a company has a very basic problem: they are too smart for their own good, and (I am guessing) likely an engineering-dominated company that spends very little on marketing, sales and advertising.

Was there any need to characterise Drupal developers as dumb in this post? From my experience that is far from accurate (but then, I have delivered two Drupal-based projects, so perhaps I am also dumb).

There was no need. I was simply suggesting that a team of Computer Scientists approach problems differently than people who may not even know what object-oriented programming is. That doesn't make them dumber or dumb, but less knowledgeable in a technical area.

Put another way, I am sure Henri's team can beat many at writing languages or compilers, but the company that is behind Drupal doesn't need to worry about that, because they have an ecosystem with a thriving marketplace and it's based around delivering functionality fast to users via tons of pre-existing plug-ins.

Indeed, we are now acquainted with big PHP and JS communities. I don't think neither we are smarter nor them dumber.

These communities have indeed built great tools. The error messages are one tiny example, but over time their whole ecosystem has become great.

When we discuss with them, they like some of the features that Opa does, and regret the lack of this or that. And this is exactly what my OP was about: Opa can be a widely used solution IF we get better at marketing it (your point) AND we keep up with Opa as great _product_ and not only a technology.