Macros in Haskell - <AUTHOR> http://playingwithpointers.com/archives/615 <comment><USER2> This is cool, but I think it's a necessity when using macros that the macro code itself be readable. Otherwise, it's very hard for someone else (or yourself later) to come along and figure out what the hell is going on. Although that runQ utility looked nice, its output, even when indented, is quite complex. Sure, I can figure it out, but I can't look at it and guess what it's going to do like, say, with quasi-quoting.

I mean, it might even be clearer-looking to output strings. Not saying that outputting string programs is good, but it is a good lower limit for how complex the code for your macro system can be in order for it to be useful.

<comment><USER3> A chunk of Haskell syntax is directly available:

      $ ghci -XTemplateHaskell
      > :m + Language.Haskell.TH
      > d <- runQ . return $ FunD (mkName "f") [Clause [VarP $ mkName "x"] (NormalB (LitE (IntegerL 5))) []]
      > [d] <- runQ [d| f x = 5 |]

The two last lines define the same `d` AST.

I have written some TH lately, and while being boring, you can write the first line as easily as the second one.

A nice thing to do when writing your TH code is to use runIO and pprint to display the generated code as it is spliced.

<comment><AUTHOR> This (the second) way of doing things looks much more sensible -- thanks!

</comment></comment></comment><comment><USER4> I'm still a TH newbie, but i collected a couple of tricks for working with TH interactively in GHCi on my blog:

[http://coder.bsimmons.name/blog/2010/12/working-with- templat...](http://coder.bsimmons.name/blog/2010/12/working-with-template- haskell-in-ghci/)

</comment><comment><USER5> I love TH (though not as much as metalua and metaocaml), but I've never had the occasion to use it. I've used a library that uses TH to parse out my prop_foo into a main method that will run all the quickcheck tests, but that's about it.

Is there any particularly well-done TH being used somewhere in the real world? (You don't have to show me the code, just what problem you had that TH solved.)

<comment><USER6> My favorite is the MessagePack serialization protocol. The Haskell implementation (officially supported, yay) uses Template Haskell to derive serialization and deserialization code, with full type-checking, for arbitrary data structures. Check it out:

[https://github.com/msgpack/msgpack/blob/master/haskell/test/...](https://github.com/msgpack/msgpack/blob/master/haskell/test/UserData.hs)

</comment></comment><comment><USER7> "Haskell too has macros. The subsystem is called Template Haskell. It is a Lisp-like AST generation framework that comes as a GHC extension"

I'm only reminded of this quotation:

 _"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."

– Brian W. Kernighan_

</comment><comment><USER8> Since macros are fundamentally just a poor man's higher order functions, Haskell really shouldn't need them.

For example, two major uses of macros in Lisp are with-macros and embedded DSLs. You don't need macros for either of those in Haskell, because first- class functions have you covered.

<comment><USER9> Haskell does not support unboundedly highly kinded types (or whatever it is called).

There is no direct way in base Haskell to declare all of 1- to 10-tuples with a single type declaration in a map or loop, for example. Template Haskell can do this, though.</comment></comment>


Microsoft's tablet - <AUTHOR> http://gizmodo.com/5365299/courier-first-details-of-microsofts-secret-tablet#

<comment><USER2> This should not be here because:

a) it's not a product

b) it's not even a prototype

c) it's from last September (and thus is not news)

d) nothing has been heard since (it's dead)

e) it's resurrected every time there is buzz about an Apple tablet - wonder if MS's PR has anything to do with it.

<comment><USER3> first sentence of the article: _Courier is a real device, and we've heard that it's in the "late prototype" stage of development._

So It's at _least_ a prototype

<comment><USER2> Yeah, right. Like WinFS, I suppose, or the Windows Vista that got shown at PDC 2003...

</comment></comment></comment><comment><USER4> Editorializing the headline, no thank you. "Microsoft Courier tablet designs leaked" or the original "Courier: First Details of Microsoft's Secret Tablet" would have been better.

From the guidelines:

 _You can make up a new title if you want, but if you put gratuitous editorial spin on it, the editors may rewrite it._

</comment><comment><USER5> If they had an actual prototype, that's what they'd be showing, instead of a mockup, yes?

<comment><USER2> And a non-working mock-up at that.

If we wanted to get fancy, they could call it a "mass simulator". All it does is simulate the device's shape and mass.

When it is not just a CGI model, that is.

</comment></comment><comment><USER6> How old does an article have to be before we can stop calling it "news"? And the corollary: Is there any theoretical limit to the number of times it can it appear on Hacker News before it starts looking a little stale?

</comment><comment><USER7> I still get this odd whiff of Microsoft pulling out the old playbook and doing a "we're working on this too!" FUD maneuver, knowing Apple was working on something similar.

Remember Pen Windows?

<comment><USER8> Microsoft generally are "working on this too" - they're a big company, and spend a lot on research. Hot research topics aren't that hard to spot. Whether it comes to delivering anything commercially is a different matter.

<comment><USER2> Yes, but the coincidence is funny. These imaginary products always appear when some competitor is about to launch something that may threaten Microsoft's mindshare.

BTW, is Project Natal shipping?

<comment><USER8> I would have phrased that as "These research projects always get surfaced when some competitor is about to launch something.." otherwise, yeah, it's about publicity and mindshare.

 _BTW, is Project Natal shipping?_

I don't know, but they are hiring.

<comment><USER2> No... Apple didn't call the Knowledge navigator a research project. This too shouldn't be misrepresented as one.

</comment></comment></comment></comment></comment><comment><USER9> The only question is -- can they also create a user experience to match Apple's. That would basically mean software which should be extremely intuitive, simple, and to the point, where touch features don't feel as an afterthought on a solid OS.

We will have to see whether Windows derivative tablet OS is capable of supporting tablet form better than it does for mobiles/smartphones, to try and match Mac OS's versatility. If it does not, then no matter how good the hardware is, it will still be a number 2.

<comment><USER10> why don't any of the tech journalists gushing over designs seem to grasp this? we already have tablet interfaces that haven't taken off because they suck. they're unintuitive buggy messes. whomever solves this first wins, _regardless_ of the hardware.

<comment><USER2> You do remember the Newton, right?

Or the Momenta?

<comment><USER11> Mentioning the Newton makes me think of how Microsoft still seems obsessed with handwriting/pen interfaces. This may be a generational thing. There seems to be an assumption that the average person finds writing with a pen the most natural way to record information. But I bet there are a lot of us now who spend more time typing on a keyboard than writing with a pen. I found myself surprised, for example, when the user hand-wrote a URL in the browser app to go to a page. Hand-writing a URL is a pretty foreign experience, except in those rare cases when I need to remember a URL and I'm away from a computer (and I can't remember the last time I actually did that).

Your comment also got me Googling for the Simpson's clip that was pretty much the Newton's tombstone. But I found the video introducing the Newton at the bottom of this page more interesting:

[http://technabob.com/blog/2007/07/20/classic-apple-moment- ne...](http://technabob.com/blog/2007/07/20/classic-apple-moment-newton- handwriting-recognition/)

One interesting thing is that it is clear that the Newton was struggling to find a way to move data around before the dawn of the world wide web. You can print! Or fax! At least, you can the next time you are physically next to a device. Or you can "beam" something who happens to be in close proximity. Er, if they also have a Newton.

The fact that literally half of the intro video is devoted to getting the handwriting recognition to work correctly, though, is certainly ominous. It indicates that the hand-writing interface was not as intuitive as they had hoped.

Which brings us back to Microsoft and pens. I wonder if the vision for tablet computing was born out of Gates and his generation's familiarity with hand writing and inherently assuming that the average person is more comfortable with it than keyboards, and not updating those assumptions for the current generation who spend far more time updating their Facebook status on a keyboard than taking notes in class (assuming they don't use a laptop for that, too).

<comment><USER12> "There seems to be an assumption that the average person finds writing with a pen the most natural way to record information."

This is a valid assumption, writing with a pen IS the most natural way for humans to record information, this includes drawing figures(how do you draw sketchs with a keyboard?).

The problem is that machines don't have a brain and find very difficult to decode pen writing, the first that solve this problem will win a lot of fans.

PS: I type very fast, but I don't like the keyboard as much as pen.

<comment><USER13> I am almost completely unable to write anymore. I've been typing for 2/3rds of my life and haven't done any serious pen writing for the last 15 years. I'm sure with some practice I could get used to it but I don't see a need. Keyboards are just more natural to me. I learned to write English and spell via QWERTY. In fact I don't really know how many words I type are spelled. I just know what sequence of key-presses are required to make them. My understanding of grammar is tied to the ability to quickly edit. It's trial & error grammar. Sometimes I have to type something out a few times to determine what is proper grammar or at least passable as a coherent sentence. I've noticed when I do write with a pen my spelling & grammar skills revert to the level they were at when I stopped writing 15 years ago. (significantly worse)

<comment><USER12> OK, that's right. But think for a moment the quantity and quality of the restrictions that needing a keyboard imposes:

-It is a big thing that requires a lot of space. -It is slow to learn. -It makes sound. -Gets dirty. -You can't write with emotions, or tone, nuances are lost.

On a laptop, makes it really difficult to rotate the screen(I'm writing on a rotated laptop right now, if you try it you will be slow at first, but I'm faster this way).

I'm experimenting with my own sound recognition programs and note taking, I thing that is the future. IMHO we will talk with computers, and the children of your children will see keyboards as awkward as they are.

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> As things like the XBOX 360 and the various MS mice show, MS hardware is actually pretty good. They seem to keep hitting failure when the dev an interesting hardware platform and just license it out (list is too long to write here).

They need to just make this themselves.

<comment><USER2> I love the natural keyboards. The mice are decent and the Softcard in my Apple II still boots, but saying the Xbox 360 is creat hardware is ignoring its alarmingly high death rate.

Still, MS hardware is good. Too bad they insist to be a software company.

</comment></comment><comment><USER13> It's an interesting alternative to the more conventional tablets coming out next year. Knowing Microsoft they wouldn't actually release this because it might threaten all the Windows licenses they are selling on net books. They wouldn't want to take the risk of creating a new market when there's a chance another company could come along and do it better on a more or less equal playing ground. If this was any other company I'd be excited about this device but I just don't think Microsoft has what it takes from a business perspective to launch a new class of mobile device.

