vmchale

57 ms·

661.
by vmchale 8y ago
> integer under/overflow very few languages actually solve this completely. you'd need refinement types to do so.
662.
by vmchale 8y ago
> the speed difference is pretty much negligible really? I'd say that's quite significant, if it's repeatable.
663.
by vmchale 8y ago
> JS is the assembly of the web, do you also criticize games written in assembly? hm
664.
by vmchale 8y ago
Not having scars on my arm from so many blood samples would be nice tbqh.
665.
by vmchale 8y ago
> I think the most disappointing thing about this whole saga is that (in theory) the Theranos technology was supposed to be a major healthcare game changer. It could have revolutionized testing, and would surely have saved countless live
666.
by vmchale 8y ago
> Invading privacy is good, but only when the more powerful do it to the less powerful.
667.
by vmchale 8y ago
>Rob Pike wrote a bit about it in "less is exponentially more". Which is wrong. >Go focuses on composition Clearly false.
668.
by vmchale 8y ago
None of these are remotely obscure unless you don't know functional programming.
669.
by vmchale 8y ago
> Nowadays I have a strong preference for simple and focused languages that use a small number of patterns that can be applied to a wide range of problems. Haskell is a simple and focused language, provided you use GHC with minimal ext
670.
by vmchale 8y ago
> One of the best pieces of advice I ever got re: programming was, "don't write the abstraction until you've written three cases first". This is good advice in the intended way (you will write the abstraction better
671.
by vmchale 8y ago
> 'There's something very seductive about languages like Rust or Scala or Haskell or even C++. These languages whisper in our ears "you are brilliant and here's a blank canvas where you can design the most perfect abs
672.
by vmchale 8y ago
Not that representing polynomials as linked lists is by any means ideal, but this "first-guess" program is quite elegant in my opinion. I know there's a tendency to over-abstract things among the Haskell community, but if you
673.
by vmchale 8y ago
I use `sn` instead of `du`. It's closer to `du` than `ncdu`. http://github.com/vmchale/tin-summer
674.
by vmchale 8y ago
> Developers love to be able to write their magical code and their clever abstractions and often forget that their code is paying the price by becoming less clear and less readable. Clearly, that justifies the fact that you can't so
675.
by vmchale 8y ago
> I worry about generics because they let you abstract with wild abandon. They let you inject a little magic. Not really. > You can't chain together operators in point-free style, or add a property to every 'Object', or
676.
by vmchale 8y ago
Well, in languages released in the past 15 years, sure. But many languages are not that recent.
677.
by vmchale 8y ago
Won't this still have all the disadvantages of JavaScript being not intended for native? I can't imagine a language with things like 53-bit integers will ever rival the performance of a language that was designed from the beginnin
678.
Show HN: Polyglot, a code counting tool written in ATS(github.com)
4 points by vmchale 8y ago|0 comments
679.
by vmchale 8y ago
> I'll just bet that you haven't read anything, because you disagree with people I think are, like, super-duper smart :) It is quite obvious from what you have said you are not aware of the literature surrounding laziness.
680.
by vmchale 8y ago
You can consult Okasaki's thesis (regrettably it is somewhat out of date) for a list of functional data structures. Some of them are lazy, some of them are strict. But being able to use all them is essential to getting good asymptotic
681.
by vmchale 8y ago
They don't have to be. If cache access has finer controls, the compiler can use them.
682.
by vmchale 8y ago
> If you put the most valuable thing in the universe inside a box that can't be opened or permeated by any force in the universe--then that thing is no longer valuable. Go find the former #2. If you have a programming ideal and that
683.
by vmchale 8y ago
> which is quite hard to completely stamp out all possibility of while retaining the concept of speculative execution So... why not do exactly that? Let compilers access cache and stop this nonsense where we pretend computer memory is fl
684.
by vmchale 8y ago
> Sounds like reasonable removes to me, custom operators are a pain. Not the point. The point is that it breaks backwards compatibility for the arbitrary prejudices of the Supreme Leader.
685.
by vmchale 8y ago
> Any language that depends on people to just "don't do that" is a language that will be full of people who do exactly that. If you make a language for stupid people, that is fine, but I will not use it.
686.
by vmchale 8y ago
> Because spending 10 minutes writing asynchronous FFI code is definitely worse than spending a couple of hours debugging a runtime failure. Or... more than 10 minutes, because you have to re-implement a library that was already written.
687.
by vmchale 8y ago
> Most languages have too many features anyway so removing them can be a positive thing. This is completely unsubstantiated.
688.
by vmchale 8y ago
> One of Elm’s main focuses is code that is not possible to crash Unless you have an infinite loop...
689.
by vmchale 8y ago
> For those of us who desperately want to put javascript (the entire language) behind us, many of the "problems" this article mentions are features. Yes, not having FFI is a feature. Brilliant.
690.
by vmchale 8y ago
Rust has FFI that doesn't shit the bed lol

More ›