IMO this niche obsession with cursives, ligatures and stuff in programming fonts actually hurts first impression for a significant percentage of people landing on this README.
Obsession with dark, unreadable text colors are much more destructive to my eyes than cursives. Whoever came up with the idea that blue on black was a good color for displaying code on a screen, or dark green on black was a good idea for comments should just stop using computers together with everyone who installs and uses those themes.
I mean, everyone should be able to use themes that they are comfortable with, right? I don't think there is any evidence for dark themes "destroying" anyones eyes. And even if there was, I think you'd be able to survive looking at a Screenshot for some trendy JS project.
For me, dark themes help reduce eye strain, particularly at night or if I've been staring at the screen for a long while already. But I don't judge others for picking color themes which are comfortable for them. Your screen, your rules.
> Obsession with dark, unreadable text colors are much more destructive to my eyes than cursives.
I disagree. When working at night, even with indoor lighting; pastel colors and lower intensity of darker themes reduce eye-strain significantly. Daily eye-strain takes its toll at night even if you didn't code or use screens during the day.
I personally don't like ligatures as much too but, it's a choice after all. People shall enjoy the work they do, shall customize their working environment to reduce friction as much as possible for them.
This is an extension of desktop customization and I look some of them with awe. I don't spend that much time customizing my coding environment and terminals. I also don't share some of the choices they make but, as I said, environment is a personal thing after all.
> Whoever came up with the idea that blue on black was a good color for displaying code on a screen, or dark green on black was a good idea for comments should just stop using computers together with everyone who installs and uses those themes.
Instead, we can use the themes which we like and suit us best, can't we?
Personally I don't use f.lux however, I think it is a nice piece of technology.
My monitor has a blue blocking filter and I personally keep it enabled 7/24 but, reducing the overall light intensity via dark themes works better for me especially, when coupled with the blue blocking filter of my monitor.
OTOH, it's important to note that I always preferred darker themes on my systems since I started to use computers.
I think it was just a natural consequence of early CGA graphics cards which only allowed combinations of on/off red green and blue components with light and dark variations giving a total of only 16 colors available to work with. If you wanted a colorful enough UI you pretty much had to use all 16
I agree the ligatures are a bad idea, and I use a ligature font in my editor. I quite like ligatures, I find they moderately enhance readability, but you need to know exactly what they are for it to be useful: readability can't come at the cost of precision in a code sample.
I'm actually far less bothered by programming ligatures than cursive font for comments. It just so happens that Operator Mono bundles these unconventional features together, so I kind of lumped them together.
But yeah, using ligatures in code that’s meant to be shared isn’t a great idea.
In the sense I'm using them, readability is the ability to scan as quickly as possible, precision is the ability for someone unfamiliar with the font to be able to reproduce what they see.
I find ligatures more readable because for example I read the => ligature faster than the two-character equivalent. I find it less precise because someone who sees the ligature may not be clear what it's supposed to be (when I first saw a ligature font, I thought it was a unicode character).
⇒, the Unicode symbol, is supported in PureScript and Agda out of the box and is supported in Haskell with UnicodeSyntax extension. Personally, I find the ligatures more confusing than support for the actual Unicode symbols (albeit they can be more cumbersome to type if your editor doesn’t help, i.e. ctrl+k "=>" in Vim). Every time someone uses Fira Code in a presentation someone in the audience always has to ask and now you have to go down a rabbit hole of explaining what ligatures even are.
> albeit they can be more cumbersome to type if your editor doesn’t help, i.e. ctrl+k "=>" in Vim
I wonder why physical keyboards lack unicode support. Virtual keyboards often have great support for this. Older keyboards could also input a lot of symbols:
Could be an issue with agreeing on a standard. But also, the average user would rather have emojis on a keyboard before various math symbols (and, outside work, I'd feel the same).
Readability of programming ligatures is very different for people who are familiar with the language/font, and people who aren't.
For instance, look at the list of ligatures for Fira Code[1] and without referencing the monospace counterparts on the right, tell me if you can tell how to reproduce each one without a lot of guesswork.
I’ve seen actual cursive code fonts (just one, I think. Maybe someone knows which one I’m talking about) and this isn’t it. I’m assuming the stylized terminal/descender (particularly on the “t” and “f”) are probably what are causing it to be described this way.
Edit: I’m blind and didn’t see the comment on the bottom :/ This is the cursive font I’m talking about.
Actually upon closer inspection it seems to be a font that’s very close to Operator Mono Italic but not exactly it... So don’t take my word for it, I guess.
Edit: Okay, it's Dank Mono. Should have checked the font options on the website.
“style of penmanship in which some characters_are_written_joined_together in a flowing manner, generally for the purpose of making writing faster, in contrast to block letters.“
“a sans-serif. (or "gothic") style of writing Latin script in which the letters_are_individual_glyphs, with no joining”
Here, the s and the l look like they are cut out of some cursive text, but even they clearly are individual glyphs. The other letters in this example to me clearly are block letters.
Examples of truly cursive fonts are Lucida Handwriting and Zapfino.
I'm of the opinion that showing window controls (the top left/right buttons) and the window chrome on a code snippet is poor form. The focus of the screenshot is to be the code itself, there is no need to highlight the crud around it which is distracting to users coming from different OSes. It is reminiscent of of various sites that showcase their products on specific phones and laptops. You're wasting valuable space on something that appears dated and cringey just a few months down the line. A well put-together div, font and background will last longer.
> It is reminiscent of of various sites that showcase their products on specific phones and laptops.
This is especially annoying because it implies the user is not part of the software's target audience. The developers use Apple and everyone who doesn't is an afterthought.
> "In 1988, Donald Norman appropriated the term affordances in the context of human–machine interaction to refer to just those action possibilities that are readily perceivable by an actor."
Putting a door handle on a door is an affordance: you can see how to open the door (action).
Putting window controls on something that's not a window and can't be controlled as such is not an affordance: it's misleading. There's no action to be perceived here.
... these code screen caps are inserted into presentations not demos?? As far as I know no audience member expects to walk up to the projector screen and minimize a window. The point is to prime someone's perception for how they should interpret something. Good try being completely literal though.
edit: i can't believe i have to explain this. the window serves exactly the same purpose as offsetting code blocks in text in a different font, in a different color, with a different background: it's to indicate that there's something meta-semantically distinct about this block of text from other blocks of text. to contextualize the code even moreso accomplishes the same goal - implicitly communicating distinction.
> The point is to prime someone's perception for how they should interpret something.
And what perception is that?
The macOS semaphore controls make the square look like a macOS window. Not all windows are text editors: people still have to look at the content of the window in order to understand it. Not all text editing is source code editing: people still have to read the text in order to realize it's source code. The Carbon twitter contains images of error logs and ASCII art.
Monospaced typefaces and syntax highlighting of the text are the design features that truly denote source code. A container with contrasting background color distinguishes the source code from the other elements on the page or slide.
> the window serves exactly the same purpose as offsetting code blocks in text in a different font, in a different color, with a different background: it's to indicate that there's something meta-semantically distinct about this block of text from other blocks of text.
They don't have the same purpose. The information conveyed by all of those elements are completely different. Monospaced, syntax highlighted text looks like source code to any programmer. Placing that text inside a container allows it to be quickly distinguished from the surrounding prose.
Adding macOS controls to this design makes it look like source code that's being edited in macOS. Why convey those additional bits of information? Does the code not work outside of macOS? Are users of other systems not part of the target audience? Is the author subtly signaling their use of macOS to other macOS users in the audience?
You might be off in your understanding of what an affordance is (or I might). A protruding door handle affords to close your hand around it and pull, while a plate or bar cannot easily be pulled and affords pushing only. The horizontality or verticality are more motivated by ergonomics and safety codes.
Regarding Carbon, it's obvious to readers that the image is just that—an image—and that the buttons cannot be interacted in any way and don't afford the reader to perform any action.
At best, it suggests that the content initially lived within an OS window, with some buttons that afforded some interaction. But so does your browser and music player and every other app that have nothing to do with editing source code. The monospaced font, syntax highlighting, and context are more than enough anyway.
IMO it has nothing to do with affording anything and the goal is just to look fancy (which is fine since that's explicitly the goal). Try to picture for a second the same screenshots but with Microsoft Windows-style buttons and it's obvious that nobody would use it since it would look low-rent and clash with the "crafted with <heart_emoji> in San Francisco" footer.
>A protruding door handle affords to close your hand around it and pull
you could easily have a bar across the width of the door that's narrow and protrudes and affords the ability to clasp it. no the real intent is to communicate to you that amount/direction of force that you need to apply; a bar across the width communicates push hard because the door opens away from you while a handle at the edge communicates pull moderately because you have lots of leverage and the door opens towards you (because if it were at the center you would open the door onto yourself).
>But so does your browser and music player and every other app that have nothing to do with editing source code
it is obviously emulating vscode/monaco editor that the maintainer assumes most people are familiar with. like there's literally a vscode extension that produces almost the same exact images
I've been using Carbon more frequently lately in some development documents in my current team.
We have a MediaWiki and, for some reason, the administrator wouldn't be bothered to set up syntax highlighting correctly. So, after asking a number of times, I thought I would just use Carbon and be done with it and have the docs looking a bit nicer.
Immediately, I thought about the issue of having code as images. You put an example in the docs but the developers can't just copy and paste it into their code. But then I realized I actually wanted this. I didn't want them to continue copy&pasting code without understanding a single thing they do, like they have been doing for the last twelve years.
I have it set up to remove the window frame and background, and use Iosevka. It's much less noisy that way.
The corollary of that though is that your code is also not accessible. I've been struggling with this myself, I don't find it fair that my snippets, no matter how beautiful, aren't readable by screen readers.
The only solution I found is to keep providing actual code as a snippet or gist next to the image.
Not saying you're doing any evil :). Those might not be yours to fix, but one could argue that if copy/pasting is such a problem in your current environment there are deeper issues at hand.
Nothing that carbon will fix, and nothing that accessibility will helps with in any case. Good luck!
Accessibility of the code should trump that. Stuff that we like to call 'temporary' inevitably ends up as long-term, and we have no idea what will really happen to it in future.
I’m glad that this gives better results than screenshots of code but, to be honest, a bit saddened that it has to exist at all. Twitter, I get a little: it’s meant for short thoughts and can’t really work well for code, but Medium (for example) not supporting code is hard to understand.
AFAIK, Medium does support embedded Gists from GitHub etc. At least it did when I last wrote a programming guide in it.
Update: Still seems that it does (scroll down) [0]
Edit: Oops, I just remembered that HackerNoon moved off Medium to their own CMS, but those Gists did used to work on Medium too, complete with code formatting.
Supporting embedded gists is hardly "supporting code". We're talking about fetching one additional iframe plus a third party script per code blob, for what should be inline HTML plus ~30 lines of CSS (check out pandoc rendered HTML with syntax highlighting, for instance). The page you linked also demonstrates visually broken embeds with extraneous white space on the bottom; hardly a glowing endorsement.
I get embedding Codepens and stuff for rendered code. Embedding gists for static, verbatim code is just sad. (Not saying it doesn't have its uses, but having to use it is another matter.)
But this is far from the most annoying thing about Medium, so meh.
Medium does support code, without highlighting though and only accessible through unobvious keys:
To begin a code block, go to a new line and type ``` (triple backtick).
For inline code in a paragraph, type a single backtick ` to begin and end your code.
Or highlight some text and press the backtick key.
So an unfortunate reality of the world today is that sometimes you need an image for a post that doesn't need a photograph, if only for better exposure with embeds. This is great for that. It's also great for posting code on Twitter.
I see a lot of people complaining about not being able to copy-paste code. That's a legitimate issue. As chrisma0 pointed out, the URLs can have a one-to-one correspondence with gists, so in blog posts you can just link directly to gists with little loss of convenience. Also note that it seems to use Twitter's alt text correctly at least.
An even better option would be to use a steganographic technique like pico-8 carts do to embed the text and then use an extension (or oembed or something) to surface that where appropriate.
I have created a similar tool https://codekeep.io/screenshot, which has pre made templates for code screenshot , for eg: notes - where you have description , title and code, good/evil - which can be used to distinguish between good and bad coding practices, and it can be used along with the service of codekeep, you can store your snippets on codekeep and instantly create screenshot from it.
a short description of codekeep below,
️ CodeKeep, Combining features from Google Keep to better organise your code snippets by tagging them with labels and categorising into folders.Tagline: Organize , Discover and Share Code Snippets. https://codekeep.io
let me know your thought
This is _very_ cool. You should make it more obvious that you match the background colour automatically, I don't think I would've even tried it if I hadn't seen that comment on twitter.
Thanks for the suggestion! I'll add it to the page!
Now that I think about it I should probably have some example or something to see what it's about because I am realising it's not really clear when you open the page
I don't use Carbon, but I would say I endorse using images to help prevent copy/pasting of source code. My last research paper [1] studied the results from students that completed optional typing exercises while learning Java. In summary, students labeled as "Completers" of typing exercises earned higher final course grades, "Completers" that also scored below the median on their first exam showed the highest learning gains on their final exam, and practicing typing exercises reduced the number of build failures these students saw in programming programs.
If you are looking for other methods for creating images, you can always go simple screenshotting. For my research, I use a combination of Dom-to-image [2] and CodeMirror [3] so that I can generate images from the CodeMirror interface which students also use to retype the code.
Is there a good free equivalent of SF Mono with which I could use this? I believe the license for SF Mono restricts usage to non commercial iOS / macOS work.
It’s my favourite typeface for code by far. I enjoy the sort of 1980s “Unix Manual” width of it. Sort of like the writing on architecture plans, which in the last would have been drawn by a plotter.
The face in Carbon is close but had too many distracting letter forms for presenting content.
I like Menlo as a fallback; it’s fairly clean and not particularly flashy. I’ll admit I haven’t looked at the licensing for it though; I know it ships with macOS and is almost certainly under a less restrictive license than SF Mono but it might not be as usable as you’d like. I think it’s based on DejaVu which is fairly permissive if you’re
OK with a similar (if slightly less polished, IMO) font.
While I felt highly sceptical at first, I have now learned that this is an amazing sales preview tool for source code tutorials.
Inside the article, all source code is posted as images using Carbon. That way, your readers can follow along and understand what you're doing.
But you didn't have to give away the source code, so you can still ask people to sign up for your $5 monthly membership which grants access to all source code projects as downloads.
Of course, your dear readers could also manually type in all the source code shown in the Carbon images, but at that point lazyness kicks in and they pay the $5.
My personal opinion is that knowledge should be shared, so I'm not sure if I consider such an approach good for our craft. But I can understand the business model that is created by having a tool such as this, which allows indie developers to earn a passive income from tutorials.
The next logical iteration is then to put your source code screenshots into a video, e.g. https://gorails.com/
Next HN post - UnCarbon: easy bulk OCR of source code. Ligatures would be a bit annoying to deal with, but shouldn't be too hard to get around... and once one person uploads the code as text everyone has access.
For me it would be worth more if the tool would make sure it would always have line breaks at places which enhance readability instead of only responsive to screen size. The single feature I would want from a tool as carbon is making captures of source code that would aways be super readable, no matter which device my audience reads it. The sample on an iPhone is completely the opposite breaking at my small width making a single line stretch over 4 rows, broken at random points where my screen ended.
It should smartly take my screen size into consideration and find a optimal balance between font size, line breaks and readability. I'm fine doing some small horizontal scrolling if that would improve readability. Kind of a "prettier" for sharing code automatically running when a reader reads it on any device.
And I hate it because you can't copy paste code from a picture. It's going backwards unless it's just a few lines. I cry because all those medium, blogs, devto etc articles are using it.
Been using Carbon for quite a while now when illustrating code in my blog posts or on Twitter etc. It is even on my Chrome shortcuts bar.
Copy and paste aside, it is ideal for showcasing important bits of code such as variable or function names that you want to stand out for illustrative purposes. It is a wonderful teaching tool.
In any case - who wants to be a copy and paste programmer?? </wink>
Alt text certainly wasn't intended for this kind of use. Screen readers don't cope with newlines in alt text particularly well, most just stop at the end of a line[0]. Also more care has to be taken when escaping the contents of the attribute, it's something people will definitely get wrong.
The MacOS app Deckset has a pretty sweet syntax highlighting feature where you can selectively highlight smaller parts of the code in that way, and then step through it as an animation.
And at least you've got the original markdown and PDF/HTML exports for extra accessibility.
For people who find the default padding too big(I did), you can control the presets with the Settings button - and if you want pixel-level control, you can export the carbon-config.json file from the Settings > Misc > Export config, edit in your favorite editor, and import it. I use a padding of 12px, instead of the (IMO) super big 56px.
1. With the current design standards, "beautiful code" just means lots of useless whitespace everywhere. Code should be compact and functional, not airy.
2. It breaks copy & paste, so this is really only useful for showing off, but not for actually communicating about code or writing tutorials.
3. This tool has lower contrast and lower readability than black text on a white background.
Combined, it's a tool for bragging about the wrong metric while excluding the elderly.
> Code should be compact and functional, not airy.
I would have to disagree for similar reasons to fooker.
> It breaks copy & paste, ... not for actually communicating about code or writing tutorials.
I posted it in another respond, but my research shows retyping code can be beneficial for learning. This extends to pre-internet coding books where that was the only way to recreate the code and Zed Shaw's "Learn Python the Hard Way" [1] where he explicitly states "You must type each of these exercises in, manually. If you copy and paste, you might as well not even do them."
If I had to choose between 2 screens full of source code with lots of whitespace, or half of a screen condensed, I'd always choose the variant that fits on my screen.
So my personal preference is strongly against airy and more like "cram what you can into one line".
But given the quick downvotes to my parent post, it seems I'm in the minority with my view that source code should be first and foremost useful.
Now it looks like https://user-images.githubusercontent.com/8397708/63456416-b... complete with weird cursive font and all.
IMO this niche obsession with cursives, ligatures and stuff in programming fonts actually hurts first impression for a significant percentage of people landing on this README.