Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The JavaScript Problem

haskell.org

Post reply on HN
Print view View original

141–150 of 183 posts

Re: The JavaScript Problem

#141

Post by Peaker »

LunaSea wrote: post #121
Peaker wrote: post #100

Earlier quoted context omitted.

Call a function "foo" that expects 3 arguments with 5 or 2 arguments, instead. Javascript will gladly accept that and not yield any error, not just at compile-time, but even at run-time! Unless the function explicitly checks that the argument list is correct, it will simply hide the bug. When changing function signatures in any language, it is the programmers' collective responsibility to fix all callers (some of whi…

How is that an issue ?

How is a common change (updating a function signature) easily causing cryptic bugs rather than a visible compile-time or run-time error an issue?

Bugs are bad?

Re: The JavaScript Problem

#142

Post by wyager »

Solarsail wrote: post #104
gordaco wrote: post #91

Earlier quoted context omitted.

>>I feel liberated by not having a strong type system restricting my options. >If you feel restricted by a type system, you're using it wrong. A type system is a useful tool, not an impediment. It only prevents you from doing wrong things. I'm always baffled about how people say that using a dynamic language feels "liberating". I feel completely the opposite; I have to be extremely more careful with a dynamic languag…

Aren't these two equivalent statements? Liberty to do any particular thing, ever, increases the ability to do something wrong. And so requires more caution. That doesn't stop restrictions that would alleviate said caution from being overbearing themselves. (Maybe they aren't always overbearing, either way...)

> Liberty to do any particular thing, ever, increases the ability to do something wrong.

The difference is that "liberty" tends to increase one's ability to do both right and wrong. Dynamic typing tends to only increase one's ability to do wrong.

Re: The JavaScript Problem

#143

Post by stplsd »

SiVal wrote: post #94
bratsche wrote: post #58

Earlier quoted context omitted.

Why do you care what the target of the compile is if you're happy with the language you're writing in? That seems like being upset that some code you wrote in a language you like might be running on some processor you don't like.

because it's inevitably a leaky abstraction

Jesus, the next time I will read phrase 'leaky abstraction' I am going to throw up.

Re: The JavaScript Problem

#144

Post by teacup50 »

somebehemoth wrote: post #134
teacup50 wrote: post #130

Earlier quoted context omitted.

It's not possible for anyone to build complex software in a unityped language while having a full, complete, and verifiable understanding of their own system invariants at any given moment. Claims otherwise are the literal equivalent of making complex mathematical assertions without a single condensed proof . This isn't opinion, any more than a formal proof is opinion.

You are making an opinion as to the definition of complex software. "Complex software" means different things to different people. Additionally, you've inserted a requirement of understanding one's systems that seems arbitrary and not universally applicable. Whatever happened to each his own?

> You are making an opinion as to the definition of complex software. "Complex software" means different things to different people.

"Complex" math or "complex" engineering means different things to different people, but "mathematical proof" and "deductive reasoning" do not.

> Additionally, you've inserted a requirement of understanding one's systems that seems arbitrary and not universally applicable.

It's not arbitrary, it's how we build systems that work, and work better.

http://en.wikipedia.org/wiki/Engineering#Methodology

"By understanding the constraints, engineers derive specifications for the limits within which a viable object or system may be produced and operated."

Without understanding one's system, it is impossible to understand its relation to one's constraints, and it is impossible to define the specifications within which that system operates.

It's possible to build a car or an engine without understanding the math and science behind them, but it's impossible to build an engine of known specifications, it's impossible to provably assert that it operates within those specifications, and it's impossible to engage in directed design based on those specifications and defined operational limits.

The best you can hope for is purely empirical evidence, and empirical evidence is of limited utility without a theoretical framework in which it can be applied to extrapolate further knowledge.

As a result, systems designed and implemented without concern for understanding the theoretical basis of their operation invariably perform more poorly and cannot compete with systems designed and implemented based on building and applying a theoretically driven specification and understanding of constraints.

To willfully prefer ignorance is objectively worse.

> Whatever happened to each his own?

Applied maths. It's either correct and verifiable or it's not.

Re: The JavaScript Problem

#145

Post by teacup50 »

flohofwoe wrote: post #98
AnthonyMouse wrote: post #62

Earlier quoted context omitted.

The issue is that the "compile to" thing shouldn't be another programming language at all. It should be something like Java bytecode. Except not actually Java bytecode, because Java bytecode was made specifically for Java. You want something designed to be an intermediary representation between code in any arbitrary language and native instructions for any arbitrary architecture. In theory you could use Javascript as…

As an example, Portable Native Client is "proper byte code" (simplified LLVM IR), but client-side compilation takes multiple times longer then AOT-compiling the same code from asm.js (the NaCl team is working hard on improving this though). The download size is also almost the same (if compressed). Performance isn't that much better either, so for every practical purpose "real" byte code isn't automatically better th…

On the other hand, because PNaCL is a sane IR, its composeability and implementability vastly exceeds that of asm.js, which requires not only a full JavaScript stack, but additionally, a complex JavaScript JIT system capable of executing it with additional asm.js-specific optimizations.

I can take PNaCL today and deploy it on alternative stacks, irrespective of the web stack. I can inter-operate cleanly with alternative libraries and environments, I can adopt efficient host platform ABIs, I can run it with a sandbox or without. I could even use it as a generic cross-platform sandboxed in-kernel driver layer.

Moreover, should NaCL/PNaCL be successful, there exists the possibility for optimization on the silicon-level via the introduction of new instruction sets that optimize for in-process sandboxing of untrusted code, much in the same way that trap-and-emulate VMs led to much higher performing silicon-implementations of the same ideas.

Issues of performance can be solved given a well-designed system that applies only as much complexity as is needed, at the level that it is needed. asm.js is a hack inserted at an inappropriate layer of the technology stack; NaCL/PNaCL is a coherent compositionally-sane design that opens the door to later optimizations and significant improvements of the underlying technologies on which it rests.

Re: The JavaScript Problem

#146

Post by teacup50 »

Solarsail wrote: post #104
gordaco wrote: post #91

Earlier quoted context omitted.

>>I feel liberated by not having a strong type system restricting my options. >If you feel restricted by a type system, you're using it wrong. A type system is a useful tool, not an impediment. It only prevents you from doing wrong things. I'm always baffled about how people say that using a dynamic language feels "liberating". I feel completely the opposite; I have to be extremely more careful with a dynamic languag…

Aren't these two equivalent statements? Liberty to do any particular thing, ever, increases the ability to do something wrong. And so requires more caution. That doesn't stop restrictions that would alleviate said caution from being overbearing themselves. (Maybe they aren't always overbearing, either way...)

Static typing gives me the liberty to explicitly define much more complex ideas in ways that leverage the compiler to create powerful and beneficial systems that would otherwise be untenable in a language in which one could not leverage the intelligence of the type system to offset their human limitations.

Re: The JavaScript Problem

#147

Post by djur »

teacup50 wrote: post #69
djur wrote: post #53

Earlier quoted context omitted.

It's sad that we should expect Haskell users to be chauvinistic about static typing. I have yet to read anyone who advocates for dynamic typing describe static typing as a "flaw".

There's nothing chauvinistic about it. If you want to hear people honestly and accurately describe "static" type system's flaws -- talk to type system theorists. Type systems can be provably flawed. What you can prove about a uni-typed late-bound ("dynamic") languages is quite simply that they're unilaterally flawed.

The chauvinism involved is the assumption that a type theory is the only legitimate way to assess the quality of a programming language's type system. Haskell is, of course, a near-ideal language when judged by the values of its creators and advocates. The inability to recognize that those values are subjective is chauvinism.

Re: The JavaScript Problem

#148

Post by cordite »

chrisdone wrote: post #140
fiatmoney wrote: post #55

Clojurescript is an excellent solution to most of the problems mentioned. In particular, functional data structures & approaches are a great fit for coordinating dependent updates to a UI based on events happening to a base state - for a concrete example, the Om wrapper around React is very slick, performant, and idiomatic.

Really the only thing missing from Clojurescript, as all Lisps, is static types.

This is especially a problem (which can only be discovered at runtime) with newbies. It has some nice constructs but my friends and even sometimes myself end up with problems like trying to deref an atom that is already dereffed, or not dereffing in the first place.

Re: The JavaScript Problem

#149

Post by teacup50 »

djur wrote: post #147
teacup50 wrote: post #69

Earlier quoted context omitted.

There's nothing chauvinistic about it. If you want to hear people honestly and accurately describe "static" type system's flaws -- talk to type system theorists. Type systems can be provably flawed. What you can prove about a uni-typed late-bound ("dynamic") languages is quite simply that they're unilaterally flawed.

The chauvinism involved is the assumption that a type theory is the only legitimate way to assess the quality of a programming language's type system. Haskell is, of course, a near-ideal language when judged by the values of its creators and advocates. The inability to recognize that those values are subjective is chauvinism.

It's chauvinistic to believe that the only way to assess math is through deductive reasoning?

By that measure, all "STEM" fields are inherently "chauvinistic".

Re: The JavaScript Problem

#150

Post by WoodenChair »

girvo wrote: post #39
WoodenChair wrote: post #11

Earlier quoted context omitted.

What kind of office are you in? If it's filled with a lot of front-end JavaScript "ninjas" I doubt you're going to make much headway. I hate to be pejorative, but I do mean the ninja part pejoratively. My best advice would be to try to start by convincing the guys with the most dev experience in other languages/serious dev experience/(dare I be controversial and say )guys with the most formal CS education first.

Mostly back end guys who have to do front end, and the genuine front end guys are indeed "ninjas" (though, I must say they are very good at wrangling JS and debugging the problems we inevitably run into). My boss is convinced at least, and I recently just convinced the team to move to proper testing + CI system (which the boss had wanted to do for 12 months but never had enough buy In from the team, so he was pretty…

You're not going to get anywhere with the ninjas. Suggest a system that's similar to what you do your backend in. Is your backend in Java? Suggest Dart. Is your backend in C#? Suggest TypeScript. Is your backend in Ruby? Maybe you can at least get some CoffeeScript going.
Post reply on HN