6 ms·

I honestly don't see a problem here. They decided to change a backend library for a non-essential system in their product. Most services don't ask for permissio

I honestly don't see a problem here. They decided to change a backend library for a non-essential system in their product. Most services don't ask for permission or make announcements when they make changes like this. The approach seemed to be, if things break, people will report it and we’ll fix it. While this may not be the best approach, the number of languages supported is too high for a person to check each one manually. Generally, I imagine they wouldn't expect a change like this to break anything significant. [people] use it as a portfolio. [..] To suddenly doink the appearance of people’s portfolios is unfortunate. It is very unlikely that syntax highlighting errors in GitHub will affect someone's chances of getting a job. Sure, this switch could cause some issues but they don't seem to be severe enough to kick up a fuss over.

Demiurge 12y ago
> It is very unlikely that syntax highlighting errors in GitHub will affect someone's chances of getting a job. And if it does, the problem lies not with the syntax highlighting, not even close...
conradev 12y ago
One other thing to note is that it's not just syntax highlighting, it's also recognizing the language a given repository is written in. Some of my repositories that use Logos[1] are now incorrectly classified as a combination of Ruby and Scala[2]. [1] http://iphonedevwiki.net/index.php/Logos http://iphonedevwiki.net/index.php/Logos [2] https://github.com/conradev/Tweaks https://github.com/conradev/Tweaks
- lelandbatey 12y ago
  Yep. And now Github thinks my Makefile is JavaScript: https://github.com/lelandbatey/link_grab https://github.com/lelandbatey/link_grab
  - lbearl 12y ago
    It comes up as an "Executable File" for me. Guess they are making tweaks still.
    - sitkack 12y ago
      Sounds like amateur hour.
muyuu 12y ago
Also, not a great idea to rely on some "cloud" 3rd party service to host your portfolio IMO - at least not exclusively. Maybe I'm old-fashioned. That said, I don't think anyone will bin a candidate because Github didn't highlight his or her code properly.
- regularfry 12y ago
  It's not that people necessarily choose to host portfolios on github, but more that employers will treat whatever's on there under your name as a portfolio regardless.
Argorak 12y ago
I beg to differ. Github pushes its code rendering as far as possible, including providing widgets to embed code snippets into you blog. It is also the _main content they display all the time_. That's not "non-essential". Just switching the library and breaking things at a whim is problematic. Also, the number of languages may be 316 (including some oddballs like "Unified Parallel C") but that's still a possible number to check for at least for major, obvious breakages. Still, for people that do use Unified Parallel C, adequate highlighting might just be the reason to choose that platform and use it to write your blog in, instead of writing a custom highlighter for prism.js. Sorry, if you business is code and you decide to support 316 languages, expect people to hold you on that promise. That said, also: errors happen. But that isn't a reason to give them a pass, just not to put too much weight on such things. It doesn't break the platform at large, but terribly inconveniences some users, and they are very right in being upset, too.
- tomcorrigan 12y ago
  > expect people to hold you on that promise What promise did github make?
  - Argorak 12y ago
    The promise any service makes. To solve my problems and to work _as a service_ for me.
    - resetti 12y ago
      That's neither how promises nor the laws around them work. GitHub owes you nothing except what was explicitly spelled out when you signed up. Half the difficulty of running a business comes from customers with a sense of entitlement not understanding this.
      - darkarmani 12y ago
        > Half the difficulty of running a business comes from customers with a sense of entitlement not understanding this. I'm not sure you understand the network effect and how that ties into Github's business.
greghendershott 12y ago
I didn't expect my blog post to be on the front page of HN. Here's a TL;DR summary: For many languages this is a significant and distracting degradation in the presentation. I could understand GitHub removing highlighting completely because they feel speed is the overriding priority. That would be even faster than what they're doing now. Languages would look "plain" instead of "wrong". Not my first choice, but a reasonable choice. The situation now is that they've replaced a library that had been handling highlighting thoroughly, with a variety of text-editor lexers that mostly are not. People like me who already contributed to Pygments, aren't feeling motivated to do this all over again for no good reason. So it seems likely the lexers will remain poor for quite a long time. Which is unfortunate. Finally, at the time I wrote my blog post, I was speculating about the motivation because GitHub hadn't explained why, yet. Someone later did explain ("because speed") in the issue thread.
- res0nat0r 12y ago
  Are the majority of languages now broken, or just a small niche subset that don't see much use vs. ruby, python, etc? If a few minor languages hardly anyone uses as compared to the whole site might need some fixing, this still seems like a win from Github's side of things since per the graph the change did in fact significantly improve render times.
  - Tombone5 12y ago
    The rule of thumb is that most languages are rarely used (since there are a finite number of users), so if you support only the most used languages you necessarily drop support for most languages. Then depending on exactly how popular a language must be to be supported you could end up breaking language support for quite a lot of them.
  - soegaard 12y ago
    Github now uses the lexer framework from TextMate and SublimeText. If your language community happens to use those editors, then you are fine. For Racket 99% uses either DrRacket or Emacs. This implies that the lexer deployed is very rudimentary. Any pointers besides the TextMate documentation for writing lexers are welcome.

Demiurge 12y ago

> It is very unlikely that syntax highlighting errors in GitHub will affect someone's chances of getting a job. And if it does, the problem lies not with the syntax highlighting, not even close...

conradev 12y ago

One other thing to note is that it's not just syntax highlighting, it's also recognizing the language a given repository is written in. Some of my repositories that use Logos[1] are now incorrectly classified as a combination of Ruby and Scala[2]. [1] http://iphonedevwiki.net/index.php/Logos http://iphonedevwiki.net/index.php/Logos [2] https://github.com/conradev/Tweaks https://github.com/conradev/Tweaks

lelandbatey 12y ago
Yep. And now Github thinks my Makefile is JavaScript: https://github.com/lelandbatey/link_grab https://github.com/lelandbatey/link_grab
- lbearl 12y ago
  It comes up as an "Executable File" for me. Guess they are making tweaks still.
  - sitkack 12y ago
    Sounds like amateur hour.

muyuu 12y ago

Also, not a great idea to rely on some "cloud" 3rd party service to host your portfolio IMO - at least not exclusively. Maybe I'm old-fashioned. That said, I don't think anyone will bin a candidate because Github didn't highlight his or her code properly.

regularfry 12y ago
It's not that people necessarily choose to host portfolios on github, but more that employers will treat whatever's on there under your name as a portfolio regardless.

Argorak 12y ago

I beg to differ. Github pushes its code rendering as far as possible, including providing widgets to embed code snippets into you blog. It is also the _main content they display all the time_. That's not "non-essential". Just switching the library and breaking things at a whim is problematic. Also, the number of languages may be 316 (including some oddballs like "Unified Parallel C") but that's still a possible number to check for at least for major, obvious breakages. Still, for people that do use Unified Parallel C, adequate highlighting might just be the reason to choose that platform and use it to write your blog in, instead of writing a custom highlighter for prism.js. Sorry, if you business is code and you decide to support 316 languages, expect people to hold you on that promise. That said, also: errors happen. But that isn't a reason to give them a pass, just not to put too much weight on such things. It doesn't break the platform at large, but terribly inconveniences some users, and they are very right in being upset, too.

tomcorrigan 12y ago
> expect people to hold you on that promise What promise did github make?
- Argorak 12y ago
  The promise any service makes. To solve my problems and to work _as a service_ for me.
  - resetti 12y ago
    That's neither how promises nor the laws around them work. GitHub owes you nothing except what was explicitly spelled out when you signed up. Half the difficulty of running a business comes from customers with a sense of entitlement not understanding this.
    - darkarmani 12y ago
      > Half the difficulty of running a business comes from customers with a sense of entitlement not understanding this. I'm not sure you understand the network effect and how that ties into Github's business.

greghendershott 12y ago

I didn't expect my blog post to be on the front page of HN. Here's a TL;DR summary: For many languages this is a significant and distracting degradation in the presentation. I could understand GitHub removing highlighting completely because they feel speed is the overriding priority. That would be even faster than what they're doing now. Languages would look "plain" instead of "wrong". Not my first choice, but a reasonable choice. The situation now is that they've replaced a library that had been handling highlighting thoroughly, with a variety of text-editor lexers that mostly are not. People like me who already contributed to Pygments, aren't feeling motivated to do this all over again for no good reason. So it seems likely the lexers will remain poor for quite a long time. Which is unfortunate. Finally, at the time I wrote my blog post, I was speculating about the motivation because GitHub hadn't explained why, yet. Someone later did explain ("because speed") in the issue thread.

res0nat0r 12y ago
Are the majority of languages now broken, or just a small niche subset that don't see much use vs. ruby, python, etc? If a few minor languages hardly anyone uses as compared to the whole site might need some fixing, this still seems like a win from Github's side of things since per the graph the change did in fact significantly improve render times.
- Tombone5 12y ago
  The rule of thumb is that most languages are rarely used (since there are a finite number of users), so if you support only the most used languages you necessarily drop support for most languages. Then depending on exactly how popular a language must be to be supported you could end up breaking language support for quite a lot of them.
- soegaard 12y ago
  Github now uses the lexer framework from TextMate and SublimeText. If your language community happens to use those editors, then you are fine. For Racket 99% uses either DrRacket or Emacs. This implies that the lexer deployed is very rudimentary. Any pointers besides the TextMate documentation for writing lexers are welcome.