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.
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.
Just what does “code as data” mean anyway? (2014)
141–150 of 178 posts
Re: Just what does “code as data” mean anyway? (2014)
#142Earlier quoted context omitted.
I theorize lisp isn't used more because of the massive amounts of parenthesis. I think the concepts are great, and it's a great language for certain task, but my right pinky finger hurts just looking at it. New programmers and developers look at that and compare it to something like Go, Python, or JavaScript, and all those look easier to write (although deceptively complex in places) and are 1000x easier to read. A p…
>New programmers and developers look at that and compare it to something like Go, Python, or JavaScript, and all those look easier to write (although deceptively complex in places) and are 1000x easier to read. Are you sure? Reading a file in Go func read(f) { var text string var scanner *bufio.Scanner var err error file, err := os.Open(f) if err != nil { log.Fatal(err) } scanner = bufio.NewScanner(file) for scanner.…
Perhaps a lisp with python-style indentation for blocks would be more easily read?
def read (filename)
with-open-file (input filename)
for line in (read-line input nil)
while line do
print lineRe: Just what does “code as data” mean anyway? (2014)
#143Earlier quoted context omitted.
Sure there is. Imagine you had this function: int f(void) { int x = 1; return x * 2; } Then pretend that later you wanted to call f and provide your own value of x for it to transform, but you realise that f doesn't take a parameter, so you go to move the x declaration in f into its parameter list. What you really want to do here is delete the first element of the parameter list, and then move the first expression in…
Regarding the loop: that's exactly what I described, you just move lines and fix the indentation. It's super quick. There just isn't significant nesting in good code. It's almost always bad style to nest function calls. In statement-blocks you don't have the "trailing parentheses" problem that you have in LISP, since the closing brace is on its own line - so it really boils down to cutting and pasting lines >90% of t…
The experience you get with Paredit is not the same experience you get with C and vi, because you have to be concerned with things at the character level to make the transformation. What single command do you use to move the function call, for loop, label, or do-while loop after the closing brace of the current block into this block, whether it's 1 line or 100? What if you have something like f(x, y * 2) and you decide that you want to put y * 2 into a variable instead? Do you write every argument to every function on its own line?
Again, if you want to do things the C way in Lisp, it's not like Lisp makes it hard to do those kinds of edits. Things like Paredit are popular because people find them more efficient to use. Editors can support Paredit-like editing in C, but it's much more difficult to accomplish because of limitations with C's syntax.
Re: Just what does “code as data” mean anyway? (2014)
#144Earlier quoted context omitted.
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.
Yea, that's true, but your editor pane is a text editor non the less. The refactoring in this case is structured, even more so, its semantically accurate to a specific language. But your editor isn't. A structural editor does not allow you to make edits that would go against the syntax rules of your language.
And the editor pane with paredit somehow becomes a magical structural editing machine?
Paredit knows exactly zero things about your code. The only thing it can do is match brackets/parentheses and move code between them. That's it.
In an actual code editing tool that actually understands code structure and semantics, I can:
- select and move semantically and structurally valid blocks of code
- extract parts of code into a separate variable
- extract parts of code into a separate function
- extract parts of code into a separate module
- safely rename variables and functions across multiple files
- simplify/split/extract/generify code
- ... many more ...
Re: Just what does “code as data” mean anyway? (2014)
#145Earlier 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…
The --> macro invocation would just look like -->(work, task1, task2, task3).
There are good reasons for considering f(x, y) to be a bad notation compared to (f x y); but this isn't one of them.
Re: Just what does “code as data” mean anyway? (2014)
#146Earlier quoted context omitted.
You'll have to substantiate that, because refactoring Java is pretty easy if you have a good IDE. In many other languages, you're lucky if you can reliably rename a function without having to manually check for false positives, let alone something complicated like change signature or extract superclass . Also, in any statically typed language, you can fall back on changing the function and using compile errors to tel…
refactoring Java is pretty easy if you have a good IDE rename a function Refactoring in software development is not the same as refactoring in IDEs. Refactoring in software development is changing existing code. Specially the architectural parts.
Re: Just what does “code as data” mean anyway? (2014)
#147Earlier quoted context omitted.
> Care to explain? Some of this comes down to what you consider a 'large' program. Suppose you want to build an MMO in lisp, now you need to consider things running on both a client, and server, as well as rendering, path-finding etc. Choosing reasonable primitives becomes difficult as you get pulled in several directions. Should I be running the same code on client an server or should I have multiple different model…
This looks more like software design problem and not a Lisp problem. Building anything complex requires, apart from tools, getting organized in a lot of other things as well.
The is an old saying they enterprise software ends up mapping the organization that built it. If you have N teams you tend to break a large project into at least N parts.
Sharing code between teams works, but it's harder to share complex lisp macros vs functions. Which is really closer to my point, the larger the project the more tools get set aside too being to ~complex/risky to safely use.
Re: Just what does “code as data” mean anyway? (2014)
#148Earlier quoted context omitted.
> Rather than thinking in letters, words, lines, or paragraphs, editor modes like paredit let you edit in terms of the structure of your code. Is there a single programmer on this planet who thinks about code in terms of letters, words, lines, or paragraphs? Newsflash: it's 2018, not 1960, and code editors are capable of things most lisp "editor modes" can only dream about.
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…
As for full IDEs, they absolutely have a place. They can even infer things about the structure of your code fairly well. I still find the productivity of being able to work deterministically and consistently with my code at a structual level a pleasure.
I’d appreciate that even in an IDE, if for no other reason than that the structure editing could be done efficiently and leave me some extra system resources for other things :-)
Re: Just what does “code as data” mean anyway? (2014)
#149Earlier quoted context omitted.
I'm still wrapping my head around macros, but I have been able to come up with a couple use cases that I quickly realized were already covered by existing macros, the most recent one being a less flexible -> macro. Anyways, I kept reading places that lisp macros and c macros were completely distinct, which seems untrue after a couple years of trying clojure.
>Anyways, I kept reading places that lisp macros and c macros were completely distinct, which seems untrue after a couple years of trying clojure. I haven't used Clojure macros but as a programmer that uses both C and Common Lisp, I can say with good authority that C macros and CL macros are very different.
Re: Just what does “code as data” mean anyway? (2014)
#150And, as I wrote in another thread yesterday, it allows you to work with your text editor at a higher level of abstraction than non-lisp-coding people may have seen before ( https://news.ycombinator.com/item?id=16386380 ). Rather than thinking in letters, words, lines, or paragraphs, editor modes like paredit let you edit in terms of the structure of your code. I find this really hard to give up after lispy sessions.
I really value C syntax. I'm convinced it's much easier to navigate with the eyes than "oatmeal with fingerclips mixed in" (quoting Larry Wall). And >90% of the time the relevant syntactic unit is on its own line or ranges of lines, and that's really super easy to handle in vim. I don't think there is much to improve by building more complex abstractions on top. If you use vim as a C programmer, you should know the b…
That exact phrasing only seems to show up in 2 places: this comment, and a comment of yours from about a year ago. So I suspect you're paraphrasing...but my purpose for looking was to find that talk/essay/whatever. Would you happen to have a link?