zZorgz

Tried this before making Komet but from what I tested I found this to be slow (stuck in save-and-close model) and obstructive (can bring other sublime documents active).

On the contrary, I've found keeping the terminal history visible while making commits to be a useful reference.

"<escape> colon w q <return>" is too many 'actions' for me personally (and anything that needs me to reach to escape is really asking for it), and I sometimes even mess that combination up (I used vim before using Komet). I learned about :x recently which is only just slightly better, but not in my muscle memory yet. Then one may need to decide when to use q! or cq to discard..

I also prefer using a native editor and am more productive with spell checking and auto correction, surprisingly.

edit: I'm also not a user that uses the keyboard all the time. After using Komet, I am surprised how often I actually used the mouse to hit commit instead.

cp /usr/bin/ruby ~/Desktop/ruby

lldb ~/Desktop/ruby

:-)

So there's gonna be arguments both ways whether or not this console command should ask for a password or not since the user is already logged in.

The main concern I have is the inconsistency that this command does not request a password while the keychain access app, as far as I know, does request one.

Apple has been aware about their security behavior here at any rate.

I don't want to be asked about moving apps somewhere else especially for testing them. It is kind of hostile. And it's a burden for the dev to include yet more code for this. IMO, Apple should have a way to solve the issue for out-of-store apps.

(I really don't know if that many apps do this btw, I think most apps I download today are packaged in zip..)

Other users are just baffled and run apps from disk images or Downloads just because.

The authors point is that at least before 10.12 zip was a decent approach.

Too bad they aren't offering signed zip or something similar that takes same advantages that a signed dmg does..

Not updating is what most apps currently do in this case.

The author's concern is that they (and many other developers) ship apps in zips, have many users download them, and run them from ~/Downloads/ or wherever their browser downloaded the app to. Only in 10.12, this practice will prevent most 3rd party apps from being able to update themselves.

The author wants an info.plist key (plus perhaps app signing) to opt-out of translocation and say that they are competent enough. Before thinking that this "defeats" the point, people may miss that Apple is fine with opting out provided you code sign and package a dmg.

The author and many others also don't like dmgs, however, and find that they confuse many users. What the author is concerned about does indeed affect a lot of apps.

I like to think about cohesion and coupling for non-trivial projects https://en.wikipedia.org/wiki/Cohesion_(computer_science)

Recently, I've been using a tool to show the dependency graph of my program and I've found it to be quite helpful. Perhaps a bigger point is to find and use tools for your environment that really help!

I like others also favor minimizing changing global state, unit testing (increases odds your code's interface is more well designed), code reviews..

Perhaps, but it's unlikely that many do. Updating such an app would involve writing the new update to a different location, which could pose a challenge for not confusing the user. The Mac App Store doesn't have to deal with this.

Some developers that distribute their app in dmg's try to nudge the user to move the application for them into /Applications, but that's kind of hostile, and developers shouldn't have to go out of their way to do that.

Before 10.12 at least, developers were generally okay with the updater not running on read-only media - this is more intended behavior rather than being 'broken'.

Anyway, just pointing out the real concern from the article.

The main concern is that software updaters will not be able to easily replace an app bundle if it is translocated to a readonly mount. The user will have to move the app somewhere else first.

Apple wants developers to use dmgs (and signed ones particularly) but updaters don't have an easy time with apps being launched from those either, and people don't think dmgs provide a good user experience as well.

I only use Seil/Karabiner for re-mapping caps lock but they have been pretty reliable for me :).

Ditto. Can't function without the clipboard history.

Google did make battery life improvements by reducing wakes at least on the Mac in response to Safari performing better. Some interesting details are at https://plus.google.com/+PeterKasting/posts/GpL63A1K2TF

Perhaps Edge will a nice competitive impact on the Windows side :P.

Well I am also then interested in it being hard or illegal to write something bad :)

I had a small server written in Haskell but since the other contributor familiar with Java/C/C++ was not able to pick at it effectively, we switched to Rust and we all were happy, and transitioning was fine.

At work I deal with Java code, but we have a framework we wanted to use that's written in Scala, and since Scala can interop with Java, we were all productively able to transition over for the better.

For a hobby project we use Objective-C, but we are starting to write some bits in Swift. Apple is especially effective at trying to convince the developers to change over to this shiny language.

