Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
vmchale
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
58 ms
·
721.
▲
Polyglot – a code counting tool written in ATS
(github.com)
2 points
by
vmchale
8y ago
|
0 comments
722.
▲
by
vmchale
8y ago
so now only typing `npm update` will get your data stolen. how innovative.
723.
▲
by
vmchale
8y ago
Right but node projects tend to use ten billion trivial packages to do anything whatsoever (no standard library!) so the problem does get exacerbated. Moreover, npm has been told multiple times how to avoid this and they did not care .
724.
▲
by
vmchale
8y ago
It would have prevented this from happening.
725.
▲
by
vmchale
8y ago
Here's an example from one of my projects: https://github.com/vmchale/polyglot/blob/master/atspkg.dhall
726.
▲
by
vmchale
9y ago
I wrote tomlcheck ( https://github.com/vmchale/tomlcheck ) in Haskell.
727.
▲
by
vmchale
9y ago
>Sane indentation for a functional language, known as "backstep" This is A) not an impressive problem to solve, and B) not actually a problem in Haskell or Elm.
728.
▲
by
vmchale
9y ago
None whatsoever. Hindley-Milner is in fact used widely in language design because of its relatively good error messages (as well as ease of implementation). Also it really doesn't have much to do with category theory.
729.
▲
by
vmchale
9y ago
I doubt they would admit anything of that nature. And yeah, I don't understand why the CEO of the company would think this would help their PR. Even if it was a secret.
730.
▲
by
vmchale
9y ago
I have a hard time seeing the value in a Mandelbrot benchmark. I absolutely don't have a problem with benchmarks that make Haskell look bad (e.g. directory traversal, regex), but I would like a benchmark that provides insight into the
731.
▲
by
vmchale
9y ago
You might have better luck with the fast-logger library, for one. I'd also suggest using ansi-wl-pprint, which would work on Windows and also probably be faster than string concatenation (which is just plain bad in Haskell). As was poi
732.
▲
by
vmchale
9y ago
>I believe there's a case that funding MDMA research has very high dollar/impact returns - or at least that it's likely enough that it's worth a thorough exploration. Sort of? I'm sure there's potential, but
733.
▲
by
vmchale
9y ago
That's... not really true. JavaScript solves trivial problems, and it's mainly popular because it's literally the only web language around.
734.
▲
by
vmchale
9y ago
C++ is legacy. It was created in 1979.
735.
▲
by
vmchale
9y ago
>There's no general purpose idiom you can use to replace all loops, only tons of special purpose HOFs you must memorize. Ah, but there is! Recursion schemes. >Usually an imperative algorithm will be much clearer in an imperative
736.
▲
by
vmchale
9y ago
>Computer Language Benchmarks of GHC versus C don't seem to be close to matching your 80% as fast claim [1]. Also, the 10% of the effort of hand-optimized C bit - seem to recall there was a caveat - "if you happen to Don Stewar
737.
▲
by
vmchale
9y ago
>Haskell addresses this common concern by allowing you to turn off laziness altogether so everything evaluates eagerly It's a common concern but it's a terrible critique. Laziness has many subtle benefits, but everyone whines a
738.
▲
by
vmchale
9y ago
Do you have source code? It sounds like you were writing unidiomatic Haskell.
739.
▲
by
vmchale
9y ago
>But Rust gives me all those things, as well as iterators for laziness when desired, without the pervasive laziness that had me constantly chasing down space leaks Well, yeah, Rust has manual memory management. Of course you don't g
740.
▲
by
vmchale
9y ago
>GHC honcho Simon-Peyton Jones saying the next Haskell will be strict, I think all he meant that strictness was an interesting paradigm that would differentiate a language enough to justify its existence alongside Haskell. >Following
741.
▲
by
vmchale
9y ago
>It was very frustrating to try reasoning about performance in Haskell due to its laziness. Conversely, I find it hard to achieve the same performance with strict code. I think it's likely a matter of familiarity. >Haskell is not