wellpast

20 ms·

181.
by wellpast 7y ago
I would love to read this. Thank you.
182.
by wellpast 7y ago
I wonder how they are able to trace and capture variable and stack state at a rate of 20M invocations — per second!? How is this possible on the JVM? (I’m aware of the instrumentation API that profilers use but I thought they had to do samp
183.
by wellpast 7y ago
I take your point that all of these Hickey comments resonate with ideals of Haskell. The last piece of the puzzle would be to discuss why Hickey -- in addition to these points -- also is overtly against static typeing and the kinds of idi
184.
by wellpast 7y ago
Sorry to mishear your prior point about omitting the field entirely.. But let's set that aside and focus on the pre-declaring of your ADTs, as you suggest. This is no trivial matter. In fact this is the crux of the issue if not a large
185.
by wellpast 7y ago
Thanks for your reply, as well. But there’s no indoctrination going on. It’s right there: > If you know that a field of a data type is going to be unused you can fill it in with an `error` I don’t want to fill anything in. I don’t want t
186.
by wellpast 7y ago
What I find crazy about these conversations is that I will say “I don’t like that I have to do X...” And the response is always “But that’s easy you just do X...” The argument is not that you can’t do some task in Haskell. With enough time
187.
by wellpast 7y ago
You're not confused. I think you're right that both cljs/go and js/async blocks are giving a 'procedural way' to basically create an asynchronous processing/state machine. It would be interesting to see a
188.
by wellpast 7y ago
At first glance the cljs community doesn't seem short on libs that give await/async-like abstractions and from what I recall JS interop in CLJS was smooth enough to operate directly against Promise objects. In Rich Hickey's f
189.
by wellpast 7y ago
> Pattern matching for one. I can prove that 3 cases won’t be met but I have to ‘fill in’ them anyway. >> This is a funny one because, no, GHC will not ask you to fill them in! You have to turn on a warning for it to complain. The
190.
by wellpast 7y ago
I spent too many years programming in all kinds of dynamically typed and statically typed systems and I kept a clear head and didn't cling to a blind religious persuasion. I've also watched the performance of static type enthusias
191.
by wellpast 7y ago
> There is nothing you can do in a dynamic language you can't do in a typed language. There is nothing one can't do in assembly that you can't do it in a higher-level PL. The argument is not what one can or can't do.
192.
by wellpast 7y ago
I can use strong typing productively. I can use dynamic systems _way_ more productively. When all things are equal, the impedance is not from lack of skill. It is staring at you straight in the face: it's a rules-based type prover that
193.
by wellpast 7y ago
If you are truly doing an apples to apples comparison here, I suspect you’re using a struct subset of your dynamic language. Otherwise I can’t see how the addition of a rule-based static-check pass filter gets you faster. What are the two s
194.
by wellpast 7y ago
Here’s another that kills me every time, I want to compose where I know types are mismatched and I am okay with a runtime fault downstrean . This is hugely powerful to move very fast in, eg, REPL-driven development environment where you
195.
by wellpast 7y ago
And these are insanely expensive to deal with over time when you compare to the alternative.
196.
by wellpast 7y ago
This is not an opinion thing. If you’re saying that type checkers can reject code at no worse than the same rate as dynamic runtimes then you are just plain wrong. In any case the burden is on you to show this with the slightest sketch of
197.
by wellpast 7y ago
Pattern matching for one. I can prove that 3 cases won’t be met but I have to ‘fill in’ them anyway. ADTs with non-Maybe fields. I can prove that all is fine if this ‘slot’ isn’t filled in. Trying to pass an opaque reference down a function
198.
by wellpast 7y ago
Nope. Not everything is "every way is just as good as the other". >Whatever you like and whatever gets the job done: bravo "The job" is this: it's an optimization problem of maximizing development throughput. Tha
199.
by wellpast 7y ago
> Just because an expressive static type system is available, doesn't mean you have to use all of its expressive power. There's nothing stopping you from writing your system using little more than String, Int, lists, IO etc. Of
200.
by wellpast 7y ago
I will probably get stomped on for this but to me it's a giant elephant in the room. When that one purist on the team proposes mandating having 100%, 80%, or any hard number of unit test coverage, most sane people tend to disagree an
201.
by wellpast 7y ago
> explain why Susan Sontag is considered an important American intellectual figure ... whose contribution seems to be just...being that kind of person This to me is akin to asking that common pedestrian plaint about art, "Why is a M
202.
by wellpast 7y ago
See the link to Rich Hickey’s talk in my other comment. It covers the issues pretty well. I’m not being contrarian, but I am expressing frustration with a common yet unnecessarily complicated approach to a general problem. But I stand by my
203.
by wellpast 7y ago
If the semantics change, why do you need a “-2”? If the semantics don’t change, why do you need a new URI. Keep in mind you don’t have to focus on the suffix or the last part of the path name when you are naming things by URI. Also, why is
204.
by wellpast 7y ago
Rich Hickey explains a similar thinking in this talk https://youtu.be/oyLBGkS5ICk but it’s more directed at code libraries. The same arguments apply. I 100% think this is the way to go for internal APIs. For public APIs I m
205.
by wellpast 7y ago
Or no versioning. Create new endpoint URIs for new semantics. Use vocabulary-based (property-based) entities and never change word (property) semantics. Contrary to its unpopularity (or because of?), this “strategy”* is far far simpler to
206.
by wellpast 7y ago
Noir film , the same deal. “I know you like a book, ya little tramp. You’d sell your own mother for a piece of fudge. But you’re smart with it. Smart enough to know when to sell and when to sit tight. You’ve got a great big dollar sign the
207.
by wellpast 7y ago
Here's a good adjacent read that I thought was a much clearer and relatively accessible tour through the Proof - https://www.amazon.com/G%C3%B6dels-Proof-Ernest-Nagel/dp/081... - it's more of a pamphlet
208.
by wellpast 7y ago
I’ve always found it much easier to lean on downloaded transactions. Data entry through the day is way too cumbersome to me. Am I alone on this?
209.
by wellpast 7y ago
This is a great list of my exact same needs. I believe that the correct solution is a desktop application. How many of you/us do you think there are? And how much would you/they pay for this?
210.
by wellpast 7y ago
Sontag's journals are a fun read. They are like a twitter stream of her random thoughts, from the 60s and 70s. Weird, fevered, genius stuff. e.g. She predicted the iPhone: > A novel about the future. Machines. Each man has his own m

More ›