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

Project Lamdu: A Live Programming Environment and Language

lamdu.org

Post reply on HN
Print view View original

11–16 of 16 posts

Re: Project Lamdu: A Live Programming Environment and Language

#11

Post by proc0 »

eliribble wrote: post #7

I think this project is great, but I tend to agree with others - it's going to be somewhat doomed by second-system effects and the fact that coding is a social art form. You have to get other developers to buy in to what you're doing to be successful. So what I wonder is this: is there a migration path instead? If the goal is to ultimately work on ASTs instead of treating software as a giant string, is there a way we…

I'm completely ignorant on this, but I'm wondering if there could be a strict superset of haskell or other pure functional language that is inherently visual. It seems this is what lambdu is, but it would definitely benefit the language to have it compile down to some readable functional code whenever needed.

Re: Project Lamdu: A Live Programming Environment and Language

#13

Post by lispm »

dTal wrote: post #10
eliribble wrote: post #7

I think this project is great, but I tend to agree with others - it's going to be somewhat doomed by second-system effects and the fact that coding is a social art form. You have to get other developers to buy in to what you're doing to be successful. So what I wonder is this: is there a migration path instead? If the goal is to ultimately work on ASTs instead of treating software as a giant string, is there a way we…

I think the closest thing to a migration path is the Racket programming language. When you get right down to it, "working on ASTs" basically means working in lisp. The idea is you have a canonical, external format for the AST; it might as well be s-expressions. The trouble is that lisp culture is highly resistant to any other syntax than raw s-expressions. They say things like "making alternate syntaxes is a rite of…

Lisp has various parser for language implementations. There is even a relatively complete Python implementation in Lisp.

Having Python syntax doesn't give you access to all the Python libs. Lot's of things need the Python runtime and also its support for non-Python extensions.

Literally hundreds of languages had been implemented on top of Lisp over the years. My Symbolics Lisp Machine had already in the 80s full C, ISO Pascal, Fortran, Ada and Prolog implementations written in Lisp. I was running on my Lisp Machine the original X11 server written in C and TeX written in Pascal...

Python is also not an alternative syntax on top of Racket or Lisp ... it's a different language.

Re: Project Lamdu: A Live Programming Environment and Language

#14

Post by nrtd »

eliribble wrote: post #7

I think this project is great, but I tend to agree with others - it's going to be somewhat doomed by second-system effects and the fact that coding is a social art form. You have to get other developers to buy in to what you're doing to be successful. So what I wonder is this: is there a migration path instead? If the goal is to ultimately work on ASTs instead of treating software as a giant string, is there a way we…

I think when speaking about languages we should speak more about the AST and their elements. When I see code I often find myself wondering about what parts of the text form a leaf. A part about this in the language introduction would help. This would be a point maybe between 1 and 2.

Re: Project Lamdu: A Live Programming Environment and Language

#15

Post by soegaard »

lispm wrote: post #13
dTal wrote: post #10

Earlier quoted context omitted.

I think the closest thing to a migration path is the Racket programming language. When you get right down to it, "working on ASTs" basically means working in lisp. The idea is you have a canonical, external format for the AST; it might as well be s-expressions. The trouble is that lisp culture is highly resistant to any other syntax than raw s-expressions. They say things like "making alternate syntaxes is a rite of…

Lisp has various parser for language implementations. There is even a relatively complete Python implementation in Lisp. Having Python syntax doesn't give you access to all the Python libs. Lot's of things need the Python runtime and also its support for non-Python extensions. Literally hundreds of languages had been implemented on top of Lisp over the years. My Symbolics Lisp Machine had already in the 80s full C, I…

Python On Racket: https://github.com/pedropramos/PyonR

Re: Project Lamdu: A Live Programming Environment and Language

#16

Post by kmicklas »

ModernMech wrote: post #5
kmicklas wrote: post #2

Lambdu, Unison, etc. are all great in principle but share the same fatal flaw: no layering. It's just one monolithic component trying to take on type systems, effect systems, syntax, version control, compiling, editing, distributed execution, etc. All of these problems taken decades just to get to the shitty everything-is-text/worse-is-better state we're in now. I'm skeptical that any single team can solve them all a…

Part of the reason we're in the shitty everything-is-text/worse-is-better state we're in now is because we haven't invested a lot of effort in the top-down design of systems that work really well. This is in contrast to the current state of development, which was driven by Moore's law and the rapid improvement of single-core processors to consist mostly of imperative programming. As soon as we started hitting a wall…

> we purposefully design smarter systems, maybe we can cut out layers out of the stack entirely, so worrying about things like distributed execution is a thing of the past for 99% of programmers.

Actually I disagree. If your layers represent conceptual abstractions, and not arbitrary divisions of your code stack leaking details from below, then _more_ layers is actually a good thing.

Post reply on HN