Hacker News new | past | comments | ask | show | jobs | submit login
Ask YC: Development-wise, what do you do that's unconventional and why?
34 points by ericb on March 13, 2008 | hide | past | favorite | 74 comments
I'm interested in how people are running against the herd and why.

A good example of what I mean would be HN's use of tables for layout--it's not trendy.

For myself, I am playing with stylesheet formatting so most things are on one line, which I find faster to get around, and easier to see more at once. Another example is I now rarely abbreviate in variable and function names. I've decided I waste more time remembering my abbreviations than I would spend typing the word.




For Openomy, one of the things that makes our project really exciting day-in and day-out is that we went to a service based architecture early. We don't have one single application for everything and we don't have one single database for everything.

For instance, we have a user service (which controls accounts, sessions, etc and has its own database), a metadata service (which controls what files we know about, what tags they have, etc and has its own database), a file service (which controls the actual binary data of the files and has its own database), etc (we have a few others, but that gets the point across). They talk to each other through REST -- though it could be anything, of course -- to get anything done they might need.

This allows us to scale each service independently, which is great. I'm always surprised at how long it takes folks to move to a SOA.

But, perhaps, the coolest part from an always-hungry-to-try-new-things development team is that having a service based architecture means that we are free from programming language constraints. As long as the language can speak HTTP, we can try it out for a new service or a new client. There's nothing like the feeling you get when mastering a new language. And there's no better way to master a language than write something tens of thousands of people will be using.

So, we have an old front-end built in C#/Mono, we have a couple Rails services, a Java service, our new APIv2.0 (http://api.openomy.com) is written in Haskell/HAppS (which I'm particularly proud of), and now we're writing a client in Scala. And, besides that, we use Perl for some offline scripting tasks.

I think it's pretty unconventional-- but it shouldn't be! I highly recommend going this route.


I'm working on a variant of this SOA model using (don't laugh) IRC and JSON. Pick your language, and hook-up.


Pencil & paper for a lot of the design & architecture work. I write a lot of little notes to myself in a spiral-bound notebook.

Using immutable data structures. I've jiggered up some Python decorators to handle the copying for me, so all my setters return a new object instead of mutating the old one.

Writing code that's both Flash and JavaScript. A lot of our product is written in the common subset of both languages, with a compatibility library to paper over differences.


I design on paper a lot too. A new feature or big refactoring has to be absolutely clear in my mind before I start coding.

ActionScript classes are syntax-incompatible with JavaScript, how did you solve this? An AS to JS mini-translator seems to be the simplest way, no?


I don't use ActionScript classes. Everything's done with closures and literal objects. Can't even use prototypes; MTASC doesn't allow standalone functions or prototype declarations (instead requiring that everything live inside a class), so that falls outside the common subset. We namespace things the way it's done in JavaScript, with objects serving as namespaces, so there's a notion of libraries that're imported at compile time. My Scheme experience certainly comes in handy.

I haven't ruled out doing a mini-translator; this is very obviously a hack, and if the common codebase grows much larger we'll probably appreciate it. (We've also considered rewriting the whole thing in pure Flash, but there're certain user benefits that the dual-language architecture gives us that we're not quite ready to give up.) This approach is "good enough" for now though, so we're hoping that it'll get us to an initial launch, and then we can decide whether it needs a rewrite based on what users want to do with it.


I'm not sure whether any of these are anti-trendy or not, but here are a few things I found myself doing in a project I've been working on recently:

* It's an online bookmarking system, and I didn't add tagging. I found that the UI step to add tags was a bit of a usability burden, and that I never actually used them to find stuff again anyway.

* I wrote it in Perl. Definitely not trendy, but it's fast, dynamic and (with mod_perl) stupidly easy to deploy.

* I rolled my own JavaScript libraries and wrestled with cross-browser issues rather than using jQuery, prototype, or some such. Why? To learn the nitty-gritty details of DOM manipulation and browser compatibility.

* I de-normalised the database from the start. Why? Because it enabled me to build a simple, light and fast object-oriented table wrapper without the overhead of dealing with associations, joins, and so forth. For any structure that does require a table join, I use database views to make it look like it's a simple table to the application.


For my desktop application I've decided to spawn processes rather than threads even though the trend these days is to use processes.

It separates the engine of the app from the GUI, and the interface between is well defined. I use txt + UNIX Pipes to communicate.

Also, any stability issues and memory leaks don't effect the entire app and I get to avoid all the weird concurrency issues of threads.


I mix tables and divs in my layout. I use whichever is easiest and works best on the most browsers. In general, I regard HTML/CSS as bytecode for browsers, not a programming language that I should write readable code in, and web standards as something I hope browsers will comply with, not web sites. Sometimes I even abandon templates in favor of graphics-library-style HTML generation.


I'll have to second not using an IDE; I use (g)vi(m) instead.

It forces me to understand each step of the development process, reduces the overhead of any machine I work on, and allows me to work on pretty much any server, anywhere, using just Putty/Terminal.

Interestingly, I also try to minimize the amount of customization I do, sticking instead with the defaults so I can easily work in new environments. I'm not sure if that's unconventional though.


Not long ago I would have said using a Lisp dialect for web development, but now I think that might actually be trendy.


It's still very much in the minority. You're just running with an oddball crowd here at HN. If you look at projects being released and sites being launched, PHP is still the most popular by an order of magnitude, with Ruby and Python gaining. So, don't worry, you're still a lisp weenie hanging out with the long-haired weirdos and art fags at lunch.


OK. In that context, the unconventional thing I've done is to make an actual functional site used by people who don't have CS degrees. In fact, the target market is adults who have a life. Like me! I do stuff, you know. I'm about to go do stuff now. (Upgrade tinymce.)


That is very unconventional indeed ;)


I think that it is trendy - but non conventional. It sounds very cool and fun to me.


I simultaneously munge the language and the application written in it.


I discovered today that's actually an established practice: http://lambda-the-ultimate.org/node/2711. I haven't read any of the papers yet, but looking at the abstract of "Language Oriented Programming" by M. P. Ward, there does seem to be a difference between his idea and your approach with Arc and your other projects.

In the abstract, Ward defines Language Oriented Programming as defining a formal description of the language to develop the type of application in question, and then write the application in that language, and implement the compiler using existing tools.

The problem I see with this approach is that it's rare to know ahead of time what the ideal language for an application should look like. I don't think you're really going to know until you try to develop it. That's how the Arc approach differs. Particularly when you're already working in a language with rich meta-programming/code generation capabilities, I don't think there's any reason to have a strict separation of the phases. Even if you're not using a language with innate code generation, it's still possible to iterate back and forth between writing the application and changing the language/compiler

Keep in mind I haven't read the whole paper yet, or any of the related work, so the methodology might not be as strict as I've presented.


The common practice in Smalltalk is to just extend Smalltalk so that it becomes a powerful domain specific language for your application. Most everything in Smalltalk is just an ordinary message send (procedure call) so any good programming where you Don't Repeat Yourself ends up being a domain specific language.


Is that where Ruby got this tendency from? I haven't used Ruby yet, but I see this style of development talked about in conjunction with Ruby.


Nothing - I think the key is to minimise risk, and find the few areas where you can actually add value. My value adding is in usability and design - the actual code is pretty simple. So I see no need to take risks code-wise and stick to tried-and-true (boring?) programming paradigms.


Agreed. Blub can do everything I need anyway.


I use perl as pseudocode, especially when I have to target multiple languages/platforms.

Its stupidly easy to hack together prototypes of functions to test out data structures and algorithms just using perl and the command line. This helps me think more about the structure of the program and less about the syntax of a specific language, especially languages that I'm weaker in.

Once its working right and thought through, I'll use the perl "pseudocode" as a guide to code in the target language.


I'm in favor of the speed of flat files. I have two Windows desktop applications (one for sale, one freeware) that both were converted from using a database to using a simple flat file. It was easier to program and much easier to distribute. One of the programs has a search functionality - it's just the normal linear text search. Even with all the data I have in the program it's instantaneous.


I've started tinkering with the idea of using JSON for RPC calls, particularly across languages. It's lighter than CORBA, XML-RPC, SOAP, etc. and well-supported by all of the languages I like and use. One has to formalize some sort of standard function call interface, but since JSON is relatively limited and similar to the data structures one could pass as arguments in Perl or Ruby or Python, that's pretty easy and natural. And I hate XML.

I use Perl (which, given the number of others here mentioning Perl, seems to not be so unconventional after all). Partly because our codebase is 450kLoC, or so, and almost all Perl. Won't be rewriting that anytime soon. Perl is also very comfortable for system administration tasks. Moreso, in my experience, than Python.

