Hacker Newsnew | comments | show | ask | jobs | submit | cschneid's comments login

I've explored ghcjs. I had a reasonable react based site down to ~400k after dead code removal and minification. Still biggish, but not multi-megabyte.

The raw unoptimized code was in the several megabyte range though.


I think it would be worth sharing that on a blog post submitted to HN. Sounds like a lot of work, maybe there are ways to automate that with a shell script or a Haskell program. 400KB is absolutely okay I think.

I agree, that would be awesome to study/emulate. Possibly use some of the techniques to make GHCJS programs smaller.

What is the 3 color chart that I've seen posted in several of these articles? I get that it breaks down the different CAP combinations with the things that it allows/implies. But is there a good breakdown of all the terms and what they mean?

-----


Here is a paper [0] out of Berkeley that explains the chart you're asking about (the chart appears on page 8). For more information on each isolation level you might have to refer to the cited works or other sources.

[0] http://db.cs.berkeley.edu/papers/vldb14-hats.pdf

-----


Thank you! That's perfect.

-----


The afl fuzzer relies on compiling C code with its own compiler, so I think it's limited to only C based programs.

What you may want is to use something like `quickcheck` (scalacheck or clojure's test.check I guess?) to send lots of "arbitrary" xml at your code and see what breaks. With sufficiently interesting definitions of "arbitrary" you can probably find bugs.

That approach would be testing inside the process, as opposed to passing in whole http requests. But if you know a section of code is more vulnerable than others, focus on it. No need to test all of tomcat's http parsing when you really care about your specific library.

-----


Keegan McAllister has got AFL working with Rust code: https://github.com/kmcallister/afl.rs

Rust is designed to be memory safe by default, but fuzzing is still useful for testing unsafe code, and for finding assertion failures.

-----


It even happened the other night on The Nightly Show - an otherwise wildly liberal show opened their panel with a recommendation that Tsarnaev should be raped in prison.

The amount of vengeance in the american system, at the total exclusion of anything else disgusts me. See-also the torture that is super-max [1].

[1]: http://www.nytimes.com/2015/03/29/magazine/inside-americas-t...

-----


White males being raped in prison does not figure very high in the liberal agenda. The prison rape elimination act was a result of lobbying by conservative and Christian groups.

-----


I have been using spock for a 2-3 end point website. It's good. Very simplistic form of web framework (along the lines of sinatra).

The docs should be a bit better, with some examples of how to use the database and session features. I couldn't figure out how to get the database pool to work with Persistent (a db mapper library).

I bet its obvious to somebody with more knowledge of the type system extensions used, but I gave up after playing with it for an hour or two.

-----


Did you look at https://github.com/agrafix/funblog ? It shows how to use Spock with persistent.

-----


Amazingly in depth post!

I'm sad when programming languages have to reach for new keywords and syntax to add features.

`function*` is difficult to google for, and doesn't have any human readable hints for somebody to understand.

-----


JavaScript is constrained by backwards compatibility. That’s why the ideal solution, the keyword `generator`, wasn’t possible.

-----


This can't be about backwards compatibility. If it was, they wouldn't have been able to add 'yield, 'await' etc.

I don't agree the keyword "generator" would have been ideal. It wouldn't work when using 'enhanced object literals' [1], where you can declare a method without even using the keyword "function". In this case, if you want the method to be a generator, you can just put an asterisk in front of its name, so it's consistent with the "function*" syntax.

[1] https://babeljs.io/docs/learn-es6/#enhanced-object-literals

-----


FYI, "yield" has been a reserved word since ES5 and "await" is becoming reserved in ES6 (for eventual use in ES7): https://mathiasbynens.be/notes/reserved-keywords

It seems like a word must be reserved for at least one ES version prior to it being used.

-----


What about the "yield" keyword?

-----


It's only valid as a keyword within the `function*` block, so the parser can treat it as an identifier elsewhere. I haven't read the detailed spec, so I'm not sure that this is the standard behavior, but this would be a way to preserve complete backward compatability.

-----


Yes, that’s how it works. `yield` is only reserved in ES5 strict mode. But due to it only being a keyword inside generators, there are no problems in non-strict mode.

-----


Why do you think the current syntax is more backwards-compatible? Vanilla ES5 parsers complain loudly when seeing "function *".

-----


It's the other way around. ES6 needs to support loading ES5 content. They can't make 'generator' a keyword because it was a perfectly fine variable name in ES5.

-----


You are right. My bad.

-----


That would be considered "forward-compatible".

-----


which is strange, considering the `async` keyword in upcoming versions.

-----


AFAICT, `async function` is OK, because you combine a keyword with something that is contextually turned into a keyword. With a single non-keyword that isn’t possble. For example, the following code (a hypothetical ES6 anonymous generator expression) could be an ES5 function call followed by a code block.

    generator (a, b, c) {
        ···
    }

-----


That's why it wasn't included in the ecmascript 6 draft. In es6, "async" and "await" are future-reserved keywords. It's kind of a process of marking variables named "async" as deprecated. The spec authors have to balance compatibility with making the language pleasant to use.

-----


Is there even any situation where "async function(..." or "generator function(..." is currently valid syntax?

-----


I don't think googling is much of an issue here. Unless you're talking about the very first occasion that someone sees "function*", then OK, they can't google for that easily... But they can google "function with astersik" or something and they'll find out it's called a "generator", and use that in future.

-----


An unpopular opinion on a post about JavaScript maybe, but C#, Python, and others have implemented generators with no extra syntax because of an actual type system aside from "object, number, string, bool".

-----


I keep tax and similar docs on dropbox inside a truecrypt encrypted disk. Suitable level of security for my needs, and I like that its synced across a few systems (including one that is separately backed up).

-----


Good article. I like these articles that discuss haskell from a practical engineering point of view, rather than the bleeding-edge researchy point of view.

Even if I disagree with some of his style, its a cool way to get a starting point and begin getting a feel for what good haskell code looks like, and how to lay out an application.

-----


Also a good tutorial for getting a good feel what good Haskell code looks like and how to lay out an application is the howistart tutorial[0].

0: http://howistart.org/posts/haskell/1

-----


The downside of using (.:) is that it is used heavily in other libraries (Aeson for instance) in a very different context (field accessors, similar in look to json's `:`).

-----


Its riding the haskell bandwagon to some degree. By borrowing ideas from category theory they have some really nice abstractions in practical code. But then it gets more confusing so you want to loop back and see what the actual definition of a "monoid" is, or understand "functors". Even if haskell's idea of functor isn't 1 to 1 with category theory's.

-----


The only thing I can think of that's wrong with Haskell's functors is that they're more specifically endofunctors, or am I missing something else?

-----


And Hask is arguably not a proper category

-----


Can you expand on this? I'm genuinely curious.

-----


My understanding is that it's not a proper category due to the presence of Bottom - https://wiki.haskell.org/Bottom

> Bottom is a member of any type, even the trivial type () [...] If it were not, the compiler could solve the halting problem and statically determine whether any computation terminated

You can imagine function composition and identity don't work too well on things that never complete.

-----


Ah yes, you're right. I always forget about bottom.

-----

More

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: