mheathr

Mathematica is a lot cheaper than Matlab, in the US anyways. Mathematica excels at symbolic computing, where as Matlab excels at numerical computing. Mathematica happens to be poor at numerical computing, and Matlab happens to be poor at symbolic computing, although Mathematica is becoming better at its current weakness at least.

In what way is Matlab more feature-complete and polished? With respect to just the actual language Octave is nearly a 1:1 implementation of Matlab, which is an primary goal to stride for and maintain, any differences between the two is considered a bug even.

I second this, and I would third this if possible; I obtained mine through massdrop as well.

Having suffered from debilitating RSI at one point that took several months to even moderately recover from, an ergonomically sound keyboard (along with other habits) is a necessary step for satisfying best practices and not having to change careers as a result.

RSI is an extremely annoying and potentially career ending injury that is not resolvable fully through surgery, so doing everything possible to avoid ever having that is very smart.

If you ever have it you will wish you went with the ounce of prevention rather than the pound of cure route.

At one point the injury was so bad that I could not even read a book or touch a surface without searing pain; any force on my hands was agony basically and empathizing with people who have physical disabilities is accessible at a whole new level.

An unfortunate side effect of RSI/CTS is that while you appear perfectly healthy to external observers you are incapable of actually doing the same things a healthy individual can without worsening the injury and prolonging recovery in addition to the searing pain.

So be prepared for strange looks in some social situations from those unaware of your ailment.

Anyways, the ErgoDox keyboard is currently the state of the art if ergonomics is being maximized for, all other keyboards are either completely incompetently designed and effectively not designed for human beings or suffer from more flaws than the ErgoDox does.

Researching ergonomic keyboards and ways to help recover from my injury as well as avoiding having the same thing happen again revealed that most keyboards had show stopping design flaws inherited from typewriters or as a result of maximizing for cost and ease of manufacturing rather than quality and usability.

As someone who wants to avoid re-injuring myself, uses a keyboard heavily, and uses emacs and vim as much as possible I choose what keyboard to use based on these qualities:

1) Modifier keys (shift, alt, control, and in my case option fn as well as another key to act as a fifth modifier so that I have hyper and super keys in emacs) must be accessible by the strongest digit humans have: the thumb.

Designing modifier keys such that they are solely accessed by the pinky while the other fingers remain on the home row, the least durable digit, is utterly bereft of intelligence.

The Kinesis Advantage and the ErgoDox satisfy this property.

2) Modifier keys must have a mirrored layout such that they exist in the same location on both sides of the keyboard.

The ErgoDox* and Kinesis advantage satisfy this property as well as the Truly Ergonomic.

The Truly Ergonomic does not feature an island for thumb keys though.

* Note that the ErgoDox is the only one that satisfies this if the user needs more than three modifier keys (alt, shift, ctrl).

3) When the hands are on the home row, the entire hand and forearm must be aligned perpendicular to the keys,* deviating from this is main contributor to RSI and why in part laptop keyboards are not comfortable to use for long periods of time.

Split keyboard designs are the best design for satisfying this requirement for as many users' body types as possible as the different halves can be arranged the appropriate width apart.

The split keyboard design is rarely found due to manufacturing complexity as well as increased component cost.

That requirement is why most keyboards can be immediately crossed for not being designed for humans.

The ErgoDox satisfies this property; as the degree of deviation from perpendicular alignment the worse the keyboard is to use in practice.

* Note that in the case of the fingers their differing lengths may be taken account for via a sunken key design which the Kinesis Advantage utilized where the fingers curl inward comfortably

Ideally, the keyboard design would also be such that it is trivially disassembled for regular maintenance, such as removing the grime that develops over time from using the device, however I have not found any keyboard which actually has this property; it is on my wish list for a keyboard.

4) While the fourth one is not necessarily a requirement, it is very nice to have and an expectation. I expect the keyboard to have quality components, which means no rubber dome switches used. Buckling springs, mechanical switches, or capacitive switches satisfy this.

Ergonomically speaking, capacitive switches require the least force to trigger a key input, however they also have no tactile feedback by themselves and as a result there is no indication while touch typing that the key was actually pressed.

Capacitive switches are the least popular due to their cost and also the need to modify them to have some sort of tactile feedback so that the user does not bottom out the keys.

Cherry MX switches are the most popular among quality keyboards, however there are other mechanical switches available such as the Topre ones.

What switches the user will prefer varies; however the user can modify them to require less force to depress or have greater tactile feedback if they wish or simply swap them out for another switch that still fits the keyboard. The Cherry MX switches fit the ErgoDox.

