What non-technical users don't understand about your software - <AUTHOR> http://successfulsoftware.net/2010/08/24/10-things-non-technical-users-dont-understand-about-your-software/ <comment><USER2> I am left in the bittersweet position where a) I 99% agree with an article and b) scratch one post in my Wordpress drafts, because it would add very little to the topic now.

I also sell software to customers with substantially the same technical aptitude as Andy's. My comments:

1) Copy/paste: they can't reliably copy/paste. Of those customers who can copy/paste, a number of them know exactly one way to copy/paste, and will fail if it does not work in the context they need it in. (i.e. they either know what an MS Word copy/paste button combo looks like, OR they know how to right click, OR they know the keyboard shortcut -- and it is, far and away, the keyboard shortcut which is the most widely supported and _least widely understood_ option)

Andy's suggestion is to make it easier to type things out longhand. I suggest making it unnecessary instead -- you can do some client/server trickery to avoid this (discussed here: [http://www.resultsjunkies.com/blog/back-office- exposed-bingo...](http://www.resultsjunkies.com/blog/back-office-exposed- bingo-card-creator/) under the heading "When a sale comes in, can you walk us through the process?")

9) My sole point of disagreement with Andy: this type of user really wants to relate to their computer like they relate to a toaster. No one reads a toaster's documentation, and _no one should have to_. If the UI needs external documentation, that is probably a bug.

<comment><USER3> > I am left in the bittersweet position where a) I 99% agree with an article > and b) scratch one post in my Wordpress drafts, because it would add very > little to the topic now.

Post it anyways? Your articles and style fill me a mix of joy and inspiration. And I think hundreds or thousands of other people too.

</comment></comment><comment><USER4> It doesn't make sense to distinguish "technical" from "non-technical" users. Plenty of users with no interest in programming and no formal training in computing handle these tasks easily. Many users understand that a file exists in a physical location, that it can be copied from a hard drive to a flash drive, and copied from that flash drive to a different computer, and they understand the necessity for that. And they understand that when they use a web app that relieves them of that burden, that the data is now stored "out there" somewhere instead of locally.

From the other side, I had a boss with a Master's in Computer Science who had lots of trouble with normal desktop usability. He certainly never learned to guess which actions were reversible or not. My sister, who teaches history and is barely technically self-sufficient, could run rings about him on the Windows desktop, not to mention my friend the accountant who has never written a program but could be a passable professional programmer with six months' full-time training.

So instead of saying, "this is what non-technical users don't understand," it's better to say, "these misunderstandings are part of the normal spectrum of user savviness that you will have to deal with." Whether a user is technical or non-technical only allows you to make a rough guess about the mistakes they'll make.

<comment><USER5> How do you get a master's in _computer science_ without knowing how to operate a computer?

<comment><USER6> The same way you get a master's in astronomy without knowing how to operate a telescope.

<comment><USER7> Years ago I had the opportunity to host a professional astronomer at a star party at a dark site. He was really excited because he had never seen the milky way before; at least not with his own eyes. He was totally blown away. Most of the regulars were complaining about the transparency that evening, but to this guy it was a revelation.

</comment></comment></comment></comment><comment><USER8> This article reminds me of two things I've observed in ordinary computer users:

 _1\. Many users don't understand how or where data is stored or even that it is separate from the application._

That is correct. My photographing neighbour keeps his photos 'in' Adobe Bridge, another neighbour keeps them 'in' Adobe Elements. They don't have a notion that those programs only offer a view on the pictures which are stored in some directory on their harddisk (they don't understand the hierarchical file system either). When they have to import photos from their camera or email a photo, they always do it from their photo cataloging program, never from the Windows Explorer.

Likewise, a few of my collegues think their texts exist solely 'in' Microsoft Word, and that the 'Internet' is the same as the WWW.

 _2\. reversibility_

One day I was helping a friend of a friend with transfering some texts over to another computer. We reviewed a text, by accident I deleted a paragraph and restored it promptly with Control-Z (undo). The person was looking flabbergasted at me: 'How did you do that?'. He told me that often when some part of his text 'disappeared' magically without apparent reason, he had to type it all over again. He didn't know that Word has an Undo. I told him he could benefit from a basic Windows and Word training, but he wouldn't hear of that. He did remember the Undo trick, however ;-)

<comment><USER9> Beginning with Windows 98, it has been more trouble than it's worth to try putting your files where you want them in the filesystem, instead of letting the application find a place for them. After I realized this, I tried putting My Documents on drive D - that didn't go so smoothly either.

I recently helped my aunt install a new scanner. She asked me how to send a document to someone. After exploring the driver software for a while, I adviced her to start the scanner wizard/pamphlet printer/photo editor/document manager, click "scan", click "email", and let Outlook take it from there.

</comment></comment><comment><USER10> I honestly believe that this is the difference between Apple and the rest of the competition. You see, the secret they have to their products is that they realize that most people don't have any idea whatsoever what the hell a frikkin' mp3 file is. Neither do they know the difference between lossy and lossless conversion. They are intimidated by all those fancy buttons on the screen and are too scared to try anything just in case they break something.

Steve Jobs recognizes this and that's his genius in a way. So, instead of creating a widget that does everything they choose to make a widget that does everything the user wants. There's a subtle, but important difference over here. Only a small subset of their users want extensive options so that they can put FLAC and other stuff onto it. Those are the users who fret about the product to the nth degree and they know that they don't exist to serve _them_.

So, they pick a feature and implement it in a way that those other users (80%+ of the market) know how to use it, and that makes all the difference. Just look at enterprise software and how hideously broken it is. You have SaaS that try to do everything at once which directly results in their users doing nothing at once. This instead causes grumbling against the software and in the longer turn your sales go down. The hardest lesson in business, I think, is learning how to bite the bullet. No one wants to admit that their software can't do something. So, they rush and put the feature in to satisfy themselves without checking if it works or not. Big mistake. What's worse is that it is so ingrained in us that we don't even realize what damage we have done.

What I am trying to say is that it's perfectly fine to not have the insanely great feature X, but it's inexcusable that the user has to read a 300 page manual to use feature X.

This is why I suggest everyone to read the Apple Human Interface guidelines. They aren't perfect, but they've gotten quite a few things right. (see: [http://developer.apple.com/mac/library/documentation/UserExp...](http://developer.apple.com/mac/library/documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGDesignProcess/XHIGDesignProcess.html#//apple_ref/doc/uid/TP40002718-TPXREF101) )

<comment><USER11> "does everything the user wants"

Then some OS X features completely baffle me. Like installing software. I'm not a "Mac guy" and each time I ask someone how to install software downloaded off the web I get a different answer, all preceeded by "You just ..." and then 10 or 11 simple steps. Apparently they have never heard of installers. I'd guess from this, that the average Mac has never had ANY software installed after it left the factory.

<comment><USER12> Apparently the the drag/drop install thing is not intuitive to even technical users. I don't remember what my reaction was to this the first time I encountered it, but I'd guess it wasn't entirely positive.

There's a perfectly good system wide Installer on the Mac, but nobody uses it unless they have to, because installers suck (they ask, among other things, which drive you'd like to install the software to -- what normal user knows the answer to that question?).

A number of vendors are working to improve application downloads by distributing applications as self-extracting zipfiles that put the original archive in the trash on extractions, and making it so that if the application is launched from the downloads folder or the desktop it initially politely asks if you'd like to "install" the application. This is pretty foolproof. Even if the user declines to move it, the Application will still _work_ from the Downloads directory or the Desktop, it just won't be as easy to find.

<comment><USER13> _There's a perfectly good system wide Installer on the Mac, but nobody uses it unless they have to, because installers suck (they ask, among other things, which drive you'd like to install the software to -- what normal user knows the answer to that question?)._

It didn't help that PackageMaker used to be one of the oddest, most incomprehensible pieces of software you ever had the misfortune to use. It's a bit better now, but most developers I know have sworn off it for good.

Apple does have a technology called "Internet-Enabled DMGs", which automatically mounts, copies the application, then unmounts and deletes the dmg. It's not widely known about or used.

<comment><USER11> That's sounds like the feature that was needed. The software I've had to suffer under, had me do that by hand.

No, drag-and-drop is NOT unintuitive, and if that was all that it took then great. But Mac guys are so used to the ringamarole that they forget this part: "Oh yeah, then mount the dmg, then open the virtual drive, then drag one of the various icons (which one???) to your Applications folder, oh yeah open that first in the finder, then close the virtual drive and unmount the dmg, then find the downloaded wad (what was it called again?) and delete it." All of those operations accessed from different menus/tools.

<comment><USER12> A few things used to make this process a little less painful.

First, Safari used to download things to the desktop. This meant the DMG file was sitting right there, looking ugly, taking up space.

Second, Safari used to, by default, open "Safe" attachments (which included disk images), and open the Finder window to the newly mounted image automatically.

The upshot was that, assuming the developer had made an effort to indicate what to drag where with a big honkin' arrow, after your download was done there would be a pretty clear sign of what to drag where to install the app. Unmounting an deleting the DMG has always been an issue (and the internet- enabled DMGs are better for this), although only the unmounting bit is unique to OS X. Under Windows you're still going to have an installer file lying about that has to be deleted.

Both of these things went away, though, and many developers haven't caught up with the times.

</comment></comment></comment></comment></comment></comment><comment><USER14> My benchmark for non-technical users is my father: he's 60-something and he started using computers & internet 3 years ago when I bought him a laptop.

I can recognize in him pretty much all the behaviours described in this article, especially the fear of setting everything up on fire with a click, but I've also noticed that he tends to use the machine with a weird sequential approach.

