Voting is open for the next 20 hours, 28 minutes
Just so I have this straight, your argument is "Haskell is better at everything than Racket, but only if you're smart enough?"

It's not about investment, it's about time learning the quicks and non-obvious bits of the language. A samart person will get there faster than a stupid person, but it'll still take time. Racket gets you farther with less time, but you hit a point of diminishing returns. Haskell has a way of turning parts of systems are are usually non-orthogonal into orthogonal composable components that takes time and practice to get used to, and the structure of the type system supports that process in a way that is hard to emulate in most other languages. Also optimization Haskell is black magic because laziness, while incredibly useful, does weird things to performance and memory use.

Haskell is not a perfect language, and it has a lot of style/design pattern/historical cruft to learn. I'd rather it didn't but my contention is that it's worth it for tasks where you need really complex non-timing guarantees to hold across lots of complex operations. Things like interpreters and compilers.

As for the latter, the only place where I've heard people go "Racket is exceptionally good at X" is developing languages and DSLs.
 
I've gotta say, the programming debate is fun to watch. A bit disheartening from someone who washed out of their CS program after barely learning enough C++ to compile anything, but fascinating nonetheless.

Also what would a sealing Segfault look like? More tentacles?
 
It's not about investment, it's about time learning the quicks and non-obvious bits of the language. A samart person will get there faster than a stupid person, but it'll still take time. Racket gets you farther with less time, but you hit a point of diminishing returns. Haskell has a way of turning parts of systems are are usually non-orthogonal into orthogonal composable components that takes time and practice to get used to, and the structure of the type system supports that process in a way that is hard to emulate in most other languages. Also optimization Haskell is black magic because laziness, while incredibly useful, does weird things to performance and memory use.

Haskell is not a perfect language, and it has a lot of style/design pattern/historical cruft to learn. I'd rather it didn't but my contention is that it's worth it for tasks where you need really complex non-timing guarantees to hold across lots of complex operations. Things like interpreters and compilers.

As for the latter, the only place where I've heard people go "Racket is exceptionally good at X" is developing languages and DSLs.
So it has unpredictable (a polite term for 'bad') performance and memory usage, is difficult to optimize, is difficult to learn, has lots of style/design pattern/historical issues, and is good mostly for low-level toolchain projects that don't actually solve first-order problems. Sign me up!

In seriousness: most of the discussion at (seventh RacketCon) was about type systems, and all of the other people there were worthy of respect so I've been getting interested. Do you have a recommended source from which to learn Haskell?
 
Also what would a sealing Segfault look like? More tentacles?
This assumes they have a memory model under which "segfault" is meaningful. Since its primitives are Lisp primitives, and there is no "dereference arbitrary pointer" operation, that's not going to happen. It's simply not expressible.
Do you have a recommended source from which to learn Haskell?
It's a trap! Don't fall for it!
 
<programming makes me want to poke my head in>

Most of the conversation is not something you'd find out in the earlier parts of a CS education. It requires a certain type (read: insane) mind to dig into the esoterics.

That said, in my current day job I'm writing a Prolog/Lisp/SQL fusion language[1] and we have almost a thousand people writing code in it. Fight me. :D

[1] Relational, extended lisp syntax, solver based on miniKanren.
 
<programming makes me want to poke my head in>

Most of the conversation is not something you'd find out in the earlier parts of a CS education. It requires a certain type (read: insane) mind to dig into the esoterics.
Hm.
That said, in my current day job I'm writing a Prolog/Lisp/SQL fusion language[1] and we have almost a thousand people writing code in it. Fight me. :D
You're in good company for insanity :p
 
Can people not vote for omakes?
You absolutely can!

EDIT: I just realized that you may have meant "Could people please not..." as opposed to "Are we allowed to...." Sorry about that. It's going to be at least one and possibly two more updates worth of omake, but we're trying to get a system nailed down as quickly as possible.
 
Last edited:
Can people not vote for omakes?
I understand your preference for more-salient updates, but -- on top of the acquiescence to these votes being optional on the QM's parts -- I feel that omake fulfill the purpose of these systems-exploring updates as well or better than canon ones would. Particularly when -- as indicated by the Team 7 Chuunin Exams one -- they are hardly guaranteed to be canon even if they involve characters in the story.
 
Can I vote for an update to Lighting Up the Dark Shining Down the Dimness?
You know, from the QM's perspective, I would begin wondering whether when my players wake up, if they think,

"Hm... I wonder how best I can screw with my dear, glorious, ever-generous purveyor of entertainment?"

And then I would weep and reminesce about days in which I could write about simple things, like superintelligent eldritch beings. :p
 
Last edited:
So it has unpredictable (a polite term for 'bad') performance and memory usage, is difficult to optimize, is difficult to learn, has lots of style/design pattern/historical issues, and is good mostly for low-level toolchain projects that don't actually solve first-order problems. Sign me up!

Unintitive ≠ unpredictable

And yes, though admittedly the community is pretty consistently working through historical issues. It's slow because the community also cares about not breaking things, think 1-2 years or 2-3 major versions between depracation of historical cruft and removal.

And, I didn't say it's mostly good for that, just that it's particularly good at low level toolchain work. Lots of people use it for many things, but my day job is low level toolchain work, so I end up caring about it more. Low level toolchain work is fun.

Personally I think it's hard to learn because we teach strict imperative as the "one true way" for everyone, and that sets up mental habits that need to be broken. Honestly, Haskell seems to be intuitive for people from a maths background so it's not like it's not using a consistent mental model.

That's a bit of an issue, there's a bunch of good resources but opinions vary wildly on quality and usefulness. For each of the major on-ramps you'll find passionate evangelists and detractors. There's a good list at the Haskell wiki, though I particularly fond of Happy Learn Haskell Tutorial for the basics and don't really have an opinion for more complex work. I mostly learned past that point by asking on IRC for pointers.

Edit: though Real World Haskell looks good for more practical use of the language, and the Haskell Road to Logic, Maths, and Programming for the mathy mindset that helps make Haskell anomalously good.
 
Last edited:
[X] Shining Down the Dimness

In a way, it's reassuring to hear that people haven't given up on waiting for it. It is still in progress, and this month has been a productive month, but a productive month for me is still pretty poor by most writers' standards, so I wouldn't expect it just yet.
I certainly haven't noticed that; I sure as heck wouldn't be able to keep up writing an update a week for a long as you have.

e: Also, seconding that I've been waiting on it too. It and 2YE are some of the first r/r fics I read :p
 
Last edited:
Voting is open for the next 20 hours, 28 minutes
Back
Top