</comment><comment><USER15> A bit old, no?

<comment><USER2> Well... We have tablets since the early 90's...

<comment><USER15> The article :-)

And nothing new about Courier has come since then.

<comment><USER2> It seems the vapor in the vaporware dispersed.

<comment><USER8> only 3 months later? I'd give it at least another 3 with no news before calling it "an abandoned line of research".

<comment><USER2> They will certainly show something (that will never ship) on CES, trying to steal some of Apple's thunder.

It's not a hard device to fake - just glue two 10-inch tablets with a fake interface and off you go. It would be good enough to show on TV.

If I were Jobs, I would not announce a tablet after CES and watch how that confuses Microsoft PR people.

<comment><USER8> _If I were Jobs, I would not announce a tablet after CES and watch how that confuses Microsoft PR people._

Jobs, on the other hand, probably cares more about his own business than about confusing Microsoft PR.

<comment><USER2> That's why he is Jobs and I am myself ;-)

Apple is in much better hands than mine.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER16> Interesting to see how they were, well let's say inspired, by the Iphone. The pinch thing is the most obvious giveaway.

It's even more interesting to see that they don't get _why_ the Iphone was designed the way it was. It's all about simplicity and form follows function. There's nothing in the iphone's design that doesn't absolutely have to be there. There's no clutter. When you look at the courier it's obvious they haven't grasped this.

<comment><USER11> "It's all about simplicity and form follows function."

In the demo, there were a lot of actions where I did not understand the underlying UI philosophy. Flicking from one application to another (how are the apps spatially related to each other?). Flicking a person's entry onto a todo list to give him access (why doesn't it email it to him, or some other action?). The "pinch" seems to do different things in different contexts, and I'm not sure what ties them together. I get that she was taking photos at one point, but is holding up a book form factor to take a picture going to work ergonomically? And then pressing the button to snap the photo, do you have to balance this open book form factor with just one hand so you can press the button with your other hand?

On the other hand, during the original iPhone demo, I kept thinking "of course!" It was clear that Apple had created an entire, consistent UI philosophy for operating a mobile device with just the fingers on one hand, while holding it in the other.

</comment></comment><comment><USER17> I had to love one of the comments from the article:

 _Glass on glass = Dirt rubbing/scratching madness.

When it's off the screen will look like the back of an iPod Classic._

</comment><comment><USER18> I do not think that a Microsoft product mockup (or one produced by a company working for MS) would use Google Maps.</comment>


Show HN: Hacker News client with story filtering - <AUTHOR> http://diethn.gq/ <comment><USER2> FYI the "Hacker News for Hackers article" link on the github readme is broken, because it's being interpreted as a relative url.

<comment><AUTHOR> Fixed. Thanks

</comment></comment><comment><USER3> Just the other day I was looking for a service like this, or a Firefox Add-on to filter the stories. Kudos!

</comment><comment><USER4> Can't seem to get to page 2 on mobile safari. Requested desktop version but no joy.

<comment><AUTHOR> It only loads top 30. There is no support for additional stories or pages. If you're interested in this, you can create an issue on the github repo for this feature. [http://github.com/francium/hn-diet](http://github.com/francium/hn- diet)

</comment></comment><comment><USER5> Most RSS readers support this already.

</comment><comment><USER6> Anyone has a good filter list to share?

<comment><AUTHOR> What I'm using

      site:snap.com
      site:support.apple.com
      site:aws.amazon.com
      instagram
      site:www.vox.com
      site:theatlantic.com
      site:sciencemag.org
      site:digiday.com
      site:theverge.com
      site:nytimes.com
      site:techcrunch.com
      site:bbc.com
      site:bloomberg.com
      site:zdnet.com
      site:www.theguardian.com
      site:nature.com
      site:www.washingtonpost.com
      site:bbc.co.uk
      site:qz.com
      site:www.economist.com
      site:reuters.com
      site:newyorker.com
      is hiring housing
      market
      bitcoin
      (IOT.*security)|(security.*IOT)
      apple
      iphone

<comment><USER7> Is this a whitelist or blacklist?

<comment><USER8> Blacklist</comment></comment></comment></comment>


Late applicants - <AUTHOR>

When can a late applicant expect to hear for the summer class? <comment><USER2> Towards the end of May.</comment>


Starting Ruby On Rails:  What I Wish I Knew - <AUTHOR> http://betterexplained.com/articles/starting-ruby-on-rails-what-i-wish-i-knew/ <comment><USER2> My rails (not ruby) experience: The deeper you go the more muddled you are; or better: At the end the ratio of rails and your own or third party code is 1:100

The only helpful thing in rails is ActiveRecord, you can also use separately. Distressful is that ruby and rails are by many people considered as the same thing. Those ROR versus PHP versus Java versus whatever-you-want are simply infantile. Please no flame and good luck :)

<comment><USER3> ..Whaaat? Hehe. Sorry but that ratio is way out of whack. There's almost certainly a way to do things the "rails way".

</comment></comment><comment><USER4> It's funny how the article uses parenthesis and brackets as examples of unneccessary 'cruft' that muddles your program's readability, yet to explain a common 'Rails-ism' the author re-introduces both of them into the sample code to make it more readable.

<comment><USER5> I'm the author :)

Yeah, Ruby certainly has some quirks, especially coming from a C/Java background. I think it's similar to seeing i++ for the first time... you need to separate it into "i = i + 1" when explaining it to newcomers.

</comment></comment><comment><USER6> I'd like to add that Netbeans 6 M9 with Ruby support is the best Windows / Linux IDE I've found so far.

Edit: Link: <http://dlc.sun.com/netbeans/download/6.0/milestones/latest/>

<comment><USER7> Have you tried RadRails? I think it was easy for me due to familiarity with eclipse.

</comment></comment><comment><USER8> These are all very valid points, although when I started I didn't have much trouble picking them up quickly. Still, a good resouce for beginners.</comment>


Why Women Volunteer for Tasks That Don't Lead to Promotions - <AUTHOR> https://hbr.org/2018/07/why-women-volunteer-for-tasks-that-dont-lead-to-promotions <comment><USER2> The opposite is overwhelmingly consistent in political organizations. Men are drastically more likely to invest their time in outreach activities that feel almost hopeless and don't support personal advancement, while women generally only show up when there are opportunities for advancement within the organization or very particular issues (usually issues which support women). Men are eager to change that because these are organizations that genuinely want and need visible diversity in order to grow.

<comment><USER3> Are you talking about the Libertarian party?

</comment></comment><comment><USER4> So basically they volunteer on tasks that bear no risks of failure whatsoever and therefore rarely provide a chance of personal growth.

In my book, not getting promoted for volunteering on these tasks is more than fair. No risk, no fun.

</comment><comment><USER5> So the problem seems to be that evaluations and performance reviews are flawed and don't take these tasks into account. Thus making them un-promotable?

<comment><USER4> People do not get promoted for being the Busy Bee, they get promoted when they show that they're capable of fulfilling more demanding tasks than their current role implies.

You're not in school, anymore, stop trying to please the teacher.

<comment><USER5> Well they are doing tasks that no one else wanted to do when the boss asks. That shows that they care more about the company no?

Just because bob takes a chance and makes a lucky 10 mil investment that goes up 100% overnight doesn't mean that he is the right guy to promote even if the numbers in the evaluations say so. That's all I'm trying to say.

<comment><USER4> Again, you don't get promoted for "caring for the company", you get promoted when you show that you can perform more demanding tasks than your current role requires. Be it because you were underestimated when you applied or because you learned a bunch of stuff since then.

Promotion is not a reward for playing nice, it's about getting the maximum possible value out of an employee.

<comment><USER6> I don't think anyone is arguing that playing nice should provide a reward. It's more that some critical tasks are undervalued.

<comment><USER4> Again: A promotion is not a reward, it's an optimization. Regularly performing "critical tasks" that fit your current role only shows that you're exactly where you belong.

<comment><USER7> On a systemic level, however, if no one does these non -promotion worthy tasks, everyone suffers (not an optimization). So, perhaps not changing the rules for promotion, but the system seems to need a change unless we want either everyone refusing these tasks or to require a social group to get them dumped on them.</comment></comment></comment></comment></comment></comment></comment>


Is the Future of Farming Underwater? - <AUTHOR> https://opensource.com/article/19/11/underwater-farming <comment><USER2> I am going to go with NO!

<comment><USER3> FWIW, Greenwave et. al. is one of the areas where I think automation might be more compelling (than in normal terrestrial farming) mostly because you're not (directly) competing with human farm labor.

<comment><USER2> It starts like this: [..]Land-based food production is in crisis, driven by climate change and population increases. We have to grow 70% more food by 2050 in order to accommodate two billion more people on our planet.[..]

Sorry, I remain unimpressed. I can't take anything after that seriously.

<comment><USER3> Immediately after that it settles down and starts talking about Greenwave. FWIW, I think Bren Smith might be on to something and I'd be interested in your take on it in particular, given what you were saying the other day about your background/experience in farming.

<comment><USER2> I am not an ocean farmer. I will try to learn more about it before I comment.

Having said that:

1\. I think this is a good model/whole systems approach.

2\. But it won't feed 'the world'. It's a responsible way to conduct an ocean mining activity.

3\. All Ag is extractive. With field Ag, we surface mine top soil. With ocean Ag, I'd hazard a guess that it's extractive too. It might subscribe to 'leave no trace' or 'do no harm' which is admirable and praise worthy.

4\. Anything that is extractive is not regenerative.

5\. Oceans have a fragile and rich Eco system. I think we make a mistake when we exploit it and imagine that it won't have broader effect.

These are my initial thoughts. I will look more into it.

<comment><USER3> Those are good points. Cheers.</comment></comment></comment></comment></comment></comment>


Sierpinski Triangles in Bitwise Logic - <AUTHOR> http://languagengine.co/blog/sierpinski-triangles-in-bitwise-logic/

<comment><AUTHOR> I put together this little blog post showing how bitwise logic operators secretly have Sierpinski Triangles lurking in them. They also have other interesting patterns too, if you use different operators.</comment>


Cathode: A Vintage Terminal for Mac - <AUTHOR> http://www.secretgeometry.com/apps/cathode/