I think "advanced" languages can be used in real world applications, and the transition experience from other well known languages can certainly matter.

Out of curiosity I google searched ergonomic keyboards, found Wikipedia page, saw it stated they may reduce risks of injury but that there is no clear evidence of benefit.

My own reality is I used a "ergonomic" labeled keyboard that I felt caused me more discomfort.

Of course there are convenience trade offs somewhere and laptops to me fall under convenience.

It's works fine if you avoid/work-around ASCII art, use tabs for indentation, and only align code by indentation which has merits when coding even in monospaced fonts.

How many people can actually type in multiple layouts proficiently? I can program & type in Colemak and Qwerty equally at speeds over 100 WPM. I tend to use Qwerty at work and Colemak at home, minus tablets/phones.

Some notes based on my own experience:

* If you can touch type very well in Qwerty already, you may have a much easier time picking up a layout than the average typist. And you may have an easier time retaining more than one layout.

* What you're typing (context) is important with regards to adjusting to a layout. For example, if you learn Colemak and decide to try using the Terminal some time after you've become proficient, you might find it awkward - at first. I personally haven't found the type of physical keyboard you use to matter much with regards to this..

* When I was at the state where I could type in both layouts very poorly (due to muscle memory being confused), I realized I took many things for granted that eliminate needing to type quickly altogether like auto-suggestion/completion - and a lot about software development is about automating tasks.

* When I started to become proficient at Colemak and started to lose my proficiency at Qwerty, I developed a justification and bias that Colemak is way more comfortable for my daily usage.

* The most effort I ever put into typing was ironically typing tests, not programming =P. And those can be really tiring if you do them frequently regardless of layout.

Maybe I find these days that colemak is marginally more comfortable. Maybe I just don't type that much though, although I use the computer a lot. Software developers certainly don't type nearly as much as a "typist job" (if those still exist) in any case. If I lose my ability to type in Colemak, I don't think it will effect me that much. All in all, I can't say my transition was worth my time.

I used to use a split keyboard but now I just stick with Apple's flat keyboards. I don't buy it anymore that they're more ergonomic. The "extra rest space" on my MS split keyboard I've actually found to be detrimental for me.

Besides, people also use laptops and may not want to swap their keyboard.

Employees aside, toxic nature is inevitable for competitive online games that allow for open communication. To "fix" this may mean to make chat communication closed, or opt-in with friends, or only have a select few chat rooms with heavy moderation, or only allow a select number of phrases, etc. It would require re-thinking how chat communication in games should work, something that say Nintendo and Disney put effort into.

I had a PHP program that processed HTTP requests and stored some data onto a local database, and decided I needed to rewrite it for various reasons so I decided to choose Go. Some points I recall:

* Static typing is good.

* As I expected, the standard library and other packages available had the http & routing stuff I needed, which is all good.

* I like that errors are specified in function signatures, unlike exceptions in languages like ruby/python.

* I don't like errors being easily ignored, and return values being assigned default or arbitrary values. I once may have also accidentally used the wrong equality operator against nil.

* Defer is nice, but would be better if it was based on current {} scope.

* Append on arrays? has very bizarre semantics sometimes mutating or returning a different reference.

* Initially I ran into trouble reasoning how to use some sql package and ran into "invalid memory" deference issues or some such when passing a reference. Thus, I'm skeptical about "memory safety."

This was only a simple program though and turned out to be worthwhile for me in the end.

I have embedded Ruby and Python before so I found that paper interesting to read. Wish there were mentions of languages I'm unfamiliar with (eg: squirrel, javascript). Anyway, I appreciate the design decisions and no doubt Lua has merits, but my personal experience is I haven't found it to be a pleasant language to use or embed.

Garbage collection is a controversial topic too, and if I understand correctly, a part of the reason Lua has a stack based API (with how its GC works). I somewhat liked the level of control I had with reference counting from working with CPython. Some applications may even go out of their way to disable the GC and use weak references to guarantee determinism similar to Apple's ARC. Squirrel, born as a competitor to Lua, looks to use a GC approach similar to Python at a glance..

I prefer to embed a language that I enjoy programming in. I don't know about Tcl, but I enjoy using Python more than Lua. Python isn't that unusual of a choice for embedding either; eg: take a look at LLDB or Sublime Text.

