Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
Maes

Does anybody else here hate "web languages"?

Recommended Posts

For sure, I know I do.

First of all, there's like a fuckton of them, and new ones keep sprouting every day, often shaped (or stretched) to fulfill specific needs, and filling the web and IT worker resumes' and job requirements with loud buzzwords.

If there's a design pattern, it seems to go mostly in the xml-y and pseudo-c syntax, which at least limits the variability of expressive differences somewhat.

The biggest problem, IMHO, is that there is practically no way to consistently develop and debug: e.g. to test javascript, the only way to make sure it will work is to fire it up in a browser, and then fight with the often cryptic errors (if you get any error warnings, of course...). Then there are browser-specific incompatibilities etc. and the need to couple more than one of these abominations together to achieve a specific goal.

IMHO, web languages suck some anal shit out of a rectosaurus swollen hemorrhoidal lower colon's glands.

Share this post


Link to post

Yes, the lack of compile-time checking sucks, though there are programs available that reduce this problem somewhat.

JavaScript is another example of a language that has been around almost since the dawn of the web and it's prevalence is like a self-feedback loop that keeps it popular and relevant. Again yes, it's legitimate to dislike it.

XML is the readheaded stepchild of the internet. We're just going to have to learn to live with it.

The only truly well-developed (and prevalent) web programming solution, in my opinion, involves a language that is heavily tied in with an unreliable operating system and often costly operating licenses. I'm talking about ASP.NET.

Share this post


Link to post
AndrewB said:

The only truly well-developed (and prevalent) web programming solution, in my opinion, involves a language that is heavily tied in with an unreliable operating system and often costly operating licenses. I'm talking about ASP.NET.


Hold yer horses... server-side programming is whole other beast, no matter what's your language/platform of choice. On the good side, in general you can at least enjoy the benefits of a "real" programming language like debuggers and a stable, predictable platform to run your stuff on. On the minus side, what your funderful code must ultimately do is spit out some client-side, browser-compatible stuff like HTML...and XML...and Javascript...there's no escape from the plague.

Share this post


Link to post
AndrewB said:

Yes, the lack of compile-time checking sucks, though there are programs available that reduce this problem somewhat.

I actually think this is a good thing. First of all, the only reason that variables have types in languages like C or Java is performance reasons. That's all there is to it. It's a lot easier to write compilers that generate fast code when the programmer is forced to declare the type of every variable. Types on variables aren't there because they're a safety measure, but the fact that they can be used to do compile-time checking is an extra benefit.

Secondly, it really makes things a lot easier to deal with when variables don't have fixed types. The most obvious difference is that it saves a lot of time just not having to superfluously re-write type names all the time (ever tried using Java collections, without generics at least? you'll know what I mean). However, it also means more fundamental differences in the type system as a whole - there's no need for warts like "interfaces" for example.

Finally - and I think this is the most important point - it doesn't lull you into a false sense of security. Here's the thing - you should be writing tests for your code. If you aren't, there's a good chance it doesn't work properly. Static type checking provides this sort of "false safety net" that can lead you into thinking that if your program compiles, it works correctly. I'm not saying it's a conscious belief, but rather a sort of unconscious "rewarding" behavior - like, "congratulations! you've fixed all the compiler warnings and errors!"

Type mismatches, in my experience, aren't really that common a problem. The fact that your program contains no type mismatches proves nothing about its correct behavior. Conversely, type mismatches are the kind of obvious and fatal error that will immediately be made obvious as soon as you test the code.

Maes said:

The biggest problem, IMHO, is that there is practically no way to consistently develop and debug: e.g. to test javascript, the only way to make sure it will work is to fire it up in a browser, and then fight with the often cryptic errors (if you get any error warnings, of course...). Then there are browser-specific incompatibilities etc. and the need to couple more than one of these abominations together to achieve a specific goal.

Testing with Javascript is possible, although it's certainly more difficult. Check out the automated test suite for the Dojo Toolkit to see an example of Javascript testing done really well.

