pka

I highly recommend watching this playlist about AI self-improvement and safety [0] by Rob Miles. Probably best short overview I've watched on the topic.

[0] https://www.youtube.com/watch?v=5qfIgCiYlfY&index=6&list=PLB...

So now if something like this gets integrated into the OS and gets deeplink support and some OS-wide back button on the desktop [0] I think we actually may be one step closer to interlinked, insta-updateabble, native apps!

Maybe we'll someday see the browser dethroned after all...

[0] https://github.com/ptmt/react-native-macos

Instantly reminded me of "I have no mouth and I must scream". It's a short, but pretty depressing read.

Why can't you use higher-order functions in macros?

Even Apple's current leadership can't be stupid enough to do that. If they kill the Mac/MacBook, who is gonna write the apps for their mobile platforms?

Or maybe they can, judging by the last MBP release. Hopefully they turn it around.

They won't need luck, plenty of people would love to program in Haskell professionally.

My impression was that QFT includes gravity and "only" breaks down when things get extreme, i.e. black holes/big bang/etc.

At my previous company we used Haskell for a very complex, edge-case ridden, algorithm heavy path finding and pricing backend.

For other uses, [0].

[0] https://wiki.haskell.org/Haskell_in_industry

Cont, the mother of all monads [0] :)

[0] http://blog.sigfpe.com/2008/12/mother-of-all-monads.html?m=1

(Shameless plug)

Couple of years ago I made Atea [0], a text-based note taking/TODO/time tracking app for MacOS. Since it stores everything in plain text files, synchronisation can be offloaded to Dropbox etc.

There's no sorting, attachments end everything else Collate offers, but I still use if for tracking time and managing projects.

[0] https://github.com/pkamenarsky/atea

This resonates well with me. Had I not learned Haskell, I probably would've left the industry 5 years ago.

The novelty has yet to wear off, there's really so much to learn.

However, I agree with the general sentiment of the responses here: if there's no passion, one can not really be good (at whatever, not only programming.)

Sure, then you have a valid use case for C/C++ (even better, Rust!) But often people don't and still use C++.

From a practical point of view, in many cases the performance critical sections are tiny compared to the rest of the codebase. Imposing such a cognitive overhead on the programmer when 90% of the code are executed once a second just to make those 10% really really fast, and then screaming "performance!!!" is not very convincing. Just use a high-level language and drop to C when needed.

Anyway, the author later says he just enjoys writing low-level C++ code, however unpractical this may be. In which case I don't really see the point of defending his choice.

And after that, PureScript :)

C programmers should be held personally accountable for the damage they cause.

Now of course everybody makes mistakes, but if you deliberately choose C when there are better options available then you should pay out of pocket for your buffer overflows and 0-day exploits.

The monad laws guarantee that there's no difference between do_x(); do_y(); and do_x_and_y(); where the latter is defined as { do_x(); do_y() }. In fact, monads would be pretty useless if that were not the case.

I don't think this is top-dow design really, just an overengineered OOP monstrosity.

Top-down doesn't mean that you have to model the universe first before getting to model your problem :)

I don't know why people keep spreading the misconception that mutation isn't possible in pure languages.

    ref <- newIORef 0
    writeIORef ref 1
    y <- readIORef ref
    print y

> 1

There you go, mutation in Haskell.

Have you tried what I'm talking about, i.e. prototyping something by specifying the types and iterating on the core design first before implementing large chunks of the required functionality?

It's probably hard to see the benefits without having tried it first.

This [0] is one of the bigger Clojure projects I've done (around 2.5kloc), also without spec/schema, and I really didn't dare refactor much, even when having a clear understanding of how things could be done better. It was just too much work.

With types I'd go through 10 design iterations before settling for something I'm satisfied it, and even halfway through the project changing things radically isn't a problem (I've worked on a 50+ kloc Haskell backend service, and changing core data structures used pervasively throughout the codebase was a 10min job, literally.)

[0] https://github.com/pkamenarsky/tellme

> If I am facing a problem that I have never faced before, I like to start off without any types in my code, and then, as I understand the problem more, I like to add in more contract-enforcement.

This seems to be a widespread sentiment.

In practice, I've found that prototyping anything remotely complex without types is so painful that I'd rather settle for an inferior design than trying to come up with the best possible abstraction.

In Haskell, I come up with a coherent skeleton without having to implement mundane details, hit a wall in the design space because of some case I didn't think of, come up with a better idea and then go back to the code and refactor with confidence. The type system always guarantees that my prototype is coherent as a whole. And I can do that dozens of times.

In Clojure, even with spec, I'd have to implement all my functions fully before being even able to test the design as a whole (sure, testing individual functions works fine in the REPL.) And after hitting a wall, having to reimplement everything every time is just too much work.

Yeah, that's what I meant.

You can't tell from the type signature alone if a pure function uses ST though, so I'd say that counts as pure :)

You can do that perfectly fine even in a pure language like Haskell.

Often, when I need to get familiar with a particularly tricky piece of code, I print it out and start annotating the printout, drawing arrows between dependent functions, visualizing data structures, algorithms and data flow, simplifying fragments in the margins, highlighting important stuff with different colors.

For fragments of code where search is not needed this is just such a superior experience. I dream of some day being able to do the same in a code editor with i.e. diagrams in comments or graphical annotations right there in the code.

The same applies to writing code. Being able to visualize hard-to-describe concepts on a piece of paper makes the overall algorithm as well as early design mistakes and edge cases much more obvious.

When I'm writing just text (todo lists, product ideas, whatever) and being able to easily edit, archive or search through the text a normal editor is a much better choice, but I'm not gonna ditch paper anytime soon.

> I haven't looked at the browser since I started.

> I switch to the browser and sure enough, the whole thing works perfectly.

This is the general workflow in a typed language as well (i.e. PureScript, Elm) - you write some code and then fix the type errors in the editor - only that instead of running a couple REPL queries and just assuming that your app works, you really do have some hard guarantees in all edge cases, like no crashes, no type mismatches, logical coherency.

Most of the time this then means that the "app works".

But it's not static. Pre/postcondition runtime checks can be implemented in a static language as well.

Clojurescript doesn't have a way of managing IO (i.e. types.)

So what is it that you need classes for that dearly?

I've heard that argument dozens of times, but I really can't understand it.

The App Store has millions of apps. Who created those apps, if not pro users? Without the App Store, who would buy iPhones, iPads and iPods?

If Apple shit on the pro users they shit on themselves.

Nice, thanks!

ST is exactly that. You probably mean the State monad.