Click the fox icon, go to thataddress.com, click there, type this, click yes etc.

For some complicated tasks (such as burning a DVD) he's got all the buttons and actions he needs to perform written down on a piece of paper.

The amount of struggle and effort he puts in it always fascinates me.

<comment><USER15> My assorted elderly/older relatives all exhibit the same pattern, and after years of not understanding it, I've finally learned enough about how people learn to explain it. Basically, they haven't developed any kind of abstracted internal mental model of what the computer or software are doing, and, as a result, treat it as a rote incantation. To put it in education-geek terms, they're stuck at the first level of Bloom's Taxonomy, and while they have some "knowledge" (where to click, etc.) they have no "comprehension" and therefore don't really know what their knowledge means or represents in any kind of larger context.

As far as they're concerned, each step in their "get my email" checklist is equally important and equally arbitrary. You could literally tell them that, after clicking on the fox icon and going to thataddress.com, the next step is to spin around counter-clockwise three times in their desk chair while singing "God Save the Queen", and they'd believe you- and then, one day when they only spun around twice in their chair, they'd be calling you in a panic to ask if that's why their "internet is broken".

This isn't a matter of stupid vs. smart, or anything like that- it's a matter of learning. Getting past that first step is hard for a lot of people, especially with computers[1]... and, while I'm on my soap box, I gotta say that I'm not convinced that GUIs do a good job of making it any easier (although I certainly can't think of anything that does a better job). GUIs make it really easy to aquire "knowledge" about how to use a program, but they _can_ impair their users' abilities to get past that first step and really understand what's going on.[2]

I think that this is because GUIs sort of imbue the computing experience with a sense of, for lack of a better word, "false concreteness"- they make what are, in reality, highly abstract tasks appear to be very concrete, and let novice users get away with treating them as such... until, of course, something breaks or changes, at which point the user panics: since they don't have any sense of the larger context surrounding their use of the computer (i.e., why they need to click on one button as opposed to another, what the address in the address bar really means, etc.), they have no way of telling what "broke", or whether the changes they're seeing are important or not, and they don't have the mental tools they need to reason effectively about ways to get around whatever problem they've encountered.

Neal Stephenson touches on this subject a little bit in his essay, "In the Beginning, There Was the Command Line." It's more than a little dated, but I actually re-read parts of it a week ago and I'm happy to report that it's held up better than a lot of things that were written in 1999 about computers. Not surprisingly, the things that have held up the best are the parts that aren't tied to any specific piece of technology, but rather are about the abstract concepts and theories underpinning modern (i.e., post-1984) UI design.

[1] Anybody who's tried to teach somebody how to program will tell you that, while students have trouble with syntax and what-not, their bigger problems are almost always related to learning to think about problems in an abstract and generalized way.

[2] Here, I'm not necessarily talking about understanding the algorithms and data structures behind the program- I don't think it's particularly important for most users of most programs to understand the software at that level, although there are some cases where it might be desirable (certain medical or industrial applications, for example). What I'm referring to is the abstract understanding of how the different parts of the user interface fit together with one another and with the task that the program is trying to accomplish for the user- sort of like what Joel Spolsky's talking about in his "Figuring Out What They Expected" essay, but at an even more basic level.

<comment><USER16> To me, the interesting thing is that the entire culture of usability seems to be focused on widening this gap. Perhaps the biggest rule of user interface is "the user shouldn't have to care how it works". This extends even down into programming. You bring in a library, you look at the function specs, call a function, and if it works without you having to grok a single thing happening beneath the surface, it's resounding success. The same thing but worse happens at the application level.

Of course, good luck competing in a market where you're the only guy trying to (gasp) make the user understand what's going on. I don't even know if I expect the problem to get worse (as interfaces become more and more abstracted) or better (as users increasingly grow up with computers in their lives) as time goes on.

<comment><USER17> It sounds like you're saying users should have a mental model of how a computer works in order to be successful at using it as a tool.

I disagree.

How does my car work? I press on the gas and it goes. I press on the brakes and it stops. Drive shaft? Carburetor? What's those things?

That users can't use a computer is usually, not always, the fault of developers and designers.

For example, if backing up is so crucial, why don't computers come with that functionality built in?

Why _is_ data storage separate from the application? In the iPad, it's not. And that's a brilliant improvement in computing!

<comment><USER18> A mental model is essential to successfully use _any_ machine.

You don't need to have a correct mental model of how it works, just a mental model that given the most common input, predicts the output.

From your comment, I can see you have a mental model of how the car works. You press on the gas, and expect the car to go faster. You press on the brakes, and expect the car to slow down until it eventually stops. You turn the steering wheel to the right and you know that the front wheels point rigthwards, making the car go in that direction. This mental model allows you to predict the outcome of pressing the gas and the brakes at the same time, and therefore know that you should not do it.

You do not need to know the inner workings of the car. You might as well think there are midgets under the hood doing all the work.

The problem is that the mental model that most people form about computers is so wrong, that it doesn't predict anything. So they can't use a computer properly.

And this is mostly the fault of interface "designers". An interface to _anything_ should allow the user to form a mental model that predicts the outcome of the operations that users will need to perform. This does not mean exposing the inner workings of the machine, but also not over-simplifying and use metaphors excessively. Like I said, the mental model does not need to be accurate, it just needs to help the user do whatever it needs to do.

</comment></comment></comment></comment></comment><comment><USER19> In the golden age of the British pop industry, record companies used to play their newly pressed singles to the elderly doormen and cleaners in the offices. If these old duffers could whistle the tune after hearing the record once, they knew the song stood a good chance of becoming a hit. They called it "the old grey whistle test".

I am increasingly of the opinion that the single most valuable asset to any consumer software company is at least one "old grey". The more time I spend with ordinary end-users, the more I realise that I cannot even begin to comprehend their mental processes. They are a total black box to me, with a completely different set of instincts and intuitive responses. I think that the majority of software developers, even professional UX folks, massively misunderstand their users.

<comment><USER20> Yup. I'm lucky in some respects as a UX designer, because I do UX for set top boxes, not computers - my users are even less technically-aware that computer users, and they have a very strong expectation that their television is not going to be hard/confusing to use.

As STBs have got more and more complex though, taking on major media centre capabilities, interfacing to Internet services such as YouTube, Netflix and FaceBook, we are really struggling to keep the interface simple. But at least we are aware that this is a critical aspect of our software - computer app developers sometimes can lose sight of that.

</comment></comment><comment><USER17> #23: Users will not read dialog boxes. Especially on Windows. They will click them away and not even realize they existed.

Try it.

1) Put a dialog popup in your MS desktop app that says, "Clicking OK below will destroy the chair beneath you. Clicking Cancel will make a box of chocolates appear on your desk."

2) Observe when a user performs a task that produces the pop up.

3)Ask the user if they were disappointed that no chocolate appeared.

The user will look at you with incomprehension.

To clarify, I am not criticizing users. Users are users, we're not going to change their behavior with training or help manuals. We need to design around them.

<comment><USER21> That's a habituation to the reality of the Win32 style — "Find reached the end of the document | OK"

Users don't have an a priori instinct to dismiss dialog boxes out of spite — on the contrary, the elderly noob reads every one carefully as if the wrong choice would actually destroy the chair beneath them. A new dialog box like that would ruin their day, and mine when I get their panicked phone call now that they've gone off script. If they ever do build a mental model of the UI, they'll have learned otherwise.

<comment><USER17> But because of the way UI is designed, one of the first elements of the UI mental model your elderly noob will learn is that dialog boxes are to be ignored.

</comment></comment></comment><comment><USER22> It seems like an easy way to avoid many of these issues is simply to make web applications where all the software is stored in the cloud. Most of the arguments I've seen for web apps are from the devs' perspective (you control the hardware, you can pick whatever programming language you want, etc), but I guess web apps are better for users, too.

<comment><USER23> There's a whole nuther article about "what users don't understand about your web app"

That network/DNS/router/etc issues aren't your fault and you can't fix them.

Everything regarding passwords and account security.

URLs, esp typo's and that The Google (esp it's search bar) != Internet.

HTTPS

Phishing, and a slew of other attacks. Also that punching the monkey is probably a bad idea.

Browsers, different browser versions, different browser manufacturers, cross browser incompatibility. Also that you did not create the browser and you can't fix it. Also why they have to download install new version of browser to use your software.

Why your webapp quits working when they aren't connected to The Google.

</comment></comment><comment><USER24> Number 11 (Only applies to non-english speaking software): English.

Related to number 4, english expressions can be as bad as technical jargon. There's no reason to call a file 'file', if the localised Datei or Fichier is better understood.

</comment><comment><USER23> > [techies explore & fiddle] Non-technical users aren't so confident and won't > try things in the same way. In fact some of them seem to think that a wrong > move could cause the computer to burst into flames.

This is the fundamental difference between a "technie" and a "non-techie". In fact the inclination to explore, to fiddle, to hack is largely how someone gains the knowledge, experience, and craft to become a "techie".

<comment><USER25> I suppose fear literally _is_ the mind-killer.

