My Software Development journey: Year 3-4. Just over a year ago I wrote a blog post about my software development journey up to that point and I thought it’d be interesting to write a new version for the 13 months or so since then to see what the main things I’ve learned are. Functional programming I started playing around with F# about 11 months ago after becoming intrigued about this approach to programming following some conversations with my colleague Phil Calcado. I’ve only really scratched the surface of what there is to know about functional programming so far but some of the ideas that I’ve come across seem very intriguing and I think they can help us to write more expressive and easier to understand code. One of my favourite aspects of the functional programming approach is that it heavily encourages immutability. In contrast I don’t think I’ve ever tried to debug any F# code I’ve written.
Jeremy Miller covers these ideas and more in his recent article titled ‘Functional Programming for every day .NET development‘ Context. A Ban on Imports. This is not, of course, an essay on restricting free trade. Rather, this post is about the evils of the import clause, which occurs in one form or another across a wide array of programming languages, from Ada, Oberon and the various Modulas, through Java and C#, and on to F# and Haskell.
The import clause should be banned because it undermines modularity in a deep and insidious way. This is a point I’ve attempted to convey time and time again, with only limited success. I will now try to illustrate the problem via a hardware inspired example. Consider the not-so-humble MP3 player. Let’s try and describe the analog of such a sound system using programming language modularity constructs that rely on imports: module SoundSystem import MP3Player; ... wonderful functionality elided ...end I want to describe how my sound system works, separately from the description of how an MP3 player works. Now the first problem is that neither Zune or iPod are named MP3Player. Say I decide to go with a Zune.
Does Visual Studio Rot the Mind? Ruminations on the Psychology and Aesthetics of Coding By Charles Petzold A Talk Delivered at the NYC .NET Developer’s Group,October 20, 2005 Abstract: Visual Studio can be one of the programmer's best friends, but over the years it has become increasingly pushy, domineering, and suffering from unsettling control issues. Should we just surrender to Visual Studio's insistence on writing our code for us? Or is Visual Studio sapping our programming intelligence rather than augmenting it? This talk dissects the code generated by Visual Studio; analyzes the appalling programming practices it perpetuates; rhapsodizes about the joys, frustrations, and satisfactions of unassisted coding; and speculates about the radical changes that Avalon will bring. I don’t speak to user groups or developer groups very often, partially because of a bad experience I had a number of years ago.
Instead, I decided to talk about something that people could not read about in my book. Well, people went berserk. From People to Programming.. I went to the Agile2009 conference this month, and enjoyed it a great deal. I have deep roots in that community.. people I've worked with.. people I've known on and off for close to 10 years. For me, it is a big "catch up" thing. I pick up things from the sessions but really it's all about the hallway conversations.. people I know and respect who are passionate about delivering software and making the workplace a better place.
I feel lucky that I stumbled upon all of this. In 1997, I went to the OOPSLA conference in Atlanta, and I was mesmerized by the technical sessions. I was equally mesmerized by the interactive sessions. In one, I overheard two people talking about how in their consulting job, they had to share a single desk in a half-cubicle, with one of them standing all the time while they were working on their system. That attitude always terrified me. It's amazing how much things have changed since then.
Now, having said all of this, I feel myself pulling away from it. Semantic Versioning. Facts Behind Code Indendation Styles Wars. About a week ago an anonymous visitor to Experiment Garden made the following comment: "Please, please, PLEASE, for humanity's sake: use the Kernighan and Ritchie's indenting style! Don't use braces for single line statements.Much less, put them in their own lines! Vertical space is precious. By committing those sins, you're making your code unnecessaringly [sic] long, which means I must scroll down to read it completely, whereas it could've fitted in very few lines, if you take out all the fluff!!!
" This is just one more example of the great code indention style war that has plagued programmers for decades. In most languages code indention isn't a requirement. The Allman Brace Style Personally, I favor the Allman Brace style, which is credited to Eric Allman, the programmer who created sendmail. In my opinion, the Allman brace style is easier to read because it separates the code into solid blocks that can quickly be distinguished from the rest of the code. The War Behind Indentation Style. Schuchert - Katas. Concepts, Techniques, and Models of Computer Programming. MIT Press, hardcover, 900pp+xxix, ISBN 0-262-22069-5, March 2004 by Peter Van Roy and Seif Haridi “More is not better (or worse) than less, just different.” — The paradigm paradox.
“Wonderful book, very insightful, strangely easy to read (haven't figured that out yet), very unusual in many respects.” — Doug Merritt. “The overarching achievement of this book is to be so provocative that one wants to engage the authors in debate about almost everything they say. Partly this is due to the chirpy writing style [...] but mostly it is their delicious iconoclasm.” — Peter Gammie, Book Review, Journal of Functional Programming, March 2009. Errata Supplements This textbook brings the computer science student a comprehensive and up-to-date presentation of all major programming concepts, techniques, and paradigms in a unified framework.
Concurrent programming: The broadest presentation of practical concurrent programming available anywhere. What other people say Endorsements Book review by Edgar R. Talks. The disappointingly ongoing success of WvDial. EQL Data in Connecticut In Farmington, CT, in fact, the town my cat was named after. Oh yes. That's how much we love that place.
Lukasz, Ashok, and Matt will be presenting EQL Data at the Connecticut Access User Group tomorrow (well, by the time you read this, *today*) at around 5:30pm, at the Microsoft campus in Farmington. If you live in Connecticut, or anywhere else for that matter, you should come check it out! December 9, 2009 05:07 Note to the beloved fans subscribing to my Youtube feed I don't have a Youtube feed. I don't post Youtube videos. I can't find myself on Youtube. I don't even like Youtube. And yet I'm getting notifications about it. So whatever it is you're subscribing to... um, no need. Update 2009/12/21: drheld points out that I have, in fact, posted one lousy video to Youtube in the past. December 22, 2009 04:47 The disappointingly ongoing success of WvDial For those who don't know, I'm one of the original two authors of WvDial (Oh yes, that's a real Wikipedia link!)...
Nope. Code fast. The left fold: 2009-12-14. Welcome to the eighth issue of The Left Fold, a weekly programming news and article digest. Is Small Still Beautiful? (LTU appropriate punchline at end) I suppose I'm just old enough to have been raised on the "small is beautiful" philosophy, and I still hold in awe some languages built from a relatively spare set of primitive concepts: Forth, Smalltalk, Scheme, C and the Unix shell + utilities + pipeline all come readily to mind. But recently, I've had some time on my hands and spent some time "swimming" about in the programming language space. A few observations. Some of our modern languages (some a decade+ old already) have type systems that require a PhD to understand fully. We have a low level threading model in languages like C and Java that almost require a PhD to use effectively in any sufficiently complex system. (Not to make a fetish of the PhD.) In Pike's Power Point on system research, recently posted in another thread, he mentions, IIRC, that 80% of the Inferno (?)
Designing an effective GUI library for the modern, newly more complex UI was a grand challenge of the late '80s and early 90s. Lemma the Ultimate. Every thing you need to know about a Programmer, you can learn f. I've been doing interviewing and hiring at our technology startup for almost a year now. When we began hiring, I found that I was basically the only person who would do it -- partly because I was the only person who displayed any sort of natural aptitude at judging another Engineer's technical and personal abilities. It didn't take me long to create my own system which I thought was both fair to the interviewee (whom I empathized with, having been one for so long), and gave me a decent understanding of the candidate's qualities. With a little bit of intuition, and some trial-and-error, I evolved my system.
As the people I had interviewed and hired began to join me in the interviewing process, I got to notice how other people handled going from interviewee to interviewers, and how their outlook on a candidate's performance differed from mine. This evolutionary process has lead me to solidify the following as my Golden Laws (tm) of hiring. 1. 2. 3. 4. 5. The Sample 1. 2. 4. 5. 6. It occurred to me recently that programm. It occurred to me recently that programming comes in several flavours, and that how much I enjoy a programming task depends strongly on which flavour predominates.
The flavours I've identified so far, in descending order of how much I like them, are the following: Data munging: You have a large mass of data in some fairly generic form, and must fold, spindle and mutilate it with well-understood tools to extract the information of interest to you. Writing Unix scripts is the classic example, but list manipulation in Haskell or Lisp and array manipulation in J or APL have this flavour too. Clever algorithms: You have some calculation or task to perform, and brute force has proved inadequate.
Now you must apply the Power Of Your Mind to find a cunning and better approach. I haven't actually done very much of this stuff, but I have had to solve a couple of problems of this nature at my current employer, and have another one waiting for me on Monday morning. API spelunking. The Nerd Handbook. A nerd needs a project because a nerd builds stuff. All the time. Those lulls in the conversation over dinner? That’s the nerd working on his project in his head. It’s unlikely that this project is a nerd’s day job because his opinion regarding his job is, “Been there, done that”. We’ll explore the consequences of this seemingly short attention span in a bit, but for now this project is the other big thing your nerd is building and I’ve no idea what is, but you should. At some point, you, the nerd’s companion, were the project. You were showered with the fire hose of attention because you were the bright and shiny new development in your nerd’s life.
Regarding gender: for this piece, my prototypical nerd is a he as a convenience. Understand your nerd’s relation to the computer. First, a majority of the folks on the planet either have no idea how a computer works or they look at it and think “it’s magic”. Your nerd has control issues. Your nerd has built himself a cave. Cool? My advice: Quine リレー - まめめも. ■[Ruby][Python][Perl][Lua][OCaml][Haskell][C][Java][Brainfuck][Whitespace][Unlambda] quine リレー Update (2013-07-15): I improved this program to 50-language version. 50 言語版にパワーアップさせました。 これはこのプログラム自身を出力する Unlambda プログラム、を出力する Whitespace プログラム、を出力する brainfuck プログラム、を出力する Java プログラム、を出力する C プログラム、を出力する Haskell プログラム、を出力する OCaml プログラム、を出力する Lua プログラム、を出力する Perl プログラム、を出力する Python プログラム、を出力する Ruby プログラム、です。
# ruby l=92.chr;eval s="s=s.dump[r=1..-2].gsub(/("+l*4+"){4,}(?! 最初のコメント行以外の改行は読みやすさのために入れています。 QuineRelay.rb などというファイルとして保存してください。 以下のように実行します。 $ ruby QuineRelay.rb > QuineRelay.py $ python QuineRelay.py > QuineRelay.pl $ perl QuineRelay.pl > QuineRelay.lua $ lua QuineRelay.lua > QuineRelay.ml $ ocaml QuineRelay.ml > QuineRelay.hs $ runghc QuineRelay.hs > QuineRelay.c $ gcc -Wall -o QuineRelay QuineRelay.c && . 最終的に得られる出力 QuineRelay2.rb は最初の Ruby プログラムと一致するはず。 $ diff QuineRelay.rb QuineRelay2.rb 念のため各処理系バージョンを書いておきます。
Stop Exposing Collections Already! Every time I see code with properties that return List<T>, IList<T>, ICollection<T> or any other of the types which allow you to modify the contents of a collection, I cringe a little. In most cases, the only reason to expose the contents of the collection is for read-only usage. You want people to be able to use the objects in the collection, but why on earth do so many developers continuously enable someone else to modify the internal state of the collection that they are holding?
The problem that I have with exposing a collection's values through a type which enables other pieces of code to modify the state of that collection is that it is effectively a pretty big breach of encapsulation. You no longer have sole control over the contents of the collection. Anyone can effectively add and remove elements from the collection, or even clear them entirely, without your object knowing about it. Obviously, this can cause subtle side-effects in the behavior of your object. Structured Parallel Programming. One way of looking at parallel patterns (sometimes called algorithmic skeletons) is through an analogy with "structured programming". The premise of structured programming is that a small number of control flow and data management patterns can be composed to implement the necessary control flow and data access logic in most serial programs.
There is some evidence (see, for example, work by Skillicorn, Campbell, Cole, and the Berkeley Dwarfs) that a relatively small number of patterns can also express the necessary task and data organization in a large fraction of parallel programs. Back in the '70s there was a heated argument about structured vs. unstructured control flow. Basically, you can obviously do anything you want with a conditional goto, which is usually the only control flow construct made available in machine language. From the point of view of completeness, this is all a programming language really needs to support. For parallel programming we are seeing the same evolution.
General Decimal Arithmetic. Roundoff Error. Applied Philosophy, a.k.a. "Hacking" The Interview With The Programmer. The Best Programming Language for a Lean Startup. About. Loop Patterns. Publications by Googlers in Software Engineering. David MacKay: Information Theory, Inference, and Learning Algori. IT books - Download for free. Duct Tape Programmers and the Culture of Complexity in Software.
Push-pull functional reactive programming. Linkers and Loaders. The passionate developer: I do like my profession, I don't. The unspoken truth about managing geeks. The Problem with Design and Implementation. The Curse of Xanadu. How I grew to hate every computer language. Law of Demeter. Stiff asks, great programmers answer. Watch out, developers: Here come the lawyers. Where I program. PLEAC - Programming Language Examples Alike Cookbook. Burnout. On the Skillfulness of Developers (part 2/2) Reinventing the desktop (for real this time) – Part 1. Omit Needless Code.