Lisp, Smalltalk, and the Power of Symmetry (2014) • Hacker News Board

Re: Lisp, Smalltalk, and the Power of Symmetry (2014)

#51

Post by gnaritas » Sun, May 14, 2017, 3:19 PM UTC

shawk wrote: post #42

gnaritas wrote: post #11

Earlier quoted context omitted.

> Lisp and Smalltalk actually suffer from the same problem: late-binding sucks. That's a feature, not a bug. Late binding rocks. > This plays havoc with your ability to do static analysis, and languages that hinder static analysis should not be used in real-world systems. The real world is full of late bound languages; much of the internet runs off late bound languages including this site. There's a million Rails and…

> That's a feature, not a bug. Late binding rocks. So much that you can see ripples everywhere of late binding languages being slowly (not saying the transition is complete) replaced by static languages. Even the one true bastion of late binders, web development, is seeing massively increasing adoptions of languages like Typescript on the frontend, and languages like Go on the backend (see adoption at Youtube, Dropbo…

We get it, you're a static typing fan, this debate is as old as the hills, but late bound dynamic languages are not going anywhere, are not being replaced, and will continue be popular and make money because what you don't seem to get is that we don't all agree static typing is the golden hammer you seem to think it is. Yes, those people are software engineers despite your unwarranted superiority. And Rust... please, in time maybe but right now it's hardly used and can not remotely be called a popular language, not in comparison with the popular dynamic languages which dwarf it in usage by orders of magnitude.

Re: Lisp, Smalltalk, and the Power of Symmetry (2014)

#52

Post by gnaritas » Sun, May 14, 2017, 3:23 PM UTC

lispm wrote: post #30

gnaritas wrote: post #29

Earlier quoted context omitted.

I'm well aware, I've programmed in Pharo daily for a decade; I Smalltalk for a living. What I said it true practically speaking, you're getting into implementation details that don't make a practical difference. Lisp and Smalltalk are both image based systems, but Smalltalk'ers actually work on the running live image all of the time, they aren't ever booting from the sources file nor are they ever editing it manually…

> editing it manually You edit the source code via the IDE. Just like in Lisp systems. It's just that the IDE works differently. > Smalltalk'ers actually work on the running live image all of the time That's the dominant way to work in Lisp, too. My Lisp Machine even runs it as an OS. I use LispWorks for development on my Mac - the IDE is the running Lisp system. > it's not the normal worflow to work entirely in the…

> That's not how Lisp works. Macros are not simple code generators, where the workflow would be write macro code, expand that, and use the expanded code.

You're putting words in my mouth, and yes macros are just code generators. I didn't imply or say they're expanded and then devs use the expanded code. The whole point of them is you're not supposed to think about or see the generated code, the macro becomes the abstraction the dev works with.

> In this case the Lisp developer sees the generated objects: the getter, setter slot definitions. What the Lisp developer usually does not look at is the code generated by the macros. There are many macros, where there are no generated objects and the resulting code is extremely complex and large. Thus it would not make sense at all to present this code or edit this code...

Exactly the point I was making. You're actually agreeing with me though the tone doesn't come off that way.

> Actually that's the default mode. If you develop Lisp code with SLIME / GNU Emacs, it talks to a live Lisp system.

I said multiple times Lisp "can" work that way, stop being so defensive. But the point in fact is most Lisp developers don't work that they, they don't live in the REPL full time like Smalltalk devs do, you load from source quite often in comparison to the 0 times Smalltalk'ers do.

Look this isn't a competition; Lisp is technically superior to Smalltalk in features both due to macros and due to CLOS and its multiple dispatch OO system. Lisp was the inspiration for Smalltalk, Alan Kay goes so far as to call eval/apply the Maxwell's equations of computer science. However, I any many others having tried both Lisp and Smalltalk, prefer Smalltalk largely due to the syntax and dev environment. Emacs and Slime just don't cut it for us. Generic functions don't feel like object orientation, the way Smalltalk does OO just feels better and the dev environment feels better than anything else out there.

Re: Lisp, Smalltalk, and the Power of Symmetry (2014)

#53

Post by big_spammer » Sun, May 14, 2017, 3:39 PM UTC

gnaritas wrote: post #52

lispm wrote: post #30

Earlier quoted context omitted.

> editing it manually You edit the source code via the IDE. Just like in Lisp systems. It's just that the IDE works differently. > Smalltalk'ers actually work on the running live image all of the time That's the dominant way to work in Lisp, too. My Lisp Machine even runs it as an OS. I use LispWorks for development on my Mac - the IDE is the running Lisp system. > it's not the normal worflow to work entirely in the…

> That's not how Lisp works. Macros are not simple code generators, where the workflow would be write macro code, expand that, and use the expanded code. You're putting words in my mouth, and yes macros are just code generators. I didn't imply or say they're expanded and then devs use the expanded code. The whole point of them is you're not supposed to think about or see the generated code, the macro becomes the abst…

On living in the REPL full time and having a better environment, is there something you wish Smalltalk could do to become a better environment that it doesn't?

What would feel better?

Re: Lisp, Smalltalk, and the Power of Symmetry (2014)

#54

Post by DonbunEf7 » Sun, May 14, 2017, 3:42 PM UTC

Denzel wrote: post #16

DonbunEf7 wrote: post #3

Indeed, homoiconicity is a very powerful thing. It doesn't have to be core to the nature of the language, though; as far as I know, any Turing-equivalent language readily admits a metacircular interpreter, and so really a homoiconic language is a language with a compiler in the standard library. As a thought experiment, imagine Lisp without macros. It's not hard; after all, "The Little Schemer" covers metacircular in…

No, this is incorrect. The syntax and the AST must be isomorphic for a language to be homoiconic. It's not enough to expose the compiler/AST as a first-class library. Wikipedia has a nice entry on this. In short, "homoiconicity is where a program's source code is written as a basic data structure that the programming language knows how to access." [1]: https://en.wikipedia.org/wiki/Homoiconicity

By "first-class", I really did mean "indistinguishable from the rest of the core of the language." Consider Monte:

    def x :Int := 42 # evaluated statement
    def ast := m`def x :Int := 42` # quasi-quoted Monte fragment
    eval(ast, safeScope) # easy evaluation

Now, it happens that m`` is a library written in Monte itself, but that's unsurprising when you consider how much of the Monte compiler is also self-hosting. Since Monte is a complex and rich language, the homoiconic representation is equally rich:

    def m`def @lhs := @rhs` := ast # pattern-matching!
    [lhs, rhs] # [mpatt`x :Int`, m`42`]

Re: Lisp, Smalltalk, and the Power of Symmetry (2014)

#55

Post by pron » Sun, May 14, 2017, 4:36 PM UTC

armitron wrote: post #50

pron wrote: post #44

Earlier quoted context omitted.

> has hinted, numerous times, that Java was a compromise. How does that make what I wrote completely wrong? Good design is a compromise. Gosling presented Java's design as a wolf in sheep's clothing. They figured that the features most important in Lisp and Smalltalk are memory safety, GC, dynamic linking and reflection, shoved all of them into the JVM, and wrapped them in a non-threatening language that could actual…

Well, unfortunately, the features most important in Lisp and Smalltalk are not memory safety, GC, dynamic linking and reflection. Which is one reason Java is a shitty language. It may be popular, "a blue collar language" but it's not sitting on some apex of programming languages, and it's certainly not Art. Which makes sense if you consider that the vast majority of programmers working today are not artists or crafts…

Well, that's your opinion. I'm not sure by what metrics you think languages should be ranked. There's certainly no evidence that any other language results in better software, or that linguistic features have a significant bottom-line impact at all. Whatever few studies we do have indicate that the coice of language makes little difference, certainly ehen it comes to large software. Of course, language designers and PL enthusiasts make all sorts of claims, but they're largely unsubstantiated at this point.

Re: Lisp, Smalltalk, and the Power of Symmetry (2014)

#56

Post by lispm » Sun, May 14, 2017, 4:37 PM UTC

gnaritas wrote: post #52

lispm wrote: post #30

Earlier quoted context omitted.

> editing it manually You edit the source code via the IDE. Just like in Lisp systems. It's just that the IDE works differently. > Smalltalk'ers actually work on the running live image all of the time That's the dominant way to work in Lisp, too. My Lisp Machine even runs it as an OS. I use LispWorks for development on my Mac - the IDE is the running Lisp system. > it's not the normal worflow to work entirely in the…

