List of what Haskell doesn't have?

#44

Yes! In fact, I think we should develop our macro facilities enough in a Racket inspired way that do notation need not be part of the language anymore!

Any special-case solution should be viewed as an issue tracker for the more general mechanism.

This a practical argument to me too in that:

  • do is great, but I think we overuse Monad because of it
  • Arrows are not nearly as great, but we can’t yet make them separate from GHC. A macro story good enough for Monad do should also be good good enough to handle arrow proc too, and then we can start by making the latter library code as that ought to be less controversial.
1 Like
#45

…using Lazy and Typed Racket as a guide - who knows, maybe Template Haskell can be then be subsumed by such a macro facility! Clean’s macro system may also be worth looking at for ideas.

Any special-case solution should be viewed as an issue tracker for the more general mechanism.

…which would deal with all the “simple” expansions - what’s left (as few as possible) can then be candidates for direct support in Haskell.

#46

There’s actually a fairly easy way to indicate multiline strings, if someone wants to add the language extension or use TemplateHaskell for it.

"~…

\ indicates an escape character, adding a special escape character actually saves space relative to “”" “”" by two characters.

#47

Check out Stuck macros: deterministically interleaving macro-expansion and typechecking - YouTube and links in comment

slides: http://gelisam.com/files/stuck-macros.pdf
Hackett: GitHub - lexi-lambda/hackett: WIP implementation of a Haskell-like Lisp in Racket
Typer: Stefan / Typer · GitLab

and https://davidchristiansen.dk/pubs/tyde2020-predictable-macros-abstract.pdf .

Better macros are (to me) less replacing Template Haskell than merely fixing (hygine) and extending (this sort of thing) it.

Also note that that last paper there involved incoming HF director @david-christiansen. Auspicious, if I may say so!

1 Like
#48

o_0 …you’re contemplating both Template Haskell and a macro facility?

I think we’re going to need a whole new collection of tutorials…

#49

No Template Haskell quotes and splices are lisp quasiquotation, which is at the foundation of modern Racket macros too.

(The whole “scheme says use pattern based macros [syntax-rules] only, quasiquotation is not hygienic” is super out of date. Quasiquotation has been fixed, and syntax-rules can be written in terms of syntax-case.)

(Haskell’s quasiquotation is not quasiquotation, and a silly feature that should be deprecated.)

Pre-HFTP: Coordination for finishing Trees That Grow
#50

Speaking for myself, the main shortcomings of Template Haskell that I see are:

  1. Template Haskell does not work on all platforms. (For example, there was a period of time when Template Haskell was not yet supported on ARM. Although it is supported now, that will always be a problem for new platforms.)
  2. Template Haskell does not work in cross-compilation.
  3. Template Haskell slows down compilation. (Thus making it an “expensive” feature to use, compared to built-in syntax.)

Yes, if these shortcomings could be fixed, it would be great. I don’t know enough about the implementation of Template Haskell to know whether these could be fixed, but my impression/guess is that these limitations are fairly fundamental to the way Template Haskell is implemented.

2 Likes
#51

IIRC Haskell doesn’t have the compromise that is required to gain critical mass(i.e. it lacks the success).
Type unsafety is another thing it lacks. Ppl often just want to implement broken stuffs, but haskell does not allow that.

2 Likes
#52

Why is it silly? Isn’t it the only feature we have that allows the embedding of DSLs with arbitrary syntax (such as the string interpolation feature discussed above)?

2 Likes
#53

Hmm:

@simonpj:

Avoid “success at all costs”.

…aren’t there already enough “compromised” programming languages?

…I thought the opposite was true: people like Haskell because helps them to implement stuff that works properly. Again, for those who really do want to build “broken stuff” by choice, there are plenty of other programming languages to choose from.

Perhaps these might better explain why the majority of us are here:

#54

I think this is what @Abab9579 meant, actually.

1 Like
#55

Yep, tbh why it is this way is mystery to me as well. Ppl seem to love to spew off broken stuff fast. I guess 1. They love the feeling of being trusted on their program & programming 2. They kind of want to hide in shady stuffs in their code secretly, to deceive users more easily.

Btw I dislike the wording “fundamentalist” there, it comes with negative connotation.

#56

IMO, from my point of view, this is just pedagogy and marketing, man. My dream with Haskell is to get Haskell pedagogy to 2x Python level, then figure out how to market Haskell until it does hit critical mass.