I've noticed that my own depth of comprehension is far better when I explore and experiment _first_ , and not study the formalized knowledge from a textbook/documentation until I'm satisfied that I have at least grasped the fundamental patterns on my own. This works not just in computing, but in almost every context (or at least those that don't have the potential to cause serious damage or injury).

</comment></comment><comment><USER26> _Consequently, when they install a desktop app on a new machine they are often surprised that it can't automatically access the documents they created on a previous machine_

Really!? I've never, ever observed this.

In the words of Zoolander, the files are IN the computer.

<comment><USER27> Some years ago, a relative of my wife bought a new PC and gave her old one to the doorman in her building. She then asked my brother-in-law to "put the data back" in the new machine. She apparently hadn't realized that "the data" was now at the doorman's, inside her old machine.

I think my brother-in-law was able to get a hold of the old machine before it got re-installed.

<comment><USER26> Wow. That's like buying a new suitcase when you arrive at the hotel, and wondering why your clothes aren't in it. Packing? Don't confuse me with your jargon!

<comment><USER28> That makes me wonder if we should use that exact metaphor to explain computers/software. Your computer is a suitcase. Everything you do packs your suitcase. If you want to get a new suitcase, you have to unpack the old one and pack the stuff into the new one.

Not really sure what software would be though.

<comment><USER29> That is why I am against using analogies (water through pipes to understand electricity). All analogies are false. The only question is when it is going to mislead, not if.

<comment><USER28> Files and folders are an analogy. Files aren't really _in_ a folder, they're just associated through clever indexing. Is there any reason we should stop using that analogy?

Analogies are useful when they allow you to not think about something low- level so you can work on something high-level. If I had to think about electrons every time I sat down to write code, I'd never get anything done. If I had to learn it before I started learning to write code, I'd still be in school.

<comment><USER29> I am not so sure that this is an analogy. These are different names for new things. Except for 'folder' as opposed to 'directory'.

You sort of lost me there with the electrons thing. Are perhaps you really meaning the abstractions that enable you to not have to think about electrons while writing code.

</comment></comment></comment></comment></comment></comment></comment><comment><USER30> This article talks about consumer software, but most of the issues are applicable even to relatively technical enterprise software. The end users of this kind of software generally have a lot of expertise in their daily routines, but stumble when they are asked to use the software to do something outside of their typical use patterns. It's important to stay humble and realize that the software you're offering to a customer is, in all likelihood, going to have a relatively small (but hopefully positive) impact on the user's life, and in these cases the users are not going to want to spend a lot of their time mastering your software.

</comment><comment><USER31> heh... I have the opposite problem with copy-paste.. users keep pasting in content from microsoft word and wonder why it doesn't work properly.

</comment><comment><USER32> Nice one. Regarding point 7 ("what changes can be reversed"), tendencies are different for the younger cohort compared to those who grew up with DOS. Younger people actually try a lot without fear of serious damage, so if you're building for them, you can exploit this .. provided you ensure safety under such trials as well.

</comment><comment><USER33> This article raises good points, but I'd like to argue / disagree with it in several points:

 _It doesn't mean that your users are stupid, just that they haven't spent the thousands of hours in front of a computer that you have._

Like office workers spending 8 hours a day in front of a computer? They easily make that time only on work time.. not that it helps.

 _..they don't know how to (or even that they can) copy and paste text._

Some users don't. But what should I do, send a copy of computer 101 with every eMail I send?

 _Many users are used to web applications and don't understand that they need to download and install new versions of desktop software to get access to the features in a new version._

So, what's the maintenance staff there for? In my experience regular office users don't set up or update anything, ever!

 _Data storage_

File system hierarchy and network mount points are so far off the average user horizon that you shouldn't bother anyway. You just point to it in the file explorer. Everything else is completely pointless.

As for filetypes and converting: ok, that's a valid point. It's a good idea to send instructions with it, as it is a somewhat non-common task.

 _The jargon you use_

I agree. Talk the users language, not computer slang.

 _You should therefore never put something only in a right click menu or anywhere else that it can't easily be discovered._

Please, I beg you. Put stuff where you would normally expect it from your WM / OS. If it would be in the context menu, then put it there. Normally you also put stuff in the menu bar / ribbon / icon bar depending on conventions. Don't try to invent new interface guidelines, you'll probably fail.. horribly.

 _Concurrency_

Try not to expose them or avoid it entirely (rework the workflow if necessary). Otherwise build the interface in a way that clearly notifies the user of this circumstance.

 _Non-technical users aren't so confident and won't try things in the same way. In fact some of them seem to think that a wrong move could cause the computer to burst into flames._

Most of them don't try anything at all. They will ask you how to do it. If you have some kind of system that has tweaks: train your users (that's what tech training is for).

 _So try to stick to conventions they will understand_

Absolutely.

 _The need for backups_

I preach this all the time. People also always agree to me in this respect. Doesn't help, they never actually do it, much less spend money on it. Could as well talk to the wall..

 _That they should read the documentation_

I totally agree. No one will read your precious documentation. If you roll out a new software, train them with the workflow. You do train your workforce to use the tools they use, right?

 _Unskilled users often don't realize how unskilled they are. Consequently they may blame your software for problems that are of their own making._

May? They always do. I figure this must be human nature or something.

 _One just has to be as polite as possible in such cases._

In other words, stay professional.

\</comment><comment></comment><comment>-

Otherwise I found it the article as entertaining as irksome. Raises some good points.

</comment><comment><USER34> "I hear and I forget. I see and I remember. I do and I understand." -- Confucius</comment>


Saudi-Russia oil war is a game theory masterstroke - <AUTHOR> https://www.ft.com/content/1da60fa2-3d63-439e-abd4-1391a2047972 <comment><USER2> De-paywalled: [https://archive.is/yLgUF](https://archive.is/yLgUF)</comment>


More Redis internals: Tracing a GET & SET - <AUTHOR> http://pauladamsmith.com/blog/2011/03/redis_get_set.html

<comment><USER2> Great article, thank you very much.

Btw it is possible to use:

        make noopt

To compile Redis without compiler optimization.

<comment><USER3> Or set the OPTIMIZATION environment variable for even more control ;-)

<comment><AUTHOR> Thanks, gents, I updated the post with that, and Pieter's correction that Redis keys are not Redis objects, but sds strings.</comment></comment></comment>


Show HN: How much developers earn? - <AUTHOR> http://tehcookies.com/devsalaries/vis.html <comment><USER2> Re: "Oops! Something went wrong on the server. Please try again."

      form.js:225 Error: PERMISSION_DENIED: Permission denied
          at firebase-database.js:28
          at z (firebase-database.js:28)
          at t.callOnCompleteCallback (firebase-database.js:28)
          at firebase-database.js:28
          at firebase-database.js:28
          at e.vr (firebase-database.js:28)
          at t.vr (firebase-database.js:28)
          at t.cr (firebase-database.js:28)
          at e.onMessage (firebase-database.js:28)
          at e.nt (firebase-database.js:28)

chrome 60 on osx 10.11.6 - browser plugins disabled

Thanks for sharing this. looking forward to submitting and checking the site as data grows!

<comment><AUTHOR> Thanks for the feedback. We're investigating this.

</comment></comment><comment> 52-6F-62 Nice work. It works great! Hopefully you'll get some more data in there soon. It's interesting.

Lately it's been a little surprising for me what I make vs market rates. I knew I make a little on the low end, but over the weekend doing some salary comparisons on Glassdoor I discovered I was making much less (to the order of 15 to 60%) than more similar roles and contractors in other departments in the same field, and probably the equivalent of interns or just above throughout the company...

It's good to have some data

<comment><USER3> Glassdoor isn't really that accurate. It doesn't reflect current market rates, it shows rates for the duration of the time the website has been around. Also, there is massive selection bias about who puts their salary up there

<comment> 52-6F-62 That's a good point. I imagine in my case that could mean that my rate is even worse than it would have been during their terms. I guess it's pretty near impossible to determine an accurate measure without polling my current coworkers and bosses. haha

<comment><USER3> Best way to know current market is to ask a recruiter who will be honest with you

</comment></comment></comment></comment><comment><AUTHOR> Hi HN!

One week ago there was a good post by @ciaoben and discussion [1]. We noticed that there were complains about data readability. Since we love visualizations we decided to make this data more interesting to view and get insight into.

Our work consists of two parts:

\- a form to collect data from developers living in any country in the world;

\- a visualization showing statistical summaries for countries and cities.

We would love to collect more data to make the visualization complete.

The project is open-source, so feel free to contribute [2].