I think a lot more than I code. If I write more than a dozen or so lines a day, it's a heavy day. I am mainly maintaining and extending existing software...so it's often just wrapping my head around the existing API and code. But even when starting from scratch on something, I take a long time to start actually coding, and only occasionally have a blast of productivity where I push out a couple hundred lines in a single stretch. This is somewhat bug-like, but I've never really been able to change. Luckily, as I've gotten better at the tools I use (Perl, JavaScript, and shell, mostly) those few lines of code tend to actually accomplish quite a lot--and the resulting code is usually nice to maintain because it is very short. So, the work does get done...but when I look at my co-founders output, I always feel tiny. He pumps out hundreds, and sometimes thousands, of lines per week...and they all work really well and are often as concise as what I would have come up with (though not always...he sometimes "powers through" and tightens it up later when it becomes a problem, which is a skill I often wish I had).


When I'm doing algorithmic work, I rewrite rather than refactor. Perhaps it's just me as a programmer, but it takes me three or four rewrites before complex and nasty algorithms begin to appear simple.

Also WRT abbreviations and again in algorithmic code: I love to use one-letter variables for 'working' variables. It forces me to reread what I've written and really understand what's going on, rather than take shortcuts based on what a variable name might imply.

Business logic "if the account balance is below $100 send a warning email" code need not apply ... for that stuff I just wade through same as anyone else, although I'm more apt to write code that writes code if I'm faced with a particularly high pile of the stuff.


Generate Java boilerplate using shell scripts -- not sure if that was included in the list of new sins the Vatican put out last week.


I never code in a mega-syntax language (Perl, C++, C#, Java 5) if I have the choice. I feel that I'm lighter on my feet and able to move between environments better by sticking with languages that have more terse syntaxes.


It looks like people have already picked the low-hanging fruit here, so here are a few things not yet mentioned I try to do that I don't see others do often:

I use tools like Libero[1] to express service logic directly as a state machine.

I generally try to build and maintain a simulator for whatever I'm working on with tools like SimPy[2] and Spin[3].

I try and use Excel spreadsheets to build mock-up GUI's.

I try and make it so that all database access occurs behind service API's. Before I have the basics worked out I don't even bother with an actual database and instead just use memcached[4] and a file of initial data.

[1] - http://legacy.imatix.com/html/libero

[2] - http://simpy.sourceforge.net/

[3] - http://spinroot.com/spin/whatispin.html

[4] - http://www.danga.com/memcached


Recently I've found myself writing out a tricky algorithm in comments at the top of the function. Easy, bulleted English points about what this function is doing. I then find that I can do the coding and simply make a quick comment back to the bulleted list. "# 1. Load users into dictionary", etc.


I guess something I do is using bleeding edge frameworks and libraries to start projects if I think it'll give me an advantage. I figure that they'll stabilize (or I can help stabilize them) in time for the production release of what ever I'm working on.


I did that with ExtJS (starting way back when it was first announced as YUIExt). I haven't been entirely happy with the manner in which it has matured, as it has bloated into a somewhat intimidating Java Swing feeling creature (which is both good and bad) that means the most comfortable way to develop is without any HTML at all--everything is built in JavaScript and data comes in via JSON. But now that I'm about to finish up the project that uses it, it's turned out pretty awesome.


Can't vouch for exactly how unconventional this is, but when I'm building a website I go through and do all of the HTML first, then CSS. Some I've seen do both at the same time, create a header, then make the CSS, navigation, then CSS, little by little.


I work in a Smalltalk shop where we get around Smalltalk's lack of Interfaces/Multiple Inheritance with State/Strategy objects. That's not so unusual. What goes against the grain is our eschewing polymorphism in that one situation, instead having case statements for the different object types. My boss prefers that because he feels it's better from a code management standpoint. The rest of us just quietly acknowledge to ourselves that it's not real OO, and play along.

Surprisingly, it works well, probably because it discourages us from making those things too complicated. The frameworks/APIs used by those objects have to be clean.


While looking at a co-worker's UI code the other day, I commented out loud to him and our other cubicle dwellers that "I would have coded it very defensively " and told him "that he took risks programming and that was why he was more likely to start a business than I (the conservative programmer) was (he's got an entrepreneurial long-term outlook).

Some of the things he was coding seemed relatively risky (e.g. relying on binding to work flawlessly with a complex, deep nested model - we've had hard-to-debug issues with ssome Flex UI-field binding in the past)


Bad, difficult-to-debug programming is not moving against the herd, it's moving with it.

Are you implying poor programming makes one more likely to start a business? That will float like a lead balloon here.

Am I misunderstanding your post, or feeding a troll, perhaps?


My intention was not to imply that bad, difficult-to-debug programming makes someone more likely to start a business.

The issues with Flex in the past with viewing/editing attributes on a complex parent.child.subchild model are in the past (they fixed the issues). His code was not "bad, difficult to debug" it was "risky" in the sense that Flex didn't support it in a previous release.

When I told him that his code was risky, I said it with a half-serious tone (e.g. half joking). Rereading the post indicates that the tone of the post and the tone of the original comment never carried through. I apologize.


No worries, a lot is lost in typed communication.


them's fightin' words


I would go with either a troll or a jerk.

If someone intentionally loudly told me my code was irresponsibly risky and stated my future ambitions for all to hear, I would not be impressed.


Sounds a little passive aggressive to me.


I do all my client-side prototyping in a technology that does not use a mouse, graphics, or a browser. Once the basic functionality works perfectly, then I port it over to javascript and add the rest of my interface.


I'll bite. What's the technology? Are you going to say paper? :-)