> That's not how Lisp works. Macros are not simple code generators, where the workflow would be write macro code, expand that, and use the expanded code. You're putting words in my mouth, and yes macros are just code generators. I didn't imply or say they're expanded and then devs use the expanded code. The whole point of them is you're not supposed to think about or see the generated code, the macro becomes the abst…

> I said multiple times Lisp "can" work that way, stop being so defensive. But the point in fact is most Lisp developers don't work that they, they don't live in the REPL full time like Smalltalk devs do, you load from source quite often in comparison to the 0 times Smalltalk'ers do.

That Lisp developers load source does not mean that the image gets restarted. Lisp usually is designed such that you can incrementally update/manipulate the running image. As I said that's the dominant development style for Lisp, AFAIK.

> the dev environment feels better than anything else out there.

That's what my friends who still use Symbolics Open Genera tell me all the time. ;-)

Re: Lisp, Smalltalk, and the Power of Symmetry (2014)

#57

Post by agumonkey » Sun, May 14, 2017, 7:54 PM UTC

I find symmetries a very necessary concept. It's a complexity divider. A bit like self similarity or inductive reasoning, it turns chaos into cosmos.

Re: Lisp, Smalltalk, and the Power of Symmetry (2014)

#58

Post by gnaritas » Sun, May 14, 2017, 8:55 PM UTC

big_spammer wrote: post #53

gnaritas wrote: post #52

Earlier quoted context omitted.

> That's not how Lisp works. Macros are not simple code generators, where the workflow would be write macro code, expand that, and use the expanded code. You're putting words in my mouth, and yes macros are just code generators. I didn't imply or say they're expanded and then devs use the expanded code. The whole point of them is you're not supposed to think about or see the generated code, the macro becomes the abst…

On living in the REPL full time and having a better environment, is there something you wish Smalltalk could do to become a better environment that it doesn't? What would feel better?

Yes, several, it's slightly too dependent on the mouse for focus; I'd rather never touch a mouse. I wish it used native windows (this is specific to Squeak/Pharo) so my editor felt like any other editor rather than a window within a window that it currently is (some other Smalltalk's do this but they're windows based and I'm on Linux). I wish the code browser had a back button so I could go dig into the source of something and then come back rather than popping a new browser to investigate that thing. Even better I'd like bookmarks like you get from more modern IDE's where you can mark a few key spots you want to constantly be jumping between rather than having a different browser open on each one.

Re: Lisp, Smalltalk, and the Power of Symmetry (2014)

#59

Post by coldtea » Sun, May 14, 2017, 11:20 PM UTC

saywatnow wrote: post #40

The thing about both Lisp and Smalltalk that keeps making me feel alienated is that their power seems much weaker beyond their kingdom. The outside world does not have an object browser, nor is it made of s-expressions. Tcl occupies a very nice place in this regard: its homoiconicity and symmetry (and late binding) come from text. The outside world, to a very close approximation, is also made of text. Subprocesses, s…

>The outside world does not have an object browser, nor is it made of s-expressions.

You'd be surprised.

Joking aside, you seem to fixate on an implementation detail. It's just that the computing world, or rather the Unix on, is "made of text".

The world is actually made of objects and data, and this is closer to Lisp and Smalltalk.

Re: Lisp, Smalltalk, and the Power of Symmetry (2014)

#60

Post by zimablue » Mon, May 15, 2017, 1:00 PM UTC

maemre wrote: post #35

pron wrote: post #33

Earlier quoted context omitted.

Right, but an important point here is "some highly dynamic language features make analysis really imprecise or really hard". Not all "late bindings" are born equal. JavaScript's dispatch is very different from Java's from a static analysis perspective, the latter being almost indistinguishable from pattern matching.

I totally agree with that. When I mentioned dynamic dispatch, I had something like Scheme or JavaScript in my mind. Dynamic dispatch in those languages require a more subtle analysis to obtain precise results. I wish I could edit my parent comment to clarify my example. To clarify my position (hence my parent comment's point) on this general matter, I'm OK with any language feature that is amenable to static analysis…

I think the standard counterargument is that if unit testing is ubiquitous, we're already admitting static analysis is at best very incomplete.