wellpast

45 ms·

421.
by wellpast 9y ago
How well can you decouple? That's all I need to know about you. If you can do this well, I (or you) can fix all your bugs quickly. I (or you) can fix (most of) your performance issues quickly. If you can decouple, you can isolate whate
422.
by wellpast 9y ago
I'm still part Alice, I think. The Carnegie book really helped me, for sure. The difficulty though is that at some point if you believe something is important you may ultimately have to go through some kind of dialectic to make your ca
423.
by wellpast 9y ago
Whatever you want to call it, it’s a temper tantrum. It’s what children do in supermarkets.
424.
by wellpast 9y ago
I don't think it's acceptable in any situation to express your frustration this way in a public forum, especially for OSS. Thoughtful critical pieces are fine and necessary, but I don't think blatant vitriolic "cathartic
425.
by wellpast 9y ago
https://joinstarcity.com/ (Found it from last month's "Who is hiring?" -- however it is replying HTTP 500s right now.)
426.
by wellpast 9y ago
> Much of the rhetoric that is currently flying around is a false dichotomy. The author here is missing the rhetoric. The rhetoric is not about the programming language but about how we should be doing information processing. Except that
427.
by wellpast 9y ago
The worst case for the number of places I have to go fix is O(n). I.e., the verification half is O(n). The solution search side ("solving the puzzle") may be worse, because I have to generate/find the code that fits the type
428.
by wellpast 9y ago
> There is no such thing as type checker puzzle once you have learned types, just like you don't stop on each word once you're literate. Your analogy doesn't apply. I can read a book in O(n) time, where n is the number of
429.
by wellpast 9y ago
How would it infer: isOld(parseJson(json)) When parseJson may or may not produce an entity with the "age" property?
430.
by wellpast 9y ago
No I haven't. And, depending on how long life turns out to be, maybe I'll get to. But. I have built plenty of large software systems. And the source of cost in those systems is always -- by at least a factor of a 100 -- was coupli
431.
by wellpast 9y ago
From Rich's talk: "Now at this point I was an expert C++ user and really loved C++, for some value of love." Rich has had many years of experience in statically typed language.
432.
by wellpast 9y ago
This is pretty cool. The Scala version is a little weird. Why do I need a separate Person and Dog class? Can't a dog have a name as well? Why do I need to declare that upfront or ensure that no other part of code can give a Dog a name?
433.
by wellpast 9y ago
Which part is effortless? Solving the type checker puzzle, or asking whether type verification is truly needed in a particular given instance?
434.
by wellpast 9y ago
I can do all kinds of things to prevent bugs showing up in production. I once worked on a mission-critical piece of software in which the entire team was brought in to do a page-by-page code review for all newly written code. Of course, the
435.
by wellpast 9y ago
I just did. Having a Person vs. Cat taxonomy. The claim is about ADTs, not Haskell. When a "name" property will do, why do we need to introduce an ADT? Why do we need to taxonomize?
436.
by wellpast 9y ago
If null pointer exceptions are the most of your problems then I think you're doing pretty well. In my experience NPEs are the easiest bugs to root out and fix.
437.
by wellpast 9y ago
class Person { def age; } There is a second-class "age" property: the only way to specify it or use it is to first declare the ADT/Person class. (In this example, I use a dynamic language; that is, the prope
438.
by wellpast 9y ago
If my function only needs to know the "age", then why am I having to fill out my Person class with all the other stuff? Why, if I have facts about a Cat in hand, must I coerce it to a Person? These are hoops you're typically
439.
by wellpast 9y ago
But "interface bugs" are the least of our problems. As evidenced by most bug queues that I've peeked at.
440.
by wellpast 9y ago
Let me rephrase: A statically typed language typically asks us to redirect our brains from asking the question, "Is type verification really needed in this particular instance to deliver my business value?" to instead solving the
441.
by wellpast 9y ago
> It doesn't if the systems are well-designed sytems, comprised of loosely-coupled components I've been going down a similar line of thought. But I went the other direction. That perhaps in "poorly designed" systems w
442.
by wellpast 9y ago
> Why would you not want to know about these bugs immediately and fix them early in the development process? That's a good question. But enforcing your codebase to be a Rubix cube you have to twist and turn until the static type che
443.
by wellpast 9y ago
What resonates most with me is that traditionally ADTs make the properties second-class citizen to the ADT/class. First-class properties are strong enough semantics and bundling them together in an ADT is almost always introducing coup
444.
by wellpast 9y ago
Aren't statically typed languages "sound models"? Aren't ADTs a form of data structure? I think his point is much more in the realm of abstraction. RH always seems to be trying to minimize the delta between thinking and
445.
by wellpast 9y ago
An interesting thought I got out of this talk is the reminder that most (nearly all?) statically typed languages are really just "mandated type verification" (not RH's terminology, btw). But, in the talk, Rich isn't anti
446.
by wellpast 9y ago
But notice that his arguments are always focused on the tool/feature. You can look at Clojure as a "reference implementation" for many of Hickey's ideas. (A production-ready reference implementation, of course.) But all
447.
by wellpast 9y ago
> Talking in the level of ADTs (or some representation that is equally precise) I will argue that ADTs offer no more precision than first-class properties and first-class properties are much more aligned with human beings natural way of
448.
by wellpast 9y ago
...and which programming language to use. One of the things Rich says more than once in this talk is that he doubts even that programming languages (including his own) are the most important aspect of doing our programming work well. And
449.
by wellpast 9y ago
> Clojure itself and its libraries are very coupled to the Java libraries and the JVM. .... Clojure is very coupled to the JVM This is not true. Clojurescript has been a very productive language for me and for many others.
450.
by wellpast 9y ago
I agree it'd be nicer if he could dive down deeper into tangibles. However that can take a lot of time in a talk like this. Many of the points he makes could almost warrant a whole entire talk/article on its own. For example, he r

More ›