seagreen

Can you share a file that's anywhere on your computer, or does it have to be in a shared folder?

Also, how does Amium handle file renames? This is a tricky one so I wouldn't judge the product if it has trouble here.

I agree, especially with the easy to understand part.

Look how short the standard is: http://www.ecma-international.org/publications/files/ECMA-ST... It's small and perfect, like a 2x1 LEGO block.

Here's the XML spec: https://www.w3.org/TR/REC-xml/ <backs away slowly>

I support this attitude!

Haskell is coming around though. We got Stack which is a fantastic package manager, and we now have a web API library which is pretty much unmatched: http://haskell-servant.readthedocs.io/en/stable/ (each Servant endpoint has a type, and you can generate docs and client libraries from your backend code). Editor tooling has historically been the other problem, but that's starting to come around too.

Hey! So I'm deeply appreciative towards cabal-install for historical reasons. The situation before cabal-install was . . . not the best (https://www.gwern.net/Resilient%20Haskell%20Software) so I think we can credit cabal-install with a lot of the success the ecosystem has had over the last decade.

That said, nix-style builds don't actually address my issues with cabal-install. My (very personal) preference is to always have the current dependencies being used reflected exactly in a local file. I picked up this attitude from NixOS, but it's an extremely useful way of doing things -- the knowledge that as long as I don't lose that file I can always rebuild my current environment exactly is just too awesome.

I think that if you need to track version bounds as well (say you're developing a library) they should be kept in a separate file, and you should always have a master file that describes what you're currently using locally. Happily this is exactly what Stack does with my-project.cabal and stack.yml.

That said, I appreciate that others like cabal-install, so I do what I can to make my code easy to use with both package managers (the main thing is keeping aggressive upper bounds on the few libraries I maintain, which especially helps cabal-install users since they do dependency solving more).

Not sure why you're being downvoted. Haskell tooling definitely started turning around with Stack. I've used a fair amount of package managers (including cutting edge stuff like Nixpkgs) and Stack is by far my favorite.

EDIT: To elaborate on why I like Stack:

+ Fully declarative. I don't run commands to edit my Stack environment, instead I modify the relevant stack.yml file. This means that the current environment can always be easily examined, committed to Git, etc.

+ Easy NixOS integration which means I can also describe the non-haskell dependencies for a project, and enforce that _absolutely_ nothing else on my system gets used. This is amazing.

+ I like that it uses Stackage by default, and that I can pin projects to LTS Stackage releases. This means that many users of my projects will probably already have most dependencies installed -- especially cool for small things like tutorials where users won't have the patience for long build times.

+ It reuses the already existing `.cabal` file format so it's easy to make libraries compatible with cabal-install, the other package manager in the Haskell ecosystem.

  "if you use these platforms you are a fool"

Hey, that's not fair, you're arguing against half my point!

I said if you use these platforms _and don't have a reason to think you've got an advantage_ you shouldn't be doing so.

Lun and his peers are an exception to this. If you want to make a second argument and say he shouldn't be trading go ahead (and I'll try to back you up), but my original point was about the 99.9% who aren't Lun and are clearly just fish.

Dr. Lun has a PhD from MIT and is doing original AI research. If that's your profile then do what you want=)

My thoughts are that if you use either platform for anything other than entertainment you're a fool.

Seriously, here's your competition: https://en.wikipedia.org/wiki/Renaissance_Technologies How deluded do you have to be to think you have an edge over that?

Great point! I found this for python: https://www.stephanboyer.com/post/9/monads-part-1-a-design-p..., but it definitely focuses more on explanation than practical use. A list of "how to practice with monads in various languages" would be a neat thing to have.

  Can you recommend a good one? ... I hardly have time to 
  write code to learn it like people say is necessary.

The _easiest_ way to learn monads is through code (in haskell they're just a tricky typeclass: http://dev.stephendiehl.com/hask/#eightfold-path-to-monad-sa...) If you don't want to write code you could learn them like a mathematician from first principles (https://en.wikipedia.org/wiki/Monad_(category_theory)), but that seems so much harder to me I'm not sure why you would.

Not at all! I like Haskell because it nails the two things that are most important to me: a good type system and the ability to restrict side effects. Constructive criticism of other parts of the language can only be a good thing.

Hilarious, but not nearly boring enough to use in actual business writing:)

It's actually restricting our thought to an annoying extent that we've overloaded the term "operating system" so much. This isn't Sandstorm's fault -- Windows already has billions of people thinking "operating system" == "desktop environment" so the ship has already sailed.

I would really like a word that describes this set:

  + Unix CLI
  + WIMP desktops
  + Browsers
  + iOS touch interface
  + Android touch interface
  + Emacs (when used for general computing)

Perhaps "user environment" would work?

EDIT: For me at least "platform" doesn't quite fit. I think whatever word is best should imply "single user interface" which platform doesn't necessarily.

The new subreddit is not for general haskell discussion, it's only for the discussion of things related to the haskell-lang.org site.

Source: https://www.reddit.com/r/haskell/comments/4ghznv/improved_hp...

Note that the community page on haskell-lang.org still links to /r/haskell: https://haskell-lang.org/community

I understand why this is confusing though, since the HN link goes to an annoucements page which mentions the new subreddit prominently), but the homepage for haskell-lang.org does not.

