Maëlys McArdle

Category: Life

Every other post.

  • Vegan Cookie Dough Whoopie Pie

    Vegan Cookie Dough Whoopie Pie

    Chocolate Whoopie Pies (Original)

    • 1 2/3 Cup Flour
    • 2/3 Cup Cocoa Powder
    • 1 1/2 Tsp Baking Powder
    • 1 Tsp Salt
    • 1/2 Cup Vegan Butter (I used Earth Balance)
    • 1 Cup Light Brown Sugar
    • 1 Egg Substitute (I used a Flax Egg)
    • 2 Tsp Vanilla
    • 1 Cup Vegan Milk (I used Unsweetened Almond Milk)
    1. Preheat the oven to 375 F.
    2. If preparing a flax egg, grind 1 Tbsp of flax seeds. Put them in a small bowl and add 3 Tbsp of water. Mix them up and refrigerate for 15 minutes.
    3. Mix the flour, cocoa powder, baking powder and salt in a bowl.
    4. Cream the butter and brown sugar in a separate large bowl.
    5. Add egg substitute and vanilla and keep mixing.
    6. Pour half the dry ingredients and half the milk into the wet ingredients bowl. Mix.
    7. Repeat with the other half.
    8. Drop a rounded table spoon onto your baking sheets.
    9. Bake for 8 minutes.
    10. Let cool.

    Chocolate Chip Cookie Dough Filling (Original)

    • 1/2 Cup Vegan Butter (I used Earth Balance)
    • 1/2 Cup Light Brown Sugar
    • 1/4 Cup White Sugar
    • 3 Tbsp Vegan Milk (I used Unsweetened Almond Milk)
    • 1 Tsp Vanilla
    • 1 Cup Flour
    • 1/2 Cup Mini Chocolate Chips (Make sure there’s no milk products)
    1. Cream butter and sugars.
    2. Add vanilla and milk. Mix until uniform.
    3. Fold in chocolate chips.
    4. Spoon on cooled whoopie pies to make sandwiches.

    IMG_20131014_150801

    Notes

    So I wanted to bake for a support group tonight, but all the stores are closed. My fridge was purposefully empty because I had been on a trip for the last few days. I did however have butter and almond milk, as well as some chocolate chips left over from a previous project. I found a recipe that could work with that and off I went.

    The whoopie pie sandwich part was actually pretty devoid of taste. It was the filling that made it good. Otherwise very rich – probably too much so for me to make it again.

  • What’s been going on (or why I’m transitioning)

    What’s been going on (or why I’m transitioning)

    This blog is part of my public identity, and therefore I exhibit a fair amount of care in terms of what I divulge. One consequence of this approach is that I have very little insight into my past internal emotional state despite ten years of blogging.

    In an effort to have some record of this tumultuous period, I’m going to talk about what’s going on with me. I said in July that I was taking the steps to transition. That followed an earlier post in March where I noted that something was up gender-wise.

    I’m still getting assessed for hormone replacement therapy. I had my fifth of six appointments at a community clinic this week. I should probably start on HRT come January.

    Since my last update, I changed my name to Maëlys. It popped out at me when I was looking at popular French girl names. I hadn’t wanted to use variations from my birth name because I associated them with specific people. I liked that Maëlys was uncommon, that the first letter was in keeping with the names of my two other sisters, and that part of it was also an homage to a good friend.

    Despite these traits I still wasn’t too sure about it at first, but as I’ve been using it more and more it’s come to feel right. My pronouns have also changed and are now she/her.

    On that note, I was given this card the other day to honour the name/pronoun change. The friend wrote inside that there needed to be Hallmark cards for these milestones. It was a really kind gesture.

    IMG_20131009_172320

    Transitioning wise, I was going to talk about when I started to shave my legs this summer, but actually it goes a fair bit further back. It wasn’t entirely with that awareness.

    There are signs that go back to when I was 18 but on their own they were pretty inconsequential. Then in 2010/2011 things started to get more serious, in particular around sex and my bottom bits. It got to be that sex was really painful for me, but again I let it go.

    It wasn’t until the early months of 2012 that I started to make an effort to hide my secondary sex characteristics whenever taking pictures of myself. I’d tuck, make sure I was shaved and take photos from angles that would seemingly round my face. I wasn’t able to verbalize it, but the masculinity I was seeing was a real problem. Even though I never admitted it, I loved it whenever someone mistook me for transitioning the other way. That happened a fair bit because I was posting selfies to a queer-friendly social media platform and it meant that maybe one day I could be mistaken for another sex.

    That’s also about when I got my first strap-on from a vendor at Sexapalooza. I couldn’t enjoy sex with my own parts anymore; initially because of the pain and then because whenever I saw it as the male appendage it just completely killed it for me. A strap-on changed the game. It was cheap mainstream sex shop crap designed for impotent men, but that didn’t matter.

    I knew that if I could make a wish and wake up in a girl’s body, I totally would. I knew that even sexist 18 year old me would have too after coming to terms with my internalized misogyny. I dreamed of being able to trade my body with someone of the other sex. But that wasn’t my world, so I just kept going on.

    Come summer 2012, I got my first RodeOH harness. It felt so validating. I kept getting confused for a trans guy. I bought my first binder in the spring of 2013. It suggested I had a chest to hide, and that message was affirming the body I was seeing in the mirror. By this point I knew I needed to quench this disconnect with my body.

    At first, that was in the form of seeking bottom surgery. Really I could live on as a guy, I just needed to fix what was down there. If I contemplated hormone replacement therapy, it was just to follow the narrative to access surgery.

    Outwardly transitioning wasn’t really an option I thought. I had no hopes that I could live on as stealth and that was really discouraging. I feared rejection. Meanwhile, all the trans women I was aware of seemed to be very feminine, which further made me feel isolated as that wasn’t my path. Genderqueer was more apt but that seemed to only to mean female-assigned-at-birth. I felt like I didn’t really belong anywhere.

    I kept thinking more on transitioning, and I realized that no – actually I wanted what the hormones would bring me. Belonging be damned. Bottom surgery started to get less important. I reflected much in this period. I realized that despite all these fears of going at it alone and forever being ostracized in a deeply transphobic society, that it was better than the alternative.

    A big driver was looking at year old photos and realize that I was masculinizing at a fast pace, and that soon I would look like what men do in their thirties. I felt that any shot of inhabiting the body I desired was dropping rapidly. I felt that it was time to get the ball rolling.

    I consulted friends on how I could start HRT given that I didn’t feel like I could out myself to my GP. Fortunately, a local clinic was starting a program to offer free assessments for hormone replacement therapy. I called them and after a while was able to see someone.

    Those assessments started in the summer of 2013. I wasn’t in love with the idea of transitioning but I was doing an enormous amount of processing. The pause and simultaneous feeling of progress with the assessments helped in this regard.

    By that point I felt like I was suffocating. I was going through this difficult period, for which talking would have helped immensely, but I couldn’t do that except in great confidence with a few friends. The mediums that I was using to express myself, like this blog and Facebook, were becoming jails. I couldn’t say anything otherwise risk compromising my relationship with my family and my work situation. Suppressing myself on every platform, however, was taking a toll.

    So I started to make spaces where I could be free. I deleted my Facebook account, creating a new profile where I only friended those that would respect me regardless of my identity. I came out on this blog and to those in my life I could trust.

    Outside of that, the transition kept progressing. I went out with a friend and picked up my first sports bra. I was too scared to go alone. It’s difficult to convey how liberating and good it felt to finally wear it. That was an important moment. I soon bought my first sports bra on my own.

    Weeks before Pride, that friend and I went to Value Village where I picked up two skirts. I wore that skirt for the first time outside a week before Pride. I was so afraid before then that I would be destroyed by comments from judgy passerbys. I had witnessed such homophobic and transphobic vitriol over the years in Ottawa. But at the same time, I needed to do this for me. So I femmed up and walked outside.

    I did get inappropriate comments. But I didn’t care – because what I noticed as I walked down the street is that virtually no one so much as gazed in my direction. That lack of attention was in itself so affirming that when someone finally did say something nasty, I just didn’t give a shit.

    Pride came, and I wore that skirt again. I felt so real.

    Two days later, I announced that my name had changed to Maëlys.

    By then I was wearing and stuffing sports bras every day including to work. Not wearing one made it as if all the air in the world outside my apartment’s door were as heavy as molasses. I still dressed in a masculine fashion, which was in line with my gender expression.

    I nonetheless did like to occasionally femme up. That said, wearing skirts started to make me feel very uncomfortable about my hairy legs. I wanted those hairs gone but I was scared to shave because I thought people at work would notice. I was afraid of what would happen if they did.

    But at one point it became too much. So I shaved. The second I was done, it felt so right. All those fears about work just melted away. A few weeks later, I went through the same thing with my arms. Same anxieties, just as quickly vanished once done. As it turns out, no one at work said a thing.

    Meanwhile, my processing started to bear fruit. I continued to have reservations about starting hormone replacement therapy. The question became should I move ahead while having these doubts.

    I came to conclude that the answer was yes. I recognized that those doubts would persist for as long as the dissociation with my gender continued, which could be the rest of my life. Hormone replacement therapy would bring me a resolution.

    There was also reassurances in thinking of what if I was wrong. If I did this and was wrong, I could just stop and things would be more or less reversible. I would have many months to evaluate the slow changes and see if I liked what I saw. However, if I didn’t do this and was wrong, I’d be in real trouble. I would have squandered my one chance to do this as young as I did, and by then I’m not sure I could stand myself. I can barely do it now. I don’t know if I could carry on.

    If it turned out that this reversal of feelings came in ten, twenty years – then I would of had all these years of good life that I made happen. That’s an excellent thing to be able to claim and I can deal with whatever steps I need to then.

    The sense of victory in terms of my bra and shaving did lead me to believe I’d likely feel pretty good about HRT too. Doing these things had been like weights lifted off of my shoulder that I never knew had been there until they finally came off. Now being cognizant of the relief in their absence, I could never go back. There was also a pretty good track record with the transition of others, though I never felt like I quite matched up to their exhibited resolve.

    Then finally, there was how I felt about regret. Which is to say that it isn’t the things I do that I regret but rather the things I didn’t do because I was afraid. Regret doesn’t belong with the outcome but rather somewhere much before that point. For me, that was a discussion spanning months on how I could transform this very unhappy set of years in terms of my body into something good. That I won’t regret nor the decision it led to.

    I started to gain some confidence with my newfound identity. A part of that was being able to have friends that didn’t bat an eye at treating me like a girl, and sharing intimacy with people that respected my body as feminine. So much of my lack of confidence had been rooted in the poisoned depiction of trans women in mainstream society – from being treated as threats in the washroom by this country’s elected officials, to openly derided in television and games, to desired in a creepy objectified way as “shemales” by straight men. In all of these cases, we are no more than genitals to them, as if to say that that’s all a woman is.

    It also helped that I finally found role models that made me feel less alone in my approach. There was a talk by butch trans women at a conference that was absolutely affirming for me. There were people in the local queer community that showed that having side burns didn’t mean you were disqualified from being she’d.

    That confidence led to me being able to finally change my gender marker on a dating site. It also led me to being able to hold up my own in the face of disapproving parents and not be affected by ignorant messages like that below:

    Untitled

    So there you have it. My name is Maëlys. I’m 28 years old, queer, and go by the pronouns she/her. Pleased to meet you.

    Note: Even though this site is public, please don’t disclose what I’m doing to others. Allow me to decide for myself when I’ll disclose to those who don’t read this blog. I’m sharing this because I hope that it being out there as yet another narrative might help someone else feel a little less alone.

  • Vegan Lemon Pies Inside of Apples

    Vegan Lemon Pies Inside of Apples

    So I came up with two ideas for desserts the other day, and this was one of them. I’m happy to report that it worked out!

    Vegan Lemon Pies Inside of Apples

    This makes four lemon pies.

    Ingredients (Original Recipe)

    • 4 Apples (I used Fuji)
    • 2 Lemons
    • 3/4 Cup Water
    • 1/2 Cup Sugar
    • 3 Tbsp Corn Starch
    • 1 Tbsp Flour
    • 1 Tbsp Vegan Butter (eg. Earth Balance)
    • Pinch Salt
    • Icing Sugar to Drizzle

    Directions

    1. Juice one of the lemons.
    2. Cut the top off of the apples, and carve out their insides to create a hollow shell. Each time you finish with one of the apples, coat its insides with lemon juice. This will prevent it from browning.IMG_20130929_153733
    3. Optional: I put the apple carvings in a separate container, to use for a later day. When I was done preparing all the apples, I dumped the rest of the lemon juice in the container with those carvings and shook it up before placing it in the fridge.
    4. Juice the second lemon.
    5. In a small sauce pan, mix the sugar, corn starch, flour and salt. Stir in the water and lemon juice. Make sure there are no clumps.IMG_20130929_154557
    6. Bring the sauce pan to a boil. Stir frequently.
    7. Add the butter.
    8. Stir constantly until the mixture thickens.IMG_20130929_155340
    9. Take the sauce pan off the heat, and pour the contents into the four apples.IMG_20130929_155725
    10. Drizzle with icing sugar.IMG_20130929_162430

    My Thoughts

    This dessert took no time at all to put together, and in terms of calories you’re looking at quite a reasonable amount – definitively below the 200 calories per apple mark. It tasted fine, but I felt like it needed something else beyond the apple and lemon filling. Perhaps it would have been better served by a crumb topping or whipped cream rather than the icing sugar drizzle.

  • Visual Programming Language, Take Three

    Over the last year, I’ve written two pieces reflecting my thoughts on the programming language I’d like to see. This third piece reflects my evolving views on how I’d approach it.

    Why This Visual Programming Language

    There’s no shortage of excellent programming languages out there, and there’s no point to adding another one to the mix if it doesn’t add anything. To that end, there are some short-comings that I’ve encountered that this fictitious language would address.

    Existing Languages Are Inaccessible

    Lots of people today use tools like Excel or Access without even thinking about it. We’re talking about specialized programs that through intuitive design put very complex operations at the disposal of a user. It enables people to do things that were previously the domain of experts.

    Excel hasn’t displaced the need for statisticians and graphic artists, but it has empowered users to capture some of their domain for their own work. Programming languages don’t have a widely accepted analogue. For kids, you have cool application-specific projects like Lego Mindstorms  and Alice, but there’s nothing really quite as accessible for general purpose use.

    This fictional language seeks to address that gap. To make programming as accessible and as painless as any modern spreadsheet program. This is why it’s visual, to avoid reliance on memorization and to provide an intuitive graphical cues. So when I say existing languages are inaccessible, I don’t mean to those that have a personal interest in programming. I mean to those that don’t have an interest but would benefit from its use were it easy enough.

    Modern Computers Discourage Writing

    Computer usage has shifted from mainframes, to minicomputers, to microcomputers, to tablets and smartphones. Programming languages are rooted in having access to a keyboard, but that’s no longer true with many computers in use today.

    This language caters to those new platforms by greatly reducing how much text needs to be inserted to dictate logic. Instead, it’s very much grounded in having a pointer or touch screen.

    Getting The Big Picture

    A big part of my time as a programmer is devoted to maintaining software. When I do that, most of my time isn’t actually spent writing new code. It’s spent looking through thousands of lines of jargon to understand what’s already there.

    Programmers can structure their code to ease that burden, but many do not. That results in loads of wasted effort for whoever inherits that code. Programming languages can go some way into enforcing a structure, like Python’s use of indentation to define code blocks. I believe that a visual programming language could further enforce clarity by way of a flow chart representation.

    The trick then is to keep the flow chart simple, and unencumbered by details irrelevant to the scope you’re interested in. This is where this fictitious language would distinguish itself from existing visual programming languages, such as LabView’s G. It would do so by using a tile-based environment, by making use of an infinite canvas with stepped zoom levels, by having the presentation of connectors take a page from the likes of SimCity’s roads, by automatically hiding details irrelevant to the presented scope.

    Concurrency Should Be A Language Feature

    All of the programs you’re running on your computer right now are doing more than one thing at the same time. Yet none of the big programming languages today have support for running many things at once built-in, Google’s Go aside. Instead, you have to invoke libraries and do a whole bunch of legwork.

    We’ve reached a point where this micro-management should be invisible for those using a high-level programming language. A flow chart based programming language makes that implicit. Any set of interconnected blocks can run in its own lightweight thread. Channels can be the connections between these sets of blocks. Any split, where the output of one block goes into two separate blocks, could launch new lightweight threads. Wait conditions are where the output from two separate threads are likewise coerced back into a single block. You get the idea.

    Don’t Forget Existing Languages

    I think that a short-coming of existing visual programming languages is that it’s seen as all or nothing. It either has to be all visual, or it’s all text. Yet there are things for which presenting everything as a series of visual elements impedes clarity.

    For instance, I once saw an undecipherable diagram in LabView’s G, that was more or less just a few multiplications. A single line of Python would have been far less opaque. I think there has to be a place for a text-based programming language in a visual environment.

    The blocks in this fictitious language would therefore be made up of more blocks, or the code of a text-based programming language. That brings me to the next distinguishing characteristic of this made-up language.

    Piggy Back on Success

    A programming language is only as good as the libraries written for it. That’s a big reason why I suspect Python has been such a success in the research domain over Ruby and why C++ is still favoured despite the rise of Go.

    That also speaks to a problem with many fancy new programming languages. It’s all great to have easily understood code, but if there’s nothing for that code to do, then it’s not much use beyond a learning exercise.

    Thus not only is it important for this fictitious language to have a text-based programming language to back it (see previous point), but it has to be one that’s well supported. To that end, this project would be built around Python. Each of the visual elements on screen would in fact correspond to a Python object, and it would be Python objects that’s passed around by the connectors.

    This also has the effect of reducing how much work has to be done to make this language useful, because implementing a standard library is no longer a requirement. Instead, Python’s existing libraries can be used, and wrappers around them can be added over time.

    High-Level Standard Library

    Computers do so much more now than they used to, yet today’s programming languages are still rooted in a period where the most complicated thing someone did was read files and talk to a device. There’s some good reasons for that, like retaining a standard library that can be fully implemented irrespective of target.

    However, this language is for a use case where the user just wants to play a sound without having to figure out the logistics of how to make that happen. It’s a language for people who just want to pull data from a web page. That’s at a far higher level than current standard libraries, and this programming language should  facilitate that.

    However, this is an unachievable goal – since computers do so much more, so much more code is required to let them do that. So you have to pick and choose. Perhaps taking cues from what the Qt and Python folks have implemented in their respective libraries would be a good starting point. That and looking at the now defunct Yahoo Pipes and the Tasker mobile app. The end goal nonetheless is to reduce modern activities to a handful of blocks chained together in the IDE. Like automatically uploading GPS coordinates to Twitter.

    Implementation Concepts

    In the last section I talked about what needs were unmet that this visual programming language would address. In this section, I’ll cover how a bit about the internals.

    Blocks And Connectors

    The basic visual experience for the programmer would be to grab blocks from a pool, and to connect them together to define how the application would behave. Like a flow chart. So one block might be to read a file, which would output the contents of that file. That would then be chained to a block that parses the contents of that file and spits out text, etc.

    There could be many independent sets of blocks visible, which would execute concurrently. When the last block would execute, the program would exit. Blocks could have multiple connectors in, the equivalent of multiple function arguments, and would only execute once all of the input connectors would have furnished a value.

    Tile-Based

    The IDE for this language would be tile based, with a block taking up a full tile. The connectors would also consume a tile, though you could have multiple connectors sharing a tile. This is to prevent messy diagrams that inhibit clarity when things are all at random offsets from each other.

    Blocks Are Monochrome Symbols On Top Of A Base User-Defined Colour

    The blocks show up in a tile as having a background, which defaults to a given colour but can be changed to anything the programmer wants. On top is a symbol that represents the functionality of the block, so like a plus symbol for a block that adds numbers. This symbol would be monochromatic, and would change colours automatically to contrast that of the user-chosen background.

    The purpose of letting the programmer change the background colour is so that they can group blocks visually according to some logic that makes sense to them.

    Zooming Into Blocks

    Blocks can be made up of more blocks. The programmer can group blocks together this way to simplify their diagram. That way, the entire logic flow of the program doesn’t have to exposed at once. The programmer can have a few blocks representing the general functioning at a high level, and can drill down to blocks to expose more specific logic.

    In the IDE, the blocks and connectors are laid out in an infinite canvas. The blocks would appear as tiles. You could then zoom into a block, which would expand from being a tile to taking up the entire screen. The contents would then either be code, or more tiles.

    There is only one zoom level, in the sense that the tiles would always be the same size when presented to the user. But you could zoom into or out of levels of tiles an infinite amount.

    Blocks are Saved As Files

    Blocks, irrespective of whether they are made up of code or other blocks, are stored to a file. So each programmer-defined block in a project would be saved to a separate file. Which means that the main program itself is a block too.

    This would be seamless in the IDE. The data from all these disparate files would be loaded at once, and saved accordingly, so that the programmer would just be able to zoom into any block and do edits without having to concern themselves about files.

    If the programmer chose to do so, they could save the contents of a given user-defined block to a named file. Otherwise, these would be considered unnamed files, meaning that the IDE would choose a name for it. Doing it this way means that blocks could be imported into other projects and re-used.

    Python

    Python is at the core of this fictitious language. For the programmer, they’re chaining together blocks to define the behaviour of their application. These blocks are either made up of other blocks or Python code. Which means that all the blocks are actually just Python code at their root.

    This language would have a run-time entirely written in Python that would itself run in the Python interpreter. The reason for this run-time is to handle the event loop, the passing of objects between blocks, handling malformed code, launching and managing threads, and also to provide real-time debugging facilities for the IDE.

    Connectors as Roads

    As the language of implementation is Python, the connectors between blocks would be passing Python objects. The connector would look like a road or thick wire, the representation of which would change depending on whether the object was a Python NoneType (very thin road), an iterable/generator (multiple roads together), or any other object (regular road.)

    The presentation of the roads would take a page from SimCity. Crossing ‘roads’ would have one form a little bridge over another, ‘roads’ could be side-by-side, etc.

    Blocks can Output Multiple Times

    When a block is executed in this fictitious language, it doesn’t have to output just the once. If the block is an iterable/generator, it will output many times as it iterates through. A progress bar overlaying the block will indicate how far it’s progressing through the iterable.

    Or if the block represents some I/O interface, it can output many times corresponding to the related input.

    Event Driven

    Needless to say, the language is event driven. Blocks are called when its input requirements, which may be asynchronous, are fulfilled. Likewise, blocks are triggered on I/O, such as a GUI event or incoming network packet.

    Block Inputs / Output Specifics Hidden

    The IDE presents blocks as having connectors going in and out. There is no labels to these connections to the block. Hovering over the block with a mouse blows it up in the IDE, such that the inputs and outputs are all shown and labeled. The user can then use their pointer to modify the arrangement of connectors or create a new one.

    Constants Are Hidden

    Constants that serve as inputs to blocks are only indicated as a little bump that comes out of a block where a connector would be. Blowing up the block would reveal what constant is there as a block input. Constants can be created and modified in the same way as connectors are handled.

    Minimum Information Displayed

    The idea is that you want the IDE to display the least amount of information. This is why there are multiple levels of blocks (in addition to code re-use), this is why blocks don’t show labels, this is why constants are hidden until explicitly queried. Simplicity is key.

    That simplicity is also why the IDE tiles blocks and connectors are also tiled. This enforces a granularity in the presentation and leaves more control to the IDE to naturally simplify the ‘flow chart’, rather than leaving it up to the user. Let the user handle the logic, and the program enforce presentation.

    Documentation

    Visual elements assisting in documenting the blocks and connectors can be added to the code. These are in the form of strings that can be associated with any block, connector, or groups of the above.

    The IDE handles its presentation. A second visual layer can be invoked, in which groups are treated as territories on the world map that is the program, with clearly defined borders. This map is faintly visible regularly and come into view depending on where the pointer is situated.

    Flow Control

    Flow handling in this fictitious visual language are handled the same as any block. Nothing stops a user from defining a block with multiple inputs that would act as an if statement, for loop, etc. You can loop by having the output of one block be the input to a block further back in the chain.

    For clarity, However, a magic function is set in these Python objects that identifies their role in flow handling, and alters their appearance.

    Animated

    When running code in the IDE, the presentation would be animated. Blocks would go from partially transparent to opaque when called, connectors would animate showing data passing through, etc. The type of connector animation would reflect the data (eg. NoneType, iterator, or any other object.) Deleting a block would show an animation with its attached connectors also disappearing.

    This seems so shallow, but having this emphasis on almost video-game like presentation makes the whole thing much more easily to mentally parse than to default to very utilitarian designs. This is especially key with programming newcomers.

    Touch Is The Future

    The IDE would need to be functional with a finger as it is a mouse. The future is going to the finger as an input device. While serious programmers may always use a text-based programming language and a pointer device, we have to envision a world where there are programmers that do their work on a tablet. That do their work in a purely graphical environment.

    This fictitious language doesn’t need to be used for systems design. But the visual format lends itself well to touch. Hold your finger down (or mouse button) to pop up a radial menu with blocks, which can then be dragged to the appropriate tile. Likewise for dragging connectors. It’s there.

    Slow Motion and Debugging

    For debugging, the run-time would allow users to set breakpoints and put probes at any connector. The run-time could also put delays at each connector, creating the illusion of slow-motion and displaying where data is being passed around. This would facilitate debugging.

    Branched Time Machine

    The IDE would create a time line of the changes made by the user, which could be invoked by the user. The “time” is not based on real-world time, but relative to the changesets. The programmer could then rewind or go back to any past state, and start making changes from there. This would create a new branch in the timeline.

    There are no explicit commits, every change is tracked. The user could switch back to other branches by clicking their visual representation in the IDE. I don’t know how I would go about  multi-user content revisioning and merging independent work.

    Block Limit

    The IDE would have a block limit and produce a warning when it was exceeded. Perhaps 32 blocks, though each block can be made up of an infinite number of sub-blocks (all with that same limit.) This is going back to the idea of enforcing structure. It would force developers to componentize associated blocks, making the overall structure simpler.

    GUI Driven Development

    Ask a non-programmer to design an application on a sheet of paper. What you’ll often get is that they start drawing the GUI, and then note things like “when they press this button, the program does X.”

    That’s probably the reverse of how most programmers think, yet it’s the most intuitive way for non-professionals. That should be captured. Ideally, if the fictional IDE for this language ever took off, you’d be able to design your GUI first without needed to put any code down.

    GUI elements would appear as blocks in the flow chart to which inputs and outputs could wired. This is similar to LabView. However, there would only be a single window for both GUI and logic, separated instead by layers. Switching from the GUI layer to the logic layer would cause the UI elements to blow out and turn into blocks.

    Summary

    So to summarize, the language I envision is a general-purpose visual programming language. Its graphical representation is intended to make it accessible to non-programmers and lessen the dependence on programmers to make clean code. The interpreter would be no more than a run-time written in Python running Python code, so that the language could interface with Python code as easily as visual elements. There would be a focus on making the IDE as usable on touch-screen devices as those equipped with a mouse and keyboard.

  • Vegan Apple Pies Inside of Apples

    Vegan Apple Pies Inside of Apples

    I once saw a really cool recipe for baking apple pies inside of apples. I thought it was really cool, but the recipes called for baking the whole apple which made them soggy. I didn’t much care for that, or lining the whole thing with a calorie-rich crust, so I came up with a variant. There was three of us in the kitchen making this, and it worked out!

    Vegan Apple Pies Inside of Apples

    This makes four apple pies.

    Crumb Topping (Original Recipe)

    • 1/3 Cup Brown Sugar
    • 1/3 Cup Flour
    • 2 Tbsp + 2 Tsp Vegan Butter (eg. Earth Balance)

    Apple Pies (Original Recipe)

    • 4 Large Apples (we used Fuji)
    • 1/2 Lemon
    • 1/2 Cup Sugar
    • 3 Tsp Cinnamon
    • 1/4 Cup Vegan Butter

    Maple Cream Cheese Glaze (Original Recipe)

    • 1/2 Cup Icing Sugar
    • 1 Tbsp Vegan Butter
    • 1 Tbsp Vegan Cream Cheese (eg. Tofutti)
    • 1 Tbsp Maple Syrup
    1. Set the oven to 350 F.
    2. Mix the crumb topping ingredients in a bowl until it becomes crumb-like.IMG_20130921_122638 IMG_20130921_122910
    3. Spread mixture on a baking sheet with a silicone lining or parchment paper.
    4. Bake for 10-15 minutes.
    5. While the crumb topping bakes, you can prepare the apples. Squeeze the juice from the lemon in a glass.
    6. In a large bowl, mix the sugar and cinnamon for the apple pies.
    7. Cut the top off of the apples, and scoop out the insides into that bowl with the sugar. Using a melon baller is handy for this.IMG_20130921_123332 IMG_20130921_123827
    8. When you’re done scooping out the insides of the apple, rim its insides with the lemon juice. This will prevent the apple from browning while it sits.
    9. Mix the apples with the sugar in the bowl.IMG_20130921_124207
    10. Pour into a pan on the stove top. Add the vegan butter. Set the heat to medium.IMG_20130921_125204
    11. Use a fork to gauge whether the apple pie filling is ready. When tender, turn off the heat. This may take 40 minutes.
    12. While the apple pie filling cools, prepare the maple glaze. Mix all of those ingredients in a small bowl.IMG_20130921_125420
    13. Pour the apple pie filling inside the apples. Cover with the crumb topping, and then spoon the glaze on top.IMG_20130921_135422 IMG_20130921_135520 IMG_20130921_135727
    14. Enjoy!IMG_20130921_135915 IMG_20130921_140315

    Remarks

    This was tasty! The crumb topping kind of became a gigantic cookie upon pulling out of the oven. After employing different strategies to break it up, it turned out that using our fingers was best.

    IMG_20130921_125159 IMG_20130921_130216

    Going forward, I think I might try a different pre-baked crumb topping recipe. Perhaps one that has oats?

    What I really like about this recipe is how the crisp uncooked apples make for a really good crust substitute. This thing was borderline healthy!