Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Just what does “code as data” mean anyway? (2014)

adambard.com

Post reply on HN
Print view View original

131–140 of 178 posts

Re: Just what does “code as data” mean anyway? (2014)

#131

Post by dmitriid »

didibus wrote: post #128
dmitriid wrote: post #125

Earlier quoted context omitted.

I wish people who downvote my comment would explain what they disagree with. The entire discussion in this subtree centers around paredit (oooh, it can slice and slurp lists!) and vi commands. Have you ever ever seen and experienced an actual modern coding environment? IntelliJ IDEA? Visual Studio? Hell, even Visual Studio Code. The full power of those tools put both vi and paredit to shame when it comes to actually…

You were downvoted because what you said shows that you do not understand what paredit is. I'd recommend you read https://en.m.wikipedia.org/wiki/Structure_editor to better grasp the concept. If you've ever used the XML structure view in eclipse, its the Design tab, you get a better idea. In contrast to its source tab.

Let's see. Here's the original text:

> Rather than thinking in letters, words, lines, or paragraphs, editor modes like paredit let you edit in terms of the structure of your code

So. My question is: which modern programmer thinks in terms of thinks about code in terms of letters, words, lines, or paragraphs?

The truly antiquated tools (like vi and emacs) may still handle code as if it was just text. The actual code editing tools have long been able to deal with the structure of the code. And in ways that paredit may only dream of.

> If you've ever used the XML structure view in eclipse, its the Design tab, you get a better idea.

Erm. The only "think semantically" that paredit pretends it does happens only because Lisp has a rather regular syntax. It doesn't take much thinking or work to move parts of code in and out of parenthesis, or to be able to close a matching bracket.

Actual modern tools know the structure of the code and offer much greater editing and code handling capabilities than that.

Edit:

As a trivial example. Here's IntelliJ and PHP code (yes, PHP). It understands the code, it's structure, and offers context based editing help based code structure and semantics: https://dmitriid.com/i/gm2tmnztha4tenjq.png

Speaking of semantics. Unlike the dumb "move things in out of brackets" the actual tools understand semantics of code. Once again, this is PHP (!), and the tool knows about the semantics of code: https://dmitriid.com/i/gm2tmnbtga4tanjs.png

Editing capabilities available to some other languages would blow your mind.

Re: Just what does “code as data” mean anyway? (2014)

#132

Post by jstimpfle »

nickpsecurity wrote: post #75
peatmoss wrote: post #14

Earlier quoted context omitted.

I find C syntax awkward, bloated, inconsistent, and gross compared to lisp syntax, but that’s an aesthetic preference. Beyond the personal preferences of individuals (individuals who probably started with one kind of syntax or another) there are characteristics that have some objective utility. I appreciate that a lot of people start with C-ish syntax, and a similarly large number of people prefer that syntax, but I’…

"I appreciate that a lot of people start with C-ish syntax, and a similarly large number of people prefer that syntax, but I’ve never heard anything that demonstrated an intrinsic benefit of C syntax." Short stuff is easier to type and maybe to read. There's that. Far as its "design," it was made by tweaking BCPL to make it run on a PDP-7 and then PDP-11. The assignment change was admitted as personal preference. BCP…

> The brain then starts rationalizing attributes about it that were designed or hacked in for totally different reasons in a past of constrained hardware lacking knowledge or tools of modern, language design. That context no longer applies to most users of C. It's just myth-making by users reinforcing use of it.

That's just _your_ rationalization. I don't think it's commonly claimed that all was set in stone from the beginning. The history is there for everyone to read.

Another possible explanation is that C is so minimal (in spirit) and doesn't get in the way, people are able to pull of impressive things, which makes them love C.

And now why exactly isn't (the gist of) C sensible design? I fail to see your argument. By the way, please enjoy this cool video: https://www.youtube.com/watch?v=khmFGThc5TI

Re: Just what does “code as data” mean anyway? (2014)

#133

Post by goatlover »

jstimpfle wrote: post #67
kbp wrote: post #47

Earlier quoted context omitted.

> I don't disagree that if all you have is parens, then you want something like paredit. But for a C programmer there is no need for such a thing. If that's a good selection of tools for editing code, then why would Lisp programmers need Paredit? Most of those commands work just as well for editing Lisp. The advantages that Paredit gives over that model are semantic commands rather than character based ones, things l…

