7 ms·

Lisp as Blub

28 points by mqt 19y ago

pg 19y ago
He's reading too much into this. At loads this low, it can't be a language design issue. There's probably just a bug in Mzscheme. Hard to say whether this post is deliberate linkbait or just overeagerness to see this as evidence confirming a pre-existing bias. Probably a little of both.
- davidw 19y ago
  It's sort of linkbait, and it'd be more interesting if he had something more substantive to say... however, Erlang certainly is adept at being a robust, stable server, and has had a lot of time and brain power poured into those efforts, so I think they have a right to be proud. It'd be better to find another way of saying it, though.
- icey 19y ago
  Tangent: In your troubleshooting, have you already made sure you aren't occasionally receiving a malformed request that is causing the server to puke? In other server software that has displayed that sort of behavior, I've seen that be the problem more often than a traffic issue. I mean; you would have noticed a memory leak type of situation by now, I'd imagine.
  - pg 19y ago
    I'm pretty sure that isn't the cause, because Patrick has been able to reproduce the problem by generating only correctly formed requests.
    - icey 19y ago
      I poked around some in news.arc from the download on arclanguage.org; it looks like the newscache macro does quite a lot of heavy lifting... I recall reading someone having some weird issue with the way w/uniq's gensym works (vs. mzscheme's) - is it possible some change has been made to that functionality in the past month or two? Unless of course Patrick is generating requests that perform functionality, like logging in, up/down voting etc... Then the idea is totally moot since you'd be hitting a much larger cross-section of functionality. I don't really know Arc and it's intimidating making suggestions knowing the caliber of people looking at the issue; but I figured sometimes an opinion from someone who isn't intimately familiar with the code can be at least a little helpful. If not, feel free to ignore this post completely =D
