Ask YC: Feedback on my Mac Leopard App - <AUTHOR>

About 4 months ago, I quit my full time coding job and started freelancing while working on this task management app:
http://gearsquare.com/actiongear/
I wanted to make the app stay in the background, only showing itself when the user hits a hotkey combination like Quicksilver.  This works really well when I'm "in the zone", because ActionGear just pops up over TextMate/XCode/Firefox when I need it and then goes away when I'm done.
It's in early beta right now (and free) because I believe in the "release early/release often route".
I'd really appreciate any feedback you guys have on the application, website, screencast, or even the business.
And if you guys have any questions for me, feel free to ask here =].
Thanks! - Hugh <comment><USER2> You have a lot of competition, but hey, that's not always a bad thing!

The website looks very neat and clear, but you need to do a better job of conveying why ActionGear is better than the other options out there, from Things to OmniFocus to other GTD implementations. At the moment it's not clear.

<comment><AUTHOR> Thanks swombat, I do have a lot of competition =].

I think ActionGear stands out by being a background app, like Quicksilver, instead of being a full blown GTD implementation. I'll try to emphasize the difference more.

<comment><USER3> I was going to say roughly the same thing as swombat... you need to distinguish more. In particular, you seem focused on the fact that your app stays in the background. OmniFocus does the same thing. I hit

</comment></comment></comment><comment><USER4> I think its really nice, thanks. I'll continue to test it and compare it with Check Off, which I use now.

A few suggestions: 1\. Really crank out the keyboard shortcuts. Things like Delete on a group would be good. 2\. Small thing--when you create a Group, go ahead and make it editable so that I can just start typing its name. 3\. Support colored Groups, tasks.

<comment><AUTHOR> Thanks for the suggestions!

I wanted to let you know that I'm working on (1) more keyboard shortcuts and (2) making items/groups editable after adding them. Both features should be in the 1.0 release.

In fact, if you're a TextMate user, there's this "Go to File" shortcut that I enjoy so much I wanted to put in ActionGear. The idea is: user hits hotkey, window pops up, user types in group name partially, ActionGear takes you to that group.

I'm a big fan of keyboard shortcuts too =]. I even dedicated a page to them:

<http://gearsquare.com/actiongear/hotkeys/>

<comment><USER4> Cmd-T is the greatest keyboard shortcut of all time in TextMate.

What is the Inbox for in your app?

<comment><AUTHOR> It's one place to collect all of your thoughts so you can organize it later. It's from David Allen's GTD method: <http://en.wikipedia.org/wiki/Getting_Things_Done>

</comment></comment></comment></comment><comment><USER5> I like it. I'm continually trying out apps for this purpose but inevitably end up using an editor under Terminal.

(Pretend each hyphen starts a new bullet point)

Problems: \- The cold start is a bit weak on first run. What should I do next? A little tutorial would be good. \- I wish I could create an item without mousing to edit the description. Is this possible?

Ideas: \- Growl integration: Randomly pop up items that need to be done, sortof as a teaser. Perhaps bias towards older or stale items? \- Dependancies?

Wild idea: \- add a server component, via a simple REST api, with a simple PHP version. Let me make a specific project folder be shared with other people. The website can show a simple list of todos/completions ala twitter. (anything you can X, I can social X. sorry.)

<comment><AUTHOR> Joshu, thanks for your feedback!

I was concerned about the cold start as well, I'll think of a better way to do a first run.

You can add a new item using cmd-N and then hit 'tab' to edit it. When you're done, hit 'enter' or 'tab' again to edit tags. I'll be changing it so right after adding a new item, it'll go straight to editing it.

I haven't thought of Growl integration, but honestly it sounds like a great idea to show users what to do next in their list.

<comment><USER5> The Growl stuff is something I've wanted forever. Remind me of what I'm supposed to be doing!

Seriously, though, the more I think of it, a server component would be great.

</comment></comment></comment><comment> a-priori It looks good. I currently use Things (<http://www.culturedcode.com/things/>) for a similar purpose, but good global keyboard shortcuts might make me switch.

<comment><AUTHOR> Thanks a-priori, I used to be a Things user myself - I think it's a great app =].

</comment></comment><comment><AUTHOR> Link:

<http://gearsquare.com/actiongear/>

<http://gearsquare.com/media/vid/actiongear.mp4> <\-- this is just a 73 sec video demo I put together in iMovie, it's a 6.4MB download

</comment><comment><USER6> It seems odd to me that this isn't coupled with a network host of some kind. Organizing my tasks is rarely the hard part. It's remembering them from anywhere that proves tricky.

Perhaps instead of a network host, something better integrated with an iPhone would be good..?

<comment><AUTHOR> I completely agree with you, I'm definitely going to make an iPhone version that syncs with the desktop app. It's very useful to have your tasks on you all the time, so you won't forget them.

</comment></comment><comment><USER7> At first sight it's nice, simple and needs a bit of polishing. It's a bit annoying to not being able to delete groups.

I know that you want the app to appear when you need it, but I personally would like it to stay as a normal app after I unhide it and cmd+tab on it.

<comment><AUTHOR> Thanks, I'm hoping to give it more of a polish for the 1.0 release. It's still missing some features that I think are necessary.

To delete a group, select it, and click on the "gear" icon on the bottom left. There's a menu item to "Delete Group".

Did you expect the delete key to delete a group? Or did you right click on a group looking for a menu to delete? I should implement those features, I want the UI to be clear for everyone.

If more people request it, I _might_ make an option in the preferences to have it act like a normal app so you can cmd+tab to it.

<comment><USER7> I was expecting right click menu.

Thank you for taking into consideration my option, it's not a requirement for me. I'll play more with your app see how it feels.

</comment></comment></comment><comment><USER8> I'm having a problem..

I assiagned a hot key. Then I didn't restart the computer yet.

Later, I was in the safari search bar, and whenever I hit 'a' it would toggle the program. I had to close the program to be able to hit 'a' again.

<comment><AUTHOR> Hi izak,

This seems to be a bug that some other people are having also. I'm working on a fix for it and it'll be out for the next version.

</comment></comment><comment><USER9> Hugh, your app looks promising. I will try it out for a week and see how it fits into my workflow.

One side question: what is the terminal icon in your menubar? I must have that app (whatever it is).

<comment><AUTHOR> Heh, it's called Visor, from the makers of Quicksilver:

<http://docs.blacktree.com/visor/visor>

You can hack Terminal.app so it becomes a background app too, like Quicksilver/ActionGear:

[http://www.macosxhints.com/article.php?story=200107011915182...](http://www.macosxhints.com/article.php?story=20010701191518268&query=nsuielement)

I also made it a "login item" to start on system start up. System prefs -> Accounts -> Login Items.

So now, I always have a command line prompt handy =P.

</comment></comment><comment><USER10> Looks really cool :) I'm not in front of my mac right now, but looks promising, will definitely try out.

One thing about the website though, please please resize your screenshots into thumbnails!

<comment><AUTHOR> Thanks bdotdub, I resized the screenshots so they should look better on Windows IE/Firefox now.

</comment></comment><comment><USER11> If you click "Show ActionGear" and then bring another window to the foreground, the menu says "Hide ActionGear", but clicking the item brings the window to the foreground.

<comment><AUTHOR> Thanks! I'll get that fixed for the next version.

</comment></comment><comment><USER12> Somehow your #pp h#s t#ken over my keybo#rd.

Every time I try #nd type #n "#" (# being pronounced "eh"), your #pp comes to the foreground. It is very #nnoying.

<comment><USER13> Yeh sme for me too...shme becuse t first glnce it looks gret!

Intel Mcbook Pro, Leoprd 10.5.4

Btw, no ide why I didn't close the pp before typing this messge, its very hrd to remember not to press letter...

<comment><AUTHOR> Sorry! I hope it wasn't a huge inconvenience for you, but thanks for the bug report. I'll get on this one immediately...

It looks like for you the app wasn't substituting '#' in place of 'a', or were you deleting the '#' characters?

<comment><USER12> That was my bad. I typed in # characters in place of 'a''s.

</comment></comment></comment></comment><comment><USER14> Looks pretty slick. I really like the minimal, "lurking in the shadows" sort of approach. Would integration with iCal be something feasible/desired?

<comment><AUTHOR> Thanks jobeirne, I was hoping that people like the minimal approach.

I use iCal too, so I think integration with iCal would be a really useful. I'm putting it on the back burner as a 1.1 or 1.2 feature.

</comment></comment><comment><USER15> Website Feedback :)

1\. Alter typography, add a decent line height (maybe 1.6em?) 2\. Background image is yeck. You'd be better off with a lighter grey than the current image. 3\. Headings would look better without small-caps

Other than that, seams good! Still testing the app atm.

</comment><comment><USER16> Seeing as its a Mac app, you might not care, but the site doesn't look very good on Windows XP + IE7 (I'm using someone else's computer). The font(s) look kind of 9-pin dot matrix, and the screen shots are not very clear (it's hard to see what the text says in them).

<comment><AUTHOR> Ah thanks, I'll probably fix the site in IE7 tomorrow. I googled about the blurry screenshots, turns out PNG looks bad in IE7. I'll try converting the images to JPEG..

<comment><USER17> it looks bad for me in firefox on unix as well. make properly scaled thumbnails of your images, don't rely on the browser to scale them down.

</comment></comment></comment><comment><USER18> I reviewed your app and also many of the other apps that people mentioned in the comments.

