"Apple took away Messages.app UI scripting capabilities in OS X 10.11" - <AUTHOR> https://github.com/CamHenlin/imessageclient <comment><USER2> I love open source and open protocols as much as anyone on HN, but honestly, secretly, I love the tied-down nature of iMessage because that keeps it (mostly) free from spam and abuse.

If you want something more open, that exists too, which is great. It doesn't make sense to complain that iMessage isn't what you want it to be. Choice means that open _and_ closed solutions exist in the market.

<comment><USER3> Choice means interoperability, not picking between walled gardens.

<comment><USER2> Choice means choice, not interoperability. Choice means I get to _choose a walled garden_ or an open protocol.

<comment><USER4> Except in quite a lot of cases - like communication tools or social media platforms - you _didn 't choose anything_. Your friends did, as an aggregate - as individuals they didn't chose anything either.

Somehow people recognize that illusion of choice when talking about Facebook, but fail to recognize it here? Weird.

<comment><USER5> Facebook is quite different from this case. If you friends use Facebook to communicate, you need to as well. There is, as far as I know, no alternative. But if your friends use iMessage to communicate, you can easily communicate with them through SMS. Just turn off iMessage, and Apple will recognize this and fallback to SMS. You are not forced to use iMessage just because your friends does.

<comment><USER6> You wish Apple would recognize this. But in fact my sister did this, and filled out their web form and did everything else they suggest. And Apple still does not recognize it. (On the inbound side. )

She can text me, but when I or anybody else On an iPhone try to text her it goes to iMessage and she never receives it.

Yes this is "just a bug", but it also seriously promotes lock-in. It's a very strategic bug, and if she hadn't bought a new phone she would probably be back on iMessage.

iMessage is not always a choice, sometimes it's for life whether you wanted it to be or not.

</comment></comment></comment></comment></comment></comment><comment><USER7> I don't think it actually helps with spam issue, at least not in China.

Almost every iMessage user who activated with a Chinese mobile number has been receiving 3~10 spam iMessages everyday about online gambling and etc since ~2012 when iMessage service went live in China. The content for those messages have been pretty much the same with some minor variant on wording.

With the scale of the spam, I believe it's likely not sent thru UI scripting, but the iMessage protocol might have been well reverse-engineered and exploited by spammers. So disabling UI scripting won't help anything but cause trouble for developers with legit usage.

<comment><USER8> At Chinese wage levels you might just set up a sweat shop and have people send messages by hand. It worked to break captchas, too.

