codygman

> rather than going from a poor-but-performant systems programming language like C to a pedagogic language like Scheme, it’d be a better idea to move to an rich-and-performant language meant for industrial systems programming like Common Lisp.> Scheme’s a pretty little language, but it’s not meant for building large applications.

Weren't people saying the same about python and Java long ago?

How do you arrive at that conclusion?

> Indeed, elisp’s weaknesses are IMHO mainly where it’s most akin to Scheme (e.g. its flat namespace)

Racket at least wasnt flat iirc, is guile scheme?

> The great thing about a JIT is that we get a speedup without changing the actual implementation language or fragmenting the ecosystem.

Agreed.

> I can not for the life of me understand the appeal of org-mode

For me it's the seamless transition (no transition?) between deciding to do something, creating an outline, creating todo's, scheduling them/creating deadlines, writing code directly under the todo's using org-babel.

I use org-mode for work actually. Kind of similar to this but less devops:

http://www.howardism.org/Technical/Emacs/literate-devops.htm...

Can you link to your project?

> Static types are not powerful enough to cross remote boundaries.

?

Is this related:

https://ocharles.org.uk/blog/guest-posts/2014-12-23-static-p...

>>Haskell is used by, to a first approximation, no one. Which was my point.

> If that's your point, then I agree.

You are agreeing to something that is false. See my reply to the grandparent.

> Haskell is used by, to a first approximation, no one. Which was my point.

Unless you have a very loose definition of"no one" that simply is not true.

Just off the top of my head:

Haxl at Facebook Bond at Microsoft Supply chain management at Target

Also see:

https://wiki.haskell.org/Haskell_in_industry

Thanks for writing this out. It effectively communicates many of the underlying reasons for the state of technology in regards to race and how it affects accessibility.

> Stop ramming your stuff down other people's throats.

Pointing out your preferred language addresses one of the hardest problems in another language qualifies as "ramming your stuff down other people's throats"?

I find that hard to believe.

>> Speaking from experience, zero. You can just treat them as syntax, like the largest proportion of every other language, but with the opportunity of actually being able to write things like that yourself later.

> So, basically, "learn this thing without understanding what it does" :-\

> Reminds me of teaching Java to newbies: "oh, just type this syntax, you have to memorize it, don't worry about it".

I don't think what's recommended is the same.

> argue against automatically generated encoders/decoders since it's easy to accidentally introduce breaking changes to your API by renaming a record field / class method

Can anyone further substantiate this argument, I feel like it's not very strong as is.

> Go has sub-millisecond GC pauses

At the cost of throughput:

> Go optimises for pause times as the expense of throughput to such an extent that it seems willing to slow down your program by almost any amount in order to get even just slightly faster pauses. - https://blog.plan99.net/modern-garbage-collection-911ef4f8bd...

Types for instance.

> with Racket's move to the Chez Scheme interpreter,

Is there a wiki or an issue to track progress of this?

Can you briefly talk about the issues you experienced working with Haskell and the even worse issues you experienced trying to find Haskell developers?

Did you post on Functional Jobs, haskell-cafe, and r/haskell?

spurious lap infant?

For many simplicity is defined by ease of use though.

> var foo map[<type>]interface{}

> solves 99% of issues where I would normally need generics.

But it also opens you to to runtime conversion errors, spurious if checks for type information compilers with generics have, or slow reflection to find the type.

> The author also doesn't really specify what kind of generics, there's a huge difference between parametric polymorphism (i.e. Haskell type classes) and Java/C++/C# generics.

Java/C++/C#/Haskell generics all provide parametric polymorphism though.

Haskell type classes provide ad hoc polymorphism, though I guess maybe they provide parametric polymorphism as well.

Per Wikipedia:

> In programming languages and type theory, parametric polymorphism is a way to make a language more expressive, while still maintaining full static type-safety. Using parametric polymorphism, a function or a data type can be written generically so that it can handle values identically without depending on their type.

> You want the first N digits of pi? Just wait while I calculate all of them for you...

I don't think that example cold actually happen, or at least I can't see how it would happen in Haskell.

> On the other hand it is not specifically designed for concurrency, or any industry use, so it is less pragmatic than Erlang or Go.

Can you give clarification? Haskell allows concurrency nearly as easy as Go imo.

> surprisingly little from the likes of haskell beyond self serving academic noodling

Your final statement is demonstrably incorrect.

Facebook (haxl), Microsoft (Bond), Google (ganeti), Target for supply chain automation, Bank of America (Haskell is being used for backend data transformation and loading), standard chartered, Prezi, Android bump (http://devblog.bu.mp/post/40786229350/haskell-at-bump), At&t (automate processing of internet abuse complaints).

Really great talk, as all I've watched by Simon have been.

> (e.g., `ByteString.map (+ value)` is incredibly slow compared to a pseudo-C loop).

That situation sounds like you needed a ByteString Builder to get comparable performance.

> Until you have to solve a (maddeningly common) space leak issue.

Hm, I've been making useful things with Haskell for a couple years including quite a few freelance projects and haven't encountered many space leaks.

Definitely not enough to say they are maddeningly common, or even enough to say they are common.

I think hawk should steal the idea of aliasing "|]" personally ;)

> If one is able to write code in Haskell it tells a lot about them, and he might be a better programmer than one who writes in Ada or C++. - solomatov

> And here's the arrogant, self-important attitude that turned me off of Haskell. - jlarocco

> It is people frustrated by the (difficult) learning curve of Haskell that say such things. - peaker

> And there it is again. I haven't drank the Haskell kool-aid, so I must not be smart enough to use it properly.

Firstly, reading "people frustrated by the difficult learning curve of haskell say such things" as "I haven't drank the Haskell kool-aid, so I must not be smart enough to use it properly." is a very uncharitable interpretation.

Secondly, I believe solomatov and Peaker's comments could be written more unambiguously as follows (though I thought they were precise enough):

solamatov commment rewrite: Someone who can write Haskell might be a better programmer than programmers who use other languages because Haskell is difficult to learn.

peaker comment rewrite: People frustrated by the difficulty of the Haskell learning curve say things such as "Someone who managed to learn Haskell to the point they can write code in it have proven their worth more than those who use easier to learn languages"

So jlarocco, could you still call classify these comments and the thought processes behind them arrogant and self important? Is there anything that would turn you off of them?

cons = prepend snoc = append fst = first item of tuple snd = second item of tuple

>>= is monadic bind... I won't try to explain it here. It's somewhat similiar to flatmap in Scala which has some easy explanations.

zip, I just remembered I explained already.

With the warning that it's using Idris and strict semantics rather than lazy, I'd almost agree.

I think for Haskell specifically that http://haskellbook.com is the best.

Yep, I've missed apostrophe's quite a few times. It's was a common cause of infinite loops for me in the past, but I suppose I've trained myself to spot them more quickly.

Perhaps zip can be more simply explained by a simple example:

    out: zip ["a","b","c"] [0,1,2]
    out: [("a",0),("b",1),("c",2)]

    out: fmap fst [(0,1),(2,3),(4,5)]
    out: [0,2,4]

    out: fmap snd [(0,1),(2,3),(4,5)]
    out: [1,3,5]