GOPHERSPACE.DE - P H O X Y
gophering on hngopher.com
HN Gopher Feed (2017-07-12) - page 1 of 10
 
___________________________________________________________________
Project Lamdu: A Live Programming Environment and Language
55 points by telekid
http://www.lamdu.org/
___________________________________________________________________
 
raymondgh - 32 minutes ago
It all sounds nice, especially considering that the expansion of
the code-literate demographic should eventually necessitate more
intuitive tools than the languages & environments we use today, but
it also seems intimidatingly different and severely under-
supported. Overall, I feel like I can confidently ignore this
project because it appears doomed to fail and/or ahead of its time.
 
kmicklas - 2 hours ago
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 at once, even with the most radical vision
and competence.
 
  teleclimber - 47 minutes ago
  A lot of these things are solved, or at least there is a
  tremendous amount of experience to draw from now. It's more a
  problem of packaging the different pieces together into a
  cohesive system.
 
  ModernMech - 44 minutes ago
  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 in single-
  threaded CPU improvements and moving to multi-thread and multi-
  cores, the imperative programming model began to rapidly show its
  limitations. After all, Von Neumann meant for his architecture to
  be a prototype, and we went ahead and built an entire industry on
  top of it.Leaving everything in the development ecosystem up to
  market forces has left us in a state that is entirely too
  complex. There is far too much accidental complexity in
  developing even the simplest applications today.If 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.
 
  zokier - 1 hours ago
  I think these kinds of projects are mostly "conceptual" rather
  than something that will straight up take over the world,
  providing inspiration for people writing those things that will
  actually get used. I feel like it is extremely important that
  this kind of work gets done, and I think people should also be
  more eager to actually try out and really use all sorts of novel
  systems.
 
eliribble - 18 minutes ago
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 can make incremental transformations to
languages to move in that direction.So far what I've considered is
this:1 - Automated formatting such as gofmt which eliminates any
decisions around whitespace to culture people towards treating code
as data rather than prose2 - Language-aware editors that constrain
user input to valid states based on 13 - Plugins for version
control systems to optionally do diffs on ASTs rather than plain
files4 - Compilers that can operate on ASTs instead of strings5 -
Checking in ASTs rather than strings based on 3 and 46 - Updating
editors 2 to operate on ASTs since 5 makes it reasonable to always
work on ASTs rather than text7 - Creating new styles of code
editors that visualize and manipulate ASTs in ways that are
independent of their text representationsThere's probably steps I'm
missing. I'm only just getting in to this space so I'm ignorant of
most research that has been done in this area.