Improved Means for Achieving Deteriorated Ends

Content tagged strangeloop

Strangeloop Thoughts, 2014 Edition

posted on 2014-09-24 16:05:00

Why do Programming?

After going to Strangeloop for the first time in 2012, I was really fired up about programming. I'd only been out of school a year and was already a full-remote Clojure developer making a great salary. Even better, I had made good progress on my lisp emulation project and received some recognition from hackers I respected for it.

The last two years Strangeloop has been a lot more sobering. I told myself things in 2012 about how fast I'd get better and how good I'd be. Even though my expectations were unreasonable it's taken a long time to not feel bad about my (relative lack of) progress. I've been slow to accept the fact that I don't want to fight my way to being the best in my field.

Strangeloop, 2014

I got in Tuesday night, dropped my bags at the hotel, and immediately ran off to drinks and phenomenal conversation at the Schlafly Tap Room. Many of the best experiences I've had at Strangeloop have been at the tap room. Sure there is excellent food, beer, and technical conversation, but I've always gotten a sense of personal acceptance at gatherings there. Strangeloop is certainly a welcoming crowd.

Wednesday was a blast as well, as any day with a trip to the STL City Museum should be, but more and more I found I cared about personal interactions more than the content of the talks I attended.

By the end of Thursday, I was stressed out. I wasn't even excited about the talks, which isn't to say they weren't good. I hated the idea that I was just an average programmer, that I didn't aspire to more than hacking bog-standard Rails apps as a career, that I'd spent almost $2000 out of my own pocket to come to a conference that someone else might have gotten more out of. I went to bed early that night.

I kept my mindset in check much better on Friday. I reminded myself to be excited about others discoveries and creations, not to demand myself learn every tool or technique. The conference wrapped up well and I particularly enjoyed some of the Distributed Systems talks, a subfield I still have no experience with. Not to say I want to go fight distributed heisenbugs soon or design highly reliable systems. The talks were quite entertaining and informative is all.

Back Home

The main takeaways I've had from Strangeloop have nothing to do with tech and everything to do with me. Strangeloop has, in many ways, been a time for me to reflect these last two years. I'm not sure that's a good way to use the conference but it seems to be what I've done.

The first takeaway that comes to mind is that I need to try and respect myself for just being a decent Rails developer. I'm not great at solving algorithmically tricky problems and my CS background is, frankly, pretty damn weak. But no matter what I shouldn't beat up on myself for being "just a programmer". I need to put in an honest day's work and actually pat myself on the back at the end of it.

The second takeaway is that I need to program for me again. I got into programming mostly because I wanted to know more about how computers work. The emulator and talks surrounding it, some of my favorite work, is really more an investigation than artifact. I still want to support coleslaw. It actually has a few satisfied users and I'm one of them. But the only real purpose of the emulator is to sate my curiosity. Not to become a real thing or be special or groundbreaking.

There is plenty I'm still digesting and plenty I'm still not sure of, both technically and in terms of what I want for myself, my career, my life. But I'll leave that for another day. Cheers.

Strangeloop 2014

posted on 2014-09-16 10:10:00

It's time for the best programming conference of the year, again!

I fly out to Strangeloop later today. Here are the talks I'm planning on attending:

Wednesday the 17th: Future of Programming Workshop/Emerging Languages Camp (all day)

Thursdsay the 18th:

Friday the 19th:

!! = Denotes time slots I'm uncertain about. Open to suggestions...

Strangeloop 2013 Schedule

posted on 2013-09-12 09:55:00

I can't believe Strangeloop is only a week away!

Thursday:

  • Machine Learning for Relevance and Serendipity - Jenny Finkel (keynote)
  • Fast and Dynamic - Maxime Chevalier-Boisvert
  • Graph Computing at Scale - Matthias Broecheler
  • The History of Women in Technology
  • Software for Programming Cells - Colin Gravill
  • Learnfun and Playfun - Tom Murphy VII
  • Linear Logic Programming - Chris Martens
  • Creative Machines - Joseph Wilk
  • Making Software Development Make Sense to Everyone - Jen Myers (keynote)

Friday:

  • The Trouble with Types - Martin Odersky (keynote)
  • Abstract Algebra Meets Analytics - Avi Bryant
  • Programming a 144-computer chip to minimize power - Chuck Moore
  • Web Apps in Clojure and Clojurescript with Pedestal - Brenton Ashworth
  • Getting Pushy - David Pollak || Why Ruby Isn't Slow - Alex Gaynor
  • Thinking DSLs for Massive Visualization - Leo Meyerovich
  • Finding a Way Out - Chris Granger || Servo - Jack Moffitt
  • What is a Strange Loop? - Douglas Hofstadter (keynote)
  • Thrown for a Loop - David Stutz

On Visible Programming

posted on 2012-09-26 20:13:00

I have a bad feeling that I'm about to piss off a lot of people. Oh, well.

Bret Victor gave a very interesting talk at Strange Loop called "Visible Programming". From what I can tell, Bret is a very smart guy and an accomplished UI designer. I was surprised to find that while I agreed with many (all?) of his premises I disagreed with most of his argumentation. As I've received a question or two about it, I'll try to clarify my thoughts here.

I have three core points:

  1. His vision requires reflection and an editor is the wrong place for it.
  2. Many examples were domain-specific and/or trivial but he didn't talk about general editor extensibility.
  3. Much he suggests is already done or can be done with some solid effort and available technology.

On Relective Systems

