ENTRIES TAGGED "learning"
CSS already making Web code more approachable
Last week, I wrote about the need to make programming, at least much programming, more accessible. I was thinking in terms of business processes, so spreadsheets and flow-based programming sprang to mind. Today, though, Jeremy Keith reminds me that on the Web, we already have much of that world in Cascading Style Sheets (CSS).
There are a lot of really powerful programmatic concepts that we could add to CSS, all of which would certainly make it a more powerful language. But I think that power would come at an expense.
Right now, CSS is a relatively-straightforward language.
I suspect some readers are scratching their heads, wondering why CSS is even being considered a language, much less why adding programming features to it would be a bad thing. If you think of CSS as a simple object-manipulation language, though, it fits pretty neatly into the sweet spot I described last week.
Teaching Future Coders
Ever since PyCon 2013, the interest in the Young Coders class has been intensifying. Practically every Python conference since then has asked about doing one, and several have run their own. Classes outside of conferences have sprung up, as well, from one time workshops to after school clubs.
As more classes happen, more people have been asking about running their own. These classes do take quite a bit of effort to set up, but the payoff is enormous. Also, once you do one, doing subsequent ones gets easier and easier.
A few iterations make even functional programming digestible
Programming gets easier and easier as you do more of it. Languages and logic become familiar, in ways that extend from looking up less and less all the way to muscle memory in your typing. The first few iterations in a new language are often difficult, as everything seems odd. Shifting not just to new languages but to new approaches makes practice even more important.
One of my worst features has been that I never liked to practice. I understood rehearsing, working together in a group, but practicing? Exercises, especially for the sake of exercise, were never my thing. That character flaw has hobbled my writing. I can come up with examples for books, focusing tightly on an issue I’m explaining. But then, really? I have to ask readers to go solve a particular (already solved) problem?
I’m not alone in this—too many writers have inflicted that attitude on their readers. Exploring sample code is not the same as writing your own code. Miguel de Icaza points out that:
When you finish a chapter in a modern computing book, there are no exercises to try. When you finish it, your choices are to either take a break by checking some blogs or keep marching in a quest to collect more facts on the next chapter.
During this process, while you amass a bunch of information, at some neurological level, you have not really mastered the subject, nor gained the skills that you wanted.
We can fix this.
Cody Lindley on finding your way through a popular and powerful language
- Don’t be down on jQuery users (at 2:03)
- Are buffers between your code and browser APIs necessary? (at 9:17)
- Running browser tests on the DOM (at 11:08)
- Needing more focused in-depth documentation (at 12:57)
His closing – “we need to do a better job communicating with the bulk of developers out there” – sounded just right to me.
You can view the entire conversation in the following video:
Steve Vinoski on when to make the leap to functional programming.
Functional programming has a long and distinguished heritage of great work — that was only used by a small group of programmers. In a world dominated by individual computers running single processors, the extra cost of thinking functionally limited its appeal. Lately, as more projects require distributed systems that must always be available, functional programming approaches suddenly look a lot more appealing.
Steve Vinoski, an architect at Basho Technologies, has been working with distributed systems and complex projects for a long time, first as a tentative explorer and then leaping across to Erlang when it seemed right. Seventeen years as a columnist on C, C++, and functional languages have given him a unique viewpoint on how developers and companies are deciding whether and how to take the plunge.
Highlights from our recent interview include: