Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jan 29 17:24
    userabuser starred cheery/lever
  • Dec 17 2018 08:59
    dkrikun starred cheery/lever
  • Nov 18 2018 17:44
    slikts starred cheery/lever
  • Nov 05 2018 09:18
    VedVid starred cheery/lever
  • Oct 21 2018 21:55
    oliviaguest starred cheery/lever
  • Oct 21 2018 21:05
    TrevorDev starred cheery/lever
  • Oct 07 2018 17:50
    schedutron starred cheery/lever
  • Sep 15 2018 12:10
    andrewchambers starred cheery/lever
  • Sep 05 2018 04:32
    scalarwaves starred cheery/lever
  • Aug 19 2018 21:49
    gr4yscale starred cheery/lever
  • Aug 18 2018 05:21
    nickolasburr starred cheery/lever
  • Aug 06 2018 22:28
    cahiggins starred cheery/lever
  • Aug 01 2018 04:57
    secondwtq starred cheery/lever
  • Jul 24 2018 19:27

    cheery on next

    soon it is time to study (compare)

  • Jul 24 2018 19:23

    cheery on next

    the new IR works well enough now (compare)

  • Jul 24 2018 19:21

    cheery on next

    scattered bugfixes analysis and… (compare)

  • Jul 23 2018 22:21

    cheery on next

    fixed bugs in sourceloc and cle… (compare)

  • Jul 22 2018 21:40

    cheery on next

    bootstrapper started to gunk up… (compare)

  • Jul 13 2018 09:30

    cheery on next

    adjusted pattern handling (compare)

  • Jul 13 2018 08:16

    cheery on next

    record objects (compare)

Henri Tuhola
@cheery
I haven't decided the final direction with Lever, but I think it'll be the language of multiple heaps and multiple compilers/translators/interpreters.
Chancy Kennedy
@chancyk
Separation of concerns definitely seems like a good objective for encouraging participation.. and really for sanity.
kind of where Python is shining lately... competing interpreters, separately maintained static type checker.
Granted, I feel like I'm constantly battling the desire to have total control vs delegation :P
Chancy Kennedy
@chancyk
Here's a somewhat unrelated question, what's your personal approach to gathering ideas and making notes for working on something as esoteric as language design? And what are your thoughts on writing code that's meant to be read and is well documented, a la literate programming? (I enjoyed your good code section. I wish it was easier to find similar analyses.)
Chancy Kennedy
@chancyk
Also, are you familiar with this work? http://www.cs.cmu.edu/~aldrich/wyvern/
Henri Tuhola
@cheery
I remember the name, but haven't read that page recently.
I keep stumbling across problems and ideas when I do programming.
That is the kind of main source of ideas, I write them down into worklist when I get them.
Or then I implement them straight away and see how it matters.
Then I also tend to explore interesting concepts in other languages and see if I can apply it into mine.
Henri Tuhola
@cheery
Finally, the incomplete language ends up presenting a question of how to get something done. Sometimes those things alone lead to good ideas.
Programming language is a tool. You can't test it by other than using it.
Henri Tuhola
@cheery
Worklists containing details on what's in my schedule, TODO message, holes in documentation, holes in the implementation help me determine what to do next.
Well-documented code means different things to different audiences. This is apparent especially with the code that computes hashes or programs relying on matrix or vector arithmetic.
But I'd say it is up to the person to learn what the code means.
I prefer documentation and code being separate, but hyperlinked.
Also I have the strategy that the code must come before the documentation.
And the documentation starts by explaining details of the code.
Going upwards until the things relevant to the user is documented well.
Henri Tuhola
@cheery
Without this order, there will be gaps that prevent the travel from the documentation into the code.
Although I prefer code and documentation separate, I think comments are still necessary.
If there are surprises in the code, that are surprises no matter what your general knowledge about the subject were.
They should be documented into the code into the comments.
Surprises such as variables that are not immediately used, or used from different files. Such that you can't be sure how it's used.
Overall the information about the data flow and structure in the program is important for understanding.
That has led to avoidance of OOP constructs, unless they have important role or a purpose.
Henri Tuhola
@cheery
In other hand you neither want to hide things in the libraries, although it is important to define what's stable behavior and what is allowed to change.
But it is still preferable to minimize the kind of dataflow that would have to be documented down, or then it should be done explicit.
Readable programs are bit like readable stories, where the computer is the actor.
it cannot be an audience, because it doesn't understand the story.
Henri Tuhola
@cheery
In the end we have contradictions everywhere.
For example, in a good system you leave decisions to late as possible, but it's in conflict with explicit data flow because explicit dataflow demands you from choosing carefully what you pass downwards into calls.
Chancy Kennedy
@chancyk
Thanks for taking the time to answer! I often get the sense that software is a very personal expression of an individuals understanding of the problem, versus it simply being a tool to be used, due to the complexity of programming in general.
Also, regarding documentation, I find the abstractions and metaphors the author uses to think about the problem often are not documented and one is left trying to infer them from the details of the program.
And you're forced to arrive at the same understanding by following a distinctly different path of knowledge. Maybe like trying to learn calculus before algebra? In that there's an unknown hierarchy of abstractions and you start trying to understand them at a random location.
Chancy Kennedy
@chancyk
I guess you could say that about learning anything, but software seems particularly resist ant to intuition and exploration.
Henri Tuhola
@cheery
I'm going to bring up font triangulation library into Lever today.
All the pieces are in place, I just need to organize it.
Henri Tuhola
@cheery
Switching on triangle instancing, and going to try some metrics so that I'll get legible text.
Chancy Kennedy
@chancyk
This is an interesting read: https://arxiv.org/pdf/1604.01290.pdf It discusses the implementation of the Dino language, which includes an Earley parser in its standard library. (Bumped into it reading about Marpa)
Henri Tuhola
@cheery
That is a younger paper than what Lever + parser is.
Henri Tuhola
@cheery
interesting, sort of.
Henri Tuhola
@cheery
@chancyk I have those two puzzles, but I have to write them somewhere for referencing them.
But in short: The first problem is, how do I make Lever better for live-programming?
The second problem is, is there a better way to associate documentation with the code?
The current model I am using is: have a documentation URL
when the module is done, I roll through the module names and annotate them with documentation reference.