[http://blog.blakeperdue.com/2008/09/15/app-reviews-task- mana...](http://blog.blakeperdue.com/2008/09/15/app-reviews-task-management/)

</comment><comment><USER18> i would say add a publish a group feature would be nice. i currently do this with remember the milk so my boss can keep tabs on what i'm doing.

<comment><AUTHOR> Hi blakeperdue,

This sounds like a pretty useful feature. I'll put it on the back burner for now, but what I'm thinking of is a simple HTML page generated and published to a server for other people to view.</comment></comment>


Symas Lightning Memory-Mapped Database (LMDB) - <AUTHOR> http://symas.com/mdb/ <comment><USER2> If you're on the CMU campus tomorrow you can learn all about it. [http://db.cs.cmu.edu/events/databaseology-2015-howard-chu- lm...](http://db.cs.cmu.edu/events/databaseology-2015-howard-chu-lmdb/)

<comment><AUTHOR> I would love to, but I live on the other side of the "pond" :)</comment></comment>


Housing is a human right: How Finland is eradicating homelessness - <AUTHOR> https://www.cbc.ca/radio/thesundayedition/the-sunday-edition-for-january-26-2020-1.5429251/housing-is-a-human-right-how-finland-is-eradicating-homelessness-1.5437402 <comment><USER2> Rights used to mean human capabilities that government should not obstruct, because the government was not the source of said capability, and therefore had no authority to control the capability.

Now rights seems to mean things the government is responsible for giving to the citizen, which turns the formulation on its head to imply that the government is the source of human rights.

Seems to be a dangerous trend, however humanitarian its portrayal may be.

<comment><USER3> Private property in land is pretty much the definition of a government-created privilege, so the government does plenty of "obstructing" when it comes to people's right to shelter. The governments which originally granted those monopoly rights on land many centuries ago had no inherent authority to do so-- although they may have had authority to _lease_ the use of that land for some limited time, under fair and non-discriminatory rules. (This is how land is managed e.g. in Hong Kong and Singapore, and the system works quite well.)

<comment><USER4> > Private property in land is pretty much the definition of a government- > created privilege

Though I welcome citations to prove the matter one way or the other, I suspect that the 18th-century Lockean concept of natural rights which informed the founders of the USA, saw ownership of private property as a right and not a government-created privilege. That is, if one claimed land on what was seen as terra nullius, or if a person's family had owned the lank back to time immemorial, then the land was rightfully theirs regardless of government recognition or not. State recognition in the form of deeds would only have represented something useful for dispute resolution, and did not imply that the state was granting any rights.

<comment><USER3> Locke _specifically_ cautioned that ownership in land could only be justified so long as there was _" enough, and as good, left in common for others"_. Clearly, this is no longer the case today; indeed, the monetary value of that monopoly right precisely shows the extent to which the use of land has become scarce.

<comment><USER2> An artificial scarcity created by the fact the government controls most of the land...

We should be demanding the government cede control of the land, instead of pleading for the government to give us a smidgen of what it does not rightfully possess!

<comment><USER5> And private investors wouldn't immediately buy up as much land as possible as they did with single family homes during the housing crisis?

Everyone needs a place to live and land is a finite resource. Plus, foreign investors love to use real estate to park money. Government doesn't seem to be the problem here. People will pay what they have to to avoid being homeless. At the same time, developers will build what's most profitable: luxury housing. The market won't fix the problem, so we the people, by way of government, should.

<comment><USER2> Well, don't let foreign investors buy up all our land. Government should cede control of the land, and let its citizens stake out plots.

<comment><USER6> And then we've just kicked the can down to the road a generation or so. Whatever problems you think more privately owned land will solve today, will just be waiting for us tomorrow.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> Housing is the perfect example to illustrate the flaws of how democracy is put into practice in many (but not all) Western societies. There are at least two big issues:

1\. Those who have housing are less transient and as a result have (increasing) influence over local politics in aggregate.

2\. Said local politicians then take their constituents will upstream, resulting in the (re)enforcement of policies that benefit the existing property owners. Mainly this manifests itself in anti-growth policies. Not just in housing, but really any sort of change that can be seen as disruptive to the existing population even if it's good generally. This can mean housing, public transportation, roads, and more!

The solution to these issues is to nationalize rules regarding housing, but because of (2) it's unlikely to ever happen.

I wonder what will need to happen before the minority (not speaking about race or ethnicity, but in terms of voter participation) finally are empowered, given many times the minority voting population actually makes up the majority of eligible voters.

I guarantee you that if 100% voter participation was enforced and macro votes could override micro votes (i.e. a state vote could overturn a local rule) most issues would go away.

<comment><USER8> Landownership being the foundation of American politics is it's original sin.

<comment><USER9> I think even landownership is not a problem, the problem is that people think about housing as an investment and not a tool(eg car).

<comment><USER10> Given the need for extensive labour and planning to construct most dwellings, how do you propose doing a built property from retaining value?

</comment></comment></comment></comment><comment><USER11> What a total disaster the threads on articles about homelessness turn into. No wonder most of the developed world has a serious homeless problem when people are so completely lacking in both empathy and insight.

Straw men about "rights" and "coercion" abound, while there's very little acknowledgement of the scale of human suffering that can be solved by just _providing housing_ instead of half-heartedly funding shelters, halfway houses, ERs, etc.; the usual leaky uncoordinated sieve of a "safety net" that exists in most countries.

How about instead a Y Combinator applicant that takes the idea in the article of cost-benefit analysis in terms of public service usage and scales it up across cities, states, and nations?

"Keeping people homeless, instead of providing homes for them, is always more expensive for the society. In Finland we have some scientific evaluations of the cost of this program. When a homeless person gets a permanent home, even with support, the cost savings for the society are at least 15,000 Euros per one person per one year. And the cost savings come from different use of different services.

In this study, they looked at the services that homeless people used when they were without a home. They calculated every possible thing: emergency healthcare, police, justice system, etc. They then compared that cost to when people get proper housing. And this was the result. I'm quite sure this kind of cost analysis can also be found for Canada."

<comment><USER12> Providing housing is not the solution.

A previous partner of mine worked as a social worker for an organization that did "housing first". She would house homeless individuals in apartments, advocated on their behalf to the landlord, get them some basic furniture, and helped them get financial assistance to afford rent and food. That part was easy.

The biggest problem she faced was that people would leave their homes. She would come by a few days after housing them and they weren't around. She'd call them up only to discover they'd taken the train over to the next town and spent the night on the streets there. One lady complained that she thought the apartment was too small and preferred to be outdoors. She housed a family of 4 who were sleeping in their car, only to find that they crossed the border a few days later because the father thought that there were better opportunities there.

Homelessness is not about "not having a home". It is a mindset and lifestyle that people develop over many years.

The best solution is to try to stop the incoming generation from developing this lifestyle - get 'em while they're young. Keep troubled kids in school at all costs. Double down on drug and addiction education. Police the shit out of poor neighborhoods. And then provide some health and wellness support for those who choose this lifestyle. Because that's all you can do.

<comment><USER13> This conflicts with the very article posted in this thread though, backed by empirical data vs your anecdotes.

<comment><USER12> Perhaps. The experiences came to me from someone new to the profession, who was probably given all the troublesome cases so the established employees could have an easy ride with the ones who were interested in changing their lives around.

</comment></comment></comment></comment><comment><USER14> Especially with the increase of automation and the reduction of the number of jobs, I think it's a must.

It's 2020, it just doesn't make sense to still have people living on the streets, like animals.

As most people are not financially independent, homelessness could literally happen to any of us. All it takes is a rough period in your live, you get laid off, a bad divorce, someone in your family passes away that used to contribute to the expenses and now you can't pay the rent, a war veteran that could not adapt to society.

A car breaks down and you can't go to your minimal pay job anymore, you get laid off and can't pay the rent.

To anyone who thinks otherwise and thinks homeless people just don't want to work, I recommend the channel Invisible People - [https://www.youtube.com/user/invisiblepeopletv](https://www.youtube.com/user/invisiblepeopletv)

<comment><USER10> How do you stop someone going outside and sitting down on the streets?

<comment><USER15> Well some places criminalize being homeless.

<comment><USER10> So if someone came and plopped themselves and the entrance to your house on the pavement, you'd want there to be no recourse to ask them to go away.

Vagrancy, loitering etc have always had cause to be enforceable offenses for 200 years for a reason

</comment></comment></comment></comment><comment><USER16> Good show, Finland.

I have some fairly extensive experience with the types of folks that end up homeless.

I'm extremely grateful that it's never happened to me; but I'm quite aware that it's always a a possibility.

</comment><comment><USER17> Does this apply to all residents or just Finnish citizens?

It would only work if all residents are covered, right?

In New Zealand citizens and residents can get govt support for accomodation, yet there are crazy numbers of homeless people everywhere!

<comment><USER18> I can't find a quote but as far as I know it's true across the EU- permanent residents get the same rights as citizens (except for voting, working for some government positions etc)

</comment></comment><comment><USER19> Interestingly, there's been many news articles in the Finnish newspapers recently about Finnish homeless people living in the forest.

</comment><comment><USER20> >... completely end by 2027

Having a very tiny homeless population is a sign of healthy society. What are gonna do with some people that are non-violent and don't want to live in the building X? Are you gonna lock them up?

<comment><USER11> I'm sure you mean well by posting this comment, especially given the "very tiny" qualification. However, this is a quite common straw man argument that homeless people are choosing to be so, rather than finding it the least bad of their terrible options.

The problem of involuntary homelessness and lack of access to adequate facilities, health care, mental care, transitional assistance, etc. is so large that to get hung up on some mythical dystopia where people are forced into homes is worse than a distraction; it actively aids those who for whatever reason do believe that for currently homeless people it's a choice or the result of their own bad decisions or whatever.

I seriously doubt the metrics used by the Finnish government would encompass such "wanderers by choice" that you're imagining. They are instead talking about people coming into shelters for assistance and _helping_ them find stable housing that they can rely on.