There's a very good summary of the Haskell ecosystem here: https://github.com/Gabriel439/post-rfc/blob/master/sotu.md

Update: sorry you're getting downvoted, that's not me. I think worrying about the predictability of performance is perfectly reasonable, especially in the presence of lazy evaluation.

  Citing Credit Suisse and Standard Chartered is just 
  name-dropping big banks in the hope that it will deceive 
  people into thinking that these institutes are seriously 
  invested in Haskell. They are not.

Lol, Standard Chartered is hiring like 30 haskellers _this year_, and I'm pretty sure they were heavily invested in Haskell in 2010. That writer of that article has an axe to grind, and is twisting facts to suit it.

Great tactical advice, but what a sad situation to be in. "Run this command, then run this command, then run this command ..."

There should be a single configuration file (or set of files) that declaratively describes the whole state of the machine. That way the exact situation of the server can be reviewed by just looking at files, instead of trying to poke and prod at the machine to see what commands have been run over the last X weeks.

  The current situation (importing ByteString or Text for
  performance) is pretty good IMO. Haskell doesn't have Map 
  or Set or anything in the prelude, so I think it's 
  reasonable to leave powerful packed text types out as well.

Interesting. Maybe all we have is a community problem then? Since `String` is right there, and `Text` is both an additional dependency and an import away `String` gets used in situations it shouldn't.

  Try going to a python or java developer and telling them
  "array access should return an optional type instead of
  throwing an exception on out-of-bounds".

Alright, I think we have synthesis. From a Python programmers perspective the Prelude issues are somewhat trivial. From a Haskell programmers perspective it's offensive to good engineering. So it depends on your perspective:)

  I remember showing a new engineer who'd never seen
  any Haskell before monads on a whiteboard and he
  after I explained monoids and functors and then monads,
  he just nodded and said "oh, okay, makes sense".
  He wasn't bluffing - he actually internalized the concept
  that quickly.

This is amazing.

  The trick with teaching Haskell is to start with specifics
  and THEN generalize the ideas.

Definitely!

  Sorry, I rambled a bit, but tl;dr: Haskell was a mixed
  success, brought along some drama, but overall enabled
  us to reduce the latency of some critical services by
  about 10x. At least while I was at IMVU, teaching people
  Haskell was actually not hard. Getting them to care
  about Haskell or even want to try it was sometimes VERY
  hard, depending on the person.

Please, please, PLEASE turn this into a blog post. Haskell has a lot of great testimonials, but they can't be convincing unless they also show the downsides. For technical topics I think Haskellers do a great job being honest, eg: https://github.com/Gabriel439/post-rfc/blob/master/sotu.md ("Numerical -- immature ... Front End ... immature ... Distributed programming ... immature"). But there aren't a lot of writeups of Haskell being tried in business with mixed results. A writeup saying "a big concern is getting developers onboard" would be hugely reassuring to companies considering Haskell that _do_ have their developers onboard.

  Oh yeah, and I 100% agree with slezakattack that Haskell
  programmers are not necessarily magical systems designers
  or system programmers. They're just like you and me.

Totally. There are some geniuses, but then there are also people like me who use it because my brain isn't big enough to hold a whole program in my head, so I need the types:)

I wish this was the case, but it's not. A bad string type and lots of partial functions are legitimate red flags, not "first world problems".

As a huge haskell fan, I'd love to hear more of this story. There aren't enough good writeups of companies trying haskell and it not working.

  What kind of Web do you want?

  + Promotes freedom
  + Inspires learning
  + Safeguards privacy
  + Is available to all
  + Creates opportunity
  + Puts me in control

This is a good question. My answers would be "inspires learning" and "puts me in control".

Sidenote: let's address the "enable JS" issue once and for all since it keeps popping up in these threads.