http://www-306.ibm.com/software/data/u2/universe/


+1 for Pick


Writing C++ code that's as functional as I think is reasonable; lots of recursive function objects operating on containers, but with mutable data.


I have a similar approach for Java:

- as functional as possible, using classes almost only as namespaces.

- lots of little inner classes as data tuples.

- lots of recursive functions filling in/trimming out containers.

- the 'final' keyword is the best of the lot.

And no standard boiler-plate "patterns" for which the java language is sadly know (and which make java code unreadable, unpleasant, and altogether a horrible experience).


Why not take the jump and just use Scala? I have. :)


I second that (using Scala), it's amazing. Totally compatible with Java and the JVM, but lets you mix in really concise functional programming, along with a dozen other big pluses and scores of little treats (for a long-time Java programmer like me). We're using it as the primary language for our start-up. I use the Emacs mode for syntax-highlighting and indentation (and I've fixed a couple annoyances). I use two Emacs shell-mode buffers for a scala prompt and a shell prompt to run build scripts (I don't use whatever facilities scala-mode has for those things).


what editor are you using for scala? The eclipse plug barely does anything and I am fed up of using the scala interpreter on emacs :(.


Sorry to say that I use emacs, so I can't help you too much. It occasionally screws up indentation but otherwise stays out of my way.

(I'm far from an emacs power user -- also I don't use the interactive toplevel much, and never from inside emacs; instead I throw that sort of thing in run-once junit code in case it becomes a test suite.)


Because Scala still has a lot of the verbosity of java. So I'd rather use plain java for the plumbing, and then use concise, clean, reads-like-documentation short jython scripts for high-level programming.

[edit: by which I mean I don't have such a need for properly functional programming with function-as-argument etc. Most of what I do is plain ol' number crunching, paired with threading.]

[edit 2: i.e. "blub" is better. I have to give scala a better look one of these days.]


If I were in an arguing mood, I'd say that in terms of verbosity, scala is closer to jython than it is to java... the only major number-of-characters difference is that you need type annotations for method arguments (and return value if it's recursive).

Still from a 'conciseness' point of view and ignoring all the benefits of closures, first-class-functions, and other goodies, scala still has some serious awesomeness to serve up, especially when navigating the world of Enterprisey Java Libraries: implicit conversions. A good explanation is here: http://www.artima.com/weblogs/viewpost.jsp?thread=179766

There are also some downsides, of course ... I'd say they can all be summed up by the facts that scala is a young language, still evolving, and it is a large language with lots of features (some rather hard to grok at first).

Cheers!


What does your code look like? I'd love to see an example. While I have to implement a decent amount of scaffolding (lots of brain-dead constructors for simple function objects), being able to overload operator() helps.


I consciously try to program like a newbie, moving ahead clumsily and directly. Make it work, then make it small. Code is a bridge, it doesn't need to look good, just get me across. What use is a beautiful bridge to nowhere?


Never MySQL ; Solaris instead of Linux ; AOLserver instead of Apache and *AMP stack.


I used AOLServer and OACS for Virtualmin's first website. I got over it. http://www.obsceneart.com/?p=6


Based on all of the comments submitted thus far, it seems that an uncommon philosophy is actually quite common. :)

Can we not "rage against the herd" while running with the herd?

Does the direction in which we wish to go need be contrarian?

Am I making any sense whatsoever? :/


I see what you're saying, but there's a difference between being contrarian for the sake of it and being so for a reason.

Having a good why is the difference between Darwin and a Darwin-award candidate. Sometimes a best practice is best, sometimes it's just a practice.


If you herd is HN readers, then you'd probably have to do some suboptimal practices to rage against the herd.

If the herd is everyone in the world that writes software, then I'm pretty sure everyone here is raging against that (much larger) herd.


I ask questions on YC!


I use the shell as a development environment. In this world of SPE, Eclipse, and XEmacs, developing C/python/Java/others in a shell with vim, grep, sed, less, find, is starting to become unconventional.