Threading and reference counting may be some ugly aspects of embedding CPython sure, although I don't think manipulating the stack in Lua is that praiseworthy either.

I think I have set CFLAGS to something like "-arch x86_64 -mmacosx-version-min=10.8″ when running ./configure to autoconf projects.

It's not really specific to Python, so "poorly documented" isn't a surprise.

If it's an autoconf project you should be able to (as far as I recall) pass appropriate min version and architecture flags to ./configure

Python bundles a bunch of modules one may not need for embedding in either case, and they can be turned into byte code before distribution.

Interesting read. I had embedded Python in one of my apps and I wish I had known about being able to zip the distribution. To save space, I compiled all the .py files into .pyc bytecode files, and tediously removed a bunch of modules my app didn't need (tkinter, antigravity, ...), along with setting PYTHONDONTWRITEBYTECODE. You can probably still do this, of course, in addition to zipping it all up.

I had compiled python myself and used static linking instead of dealing with install_name_tool, although I do wonder if I should have built a dynamic library instead. Anyway, compiling from source (or adjusting the homebrew formula?) gives you control and being mindful of eg: LC_VERSION_MIN_MACOSX as already mentioned here.

For my specific use case, I also wanted to use Apple's GCD and have Python do all of its work on a secondary thread. I had to make sure the interpreter would only stay on a single thread (whereas GCD normally doesn't make such a guarantee).

Yeah, when the effort put into inserting types is higher cost than reading them (as with short lived / unstablized code), what you're saying makes sense.

Which is kind of why I wish for tooling outside the compiler to make the effort in specifying types (when it increases readability, maybe based on heuristics) very minimal. Wishful thinking.

My own experience is that I've been running into less scenarios where I think omitting the type makes code more readable (coming from Scala). It doesn't help myself and my coworkers that it's easy (or 'lazy') to omit annotations.

I often wish I was using a text editor or IDE that understood my code and could insert type annotations for me, maybe automatically, and maybe not choose to do so if the line of code would "look" more redundant (i.e: parsing variable name or constructor/initializer).

Rust is one language that, while has the capability of doing full type inference, deliberately chose not to (https://doc.rust-lang.org/book/functions.html):

> This is a deliberate design decision. While full-program inference is possible, languages which have it, like Haskell, often suggest that documenting your types explicitly is a best-practice. We agree that forcing functions to declare types while allowing for inference inside of function bodies is a wonderful sweet spot between full inference and no inference

Seems reasonable. But now you risk the chance of reading code written by those who don't specify types, don't know better, or don't use -Wall.

I think deciding what to allow and prohibit by default is an important design decision.

Having the option to use type inference in this specific use case is nice.

But I'm glad it's just for initializers.

After playing with Scala, I've found out I don't love type inference as much as I thought I did. In Scala, the compiler can infer return types of named procedures for example, but I've always found omitting these makes my code harder to read, having to read the body (an implementation detail) to see what it may be returning. It would be even worse if types were optional for parameters (ala Haskell). Other modern languages (ala Rust) have come to realization that this is a bad idea.

The same even applies to having the compiler infer types from local variables to a lesser extent. A lot of my code goes through transformations and chains, and sometimes it's not obvious what the resulting type is (and what the code is doing) if the type is not specified.

Even looking at the simple example mentioned from the article in isolation:

    var stream = list.stream();

I don't know what type stream is. Sure, I can make an educated guess that it's some kind of Stream, but then knowing it's a parameterized, and then knowing what kind of type it takes is even more challenging. I would have to look at the right hand side (again, an implementation detail), or may have to traverse up even further (eg: looking up how `list` is derived in this case) to figure out for sure. Or worse yet, look up documentation. Imagine if the right hand side was composed by calling a series of procedures, then you have to traverse all the way to the right to validate the type. In the end, you have a mental burden.

The same issue applies with calling functions and assiging their result to a local variable you're initializing.

I'm happy to see type inference is just added for initializers. Whilst I haven't found writing 'Foo foo = new Foo()' that common in functional code, I see that being prevalent in Java at least. On the flip side though, if your language or use case (C++?) makes code harder to understand rather than easier by specifying types, then you may be wishing you had type inference :)