Also, type unsafety, there’s a language extension that allows you to disable the typechecker.

===

As for something else Haskell misses:

linesToListofList :: String -> [String]
linesToListofList = exe
    where exe [] = []
          exe x = takeWhile untilLine x:exe (dropWhile untilLine x)
            where untilLine = (/= '\n')

appendTuple :: [String] -> [(Int, String)]
appendTuple = exe
    where exe [] = []
          exe (x:xs) = (length x,x):exe xs

The reason I’m using where blocks is because I don’t want to retype appendTuple, and the where block isn’t working sufficiently to compact the line.

There is no feature to say, type ‘’ or `` and then have it be interpreted as the previous name. Or is there? I know you can implement it via TemplateHaskell.

2 Likes
#57

Are you looking for \case? Or did I misunderstand what you mean by don't want to retype appendTuple?

linesToListofList :: String → [String]
linesToListofList = \case
  [] = []
  x = takeWhile untilLine x:linesToListofList (dropWhile untilLine x)   
  where untilLine = (/= ‘\n’)

appendTuple :: [String] → [(Int, String)]
appendTuple = \case
  [] = []
  (x:xs) = (length x,x):appendTuple xs

My dream with Haskell is to get Haskell pedagogy to 2x Python level, then figure out how to market Haskell until it does hit critical mass

Do you have any ideas of how to go about that? Sounds interesting!

1 Like
#58

Well to be fair, statistically, majority of people have hard time comprehending middle school-level functions.

2 Likes
#59

And the majority of people don’t know how to code.

By 2x Python level, I mean, if we have a refined Haskell pedagogy, Haskell will be 2x as difficult to pick up as Python. Reading “Think Julia”, it looks like the Julians / Julliards got themselves to 1.5x Python level.

The approach I’m looking for is currently, well, read the intro programming books in all the languages, including Python, and take apart their pedagogy for reverse engineering.

I want to be able to both dumb-down and professionalize Haskell, because, in the following section, you’ll see the real audience I’m targeting with Haskell.

===

One of my main concerns is the psychological aspect of it, because I’m looking at Haskell as a marketing project. Taking a bit of my thread derail of HF Executive Director Christiansen’s selection thread, my idea is that, say, if 40% of the managers at a given firm were talked into taking a simplified practical Haskell course as a hobby, and were productive at the end of it, they’d end up pressuring IT to support Haskell so that when they put up their own code, IT would be able to clean it up and use it for production.

With Haskell, but not for many other languages, having middle management or senior management in non-IT positions or non-IT backgrounds be able to produce reusable code that IT can actually reprocess for their codebase is practical.

Hell, I think Barclays or was it Standard Chartered trained all their traders in their proprietary Haskell dialect Mu. This is a major potential selling point of Haskell; that Haskell makes it hard to code badly means that non-IT professionals should be able to produce near-professional or at least usable code, so in a corporate environment Haskell is now useful NOT because the IT department wants it, but because the rest of the staff has this massive Haskell hobby codebase and is begging IT to integrate it into their proper codebase.

If the CEO spent his weekend hobby-coding a prototype to extend the IT capability of his firm, is the CIO and IT department going to be able to say no to actually developing the prototype into something useful for the IT department? This is making a pointy-haired boss work for Haskell.

And if you don’t think executives code, I think Wang (formerly their CEO) at Computer Associates spent a few flights coding random crap. Yes, he’s an IT-er, but we should hopefully be able to get C-suiters and middle-management into programming with the right marketing and pedagogy. And yes, cleaning up your pointy-haired boss’s Haskell shitcode is not exactly a good Haskell job, but it’s still a Haskell job.

===

Basically, my view is that Haskell’s purportedly “good” features aren’t actually useful for IT, because IT has its own sociological problems. The high productivity of Haskell is actually a demerit, because if Haskell is so productive, having the IT staff switch to Haskell means that the IT department can now be made smaller. IT execs aren’t going to agree to nuke their own department by switching to Haskell, because while they’ll be able to reduce payrolls and save money, it also means they have a smaller department and that impacts the power and compensation of the IT executives, even if the IT execs are sociopathic enough not to care about firing their subordinates.