<comment><USER2> I'm not really sold on the whole idea, but this part is pretty creative

> _Demo Limitations_

> _Cathode is free to use, but the picture will slowly degrade unless you > purchase. Effects like static and flicker will increase over time until you > relaunch the app._

</comment><comment><USER3> I bought this when it first came out. It's a fun trip down nostalgia lane.</comment>


Show HN: Farkle Score Keeper PWA - <AUTHOR> https://farkle-scorer.firebaseapp.com <comment><AUTHOR> I got tired of keeping score using pen and paper. Options on the app store lacked some of the features I wanted, so I made my own app. It's a PWA as I'm not a mobile dev. Figured I'd share for others who may find it useful.</comment>


GM dumps Chevy for Chevrolet - <AUTHOR> http://money.cnn.com/2010/06/10/autos/gm_no_chevy/

<comment><USER2> This is one of those things that your branding expert will tell you is a good thing, but will tick off the people who still buy your products.</comment>


We Tried to Hack Facebook Ads with Pics of Beer. Here's What Happened. - <AUTHOR> http://feefighters.com/blog/we-spent-1951-on-facebook-ads-featuring-beer-heres-what-happened/

<comment><USER2> A little OT, I was scrolling/reading the paragraph "We opted not to do the "likes" because..." and suddenly a black panel slid down and hid the entire paragraph. Clicked on it to dismiss, nothing. Clicked on the page to dismiss, nothing.

I'll have to bookmark this for textbook UX bad practice.

<comment><USER3> I just came back here to write a similar comment. I couldn't believe how intrusive it was to the reading experience. I was so shocked I started playing around with the page to see when it pops up, and never finished reading the article.</comment></comment>


Salvaging the German High Seas Fleet Wrecks of Scapa Flow (2005) - <AUTHOR> https://addiator.blogspot.com/2005/02/forgotten-history-scapa-fl_110823866174264713.html <comment><USER2> I can't imagine what it would be like going through the airlocks into a ship sunken on the sea floor. That has to be creepy at best.</comment>


Parsing a string as a 64-bit integer, somehow - <AUTHOR> http://blogs.msdn.com/b/oldnewthing/archive/2015/06/29/10624284.aspx

<comment><USER2> Why no negative hex?

I'd write something like this:

      long long parseLongSomehow(char *s) {
          if (isspace(s[0])) {
              return parseLongSomehow(s + 1);
          } else if (s[0] == '-') {
              return -parseLongSomehow(s + 1);
          } else if (s[0] == '0' && s[1] == 'x') {
              return strtoull(s + 2, 16);
          } else {
              return strtoull(s, 10);
          }
      }

That doesn't handle negative values smaller than LONG_LONG_MIN gracefully, though. Also doesn't do error handling.

<comment><USER3> Recursion is rarely a good idea, especially when doing something that is intrinsically non-recursive:

        char *v = malloc(100000000);
        memset(v, '-', 99999999);
        v[99999999] = 0;
        parseLongSomehow(v);

What happens?

<comment><USER4> > Recursion is rarely a good idea

Umm, I really disagree. Recursion and tail-call semantics are enough to make it equivalent to iteration, except the state is stored in the calls instead of explicitly outside the loop. What sucks is buggy code that does not handle cases. Depending on how you view functional languages, for instance, you could argue that iteration is necessarily implemented with recursion, and not vice- versa, and that explicit looping is only necessary to serialize it into steps (instructions).

Nonetheless, with both approaches you need to guard against multiple negative signs. Not much to do with recursion. His approach would have been fine if he had a signed? flag.

<comment><USER3> Observe that in this case, the difference between a non-tail call and a tail- call is a single '-'! If the compiler does tail-call optimisation, then the function can consume an unbounded amount of leading spaces, yet a large amount of leading '-' would overflow the stack. If it doesn't, then lots of leading spaces will also overflow. This is not what I'd consider obvious and intuitive behaviour if you were black-box testing this function.

There is a reason why high-reliability coding standards forbid or severely restrict recursion. It's difficult to reason about the resource usage of recursive code, and it also leads to non-obvious failure modes like this.

<comment><USER4> Well, obviously the - is a base case and should be removed from successive recursions.

And I don't think it is difficult to reason about resource usage. Tail-calls are very intuitive. Some languages (e.g. scala) allow you to force a call to be a tail call (or fail with an error).

I suspect that preferring explicit over implicit is why coding standards forbid recursion. However, many algorithms become straight-up awkward when having to manipulate the "call stack" manually: see traversal of graphs.

Finally, what you were really complaining about was the fact that he didn't handle multiple dashes. It has very little to do with recursion, which is just a different way to fold the same semantics you'd still have wrong with an iterative version. It would never overflow the stack because why would you accept unlimited minuses? You're not evaluating an expression, you're parsing a known format and can fail fast.

</comment></comment></comment></comment></comment><comment><USER5> > return (long)ulong.Parse(s);

Why on earth would you do this instead of just letting the underlying library call throw? Note that it will still throw for strings that parse to a value that cant fit into a long/unsigned long.</comment>


Show HN: Traveldays – Simple but beautiful travel diary - <AUTHOR> http://traveldays.com <comment><AUTHOR> I first made traveldays back in 2016, for a company that was offering group tours to China. It was mainly used by their tour guides, to upload photos of the participants to share with their friends and family.

Now with the current Covid situation, they went out of business, and I had some time on my hands to give it a complete overhaul. So I completely changed the front-end and opened up registration to everyone.

The goal is to create a travel diary that looks beautiful and feels personal, for reminiscing and sharing. At the same time I'm trying to make uploading and sharing as frictionless as possible.</comment>


Nvidia's G-Sync: Attempting to Revolutionize Gaming via Smoothness - <AUTHOR> http://www.anandtech.com/show/7436/nvidias-gsync-attempting-to-revolutionize-gaming-via-smoothness <comment><USER2> This looks incredible and I want nVidia to succeed because it's actually been a long time without any game-changing (no pun intended, honest) improvements (evolutionary or revolutionary) in the gaming and graphics market.

That said, I read the article and yet remain confused as to where exactly the G-sync module integrates with the monitor. From what I understand, it the G-sync hardware/firmware will run on a packet level, analyzing in realtime the incoming feed of DisplayPort packets and deciding how much of what goes where and when. Very neat.

The most important question, I believe, is what monitors can this be used with? The text makes it clear that users will be able to mod their own ASUS VG248QE monitors to add on the G-sync card, but that's a very, very specific make and model. Is this technology going to require hardware manufacturers to cooperate with nVidia, or will their cooperation simply make things nicer/easier?

Also, some of us have (in business environments) $1k+ S-IPS 30"\+ monitors — the quality of these monitors is way above that of consumer models like the VG248QE and others. If there is no way to generically mod monitors without onboard DSPs, I could see that hindering adoption.

<comment><USER3> > _Also, some of us have (in business environments) $1k+ S-IPS 30 "\+ monitors > — the quality of these monitors is way above that of consumer models like > the VG248QE and others. If there is no way to generically mod monitors > without onboard DSPs, I could see that hindering adoption._

I think Nvidia is targeting hardcore gamers first and foremost. Most gamers are not gaming at 2560x1600/1440\. Some are, but most aren't.

The most popular monitors by pro gamers right now (Twitch/eSport players and enthusiasts) are 120/144hz 1ms monitors, such as the ASUS VG248QE. Color reproduction isn't as important to pro gamers as smoothness/framerates.

Also hardcore/pro players are dumping lots of money on the most expensive computer rigs, often upgrading to the latest and greatest every generation. They are a very important marketing group for Nvidia.

<comment><USER4> > The most popular monitors by pro gamers right now (Twitch/eSport players and > enthusiasts) are 120/144hz 1ms monitors, such as the ASUS VG248QE.

I wonder if that latency is noticeable to them or this this the same market as the audiophile market that sells gold-plated cables for 100x markup.

<comment><USER5> It's not really about the latency (5ms vs 1ms is negligible), but its about the pixel response to reduce/eliminate ghosting and other artifacts of LCD's persistent pixels. The speed that the pixels can update is proportional to the amount of ghosting. Interestingly enough, it won't eliminate it no matter how fast the pixels update. The real problem with ghosting turned out to be precisely the pixel-persistence. Even more interesting is that someone discovered a hack for the modern 3D monitors like the ASUS mentioned that completely eliminates ghosting: the strobing backlight functionality necessary for 3D completely eliminates ghosting when applied to 2D. I currently have this setup and its exactly like using a CRT. A flat, light, 1920x1080 CRT. It's beautiful.

<comment><USER4> That makes sense, thanks for explaining!

<comment> Tuna-Fish He's actually completely wrong. Persistence is about image quality, and can be mitigated by filtering that hardcore gamers always turn off, because it costs them latency.

Reducing latency isn't about how noticeable it is. Latency can be completely impossible to detect for you but still hurt you.

Input lag is the time between providing some input, such as clicking with your mouse, to getting feedback of this event on the screen. As the clicking will be prompted by things happening on the screen, input lag acts as a command delay to everything that is done. The most interesting feature of latency is that _all latency is additive_. It doesn't matter how fast or slow each part in the system is, none of them can hide latency for one another. Or, even if the game simulation adds 150ms and your stupid wireless mouse adds 15ms, the 2 ms added by the screen still matter just as much.

The second mental leap is that the human controlling the system can also be considered to be just another part in the pipeline adding latency. Consider a twitch shooter, where two players suddenly appear on each other's screens. Who wins depends on who first detects the other guy, successfully aims at him, and pulls the trigger. In essence, it's a contest between the total latency (simulation/cpu + gpu + screen + person + mouse + simulation) of one player against the other player. Since all top tier human players have latencies really close to one another, even minute differences, 2 ms here or there, produce real detectable effects.

<comment><USER5> This is completely wrong. When even the fastest human reaction time is on the order of 200ms, 5ms vs 1ms of monitor input lag has no effect on the outcome. Also consider that 5ms is within the snapshot time that servers run on, so +/\- 5ms is effectively simultaneous to the server on average.

Pixel persistence is not about image quality and cannot be mitigated by anything, except turning off the backlight at an interval in sync with the frame rate you're updating the image. This is how CRTs work, and that's why they had no ghosting effects. The 3D graphics driver hack I mentioned does exactly that for 3D enabled LCD monitors.

