The Zelda Test (or Why no Zelda Clones?) - <AUTHOR> http://games.greggman.com/game/the-zelda-test-or-why-no-zelda-clones/ <comment><USER2> I think I'm one of the five people on HN who do not hold Zelda as the pinnacle of gaming. To address a few points:

1\. Op chooses to compare Zelda (and let's be clear, this is modern day zelda) to what amount to first gen games. However, comparing modern Zelda to Doom seems a bit unfair. How about The legend of Zelda, which by my count, has 25 items and pick-ups (including sword and shield upgrades). The original Doom, which is continually referred to throughout the piece, has 26 items.

2\. Devil May Cry 3 is not a button masher. Go ahead, beat the game, and then tell me you could randomly tap buttons and progress. Just because you are quickly hitting buttons does not mark a game as a masher.

3\. I just don't understand the point that is being made. He claims other genres are all just clones of each other and then defines them so loosely that Twisted Metal is now not worth mentioning because, more or less, it is just Gran Turismo...

I'm finding that this response is growing rather uncontrollably and frighteningly I could probably write an entire blog response to this article. But, I think this article skims a bigger idea: Unique games stand alone in their respective genres because they bring together multiple disciplines/genres and blend them into a cohesive experience. Some games try to do this (Duke Nukem Forever) and most fail. Others like Zelda, Portal,and GTA succeed and become fan favorites that influence future game designs.

<comment><USER3> It's true that The Legend of Zelda has 25 carryable items (see [http://www.zeldadungeon.net/Zelda01-the-legend-of-zelda- item...](http://www.zeldadungeon.net/Zelda01-the-legend-of-zelda-items.php)). But it also has a bunch of other items: hearts, heart containers, fairies, pieces of Triforce, blue and red rupees, the magical clock, possibly other things (this is off the top of my head). That's 32 items, which is I think the count in the article. Of those, at least 18 are classes of things (eg "key", "sword", "potion", "health"). Each class has a unique function (almost -- the wand is arguable). By comparison, half of Doom's items are the same class ("gun"), and most of the others fall into one of the two classes "health" and "armour". I think the OP's point is quite well made here: Zelda, even the first one, made in 1986), puts a huge emphasis on unique items and incorporates them into puzzles.

</comment></comment><comment><USER4> He listed so many must-have items that virtually no non-Zelda game will hit all of them.

One entire series that was obviously Zelda-inspired (in both 2d and 3d incarnations) was The Legacy of Kain games. Blood Omen played very much like a 2d Zelda and Soul Reaver 1&2 played very much like a 3d Zelda.

After those games the series kind of switched gears into Devil May Cry territory, but the first 3 games were very Zeldaish, only with a dark emo coat of paint.

<comment><USER5> Hell, the very first _Legend of Zelda_ fails on half of these items. And, naturally, there were rather a few games that emulated the _crap_ out of the first two Zeldas, just as a starting point.

</comment></comment><comment><USER6> Though the author seems aware of his subjective limitations ("...there are almost ZERO clones of Zelda. I'm probably missing a whole bunch but..."), he is nevertheless very quick to make sweeping pronouncements. And he defines the Zelda subgenre more or less recursively; to be like Zelda is to be Zelda-like in ways X, Y, and Z.

Through it all, the primary conditions for being like Zelda seem to be: a) to have been noticed by the author in his game-playing travels, and b) to have passed the author's retroactively applied taste test.

All of this is a shame, not because the author gives short shrift to every Zelda-style game out there, but because he does so to _Zelda itself_. Given his passion for the series, he could have written a very insightful dissection of what makes it work. Why is Zelda so revered, so timeless, and so enchanting? These are questions the author seems overly equipped to handle, and their answers would make for a very interesting post (or series of posts). I, for one, would love to see him take a deeper dive into the mechanics, psychology, mythology, setting, and style of the series. Relieved of the burden of proving a categorical declaration, he could instead focus his energies on a lively study. Rather than talking about what makes Zelda an exception, he could talk about what makes Zelda exceptional.

<comment><USER7> Although I understand what you mean, I also understand the author's point about 'being zelda-ish'. I.e. I really like Zelda (I'm currently playing the last one and really enjoying it), but I'd enjoy any other games based on Zelda's principle game mechanics which the author rightly described.

For instance, I enjoy how the same region will evolve over time depending on where you are in your main quest. At first, it's just a road to go to the temple. But as the game progress and you get more items, you can explore it in depth and discover awesome quests/items.

I agree with him/her that there's really few games out there that mimics the game mechanics of zelda. Mario 64 comes close but, for instance, miss the in depth strategy and the various items. Zelda really have unique game play and it's not just about the world of Zelda.. you could create a totally different world and still copy the game mechanics.. but lots of really successful game use only a part of zelda's game play which is on what the author argue.

In fact, it can be summarized as Zelda being the intersection between multiple 'genres'. And it's surprising that nobody copies it exactly as we all know how Zelda is a success and is popular.

<comment><USER6> _"I agree with him/her that there's really few games out there that mimics the game mechanics of zelda."_

