I had my credit card out at "Vim Keybindings", only to be slightly disappointed by the Windows-only limitation (for now). Looking forward to try this out on Linux soon. Although I'm pretty happy with Vim, I'm curious to see if I'm missing out on a significantly better experience.
That being said, not a fan of a monthly subscription for a native desktop application.
For desktop applications I just translate the monthly subscriptions into yearly. Most software right now is sold as either yearly subscription or "year of upgrades" so it is one and the same.
If I can't use the software without an active subscription, it is definitely not one and the same. I like Sublime Text's license of 3 years of upgrade with a purchase, no limitation on usage of the software. Unclear (AFAICT from the FAQ) how it would work for CodePerfect 95.
I have some applications that are years old without upgrading to current version. Reason - the old version works fine and does everything I need. However if that's the case I sometimes decide to upgrade at some point to feed the developer.
I'd take that a step further and require that the PR fixes an existing issue opened by a different user. Go ahead and fix a typo too if you want, but that alone won't get you a t-shirt.
> The "Business Source License" is not an open source license, and lying to the community about it is nothing short of gaslighting.
They do state that it is not an open source license in the article:
> Although we’ve come to refer to the BSL as eventually open-source since it converts to an OSI-approved license at the conversion date, due to the grant restriction, it is formally not an open-source license.
Go's context is fine to signal cancellation, but it lacks a way to wait for that cancellation to complete gracefully. And the fact that it is also an arbitrary bag of values is concerning. It worries me that it started "polluting" the stdlib's API without solving those issues first. Dave Cheney wrote a good article about it: https://dave.cheney.net/2017/08/20/context-isnt-for-cancella...
I don't think you can expect a daily practice to have "an equivalent effect" to a 60-day retreat. I know there are 10-day retreats for vipassana meditation just about everywhere in the world (probably for many other types of meditation too), though I've never been to one (scares the hell out of me to be honest, must be so incredibly hard - both mentally and physically).
I recently started meditating for 20-30 minutes at a time, once or twice a day, and the eerie calmness that settles in when I'm done (for the "good" sessions) is a great feeling. I can only imagine what 10 and 60 days can do.
It's worth it. I've done two 10 day courses and you learn to develop your focus in ways that are pretty hard to believe without going through it.
I know about a dozen people who have done the 10-day Goenka course. It is definitely hard work because you are meditating for around 10 hours a day, but it isn't actually what I would call hard to do; all your needs and schedule are taken care of and you just give into it.
A lot of the resistance for me was actually preparing family and clients for me being completely offline and unreachable for 10 days, and going through that was a revelation separate from the benefits of the meditation.
The recommendation I give to everyone is that if you have any interest, just book a course several months out when you think you may be able to make it. If you end up not being able to or not feeling ready, then you can very easily cancel in advance, and there is usually a waiting list anyway. However, booking a spot seems to set the wheels in motion.
It's important to note that the sales line of this being purely practical without dogma is completely false. Goenka is very clear in the lectures that meditation is all about purifying yourself for reincarnation. There's tons of anti science stuff, like claiming Buddha knew more about physics than the inventor of the cloud chamber.
The entire time, he chants in a dead language, and they want you to blindly recite things in said dead language. He purposely plays with his accent and speaking in order to push a bit of mystical properties to what he's saying (repeating words over and over, laying on a thick accent, whereas at other times he is capable of speaking very clearly).
The actual practise may be fine, but I found the woo-factor to be incredibly high - false advertising.
> In Canada, and in a growing number of jurisdictions - there is 'harassment' so long as the victim feels as if there was.
Nonsense, it's still an uphill battle for victims to get their harasser convicted in Canada. See Jian Ghomeshi, Marcel Aubut and the First Nations women v. the police in Val d'Or for recent examples.
> A) I don't doubt it can be difficult for women - but my statement holds true.
That doesn't make any sense? You said:
> If a girl feels harassed - then that's it. Guilty.
Yet you go on and acknowledge that it may be hard to get their harasser convicted. In all those 3 cases I mentioned (including Ghomeshi), there were many victims that felt harassed. Yet no one in any of those cases was convicted. How does that make your statement true?
"Many valid incidents of harassment are dismissed/ignored, and many invalid/borderline incidents are punished unfairly, and therefore the current system sucks for everybody".
Yet you go on and acknowledge that it may be hard to get their harasser convicted
The structure of western government and judicial systems is set-up to make it hard for the individual to get convicted. This is why there is a 5th amendment. This is why "innocent until proven guilty" is a part of the Universal Declaration of Human Rights. (Supported by Eleanor Roosevelt.)
It's about protecting the individual against the group, even if the group is operating under the auspices of the state. If such principles are abrogated to convict a guilty man, then the state can start to abuse its authority to start convicting innocent men. Precisely such actions are what spurred the creation of the Magna Carta.
Just because someone advocates free speech for a White Supremacist, doesn't make them a White Supremacist. Just because someone advocates the 5th amendment for a an organized crime chief doesn't make them a mob supporter. Just because someone advocates for due process and innocent until proven guilty for an accused harasser doesn't make them an advocate of harassment.
"In all those 3 cases I mentioned (including Ghomeshi), there were many victims that felt harassed. Yet no one in any of those cases was convicted. How does that make your statement true?"
That's a fair point.
Because it was a criminal trial - not civic or employment suit, also, by blatantly lying, those women destroyed their own credibility.
He was definitely fired by the CBC - and I don't think anyone is questioning that. No trial or legal examination needed.
He should have been fired by the CBC long time ago - then those suits would have never come up.
> When you omit quotes the string ends at the newline.
> Preceding and trailing whitespace is ignored as are escapes.
>
> A value that is a number, true, false or null in JSON is
> parsed as a value. E.g. 3 is a valid number while 3 times is
> a string.
It is ambiguous only if you think it can be a completely useless format. If you decide to use it, chances are you considered it useful, and the only useful way this can parse is as a number, otherwise it would't be able to represent numbers, booleans and null. I'd say it parses pretty much as expected, and as such, contrary to other comments, you don't have to go back to the docs every so often.
The problem is that this is supposed to be a more-easily-readable form of JSON, but it requires consulting the docs to understand the meaning of something which is completely unambiguous in regular JSON.
> But the expense of extra lines of co[d]e come at significant maintenance costs.
All lines are not created equal.
if err != nil {
return err
}
Those 3 lines have very, very little maintenance cost.
The obvious must also be mentioned: less lines of code usually mean building on abstractions - the lines of code are in there, somewhere, but not in your code. Better hope that abstraction is well-tested. Of course it's all a matter of balance, but I disagree with "more lines of code is inherently a bad thing", which stated another way, would mean "cram as much information as possible in a single line of code".
In the end, lines of code are a bad metric of software.
Less than other lines, but I definitely would disagree with the doubled-up "very" on "little". In addition to simply being distracting and verbose, a core issue is that you have to make certain you always have the boilerplate and that you have to make certain it is always correct. Otherwise you just https://gotofail.com/ :(.
> Those 3 lines have very, very little maintenance cost.
These three lines are everywhere, give me no clear indication of whether they are intentional behaviour or merely a boilerplate-by-convention, and worst of all, they obscure the actual business logic.
Error handling does obscure the business logic when, as in Go, nearly every operation needs to be followed by a boilerplate guard clause.
Other languages (e.g. Java) have solved this problem quite elegantly over a decade ago with the introduction of Checked Exceptions[1].
Since this is the pattern that every Go program ends up emulating anyway, Google could save everyone a lot of work by just baking it into the language.
In the eternal words of Larry Wall:
The computer should be doing the hard work.
That's what it's paid to do, after all.
That's the right approach, but it's still decades behind what a decent programming language would give you for free. You have to copy-paste that "errWriter" definition for every possibly-error-raising method that you want to call, because go has no generics. If you want to write to two different writers, let alone a list of them, then you have to go back to the function-and-variable version, which is very boilerplatey and impossible to reason about when refactoring.
This just shows that, to avoid having do-and-check after every operation, the provider needs to invent several idioms because it's tedious to the consumer.
But now the consumer needs to know multiple idioms and recognise when they are being used. And the reader of the consumer code needs to know that the normal `err != nil` idiom is not being followed. All of which requires everyone involved to do more reading of source code than a "throws" line.
How is this simpler than having a single, universal concept of exception handling?
Your link describes (and encourages) exactly the laborious emulation of Checked Exceptions that I was talking about in my above comment.
It doesn't make the guard clauses disappear. It merely forces the programmer to manually aggregate them at a higher level with even more boilerplate code.
The "helper" function there introduces 10 lines of code (per function in which you want it), and doesn't even work if you call anything besides that one `write` in sequence.
Unchecked exceptions are for programmer errors. They are an important part of the language since humans (who write the programs) are error prone. They are unrecoverable by nature. Checked exceptions should only exist in situations where the caller can definitely recover from them. Arguably almost nobody does the latter correctly when choosing checked exceptions and the consensus is, as a result, this is the kind of exception that should have been omitted from the language.
Unchecked exceptions are for programmer errors. They are an important part of the language since humans (who write the programs) are error prone.
I should clarify: The wart is that programmers can introduce their own unchecked Exceptions. This should not be allowed since, as you say, unchecked Exceptions only make sense for unrecoverable runtime errors.
Checked exceptions should only exist in situations where the caller can definitely recover from them.
False dichotomy. Unchecked exceptions become part of the callee's method signature, i.e. the contract that the caller must fulfill.
Arguably almost nobody does the latter correctly when choosing checked exceptions
Baseless claim. I see many people using Exceptions correctly and elegantly, for error handling and flow control.
There are times when Go (et al) style multiple return values would better serve a function than exceptions.
For example, a function to parse a string into a number should return both a number-reference, and a flag of some kind (or maybe just an Option). Crap input should not generate an exception like out-of-memory or an I/O error. Trying to dereference the number w/out checking to see if the string was parseable COULD generate a not-mandatory-to-check exception, though.
I guess there is a certain amount of tension between the idea that functions/methods should document the kind of errors/exceptions they might have, and between the annoyance that is all the crappy do-nothing catch clauses that turn around and re-vomit wrapper exceptions that ultimately land in a "well, it didn't work" log message and punt, rather than really "handling" the original exception in any way, shape or form.
The further away from a "network server" you get, the less appealing Go gets. It's a general purpose language, but it's not entirely wrong to think of it as a DSL for writing network servers that happens to be useful for other some things.
Why doesn't lack of generics kill Go? Well, if you're working in Go's wheelhouse, []byte actually covers a lot of things and you're rarely that far away from it, because you're about to read or write a []byte real soon now. (I don't mean you always have one literally in hand, you probably marshaled in into a struct, just that you're often very close to either reading or writing it.)
Why does it work to have this error handling in Go? Well, when writing network servers or other basic cloud infrastructure, actually a lot of the errors require different handling on a case-by-case basis. Big ol' exception blocks around the whole operation are often hiding bugs, or at the very least, suboptimal exception handling. By contrast, when you're not writing the code to do all the nitty-gritty network operations it's a level of detail you don't want or need.
I think every single posted "success story" I've seen for Go has been a network server. I don't think I've ever seen one about how it really cleaned up my Android app, or how my game development was crashing and burning until I switched it to Go. I don't think this is a coincidence, nor do I expect to see one anytime soon, the recent Android support notwithstanding.
The most common maintenance task is reading an entire region of code, which costs in direct proportion to the number of lines. Bugs are also proportional to number of lines of code independently of language, http://programmers.stackexchange.com/a/185684 . So no, lines of code is a good metric.
(Though I wouldn't characterize it as "cramming"; better languages save lines by not requiring programmers to specify irrelevant detail rather than by packing more information into the same space).
As opposed to the bugs you didn't find in some other language, because your program was spitting out unhandled exception errors from random places at runtime.
An unhandled exception means the program stops rather than continue in an unexpected and possibly invalid state. The latter being what happens in C or Go.
And it's not like these two are the only possible error handling strategies.
That isn't really what happens most often. What happens is that the exception is caught and thrown out, or caught and printed (especially with java if you are using eclipse_.
You can't have your lunch and eat it too: if you want robust code, you -- the developer -- need to spend some time thinking about how you manage your errors. Go makes it all too easy to sweep those under the rug.
No it doesn't. You need to handle every error or your program will panic and crash. You are forced to think of and handle every error by the if err != nil construct.
The problem with verbose code, is missing the small difference in the boilerplate and creating new bugs.
It's the same problem with copy/paste code. With copy/paste code, it often has small changes that you can miss easily. You have to read every line of code to not miss the small variations. If the person bothered to generalize the copy paste code a bit, you can cover all cases in one spot, and be less likely to miss problems.
That being said, not a fan of a monthly subscription for a native desktop application.