Hacker News Reader

Comment by givan | Hacker News Reader

This is how people that think in oop and love java think, everything that does not have classes is unmaintable, this is very subjective.

View on HN

No, this is what people that have real life experience from large scale applications think.

I have quite some experience with most mainstream dynamic languages, and wouldn't do any large scale application with any of them.

The company I work for, does large scale enterprise consultancy projects.

This means:

- Multiple development sites;

- Some projects have up to 200 developers;

- Usually several megabytes of source code;

- Continuous Integration build systems with automatic unit and integration tests

- Usually distributed architecture

- High performance requirements

No way I would advise anyone to do develop such systems in a dynamic language, let alone in JavaScript.

Maintaining a large PHP project written by idiots, in addition to a much smaller codebase in Javascript has convinced me of the importance of static typing for large-scale projects.

It's about the type system.

Dynamic, weak typing makes writing static analysis/refactoring/etc tools extremely hard, but more importantly makes nearly any compile-time guarantees impossible. Having your app crash because of a small typo of a member name is impossible in C++/C#/Java. It happens to me almost once a day with Node/JS.

This rings very true to me too, as our entire application is written in Perl. As much as I do like the language, the lack of just about any static guarantees mean we regress an awful lot. Yes, we have unit tests, but until we have 100% coverage we have gaps for regressions that a compiler could have picked up.

Anyone doing a large project in an weakly-typed language will eventually spend more time writing unit tests than features.

No-one should even be thinking about unit tests if they are not already using a language in which all code paths can be evaluated and type-checked at compile time. Why get a dog and bark yourself?

This is not why you write tests. You write tests to be sure nothing breaks when you make changes.

And you should do this with any language, typed or not.

Using a language with static typing means that there are a lot of tests you don't have to write. Do you remember the units trick from physics? If you forgot which equation you're supposed to use, keep on using identities until you're in the units you're supposed to be. Static typing checks that your units are correct for free.

Well, not entirely for "free", but I do agree that the price is much lower than what you end up paying eventually for the convenience of dynamic typing.

I don't ever have to write a test in OCaml to tell me what I need to fix if I change a function signature, or add another item to a struct or an enum, or change a function to return something else, or anything like that. The compiler does it all. Every code path is evaluated at compile time. 90% of unit testing is just not needed in OCaml or Haskell (and that which you do need, there's QuickCheck for).

I had the same experience when writing Haskell. I would start by inserting a function call at the top level referencing a function I hadn't written yet, and then start hacking on the function and all its helpers. Without fail, as soon as the program compiled it was basically correct. The only thing that could go wrong were legitimate algorithmic errors, such as using the wrong base cases for recursion or something.

So how about using a tool like jslint that will get you 90% of the static checking and will solve the kind of crash you mentioned ? Looks pretty good to me.

Does jslint handle imports? Which would be surprising, given the lack of a standard system in Javascript? If it doesn't, then this leaves you very far from your 90%.

On the other hand, pylint for Python is really good for static checking, even if it won't catch everything.

Except that to work around the pesky types, Java people started moving everything into XML. Now they have a horrible solution to being able to work typeless.

Apparently you haven't looked at Java development in the last 5 years, so you may want to stop making statements about it that make you look like a fool.

I just did a three month enterprise Java project. I admit that I hadn't used it in a while, so I picked Spring like in the old days (+Hibernate at first, but had to kick it out eventually). And hell it turned out complicated (even with Spring). What is the new mantra that makes Java suddenly usable? Playframework?

It doesn't look like you're interesting in anything except following your own mantra of "Java suxx", but XML configuration files (which were never really about working around the type system) have been almost universally replaced by annotations.

I know about annotations, but I admit to not being the biggest fan. And they lead to even more files...

How so? I've only ever seen them eliminate external configuration files. Hell, thanks to annotations and some simplifications to the standard, EJBs have turned from the epitome of overengineered bloat into a simple, lean service layer.

Annotations have only ever led to less files for me

Could you elaborate(/give references) about your claim?

(I don't know anything about the GP, but I really haven't looked at Java development in 5++ years. (-: If nothing else, I might need to update my jokes :-) )

XML configuration files have pretty much disappeared/become optional. It's all done via annotations nowadays, which are much less verbose since their context is implicit, and which are actual language constructs known to the compiler.

Thanks!

Annotations have the disadvantage of needing a recompile to reconfigure?

Can I ask why you're rewriting code on your production server on the fly without the aid of the rest of your tool chain?

In any good development shop you make a change, your CI server picks it up, builds it, and creates a release candidate you deploy. Every change should be checked into source control and built by your automated build bot.

At that point the difference between changing an annotation and an XML configuration file should be moot. I'd think the annotation would be easier because you can still mess up the syntax of the XML file pretty easy (e.g. "Can you change the blahblah label to System & such?" That ampersand will hose your system when you get it to production).

Well, there's always some genuine configuration that contains the actual differences between environments, like DB connection and API keys, and which isn't going to be part of the automated build.

But that's a tiny subset of what architecture astronauts try to label "configuration".

By the way, if all you need is classes, there are many many libraries that give you those in JS (not to talk about CoffeeScript).

What I really miss from a maintainability point of view with javascript, on the other hand, is better development tools (ie IDEs and testing tools). I'm pretty sure there is a big opportunity there.

> everything that does not have classes is unmaintable

Not that javascript doesn't. It doesn't have the sugar around it, and it doesn't statically check them. But javascript's OO is not "prototype-based" (that doesn't even make sense, prototypes are not a unit of reuse in Self) and it's not anything even remotely close to Self's.

Javascript's OO is single-inheritance class-based with no `class` sugar but at the end of the day it behaves pretty much the same way (and offers no more features — less if anything) Python's or Ruby's class-based OO work (sans metaclasses).

Was the argument really about classes? I would have expected this to be about the lack of namespaces. (I can't watch the video, it stops to buffer every second.)

Yet Google agrees with him and pushes Dart

I think they're covered under "think in oop and love java"

I don't think the Go developers "think in oop", and they certainly don't love Java.

Note that Go has no 'classes', and doesn't follow what many people consider mainstream OO principles (eg., inheritance), and many people would say this is one of the things that make it so great, specially in large projects (working out a good type hierarchy, and evolving it over time is extremely difficult and painful).

The problem with JavaScript is not lack of 'classes', but a not just dynamic but also very weak type system.

Add to that the callback-hell caused by the async model of things like Node.js, and you end up with something very hard to maintain quite fast.

You definitely can create classes in JavaScript, its just not especially convenient.

But to me its not really a critical issue, because OOP is very easy in CoffeeScript, which is my favorite language and happens to compile to JavaScript.

Reply on news.ycombinator.com