I guess I take two general issues with that statement. The first is that the author's criterion, or yours, about what constitutes "very few" is vaguely defined. How many would be "more than a few"? I'm really not trying to pick nits here. I very much understand and appreciate your main point. But it seems as if the comment section of this article is brimming over with examples of Zelda-like games (whether or not they are true "clones" is also vague and subjective).

Second, do we really _want_ games to be "mimicking" Zelda? Is that a goal we're generally in favor of? Personally speaking, I'm completely content to let Zelda be Zelda, and let other developers and publishers try to break different ground in different areas. If we're generally in favor of an expansion of the Zelda-type subgenre of Action RPGs, that's fine. But why must games in this subgenre have to "mimick" Zelda in order to meet our needs? By very definition, isn't the attempt at mimicking Zelda going to doom those games to being second-rate Zelda clones?

</comment></comment></comment><comment><USER8> MODERN WARFARE 3 IS BASICALLY A DIRECT RIP OFF OF DOOM BUT NOTHING IS EVEN IN THE SAME GENRE AS ZELDA.

Only a Nintendo fanboy could ever rationalize something so ridiculous.

There's a ton of games out there with large worlds and in-game isometric/3d action.

Sure, nothing follows the exact formula, but that's because there is no need to directly copy. The genre is alive and well and no fanboys are going to convince anyone that Zelda is a unique butterfly.

</comment><comment><USER9> I disagree with the author when he says that "RPG, in the context of video games basically means quest based game with turn based combat." IMO, this is extremely narrow-minded, and entirely sidesteps the most important part of the RPG acronym: the R and P, standing for role-playing.