<comment><USER6> People can notice input latencies that are many times smaller than their reaction time. 200ms of input latency is going to be noticeable and bothersome to basically everyone for even basic web browsing tasks. Most gamers will notice more than 2-3 frames of latency, and even smaller latencies will be noticed in direct manipulation set-ups like touchscreens and VR goggles where the display has to track 1:1 the user's physical movements.

<comment><USER5> I think you misunderstood my point. In terms of actual advantage, 1ms vs 5ms is negligible, considering the fact that human reaction time is 200ms. So in the case of shooting someone as they popped out from behind a corner, the 200ms reaction time + human variation + variation in network latency + discreet server time, will absolutely dominate the effects.

I definitely agree that small latencies can be noticed, even latencies approaching 5ms (but not 5ms itself--I've seen monitor tests done that showed this).

<comment> Tuna-Fish > I think you misunderstood my point. In terms of actual advantage, 1ms vs 5ms > is negligible, considering the fact that human reaction time is 200ms.

You did not understand the point of my post. The quality that matters is total latency. How long a human takes to react is _completely irrelevant_ to what level of latency has an effect. Whether average human reaction time was 1ms or 1s doesn't matter. All that matters is that your loop is shorter than his, and your reaction time is very near his, so any advantage counts.

> the 200ms reaction time + human variation + variation in network latency + > discreet server time, will absolutely dominate the effects.

Server tick time is the same for everyone. Top level gaming tourneys are held in lans, where the players typically make sure that the network latency from their machine to the server is not any greater than from anyone else. However, none of that matters to the question at hand.

Assume that total latency of the system, including the player, can be approximated by:

Human_reaction_time + network_lag + processing_lag + display_lag

and assume all are normally distributed random around some base value, except display lag, and you have:

(midpoint, standard deviation)

rand(200,20) + rand(20,5) + rand(16,2) + 15

while I have:

rand(200,20) + rand(20,5) + rand(16,2) + 5

The total latency is utterly dominated by the human processing time. Yet if we model this statistically, and assume that lower latency wins, the one with the faster screen wins 63% of time. That's enough of an edge that people pay money for it.

<comment><USER5> No I understood your point, I just don't agree that it results in any _meaningful_ advantage. What you didn't model was the fact that the server does not process packets immediately as they are received. They are buffered and processed in batch during a server tick. If the two packets from different players are not received along a tick boundary, then the server will effectively consider them simultaneous.

And remember, we're considering 1ms vs 5ms, so the difference would be 4ms in this case. I would like to see what percentage an advantage someone has in this setup. Even 63% isn't anything significant considering skill comes down to game knowledge rather than absolute reaction time. People will pay for smaller/bigger numbers, sure. But that doesn't mean there is anything practically significant about it.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> Carmack had some interesting notes on this, a couple being:

\- This would be perfect for games common in emulation where frame rates are capped but vertical sync isn't used. [https://twitter.com/id_aa_carmack/status/391303034745401344](https://twitter.com/id_aa_carmack/status/391303034745401344)

\- This technology will come later to laptop and mobile devices and sadly, he tried to get Apple to do this years ago. [https://twitter.com/id_aa_carmack/status/391303627278925824](https://twitter.com/id_aa_carmack/status/391303627278925824)

<comment><USER8> > and sadly, he tried to get Apple to do this years ago.

As an Apple user, this doesn't really surprise me. Apple has never liked games, although I'm hoping that was a Steve Jobs thing and the company will see the light.

In some ways they are behind on displays. Windows 7 and above supports 'Deep Color' (30-bit or more), but as far as I know Mountain Lion doesn't.

They're were out first with retina though.

It wouldn't surprise me if this doesn't come to OS X any time soon. Too bad.

<comment><USER9> >As an Apple user, this doesn't really surprise me. Apple has never liked games, although I'm hoping that was a Steve Jobs thing and the company will see the light.

But Apple DOES have a thing for responsiveness and smoothness, and latency and smoothness is exaclty what this tech is improving. I think you could make a strong case without mentioning games. Not that you would have to anymore, since games are so popular on these devices...

But an example: I find the animations in IOS 7 look great on 5S but a bit choppy on regular 5. They clearly aren't maintaining 60 FPS on that device and you can see some hitching. This tech is most beneficial at making variable frame rates between 30 and 60 be more smooth so it could be a big help.

</comment></comment></comment><comment><USER10> I used to think my next computer purchase would be whatever was required to drive the first 4k monitor under $2k. But I have seen that I was incorrect. Smoothness is far more important than resolution (to me), so if this technology proves to be useful, I will probably end up purchasing a monitor with this capability and a new computer to go with it.

I really have to applaud the engineers at Nvidia, and whoever else drove this initiative. I thought graphics were slowing down and I wouldn't need to upgrade for a while (it's already been two years). To come up with a product that proves me wrong is both surprising and delightful. Great work from a corporate perspective, great work from a gaming perspective, and great work from an engineering perspective. Just really fantastic all around.

<comment><USER11> I thought 4k was just for large tvs, can you tell a difference over a retina display? Aren't they called retina because that's the most your eye can see?

Genuinely curious, thanks!

<comment><USER12> No. They're called "retina" because the people who name things at Apple are professionally focused on deceiving you. What a surprise.

I've seen lots of articles about this over time, here's one I googled just now:

[http://www.cultofmac.com/173702/why-retina-isnt-enough- featu...](http://www.cultofmac.com/173702/why-retina-isnt-enough-feature/)

Combine this with what jamesaguillar already said, about wanting a larger screen and also wanting high PPI, and why wouldn't you want higher res?

</comment></comment></comment><comment><USER13> Why can't a display behave exactly as bit-mapped memory? That is, you set this pixel in memory, and that pixel changes on the screen, at that time.

That is, like a vector display, but using the LEDs of a flat screen. There's no electron ray scanning over the phosphors as there was in a cathode ray tube.

\--

The LEDs can switch only so fast - but does this latency prevent them from being switched independently?

The LEDs need to stay on for long enough for the human visual system to perceive them (and without flickering etc) - but this could be managed in other ways.

I think the main reason, apart from inertia, is that the larger market for displays is as TVs, where the concept of updating the whole frame (frames per second) is even more entrenched - though, there's no reason why video couldn't be displayed in the same way, it's just pushing out a kind of compression to the display itself. Light from real objects is not emitted one frame at a time.

<comment><USER14> I assume you're talking about LCD? Not too many LED displays around (though the principle is still similar).

While there's no scanning electron beam the electronics on these displays are still optimized for scanning. That is they push a whole bunch of adjacent pixels in every clock cycle. If you try to use those for random access your refresh rate is going to fall dramatically. The problem isn't whether or not each pixel can be switched independently it's how to efficiently address them and move data from the display controller to the display.

(editing with some more info)

If you changed the monitor's protocol to push X, Y, pixel and souped up the on-board electronics your pixel rate would probably fall by an order of magnitude. So your 80Hz display is now an 8Hz display (for full frames). In terms of how each pixel behaves they are independent (each has it's own transistor and capacitor) but the addressing is on a grid. So you can select your row and then set a whole bunch of pixels in this row (for example)...

<comment><USER15> That doesn't seem to agree with [http://www.fujitsu.com/downloads/MICRO/fma/pdf/LCD_Backgroun...](http://www.fujitsu.com/downloads/MICRO/fma/pdf/LCD_Backgrounder.pdf) .

<comment><USER14> What specifically do you have a problem with?

Details will vary between different displays but my point is that due to the pixels being on a grid sequential access is going to be faster. This is not unlike memory.

EDIT: Here's a reference that discusses scanning in a TFT: [http://www.electronicsforu.com//EFYLinux/efyhome/cover/March...](http://www.electronicsforu.com//EFYLinux/efyhome/cover/March2010/TFT- LCD_Mar2010%284%29.pdf)

"The TFT-LCD panel of the AMLCD is scanned sequentially line-by-line from top to bottom. Each line is selected by applying a pulse of +20V to gate line Gn, which turns on the TFTs in that specific row. Rows are deselected by applying –5V to G n-1 and G n+1, which turns off all the TFTs in the deselected rows and then the data signal is applied from the source driver to the pixel electrode. The voltage applied from the source driver, called 'gray-scale voltage,' decides the luminance of the pixel. The storage capacitor (CS) maintains the luminance of the pixel until the next frame signal voltage is applied. In this way, the next line is selected to turn on all the TFTs, then the data signal is fed from the source driver and hence scanning is done."

<comment><USER16> But it's most likely working that way because (analog) displays always worked like that and your display technology needed to be as compatible as possible for CRTs and TFTs.

From my point of view you have not explained why it's not technologically feasible. You're merely describing that the current display tech isn't working that way.. of course not..

<comment><USER14> It's hard to speak about feasibility in absolute terms here. I would disagree that the current tech is the way it is simply because of the history of CRTs (though there's definitely _some_ influence). Displays have evolved to their current technology by optimizing for things like manufacturability, price and performance. Those obviously would come ahead of CRT compatiblity.

The motivation for the gridded layout is clear I think? You have this grid of transistors and you need to address them individually. Being able to drive an entire line and then select the columns is a good and relatively cheap solution. Now you can drive all pixels in one line concurrently if you need to and the performance of a single pixel becomes less of a bottleneck. So the row/col grid structure isn't a result of needing to be compatible with CRTs... Also naturally accessing in sequence allows you to simply send the data and clock down the line. Random access would require either multiplexing the coordinates or widening your bus.

I would imagine it's possible to design a random access LCD. You would need better performing individual pixels, you will almost certainly need more layers and more conductors, you will complicated your interfaces and protocols. So you end up with a more complex and expensive system for practically little benefit. In many applications (games, videos) all pixels change every frame.

Sub-scanning a rectangular portion of the display is maybe a more reasonable target.

</comment></comment></comment></comment></comment></comment><comment><USER17> I'm glad to see others have been working on this. I'd been batting the idea of Hz-less displays around in my head over the past few weeks. I was actually going to write a blog post about the idea, as I was surprised that it seemed to have gone unimplemented.