[1] [https://news.ycombinator.com/item?id=15088840](https://news.ycombinator.com/item?id=15088840)

[2] [https://github.com/tehcookies/devsalaries](https://github.com/tehcookies/devsalaries)

<comment><USER4> I noticed you're asking for salary. Many well paying companies have a significant non-salary component, so you're going to get some people who put their base salary and some people who put their total comp.

I don't know shit about survey design, but it might be worth thinking more about how you collect your data.

<comment><AUTHOR> Good point actually. Do you think that additional input for bonuses would do the trick? Though I have no idea how to account non-cash bonuses (they do have a cash equivalent, but I'm pretty sure that people won't bother to convert).

</comment></comment></comment><comment><USER5> This is one of those chicken and egg websites. (like stackoverflow). It's only useful once you reach a good traction. I wish you luck. I would find it useful

<comment><AUTHOR> I agree. This has been driven mostly by curiosity after reading a thread about salaries here on HN. It took one week for us to prototype it and post it. So we don't expect much from it but would like it to be useful for others.

Actually we want to show that collecting data from others can be different. Not a Google Form with Google Spreadsheet which only _gets_ data from people, but an interactive visualization, which also _gives_ data.

</comment></comment><comment><USER6> Cool site. Antarctica is getting _a lot_ of space on that map though...

<comment><AUTHOR> True. But this is how mercator projection works [1]. One idea in my mind is to restrict panning so that Antarctica is not reachable like it's not there.

Wish I could be a remote software engineer working from Antarctica. :-)

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

</comment></comment><comment><USER7> I'd suggest linking to the github repo in the footer of your site

<comment><AUTHOR> Thanks for the suggestion. Now it's there.

</comment></comment><comment><USER8> It's interesting that on the map, Crimea is considered as part of Russia.

<comment><USER9> Regardless of what one may like or wish, it's the reality on the ground.

</comment></comment><comment><USER10> Why is it 'branded' like HN?

<comment><AUTHOR> It has been done for HN with dataset collected on HN. See description [1]. The initial inspiration we got from HN and discussion here. And the whole demo has been done for fun and curiosity, so it's not a startup, product, or anything we are going to develop further as a standalone app with this design and branding. Otherwise we'll use our own different branding.

[1] [http://tehcookies.com/devsalaries/](http://tehcookies.com/devsalaries/)

</comment></comment><comment><USER11> form won't submit

<comment><AUTHOR> What's your platform and browser?

<comment><USER11> Unrelated - what are you using for the map? D3?

<comment><AUTHOR> Here is the topology file btw: [https://github.com/tehcookies/devsalaries/blob/master/data/t...](https://github.com/tehcookies/devsalaries/blob/master/data/topology.json?short_path=ec86f5a).</comment></comment></comment></comment>


Silicon Valley is turning our lives into an asset class - <AUTHOR> http://www.ft.com/cms/s/0/9d2a73fe-a54a-11e3-8070-00144feab7de.html

<comment><AUTHOR> Non-paywalled copy: [http://evgenymorozov.tumblr.com/post/79466871548/my-oped- in-...](http://evgenymorozov.tumblr.com/post/79466871548/my-oped-in-tomorrows- ft)</comment>


Answers are easy. Finding problems are hard. - <AUTHOR> http://venturebeat.com/2011/05/20/answers-are-easy-finding-problems-are-hard/

<comment><USER2> Isn't there a problem with the headline? Maybe they're not that hard to find after all. If not then there is one with my english, which would still mean that finding a problem is not too hard :-).

Anyways I am not sure if it is really easier to solve a problem than to find one. I would say the hardest part would be defining a problem in way that it is approachable. You can come up with a lot of very general problems, the hard part is narrowing it down.

<comment><USER3> Yes, there is a problem with the headline. The latter sentence should read, "Finding problems is hard."

However, convention on HN suggests that it's appropriate to copy headlines verbatim from the linked article. It's unclear what the appropriate behavior is.

<comment><USER4> Unless we're talking about the particular class of problems which involve finding things. As in:

"Sorting problems are easy, finding problems are hard."

And of course, finding problems is a finding problem. No wonder it's hard!

<comment><USER3> Hm... I hadn't considered that. Touché.

</comment></comment></comment></comment><comment><USER5> Finding good problems for _the answers you already have (built)_ is hard, also known as seeking market fitness :)

I stumble on good problems with no obvious answers frequently, and my take is that _approaching them with the mindset of "hey, what if...?"_ is what is really uncommon. Not hard, children do it all the time.

What's hard? Keeping that mindset of "what if...?" alive over the years! :)

</comment><comment><USER6> You don't have to solve a problem to have a product. E.g. <http://sethgodin.typepad.com/seths_blog/2007/08/just-in>

<comment><USER7> The link seems dead. The following works though: [http://sethgodin.typepad.com/seths_blog/2007/08/just-in- time...](http://sethgodin.typepad.com/seths_blog/2007/08/just-in-time-fo.html)

</comment></comment><comment><USER8> Grammar are hard.

</comment><comment><USER9> Most problems are trivial or impossible. Progress happens on the small margin of problems that are in between.

<comment><USER10> Yes, but don't discount the trivial-- that's where a lot of the money is made.

</comment></comment><comment><USER11> Richard Bellman, I think, is famous for pointing this out frequently.

</comment><comment><USER12> The phrase "it turns out" has gone viral. Unfortunately somebody else got the domain before me.

<comment><USER13> It seems to me that complaining about the phrase "it turns out" is what's _really_ gone viral.

<comment><USER14> Relevant link: <http://jsomers.net/blog/it-turns-out></comment></comment></comment>


365 Days of Frugality - <AUTHOR> http://thefrugalgraduate.wordpress.com/daily-saving-tip/

<comment><AUTHOR> Blog that provides a daily saving tip each day for a year. Take a look and see what you can apply today.</comment>


The Justice Dept's secret rules for targeting journalists with FISA court orders - <AUTHOR> https://freedom.press/news/revealed-justice-depts-secret-rules-targeting-journalists-fisa-court-orders/ <comment><USER2> The FISA court should be abolished or needs very serious reforms. The original reasoning was for surveilling foreign spies but it is now being used to monitor journalists (presumably American as well!) and American's involved in political campaigns. If the FBI had disclosed it would be using the FISA court in this manner when the laws were proposed the laws would not have received support.

<comment><USER3> FISA court is still about national security and espionage cases. The reason they may want a FISA warrant on a journalist is because we know that there are foreign intelligence services that use journalists to spread disinformation, propaganda, and stolen classified materials.

So for example, RT America was recently forced to get FARA registration, as was some Chinese media outlets.

One development in the Paul Manafort case is that he admitted to pushing disinformation to American media to support his Ukrainian clients. If there were other avenues of hostile foreign influence operations attempting to subvert US media, a FISA warrant would be one way it might be done.

One thing to remember about the FISA court is that it's not about surveillance for the purpose of normal criminal prosecutions, it's about supporting national security, which often doesn't necessarily lead to criminal charges. It may mean just monitoring what adversaries are up to. This is also why the bar for FISA warrants is different than it is for normal criminal investigations.

At any rate, the FISA court's powers can certainly be abused and meaningful oversight is needed. Especially in this time with increasing politicization of federal law enforcement. Spying on journalists gets into dangerous territory, so yes, people should pay close attention here.

<comment><USER4> > the FISA court is that it's not about surveillance for the purpose of normal > criminal prosecutions

It _is_ used for domestic criminal purposes, as long as the court only sees a _parallel construction_ [1] that conceals that the evidence is the fruit of the poisonous tree.

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

<comment><USER3> Yes, that is a very important loophole to bring up here.

On one hand, parallel construction can be used in order to not compromise sensitive sources and methods. If you found out about a spy ring because you compromised a spy's phone, you might not want that revealed, so a different path to the evidence is constructed to conceal that method.

But it of course can be used in a nefarious manner to launder evidence gained on someone illegally. So maybe in the course of a nat'l security investigation the feds stumble conversations of a drug trafficker, then use parallel construction to create a paper trail that would make it seem like the knowledge about the drug trafficker was obtained through normal channels.

That is absolutely an area that requires more rigorous controls and oversight, although I don't know how often FISA warrants have been exploited in that matter. Could be mostly federal law enforcement eavesdropping with stingrays.

<comment><USER5> Parallel construction doesn't have nefarious uses it is inherently nefarious. It is an end run around the law they are supposed to be upholding.

In actual practice you shouldn't perform broad illegal surveillance of your populace and if you do you shouldn't be able to use it in court without revealing your sources.

This fundamentally violates the rights of the accused.

<comment><USER6> Parallel construction is a euphemism for perjury committed by law enforcement.

<comment><USER5> This should be prosecuted as such instead of concealed.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> Just a note to try to derail the inevitable political handwringing: these documents are all dated from 2014 or 2015 and therefore have nothing to do with the current administration, beyond that they haven't revoked them and replaced them with something else.

<comment><USER8> I'm more curious about the status quo before the rules. They might have been put in place due to abuses in the absence of clear policy. The government shouldn't target journalists _at all_ , but it will, and clear policy may rein in darker impulses.

<comment><USER9> FISA surveillance is intended to go after spies. If government shouldn't target journalists _at all_ , won't spies just become journalists?

<comment><USER8> Government is going to target journalists regardless of the ethics and legality of it. Joining a profession with less access to vital government secrets and more scrutiny by government than any other seems like an odd choice for a spy.

<comment><USER10> Journalist is also a good cover. There are a lot of secrets that are not actually secret if you just spend some time looking in the right places. However normal people do their day job and go home to the family so they don't figure out much.

An example: a "office building" that has a large underground lab. Normal people see a construction site with a few dump trucks of dirt leaving. A spy will watch long enough to figure out it isn't just a few dump trucks, a lot more dirt is leaving than should be. A journalist has cover to watch long enough.

It is a double edge sword. A spy who can copy the real blueprints, or works in the lab is better. However the people who have that access to that might not talk at any price so you take what you can get.

<comment><USER11> Journalists are complementary to government agencies. Complicit journalist looking for access can leak anonymous scoops that can then be used as a pretext to launch a FISA request.

</comment></comment></comment></comment></comment></comment><comment><USER12> Just another reminder that the Justice Department is not your ally. Sessions, Mueller, Rosenstein, and Comey; if they eat their own fine by me. But don't think for a second if they aren't working against your interests while they are arguing over Russian influence.

<comment><USER13> A lot of left wing Americans seemingly threw out their ability to question once the DNC started making claims that Russia was responsible for Trump. They trust these people hands down, without realizing that Mueller was instrumental in lying about the Iraq WMD's [1]. While I'm glad massive fraud charges are being brought up on Trump's friends & cabinet, I'm hesitant to not seriously question anything about foreign influence from the same people who lied us into the Iraq war.

[1] [https://youtu.be/uTDO-kuOGTQ](https://youtu.be/uTDO-kuOGTQ)

<comment><USER14> From that perspective, it's possible to see Trump's schizophrenic foreign policy as a sort of negotiation from his previous stated position of non- interventionism. He could get away with peace talks with Kim only by countering them with saber-rattling toward Iran. He has avoided the planned Syrian War but still managed to drop bombs in Syria. The military-industrial- media complex wants Endless War, and they were only too happy to corrupt progressives in order to pressure Trump. The biggest risk now is that D's take back both houses, and Trump starts another disastrous war in order to avoid impeachment and removal from office.

<comment><USER15> Why would you need to threaten war with Iran in order to have peace talks with NK?

<comment><USER16> Because the military-industrial-pharmaceutical complex exerts an enormous influence over American politics, both domestic and foreign, and if they want war: they get it. (cf., the last 40 years of illegal American wars.)

All this attacking-the-figurehead is really doing, is distracting the public from the real cause of trouble in American politics today: the Generals. The Pentagon is a significant source of turmoil in the world - for anyone to think that this doesn't apply to the President, is just plain nuts. Nobody exerts more pressure for war, more war, endless, holy war, on an American President than the Pentagon and its complex of intricate corporate lackeys, financiers, courtesans and pimps...

<comment><USER17> The generals are also just dominos of the business interests. The US industry generals are driving the endless wars, through the generals, CIA, bought politicians and bought press.

</comment></comment></comment></comment></comment></comment><comment><USER18> I'm not sure what I'm reading here. The only documents in this tranche that discuss FISA orders make it _harder_ to get a FISA order targeting an overseas journalist, not easier.

</comment><comment><USER19> If China, Russia or any other country target journalists its oppression and totalitarianism. If the US does it its not? This is alarming double standards by jingoists who do not believe in any values.

FISA courts, secret processes, secret orders are completely arbitrary and undemocratic. You can't hollow out the very things that define democracy and continue to call it that. How does a secret court fit in a democracy? How does targeting journalists with secret courts and orders fit a democracy? Then what is the difference between totalitarianism and democracy?

Threads on China, Russia and others are full of commentators lecturing others about democracy and human rights. How can you hold others accountable for the very things you are guilty of yourself, how can this kind of hypocrisy pass in informed discussion?

It's this alarming dissonance, hypocrisy and complete failure to hold anyone accountable since Snowden's revelations that is providing cover for these kinds of shocking overreach. And in the absence of mainstream protest and activism it will keep getting worse.

</comment><comment><USER13> I feel like Noam Chomsky's 'Manufacturing Consent' needs a 2019 update to the propaganda model.

<comment><USER20> In what way? Nothing really has changed, it has only gotten more extreme and blatant.

<comment><USER21> So something has changed then?

</comment></comment></comment><comment><USER22> We need a list of lists and how you get on them, and off them, then a service for managing them.

</comment><comment><USER23> Power corrupts, absolute power corrupts absolutely.

</comment><comment><USER24> Targeting journalists is horrible.

Any government that is doing these things does not represent we the people. Journalists are our loudest narrators - meaning - the government appears to really wish to control our narrative.

<comment><USER25> > Journalists are our loudest narrators - meaning - the government appears to > really wish to control our narrative.

When the narration is coordinated with the DNC, this makes me think they aren't doing their job any more.

But yes, it wasn't acceptable when the Obama administration was wire tapping Fox News reporters, and it's not acceptable now.

<comment><USER26> ABC, NBC, CBS, WSJ, NYT, Chicago Tribune, New York Post, BBC, PBS, NPR, AP, Reuters, etc...

All of these (or even the majority) are controlled by the DNC?

I don't think so, and if that isn't on the nose enough for you, I'll just say that I think you're talking about 24 hour news networks... CNN specifically. Yea, they endorsed Clinton as hard as they could.

So STOP WATCHING THEM, and stop equating journalism to the likes of CNN and Fox. Watch and/or read something else. You speak English and live in a country with a protected press (which is why this article is worrying in the first place). There are literally thousands of newspapers, magazines, television news shows (and networks) out there.

Pick a couple of reputable ones (including at least one that challenges your views) and stop watching piffle.

<comment><USER27> >All of these (or even the majority) are controlled by the DNC?

To play devils advocate, yes they are (to varying degrees), in the same way that college campuses are "controlled" by the DNC.

>and stop equating journalism to the likes of CNN and Fox

Kinda funny how far we've come. CNN used to be the impartial one.

<comment><USER28> It is pretty disingenuous to compare correlating political opinions to being "controlled".</comment></comment></comment></comment></comment>


How To Think Like A Computer Scientist - <AUTHOR> http://openbookproject.net//thinkCSpy/

<comment><USER2> This isn't 'How to Think Like A Computer Scientist', but rather 'Introducing Programming with Python'.

It's a good introductory text for learning Python. However programming is a very small part of Computer Science.

<http://abstrusegoose.com/strips/computer_science_major.PNG></comment>


Ask HN: What does Ruby have that Python doesn't? - <AUTHOR> About 6 months ago I decided to learn either Python or Ruby because I wanted a language to write webapps and simple computergames fast.
I kind of tried both for a while and Python gave the better impression in every way, readability, ease of use, libraries, documentation, expressiveness etc.
But there are so many really enthusiastic posts about Ruby and while Python has a lot of users and is very popular and successful I rarely see anyone rave about it. But maybe that just means it has gotten mainstream.
But anyway I like the Python philosophy that there should preferrably be one obvious way to do things.
While similar in most ways, there the languages differ.
So, what do you Rubyists like so much about Ruby? Especially what do you think Pythion lacks? <comment><USER2> What the hell, they're only karma points:

I lived with Python for 4 years before I lost an argument at my own company and had my project moved to Ruby. I've since moved in with Ruby and haven't looked back.

* Everything in Python feels like a symbol table hack. Private methods? We have those! Just exploit this bug in the class symbol table lookup code!

* First-class symbols. There may be little difference under the hood between a Ruby interned string and a Python string atom, but there's definitely a difference syntactically. This is a difference that is hard to articulate, but if you've written much C, it's like having every "enum" you could ever want predefined for you, and completely eliminates "magic numbers".

* Blocks and lambdas. I've read GvR's take on this. I know he thinks a named function is just as good --- maybe even better! --- than an anonymous function. I had nested named functions/functors in C++ and Java. Even Tcl "uplevel" is better than Python's castrated lambda.

* Method definitions in Ruby don't need to accept a "self" argument. Again: all of Python feels like a symbol table hack to me.

* Ruby has first-class Regexps. Python has an "re" library. You know what else has an "re" library? C.

* I haven't found an expression that is better written as a list comprehension than as a map/reduce/select expression.

There are painful things about Ruby:

* The FFI is immature. Outside of Common Lisp, Python ctypes may be the best FFI out there.

* I never got Python to crash on me (at least, not where it was Python's fault). I crash Ruby once a week.

* Ruby is palpably slower than everything. If performance matters to you and you don't know C, you may be better off in Python.

* The community is led by the nose by Rails developers, which can at times feel like a worst-of-all-worlds grab bag of methodology programmers, web designers, and dabblers.

<comment><USER3> _Blocks and lambdas_

Yeah, but this is an area where both languages are just a mess. If python's lambda is castrated, ruby's notion of an anonymous function is tumorous. We've got blocks, procs, lambdas and methods? What's the difference?

Ruby mixes up the syntactic requirements of "passing" some code to a loop to iterate with with the data requirements of binding a function to a scope. It's just a huge mess.

LISP and Scheme figured all this out decades ago, and yet only Javascript (and, almost, perl) among common scripting languages has managed to absorb the lesson.

<comment><USER2> You say "both languages are just a mess" as if to equate the two. But there's no comparison.

Your Ruby problem with blocks and Proc objects is a nit about elegance and semantics. How often does the difference between an actual Proc object and a block actually affect you? More importantly, if the cost of fixing that nit is that we wind up with Lisp's or Javascript's lambda notation, who would accept that? Javascript has relatively consistent semantics for anonymous functions, but extremely clumsy syntax.

Python simply doesn't have real lambdas. It has the ability to pass something called a lambda in place of a function, and that something forces you to think about things like the difference between a statement and an expression. It then tells you that you don't in fact want anonymous functions, but instead you want to define tens of itty bitty named functions and use them instead. You also "want" that "self" argument to all your methods, and you "want" to tack two underscores to the front of your method names to make them private.

So, I half agree with you. Yes, it would be nice if there was a (zero-cost) way of fixing Ruby's block semantics. Yes, I can rely on Lisp's lambda semantics slightly more than I can on Ruby's, which does start to matter when you start writing domain-specific language code. But I don't agree that this has any bearing on the Python vs. Ruby argument. Python lambdas suck.

<comment><USER4> True python's lambda's suck. And Ruby's lambda's for the most part don't suck.

But ruby's methods really do suck, and so do the complex construction of Blocks. While I recognize that blocks allow you to do weird things (like use return on the calling scope), the fact that they necessitate a special form (yield) and cannot be bound to a variable, and are not passed as standard function parameters just makes them inconsistent and gross.

Methods which aren't first class functions (but can be transformed into one with the helpful helper function!) also suck, and passing those around in a functional way is just a lesson in futility.

All that being said, I have much more faith in these warts being fixed as time goes on, than python's nasty lambda, and the gross over use of dunders.

<comment><USER5> "the fact that they necessitate a special form (yield) and cannot be bound to a variable, and are not passed as standard function parameters just makes them inconsistent and gross."

Which brings us to another point - when exactly do you actually need them? I have for every 1000 lines of ruby code maybe one line of "yield" code, and this is only to further extend classes for flexibility. Other languages dont allow you to choose what you want to have, ruby does.

You simply have to make decisions when to use what.

For me it is simplicity, elegance and beauty. These are my biggest design criterias.

<comment><USER4> I'm 100% with you on simplicity, elegance and beauty. I just demand that as much from the design of the languages I use as from my own code.

I've tried to explain it like this. To me ruby feels Turtles all the way down with respect to Objects, but some kind of nightmare tunnel of interleaved beasts down with Functions.

I don't think I should have to make that compromise, so I'll happily go about writing my ruby when I have to, but I'm waiting for the language that is consistent all the way down.

If I could replace every yield I've ever written in ruby with a .call() I would be so much happier :)

<comment><USER2> Ok, now I'm not sure I follow. Apart from the performance issues, why can't you replace every method that "yields" with a method that takes the explicit block parameter, and .call() it?

<comment><USER4> _sigh_ yeah... you could do that, but you often times you have to deal with methods that aren't invoked that way.

<http://blog.sidu.in/2007/11/ruby-blocks-gotchas.html>

is a good run down of some of the problems here

<comment><USER5> No it is not. You dodged the question again, by throwing a hardly related blog of someone else at it.

How many people will use yield _AND_ self.send in the same method please?! That seems like an awfully complicated and contrived example. Who the heck does this?

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> I don't think Python lacks much, if anything. It's a very fine language, with a great community. Over the years though, I just lost interest in it, and have come to prefer Ruby after having rediscovered it because of Rails. It's pretty much a matter of taste: I like the syntax and convenience more.

One (fairly minor) real world case where the syntax makes a difference is in web templates: you can use Ruby pretty much straight up to do templating, but Python requires more hoops and hacking, due in part to the whitespace issue. I like the fact that Ruby is flexible enough to be used as-is for templates as well as other code. BTW, it also needs to be said that that is the _only_ place I've ever noticed the whitespace issue being any kind of problem: it's not the big deal that some python detractors make it out to be.

In short: if you're happy with Python...great! Keep using it, you made a good choice. If you want to learn another language, pick something a bit further from it... say, Erlang, Tcl, Java, or C, depending on what your needs are.

<comment><USER7> Note that Python is sensitive to _indentation_ not whitespace per se. So long as your line is at the right level there's no difference between

        a=1+2

and

        a = 1      + 2

In fact I wish Python were _more_ sensitive to whitespace, then I could say my-variable without it mistaking a hyphen for a minus.

<comment><USER8> "then I could say my-variable without it mistaking a hyphen for a minus"

That's something cool. It would involve a new PEP and aggressive enforcement of PEP 8

<comment><USER7> Reckon it'd break too much existing code, but hyphens are so much nicer than underscores or interCapping. Using a language that supports that, my hands are noticeably more comfortable without needing to reach for the shift key all the time.

<comment><USER9> you could just use a font that renders underscores differently (like, say, slightly stylized hyphens.) That's the correct approach, semantically--when you use an underscore, you're basically trying to say "a space, but without the syntactic meaning of one."

<comment><USER7> It's not about how it appears on screen but about the keystrokes needed to enter it. If I could I'd find a way to use only square brackets too. Ideally I'd use only ; or : and only ' or " too, and adjust my keymap accordingly.

<comment><USER10> Lisp? ;-)

<comment><USER11> Forth?

<comment><USER7> I really like Forth, it seems to me to be very much the right way to do things, however I've never managed to write an actually useful program in it.

Mostly I use Tcl as a sort of Lisp/Forth mashup :-)

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> They're both impressive, modern languages. What I find interesting when comparing Python to Ruby is how much Python isn't like Lisp. Matz has said outright that he considers Ruby to be "MatzLisp" and it shows, whereas Guido has absolutely no problem chucking Lispy things overboard--like multi-line anonymous functions--if they do not fit the rest of the language.

Instead, Python finds another way, like powerful list comprehensions that can be used wherever Ruby would use blocks and maps.

So I would say you can learn some very interesting things from either language, and there's a good chance they will be _different_ interesting things.

<comment><USER4> Matz might say that, but doing functional things in Ruby is a pain in the arse as well. Blocks, Lambdas, Procs, and Methods, all which are slightly different and require transformative functions to move one into the other. That's about as far from an s-expression as you can get.

That being said, having the easy ability to create lambdas or blocks is hugely benefitial. _sighs_ and I wish python would hop on board there, but I don't think it ever will.

<comment><USER12> I dig: [http://weblog.raganwald.com/2008/06/what-does-do-when- used-a...](http://weblog.raganwald.com/2008/06/what-does-do-when-used-as- unary.html)

<comment><USER4> Yeah... _sobs_ it's a nice band-aid, but an inelegant solution. I would much rather that they all just be Proc or all some other mythical procedure class of the future. I figure that would break the whole ruby method call chain, though I don't see any reason why blocks couldn't just become straight syntactic sugar for lambda (I would love that)

<comment><USER12> A little off-topic, and I apologise to everyone for our exercise in bikeshedding, but... :-)

The problem is that Ruby blocks were designed to imitate the behaviour of C-like blocks, while lambdas are true closures. (Don't get me started on why procs are just like lambdas only different).

The difference between a block and a lambda is most clearly seen by asking what the return keyword does in a block vs. what it does in a lambda.

So in Ruby you can write something like:

        def which_answer_is_correct(*answers)
          answers.each_with_index do |answer, index|
            return index + 1 if answer.to_s == '42'
          end
          return 'none of the above'
        end

        which_answer_is_correct('black','white',42,:symbolic_logic)
          => 3

If blocks were syntactic sugar for lambdas, this method would always return 'none of the above'. Of course, there is another, very elegant way to write this method that doesn't rely on the return keyword or the semantics of blocks, and one can easily argue that this would be an improvement.

<comment><USER4> (though my intention was not to derail the conversation. This is a niggling difference between ruby and python that irks me :-D)

Right I would be arguing as the latter.

My problem is that these small niggling differences between all the different types of callable items (including what I think is simply disgusting use of a special form "yield") confuses the whole mess.

I'm glad that all these different ways to use callables exists. That's "A good thing" in my opinion. But I can't help but feel that their quirks and differences couldn't be consolidated into a single experience.

<comment><USER12> _derail the conversation_

De- _rails_ -ing conversations about Ruby is often an improvement.

<comment><USER4> Good sir I do say... that was quite the pun :-D

 _takes his hat off_

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> I've always taken the approach of learning both and deciding for myself. If you're interested in true proficiency and building something for yourself, go with whatever rings most true to you.

I liked Ruby, but found that Python clicked better for me. That, and call me crazy - but I prefer quiet competence to foaming at the mouth zealotry. There are plenty of people who rave about Python - but they've been doing it for a lot longer than the Ruby people (simply age of language).

Ruby also has gotten lots of people hooked via Rails, and that seems to be where most of the evangelism is coming from.

(edit: commented to clarify my meaning below, in another comment: <http://news.ycombinator.com/item?id=283771>)

<comment><USER14> >> but I prefer quiet competence to foaming at the mouth zealotry.

Do you really pick your language by your perception of its users? I'm not sure that's a great criteria for choosing a tool. If an annoying dinner guest admired the butter knives, would you butter your roll with a fork?

<comment><USER15> Well, working extensively with a language means working with its community, as a reader of news and documentation if nothing else. The size, expertise, and helpfulness of the community are all important factors in deciding whether to adopt a language. If a programmer finds the community annoying, that could be a legitimate problem.

<comment><USER7> The community also determines what is and isn't easy. This is something that a lot of otherwise smart people don't seem to get. Everytime someone into a powerful but obscure language wonders why it isn't more popular the answer is almost always something like "because Haskell's interface to Oracle is rubbish". And that's fine, because the Haskell community care about other things, if they want to be popular tho' they'll have to address that.

Concrete example: The Ruby community is very focussed on the Web, so there's Rails but they aren't really interested in scientific computing so there isn't a real equivalent to NumPy.

<comment><USER16> _Concrete example: The Ruby community is very focussed on the Web, so there's Rails but they aren't really interested in scientific computing so there isn't a real equivalent to NumPy._

I'd mod this up more if I could, because this is the best answer to the original question.

The important thing is the community, not the language. Decide what your problem is, find the people who are working on that problem, and use whatever they use.

The importance of community is the reason why the number of people who praise Lisp as a language is so much larger than the number who _use_ Lisp every day: The Lisp community is small, unfocused, and arguably broken. Meanwhile, I work as a professional Drupal developer and am (god help me) gradually becoming an expert on PHP, but that has nothing to do with my nigh-nonexistent respect for PHP as a language. I do it because the Drupal community is large and growing larger, it includes as many noncoders as coders, and it's focused on building websites rather than obsessing over tools. The result seems to be that customers like using Drupal for their sites. Rails and the like are focused on making programmers feel empowered, but Drupal is focused on making _site admins_ feel empowered.

</comment></comment></comment></comment></comment><comment><USER17> Two good things and one bad thing. The good things are multi-line lambdas (which Ruby calls blocks) and loose syntax rules, which I found weird at first but is the secret behind all of that DSL stuff.

The bad thing is the cultural tendency of the Ruby community towards monkey patching, which in my opinion trades long term maintainability for short term convenience.

<comment><USER4> To be fair... blocks are not lambda's, but things would be a lot better if they were.

</comment></comment><comment><USER18> I like how this conversation has gone on for so long, but on the whole, everyone's still polite and detailed in their responses. :-) _warm fuzzy feeling_

</comment><comment><USER19> It isn't so much about language features, as both languages are roughly equivalent in that sense.

It is about how the language makes you _feel_. If you're going to be spending >5 hours a day writing in some language, it is of great importance how that language makes you feel when you write it. Simply said, writing Ruby makes me happier than I've ever been while writing code.

Python is to German as Ruby is to French. You can get roughly the same message across equally well in both languages, but French just sounds so much better.

<comment><USER20> Two words: "French Engineering".

<comment><USER21> Two counter words: Ariane, Nuclear (as in 80%+ national electricity)... not too shabby as far as engineering goes... I would add Airbus, LHC, etc... but two are enough.

</comment></comment></comment><comment><USER22> _About 6 months ago I decided to learn either Python or Ruby because I wanted a language to write webapps and simple computergames fast._

If you're after writing simple computer games fast, then you might have a look at Pygame: <http://www.pygame.org/news.html>

There are also a number of visual effects companies (ILM, Dreamworks) that use Python as their system scripting language. I don't know if it's because of that community, but I find a number of graphics/games libraries in Python: <http://www.vrplumber.com/py3d.py> and <http://vpython.org/>

Blender the open source 3D modeling program used Python as it's scripting language last I checked: <http://www.blender.org/>

I don't know if Ruby has libraries like that or not. I've only used Ruby to mess around with Rails.

</comment><comment><USER23> For me, the question isn't so much what Ruby has that Python lacks, but the extra Python bits I find annoying and/or tedious:

* having to declare "self" in every method argument — reading code, it just clutters up the screen/page

* the big use of of double underscores for special methods (i.e., __init__, __str__, __getattr__, etc...) — IMV, it's gooberish...

* no switch/case statement

In defense of Python over Ruby:

* I prefer the whitespace over the Pascal-ish begin/end, especially for real life code solutions

* the Ruby shorthand syntax IMV at times obfuscates code clarity - is it a method or variable I am looking at?

That said, I'd much rather code in either Ruby or Python than in Java or C...

</comment><comment><USER24> Well, they're both foundational languages, pretty much, not in the sense of this blog, i.e. most instructional language

<http://mvanier.livejournal.com/998.html>

but in the sense of can you put up a significant web app in 2 or 3 days, do lots of companies use it (along with C, java, C#, javascript).

r vs. p can't be reduced to 15 bullet points, but one of the best things i remember is Alex Martelli in 2003, so he was talking about ruby 1.6 and python 2.3, i believe, but still valid

[http://groups.google.com/group/comp.lang.python/msg/28422d70...](http://groups.google.com/group/comp.lang.python/msg/28422d707512283)

and here's the last thread from May.

<http://news.ycombinator.com/item?id=157269>

There's the other killer apps: Python: twisted, zope, SQLalchemy, mercurial. Ruby: rake, capistrano, rspec, adhearsion, merb, puppet, metasploit. I'm sure python has a bunch more, but i've been living in rails-land.

</comment><comment><USER25> Though I'm pro-Python on maintainability grounds, there's one Lispish feature Ruby has that I wish were available in Python, that's not even in the Py3000 spec: continuations. The Ruby community doesn't seem to be too enthusiastic about using them though. We're just beginning to see continuation-based web framework experiments on Ruby, in the spirit of Seaside in Smalltalk.

The continuation-based web frameworks make state management on the server transparent; but they have a scalability problem since state can't move between servers or even be taken out of memory on the same server.

Now once somebody makes serializable continuations practical - certainly a hard problem - it would be a jolt to web development on at least the same that Rails has been.

<comment><USER26> In Lua, the Pluto serialization library has no problem persisting coroutines, which are isomorphic to one-shot continuations. Lua isn't terribly active in the web space, though this feature has been used to good effect in games.

</comment></comment><comment><USER27> I think that a lot of the popularity of Ruby came not so much from Ruby itself, but Rails. I think that with the emerging popularity of Django, you are likely to begin noticing a similar influx of Python enthusiasm...

<comment><USER13> Admittedly, Django was what first got me really going with Python (we started using it for some small projects as a possible replacement for PHP a few jobs ago).

There are however also some great alternatives within the Python community, in addition to Django which I no longer tend to use.

Pylons, which is very Rails like including having similar WebHelpers functions, and a port of the Rails "routes" system.

TurboGears, which is currently re-tooling itself to be based on Pylons.

And a variety of others that I'm probably forgetting.

I'm admittedly ignorant on alternatives on the Ruby side, but would be interested to see what other web frameworks people have built and the pros cons vs. Rails.

<comment><USER28> _I'm admittedly ignorant on alternatives on the Ruby side, but would be interested to see what other web frameworks people have built and the pros cons vs. Rails._

Merb is the big one. Think Rails, but more lightweight, greater emphasis on scaling and performance, and open to several ORMs (not just ActiveRecord), templating languages (not just ERB), and Javascript libraries.

Camping is a Ruby micro-framework that's been around for a while. The framework itself is 4kb, and Camping apps are designed to sit in one file. Used a bit on the side, but not especially widely for production work.

Sinatra is a newer microframework that looks similar to web.py, but in Ruby. Looks useful, and I've been meaning to get around to it.

The nice thing about Rails, Merb, and Camping is that if you know one, the others will be familiar. They're all MVC frameworks that support ActiveRecord (and other ORMs, sometimes). They all favor convention over configuration.

<comment><USER13> >> Merb is the big one. Think Rails, but more lightweight, greater emphasis on scaling and performance, and open to several ORMs (not just ActiveRecord), templating languages (not just ERB), and Javascript libraries.

Sounds exactly like the reasons why I went to Pylons. I found SQLAlchemy to be a lot more powerful than the Django ORM, and we needed more application components to be 'detached' from the web interface which got wonky in Django.

I'll have to check these out, thanks.

</comment></comment></comment></comment><comment><USER29> After leaving Ruby (non-Rails) for Python this year, I've mostly noticed the difference in the obsession about testing. The Ruby crew is very into TDD (and now BDD)–that isn't to say that Python folks don't test (or do TDD/BDD), but simply that the tools available in Python aren't quite as polished. Ruby's RSpec, RCov, Flog, Autotest, & Heckle are all quite wonderful. I do like Nose, but get annoyed by lack of friendly code coverage tools in Python.

</comment><comment><USER30> Rails. but you have Django which is better ;)

Seriously, I envy ruby's blocks and being able to redefine a class later in your code (monkeypatching-easy-syntax).

Oh, and Shoes :)

<comment><USER31> I chose RoR over Python/Django for one simple reason: RoR's tight integration with the Prototype AJAX javascript library. Personally, I like Python as a language much better than Ruby. But if I'm going to code up a Web app, I want easy AJAX integration - I don't want to hand craft a bunch of javascript. It's not that I've got anything against writing javascript, but I hate, hate, hate trying to debug it.

<comment><USER32> Tight integration with prototype is one of the things I don't like about Rails, mainly because I don't like Prototype (I'm a big fan of JQuery).

<comment><USER2> Then what you want is jRails, which subs jQ in for Prototype in all the Rails helpers and removes Prototype from your project. You "plugin install" it, forget about Prototype, and use nothing but jQuery from then on.

<comment><USER32> very cool, thanks. wish I knew about it a month ago.

</comment></comment></comment></comment></comment><comment><USER33> There really isn't a huge difference between the two. For what it's worth, I personally prefer Ruby because it has better support on the Mac - Apple use ruby a fair bit themselves. For example, the command line tool gen_bridge_metadata (supplied by Appleto make it possible to access system frameworks written in C from scripting languages) is itself a ruby script. I notice that on Linux it's the reverse - python seems to be the preferred scripting language.

But don't take my comments as saying only ruby is supported on the Mac, or only python on Linux - in reality it's only a light preference one way or the other.

<comment><USER34> The CalDAV server authored by Apple and included with OS X Server is written in Python. PyObjC receives a lot of attention from Apple employees. I don't think there's much preference exhibited by Apple one way or the other.

And vice versa, there must be some Linux distros that have tools written in Ruby, right? Particularly some of the newer ones, I seem to recall hearing that their system tools were Ruby.

<comment><USER35> FWIW, the wiki that Apple includes in Leopard Server is also written in Python. Apple apears to be making much more use of Python than it is of Ruby.

<comment><USER36> Counter-counter: Podcast Producer is a Rails app. I think Apple is just letting their employees pick their tools (at least for server apps) as they see best, rather than arbitrarily enforcing the choice of a single language.

</comment></comment></comment></comment><comment><USER37> The languages are similar enough that it does not really matter. Just pick any, but make sure you balance it out by also knowing a low level language or a functional language.

Remember this: Every language you learn is a big investment in time and energy, and I don't think many people can be really proficient in more than 2 or 3 languages. Some can, but not most.

So, choose wisely, because you will likely be using that language for a long time to come. I personally prefer python because it's more widespread and right now, you have more available to you when you know it than with ruby.

<comment><USER38> maybe i'm an incredible genius or something, but give me a week or two and i'm writing code at an advanced level in any language. it's pretty easy. it more or less involves making an actual project in that language, which cold turky sink or swimly requires that you know the language at least decently

i think it's mostly mentality. if you think languages are hard to learn, then they will probably seem that way because you will allow yourself too much time to play around with mere _details_ , whereas if you recognize there isn't much to them, you can accomplish a lot in no time at all

<comment><USER37> I think it is more likely that you do not recognize your own flaws. It takes a real genius to be able to learn the little things about C++ in a week or two.

A language is not just the syntax of the language itself, it's also the code style, the convention, the best practise, the language specific stuff, the API of the libraries available, the best way of doing things with libraries.

If you use python to write simple number crunching console applications, then switch to ruby, that is an easy switch.

But if you're writing a Web application using Python and Django and you switch to writing DirectSound using C++, and you tell me you can do this in a week, then you are a genius.

The syntax of languages are trivial, but that's like saying you can discover the colors used in a painting. That's the easy part. The difficult part is knowing how it works. Let me list a few examples of technologies that I think differ strongly from each other that make it difficult to switch

\- MFC with C++

\- Django with Python

\- DirectShow with C++

\- VHDL

\- ASM

\- Javascript with JQuery

\- CSS with HTML

\- Helix Framework with C++

\- Quicktime API with C++

\- OpenGL with .NET

\- LISP

Have you ever had to switch between things on that level? Or are you talking more of a python to ruby switch?

<comment><USER39> To go one step further, to be at an "advanced level" in a language also means to be idiomatic in it.

I have a hard time believing that's achievable in a "couple of weeks", regardless of the level of someone's "genius".

(Also, just because something compiles doesn't mean you're good at it.)

<comment><USER38> when programming, if you keep your mind on the structures and on the problems themselves instead of on the language, you'll naturally reach points where you will demand that the language do X. sometimes the language will be able to, and it will seem "advanced." sometimes the language won't be able and you'll sob quietly for a moment because you have to implement it in another less elegant way

but if you worry about the details of the language, it will prematurely affect the structures that you create. in this mode it's harder to write "advanced" things because you are respecting the language too much, and are more confined to its syntax/semantics

if you stay above/outside the language, you will naturally pull it up

<comment><USER37> Well, you prove the point. You are incapable of seeing your own weaknesses in a language.

One can write every language the same way, but that's not programming. You can't learn python and then write C the python way. You can't write Python as you would Java.

Syntactically, it's possible, but that's a different language you are using then.

Don't confuse syntax or knowing when to use particular constructs with knowing a language. Call me slow, but it took me 3 years before I felt confident that I really knew most of C++. I know when to use Boost, when to use STD, What AtlArray is, how to write an IDL file, what extern 'C' does, what an stdcall is, how my variables are layed on my stack, what Gui toolkits are available, how Borland C++ makes properties appear in C++ classes, when one should use an int64, etc.

It takes time to learn that stuff, but to be really good at a language, you need to know it.

We're like doctors, you don't need to apply your knowledge all the time, but when you need it, you need to be aware of what exists and where to look it up.

If they ask me - write a webserver under Windows, I need to instantly be able to think of 3-4 libraries I could use for the low level stuff, and then decide which is best. All that takes time.

The syntax is nothing. A language is a whole lot more than that. You can't stay above a language. You need to delve into the language, you need to have a feeling for the language, you need to feel inside you how to express things in a particular programming language.

When you describe a problem to me, I can see the C++ structure in my minds eye. I can mentally walk through the code, see where I would use templates, where I would use an interface class, where I would subclass and so on.

I can't do the same with python, because even though I know the syntax, I've not used it long enough to get an extreme feel for the language. And the python folks like to reduce stuff down to short lines, and that's something you don't do in C++.

Learning a programming language is learning a new way to think. Not a new way to string sentences together.

<comment><USER10> > If they ask me - write a webserver under Windows...I can't do the same with > python

I'd use BaseHTTPServer. Batteries included and all that. ;-)

</comment></comment></comment></comment></comment></comment></comment><comment><USER40> I prefer Python, but I am somewhat envious of Ruby blocks. Also I like the idea that method calls are messages.

<comment><USER41> I've done quite a bit of Smalltalk programming, and I agree about the blocks. But what do you mean by "method calls are messages"?

<comment><USER26> In Ruby calling a method on an object basically sends a message to the object with the name of the method and the arguments. You can hook into the dispatch code and do pretty much whatever you want with that message at the class level. I don't know the internals of Python's method dispatch that well, so I can't say how it compares in that regard.

<comment><USER7> I believe Python's __getattr__() and __setattr__() allow you do the same thing, but I don't know enough Ruby to say for sure :-)

<comment><USER4> You couple those with ruby's method_missing and then you have some interesting functionality. But basically the way that Ruby handles operator overloading and function accessing is a lot cleaner than pythons. It would be pretty nice to get rid of a lot of the dunders.

</comment></comment></comment></comment></comment><comment><USER42> this is never really brought up, but objects in ruby fully encapsulate their instance and class variables. the only way to get at them from the outside is by sending an object a message asking for them (like Smalltalk or Objective-C). what appears to be setting a property on an object, is really calling a method: `foo.bar = 5` isn't directly setting the property, its calling a method named `#bar=`

in my opinion, this is powerful and elegant.

that being said, i have little experience with python, but what i've seen never wowed me. it seems like it has a well written collection of libraries, but that seems to come from the community more than the language. correct me if i'm wrong.

<comment><USER43> You can do exactly the same thing using Python descriptors. No advantage to Ruby here.

<comment><USER42> but its not enforced by the language or the object model. advantage ruby ;)

</comment></comment></comment><comment><USER44> _why

</comment><comment><USER38> personally i don't like the 'one way' mantra that Python is designed by, because it seems to imply a couple things. 1, the language is probably not as flexible and powerful as it could be. and 2, the design goal is similar in nature to that of production languages, eg Java which forces object orientation. the intentions are good... to allow the construction of readable, maintainable software by normal humans, and Python is at least not as retarded about it as Java, but i have found that languages which constrict aren't for me

so to me Python seems more of a team production dynamic language than one where i can get into flow and crank shit out

<comment><USER10> The practical benefit of "one true way" is that it eliminates decision points. Most of the time in a software project is wasted in making decisions; if you eliminate all decisions that are not relevant to getting the software finished, you have a huge head start on everyone else.

There's a joke going around that a Python team will finish a project before a C++ team can decide which brace style to use...

</comment></comment><comment><USER45> The lack of built-in regular expressions is a pain point for me.

</comment><comment><USER46> Consistency in class definitions (that is, not two "types" of class). Python's packaging is less consistent. Oh, and far better community sites.

</comment><comment><USER47> First class symbols are the big one, I think. Of course, we all know about Python's brain-damaged function literals.

</comment><comment><USER48> I really like Python, but it doesn't have an equivalent to CPAN or RubyGems.

I'm actually quite puzzled by this.

<comment><USER34> Read up on setuptools and the Python Package Index, aka the Cheeseshop. Setuptools hasn't yet been adopted as the one true packaging format by all library creators, but it gaining acceptance.

<comment><USER48> Ok, awesome. And that's the same story as RubyGems. I've noticed that Python peeps are pretty big on "show me the code" anyway, but I think a lot of untapped potential is lost by not having a dead-simple distribution mechanism, as good as Python libs tend to be overall.

That's one thing I do like about Ruby; it wasn't always this way, but RubyForge + GitHub (Oh, GitHub!) + RubyGems combine to make for a very fluid feedback mechanism and make good use of The Cloud.

The result is that new libs get announced, distributed, tested, and improved by rabid Rubyists rather... rapidly.

</comment></comment></comment><comment><USER7> My experience is that the languages are similar in terms of features, but the communities are very different and there isn't much overlap between them. Ruby types tend to be younger, focussed on the web, probably employed as full-time developers. Python types tend to be older and not employed as developers, but write code as part of their main jobs. Python people often have experienced a nightmare of unmaintainable Perl, that is why there is the insistence on there being one right way to do everything (which is the exact opposite of what Perl people believe). Ruby people (being younger and hence less experienced) haven't, which is why they talk about expressiveness and do things like monkey-patching. Neither group is "smarter" and neither language is "better". The choice is a choice of what community you want to join, not a technical one.

<comment><USER49> From my observation, the ruby community is heavily skewed by the recent influx of Rails programmers, which is web dev and younger. Old-school ruby folks (the guys who were ruby gurus when Rails was still an infant) have different characteristics: older, less confrontational, veteran programmers, Matz-like. A generalization for sure but my impression.

The python community has done significant development in science/math so they have stronger libraries in those fields. Python has had an influx of Railsy people due to Django and might get a shot in the arm from Google App Engine.

From a language perspective, I like the wealth of libraries for python. I like that many reference/experimental applications on web stuff is in python. The whitespace issue for me has disappeared and I'm actually leaning toward liking it more than ruby's block delimiters. The template/erb issue can be diffused by looking at HAML. (That's a cool way of incorporating pythonic indentation to templates.) Unicode is solid in python.

Ruby is a better choice if you like to reshape the language into something that could potentially look un-Ruby. It's possible I haven't gotten far enough into python yet, but I can see why metaprogramming and DSLs are more prevalent in ruby than python, and it's not just "one way" culture. (Ruby's optional parentheses for method calls is an example of a language feature that fosters DSL use.)

<comment><USER50> I have to agree. Ruby has incredible flexibility, but how it's been used by "the kids" in things like Rails (and especially Rails extensions) makes my skin crawl.

This also bugs me to no end: nil.to_i == 0, 0 evals true, but nil evals false.

Python's lack for me is anonymous functions. It's cumbersome to set up 40 slightly different named functions and a hash table (or some "factory pattern" thing) to do the same job as 3-4 lines of Ruby. Symbols are nice too.

But for my personal work I choose Python for the libraries, cleanliness, and performance.

<comment><USER49> What are you doing that can't be done with python's lambda functions?

<comment><USER12> What are you doing with Python that can't be done with FORTRAN?

<comment><USER49> Running on Google's App Engine :)

Seriously, though, I'm not arguing python's anonymous functions are just as good as ruby's. I'm curious about his particular situation where "3-4 lines of Ruby" is all it takes.

<comment><USER11> You could run FORTRAN on a virtual machine on Python.

</comment></comment></comment></comment></comment></comment></comment><comment><USER51> I would love to read pg's thoughts on this question.

Actually, I would love to read more of pg's thoughts on Ruby, what I have read of his thoughts on it has been brief yet highly positive.

</comment><comment><USER41> Hype? ;-)</comment>


Three Skills of Great PMs - <AUTHOR> http://bubba.vc/2014/12/08/the-three-skills-of-a-great-pm/

<comment><USER2> Probably meant 'PMs', not 'PMS', heh.

<comment><AUTHOR> indeed I did...fixed.</comment></comment>