That said, just role-playing is not enough to make an RPG (otherwise, all games would be RPG's!). To say Zelda is anything other than an RPG is narrow- mindedness at best, and intentionally misleading at worst.

<comment><USER10> The article addresses this part clearly: the "RP" in "RPG" doesn't really define the category, since most (all?) character-based games are "role- playing": in a racing game, you're role-playing a race car driver, in a military FPS you're role-playing a soldier, etc. But I wouldn't call those RPGs by any stretch of the imagination.

RPG has pretty much come to mean a very specific thing: quest-type game with turn-based combat. I would never think of Zelda as an RPG.

(As an aside, remember Super Mario RPG? They mashed standard Mario with the kind of RPG format I describe above... funny that they explicitly acknowledge the format in the title of the game.)

<comment><USER11> I disagree with the "turn-based". There are loads of RPGs which aren't strictly turn-based or even feature action-oriented battles. Games such as Final Fantasy and Xenosaga would fall into the former category (which really is blurring the line a bit because it depends on what you define as turn- based) while games such as World of Warcraft or the "Tales of" Series, which feature real time combat, either more tactical (WoW) or even in the style of Beat-em-Ups (which was essentially pioneered by Tales of Phantasia and became a selling point of the series as a whole).

I would personally define RPG as a game that features most the following:

\- a story that isn't just background for the gameplay (like in many FPS, where the story is just an excuse for you to shoot stuff). This will most likely includes character development and other sorts of progression in the game world. (Zelda? Check.)

\- some sort of combat system, whether turn-based, action-oriented or with strategic elements doesn't matter (Zelda? Check.)

\- generally non-linear gameplay including sidequests. There's usually a red thread along which the main game progresses, but you can "pause" at almost any time and just do what the fuck you want - go explore, do sidequests, grind levels or equipment etc. (Zelda? Check.)

\- character progression, through acquiring new items, abilities, levels, skills etc. (Zelda? Check.)

I kept this intentionally fuzzy because there are many fringe cases, such as Monster Hunter, which basically lacks the story (it's really just an excuse to tell you "go hunt monsters"), but is otherwise considered an RPG too.

Zelda definitely IS an RPG. I think it's partially due to being so special that many people don't like to classify it as such - they might feel like it takes away from the magic a bit.

<comment><USER12> _a story that isn't just background for the gameplay... (Zelda? Check.)_

Is there some hidden story mode for Zelda? Last I checked a princess got kidnapped and you go rescue her. That is the total extent of the plot. It is as paper thin as you can get. There is no character development. Outside of Link's ability to use a sword he has zero character. Gannon is an equally shallow evil wizard dude.

<comment><USER11> I agree to a point, but there's a reason I included "world progression" into that point.

I do have to admit I'm a bit biased on this since I've read a lot of supplementary materials which flesh out the games a lot (there are mangas for Ocarina of Time, Majora's Mask and quite a few other Zeldas), and especially the newer Zeldas (arguably starting with Majora's Mask[1]) _do_ have a decent plot and story, even though it isn't as "epic" as the likes of Final Fantasy.

[1] Majora's Mask deserves a special mention because it's - perhaps infamously - a very non-standard Zelda. Most of its charme lies in the incredible amount of (mostly optional) character driven side-quests which range from funny and interesting to soul-crushingly depressing. I consider it my favorite game in the franchise for this reason.

</comment></comment></comment></comment></comment><comment><USER13> First thing I thought when I read the title was "Never heard of Okami?". Fortunately, the article mentions the game as well. It predates Twilight Princess, but is obviously heavily inspired by the Zelda franchise in a good way. It's very original and beautifully styled. I highly recommend anyone who enjoys playing Zelda to check it out.

</comment><comment><USER14> Three games that would get pretty close to that are cavestory (but not many optional subquests), secret of mana (not sure though for the rule #8 it's been a while) and little big adventure (but it's been a long time I've played it so I'm not 100% sure anymore). Incidentally, those are some of my favorite games...

But indeed there are very few games that meet all those requirements which is a bit of a pity...

</comment><comment> buff-a If you apply those strict standards of similarity to Mario as you do to Zelda, then not one of those games listed is the same as Mario, and Sonic the least of them.

</comment><comment><USER15> 3D Dot Game Heroes is a pretty obvious clone of Zelda (and fun, too!).

Also, after thinking about it, Batman: Arkham (Asylum|City) incorporate many elements from Zelda, especially the gadget and backtracking-mechanics.

</comment><comment><USER16> I found Darksiders to be very similar to Zelda, based on all the points mentioned by the author.

Separately though, I agree Zelda holds a unique charm that's very difficult to evoke or copy (kind of like Pixar movies).

<comment><USER17> I totally agree. You can always tell the people who didnt play Darksiders when they diss it as a God of War clone. :)

</comment></comment><comment><USER18> No Zelda clones? Maybe it's more accurate to say that very few Zelda clones come close to the Zelda series' quality.

There are plenty of Zelda clones:

The Legacy of Kain Series

The Darksiders Series

Secret of Mana

Zenonia

Sacred Odyssey

... and plenty more for iOS and Android.

<comment><USER19> There are so many subtle details, which are so well designed, you can't catch that with a score.

The whole games makes an impression as a whole. We are only talking about game mechanics but there are few games that have this atmosphere. The music, the lightning and the themes are simply art. You can't break that down in a list.

There is only one Shigeru Miyamoto.

<comment><USER18> One of us has misunderstood the others' post. As I have already written; I agree with you, I can't think of any game in Zelda's specific genre that beats or even comes close to Zelda's quality. I only pointed out that there are actually many games that clone Zelda's game mechanics at large, which imo the article's author completely missed for some strange reason. (None of the games he listed are actually games that fall within Zelda's genre.)

</comment></comment></comment><comment><USER20> The Current Generation of the Grand Theft Auto series do in fact meet the qualifications. The game skin throws you off, but the structure is very similar. The only major difference is that there are subchapters in plot instead of just chapters.

<comment><USER21> Yep, GTA3 (even) arguably meets all of the listed criteria:

</comment></comment><comment><USER22> Seems everyone here is talking about "games in the Zelda sub-genre." I'd like to mention an actual _Zelda clone_ (as it's a game I played for years, long ago—I don't know enough to endorse it in its present state): Graal Online.

Graal Online (or just Graal for short) is/was an MMORPG resembling Zelda: A Link To The Past in almost every way. In fact, it was originally _called_ "Zelda Online" until they were served notice by Nintendo (the resulting changes were profoundly minor.) The game went through phases of being first a Java applet, then a Windows executable, and—most recently, it appears—a Facebook and iOS app.

It's basically what you'd expect from a Zelda game: a sword with damage levels and a shield that can deflect projectiles, bombs and arrows, rupees in bushes, Metroidvania-style "dungeon key-item unlocks more overworld" gameplay, etc. On the other hand, it's actually very _programmable_ : it comes with (or, at least, used to come with) a built-in game editor, which can be used to construct one's own 64x64-tile maps, and Actor-modeled "Graalscript" sprite objects. (For example, you can drop any arbitrary image onto the map, and then add hooks for "was obtained," "was selected in menu," and "was fired," and you'll now have a new carryable item.) This content can then be pushed to the server where (after moderation) any group of players can wander in and interact with it. In fact, "outdoor" maps may actually get stitched right into the main overworld. (This is still my gold-standard for the concept of "player housing" in an MMO.) I would compare the usage-experience as similar to a 2D, Zelda-motif'ed Second Life, or a sprite-based _MOO_.

After a while, Cyberjoueurs (the creators) came to the money-making strategy of allowing people to run the server software on their own (centralized) game servers, charging a fee but allowing people to make money off those "Player Worlds" in turn. This then introduced waves of heavy customization, where little of the original Zelda mechanics remain in many player-worlds (the UI may be overridden at a low level in Graalscript to draw your own GUI, perform your own sprite animations in reaction to arbitrary key-presses, etc.) Because of this, most of the communal world-building aspect was abandoned, which is a shame. It does still seem to play a lot like Zelda, though :)

</comment><comment><USER23> I concur with the rest of the comments - I don't understand how the author can dismiss the plethora of RPG/adventure games, from GTA to Skyrim, as not being inspired by Zelda's gameplay in the same way platformers can be said to be derivative of Mario.

What's surprising is the fact that the "fanboyism" would only be augmented by this conclusion, in that imitation is the greatest form of flattery. I'd say the message would be even more powerful if he could articulate this genealogy.

On the other hand I realize the Zelda series is absolutely unique, but that this is due its minimalism, its art, and its' developers' refusal to sacrifice artistic continuity for the sake of graphic realism. The directing through the history of the series is the element impossible to replicate.

</comment><comment><USER24> Personally I think Crystalis for NES came pretty close to this criteria - worth checking out if you haven't played it before.

<http://en.wikipedia.org/wiki/Crystalis>

</comment><comment><USER25> What about Deus Ex? Though the original game doesn't have an overworld, it's levels are quite large (and open ended) and it seems to meet all the other criteria. I'd never thought about it before, but this might be why I enjoy the game so much - it's a Zelda-type experience. I will admit that it lacks the specific weapon/enemy combos the Zelda thrives on. And really, there's only one way to play a Zelda game, while there are a number of very different ways to play DX.

</comment><comment><USER26> Chrono trigger is almost there. I really like the time based should-I-wait- for-combo-or-go-now Combat system.. Also, it has one thing many zeldas do not - various endings

</comment><comment><USER27> secret of mana?

<comment><USER28> As an aside, I could never understand why A Link to the Past was consistently ranked higher than Secret of Mana in gaming magazines, top 100 lists, etc. Secret of Mana seemed _vastly_ superior in almost every way.

<comment><USER29> My 6 year old son just played through it on our Wii and I was reminded how awesome Secret of Mana is. I started a new game myself and was sucked in instantly.

Excellent game.

</comment></comment></comment><comment><USER30> I don't know if it passes the Zelda test but "Sphinx and the Cursed Mummy" (GameCube, PS2, Xbox) is - as far as I remember - a good clone.

</comment><comment><USER31> Final fantasy ticks all the boxes mentioned. And I'd say its as great a game as Zelda (though en large maybe not quite as "polished").

<comment><USER10> FF has turn-based non-precision battles, unlike Zelda, so that fails the test according to the article's list.

(I'm actually surprised the article didn't mention FF at all.)

<comment><USER32> Depends on which FF as the battle mechanic changed for each game

FFVII had (from memory; it's been a few years) a time based system - like turn based, but each character has a timer run down after their turn until their next one. You had only that much time to decide on your next attack, and with 3 of your characters in the same battle things could get frantic on occasion

</comment></comment></comment><comment><USER33> There's a Zelda-like game for iPhone that came out earlier this year, Sacred Odyssey: Rise of Ayden, made by Gameloft.

</comment><comment><USER34> So many things define Zelda. _Ocarina of Time_ without the score would be a completely different game. If it were so simple to make a clone, people would already have done it.

Then again, I stopped bothering with the series after _Majora's Mask_ which I didn't even like.

</comment><comment><USER35> There is one for Sega Genesis that I remember liking a lot when I was younger: Beyond Oasis

<http://en.wikipedia.org/wiki/Beyond_Oasis>

</comment><comment><USER36> only commenting here because zelda is my favorite game ever and i want to go over this list later (like when my daughter is a almost grown up), but if i just bookmark it, it will be lost and i'll forget.

</comment><comment><USER37> You've just described Skyrim

<comment><USER38> I didn't downvote you, but the article _directly explains_ why The Elder Scrolls games are not relevant in his opinion.

The 'unique abilities' point he makes (whether you agree or not) fails here: I love Skyrim (lvl 38 right now), but magic is not needed so far (I don't know anything special), nor any skills. Combat is the same, whatever weapon you use, from the process point of view (sure, some weapons look cooler. You can do sneak attacks. Still - you do the very same thing, all the time).

<comment><USER39> I thought there were sections where your shout powers are required to progress the plot?

<comment><USER38> Just thought about it. I haven't finished the main quest/plot, so I cannot be sure and I won't spoil any detail here. I cannot judge how far I'm into the main plot but I did a ton of side quests and explored a lot, actually avoiding progress on the main line.

You are correct, a couple of times (4?) I encountered a situation where I needed a shout. Three categories:

1) Do the shout that everyone knows (no spoiler here: You get one 'for free' at the start of the game), to prove that you can. I consider this pointless. It's more like "Link, can you swing your sword". A press of a button, not 'changing the game' or 'necessary to advance' in a real sense. It's not that I bomb my way into a previously hidden cave, I have to shout someone in the face because the story requires it..

2) "I taught you this shout that you might never use again (for me, at least. I tend to use just the first/basic one and even that's rare), show me that you understand its use" (twice?). Again, this is not used to overcome anything, it's just part of the narrative, to show your character's understanding, part of the 'being taught' play. Doesn't qualify.

3) "This impassable area can only be accessed with a specific shout that you get right at the entrance and that is useless everywhere else" (again, from my experience so far). This is - a key. Not a tool. A key that you only get after a couple of quests and that requires you to press Z (or whatever button on the console of your choice) a couple times to pass the 'door' area. Once, so far for me. Maybe I need to return in the future and use it again. Still a key in my book.

</comment></comment></comment></comment><comment><USER40> Dink Smallwood is a lot like Zelda.

</comment><comment><USER17> check out the Neutopia series for the Turbo-Grafx 16.</comment>


Why's poignant guide to Ruby [pdf] - <AUTHOR> http://www.rubyinside.com/media/poignant-guide.pdf <comment><AUTHOR> I have started reading this after doing [https://www.railstutorial.org/book](https://www.railstutorial.org/book) to fill in some gaps in my own knowledge. It is very amusing (and very poignant). Full credit to the author. (Is it who I think it is?)</comment>


Ask YC:SMS Messaging... - <AUTHOR>

I was thinking of writing a small app, that potentially needs SMS notifications [That is, it should send out SMS's, to start with anyways]. I read about SMS Gateway on Wikipedia, and other articles on the web. It seems most recommend http://www.clickatell.com/ as they provide an API, but I was looking for alternatives.
Can anyone provide any direction here? This is a small project on the side for me so I am hoping it won't be too expensive. I honestly did not look into the pricing of any vendors out there, but is it possible to hack up such a service? I came across this [http://jmarinez.typepad.com/blog/2007/05/poor_mans_sms_g_1.html]
Any suggestions/pointers would be nice.
Thank you all. <comment><USER2> It all depends on home many messages you're sending. If you're sending in the tens of thousands per month, there are companies that'll pay you to send them for you (and include an ad)

If you're just sending a few, you should send them using an email. The only downside of this method is that you need to know which provider they use, which means either asking the user, or looking it from an expensive DB.

If you do know which provider they have, you can look up the email here

[http://www.livejournal.com/tools/textmessage.bml?mode=detail...](http://www.livejournal.com/tools/textmessage.bml?mode=details)

If you don't want to ask, you could use Teleflip, who will do the lookup for you. Just email firstname.lastname@example.com

There was an earlier discussion about this, but we don't have a FSQ [1] or search feature, so I don't blame you for missing it. Take a look at <http://news.ycombinator.com/item?id=68227>

Let us know which way you end up going!

[1] <http://news.ycombinator.com/item?id=97491>

<comment><AUTHOR> Hey e1ven. Thank you for those links. I did use searchYc.com to search for sms and text, but did not find those, so I appreciate you sending those my way.

To all those who responded, thanks a lot. I think I will start with the email->sms option, and then to textmarks (that really looks interesting, though if I were to open this out others they might not appreciate me giving their phone number to a third party).

I will be sure to fill you all in when and if this goes anywhere ;-) I certainly don't have $12000 for clickatell and if it comes to that, well, I might just not go public.

</comment></comment><comment><USER3> A friend of mine simply hooked up a cellphone using USB and sent SMS using AT commands. Takes a bit of programming, but as cheap as can be.

<http://www.developershome.com/sms/howToSendSMSFromPC.asp>

<comment><USER4> Sweet idea. Scales well, too, assuming you can find cheap cheap phones with pay as you go data.

<comment><USER5> You can even get GSM PCI cards that take 1 or more SIM cards. Presumably they exist for the north american system too. You might just want to check the terms of use of the operator, they may prohibit automation on normal tariffs.

</comment></comment></comment><comment><USER6> If you're looking for a no-cost solution you should consider an email to SMS gateway. You'll have to know who the carrier you're sending to is, and I know several of the carriers give a lower priority to these sorts of messages, but depending on your application, this may be a viable way to go. <http://basicstate.com/htm/page.htm> is a pretty comprehensive list

<comment><USER7> The problem with email->SMS is that if you 'abuse' the system, and abuse can be loosely defined here, you might find SMS messages disappearing. If you're only sending messages in the hundreds per month, it's fine. Anything more than a thousand you really need a gateway.

<comment><USER6> Totally valid point. Mobile carriers are very difficult to deal with, and almost universally have a policy of shutting off access first, and then it is your duty to try and figure out why it happened so you can navigate their bureaucracy in hopes of getting things restored.

I suggested email->sms for raju's question because he was looking for a solution for his "small app" that only "potentially" needed sms capabilities, so I assumed a low-volume transaction limit, for which email->sms is a cheap and easy solution.

<comment><AUTHOR> Thanks! I might start with the email->sms and see how that goes. I have noticed, too that carriers don't always deliver the email->sms and many a times they have disappeared.

</comment></comment></comment></comment><comment><USER8> I have been experimenting with <http://www.txtdrop.com/> \- they add a little tagline at the end, but it works. You may have users that do not want their number going to some random company.

The best bet is to pay for one at some point.

<comment><AUTHOR> With txtdrop, I did not see an API on their website. Is there something I am missing here?

<comment><USER8> there is no api per se. You could post to their site programmatically.

</comment></comment></comment><comment><USER9> I usually go with multiple local SMS providers. I've written a simple service that accepts a phone number and a message and then decides which gateway to use based on the country code. I've put a queue in between so that it is easy to quickly push out messages asynchronously. It's less than 1000 lines of Java. Today I would probably hack it together with Python and based on Amazon's Simple Queue service. In even less lines of code :-)

</comment><comment><USER10> I've done a couple sites in the past that used SMS messaging for notifications -- I found the quickest, easiest was to ask the user their provider and send the notification using one of the email->SMS gateways listed above by Elven.

Teleflip is nice. I remember giving them a try a long tim eago, only thing is I remember them inserting their brand into the message. I didn't particularly want that.

Also, speaking of Teleflip... I've heard people speculate how they're able to find the correct provider. Anyone know? Initially sending the message to all providers and then seeing which one doesn't bounce back seems spammy, but who knows. (And I suppose if you then cache the results for future requests, it ain't so bad.)

</comment><comment><USER11> I use a programmable windows CE modem and an actual SIM, and I do inbound as well. I am well-versed in the SMS APIs and market and have worked with a bunch of the vendors. Clickatell is the best I believe for going the API route.

</comment><comment><USER12> This might be an option: <http://smstools.meinemullemaus.de/>

</comment><comment><USER13> You can go old school 1990's.... and ask the person for their carrier, then append the carrier to their 10 digit number, like... email@example.com and it should arrive as a text message.

like this: [http://en.wikipedia.org/wiki/SMS_gateways#Email_to_SMS_.2F_W...](http://en.wikipedia.org/wiki/SMS_gateways#Email_to_SMS_.2F_Web_to_SMS)

</comment><comment><USER14> If you are from India,check out: <http://www.smssolutions.net/smscenters/high/1204/> <http://www.sancharnet.in/BulkSMS/BulkSMS.html>

<comment><AUTHOR> Well, I am Indian, but currently in the US... :D

</comment></comment><comment><USER15> just use textmarks. they offer an api for developers and all messages in/out/unlimited are free</comment>


Why Erlang?  - <AUTHOR> http://smyck.net/2012/04/22/why-erlang/ <comment><USER3> A lot of intros to Erlang miss an important point: Erlang is about _fault tolerance_ , not concurrency. The concurrency is a means to an end -- if your systems has to survive process crashes, hardware failures, and so on, it needs to have multiple components that can supervise and restart each other. Unlike (say) node.js, in Erlang, error handling is priority #1. Its ability to juggle lots of concurrent connections is just a consequence of its priority on localizing errors.

Also, Erlang tries to address many failure cases that other languages/platforms do not; this isn't free. It's often a good trade-off (making systems resilient after the fact can be quite an undertaking), but worth noting.

</comment><comment><USER4> I think this is a great article but misses some of what I think are the most essential points of what makes Erlang great.

Superficially, Erlang is Actor Model for functionalists. I could go on about the various advantages this model provides, but as other posters have so eruditely pointed out, MPI provides the same abstract framework for dealing with the problems that actors are intended to solve.

I'm not a professional erlang developer, but I've based and written a new NoSQL database thats intended to store billions of records in Erlang, altogether clocking in at less than 1000 lines of code, and after this experience, I can safely say that I will never try to build distributed apps, save some niche cases, in another language (even Haskell).

Here's what stands out about Erlang to me, in contract to comparable options.

Firstly, HiPE and BEAM may be the most advanced virtual machine systems in the world. People working with JVM will claim this an exaggeration, but in terms of reliability and speed, my experience with HiPE is unmatched.

Secondly, and perhaps more importantly, OTP.

Open Telephony Platform is the single best collected library for dealing with various problems that I have ever seen. The Generics (gen_server, gen_fsm, etc.) are a quick, fast and easy solution to problems and edge cases that would bog down even the best MPI developer. For example, dealing with internal state as a finite state machine is not new, but it's not nearly as popular as it should be, perhaps to this end it's apt to say that Erlang does for parallelism and distribution what Ruby on Rails did for web development -- It forces you to make intelligent decisions.

The systems responsible for controlling emergency services, global telecom infrastructure, many large MMOs, and countless other applications _are_ Erlang. If you trust 911, you can trust Erlang.

I could go on, Hot code loading while old processes still depend on usable code? Built in failover? Function takeover? Automatic workload offloading? Good luck if it's not Erlang.

<comment><USER5> > Firstly, HiPE and BEAM may be the most advanced virtual machine systems in > the world. People working with JVM will claim this an exaggeration, but in > terms of reliability and speed, my experience with HiPE is unmatched.

Reliability, maybe, but these benchmarks disagree with 'speed':

[http://shootout.alioth.debian.org/u32/which-programming- lang...](http://shootout.alioth.debian.org/u32/which-programming-languages- are-fastest.php)

It's not _bad_ \- it beats a lot of dynamic languages - but it's not great either. Go and Javascript V8 both beat it.

<comment><USER5> Uh, is anything I said here actually inaccurate, or is somebody just downvoting because I said something "bad" about Erlang (which jlouis actually confirms...) ?

I hate this kind of mentality. If you can't look at things honestly, you'll never improve your favorite language(s).

<comment><USER6> I don't think you have said anything wrong, for the record. Go outperforms Erlang, mainly because it is a compiled language. V8 is a JIT-compiler (and it doesn't even interpret per se). In other words, those two systems are usually much faster than the BEAM VM when it comes to raw CPU bound computation.

HiPE does help a lot, but even with HiPE you can't easily beat a language with a static type system like Go: You have much less data to shove around when there are no type tags needed on most data.

</comment></comment></comment></comment><comment><USER7> Can anyone comment on writing erlang style apps in Haskell?

Haskell appears to have many of the required ingredients: Cheap multi threading, immutability and the Cloud Haskell[1] framework, with the added benefits of speed and the awesome type system.

I currently use eventlet and ZeroMQ in python to emulate a similar (and probably crappier) style of writing message passing concurrency apps. With the addition of protocol buffers this type of architecture is easily applicable to a multi language set up. I'd be very interested to see what others are doing.

Has anyone who's used erlang tried playing with Haskell in the same role?

[1] <https://github.com/jepst/CloudHaskell>

<comment><USER6> Yep, see my Combinatorrent and eTorrent projects, respectively. The long story short is here:

[http://jlouisramblings.blogspot.com/2010/04/haskell-vs- erlan...](http://jlouisramblings.blogspot.com/2010/04/haskell-vs-erlang-for- bittorent-clients.html)

<comment><USER7> Thanks for the link, I remember reading it a while back. Have you played with the cloud haskell stuff at all? I seems you were able to achieve most of what you wanted with STM channels for combinatorrent - do you think that the presence of cloud haskell might have made any difference?

<comment><USER6> Cloud Haskell came after my work, so I do not know how it fares. I remember that I saw it and thought that there were neat ideas in there.

My guess is that it would simplify the amount of work I had to do in code since CH would subsume many of my lines.

</comment></comment></comment></comment><comment><USER8> What I gather from the slides:

1\. server loads the data from S3 on start (sessions are sticky to a particular server)

2\. user data gets mutated on that server for the lifetime of the session

3\. the data gets written back to S3 on session end

How are failures handled in 2? If a box goes down, do you not only lose the open connections but also any data that has been changed in that session? If these are game sessions it seems like they'll be long-lived; do you periodically dump back to S3?

</comment><comment><USER9> I've been curious about this for a while: If you can do concurrent processing so easily by message passing, why not just write Java or C++ that just passes messages around instead of sharing state? That way you don't have to learn a whole new programming language to do it.

<comment><USER10> You can do that, but as far as I know Erlang (not far, mind you) it takes care of a ton of details for you. For instance to send a message to another actor, whether they are on you machine or a remote machine you just need a PID (process identifier, an Erlang id concept similar to, but not the same as an OS level PID). In C++ you would either need to deal with local/remote differences in message transport (ignoring the non-trivial nature of serializing arbitrary types in C++) or create an abstraction that would do so on your behalf. Second, in Erlang all actors have their own heaps, so their local data is spatially close in memory by definition making actors NUMA/cache friendly (assuming the runtime is "doing it right") heap allocated data passed between actors in C++ wouldn't have that attribute by default (again, you could make it so with some effort, but it certainly isn't free). Third actors in Erlang don't use full OS level threads, so the overhead of spawning say 10k of them is not the overhead of spawning 10k C++ threads (also ignoring that C++ really only acknowledged the existence of threads in C++11). These are a few issues/benefits, but as I said you could do all of this in any language mostly, but in Erlang a lot of the gross/tricky details are already handled for you.

<comment><USER11> In other words, it would require Greenspunning Erlang.

</comment></comment></comment><comment><USER12> On a related note, I have heard of quite a few game companies that are using Go for their server side code.

<comment><USER13> That's quite interesting. I'd like to know what kind of games. Care to name names?

<comment><USER14> The server code for AirMech by Carbon Games is written in Go: see <http://carbongames.com/> Basically, a modern Herzog Zwei.

</comment></comment></comment><comment><USER15> I'm curious to know what type of CPU & Memory utilization there was on the ruby backends vs the erlang backends between the two games

<comment><USER16> He states that the Erlang server only needed a single box vs. the 80-200 for the Ruby; I'd wager the Erlang is dramatically lower in terms of resources consumed (or at least much more efficient)

</comment></comment><comment><USER17> In lthread, a coroutine lib, (<http://github.com/halayli/lthread>) you can make blocking calls inside coroutines. It gives you the lightness of event- driven, the advantages of threads, and the simplicity of sequential statements. And it can scale over cores.

<comment><USER18> Remember, Erlang scales between machines.

Erlang's actually all about reliability. It's the secret decoder ring to its design, not the actor model or message passing, which serve as the ways it gets to reliability. (Even to some extent its syntax. Excepting comma-period- semicolon which is just dumb.) And one of the principles of Erlang is that you don't have reliability when you are running on only one set of computer hardware.

<comment><USER17> lthread allows you to do so by message passing.

</comment></comment></comment><comment><USER19> Frankly, I'm surprised (but I shouldn't be) that so many people are desperate for an alternative to Erlang. Going so far as to try to pretend that libraries bolted on to other languages give you the same thing at lower cost. This is impossible, and you'd understand that if you understood what erlang does.

Stop that, right now. You're supposed to be hackers. New technology isn't supposed to scare you this much.

Erlang doesn't use the C style syntax. BIG WHOOP. Yeah, it looks "weird" at first but don't be scared off by it.

You can't get the fault tolerance (and consequential scalability) of erlang in any other language/platform. Period. Full Stop. It simply doesn't exist.

Yeah, theoretically, one could build it with some low level language like C. You whipping up crappy C++ code using an "actor" library is not the same thing, by a long shot.

So, unless you want to spend 20 years reinventing the wheel, why not just use the wheel. Yeah, I know its round and you're used to square.

I promise you that you'll really enjoy the much smoother ride.

Don't be a blub programmer. Learning erlang takes you about 2 weeks. The syntax is perfectly fathomable once you put in those two weeks.

But be serious about it. Do a chapter each night from the armstrong book.

This really is one of those languages that separates the hackers from the hacks. Not because its difficult, but because the hackers are not scared of it, while the hacks are.

Seriously. Stop rationalizing.

<comment><USER20> While I wouldn't disagree with your points, I think you've chosen a fairly narrow view of reasons people might want an alternative to erlang.

An obvious case you've omitted, is that people already have existing codebases written in other languages, and rewriting them all in erlang is not an option. Attaching an actor library to "X" language can give us many of the features offered by erlang with our existing codebase, and allow us to continue using our existing skills and paradigms.

Erlang does an excellent job at solving certain issues, but it's lacking in many other areas that "X" might do a better job of. If my project needs both the fault tolerance and concurrency of erlang, and feature "A" which language "X" is good at, but erlang not so good at, then choosing erlang all the time might not be the right solution.

I'm personally a fan of polyglot programming. We should pick the most suitable languages for each task, then we wouldn't need to keep re-inventing programming languages and libraries to emulate other languages. It's quite an idealistic view, but there's certainly ways we can improve the interoperability between languages, including erlang's - which is quite limited so far.

An example of such approach is the (now discontinued) Axum project from Microsoft Research. It offered many of the ideas of Erlang, but built onto the .NET framework and largely compatible with existing code. Axum could call, and could even contain almost any C# code inside it, although it was a restricted version of C# which had isolated states, and no static variables - <USER2> that high standard codebases omit anyway, regardless of the whether language allows it, because it's been known good practice for a long time that shared state causes problems.

The Actor Model existed long before Erlang, and will feature in many other languages other than it - whether or not they are successful is a different matter, but programming language designers would be wise to have a good knowledge of Erlang, and many other languages, so they're not re-inventing the wheel badly. Concurrency and fault tolerance should be considered from the start.

I personally think we can do better than Erlang - or at least offer the same without sacrificing every other paradigm to achieve the aims of erlang. (And Haskell will probably be the language to better it).

<comment><USER3> Since when do you have to rewrite everything in Erlang? Erlang is happy to call out to code in C (or whatever) via ports, which are a way for Erlang to run untrusted code in isolation and restart it when it crashes. Unlike (say) Ruby or Python, buggy C libraries can't bring the whole system down in Erlang.

</comment></comment></comment><comment><USER21> Erlang is indeed impressive. But there is a big learning curve (at least for me!) and a whole new tool-set to support. It would be great if a Ruby/ZeroMQ based framework modelled on Erlang became widely adopted.

<comment><USER22> Most of the learning curve really is OTP. And as with Cocoa, the only way to skip those is to reinvent them, or not even reach an understanding of the problem they're solving.

I'd expect an equivalent toolset on a different platform to have an equivalent learning curve if it existed at all.</comment></comment>


GPLGPU Walkthrough - <AUTHOR> http://latchup.blogspot.com/2016/07/gplgpu-walkthrough.html <comment><USER2> I had a laugh at the mention of the Number Nine Revolution IV graphics card.

Back when the SGI 1600SW monitor came out, I had more disposable income than common sense. I ended up buying two of them and the accompanying RevIV-FP graphics cards. They were they very best in LCD screens with a digital display connection (OpenLDI, which sadly never caught on), and continued to be so for years afterwards.

I continued using them for a long time in a dual-head setup, until support for the Nine RevIV-FP graphic card in XFree86 evaporated. By that time, monitors with DVI input were _finally_ becoming widely available.

The uptake of digital display connections was frustratingly slow in the early 2000's. I had tried a couple different VGA LCD screens around the turn of the millennia, but I was disappointed with image quality of the digital->analog->digital conversion, which has since improved a lot.

Those 1600SW monitors were very expensive, but running them as long as I did, I suppose I got my money's worth out of them.

Actually... I think they're still in the basement somewhere...

<comment><USER3> Gosh, super cool. Can I collect them off of you cheap? :-) Being an old SGI fan, I have been collecting them over the years and donating to e.g. Computer History Museum. Dan Evanicky is one of the main folks who worked on it, and I've been in touch with him over the years about the history of it all. PDF at [http://goo.gl/T4YNYZ](http://goo.gl/T4YNYZ)

<comment><USER2> Maybe... I'll have to see if I've actually still got them.</comment></comment></comment>