Not everyone will become a software engineer. I learnt basic statistics in junior high and I never became a statistician. Still, it made it easier to understand charts, statistics, and help not getting duped by everything I read.
IMO everyone should learn basics... computers are in EVERYTHING we do. I was thought basics of electronics, woodworking, biology, math, foreign languages... a lot of things that are useful in every day life, but are much less ubiquitous. Why not basics of programming?
Then some will run away with it and become software engineering super stars. The rest won't, but will at least be able to understand enough to be able to communicate with the engineering department at their company, or maybe write little scripts on their own to automate stuff they do often.
Why not? Its -everywhere-. They should know at least enough to be able to ask questions about it.
That was my reaction too. Most people never learnt about public/private key encryption. Those who did forget pretty quickly.
I learnt it in college....13-14 years ago. Then I forgot, and while i always remembered the basics, I never really dug into it until recently when I wrote a MitM proxy for debugging purpose. Now I could explain it quite well, but last year? NOPE. I knew enough to be able to tell the difference between a seemingly secure system and an obviously insecure one. That's it.
Now, it doesn't change the fact that 95%+ of engineers are basically running a bullshit scam.
Cool. So now i have infinite free software. Unfortunately, my city tax bill came in, and they won't take free software as payment. I guess I can go and become a patent lawyer, I hear that pays pretty good, but I'll probably be a little too busy to write software then.
Right now, My main ways of justifying writing open source is (aside the fact that its a hobby and I do get enjoyment out of it) is: A) my github account makes for a powerful tool to negotiate my salary. You like what you see? You want more, and on your terms? Cool, now give me a hell of a salary. And B) My employer gives me time to work on open source because it helps the company brand, makes it easier to recruit, and saves a shitload on recruiter fees because people seek us out instead.
Thats pretty cool and is good enough for me...but I won't be writing the next Linux stack on that time.
Yup, and this is one of those ways. But if I charge you money for a piece of software you can copy (or god forbid, resell indefinately!), I'll only make a few sales.
So you can get donation, or sell services. The later works pretty damn well for most successful open source companies...but some stuff just doesn't work for it. If I make a end user centric operating system...no one's gonna pay for services/support for that. Workstations can get a support contract, but home user stuff? Nope. If I make a single player offline game? Nope.
There's a huge array of software that people love and are absurdly expensive to develop, and only have gimicks as funding method (I could sell merchandise for my game, woohoo...and everyone loves micro-transactions! All games should be Candy Crush!)
A lot of smart TVs are cheaper (by a lot) than the equivalent dumb TV of similar quality, because of the stupid ads and the "shop".
I have a panasonic viera. Works fine, the big channels are updated pretty frequently, etc.
I have a Roku, but often the image quality is better on the Viera apps, and it lets me have my 2 mostly used apps opened and just toggle between inputs, which is faster than switching app/channel on the roku or the viera themselves.
If i had to choose just one, I'd pick the Roku for sure... but I'm already using all 4 HDMI inputs, and TVs with more than that are fairly expensive, and HDMI splitters are pricey in themselves, so its tempting to just disconnect it since the only channel/app the Roku supports that Viera doesn't is Funimation, and that's flaky in itself.
Post is the only non-indempotent of the major http verbs. Its one of the core difference between Post and Put and why when you create a new resource without a natural id, you use post, not put...
Economy of scale. They make a profit because they're always using it. Spending $10/day on uber (enough for a roundtrip to work, if its just borderline too far to walk without getting sweaty, and annoying in winter) would be about $300/month, even if we count weekends. If you include gas, maintenance, etc, thats cheaper than a lot of cars. Now, that doesn't get you very far, so its probably not a very good example.
If you take the subway to work and only need a car to do groceries and get the cat to the vet though? Then uber wins hands down even if you take Uber black.
The paradigm and semantic is perfectly clean/correct. The roundtrip is just an implementation detail.
The protocol could simply return the result of the post with a redirect, as well as the result of the get, in 1 response. Then under the hood even though you do a GET, the get "chunk" of the post result would get rendered. No additional roundtrip.
This is already used in some context. Imagine I want to show you a server rendered image based on some query string generated in javascript or something (ie: nothing is known about the image to the initial page except how to request it). I also want to return the description of that image along with some metadata.
I set the image url in an img tag. The image is shown to you. The description of the image is returned in metadata/headers/whatever. It is being requested by an img tag, so I don't get access to its data. I can then to an ajax request for that image, which will get served from cache (no additional roundtrip) and get the data that goes with it.
(yeah, I could request the image and then set the data to the img tag. This was just a roundabout example).
That technique works today, and for some edge cases, it is actually being used in the real world. Making a post -> redirect -> Get without roundtrip wouldn't be very different from existing paradigms.
If I go through college and replace all my assignment with libraries, I'm barely going to have to code. Writing a Chess AI? No one would bother, there's some already implemented. Learning how to write sorts? Pffft.... sort is built in virtually every collection type of all mainstream languages, or at least its in the mainstream libraries..each is there even in most imperative languages, so you wouldn't be learning for loops either.
Obviously from the article's context, the assigment is to implement it, not use library functions. So you'll either be using some kind of imperative loop, or you're going to use recursion.
Thats already an issue. Lots of people don't end up in jail because of "they had mental issues!! omgomgtheyarevictims!" or they did what they did because they had a tough childhood and somehow its a factor that reduces their sentence.
The most we discover, the worse it gets. You have the ability to choose, of course. But what do you think makes your choices, beyond outside factors/uprising + hormones/biology/etc.
Hell, how well you slept last night probably affects your choices more than free will ever did.
I know its a joke, but not really. At the end of the day, humans are just fairly complicated machines, or even just a big complex chemical reaction.
Pretty much everything we do comes from either training/uprising, or from some biological system or another. As time goes, we'll figure out all of the later...and statistics will take care of the former.
When something happens and your guts flora goes out of wack, because of a previous illness, some surgery, whatever, your digestive system suffers quite a bit, and has no way to recover (those bacterias don't come out of nowhere...if 100% of them are gone, they're not coming back...).
So the only way to get them back is to transplant bacterias from someone else, to "bootstrap" your system anew. And the easiest way to get a bunch of those bacterias is in, well...yanno...
So they either take a piece and stick it in you, or they make a pill out of a little bit of it. Gross as hell, but less gross than dealing with a fucked up guts flora.
Backbone is a piece of shit. It had its time of glory, for like... 6 months. It has so many problems and design flaws, its ridiculous.
That said that isn't the point of React. If you want easy to use/maintain...yeah, you can use it, but there are significantly better libraries for that. The point of React is to generate the most efficient UI update batch job possible whenever you change your state, because if you do it yourself, either you'll end up with a totally absurd amount of code, or you'll do it in a sub optimal way. It also lets you use the same code to render the initial load on the server for deep linking and SEO purpose.
So basically React has the sweet spot between performance and maintainability. Most apps don't need that performance. If you just have a bunch of forms, a few menus, a couple of charts...whatever. Netflix was bragging on their blog about how awesome React was to them. You can look at their UI...it isn't a case where React was necessary. If they like it, sure, no problem, but it was just 1 of dozens of options that would have worked for them.
When you have a single page app with lots of interrelated dynamic updates happening constantly, then React is a good fit. Shit like Angular or Ember (even with htmlbar) go to a crawl in these scenarios no matter how good your code, and Backbone requires you to micro-manage your code like crazy.
For me it was classes and inheritance that drew me to coffeescript
Bad start, considering classical inheritance is a downgrade from prototypical... CS is just sugar over the built in stuff, but it basically does it worse than how a library could using the full power of javascript prototypal inheritance (ES6 has that same issue though, it was a big source of debates...). Now you have the issue where ES6 and CS inheritance are incompatible in very subtle ways...for most purpose they work together fine, but the super behavior is different, which can be awkward at best.
Personally, I don't see it as a dead-end
Its a deadend because they're late or don't have a path to use the new features. Generators were way late, getter/setters can't even be safely consumed in all cases (it introduces very subtle bugs) and can't be created, string templates are behind (I don't think CS has string templates yet?), and they don't have a plan to keep up with it. The maintainers generally start thinking "Oh crap, we need to introduce this feature somehow" once its natively supported by mainstream environments...which is way too late. And in some cases (again, classes/inheritance), they're incompatible, which will lead to some subtle, very annoying bugs.
The language features almost all come from other languages, so unless "Other JS Devs" do nothing but JS, you don't really have a leg up.
And no, I've never had an issue with debuggability
Yes, source maps will give you errors. You may even be able to use them in the debugger to set breakpoints. Its flaky at best. Getting error line numbers isn't debugging. Being able to load up the Blink V8 remote debugger and line by line/watch/set breakpoints/REPL using the same language you wrote the code in, is debugging, and you can't do that with any transpiled language. Using ES6 transpilers you can at least get close, and as features get supported in your environment (ie: io.js supporting generators), you can disable the transpile of features 1 by 1 and improve your debuggability.
Its gool to get exception line number...until your bug doesn't throw any exception. Then again, ruby devs seem to think binding.pry is modern debugging (and while Ruby IDEs usually offer modern debugging environments, they're usually so slow/unstable as to be unusuable... RubyMine fail). Even embedded C devs have access to better tools than that.
CoffeeScript is almost tied to Ruby. Its Javascript for people who like Ruby syntax, even if it costs them real debuggability (sourcemaps are meh with it, and the output code is terrible, no matter how much they argue until they're blue in the face that its beautiful... I had 20 lines of CS code get compiled to a single line of nested ternary operations before...that was fun...not).
While on that index Ruby went up, non-ruby people rarely hit CoffeeScript (they do, but in a significantly smaller ratio), and with ES6 around the corner and amazing transpilers for ES6 (that are actually debuggable), that eats away at it.
Its a technological dead-end (generators JUST got in master...node.js had time to get forked and the fork have a 1.0 release that supported them before CS added them...), so of course its going down.
Its not about the language, its about the ecosystem. ie:.NET may be somewhere in between java and scala, and the basic of the framework is the same, but if you do high end stuff, JVM languages and CLR languages are totally different. Different in how you debug it in production, different in what the standards are, different in what patterns people expect you to use when they build a library, different gotchas. And while you can pick up the basics in an afternoon, it can take years to really push it.
Doesn't fucking matter if you're doing yet-another-e-commerce-site (and if you are, why?). Really fucking big deal if you do something that's never been done before with a ridiculous amount of users.
Its pretty damn blazing on a nexus 6. The only real lag comes from the software encryption (which got better with updates, but its still not as fast as it should be).
Im personally fine with it, but loading up lollipop without encryption and the thing screams.
Orders of magnitude cheaper if you don't count the devs maybe... $0 in tools and software license, vs a few thousand for something fairly large, when your engineers + AWS (or data center, or whatever) cost you tens of millions, makes a minimal difference.
That said, it really isn't surprising. Its just incremental. Their devtool division has been slowing going toward this for years now.
Slashdot Mirror
Not everyone will become a software engineer. I learnt basic statistics in junior high and I never became a statistician. Still, it made it easier to understand charts, statistics, and help not getting duped by everything I read.
IMO everyone should learn basics... computers are in EVERYTHING we do. I was thought basics of electronics, woodworking, biology, math, foreign languages... a lot of things that are useful in every day life, but are much less ubiquitous. Why not basics of programming?
Then some will run away with it and become software engineering super stars. The rest won't, but will at least be able to understand enough to be able to communicate with the engineering department at their company, or maybe write little scripts on their own to automate stuff they do often.
Why not? Its -everywhere-. They should know at least enough to be able to ask questions about it.
That was my reaction too. Most people never learnt about public/private key encryption. Those who did forget pretty quickly.
I learnt it in college....13-14 years ago. Then I forgot, and while i always remembered the basics, I never really dug into it until recently when I wrote a MitM proxy for debugging purpose. Now I could explain it quite well, but last year? NOPE. I knew enough to be able to tell the difference between a seemingly secure system and an obviously insecure one. That's it.
Now, it doesn't change the fact that 95%+ of engineers are basically running a bullshit scam.
Cool. So now i have infinite free software. Unfortunately, my city tax bill came in, and they won't take free software as payment. I guess I can go and become a patent lawyer, I hear that pays pretty good, but I'll probably be a little too busy to write software then.
Right now, My main ways of justifying writing open source is (aside the fact that its a hobby and I do get enjoyment out of it) is: A) my github account makes for a powerful tool to negotiate my salary. You like what you see? You want more, and on your terms? Cool, now give me a hell of a salary. And B) My employer gives me time to work on open source because it helps the company brand, makes it easier to recruit, and saves a shitload on recruiter fees because people seek us out instead.
Thats pretty cool and is good enough for me...but I won't be writing the next Linux stack on that time.
Yup, and this is one of those ways. But if I charge you money for a piece of software you can copy (or god forbid, resell indefinately!), I'll only make a few sales.
So you can get donation, or sell services. The later works pretty damn well for most successful open source companies...but some stuff just doesn't work for it. If I make a end user centric operating system...no one's gonna pay for services/support for that. Workstations can get a support contract, but home user stuff? Nope. If I make a single player offline game? Nope.
There's a huge array of software that people love and are absurdly expensive to develop, and only have gimicks as funding method (I could sell merchandise for my game, woohoo...and everyone loves micro-transactions! All games should be Candy Crush!)
A lot of smart TVs are cheaper (by a lot) than the equivalent dumb TV of similar quality, because of the stupid ads and the "shop".
I have a panasonic viera. Works fine, the big channels are updated pretty frequently, etc.
I have a Roku, but often the image quality is better on the Viera apps, and it lets me have my 2 mostly used apps opened and just toggle between inputs, which is faster than switching app/channel on the roku or the viera themselves.
If i had to choose just one, I'd pick the Roku for sure... but I'm already using all 4 HDMI inputs, and TVs with more than that are fairly expensive, and HDMI splitters are pricey in themselves, so its tempting to just disconnect it since the only channel/app the Roku supports that Viera doesn't is Funimation, and that's flaky in itself.
Post is the only non-indempotent of the major http verbs. Its one of the core difference between Post and Put and why when you create a new resource without a natural id, you use post, not put...
Economy of scale. They make a profit because they're always using it. Spending $10/day on uber (enough for a roundtrip to work, if its just borderline too far to walk without getting sweaty, and annoying in winter) would be about $300/month, even if we count weekends. If you include gas, maintenance, etc, thats cheaper than a lot of cars. Now, that doesn't get you very far, so its probably not a very good example.
If you take the subway to work and only need a car to do groceries and get the cat to the vet though? Then uber wins hands down even if you take Uber black.
The paradigm and semantic is perfectly clean/correct. The roundtrip is just an implementation detail.
The protocol could simply return the result of the post with a redirect, as well as the result of the get, in 1 response. Then under the hood even though you do a GET, the get "chunk" of the post result would get rendered. No additional roundtrip.
This is already used in some context. Imagine I want to show you a server rendered image based on some query string generated in javascript or something (ie: nothing is known about the image to the initial page except how to request it). I also want to return the description of that image along with some metadata.
I set the image url in an img tag. The image is shown to you. The description of the image is returned in metadata/headers/whatever. It is being requested by an img tag, so I don't get access to its data. I can then to an ajax request for that image, which will get served from cache (no additional roundtrip) and get the data that goes with it.
(yeah, I could request the image and then set the data to the img tag. This was just a roundabout example).
That technique works today, and for some edge cases, it is actually being used in the real world. Making a post -> redirect -> Get without roundtrip wouldn't be very different from existing paradigms.
that was the whole point i was getting across. It was a rhetorical question =P
If I go through college and replace all my assignment with libraries, I'm barely going to have to code. Writing a Chess AI? No one would bother, there's some already implemented. Learning how to write sorts? Pffft.... sort is built in virtually every collection type of all mainstream languages, or at least its in the mainstream libraries. .each is there even in most imperative languages, so you wouldn't be learning for loops either.
Obviously from the article's context, the assigment is to implement it, not use library functions. So you'll either be using some kind of imperative loop, or you're going to use recursion.
Cool. Now someone implemented the forEach function. How did they without imperative loop construct?
Thats already an issue. Lots of people don't end up in jail because of "they had mental issues!! omgomgtheyarevictims!" or they did what they did because they had a tough childhood and somehow its a factor that reduces their sentence.
The most we discover, the worse it gets. You have the ability to choose, of course. But what do you think makes your choices, beyond outside factors/uprising + hormones/biology/etc.
Hell, how well you slept last night probably affects your choices more than free will ever did.
Point taken. I stand corrected.
I know its a joke, but not really. At the end of the day, humans are just fairly complicated machines, or even just a big complex chemical reaction.
Pretty much everything we do comes from either training/uprising, or from some biological system or another. As time goes, we'll figure out all of the later...and statistics will take care of the former.
Will be a very boring world probably, but...
When something happens and your guts flora goes out of wack, because of a previous illness, some surgery, whatever, your digestive system suffers quite a bit, and has no way to recover (those bacterias don't come out of nowhere...if 100% of them are gone, they're not coming back...).
So the only way to get them back is to transplant bacterias from someone else, to "bootstrap" your system anew. And the easiest way to get a bunch of those bacterias is in, well...yanno...
So they either take a piece and stick it in you, or they make a pill out of a little bit of it. Gross as hell, but less gross than dealing with a fucked up guts flora.
Backbone is a piece of shit. It had its time of glory, for like... 6 months. It has so many problems and design flaws, its ridiculous.
That said that isn't the point of React. If you want easy to use/maintain...yeah, you can use it, but there are significantly better libraries for that. The point of React is to generate the most efficient UI update batch job possible whenever you change your state, because if you do it yourself, either you'll end up with a totally absurd amount of code, or you'll do it in a sub optimal way. It also lets you use the same code to render the initial load on the server for deep linking and SEO purpose.
So basically React has the sweet spot between performance and maintainability. Most apps don't need that performance. If you just have a bunch of forms, a few menus, a couple of charts...whatever. Netflix was bragging on their blog about how awesome React was to them. You can look at their UI...it isn't a case where React was necessary. If they like it, sure, no problem, but it was just 1 of dozens of options that would have worked for them.
When you have a single page app with lots of interrelated dynamic updates happening constantly, then React is a good fit. Shit like Angular or Ember (even with htmlbar) go to a crawl in these scenarios no matter how good your code, and Backbone requires you to micro-manage your code like crazy.
And now with the rollover data, if you're just an average user, you effectively have unlimited without needing an unlimited plan.
I have a 3gb plan, I don't use it much, but when i go in vacation then I can go through several times that.
Now I'll basically never run out.
For me it was classes and inheritance that drew me to coffeescript
Bad start, considering classical inheritance is a downgrade from prototypical... CS is just sugar over the built in stuff, but it basically does it worse than how a library could using the full power of javascript prototypal inheritance (ES6 has that same issue though, it was a big source of debates...). Now you have the issue where ES6 and CS inheritance are incompatible in very subtle ways...for most purpose they work together fine, but the super behavior is different, which can be awkward at best.
Personally, I don't see it as a dead-end
Its a deadend because they're late or don't have a path to use the new features. Generators were way late, getter/setters can't even be safely consumed in all cases (it introduces very subtle bugs) and can't be created, string templates are behind (I don't think CS has string templates yet?), and they don't have a plan to keep up with it. The maintainers generally start thinking "Oh crap, we need to introduce this feature somehow" once its natively supported by mainstream environments...which is way too late. And in some cases (again, classes/inheritance), they're incompatible, which will lead to some subtle, very annoying bugs.
The language features almost all come from other languages, so unless "Other JS Devs" do nothing but JS, you don't really have a leg up.
And no, I've never had an issue with debuggability
Yes, source maps will give you errors. You may even be able to use them in the debugger to set breakpoints. Its flaky at best. Getting error line numbers isn't debugging. Being able to load up the Blink V8 remote debugger and line by line/watch/set breakpoints/REPL using the same language you wrote the code in, is debugging, and you can't do that with any transpiled language. Using ES6 transpilers you can at least get close, and as features get supported in your environment (ie: io.js supporting generators), you can disable the transpile of features 1 by 1 and improve your debuggability.
Its gool to get exception line number...until your bug doesn't throw any exception. Then again, ruby devs seem to think binding.pry is modern debugging (and while Ruby IDEs usually offer modern debugging environments, they're usually so slow/unstable as to be unusuable... RubyMine fail). Even embedded C devs have access to better tools than that.
CoffeeScript is almost tied to Ruby. Its Javascript for people who like Ruby syntax, even if it costs them real debuggability (sourcemaps are meh with it, and the output code is terrible, no matter how much they argue until they're blue in the face that its beautiful... I had 20 lines of CS code get compiled to a single line of nested ternary operations before...that was fun...not).
While on that index Ruby went up, non-ruby people rarely hit CoffeeScript (they do, but in a significantly smaller ratio), and with ES6 around the corner and amazing transpilers for ES6 (that are actually debuggable), that eats away at it.
Its a technological dead-end (generators JUST got in master...node.js had time to get forked and the fork have a 1.0 release that supported them before CS added them...), so of course its going down.
Its not about the language, its about the ecosystem. ie: .NET may be somewhere in between java and scala, and the basic of the framework is the same, but if you do high end stuff, JVM languages and CLR languages are totally different. Different in how you debug it in production, different in what the standards are, different in what patterns people expect you to use when they build a library, different gotchas. And while you can pick up the basics in an afternoon, it can take years to really push it.
Doesn't fucking matter if you're doing yet-another-e-commerce-site (and if you are, why?). Really fucking big deal if you do something that's never been done before with a ridiculous amount of users.
+1 for that. Semver is awesome.
Its pretty damn blazing on a nexus 6. The only real lag comes from the software encryption (which got better with updates, but its still not as fast as it should be).
Im personally fine with it, but loading up lollipop without encryption and the thing screams.
probably the old nexus 7, as factory images for 5.0 for the 2013 one just came out. Its really buggy, but other devices dont have that issue
Congratulations, you described the software engineering world in general. Tried JavaScript, Ruby or the JVM world lately?
You -may- be ok with Python, i guess. But even that depends on what version you're looking at.
Orders of magnitude cheaper if you don't count the devs maybe... $0 in tools and software license, vs a few thousand for something fairly large, when your engineers + AWS (or data center, or whatever) cost you tens of millions, makes a minimal difference.
That said, it really isn't surprising. Its just incremental. Their devtool division has been slowing going toward this for years now.