Really? I like the REPL, but I wasn't aware that they had fixed the entanglement issues.
Thanks to Roslyn being designed explicitly for these kinds of scenarios, it can give you helpful information from nearly every stage of the compilation progress. You can get syntax trees! Not only that, you can feed it an invalid program and you'll get back a syntax tree that says that it's invalid, but knows when it stopped parsing, what kind of token it expected and can be stringified to the exact text you fed it. You can do flow analysis. There's a solidified model for how C# works in a REPL or scripting environment outside of everything-is-in-a-class mode, which admittedly it was never up to Mono to define.
csharp-repl is a very good REPL and the mcs family (which now seems to be merging into a single compiler) are very good compilers with source readily available, but I think it takes something that's designed from the start for reusability and being a library as much as a tool to get you these things.
The "dynamic code execution" just builds on top of support that's already there. You could build a string of a C# program, feed it to a compiler and run it dynamically previously as well. This just makes the compilation part less of a headache.
Rigging GCC (other comments have already brought up clang) would maybe be more dangerous because arbitrary C code could do anything. Arbitrary IL code can be hamstrung by some security layers. Of course, the differences between managed and native code pale in comparison to what permissions they are executing with, the robustness of any jailing or sandboxing that might be in place and so on.
If you worry that people can compile programs into executable code, you're not worrying about the right thing. You could write a C compiler in JavaScript or QBASIC. You should be worrying about what happens when that code executes.
I'm not about to debate anyone on the Visual Studio segmented pricing, but Anders Hejlsberg has gone on record saying he'd like for Roslyn to be open source, by which he likely means Ms-PL. If they do that, they could indeed close it later, at the cost of an enormous shitstorm. (When Microsoft has stopped providing open source before, they've stopped developing the software (see: Rotor). This is the new version of the C# compiler and its IDE integration so that's not going to happen.)
There are already APIs to emit IL or to invoke a C# compiler built into.NET and the security systems built into.NET give you a way to prohibit them. There's no additional risk exposed by Roslyn. Rather, it's a way of getting at the juicy knowledge about the code that the compiler builds up before it exits and that libraries have been written to poorly piece together. That's a good idea that I'd like to see accompany more official language compilers, static or not.
Seems to me like arbitrary external expansion is worth it. That doesn't mean everyone will need it (or that HDMI and USB 3 aren't both great things to build in regardless), but it's just what the doctor ordered for a docking station or external enclosures. You can basically add whatever gear you'd like to, for example, a MacBook Air form factor laptop. Adding some limited, predetermined expansion has been possible before with purpose-built docking connectors and matching docks, but all this needs is the physical port and you can add what you wish.
You could upgrade basically everything in that computer but the CPU and the RAM, and you could chain those expansions together such that you cart around a lightweight laptop up until when you get to your desk, where you plug in one plug and everything comes online. You can have a laptop when you need a laptop and a desktop when you need a desktop with few tradeoffs. That's interesting, but you're right that it's not interesting for the reasons that HDMI and USB 3 are helpful. They are complementary ideas.
The back button is different from the up button, and I want them both because they're both useful for their respective uses. Windows 8 coincidentally has them both, as did Windows XP.
Serves me right then, but assuming someone that knows the correct spelling and meaning of "köttkvarn" to be Swedish is generally a low-risk bet.
If fingers are crossed in plain view, then it has the connotation of hopeful intent. If they are crossed while concealed - such as behind one's back or under a table - then the implication is that one is lying. The assertion that one's fingers were not crossed would be necessary only if one or both hands were not in plain view, so the association would be an untrustworthy denial of lying.
Certainly, but in written form, you'd have to point out that your fingers were crossed no matter which meaning you were aiming for. So the matter of pointing out that one's fingers were crossed didn't make it clear, the surrounding context did.
So it seems from the other replies that "crossing your fingers" in that way is used by at least some English speakers as well. Neat. Didn't know that, primarily because Swedish English education teaches that it is a false friend since "crossing your fingers" is already something else in English.
With this in mind, I'm not surprised that AliasMarlowe is Swedish per the above because I've never heard a native English speaker use it in that context.
Helpful tip: Having your fingers crossed while saying something only means what you think it means (that you're lying) in Swedish, not in English. In English, it means you're hoping for a particular outcome, which could be true in this case too, I guess.
18 may mean diddly squat for you when you're not using a 24 hour clock, but I bet you know the difference between 2 AM and 9 AM. The 24 hour clock just extends the same idea to all hours. Having to cart around two digits and a letter seems like more work than just two digits, even if neither of the two are crushing work as such once you're used to them.
And for the record, yes, most people in a 24 hour clock country don't say "we'll meet at 18" but "we'll meet at 6 in the evening". But they also say "we'll meet at noon" instead of worrying about which of 12 PM and 12 AM is noon and which is midnight. It seems like people assume that "24 hour people" want their time in one strict format, when it's more often about just being clear with what you mean.
Fair enough; I know far less about the specifics than even Randall does. I thought the main source of nonsense was the "WHAT DID THEY USE UNMODIFIED HIV WTF".
Wasn't the point of the xkcd joke precisely that it was not real HIV, but that it's a hard sell regardless to pitch anything based on HIV or its way of spreading as a solution?
Define standard. If you mean standards-based, we're there. Many of the vendor prefixed CSS properties are initial implementations of standards, and many of them have since graduated to actual standards. Even the ones that are made up by a vendor (like the canvas element) are written up, submitted, improved and adopted; a far cry from attempts to insert a box with a new environment in the middle of everything (ActiveX, Silverlight, Flash, Java; the list goes on). NaCl looks like a more well-meaning version of those boxes. With Chrome OS and the pain of NPAPI plugins, I understand why Google would want it in Chrome. The case isn't so clear for the rest of the world.
The vendor prefix is a symptom of incremental adaptation of lots of smaller features. I prefer it to necessarily waiting five years to start using an entire versioned standard.
You're right, buying a tablet because it's a cool new must-have tech gadget is idiotic. Buying a tablet because it has a dual-core processor makes much more sense!
If you change enough of your hardware, including motherboard, you need to reactivate Windows.
There have also been weird licensing terms for a number of products (Oracle and certainly Windows Server versions) that don't make much sense or skyrocket when you combine the concepts of actual socketed CPUs vs CPU cores vs virtualized CPUs.
It's not exactly weird that FSF GCC is behind on Apple's improvements to their own language to run on their own OS, especially since Apple decided to not track GCC development shortly after starting clang.
My point (and yours too, it seems) was more that clang is a cleaner and more well-maintained architecture than at least the version of GCC that Apple left. The layering had grown crooked in GCC. Some things, like GCC's breadth of optimization, extensions, target architectures and bug compatibility support, can only be solved by adoption and maturing over time.
Is your argument really "well, *I* haven't heard of it, so it can't be that good"?
clang, the LLVM-based compiler for C/C++/Obj-C that Apple and others built (and, yes, actually keep open source and updated, no hidden bogeyman saving-the-good-bits forks) builds all of Mac OS X, all of FreeBSD kernel and world, several other OS kernels and probably most C and C++ code in the world. The Linux kernel and all drivers in the tree are almost working (see http://lwn.net/Articles/441018/ ) but needs some deep and/or rare GCC functionality to compile correctly.
clang is better structured than GCC, compiles the same code faster and optimizes it heavier, assuming it's in the 99% of the code that it will support. It's also built around a library approach that lets you use its innards and ASTs for related projects (like translators and deep code analysis) along with a more stable long-term API for syntax highlighting and symbol/type lookup.
I am not up to date with GCC, but when clang was started a few years back, it was started because the compiler team at Apple wanted all these things -- none of which involve making Apple masters of the universe or forcing everyone to port to Objective-C -- but couldn't do them with the GCC codebase. From what I've heard, GCC has now started to move in this direction. I still want GCC around and I hope it keeps improving, but I'm happy I didn't wait.
That's $99 for the ordinary developer program, which gets you App Store apps as well as Ad-Hoc apps, limited to distribution to a few devices picked from a list that may only contain 100 devices per year. The Enterprise program, which gets you arbitrary distribution apps that you're only supposed to use inside your company, requires $299 and a DUNS number (some sort of business identifier) to keep the commoners out. (There used to be a prerequisite of hundreds of employees which was recently removed, so there's that.)
But in the reality you can observe that next to none of the students with no prior experience become good.
In ("the") reality, there are bad teachers and bad curriculums. To make a good curriculum, you have to go back to what makes people interested. Very few people start programming because they hear of the theory of hashtables, linked lists or dereferencing pointers.
You have to hook the bait, pull them in and engage them, at which point you are mentally prepared to start learning the harder stuff. You have to present a bigger picture; so much of programming education is just running down the language specification table of contents without providing context for anything, without answering the question "why am I learning this?". Not only do you have to solve real problems repeatedly, you have to learn how to apply patterns to solve parts of problems, not just learn the name and basic function of a few design patterns in order to rattle them off at the exam.
None of this is new or revolutionary. It's how many of us who did learn programming learned it, but it's startling how few of us did it in school.
You might say "OK, but Computer Science *is* really about hashtables, linked lists and dereferencing pointers, so these points don't apply". Bullshit. It's as if carpenters had a course where you learned what a hammer looked like and how it behaves aerodynamically, but not how to use it to drive nails into a wall. Even if you intend to spend your life becoming an authority of hammer design, you're going to have to ground that in experience.
I agree with you that having people exit education who do not really know the first thing about building programs ("these clown" "drag hurly rated down") isn't a good outcome. But rather than keeping the existing structure going and asking the part of the class that's scratching its head to leave, why not fix the course instead? No, they don't turn out good programmers. Let's fix the process that's supposed to turn them into good programmers and stop blaming them. It doesn't require physique or genetic predisposition, it just requires enthusiasm and conditioning.
I think the name "retina" is awkward, but I like the idea that there's no reason a display should be cruder than a piece of paper printed by the cheapest inkjet printer you could find. It's a useful thing to measure because it's something you can by definition tell right away. It only gets confusing when you pretend it doesn't mean different DPIs for different uses.
The guarantee is that given you are looking at the display from the intended distance, its pixels don't look like pixels. This isn't very much different from the guarantee of "HD ready" TVs or similar displays that HD footage always gets at least one pixel per pixel in the source material in that both look like ass under the wrong conditions and neither may be exactly what you want in a display.
You can quote "intended distance", and I'll quote "high definition", given 720p HD shown on a 80" TV. Pixels the size of peas given a sufficiently sized screen or pixels that are actually individually visible because you're holding your tablet at nose length - it's all "weak guidance"! However, given that displays don't grow larger and larger into infinity, I'm happy that someone finally cares about pixel density.
If you take Apple's naming of a Retina display to be the original definition, it's when a display's pixels are of high enough density that, at the intended viewing distance, the eye doesn't discriminate between the individual pixels.
HD is a good way to specify a standard for a video format, and "HD ready" is a good way to specify that a display can show HD without scaling down ("HD ready" for 720p, "full HD" for 1080i). Depending on the size of the display you can't consistently claim that the image you're seeing is "high definition", just that it's higher than SD. In this way, a "Retina display" per the above definition gives the same guarantee for every size.
Slashdot Mirror
Really? I like the REPL, but I wasn't aware that they had fixed the entanglement issues.
Thanks to Roslyn being designed explicitly for these kinds of scenarios, it can give you helpful information from nearly every stage of the compilation progress. You can get syntax trees! Not only that, you can feed it an invalid program and you'll get back a syntax tree that says that it's invalid, but knows when it stopped parsing, what kind of token it expected and can be stringified to the exact text you fed it. You can do flow analysis. There's a solidified model for how C# works in a REPL or scripting environment outside of everything-is-in-a-class mode, which admittedly it was never up to Mono to define.
csharp-repl is a very good REPL and the mcs family (which now seems to be merging into a single compiler) are very good compilers with source readily available, but I think it takes something that's designed from the start for reusability and being a library as much as a tool to get you these things.
The "dynamic code execution" just builds on top of support that's already there. You could build a string of a C# program, feed it to a compiler and run it dynamically previously as well. This just makes the compilation part less of a headache.
Rigging GCC (other comments have already brought up clang) would maybe be more dangerous because arbitrary C code could do anything. Arbitrary IL code can be hamstrung by some security layers. Of course, the differences between managed and native code pale in comparison to what permissions they are executing with, the robustness of any jailing or sandboxing that might be in place and so on.
If you worry that people can compile programs into executable code, you're not worrying about the right thing. You could write a C compiler in JavaScript or QBASIC. You should be worrying about what happens when that code executes.
That was the announcement of the release. This was the actual release.
I'm not about to debate anyone on the Visual Studio segmented pricing, but Anders Hejlsberg has gone on record saying he'd like for Roslyn to be open source, by which he likely means Ms-PL. If they do that, they could indeed close it later, at the cost of an enormous shitstorm. (When Microsoft has stopped providing open source before, they've stopped developing the software (see: Rotor). This is the new version of the C# compiler and its IDE integration so that's not going to happen.)
There are already APIs to emit IL or to invoke a C# compiler built into .NET and the security systems built into .NET give you a way to prohibit them. There's no additional risk exposed by Roslyn. Rather, it's a way of getting at the juicy knowledge about the code that the compiler builds up before it exits and that libraries have been written to poorly piece together. That's a good idea that I'd like to see accompany more official language compilers, static or not.
In Korea, only old people die! No, wait...
Seems to me like arbitrary external expansion is worth it. That doesn't mean everyone will need it (or that HDMI and USB 3 aren't both great things to build in regardless), but it's just what the doctor ordered for a docking station or external enclosures. You can basically add whatever gear you'd like to, for example, a MacBook Air form factor laptop. Adding some limited, predetermined expansion has been possible before with purpose-built docking connectors and matching docks, but all this needs is the physical port and you can add what you wish.
You could upgrade basically everything in that computer but the CPU and the RAM, and you could chain those expansions together such that you cart around a lightweight laptop up until when you get to your desk, where you plug in one plug and everything comes online. You can have a laptop when you need a laptop and a desktop when you need a desktop with few tradeoffs. That's interesting, but you're right that it's not interesting for the reasons that HDMI and USB 3 are helpful. They are complementary ideas.
The back button is different from the up button, and I want them both because they're both useful for their respective uses. Windows 8 coincidentally has them both, as did Windows XP.
Serves me right then, but assuming someone that knows the correct spelling and meaning of "köttkvarn" to be Swedish is generally a low-risk bet.
Certainly, but in written form, you'd have to point out that your fingers were crossed no matter which meaning you were aiming for. So the matter of pointing out that one's fingers were crossed didn't make it clear, the surrounding context did.
So it seems from the other replies that "crossing your fingers" in that way is used by at least some English speakers as well. Neat. Didn't know that, primarily because Swedish English education teaches that it is a false friend since "crossing your fingers" is already something else in English.
With this in mind, I'm not surprised that AliasMarlowe is Swedish per the above because I've never heard a native English speaker use it in that context.
Helpful tip: Having your fingers crossed while saying something only means what you think it means (that you're lying) in Swedish, not in English. In English, it means you're hoping for a particular outcome, which could be true in this case too, I guess.
18 may mean diddly squat for you when you're not using a 24 hour clock, but I bet you know the difference between 2 AM and 9 AM. The 24 hour clock just extends the same idea to all hours. Having to cart around two digits and a letter seems like more work than just two digits, even if neither of the two are crushing work as such once you're used to them.
And for the record, yes, most people in a 24 hour clock country don't say "we'll meet at 18" but "we'll meet at 6 in the evening". But they also say "we'll meet at noon" instead of worrying about which of 12 PM and 12 AM is noon and which is midnight. It seems like people assume that "24 hour people" want their time in one strict format, when it's more often about just being clear with what you mean.
Fair enough; I know far less about the specifics than even Randall does. I thought the main source of nonsense was the "WHAT DID THEY USE UNMODIFIED HIV WTF".
Wasn't the point of the xkcd joke precisely that it was not real HIV, but that it's a hard sell regardless to pitch anything based on HIV or its way of spreading as a solution?
Define standard. If you mean standards-based, we're there. Many of the vendor prefixed CSS properties are initial implementations of standards, and many of them have since graduated to actual standards. Even the ones that are made up by a vendor (like the canvas element) are written up, submitted, improved and adopted; a far cry from attempts to insert a box with a new environment in the middle of everything (ActiveX, Silverlight, Flash, Java; the list goes on). NaCl looks like a more well-meaning version of those boxes. With Chrome OS and the pain of NPAPI plugins, I understand why Google would want it in Chrome. The case isn't so clear for the rest of the world.
The vendor prefix is a symptom of incremental adaptation of lots of smaller features. I prefer it to necessarily waiting five years to start using an entire versioned standard.
You're right, buying a tablet because it's a cool new must-have tech gadget is idiotic. Buying a tablet because it has a dual-core processor makes much more sense!
If you change enough of your hardware, including motherboard, you need to reactivate Windows.
There have also been weird licensing terms for a number of products (Oracle and certainly Windows Server versions) that don't make much sense or skyrocket when you combine the concepts of actual socketed CPUs vs CPU cores vs virtualized CPUs.
It's not exactly weird that FSF GCC is behind on Apple's improvements to their own language to run on their own OS, especially since Apple decided to not track GCC development shortly after starting clang.
My point (and yours too, it seems) was more that clang is a cleaner and more well-maintained architecture than at least the version of GCC that Apple left. The layering had grown crooked in GCC. Some things, like GCC's breadth of optimization, extensions, target architectures and bug compatibility support, can only be solved by adoption and maturing over time.
Is your argument really "well, *I* haven't heard of it, so it can't be that good"?
clang, the LLVM-based compiler for C/C++/Obj-C that Apple and others built (and, yes, actually keep open source and updated, no hidden bogeyman saving-the-good-bits forks) builds all of Mac OS X, all of FreeBSD kernel and world, several other OS kernels and probably most C and C++ code in the world. The Linux kernel and all drivers in the tree are almost working (see http://lwn.net/Articles/441018/ ) but needs some deep and/or rare GCC functionality to compile correctly.
clang is better structured than GCC, compiles the same code faster and optimizes it heavier, assuming it's in the 99% of the code that it will support. It's also built around a library approach that lets you use its innards and ASTs for related projects (like translators and deep code analysis) along with a more stable long-term API for syntax highlighting and symbol/type lookup.
I am not up to date with GCC, but when clang was started a few years back, it was started because the compiler team at Apple wanted all these things -- none of which involve making Apple masters of the universe or forcing everyone to port to Objective-C -- but couldn't do them with the GCC codebase. From what I've heard, GCC has now started to move in this direction. I still want GCC around and I hope it keeps improving, but I'm happy I didn't wait.
He's my friend and a whole lot more.
That's $99 for the ordinary developer program, which gets you App Store apps as well as Ad-Hoc apps, limited to distribution to a few devices picked from a list that may only contain 100 devices per year. The Enterprise program, which gets you arbitrary distribution apps that you're only supposed to use inside your company, requires $299 and a DUNS number (some sort of business identifier) to keep the commoners out. (There used to be a prerequisite of hundreds of employees which was recently removed, so there's that.)
In ("the") reality, there are bad teachers and bad curriculums. To make a good curriculum, you have to go back to what makes people interested. Very few people start programming because they hear of the theory of hashtables, linked lists or dereferencing pointers.
You have to hook the bait, pull them in and engage them, at which point you are mentally prepared to start learning the harder stuff. You have to present a bigger picture; so much of programming education is just running down the language specification table of contents without providing context for anything, without answering the question "why am I learning this?". Not only do you have to solve real problems repeatedly, you have to learn how to apply patterns to solve parts of problems, not just learn the name and basic function of a few design patterns in order to rattle them off at the exam.
None of this is new or revolutionary. It's how many of us who did learn programming learned it, but it's startling how few of us did it in school.
You might say "OK, but Computer Science *is* really about hashtables, linked lists and dereferencing pointers, so these points don't apply". Bullshit. It's as if carpenters had a course where you learned what a hammer looked like and how it behaves aerodynamically, but not how to use it to drive nails into a wall. Even if you intend to spend your life becoming an authority of hammer design, you're going to have to ground that in experience.
I agree with you that having people exit education who do not really know the first thing about building programs ("these clown" "drag hurly rated down") isn't a good outcome. But rather than keeping the existing structure going and asking the part of the class that's scratching its head to leave, why not fix the course instead? No, they don't turn out good programmers. Let's fix the process that's supposed to turn them into good programmers and stop blaming them. It doesn't require physique or genetic predisposition, it just requires enthusiasm and conditioning.
I think the name "retina" is awkward, but I like the idea that there's no reason a display should be cruder than a piece of paper printed by the cheapest inkjet printer you could find. It's a useful thing to measure because it's something you can by definition tell right away. It only gets confusing when you pretend it doesn't mean different DPIs for different uses.
The guarantee is that given you are looking at the display from the intended distance, its pixels don't look like pixels. This isn't very much different from the guarantee of "HD ready" TVs or similar displays that HD footage always gets at least one pixel per pixel in the source material in that both look like ass under the wrong conditions and neither may be exactly what you want in a display.
You can quote "intended distance", and I'll quote "high definition", given 720p HD shown on a 80" TV. Pixels the size of peas given a sufficiently sized screen or pixels that are actually individually visible because you're holding your tablet at nose length - it's all "weak guidance"! However, given that displays don't grow larger and larger into infinity, I'm happy that someone finally cares about pixel density.
If you take Apple's naming of a Retina display to be the original definition, it's when a display's pixels are of high enough density that, at the intended viewing distance, the eye doesn't discriminate between the individual pixels.
HD is a good way to specify a standard for a video format, and "HD ready" is a good way to specify that a display can show HD without scaling down ("HD ready" for 720p, "full HD" for 1080i). Depending on the size of the display you can't consistently claim that the image you're seeing is "high definition", just that it's higher than SD. In this way, a "Retina display" per the above definition gives the same guarantee for every size.