Actually Goto doesn't have a problem; And it wouldn't matter in modern languages that deny access to that low-level instruction.
In basic you can use your labels and goto statements to create a hierarchy of dispatching routines. And if you're very disciplined about which global variables you use as flags to control the execution flow, i.e. which goto statement gets selected next, and which variables to hold return values, you could write a decent program.
The danger lies in that it allows the programmer too much range to produce low-quality code. The negative effect includes too much attention to the implementation of abstractions, instead of its usage. The existence of the goto statements can undermine other abstractions offered by the programming language.
Goto doesn't break structure of the code, programmers do. (I guess that's the whole reason we stopped using it: reducing the risk of making crappy software)
Certainly. Use of goto to implement structured programming is structured programming, but if you're implementing control flow structures that are provided by your language anyway why are you bothering to use goto? The result will be slightly less readable and slightly less maintainable. There remain a few places where a commonly used language doesn't implement the control structure that we'd want to use and goto can be a reasonable choice - the most common example is using goto to implement (limited) exception handling in C.
The point Dijkstra was trying to make is that humans are inherently incapable of dealing with that kind of detailed complexity, and still reliably make useful programs. That's why he proposed that goto should be excluded from all higher-level programming languages.
In my comment structured programming refers to using structured syntax to generate goto statements, so you don't have to see them or implement them yourself. It should free the programmer of considering those alternative ways of controlling program flow. Presence of goto statement points to a flaw in the language design.
To answer your question:
Because the basic language I'm referring to, was on my TI84-plus calculator, and it only had an if-statement (no if-else!).
"The point Dijkstra was trying to make is that humans are inherently incapable of dealing with that kind of detailed complexity, and still reliably make useful programs. That's why he proposed that goto should be excluded from all higher-level programming languages."
There is a very simple isomorphism between each of the typical control structures (sequencing, choice, and iteration) and its implementation with gotos. It's an easy mechanical translation, in either direction. I don't think Dijkstra was making any claim that spelling these control structures with goto radically increased the difficulty of programming. The important thing was using reasonable control structures (and only reasonable control structures) in the design of your program. Obviously, having the language do it for you is preferred much like any other mechanical translation - but that's not the key point.
"It should free the programmer of considering those alternative ways of controlling program flow. Presence of goto statement points to a flaw in the language design."
I don't disagree with any of that.
"Because the basic language I'm referring to, was on my TI84-plus calculator, and it only had an if-statement (no if-else!)."
That's still an example of using goto to implement missing control structures, not using goto when the control structure you want is present.
I'd increase the time a little at least a couple of times during the week. Because learning to programming or playing an instrument is like learning a language, and it requires some extended time of immersion to really make significant progress. An hour of focused practice is the minimum I need to really have noticeable progress.
Nice analysis/strategy description. I just want to add that one of the primary reasons why saas companies increase in size, is because they provide convenience. It seems that the SEO strategy increases convenience by having a relevant guide/tutorial for each use case. Which makes it easier for the short-in-time managers making the decisions whether or not to use this or that saas company's services.
Maybe. But just consider that GitHub popularized git among professional developers. I don't think it's the audience this initiative has to reach. Though it will certainly make crypto more accessible, I doubt that doing the analogous thing to github will give keybase the userbase that would most benefit from their services (less tech savvy people).
Maybe not in this incarnation, but when they roll out an API it could be baked into all kinds of things.
For example, consider a multi-service contact managers like the Windows Phone People Hub or Contacts + on Android. They let you establish a database that represents people as collections of identities across various services. These services could add a feature that discovers public keys hosted with keybase.io for your contacts based on proofs offered by the identities you've already mapped to each contact. This could be presented as a simple "have key yes/no" indicator, and symbols showing which service-identity pairs have vouched for that key, as well as warnings if any of the identities have vouched for a DIFFERENT key.
Obviously client-to-client is always best, but you could extend this model to cloud services, even email. It could provide an organic authentication layer.
Now, you can argue that it's only as secure as your twitter / github / domain. Fine. But your twitter / github / domain ARE you on the internet. For most purposes, you're just "User X on Service Y". It can be useful to be able to prove that outside of Service Y. In addition, it's really valuable to be able to have multiple "proofs". An attacker would need to compromise four separate services to successfully spoof your identity (keybase, twitter, github, domain). That's not impossible, but it is hard and probably slow, especially if you're using two-factor authentication.
Finally, you can add additional out-of-band proofs. Hand-deliver a print out of your key to your associates, then they can pin that proof in the client and use keybase of on-the-fly verification, comparing everything to the key you provided them at your cypherpunk birthday party.
Nice counter-argument, with the concession that this is more like git than it is github. It might really put crypto on the radars of, and make it accessible to, the developers involved in these cloud services - which would be the equivalent of github. A jquery plugin that simply allows developers to include a verify-identity-feature, would actually go a lot further in bringing the rewards of crypto services to the larger audience, imho.
I think this is a fair criticism. However, if keybase is done right, it provides a place for consumer-facing email and storage services to do trust-able key exchange, using trust mechanisms embedded in services consumers already use.
With or without keybase, it is up to the major services to enable email and storage that uses public key encryption to secure it, and to do that with open source clients that can be verified.
The advantages of the anonymous marketplace only really apply to people who's work is being suppressed (activists/journalists) or who's work is rightfully being persecuted (criminals). Maybe there's a case to be made that a lot of people do want to know who they're dealing with, besides that the system (algorithm etc.) thinks they're thrust worthy.
In countries like Venezuela, where government is enforcing laws for price control and shops are shutting down everywhere, an anonymous marketplace would be a godsend.
Citizens under totalitarian regimes are the ones who benefit most from crypto currencies, crypto messaging and crypto markets.
Yeah, I should have included that example. Just adding that repression on that scale actually merits regime change more than finding a workaround. Although the workaround might be more feasible in most cases. So, it's a good initiative.
You're making ad hominem attacks. Yes comparatively it is ridiculous to portray this as a major issue, but just because other people are less-off doesn't mean you should let yourself get screwed over. It's also worth considering that is a discussion on a tech-oriented website, so here it is important.
And you're basically right, it was a cost-benefit analyses. And it was illegal to act upon it the way they did, which is the whole point.
Absolutely if your an "engineer" on 150k pa you are still just a worker you still will face issues at work OK maybe slightly slightly different ones to say a semiskilled car worker or a Navvy might face.
But those sort of jobs dont face a lot of the issues that come with professional ones - if your a docker you boss is not going to trick you out of your vested stock and cost you millions ala silver lake partners.
About your two first paragraphs: Over time that market-mechanic would also have as an effect that all engineers have capped wages, because the cause for wage increases - negotiations - would significantly decline; Everybody, almost by definition, accepts the same wage-ranges.
It also introduces systemic risk for engineers, because then the wages could only go down over time. Because any attempt to look for a wage increase would be stopped short by the don't-share-employees-agreement. I also want to note that the companies in the best position to offer you a wage increase are the top-tech companies like Google and Apple.
And yes, compared to other people engineers have little reason to complain. But I still think this incident is a valid reason for complaint.
I also think you have a misunderstanding. Adam Smith is clearly explaining the reason for the more liberal wages from the perspective of the one who is to commence the study, and his likelihood of succeeding. Smith is pointing to the fact that liberal professions are inherently more difficult to master, and often provide a value that is more rare (and therefore worth more money).
You cannot turn this quote into a formula, because it's a description of how wages ought to be, and the reasons therefore. And it is completely irrelevant to discussion, as I'm sure if Smith were alive today, he would count the art of programming among the liberal professions. There is more to making a useful application than to be able to think mechanically. Because programmers create and shoemakers copy.
I wasn't addressing lawers v. programmers, but just the relationship between the cost of education and the wages expected from undertaking it.
Of course, today you could point to a plethora of professions for which a long and expensive education is required, but for which compensation lags, often painfully. Though in some cases job security may be higher.
In theory at least, wage should reflect responsibility and liability within the company. If you go over those of the CEO, you see why they make so much more money. They should be held accountable for the wealth of the entire company.
As far as lawyers are concerned, their wages just reflect the fact that they (should) have been trained as A-list negotiators, and it is common practice for lawyers to have a fee based on a percentage of the deal they negotiated.
There is a corollary for programmers for the above: start-ups. Though not trained negotiators, skill and work ethic can get you far enough. And it is common practice to receive a percentage of the reward.
In basic you can use your labels and goto statements to create a hierarchy of dispatching routines. And if you're very disciplined about which global variables you use as flags to control the execution flow, i.e. which goto statement gets selected next, and which variables to hold return values, you could write a decent program.
The danger lies in that it allows the programmer too much range to produce low-quality code. The negative effect includes too much attention to the implementation of abstractions, instead of its usage. The existence of the goto statements can undermine other abstractions offered by the programming language.
Goto doesn't break structure of the code, programmers do. (I guess that's the whole reason we stopped using it: reducing the risk of making crappy software)