Imagine an alternate history where a book reading program went critical (we'll call it "Reader") and took over the world. (In the actual world of course it was a static document consumer -- the "Browser" -- that took over everything and eventually became its own operating system).

In this alternate history there are regular internet fights (occurring in Reader of course) over whether turning off ReaderScript in Reader is a reasonable thing to do.

One side says: it's dumb to turn off the programming language in your Reader and still expect it to function -- programming graceful degradation into every reader app in the world would cost billions of dollars and be a huge waste.

The other side says: that's true, but I just want to read the Quran without popups!

Happily synthesis is easy since both sides are right. You should never expect a readerapp to work without ReaderScript. You should always be able to expect a book to work without RS -- they should never have had access to it in the first place.

The path forward is clear. Readers should have clearly different modes for books (documents/sites in our world) and apps. We should maintain a community list of which URLs are which, and load that by default into Reader. This way apps can continue to run programs by default, but we don't get popups in our books.

  “The web is already decentralized,” Mr. Berners-Lee said. 
  “The problem is the dominance of one search engine, one 
  big social network, one Twitter for microblogging. We 
  don’t have a technology problem, we have a social 
  problem.”

  One that can, perhaps, be solved by more technology.

This is a very confused article. It's a social problem! But we're going to solve it with technology!

I'm sure Tim Berners-Lee has a great understanding of the situation, but since it didn't come across in the article let's try to build our own description of the problem here in the comments. To do this we'll go through the most interesting projects in the "fix the web" space and steal their key insights.

# Camlistore - All Your Data Should Be in One Place

I probably have important data in two dozen different places. Google, FB, Dropbox, Reddit, GitHub, Mint, Stack Exchange, Amazon, etc. This is crazy!

All my personal data should go into a personal data store. I'm not sure how we'll ever approach a sane system without this step. Camlistore is all about making that data store.

More info here:

https://camlistore.org/doc/overview " Camlistore is your personal storage system for life. "

# Urbit - Everyone Should Have a Name

Right now only techies own their names. We do it in two ways -- the total ownership way where we make a private key and identify ourselves with it, and the "technically renting but basically ownership" way where we buy a domain. You can reach me at <myname>@<mydomain> today, tomorrow, and probably for the rest of my life.

Most non-techies get by with Gmail and a FB page. This isn't the worst, but it's not ideal.

And for every different service we use we get a different name. I don't want 20 names! I want to use my name! (Or sometimes one of my pseudonyms, which Urbit has first-class support for).

In Urbit everyone has a name[1]. Even better, this name maps to their computer, so if I know my friends name I can connect to their computer -- the foundation of getting an actual peer-to-peer network back from the current mess.

[1] Connected to a private key and human readable! But often silly, eg: ~gumdob-tumlub

# Sandstorm - Everyone Needs a Server

Servers are necessary to be real internet citizens. I think this is basically self-explanatory. If your entire internet presence disappears when you close your laptop lid you're basically beyond helping, and will always need some kind of walled-garden to watch out for you.

The problem is that Linux servers are a pain to host. With Sandstorm you can set up a server with one click. You can install apps with one click. This is . . . basically such an obviously good idea it's hard to find more to say about it.

If there are more interesting projects in this space please mention them, I'm going back to coding:)

EDIT: I wasn't really sure what to write for a conclusion, but now I've thought of one: The web evolved, what we get next will be _built_. This is very exciting.

Real World Haskell is somewhat out of date. I'm not sure what to go with instead, but I've heard good things about Haskell Programming from First Principles (which has already been mentioned in this thread).

Oh man, I can't say enough good things about PureScript!

One really neat thing is since PureScript basically copies Haskell's type system, if you learn PureScript you're learning to use one of the best type systems in industry.

Oh, well said!

Any strong language I used was directed at me as of a year ago who was wasting time on redirects no one would ever use, not the original authors.

Heh, you got me:) I agree the situation is more complicated than I described.

My main response to this is: just because we can't always use content-addressable links doesn't mean we shouldn't use them where we can. I'm sure you see where I'm going with this. When pirate movie websites have a 1000x more rock-solid way of identifying content than the NY Times we have a problem.

But even in the most inhospitable situations like the one you describe we can still do better. Content-addressability won't help, agreed. How about promoting UUID style non-human readable paths instead? One of the reasons links change is that the content changes slightly and the name goes out of date. Perhaps in your case legal says "these prices may be up to ten minutes out of date, we can no longer call that path /prices/current/feed". If the path was /3824-3822-4864 this wouldn't be a problem. Information about what that endpoint returns can be placed in a description field or in the docs where it can be kept up-to-date without breaking links.

Working on IPFS/Tahoe-LAFS/Camlistore/BitTorrent is cool. Doing make-work isn't.

This is a make-work trap for conscientious people.

If it's more efficient for your business/project to change your URIs when going through a website design, go ahead (with the knowledge that you'll lose some traffic, etc.)

Seriously, there's no reason to feel guilty over this. It's not your fault, it's the fault of a system that built two UIs into every website (the website's HTML and the URL bar -- the second of which is supposed to be useful for browsing and navigation just like the first).

If W3C actually cared about links continuing to work, they would fix it at the technical level by promoting content-addressable links instead of trying to fix it at the social level (which will never work anyway, the diligent people that care about these things will always be just a drop in the bucket).