I don't see much info about _partial_ screen updates. I hope the eventual standardization of this sort of thing in DisplayPort will provide for Hz-less partial screen updates. It would be nice to be able to run a 3D application and a movie at the same time, providing 24 or 30 updates/second for the movie, and a dynamic rate for the 3D application. It also allows for cleaner implementation of 3D applications that aren't running fullscreen. Generally, partial updates seem like a more flexible, more natural evolution of the Hz- less display idea, particularly with "panel self refresh" and "partial frame updates" already in DisplayPort.

The obvious downside is that you've got a classic example of resource contention, this time in the case of bandwidth. If you've got two areas that want to be redrawn at the same time on different parts of the screen, only one (or a portion of one) can be sent at a time. This leads to jitter or (depending on how you decide to deal with it) some other visual problem. But let not the enemy of "good" be "perfect": it's still a very useful feature.

The best half-solution to the bandwidth contention problem (IMO) would be to push all the decision making as to who gets access to the "pipe" to the OS. It can decide which application (if any) gets a jitter-free experience (perhaps with user preference taken into account), it can provide hints to applications about when the pipe will be free, etc. The OS really has to manage it in order to provide a good experience.

<comment><USER18> Me too. I thought about it a bunch when Abrash and Carmack were discussing VR early this year, and while thinking about 48fps movies. Really, I've wanted higher refresh rates ever since the switch to LCDs, and VFR displays would make smooth, high-refresh video much easier.

Since it's unlikely I'll ever be able to get into VFR display tech professionally, for the benefit of anyone working in the industry, here are my thoughts on the subject from February (focused more on video and movies):

      Feb. 21, 2013
      </comment></comment><comment></comment><comment>-

INTRO:

In the modern digital age of LCD, LED, plasma, and DLP displays, there's not much need for refresh rates to be all that high, or even constant. In the days of CRTs it was necessary to have a constantly refreshing signal coming from the video source in order to drive the electron beam across the screen and refresh the image in the phosphors without visible flicker. With film, it was much easier to run projectors and cameras at a constant rate due to their mechanical nature (and probable lack of a standard for indicating when to switch frame rates).

PROPOSAL:

I propose the development of a complete variable frame rate video chain, from camera, through production, encoding and distribution, and an HDMI/DVI-like video interface, to display devices. My primary focus of thought thus far has been on the video interface and display devices.

APPLICATIONS:

Cinema: Recently, The Hobbit was released at 24fps in some theaters, 48fps in others. As more directors want to experiment with 48fps cinema, why not remove the restriction to a fixed frame rate entirely? Initially, with widespread device support, directors and cinematographers could switch between 24fps and 48fps on a scene by scene basis. Eventually though, why not allow the frame rate to be varied continuously on a per-frame basis? Special effect sequences could be presented at 120fps, with either a gradual or an abrupt transition down to 24fps or even lower as desired for emotional or psychological effect. Variable frame rate displays would also allow mixing of NTSC, PAL, and film content without the delay of switching video signal refresh rates or using nasty time stretching or pulldown techniques. Video cameras and encoding systems could be developed that automatically adjust frame rate based on the amount of movement detected (to some extent this already exists in video codecs).

Gaming: Video games would also benefit from variable frame rate displays. No longer would gamers and game developers have to choose between a tear-free but delayed game using vertical sync, and a low-latency experience at high frame rate but with tearing. In a VFR display, the frame would be sent to the display when the game is ready, rather than the other way around. The content should be in control, not the device. This way a game could still remain artifact free if the frame rate drops, without the lag induced by waiting for the vertical blanking region before swapping buffers.

Mobile: Finally, variable frame rate devices could use much less power for signal processing and transmission; this would be especially desirable in battery-powered devices. A tablet running a word processor on an external display only needs to send an update to the screen once or twice per second to flash the cursor, saving the power that would be used for reading from video RAM and driving the display interface.

AREAS OF STUDY:

A very incomplete list of some of the considerations that must be made when developing a VFR technology suite follows:

The clock rate of an individual frame on the video display interface must be determined. Should devices negotiate an optimum clock rate upon connection and use that rate for all frames transmitted? Or should they adjust their pixel clock rate based on the current frame rate? Using the maximum possible pixel clock supported by the devices and the copper (or fiber or RF spectra) connecting them would reduce transmission-induced latency but might increase power consumption slightly.

A signaling method would need to be devised. Should the display interface protocol be verbose, with the video source announcing frame rates or frame times in advance to the display device? Or should the video card just start scanning out pixels whenever it wants to, and the display just has to deal with it?

Buffering techniques in the display would need to be considered. Should the LCD (or other) panel be updated as the pixels come in, or should a full frame be buffered first? How quickly could a buffered frame be shifted into the display panel? Given the fact that gamers can adapt to and extract greater temporal information from a higher framerate signal with tearing on a fixed rate display, there may be some benefit to scanning out the rows of an image as they arrive (the top row would be displayed a full 16ms sooner than it would otherwise).

Software would need a method of informing the video card that it's done drawing a frame. To a large extent this already exists in the form of the buffer swap call, but in a variable refresh rate system, there would be less need for double buffering to prevent artifacts. The application could draw to the scanout framebuffer as it pleases, tell the video card to send a scan to the display, then wait for the video card to notify it that the scan is done. Double buffering would still be used in games and applications that don't want to wait for one frame to finish scanning before drawing the next.

FURTHER THOUGHTS:

It would be interesting to go beyond VFR and create a display standard that can update selected regions of the screen (AKA dirty rectangles). For example, a video card could send a hypothetical "Start Scan" packet to the display device that contains the location and size of the region being updated, then stream raw pixel data that the display device fills into the updated region. For that matter, the updated region needn't be rectangular.

What about variable resolution display updates as well? This seems to make less sense in discrete pixel digital displays, but might find application when displaying low-DPI content in a subset area of a high-DPI/"retina" display.

It seems that a VFR display chain is a lot like double or triple buffering was back in the CRT days, but one of the buffers has been moved into the display device itself.