Personally, I like the Cherry MX Blues, but the Cherry MX Brows that the Kinesis Advantage uses also had a nice feel; your mileage may vary here.

On top of the switches and springs used, the keycaps can be independently sourced and swapped out through various manufacturers; depending on the manufacturing process the keycaps will have different properties, some having a flat design that appears on the DAS keyboard, others having a depressed surface.

While an entirely aesthetic choice, keycaps also come in many different colors; so if the user wants keycaps with pink elephants etched on top the surface that is possible.

So far, the ErgoDox keyboard has been the keyboard I have found the least flaws with, and I now use it over my Kinesis Advantage all the time except when traveling, at which point I am resigned to the unfortunate keyboard design laptops have.

The one flaw the ErgoDox has is that the island of thumb keys are not all comfortable and not awkward to access while having the fingers on the home row.

I think that the Grand Piano keyboard design (http://geekhack.org/index.php?topic=44940.0) will rectify that issue though, and I am very anxious to actually be able to purchase a keyboard that utilizes the design as a result.

I love my ErgoDox and consider it state of the art as previously mentioned, however Acidfire's design would have all of the features I like about the ErgoDox while fixing the issue with the thumb key placement that the ErgoDox and Kinesis Advantage have.

Fixing that will cause the thumb keys to be even more ergonomic for users like myself that want a control, shift, alt, fn, and a fifth mirrored key that is comfortable to use frequently in chords (a prominent design property in computing outside of designs employed by vi/vim).

I wish laptops followed the same design somehow while still not being massive in scale to accommodate that.

An 11" or 13" laptop with retina or better resolution with sufficient battery life to last 12+ hours per charge and an ergonomic keyboard available without using an external device is my ideal laptop, unfortunately such a laptop does not actually exist, so I will have to make due with only having 2 of those wants until then.

In addition to using an ergonomic keyboard though, I also regularly take breaks from using my hands, especially from typing and gaming, and use the colemak layout.

The workman programmer layout is hypothetically an even nicer layout for English, however not having that layout available by default in any OS is a deal breaker, so I use the colemak layout for that reason.

Using an alternative layout has not resulted in issues with touch typing in qwerty still, I can switch between the two fluently still; I was somewhat concerned that touch typing with a qwerty layout would become an issue starting out, but in practice it has not been a problem whatsoever.

I also use evil-mode in emacs and make use of meta, hyper, super, escape, shift, and control so that I can use key chords that only consist of a sequence of one modifier key plus a one non-modifier key in the vast majority of cases.

Having a hyper and super key in emacs allows me to avoid experiencing as much collisions that occur with default key bindings in emacs due to ctrl, meta, and shift becoming so overloaded in modes; I also abstract out common commands between modes to use the same chords consistently as they are not unified across emacs modes by default regrettably.

Doing so greatly reduces the solution space and required learning curve when changing between modes and states and implementing new features.

Aside from being a vim refugee, still using vim for some tasks, and being as lazy as possible to the point of aggressively eliminating anything that is redundant, potentially automated, and reducing what is reducible in effort, the reason I use evil-mode is that having access to vim's modal design makes per state bindings available as well as per mode bindings.

As a result not only do I have chords that are composed of merely two keys to issue a command thanks to having a hyper and super keys, I also often have to press only one button to accomplish a task thanks to the potency of vim's grammar.

All of these habits come together for a very comfortable and efficient computing experience with as little hazard as possible to my health without a career change, plus I have access to C-x M-c M-butterfly (https://xkcd.com/378/).

This article really removed some of my enthusiasm for Jetbrains products, even though I like them a lot.

It's incredibly ignorant and blatantly false to anyone knowledgeable about both.

As an example, I don't know how the author could claim that IDEAVim is comparable to the emulation either EVIL or ViEmu has, and that claim would not be so bold if IDEAVim was not a facsimile of even VI.

And using Python as an example to use in a lie is not very smart as it is one of the better supported languages in VIM for those trying to emulate an IDE's features to an extent.

It's not as though Jetbrains is trying to sell itself as a VIM replacement, that angle is nonsensical as one is an IDE and VIM's quite antagonistic to merging non-text editing features into the defaults.

Plus, lets assume the author's claims are true.

The author claims VIM is horrible, but then concludes by championing what the author just finished deriding as something PyCharm is a paragon of (VIM's design), what?

The article is incredibly distasteful and tries to sell a lie to an incredibly technical audience deft at parsing nuanced information that is much more knowledgeable about the domain than the author portrays.

There is no reason for Jetbrains to promote such base trash instead of continuing to stand on its own merits, which it has been doing well so far.

I hope Jetbrains has the integrity to at least apologize for the blatant stupidity on display in the article soon as it is horrible in all facets and very insulting.

I am a huge fan of VIM's design (and by extension EVIL http://www.emacswiki.org/emacs/Evil in Emacs, which is what I use most of the time), and I agree that all to most of this is achievable in Emacs.

I really like Jetbrains products though, and when I am on Windows those are my goto tools as I don't have the UNIX user space to leverage alongside Emacs or VIM.

They provide a great environment for those languages that don't have great support outside of commercial IDEs or for people turned off by Emacs/VIM.

My first experience was using IDEA for Java (both VIM and Emacs support for Java is an area where they are weakest somewhat surprisingly) and I was very happy with IDEA, so I tried PyCharm later on when I was on Windows and using Python there.

However, Emacs makes use of Python's REPL much more fluently than what I've experienced in PyCharm where the IDE has no interaction with the REPL outside of user engagement.

PyCharm in comparison seems entirely ignorant that it has a REPL it can exploit and integrating tightly with it would pay dividends.

Coming from Emacs where REPL integrations tend to have at least some sense of intelligence about them this was jarring.

PyCharm's intentions though are also very nice and isn't something I've found in Emacs or VIM to the same extent.

The IDE still has the same trait I've seen in Eclipse, VisualStudio, XCode, and Jetbrains' products though where it makes determining what the project entails into an overly complicated affair though, an area where VIM and Emacs have less red tape to get into.

There seems to be a great deal of improvement in that area for tools to get into where they are smarter without requiring so much user facing bureaucracy up front.

On one hand we have Emacs and VIM that largely pretend there is no such thing as a project and that tools could perform actions on that as a unit.

Then on the other side IDEs want to recognize that a project is an actionable unit and that it is a unit but then engage in 20 questions just to get started on a project and even after that get easily confused when moving files around.

Anyways, as far as IDEs go, Jetbrains' products have been the most enjoyable to use.

I do wish they were full open sourced though so that contributing improvements voluntarily wasn't a comparatively precarious trade off compared to VIM or Emacs or whatever open source tools you use.

Also, I wish IDEAVim was a lot nicer support of VIM's features than what it currently has so that I didn't have to want for some functionality at times.

Both the Emacs and VIM or typical IDEs have a lot of room for improvement in general though, tooling could be a lot nicer and homogenous across languages to the extent possible.

I really wish anyone would run with Bret Victor's idea of closing the feedback loop in programming (http://vimeo.com/36579366) adamantly and also implement Douglas Crockford's idea of scope based coloring everywhere (https://www.youtube.com/watch?v=dkZFtimgAcM), the latter of which I really want in functional languages like Haskell/OCaml.

Those two alone would add significant utility to the available tools.

After seeing Crockford's scope based coloring idea syntax based coloring seems incredibly superfluous even though I use it myself.

It really feels like we are in a tooling stone age with a great deal of retreading and regression in some respects despite having a lot more man-months thrown at the area.

I always use braces in order to protect my future self from my current self. I don't want to end up introducing a logic error in the program because I overlooked proper scope while less coherent later on.

Personally, I find both Lisp-1 and Lisp-2 easier to read (when it is pretty printed) than any other language syntax.

That the syntax or lack there of also expresses itself as an AST in addition to that is quite elegant.

Due to the reduction in syntax verbosity it is evident in the code what the important elements are as that is the only information displayed.

Lisp's syntax enables powerful utilities like Paredit to exploit that for unrivaled transpositions of the code as refactoring occurs.

I do think other syntax designs look more aesthetically pleasing on its face than what either Lisp-1 or Lisp-2 appear to the novice (the ML family of languages for instance) but it is something I have come to appreciate as my proficiency in Lisp has improved.

Code simultaneously being data and the converse as well is another elegant consequence of Lisp's design, so everything is optimized for the tail, which is what is important for tools and the environment to provide.

I wish the environment provided in other languages was as mature as that of Common Lisp (http://www.cliki.net/development), because it is immensely pleasurable to code in once the learning curve is overcome.

The quality of documentation and literature available for Lisp is also excellent, many of which are classics in Computer Science as a result and are worth reading regardless of actually using Lisp to develop with.

The analogy of Emacs learning curve being a fractal is quite appropriate I think if we take each fractal to represent an amount of time required to gain proficiency in modes that introduce significant amounts of features, with the smaller fractals representing modes that require less time to learn.

That sounds like chaos, but it captures Emacs platform nature and diversity of functionality well and seems true thus far as Emacs replaces more and more tools.

Emacs:Display Editor::Java:Program Execution

Rob Pike made an excellent point in one of his presentations on GO.

He pointed out that utilizing a language through a DSL or FFI that utilizes indentation instead of another method makes utilizing that language inside another language more difficult as it is easy to introduce bugs in the host language that are non-obvious to debug based on the indentation being incorrect but not obviously so.

I recommend watching all of his videos as they are very illuminating due to his primary focus being that of software engineering rather than theory.

Both arguments are not sound though, and as a result demonstrably irrelevant. The title of the thread and the argument in the GP is based on features present in ZSH but not Bash and the benefits there of.

The OP's first argument is: for all operating systems Bash exists. Which, while also untrue is and unrelated to whether ZSH has features or improvements that Bash does not. OP's second argument is: all ZSH users also program in D...., which I won't even bother with.

For what it is worth, I use both Bash and ZSH. Their usage and knowledge there of is not mutually exclusive. The only issue I've encountered with using ZSH is that most build scripts expect to be ran from Bash and will run into issues when that is not the case sometimes, so I open Bash before running the command if I happen to be in ZSH at the time.

If I based my tool choices on popularity instead of their appropriateness for the problem domain my work flow would look much different as well.

Emacs could gain a lot of performance boosts with some significant changes to its architecture. It would be a lot of work to do and doing so requires a set of skills that are much less available than other software engineering skills unfortunately. I am hoping either that occurs or there exists a viable replacement for Emacs that incorporates the improvements more easily due to starting with a blank slate.

Proprietary programs are a deal breaker for me as far as contributing to them in my free time a great deal due to how frequent they go out of business and lose support. So, a new iteration of Emacs would require a very free license for me to have confidence that my efforts won't be wasted in a short period later.

I am hoping that Light Table is released with a license and degree of openness that provides a similar degree of hackability as the Emacs platform does. If that happens I think I will make a lot of effort to bring it up to speed with features Emacs has but Light Table doesn't at the time.

Chris Granger has made a lot of smart design decisions that really appeal to me about Light Table. His point in one presentation that while Emacs and VIM are fantastic at text related operations, there doesn't exist something comparable that has both great support for text and great support for visualization.

That is a thought that really resonates with me. Having fantastic graphing capabilities and embedding of graphic tools such that the work flow can exploit both graphics manipulations and text operations would be a huge boost in capabilities, something which adding to Emacs would be much harder due to so much legacy code in the platform that will have to be accommodated in the process.

As an example, people have really wanted to move Emacs underlying language from elisp to common lisp for a long time, but it is such a massive undertaking and transitioning the community to using it would be so difficult that (without a team to work on it constantly) no one has succeeded in doing so fully.

Light Table's decision to use any language which can compile to javascript as its backend and use node-webkit as its front end results in a lot of features that are free in the process that are very nice to have for tool building.

And Granger has made a point to customize the compilers for the languages it supports to glean even more information and manipulation of the languages in the process, something which I hope is kept up as its support expands.

I absolutely love its instarepl design that is motivated by his idea of real time debugging. Combining that with Crockford's context or scope based coloring concept would be a massively useful feature set for development and tools to be able to exploit. The scope based coloring isn't something that Light Table has already or something Granger has mentioned adding, but it is something I hope enthusiasts can add assuming the platform is sufficiently extensible.

Granger's earlier idea of breaking down the environment based on functions as the smallest unit of focus instead of a file is another brilliant design concept that will be available in the future (according to another presentation he did).

So, I am very excited about its potential as a replacement for Emacs that takes that idea and makes it even better based on adding modern developments, and Granger seems to really appreciate open source and has a willingness to contribute towards that.

So, I am hoping that somehow the Light Table team is able to both charge for the tool and make it fully extensible as well as remove the potential for abandonment of the platform to result in a volunteer's effort being wasted, such as fully porting SLIME (a very exceptional lisp development environment that emacs has) to Light Table as well as ESS (a statistics development environment which could benefit from more graphics potential being available) that emacs has.

I think Light Table will already be a killer app for REPL centric platforms by the 1.0 release, and languages which have excellent REPL support and debugging is what I mainly use already. Adding the other features I mentioned will make it unquestionably the new state of the art for that context.

I am very impressed by this. Are their plans to integrate the software elsewhere such that it is available ubiquitously in every environment instead of just Android?

Fortunately computing hardware is improving at a faster rate than emacs is getting slower, so we are not interacting with molasses.

As of Emacs 24, either dynamic or lexical binding is available. Dynamic binding is the default though.

In answering this I will ignore details specific to the two tools (such as how the implementations are modified), the merits of either, how they are used, and only compare their design goals.

It is true that both tools are mutable and that hypothetically their potential use cases will overlap entirely.

The reason this will not occur though is a consequence of one tool aiming to provide a general environment by design and the other tool aiming to provide a general environment for a specific use.

Less abstractly, consider the difference between having a factory which produces a specific item and having a factory which can produce any factory.

Possibly the specific item the factory produces is sufficient for the recipients of the specific item, and further that specific item may even make other items the recipient possessed moot.

However, the factory which can produce any factory can still (and possibly already has done so) produce the specific item.

Emacs' design (and Light Table's) is much more similar in breadth to the factory which produces other factories.

Sublime Text is more similar in scope to a factory which produces a single item.

The difference in design choice leads to Sublime Text and other text editors being comparable in features and it is also why Sublime Text can replace Emacs' text editing functions.

At the same time the design choice also leads to Emacs being a RSS client but Sublime Text not also having that functionality (or being reasonable to expect), despite the potential for the functionality to exist in both tools.

The difference between the two goals is why Light Table is much more intriguing to me than Sublime Text is despite the utility Sublime Text provides and how well executed Sublime Text is.

Sublime Text will never be a plausible replacement for Emacs as its design does not encompass all of possibilities a lisp machine provides. Sublime Text is a plausible replacement for any tool which only targets text editing though. It has many converts or new users whose use case is only a text editor though, so to that extent Sublime Text has been successful.

Can you comment in generalities on the scope of changes to LT's behaviour end users can expect to be possible by design, e.g. the entire stack is modifiable to the extent that Emacs (even the underlying elisp interpreter) is modifiable, only via a limited API like Sublime Text 2 has (which results in end users being reliant on major changes coming from the top down), or something else entirely?

If a tool exists to format the code, it is of no consequence that a check in violates the formatting, as when that code is actually viewed it can (and should be) passed through that tool ahead of time such that the check in which violates the formatting guide lines is never actually viewed as such.

ASIC is an implementation of a circuit. They will be the fastest implementation of the logic, however they are the most expensive implementation of that logic by far.

Unlike FPGAs once logic is implemented in an ASIC the implementation is set in stone, so if there is a bug in the hardware fixing it will require producing an additional run and incur the expensive cost again.

The high cost is why FPGAs are popular for both prototyping and production units when possible as it is much cheaper for smaller quantities.

ASIC having exactly the logic necessary to target a task is why they are the most efficient at the task compared to general purpose hardware.

https://en.wikipedia.org/wiki/Application-specific_integrate...

It is a really useful term when used in its original context, rather than the way the term is commonly used now.

I agree that the article is well written for the scope the author targets, however I think it is disingenuous to group all PhD fields into the same demographic as the return on investment for pursuing that degree is not equivalent for each area.

Further, using only monetary reward as a metric for PhD utility is not reflective of the reasons why people pursue a PhD.

Even excluding monetary reward and the fact that a PhD is often required to do original research in industry (and receive a position as a professor at a university), the people pursuing a PhD are doing so because they are obsessed with the area they are studying and want to have sufficient knowledge to expand the available information known about the field.

The article is overly dismissive of knowledge being considered as its own reward among the demographic and eschews the trait to focus only on monetary reward, and as a result the conclusion is nonsensical by concluding that the smartest individuals in their areas of interest are habitually irrational actors.

An individual has to reach the giants to be able to stand on their toes so to speak and getting a PhD is often a requirement for even being given a chance to do so.

A more damning reason to not pursue a PhD is that the hours are insane and academia is increasingly less available as a career path, which for a lot of fields is the only option for employment that will utilize the specialized knowledge for a PhD holding individual.

It would be strange to claim to have invented something that already existed, but whose status exists only because people were unaware of it prior. People did not say that they invented gold when it was discovered for instance.

Spelt is a valid past tense and past participle of spell. http://dictionary.reference.com/browse/spelt?&path=/

Since you transitioned into full-time UX starting as a developer originally, I am curious as to what resources you utilized to improve your knowledge of good UX principles.

Technically Pi is a complex number that has the real number coefficient a = Pi and b = 0 resulting in a complex number of pi + 0j. This is because the set of real numbers is a subset of the set of complex numbers and Pi is an element of the set of real numbers.

Instead of starting from scratch perhaps implement utility in an existing editor that is in demand but not yet available for a fee.

There are a lot of things that would be nice to see in existing programs that a bounty type system would possibly work well to encourage.