Agreed! My Mom always says that nobody will fucking care if you put it on the resume that you were walking when you turned 10 months old, talking in full sentences by 15th month, and reading before you turned three. I have some fairly prodigious friends who were early readers. They are extremely good in their fields but are somewhat mediocre parents, for example -- we always feel a bit sorry for their kid when they visit. Their jobs are in humanities so the pay isn't all that great, but at least they seem to enjoy themselves at the parties. They drink, oh boy do they drink at the parties. Alas, when you apply for a job, it matters whether you can do the job -- or learn to do it, as the case may be.
It wasn't even called copyright. The U.S. Constitution is entirely utilitarian -- it prescribes the why, the guiding reason. Copyright as it exists now simply doesn't aid the consistutional cause at all.
Chip fabs are expensive mainly because there isn't all that many of them. There are no economies of scale. The companies that make machines for fabs have to pay for large R&D efforts while sometimes selling on the order of 10 units per year. If there was a serious market for desktop-sized fabs, you could certainly get them for reasonable sums. A somewhat compactly designed but still entirely possible 1um process for BiCMOS on small (say 50mm) wafers could occupy the circumscribed volume of a couple large workbenches. You'd probably want the vacuum pumps and power supplies in another room, of course:) And I mean from design to a chip: a complete process where you load the mask files on one end, and get tested and encapsulated chips on the other end. It could definitely be made small and modular, but it'd take a lot of engineering to get such a unit done, and I don't see the market for it.
Sure, but that's all engineering, not issues inherent in a particular class of technology. Fungus, for example, needs both moisture and food to grow, there's no magic there. Either they had some organic surfaces that were edible by fungus, or there were deposits of human-origin dust (skin, hair, snot) over condensation. Those same problems are faced in regular buildings down on Earth. Im no Mir apologist, sure it was less pleasant AFAIK than even Skylab, but let's not pretend that Mir's problems were somehow special.
Mir wasn't all that different from ISS in terms of underlying principles. It was to ISS like a cheap motel is to a mid-tier chain hotel. Sure ISS is roomier and less smelly, but it's no interplanetary spaceship. It won't go to Mars just as Mir wouldn't.
It's a local functor, not a local function. In C/C++, function definitions have certain syntax. Neither lambdas nor local functors maintain it. I'd like to hear a technical reason why the original syntax couldn't have been reused for local functions in both C and C++.
This std::function func = [](int i) { return i+4; }; looks nothing like int function(int i) { return i+4; }
There was a perfectly good function declaration syntax to reuse. That's all you'd need for local functions Pascal-style. Besides, the whole "over 2 years now blah" argument gets kind of old. There's still plenty of code out there that hasn't been ported over to newer compilers, even if that code is otherwise perfectly valid C++ that just doesn't use certain features. I have a lot of code that uses what you got in Visual Studio 2008, and I simply have no time to deal with requalifying it all under VS 2012.
LOL. Ansys is, user-interface-wise, stuck in an awkward prehistoric backwater that it created for itself. We're talking of a system that has FORTRAN READ command line syntax, for crying out loud. At least until 3 years ago or so didn't have any sort of undo in its user interface. I see absolutely no reason to use ANSYS as a modeler of any sort, except if you want to run FEA on your ad-hoc model. Your productivity will be worse than entering openscad or povray source - in notepad. I have used Ansys for a bunch of courses and it would have almost been easier to use the core functionality as a library callable from custom code written in something modern like C++. I really didn't care for the awkward and useless GUI. Give me a break, their GUI functionality doesn't even provide the basics that you had with Autocad in the times when a 6MHz 80286 machine was top-of-the-line. I've first used Autocad on an XT clone, with Hercules card on a monochrome Roland monitor. Today's Ansys's GUI feels like crap compared to that.
The G-code interpreter will convert G-code arcs/curves into polylines, so it's being faked at some layer. Remember, in the end you must discretize the curve somewhere. Whether it's done before generation of G-code, or during interpretation of G-code doesn't matter for the output -- as long as the pre-generated polylines match the resolution of the machine.
And that's almost all there's to it. The energy demands for desalination don't include, obviously, the material and energy costs of filter media and their maintenance. The subject technology is all about reducing those.
I'd like to know, though, if it has any applications to dialysis. We really need an artificial kidney. For those who don't know how it works: when you're on dialysis, they only dialyse you enough to survive, not enough to feel like normal people feel. People on dialysis are permanently tired and feel sick, pretty much. There was a study where they decided to find out what it'd take and they dialyzed "the heck" out of their subjects -- running them 7 days a week for 8 or more hours IIRC. And guess what: that's what it takes for people on dialysis to feel normal.
Yup, but it's even worse: everyone even in a single company would do just that, even in C. Just look at how many kinds of strings are used in winapi. It's a nightmare.
Typical "hardcore" C code is written a lot like typical Pascal code, and it reads like this abomination, for example (feel free to ignore the assembly bits, they may improve the readability too much). Sure you can understand it coming from just about any other procedural programming language, but that file could be actually quite readable and with no boilerplate if it the project was done in C++ not Pascal... As part of a research on code transformations I've contemplated writing a tool to machine-port Inkscape to from Gtk+ to Qt. There was so much boilerplate code there that it was just silly. Inkscape is written in "OO" C, using C++ as syntactic sugar, and it shows. The codebase is probably 3x too big, considering what it does. As far as use of language features goes, it's really Object Pascal code written in C++ syntax. Not much to do with modern C++ at all, not even much to do with where C++ was 5-6 years ago.
Agreed. If C/C++ at least had local functions, you could put the body somewhere close, or even right where it belongs by using a wrapper macro. I find it hilarious that shit that was a well solved problem in Pascal never made it to C++. The pimpl idiom is completely unnecessary in Pascal, because separation of implementation from interface is a part of the language. In C++ it's a yet another manual task you have to deal with, and you always pay for it in non reference-counted classes -- it costs you the extra memory allocation and the extra indirection. Of course Pascal's separation of declarations from the body of the code is IMHO an ugly historical leftover as well:/
At that point you could drop all of the template metaprogramming mess. If that day came, I'd probably cry like a baby for 8 hours straight. I kid you not.
I don't know what practical problem does std::string solve, because sure as heck it doesn't provide most of what you actually need to use strings in real life applications. Qt's QString and the associated codec infrastructure is pretty much what you need. std::string is a solution to a problem that nobody has. If all you need is to pass around safe arrays of characters, then std::vector does it for you, duh. std::string is a safe wrapper for C strings, and that's the whole problem: modern software has outgrown C strings two decades ago.
For linear algebra and C++, there's nothing but eigen, IMHO. Yes, the error messages are incomprehensible, but at least it's documented, well designed, and works mostly as advertised.
Slashdot Mirror
Agreed! My Mom always says that nobody will fucking care if you put it on the resume that you were walking when you turned 10 months old, talking in full sentences by 15th month, and reading before you turned three. I have some fairly prodigious friends who were early readers. They are extremely good in their fields but are somewhat mediocre parents, for example -- we always feel a bit sorry for their kid when they visit. Their jobs are in humanities so the pay isn't all that great, but at least they seem to enjoy themselves at the parties. They drink, oh boy do they drink at the parties. Alas, when you apply for a job, it matters whether you can do the job -- or learn to do it, as the case may be.
It wasn't even called copyright. The U.S. Constitution is entirely utilitarian -- it prescribes the why, the guiding reason. Copyright as it exists now simply doesn't aid the consistutional cause at all.
Chip fabs are expensive mainly because there isn't all that many of them. There are no economies of scale. The companies that make machines for fabs have to pay for large R&D efforts while sometimes selling on the order of 10 units per year. If there was a serious market for desktop-sized fabs, you could certainly get them for reasonable sums. A somewhat compactly designed but still entirely possible 1um process for BiCMOS on small (say 50mm) wafers could occupy the circumscribed volume of a couple large workbenches. You'd probably want the vacuum pumps and power supplies in another room, of course :) And I mean from design to a chip: a complete process where you load the mask files on one end, and get tested and encapsulated chips on the other end. It could definitely be made small and modular, but it'd take a lot of engineering to get such a unit done, and I don't see the market for it.
There'll be a glowing white apple logo in your ear. Just large enough and bright enough to be noticed :)
Sure, but that's all engineering, not issues inherent in a particular class of technology. Fungus, for example, needs both moisture and food to grow, there's no magic there. Either they had some organic surfaces that were edible by fungus, or there were deposits of human-origin dust (skin, hair, snot) over condensation. Those same problems are faced in regular buildings down on Earth. Im no Mir apologist, sure it was less pleasant AFAIK than even Skylab, but let's not pretend that Mir's problems were somehow special.
Mir wasn't all that different from ISS in terms of underlying principles. It was to ISS like a cheap motel is to a mid-tier chain hotel. Sure ISS is roomier and less smelly, but it's no interplanetary spaceship. It won't go to Mars just as Mir wouldn't.
It feels to me like the editors never actually look at the site, and they have such short memory that they become useless as editors.
It's a local functor, not a local function. In C/C++, function definitions have certain syntax. Neither lambdas nor local functors maintain it. I'd like to hear a technical reason why the original syntax couldn't have been reused for local functions in both C and C++.
This std::function func = [](int i) { return i+4; };
looks nothing like int function(int i) { return i+4; }
There was a perfectly good function declaration syntax to reuse. That's all you'd need for local functions Pascal-style. Besides, the whole "over 2 years now blah" argument gets kind of old. There's still plenty of code out there that hasn't been ported over to newer compilers, even if that code is otherwise perfectly valid C++ that just doesn't use certain features. I have a lot of code that uses what you got in Visual Studio 2008, and I simply have no time to deal with requalifying it all under VS 2012.
LOL. Ansys is, user-interface-wise, stuck in an awkward prehistoric backwater that it created for itself. We're talking of a system that has FORTRAN READ command line syntax, for crying out loud. At least until 3 years ago or so didn't have any sort of undo in its user interface. I see absolutely no reason to use ANSYS as a modeler of any sort, except if you want to run FEA on your ad-hoc model. Your productivity will be worse than entering openscad or povray source - in notepad. I have used Ansys for a bunch of courses and it would have almost been easier to use the core functionality as a library callable from custom code written in something modern like C++. I really didn't care for the awkward and useless GUI. Give me a break, their GUI functionality doesn't even provide the basics that you had with Autocad in the times when a 6MHz 80286 machine was top-of-the-line. I've first used Autocad on an XT clone, with Hercules card on a monochrome Roland monitor. Today's Ansys's GUI feels like crap compared to that.
The G-code interpreter will convert G-code arcs/curves into polylines, so it's being faked at some layer. Remember, in the end you must discretize the curve somewhere. Whether it's done before generation of G-code, or during interpretation of G-code doesn't matter for the output -- as long as the pre-generated polylines match the resolution of the machine.
Sure it'll change your life. You'll go broke, that's why. Unless you've got serious money to burn, FreeCAD and Alibre are the only serious contenders.
Now that's just dumb. You mix it with seawater to dilute it, and dump it back into the ocean. That's all there's to it.
And that's almost all there's to it. The energy demands for desalination don't include, obviously, the material and energy costs of filter media and their maintenance. The subject technology is all about reducing those.
I'd like to know, though, if it has any applications to dialysis. We really need an artificial kidney. For those who don't know how it works: when you're on dialysis, they only dialyse you enough to survive, not enough to feel like normal people feel. People on dialysis are permanently tired and feel sick, pretty much. There was a study where they decided to find out what it'd take and they dialyzed "the heck" out of their subjects -- running them 7 days a week for 8 or more hours IIRC. And guess what: that's what it takes for people on dialysis to feel normal.
Yup, but it's even worse: everyone even in a single company would do just that, even in C. Just look at how many kinds of strings are used in winapi. It's a nightmare.
Typical "hardcore" C code is written a lot like typical Pascal code, and it reads like this abomination, for example (feel free to ignore the assembly bits, they may improve the readability too much). Sure you can understand it coming from just about any other procedural programming language, but that file could be actually quite readable and with no boilerplate if it the project was done in C++ not Pascal... As part of a research on code transformations I've contemplated writing a tool to machine-port Inkscape to from Gtk+ to Qt. There was so much boilerplate code there that it was just silly. Inkscape is written in "OO" C, using C++ as syntactic sugar, and it shows. The codebase is probably 3x too big, considering what it does. As far as use of language features goes, it's really Object Pascal code written in C++ syntax. Not much to do with modern C++ at all, not even much to do with where C++ was 5-6 years ago.
He also has a history of indirectly getting people jailed back in Argentine, so I'd be careful not to be fooled by the appearances.
This should be +5 insightful.
The best you can do "OO" in C is shown in GObject. Thanks, I'll pass.
Agreed. If C/C++ at least had local functions, you could put the body somewhere close, or even right where it belongs by using a wrapper macro. I find it hilarious that shit that was a well solved problem in Pascal never made it to C++. The pimpl idiom is completely unnecessary in Pascal, because separation of implementation from interface is a part of the language. In C++ it's a yet another manual task you have to deal with, and you always pay for it in non reference-counted classes -- it costs you the extra memory allocation and the extra indirection. Of course Pascal's separation of declarations from the body of the code is IMHO an ugly historical leftover as well :/
At that point you could drop all of the template metaprogramming mess. If that day came, I'd probably cry like a baby for 8 hours straight. I kid you not.
I don't know what practical problem does std::string solve, because sure as heck it doesn't provide most of what you actually need to use strings in real life applications. Qt's QString and the associated codec infrastructure is pretty much what you need. std::string is a solution to a problem that nobody has. If all you need is to pass around safe arrays of characters, then std::vector does it for you, duh. std::string is a safe wrapper for C strings, and that's the whole problem: modern software has outgrown C strings two decades ago.
That about sums it up. It was around 15 minutes for me too. I use it so rarely that I usually have to repeat the learning each time I use it :)
For linear algebra and C++, there's nothing but eigen, IMHO. Yes, the error messages are incomprehensible, but at least it's documented, well designed, and works mostly as advertised.