Live data from Hacker News

Not Lisp again (2009)

funcall.blogspot.com

261–270 of 276 posts

Re: Not Lisp again (2009)

#261

Earlier quoted context omitted.

It's been stated a number of times, but x.f(y, z) has just as many parens as (f x y z). And Haskell particularly comes with so many syntax quirks. There is a lot of cruft you need to learn to get to the underlying functional core of haskell. Lips you can get 100% of the cruft out within a few days / 1 week. And the rest is just understanding programming concepts. I don't use any LISP on a regular basis, but it still…

> And Haskell particularly comes with so many syntax quirks Wouldn't agree per se , I'd rather formulate "it gives the user-land a lot of freedom & powers for introducing syntax quirks". You can code super-clean Haskell, or you can roll in 2 dozen language extensions and libraries with a 100+ custom operators, and use TemplateHaskell --- then yeah the syntax will begin to look horribly "quirky". Many practitioners en…

> super-clean Haskell

The super-cleanest Haskell still has a ton of syntax to learn compared to Scheme. If your goal is to teach concepts of programming, almost any time spent on the syntax of a particular language is time wasted. Particularly so during a semester in university.

Similarly, if you won't be using FP for your day job, and would be using it for the insight gained (and have never used it), a language where you can begin learning concepts without needing to internals a bunch of syntax or infix operator precedence rules is also the better choice.

Re: Not Lisp again (2009)

#262
post #253

Earlier quoted context omitted.

> by using an editor that provides the appropriate assistance. To spell it out: this means Emacs with Paredit, or an imitation thereof.

To any lisp enthusiasts who wonder why the language family isn't more popular: this is 99% of why. You have to use an editor where "copy" is called "Kill-ring-save" is invoked with "Meta-w". Any attempt to use any other tool will be met with incredulous responses to "just use Emacs". It's such a shame because the development environment for Lisp could be so much better than other languages. It could be mindblowingly…

Any large piece of software will have its own terminology (car, cdr, frame, window, buffer, yank, kill, meta, ...). It is a shame that people would rather fixate on these superficial things instead of the minimal effort to get familiarized.

Re: Not Lisp again (2009)

#263
post #225

Earlier quoted context omitted.

Because lisp is good at anything? But especially alternative evaluation systems (of which theorem proving is one). Because they took lisp and added types to it; via the ISWIM language document ("The Next 700 Programming Languages") which was based off of the original lisp. Because the lisp language family is a formulation of lambda calculus and has first class functions, unlike any other language family at the time,…

Can you point me to a good reference paper about this?

No one has really written a paper about the history of all this (I also mentioned this paper [1] in one of my other comments). But if you read the original ML paper [0] you'll see how they developed the language (notably by using ISWIM's syntax as a base). Note also that they are solving a problem with LISP (and dismissing Algol languages entirely) by building in strong types.

[0] http://www.sciencedirect.com/science/article/pii/00220000789...

[1] https://archive.alvb.in/msc/11_infomtpt/papers/the-next-700_...

Re: Not Lisp again (2009)

#264

Earlier quoted context omitted.

> And Haskell particularly comes with so many syntax quirks Wouldn't agree per se , I'd rather formulate "it gives the user-land a lot of freedom & powers for introducing syntax quirks". You can code super-clean Haskell, or you can roll in 2 dozen language extensions and libraries with a 100+ custom operators, and use TemplateHaskell --- then yeah the syntax will begin to look horribly "quirky". Many practitioners en…

> super-clean Haskell The super-cleanest Haskell still has a ton of syntax to learn compared to Scheme. If your goal is to teach concepts of programming, almost any time spent on the syntax of a particular language is time wasted. Particularly so during a semester in university. Similarly, if you won't be using FP for your day job, and would be using it for the insight gained (and have never used it), a language wher…

> a ton of syntax to learn

A handful of keywords (same as any language), fewer (mandatory) parens & braces than any other language, no (mandatory) semicolons, the same sort of indentation one tends to apply in any language anyway --- Essential-Haskell's "ton of syntax" in a nutshell.