But there is no such thing as "parent lists" in C. There are much less parentheses. You don't make nested functions or data. You write simple, procedural code, and therefore you simply move lines up or down, and at most change the indentation level. (To fix indentation in vim, select a block of lines and use =. To shift left or right, use >).

So instead of lots of parens, you get lots of {}, [], and () spread across more lines, and curly braced blocks are often nested.

Re: Just what does “code as data” mean anyway? (2014)

#134

Post by [deleted] »

metaobject wrote: post #109
zeveb wrote: post #34

Earlier quoted context omitted.

That's the beauty of Lisp: it's all very readable, because it's a real language, not a string-substitution preprocessor. Yes, any idiot can write unreadable Lisp — but good Lisp is a work of art. The Art of the Metaobject Protocol should be required reading: it builds an entire object system, complete with classes and generic functions (multimethods), written in the language itself . It's a tour de force .

And I'm just pointing this out for those who aren't already aware -- C macros and Lisp macros aren't really comparable. C macros are implemented as string substitutions in a separate step before compilation. Lisp macros can make use of the rest of the language features and allow for operations on the abstract syntax tree of the code, opening up things like adding new control constructs, generating boilerplate code, s…

[deleted]

Re: Just what does “code as data” mean anyway? (2014)

#135

Post by andolanra »

kamaal wrote: post #122
scottmsul wrote: post #26

Would it be possible to do the same thing in Haskell using partial function application, where the first argument is the name of the tag and the second argument makes the " " tags and applies string concatenation?

Haskell comes from a family of languages called ML. And ML was known as Lisp without parentheses. So its again Lisp all over again.

I don't know that I've ever seen someone call ML "Lisp without parentheses". Regardless, even with some familial relationship and a few principles in common (like a commitment to functional programming) the two lineages are far more different than they are alike: Lisp has a powerful dynamic core and intricate metaprogramming capabilities, while Haskell builds on a powerful type system and non-strict evaluation. Saying that Haskell is "Lisp all over again" is sort of like saying that cars are "trains all over again": a statement so reductive, it's somewhere between wrong and nonsensical!

Re: Just what does “code as data” mean anyway? (2014)

#136

Post by lazyasciiart »

didibus wrote: post #128
dmitriid wrote: post #125

Earlier quoted context omitted.

I wish people who downvote my comment would explain what they disagree with. The entire discussion in this subtree centers around paredit (oooh, it can slice and slurp lists!) and vi commands. Have you ever ever seen and experienced an actual modern coding environment? IntelliJ IDEA? Visual Studio? Hell, even Visual Studio Code. The full power of those tools put both vi and paredit to shame when it comes to actually…

You were downvoted because what you said shows that you do not understand what paredit is. I'd recommend you read https://en.m.wikipedia.org/wiki/Structure_editor to better grasp the concept. If you've ever used the XML structure view in eclipse, its the Design tab, you get a better idea. In contrast to its source tab.

Can you explain it? For instance in IntelliJ I can refactor and have it automatically replace only instances of the word "call" that are actually invocations of the function call(). That's structured editing, not text-based.

Re: Just what does “code as data” mean anyway? (2014)

#137

Post by didibus »

dmitriid wrote: post #131
didibus wrote: post #128

Earlier quoted context omitted.

You were downvoted because what you said shows that you do not understand what paredit is. I'd recommend you read https://en.m.wikipedia.org/wiki/Structure_editor to better grasp the concept. If you've ever used the XML structure view in eclipse, its the Design tab, you get a better idea. In contrast to its source tab.

Let's see. Here's the original text: > Rather than thinking in letters, words, lines, or paragraphs, editor modes like paredit let you edit in terms of the structure of your code So. My question is: which modern programmer thinks in terms of thinks about code in terms of letters, words, lines, or paragraphs? The truly antiquated tools (like vi and emacs) may still handle code as if it was just text. The actual code e…

You were probably downvoted too because you keep assuming other people talking about structural editing have never used IDEs for Java, php, C++, C#, etc.

Nothing is blowing my mind, structural editing is different from what you're talking about, and enables different benefits and also downsides then those.

I think the wikipedia article I linked does a good job at explaining the distinction:

> editors in some integrated development environments parse the source code and generate a parse tree, allowing the same analysis as by a structure editor, but the actual editing of the source code is generally done as raw text.

