How to Draw Animals (1930) - <AUTHOR> http://dessinoprimaire.blogspot.com/2012/02/les-animaux-tels-quils-sont.html <comment><USER3> The site is in French. It's possibly "blog spam" in that it points to another French site as the original source:

[https://bibigreycat.blogspot.com/search/label/dessiner?updat...](https://bibigreycat.blogspot.com/search/label/dessiner?updated- max=2009-06-10T02:31:00%2B02:00&max-results=20)

On both sites, the images can be clicked to enlarge them. You probably don't need to know any French to figure that out, but I thought I would mention it in case it was helpful to someone.

Edit:

This info is from the top of the article:

 _sur le site de l 'Agence Eureka_ = from the site Agence Eureka

 _(cliquez sur les images pour les agrandir)_ = click on the images to enlarge

Per another comment here, there is an English language blog it points to and Wikimedia at the bottom of the page. The other French site appears to be the original source, not Wikimedia nor the English language site.

It also says "Images on Flicker" and links to this, which some people might like better:

[https://www.flickr.com/photos/taffeta/sets/72157618009562834...](https://www.flickr.com/photos/taffeta/sets/72157618009562834/)

<comment><USER4> And the URL means "draw in elementary school" in French.

<comment><USER5> In _phonetic_ French.

</comment></comment></comment><comment><USER6> If you, like I did, wish to have all the pages as a single pdf, I grabbed them all and made one [1].

(I just googled and found a simple site to share it on, so if it doesn't work or you have a better suggestion let me know.)

[1] [https://docdro.id/FFIBIrU](https://docdro.id/FFIBIrU)

<comment><USER7> Thanks for posting this. On the last pages it is said to be licensed under Creative Comments Share alike. I'd assume that the content might still be copyright protected by the original creator? So I don't think that anyone can relicense it as simple as that.

I don't have a moral problem appropriating content that has been published 90 years ago. I don't think it is appropriate to assign it a Commons license though.

<comment><USER8> The cc-by-sa note in the pdf is presumably because that is the copyright listed on Commons and Flickr.

However, the original work appears to be in the public domain. R & L Lambry were a father (Léon) and son (Robert) who died in 1940 and 1934, respectively. French copyright, as in all of the EU, lasts for the life of the author + 70 years.

I found this fairly interesting bibliography of the Lambrys: [http://nouvellesuzette.canalblog.com/archives/2010/05/13/179...](http://nouvellesuzette.canalblog.com/archives/2010/05/13/17919647.html)

And confirmed with this information from the French national library:

[https://catalogue.bnf.fr/ark:/12148/cb32342632r](https://catalogue.bnf.fr/ark:/12148/cb32342632r)

[https://data.bnf.fr/10863941/leon_lambry/](https://data.bnf.fr/10863941/leon_lambry/)

[https://data.bnf.fr/16969919/robert_lambry/](https://data.bnf.fr/16969919/robert_lambry/)

<comment><USER6> Correct. Since i got the files from wikimedia, I wanted to adhere to their license claim and give attribution. I was pretty sure it's P.D. but didn't know if the scans themselves might have a copy right in some jurisdiction.

</comment></comment></comment></comment><comment><USER9> Couldn't help but remember Picasso's bull.

[https://www.flickr.com/photos/sorarium/8578925321/in/photoli...](https://www.flickr.com/photos/sorarium/8578925321/in/photolist-5WrLxK-6fSRMQ- dh5a6F-9mfRY-8386qy-BMa4H-e56eBx)

Also teaches you about how hard abstraction is. You really really need to understand the subject and the underlying dynamics to simplify.

<comment><USER10> Many artists aren't trying to simplify an final subject. If anything, they come from the opposite direction - they don't worry at all about the final object - just look at it. Look at its lines. Mark out the major shapes. And there you have your abstraction. Now if you want to finish it, keep adding the next layer of detail. Mark out the smaller shapes. Mark out lines and endpoints. Start filling in some shading. Then add some texture.

In other words, you start from a simple abstract and fill in. And most of the 'how to draw' sketches from the original post do exactly that.

<comment><USER11> It's interesting to compare how theatre went from scripted shows to improv. Soon painters will ask audience members to draw some random shape for them to start.

<comment><USER12> I love doing this when doodling. I can start with nothing, but often it is more interesting to start with a scribble!

</comment></comment></comment></comment><comment><USER13> This article has links to original blog post in English[0] + media folder on Wikimedia Commons[1].

Think, link to Wikimedia Commons is better as source for images.

In same time, Daddy Types has more info about other editions:

> _Lambry 's instructions were originally made for l'Echo du Noel in the > 1920's and 30's, a weekly Catholic children's paper published by Maison de > la Bonne Presse until 1936. [Bonne Presse was owned by Bayard, which is in > turn owned by the Augustines. These images come from an unsold set of 51 > editions of l'Echo du Noel from 1931 on eBay.fr_[2] _.]_

> _A Spanish translation [Los Animals tul cual] came out in 1941, but so far > the earliest French edition of Les Animaux tel qu 'ils sont I've found > mentioned is from 1949. [The authors are listed as R. y L. Lambry, so > someone--a brother or wife, perhaps--is getting shortchanged on her credit > for the book. Desole', madame.] The 1959 edition_[3] _has a whopping 200 > pages and promises to teach this "reputedly difficult subject [sujet réputé > difficile]" in just 95 simple lessons. Et voila!_

Funny, I has similar 50-page book «Noah, teach us how to draw animals»[4] (Moscow: 1990, 1992) by Zheli Terez(?) in Russian (rus. Желли Терез. Ной, научи нас рисовать животных - М.: Рудомино, Цицеро 1990; Деймос, 1992. - <USER2> с.), but not sure what used as source for this book.

[0] [http://daddytypes.com/2009/05/13/how_to_draw_animals_the_rob...](http://daddytypes.com/2009/05/13/how_to_draw_animals_the_robert_lambry_way.php)

[1] [https://commons.wikimedia.org/wiki/Category:Les_Animaux_tels...](https://commons.wikimedia.org/wiki/Category:Les_Animaux_tels_qu%27ils_sont)

[2] [http://rover.ebay.com/rover/1/709-53476-19255-0/1?icep_ff3=2...](http://rover.ebay.com/rover/1/709-53476-19255-0/1?icep_ff3=2&pub=5574636946&toolid=10001&campid=5335844480&customid=&icep_item=270369722888&ipn=psmain&icep_vectorid=229480&kwid=902099&mtid=824&kw=lg)

[3] [http://www.livre-rare-book.com/Matieres/pd/8375.html](http://www.livre- rare-book.com/Matieres/pd/8375.html)

[4] [https://www.liveinternet.ru/users/ksu11111/post414036566/](https://www.liveinternet.ru/users/ksu11111/post414036566/)

</comment><comment><USER14> We play a great party game called 'Six Second Animals.' The caller names an animal and counts down from 6. Other players draw the animal. The caller picks a favorite and that drawer becomes caller.

<comment><USER15> Neat! check out Google's Quick Draw [1] where you need to draw a given object in 20 seconds and a neural network will recognize what you're drawing.

[1] [https://quickdraw.withgoogle.com/](https://quickdraw.withgoogle.com/)

<comment><USER16> I mean it literally asks you to draw the thing to be recognized.

It would be more impressive if you were to draw freely and the neural network would recognize whatever you drew.

<comment><USER17> That game wouldn't generate labeled training data for their machine vision algorithms, which I'm sure is the whole point.

</comment></comment></comment></comment><comment><USER18> I don't know about you, but I hate this cerebral type drawing, where you take a subject, analyse, restructure and reduce it into some components, etc. It's no fun and uses faculties that I want to rest when drawing. If I draw like this, what happens in my head is pretty much the same as when I work. I'd definitely not teach kids to draw this way. If anyone is interested in alternatives, check out Drawing on the Right Side of the Brain by Betty Edwards [0][1]. First edition came out quite a long time ago, and it has some popular neuroscience sprinkled in there from that time, but if you get through that, the actual learning material is very good. You'll be surprised how effective it is.

[0] [https://www.drawright.com/](https://www.drawright.com/) [1] [https://www.amazon.com/dp/1585429201](https://www.amazon.com/dp/1585429201)

<comment><USER19> I disagree, this is how I learned by myself (no book, no adults) and it was so much fun! The book just makes a system of it: you identify basic shapes to create an envelope then enjoy tracing beautiful lines.

People used to say I have "a gift", that was annoying. So many times I offered to teach anybody (using a similar method as the book) but no one ever accepted. "See? It's not a gift, some people just want to put the hours".

<comment><USER20> Well, I've put in the hours also- in a past life I studied art and traditional animation (hand-drawn) so I've learned a thing or two about framing. It has its place in a production setting where the emphasis is on finishing a drawing within a deadline, but as a teaching tool to show kids how to draw I'd really question its use.

For me the goal of teaching kids to draw should be to allow them to "unlock" their ability to communicate their experience of the world using form and colour. They should be shown the cave art from Lasceaux and Altamira, and inspired to look for their own internal representation of what their eyes can see and the ways to reproduce it on paper (or whatever medium). Not to follow closely someone else's set of lines.

So what if a kid learns to draw the same pretty butterfly, and only that one pretty buttefly, again and again and again, for ever? What has she achieved?

Here, this is the kind of art that should be taught to kids:

[https://en.wikipedia.org/wiki/Cave_painting#/media/File:Alta...](https://en.wikipedia.org/wiki/Cave_painting#/media/File:Altamira_bisons.jpg)

<comment><USER21> That's a cynical way of putting it. This kind of approach, repeated over many permutations until I have various arrangements of shapes available in muscle memory, makes for good mileage, relative to many other ways that one could practice drawing. It isn't the "only" technique, it just presents one more option.

And it is difficult to get beyond "trace these shapes" and start using abstractions of structure and proportion as a way of seeing. It's the same barrier that happens in gaining technique on a musical instrument: you can pick out some notes at the beginning, but if you want to feel really comfortable and have the fluidity to sight read or improvise, you have to start drilling scales. But once you have those skills available and try to compose, the problem is with having a stagnant reportoire, and then music theory drills gradually become more important.

But most kids do get stuck after learning a few songs.

<comment><USER20> Sorry if my post comes across as cynical. I didn't mean it that way.

</comment></comment></comment></comment></comment><comment><USER22> Reminds me of Ed Emberly books and the "draw 50" series of books I checked out of the school library as a kid. Draw a few shapes, fill in the blanks and details, erase your marks...

Or traced the second to last drawing and then fill it in by hand. I was a good "drawer" but you need a lot more practice to learn about perspective, shadows, and all the stuff that makes your drawings look _good_

</comment><comment><USER23> Some would say that is _not_ how you draw a (live) butterfly: [http://emilydamstra.com/news/please-enough-dead- butterflies/](http://emilydamstra.com/news/please-enough-dead-butterflies/)

<comment><USER24> This was very insightful. I never thought about what the natural wing position of a butterfly is like.

</comment></comment><comment><USER25> Note that the works seem to be in the Public Domain, since the author died in 1934 and the copyright law is 70 years after death in France. However, there is a co-author but no information is available on her/him which might extend the copyright duration.

Another argument for public domain is someone translated it to English and plans to sell it (at least on Amazon): [https://www.amazon.co.uk/Draw-Animal- Book-Step-Step/dp/16315...](https://www.amazon.co.uk/Draw-Animal-Book-Step- Step/dp/1631598414/ref=sr_1_1?qid=1559812155&refinements=p_27%3ARobert+Lambry&s=books&sr=1-1)

</comment><comment><USER26> Here are my personal top 5 drawings for lazy daddies:

[https://twitter.com/heinrichhartman/status/11365667071479439...](https://twitter.com/heinrichhartman/status/1136566707147943936)

</comment><comment><USER27> Thanks a lot to whoever posted this. I have recently started my new "(at least) one drawing every day" stint and I am currently working on animals (even if I tend to copy from photos) so this is very interesting to me.

[http://pa-mar.net/Hobbies/Drawing.html](http://pa- mar.net/Hobbies/Drawing.html)

</comment><comment><USER28> I showed this to my girlfriend who is an artist, and she basically scoffed and said, "I'm not really into that. I was taught to draw what I see."

As in, don't even THINK about drawing those circles.

<comment><USER29> In my naive way I guess she has to abstract too, maybe unconsciously to keep proportions for example.

For someone learning to draw without much talent, me, it is hard to know what is important and what to focus on. To me it seems like thats what these circles and lines are there for. Look at what is important and what proportions they have.

</comment></comment><comment><USER30> Drawing like most things, you get better by training. Once you can do basic shapes and features you can also start to free draw which is fun and also still useful in this age as you can make decent looking illustrations in order to explain stuff.

</comment><comment><USER31> this is cool, i'm about to be doodling some animals

</comment><comment><USER32> It was a simple book like this that I had as a boy that got me into drawing.

It taught me to see the simpler shapes that things are composed of — start there and build up.

It also caused me to begin to think about proportion when drawing — so that an animals head is properly proportioned to their body, etc.

If I were granted a wish it would be that schools had the budget to create books like this and outright give them to students to take home.

</comment><comment><USER33> The fundamental issue that is hardly addressed in drawing by shape recognition is that it gets the proportion right but fails to teach the inherent "3D" structure of the animal.

The litmus test for drawing is to ask someone to draw an animal. If they can, great. Follow up and see if that draw the same thing but now in isometric view or from an arbitrary viewpoint/perspective. Imagine if you have a camera with various lenses (24mm, 35mm, 50mm, 90mm, etc) which describe the amount of foreshortening you need to compensate. Now imagine taking that camera and point it to the object (animal in this case) and taking pictures from many different angles and distances. You simply cannot draw these if you haven't internalized the 3D form.

Check out Aaron Blaise (Lion King fame) who has a YT channel. His drawing skills are "3D" so to speak. He truly understands not just static anatomy, but the kinematics of how animals move and which muscles are involved. It is not by chance you get to work as an animator at Disney.

This guide fails (like 99% of the drawing guides, I've bought many books on drawing and they all sorta suck) to teach structure. It does well in teaching proportions (relative size of parts of an animal) but that's not all you need to draw. You NEED to know anatomy; even if you know anatomy, then you need to be able to internalize the 3D structure of the skeleton, muscular volume, understand foreshortening, line quality, overlap, chiascuro or shading, etc. I have mad respect for caricature artists, because they know all this and then have the license to exaggerate and modify the form.

Drawing is fucking hard, like insanely hard. I have spent more than 10 years in learning how to draw. It sounds like gatekeeping but honestly, I spent a whole year trying to draw basic shapes, doing coil exercises (See Sycra on YT), rotating objects, drawing architecture and basic geometrical scenes, etc. I would say getting an engineering degree (I have BS and MS) is wayyyy easier than learning to draw. It is one of the most difficult things I've pursued and the joy of sketching wherever I go is amazing. I still have ways to go, and I'd love to post a link to some of my drawings but I'd like to keep my account anonymous.

Also, you know why organic chemistry students have real models of molecules? Because they need to know the 3D form. Same with physicians who play around with 3D models and do real dissections.

Edit: Here is a sample of my early drawings (I did reverse google search and nothing showed up :-) ): [https://i.imgur.com/e4GgxFA.jpg](https://i.imgur.com/e4GgxFA.jpg)

<comment><USER34> Not everybody need to be able to draw things anatomically correct.

This guide IMHO serves perfectly as a material to teach children drawing as a recreational activity. There's almost no explanations, only directions. There's no exact proportion either, you choose what look good to you.

<comment><USER33> That's a fair point, I went off of on a tangential rant then :-) What I said bothers me deeply about drawing resources in general and I hope I can shed some light. I also draw recreationally, if I were to follow this guide, my animals would look horrible and rigid. Have you tried following this guide?

</comment></comment></comment><comment><USER35> A small thread from 2017: [https://news.ycombinator.com/item?id=14120920](https://news.ycombinator.com/item?id=14120920)

</comment><comment><USER36> It reminds me of Ed Emberley. Or Trogdor.

"S, more different S... Close it up real good for his head, then, using consummate V's, give him teeth, spinities, and angry eyebrows."

</comment><comment><USER37> I really like the handwriting. Both serious and playful.

<comment><USER38> It's an art-deco style, which is what the late 20s were made of. The entire book oozes that look.

</comment></comment><comment><USER39> The owl is on page 29.

</comment><comment><USER40> "Basic Bean Bodies".

<comment><USER41> Link? This sounds like it could be interesting.

<comment><USER40> Old Kliban cartoon.

</comment></comment></comment><comment><USER30> Drawing, like m

</comment><comment><USER42> This is what HN was invented for. Fuck the Silicon Valley venture capital narcissistic shite, let's just share worthwhile things like this.

<comment><USER43> You know, I was just thinking that HN is truly the last site on the web left where something cool like this would be at the top of a list, like something Jerry and David's Guide to the World Wide Web would have on it.

I'm so glad we still have this place.

<comment><USER33> I've been here for a while and I am seeing it erode slowly.

<comment><USER35> Everything is eroding slowly.

<comment><AUTHOR> You've been keeping the whole site together for years

</comment></comment></comment></comment></comment><comment> matt-attack This is literally a meme [1].

[1] [https://knowyourmeme.com/memes/how-to-draw-an- owl](https://knowyourmeme.com/memes/how-to-draw-an-owl)

<comment><USER44> True, the peacock example is very like the owl meme

[https://live.staticflickr.com/3549/3546657319_57861e46ff_b.j...](https://live.staticflickr.com/3549/3546657319_57861e46ff_b.jpg)

<comment><USER45> Not really. If you get the basic shapes and angles down, drawing the plumes is easy. Just try it! A funny thing about drawing is that some things which look simple is hard, and some things which looks impressive is really easy. Shapes, proportions, movement and perspective is generally hard. Textures, patterns, tones and shadows is relatively easy since you are just "filling in".

In the owl meme, some of the hard things (like getting the perspective and angles of the eyes and face correct) is glossed over.

</comment></comment></comment><comment><USER46> There's a lot of "draw the rest of the fucking owl" here. For actual step by step instructions for drawing dunces, look at Ed Emberley.

</comment><comment><USER47> I think this is actually the best book for learning to draw animals. I've had a copy for over 30 years, and I still like to go back to it sometimes.

[https://www.amazon.com/Draw-Animals-Perigee-Jack- Hamm/dp/039...](https://www.amazon.com/Draw-Animals-Perigee-Jack- Hamm/dp/0399508023)

</comment><comment><USER48> As per usual there is a subreddit for this /r/restofthefuckingowl</comment>


Survey of Syntactic Extensions in Lisp Family : elisp, CL, Clojure,Arc, defmacro - <AUTHOR> http://dorophone.blogspot.com/2011/08/survey-of-syntactic-extension.html

<comment><AUTHOR> (the reddit thread mostly re:arc)

[http://www.reddit.com/r/scheme/comments/jfscn/survey_of_synt...](http://www.reddit.com/r/scheme/comments/jfscn/survey_of_syntactic_extension_in_the_lisp_family/)</comment>


Finding My Next Bootstrapped Business Idea - <AUTHOR> https://www.derrickreimer.com/essays/2019/05/28/finding-my-next-bootstrapped-business-idea.html <comment><USER2> "The market must already exist". I think trying to find a brand new market is one of the biggest mistakes many founders make when trying to come up with a startup idea. An existing market indicates that demand already exists!

And when "no market need" is the most common reason startups fail [1], this seems to be often overlooked.

[1] [https://www.cbinsights.com/research/startup-failure- reasons-...](https://www.cbinsights.com/research/startup-failure-reasons-top/)

<comment><USER3> You're exactly right, but I think the real world is even more more nuanced than that (particularly when it comes to software).

Some markets just don't exist, period. Think nail polish for pet turtles. It's easy to figure this out, because every pet turtle owner tells you "I wouldn't buy this". There's no two ways about it. You know exactly where you stand.

This is infinitely better than the alternative, which is selling a product that kind-of fits, to a market that kind-of exists. You've identified a problem, everyone is saying "great idea, love the design, etc" \- but hardly anyone's buying. They all stall, or come up with excuses as to why they can't buy, even though they say the product is great.

Both are cases of "no market demand", but the former is an infinitely better place to be. You know exactly where you stand and what needs to be done - scrap everything and start over.

The latter is a very dangerous place to be. It's easy to give yourself any number of options - "maybe we just need a (UI redesign|new website|better marketing materials)". But fundamentally, the product is flawed. You haven't really found a market need. Odds are you've identified a _market want_. This is something that's nice for people to have (and that they might be happy to use). But it's not compelling enough to reach into your pocket and pay for.

This is an acute problem in software because

(a) we tend to be builders at heart, so we favour making things over identifying customer needs.

(b) it's relatively cheap to build something. Other industries have significantly higher barriers to entry, meaning you (usually) need to secure customers and funding before the production/manufacturing phase.

<comment><AUTHOR> Great points here. It's very tricky to get accurate information from potential customers. The fact that there is demand for what you want to build is a necessary, but not sufficient quality -- you must dig deeper to make sure the pain is bad enough for someone to adopt your product / switch from whatever they are doing now. I have to remind myself of this constantly :).

</comment></comment></comment><comment><USER4> Hey Derrick! I don't have much to say, except that I really enjoyed your site's design. Good luck!

EDIT: Now that I've read through your article: I'm the founder behind browserless.io. Your outline is great, and is the same rough rubric I've used before. If you ever want to chat about anything, let me know! You're totally right: this thing is hard, and having more successes/failures doesn't make it any easier sadly. Lot's of dice rolling and trying.

<comment><AUTHOR> Thank you!

</comment></comment><comment><USER5> I would like to know your opinion on "When to drop the ball when trying to build a business?" You need to persevere, but like playing poker, you invested so much energy that it might be hard to pull the plug. Success might be just around the corner...

<comment><AUTHOR> Totally! To clarify, by the "drop the ball" do you mean knowing when to call it quits if something is not working out? I recently wrote about my experience with that: [https://www.derrickreimer.com/essays/2019/05/17/im- walking-a...](https://www.derrickreimer.com/essays/2019/05/17/im-walking-away- from-the-product-i-spent-a-year-building.html)

My friend Justin Jackson also published a good article about this too: [https://justinjackson.ca/giveup](https://justinjackson.ca/giveup)

<comment><USER6> Thanks to you, I finally read The Mom Test. It was extremely insightful alongside your written experience.

<comment><AUTHOR> That's awesome!

</comment></comment></comment></comment><comment><USER7> Hi Derrick, looking at the criteria you listed I would say you probably could find some interesting ideas in the real estate sector. I created an open source real estate website builder and though that hasn't made me any money, it got me enough contacts and insights into the sector to make me realise how much potential there is there.

I am happy to have a chat if you want to know more. My plan is to launch a product in that space in the next 6 months

<comment><USER8> I worked for a real estate company for a number of years and have watched the behavior of agents over a longer period of time.

I'd advise anyone working in the software side of real estate to target anyone other than real estate agents (brokers, title, inspectors, etc) as customers. The churn is punishing, there's a lot of competition and many agents do a small number of deals/year.

<comment><USER9> I'd second this. I've seen several people get their agent license in recent years, and most of them have additional jobs. (meaning they're not generating as much income as an agent as they'd need to do it full time) It's a very flooded market.

<comment><USER10> Agreed. Just launched my company to help the types of agents you're talking about: GeneralReferral.com

Brings technology to an underinvested corner of the traditional brokerage.

Could use some marketing help...

<comment><USER11> I work as an agent in the commercial real estate space. Usually referrals happen when one agent who let's say specializes in office (for example) finds a lead/listing in Industrial, multifamily, etc (That they aren't well versed in). Usually I've noticed 20% (of the commission) is about the standard fee if you get them a listing. Most often however referrals aren't concrete and no sale actually comes out of it. This is because you have to convince the owner to sign a listing with the person you are referring and they are probably already getting contacted by competing brokers who already specialize in the space. I've only had 1-2 referrals work out for me. You'd want some kind of way for agents to list their specialty and maybe a list of done deals (of that property type) to show experience. I've noticed on the commercial side that Generalists (Who do everything) NEVER get referrals. No one will refer for example the sale of an office building to an agent that lists everything, the refer to the office broker who specializes in it. I have an idea for a Real Estate site (I've put it on the back-burner) that nobody is doing right now because from my experience the tech savvy guys who can build this kind of thing are not privy to the high end investment sales market (Investment properties that are at least $2 million) There is a certain culture and way of doing things that isn't really easy to understand unless you've worked in it.

<comment><USER12> I work in R/E Analytics, email me: email@example.com

</comment></comment></comment></comment></comment></comment><comment><USER13> Hey Derrick,

Thanks for the great posts and for responding to comments!

Would love some feedback on choosing to raise money or not. I read this post (and many others) about having those filters ready ahead of time. The filter on raising money unfortunately I don't have, I keep going back and fourth on that.

I have been working on an app, cross platform iOS and Android, that lets people listen to articles from the web. It uses great sounding AI ML to convert the articles to audio you can listen to in seconds.

I have been working on it for a few months have some good traction and a few paid users, working on it part time as a side project. I can't help but feel that raising money would allow me to go full time and really concentrate while still affording my bills. The issue is VC money comes with strings.

(Shameless plug for anyone interested, the product is here [https://articulu.com](https://articulu.com) )

<comment><USER14> Your website looks great. I didn't try the product. Can I ask how you did the design and UI of your landing page? Did you do it yourself or contracted someone to do it?

<comment><USER13> Thanks for the feedback, we did everything ourselves. Two of us on this with developer backgrounds.

</comment></comment></comment><comment><USER15> Completely unrelated...

When developer makes a blog, and it has UX well done, it is amazing. Site looks good from the outside, as well as inside the source, nothing insane, but you can see quality.

I am inspired now to make my own, that lays neglected for long time.

Oh, now I see that he is using Elixir, Elm, Phoenix etc... All the good stuff. :) Clearly a person with great taste.

<comment><AUTHOR> Thank you! It happens to the best of us, I haven't been super consistent with writing regularly. Trying to change that!

</comment></comment><comment><USER16> This is a great article. I'd advise any entrepreneur to read this, including myself 6 years ago.

</comment><comment><USER17> I'm trying to launch a graphql hosting business on gqlengine.com .. validating whether there is a "market" is too hard for me to figure out it seems! If anyone is interested to partner and work with me on this, shout out at me @ak_kim0

</comment><comment><USER18> Good luck! Love listening to you and have been following your journey for a long time. I'm here to listen and watch what you build next. Who knows maybe I'll be a customer.

<comment><AUTHOR> Thanks! Glad you are finding it helpful!

</comment></comment><comment><USER19> Correct link: [https://www.derrickreimer.com/essays/2019/05/28/finding- my-n...](https://www.derrickreimer.com/essays/2019/05/28/finding-my-next- bootstrapped-business-idea.html)

<comment><AUTHOR> Thank you! I also added a redirect from the previous URL.

</comment></comment><comment><USER20> I find articles like this deeply disingenuous. The OP wants to basically find some problem that he doesn't know anything about, and apply whatever knowledge he has gained in hopes of building a "company" which appears to me is just a facade of a company until he can flip it to someone else who actually cares more.

The idea that someone with presumably no knowledge or even any passion can dip their toe into a problem space and try to create a "company" isn't very appealing to me at all. Everything about it feels so superficial and contrived with no passion.

Even the list he came up with is so low-hanging-fruit, it reads to me "I want something that is easy to build, easy to sell and makes me lots of money before I flip it to someone else, and then I can start the process again."

The lack of commitment and conviction screams to me that I shouldn't become a customer because he will abandon the project, and end it with another "Thanks for following me on my journey, I'm abandoning all my customers but join me on my next adventure soon!"

<comment><AUTHOR> Ouch. That's not at all what I'm trying to do. I have no shortage of passion, but passion alone does not make a viable business.

My hope is that my post will help others think about choosing an idea that fits with their goals, so that it will work out for the long haul.</comment></comment>


Ask HN: What's the Legality Around Web Archival? - <AUTHOR> What's the legality around Web Archival ? Is it possible for a startup to grow around web archiving, or a business to build APIs which allow pages to be archived ? <comment><USER2> Archive.org has a special exemption via US copyright law, I believe, and other parties will not have the same exemption.

I imagine it would be very difficult for someone to start a website which hosts a lot of copyrighted material and claim they are genuinely archiving copyrighted material. This would be the defense of every piracy site ever, if it were feasible, I imagine.

I am not a copyright lawyer, and I welcome correction on this.

Developing an archival API for those who want their site archived is perfectly fine, though this is probably what robots.txt is for.

<comment><USER3> I don't think there is such a thing as a special exception to copyright law given to one website.

There is fair use.

I think what happened with archive.org is that it became popular, and also popular to think of it as fair use. It's a social phenomenon of acceptance that does not have any legal bearing.

Companies that don't want their stuff 'archived' can and do take action to enforce laws about digital libraries. For example the book that helped teach me programming was Turbo Pascal DiskTutor. You cannot simply download that one on archive.org. You have to get on a waiting list and 'borrow' it when it's available.

The fact that they made it so there is apparently exactly one digital copy available for 'borrowing' makes me feel that the digital library laws are invalid. It should not be legal to enforce only one copy total when it is possible to make it ten just as easily.

Anyway, there are lots of sites like YouTube that would not exist without encouraging users to violate copyright. This was the whole reason YouTube got big in the first place. It was only after they had a massive library of content and users that they started really playing ball with distribution companies.

<comment><USER2> > I don't think there is such a thing as a special exception to copyright law > given to one website.

An example of an exception obtained by the internet archive:

[https://archive.org/post/82097/internet-archive-helps- secure...](https://archive.org/post/82097/internet-archive-helps-secure- exemption-to-the-digital-millennium-copyright-act)

<comment><USER3> They hired people to amend the regulation and succeeded, but like I said, its not specific to "the Internet Archive".

</comment></comment></comment></comment><comment><USER4> If you plan to do such a thing, consult a copyright lawyer first. You won't get reliable advice here about the law (speaking as an attorney myself...). Don't build your business copying other people's stuff unless you really know what you're doing, lest you end up like Napster, MP3.com, or a bunch of other startups that were sued into oblivion.

</comment><comment><USER5> One of the biggest companies in the world did it. Starts with a G.</comment>


10 Spock invites available: ping me in comments - <AUTHOR>

<comment><USER2> _"10 spock invites" and no_ link with invites _or email address is ill- logical. Having received personal spock invite via email is not_

having said that, here's my first impression

\- signup: email + firstname + lastname

\- find friends: plaxo, gmail, gmail, aol, yahoo, hotmail \- control identity: works off existing social sites (myspace, linkedin, friendster sites, gmail, yahoo & aol email)

\- log in, pwd

\- vote on if details are correct (social voting on your details?)

\- add personal info ... tags, sites, bio, name, age, dob, address

Searching: Ho hum. Lots of dead people are listed. Quick search on names I found lots of _inflated_ cv-like & MySpace entries. Maybe thats why the _vote_ is added to allow checks & balances to occur. Laugh at people who are not me.

</comment><comment><AUTHOR> Need a first name & last as well as your email.

or write to carlos -t- bueno -d- org if you don't wanna be an exhibitionist.

<comment><USER3> Kyro Beshay, email@example.com</comment></comment>


How to reduce the cognitive load of your code - <AUTHOR> http://chrismm.com/blog/how-to-reduce-the-cognitive-load-of-your-code/ <comment><USER3> There are so many similarities between writing code and writing English.

\- Thinking of paragraphs as functions with one purpose

\- keeping sentences short to reduce load on working memory and increase comprehension

\- create visual breaks to help the reader by grouping common stuff together as mini-functions

\- reduce intimidation factor of reading by removing convoluted stuff

\- remove cognitive noise (dead code, unnecessary comments, variables declared out of context or too soon etc.)

\- keeping terminology consistent across the code (domain language)

\- not using double negatives e.g a = !notLocked

\- using automated systems to simplify expressions (e.g weird boolean conditions [http://www.wolframalpha.com/input/?i=a+%26%26+b+||+c](http://www.wolframalpha.com/input/?i=a+%26%26+b+||+c) )

etc.

Unlike English, it is less difficult to have a program reorganize your code to make it more readable based on a set of cognitive principles.

But, beyond the readability and understanding of a function, we should also learn from other engineering fields. For example, system thinking helps tremendously in organizing code if the cost of refactoring code wasn't so risky in dynamic languages.

<comment><USER4> I agree with everything you said. As an old Perl guy, I found it hilarious that Perl has a reputation for illegibility, while I find it easier to read than most Java, because in Perl I can express my intent, and in Java it's buried in the noise.

One cognitive problem I've not yet found a good solution to:

So I have a high level routine to, say, sort the items in a display. Said sorting has some cascading effects, so I'll have a high level function that calls some mid level functions that call some lower level functions.

But at some point I get a name clash between a high level function and a low level one. Like...I'm calling the high level sortDisplayedItems, (or sort_displayed_items) and there's a low level function that ACTUALLY sorts them (as opposed to handling the other bits). Sure, I can give it a distinct name (e.g. sort_items), but when skimming the code, it's unclear which is which. If I have to mentally parse the code to understand what is happening, I've failed at readability/maintainability.

How have others handled this?

<comment><USER5> One approach that can help is to name things based on what the functions actually do.

      validateSortDisplayedItems
      {
       validation Logic
       ...
       sortDisplayedItems(); //Actually sorts items.
      }

This can be harder to maintain, but really long names end up a useful code smell.

<comment><USER4> I find it a bit...incorrect.

I mean, your above code LIES. If I call validateSortDisplayedItems, I don't validate, I validate AND sort. Plus, what do you do if you have "validateItems" and "sortItems", and then one function that calls them each in turn? call it "validateAndSortItems"? Yuck.

<comment><USER5> Depends on the Validation Logic. I like the style that basically works like this:

      validateSortDisplayedItems
      {
       if(!DisplayedItemsValid())
       {
         CorrectDisplayedItems();
         if(!DisplayedItemsValid())
         {
           DisplayValidationError();
           return;
         }
       }
       sortDisplayedItems(); //Actually sorts items.
      }

AKA validate means try and make valid, not verify that data isValid. So, you can't just do if(isValid) sort; the bonus is unrecoverable errors end up at leaf nodes vs. the happy path.

At the high level, your function might be sortClicked, which can then respond to that by calling a wide range of functions. (userCanSort,SortData,UpdateDisplay)

PS: I find the validate > correct loop is generally the important and error prone part of code, so I give it priority. The happy path where everything works is more or less an addendum.

</comment></comment></comment></comment></comment><comment><USER6> Code clutter is much more consequential than it gets credit for. Poor formatting, inconsistent whitespace, snips of unused code, and misleading filenames are speedbumps (or worse, spike strips!) that a developer is going to hit every time they sit down to code.

And unlike bad abstractions -- which you can "learn" about and mentally model -- the friction of clutter is a constant damping to your productivity.

Building features in a cluttered codebase is like being asked to install plumbing in a hoarder's basement.

Understanding a cluttered codebase is like reading an advanced math textbook by candlelight that was written with broken typewriters by a group of modernist poets.

De-cluttering is the first thing you should do, and you should stick to it above all else. Before you add tooling, before you refactor, before you abstract and framework-ize, get rid of the clutter. That means format your code, and use a linter whose rules are based on widely adopted community conventions.

<comment><USER7> What's a Linter?

<comment><USER8> It's a tool that finds things that aren't strictly errors in your code, but are likely to cause problems.

see also: [https://en.wikipedia.org/wiki/Lint_(software)](https://en.wikipedia.org/wiki/Lint_\(software\)) (this article refers to one particular (original?) lint tool, but there are numerous others for various other languages)

</comment></comment></comment><comment><USER9> I used to think that a lot of bad code out there was made by lazy, incompetent programmers...

But then, after a certain job, I realized that this is probably not the case.

Now I belive that most bad code out thare is made by overworked and tired programmers in a rush to deliver something that works.

<comment><USER10> Most of the bad code was made by very productive developers.

<comment> maze-le This leads to the question what 'productive' really means. If a productive programmer writes a lot of code that isn't maintainable at all, can you really call that person productive? Maybe... but the poor sob tasked with maintaining the code later, will certainly not be called productive.

Maybe productivity should not be regarded isolated from other metrics and/or certain style-considerations.

<comment><USER11> What is the true measure of productivity? If you include things like maintenance and other developers' time are they really being productive? There's individual productivity and team productivity. Also a quick one time job is different than something that needs to be maintained. Everything is relative to the goals.

</comment></comment></comment></comment><comment><USER12> Like often with this kind of article it barely scratches the surface.

"null != variable" will confuse people is downright silly. People confused by this won't have an inkling of what any non-hello-world program does.

The rest has some validity, but it focuses on syntax and programming in the very small. It might take a bit of effort, but I can make sense of a tangled function (that's not an excuse to code sloppily though).

The real challenges are architectural: understanding how an application is structured is often a daunting task, and yet there are some very simple things one can do to combat this, starting with grouping things thoughtfully, generous pointers in the documentation, and a few paragraphs of architecture overview in the readme file.

<comment><USER13> yeah, I'm not even sure what's suppose to be confusing? That the "constant" comes first, before the comparison operator?

<comment><USER14> Yoda speak, it is confusing like. Most people think "if the variable is not null" rather than "if null, the variable is not". It's easy enough to adapt to the style if it's used consistently throughout a code base, but that effort yields no benefits in most languages.

<comment><USER15> _Most people think "if the variable is not null"_

Only because this is how people are traditionally _taught_ to think. This can be untaught easily enough.

<comment><USER16> So you can unteach your developers to think... for what purpose?

</comment></comment></comment></comment></comment><comment><USER17> "Avoid using language extensions and libraries that do not play well with your IDE. The impact they will have on your productivity will far outweigh the small benefit of easier configuration or saving a few keystrokes with more terse syntax."

This is the main reason to avoid Spring.

Having so much critical code in XML and properties configuration files, annotations, and magical interfaces that somehow sprout implementations with no source code, make it impossible to debug using the normal techniques of Java development.

"Show me all of the implementations of this interface method"

"Show me where this object is instantiated"

"Show me the code being invoked when I call this method"

In my day to day work, Spring's only purpose often seems to be hiding the code that will actually execute when my program runs.

<comment><USER15> Because it is much better to let misspellings get caught during run time than compile time. /s

Same with a lot of the DI frameworks that were so popular for a while. New guy doesn't wire something up correctly, checks it in and everyone spends the next 3 hours debugging a rabbit hole. (OK, slight exaggeration.)

<comment><USER18> I spent 3 weeks on a spring rabbit hole as a new dev. Not exactly the easiest thing to get a hang of.

</comment></comment></comment><comment><USER19> If I was to describe the essence of clean code in one word, I would say "balance".

Yes, yes, readability and problem separation and stuff is important, but so is efficiency and usability and security and deadline and everything. Bottom line: balance.

And it's the hardest thing to achieve.

<comment><USER20> I've always worked through the idea that "Extremism is harmful".

Literally anything taken too far is a bad thing. And just about everything in life is a matter of finding the right balance.

</comment></comment><comment><USER21> No one ever mentions formatting.

I really like aligning multiline blocks, adding whitespace and useless braces here an there. e.g: Having just a single space between function name and arguments makes it look less like a call. Yet almost all lint presets/defaults forbid this. Typography is all about the whitespace between letters forming easily recognizable shapes.

<comment><USER22> All this is solved by a linter though, there's no point even trying to remember this, just define your linter rules and let it deal with it.

It might not be the default linter styles, but set up your linter for your project and give your mind more important things to focus on.

<comment><USER23> A linter is also a great way to jump start learning a new language. If you encounter a warning that doesn't make sense to you, look it up. You'll start to get familiar with common language pitfalls without actually getting burned by any of them.

</comment></comment></comment><comment><USER24> 'Avoid using language extensions and libraries that do not play well with your IDE'

I'm of the opinion this should be extended to "does not play well without an IDE". Because even in projects that said "everyone, use Eclipse(/IntelliJ/whatever)", and tried to share project files, there was constant pain in ensuring that everyone had the same development environment ("Oh, yeah, I made a local change to my project file, but then I also made a change that needed to be shared, and whoops, I broke everyone" and the like). Not to mention trying to work with code deployed onto boxes without an IDE. I've gotten to where "if I can't make sense of it and be productive in it with just vim, grep, and find, your code is too complex".

<comment><USER25> Well, sure, but that's why you don't share project files.

I think that if you do things correctly, your concern is mostly mitigated. My last job was Java/Spring. As someone noted above, you really don't want to be working with Java/Spring _without_ IntelliJ.

But we never had issues with anyone breaking builds due to screwing up project files, because those weren't shared and the project would run/build/test immediately after import into the IDE without any additional tweaks.

I think it's sort of odd that many folks complain about IDEs, but then use vim with a million plugins. Isn't vim + plugins = IDE? Or, if the overall point is "java sucks, don't use java" then fine, but if you _have_ to use it, I couldn't even imagine using plain old vim without any language support...

<comment><USER24> Sure. Does it require a specific IDE then? Does it cleanly import, from scratch, with working tests and etc, regardless of whether they're using Eclipse, IntelliJ, Netbeans, etc? Or is there One True IDE? Is that IDE available everywhere you have to touch code? Is it straightforward to integrate it with your CI/CD tools, despite conforming to that IDE convention? Will it continue to cleanly import after you've left the code to rot for a couple of years in production, and then have to come back in to maintain it? Etc. I've been bitten by all of these.

Whereas I've gone to projects that were written without all of this, and even without getting the code to even compile locally (because of dependency hell that I didn't want to suffer through if I didn't have to), was able to diagnose and fix issues, because the code was written to be understood with only a text editor.

<comment><USER26> The idea is that you still conform to the convention of the project (Rails, Spring, etc.), not the IDE, and the FOSS CLI tools etc. can still understand the project, but so does the IDE (because it is made to understand the convention, e.g. how the annotations/XML files work, how to get a list of all your Rake tasks).

By not sharing IDE project files, not having any IDE-specific machinery in the project, but still expecting CI to be able to run it, being able to theoretically hack on the project and get results (build, test) even with just bash and grep and nano, you get the best of both worlds.

Modern IDEs are better at this than they ever used to be. I was really anti- IDE for a long time, but JetBrains' products made it make sense finally.

</comment></comment></comment></comment><comment><USER27> I didn't appreciate how much of a difference it would make until I tried it, but now I know that one of the best ways of making code more comprehensible is to eliminate any questions about interactions between components by using a language with referential transparency. The results of functions should be determined solely by the values of their arguments, with no contamination by shared state and no side effects.

<comment><USER28> In other words, a pure function.

[https://en.wikipedia.org/wiki/Pure_function](https://en.wikipedia.org/wiki/Pure_function)

<comment><USER27> In mathematical words, a function.

</comment></comment></comment><comment><USER29> Biggest thing for me: have a small number of fundamental, composable abstractions. Be able to reason about how their properties interact when you combine them.

This is the main reason that Haskell is such a force multiplier for me. All the small minutia is well defined and it frees you to think about the big picture. Sure, it's a big learning curve, but so worth it :-)

</comment><comment> awinter-py The variable name you choose when writing a function may not make any sense when reading it a month later, or to a third party. These rules are as useful as feng shui -- if you have a good design sense, you can produce good results with FS.

The readability wins I've seen come from using common tools; I'm going to be much more productive on a codebase written in a library ecosystem I understand. More generally, a powerful standard library with consistent calling conventions can help a language be useful. It's not productive for me to spend 10 minutes reading a function only to realize 'oh, this human wrote their own string split'.

Tests help too because they make clearer the dependent typing of a function's call signature; stuff like 'don't pass both of these variables' or 'a must always be > b' are never clear (and I've never used a design by contract langauge). Tests are sometimes better than documentation because you can sometimes get alerted if they're wrong.

Most important rule for readable code: hire programmers who know how to read. Reading a large project is a skill and lses people can read than write code. Every project is going to have a quirk of its evolution that's hard to understand without a close reading. (Every large C project contains a buggy partial implementation of LISP). Hire programmers who can survive that.

</comment><comment><USER30> I spend a lot of energy discussing this at work, and mostly that has been "continue talking while people look at you like you have two heads"

It feels like maybe people are almost ready to listen now. I don't know how this relates to the number of libraries we use now, or the StackOverflow culture, but I have my suspicions that they are related. Maybe we should start talking about Library Fatigue...

</comment><comment><USER31> Not sure I can say I always write clean code but when I do, in non-trivial cases, I often start to write a comment, delete it and replace the code I wrote with something that does not need a comment... I suppose it only works for people who (think they) know(s) what good code looks like, but (I think) it works as a good guiding principle (for me).

<comment><USER32> This is one of my guiding principles too. If I find myself wanting to comment the code to make it clearer or understandable, I refactor the code.

The one time I let comments slide is when they document unexpected and unavoidable behavior that I can't fix in code. For example working with an inconsistent data set and having to add some convoluted code because what is a string in 95% of the rows might parse as a tuple in the remaining lines, so I need to account for that. This is so that I, or the next guy, knows why the code was written as such and won't go off trying to fix it.

</comment></comment><comment><USER33> Developer cognitive load is one thing that kills projects, teams, and, eventually organizations. In the various companies and projects I've worked on, you can usually spot the culprit: a single person, or small group of people who take pride in making things more difficult for others to understand, or actively creating insider systems that serve to entrench themselves and make them seem important and the center of attention.

</comment><comment><USER34> He advocates prefixes on variable names. I would like to see good examples of this as I have never seen them as helpful (especially the tblUsers and intUserId type that can be common) .

<comment><USER35> Christian points to Joel Spolsky's example of using prefixes to add meaning, not type information like your examples. From Joel's essay:

 _All strings that come from [user input] must be stored in variables (or database columns) with a name starting with the prefix "us" (for Unsafe String). All strings that have been HTML encoded or which came from a known- safe location must be stored in variables with a name starting with the prefix "s" (for Safe string)._

        us = Request("name")

        ...pages later...
        usName = us

        ...pages later...
        recordset("usName") = usName

        ...days later...
        sName = Encode(recordset("usName"))

        ...pages or even months later...
        Write sName

_The thing I want you to notice about the new convention is that now, if you make a mistake with an unsafe string, you can always see it on some single line of code, as long as the coding convention is adhered to:_

        s = Request("name")

_is a priori wrong, because you see the result of Request being assigned to a variable whose name begins with s, which is against the rules._

[1] [http://www.joelonsoftware.com/articles/Wrong.html](http://www.joelonsoftware.com/articles/Wrong.html)

(edit: formatting, citation)

<comment><USER36> In modern type systems (Haskell, etc.) you can define a new type that wraps an existing type with zero runtime cost. In Haskell you could write

newtype UnsafeString = Unsafe String

(UnsafeString is the name of the type. Unsafe is the constructor you use to create an UnsafeString from the String).

With this and other techniques you can lift these characteristics of you data into the type system, which is IME much more useful than using hungarian notation.

<comment><USER37> I don't think the Haskell typing system is powerful enough for completely replacing prefix labels.

Marking something unsafe is a best case scenario. Separating lines from rows would require a huge amount of boiterplate to preserve the numeric operations, and one still can not create a library that will check something like:

        let
        l = 5 :: Meter
        w = 4 :: Newton
        in l * w :: Joule

<comment><USER36> Representing constraints in the type system is always an engineering tradeoff ---how much type level machinery do you want to build vs the effort required to build that?

Not sure what you mean by separating lines from rows. In the example you give of computing with units, I've seen examples of such systems in Scala (e.g. [http://www.squants.com/](http://www.squants.com/)) and F# comes with something built-in for this (IIUC). You might be interested in checking them out; it's quite neat.

<comment><USER37> > Not sure what you mean by separating lines from rows.

It's the example Joe Spolsky used on the blog post about prefixes that everybody keeps pointing to. He showed code that worked on rows and columns (not lines, sorry) on a table, using prefixes to avoid mixing them.

Haskell types do support this use, but you'll have to declare both types as Integral and Numeric, with the resulting boiterplate. I'm not sure exactly how to solve this, maybe a way to "lift" typeclasses out of a newtype declaration would be general enough. It is probably possible to do with template Haskell, but that is already outside of the language.

That Scala library is interesting, although it looks like lots of the work is done at run time. Also, it looks like Haskell is able to do it [1]. (It's a recurring theme of mine, to complain that something can not be done on Haskell, just to discover somebody that did it.)

[1] [http://hackage.haskell.org/package/dimensional](http://hackage.haskell.org/package/dimensional)

</comment></comment></comment></comment></comment></comment><comment><USER11> I've thought about this quite a bit from a language design standpoint. I've come to realize the following:

1) Reduce the number of variables that need to be kept track of in order to make a function easier to understand.

2) Avoid metaprogramming unless there is a clear need for it (doing something over and over).

3) DRY isn't always good. Sometimes being more verbose is easier to read than being clever so you don't have to type as much. Concentrate on readability first.

4) When there are a lot of interacting components consider the DCI pattern. It will save the developer from bouncing from file to file, module to module, just to understand the flow of an algorithm. Each time a developer needs to look up a different file more cognitive load is introduced. An algorithm should be easy to follow in a single file with code in sequential order. The opposite of this is message passing and having components pass messages to other components.

5) Syntax matters. Unfortunately once you choose your stack there isn't much you can do about this. Some syntaxes are much noisier than others. Every little bit of noise adds more cognitive load. Don't believe me, try do long division with Roman numerals.

6) Compress complex concepts into shorter ones. This builds on the Sapir-Whorf hypothesis. This might be a moving a part of an algorithm into its own function or storing an intermediate state in its own variable (as opposed to function composition 4 levels deep). `map` is much simpler to understand than `for (var i=0; i<arr.length; i++) { doSomethingWith(arr[i]) }`.

7) Spend time getting to know your editor. When you can reduce the amount of muscle movement required to perform an action it generally reduces the cognitive load as well. Not to mention making you more productive.

</comment><comment><USER38> One thing I like which nobody ever seems to mention, is that when you divide your code into smaller functions it helps to have your functions actually take inputs and give outputs. It is very hard to read code which is just line after line of functions taking no arguments and returning nothing. No matter how descriptive your method names are, it will just end up being more confusing than if you simply wrote out all the code contained in those functions instead.

People need to see how the code flows and how things are logically connected. That is impossible to do with reams of methods operating exclusively on member variables.

I guess this is just another way of stating the benefits of functional programming. People do modularization at the function/method level so badly so often that I often think talking about modularization at class level, is beginning at the wrong end.

So many struggle with modularization at small scale.

</comment><comment><USER39> Honestly, while I love these articles as food for thought, they really aren't the solution to the problem.

In my experience, programmers generally have a sense of what parts of their code need to be cleaned up. If they are a newer developer their ideas might be a _little_ screwy. They might not see the root problems, but they know which closets are producing ghouls.

The issue I see is that developers don't think refactoring is a good a use of their time, or someone up the food chain doesn't think it's a good use of their time, or there's just so much institutional inertia making people question whether it's a good use of their time.

If you want your code to be better though, don't read about architectural problems, just take some time to fix the stuff you know is bad in whatever way you know how.

That's better than any article or class and it pays you money and it makes your code more fun.

</comment><comment><USER40> I've found that diagrams help. Young developers (in my experience) tend to laugh at the thought of making UML diagrams. At the very least, a class diagram will tell what classes references what. Using some custom stereotypes can help give further meaning.

Ideally, sequence diagrams (or a similar type) can help shed light on just how the project comes together. Explaining how a project works from a high level can leave unintended knowledge gaps. The great thing about these diagrams is that they can largely be automated with very few inaccuracies.

Diagrams are definitely now a silver bullet. I have found that they can easy grow unwieldy when attempting to incorporate too much information into a single diagram. Much like separation of concerns or the single responsibility principle, I believe that diagrams work best when they're focusing on a single piece of major functionality.

<comment><USER41> What is a stereotype?

<comment><USER40> Stereotypes are an extension of UML to include extra information about the class. This[1] is a class diagram (albeit, overly detailed) I created for a library that we used. Above the class names are stereotypes. I know which classes came directly from the library, which are service classes, etc.

[1]: [http://i67.tinypic.com/33xyaz4.png](http://i67.tinypic.com/33xyaz4.png)

</comment></comment></comment><comment><USER42> one programming style that i think makes things worse is the "how many calls can i make on a single line" programming style.

      MyObjecter.GetObjectRelatativeThingy(ThingyHolder.WhatsMything(IndexKeeper.Get(), OtherWhatsIt.BuildOther( MoonCheese.Intensify(true)))

It's probably a result of the letterbox effect of widescreen monitors and IDEs with horizontal toolbars and status bars.

Is there anything wrong with expanding the idea of 'one purpose per function' into 'one purpose per line' and split it all up into multiple lines with temp vars inbetween.

this gives you benefits of:

\- short lines and simple ideas

\- easier to set break points

\- allows for adding logging between calls.

\- allows for setting debug watches on the temp vars

\- the compiler tidies any temp vars away so there shouldn't be any extra copying.

<comment><USER32> I like Raymond Hettinger's idea of one _concept_ per line. Sometimes that means having two or even three functions on a single line, sometimes one.

</comment></comment><comment><USER43> Would recommend reading 'Code Complete' than this article

<comment><USER34> He does reference it in both the first and last paragraph!

my fave is clean code... though uncle bob seems divisive these days for some reason.

[http://www.amazon.co.uk/Clean-Code-Handbook-Software- Craftsm...](http://www.amazon.co.uk/Clean-Code-Handbook-Software- Craftsmanship/dp/0132350882)

</comment></comment><comment><USER44> The article is well-intentioned but misses the point in a few places. For example, the suggestion to have, in an MVC project, three top-level directories: one each for models, views, and controllers. This works fine for small projects, but larger projects can see significant benefit by keeping related code together. As with everything, it's a judgment call. The simple "one folder per type of thing" rule may not be applicable in all situations.

<comment><USER45> Yeah, where do you add queues, events, observers, helpers, traits, interfaces, etc.?

<comment> awinter-py Each of those should be a separate module uploaded to NPM. That was the versions can vary independently (for max compatibility).

This technique is named 'carbo-loading' (because of all the spaghetti).

</comment></comment></comment><comment><USER46> Its not about understanding a line of code - anybody can do that. Its about absorbing kilo-lines of code and gaining an understanding of the whole thing. Without having to draw attention to every line.

I can read code by the page, hitting next page at about a 1Hz rate. If the code is not overheated. That means, avoid lots of syntactic bloat, keep it concise, keep it modular, with low branching. Just about what the OP says.

</comment><comment><USER47> One thing I appreciate about .NET are the conventions around project structure. When digging into an ASP.NET project I know where I can reliably find assets, models, views, and controllers. Also like conventions like prefixing interfaces with "I". Little things but makes diving into random codebases easier as a Java developer.

</comment><comment><USER48> +1 for avoiding frameworks and extensions that don't play along with the IDE. I've only recently realized just how much the supposed productivity gains of those tools evaporate when your workflow gets bogged down.

</comment><comment><USER49> Very good

Until you have some code reviewer that thinks otherwise because of some "stupid reason" and you can't get around their hard heads.

One example, breaking a 81 char line because it goes over the limit and getting two shorter lines that are awful to read

So yeah I'll go for this when I'm working with reasonable people

<comment><USER50> So, what do you do if you get a job with Java or iOS and 30++ char method names?

(Not being snarky, I would like to do some iOS development for fun but want lines under 78 chars, so it don't go over 80 with diff.)

<comment><USER51> Sorry, it's just not practical to keep lines under 80 characters in some languages.

</comment></comment></comment><comment><USER52> Good advice, but it still seems like just cosmetics compared to the real brainkiller: (incidental) complexity.

It's kind of how legible handwriting is desirable, but not really the most important factor, when it comes to the amount of brain required to solve a math problem.

</comment><comment><USER53> > There are four main concepts I will talk about here.

There are 5 concepts in the article. Off-by-one error? :)

<comment><USER54> Cognitive load is a harder problem than we give it credit.

</comment></comment><comment><USER55> Is there a program that rates other programs in terms of Flesch Kincaid score or the equivalent? Old Man and the Sea F-K score is 4. Code isn't much different than other writings. I prefer to read code written like a Hemingway.

</comment><comment><USER56> Some good tips in this article but for me the problems usually start when I have to tie two or three APIs with different coding conventions together.

</comment><comment><USER57> Nothing about division of concerns and organization?

</comment><comment><USER58> Even the first example is a bit silly. Nobody is going to not understand that (null == foo) is the same as (foo == null).

<comment><USER59> It does increase the cognitive load for no particular reason. Which is what the author is trying to avoid.

<comment><USER60> It's the difference between, say, length(foo) and foo.length() - <USER2> difference in cognitive load should be lost in the noise next to "this variable can be null".

And given most languages in use today use = to mean assignment instead of equality, it's hardly "no reason".

<comment><USER18> Except if you do if(foo = null){} it won't compile in java which is exactly what you want to happen. So using it in java is just cognitive load and provides 0 benefits.

<comment><USER61> Habits are hard to break. Switching back and forth between habits leads to mistakes. There's a trade-off here. I'm not going to say one is definitely worth it vs. the other, but if we pretend the disadvantages of one option don't exist, we lose the ability to make appropriate judgements.

<comment><USER18> I guess I didn't think about people using C/++ and Java together regularly.

</comment></comment></comment></comment></comment></comment><comment><USER62> Isn't this just a fancy phrasing for "make your code easy to read"?

<comment><USER63> +1 This whole blog post reeks of elitism and over confidence.

The blog post over states its own importance as after learning these clean code would be easy. Like fade diets, magic paradigms etc... another example of someone believing or trying to convince others that there is a "magic path". "Just remember these four concepts", "get a six pack with just 20 minutes a day"...

There are a few good tips in here but really nothing new. A nice reminder that there are some simple steps to help improve your own code.

A large devil of clean code is not just in nitty gritty "have one line per logical action" but rather the deconstruction of a problem into easily followable steps.

In that way this is definitely not an exhaustive description.

</comment></comment><comment><USER64> The best way to minimise the cognitive load is to always use DSLs.

<comment><USER65> Especially if there are objects that correspond to something real.</comment></comment>


What is the 'legitimate interests' basis? - <AUTHOR> https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/legitimate-interests/what-is-the-legitimate-interests-basis/ <comment><USER2> Without any precedent on concrete examples of what is legitimate and what is not, this clause in the GDPR is its biggest weakness.

If a company sells something online they only really need your address & name for delivery + credit card details. Then you could argue it is legitimate to use an email to create an account, fair enough. But without precedent it's so easy to just say 'in order to increase revenue (legitimate intrest) we're going to use all emails to send a newsletter, boosting sales'. And then you could use the 'Right to object' in the GDPR as a fallback for your actions.

I know of multiple companies where they prior to GDPR asked for explicit concent during signup for being allowed to send newsletters, but who post-GDPR dropped the concent and use 'Legitimate intrests' to justify it. Basically leaving the individual worse off.

<comment><USER3> I forget where I saw it, but I thought this was a good test of whether it is legitimate interest. It went something like:

"Would a 'reasonable' person be surprised if you told them about how you were using the data?"

<comment><USER4> That scale slides around every day. And 'being surprised' and 'being happy' are very different things also.

I'd prefer to have hard limits. No collecting any info from my computer about me that aren't explicit in the interaction itself (asking for email is ok; scraping installed apps while doing that to gauge my interests is not)

<comment><USER5> "Reasonable person" tests are pretty common and well-understood in general. One of the reasons that the GDPR in particular avoids being overly prescriptive about _how_ to meet its requirements is to avoid situations where it becomes inapplicable or obsolete due to changes in technology or habits.

<comment><USER6> In the US, a reasonable person test is meaningless without a body of precedent setting cases.

If the language of a new law uses it with regards to a new technology, then no one can be sure what the courts will decide.

It may be different in the EU, as the legal system is quite different.

</comment></comment></comment></comment></comment><comment><USER7> I love that completely hypothetical example of a public figure on a train making a political point.

[cough] [https://www.bbc.co.uk/news/uk- politics-37167700](https://www.bbc.co.uk/news/uk-politics-37167700)

I mean why bother attempting to obscure it when it's such a commonly known about case.

<comment><USER8> Important to point out that the VM rebuttal has been debunked and most of those supposedly empty seats have children and shorter people in.

That choice to mislead the public makes it a bit of a weird example to use by ICO.

</comment></comment><comment><USER9> Note that this only addresses the _lawfulness_ of the processing under Article 6 GDPR, which itself is only one of the required _principles_ relating to the processing of personal data that must be upheld under Article 5.

Other principles that must be upheld, for example, are _data minimization_ (lit c) or _storage minimization_ (lit e).

I know that one of the supervisory authorities has already ruled that the principle of data minimization trumps the lawfulness argument of "legitimate interests" in certain cases. Certain records must be destroyed when the legally mandated terms for keeping them have expired (eg 7 years).

</comment><comment><USER10> Hackers becoming lawyers, journalists becoming hackers! xD

</comment><comment><USER11> Facebook's ability to not allow you to opt out of personalised advertising is the white elephant in the room, and a clear sign that GDPR is not sufficient.

<comment><USER12> Who says that Facebook is compliant?

Enforcement hasn't really started yet, but what I've read is that they are preparing some pretty big cases.

<comment><USER13> In fact, Max Schrems (who previously got FB to start giving people access to their data) has filed a complaint hours after the GDPR went into full effect: [https://www.irishtimes.com/business/technology/max- schrems-f...](https://www.irishtimes.com/business/technology/max-schrems- files-first-cases-under-gdpr-against-facebook-and-google-1.3508177)</comment></comment></comment>


More on Postgres Performance - <AUTHOR> http://craigkerstiens.com/2013/01/10/more-on-postgres-performance/ <comment><USER2> Worth reading. I had no idea you can do conditional indexes. Is that something other dbs support? (looks like mysql doesn't)

<comment><USER3> I think postgres calls them "partial indexes". See [http://www.postgresql.org/docs/9.2/static/indexes- partial.ht...](http://www.postgresql.org/docs/9.2/static/indexes-partial.html)

... and they're great! Postgres is very smart about using them, too, so they can be a lifesaver when you have a large table of which you only [typically] use a small bit.

I've created partial indexes over geospatial data. There are 1M doctors in the US, so answering the question "how many doctors are in San Francisco" requires a join between indexes of all doctors in the US and all businesses in SF. Using partial indexes, we carved up the country into a bunch of polygons and were able to frame the question as "how many doctors are in San Francisco in polygon 34?". Much faster.

<comment><USER4> I've actually seen cases where a partial index can cause query performance to fall on its face.

Just recently, we had a case with a partial index where the predicate was a boolean field, but the indexed field was a timestamp, sorted descending. The planner chose that index when given a query that had an ORDER BY ... DESC on the timestamp, and query times spiked several orders of magnitude. Dropping the index (which was only used by that query) caused it to drop from 2.5s to .7ms.

Yes, indexes are that powerful.

<comment><USER5> Because of irritating query planner outcomes like these, I've always wished postgresql just offered an API where you hand it the query plan. It seems like the bulk of questions from experienced users of postgresql (and all other SQL databases, really) relate to how to express the query to the planner does what you wanted it to do in the first place. Seems easier to just hand it the plan when you know what you want.

<comment><USER6> Oracle and DB2 both offer ways to provide hints to the database about how you want the query processed, and the ability to store those hints independently of the query - Stored Outlines and Plan Stability being the features in question. This is particularly useful when you can't risk the plan changing in production and screwing you over - in that situation it's preferable to experience a gradual degradation->optimisation cycle personally.

It's one thing that I find it frustrating that Postgres (which I otherwise love) doesn't offer - I understand that they don't like optimiser hints, but at least the ability to say 'keep using the current plan until I give you permission to do otherwise' would be invaluable.

</comment></comment></comment></comment></comment><comment><USER7> Tangent: I met Craig yesterday randomly in a coffee shop. He seemed really smart and gave me a few Postgres performance tips. I didn't know he was a big deal. I guess those are the cool twists of fate people talk about happening in the Bay Area.

<comment><USER8> I met him a few months ago in Oxford, UK when he was speaking. Really enjoyed his talk and he was very approachable in the bar afterwards.

</comment></comment><comment><USER9> I thought ratio based tuning is old-fashioned.

</comment><comment><USER10> tl;dr

Use EXPLAIN ANALYZE and read the manual.</comment>


Facebook Patent Would Allow Lenders to Determine Credit - <AUTHOR> http://consumerist.com/2015/08/05/facebook-patent-would-allow-lenders-to-determine-creditworthiness-by-looking-at-your-friends/

<comment><USER2> Lenders and credit score companies already have enormous influence and access, do we really need to open the door to our friends and family? I suppose this is in line with previous reports of users getting different quotes based on what browser they use — admittedly your friends are probably a better measure of your credit — but it's yet another dive into your personal life by creditors.

I think Facebook's going to find that if your social network can directly impact your money, people are going to behave differently. I can think of at least 50 friends I'd cut today under such a scheme. How does that help Facebook if suddenly its users have fewer connections?</comment>


Motorcycle that doesn't fall - <AUTHOR> https://www.youtube.com/watch?v=zY1l6FdNgfA <comment><USER2> So at low speeds, the forks' slant is increased, bringing the point of tire contact ahead of where the steering axis intersects the ground, creating negative trail. Small movements of the steering can correct for the tilting of an incipient fall by using the leverage the trail affords to bring the bike back to the upright position.

I was wondering why this would not work with conventional positive trail, if you reversed the direction of the steering response to an off-vertical tilt. My guess is that this would work for a stationary cycle, but for steering one moving slowly forwards, countering the centrifugal effect would require movements in the opposite direction to those needed to perform the turn.

<comment><AUTHOR> I would buy this even it would just work for 'stationary' situations because I use a big bike. Personally, I find it harder to manage than slow speeds.</comment></comment>


Throw Away the Password to Your AWS Account - <AUTHOR> http://alestic.com/2014/09/aws-root-password <comment><USER2> Except don't actually throw your password away since you will need it to create privileged IAM accounts.

<comment><AUTHOR> Can a sufficiently privileged IAM account not create other privileged IAM accounts? If not, and it is a rare enough requirement, one might just use email password recovery in that case.</comment></comment>


A Linux driver to connect PATA/IDE directly to GPIO - <AUTHOR> https://github.com/Manawyrm/pata-gpio <comment><USER2> Going the other way, a PATA port in PIO mode can be used as GPIO: [https://hackaday.com/2011/02/03/stk200-pocket-change- program...](https://hackaday.com/2011/02/03/stk200-pocket-change-programmer/)

<comment><USER3> When I saw the title, I thought it was going this way.

Or, more specifically, a driver to turn an IDE port into GPIO pins that PC programs can control. Closing the gap on making a feature-complete Windows 95 arduino core.

<comment><USER2> I think you can do this directly, the linked project just tells the kernel "this is a parallel port here", and it just uses normal I/O instructions. The IDE port is already exactly that, though I think the data-direction register controls the whole port at once, rather than one bit at a time.

</comment></comment></comment><comment><AUTHOR> An interesting project I found on twitter. Interfacing PATA/IDE directly to Raspberry Pi's GPIO is pretty trivial and manages to transfer 500 KiB/s. Enough to play CDs. The driver code is around 500 LOC.

</comment><comment><USER4> This is a fun hack. FWIW, similar sorts of things can be used to add a PATA drive to a Cortex-M microprocessor like the STM32 series.

Who doesn't want a micropython board with gigabytes of code space ? :-)

<comment><USER5> It hadn't occurred to me that PATA/IDE could be so simple to speak. Now I'm excited about the possibility of being able to dump a 25 or 30-year-old IDE drive I have that my USB adapter doesn't want to talk to (via another SATA-to- IDE adapter).

The README says this option relies on the kernel's "ATA framework" (presumably for the protocol/non-interfacing logic?). Is that part of the "talking to a drive" stack very much to have to implement? Or do you know of any existing code for microcontrollers?

<comment><USER6> Depends on what you want to do :) If you just want to read/write sectors of 512 bytes at a time, it's pretty easy to implement even on a simple MCU.

There's a couple of registers which need to be set: [https://wiki.osdev.org/ATA_PIO_Mode](https://wiki.osdev.org/ATA_PIO_Mode) and you can then just read/write the data from the parallel lines.

Here's a similar project using an ATmega32: [https://github.com/zwostein/idetrol](https://github.com/zwostein/idetrol) (i used this code, ported to ARM to check my hardware before I wrote the kerneldriver)

<comment><USER7> How can this be so easy but talking to an SD card is an impossible task without implementing a billion vendor/type quirks.

<comment><USER2> ATA was implemented by engineers and then described in a spec.

SD was designed by committee and then implemented as best they could.

</comment></comment></comment></comment></comment><comment><USER8> > Data transmission is well outside the design scope of libgpiod.

But it can do it, anyway. Lovely hack.

</comment><comment><USER9> I was just watching 'Anna' on Hulu, and was thinking about IDE drives.

This does look really cool.

</comment><comment><USER10> I wonder if you could implement a floppy interface the same way?</comment>


Consider the Hare - <AUTHOR> https://www.lrb.co.uk/the-paper/v42/n13/katherine-rundell/consider-the-hare <comment><USER2> Out here in southwestern high desert we're saturated with jackrabbits (a hare), even though we're also saturated with coyotes. I sometimes count the ones that the headlights catch as I drive the three miles from the highway to home at night. My records is 27. And they're huge. I suspect I could saddle and ride one if I could catch it. Sometimes instead of dodging my car they just run in front of it, at maybe 35 mph, for an astonishingly long time.

I'm thinking of learning to snare and cook them, for in case the shit hits the fan. That and eggs could keep someone alive indefinitely. There's a cave near here that ancient natives lived in for millennia. Archaeologists did a detailed analysis and discovered that their main staple was hares and rabbits. If it's good enough for them ...

There are also herds of small antelope in the vicinity, so with the huge jackrabbits this would seem to be prime jackalope breeding habitat. I'm keeping my eyes open.

<comment><USER3> Hank Shaw's recipe is supposed to be among the best: [https://honest- food.net/hare-stew-hard-times/](https://honest-food.net/hare-stew-hard-times/)

</comment></comment><comment><USER4> As someone not overly into animals, I do really like this recurring feature in the LRB. My favorite recent one was on the Hedgehog. Among other great anecdotes:

"The 1566 debate led to the decision to put a tuppence bounty on hedgehogs: farmers believed they suckled milk from cows in the night, and as a result as many as two million were hunted and handed in. That was another of our mistakes: hedgehogs are lactose intolerant and milk can kill them."

[https://www.lrb.co.uk/the-paper/v41/n20/katherine- rundell/co...](https://www.lrb.co.uk/the-paper/v41/n20/katherine- rundell/consider-the-hedgehog)

</comment><comment><USER5> [https://outline.com/fYEDgZ](https://outline.com/fYEDgZ)

<comment><USER6> Alternatively: [https://archive.is/czqYK](https://archive.is/czqYK)</comment></comment>


The Most Unusual (and Best) Computer Language Book I've Ever Seen. - <AUTHOR> http://poignantguide.net/ruby/index.html

<comment><USER2> Unusual? Certainly. Best? Not for me.

I had some time this past summer and decided that I wanted to experiment a bit with Ruby. I tried _Poignant_ three or four times, and each time I would put it down after half an hour, with the same thought - "Why is this book, widely regarded as the One True Way to learn Ruby, fucking around so much? I don't want foxes and cartoons, I want syntax, rules, conventions, and information."

Maybe it's just me, but the way I tend to learn a new language is with a bunch of docs on one screen, and an IDE/REPL on the other. I read some stuff from the doc, try it out on the other screen, and move one. After a few units of time doing that, I'll write up a trivial project to try and make the various bits I've learned work together. Once that's done, I'll have a sufficient grasp of the syntax and general themes of the language that I can dig deeper into various parts of it to learn what I need to keep going.

You know what the "best" language book I've read is? K&R, ore more precisely, K&R2. It gets to the point, and tells you exactly what you need to know about what you looked up in very clear and exact language. It doesn't hold your hand, and it doesn't make you read about foxes.

 _Poignant_ always seemed like it was designed for someone who had no idea what programming was and wanted to end up being somewhat fluent in Ruby. That's good and all - there's certainly a market for that - but not what I look for when I'm in the market for a book on a programming language.

EDIT: Why the downmod - casual use of the f-bomb or contravention of established orthodoxy?

<comment><USER3> With all due respect, if you had such trouble with _Poignant_ , the you probably also would have had a hard time with Ruby. Not to imply that you couldn't understand Ruby or write in Ruby, but just that Ruby has a very distinct character, a personality almost, and I suspect you and Ruby would not have gotten along.

For me, it's that way with Python. Honestly, Python is not fundamentally different from Ruby except this: In Python, there is "one right way". For some programmers that's a saving grace, for others it's akin to a death sentence. To each his/her own...

<comment><USER4> Claims like this bother me, whether about Ruby or Python. a programming language is simply that -- a language used to program computers. It doesn't have a personality. It has a distinct syntax, methods, etc. It is the community which gives it a personality, if any.

<comment><USER3> Matz would disagree with you:

 _"I believe people want to express themselves when they program. They don't want to fight with the language. Programming languages must feel natural to programmers. I tried to make people enjoy programming and concentrate on the fun and creative part of programming when they use Ruby."_

[http://www.linuxdevcenter.com/pub/a/linux/2001/11/29/ruby.ht...](http://www.linuxdevcenter.com/pub/a/linux/2001/11/29/ruby.html)

<comment><USER4> Honestly, I don't even agree with me. That comment came out wrong. What I meant to say was that I feel it is obtuse to say something like "you will probably have a hard time with Ruby if you have a hard time with this goofy book."

</comment></comment></comment></comment></comment><comment><USER5> I love the poignant guide! It (along with Ruby being an awesome language) got me into Ruby.

It's great because you read it because you enjoy it, and then you happen to learn Ruby in the process.

It also has some interesting analogies, examples, and ways to remember things. When talking about how block variables go inside |pipes|, he says:

 _I like to think of the pipe characters as representing a tunnel. They give the appearance of a chute that the variables are sliding down._

Much better at helping you remember the syntax than "block variables go in a comma-separated list which is enclosed by pipes" like you'd find in a normal book.

<comment><USER6> Indeed. You get the sense when reading it, that the author was having a blast writing it, which makes learning Ruby fun. Also, the way its written is almost like a captivating book, so you can't help but dive further in.

I remember picking up 'The Ruby Programming Language' written by Matz, got to the 2nd chapter before I hopped online and found the poignant guide. Made for a much more interesting time learning Ruby.

<comment><USER3> For what it's worth, _why did the illustrations for Matz's book too...

</comment></comment></comment><comment><USER7> I'm a bit surprised this is a top link off of HN, I remember it topping reddit many years ago – hardly hacker "news."

As I said about this product then, taking 3 tabs of LSD should not be required before reading a "how to program in this language" book. The cartoons are great, but if they had some bearing on the content e.g.

3.times{ puts 'chunky bacon' }

then I wouldn't feel so much like I was sitting through some performance from the gifted kid class which is sort of boring and semi-insulting: Why yes, imagining what it would be like to be a butterfly at Valley Forge is very creative, but is neither dramatic nor historically enlightening (cf. Beavis and Butthead watching Beck's "Pay no Mind").

</comment><comment><USER8> If you like this learning style (as I did), and you are interested in haskell, BONUS' Learn You a Haskell for Great Good is a good intro as well: <http://learnyouahaskell.com/>

</comment><comment><USER9> Wow: a lot of people really have some dislike for this book. Not surprising, since Hacker News emphasizes the code-obsessed mind.

I'm not somebody who lives in the world of programming, and this is the only guide to coding that I've ever read and learned from. _why phrases things in ways that make their concepts easy to grasp and he makes for a compelling read. People who insult that or call it drugged-up miss that he's not writing a technical guide. He's writing a _poignant_ guide, and that means that the larger goal is getting people really emotionally invested in the language. You learn the bare minimum to the language, which is enough so that _then_ you can go on and find technical manuals, understanding enough to not be instantly turned away.

I hate tech manuals. I use a few reference books, but I can't pick up a "Guide To X Language" and get very much from it. A guide that makes coding fun is exactly what I need.

<comment><USER10> I recommend why's guide to every non-techie I know who wants to jump into programming.

I had an HR friend of mine trying to make sense out of some data, and wanted to contract me to write a really simple script to make some sense out of his flat file data.

I didn't have time, and since he wasn't an idiot, I figured he could take it on himself, and gave him a link to the poignant guide, which he claims worked like a charm.

Now he's making me justify my salary to him.

For people who already know programming concepts, and just need to know syntax and what's different about Ruby from what they already know, I think the poignant guide is the long way there.

For this crowd, I understand the bitter reception.

</comment></comment><comment><USER11> Frankly, I do not think very highly of _why's writing style. I find the book to be very difficult to read.

If you want an example of excellent technical writing, consider Paul Graham's 'On Lisp' or 'ANSI Common Lisp'.

<comment><USER9> _why isn't writing a technical book, though. He's writing a fun book that introduces people to a coding language.

</comment></comment><comment><USER12> This is my recommended book for every programmer who wants to start learning ruby. One of the why's product.

</comment><comment><USER13> I think it's rubbish. Probably just fine for a complete novice into program design, but utter rubbish to learn anything substantial from.</comment>


Show HN: UnityPack, a Python 3 deserialization library for Unity3D files - <AUTHOR> https://github.com/hearthsim/python-unitypack <comment><AUTHOR> Hello HN!

Unity3D is a popular game framework ([https://unity3d.com/](https://unity3d.com/)) in C#. Unitypack is a library that deals with the unity3d files it uses at a very low level.

This is an alternative to tools like Disunity. It can deserialize into python object, and included are tools to extract/convert raw files and convert entire bundles to YAML. I have explained the reasoning in the README.md file.

The library is still in an early alpha stage. It does not support all versions of Unity and some features (such as cross-bundle references, Mesh conversion to .obj, several texture formats etc) are still missing.

Unitypack was written as part of the HearthSim community ([http://hearthsim.info](http://hearthsim.info)). Come check us out (#hearthsim on Freenode) if you're into Hearthstone and AI/Reverse engineering/Simulation :)</comment>