</comment><comment><USER9> Video of the panel discussion between Carmack, Sweeney, and Johan (lead on EA's Frostbite engine):

[http://www.twitch.tv/linustech/b/471263848?t=2h27m](http://www.twitch.tv/linustech/b/471263848?t=2h27m)

Carmack answered some questions about it on twitter right after as well:

[https://twitter.com/ID_AA_Carmack/with_replies](https://twitter.com/ID_AA_Carmack/with_replies)

<comment><USER19> Thank you for the twitch link!

</comment></comment><comment><AUTHOR> Submitted this a bit earlier with a link to the actual press release, but it never made front page.

[http://www.geforce.com/whats-new/articles/introducing- nvidia...](http://www.geforce.com/whats-new/articles/introducing-nvidia-g- sync-revolutionary-ultra-smooth-stutter-free-gaming)

</comment><comment><USER20> Consider another revolutionary technology from the same company, Optimus. When it first came out, it took a number of years and a public roasting by Linus Torvalds [1] to convince nVidia to officially support it on Linux.

Hopefully, with Valve and increasing numbers of indies supporting Linux, nVidia will learn from their previous mistakes and offer official Linux support for G-Sync from the beginning.

[1] [http://www.phoronix.com/scan.php?page=news_item&px=MTEyMTc](http://www.phoronix.com/scan.php?page=news_item&px=MTEyMTc)

<comment><USER21> Optimus wouldn't have a reason to exist if say Nvidia made their "mid-range" dedicated notebook GPU's to clock at 200 Mhz for "normal use", and then go to 600+ Mhz in games, or other high-end apps.

Of course, perhaps the company that led to the making of Optimus in the first place is Intel, because they started bundling their GPU's and then charging OEM's _more_ for the standalone CPU than from the bundle - and eventually OEM's were like "why not just get both Intel's GPU, and a higher-end Nvidia one?"

If you ask me, I think Intel's move should've been declared anti-competitive from the beginning. There's no way the bundle cost Intel less than the CPU, but they priced it that way because they had a monopoly, and could force OEM's to just accept the deal "or buy the more expensive CPU if they don't like it", which was obviously a non-option option.

</comment></comment><comment><USER22> This is absolutely brilliant. Pushing the clock from software seems like it'd help the issue with syncing the encoded framerate on streaming video to the display, as well. I wonder if the non-uniform refresh of a 60fps and 24fps video on-screen at the same time would look weird.

If they're adding some cpu and a framebuffer on the display, maybe they can start doing some compression for the cable link between GPU and display -- the raw bitrate is proportional to resolution² ✕ color depth ✕ framerate but the information rate doesn't go up nearly as fast as that increases. Even simple, lossless PNG-style compression would be a huge gain on a 240hz/48bit/4k display.

<comment><USER23> The flip side of the coin is that as soon as you're pushing more data than the link can hold, if you encounter incompressible data (say I just generated some recursive high-frequency Perlin noise) - you would start getting stutter and lag.

<comment><USER22> Yeah, it couldn't be perfectly general. You could still keep the decoder simple and just put a little more intelligence on the GPU side to handle quantizing on the time/space/color dimensions appropriately when you try to send a pathological image. Getting the few multiples of compression you'd need to run 4k@48bit 240hz on current interfaces would probably be safe, trying to put HD over a serial cable will probably go less well.

</comment></comment></comment><comment><USER24> This could also be nice for watching simple videos. It's subtle, but on smooth pans, you can see the stuttering of a 24p video on a 60Hz display. If the video player could tell the display to refresh at 47.952Hz (or any other integer multiple) instead, it would clean that right up.

Combine that with morphing frame interpolation, and you could be watching movies at just about exactly the rate your hardware can manage to push them out.

</comment><comment><USER6> It is kind of surprising that CRTs have been dead for so long but we're still driving our displays in pretty much the same fashion, except with reduced blanking intervals. We still treat video connections as constant data-rate streams, when we should be bursting frames to the monitor as soon as they finish rendering and letting the monitor worry about when it will be able to update which part of the screen.

<comment><USER25> That's how it would work with OLED, right? So we should have that in a few years once density and cost catch up to traditional LED-backed LCDs.

<comment><USER6> That's how it _could_ work on any of the common display technologies that don't use a single electron beam tracing across the screen. Active-matrix displays - be they OLED or TFT LCD - don't require that pixels be updated in any particular order or at any specific frequency save for the minimum update frequency that is analogous to DRAM refreshing.

The way we currently send pixel data to monitors is basically optimized to make the monitor's electronics as simple as possible and to minimize the bandwidth used at all times, even if the hardware is capable of communicating at higher speeds. Just simply changing DisplayPort to always send pixel data at the highest speed even when operating at less than the maximum resolution supported by that link would result in a significant reduction in latency, by no longer taking 16ms to send each frame (which almost all monitors fully buffer in order to apply color transformations or scaling). The next step after that would be to allow frames to start on irregular intervals, which is apparently what NVidia's implementing. But it's still all just about how the contents of the GPU's framebuffer are transmitted to the monitor's framebuffer, and is in no way dependent on what kind of technology is downstream of the monitor's framebuffer.

</comment></comment></comment><comment><USER26> Sounds great. But it should be in a standard, keeping this proprietary to nvidia means it will only be available on a limited number of monitors and cross-fingers AMD doesn't do their own version.

Put it in the next HDMI spec (and the rev the spec fast, not another 2 years or so).

</comment><comment><USER27> I'm curious how similar this is to Embedded DisplayPort's panel self refresh feature. It would be neat to be able to run the display at exactly 24 FPS for movies, down lower when staring at code (to save power), and then dial it up to 100+ Hz for scrolling and animations.

</comment><comment><USER28> I've never understood what is so difficult about making software that can generate frames at a fixed rate, and I don't understand this product- I don't understand how having a variable refresh rate would do anything other than harm smoothness, and encourage more bad software.

Maybe someone can clarify this for me, but what is so wrong with writing software that can just meet the frame deadline? Maybe the hardware innovation should be hardware and drivers that helps you do vertical sync more reliably?

<comment><USER29> If your renderer can draw 40fps in the highest density scenes (lots of polygons, particles, and effects) on specific hardware, then that is the most you'll be able to guarantee to that user without sacrificing detail. That will be your "fixed frame rate".

However, in simpler scenes the same renderer is likely to output significantly more frames (even up to thousands) at the same detail level.

So in this scenario, all you're doing by setting a fixed rate is throwing away tons of frames in low density scenes. Most gamers would prefer to have the most fps possible at any given moment, even if it means variability.

The most hardcore gamers I know use 120hz monitors, and machines that can deliver 241fps (120 * 2 + 1) in the highest detail scenes. They then set the engine to cap frames at 241fps which will eliminate tearing, negating the need for this technology. However, their gaming machines cost a LOT, so this would deliver similar results for a much wider range of hardware.

<comment><USER28> If you're generating thousands of frames and throwing them away, you wrote your rendering software wrong. I ask again, what is so impossible about _just_ rendering the 60fps (just a bit under the limit of the rate at which a human is able to perceive any difference), and then not rendering any more? instead of rendering as fast as you can, do the different trade of of always meeting the deadline.

 _sigh_ why am I explaining this again? is it really hard to understand? why?

<comment><USER30> Your question was answered; it has nothing to do with the case where you're "generating thousands of frames and throwing them away". What you want is a rendering engine that will perform at 60fps in the worst case. What engine devs want to write is an engine that can do better (even much much better) than 60fps in the average case, and be allowed to slip in those pathological cases. Gamers want more frames. More frames than is noticeable. They want some slack so that if something totally unrelated to the game ties up the machine, the framerate drop is not noticeable. They want to be able to double it so that they can drive a 3D display but still have the same effective framerate per eye.

Having a consistent 40fps is much worse (for a gamer) than a variable framerate that will dip down to 40fps for 1% (or 10%) of the play time. Having to limit your most complex scene to what can be guaranteed rendered at 60fps is much less appealing to a developer than making sure all the likely scenes can render at 60fps.

<comment><USER28> > Having a consistent 40fps is much worse (for a gamer) than a variable > framerate that will dip down to 40fps for 1%

stuttering animations is better than smooth animations?

Stuttering is better than smooth. gotcha.

> Your question was answered;

for someone who doesn't appear to understand what I'm asking you have a high degree of confidence that I've been answered.

What is so terrible about having a lower complexity budget that guarantees 60fps? What if you had 60 fps no exceptions as a constraint in your hardware and software design, how far could you really go with some creativity? Think about it- is having a complexity ceiling the _only possible_ way to ensure 60fps?

<comment><USER9> >What is so terrible about having a lower complexity budget that guarantees 60fps

>Think about it- is having a complexity ceiling the only possible way to ensure 60fps?

I'm really not following you. Are you asking what is the benefit of this technology when games come out every day at 60fps even now? This technology allows them to get the same fidelity and smoothness on less powerful hardware, with more complicated simulations, and lower latency.

</comment></comment></comment></comment></comment></comment><comment><USER31> This also looks really good for video playback (as in movies). It would avoid stuttering from pulldown. I am quite hyped about this.

</comment><comment><USER32> This holds some potential for media playback as well, since matching display frame-rate to source material is usually necessary to avoid jerky playback (Some people are very sensitive to any kind of micro-stutter while others don't seem to notice). Of course, playback software will have to support it (easy) and it may be a while before HDTV's or projectors include Nvidia's chip, if that even happens at all! However, if it does happen, this will effectively signal the end of adjusting frame-rate on displays. Even simply allowing higher refresh rates than 60 Hz could clear up a lot of problems.

I don't think Displayport has sufficient bandwidth for 4K video at 144 Hz unfortunately. An upgrade on Displayport may be necessary. Given that HDCP has proven to be utterly pointless, one would hope DRM gets the boot. Encrypting and decrypting data at over 20 Gbit/s is probably a PITA when you're aiming for low latency and low cost.

</comment><comment><USER33> What exactly does the extension card do? 1920x1080 24-bit pixels is 6MB, so why does it need 768MB of on-board memory?

<comment><USER34> There are games that can use up 2GB of on-board GPU memory right now, for textures/buffers/etc. It won't be difficult to use up as much as 8 in the near future when panel resolutions get higher - higher panel resolution means a demand for higher resolution textures.

Given this, I'm sure there are things they can do with that onboard memory in the display. Maybe buffer up a half dozen video frames with timing data for smooth high res video playback?

<comment><USER35> But we aren't moving the gpu to the screen.

With it's currently advertised feature set, there is no need for that much ram.

Assuming future-proofing support for 4k monitors with framebuffers in 16bit floating point format, That's still only 48mb per buffer and there is no reason to have more than two buffers in a screen.

<comment><USER36> Maybe they were 256 megabit chips.

</comment></comment></comment></comment><comment><USER37> So is the idea here that the buffer is actually on the monitor now and no longer on the gpu? Is that why there is 3x256MB memory on the controller? Perhaps the gpu just pushes bits across the wire as soon as its ready now? And the monitor is now responsible for maintaining a localize triple buffer mechanism?

<comment><AUTHOR> The idea is that the monitor will only refresh after it is given a frame to render from the graphics card, which makes the monitor sync to the framerate of the graphics card, not the other way around. From what I can tell, this basically means instead of having a fixed refresh rate, the modified monitor now has a variable refresh rate, slaved to the output of the GPU.

<comment><USER37> Right, but a traditional 1920x1080 monitor only needs ~50MB of memory to store a frame of data to flush to the screen. So why introduce 3x256MB of memory on the controller? Unless the idea is to move away from managing frame buffers on the gpu.

</comment></comment></comment><comment><USER38> Am I missing something, or this would make a real difference only if you monitor has a low top refresh rate? If the refresh rate is 144 Hz, like the one they talk about in the article, I wouldn't expect that waiting for vsync will have big impact on the fps.

<comment><USER9> If you running at 144 the frame rate drops to 72 whenever the game can't maintain it. Carmack says when this happens in VR it's like being kicked in the head but they can't disable Vsync because tearing is even worse.

Unless you triple buffer but which adds its own problems, including more latency. But this tech is also about the feel -- even at the 'same' frame rate the subjective impression is of a much smoother game. For obvious reason this can not be captured in a video so it's tricky to sell, they have to show it you in person.

Their slide showing vsync lag:

[http://images.anandtech.com/doci/7432/NVMontreal-097.jpg](http://images.anandtech.com/doci/7432/NVMontreal-097.jpg)

Anand has some of his personal impressions posted already:

[http://www.anandtech.com/show/7436/nvidias-gsync- attempting-...](http://www.anandtech.com/show/7436/nvidias-gsync-attempting- to-revolutionize-gaming-via-smoothness)

"I can't stress enough just how smooth the G-Sync experience was, it's a game changer."

<comment><USER38> 72 FPS looks very high to me, but I never tried VR. Would be curious to see the difference there.

</comment></comment></comment><comment><USER39> Here is a great read about V-Sync and how it tries to fix the disparities in refresh rates:

[http://hardforum.com/showthread.php?t=928593](http://hardforum.com/showthread.php?t=928593)

Contrast it with what G-Sync is trying to achieve.

<comment><USER40> Reading that, it sounds like triple buffering is already a better solution to this problem. It sounds simpler than requiring a specially embedded DSP from Nvidia in your monitor to talk with your Nvidia card (and _only_ with your Nvidia card).

<comment><USER41> Triple buffering does not solve the problem. If your monitor is locked at 60Hz and your rendering can't produce more than, say, 55 frames per second then you're going to have to display the same frame for multiple monitor refresh cycles. The monitor will typically show every rendered frame for 2 refresh cycles, with triple buffering you may be able to occasionally show a frame for just one cycle.

With something like G-Sync you can instead show 55 frames per second.

<comment><USER40> My understanding from nivla's link is that triple buffering does solve the problem. Rather than experiencing the Frequency/N fps drop when the card can't push out enough frames, triple buffering lets the display's framerate stay at the framerate the card is pushing, with the price being VRAM overhead.

But perhaps I'm misunderstanding the problem statement. The link talks merely about fps drops and how triple buffering can permit the display to be more efficient than Frequency/N fps by essentially pipelining the frames over 3 buffers to keep the monitor's framerate at the graphic card's framerate. However, it accomplishes this by having some frames stay for 2 cycles and others for 1. I don't know how noticeable this is. Perhaps it's a perceptible problem, in which case being able to dynamically manipulate the display's refresh rate is a suitable solution. Granted, at the current price range it sounds like a cheaper solution would be to simply buy a newer model graphics card that can maintain an FPS greater than or equal to your monitor's refresh rate. Though of course I'm sure the goal is to drive the price down and it appears they already have display partners lined up to integrate their embedded DSP.

<comment><USER42> Triple-buffering doesn't help that much, and it adds an extra frame of latency, which is really bad.

</comment></comment></comment></comment></comment><comment><USER43> For anyone excited about this, check out [http://www.blurbusters.com/](http://www.blurbusters.com/). It's a blog dedicated to everything-refresh-rate.

</comment><comment><USER44> One thought on this is that this technology, or something related, would be beneficial to Oculus. Carmack already had a comment on it:

      G-Sync won't work on any of the display panels Oculus is considering right now, but it will probably be influencing many future panels.

[https://twitter.com/ID_AA_Carmack/status/391299110344867841](https://twitter.com/ID_AA_Carmack/status/391299110344867841)

</comment><comment><USER45> Any benefit if your game is rendering 120fps and your monitor is doing 120hz? Even though they're the same speed they're not necessarily in sync?

<comment><USER46> Almost no game can render at exactly a target frame rate, and if so it means the game isn't pushing the GPU to the limit. For any graphically awesome game the frame rate will vary and G-Sync should help in that case.

<comment><USER45> Nah, there's plenty of (mostly a bit older) games that my fairly powerful gaming PC can max out on FPS at very high rates.

</comment></comment></comment><comment><USER47> I have been wondering for a while what reason there is for LCD displays to have refresh rates at all. There is nothing to refresh per se. Shouldn't the display just tell the videocard it can handle frames as long as they're at least some ms apart, then the videocard pushes the frames when they are ready, whenever that may be?

It makes way more sense to me than carrying over the limitations of old (CRT) technology.

<comment><USER42> You are correct. The whole reason things are set up this way is historical, compatibility with CRTs.

</comment></comment><comment><USER48> With this, ShadowPlay, and Gamestream, I'm very excited for the near future of gaming. NVIDIA is really streamlining the experience for PC gamers providing amenities like TwitchTV streaming via hardware acceleration.

They're going to make hardware manufacturers that strictly focused on streaming capabilities go out of business.

</comment><comment><USER49> This and Wayland and hopefully I will never ever see a teared or mistimed(stuttering) frame anymore. I can't wait.

</comment><comment><USER21> Will these work with other GPU's? How hard is it to replicate by the competitors? And will all displays have to support 10 different GPU makers for this feature, if there's no standard set?

</comment><comment><USER50> I don't think I like the LCD refresh rate to go anywhere below 60hz. 30 seems like really quite bad, duplicated frame or not.

</comment><comment><USER51> Are my eyes just that bad or is this solving a problem I didn't ever notice exists?

</comment><comment><USER52> Where is my Optimus driver for Linux?</comment>


Chinese Yuan Becomes Official Currency in Zimbabwe - <AUTHOR> http://howafrica.com/breaking-the-chinese-yuan-becomes-official-currency-in-zimbabwe/ <comment><USER2> Not really news [https://www.theguardian.com/world/2015/dec/22/zimbabwe-to- ma...](https://www.theguardian.com/world/2015/dec/22/zimbabwe-to-make-chinese- yuan-legal-currency-after-beijing-cancels-debts)

<comment><USER3> If you look at the links to the other "top articles" on this site, none of them are really news either. Example:"How America Created 'HIV/AIDS' to kill Black People"

</comment></comment><comment><USER4> The guardian reported this in December of 2015. WHy does this say BREAKING?

[https://www.theguardian.com/world/2015/dec/22/zimbabwe-to- ma...](https://www.theguardian.com/world/2015/dec/22/zimbabwe-to-make-chinese- yuan-legal-currency-after-beijing-cancels-debts)

</comment><comment><USER5> Not news. But while we're on the subject, can someone explain why Zimbabwe's Wikipedia page doesn't list the Yuan as its currency?

        United States dollar (official for government),
        South African rand, and many other currenciesa, e.g. Botswana
        pula. Zimbabwe bond coins are used as a proxy for US dollar
        coins. Zimbabwe bond notes are set to be introduced in 2016.

</comment><comment><USER6> Documentary from 2011 on the topic, Empire of Dust: [https://www.youtube.com/watch?v=A0C4_88ub_M](https://www.youtube.com/watch?v=A0C4_88ub_M)

</comment><comment><USER7> Reading the whole article I am not sure if it has been written by a human. Maybe an algorithm or a translation from some other language.

<comment><USER8> It's a decidedly odd website. There's an article at the top titled "Meet Esther Rolle" \-- an actress who died almost 20 years ago.

</comment></comment><comment><USER9> And a Chinese era begins!

Can't think of a more effective way to extend one's colonial reach.

<comment><USER10> Maybe this indeed is the beginning of the end of the current US based hegemony.</comment></comment>


iPhone 5 Benchmarked: The Fastest Smartphone in the Land - <AUTHOR> http://www.pcmag.com/article2/0,2817,2410034,00.asp Apparently, the iPhone 5 seems to be the fastest smartphone guys at PCMag have ever tested. <comment><USER2> Can you imagine any other phone warranting this article? "Recently released phone with new parts faster than previously released phone with older parts."

<comment><USER3> Certainly. Gadget sites have it as headline news every time a new phone is faster than all previous phones. It only happens several times every year. The iPhone 5 will probably be dethroned by the Optimus G in November.

It's big news for gadget sites, but it apparently only warrants 4 upvotes on Hacker News. That feels about right.

</comment></comment><comment><USER4> Interesting…

"Fastest smartphone in the land (even though older hardware beats it on 1/3-1/2 of the metrics, which are not evenly weighted by any stretch)".

Also, Jellybean has widely been shown to be more performant than ICS on the same hardware (S3 included), so one wonders why ICS was used (after all, software that was released yesterday should probably be compared to software released in July, not December last year, before the hardware came out), for a fair comparison, right?

</comment><comment><USER5> Does this speed still matters for people who aren't gamers ? Isn't the experience already "good enough" ?

<comment><USER6> Off the top of my head, it might be relevant to face recognition, or the new real-time (?) panorama stitching, or image processing in scanning apps, or advanced paint apps (properly-smearing finger paint?), or HTML5 apps (say, Google Maps), or Garage Band, guitar amp simulators etc ...

Mostly it's stuff that people only do rarely. But the big exception is the browser -- render time is still something we worry about in desktop browsers, so I bet it'll still mean something for mobile browsers for a while.

<comment><USER7> Gaming and video rendering are another couple that could use more CPU.

</comment></comment></comment><comment><USER8> it's worth mentioning that a samsung galaxy s3 on jellybean (4.1) is A LOT faster than the the s3 running on 4.03 tested here.</comment>


Ask HN: How do I get started in cell phone repair? - <AUTHOR>

I'm a sysadmin at a medium-sized company. Blackberries are VERY popular here; both company-owned and personal phones. There's always something wrong with them, and let's just say I smell an opportunity...
So how do I get started? Any recommended blogs, books or courses? Any obvious caveats and gotchas? Any war stories?
Thanks.
--EDIT-- I should have added that I'm from Jamaica. The carriers do sell Blackberry's, so company owned phones would be under warranty. However, many people acquire their personal pones  from the grey market, or as a gift from someone overseas, so there's no warranty. And I do happen to know of quite a few people who make decent money in phone repair. <comment><USER2> Serious question, as I've never had a phone repaired. I have a work paid for phone, if my phone were to stop working I would call Apple and either have a new one shipped to me or go and pick one up (probably go pick it up as I'd like to get it ASAP) when I previously had a blackberry I would have done the same (substituting Apple for Verizon). Can you (at any level of expertise) fix my phone faster that the carrier/provider can replace it?

</comment><comment><USER3> I'm being quite serious, I'd hesitate to build much of a business around BlackBerry hardware right now.

I think for the most part the users have other options through their carriers for repairs, and/or will use a hardware failure as a reason to upgrade to a new device (newer BB, or other smartphone).

My guess is that you wouldn't make enough long-term to cover your initial investment in random tools and spare parts.

</comment><comment><USER4> Verizon fixes BB's for free and often while you wait (its usually the trackball) so it may be rough waters profit wise.</comment>


Two brothers invented an alphabet for their native language, Fulfulde - <AUTHOR> https://news.microsoft.com/stories/people/adlam.html?ocid=lock <comment><USER2> As a Fulani, when I was growing up there weren't any official alphabet. Some people wrote in Arabic, other's in the latin letters using french phonetics and agreed upon combinations for those new sounds. (ie Bhe, dhe, etc.) I only know Fulani orally.

But around 2002, if I remember correctly, Guinean students from the University of Azhar in Egypt, started working on a new alphabet. They agreed on using latin letters for familiar sounds, since most of Fulanis speak french anyway. They added new letters for those particularly Fulani sounds.

I remember being there in a small college bedroom where they were all gathered around the computer. It had a Pentium III and they were excited about a new Pentium 4 machine that someone had donated but they didn't get the chance to install it yet. I don't remember if the two brothers were there since those names are extremely common for Fulani (yes, my name is Ibrahima too).

I was there to get a hair cut, and along the way they told me the computer had issues. All I did was go to windows Registry, and delete the files that automatically started at boot.

The script in this article is new to me, never saw it before. I read books in the one they made in Egypt, since it's easy to pick up. In fact, I think when you take an official test in Fulani, it is written in the script from Egypt.

Either way, I'm excited for this and hopefully I'll get to learn it quick enough to teach my own children.

</comment><comment><USER3> The big point here isn't that these two brothers invented an alphabet — that alone isn't that remarkable — but that it had gained so much acceptance so quickly, and that they are still here to talk to. It sounds like writing in their language in Arabic script is still in a chaotic state where orthographic conventions have not been established, so it's the perfect time for a natively-suited alphabet to come on the scene and take over.

<comment><USER4> The primary problem with Arabic script is that it is an abjad, not an alphabet. It is less suitable for writing a vowel rich language like Fula.

<comment><USER5> Yeah, I consider the arabic alphabet remarkably well adapted for the structure of Arabic but less appropriate for many of its other adapted uses (e.g. Urdu, Farsi).

But almost any alphabet could be made _adequate_. The politics of writing are complex.

</comment></comment></comment><comment><USER6> This is great, I love languages and writing systems. My own heritage is Irish so I can see how language and culture are linked so strongly to writing the words to speak the language of that culture.

It's amazing how dismissive we can be too. A friend of mine who is Mi'kmaq (pronounced mig-maw) a First Nations/Native American was showing me ancient glyph symbols of his language. I had been telling him about languages I liked and that's why he showed me the Mi'kmaq alphabet/syllabary for their writing system. They aren't used Latin letters are used but it shows how even me as a fan of languages assumed First Nations peoples in the Americas did not develop writing systems. [https://www.omniglot.com/writing/mikmaq.htm](https://www.omniglot.com/writing/mikmaq.htm)

I can spend hours looking at Omniglot.com I strongly recommend it.

</comment><comment><USER5> The article doesn't really show the alphabet (their picture has the stroke marks overdrawn so it's hard to see). Here's the unicode page with images of all the characters: [http://www.unicode.org/errata/Adlam-Ebima- chart-2019-05.pdf](http://www.unicode.org/errata/Adlam-Ebima- chart-2019-05.pdf)

</comment><comment><USER7> These guys are the modern-day Sequoyah, who invented the writing system for the Cherokee language in the early 1800's

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

</comment><comment><USER8> "the Fulbhe people never developed a script for their language, instead using Arabic and sometimes Latin characters to write in their native tongue... Many sounds in Fulfulde can't be represented by either alphabet".

That's not really how alphabets work. English is written in the Roman alphabet not because its sounds are particularly well suited to that alphabet, but because it's the alphabet we had.

It sounds like what Fulfulde was lacking was a standard orthography, not an alphabet of its own.

<comment><USER9> My native language is Portuguese. When I learnt the Cyrillic alphabet I realised it would be perfect to have letters for diphthongs in Portuguese. It would simplify and obviate many diacritics.

Take "simpatia" and "ânsia". In the first case, the last "ia" is not a diphthong. In the second it is and you need the diacritic over the a to make it the tonic syllable (Spanish is more clever in that the general case is that the "ia" ending is taken to be a diphthong unless you put an acute sign over the i - ía).

But, when diving further into Russian, I soon found out that they do weird things like pronouncing a G as a V (его - his).

So, my conclusion is that even if you have the perfect alphabet, it will soon become obsolete.

<comment><USER10> It's grammar, not alphabet. Weird things are dialects and simplified forms. You can still say "ego" as it's written and that will be correct. Eventually the language grammar will allow writing "evo" (Alphabet will stay relevant)

<comment><USER11> No, it will not be correct, but of course you will be understood, no problem. I had a friend that pronounced these words with г for ironical purposes.

<comment><USER10> The modern pronunciation of "g" as "v" in certain words appears not earlier than in XVII century in Moscow dialect of Russian. It eventually spread across the empire and became literary norm, but in the church and in some regions you may still hear old spelling sometimes.

</comment></comment></comment></comment></comment><comment><USER12> The alphabet itself and a sample text on Omniglot: [https://omniglot.com/writing/adlam.htm](https://omniglot.com/writing/adlam.htm)

</comment><comment><USER13> We share the same kind of story in Lebanon. Three friends created not only the alphabet but automated the conjugation using ai. Check the verb conjugation on

[http://www.lebaneselanguage.org](http://www.lebaneselanguage.org)

[http://www.lebaneselanguage.org/language/lebanese-verbs- conj...](http://www.lebaneselanguage.org/language/lebanese-verbs-conjugation/)

</comment><comment><USER14> So what's the actual benefit of this? Maybe there's something I'm missing but couldn't they just use any alphabet that has enough symbols to represent the sounds in their language? What's actually gained from this?

<comment><USER10> They had two alphabets which were familiar to them but didn't fit and should be adjusted, probably repurposing some letters for different sounds. Any other alphabet was completely foreign to their culture, would probably require some adjustments too and thus would not bring any benefits besides some existing fonts. As languages would evolve, it would create an incompatible fork anyway. Own alphabet brings 100% compatibility, cultural heritage and reduced cognitive load when learning new languages (ask English speakers how they figure out how Z, S or V should be pronounced in German).

<comment><USER14> >100% compatibility

Again, this could just as well have been achieved by just adapting a different alphabet, so this is not really a benefit to inventing your own alphabet

>cultural heritage

That depends on what you take "cultural heritage" to mean. I don't think inventing something new from scratch actually brings any kind of heritage. It looks like a case of "we just need to have something unique because, uhh, reasons".

>reduced cognitive load when learning new languages

I'm not convinced this is true. You're trading not having to switch mindsets about the sounds when switching languages against not having general familiarity with the alphabet, and I'm not sure which has a bigger impact on cognitive load. I also don't think either of those really has a big impact; the fact that a different language just has different sounds seems to be the main cause of cognitive load here.

All in all I think these are some pretty myopic benefits at best, and do not justify the gradeoff of having to add yet more stuff to unicode, make fonts for this new language, etcetera. I do not think the world needs _yet another_ format to write down sounds.

</comment></comment></comment><comment><USER15> Why not use the phonetic alphabet? Was it not known yet?

<comment><USER16> They developed it as teenagers and had probably never heard of the IPA at that point in their lives.

An IPA encoding may not have spread as well as a unique alphabet designed by two members of the culture it was intended to work with, either. IPA is an ugly mishmash of Latin and Greek characters with assorted flourishes; the further you get from English and various Romance languages, the more you have to use the fiddly mismatched characters; ADLaM is clearly one set of characters designed to harmonize with each other.

</comment></comment><comment><USER17> I hesitate to wade into this, since I have a lot of admiration for these two men, and I am only a mediocre speaker of Pulaar, the western dialect spoken by Fulani, whose eastern dialect is Fulfulde. I have seen several variations of this story making the rounds over the last few years, and it is full of misconceptions about the Fulani communities across the Sahel, and more generally about linguistics (and language politics) of trans-national communities. It is unfortunate that in this particular article Microsoft repeats many of the errors of the Atlantic[1], and the Letterform Archive [2], and adds its own self-congratulatory spin to it.

The first misconception is that Pulaar/Fulfulde is/was rarely written. Despite the experiences of the Barry brothers, the language has been written for hundreds of years. There are manuscripts in Arabic script that attest to this - unfortunately these are generally poorly catalogued, but BU's African Ajami Library lists 25 [3] and the British Library has several collections [4]. There is a strong historical argument that the Fulani were actually the primary instigators of literacy in pre-colonial West Africa, from the 15th and 16th centuries. The practice of writing Pulaar/Fulfulde with Arabic script did without question wane in the 20th c. - particularly among the more educated and urban communities which the Barry brothers come from. This led to decreased standardisation of the language as written in the Arabic script, especially as Fulani communities came to have stronger ties to national identities than to their transnational identity as Fulani. At the same time, the general push for literacy in languages written with Latin script in the region (mostly French and English) led to a loss in language prestige for Pulaar/Fulfulde as it had less utility as a lingua franca, and was not the language of religion, trade or politics, in the way it had been.

By the 1990's, however there was substantial linguistic work done on Pulaar/Fulfulde and a modified Latin alphabet was widely in use in the linguistic and academic community, which is currently seen on almost all Wikipedia articles on the subject. This is marked by 'hooked' letters for plosives, as in Fulɓe, which this Microsoft article writes "Fulbhe." The fact that this was not widely enough known that the Barry brothers came across it before developing a new standard for writing is testament to the fragmentation within the Fulani community, but I think it also reflects the fact that they did not come at the issue from a linguistics background. Nonetheless, this pre-existing writing standard does accurately represent all of the sounds in Pulaar/Fulfulde (and also is not much different from many other African languages in the region written with a Latin alphabet). It also was used for printing a number of books in the early 2000s, and I knew of a handful of companies regularly printing books in Pulaar in Dakar, Senegal (where it is also a minority language). I once picked up an order for 10,000 books printed in Pulaar in 2005, typeset in this commonly accepted script adapted from the Latin Alphabet.

The second major misconception of the article, is that a language needs to have its own script to be accurately represented, or that having its own script enhances the literacy rate of a language. Other comments have touched on this, so I won't dwell, but from a linguistic perspective (or even from a software language perspective) the opposite is more likely to be the case. The answer to the proliferation of different standards should almost never be to create a new standard - especially one that is not at all based on the previous standards (as Adlam is based on neither Arabic or Latin abjads/alphabets). Literacy in Pulaar/Fulfulde is almost certainly better served by doubling down on an existing standard that is accessible to those who most want to access it, rather than a new standard. There are 100-150 million Pulaar/Fulfulde speakers, so even success in the range of thousands of Fulani who recognise Adlam doesn't mean it is likely to overtake the actual pragmatic literacy of those hundreds of millions who already ready on a daily basis in Latin scripts, and could easily recognise the adapted letters.

From a political perspective, there might be a value in a new unifying standard that underscores the uniqueness of Fulɓe from their neighbours in Mauritania to Sudan. But in every one of those countries, the Fulɓe are a minority, and many of their communities are nomadic/transhumant as well, further undermining their ability to integrate or oppose existing political structures. While I applaud Adlam as a commendable assertion of identity, and a valuable potential contribution to the linguistics and typography of West African languages (should it engage constructively with the field), it is politically doomed, and unfortunately lends credence to the dictum that "a language is a dialect with an army."

Pulaar/Fulfulde is an incredibly important language, but it hasn't had an army since the fall of the Empire of Sokoto in 1903 to colonial powers. It has largely been seen as a dialect because of that, despite being one of the most widely spoken in Africa (Swahili is the only other African language with a claim to have more than 100 million native speakers).

[1] [https://www.theatlantic.com/technology/archive/2016/11/the-a...](https://www.theatlantic.com/technology/archive/2016/11/the- alphabet-that-will-save-a-people-from-disappearing/506987/) [2] [https://letterformarchive.org/events/inventing-the-adlam- scr...](https://letterformarchive.org/events/inventing-the-adlam-script- designing-type-for-a-society-in-flux) [3] [https://open.bu.edu/handle/2144/18688](https://open.bu.edu/handle/2144/18688) [4] [https://eap.bl.uk/collection/EAP387-1](https://eap.bl.uk/collection/EAP387-1)</comment>