- damienkatz 19y ago
  Confirming bias? Maybe. Link bait? Definitely. But you say it likes it's a bad thing. Do you think I don't have a valid point? Are you not debugging a memory leak in a production Lisp app? With Lisp you can put together a site in a few hours. But how many days must later be spent debugging issues like this? Will this time spent debugging be counted against your productivity gains you attribute to Lisp? This is exactly the sort of problem Erlang has nailed down. And it requires a whole new thinking about program structure. Is it possible you don't see the problems with Lisp because you can't imagine there is a fundamentally better way?
  - deleted 19y ago
    [deleted]
  - apgwoz 19y ago
    > Are you not debugging a memory leak in a production Lisp app? But, you're confusing the actual application with the Lisp implementation. Arc (and Mzscheme for that matter) are not as mature as Erlang's 20 years (or whatever). If this was running on a more mature Lisp system, I don't think we'd be discussing the same thing.
    - davidw 19y ago
      You don't get to pick and choose implementations to compare. Mzscheme was probably chosen because it's a pretty well known scheme implementation and seems popular... likely because it's well done in many ways. But you have to take the bad with the good.
      - dpapathanasiou 19y ago
        Maybe the problem is Arc's lack of tensile strength.
    - simonb 19y ago
      To be honest, this is not the only such case. Eve Online folks migrated part of their system from SBCL to Erlang for seemingly the same reasons [http://lambda-the-ultimate.org/node/2102 http://lambda-the-ultimate.org/node/2102]. Having said that, it is still not a language issue, since we have systems such as Termite/Gambit Scheme [http://toute.ca http://toute.ca].
- lg 19y ago
  have you tried the latest mzscheme? i remember you were running arc on v352, the libraries have changed a lot since then, so maybe the gc did too... iirc there's a patch on anarki or someplace to make it work.
raganwald 19y ago
Interesting point about having a process-oriented architecture where each process has its own independent GC, but boy-o-boy is the title a troll-tastic piece of link-bait.
henning 19y ago
I don't get it. The "blub" quality refers to expressiveness, not the robustness of the runtime system or suitability for particular kinds of application development. To say that Arc is not concerned with brevity or expressiveness is simply ridiculous. For the record, I think the way Erlang supports functional programming isn't particularly elegant and I think having Prolog-like syntax without Prolog-like semantics is silly.
- LogicHoleFlaw 19y ago
  having Prolog-like syntax without Prolog-like semantics is silly. Yes. Yes! I'm not the only one thinking it then! I think the Erlang process model is brilliant but it really took on the ugliness of the Prolog syntax without attaining the full benefits of the Prolog logical semantics.
  - KirinDave 19y ago
    My misogynistic and politically incorrect, but very accurate, metaphor for erlang is, "The Ugly Girl Who's Great In Bed." You don't mind doing the horizontal polka with her, but she certainly won't win any beauty contests. That said, a few small changes to the erlang grammar could go a long way towards fixing it (changing separators to terminators, etc). Once you get more familiar with Erlang, you go from writing ugly cascading ifs on multiple conditions to simple clean case statements on tuples. You learn when to use function-clause matching vs. internal matching, etc.
  - giardini 19y ago
    I think Erlang is brilliant because it keeps Prolog's unification (matching) but discards Prolog's backtracking in favor of procedural execution. Unification can be very useful in solving some problems. Backtracking is also useful but sometimes gets in the way. Procedural code can be used to do anything that any language can do and students are more familiar with it. So I think Erlang is an interesting addition to languages. And that's without considering it's more practical aspects, e.g., multiprocessing, failover capability, etc. Nor is Prolog syntax particularly ugly. A problem is that it is too simple, so simple that novices can become confused. Brna, Boulay and Pain discuss why Prolog is difficult in the book: "Learning to Build and Comprehend Complex Information Structures: Prolog as a Case Study" http://www.amazon.com/Learning-Comprehend-Complex-Information-Structures/dp/1567504345/ref=sr_1_2/102-1192735-0366500?ie=UTF8&s=books&qid=1208217565&sr=1-2 http://www.amazon.com/Learning-Comprehend-Complex-Informatio... See the review there by Randall Heltzerman titled "The Most Unlikely Book Ever to be Published".
mnemonicsloth 19y ago
"Why current event X means we should all grind my favorite axe."
- boorad 19y ago
  It's a pretty robust axe
lst 19y ago
If you want to prove something seriously, please find some more examples. (Really!)
mroman 19y ago
This guy sounds like a suit in a boardroom . . . just spouting words devoid of validity . . .

28 points by mqt 19y ago

pg 19y ago

He's reading too much into this. At loads this low, it can't be a language design issue. There's probably just a bug in Mzscheme. Hard to say whether this post is deliberate linkbait or just overeagerness to see this as evidence confirming a pre-existing bias. Probably a little of both.

davidw 19y ago
It's sort of linkbait, and it'd be more interesting if he had something more substantive to say... however, Erlang certainly is adept at being a robust, stable server, and has had a lot of time and brain power poured into those efforts, so I think they have a right to be proud. It'd be better to find another way of saying it, though.
icey 19y ago
Tangent: In your troubleshooting, have you already made sure you aren't occasionally receiving a malformed request that is causing the server to puke? In other server software that has displayed that sort of behavior, I've seen that be the problem more often than a traffic issue. I mean; you would have noticed a memory leak type of situation by now, I'd imagine.
- pg 19y ago
  I'm pretty sure that isn't the cause, because Patrick has been able to reproduce the problem by generating only correctly formed requests.
  - icey 19y ago
    I poked around some in news.arc from the download on arclanguage.org; it looks like the newscache macro does quite a lot of heavy lifting... I recall reading someone having some weird issue with the way w/uniq's gensym works (vs. mzscheme's) - is it possible some change has been made to that functionality in the past month or two? Unless of course Patrick is generating requests that perform functionality, like logging in, up/down voting etc... Then the idea is totally moot since you'd be hitting a much larger cross-section of functionality. I don't really know Arc and it's intimidating making suggestions knowing the caliber of people looking at the issue; but I figured sometimes an opinion from someone who isn't intimately familiar with the code can be at least a little helpful. If not, feel free to ignore this post completely =D
damienkatz 19y ago
Confirming bias? Maybe. Link bait? Definitely. But you say it likes it's a bad thing. Do you think I don't have a valid point? Are you not debugging a memory leak in a production Lisp app? With Lisp you can put together a site in a few hours. But how many days must later be spent debugging issues like this? Will this time spent debugging be counted against your productivity gains you attribute to Lisp? This is exactly the sort of problem Erlang has nailed down. And it requires a whole new thinking about program structure. Is it possible you don't see the problems with Lisp because you can't imagine there is a fundamentally better way?
- deleted 19y ago
  [deleted]