<comment><USER9> precisely: [http://i.huffpost.com/gen/2575582/thumbs/o-WET-570.jpg?7](http://i.huffpost.com/gen/2575582/thumbs/o-WET-570.jpg?7)

<comment><USER10> Hadn't seen that before. But there's one disadvantage with breaking captchas: have you been challenged recently with Google captchas? They take much, much longer to solve and oftentimes you don't even pass. This is with their image neural net training captcha. It constantly asks you to select more than the visible and inserts new images until it's satisfied. What I'm saying is that any site that uses Google's captcha system before posting a comment or something similar takes up much more of my time than it did before. I'm not sure if this is strictly needed, seeing many sites that manage with simple captchas. My impression is that Google turned their captcha system into a mechanical turk for letting the masses work for them and train their image neural net.

<comment><USER11> I haven't gotten anything except that "I am not a robot" captcha.

Generally I am not that upset if a business uses a captcha; I'm willing to meet in the middle. I as the customer am the one paying for fraud, do you think the CEO just takes fraud as a deduction out of their paycheck?

<comment><USER10> The general idea of a captcha is valid and sound, but it's a problem if captchas turn into crowdsourced labor for Google's neural net. First it was reading house numbers, which was easy and not that time intensive, thus acceptable, but the new captchas are a time sink and hard to accept.

<comment><USER11> It takes time to solve a captcha regardless of whether or not it's going to /dev/null or into some neural network.

(My second paragraph was actually directed at a reply to your comment.)

<comment><USER10> > It takes time to solve a captcha regardless of whether or not it's going to > /dev/null or into some neural network.

Yes, and if Google's captcha didn't get much harder, I wouldn't mention it. At least they stopped showing impossible to read random words. They had one variant which I never once passed and had to reload until I got something with distinctive letters.

<comment><USER8> It's definitely getting worse. Last week I had to give up on trying to file a warranty claim for a WD hdd, because their warranty portal stuck me in a "select all images showing X" captcha loop for 45 minutes.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> They didn't remove all OSAScript (AppleScript) functionality apparently. This tiny thing still works: [https://gist.github.com/aktau/8958054](https://gist.github.com/aktau/8958054).

Perhaps the OP really is talking about the Messages.app UI, but the screenshot on github imply that this is some sort of alternate UI (curses-based). Perhaps I'm misundestanding.

<comment><USER13> There is no API for Message; this github repo was scraping/scripting the Message.app GUI to create a Message command line client. OSX has removed the ability to scrape/script Messages.app GUI, so the github repo is dead in the water.

<comment><USER14> There is a scripting API and most of it still works. For instance you can do

        tell application "Messages" to send "This is an SMS" to buddy "+14155555555" of service "SMS"

<comment><USER15> I use Gammu to forward received SMS messages from a USB 3G modem to iMessage (which then appears on all my devices) -- [https://gist.github.com/rcoup/93460ea39b05e957e884](https://gist.github.com/rcoup/93460ea39b05e957e884)

Unless it's been disabled with 10.11.5 it's still working :)

</comment></comment></comment></comment><comment><USER16> Funny to see someone besides me post a link to one of my git repos :) What I've done to get around of some of these issues is run an OS X 10.10 VMware image to handle running iMessage-related code. This gets less UI interference since it is fairly AppleScript heavy. Another poster pointed out that disabling some of OS X's security features seems to make this work as well, but I didn't really feel comfortable recommending that anywhere. I just want to easily and programmatically send and receive iMessages!

<comment><USER14> It's not clear from the note on the git repo, what got removed and what functionality got disabled?

<comment><USER16> UI Scripting capabilities were quietly blocked from being used with Messages.app in OS X 10.11

<comment><USER17> I don't understand. In Yosemite you don't need any UI Scripting. Have they removed this from El Capitan as well? What happened to:

       tell application "Messages"
          set iMessageService to (first service whose service type is iMessage)
          send "Hello World" to buddy "0123456789" of iMessageService
       end tell

<comment><USER16> No, that will no longer work in OS X 10.11 without disabling OS X's system integrity protection

<comment><USER18> I also just tried it on 10.11.5 w/o SIP disabled and it works for me too.

<comment><USER16> Cool, didn't realize that, thanks for checking. However this method doesn't appear to work for group chats as far as I can tell, only one-on-one messages

</comment></comment></comment></comment></comment></comment></comment><comment><USER19> Normal.

There were people selling apps that bought iMessage to other platforms, by using VMs in servers running the desktop App and using the scripting functionality.

<comment><USER20> This gets to the heart of why Apple probably did it and why it's significant.

It was a nasty hack for interoperability but it worked and is probably the only thing that would work. It also indicates how much Apple cares about squashing interoperability for iMessage. Whether you feel this is because it presents a security risk or a business risk is down to the cut of your tin foil hat.

<comment><USER21> Well, Apple originally planned to make FaceTime (and thus presumably also iMessage) an open standard. Patent trolling put an end to that.

<comment><USER22> I always wondered about where that promise went. Do you have a source for your statement?

</comment></comment></comment></comment><comment><USER23> It should be pretty easy to work around this, either by hacking around (e.g. with a debugger) whatever call was used to disable UI scripting, or by using the interface between Messages.app and the IMCore framework, which is a relatively high-level Objective-C API. On the other hand, for the record, reimplementing an iMessage client from scratch would be difficult due to DRM: while the protocol is generally sane, it includes an authentication layer based on FairPlay, involving heavily obfuscated code. Some information here, though I'm not sure if it's up to date:

[http://imfreedom.org/wiki/IMessage](http://imfreedom.org/wiki/IMessage)

<comment><USER24> _by hacking around (e.g. with a debugger)_

In 10.11 Apple added System Integrity Protection[1][2], so it might not be as simple as it once was to hack preinstalled apps. From wiki:

 _Most preinstalled Apple applications in /Applications are protected as well. The kernel stops all processes without specific privileges from writing to flagged files and folders. It also prevents code injection, runtime attachment (like debugging) and DTrace_

[1] [https://support.apple.com/en-us/HT204899](https://support.apple.com/en- us/HT204899) [2] [https://en.wikipedia.org/wiki/System_Integrity_Protection](https://en.wikipedia.org/wiki/System_Integrity_Protection)

<comment><USER23> SIP can be disabled by the user by design, but yes, it would require doing so.

</comment></comment></comment><comment><USER25> I also built a Messages.app companion app that 10.11 largely broke: [https://github.com/kethinov/BubblePainter](https://github.com/kethinov/BubblePainter)

Still technically works if you disable SIP, but that's a big ask just to be able to use my little toy app.

</comment><comment><USER26> I've got a Mac at home which I use for my own personal iMessage bot to do certain tasks in my house. I specifically left this Mac at Mountain Lion, since I sort of anticipated problems further down the line with the newer versions of OS X. I can probably safely upgrade to 10.10 but it was finicky enough to set up the AppleScript to work with my scripts.

</comment><comment><USER27> I just bought a jailbroken iPhone which I'll upgrade to a newer release supporting SMS handoff, etc; then use for running a message server so that I can send and receive synchronized messages on my Windows development PC the same way I can on my Mac.

</comment><comment><USER28> I don't think this change was to intentionally block this repo. In OS X 10.11, more system apps including Messages.app has been white listed for SIP protection. Everything works if you disable SIP protection.

It is understandable that Apple doesn't want malware to easily read people's messages.

</comment><comment><USER29> Why is everybody fighting so hard to use iMessage? I just tell people I can't use it since Apple doesn't provide a solution for everybody. I thought that was the normal response. Why are people losing sleep over this?

</comment><comment><USER30> It's still possible to script with tools like Sikuli for example.

Edit: I mean for the purposes of spam, not for the purposes of making an app like the one OP linked to.

</comment><comment><USER31> That app is such a hunk of junk, on every platform. It's disgraceful.

<comment><USER32> I'll bite. What's wrong with it on iOS?

</comment></comment><comment><USER33> Nothing new: Apple loves removing functionality from their products.</comment>


Speech-Based, Natural Language Conversational Recommender Systems - <AUTHOR> http://grasch.net/node/147

<comment><USER2> This is really impressive, but personally I'd rather interact with such agents in typed text, at least as the input method. But maybe I'm just too old.

<comment><USER3> No, I think tend to think your preferences are common.

Until a robot voice gets an appealing personality that people enjoy talking to, people will avoid interacting with "robo voices" if at all possible. Even though may interactions with voice recognition applications have reached the point of being "seamless", I still dislike the things.

Another factor is that voice isn't very desirable for things that involve only formally specifying something. If you type out the key word-preferences for recommendations, you can see what they are and change them easily. If you interact by voice, you'd need to have your preferences tediously read back to you.

Even if a person has a human assistant to perform various chores for them, the value of that assistant would derive from being able to make choices wouldn't want to overtly make or think about yourself - someone who would buy clothes for a person with no interest in fashion but needed to look good for example. Even in this case, you'd want the preferences for your assistant spelled out so much as it made sense. Once robot voices pleasant enough, they'll probably still want to supplement any interactions with "notes about the conversation" that the person could also edit.

<comment><USER4> Author of the system here.

I do agree that speech-based interfaces can be very cumbersome. Part of this is that current systems aren't perfect yet but part of it is also that speaking aloud is just plain strenuous for people. At least the second thing isn't going to go away.

Some of the things you touched on are certainly valid points, but spoken language systems also have big advantages. For example, having to spend effort for fully form a thought (to articulate it coherently), forces users to spend a second think about what they actually want. Also, and this was a part of this research, the spoken voice carries quite cool side-channel information that can be exploited in aiding recommendation.

In any case, please note that the current UI (which, btw, did show the gathered preferences to some extend by coloring / bolding the shown specs proportionally to the level of satisfaction of your determined preferences / the level of influence) is just a research UI. It does not implement the best I could do, but rather implements an interface that I allowed good interpretability of the results of the conducted study (which, for example, excluded any multi-modal efforts which would have potentially made drawing conclusions harder).

</comment></comment></comment><comment><USER5> Pretty interesting work. Thanks for sharing !</comment>


Plea for help from HN community - <AUTHOR>

I've gotten so much out of coming to HN every day. My entire nascent programming career and capacity to sustain my family is among the greater things directly tied to life decisions that were strongly influenced by this.
For this reason, and not to spam or cause clutter, I'm asking for help. My niece of 20 months has brain cancer. Her parents believe her best chance is a treatment they recently got FDA approval to try. The only problem is that simply lack money to even start the first round of treatment. Any help, either directly or indirectly provided, in any means, will help--
http://www.gofundme.com/7djqbw <comment><AUTHOR> If anyone has any questions about legitimacy please feel free to contact me.

about.me/ethanpearson supercriticalfluid is my email address at gmail

</comment><comment><USER2> Does [http://watsi.org](http://watsi.org) operate wherever you are?

<comment><AUTHOR> Now that you mention watsi I'm feeling foolish for not have made the connection (with all my time on HN) and looked into it (I think I'd just always related it more to impoverished people outside the US rather than extreme cases within the US). I will look into it and pass this along to my sister and her husband. Likely better than the high rates taken from gofundme.

</comment></comment><comment><AUTHOR> BTW here's an article in the local press that came out when they initially petitioned the FDA for the treatment.

[http://www.ksl.com/?nid=1009&sid=29959572](http://www.ksl.com/?nid=1009&sid=29959572)

</comment><comment><USER3> Are "antineoplastons" the only treatment option left for her?

<comment><AUTHOR> After her parents looked at the statistics and probable quality of life and perceived lifespan of those who endure more traditional rounds of chemo and radiation they made the decision to go with what they felt would give her the best quality of life overall. They don't want to simply give her a cure that will make her suffer massively now and give her a legacy of health and mortal consequences more tied to the treatment than the actual cure.

</comment></comment><comment><USER4> Wishing you all the luck and good energy you can muster, Ethan.

<comment><AUTHOR> Thank you. It's very much appreciated!

</comment></comment><comment><USER5> Wish you the best - brain cancer has ravaged my family.</comment>


Ask HN: Why torture yourself with Objective-C? - <AUTHOR>

A bit confused here. I've deployed multiple iPhone applications with 0 native functionality only using HTML/CSS/Javascript. I've deployed to over 10 phones and everything works perfectly.
What is the point of using OBJ-C? It seems much harder to learn and use efficiently. I have a few friends who refuse to use anything but obj-c for their apps and as a result, it's taking them forever to deploy with much more headaches. Meanwhile, I'm deploying to multiple platforms with everything working flawlessly, even accessing native phone features.
Genuinely curious, not favoring one over the other as I've never ever laid hands on objc, though I tried once, I gave up. <comment><USER2> Not everybody thinks Objective-C is torture. Some people might even say that HTML/CSS/Javascript is more torturous. And I am sure that there are people who are more productive in Objective-C than you are in HTML/CSS/Javascript on the iOS platform. Especially when they are implmenting features that are impossible to implement without using Objective-C.

</comment><comment><USER3> The most compelling reason to use Objective-C for iOS development is to make use of the vast array of device-native APIs provided by Apple, most of which are not available to webapps as of now. While you can use PhoneGap/Cordova to wrap your webapp in a native container, and access many native APIs, the process is convulated to say the least. Besides, with Apple releasing new API's(1500 new APIs for iOS 7 [1]) with every upgrade, the likes of PhoneGap cant really keep up with natively available functionality. Performance is another big reason which comes to my mind.

[1] [http://www.macrumors.com/2013/06/12/upcoming-ios-7-apis- gami...](http://www.macrumors.com/2013/06/12/upcoming-ios-7-apis-gaming- improvements-multitasking-support-airdrop-and-more/)

</comment><comment><USER4> I personally don't think that HTML and CSS are a good fit for building complicated, highly performant mobile layouts in the first place.

Additionally, despite my love for JavaScript, JavaScript is not as fast as native code on mobile phones. You can really feel the difference between a fully native app and a web based app on iOS. (well, unless you can build something as good as Fastbook[1])

But there are definitely things that you can do with two lines of HTML & CSS (like advanced text layouts) that require much, much more code in Objective-C.

Someday it will become a personal choice and hopefully won't differ at all to the user, but I don't think we're there just yet.

[1] How on earth is this this good? [http://fb.html5isready.com/](http://fb.html5isready.com/)

</comment><comment><USER5> Because I don't see it as torture. I find Objective-C to be a perfectly pleasant tool, and it allows me to do things that would be A) implausible or B) impossible were I to make webapps (or PhoneGap apps) instead.

</comment><comment><USER6> Sometimes you can't do what you need to do in HTML/CSS/JavaScript. I was trying to make an application that could read straight off of a TCP socket to stream images from Twitter, Facebook, Instagram, and Google+ into a mobile app in real-time. With the amount of data I was pushing though, the JavaScript couldn't keep up and was crashing so I had to go native. I think a lot of light-weight apps can be written in JavaScript, but sometimes it's just not possible.

</comment><comment><USER7> I have never seen a non-native app that works as well as a native one does or would.

It's a simple trade-off: easier development vs better user experience.

</comment><comment><USER8> Note that Facebook went from an HTML 5 iOS app to a native app. See this post: [https://www.facebook.com/notes/facebook-engineering/under- th...](https://www.facebook.com/notes/facebook-engineering/under-the-hood- rebuilding-facebook-for-ios/10151036091753920)

</comment><comment><USER9> Performance reasons, native API / framework availability.

A native developer can achieve anything the JS dev can, but vice versa does not apply.

OOP is a pain to learn, but once you learn it, you have access to all OOP languages. I like Obj-C, and Apple's API are great.

</comment><comment><USER10> > Though I tried it once, I gave up

Perhaps experience is the deciding factor. I thought the same thing about Common Lisp and Haskell until I took the [long] time to learn them. A steep learning curve doesn't mean the tool sucks.

</comment><comment><USER11> Because Web technology just doesn't have the performance to do what I want to do.

Because every time I use a language that lacks Smalltalk-style keyword messages, I find myself missing them.

</comment><comment><USER12> I really appreciate this question. Thank you for asking the seemingly obvious - yet, not at all.

<comment><USER13> It's actually kind of obvious. If there weren't benefits, people wouldn't use it, and there are some pretty obvious benefits. Why use a directly compiled language instead of a scripting language put through two(?) layers of translation? Why use a language that let's you directly access all features of the platform? etc

Honestly, there are few apps that provide anywhere near the user experience that a native app does (one of those being facebook) and even they opted to switch to native. I've written a graphics intensive phonegap app and... needless to say, that was enough incentive to learn objective-c and I'll never look back. Objective-c is actually an awesome language, it's just tough to learn for most developers coming from a standard dot notation language.</comment></comment>


(and why) to build a programming language - <AUTHOR> https://corecursive.com/032-bob-nystrom-on-building-an-interpreter/ <comment><USER2> See here [https://news.ycombinator.com/item?id=20069538](https://news.ycombinator.com/item?id=20069538)</comment>


Ask YC: Do 30 day trials actually help get customers? - <AUTHOR>

Has anyone here seen any benifitof offering customers 30 day free trials for a web based product. <comment><USER2> Salesforce.com offers a 30 day free trial and it works for them. If you are offering a Wiki I believe it would be a good idea but in doing so you should be sure to engage the customer with daily emails over the 30 day trial.

When I tried offering my first web application in 2001-2002 with a 30 day free trial I has 1,200 trial sign up and 3 conversions. I didn't follow up with those who signed up, I didn't collect phone numbers to make any phone calls, I failed in that partly because I just didn't engage the consumer. I got them in the door but left them hanging to figure things out themselves and sell themselves.

<comment><USER3> Might also be worth ensuring that the users have support or at least howtos to set and use your app, ensuring that they're actually using it during the trial (maybe auto-extend their trial if they never got around to using it -- you don't want to lose them instantly if they finally go to the app and the trial is over).

<comment><USER2> I like that auto-extend idea. "We noticed you didn't get a chance to use your trial period, we wanted to give you a second chance trial and help you get started".

</comment></comment></comment><comment><USER4> I know that my previous company did get more customers when they were advertising a free 30 day trial than whey they were not. I am certain that enough of the customers stuck around after 30 days to make it worthwhile.

The business was very much customer-service oriented. Every new customer got a phone call to ensure that they were properly set up, give them a 5 minute or so introduction to the product, and personally invite the customer to a weekly live training webinar.

They catered to less computer-savy people mostly, but even the technical folks seemed to appreciate the personal touch.</comment>


1608 hours of work logged since November using RescueTime - <AUTHOR> http://ivankirigin.posterous.com/1608-hours-of-work-logged-sinc <comment><USER2> Wow. Pretty amazing to see that post-YC dip (we had 'em too-- I haven't spoken to a YC RT user who hasn't seen a 30-40% drop after demo day-- that held steady). Makes you wonder-- is 3 months the right length of time for YC? What would you get if YC was 4 months? What if YC invested ~$50k and the experience was 6 months?

Of course, if DHH is right, maybe I'm actually getting MORE done. But it doesn't feel like it.

<comment><AUTHOR> The YC work cycle firstly unsustainable. It's an aberration by design: work like mad to pump something out.

Secondly it's compounded by investor meetings post demo day. They eat up 30-60% of your time.

Ohh and I don't think DHH is right. There is a direct correlation between time spent on apps tagged 'dev' and getting things done. The only question is whether it can last long enough before you burn out. For me, there is nothing too hard about a 45-55 hour work week, and it seems very sustainable.

</comment></comment><comment><USER3> Only 15 days with more than 12 hours total put in? What kind of startup are you :~) ?

Seriously, that's some really good real-world confirmation about what kind of time real startups are putting in.

<comment><AUTHOR> Use rescuetime! You'll be very disappointed that you don't work nearly as long as you think you do.

It's really just a re-normalization though.

<comment><USER4> Agreed.

I used rescuetime, or maybe some competitor, for a few weeks.

I spend 60 hrs in the office, and am far more disciplined than I ever have been before in my life...and it was hard to clock 45 hrs of REAL work.

Depressing.

On the other hand, better to do that AND HAVE DATA than to do it and not know the truth.

Data lets you create a feedback loop and improve.

<comment><USER5> Is there any data available on the avg no. hrs/week [insert type of user here] puts in?

I've been surprised at some of the readings as well.

</comment></comment></comment></comment><comment><USER6> RescueTime is nice, but if a majority of your time is used browsing a random number of domains (read documentation, blogs for problem x, procrastinate on slashdot etc) it's gets hard to separate "productive browsing" and "unproductive browsing" without going through a large tedious list of websites every day. And even then, the same domain may be productive one day, and unproductive the next. Eventually you just find the benefit isn't really there and stop checking the website. And then eventually you stop the watcher application because it interferes with your computer usage or sometimes pings to %100 processor usage.

If you guys could solve the 200 random domains a day kind of problem (put all domains under 3 minutes in a 'random browsing' category, or you could add a 'i'm procrastinating' button), it might make RescueTime a useful application for me.

<comment><AUTHOR> I can say for a fact a small minority of my time is spent on domains I don't bother tagging as waste or dev.

If you are spending a lot of time on random domains, I think even considering rescuetime has identified a clear way to, err, rescue time.

</comment></comment><comment><USER7> SlimTimer is an app that does the same and runs in the sidebar of your browser. You just need a bookmarklet and don't need to install anything. I use it daily.

<http://www.slimtimer.com/>

<comment><AUTHOR> Does it track apps outside your browser?

<comment><USER7> You manually tell the app what you are doing choosing the task on a Firefox sidebar.

<comment><AUTHOR> RescueTime is automatic, and cross platform.

</comment></comment></comment></comment><comment><USER8> So a third party website get to track what site I visit and which app I use, when and for how long?

<comment><USER2> Out of curiosity, why is this a bad thing (if the service allows you to selectively delete data or nuke your whole dataset)? It's not logging keystrokes or doing screen captures... Just start-time and end-time of window/tab focus.

Compare this to a third party website where you store all of your conversations and many of your passwords (any hosted email or chat/IM), and the privacy implications of RescueTime don't seem that painful... Assuming it actually is something that you care about.

<comment><USER9> Yes, but how do RescueTime make their money?

I see no ads on the site, and the service seems to be free.

<comment><USER10> Corporate clients.

Future subscription services.

</comment></comment></comment></comment><comment><USER10> You can also see when you were moving from SF to Boston.</comment>


From Parallel to Concurrent [video] - <AUTHOR> https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/From-Parallel-to-Concurrent

<comment><USER2> I like the distinction provided in this hn comment [https://news.ycombinator.com/item?id=5711232#up_5714834](https://news.ycombinator.com/item?id=5711232#up_5714834)

<comment><USER3> Did you link to an upvote? What does that do?

<comment><USER2> More like reddit context. The first id is the parent comment/link id, the whole context to show. "#up_{id}" is the targeted comment.

</comment></comment></comment><comment><USER4> He did a similar talk in 2012 titled 'Concurrency is not Parallelism'

Link: [http://vimeo.com/49718712](http://vimeo.com/49718712)

</comment><comment><USER5> Very nice talk. I too sometimes get confused in what true concurrency means. Also, I think people are not looking at this because of the "msdn" :P

<comment><USER6> I never look at MSDN links because they always use video. Video is a medium for toddlers. I see the title and I'm like "oh, neat, new GC in CLR 4.5 . . . oh video, pass." Give me a transcript I can skim through.

<comment><USER4> > Video is a medium for toddlers

Bold ... but ridiculous.

</comment></comment></comment><comment><USER7> I like this definition: [https://news.ycombinator.com/item?id=5715394](https://news.ycombinator.com/item?id=5715394)

Concurrency is a property of the problem - no dependencies between tasks. Parallelism is a solution which uses that property.

This definition doesn't require (erroneous) distinctions between single and multicore systems. If I use a single core system to emulate a multicore system complete with emulated clock cycles and what not, are the emulated programs running concurrently or in parallel? From which point of view? The definition shouldn't dictate an implementation.

</comment><comment><USER8> Wow, CPU centuries, petabytes

</comment><comment><USER9> An actual direct video download link that you can just wget. Works without javascript, without 15 HTTP redirects and no registration. I am speechless.

<comment><USER10> Here's a direct video link to the High Quality version: [http://media.ch9.ms/ch9/33cf/90b47d47-96f9-4fc2-a9f6-933446b...](http://media.ch9.ms/ch9/33cf/90b47d47-96f9-4fc2-a9f6-933446be33cf/LangNext2014ParalleltoConcurrent_high.mp4)

Mind you, that is 1.7GB.

Smaller size for your phone: [http://media.ch9.ms/ch9/33cf/90b47d47-96f9-4fc2-a9f6-933446b...](http://media.ch9.ms/ch9/33cf/90b47d47-96f9-4fc2-a9f6-933446be33cf/LangNext2014ParalleltoConcurrent.mp4) (this one is 86MB)

Edit: I miss-read, I read it as a question and a statement that it didn't work and as a request for a direct video link that you can wget. I'll keep the links here for anyone that might want them.

<comment><USER11> I guess that's what was meant: no registration, no redirects, it just works. It surprised me too. Interesting talks.

<comment><USER10> I must have miss-read, or was the original edited? Reading it again now it's clear that the person means "Wow this works without hoping through 15 things. I'll leave my links for anyone else that might be interested.</comment></comment></comment></comment>


Why you need a degree to work at Bigco - <AUTHOR> http://weblog.raganwald.com/2005/07/why-you-need-degree-to-work-for-bigco.html <comment><USER2> There's two types of jobs. Those where what you do creates value for people within the company, and those where what you do creates value for people outside the company. You only need a degree for the former.

Rule of thumb: Ask someone what their greatest accomplishment is. If what they say is relative, i.e. "I am better than someone else at ___," then chances are they aren't very good at anything.

Avoid those whose self-worth comes from comparing themselves to others, be it through degrees or GPA or money, etc. They're losers and hanging out with them will keep you from accomplishing anything in life.

The funniest thing is that investment banks hire based on GPA even though there is zero correlation between GPA and alpha, and alpha is 100% of your job performance.

<comment><USER3> a) What's alpha? b) There are some things where relative accomplishments are OK, like sports. Saying you're an Olympic gold medalist means you're just better than everybody else, but it's still quite an accomplishment.

<comment><USER2> Each portfolio has an expected return based on risk. The higher the risk, the higher the return has to be to justify the risk. Alpha is the difference between the expected return based on the risk of the portfolio and the actual return. So positive alpha is good, negative alpha is bad. Traders are compensated based on their alpha.

My point about the relative accomplishment thing is just that you can go through your entire life trying to beat other people at stuff, but just because you can beat someone at something doesn't mean you're making the world a better place.

Being an Olympic athlete is certainly an accomplishment, although hopefully one goes on to do stuff that benefits others. And I say that as someone who pulled a 500 meter piece on the rowing machine that was faster than ltwt Olympic standard this afternoon.</comment></comment></comment>


Games for Windows and the DirectX SDK on GitHub - <AUTHOR> http://blogs.msdn.com/b/chuckw/archive/2015/04/18/github.aspx <comment><USER2> Original article is poorly titled. The DirectX Toolkit (a collection of DX utilities and wrappers) is on Github. That is nice. If the DirectX SDK was on Github, that would be major news.

<comment><USER3> Just came here to say the same thing. Looks like a bunch of wrappers and helpers and sample code, but not the actual SDK.

<comment><USER4> The article isn't poorly titled - the submission is. The _blog_ is titled "DirectX and Games for Windows".

</comment></comment></comment><comment><USER4> Bad submission naming aside, I am loving the direction Microsoft is taking lately.

I wonder why it took Ballmer getting out for a "developers developers developers" philosophy to actually be adopted.

<comment><USER5> A "Developer" today is very different to a developer 7 years ago [[http://en.wikiquote.org/wiki/Steve_Ballmer](http://en.wikiquote.org/wiki/Steve_Ballmer)].

I started as a software developer in the 90's. Back then, if you didn't have a degree or similar it was considered strange.

These days, if you have a degree (and nothing else - no github / stackoverflow / portfolio etc) then THAT is strange

<comment><USER6> Strange, I wasn't working that long ago, but most of what I've heard from people who have is that not having a degree was very common.

This might be a game industry vs rest of software engr thing though.

</comment></comment></comment><comment><USER7> The DirectX Toolkit has been on CodePlex for years, ever since they deprecated D3DX and all of the math, texture and model handling code therein when they switched to the DirectX SDK versions that was included in the Windows SDK (Windows 7, I believe? The last standalone DirectX SDK download is the July 2010 version).

</comment><comment><USER8> Are contributions accepted on GitHub?

<comment><USER9> Yes. Microsoft has given the message, constantly, that they would accept pull requests. The workflow is still being worked out but many have contributed to many of the .Net components they have opened sourced.

Right now I think it's a semi manual process to bring code in house and semi automatic when it gets pushed into GitHub. At least that's what one of the last Microsoft engineers described when they were on HN a few months ago.

</comment></comment><comment><USER10> Anything but XNA: [http://visualstudio.uservoice.com/forums/121579-visual- studi...](http://visualstudio.uservoice.com/forums/121579-visual- studio/suggestions/3725445-xna-5)

<comment><USER9> XNA was so amazing. At my university we used it to work with another university in Argentina to develop an XBox 360 game. It was amazing how quickly we could get things up and running.

I miss XNA so much.

<comment><USER11> XNA was what I used to build my first game ever. It was a magical experience to realise how quickly I could get things running. Nowadays when I go over game frameworks' documentation, I find myself thinking back to how simple xna was. Not to put down the other frameworks out there, but it felt like I'd never have been able to pick them up as easily as I did XNA.</comment></comment></comment>


Apple and Samsung fined for deliberately slowing down phones - <AUTHOR> https://www.theguardian.com/technology/2018/oct/24/apple-samsung-fined-for-slowing-down-phones?CMP=fb_gu <comment><USER2> Main discussion: [https://news.ycombinator.com/item?id=18292417](https://news.ycombinator.com/item?id=18292417)</comment>


The Birth of Legacy Software – How Change Aversion Feeds on Itself - <AUTHOR> https://software.rajivprab.com/2019/11/25/the-birth-of-legacy-software-how-change-aversion-feeds-on-itself/ <comment><USER2> I quit my last job because my team was in this room spiral. And management's solution to the problem? Work harder.

As far as I know, everyone else still works there. I bet some of them sleep at their desks trying to keep adding more knots to that awful legacy system.

And it didn't get that way WHILE I was there. That project had been around since 1998. They were so afraid of change that they were still using the C++98 compiler. So I didn't even leave that job with relevant (read modern) C++ knowledge.

Funny thing: The server architect at my current job was one of the founding members on that project. He had the same kind of view towards it. I feel like that project has been in a doom spiral from the beginning. So 21 years at this point.

It blows my mind that there are these legacy code sweat shops out there barely holding software together like this. What a miserable existence.

<comment><USER3> >And it didn't get that way WHILE I was there. That project had been around since 1998. They were so afraid of change that they were still using the C++98 compiler. So I didn't even leave that job with relevant (read modern) C++ knowledge.

This happened to me too!

I understand the reasons for that: it was highly specialized (scientific) software used in computer chip manufacturing. Most of the people on the team had a PhD in Engineering or Science, but few had extensive Computer Science training before joining the company.

The hardware industry is moving slowly, because you don't just upgrade a fab. Some of the clients were on RH5, so that was our build target.

Part of the codebase was in Fortran (and for good reasons too; this language is common in HPC/scientific scene).

All this resulted in a codebase that was part brilliant, part byzantine, poorly documented, and not even compiling with a modern C++ compiler (hence reluctance to start using C++11 or newer).

Thankfully, the automated test suite was holding it all together; but that was about it. As people left, they took systems knowledge with them that was written down nowhere, and nobody wanted to do a deep dive and document the still known parts.

Predictably, the priority has shifted to "quality" \- that is, fixing bugs instead of innovating on the core functionality.

That was not the only reasons why I left for better opportunities, but it was a big factor. It wasn't the legacy system that was scary - no more scary than a hairy prototype that gets the job done, really - it's that nobody was going to put in the effort and take the risk to start moving from a decades-old "prototype" stage.

I believe that things finally started moving when the people there realized that there is no way but forward; I hope they are using modern C++ now. But that train was set in motion after I left.

<comment><USER4> Isn't "modern C++" pretty much an oxymoron, and pretty much follows the above definition of "legacy software" ?

<comment><USER3> It's.. not?

The definition of "legacy software" in this discussion is: software that grew so many "temporary" fixes and workarounds instead of necessary architectural changes that it's in permanent maintenance mode, and entire parts of it are untouchable because nobody understands what they do due to the exponential increase in complexity stemming from the abundance of these hacks, exacerbated by system knowledge evaporating with engineer turnover.

That doesn't apply to either C++ language and compiler (rapidly evolving in the past decade), nor projects written in it, generally (that's not a property of the language).

On that note, we've integrated some Fortran code that was written in the 80s that I wouldn't call "legacy" under this definition: the algorithm was clear, and the implementation documented well enough that modifying it, if necessary, would not have been hard, and using it with our floor was very simple (it was one of the flavors of gradient descent algorithms that converged much better than several others).

<comment><USER4> > software that grew so many "temporary" fixes and workarounds instead of > necessary architectural changes that it's in permanent maintenance mode, and > entire parts of it are untouchable because nobody understands what they do > due to the exponential increase in complexity stemming from the abundance of > these hacks, exacerbated by system knowledge evaporating with engineer > turnover

Pretty much this, what else am I supposed to think when I read this : ? [https://stackoverflow.com/questions/17103925/how-well-is- uni...](https://stackoverflow.com/questions/17103925/how-well-is-unicode- supported-in-c11)

We aren't on the ARPANet anymore - I'm expecting even low-level programming languages to use native Unicode. The way how C equates "char" to both character and byte is fundamentally broken.

(This is also/more(?) an issue with Unicode - IMHO we should have increased byte size to something like 32 bits (during the transition to 64-bit words ?) to be able to fit one character per byte - the increased hardware cost for text storage would have been quickly compensated by the decrease in developer costs. But here we are.)

</comment></comment></comment></comment></comment><comment><USER5> I've seen plenty of projects blown up with massive, fearless refactors to do thing "the right way".

Careful with that axe, Eugene.

<comment><USER6> In my open office next door, people have been refactoring a cpp98 monolith into more interdependent components to be able to have a better test suite, better CI integration, better deployment story. That sounds about right.

Well, the issue is that they have done it a bit sneakily, they removed all the legacy code they haven't understood. So the code is much more elegant, it has been moved to cpp11 or 14, it ticks every good practice. There is only one slight issue : it does not work. It somewhat work, but is not reliable and fails regularly in unexpected ways. And they've started 5 years ago, and haven't been delivering any business value since then.

At the beginning, it was okay because they had some leeway but now they are blocking the release of new products, and our market share is in free fall.

Heads have started to roll.

To be fair, a few years down the line, their team will likely be more productive and efficient, but I am still not sure that the cost of the rewrite was justified. Still the article is very on point on the risk of not paying your technical debt.

<comment><USER7> > they removed all the legacy code they haven't understood.

This is exactly why rewrites or huge refactors typically fail. The new programmer sees code and doesn't understand why the code is there and thinks the last programmer was an idiot and deletes said code. Unknown to the new programmer is that code handles some weird edge case.

A rewrite should spend 80% of the time understanding the old code and 20% writing the new. But, that's no fun for most programmers who just want to code in the latest shiny so the new code ends up broken.

<comment><USER8> Which is why it is sometimes crucial to add comments to your code. I know certain code basically documents itself, but that depends on the person who reads it. In my eyes it is precisely edge cases that might or might not be known that profit from decent explainatory comments.

As a avid writer of comments I am convinced they also help myself, to form thoughts and remember them later, so at times I will write the comments _before_ writing an actual function.

If that is to bold, commenting while the thing is still in your head makes sense anyways — saves you time later and helps everybody else who will look at your code.

<comment><USER9> And please write proper commit messages!

A short summary, preferably including a hint at which subsystem is impacted by the change. Then explain in detail the context of the change: root cause of a bug and the gist of the solution, use case(s) behind a new feature and how it can be used, ...

Yes, often there's a bug/project tracking tool being used and the commit message contains a reference to the relevant entry there. But from experience I know these tools tend to change: old one gets decommissioned, data gets migrated, what was once the primary identifier is now a mere field or comment in the new system, access rights get messed up, ... Trying to understand the history then turns into an archeological expedition through various eras long gone... unless the commit messages are sufficiently self-containing.

<comment><USER4> The issue seems to be that that tracking tool does not have its data backed up in the version control system?

<comment><USER10> This seems like it could be mitigated with an integration that watches the issue tracker for updates and then commits those updates to a docs folder on the appropriate branch of the appropriate repo.

This would have saved quite a bit of headache at my last job actually.

<comment><USER4> Or just use a version control system with issue tracker support, like Fossil ?

<comment><USER10> Switching an existing project to a new VCS loses history or at minimum causes a new layer of "identifiers in the old system don't match the new one", no?

In general, I've found value in figuring out how to improve existing systems where feasible rather than trying to migrate to a new system, since the existing system probably has advantages the new one won't. At minimum, people are already familiar with the existing system.

<comment><USER4> Of course - but I'm not sure why you assumed that I would suggest that, instead of using a different VCS for a _new_ project.

<comment><USER10> Ah. I've spent a lot more time working on projects I inherited rather than ones where I made the initial technical decisions - if you're starting a new project, you should use the most capable tools available.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> I have noticed that database changes on a live system are the hardest / most risky to implement. Also they are most likely to get to the heart of the problem. I learned what the article is talking about through experience - avoiding the "harder" changes and piling fix on top of other fixes until things become a mess.

</comment><comment><USER12> As always, there is more than one valid perspective on this problem.

Given the very first example from TFA, the problem is solved (i.e. the new requirement is satisfied) by _only adding a few lines of code_. In fact, a massive refactoring was _not_ required. I would suggest that this is actually A Good Thing(tm) and may even be indicative a Good Design(tm). If every new requirement requires the system to be overhauled, you're definitely in a worse situation.

The lack of tests/testing is a wholly separate issue.

If the new requirement comes with new tests, and even better, tests for the old behavior _and_ the new behavior, all the better: you can refactor the system at a later time to make it cleaner and simpler and still meet the requirements, which is even better, since you have a fuller picture of what the actual requirements are.

Refactoring in the face of every new requirement smacks of poor initial design.

<comment><USER13> "Make the change easy, then make the easy change" is one of the tenets of refactoring. You do, in fact, refactor the code with every requirement.

I really, really hated YAGNI about ten years ago but have come around a bit. Our users are empirically insane. You cannot guess what an insane person will do next, and trying will only make _you_ insane, too.

I've gotten a lot of good mileage and a lot less stress by following the Rule of Three (architecting on the third example). I've learned to spot bullshitters versus sincere YAGNI folks (but many more if the former). The critical factor is identifying which decisions are reversible, not investing much energy in them, do everything you can to delay irreversible ones, and failing that make people pay attention to what they are choosing.

</comment></comment><comment><USER14> > Because no one in the team has a great understanding of the system

Isn't that the main issue? I understand to not want to do invasive changes when you're not familiar enough with a system, but the solution seems to be:

1\. get familiar with the system (doing small non-intrusive changes is a good way to start to become familiar with it)

2\. do more invasive refactoring

For sure don't start directly with the invasive changes, but at some point you need to get a good understanding of the system you are working on, or are responsible to maintain.

<comment><USER15> The problem with "having a great understanding of a system" is that it's hard to pin down, to define what that actually means. You can always use that as an excuse, if you are gatekeeping a poorly constructed system and resisting change.

If you require "full understanding of our system" for me to add some new functionality in a module, then chances are pretty good that your system has a bunch of problematic dependencies, no?

<comment><USER14> The article seems to be about "invasive and risky changes" (that's from the article). In this case I expect some level of gate keeping by people familiar with the system. If people doing the gate keeping aren't familiar with whatever they keep, then that's the first thing to work on.

> If you require "full understanding of our system"

I wrote "familiar enough", and "good understanding", not "full understanding". "enough" and "good" will of course depends on the context.

Considering this:

> then chances are pretty good that your system has a bunch of problematic > dependencies, no?

In practice you need to understand some level of the context in which your module exist, hopefully not all of it, though of course it would be better to be able to just focus on the module itself. By "system" I don't necessarily mean the whole, complete infrastructure, it can be the module.

My point was that if people are blocking changes because of lack of understanding of something, the solution would be to actually get some level of understanding.

Edit: also, I assume good faith from gate keepers.

</comment></comment></comment><comment><USER16> One of my biggest failures was while managing a team like this. In this organization I was a fairly well-liked leader and had both successful and failed projects and I was brought in to stabilize a core team that was having rampant attrition, had a two-year project that had practically stalled, and was feeling somewhat in a siege relationship with the rest of the company.

Interestingly, the whole situation _was_ almost exactly what he describes here and a full year later I had failed to correct it (and probably made it worse). Here's what I did so that others may learn from:

* Since the team had stalled on that project for two years, I pretty much sidelined it and attempted to get us in a habit of getting wins so that we'd feel comfortable with changes. Result: We just accelerated the muddying of the codebase. The team wasn't constantly upset anymore but the size of the improvements you could make was decreasing - a sign that you're in the doom spiral.

* Set aside time for us to perform the refactors, but allowed the team to identify the primary pain points and focus on them. Result: The muddied code-base was like an underwater cave, the silt was in established places. The attempted refactors were just more muddying. With two years of living with an on-call rotation, the team's primary focus was in trying to remove the things that caused them direct pain, not the underlying causes of them, because they felt that the time we had was insufficient to do anything meaningful.

* I championed automated testing, replicable builds, and atomic changes but failed to really make the argument since the net takeaway was "doing it that way would be great but it would be too slow". It didn't really take, but perhaps I should have had an enforced approach to that rather than an approach to make an argument that convinces. We got somewhere with the testing but it was a big effort. That cost me a little bit on the culture since it had to come top-down from me.

* I tried 'leading from the trenches' so to speak, but that was unsustainable. Things worked while I was there, working as an engineer along with everyone else, but then I had to sacrifice other crucial things that were necessary to retain the state.

In the end, things got somewhat better there in terms of attrition and big system failures, but the doom spiral was still there. So it was like adding x years to failure rather than putting us on the path to success. I'd like to think that now, with some distance, I have a much better picture of what to do.

To be honest, I really don't think that adding a slew of manual testers is really the solution. The iteration speed will plummet because now there is one more hinge to the arm controlling output.

The annoying bit about the whole thing? None of that is useful to me now. When you're trying to build a startup you wish you had problems like this because it means you are already successful. Ugh. Maybe some day it will be of use.

<comment><USER17> > I'd like to think that now, with some distance, I have a much better picture > of what to do.

OK, what, please share!! You told us what didn't work, in retrospect with distance, what would you have tried differently?

<comment><USER16> I think I would have trouble expressing the nuance in a HN comment given how much time I'm willing to spend on it.

</comment></comment></comment><comment><USER18> I think the best thing to do is use the existing system as a really, extremely detailed interactive requirements doc for a complete rewrite with modern practices and good documentation, then run both in production until you can switch the old one off

<comment><USER19> Complete rewrites seldom tend to work out well. Using a current version's behaviour as a "requirements doc" rather than the code or an actual up-to-date document probably misses out on a good deal of functionality that is rarely used but critical in some conditions. The thing about legacy software is that the software has encoded in it years or even decades of changes to functional and technical requirements, workarounds for edge cases that weren't foreseen, bug fixes, optimizations. Each of those can appear like a mess to the observer but it is foolish to think a new system will not run into similar issues. The idea of starting over to "do it right" is a fallacy because perfection does not exist. This is why the software industry is increasingly focused on processes that reap the benefits of quick turnaround and making change easier to deal with.

Believe me when I say the day you switch the old system off will never come in the vast majority of scenarios like this. The result is either wasted development time or, probably worse, you now have two systems to maintain and keep running.

<comment><USER20> That is basically an example of sunk cost fallacy. Yes, those bug fixes are important, but its easier to find them and fix them again in a tool with proper architechture. The idea is to run the original and the redesigned code parrallely and find the differences in behaviour and fix them.

We recently moved from a heap of matlab code which was started with a student project in 2001 to a huge tool used in the industry today to a new implementation in C++ and python. It has been a huge sucess with our customers.

<comment><USER21> It's not a sunk cost fallacy at all, sunk cost is throwing further money at something that already failed. If the code is being used, it obviously succeeded. The product works. Otherwise it wouldn't even be worth rewriting.

The reason why people warn against rewriting is that it's a risk, a gamble, and often a conceit by the programmers. Programmers will also often spectacularly underestimate how hard a full rewrite will actually be.

You're taking something that works, and attempting to recreate it. You can find lots of examples where rewrite projects went spectacularly wrong. A commonly cited example was the Netscape rewrite (which killed a hugely successful company).

Your gamble paid off, but it's almost always the worst decision you can make. There's even examples in this thread of when rewriting goes wrong.

<comment><USER20> Of course it depends on several factors. In our case, we were having a mess of spaghetti code, which crashed at important moments and there was no easy way to locate the issues. Sometimes, when your code required prayers and sacrifices to appease the gods and devils, then maybe its time for a rewrite. However, there are programmers who just want to rewrite because that think the old architechture is bad , when it is mostly fine.

<comment><USER22> But the forces which caused the current code to end up in such a sorry state will still be in force and cause the rewrite to end up in the same place.

If you have reason to think you can do better this time - e.g. the team have learned how to avoid unexplainable crashes - then you could apply this knowledge to fix the issues in the current code, which would a much less risk and less time.

<comment><USER20> In our scenario, The tool had no requirements. A student project did something which a team found useful and saved money. More students were given similar projects. Then an engineer comfortable with coding glued the code from all these students. This happened for 17+ years (converting several person months of work to few hours). The team lead for this team got promoted to a very high position in the firm and he hired a software team to redo everything with coherent code.

For us the first project acted as requirements analysis. In most cases bad software is mainly because of lack of proper requirements. In hindsight, its easier to make complex tool coherent.</comment></comment></comment></comment></comment></comment></comment>


Hublot magic gold - <AUTHOR> http://daringfireball.net/linked/2015/03/08/hublot-magic-gold

<comment><USER2> u could even price a licensed seiko at 10k, without fancy metallurgy...[http://www.calibre11.com/calibre-1887-update/](http://www.calibre11.com/calibre-1887-update/)

</comment><comment><USER2> there's no need to go bullshitting about advanced metallurgy..just go ahead and price it at whatever...[http://www.patek.com/](http://www.patek.com/)</comment>


HerStartup-the first global startup competition focused on diversity - <AUTHOR> https://herstartup.splashthat.com/ <comment><AUTHOR> SoGal Ventures, TechBase, Lean In China, and Kr Space, are proud to jointly host Ascendas- Singbridge Her Startup global competition to showcase the power of diversity. From the US and Asia, the top 15 startups will be selected to receive mentorship, funding and media opportunities, and access to world-class experts, investors, CEOs, and like-minded entrepreneurs!

At each round of competition, startups will be judged by an all-star panel of investors that are committed to investing in early-stage startups with diverse & strong founding teams.

</comment><comment><USER2> Totally stacked group of top VC judges including Arielle Zuckerberg (KPCB), Tim Draper, 500 Startups, Y Combinator, First Round Capital, Sherpa Ventures, Bain Capital and more!

<comment><USER3> Hey, they put a token male on the judging committee! Diversity!

<comment><USER4> Of course. Diversity across the board! We don't want a problem reversed :)

</comment></comment></comment><comment><USER4> So pumped for this opportunity!</comment>


Mega-Tunnels Dug by South American Megafauna (2017) - <AUTHOR> http://blogs.discovermagazine.com/crux/2017/03/28/paleoburrows-south-america/ <comment><USER3> >Dating the burrows also remains guesswork at best—animals don't dig holes after they go extinct. However, they had to have been dug at least 8,000 to 10,000 years ago, when South America's giant ground sloths and armadillos vanished.

Or, when humans came on the scene and 'vanished' them.

<comment><USER4> If only early man had worried about zoological diversity and the morality of eating giant sloth meat.

<comment><USER3> It probably had more to do with viewing them as a threat (which they were) than as food.

<comment><USER5> Whether they viewed them as a threat or food, modern humans (i.e. humans with fully developed hunting skills and weapons) who encountered megafauna that weren't afraid of them frequently slaughtered them to the point of extinction.

</comment></comment></comment></comment><comment><USER6> A more detailed description is included in this publication from the author credited for the first photo:

[http://www.ufrgs.br/paleotocas/Frank_et_al_2012.pdf](http://www.ufrgs.br/paleotocas/Frank_et_al_2012.pdf)

<comment><USER7> I'll take this opportunity to advertise one of my favourite science podcasts, Fronteiras da Ciência:

[http://www.ufrgs.br/frontdaciencia/](http://www.ufrgs.br/frontdaciencia/)

It is in portuguese, but one of the older episodes from season 5 is a very fun and informative interview with prof Heinrich about these burrows.

<comment><USER8> Thanks for the recommendation! Added to my player

</comment></comment></comment><comment><USER9> elon musk needs to hire some of these paleoburrows to finish his jobs - <USER2> seriously this is so interesting.

does anyone know if anyone has casually mapped these out? it would be scary to explore these, I imagine all types of animals / bears (maybe not as much in South america) use these caves as their homes.

</comment><comment><USER10> Funny how the article entirely ignores huge caves on Africa dug by elephants mining salt.

They ate the tailings.

Maybe there is only one such cave known, so somehow it doesn't count?

</comment><comment><USER11> I don't know why, but this feels a lot more scarey than seeing dinosaur footprints. Definitely makes me feel more like "prey".

</comment><comment><USER12> Homo sapiens is technically part of the megafauna, so the human miners that most probably dug this tunnels looking for valuable raw matherials would fit in this description, yes.

<comment><USER13> Do you for some reason not believe the experts in the article? Or have an explanation for the claw marks?

<comment><USER12> I'm not believing it because. 1) I'm not afraid of the experts. 2) They obviously are wrong in this case, as you can see if you take a look to the photos. 3) Yes, I have a better explanation for the marks. One that does not involve magical tetrapods digging in narrow spaces with unlimited degrees of rotation in the shoulder.

An expert is somebody that has done any possible mistake in a field. They commit mistakes all the time. This is just part of the journey and nothing to be ashamed of.

<comment><USER14> I sometimes wonder what is the evolutionary advantage of being as sure about ourselves and dismissive of others like a lot of us humans are.

<comment><USER15> Reminds me of the quote by Charles Bukowski "The problem with the world is that the intelligent people are full of doubts, while the stupid ones are full of confidence. "

This phenomenon seems to be explained by the Dunning–Kruger effect.

<comment><USER16> You seem rather confident with that assertion But I doubt you were serious!! _baddum-ts_

<comment><USER15> For anybody that is wondering what baddum-ts means, here it is:

[https://www.youtube.com/watch?v=VDAlblogUmY](https://www.youtube.com/watch?v=VDAlblogUmY)</comment></comment></comment></comment></comment></comment></comment>


How I built emojitracker - <AUTHOR> https://medium.com/p/179cfd8238ac

<comment><USER2> Great writeup of some fun unicode/font details. I've had to use the trick of limiting font files to specific unicode ranges while working on Amharic support for itypeamharic.com (Amharic/Ge'ez glyphs are also typically not present in any fonts on most devices)

</comment><comment><USER3> !!!</comment>


An introduction to 3D on the Mac, Part I: models & textures - <AUTHOR> http://arstechnica.com/apple/guides/2009/12/intro-to-3d-part-1.ars/1 <comment><USER2> <http://news.ycombinator.com/item?id=996025></comment>


Researchers have found seduction and deceit in the coded flashing of fireflies  - <AUTHOR> http://www.nytimes.com/2009/06/30/science/30firefly.html?hp=&pagewanted=all

<comment><USER2> On a related on, I once did a project where I simulated the synchronization of firefly flashes. In south east asia, 10000s of fireflies (of a particular species) synchronize their flashes and from a distance (at night) the colony on a tree looks like a big flashing bulb. It is quite awesome.

This is the link to my project: <http://paraschopra.com/projects/firefly/>

This is the link to downloadable Python code: <http://paraschopra.com/projects/firefly/firefly.zip>

</comment><comment><USER3> "Photuris kills other fireflies only to retrieve bad-tasting chemicals from their bodies, which it uses to protect itself from predators."

Sometimes big companies eat smaller ones to reuse the bitter patents they contain, too.</comment>


Ask HN: Project ideas on Distributed/Cloud Computing - <AUTHOR>

Hi, I am not sure whether it is appropriate to ask this kind of question on HN, but since I couldn't get any favorable response anywhere, I decided to throw this on to my fellow innovative hackers! :)
What should be the next big thing for distributed/cloud computing? How it will change our lives?
Open for discussion... <comment><USER2> Hey Praveen, this is out of context, but is there any way I can get in touch with you. I seem to match most of the things mentioned in your one-line bio on HN. Thanks

<comment><AUTHOR> twitter.com/praveenasara</comment></comment>


GNU Emacs Theme Generator (beta) - <AUTHOR> http://elpa.gnu.org/themes/

<comment><USER2> Interesting timing: just two days ago, I spent a good part of my afternoon making "emacs -nw" running inside GNU screen to look more or less exactly the way my standard windowed Emacs looks. That included mostly fiddling with terminal settings and finding colors that are supported by the terminal and resemble my original choices (and some other tweaking here and there).

Now clickong on my Emacs icon on the desktop will open a new gnome-terminal that runs an Emacs inside screen -- it looks pretty much the same as it did before, but I can access and take over my current session remotely from home. As a matter of fact, the shortcut will actually first check if there's a detached screen session that runs emacs and ask me in a small dialog window if I want to re-attach to that session or start a new window.

Makes me happy.

Sorry if that post is of no interest at all to anyone else on HN but me...

<comment><AUTHOR> I use a similar setup with urxvt and stumpwm. In stumpwm I have

        ;; Launch emacs
        (defcommand emacs () ()
           (run-or-raise
            "urxvt -title emacs -e screen -U -dRR -S emacs -c ~/.screenrc.emacs"
          '(:title "emacs" :instance "urxvt" :class "URxvt")))

which will launch emacs (or raise it if it was already launched).

Some of the thing you might want to consider when doing "emacs -nw"

      - Make sure your TERM is exported appropriatly.
        Otherwise you may end up with less colors (M-x list-colors-display).
        Screen fiddles with TERM and emacs may end up supporting less colors.

      - Copy/Paste between regular X apps and the emacs will not work.
        You would need to use something like "xsel". See here [1]

      - Some of the keys may not work as expected. This will be
        apparent especially when using orgmode. You may want to
        remap them appropriately

And also I suggest you use Emacs + Wanderlust setup for email (and put it in a screen session as well).

[1] [http://hugoheden.wordpress.com/2009/03/08/copypaste-with- ema...](http://hugoheden.wordpress.com/2009/03/08/copypaste-with-emacs-in- terminal/)

<comment><USER2> Yes, these points are exactly the ones you have to pay attention to when running -nw. For instance, I run

        gnome-terminal -x /bin/bash -c /usr/bin/screen

instead of

        gnome-terminal -x /usr/bin/screen

directly, or else I get less than 256 colors (although more than 8).

Copy/Paste works fine for me in so far as that is one of the few things I use the mouse for. (I guess, in a lot of case you use the mouse anyway to select the text you'd like to copy.)

Remapping some keys is indeed necessary. In particular, GNU screen's standard escape key sequence is C-a, which in Emacs a lot of people probably prefer to be bound to (move-beginning-of-line). But also within Emacs some keys may need to be bound using input-decode-map.

As for your launcher, one thing I did differently is that my start script does not automatically re-attach to a detached screen session, but will show me a dialog window where I can select the one thing or the other. The reason for this is that I often keep a few Emacsen running in parallel for a long time, each of which is dedicated to a different aspect of my work. If I detach one session it is not always the case that I want to continue there the next time I open a new Emacs. Also, if more than one Emacs is detached I'd like to be able to say which one I want to re-attach to.

I looked at wanderlust a few years ago when I was looking for an IMAP- compatible email client for Emacs but in the end I wasn't convinced by it. Can't remember, though, what I didn't like about it, perhaps I should give it another chance.

<comment><AUTHOR> Probably you are using x selection buffer for copy/paste. But if you want to pick up stuff from X "clipboard" buffer, you would need xsel or something like that.

Wanderlust is quite usable now. I use it everyday(I have my gmail and exchange server(imap) accounts managed in it). You should give it another try sometime.

</comment></comment></comment></comment><comment><USER3> I don't see any colors other than black and white in the theme on Chrome 10 on Snow Leopard, but I do see bold, underline, italics. I see the colors on Firefox 4 beta on Snow Leopard.

</comment><comment><USER4> I would rather have an Emacs that offers fewer choices but looks good out of the box.

Example: the software supplied by Apple with a Mac does not have any themes except for the choice between Blue (colorful) and Graphite (subdued) in the Appearance system preference pane.

OTOH, I regularly have to wait for the software supplied by Apple and I almost never wait for Emacs.

<comment><USER5> By waiting, do you mean wait for the release, or wait because the software is busy doing something?

<comment><USER4> Wait because the software is busy. E.g. OS X's spinning beach ball.

(Emacs is single-threaded, but so is a Unix shell.)

</comment></comment></comment><comment><USER6> I recommend using senny's theme-roller.el [1] to automatically apply your color theme to any new faces. Brings some sanity to the number of colors that need to be defined.

[1] <https://github.com/senny/theme-roller.el>

</comment><comment><USER7> Here's a couple more:

<http://alexpogosyan.com/color-theme-creator/>

<http://inspiration.sweyla.com/code/>

<comment><USER8> Sweyla's also generates Vim and TextMate themes.

</comment></comment><comment><USER9> There's a similar tool at <http://color-theme-select.heroku.com> it's also in beta, allowing to generate custom themes and select from a large collection of them. I've contacted the author to see if he's fixing the "generate emacs- lisp" feature.

Would be nice people could use that tool to create themes for emacs 24, and send them to emacs-devel.

</comment><comment><USER10> Here's an awesome theme: [http://blog.nozav.org/post/2010/07/12/Updated- tangotango-ema...](http://blog.nozav.org/post/2010/07/12/Updated-tangotango- emacs-color-theme)

</comment><comment><USER11> Is there any cc-mode generator like this? I spent a couple days trying to tweak mine a while back, but try as I might, my comments still want to align all the way left.

</comment><comment><USER12> I have a half-written xterm color scheme generator lying around. Has this also been already made, or is it worth finishing?

</comment><comment><USER13> I would like to see something like this for NetBeans.

</comment><comment><USER14> Use -nw and get your terminal's theme for free!

<comment><USER15> What about a 256-color theme for 256-color terminals (or 88-color for 88-color terminals for that matter).</comment></comment>


Cringely: Google planning to build a 700-MHz and WiFi mesh network? Watchout ISPs and telcos! - <AUTHOR> http://www.pbs.org/cringely/pulpit/2007/pulpit_20070914_002928.html

<comment><USER2> Google isn't going to get the spectrum! Kevin Martin (FCC Chairman) crafted the auction rules in such a way that it isn't attractive for Google or any other third party to bid, plus the incumbents have so much power in D.C. already.

Sure, they would like to build-out in the 700MHz band, but it is very unlikely to happen.

<comment><USER3> My guess is that Google never wanted to build a wireless network; instead they want a telco (who already has towers) to be tricked/forced to build a network that suits Google.</comment></comment>


Teach Yourself Programming in 10 Years. - <AUTHOR> http://www.norvig.com/21-days.html <comment><USER2> An earlier submission: <http://news.ycombinator.com/item?id=43243>

Mentioned quite regularly: <http://searchyc.com/teach+yourself+norvig+ten>

<comment><USER3> This is offtopic, but: why / how do you find so many duplicate articles? When I saw that this was posted, I was immediately pretty sure you'd leave a comment linking to past posts. Are you doing this manually, or do you have a script (that, e.g., checks the 'new' page and searches for the title and URL on searchyc?)

<comment><USER2> Why and how are different. "Why" is because I prefer to see discussions linked together rather than spread. In this case there is some previous discussion (although not a lot) and anyone coming across this and finding it interesting might find the previous discussion worth reading also. They could search for it themselves, but it's easy for me to do, and one person's work (mine) saving lots of people work seems a good trade-off.

"How" is different. I just tend to remember stuff like this easily, so I know if something's duplicated. A quick search will usually find it, and that often turns up other stuff that I find interesting in its own right. I haven't scripted this, I just remember stuff.

That also feeds back into the "Why." I've found many things of value (to me) on HN because an article that was vaguely interesting prompted a search for an earlier duplicate, and that search turned up related, more interesting material. Having found any duplicates I then put in the comment to help save other people some time because, well, why not?

However, I'm pretty much considering stopping. Although I'm not really bothered about karma, the recent instance of PG linking the ability to vote to one's average karma has made me re-evaluate what I'm doing. Although it's only approximate, clearly "karma" embodies an indication of the behavior PG wants. Flagging duplicates like this drags down my average karma because it rarely gets up-voted and occasionally gets down-voted. That suggests that, in some sense, PG doesn't want me to do it, even if I think it saves people time and helps to cross-connect related discussions.

If you'd like to discuss this more, feel free to email me.

<comment><USER4> To allay your concerns, I almost always upvote links to previous submissions on HN. I make them, and find such links valuable, so I upvote them when someone else makes them.

P.S. I find the best way to find previous HN threads that I remember is a site-restricted Google search with a few keywords, e.g.,

[http://www.google.com/search?q=site%3Anews.ycombinator.com+p...](http://www.google.com/search?q=site%3Anews.ycombinator.com+previously+submitted)

<comment><USER5> _"... I find the best way to find previous HN threads that I remember is a site-restricted Google search ..."_

Way better ~ <http://searchyc.com/previously+submitted?sort=by_date>

<comment> s-phi-nl I find both Google and searchyc useful. When one doesn't find what I'm looking for, the other usually does.

</comment></comment></comment></comment></comment></comment><comment><USER6> >> _Why is everyone in such a rush?_

Because everybody has different goals. Although many programmers seek to become masters of their craft, I suspect many more look at programming as a tool to be used in furthering some other pursuit. Those who see it as a tool are understandably better-served by "Learn C Before Dinner!" books than they are by a 10-year program.

This reality may be frustrating to experienced coders. It results in legions of sloppy programmers producing piss-poor code. It is, however, reality. And I'm not sure it's such a bad thing. Most of the people I interact with don't know a thing about computers -- I'm pleasantly surprised when I talk to someone who's had a run-in with some programming, no matter how brief.

<comment><USER7> If you are not interested in learning how to do it properly, then hire someone who is. Failing that, do not attempt to do it in C.

</comment></comment><comment><USER8> I agree with this being reposted occasionally, as its lessons are fresh to newcomers.

Several of the other comments reference useful books on the topics, particularly on algorithms. One book that has a lot of important lessons about becoming a good programmer is _Coders at Work_.

One of the interviews is with Peter Norvig who tells about a bloggers failed attempt at solving sudoku. Peter's solution used a very novel approach to the problem that is non-obvious, and I would put this in the category of what you can learn from studying algorithms. They are not all about reducing computational complexity. Perhaps the other extreme example is an epic stack overflow answer that repeats many times that you can't use regular expressions to properly parse html. And this keeps coming up, it seems.

And I found the lessons in _Coders at Work_ somewhat startling. I recommend it to new programmers and old programmers alike. It's not about the IDE, it's not about the language, it's not about the testing.

</comment><comment><USER9> I realised last night that I've actually been programming for almost 10 years now.

And you know; Im still going to be learning something in another 10 years. I think that's a really good thing.

</comment><comment><USER10> or you can take a algorithm class and become one within 2 years, as somebody once stated ;)

<comment><USER11> I don't think it works quite like that.

When I got my first programming job, straight out of high school, I finished tasks in 2 days that took the other programmers there 4 months. I figured that if I was that much faster than them, I ought to be able to become a world- class programmer in just a couple years (or more accurately, I thought I could become a world-class physicist in my 4 years of college and then a world-class programmer in the 2 years afterwards).

So I resolved to take all the shortcuts I could. I'd read all the classic books in the field and learn from those with more experience than me. I'd take internships with experienced, accomplished programmers and pick their brains for everything I could. I'd take on volunteer coding tasks so I could get some experience building things on my own. I'd cherry-pick all the tough courses at college so I got the best part of a CS degree without having to sit through stuff I already knew.

I did all that. I've read all the classic CS books - GoF patterns, Mythical Man Month, Extreme Programming stuff, Pragmatic Programmer, Knuth, SICP, TAPL, Dragon Book, On Lisp, etc. I've worked with programmers that wrote large chunks of curses, Rogue, vi, Jini, JavaSpaces, HotSpot, Gallery, Stratus, Equalogic, DEC compilers, Python, Google, and a bunch of other projects they don't brag about. I wrote Amherst's course-evaluation system, and rewrote the software for a 100k-user site, and wrote one of the front-page hits for [haskell tutorial]. I have that CS degree, and aced the algorithms class of which you speak, and took compiler design and OS and computer graphics too.

It's been 9.5 years since that first programming job, and it still feels like I have a really long way to go before I'm actually a world-class programmer.

The part I didn't realize, in my youthful arrogance, was that I was comparing myself to the wrong people. When Norvig tells you how to become a programmer in 10 years, he's assuming you're _already_ taking all the shortcuts you can. It still takes 10 years. Most of the people you'll meet straight out of high school, or in most colleges, or in random companies, will _never_ become programmers in the sense that Norvig's talking about. Eventually they'll give up trying, and start grumbling on Reddit about how the software industry is mostly boring cubicle farms where they push around Enterprise JavaBeans and never use the algorithms that they learned in college.

<comment><USER12> Which topics in programming interest you now?

<comment><USER11> Professionally, I've been doing mostly web UIs, bunch of JavaScript. Personally - I've always had a fondness for programming language design, theory, and implementation and (naturally) am working on my own compiler. I've also picked up a bit of an interest in machine learning and distributed processing, mostly because of where I work now.

</comment></comment></comment></comment><comment><USER13> Is 10 years when the site comes up? 503 Unavailable.</comment>


Forget the Stereotype of the Introverted Tech Specialist - <AUTHOR> https://www.inc.com/wanda-thibodeaux/forget-stereotype-of-introverted-tech-specialist-youll-now-need-this-key-skill-to-succeed.html <comment><USER2> I agree in so far, that the "ability to listen with a purpose" is invaluable. I have a couple of (senior) co-workers, which are technically skilled, but simply won't listen or empathize very well. They react to given trigger words in a knee-jerk way, then reeling off some kind of (technically) story. Often enough the information they give you is buried deep in noise, is not there, or worse, turns out to be wrong. Poor communication between people strikes me as one the biggest bottleneck in our company. For me it is frustrating to work with, and I really need to pay attention to not joining their mannerisms.</comment>


Python's Instance, Class, and Static Methods Demystified - <AUTHOR> https://realpython.com/blog/python/instance-class-and-static-methods-demystified#.WNu2T4fbvNs.hackernews <comment><USER2> Dan is an outstanding teacher, good team effort with @RealPython to Demystify OOP concepts in Python</comment>


Ask HN: My Birthday's Tomorrow, I Need Book Recommendations - <AUTHOR>

So, tomorrow I turn 20. My mom has been hounding me for gift ideas. I never ask for anything for my birthday, but for some reason she's particularly adamant this year.
I am a voracious reader, so I figured I'd just give her a list of books I'm interested in reading, so that she can go through 'em and buy whichever ones she pleases.
That being said, I'm turning to the smart and savvy users of HN for book recommendations. Lately, I've been on a non-fiction kick. I've been particularly interested in the biographies of the founders of major tech start-ups, or the history of how they got started. Broadly, however, I'm interested in stories about tech entrepreneurs (disruptive entrepreneurs, contrarian entrepreneurs) or the tech empires they've made.
I've also decided to start learning how to code in PHP. So, any good books on PHP are also recommended.
However, your recommendations don't have to be confined to those interests. If you read a book and were particularly floored by it, put it in your list! <comment><USER3> Programming PHP - O'Rielly its not the cutting edge book (2006), but it is by PHP founders and a good ground-start to get a feel for the language and what the commands can do. I learned quite a bit more on how many of the commands work than what other books covered. You will still need a good OOP book,

for OOP I've liked PHP Objects, Patterns and Practice by Matt Zandstra

Some Classic Computing Non-Fiction (circa 80s and earlier): * Soul of a New Machine - Tracy Kidder * Fire in the Valley - Paul Freiberger and Michael Swaine * Hackers - Steve Levy * Commodore: A Company on the Edge - <USER2> Bagnall (get the second edition) * The Psychology of Computer Programming by Gerald M. Weinberg - for being written in 1971 (with an updated edition in 98) it is very interesting and still relevant. * Coders at Work: Reflections on the Craft of Programming by Peter Seibel - interviews of many luminary programmers, how they got stated and what they have done.

<comment><USER4> The book 'Crypto' by Levy is also good.

</comment></comment><comment><USER5> For techie non-fiction stuff, I liked both of Kevin Mitnick's books, probably The Art of Intrusion more. They feature (probably slightly fictionalized) stories of creative thinkers who exploited systems, for evil or otherwise. it was very interesting to see how these creative people used their intelligence constructively (or destructively, I suppose).

on a completely non-tech book note, I'm currently reading Extremely Loud and Incredibly Close by Jonathan Safran Foer (author of Everything Is Illuminated) and I'm absolutely loving it! it's beautifully written, filled with humor and tragedy all at once.

just my two cents

</comment><comment><USER6> Just finished reading Tracy Kidder's "Soul of a New Machine" and I highly recommend it. A little older, but still a hell of a good read and really fed the part of my mind that digs tech histories and start-up narratives.

</comment><comment><USER7> fooled by randomness</comment>