Re: Just what does “code as data” mean anyway? (2014)

#138

Post by goatlover »

kamaal wrote: post #70
flavio81 wrote: post #35

Earlier quoted context omitted.

>I agree, OO is ultimately good enough. And Common Lisp has arguably the most flexible and powerful OOP system around, CLOS. Why don't write OOP in Lisp? It is done successfully by lispers around the world.

>>Why don't write OOP in Lisp? Because most people understand OO as some kind of namespace scheme. Basically to bunch together functionality under a name(class). When people talk of OO, most of them, are actually talking about modularizing code.

That's modules or packages. OO includes inheritance, polymorphism and treating objects as black boxes (little computers in Alan Kay's mental model) with messages they respond to, or APIs for working with that kind of object.

It's a lot more than simply being a namespace. It's also that idea that an object has state and behavior, with appropriate semantics for dealing with both (depending on the language).

Objects (with classes or prototypes) act as a new kind of data type bundled with functionality for handling that data, which is more than just putting a bunch of functions and variables into a namespace. So you can treat your class/prototype as a built-in complex data type. You're extending the type system in an encapsulated manner.

It's not called Namespace Oriented Programming

Re: Just what does “code as data” mean anyway? (2014)

#139

Post by dmitriid »

didibus wrote: post #137
dmitriid wrote: post #131

Earlier quoted context omitted.

Let's see. Here's the original text: > Rather than thinking in letters, words, lines, or paragraphs, editor modes like paredit let you edit in terms of the structure of your code So. My question is: which modern programmer thinks in terms of thinks about code in terms of letters, words, lines, or paragraphs? The truly antiquated tools (like vi and emacs) may still handle code as if it was just text. The actual code e…

You were probably downvoted too because you keep assuming other people talking about structural editing have never used IDEs for Java, php, C++, C#, etc. Nothing is blowing my mind, structural editing is different from what you're talking about, and enables different benefits and also downsides then those. I think the wikipedia article I linked does a good job at explaining the distinction: > editors in some integrat…

> You were probably downvoted too because you keep assuming other people talking about structural editing have never used IDEs

coming from a person who also wrote this:

> You were downvoted because what you said shows that you do not understand what paredit is. > I'd recommend you read ... to better grasp the concept.

So, people keep assuming that I for some reason have never tried paredit (or written anything in Lisp). So why don't I give you a taste of your medicine.

I suggest that you go and read some documentation on the IDEs I mentioned and try and use them to better grasp the concept.

Paredit is a very dumb tool that only works because Lisp's syntax is regular. There's nothing semantic or structural about the ability to move some words in or out of parentheses or to close matching brackets.

Other languages might not have the same wondrous ability simply because their syntax is more complex. Their tools though clearly allow much better actual structural editing and actual semantic reasoning about code.

Re: Just what does “code as data” mean anyway? (2014)

#140

Post by joshuamorton »

kamaal wrote: post #129
joshuamorton wrote: post #123

Earlier quoted context omitted.

>In lisp there is only rule, everything is a list Well no. `print` is not a list. `4` is not a list. `(print 4)` is a list containing the scalars `print` and `4`. The mechanics of lisp then say "apply the thing in the first position to the remainder of the list", but that's just notation. In python, `sum` is a function that can apply to a splatted sequence of scalars (note that it can also apply to a list, but this i…

You seem to be suggesting (sum 1 2 3 4 5) and sum(1, 2, 3, 4, 5) are the same because they both return 15. That's just one way of looking at things. And that is true only if, that one is the only way of looking at things. Structurally (sum 1 2 3 4 5) and sum(1 2 3 4 5) are NOT similar. They are not even close, in fact they represent opposite schools of thought. There is a reason we are insisting on everything being l…

    task3(task2(task1(work)))
can, with the function

    apply(data, *funs):
        return reduce(lambda d, f: f(d), [data] + funs)
be rewritten as

    apply(work, task1, task2, task3)
Its possible in exactly the same set of cases, namely those where each task takes a single argument/is provided as a partial.

I expect that `->` is implemented in clojure in much the same way (and [1] implies that, modulo some scaffolding and error checking, it is, although with a recursive, inlined impl of reduce)

[1]: https://github.com/clojure/clojure/blob/08e592f4decbaa08de57...

Post reply on HN