dukerutledge

> all in all i think it requires a lot of discipline that can easily break down, whereas some of the popular imperative languages you can still sort of plug along (=> punt the technical debt) despite that.

Interestingly I have the exact opposite perspective. Writing imperative or OOP code requires me to be excessively disciplined. It is extremely easy to build un-maintainable spaghetti. There is a whole cottage industry of methods for your discipline of choice: Clean, SOLID, TDD, etc. All these disciplines seem to boil down to the same systemic result, push effects to the edges of you program so you can more easily test, evolve and maintain. Functional programming (of the typed variety) tends to allow me to write garbage code, that is testable and can be easily evolved and maintained because the paradigm encourages me to be a good actor.

I've refactored production code in imperative languages and typed functional languages and only one of them allowed me to make HUGE sweeping changes with ease and high confidence.

This is pretty sound advice for any language. You always want most of your code to be dumb. You save high abstraction for things that have a sensible interface and are common enough to need DRYing. Haskell has a higher abstraction ceiling than most languages and there is less trodden ground, so there may be more opportunity to get lost down the rabbit hole. However Haskell2010 is a beautifully simple language that can solve all your problems (maybe with a bit more code than enabling 20 extensions will afford you).

I'm speaking about a philosophical dual.

For example: http://www.taoism.net/ttc/chapters/chap02.htm

I'd gladly storm into the breach with you :)

Hopefully we all agree that static types and dynamic types are useful. Those who use hyperbole are attempting some form of splitting. I think the point where we disagree is what the default should be. The truth is this discussion will rage on into oblivion because dynamic types and static types form a duality. One cannot exist without the other and they will forever be entangled in conflict.

There are a number of row type libraries and a proposed extension: https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker/Ro...

Probably a similar question, but headed in the other direction "Why should I learn assembly?" You probably shouldn't. But in the process of learning it you might gain a greater understanding and intuition for how and why things work.

I'd disagree. Most business logic is just transformation of data structures in disguise. Once you have a sufficiently rich set of data structures this becomes abundantly clear.

Reginald is definitely hinting at hylomorphisms here. I'd be curious to see if stream fusion could be achieved in JS for a hylomorphism.

Who works for an organization that changes their infrastructure every week? That business doesn't exist. That business already failed.

If you are asking the question, should I use this?

"I am not a security expert."

No.

Some of these remind me of Ed Kmett's YOW talk: "Stop Treading Water: Learning to Learn"

https://yow.eventer.com/yow-2014-1222/stop-treading-water-le...

Now lets see some charts about build times.

Well, this will confuse the meaning of FRP even more. Poor Conal...

Yeah, since rust is eager existential types seem like a necessary evil.

So, existentially quantified types?

Totally agree. There was a great example on /r/haskell the other day.

https://www.reddit.com/r/haskell/comments/4sdkch/haskel_newb...

Operators are certainly overused in Haskell, but sometimes they make something so much more readable.

skedge.me - Senior Software Engineer – Backend

Role

We are looking for an experienced systems engineer to design and implement deployment automation, automatic failover, reliable backup/restoration, and scalable data storage strategies that can be distributed globally.

Our technology stack is based on Haskell, Postgres, NixOS, and we deploy to AWS with NixOps. Our ideal candidate is well versed in all these technologies, but most importantly has experience managing, scaling and monitoring high performance web services with any stack.

Additionally, we desire candidates with continuous deployment/delivery experience. Candidates should be familiar with being part of an on-call rotation, and developing a runbook. We rely on our continuous integration server to build, run tests, and provide binary caches of compiled assets to accelerate compilation. We automate anything we can. We know the value of a two line shell script and a one step build.

A typical week might include

Designing a strategy for horizontally sharing our database. Implementing graceful server shutdown on runaway memory consumption. Adding real-time metrics hooks to key areas in the code base, and adding alerts to our monitoring system. Developing an offline database jobs system, for zero downtime migration. Redesigning existing APIs to common industry practices (HATEOAS, cacheable urls, etc.). Profiling slow requests and implementing improvements. Addressing production issues from our existing clients. Fixing bugs and adding tests to our automated suite.

Qualifications

    Professional Haskell experience is desired but not required. Haskell expertise is required.
    BA/BS in Computer Science, related technical field or equivalent practical experience.
    Minimum 4 years experience writing scalable, reliable software.

Email [email protected] to apply.

In frontend? Not 100%, but pretty much.

A modern static type system allows this style of programming.

How about a business plan other than mine my users' info and sell them ads?