XML does suck. Well, not XML itself, but the way it's used. It's supposed to be for markup (that's what the 'M' stands for!) but people seem to have gotten this idea that it's a sensible universal data interchange format, when there are much more useful and sensible formats to use in a lot of cases, particularly for structured data (JSON is pretty neat!)

Share this post


Link to post

For me, Javascript is borderline esoteric, and probably the only practically used language where a quine is not just a mind game, but something very real. You can in fact write Javascript code writing other Javascript code and so on (and sadly, it's used in practice because there's no better way of doing certain things).

If you thought multilevel pointers in C/C++ and self-modifying assembly code were bad, just try debugging multilevel generated code. What tool could possibly automate that? And what high level language allows such a complete travesty?

Even more fucked is the approach of certain tools like Qooxdoo: in no uncertain terms, they completely depart with the idea of developing a sensible IDE for Javascript, and instead implemented cross-compiling of Java and .NET into a virtual machine implemented in Javascript _-_ so basically it's like using javascript to run assembly or bytecodes.

A "language" that requires such workarounds has some serious issues, say I.

Share this post


Link to post
TheeXile said:

I love how Javascript is a language where 3 + "3" = "33", but 3 - "3" = 0.


However, it is interesting what you can do with Javascript with a bit of creativity:
http://oisyn.nl/wolfjs/wolfjs.html

To be fair that's pretty agreeable considering normal string manipulation methods.

If you're going to play with overloaded operators might as well throw out any preconception you have about their typical behaviour.

I actually think JavaScript is a phenomenal language for what it's used right now. If you think in terms of 'web 2.0', loathed as that buzzword may be, JS is a hell of a lot nicer when it comes to writing in-page server/client interaction, as opposed to battling Perl, PHP or ASP with the intention of sending dynamically created answers to the user's input.

Share this post


Link to post
Maes said:

If you thought multilevel pointers in C/C++ and self-modifying assembly code were bad, just try debugging multilevel generated code. What tool could possibly automate that? And what high level language allows such a complete travesty?

Debugging this sort of code isn't really that bad as long as the tools are strong (I do it in Lisp all the time without issue). Javascript isn't a bad language as much as it's a language with poor tools and an even worse environment.

One thing to keep in mind is that many of the web languages popping up are more domain-specific. Writing domain-specific languages is actually a strong way to solve a problem. What I see being more of an issue is over emphasis on the marketability of any new technology.

Share this post


Link to post
DJ_Haruko said:

Debugging this sort of code isn't really that bad as long as the tools are strong (I do it in Lisp all the time without issue).


Since comparisons with the L-thing popped up, we can mercifully end the disussion here. Javascript was supposed to be a simple procedural "do this, then this, then that" sort of language, not a functional language! Hurray, let's equiparate it to lambda calculus and admit it's at least as fucking hard!

...and speaking of strong tools, there just ain't. The problem is that anyone using Javascript expects to use it in a simple declarative "do this, do that, then do that" style, but that soon hits subtle metaphysical limits. And the "tools" for it are nothing more than your favourite text editor and each browser's interpretation of it. Good luck with that...even Lips and Lambda calculus runs in a more predictable environment that THAT...

Share this post


Link to post
Maes said:

Javascript was supposed to be a simple procedural "do this, then this, then that" sort of language, not a functional language! Hurray, let's equiparate it to lambda calculus and admit it's at least as fucking hard!
...
The problem is that anyone using Javascript expects to use it in a simple declarative "do this, do that, then do that" style, but that soon hits subtle metaphysical limits.

Whether or not Javascript was originally intended to be functional language is beyond my knowledge, but it is indeed functional today. Specifically, I'd categorize it as a multi-paradigm language.

But yes, much of the problem with Javascript (actually, with computers in general IMHO) is a lack of a deeper understanding of it among its users. I have little experience with prototype-based languages, but even from what I do know I can see that people tend to approach it wrong. And all I can pin this on is lack of education, and again, over-marketing of the language. Still, given its intended target platform, it does tend to make quick hacks to get things done easy. Going beyond that, things get ugly.

Market anything as "so easy a caveman could program in this!" or "the future of X design", and if the effors succeed, troves of people who think they know it inside and out but don't will flock to it and become its primary vocal user. Vocal being the keyword there.

Share this post


Link to post

I never really bought into the whole dynamic typing concept. I wish I could find it, but I read an interesting article where the guy claimed that what people were complaining about was bad static typing, not the concept itself. The old concept of forcing the programmer to tell the compiler everything (C, Java, etc) is really falling out of favor, and rightly so.

C# in it's latest revision is an excellent example. It's much more pleasant to deal with because you can offload a lot of work for the compiler, even though it's still 100% statically typed. Haskell is another example of a statically typed language that most people would think is dynamic at first glance due to all the type inference going on.

In my opinion the greatest problem with dynamic typing is it makes the tools so much worse. With statically typed languages it's trivial to find the implementation of some method (instead of some other method that happens to have the same name), do complex refactorings of hierarchies, find where variables are initialized, etc.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
×