-
Yes, so basically you can enjoy all the benefits (almost, and not really) with a single H-DPI monitor.. ok then, enjoy that.
-
Wow, that was a step up from the usual C# articles… Very cool.
-
hitchhiker
edited
3 years ago
|
link
| on:
Functional Programming should be your #1 priority for 2015
Stop making #1 priorities, should be your #1 priority for 2015. (tired of stupid headlines proclaiming one-size fits all solutions every 6 months for the last 10 years since the masses got involved in programming.)
-
Yes,
The “replace object oriented programming with functional programming” lead-in doesn’t do functional programming favors.
Object oriented programming was originally in “one size fits all, best thing since sliced bread, does great stuff for free” terms and that was a disaster. Indeed, that kind of sell harmed OO more than anything else.
OO has the virtue of being: 1. A way to package/encapsulate just about anything and so make something that begin a disaster into a slightly less disastrous thing in a practical time frame. Functional programming isn’t competing here and shouldn’t compete here. 2. A way to program powerfully by combining objects, programming with duck-types or generics or whatever. Functional programming does compete here but neither “wins” because after a point, power, meaning effects-per-line or flexibility-per-line only matters for small-ish programs. Once one gets to a certain program, the main limit to power is the programmer’s ability to encompass it and that’s inherently limited.
The virtues of Functional Programming (which I’m less versed in so feel free to correct). 1. If you fully subscribe to the approach, you get a variety of hard safety guarantees which also allow you to manipulate the program on various different levels. Especially, these open the door to safety guarantees in multi-threaded and concurrent programs whereas imperative programs tend to be subject to unpredictable errors, a drag given that such programs tend to be “high performance” where an unpredictable crash is a bad thing (see Twitter going from Ruby to Scala). 2. Power, see above. 3. You jump on the next-big-thing bandwagon, expand your mind, learn new and different tricks.
So there you are have it, apples versus oranges as you’d expect. Just as OO was ill-served when sold as the answer to everything in the 90s, my hunch is that functional programming will be ill-served if it becomes accepted as the answer to everything, though that seems less likely given that it seems inherently difficult to learn and use.
-
you get a variety of hard safety guarantees which also allow you to manipulate the program on various different levels
You get more than that. I’m going to scope this to Haskell because I will not defend other languages considered to be functional and because I’ve been teaching it and writing about it for awhile now.
OO has the virtue of being: 1. A way to package/encapsulate just about anything and so make something that begin a disaster into a slightly less disastrous thing in a practical time frame.
Abstract datatypes do the same thing. You see them a lot in OCaml and Haskell. I’d say the deeper point here is about final encodings but let me hand-wave that for now.
I benefit from FP (initial encodings - algebraic datatypes, pattern matching) and OO-style (final encodings - abstract datatypes/typeclasses) in Haskell in equal measures. The deeper point, IMO, is that I have a solid and principled foundation to build upon and a wealth of options to work with. Building on wet sand sucks.
Also, good defaults. I do think the “defaults” in a language like Haskell (pure, immutable, etc.) are the right way to go. I do think FP-style initial encodings are a good ‘first-pass’ default for when you’re still mapping out and understanding the domain. I don’t abstract out to something that hides information about the concrete instance until I understand the…abstraction (or pattern). Perhaps this works fine because Haskell is pure and the default is immutability, but pure code + immutability alone wasn’t enough to make Clojure scale well for me, so it’s not just that.
IMHO, thinking final encodings (OO) will save you from pervasive effects (impurity, mutability, etc.) is like thinking breathing through a straw on Venus will keep you alive.
You need a spacesuit, not a straw.
The frontier on this is continually being pushed out - you see Haskellers asking the same questions about totality and turing completeness that people ask of Haskellers about purity and “but how do you talk to the outside world?” As the author of a library that does nothing but talk to an external service (search engine) and still has ~94% of the code emit no IO, let me tell you, it works fine.
But sometimes, I use a mutable datatype. And it’s totally fine. shrug I would note, however, that I am not allowed to confuse immutable and mutable variations of the same type in Haskell, but I still allowed to (safely) write generic operations over both.
You can’t think this is a one-size fits all approach unless you’re talking about languages with a narrower set of options than something like Haskell. Unless you don’t think final encodings capture the value of OO, but then the onus would be on you to explain what OO does that abstract datatypes, typeclasses, and modules cannot. I don’t think that’ll be fruitful unless you’re formulating new foundations for programming languages which means you now must justify a totally new PL theory. That seems a rather more daunting task than, “this tool relying on 79 year old well-established theory of computation happens to be well made, have nice libraries, and lets me be more productive than the alternatives”.
I use Haskell in my 9-5 for a variety of reasons. Only one of them has the word “lambda” in them.
TL;DR - No hairshirt. Future’s so bright, I gotta wear shades.
-
-
-
This got [flagkilled] on HN :D
-
-
Unless you’re writing Go for a living, it will make you smile. That’s original enough to warrant sharing the blog post.
-
-
-
Sadly this has been a recurring theme with Google for the last few years. I don’t expect it to get any better from here on.
-
You either die a hero or live long enough to see yourself become the bad guy. And if you live long enough after you’ve become the bad guy, you might see yourself become the good guy again. But no one can remain pure forever.
-
-
Sounds lovely, how many years will we need to wait before something like this happens :(
-
hitchhiker
4 years ago
|
link
| on:
This Rural Community Is Building Its Own Gigabit Internet Network
That was just awesome to read.. makes me want to go dig a ditch to the backbone :) nice.
-
I think that’s ‘part’ of it. It also depends on the type / style of moderation. We run a huge community (4 million visitors a month) - we’ve had to ban some of our top posters over the years - just for being smarmy bastards.
You can be big, and have a friendly place - but you’re going to have to do some ‘shitty’ things to keep it that way.
-
-
Very sorry to see linkbait hitting lobsters :( Poorly written article, cult of ‘this that or the other’, general crap.
-
The ‘mania’ is a problem, many guess a 4th(?) crash is coming. It is a risky project, perhaps the riskiest. But it’s alive because many of us ‘nerdy’ types believe crypto-currencies will be the currencies of the future; whether that’s BTC or not remains to be seen.
To some degree, others believe the current fiat currencies will eventually collapse. Hence a crypto may well be the last-man-standing. It would be hard to argue its legitimacy then.
TL; Valid points, though explaining everything away as ‘mania’ might be shortsighted.
-
i’m watching it since it was at 30 cents and made a solid amount of money with my bitcoins. none the less i think its doomed. the argument of scarcity that the whole scheme is build upon is just not valid: the cost of creating a currency with the exact same properties is close to zero. on the long run there will be no trust in such a system. the real cryptocurrencies that everybody is waiting for will be smaller marketplaces and “money” will be backed by goods.
-
Filecoin is probably not a 257M Ponzi Scheme - it actually might be one of the few projects with significant real-world use (and therefore real value down the line)