Precedence rules for the built-in `Num` and `Bool` operators are equivalent to all languages. Other operators are either custom-defined (outside the scope of language's "syntax") or entirely inessential convenience-vehicles such as for composition (unnecessary, just handy in practice) or avoiding even more parens (dito) --- of which there are 2. Any tutorials or text-books that rely on such or other operators as part of "syntax" are, in that respect, simply a bit flawed.

Re: Not Lisp again (2009)

#265
post #253

Earlier quoted context omitted.

> by using an editor that provides the appropriate assistance. To spell it out: this means Emacs with Paredit, or an imitation thereof.

To any lisp enthusiasts who wonder why the language family isn't more popular: this is 99% of why. You have to use an editor where "copy" is called "Kill-ring-save" is invoked with "Meta-w". Any attempt to use any other tool will be met with incredulous responses to "just use Emacs". It's such a shame because the development environment for Lisp could be so much better than other languages. It could be mindblowingly…

I've just started using Clojure (another Lisp) and I use IntelliJ IDEa with the Cursive plug-in, with par-infer to deal with the parens.

It works like a charm. I can have a REPL and my code right in front of me, I can cmd-down to go to a function definition, and it's overall a very pleasant developer experience.

Now, I did experiment with Emacs, so I do understand what you're talking about -- kill-ring-save and the related key bindings made zero sense to me, and I was having trouble doing things I'd do easily in IntelliJ.

Re: Not Lisp again (2009)

#266
post #251

Earlier quoted context omitted.

Exactly. IMHO, this is quite similar to Python indentation rules, except it is up to writers of Lisp code to be disciplined enough to maintain the proper indentation.

No. Our editors auto-indent the code for us. This is one of the reasons Lisp syntax is better than python. Python syntax does not have enough information to auto-indent so it really is up to the programmer. Not so with Lisp.

I hate when I code python and refactor stuff, moving stuff around and such, that I cant just copy/clip around and then do a final 'indent all my work correctly' like I can in a language like lisp.

I am kind of developing a grudge against whitespace sensitive languages. Not because it forces the programmer to indent properly, but because it disables my editors abilities to do it for me.

Re: Not Lisp again (2009)

#267

Earlier quoted context omitted.

To me the hard part about lisp is that every programmer that uses lisp tailors it so to their own taste that it can become quite hard to read the 'top level' of a lisp program without first having gone through all the lower layers. It is as if every project in lisp somehow magically develops its own DSL. That's a high hurdle for newbies to clear.

Fortunately, JEE & Spring are MUCH easier to get started with :-) Let them eat COBOL...

Cobol, that's where you get your CICS! The original heavyweight framework, callbacks and all. Loads of fun.

Re: Not Lisp again (2009)

#268
post #251

Earlier quoted context omitted.

No. Our editors auto-indent the code for us. This is one of the reasons Lisp syntax is better than python. Python syntax does not have enough information to auto-indent so it really is up to the programmer. Not so with Lisp.

I hate when I code python and refactor stuff, moving stuff around and such, that I cant just copy/clip around and then do a final 'indent all my work correctly' like I can in a language like lisp. I am kind of developing a grudge against whitespace sensitive languages. Not because it forces the programmer to indent properly, but because it disables my editors abilities to do it for me.

Actually, Python has the equivalent of open-parens: the colon. What it doesn't have is close-parens, but if you use emacs then it will outdent on PASS and RETURN statements. In my personal coding style I always put PASS statements at the end of block so my code auto-indents properly. Hard-core Pythonistas hate this, but I really don't care what they think.

Re: Not Lisp again (2009)

#269
post #209
post #204

Earlier quoted context omitted.

Why? (And what language do you use where you don't have to rely on the editor to format your code?)

To me, that's a sign that maybe a language has too little syntax. I can read C++, Javascript and PHP just as well in plain text because the other non-paren elements provide necessary contextual cues, along with nesting. Syntax coloring is helpful, but it shouldn't be necessary. I can at least understand nesting closing parens on their own lines, the way Roboprog did above, but throwing all of them on a single line ju…

Thanks. Almost nobody liked my comment (downvoted), but it sure kicked off a long discussion :-)

I haven't done any actual Lisp since the 80s on a CDC Cyber mainframe and a dedicated expansion card on an Apple II, so I'm "a wee bit" out of date.

I'm very visual / "geometric", so I like to see the "shape" of things. I can't stand looking at stuff "formatted" (?) in the typical enterprise java (8) "staircase of doom" with minimal whitespace, incredibly long lines, with a few arbitrary line wraps that indent to random spots way off on the right.

I swear, many programmers have never considered how newspapers and textbooks are formatted. They don't sprawl text endlessly across even if the paper is wide, they keep it reasonably narrow so your eye can follow it.

Re: Not Lisp again (2009)

#270
post #201

Earlier quoted context omitted.

> by using an editor that provides the appropriate assistance. To spell it out: this means Emacs with Paredit, or an imitation thereof.

Having to depend on an editor to make your code legible seems like a bad thing.

Especially since most IDE's seem to go out of their way to make sludge out of the text, unless you have hours to spend training each one, and can figure out how to do so...

... until your coworker edits the file in the out of the box IDE and munges it.

I guess now-a-days, our languages and frameworks are so ugly they need a "bag" over their [inter]face while you are doing them :-)

Post reply on HN