On the other hand, Haskell is highly productive and highly correct, which makes Haskell ideal for hobbyist use. The hobbyist role is what enables Haskell adoption by businesses; the ability for Haskellers who do not have IT in their job description to produce useful code is precisely what can drive Haskell adoption; you have a ton of Haskellers who do not do IT for a living produce easily-refactorable prototypes, now you have a job opening in IT for “shitcode cleaner”.

And it’s the way it should be, no? The entry-level Comp-Sciers / ITers are the guys working Java, C, Python. The management professionals and senior executives are the ones working Haskell because they simply do not have the time to work Java, C, and Python, and Java, C, and Python are simply not productive enough for them, because as the management bible The Effective Executive says, the most valuable resource of an executive is their time.

Yes, the executive / manager might simply tell IT to do the job for them and code up the prototype according to the specifications they’ve issued, but is the executive / manager going to be able to understand the prototype they produced? Or are they going to be constantly paranoid that IT pulled one over on them, while lacking the ability to read the code and certify IT isn’t half-assing?

I suppose we could do the same in Python, but Python is not as terse as Haskell, and whereas in Haskell, it’s easy to produce correct code, but hard to produce performant code, in Python, it’s substantially harder to produce correct code.

2 Likes
#60

According to Crossing the Chasm, there is a big chasm between Early Adopters and Early Majority. The Early Adopters are looking for something new which can give them an edge. The Early Majority want something that works. The Early Majority is where you need to be to get your critical mass, but they need evidence from their peer group to say that it’s a good choice. Of course, you need to get your foot in the door from a standing start, hence the chasm.

So, marketing Haskell means that you need to focus on a market segment, and Haskell had better just work. Recently people have observed that sometimes Haskell doesn’t just work. There’s a thread about Haskell on Windows 11, and you, @Liamzy wrote:

getLine is still broken, whether you’re on 9.22 or 8.10.17, and whether you’re using the standard console emulation mode, or winio.

Using the Haskelline library, though, is a sufficient workaround.

There is your chasm.

3 Likes
#61

It’s partially chicken and egg, no? I mentioned myself that you need libs and support for the use-cases of non-traditional Haskellers, but you need to acknowledge that the non-traditional Haskellers matter and cater to their needs. Caring about crossing the chasm requires caring about the needs of the early majority, and I don’t think the community even knows what the early majority will look like.

I think the important thing is for the Haskell community to accept where we are; Haskell is no longer the new, hot cutting-edge thing, that’s Idris in type systems and F* in directions, but the Haskell community has powerful advantages. Pound for pound, there are probably more library builders per user than in any other language, and moreover, Haskell is still “fun”, in that once you get it, Haskell can be more pleasant to use than any other language out there, due to it’s terseness and correctness, as well as ease of refactoring.

Moving forward, we should embrace what we have and exploit that to expand the community, the use cases, and make Haskell into an even better language.

#62

I think the biggest thing that Haskell lacks that holds it back is a culture of pragmatism. I think that it attracts the kind of people who are willing to endure short term inconvenience and paper cuts in exchange for long term payoffs. Consigning all IO to monads is a great example of a case where this is a worthwhile tradeoff. Unfortunately, I think that this temperament which is selected for, is also apt to disregard or place less weight on inconveniences that come at no benefit whatsoever. People who think this way, I think underestimate the effects of trivial inconveniences on people who don’t.

Haskell is full of papercuts, and they add up. The fact that I have to pull in a dependency and specifically import Data.Text into every single one of my modules to get a proper string type, is a great example. I consider this unacceptable in a modern high-level language. I’m not saying there is an easy solution, but I am saying that in a language with a pragmatic community (most of them), it would have been solved.

String formatting is another example of this phenomenon. Building strings by concatenating them together is a giant pain in the ass, and I hate doing it. When I see people in this thread advocating it as acceptable, I feel like I’m going crazy. I can get by without fstrings, but it turns me off the language. I believe many other people are like me, and bounce off this language not because it is conceptually difficult to learn, but because it is unnecessarily practically difficult to use.

Ultimately I only have so many hours in my life, and there are only so many of those I’m willing to spend dealing with unnecessary inconvenience.

9 Likes
#63

Is haskell that much productive, though? I don’t think it would be productive for juniors, at least.

Hobbyists don’t care about correctness. In most cases, if it works it’s good. Also, I don’t think haskell is going to be on productive side for many of them. Plus, could haskell be made easy enough to really be 2xPython… it seems to me that even 10xPython is a tall order.