Comment by bad_user | Hacker News Reader

Comment by bad_user | Hacker News Reader

Parent Full thread

    they cover 80% of the use-cases

No they don't, it's actually the other way around -- try recreating Rails in Scala.

For that matter, give me an ORM written in Scala that's both (a) stable and consistent + (b) usable without me having to bash my head against the keyboard.

The reason why you cannot recreate a Rails clone is because Rails works basically by redefining everything at runtime, over and over again ... the whole Ruby language is built from the ground up on redefining classes (for the "class" construct, defining new classes in case they don't exist, that's just a side-effect). I'm not saying you cannot build something better in Scala (time will tell), but that something has to be a lot different and a lot more effort will be required.

Yeah, you can do "var a = 1" in Scala, that's nice.

    the path forward for programming will see 
    a convergence between static and dynamic typing

Actually the path IMHO is a bigger separation between static and dynamic, with optional static types introduced in dynamic languages as hints for performance purposes.

Basically that's because OOP is inherently incompatible with static types and because type classes are inherently incompatible with dynamic types.

It might not cover 80% of rails, but rails isn't 100% of programming. Also, the feature lacking in Scala that would help the most with both of your examples (rails and ORM) is meta-programming, which is somewhat orthogonal to the issue of static typing. And you're right that a well designed meta-programming solution wouldn't be a clone of the Rails framework - I think it would be superior in some important ways.

Why do you say that optional static typing introduced into dynamic languages is a divergence? Coupled with looser typing from the static languages, that looks like convergence to me. And what part of OOP do you see as incompatible with typing?

Rails is just an example for which dynamic typing works great -- that's why in my initial comment I mentioned style + use-cases.

Dynamic typing simply works better when you're dealing with external-interfaces that are dynamic in nature (i.e. data-structures and interfaces defined outside of your software). Web applications, because they deal with a lot of text-manipulation and because they also deal with external data-sources and multiple layers, are the prime example for which dynamic typing works best.

    Why do you say that optional static typing 
    introduced into dynamic languages is a divergence?

Is not a divergence per-se, but the purpose of static types is to prove correctness of types from compile-time. Dynamic languages (as they are used) only need static types for performance reasons, that's why the optimal implementation will consider these types as hints and nothing else.

     what part of OOP do you see as incompatible 
     with typing

A static-typing system, to function properly, must be able to trace the true type of a variable throughout the code and be able to use that type at any given time in the compilation process.

In OOP you don't know the type of variables at any given time, you can only know its interface at most. And even that is incompatible with OOP, as OOP was also designed around the idea of overriding the method-dispatching being done (even in Java/Scala, all method-dispatching is done at runtime, as you're dispatching based on the implicit parameter).

For example, Scala cannot implement the Hindley–Milner algorithm for type-inference, being forever forced to the current poor implementation that only deals with inferring the type of local variables. And F# / Ocaml on the other hand really have 2 type-systems in a single language (to be able to keep Hidley-Milner , with rules for interoperability. And when working with one or the other, it's like working with different languages.

And the truth of the matter is, if you're watching closely, hybrid languages that are trying to combine static and dynamic really give you the worst of both worlds.

> (even in Java/Scala, all method-dispatching is done at runtime, as you're dispatching based on the implicit parameter).

Uh ... invokestatic?

> For example, Scala cannot implement the Hindley–Milner algorithm for type-inference, being forever forced to the current poor implementation that only deals with inferring the type of local variables.

The reason is that Scala has a much more powerful type system, than one that can be inferenced completely by HM (The HM type system was kept simple for exactly that reason).

Actually, the Scala language specification leaves out type inference for a reason: It is improved with every release to inference more and more useful things.

I'm getting slowly annoyed by those people thinking that a HM type system is "the best thing ever". Yes, it is simple, and simple is good.

But look at what Scala's type system can do as a comparison.

Please, get some idea what you are talking about before trolling about it.

"The reason why you cannot recreate a Rails clone is because Rails works basically by redefining everything at runtime, over and over again ... the whole Ruby language is built from the ground up on redefining classes (for the "class" construct, defining new classes in case they don't exist, that's just a side-effect)."

I don't think that runtime overwritting and creating of classes is something good per se. It's just better than code generation tools in Java. Well, monkey patching is even worse.

Why is this even needed? What is missing in the programming language to be able to describe these things without the need of dynamic code generation?

    Well, monkey patching is even worse.

That's why in my initial comment I talked about style.

If you haven't worked with a given style, you're prone to harsh judgments and mentalities such as this one. Redefining classes/methods/interfaces at runtime works great for a lot of people ;)

    Why is this even needed?

In case you're working in Java, you may not realize it, but the libraries you're using are probably doing it.

The real difference is in these cases, say for example aspect-oriented programming or dependency injection or all the other buzzwords you had to learn for Java in the last 10 years -- which require big-ass, bloated, incomplete and extremely buggy libraries -- in Ruby/Python are as natural as "Hello World!".

To put it simpler - dynamic languages allow you to treat code as data and to mutate it in however ways you like.

Catching bugs at compile-times is not just about syntax-related errors or checking if some object responds to some method call. If you really want to catch errors at compile-time, you have to dig a whole lot deeper than that, which more evolved static languages are kind of doing (mostly by forcing you to model your data-structures in a certain way, such that the language can understand its purpose and mathematically prove stuff).

But then again, Java is not a representative of static-languages, mostly because Java is a fucked-up hybrid, having all the disadvantages of static-types with none of the advantages.

When talking about static types, you really should be talking about what Haskell can do. And even Haskell has limits that dynamic languages don't, that's why it comes with its own macro-language to alleviate that.

Why do you think I'm advocating Java, because the word Java is contained in my post?

I know C++, Python, Common Lisp and Haskell pretty good.

I asked serious questions why problems are solved in the way they're solved, which language features are missing to solve it in another way.

The current way might work for you, but considering bigger projects and human fallibility, I don't think it will scale that well.

Restrictions aren't per se something bad. Considering your own limitations, they can empower you to handle even harder and more complex problems.

"works great" doesn't necessarily exclude "it's a stupid thing to do".

I wonder how things like concurrency are expected to work, if no single line of code can be sure that things it expects will exist at runtime. Or maybe exists every 5 seconds for 3 seconds. It is an optimization nightmare (proven by the abhorrent performance Ruby exhibits).

Even the Ruby "developers" have understood that monkey-patching is bad and decided to do something against it.

Reply on news.ycombinator.com