</comment></comment><comment><USER21> Private housing is both a basic human need, and the largest asset class. Private speculation in private property is massive in scandinavian countries. It is hard to see speculation going away without unpopular state regulations on the housing market.

For first time buyers of housing in norway, family background has become the most important factor.

</comment><comment><USER10> By having a tiny population, and by being generally rather unattractive for most immigrants?

</comment><comment><USER22> So what does the government do if people are unwilling to build housing? Force them to at the point of a gun?

<comment><USER11> Why is that the choice? The government can just _build housing_ by the normal means, or fund other entities to do so, such as the housing nonprofit Y-Foundation in the article.

</comment></comment><comment><USER21> Speculation in private housing, is also a human right. Private housing has become the biggest asset class in the western world.

<comment><USER23> Private housing is cultural, whereas shelter is a necessity. Shelter is sometimes vital for surviving. I would be surprised to be proven that speculation in private housing is necessary for survival.

<comment><USER24> A tongue isn't neccessary to survival and yet we would call someone who went out ripping people's tongues human rights violators among other things. Not being neccessary is not sufficient to for something to not be a human rights violation.

I wouldn't call speculation in itself a human right but it emerges from others like right to trade and ownership. Taxing unoccupied homes would be a way to address it perfectly respectful of human rights - fixed costs of infastructure upkeep need to be paid after all.

<comment><USER25> What the

</comment></comment></comment></comment><comment><USER26> These Scandinavian success stories are great, but it bothers me that they are always held up as some progressive ideal. As if it's even a choice for other nations.

They have immense advantages, and unique benefits. Norway in particular being the frontrunner.

Yet in my news feeds it seems middle European progressive parties (Belgium/France/Germany/Spain) always point to these countries and say "see, look what happens if we take care of our people". Ignoring not only the money needed for such an initiative, but the huge demographic differences from immigration in the last 20-40 years.

I welcome opposing thought here, because it's a matter that genuinely confuses me, and I'm open to being on the wrong side here.

<comment><USER27> What is Finland's advantage? Norway I get, it's oil. But Finland is just a well managed country without significant natural resources. Most of its industry is not related to extraction of resources.

<comment><USER28> Considering their mentioning of immigration, I fear (Edit: I was right, see replies) they see the the nordics' advantage as being almost entirely white.

That would not just be boorish, but also wrong: both Sweden and Morway (the two I just checked) have around 17% foreign-born residents, with more than half of those from outside the EU.

<comment><USER26> Race has nothing to do with it.

Rather the question is, does importing radically different cultures, and low skilled labor bear a cost on the welfare state.

This is a cost that is probably acceptable, and necessary, but we should keep an eye on the practical limits.

Norway has far more money to spend, and Finland has far lower foreign cultural migration, so they don't make fair examples.</comment></comment></comment></comment>


