I'd mod you up if I had the points to do so. My team develops locally on Macs or Ubuntu, then pushes to CI in the cloud, which builds deployable artefacts and deploys to cloud environments. All our cloud environments are interchangeable and if they were all ARM, I'd lose very little, since I already can't run them locally. (Well, actually, I could with some scripts around Docker and/or Kubernetes, but nobody on my team has ever had occasion to.)
Just use a kanban board on the wall to practice agile without jira. Works great if everyone is in the same room. You absolutely need source control though. You don't need branching necessarily.
Your advice to do what works for your team is great. But your advice not to read books... not so much. Reading books is one of the best ways to learn and grow. The underlying theory that explains _why_ things work for your team is not at all obvious and deserves concentrated study.
I don't think you properly read the post to which you are replying. Their first sentence wasn't meant to be read literally, as their second sentence makes clear. They were simply pointing out that it's easy to make blanket assertions that aren't really true. The particular assertion-that's-not-really-true is the following:
> More cores are worthless for most tasks.
This statement would be _definitely_ true if you'd said, "more cores are worthless for _many_ tasks". Now it's far too easy to assume that everyone on the Internet is a total idiot. But the truth is that many people aren't (well we all are, some of the time). It's really best to give people the benefit of the doubt.
In particular, if someone claims that a million core is a lot of performance, it doesn't necessarily mean they don't know what can and cannot be done with those cores. Especially if they describe spinning up lots of cores on AWS as a stunt.
Google, Amazon. Netflix and the people who build and use super-computing clusters all use lots of cores. And they know what they're doing.
In another post, you also said this:
> compared to on-chip or at least on-board multiprocessing, the network is really, really slow
This is, of course, true. But it's not the whole story. The "network" and "on-board" aren't quite as distinct concepts as they once were. Especially in a datacentre or super-computing cluster. In practice, network latencies are often surprisingly small. (And, conversely, the latency within a CPU or board is often surprisingly high - they're full of networks these days) The plain fact is that super-computing clusters (and the datacentres they resemble) get more work done than if they had a single CPU.
We'd all like faster cores. But the people scaling horizontally are not idiots.
I agree with you that browsers can already run arbitrary code. And that wasm will be built into the browser. And that any bug would be a problem.
But wasm isn't just a standardisation of asm.js. It's more that asm.js is highly influential prior art. In 2015, Brendan Eich did say that wasm would be 'initially co-expressive with asm.js' but that's only approximately true of what actually shipped. See the start of the wasm FAQ: https://github.com/WebAssembly...
* 'View source' will display the text version of wasm. * JavaScript is often minified or obfuscated too. * Wasm supports sourcemaps, arguably better than JavaScript does. * Most people get their sourcecode from github rather than 'view source' these days.
... Web Assembly is just a more compact serialization (binary instead of text) of a subset of EcmaScript/JavaScript.....
Much of what you say is morally true. But it's not technically true.
It's true that wasm is a binary serialisation of an abstract syntax tree (AST) but that AST is defined _without reference to JavaScript_, see https://github.com/WebAssembly... . In contrast, the asm.js spec is genuinely a subset of JavaScript.
You're right that wasm doesn't introduce new capabilities to the browser as such. In the current 'MVP' version of wasm, the only way to invoke web assembly is via JavaScript, and the only way for wasm code to interact with the browser is via JavaScript.
But it does make certain scenarios, such as running large compiled C programs, much more practical. It is, by design, a far more efficient compilation target than JavaScript or asm.js, see https://github.com/WebAssembly... . For example, we can expect Unity running on wasm to become commonplace, see http://webassembly.org/demo/.
...if there are security issues with WAsm, they're also present in plain JS,...
You can't be sure of that. The wasm codepaths will reuse much of the existing JavaScript execution engine but there will be new code and that new code could - and probably will - have security vulnerabilities. But probably no more than any other major browser feature.
I'm not so sure the parent poster means that we need to eat sugar, merely that it's the main energy source in our blood. The second paragraph of the paper you quoted implies as much:
> Blood glucose concentrations around 30 mg/100 ml were recorded consistently during the last 8 months, although the patient was ambulant and attending as an out-patient.
If I understand the paper correctly, that patient ate no sugar (or indeed, anything else) and yet they maintained sugar in their blood. Clearly, their body had manufactured it from other things.
It's possible that you're actually in some agreement than the parent poster. You both think it's a bad idea to eat lots of refined sugar, don't you? I speculate that they think it's fine to eat apples - certainly I do. What about you?
When I first heard of high fructose corn syrup, I thought it would have much more fructose in it than sucrose does. But, according to wikipedia, it's a bit more complicated than that. For example, the typical proportion of fructose in HFCS in soft drinks is "only" 65%, which is "only" 15% more than sucrose. I'm not saying that 15% more than sucrose doesn't matter, of course, I'm just saying that the amount of fructose in HFCS varies.
If you install an x server - there are quite a few of them - then you can run pretty much any Linux-based terminal. It works fine - it was the first thing I tried.
Mod parent up. Turns out that problems that are impossible to solve in the general case often have solutions for most common cases. It's hard but really smart people have made real progress. And you can use the fruits of their efforts in SAT or SMT solvers. (As a programmer, your tools might well be using them without your knowing.)
This advice assumes that the type system can't keep track of the units. If you have a programming language that can do that - and many the better ones can - you should let the compiler do the work.
It's the other way round: closures shot dynamic binding dead. In general, lexical scoping is better for programming languages than dynamic scoping, in both theory and practice.
Javascript has both lexical and dynamic scoping: 'this' is dynamically scoped and everything else is lexical. While 'this' is used extensively in Javascript, it's really a mistake. You can do all the useful 'this'-style things with closures alone, and it's easier to reason about.
Yes! The creators of Chicken Scheme think that it's more usable than C, at least under some circumstances, or they wouldn't have bothered creating it. That's the main point of compilers: they convert from the language you'd like to use into one that some machine will execute. Of course, you _could_ go the other way - C into Chichen Scheme - but nobody has any motivation to build that.
The compiler also guarantees certain properties of the object code. In a language with types, a successful compilation amounts to a proof by construction of the corresponding logical propositions (see https://en.wikipedia.org/wiki/...).
The first sentence of that wikipedia page you linked says that it's free and open source (with those words hyperlinked to their definitions). It's developed on github like any other open source project.
No they don't. The Java or C# null is not None. The C# Nullable type is like None. The main practical difference is that _all_ reference types in C# and Java have null but in a language without null, only Option types have None.
Slashdot Mirror
I'd mod you up if I had the points to do so. My team develops locally on Macs or Ubuntu, then pushes to CI in the cloud, which builds deployable artefacts and deploys to cloud environments. All our cloud environments are interchangeable and if they were all ARM, I'd lose very little, since I already can't run them locally. (Well, actually, I could with some scripts around Docker and/or Kubernetes, but nobody on my team has ever had occasion to.)
Just use a kanban board on the wall to practice agile without jira. Works great if everyone is in the same room. You absolutely need source control though. You don't need branching necessarily.
Your advice to do what works for your team is great. But your advice not to read books... not so much. Reading books is one of the best ways to learn and grow. The underlying theory that explains _why_ things work for your team is not at all obvious and deserves concentrated study.
Care to share your experiences of them? I sense anger in you but there is hope.
I don't think you properly read the post to which you are replying. Their first sentence wasn't meant to be read literally, as their second sentence makes clear. They were simply pointing out that it's easy to make blanket assertions that aren't really true. The particular assertion-that's-not-really-true is the following:
> More cores are worthless for most tasks.
This statement would be _definitely_ true if you'd said, "more cores are worthless for _many_ tasks". Now it's far too easy to assume that everyone on the Internet is a total idiot. But the truth is that many people aren't (well we all are, some of the time). It's really best to give people the benefit of the doubt.
In particular, if someone claims that a million core is a lot of performance, it doesn't necessarily mean they don't know what can and cannot be done with those cores. Especially if they describe spinning up lots of cores on AWS as a stunt.
Google, Amazon. Netflix and the people who build and use super-computing clusters all use lots of cores. And they know what they're doing.
In another post, you also said this:
> compared to on-chip or at least on-board multiprocessing, the network is really, really slow
This is, of course, true. But it's not the whole story. The "network" and "on-board" aren't quite as distinct concepts as they once were. Especially in a datacentre or super-computing cluster. In practice, network latencies are often surprisingly small. (And, conversely, the latency within a CPU or board is often surprisingly high - they're full of networks these days) The plain fact is that super-computing clusters (and the datacentres they resemble) get more work done than if they had a single CPU.
We'd all like faster cores. But the people scaling horizontally are not idiots.
> analized
I think this was a typo.
I agree with you that browsers can already run arbitrary code. And that wasm will be built into the browser. And that any bug would be a problem.
But wasm isn't just a standardisation of asm.js. It's more that asm.js is highly influential prior art. In 2015, Brendan Eich did say that wasm would be 'initially co-expressive with asm.js' but that's only approximately true of what actually shipped. See the start of the wasm FAQ: https://github.com/WebAssembly...
What you say is true.
But to be fair to wasm:
* 'View source' will display the text version of wasm.
* JavaScript is often minified or obfuscated too.
* Wasm supports sourcemaps, arguably better than JavaScript does.
* Most people get their sourcecode from github rather than 'view source' these days.
... Web Assembly is just a more compact serialization (binary instead of text) of a subset of EcmaScript/JavaScript.....
Much of what you say is morally true. But it's not technically true.
It's true that wasm is a binary serialisation of an abstract syntax tree (AST) but that AST is defined _without reference to JavaScript_, see https://github.com/WebAssembly... . In contrast, the asm.js spec is genuinely a subset of JavaScript.
You're right that wasm doesn't introduce new capabilities to the browser as such. In the current 'MVP' version of wasm, the only way to invoke web assembly is via JavaScript, and the only way for wasm code to interact with the browser is via JavaScript.
But it does make certain scenarios, such as running large compiled C programs, much more practical. It is, by design, a far more efficient compilation target than JavaScript or asm.js, see https://github.com/WebAssembly... . For example, we can expect Unity running on wasm to become commonplace, see http://webassembly.org/demo/ .
...if there are security issues with WAsm, they're also present in plain JS,...
You can't be sure of that. The wasm codepaths will reuse much of the existing JavaScript execution engine but there will be new code and that new code could - and probably will - have security vulnerabilities. But probably no more than any other major browser feature.
I'm not so sure the parent poster means that we need to eat sugar, merely that it's the main energy source in our blood. The second paragraph of the paper you quoted implies as much:
> Blood glucose concentrations around 30 mg/100 ml were recorded consistently during the last 8 months, although the patient was ambulant and attending as an out-patient.
If I understand the paper correctly, that patient ate no sugar (or indeed, anything else) and yet they maintained sugar in their blood. Clearly, their body had manufactured it from other things.
It's possible that you're actually in some agreement than the parent poster. You both think it's a bad idea to eat lots of refined sugar, don't you? I speculate that they think it's fine to eat apples - certainly I do. What about you?
I'd mod you up if I had mod points.
When I first heard of high fructose corn syrup, I thought it would have much more fructose in it than sucrose does. But, according to wikipedia, it's a bit more complicated than that. For example, the typical proportion of fructose in HFCS in soft drinks is "only" 65%, which is "only" 15% more than sucrose. I'm not saying that 15% more than sucrose doesn't matter, of course, I'm just saying that the amount of fructose in HFCS varies.
https://en.wikipedia.org/wiki/...
How to you back up your text file? How do you secure those backups?
I am and I can. I think your statement is more about your imagination than it is anything else.
Breaking break is a known bug in a beta release. It's not in any production release.
Lots of things don't run on Cygwin that do run on Ubuntu/WSL. And Ubuntu/WSL is more like Ubuntu than Cygwin is.
If you install an x server - there are quite a few of them - then you can run pretty much any Linux-based terminal. It works fine - it was the first thing I tried.
Parent said Win32, not 32 bit. Win32 is another name for the Windows API and doesn't imply any specific bitness any more.
In my (unasked) opinion, Windows 10 is better than Windows 8.1. Most things are!
Mod parent up. Turns out that problems that are impossible to solve in the general case often have solutions for most common cases. It's hard but really smart people have made real progress. And you can use the fruits of their efforts in SAT or SMT solvers. (As a programmer, your tools might well be using them without your knowing.)
This advice assumes that the type system can't keep track of the units. If you have a programming language that can do that - and many the better ones can - you should let the compiler do the work.
It's the other way round: closures shot dynamic binding dead. In general, lexical scoping is better for programming languages than dynamic scoping, in both theory and practice.
There's lots of information on the Internet about this but here's a quick link: https://courses.cs.washington....
Javascript has both lexical and dynamic scoping: 'this' is dynamically scoped and everything else is lexical. While 'this' is used extensively in Javascript, it's really a mistake. You can do all the useful 'this'-style things with closures alone, and it's easier to reason about.
They could always let in immigrants to do it.
Its main competitor is Facebook's Flow, https://flowtype.org/ . They're influencing each other, in a good way.
Yes! The creators of Chicken Scheme think that it's more usable than C, at least under some circumstances, or they wouldn't have bothered creating it. That's the main point of compilers: they convert from the language you'd like to use into one that some machine will execute. Of course, you _could_ go the other way - C into Chichen Scheme - but nobody has any motivation to build that.
The compiler also guarantees certain properties of the object code. In a language with types, a successful compilation amounts to a proof by construction of the corresponding logical propositions (see https://en.wikipedia.org/wiki/...).
The first sentence of that wikipedia page you linked says that it's free and open source (with those words hyperlinked to their definitions). It's developed on github like any other open source project.
The license is Apache 2.0:
https://github.com/Microsoft/T...
No they don't. The Java or C# null is not None. The C# Nullable type is like None. The main practical difference is that _all_ reference types in C# and Java have null but in a language without null, only Option types have None.
C does have technical problems including lack of memory safety and null pointers. The state of the art has moved on.
Not that TIOBE has anything to do with that. But if you think C's only problems are PR, think again.