wellpast

34 ms·

241.
Thinking-Oriented Programming(write.as)
2 points by wellpast 7y ago|0 comments
242.
Static Typing Where Possible, Dynamic Typing When Needed (2004) [pdf](ics.uci.edu)
2 points by wellpast 7y ago|0 comments
243.
The Problem of Mindfulness(aeon.co)
1 points by wellpast 7y ago|0 comments
244.
The Master Programmer(write.as)
2 points by wellpast 7y ago|0 comments
245.
by wellpast 7y ago
> there you find data types defined entirely in terms of functions - pure behavior! In every programming environment that I am aware of, such data-less functions you describe would be happily deleted without any worry to customers &
246.
by wellpast 7y ago
I agree and I think rules are pointless. Everything is a tool and you pick the right tool for the job and that requires context and thinking. However, having built systems in OO and then in functional, I've come to realize that the OO
247.
by wellpast 7y ago
> Data is defined by behavior, even for "plain old" types. This is the POV of the OOP-ist, but it is not necessary and it is limiting. It's actually the "debate" we are having, so asserting it isn't provin
248.
by wellpast 7y ago
(The talk you link to is strongly anti-OOP. I assume you linked it as an example demonstrating your statement that anti-OOP is on the rise these days.) To respond to your point, though: Traditional OOP wants to meld behavior into the noun
249.
by wellpast 7y ago
Android -> Java? Java dominated well before mobile. Also JVM languages are surging even though none have a specific killer app. But Clojure is still niche. And is the most powerful/simple of them all. I think there’s something else
250.
by wellpast 7y ago
There is a famous book called The Varieties of Religious Experience. It's probably good or something. I mean, I've never read it, but let me co-opt its title while subtly dismissing it, as a light segue into my blog post...
251.
by wellpast 7y ago
The Ghost Not article/paper/essay sits adjacent to The Programmer's Stone and is mind-blowing. https://www.datapacrat.com/Opinion/Reciprocality/r2/index.ht... I'm very curious the history
252.
by wellpast 7y ago
I hope you're not suggesting that it's impossible to write this function without such constraints. If so, you should jettison your PL as fast as you can. In any case this is precisely the trouble I believe the typer enthusiast get
253.
by wellpast 7y ago
You're looking at this Python code and blaming its deficiencies on lack of types. It's deficiencies are not lack of types, but lack of separation of stable vs volatile code, lack of contract specification and documentation, lack o
254.
by wellpast 7y ago
You would stop wearing a bike helmet if: - It made you top heavy and more likely to crash - It reduced your speed in half The tacit implication (or elephant in the room) when someone argues for types and the presumed safety they
255.
by wellpast 7y ago
Static typing cannot ensure about their code what the coder can and should ensure about their code. And often -- very often -- especially in strongly typed languages -- the static checker will reject code that is otherwise valid. First po
256.
by wellpast 7y ago
This scares the hell out of me when I hear people say stuff like this, because if you think a type system is going to save you from your outages then that means you're not aware of a whole other more comprehensive, efficient and dynami
257.
by wellpast 7y ago
Okay, let me be more specific. I've built complex React apps full-stack down to Postgres and maintained them over ever-evolving/increasing product requirements. To schedule. With a tiny team, part-time dedicated. And little mainte
258.
by wellpast 7y ago
You’ve just described hell.
259.
by wellpast 7y ago
You need to rethink your #1. How about calling the function derivative? Sounds like you could have used real documentation.
260.
by wellpast 7y ago
Sounds like you could use some real documentation.
261.
by wellpast 7y ago
f(+’,1,2) = “cookie” For one. Now tell me: are types the best documentation?
262.
by wellpast 7y ago
Infinite.
263.
by wellpast 7y ago
Types alone are severely insufficient documentation. That’s the refutation of the original poster’s claim.
264.
by wellpast 7y ago
> Once you really understand the typesystem, most of the time, types really are the best documentation --- they often tell you exactly what the function does, in a way that English comments never will. Snake Oil. Apply this claim to any
265.
by wellpast 7y ago
Runtime checks are much, much more flexible (because they are ad hoc), more compose-able (they are written using the PL itself), _and_ more capable (you have the full breadth of the PL semantics). I could go on with concrete examples to dem
266.
by wellpast 7y ago
This is all false. You can get input data verifications dynamically or statically. You don't have to use static type verification to verify data inputs and dynamic validations are much more expressive and simpler. See the immensely exp
267.
by wellpast 7y ago
I will say that immutability helps a lot. Clojure is dynamic but immutable-oriented, and refactoring with deferentially transparent S-expressions is a delight— + you don’t need type system for this.
268.
by wellpast 7y ago
More or less, yes. But I also worry about the team that thinks a statically typed language is going to save them. I think at the end of the day you have to do this job well or you don’t get any guarantees. I’ve seen people make equal messes
269.
by wellpast 7y ago
This is exactly my point. If your goal is to optimize for a future “big refactor”, then your problem is a present-day skills problem, not a PL issue.
270.
by wellpast 7y ago
Haskell is fun, lots of fun, but it is not a practical language by virtue of it being strongly typed. By practical I mean strongly typed PLs are not forgiving as your world and perceptual view of the world changes over time -- as it does fo

More ›