Ask HN: Should all devops know how to fizzbuzz - <AUTHOR> I believe fizzbuzz (https://en.wikipedia.org/wiki/Fizz_buzz#Programming_interviews) should be dead simple to anyone who claims proficiency in coding or "scripting." Should it be a deal-breaker if a devops candidate struggles?<p>By devops I'm talking about someone who does things like automation (chef or puppet), cloud administration (AWS), configuring software (db, webserver), and troubleshooting some networking issues. <comment><USER2> Would you feel comfortable hiring somebody for automation who cannot provision a fleet of servers where every third server has a Cassandra node and every fifth server has a Redis instance?

<comment><AUTHOR> that's a essentially the same question, but also a ridiculous scenario that would never occur. what's your point

<comment><USER3> He applied fizzbuzz to a work scenario... maybe it's not very important in practice?

</comment></comment></comment><comment><USER4> "Everyone" knows of it, so if you don't you are not part of "everyone". That would not look good.

<comment><AUTHOR> well all the people I've asked in real life have never heard it and struggled.

</comment></comment><comment><USER3> Your link calls fizzbuzz "a word game for children"... so probably not a useful criteria by itself.

<comment><AUTHOR> scroll down to here: [https://en.wikipedia.org/wiki/Fizz_buzz#Programming_intervie...](https://en.wikipedia.org/wiki/Fizz_buzz#Programming_interviews)

edit: I fixed the OP

<comment><USER3> Lots of questions are used to probe for math and problem solving ability... but why would it be effective if it was the only question?

</comment></comment></comment><comment><USER5> Yes.</comment>


Ask HN: What's the best web programming language? - <AUTHOR>

I want to start developing web pages but i'm not really sure where to start. I like the idea of PHP, but i've been reading it's a spaghetti language and there are better places to start. Can anyone give me advice? Where to start, where to go? Mostly focused on web development <comment><USER2> there is no best language. they're all tools in a toolbox. you can smash a nail in with a screwdriver, but its easier to use a hammer.

the question is, what do you want to do? are you new to web development and want to learn a language? do you have experience with other languages? etc..

<comment><USER3> _there is no best language. they're all tools in a toolbox._

That's intellectual laziness masquerading as broad-mindedness. Obviously Ruby is going to be better for most web apps than Fortran.

<comment><USER2> thats being a bit hypercritical and decontexualizing, don't you think? obviously he doesn't want to use cobol on punch cards, either, but do i actually have to spell that out? fine, i'll do it just for you:

 _there is no best language_ for web development _. the_ subset of languages being used for modern web development are _all tools in a toolbox._

</comment></comment></comment><comment><USER4> Have a look at: <http://philip.greenspun.com/seia/>

<comment><AUTHOR> Thanks! Read the intro and reviews on amazon. Looks decent, I'll continue reading.

</comment></comment><comment><USER5> Get to grips with HTML and CSS before you start worrying about anything else.</comment>


Chinese university uses AI to check class attendance rates - <AUTHOR> https://www.scmp.com/tech/policy/article/3002107/chinese-university-uses-ai-check-class-attendance-rates-and-find <comment><USER2> This is a good method for testing their facial recognition algorithms before deploying them everywhere.</comment>


Lisp Interpreter in Tandy TRS-80/100 Basic - <AUTHOR> https://m.facebook.com/#!/story.php?story_fbid=10157953582457370&id=780707369 <comment><USER2> Hi... I'm the guy who ported this, which was actually not too difficult, as the original gentleman, to whom all honour belongs, left good hints. Most "issues" where really just IFs without THENs. There were only two errors I saw in Ira Goldking's source, a wrong line number and a THRN instead of THEN. This is a link for those not on Facebook: [https://pastebin.com/2Mih71eF](https://pastebin.com/2Mih71eF)

<comment><USER3> Any chance of putting it on github, perhaps even starting with the original?

<comment><USER2> Chaire o eschaton!

As per your request:

[https://github.com/KedalionDaimon/LispForTandy](https://github.com/KedalionDaimon/LispForTandy)

</comment></comment></comment><comment><USER4> From the author:

>This one is just for fun. When I first learned Lisp in 1981, I did so by reading Winston and Horn's book and writing my own Lisp interpreter. The interpreter was written in Basic on the only system I had access to at the time: a TRS-80 Model I. This interpreter eventually ended up as part of a series of three articles on Lisp that I wrote for 80 Micro, a TRS-80 hobbyist magazine. The first part of the series, which contains the source code for the interpreter itself, is included here. Note that the listing has all optional spaces removed so that I could fit both the interpreter and 1100 (!) cons cells into 16K (!!) of memory

[http://mypage.iu.edu/~rdbeer/](http://mypage.iu.edu/~rdbeer/)

<comment><USER5> Oh hah, I know this guy from Case Western CS dept. Around 1990 he was writing some Lisp on a TI Explorer lisp machine to simulate cockroach neurons for an AI project.

</comment></comment><comment><USER6> If we're willing to extend the discussion to microcomputer Lisps targeting machine language, I'll repost an old comment [https://news.ycombinator.com/item?id=20019592](https://news.ycombinator.com/item?id=20019592) :

> There were various Z80 and MOS 6502 microcomputer Lisp implementations > written back in the '80s, some commercially released at the time, some > readily accessible nowadays. [https://www.wisdomandwonder.com/link/3787/how- > small-can-a-sc...](https://www.wisdomandwonder.com/link/3787/how-small-can- > a-sc..). > [https://groups.google.com/forum/#!topic/comp.lang.scheme/Z_2...](https://groups.google.com/forum/#!topic/comp.lang.scheme/Z_2..).

> (There's one that I'm horribly, horribly overdue to get back to the authors > about archiving on the Internet, actually. Anyone who's based in North > America and happens to have the hardware and the expertise to recover data > from both 5.25" and 8" floppies in some CP/M format?)

<comment><USER7> You might check out the ClassicCmp ([http://www.classiccmp.org/](http://www.classiccmp.org/)) or Vintage Computer Foundation ([http://vcfed.org/wp/](http://vcfed.org/wp/)) mailing lists. There are folks on there with extensive expertise and equipment for recovering and archiving data.

<comment><USER6> Thanks!

</comment></comment></comment><comment><USER8> Funny, my current job involves a lot of coding in BASIC (BASIS and ProvideX commercial flavors) and I'm trying to wedge in some Racket where I can. I got my start typing in listings from Rainbow magazine at age 10. (I never thought I'd be writing BASIC for a living though, life took a turn at 35)

<comment><USER9> > BASIS and ProvideX commercial flavors

Looks like these are both "business" BASIC variants. Wiki has some information about ProvideX, nothing about BASIS (either the company or the BASIC product). What's the point of coding in these sorts of languages at the dawn of the 2020s? Do you still have a lot of legacy code around that can't be forward- ported for some reason? Do you have non-technical folks surveying the code, or even contributing to it?

<comment><USER10> Business BASIC was all the rage in the 1970s, especially for small to medium- sized businesses, and for good reason. It provided business functions like forms and database access in a manner that was much, much easier to work with than the dominant business language of the time, COBOL. It also had sophisticated programming constructs. For example, while it didn't have structured exception handling like Java, it did have Go-style mandatory error handling; every command that performed I/O had to be passed, as required parameters, the line numbers of where to branch under various error conditions.

Both BASIS and ProvideX are based on Java and provide rather thorough JVM integration. The languages themselves also haven't remained stagnant; they have approximate feature parity with Visual Basic. Both are derived from the MAI Basic Four dialect that was popular in the 1970s.

And yes, some large complicated business software, including the MAS 90 and MAS 200 accounting systems, was built using Basic Four. Porting such a complicated code base would be cost-prohibitive compared to porting the Basic Four dialect of Business BASIC to new environments and just running it as is -- so Business BASIC is COBOL-like in that regard also.

<comment><USER8> > "Both BASIS and ProvideX are based on Java and provide rather thorough JVM > integration."

I'm aware of this evolution. However, the software at my company was not maintained to keep pace with it. Instead it was endlessly customized within the constraints of the original interpreter. At this point, updating the software to use newer variants even by the same companies would take roughly the same effort as rewriting it in Python, for far less reward.

</comment></comment></comment></comment><comment><USER11> Facebook has to be the least convenient way this could be hosted. Here's a mirror: [https://pastebin.com/raw/Yq5khyQL](https://pastebin.com/raw/Yq5khyQL)

<comment><USER12> _Facebook has to be the least convenient way this could be hosted_

Compared to the rest of the internet, yes. But for the Model 100 people, this is actually the cream of the crop.

Sadly, information in the Model 100 community is notoriously difficult to get to. Well, not fully "difficult." More like "obnoxious."

Most of the good stuff is on old web sites with many broken links, little documentation, and abysmal navigation. I think the main repository is actually the web site of a guy who died years ago and is kept online, but unmaintained and suffering from severe bitrot, by people about to go the same way.

For interactive discussion, the primary source is a mailing list where people ask the same questions over and over and nobody trims their replies, so you might get a message reply that just says "yep" followed by 150 lines of nested quotes. In digest form, it's simply unusable.

So, amazingly, a Facebook post is a thoroughly modern and convenient way for Model 100 enthusiasts to pass information around, compared to all of the other methods they employ.

<comment><USER9> > Most of the good stuff is on old web sites with many broken links, little > documentation, and abysmal navigation. I think the main repository is > actually the web site of a guy who died years ago and is kept online, but > unmaintained and suffering from severe bitrot, by people about to go the > same way.

As long as the site(s) have been grabbed by Internet Archive, I'm not sure that this has to be an issue. (I've noticed that the archive.org 'Wayback machine' will even archive some downloads, albeit it's not something that should be counted on.)

<comment><USER7> I don't want to speak ill of them because they're doing an amazing job, but the Internet Archive doesn't have everything (especially old, long gone and/or obscure sites), isn't always complete, and often doesn't have things that back in the day that were on FTP sites. Sometimes you get lucky, but I've not had great luck there.

If you're maintaining some repository of information others find useful, please-please-please have a plan to pass it on to a successor caretaker and a notation in your will about your wishes.

<comment><USER9> I'm well aware of that, sadly. But often, part of "maintaining" a valuable repository of information (especially one that has reached stability and is not seeing ongoing updates) is uploading it to the Archive yourself. The Internet Archive has "trouble" dealing with information in the gigabytes and terabytes (which is why donations to them are valuable) but retrocomputing stuff is not like that.

<comment><USER12> _part of "maintaining" a valuable repository of information... is uploading it to the Archive yourself_

The problem is that we're talking about information that started suffering from bitrot before the Internet Archive became a big thing. Or even before the Internet Archive existed. Heck 99.999% of it existed before the internet.

Sure, it would have been great if on May 13, 1996 someone would have uploaded all of the information that there has ever been about the TRS-80 Model 100 to IA, but that didn't happen.

So often in places like HN the answer to flaws is "Well, you should have...," as if that solves the problem, or makes it go away. But it doesn't. It just makes the person writing that look like a jerk who isn't interested in solving problems, but in pointing out the failings of others.

</comment></comment></comment></comment></comment></comment><comment><USER6> You know what _else_ was written in BASIC? The original Smalltalk interpreter [https://youtu.be/pACoq7r6KVI?t=1189](https://youtu.be/pACoq7r6KVI?t=1189) . ("I'm not ashamed, I got it going quickly" \- Dan Ingalls.) Obviously this was just a scratch implementation of what became Smalltalk-72, rather than a Smalltalk-80.

</comment><comment><USER9> Blogpost reposting content from 80 Micro Magazine (published sometime in 1982). I assume that the original issue is somewhere in the archive.org collection.

<comment><USER11> Good thinking. Looks like it might be this: [https://archive.org/details/80-microcomputing- magazine-1983-...](https://archive.org/details/80-microcomputing- magazine-1983-03/page/n175)

<comment><USER9> From looking at the contents listing of this issue (400+ pages!) this looks like it _might_ be Part 1 of a LISP tutorial that perhaps was extended in subsequent issues? I wonder if archive.org has got it all.

<comment><USER4> Yes, in the next issues

Part 2 [https://archive.org/details/80-microcomputing- magazine-1983-...](https://archive.org/details/80-microcomputing- magazine-1983-04/page/n253)

Part 3 [https://archive.org/details/80-microcomputing- magazine-1983-...](https://archive.org/details/80-microcomputing- magazine-1983-05/page/n305)

</comment></comment></comment></comment><comment><USER13> I'd wondered if there was a Color Computer variant and indeed there was/is: From Hot Coco, April 1984 [http://www.colorcomputerarchive.com/coco/Documents/Magazines...](http://www.colorcomputerarchive.com/coco/Documents/Magazines/Hot%20CoCo%20\(Searchable%20image\)/)

Now to test it out.

</comment><comment><USER2> Hi everybody,

I put it also here as per eschaton's request:

[https://github.com/KedalionDaimon/LispForTandy](https://github.com/KedalionDaimon/LispForTandy)

</comment><comment><USER14> There was a TRS-80 with a 68000...

Also, I know that ELIZA was available for TRS-DOS (which I think ran on the Z80) and wasn't that based on Lisp?

</comment><comment><USER15> Broken link, can't access without an account.

<comment><USER16> I can't access it even with an account.</comment></comment>


BitTorrent seed farmer found guilty, faces 10 years in jail - <AUTHOR> http://arstechnica.com/news.ars/post/20080629-jury-convicts-elitetorrents-admin-with-mpaa-help.html <comment><USER2> "McCausland also ended up serving five months in prison before going on probation, part of which involved an odd request from his probation officer to _start using Windows (instead of Linux)_ so that monitoring software could be installed on the machine."

This is dehumanizing treatment!

<comment><USER3> Worse than the prison term, that's for sure!

Well, no, but I'll bet that software eats up half his CPU and bandwidth. I'd like to see him hold down a job with that kind of restriction.

</comment></comment><comment><USER4> I hope he doesn't get raped.

On that note, how high is the risk of getting raped in prison? I've seen the data on <http://www.spr.org/>.

Are there findings that refute or confirm that data?

</comment><comment><USER5> American people scare me, they are crazy.

<comment><USER6> Please tell me you don't judge an entire country with a population of > 300 million based on the actions of a few that get media attention? Cause that thought scares me more then anything the MPAA can try and do.

<comment><USER5> this is a little of topic, but its not just that. I know a lot of stuff about American history, i also know people that have lived in different parts of the country. I could write an entire essay about stuff that i don't find normal in American culture, but you can do that with almost any country. There are stuff in America thats just weird.(i mean weird not from my point of view, i mean weird in any point of view, i think the "most powerful nation in the world" thing has gone to your heads, power corrupts.)

</comment></comment></comment><comment><USER7> Someone should have plead guilty... It will be interesting to see what happens to the Pirate Bay guys.

<comment><USER8> The Pirate bay will never be defeated.

<comment><USER6> What makes them infallible? They're human. Maybe one of them gets sick and has to stop working. Or maybe they get bored. Or Sweden/EU's laws change.

Maybe the companies that make up the RIAA or MPAA will change policies and offer a better alternative. Perhaps a better alternative will come around? Who knows what the future holds. "never" is a strong word to use. Especially concerning technology.

<comment><USER8> The hydra is infallible. If the Pirate Bay were to collapse (may they reign forever), a dozen new sites would spring up to replace it.</comment></comment></comment></comment>


Ethreal, free fake SMTP email catching service - <AUTHOR> https://ethereal.email/faq <comment><USER2> caching instead of catching, perhaps?</comment>


War over Being Nice - <AUTHOR> https://josephg.com/blog/war-over-being-nice/ <comment><USER2> I like this article, but fail to understand why the author equivocates culture A with sexism. There is nothing in the article to qualify that, false in my opinion, equivocation.</comment>


JavaScript in the Internet of Things: JerryScript and the Fitbit Ionic - <AUTHOR> https://js.foundation/blog/2018/02/07/javascript-internet-things-jerryscript-fitbit-ionic <comment><USER2> In case you didn't know, this is the result of Fitbit's talent acquisition of Pebble. I'm still pissed we lost a <$100 programmable smart watch.

<comment><USER3> With a week of battery life and a daylight visible screen

<comment><USER4> Did you guys see this Pebble + Apple Watch clone from Xiaomi? If only they opened it up. 30+ day battery life with a similar display as the Pebble:

[https://us.amazfit.com/shop/bip?variant=336750](https://us.amazfit.com/shop/bip?variant=336750)

<comment><USER3> Very interesting! Closed platform is a bummer, but that hardware is exactly my wishlist for a smartwatch.

<comment><USER5> A closed platform is just a hurdle to overcome - but yeah, someone has to do it. If they make it a little more consumer friendly this could be very impactful.

</comment></comment></comment></comment></comment><comment><USER6> > Fitbit Ionic marks an exciting evolution in the smart device market by both > incorporating open source technologies, like JerryScript into the device > itself, and allowing developers to build on top of the software and > contribute apps.

I realize this is marketing copy, but what exactly is evolutionary about using open source software and providing an SDK for a smartwatch? How does this differ from Apple's offerings? Sounds like the evolutionary part is that you can use JavaScript.

<comment><USER7> It's still incredibly limited compared to Samsung's smartwatch platform.

For the past few years, the Gear watches and fitness wearables have been running full Linux. If you enable Wi-Fi debugging, you can actually ssh in to the smartwatch and poke around the file system.

The UI story is a mess though. There's EFL, a C-based GUI layer of somewhat legendary status in Linux circles (it's derived from the Enlightenment window manager). It's plenty fast, as a smartwatch should be, but kind of a bastard to program for.

Alternatively you can write HTML apps, but they run like sedated dogs on the smartwatch.

Last I heard, Samsung was trying to add React Native into the mix. I'm not very convinced that adding in yet another runtime will fix the fundamental problem.

<comment><USER8> But isn't the crappy widget library a general problem with Linux? What would one use if not EFL?

<comment><USER7> Well, there's Qt, but I guess it doesn't align with the politics because it's owned and controlled by a private corporation.

I agree there aren't any good options. Given the choices on Linux, EFL actually makes sense for a smartwatch.

</comment></comment></comment></comment><comment><USER9> I'd imagine that the Ionic JavaScript toolkit company are not too thrilled about the name.

<comment><USER10> Haven't really noticed it, to be honest. There's a lot more web developers than wearable devs right now, at any rate.</comment></comment>


Xamarin raises $12M to help you make better apps faster - <AUTHOR> http://blog.xamarin.com/2012/07/24/xamarin-raises-12m-to-help-you-make-better-apps-faster/

<comment><USER2> I'm looking forward to what they come up with next. There's a tremendous opportunity here to streamline the mobile dev process and things like Mono.Dialog can be a _huge_ time saver.

I figured they were finished after they left Novell but they've pulled off one of the most impressive resurrections in recent tech history.

</comment><comment><USER3> I've been using Mono for Android for a few months now and have been very impressed with the quality of the product and support, and the rate at which features are being added (modulo Xamarin's small size). I spent my own money on a pro licence and haven't been disappointed.

</comment><comment><USER4> It seems that this post is heavily flagged. 60 points in 2 hours, was top post in front page then suddenly vanished from front page. Very odd.

<comment><USER3> Very. Any flaggers want to comment on why?

</comment></comment><comment><USER5> You claim cross-platform apps, but then you have two development packages. Mono for iOS and Mono for Android. If I develop on Mono for iOS can I take the exact same code and plop it down on the Android version?

<comment><USER6> No, but your backend code is the same.

I'm using MonoTouch and Mono for Android for some game development right now. My per-platform projects are five to six classes apiece (all but one pushed into my IoC container by the last one), and everything else is shared. Obviously, for a non-game application, you'll have more, but they'll be mostly UI-based.

</comment></comment><comment><USER7> >Xamarin enables millions of experienced C# programmers to become mobile developers very quickly. _But most of them don't know about us! We're going to fix that._

I hope step 1 for "fixing that" is a name change. Seriously, developers talk just as much off-line as online about their tools and Xamarin has serious off- line confusion issues.

</comment><comment><USER8> I'd really appreciate better pricing (e.g. risk free, pay after you succeed, etc..), at least for Android platform.

<comment><USER9> Our free trial never expires and lets you try the platform in the emulator/simulator for as long as you like.

As for the paid product, we issue a no-questions-asked refund to anyone who requests it within some reasonable amount of time (30 days usually). Even with this, our refund rate is less than 1%.

<comment><USER8> What I meant is actually a different business model, which can co-exist with the current one.

E.g.: "Pay only after you earn your first 100$" but along with "NO WARRANTY" and "no support" and maybe "without IDE, only cmd line tools and SDK" but that would be an extreme - still, better than nothing.

I think this will _tremendously_ boost your user base.

All in all, you will cover a new target market with retaining the existing market.

Anyway, thanks for the great product!

EDIT: the market you actually will loose (in "no support" users) - are the users who didn't succeed. Not sure if you can track the numbers, that would help to determine if this business model will be positive for you.

</comment></comment></comment><comment><USER10> "Every person on the planet will eventually be a mobile user."

Great quote!</comment>


Diesel-Scandal: Volkswagen Leaders Charged - <AUTHOR> https://www.bloomberg.com/news/articles/2019-09-24/vw-chairman-ceo-charged-with-market-manipulation-in-germany <comment><AUTHOR> > Germany's embattled car industry suffered a one-two blow after prosecutors > charged Volkswagen AG's two top executives with market manipulation in the > four-year-old diesel scandal […]</comment>


Show HN: A crowd-sourced company library (Slack bot) - <AUTHOR> https://www.booklyapp.com/ <comment><AUTHOR> Creator here. I built Bookly to solve my own problem. I work as an engineer in a start-up with some really driven people with a passion for reading and self- improvement and entrepreneurship. We were constantly recommending and lending books to each other but there was no easy way to keep track of who owned which book, which books we loaned to others and which books were available to borrow. I was originally just going to create a Slack channel but thought it would get messy and hard to find things, and so Bookly was born.

The app is built in NodeJS and took me 4 months to build, the last month was mainly getting the website, assets and copy ready. It uses Firestore as a DB which is now my goto solution for getting backend up and running quickly (shortcomings just far outweigh everything else because of familiarity and speed).

I originally used just cloud functions for the Slack API web hook calls but they absolutely SUCK for Slack bots - Do. Not. Use. Them! Slack has a 3 second response timeout for web hooks and on a cold start I found it constantly timing out. Great if you have enough users to keep them always running but infuriating when traffic is small. They're also painful to debug. Running Node locally with Slack web hooks calling through Ngrok was such a pleasure to work with. I probably wasted 3 weeks trying to make cloud functions work.

Most popular books added so far have been programming books. Not really surprised, I think this bot will appeal to a certain self-improvement personality type. Who knows though, I may be pleasantly surprised with more fiction books added in the future.

Happy to answer any questions on building Slack bots. Only my first bot but they have really good resources and tools on their site, and the API has come a long way in the past couple of years. Also welcome feedback, this is what I consider the bare minimum product to make it usable so still a lot to add.</comment>


Show HN : Re-Designed company website, Need feedback - <AUTHOR> http://www.emmyweb.com/

<comment><USER2> If compared to the best websites out there, I can say it's average. It looks like a crude remnant of Metro style app with Google style white space added. The white top space seems bland. You can add a bluish hue to it. Also, a white background to text makes it look selected and not so pretty. Not sure if I particularly like the font either. You can also change the color schemes. These were just my negative points, there are positives as well, but those don't matter much. Good luck.</comment>


How porting to TypeScript solved our API woes - <AUTHOR> https://www.executeprogram.com/blog/porting-to-typescript-solved-our-api-woes <comment><USER3> Note that Stripe is working on a type checker for Ruby: [https://sorbet.org/](https://sorbet.org/)

I second the sentiment though. I wouldn't choose to use plain JavaScript over TypeScript for any significant project.

You might ask why I wouldn't just use a more fully typed language like Java. My main response is that I love having the flexibility to choose how strict the types should be. Sometimes, typing something out fully is not worth the trouble. Having escape hatches lets me make that choice. While I enjoy using types to turn runtime bugs into compile time errors as much as possible, it's not the right thing to do 100% of the time.

<comment><USER4> Having partial type safety is like having a no peeing section in the pool.

<comment><USER5> That's not true. There are plenty of cases where certain pieces of software is cordoned off and/or non-critical that would not affect the rest of your stack if they fail.

<comment><USER6> If you properly do validation at runtime this can be true, but it's a manual process that's not verified by Typescript.

</comment></comment></comment></comment><comment><USER7> > That means that when one side of the API changes, the other side won't even > compile until it's updated to match.

Coupling your front end and back end in this way can give you false confidence in making API changes. If you control both sides of the API on a web app that doesn't have too many users yet, then this can be very productive, but consider this situation:

You've made a breaking API change on the back end, and thanks to your type system, you make the corresponding front end changes as well, which is great. You deploy your code, and the back end changes take effect immediately. Visitors who were in the middle of a session are still running the old front end code, and their requests start failing. Cached copies of the front end start failing too.

You can engineer around this but it's better to have a system that doesn't make introducing breaking API changes too easy. It should be painful.

<comment><USER8> And if you do a gradual rollout, newer clients can connect to older backends! And if clients can talk to each other, there can be THREE versions involved. Also: rollbacks.

I'm curious if anyone has a system for managing this that they love. I've pretty much only seen painful ways.

<comment><USER9> At <dayjob> we use flow types and graphql, so like OP our frontend will fail to compile if we make a breaking change. To assist with the backward- compatible-during-deploy issue, we additionally have a teensy bit of tooling that comments on our PRs to indicate dangerous API changes.

It's not perfect (I've ignored the comments before, thinking I knew better... I didn't), but it seems to help.

It wouldn't be difficult to make it more sophisticated, and then completely block PRs it knew weren't backward compatible, but we haven't seen a strong need to do that yet.

</comment></comment></comment><comment><USER10> If you control both ends of an API, there's no reason not to use Thrift or equivalent (gRPC) rather than untyped JS. Even if you don't believe in typing in general, an API boundary is exactly where it's most important to make sure both sides agree on what the interface is.

<comment><USER11> Calling gRPC endpoints from the browser isn't something that works very well today.

<comment><USER10> Calling thrift endpoints from the browser works great. I had heard that gRPC was a thrift equivalent but haven't used it myself.

</comment></comment></comment><comment><USER12> Do I read the chart correctly and their whole Codebase (minus dependencies) is less the 15k lines of code? Porting 6.5k likes of ruby in 2 weeks sounds reasonable, but how doing migrations 10x or 100x that size is far more challenging.

<comment><USER13> I think Gary is the only guy working on the project and it is a new project no wonder he migrated it super fast.

</comment></comment><comment><USER14> TypeScript has been on HN for different reasons over the last few days. The main thing that has stood out, from the flame wars erupting over it is that it is a truly divisive idea. To some, it gives the same securities and checks provided when working with a statically typed language. To others, it curtails the power and expressiveness inherent in JS, the dynamic, functional language it compiles down to.

TypeScript does provide a lot of benefits, but for it to truly succeed and take over in the JS world would mean it has to truly also reflect, and enable JS's functional and dynamic roots. JS got where it is by being JS.. an extremely flexible and accommodating language. HTML got this far today by doing the same, just google XHTML if you doubt that. So for TypeScript to succeed where CoffeeScript failed, this may be the direction it needs to lean more towards: being less divisive, and inviting all kinds of programming paradigms to the party.

That, after-all is how JS succeeded.

<comment><USER15> _JS got where it is by being JS.._

JS got where it is solely by being the language built into browsers.

<comment><USER14> Is that really all it is though? Cases in point: Java Applets, VB, Flash, Dart ...

All of these were at one point or another "built into the browser", but where are they now? Give credit where it is due, the success of the web as a platform lies not in its technical superiority over alternatives, but in its inclusiveness and flexibility. Any tech that is trying to replace HTML, CSS and JS in this regards will seriously have to consider and accommodate this, or suffer the same fate of hundreds of other pretenders to the throne. Long live the king! Long live open, approachable and flexible tech!

Exhibit A: List of very different and diverse languages that compile to JS ( [https://github.com/jashkenas/coffeescript/wiki/List-of- langu...](https://github.com/jashkenas/coffeescript/wiki/List-of-languages- that-compile-to-JS) ). If this does not demonstrate the flexibility and malleability of the language, then I do not know what does. Take web assembly for example, which has been around for over five years now, and was specifically designed as a "compile to" language. How many languages compile to web assembly in comparison?

Any tech that is as divisive as TS is simply not going to get far. Flash ActionScript was massive 10 years ago compared to any alternative to JS tech today, and where is it now? The creator of TS even quotes ActionScript as one of the main inspirations for TS. ActionScript even had a more powerful version of Reacts JSX (ES4), where is it today? CoffeeScript was all the rage 5 years ago, JS simply absorbed all its good ideas, where is it today? The things that last, that stand the test of time are the things that are flexible and accommodate different ways of doing things. For your beloved TS to stand the test of time, it has got to accommodate the whole JS eco-system, not just those who favor the static object oriented way of doing things.

<comment><USER16> I'm not sure why you're talking about "object oriented". TS, in and of itself, has nothing to do with OOP. You can write functional-oriented code in TS same as you would in JS. TS doesn't mandate use of classes or anything like that.

As an example, I can write a React+Redux app in TS, and be writing 100% plain functions (components + reducers) the entire way through.

From my viewpoint, TS has more than hit enough critical mass to survive for the long term:

\- Microsoft is heavily invested in its ongoing development

\- The Angular community requires use of TS

\- The React community has split in general between types and no types, but a recent survey of /r/reactjs readers indicated ~50% of React devs are using TS [0]

\- Where CoffeeScript introduced new syntax entirely, TS's focus on being a superset of standardized JS means that there's both less to worry about compat-wise _and_ it can be seen as a way to use new language features instead of Babel

FWIW, I wrote up my thoughts on learning and using TS as both an app dev and a Redux maintainer [1], and I'm sold on using going forward.

[0] [https://www.swyx.io/writing/react- survey-2019/](https://www.swyx.io/writing/react-survey-2019/)

[1] [https://blog.isquaredsoftware.com/2019/11/blogged-answers- le...](https://blog.isquaredsoftware.com/2019/11/blogged-answers-learning-and- using-typescript/)

<comment><USER14> OOP is not just about using classes, just like functional programming is not just about using functions. They're different programming paradigms, each with their own patterns, strengths and weaknesses. Idiomatic TS favors an OOP style, which is why there are event libraries out their [0] whose sole goal is to enable using TS the functional way.

> The Angular community requires use of TS

Angular was once the king of the JS frontend, but now it has more or less been reduced to a certain niche in the market. It is no accident that it is very popular among those with a Java background, with Java being a very good example of a static OOP language.

> The React community has split in general between types and no types

That split is being caused by TS. This is not a good thing for the eco-system as a whole. The idea that everyone will be forced into adopting TS because of the power of MS is the very idea that will lead to a backlash, just like the backlashes against XHTML and Java applets.

[0] [https://github.com/gcanti/fp-ts](https://github.com/gcanti/fp-ts)

</comment></comment></comment></comment></comment><comment><USER13> How times are changing. The person who is famous for his amazing Ruby/Rails screencasts rewrote his Ruby backend to TS...

</comment><comment><USER17> Wow porting the entire backend in two weeks is impressive. I guess he knew the domain well and both languages well but I'm impressed.

</comment><comment><USER18> How does one deal with remote data in typescript? I really like typescript, but not having any guarantees on the returned data is kind of frustrating.

<comment><USER19> It is actually quite frustrating compared to some other languages, and more often than not you see that its just `JSON.parse` and hope for the best. I wish we had something like Rust's Serde or Haskell's aeson.

If you want to validate data coming over IO then your options are data validation libraries such joi, io-ts, and yup. You have to write seperate data validators on top of your types. io-ts has a way of deriving types from validators, but io-ts is often seen as quite intimidating being built on top of fp-ts.

No matter how carefully you maintain strict typing within your typscript project the moment you hit IO everything is basically `any`.

Some projects like openapi-generator might generate some validators for server respones, but I've not seen any good generators that do actual validation.

I'm not sure if apollo-graphql does responses validation? Does anyone know?

<comment><USER20> Plenty of web frameworks can validate via JSON Schema, using ajv under the hood. (I use Fastify.)

io-ts is pretty scary, though. I like the `runtypes` library but it doesn't help me express my types in a way clients can consume, which, enh.

<comment><USER21> I also liked runtypes more, but it turns out composing io-ts codecs is perfectly readable, and being able to deserialize at the same time/instead of validating is very convenient.

Caveat, I've only been using it for two weeks.

</comment></comment></comment></comment><comment> awinter-py this is _ruby_ -> TS

was expecting JS -> TS

<comment><USER22> It's both

</comment></comment><comment><USER23> But Ruby is so much more fun that JS or TypeScript.

/opinion

</comment><comment><USER24> I watched them go through this process via twitter, and it sounded like inventing that shared api model was a type puzzle i wouldn't be able to figure out myself. also they're the only people i know of doing it?

<comment><USER25> This is more prominent in Haskell and Scala circles.

</comment></comment><comment><USER26> Did it not occur to them to, I don't know, "test" the API when they make changes? A compiler or stricter type system may help prevent certain careless errors, but not all (or even most) of them, while a proper test scheme will catch all such errors.

<comment><USER27> The author is one of the world's most prolific publishers of TDD educational material.

You shouldn't be so quick to assume that everyone else is clueless.

<comment><USER26> My snarky tone was unwarranted but I'm not actually assuming cluelessness here, nor did I come there quickly. I find in practice that TDD and what I think of as "testing" are quite orthogonal.

> With the Ruby backend, we sometimes forgot that a particular API property > held an array of strings, not a single string. ... These are normal dynamic > language problems in any system whose tests don't have 100% test coverage.

TDD in general focuses on code-adjacent test strategies like unit tests. In the Ruby TDD world it's a popular strategy to test first, code second at the level of classes or even individual methods. In practice this"tests = code = tests" philosophy produces both more code and a focus on metrics like coverage that only measure "for how much of my code do I have other code that asserts that my code is doing what the other code says it should be doing" rather than ensuring "my code is actually doing what someone else needs it to do".

"Testing" as I intend the term means using the software to do whatever it is supposed to. For a server side API that probably means consume it via a client. Any client that relies on the type of a property being an array instead of a string will blow up (except perhaps Python, grr). Any reasonably complete smoke or integration testing regime should expose this problem, but more immediately I think developers should be actively testing the thing they are changing while they are changing it. Personally I dislike compilers and restrictive type systems in large part because they _inhibit_ this sort of rapid, iterative testing and fixing. Partially functional dynamically typed code is far more useful to me as I work through a series of related changes than statically typed code that requires I fix all the issues it perceives as important before I can keep going on what really matters.

<comment><USER27> > Any reasonably complete smoke or integration testing regime should expose > this problem

But that's not without cost. At least in the Ruby world (and Bernhardt holds/held this view) integrated tests are to be avoided where possible because it creates a negative feedback loop of slow tests and an exponential number of tests that need to be written to achieve equivalent coverage.

> but more immediately I think developers should be actively testing the thing > they are changing while they are changing it

This smells like the age-old discipline/rigour/professionalism platitude often trotted out by proponents of _Software Craftsmanship_. I'd rather embrace the fact that humans make mistakes and optimise for that, rather than hold people to unreasonable standards.

Furthermore, while I _agree_ that people should be testing the thing they are changing while they are changing it, you appear to be implying that only one form of testing is acceptable here. Why not test the type signature? Why not a formal proof of correctness? Why not a property-based test? There are many ways to improve the chances of a piece of software to work. Restricting ourselves to only one of those ways is, quite frankly, dumb.

> Personally I dislike compilers and restrictive type systems in large part > because they _inhibit_ this sort of rapid, iterative testing and fixing.

That's a fine opinion to have, but that's _all_ it is. I've worked professionally with dynamic languages, and I hold the _opposite_ view. I work with a few projects totalling about 60,000 lines of Haskell, and I feel the language _enables_ rapid, iterative testing much more than Ruby ever did for me. Of course I can't prove this empirically, which is why my opinion will only ever be as good as yours, and vice versa.

> Partially functional dynamically typed code is far more useful to me as I > work through a series of related changes than statically typed code that > requires I fix all the issues it perceives as important before I can keep > going on what really matters.

I'm sorry, but this is plainly incorrect. The ability to defer type errors to runtime certainly exists in Haskell, and I expect not exclusively.

<comment><USER26> If you can come up with a formal proof of correctness for an evolving API then you are clearly operating on a higher plane of software development than us mere craftspeople, and I certainly wouldn't presume to talk you out of trying.

</comment></comment></comment></comment></comment><comment><USER28> Swift on the Server!

</comment><comment><USER29> Porting to a typed language helped prevent type errors in a typeless language. Who woulda thunk?

I am currently also working on a project written in a JS backend that's slowly porting to TS, for the same reasons, but I still would prefer to go back to C# and take it a level further. I just don't enjoy the TypeScript language all that much.

<comment><USER30> > _Porting to a typed language helped prevent type errors in a typeless > language. Who woulda thunk?_

You say this sarcastically, but every JS-related thread on HN turns into a flamewar between type lovers and haters.

The type haters make exactly the argument you're mocking: that typeless languages do not result in more type errors. Their reasoning is along the lines of, "I don't need a type system because I'm a professional and don't make mistakes."

That sounds laughable or like an exaggeration, but it's a surprisingly common line of thinking. The buggiest code I ever worked on was a PHP code base written by someone who had been coding for 20 years and had a Master's in CS. Before I inherited the code, he told me, "I code in the terminal. I don't need IDE features because I don't really make mistakes in PHP anymore."

Again, seems satirical, but not uncommon.

<comment><USER31> Those people are also missing the point that not having types means you are inherently writing a slow program.

<comment><USER32> That's the first time I heard that any language that doesn't have types, is slower than a program with types. I'm unsure if that actually makes sense.

You mean slower as in performance? I'm having a hard time understanding how types == performance, so you have to mean something else.

I guess assembly would be the language you would use if you really need to squeeze out the maximum amount of performance of a single CPU, and as far as I know, it does not have types.

Also languages built on top of LLVM could get by with trading compile times for run time performance. Maybe you meant compiling gets slower without types?

<comment><USER33> Strong typing means that at runtime dynamic behaviors don't need to be accounted for.

For a compiled language, the compiler could know that `foo` and `bar` are 32-bit integers, and thus compile `foo + bar` to call the addition function for 32-bit integers. In an interpreted language, the interpreter could do the same thing.

Without that typing information, both would have to invoke a generic addition function that detects the types of its arguments at runtime, notices they're both 32-bit integers, and delegates to the corresponding addition function.

Of course there are tricks that can be played in the weakly-typed case, like assuming the same call site will always have the same types, so that there can be a short path that assumes that and only branches rarely. That way the first or first few executions might be slow, but eventually they get almost as fast as the statically-typed case. JS engines in particular and JITted runtimes in general usually do this.

>I guess assembly would be the language you would use if you really need to squeeze out the maximum amount of performance of a single CPU, and as far as I know, it does not have types.

Assembly absolutely does have types. The addition function for 32-bit ints only operates on 32-bit ints, and is distinct from the addition function for 64-bit ints.

<comment><USER34> > Assembly absolutely does have types. The addition function for 32-bit ints > only operates on 32-bit ints

You can add any bits that will fit in the relevant registers. Assembly cares not whether the programmer thinks they are ints.

<comment><USER33> You should read the part of the sentence you cut off in your quote.

</comment></comment></comment></comment></comment></comment></comment><comment><USER35> I can't imagine not using class-transformer[0] or class-validator[1] in any TypeScript project that deals with external/third-party APIs, remote or not.

[0] [https://www.npmjs.com/package/class- transformer](https://www.npmjs.com/package/class-transformer) [1] [https://www.npmjs.com/package/class- validator](https://www.npmjs.com/package/class-validator)

<comment><USER36> I don't understand the point of transforming things to class instances, though. All of TypeScript's strengths are available without the need for things to be an actual `instanceof` something, right? Can you elaborate?

FWIW, I'm biased against `class-transformer` because we were wondering why some of our (TypeScript-driven) API endpoints were so slow, and `classToPlain` + `plainToClass` were the culprits, comprising 2/3 of the time spent. If you look at the source code for those functions, they're kind of insane.

<comment><USER20> Agreed that actually doing the transformations is a bit of a mug's game. However, TypeScript's type system treats class definitions interestingly, particularly around metadata. You can attach validation metadata to a class and pass plain objects around that structurally match that class so long as you don't define methods or a constructor.

As mentioned in my sibling comment to yours, I do this to define DTOs that are then expressed in JSON Schema and passed through ajv, and it's pretty slick. The objects being used are all just JavaScript objects, the class is just being used as a metadata holder and something you can reference/get via `design:type`/`design:paramtype`/`design:returntype`.

</comment></comment></comment><comment><USER37> The title is misleading because TypeScript does not implicitly do any kind of runtime type checking on data which was sent by remote clients - If the client and server both happen to be written in TypeScript by the same team, the TypeScript type system can give those developers false confidence that the API endpoints on their server enforces runtime type validation on remote user input (I've seen this too many times), but it does not.

To implement API endpoints correctly in TypeScript, you're supposed to assume that the arguments sent by the remote client are of 'unknown' type and then you need to do some explicit schema validation followed by explicit type casting. Some TypeScript libraries can make this easier but it's misleading to say that this is a native feature of TypeScript; in fact, it is no different from doing explicit schema validation with JavaScript (there are also libraries to do this). You should always validate remote user input regardless of what programming language you use.

Merely getting the compile-time static type checker to shut up because the types in your client code match the types in your server code is not good enough unfortunately - In fact, it may conceal real issues by giving developers false confidence that runtime type validation is happening when in fact it is not. A hacker could write a client in a different language and intentionally send incorrect input to crash your server unless your server explicitly validates the schema.

The reality is that there is no guaranteed type continuity/consistency between the client and the server. Any tool which gives the illusion that there is any kind of continuity is deceptive by design.

This is why I like plain JavaScript; it requires real discipline and it doesn't give any sense of false confidence. Developers should always be on their toes. The only way to improve code quality and security is by exercising more caution, not using more tooling.

The benefit pointed out by the author of this article is in fact one of the few genuine gaps in TypeScript's type safety capabilities. Praising TypeScript for this fictitious feature is only going to give developers false confidence that TS somehow takes care of input validation for them and this is going to lead them to getting hacked.

<comment><USER38> (I wrote the article.)

Our system uses io-ts to dynamically validate all incoming and outgoing API data. The static API types are guaranteed to match the io-ts codecs, so the runtime validation will match the static types.

Re: "it's misleading to say that this is a feature of TypeScript": I didn't say that. TypeScript makes this kind of static verification possible. It's impossible in JavaScript.

Re: "The benefit pointed out by the author of this article is in fact one of the few genuine gaps in TypeScript's capabilities": yes, it's a gap in TS. Again, TS makes it _possible_ (as opposed to JS). io-ts (mentioned explicitly by name in the article) backfills the type erasure shortcoming for our purposes, at the expense of being more verbose and producing worse error messages when compared to first-class reflection in a non-type-erasing language.

Re: "going to lead to them getting hacked": no, io-ts isn't going to lead to that more than any other runtime validation scheme. If someone believes that TS' static types provide runtime guarantees, yes, they could write highly insecure API code. But it's hard for me to imagine someone getting to an experience level where they can write a server-side router that's generic over all possible API endpoint payloads, while at the same time not knowing that TS erases types at runtime. Erasure comes up early in the process of learning TS because it leads to surprising behavior, like objects at runtime having properties that aren't present in their static type.

<comment><USER37> >> It's impossible in JavaScript.

It's definitely possible (just as easy in fact). You just need to define a schema for each API endpoint. TypeScript does not physically protect you from having to enumerate all the properties and size constraints of the data one by one. In terms of the actual schema validation step, there are lots of tools in JavaScript which let you do the same thing; ajv, z-schema are just a couple of examples.

My point is that TS adds no value there. TS's value is only in static type checking. What the article is claiming is that TS somehow adds value with runtime type checking.

The argument of saying that "TypeScript adds value because it can reuse its internal type definitions for the purpose of validating remote input" is circular - It refers to a problem which doesn't exist in JavaScript to begin with.

JavaScript has no type definitions so being unable to reuse type definitions for schema validation does not qualify as a drawback on its part. The argument simply does not apply and cannot be used to claim TS's superiority.

At best you could claim that TypeScript cancels out one of its own shortcomings:

\- TS shortcoming: You need to define types everywhere... That adds a lot of work! (-1 point)

\- TS benefit: But you can re-use these type definitions for doing schema validation of user input as well! That saves a lot of work! (+1 point)

But the net gain over JS is 0 because:

\- JS shortcoming: You need to define a schema for all your endpoints to validate user input... That adds a lot of work! (-1 point)

\- JS benefit: But aside from that, you don't need to define types anywhere... So that saves you a lot of work. (+1 point)

The only real argument to be had is whether or not compile-time static typing adds value over dynamic typing.

<comment><USER38> The post isn't about dynamic validation; it's about static type checking of APIs, which is impossible in JavaScript.

<comment><USER37> My point is that static type checking of APIs does not solve any new problem which static type checking in general does not already solve - That's why I don't agree that it solves API woes specifically. My argument is that it adds no value in that area.

If a developer already does input validation correctly with JavaScript, then switching to TypeScript will not add any value for them in that area.

Furthermore, my first argument (about TS giving false confidence) is that TypeScript does not make it any more likely that an unskilled developer would be able to identify and solve the problem of schema validation when compared to JavaScript... From the unskilled developer's point of view, false confidence (which TypeScript can sometimes provide) is worse than having no confidence at all (which is what JavaScript always provides).

Type checking is 100% about confidence; it gives more confidence. Confidence and correctness are two completely different things and I wanted to point out that there is such a thing as false confidence.

<comment><USER38> I rename the "email" key in our register endpoint to "emailAddress" and all code that touches that key turns red less than 1s later, whether it's in the client or server.

Edit: All of these edits to your posts after I've already replied are very confusing.

<comment><USER37> What you're describing applies to static type checking in general. I don't argue this point. Sorry about the edits. It's very difficult to express such things unambiguously.

I'm more concerned about the effects of the post's title on people's programming practices than the actual content of it. HN does tend to have this effect unfortunately.

<comment><USER37> Also, I should point out that in terms of achieving correctness, it's possible to get similar value as what you're describing simply by having good tests.

I don't want to get into this argument now though because it could last forever but hopefully it highlights why it's important to keep arguments tightly bounded and not make blanket statements when the domain is so large and complex and we can go off on a tangent in an infinite number of directions.

Ultimately, I enjoy JavaScript and I don't want future employers to force me to use TypeScript because of articles like yours (with those kinds of titles)... I was already forced to use TypeScript at my last company, it went well but it would have been even better if founders had let me and my team use JavaScript... For one, I might not have quit the company. I was tired of debugging mangled JavaScript (compiled from TS) using vim over SSH whenever there was a problem (it was a large decentralized P2P project so often that was the only way to debug it). The drawbacks of TS were definitely not worth its benefits for that specific project.

<comment><USER38> You may enjoy this talk: [https://www.destroyallsoftware.com/talks/ideology](https://www.destroyallsoftware.com/talks/ideology)

<comment><USER37> This video convinced me even further that dynamic typing is superior. The speaker basically admitted that static type checking still requires unit tests because types in statically typed languages have too broad/imprecise granularity. I was also thinking about issues related to timing, race conditions and incorrect state mutations; static typing doesn't prevent any of these. IMO, static typing doesn't even begin to address a tiny fraction of all the possible programming mistakes that one might make. IMO its added utility value is often so low that it's basically not worth the mere hassle of having to come up with type definitions.

Personally, when I write a function definition, I always try to visualize the set of possible values that the function will need to handle - So given that I already have that precise set of possible arguments already in my mind as I write the function, it doesn't add any value for me to then formally generalize my function parameters as being integers or strings or some other types which are too broad to effectively constrain my function input to the required level. With static typed languages, merely specifying that a variable is an integer doesn't save me from having to think about what specific subset of integers I mean. For example, if my function only works with odd numbers as input, using the integer type definition will not offer me any additional safety.

I would argue that most functions are like this. The type definitions are never granular enough to guarantee correctness. The type system only protects you from the most basic/obvious mistakes - So obvious that you don't even need the type checker to tell you.

<comment><USER39> > The speaker basically admitted that static type checking still requires unit > tests because statically typed languages have limited granularity in the > typing.

Static types only cover one set of bugs, but it is an extremely rewarding set. The payoff of static typing, and what TypeScript focuses on, is early feedback (did I get the name right, did I forget to convert some arguments, what can this value do?). If you focus on the "it eliminates some tests" aspect, you are completely missing the point.

> Personally, when I write a function definition, I always try to visualize > the range of possible values that the function will need to handle - <USER2> > given that I already have that specific range already in my mind as I write > the function, it doesn't add any value...

So what the function will handle remain in your head? Or you found a better way to document them than type annotations? Do you write code that anyone else has to read now, or even you have to read later?

> The type definitions are never granular enough to guarantee correctness.

They were never meant for that purpose.</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment>


Open Source iPhone Augmented Reality Library - <AUTHOR> http://iphonear.org

<comment><USER2> Here iphonear.org doesn't work, but www.iphonear.org does. (probably a DNS caching issue).

<comment><AUTHOR> Doh, not sure if I can update it</comment></comment>


Microsoft Responds To Google's Extortion Claim - <AUTHOR> http://techcrunch.com/2011/09/28/microsoft-to-google-pay-up/

<comment><USER2> The question we ought to ask ourselves is this:

 _Is making a similar feature or technology bad for innovation and competition?_

Because I'm pretty sure Google didn't just start deconstructing and reverse engineering Microsoft's products to make Android.

I don't think "patents" should be licensed. Only actual working products and services - like ActiveSync for example, or the AMOLED display technoogy, and so on. Not these "patents" that no company that will license them will use the "inventions" in them to further build their own products.

Licensing should happen because you _want_ that technology in your product, not because you're afraid of being sued. The current system is completely messed up.

</comment><comment><USER3> I wonder if the Microsoft representative actually believes that "industry leaders" are the key to innovation, or likely to be hurt by patent shennanigans.

The fact that you can't make a portable computer without paying secret fees for secret patents strikes me as rather bad news for innovation.

<comment><USER4> True to a point but there is no love lost between Google and Microsoft. Google tried to drive Microsoft out of business with the Google Pack, Chrome OS etc. No serious company would turn $5 for each Android.

Apple is no fan of Google either, nor are the content and publishing companies and the list can go on.

</comment></comment><comment><USER5> An a serious note, google needs to persue Bing and any similar services using it's patent portfolio. It has important ones like Map-Reduce. Once google gets series it won't matter that MS sues, google can extort MS for cash and feed that money to samsung and friends to help them with their royalties.

</comment><comment><USER6> Software patents are a terrible thing.

<comment><USER7> Not just terrible, but an abomination that is holding back information and technology progress.

The whole patent war thing will have to go downhill a while before it all blows in their face.

</comment></comment><comment><USER8> I wonder if it's any coincidence that Samsung announced that they'll be partnering with Intel to revitalize Maemo (now "Tizen") on the same day that this was announced. This also makes me question how strong their case is against Apple. It sure looks like Google didn't have their bases covered with Android.

<comment><USER9> It's impossible to have your bases covered as a new player in the OS business. That's the point of software patents. They protect the incumbents from the threat of competition.

</comment></comment><comment><USER10> I find Shaw's response to be asinine.

<comment><USER11> I'd say juvenile would be a more appropriate word.

Given Google's recent behaviour with the Nortel auction (bidding pi etc), which could also be seen as a bit childish, perhaps this is Microsoft simply responding in kind. It is bizarre though.

<comment><USER12> Agreed, and I'd include the whole lot as guilty of immaturity. Google basically gets nailed by a patent holder, and they complain because the patent holder filed a claim against them? And they call them out for "extortion"?

I guess I can go violate someone else's patents, then when they complain, I can say they are extortionist.

And here I thought these companies were supposed to be full of smart people.

<comment><USER13> Both companies _are_ full of super-smart people, but they're too busy building cool things. This kind of stuff is what happens when you let the MBA's take over.

</comment></comment></comment></comment><comment><USER14> Microsoft should consider competing on innovation & tech for a change. Throwing lawyers & FUD at anyone who is beating them is just petty.

<comment><USER15> Why innovate if Google can just steal everything they do?

I have no doubt many of the tens of thousands of patents MS has are stupid, obvious and wrongly awarded. However, tens of thousands of patents also speaks to no small amount of real innovation.

<comment><USER2> What did Google steal from Microsoft? Has it been proven in a Court?

Look around you, all products in a "product category" are alike. It's how competition works. You don't think Microsoft build similar stuff to others? What about their multi-tasking in Mango?

<comment><USER15> I'm not claiming competition is bad or microsoft doesn't build similar stuff to others or that anything has been proven in court, red herring much?

Parent comment indicated that Microsoft should "innovate" instead of protecting their IP and apparent approval for any infringement of their other IP. I mean who cares about your other innovations everyone should be free to copy those, shut up and keep innovating.

As much as people at HN like to parrot the line that patents only stifle innovation there's a strong argument that they also encourage it and that innovation should be protected from pirates and copying.

If Microsoft believes their innovations are being copied illegally, saying "they should just innovate more" instead of using legal recourse is silly.

Similarly saying all Microsoft has is FUD is silly, who thinks HTC and Samsung are writing $100 million dollar checks to MS to avoid a spurious lawsuit?

</comment></comment></comment></comment><comment><USER16> I don't get why Microsoft doesn't mind that the world's impression of doing business with them is that a month later they will be consolling you with "Well, at least you can view this as a lesson learned."</comment>


Letter to my angellist syndicates after 3 deals and $1.4m invested  - <AUTHOR> https://medium.com/@jason/private-email-to-my-angel-list-syndicates-dffd624d8539

<comment><USER2> Pretty clear. How do you decide what deals to syndicate? And U.S. only?</comment>


90 of top 200 sites have no mobile version. Opportunity? - <AUTHOR> http://blog.programmableweb.com/2011/05/17/90-of-top-200-sites-have-no-mobile-version-says-new-api

<comment><USER2> I don't know that this actually makes any sense.

Are we still doing os checks and serving different pages based on the client (I'm not).

With modern browsers on smartphones, I think this is mostly not-necessary for the average top 200 site which likely still targest the lowest common- denominator browsers. Mobile browsers are over-powered and very capable to display these sites.

It's the smaller early adopter sites that are pushing the envelope and may need to do some sniffing.</comment>