- apgwoz 19y ago
  > Are you not debugging a memory leak in a production Lisp app? But, you're confusing the actual application with the Lisp implementation. Arc (and Mzscheme for that matter) are not as mature as Erlang's 20 years (or whatever). If this was running on a more mature Lisp system, I don't think we'd be discussing the same thing.
  - davidw 19y ago
    You don't get to pick and choose implementations to compare. Mzscheme was probably chosen because it's a pretty well known scheme implementation and seems popular... likely because it's well done in many ways. But you have to take the bad with the good.
    - dpapathanasiou 19y ago
      Maybe the problem is Arc's lack of tensile strength.
  - simonb 19y ago
    To be honest, this is not the only such case. Eve Online folks migrated part of their system from SBCL to Erlang for seemingly the same reasons [http://lambda-the-ultimate.org/node/2102 http://lambda-the-ultimate.org/node/2102]. Having said that, it is still not a language issue, since we have systems such as Termite/Gambit Scheme [http://toute.ca http://toute.ca].
lg 19y ago
have you tried the latest mzscheme? i remember you were running arc on v352, the libraries have changed a lot since then, so maybe the gc did too... iirc there's a patch on anarki or someplace to make it work.

raganwald 19y ago

Interesting point about having a process-oriented architecture where each process has its own independent GC, but boy-o-boy is the title a troll-tastic piece of link-bait.

henning 19y ago

I don't get it. The "blub" quality refers to expressiveness, not the robustness of the runtime system or suitability for particular kinds of application development. To say that Arc is not concerned with brevity or expressiveness is simply ridiculous. For the record, I think the way Erlang supports functional programming isn't particularly elegant and I think having Prolog-like syntax without Prolog-like semantics is silly.

LogicHoleFlaw 19y ago
having Prolog-like syntax without Prolog-like semantics is silly. Yes. Yes! I'm not the only one thinking it then! I think the Erlang process model is brilliant but it really took on the ugliness of the Prolog syntax without attaining the full benefits of the Prolog logical semantics.
- KirinDave 19y ago
  My misogynistic and politically incorrect, but very accurate, metaphor for erlang is, "The Ugly Girl Who's Great In Bed." You don't mind doing the horizontal polka with her, but she certainly won't win any beauty contests. That said, a few small changes to the erlang grammar could go a long way towards fixing it (changing separators to terminators, etc). Once you get more familiar with Erlang, you go from writing ugly cascading ifs on multiple conditions to simple clean case statements on tuples. You learn when to use function-clause matching vs. internal matching, etc.
- giardini 19y ago
  I think Erlang is brilliant because it keeps Prolog's unification (matching) but discards Prolog's backtracking in favor of procedural execution. Unification can be very useful in solving some problems. Backtracking is also useful but sometimes gets in the way. Procedural code can be used to do anything that any language can do and students are more familiar with it. So I think Erlang is an interesting addition to languages. And that's without considering it's more practical aspects, e.g., multiprocessing, failover capability, etc. Nor is Prolog syntax particularly ugly. A problem is that it is too simple, so simple that novices can become confused. Brna, Boulay and Pain discuss why Prolog is difficult in the book: "Learning to Build and Comprehend Complex Information Structures: Prolog as a Case Study" http://www.amazon.com/Learning-Comprehend-Complex-Information-Structures/dp/1567504345/ref=sr_1_2/102-1192735-0366500?ie=UTF8&s=books&qid=1208217565&sr=1-2 http://www.amazon.com/Learning-Comprehend-Complex-Informatio... See the review there by Randall Heltzerman titled "The Most Unlikely Book Ever to be Published".

mnemonicsloth 19y ago

"Why current event X means we should all grind my favorite axe."

boorad 19y ago
It's a pretty robust axe

lst 19y ago

If you want to prove something seriously, please find some more examples. (Really!)

mroman 19y ago

This guy sounds like a suit in a boardroom . . . just spouting words devoid of validity . . .