-
Painful.
-
So, I work on two projects at work. One is a agent, part of a distributed system, that runs in several servers and provides access to some hardware connected to said servers. We maintain some of those servers, others are run by users. The other project is a library, used by the first project.
The agent system is release once every sprint, and our sprints take 2 weeks. In the Tuesday of the second week, we ‘close’ the release: nothing merged after this will get in the release, unless it’s a bugfix. Then for the next 3 days, we run manual tests on the whole system (of which the agent is a part). If errors are found, we merge the fixes. We use a sort of trunk based development, so, if we find a bug, we’ll create a release branch and cherry-pick it there. Once we ran all tests, we manually generate a zip package (which involves creating a fresh clone, copying a bunch of files around, and zipping the resulting folder) and a) manually deploy it to the servers we maintain, and b) upload it to an internal confluence page.
It’s very manual and very error-prone. We’re finally automating some parts of it, but it’s not done yet. The system is written in python, so we could be a simple pip package, but for permission reasons (not everyone is allowed to run it), we’re not there yet.
The library is kinda worse. First, it has a binary dependency, that lives in separated repositories, so we have to make sure we keep the versions synced. It’s also a python project, but also not packaged as a pip package. The way it’s release is: We compile the binary dependency, copy it over to the development repo. We than commit and merge the release in the development branch. Then, we copy the changes, MANUALLY, to a “release” repository, commit it in there, and merge it. The users get the updates from the release repository, and we work in the development repository. I tried to sync the repositories history, to simplify this freaking mess, but there are manually applied changes in the release repository that make it impossible (or nearly) to just squash and push the changes from the development repo to the release repo.
I recently wrote a small makefile to automate some of this terrible process, and my plan is to bring all this crap together in a single repo, split the library into two parts, and package both of them as proper pip-installable packages, but we’re a fairly long way from that, yet.
Tell me that ain’t painful.
-
Oh, also important to note: the agent system has some automated tests, that are supposed to run for every pushed commit and give it a -1 code review if it fails. That’s broken, currently, and because our PO is a , we haven’t had time to fix it yet. When it used to run, it was a good thing, but we don’t have lots of coverage, and the main server (that controls all agent servers), has almost no automated tests, so, there’s that.
The library has some unit tests, but it’s a library to communicate with smartphones, so, there’s only so much test you can do without actually connecting it to a real phone and testing it. We do have a separated repo with integration tests that use real hardware, but it’s completely broken and I haven’t got time to fix it yet. So right now the reality is: I run the unit tests before a release, run a basic connection test, and hope for the best =/ Our release cycle is pretty tiny, one week, and we have release a worrying amount of bugs into production in the last months. I raised that with our manager and got the usual “Yeah, we should worry about that” response that will likely turn into no actual action.
-
Thanks for elaborating. I think that managers can be motivated by costs sometimes. If you add up the time it takes to do all the manual steps, say, over a month, then the effort required for automation might look more attractive. Maybe you could show that it will pay off within 6 months or a year.
-
-
-
Your comment doesn’t answer the OP’s questions and doesn’t contribute anything to the discussion. Please write something useful instead. I’m disappointed that several people thought this one-word comment should be upvoted.
-
-
It would be better if lobste.rs didn’t devolve into obvious one-word jokes. There’s already Reddit.
-
And as with all jokes, it has some reality to it =/
-
-
-
-
-
-
[Comment removed by author]
-
I think it’s usually because “that’s what work is buying me”.
-
-
I really like Lenovo X1 Carbon.
-
-
Personally I like the Dell XPS 13 and 15. The 4K screens are really amazing to see in person. You can configure with an i7 processor, optional fingerprint reader, fast SSDs up to 1TB, up to 32GB RAM, touch/non-touch display options, up to 97Wh battery in the ~4.5lb model or 56Wh in the 4lb if you want to go lighter (benchmarks). For ports, it has an SD card slot, 2 USB-A 3.0 with PowerShare, 1 HDMI, and a Thunderbolt 3 (including power in/out).
I feel they compete in several of the categories and are worth checking out in person somewhere (Frys, etc) if you’re in the market. Just earlier today someone posted a link to this guy’s experience spending a year away from MacOS and he winds up with an XPS 15, which he mostly likes.
-
-
I went from a 2011 macbook pro 15” to a thinkpad 460p running kubuntu, its not as flush as the macbook but it beats performance & price for me. Form factor, I should’ve got a 15” again but thats my choice. Fit & finish on the macbook is better but then I can easily remove my battery and get to all the internals of the laptop, so I prefer the thinkpad.
-
-
-
The new Huawei Matebook X?
-
How about the ASUS ZenBook Pro? I don’t have experience with it, but superficially it’s got very similar form factor and design to a MacBook. Aluminum uni-body and all. And being not-Apple, you obviously get better performance for the price.
-
-
-
I’ve run Linux on a Macbook because my employer wouldn’t give me anything else. Reason was: effort of IT team vs my effort of running Linux.
But pretty sure my effort was extensive compared to what their effort would have been :)
-
-
16:10 screen, wide-gamut display, correct ppi (X1C is too low, and the high-res Dells too high).
The last ThinkPad (of which I have many) to have a 16:10 screen was T410, which is now 8 years old.
Personally, there’s no other modern laptop I’d rather use, regardless of operating system. To me nothing is more important than a good and proper screen.
If anybody comes up with a laptop that has a 4:3 screen, I’ll reconsider.
-
-
It does, but tragically it’s ruined by a glossy finish on the screen. I bought one for the aspect ratio and brightness but almost threw it out the window several times in frustration before giving it away.
-
-
-
I don’t think many people buy new Apple hardware with the intention of immediately wiping it and installing Linux.
My MBP, for example, is running OSX because I need it (or Windows) to use Capture One photo software. When I upgrade to a new machine I’m going to put Linux on the old one and use it for everything else. I did the same thing with my iMac years ago.
I personally still think the build quality of Apple laptops are better than the alternatives. The trackpad in my old MBP, for example, still feels better than the trackpads I’ve used on newer machines from other brands. The performance and specs are less important to me as long as it’s “fast enough” and the build is solid.
All that said, I’m not buying any more Apple products because their software quality has completely gone down the toilet the last few years.
-
In this case I didn’t really have a choice. I had tried asking for a PC before I started this job; but they tried to get me in really fast and provisioned a Mac without even asking me. My boss made up some bullshit about how you have to have them for developers laptops as the PCs the company bought didn’t have the specs (16GB of ram and such). I’m really glad I got Linux booting on it and not have to use it in VMWare (which does limit your max ram to 12GB and doesn’t give you access to the logical HT cores).
But yea if it was my personal laptop, I wouldn’t even bother buying a mac to being with. My recent HP had everything supported on it with the latest Ubuntu or on Gentoo with a stock kernel tree right out of the box.
-
-
-
If you use Neovim, you can use the builtin man page plugin.
For example: https://i.imgur.com/eLNmYkh.png
Checkout https://github.com/neovim/neovim/blob/611351677dba450fc1a312061572c44c7e3d6482/runtime/doc/filetype.txt#L509 for docs and how to use it as the default man pager.
-
-
This is why we can’t have good software. This program could literally have been an empty file, a nothing at all, a name capturing the essence perfectly.
I’m not sure I could disagree more strongly. An empty file only has the
truebehavior because of a bunch of incredibly non-obvious specific Unix behaviors. It would be equally reasonable for execution of this file to fail (likefalse) since there’s no hashbang or distinguishable executable format to decide how to handle it. At a somewhat higher level of non-obviousness, it’s really weird thattrueneed be a command at all (and indeed, in almost all shells, it’s not—trueis a builtin nearly everywhere).truebeing implementable in Unix as an empty file isn’t elegant—it’s coincidental and implicit.-
I mean, it’s POSIX specified behavior that any file that is executed that isn’t a loadable binary is passed to /bin/sh (”#!” as the first two bytes results in “implementation-defined” behavior), and it’s POSIX specified behavior that absent anything else, a shell script exits true.
It’s no more coincidental and implicit than “read(100)” advances the file pointer 100 bytes, or any other piece of standard behavior. Sure, it’s Unix(-like)-specific, but, well, it’s on a Unix(-like) operating system. :)
-
It’s precisely specified, yes, but it’s totally coincidental that the specification says what it does. A perfectly-reasonable and nearly-equivalent specification in an alternate universe where Thomson and Ritchie sneezed five seconds earlier while deciding how executables should be handled would have precisely the opposite behavior.
On the other hand, if
read(100)did anything other than read 100 bytes, that would be extremely surprising and would not have come about from an errant sneeze.-
Black Mirror Episode: The year is 2100 and the world is ravaged by global warming. The extra energy aggregated over decades because non executables went through /bin/sh caused the environment to enter the tipping point where the feedback loops turned on. A time machine is invented, where one brave soul goes back in time with a feather, finds Thomson and makes him sneeze, saving humanity from the brink of extinction. But then finds himself going back to 2100 with the world still ravaged. Learns that it was fruitless because of npm and left-pad.
-
it’s totally coincidental that the specification says what it does.
This is true of literally all software specifications, in my experience.
-
-
Why isn’t
100an octal (or a hex or binary) constant? Why is it bytes instead of machine words? Why is read bound to a file descriptor instead of having a record size from an ioctl, and then reading in 100 records?Just some examples. :)
-
-
Pass a
mmap’ed pointer toread, and it shall write. :)
-
-
-
-
-
The current (POSIX) specification is the product of historical evolution caused in part by
/bin/trueitself. You see, in V7 Unix, the kernel did not execute an empty file (or shell scripts); it executed only real binaries. It was up to the shell to run shell scripts, including empty ones. Through a series of generalizations (starting in 4BSD with the introduction ofcsh), this led to the creation of#!and kernel support for it, and then POSIX requiring that the empty file trick be broadly supported.This historical evolution could have gone another way, but the current status is not the way it is because people rolled out of bed one day and made a decision; it is because a series of choices turned out to be useful enough to be widely supported, eventually in POSIX, and some choices to the contrary wound up being discarded.
(There was a time when kernel support for
#!was a dividing line between BSD and System V Unix. The lack of it in the latter meant that, for example, you could not make a shell script be someone’s login shell; it had to be a real executable.) -
The opposite isn’t reasonable though. That would mean every shell script would have to explicitly exit 0 or it will fail.
Every. Shell. Script.
And aside from annoying everyone, that wouldn’t even change anything. It would just make the implementation of true be exit 0, instead of the implementation of false be exit 1.
And read(100) does do something besides read 100 bytes. It reads up to 100 bytes, and isn’t guaranteed to read the full 100 bytes. You must check the return value and use only the amount of bytes read.
-
It’s not obvious to me that an empty file should count as a valid shell script. It makes code generation marginally easier, I suppose. But I also find something intuitive to the idea that a program should be one or more statements/expressions (or functions if you need main), not zero or more.
-
So if you run an empty file with sh, you would prefer it exits failure. And when you run an empty file with python, ruby, perl, et al., also failures?
Why should a program have one or more statements / expressions? A function need not have one or more statements / expressions. Isn’t top level code in a script just a de facto main function?
It’s intuitive to me that a script, as a sequence of statements to run sequentially, could have zero length. A program with an entry point needs to have at least a main function, which can be empty. But a script is a program where the entry point is the top of the file. It “has a main function” if the file exists.
-
I think whatever the answer is, it makes equal sense for Perl, Python, Ruby, shell, any language that doesn’t require main().
In my opinion, your last argument begs the question. If an empty program is considered valid, then existing is equivalent to having an empty main. If not, then it isn’t.
In any case, I don’t mean to claim that it’s obvious or I’m certain that an empty program should be an error, just that it seems like a live option.
-
-
Exactly. It sounds like arbitrary hackery common in UNIX development. Just imagine writing a semi-formal spec that defines a program as “zero characters” which you pass onto peer review. They’d say it was an empty file, not a program.
-
I guess
trueshouldn’t be considered a program. It is definitely tied to the shell it runs in, as you wouldn’t callexecv("true", {"/bin/true", NULL})to exit a program correctly. for example.truehas no use outside of the shell, so it makes sense to have it use the shell’s features. That is why now it tends to be a builtin. But having it a builtin is not specified by POSIX. Executing file on the other end, is, and the spec says the default exit code it 0 or “true”. By executing an empty file, you’re then asking the shell to do nothing, and then return true. So I guess it is perfectly fine fortrueto jist be an empty file. Now I do agree that such a simple behavior has (loke often with unix) way too many ways to be executed, ans people are gonna fight about it for quite some time! What about these?alias true=(exit) alias true='/bin/sh /dev/null' alias true='sh -c "exit $(expr `false;echo $? - $?`)"'The one true
true!-
It depends upon the system. There is IEFBR14, a program IBM produced to help make files in JCL which is similar to
/bin/true. So there could be uses for such a program.It also has the distinction of being a program that was one instruction long and still have a bug in it.
-
“That is why now it tends to be a builtin.”
Makes sense. If tied to the shell and unusual, I’d probably put something like this into the interpreter of the shell as an extra condition or for error handling. Part of parsing would identify an empty program. Then, either drop or log it. This is how such things are almost always handled.
-
-
-
-
That would mean every shell script would have to explicitly exit 0 or it will fail.
I don’t see how that follows.
Once the file is actually passed to the shell, it is free to interpret it as it wishes. No reasonable shell language would force users to specify successful exit. But what the shell does is not in question here; it’s what the OS does with an empty or unroutable executable, for which I am contending there is not an obvious behavior. (In fact, I think the behavior of running it unconditionally with the shell is counterintuitive.)
And read(100) does do something besides read 100 bytes.
You’re being pedantic. Obviously, under some circumstances it will set error codes, as well. It very clearly reads some amount of data, subject to the limitations and exceptions of the system; zero knowledge of Unix is required to intuit that behavior.
-
I don’t see how that follows.
You claim the exact opposite behavior would have been equally reasonable. That is, the opposite of an empty shell script exiting true. The precise opposite would be an empty shell script—i.e. a script without an explicit exit—exiting false. This would affect all shell scripts.
Unless you meant the opposite of executing a file not loadable as an executable binary by passing it to /bin/sh, in which case I really would like to know what the “precise opposite” of passing a file to /bin/sh would be.
You’re being pedantic. Obviously, under some circumstances it will set error codes, as well. It very clearly reads some amount of data, subject to the limitations and exceptions of the system; zero knowledge of Unix is required to intuit that behavior.
No. Many people assume read will fill the buffer size they provide unless they are reading the trailing bytes of the file. However, read is allowed to return any number of bytes within the buffer size at any time.
It also has multiple result codes that are not errors. Many people assume when read returns -1 that means error. Did you omit that detail for brevity, or was it not obvious to you?
-
-
-
-
Saying the behavior is totally (or even partially) coincidental is a bit strong. You’re ignoring the fundamental design constraints around shell language and giving the original designers more credit than they deserve.
Consider this experiment: you pick 100 random people (who have no previous experience to computer languages) and ask them to design a shell language for POSIX. How would all of these languages compare?
If the design constraints I’m talking about didn’t exist, then it would indeed be random and one would expect only ~50% of the experimental shell languages to have a zero exit status for an empty program.
I strongly doubt that is what you would see. I think you would see the vast majority of those languages specifying that an empty program have zero exit status. In that case, it can’t be random and there must something intentional or fundamental driving that decision.
-
I don’t care about how the shell handles an empty file. (Returning successful in that case is basically reasonable, but not in my opinion altogether obvious.) I’m stating that the operating system handling empty executables by passing them to the shell is essentially arbitrary.
-
The reason for the existence of human intelligence isn’t obvious either but that doesn’t make it random. A hostile environment naturally provides a strong incentive for an organism to evolve intelligence.
As far as the operating system executing non-binaries with “/bin/sh” being arbitrary, fair enough. Though I would argue that once the concepts of the shebang line and an interpreter exist, it’s not far off to imagine the concept of a “default interpreter.” Do you think the concept of a default is arbitrary?
-
-
-
It’s precisely specified, yes, but it’s totally coincidental that the specification says what it does.
laughs That’s really taking an axe to the sum basis of knowledge, isn’t it?
-
-
-
yes an empty file signifying true violates the principle of least astonishment.However if there were a way to have metadata comments about the file describing what it does, how it works, and what version it is without having any of that in the file we’d have the best of both worlds.
-
-
-
-
-
-
I briefly looked at Vala for writing Oil [1], although I also looked at 5 or 10 other languages.
For my purposes, Go is in a similar spot: they’re both C-like with more abstraction (interfaces in Go, classes in Vala). But Go has a complex runtime which starts threads and so forth.
So Vala was interesting in it compiles to C and I believe have no runtime. However when I actually tried the C runtime (as opposed to the GUI runtime), it didn’t work for me. I think I got a compile error. I only spent about 10 or 15 minutes on it though.
I’m still a bit curious if Vala is suited for writing low level / low-dependency code like a shell, vs. something like GUI code. My sense is that it’s more suited for the latter.
-
-
I’m in :D
-
I would take a significant pay cut before I went back to working in an office.
I wake up now, walk my son to school, come back home and play with my younger son and have coffee with my wife. I go upstairs to my office when the time comes and get to work. When my son gets home from school, I’m there to greet him and give him a hug. When my wife needs help (un)loading the car, I can run down and help her. On my breaks I can go take a shower or eat lunch at home (much cheaper than buying lunch), etc, etc.
I combat the lack of socialization by going out anywhere between one and four times a month with a close friend of mine who also works from home; we set up shop in a coffee shop/bar/restaurant and work the day together (though to be honest, we do a lot of socializing, since it was pent up).
This has worked for me for about a decade now.
-
It’s like you’ve been watching me…
But seriously. The extra time I get to have with my kids working from home is just the best thing ever.
-
-
Well okay but get you’ll have to get your own friend.
-
-
-
-
-
Things I don’t like about Nix:
- People find it scary, and I would like to fix that.
- It has no incremental build support per-project. Chromium fail to build in the last step? Sorry, hav to start over.
- The command line interface is obtuse and hard to understand. Some commands work very differently from others , and leads to extremely confusing behavior. Hopefully this will be fixed in 1.12.
- The evaluator is a bit slow and memory inefficient, causing corner cases like checking every package description across every architecture requires too much RAM and CPU time.
Almost every other build tool:
- Undeclared. Dependencies.
- Improperly pinned dependencies without hashes, making it hard to know if 1.0.0 you got today is the same 1.0.0 you got yesterday (hint! it isn’t always the same!)
-
-
-
Given he’s contrasting to Nix, I assume he’s talking about (eg) ‘you need libxml2 installed systemwide for this to build’ not being specified in a machine-readable way.
-
-
-
I’ve seen a few posts about Slack’s backend engineering. I’m normally interested in stuff like this, but honestly, their frontend client is so slow - so frustratingly slow - that I never read them. I wish they’d get it sorted out, I mean it’s truly abysmal.
-
-
-
-
-
I tap a push notification from slack on mobile, and it takes >30 seconds to show me the message (on an iPhone 6s, one of the most used devices).
-
Slack tends to run slow in larger teams. Normally, I’d chalk it up to slower hardware, but I recently started using it on a newer Dell work laptop, and it is very easy for it to get slowed down if you’re doing anything with the rest of the machine.
I think the slack desktop front-end really could use a round of performance improvements so that it runs well on hardware that wasn’t literally released this year, or otherwise highly priced.
@nhooyr: What is the relative size of the teams you’ve been using it on? How many gifs do they use, how many channels are you usually in?
-
-
-
Not able to reproduce this behavior. On Mac OS, I believe the root account is disabled by default; it gets enabled when a password is set for it. I wonder if the behavior they’re reporting is still present when a root password has been set.
-
-
Excellent.
-
Huh. Go and I share a birthday.
-
You’re only ten?
-
-
-
-
-
I don’t think it’s that big of a deal. I agree with a comment on the post.
If people use random TLDs for testing then that’s just bad practice and should be considered broken anyway.
-
At least the developer tools (like pow, puma-dev) which do squat on *.dev will now be compelled to support “turnkey https” out of the box, or risk losing many of their users.
-
Or switch to some TLD that’s reserved, like
.test -
Well, since
.devis a real domain, what I actually suspect will happen is they’ll just switch to something else. Which, to be honest, I’d prefer: I’m all for HTTPS everywhere, but onlocalhost, when doing dev, it’s not worth it 99.9% of the time (and it robs me of tools likencandtcpdumpto casually help with certain issues).
-
-
-
I have one (erm, three) and it is wonderful. Do I wish it was thinner and had like usb-c charging? Sure.
-
If you don’t mind my asking, how much does it weigh, and what’s the battery life you get?
4W draw at 32Wh means he could get something like 8h battery life – which is very attractive to me. I currently use a MacBook predominantly for the massive battery performance, but also because it’s so light, but I might trade a little weight and a little battery for a nice keyboard and good Linux support.
-
FWIW if you can stand a 16:9 display, an official Lenovo Thinkpad T470 has a cheap battery upgrade option that doubles the battery life to 16 hours. 96Wh total (24 internal battery + 72 external). 3.9 pounds with the bigger battery. https://www.laptopmag.com/reviews/laptops/lenovo-thinkpad-t470
Compare with MacBook Pro 13” 3.02 pounds, 15” 4.02 pounds.
-
-
-
-
-
This is kind of a pointless article. The author doesn’t actually postulate anything of substance.
I can’t see IOS replacing MacOS. There is a HUGE installed base of Automator tasks in all kinds of environments and I can’t see that translating to IOS at all.
-
Isn’t Apple getting rid of Automator? I recall a source somewhere that said they removed all of the Automator staff, I think it may have been in the Hypercard discussion. Ive been thru the System 6 to 7 transition, and the 9 to X transition. Its always messy. But I am getting the feeling they want to converge macOS and iOS at some point. Just my opinion.
-
Oh I very sincerely doubt that. Some of Apple’s biggest clients are huge desktop publishing houses that have crazy complicated Automator workflows.
I did some googling and couldn’t find any reference to this - don’t mean to be a pain but - got a cite? Curious to see your source.
-
This is what I found, but its not the article I remember reading (which was recent),
https://9to5mac.com/2016/11/17/mac-user-automation-sal-soghoian/
-
Wow thank you this is profoundly sad. The user sutomation suite is one of the things that keeps me a loyal OSX user. If that goes away I will be incredibly disappointed.
There is an incredible amount of power inherent in being able to control and customize the state of running apps programmatically from userland. It’s a very old idea and I don’t understand why people seem so keen on tossing it into the scrap heap.
-
-
-
-
-
-
-
-
-
Reminds me of the classic https://github.com/Droogans/unmaintainable-code
Some companies have a strict policy of no numeric literals; you must use named constants. It is fairly easy to foil the intent of this policy. For example, one clever C++ programmer wrote:
#define K_ONE 1 #define K_TWO 2 #define K_THOUSAND 999-
Never underestimate the power of a bored college student and a preprocessor: https://github.com/Hashdump/Goodbye-World/blob/master/hello_random.c I still go back to that and disgust myself with what I created.
-
-
-
I’ve done the very same thing a couple of years ago. I also went from zsh to ksh and moved to other, simpler tools. Started using ed, too :^) I’m no longer spending^Wwasting time tweaking yet another feature. I must be getting old or something.
-
-
ed is a REPL-based editor: it works the same way as the command line, and you now have the same universal interface everywhere.
Also, a lot of “plugins” can be used it ed, with the shell escape (
!):- Emacs Magit / vim gitgutter:
!git diff - git fmt:
<range>!fmt - :make:
!make
…and so on. These are not plugins, but as the output stays after the command is executed, you can display the few lines affected by that make error, jump to that git hunk you want to change… without making the backtrace / git diff go away: it is in your terminal scrollback buffer.
In the end it feels natural (but clunky to edit stuff within a line: using
s/tpyo/typo/all of the time!) and integrates fairly well with the shell.You can try it anytime with the
Qkeybinding in vim, and try ex(1) (EXtended ed):<range><command><argument>-
1m4- Move line 1 after line 4 -
1,4t8- copy line 1 to 4 To line 8 -
:set nu- convenient for working with lines range -
1,5- print lines 1 to 5 -
z- scroll one page down -
[Enter]- scroll one line down -
[Ctrl + D]- scroll hale a page down -
z=- display context around current line (very convenient but not in ed) -
s///- you know it already -
/pattern1/,/pattern2/!fmt- format lines between these 2 patterns -
1,5g/pattern/d$- delete all lines withpatternbetween line 1 and 5.
The bonus to knowing ed/ex is that you have access to these commands in vi/vim in cas you need them.
- Emacs Magit / vim gitgutter:
-
- Distraction-free - you get an error message about a specific line number and you simply work on that line, give or take 1 up/down.
- It is available in bsd.rd - vi isn’t.
- Why ed(1)?
- Ed Is The Standard Text Editor
:^)
-
-
-
I don’t think syntax highlighting is a sign of weakness or not understanding a language.
-
I wonder if someone would see it as a weakness to use proper formatting or to use obviously named variables. It’s just a preference like tabbed spacing or anything else.
-
On one hand, humans have color perception for a reason, so not using syntax highlighting is consciously handicapping yourselves.
On your other hand, the article argues that syntax highlighting distracts you from semantics, so maybe what we should really use is semantic highlighting. But even then you’d still be using colors, so either way.
-
What I’ve found is that, especially in Vim, because just about everything is highlighted, it ends up just looking like a big jumble of colours and nothing stands out (it’s also very inconsistent and the syntax files are a mess). And then you’ve got issues like native types being highlighted, while custom types aren’t recognized which is just confusing. I’m a fan of minimal highlighting, and I’ve gradually dialed my personal colour scheme right back to only highlighting comments and ‘TODO:’, ‘NOTE:’ (so they really catch my attention), and a few very specific things like function/method definitions to make it easier to visually scan a file.
-
-
I wrote on this topic; I agree that going without syntax highlighting is making it harder on yourself (e.g., not noticing that the code you are looking at is in a huge comment block or that you used an incorrect escape sequence), but too much highlighting and nothing particularly stands out. I made my own theme where most text is in one color, and I highlight comments, string literals, function definitions and a couple of other constructs. I particularly like the highlighting of function definitions, it helps my to quickly see where one function starts and where another begins.
I don’t have any particular talents in art, color theory, design, UX, and all that, and I’m sure that a competent theme designer could take only 3-4 colors and create a theme that really highlights the value of syntax highlighting.
-
not using syntax highlighting is consciously handicapping yourselves
While understanding that syntax highlighting, like editor and programming language choice, is highly subjective, I disagree with this statement.
I personally find that disabling syntax highlighting, and all colors in my terminal, helps me to focus on the actual semantics. I find that I actually read the code more carefully and retain more of the substance than when using highlighting.
I also find that disabling highlighting is particularly useful for viewing files written in programming languages I’m less familiar with. While yellow may mean parameter in one language, it may mean class declaration in another. Disabling colors completely removes any chance of information bias based solely on a first glance.
I would love to see any studies you have to support the theory that not using syntax highlighting when reading code is an intentional handicap. I would also love to know in what ways you think it is handicap. Is my understanding of the code compromised? Am I slower and less productive? How do you measure how handicapped I am?
-
I personally find that disabling syntax highlighting, and all colors in my terminal, helps me to focus on the actual semantics. I find that I actually read the code more carefully and retain more of the substance than when using highlighting.
“On your other hand, the article argues that syntax highlighting distracts you from semantics, so maybe what we should really use is semantic highlighting.” :P
I would love to see any studies you have to support the theory that not using syntax highlighting when reading code is an intentional handicap.
Here you go!
-
“On your other hand, the article argues that syntax highlighting distracts you from semantics, so maybe what we should really use is semantic highlighting.” :P
Yes, that’s why my statement was prefaced with “I personally”. I interpreted your use of “on your other hand” (emphasis mine), to mean you were incredulous of that argument. I was adding my own personal experience and preferences to the discussion.
I can’t speak to the papers, as I’m reading them now, but I appreciate the sources. You did not, however, answer how I am handicapped. Simply trying to authoritatively state that forgoing highlighting makes me perform at a lesser degree than someone using highlighting is a broad and vague statement.
-
That’s fair. My position is more philosophical: colors are very information dense for humans, so we should leverage that for parsing code. That doesn’t mean any particular syntax highlighting scheme Is Good, or even that our current position on syntax highlighting Is Good- I think it’s helpful, but there’s a lot of room for improvement.
One thing I haven’t really seen, but am really into the idea of, is semantic highlighting. That would be things like “color any function that’s imported somewhere else in the codebase” or “highlight any variable I later mutate.” Those would potentially be a lot more powerful than just coloring keywords and such, but would also be trickier to write a highlighter for, which might be why nobody’s done it yet.
Edit: “your other hand” was a typo :/
-
That’s also fair. I was mostly just wanted to dig into the theory that anyone not using highlighting is intentionally handicapped. I, clearly, disagree there but I definitely accept that feelings around highlighting, like most programming-related meta-things, are highly subjective.
While I do not use highlighting, I’m also interested in seeing how tools can improve to help people perform their tasks to the the best of their ability. I’m not opposed to highlighting existing and would love to see improvement made to make highlighting more useful. Semantic highlighting would be very interesting and I would definitely give it a try.
I just don’t don’t buy that I’m at a disadvantage by not using normal syntax highlighting.
-
-
Neither paper actually says I am at a handicap. What they do say is that syntax highlighting is useful among certain portions of the programming population for quickly identifying certain characteristics about a program. Neither explores whether the users already used syntax highlighting, or the same tools and same colors used in the study, or how the highlighting affects the understanding of a program in someone who normally does not use highlighting,.
I believe you are misrepresenting the data in those papers as “not using syntax highlighting is intentionally handicapping yourself” when in fact the first paper says syntax highlighting can be beneficial for identifying certain program constructs (first paper) and the second paper clearly states that “the magnitude of the effect [syntax highlighting has] decreases as programming experience increase”, though it does say it can reduce context switching.
So, my question is still, why do you think I’m at a disadvantage and how does this manifest?
-
-
-
-
-
On one hand, humans have color perception for a reason, so not using syntax highlighting is consciously handicapping yourselves.
I’ve never seen this brought up about IDE’s. That’s a great point. It’s reinforced in many other areas such as UX and marketing materials. Hell, even the milk I buy is always red since many generic, grocery items are categorized by color for instant recognition. It’s proven to be a useful psychological effect in general. So, we should leverage color for categorization in IDE’s. How to best do that is obviously still an open topic but keywords vs functions vs type vs etc have been useful so far.
-
keywords vs functions vs type vs etc have been useful so far
I don’t agree with this at all. I appreciate that people like it, but I bet many orders of magnitude more time have been wasted trying to tell the difference between
$accountCountand$accountCⲟuntthan betweenprivateandpersonal.Maybe even more when you consider colour fatigue tricking the programmer into thinking there’s no difference between the lines…
-
Hmm. We could make the keywords all one color with the usesr-supplied identifiers on a given page being different colors. How about that?
-
Maybe. It certainly sounds more useful than what vim and sublime editor do. There’s some risk though, and it’s unclear how common purposeful variable shadowing is:
let accountCount=get(); do_something(function() { let accountCount=get(); ... });The two “accountCount” variables above should be different colours, and while shadowing occurs frequently in my programs, in other programs it might be a bug.
-
-
-
-
-
Obligatory quote: http://aiju.de/rant/syntax-highlighting
That is what overly highlighted code looks like to me.
For me, proper indentation / spacing and code layout is way enough for reading.
For writing, highlighting strings reveals to be appreciated to me, but still, in languages such as shell script, you can quote every single word or let it unquoted. Syntax highlighting for strings then become totally pointless.
When I use vim, I switch between
:syntax offfor less rainbow reading and writing and:syntax onwhen I have a doubt about a string quote in a shell script or such.Proper color theme is also a good compromise.
-
-
-
Side note: is it just me or is the font really hard to read?
-
The points are good, but I certainly don’t want inotify features to be gating the VFS layer. IMO
inotifyis good at what it does. If you want to know about absolutely everything going on for a given filesystem, maybe you want to implement the filesystem itself (fuse, e.g.).IIRC (and I was involved in higher level filesystem libraries when this stuff was going into the kernel - but that was a long time ago) dnotify and inotify were designed with the constraint that they couldn’t impose a significant performance penalty, the logic being that the fs operations were more important than the change notification. If watching changes is as important or more important than io performance another mechanism like a fuse proxy fs or strace/ptrace makes sense.
fuse is how tup keeps track of dependencies, although I think it also will attempt to use library injection when that’s not availible.
Thing is, FUSE is slower, buggy (I’ve had kernel panics) and less flexible. A native way to track file system operations in a lossless manner would be really nice to have on linux.