Ironically, I gave a talk on a different but overlapping topic a few weeks back. As mentioned in Chris Granger's talk, examples like the ones he and Bret Victor gave are much easier when working with a dynamic runtime. Unfortunately, dynamic is conventionally interpreted as a language with dynamic types and, put simply, we should try to change that. I argue that a dynamic language is one that allows you to inspect values and update function and class definitions while the program runs. This is formally known as reflection. What I believe dynamic language advocates care about is the ability to work with a "live" system, not the presence or lack of static type checking.

Being able to visualize program execution means having a snapshot of the program state during each step of execution. Setting aside the impractical size of such a thing for programs with arbitrarily large working data sets, this requires either A) annotating every line or function call with logging statements/function tracing, or B) instrumenting the language runtime in some fashion to retrieve values during execution. That's why these examples are much easier with a reflective language like Javascript where you can hook arbitrary behavior into the Object prototype.

Trying to get an editor to do this for all languages is a fool's errand without a nice reflective runtime and API to retrieve data from. It's hard enough with that stuff! And that means we need reflective compilers and interpreters before we can have an ideal editor.

On Editor Extensibility

Many of Bret's examples were highly domain specific. While it makes sense to have a simple interface for toying with values in a visualization/drawing program, it's harder to see how to usefully apply that to something like protein folding software or even RSS feed parsers. Having editor extensibility in addition to reflective systems enables arbitrary widgets or modes for dealing with a given problem domain or data visualization need. Plain and simple, there's no way to build-in useful visualizations that are universally applicable. I admit I am not a designer or gifted at visualization so I may have simply struggled here.

What can be done today

Bret essentially wants to make the experience of programming more tractable through interactivity and tangibility. He suggested 5 key requirements:

  1. Enable the programmer to read the vocabulary.
    • Mouseovers/tool-tips on all source tokens is largely available today and seems to address this.
  2. Enable the programmer to follow the flow.
    • A visualization to step through execution could be written somewhat easily given something like Common Lisp's trace.
  3. Enable the programmer to see the state.
    • This is essentially a more elaborate visualization that requires a bit more trace data than the above.
  4. Enable the programmer to create by reacting.
    • Suggests that editor not only autocompletes function names but default values too so you can see their effect immediately.
    • Function name autocompletion exists in many IDEs. Pervasive default values are easier for typed than "untyped" languages. Still requires runtime support!
  5. Enable the programmer to create by abstracting.
    • Essentially demonstrated a refactoring system here. Keep feeling like I missed something key about his argument.

TL;DR

While philosophically well-formed, Bret seems to miss the fact that runtime support is required for a Visible Editing Experience to emerge. If the industry still doesn't understand that dynamism is about the runtime rather than types, clamoring for a magic editor will get us nowhere. I want to see a more interactive, tangible environment in the future as well but we cannot get there by arguing that IDE/editor writers need to step up their game. We need to make a concerted argument for the resurrection of highly reflective systems in both research and industry. Once systems with robust reflective capabilities are widespread, realizing a vision such as that described will be a week long hack rather than a decade-long million man-hour slog.

I'd also like to examine how far reflection can scale and a bit about making such a thing applicable to both novices and experts but I need more time to compose my thoughts so I'll save that for a future post. Any comments on this post or its mistakes, of course, are welcome.

This blog covers 2015, Books, Butler, C, Dad, Discrete Math, Displays, Education, Erlang, Essay, Gaming, Gapingvoid, HTDP, Hardware, IP Law, LISP, Lecture, Lessig, Linkpost, Linux, Lists, MPAA, Milosz, Music, Neruda, Open Source, Operating Systems, Personal, Pics, Poetry, Programming, Programming Languages, Project Euler, Quotes, Reddit, SICP, Self-Learning, Uncategorized, Webcomic, XKCD, Xmas, \"Real World\", adulthood, apple, career, careers, choices, clones, coleslaw, consumption, creation, emulation, fqa, games, goals, haltandcatchfire, heroes, injustice, ironyard, linux, lisp, lists, math, melee, metapost, milosz, music, pandemic, personal, poetry, productivity, professional, programming, ragequit, recreation, reflection, research, rip, strangeloop, vacation, work, year-in-review

View content from 2024-09, 2024-06, 2024-03, 2024-01, 2023-12, 2023-07, 2023-02, 2022-12, 2022-06, 2022-04, 2022-03, 2022-01, 2021-12, 2021-08, 2021-03, 2020-04, 2020-02, 2020-01, 2018-08, 2018-07, 2017-09, 2017-07, 2015-09, 2015-05, 2015-03, 2015-02, 2015-01, 2014-11, 2014-09, 2014-07, 2014-05, 2014-01, 2013-10, 2013-09, 2013-07, 2013-06, 2013-05, 2013-04, 2013-03, 2013-01, 2012-12, 2012-10, 2012-09, 2012-08, 2012-06, 2012-05, 2012-04, 2012-03, 2012-01, 2011-10, 2011-09, 2011-08, 2011-07, 2011-06, 2011-05, 2011-04, 2011-02, 2011-01, 2010-11, 2010-10, 2010-09, 2010-08, 2010-07, 2010-05, 2010-04, 2010-03, 2010-02, 2010-01, 2009-12, 2009-11, 2009-10, 2009-09, 2009-08, 2009-07, 2009-06, 2009-05, 2009-04, 2009-03, 2009-02, 2009-01, 2008-12, 2008-11, 2008-10, 2008-09, 2008-08, 2008-07, 2008-06, 2008-05, 2008-04, 2008-03, 2008-02, 2008-01, 2007-12, 2007-11, 2007-10, 2007-09, 2007-08, 2007-07, 2007-06, 2007-05

Unless otherwise credited all material Creative Commons License by Brit Butler