I just cannot tolerate the mouse-clickiness of all mainstream IDEs, neither the extreme use of the control+this+control+that of emacs.

My primary reason to get into vim was the promise of short key bindings, very easy text editing/rewriting and no mouse. It fullfilled that promise: my wrists have not hurt again ever.


I don't think this is all that outside the norm, but I might be showing my age. Both my co-founder and I are exclusively vim users, and at a previous software dev shop I spent a few years doing contract work for there were several emacs (which I don't consider in the same vein as Eclipse and VS or whatever--though it depends on how you use it) users, a nedit user, and a couple of other users of plain old text editors. And all of them used the same set of custom build scripts and development tools, which were all command line with matched sets for Linux and Windows.

Only about 40% or so used a big IDE (Eclipse or Microsoft's stuff, plus a few IntelliJ) full time. A few more used Microsoft's stuff for the debugger when they needed it.


>> my wrists have not hurt again ever.

Have you tried a trackball? if I use a mouse for a week or so my wrist starts aching, with a trackball none of those problems.


Sorry, I blended together several issues:

* My wrists used to hurt a lot from bizarre keybindings that use the control key (I used to use emacs a lot), than from mouse usage. Remapping to the caps is no use (strains my left little finger and left upper side of the hand). Remapping to alt (or to the apple key, in a powerbook) helped a lot, but still too many control pushes.

* The mouse slows me down, way more than hurts my wrists.

* I use Blender a lot. Using the mouse for Blender is no problem regarding my wrists. The trick for me is: extend the arm to fully rest in the table, flat, so that the mouse ends up nearly behind the laptop.


Eclipse has pretty decent Emacs key bindings built-in (you just have to turn it on), and there's a decent plugin for vi users; you don't need to use the mouse (much) in Eclipse if you don't want to


Use a text editor like JEdit to do my code because I hate eclipse and it's overhead and I like the color coding and the fact that I can install it anywhere.


Me too! I'm trying to school myself in VI (gvim), but until I reach that golden shore I'll be keeping a more intuitive editor handy.

edit: Heavy IDE's haven't paid off for me yet. (I like to be familiar with every point of control in my environment. Hidden configurations have given me more headaches and stress than my personality can afford.)

Devil's advocates could certainly say I just haven't spent enough time learning IDEs.

I would respond with tangent rant about the virtue of owning ones means of production which includes knowledge. Knowledge ownership seems more obtainable when you must know how to do everything from the ground up.


I used eclipse in a corporate environment and I understand its value.

a) Everything in one tool. Your servers can be right there, you have your code, your repository is directly connected, etc. b) It is actually is pretty good. If it wasn't so bloated I would use it. c) It is easy to train people to use eclipse, debug in eclipse, its all visual. d) Loads of plugins, again all in one tool.

Cons would be it commonly eats up over a gig of ram. It is slow. An expert in emacs can probably do most tasks quicker than an expert in eclipse.


You know what, it's high time I give emacs a fair shot, before I become to indoctrinated.


I live on both ends of the extreme. On Linux I use gedit and on Windows I use Visual Studio. If you are going to write in a static language like C#, you might as well have code completion.


I've been using Crimson Editor for the same reason and have even kept using it via Wine on my ubuntu machine. That doesn't mean I haven't tried other text editors, Crimson just does some things that all the others I've tried don't do... but I haven't tried JEdit yet, it looks promising.


Have you tried PSPad? I've found it even more useful than Crimson.


Checked it out and it seems like they took a (very) small subset of what emacs can do and re-implemented it.

In order: Edit multiple documents: Multiple buffers with buffer menus, buffer-name completion, etc. Syntax highlighting: See font-lock-mode Multi-level undo/redo: See emacs undo. Emacs does lack in the redo area though... Directory tree view window: See dired Find and replacs: C-M-$ or if you like regular expressions, M-x query-replace-regexp column mode editing: See rectangle manipulation commands in emacs. Natural word wrapping: See auto-fill-mode Spell checker: See flyspell-mode and flyspell-prog-mode which only spell shecks inside comments and program strings. User tools and macros: See elisp: One of the most advanced programming languages, integrated right into the editor. Furthermore, comint can be used to call any other program and manipulate output. Etc...: See emacs packages.

Etra: A complete programming language instead of the restricted macros in Crimson. Since elisp is turing complete, practically anything is doable, programs like GNUS, etc...

So... try emacs and see if you like it.


Yeah I use Jedit for the same reasons. I love the hypersearch and the fact that I can run it in Windows, Linux and on Mac. And it's not as resource intensive as Eclipse.


i buck the trend by building sites that effectively work.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: