zZorgz

To just toss ideas I changed my resume to be experience vs projects over work vs ‘personal’ (which could be undermining if one has significant project experience), where the experiences have multiple strong points and the projects are short descriptions. Take account importance of each item to you and recency for order. Millions of downloads is a great metric (github stars lingo is ‘meh)

Assuming you have put lot of commitment or hard work in it maybe there’s more to talk about :p. I personally have personal projects I rate higher than previous employment experience so this isn’t applicable to everyone.

It should be on your resume or you may not be giving the attention it deserves on your resume.

Speaking as someone with a decent github profile, we need to get out of the notion that github profiles are important. Anything substantial or noteworthy of interest should really be on the candidate's resume. Even personal websites are more worthwhile going through than github profiles in my opinion.

If I wanted to see the history of a file I would go to that file for more context. I agree with the author that I don't think it's useful enough to show in the front page.

I personally care about the commit log most of the time I go onto github, or the issues, or pull requests. Not that keen on navigating to files from github.

I agree with you (though perhaps speed increases become less important after a certain threshold).

I was trying to talk about comfort difference between keyboard layouts anyhow, not the speed difference.

Given the same proficiency level of QWERTY and Dvorak/Colemak, comfort difference would be more noticeable for high intensity / little breaks / long duration activity like typing tests.

Are alternative keyboard layouts significantly more comfortable for practical tasks? I’m skeptical. (Most enthusiasts already agree they aren’t really faster).

As someone that can type QWERTY and Colemak pretty equally well, I’m not convinced in my experience that alternative keyboard layouts are significantly more comfortable than QWERTY (speed aside). Comfort greatly is noticeable if you’re transcripting at high speeds frequently (typing tests) but is otherwise questionable.

Layout switchers have some bias here because they don’t type as well in QWERTY anymore or they didn’t touch type QWERTY.

In my experience a while back when writing socket / IO code, I thought Rust was safer because standard library functions in Haskell (and other languages I experimented around with) could throw unchecked exceptions/errors.

Never mind about data races :).

Fair. I was thinking of Calculus which was similar though and had AB and BC? It’s been a while. Physics C has two distinctive parts as you noted.

The A version has been around as long as the AB version. For those unfamiliar, A is roughly equivalent to 1 college semester and AB was roughly equivalent to 2 college semesters, just like AP courses for other subjects.

I was a developer in various imperative/OO languages already before I took the AB course, and I still found it to be challenging.

I think for many that have never done any programming or CS, the A version course may still be decent. It does fall short under Big O, but there should also be some extra buffer time to do something else in the year outside the AP material. That depends on the quality of the instructor though.

I must be out of the loop or this is the first I've seen this (free!) book so widely criticized. I thought it was pretty good for getting me interested in the language.

Then again, Hutton's book seems legitimately criticized too for beginners looking at the reviews I'm seeing on Amazon with some preferring or suggesting LYAH as a needed complement. So to each their own.

#macdev on irc.freenode.net is still the prominent place specifically for macOS developers that I can think of.

Not able to think of anything else off hand. Twitter or stackoverflow could be supplements. There’s other communities for Swift or other specific projects.

People can also cope with switching from different setups if trained well enough in both, which should not be too surprising. Eg: shortcuts in vim vs native editor shortcuts, scroll direction, one key swap.. It’s even possible for full blown keyboard layouts. I type using QWERTY and Colemak both on a regular basis, although I’ve not tested how long I can go without a layout to retain it, but forgetting is harder than relearning in that case.

I believe there is a lack of proof the ergonomic benefits are significant outside of typing tests which are very unrealistic to day to day tasks (unless you have a pure typist job). A bias also exists when many people that switch layouts never touch typed well or properly in QWERTY to begin with, or lose comfort awareness as they forget how to type well in QWERTY. I speak as someone that touch types equally well in QWERTY and Colemak, and think time would be spent better sticking to or learning QWERTY better.

Interesting. Looking at the proposal it seems specific to main() and not any void returning function, by automatically picking an exit status. I suppose I worry the construct has a lack of control (log diagnostics, exit status, cleaning, etc) when bailing and can’t handle eg continue, break too.

Also regarding an "early return protocol", I'd also be curious for continue, break, any ! type expression. For one of the Rust projects I worked on, I wrote an unwrap macro on Option that takes a secondary ! argument.

By single type, I meant to hint not being able to mix ? on Options and Results in the body, but good to know that's soon possible! Though you still can't, eg, use `?` in main()

As others mentioned, it looks equivalent to using the try! macro (which I'm not sure this is supposed to replace?)

Another sane alternative here is using and_then, map, etc.

Writing from memory too:

  fn h() -> Result<(A, B), E> {
    f().and_then(|x| g().map(|y| (x, y)))
  }

..which seems to be a different style of control flow to choose from. On one hand, I suppose one may avoid using and_then with code dealing with side effects. On another hand, ? seems restricted to being used inside functions that have to return a a single type (like Result) they operate on.

By saying "reference counting is a form of GC", I'm not sure whether or not you think that reference counting has usage outside of (and could have predated) GC. David did not write "a form of" either, although you think the meaning conveyed is the same. Also one could also counter similarly with saying that if David meant should, he would have said so, but whatever.

I realize memorymanagement.org conflicts with my usage, although I'm not sure I subscribe with the idea that the usage people have been using first historically is sensible.

> That is almost certainly not what David Bacon thinks. I don't know how you could get that idea from reading the introduction. Reference counting is a form of garbage collection, period.

I'm not sure what you're reading. I will quote:

"Tracing and reference counting are uniformly viewed as being fundamentally different approaches to garbage collection that possess very distinct performance properties"

Saying reference counting is an approach that garbage collection can use is certainly valid, but is not the same as saying that reference counting is a form of garbage collection, which is nonsensical usage IMO.

Further evidence that the author believes that reference counting alone is insufficient for garbage collection:

"Finally, tracing collects cyclic garbage while reference counting does not. As a result, when reference counting is applied to heaps that may contain cyclic garbage, cycles must either be collected using a backup tracing collector [43] or with a trial deletion algorithm"

"One of the primary disadvantages of reference counting collec- tors is that they do not find cyclic garbage. Therefore, an additional mechanism is required."

Regarding "who was first", although I don't have any supporting proof, I'd be shocked if usage of manually managing reference counting hasn't predated both automatic memory management and garbage collectors, which isn't a technique constrained to, say Objective-C.

Also worthy of mention, some referenced counted garbage collection implementations (e.g. CPython) vend an API for disabling the GC, which certainly has no implications on reference counting.

> The basic idea is that not only is reference counting a form of garbage collection..

Oh, how this leads to debate. The confusion is whether having automatic reference counting without a cycle detector is considered GC by the masses (what language publicizes a GC and does this?), and if people question GC to be a form of automatic memory management, where other forms may exist.

Briefly looking at the article I think the authors opinion on this matter is pretty clear that an additional algorithm such as a cycle collector is required to be considered GC.

edit: "Reference counting" itself also isn't even necessarily 'automatic'. Just find it odd the way this gets phrased. GC can use reference counting, not the other way around..

I'm a dual qwerty/colemak touch typist. I was able to learn colemak quickly with low risk of losing qwerty because I was already a very good touch typist. A large amount of typing skill is transferred which is why people with poor typing skills have such a difficult time learning a new layout.

As far as say Dvorak or colemak gaining you faster speeds, I'm pretty doubtful of that claim. It has more to do with how much effort you decide to put in.

I look forward to having tabs for most document based apps.

:q! quits without saving the text file which only aborts a commit if the message is empty, meaning it's not sufficient if the message has pre-existing content when you open it.

And you largely misunderstood. Komet has a shortcut for making the commit (command return). The mouse is just a supplemental possibility....

Having a more convenient shortcut is not the only reason I use Komet.

[edit]: and to address for "something as small as commits" -- well, I write commits pretty often. So it matters a great deal to me to have an aiding tool, and definitely not for a task I'd consider 'insignificant'

Sure, but why would one remember that if they could just do :q! regardless if there's new unsaved content or not.

Relatedly, why would one remember to do :q! or :cq depending on if there's pre-existing content if they can just cancel in Komet and have it do the right thing ;)

Yes, very arguable :). Komet has keyboard shortcuts. I don't mention them on GitHub because they're shown and I believe natural to figure out after opening the app.

I spend a lot of time on my computer not having at least one of my hands on the keyboard. Say I'm about done writing a commit message but I get a message on my phone I want to quickly check. It may be more convenient for me to use the mouse to hit commit later and then do some browsing tasks, or so. The other day I was doing some refactoring work while eating food in my other hand..

Nonetheless I believe having the option to use the mouse is better than not being able to.

Not currently in my muscle memory but this does interest me since I use vim sometimes for other ocassions. I'd prefer if shift wasn't necessary though... so I'm not sure I'll commit to this :).

Still, these are worse than Mac shortcuts that Komet uses IMO, and I dislike escape (and control to a lesser extent) :-).

Also you sometimes want to quit with an exit failure status on canceling, and why have two different operations for that when your editor is smart enough to have one.

I have invoked '<escape>:wq<return>' many times; it should be in my muscle memory but it's still something I get wrong on occasion. I can definitely see <space> being better than colon (it gets rid of shift!), although I still have beef with escape. I don't want to play the fighting game :).

What about canceling commits? Sometimes you want to quit without saving, and other times you want to exit with a failure status (which has little application elsewhere). A "commit" editor should be smart enough to decide which to do under a single action.

I acknowledge this isn't intended for those heavily invested in their CLI editor of choice.

Haven't really checked it out but if it's like git GUI, then it's probably too heavy weight to my liking to use on a daily basis.

(personal nitpick: I'd love if the app showed me how to use it rather than having to consult to online instructions)

I was referring to technical developer documentation, but I don't think user facing info will be that much revealing until after 10.12 is released.

I say that I predict using macOS will be "natural", although that doesn't necessarily mean it'll be "technically correct" for older versions.

Apple docs have references to eg: "macOS 10.8+" regarding SDK version. This may still be up in the air, but I predict it will be natural eventually to just use macOS everywhere.