Code runs. It continues to run. And, over time, the requirements change. Maintenance is adapting the code to the new requirements. If you don't understand why this is important, then I can only assume that no one is using code that you've written.
This is a confusion in terms. Personally I blame Sun. An interpreter IS a form of compiler, it is the term used to refer compilation at run time
No, sorry. A compiler is, in theoretical terms, a partial application of an interpreter to a program. In practical terms, a compiler transforms the input into some other form, which is then executed, whereas an interpreter executes the input directly. JIT compilation is still compilation. A just-in-time compiler is the term given to compilers that produce their output just before it is executed, as opposed to ahead-of-time (AoT) compilers, which produce it all up front, even if some paths are never executed.
There's some complication, because most environments that do JIT compilation also include interpreters that gather profiling information to incorporate into the JIT compiled code and to improve startup times. JavaScript implementations, in particular, often spend a reasonable amount of time in the interpreter because most web pages contain a load of JavaScript that's only run one or two times and the time taken to compile it is more than the time saved to execute it. Some have multiple compilers - JavaScriptCore from the WebKit project has an interpreter and three different JIT compilers that have different points in the space between compilation time and execution time - they'll recompile hot paths multiple times as they're executed more, with more optimisation each time. The key difference between the interpreter and compilers here is that the compilers are each invoked once on a segment of code and it's then executed without involving the compiler. The interpreter is involved every time the bytecode is run. It reads a bytecode and then jumps to the segment of interpreter code that executes it and then returns. The compiler takes a sequence of bytecodes, generates a fragment of native code to execute them, and then this fragment is combined with other fragments to produce a running program.
The shader compilers in drivers, however, are not JIT compilers. They are AoT compilers that are invoked at load time - often at install time. They don't compile the code just before it's run, they typically compile it once and cache the result for multiple invocations of the program. Some drivers (Windows and Android come to mind) have a mechanism that allows you to do the compilation at install time. Unlike most JIT environments, graphics drivers don't tend to use run-time profiling for optimisation, the bytecode exists solely for the purpose of providing an ISA-neutral distribution format.
Ugh, trust MS to fuck up a reasonable UI choice. On OS X, by default, it only happens for programs and requires you to close the dialog and then bring up the context menu for the program while holding a modifier key. You don't know how to do it unless you've actually read all of the way to the end of the dialog, so it generally protects people.
There are some interesting corner cases though, such as shell scripts. The file manager doesn't know if the thing that you tell it to open a shell script with is a text editor or a script interpreter, so may warn spuriously.
There are two problems. The first is that the OS allows you to run porn.jpg.exe having downloaded it from some random place on the 'net. I don't think that either OS X or Windows do: they'll both pop up a thing saying 'You are trying to run a program downloaded from the Internet, do you really want to?', which isn't normally something that happens when people try to open a file so ought to trigger them to avoid it (if it doesn't, then seeing the.exe extension probably won't either).
The second is that the OS allows programs and other file types to set icons at all before their first run. This also leads to confused deputy-like attacks where you think you're opening a file with one program but are actually opening it with something that will interpret it as code. The solution to this is probably to have programs keep their generic program icon until after their first run. If you double click on something that has a generic program icon, then you probably intend to run it...
This post needs a '-1 not even wrong' moderation. I started to write a reply to your points, but I honestly can't tell if you're trolling or completely fail to understand any of the parts of the hardware and software stacks involved.
Not really. Self has multiple prototype chains, Smalltalk and Java have only single inheritance. Both JavaScript and Smalltalk lack any declarative mechanism for defining classes in the language and do so by manipulating objects.
an LLVM-based bytecode for its shading language to remove the need for a compiler from the graphics drivers
This removes the need for a shader language parser in the graphics driver. It still needs a compiler, unless you think the GPU is going to natively execute the bytecode. If you remove the compiler from a modern GPU driver, then there's very little left...
There are a few. Smalltalk obviously does, as does Self. Lisp also can, depending on how it's used. JavaScript is probably the mainstream language that fits closest (it's actually very close to Smalltalk). Java and C# both mostly do, though they wouldn't count as pure OO.
C++ is a language that is very good for generic programming. It doesn't really meet Alan Kay's definition of OO (and he's the one who coined the term), nor does it pass the Ingalls Test for OO. It has classes, but method dispatch is tied to the class hierarchy so if you want to really adopt an OO style you need to use multiple inheritance and pure abstract base classes, which is a very cumbersome way of using C++.
The worst C++ code is written by people who are thinking in C when they write C++, but the second-wrost C++ code is written by people who are really thinking in Smalltalk. If you're one of these people, then learn Objective-C: the language is far better at representing how you think about programs.
Any programming language can be used to write code in any style. You can write good OO code with a macro assembler if you want. However, every language has a set of styles that fit naturally with the language and ones that don't. You can force C++ to behave in an OO way, and it sort-of works, but it's not using the language in the most efficient way.
The main advantage of auto is in templates, where the type is something complex derived from template instantiations. You simply don't want to make it explicit. Oh, and in lambdas, where explicitly writing the type of the lambda is very hard (though you generally cast to std::function for assignment). As to using a float instead of an int... I have no idea how you'd do that with auto. The type of auto is the type that you initialise it with. If you're using a platform where you don't have hardfloat, then why do you have APIs that return floats? There's your bug, the use of auto was just a symptom.
And if you've never seen anyone use the algorithms library, then you must be using C++ in a very specialised environment. I've not seen any C++11 code that didn't use std::move. I've rarely seen a nontrivial C++ file that didn't use std::min or std::max, and most code will also use std::copy. The only code that I've seen that didn't use the algorithms library included is own, poorly optimised and buggy, versions of several of them.
First, WindowsMaker doesn't use Objective-C, it's written in C. However, GNUstep, which is the open source implementation of the Cocoa frameworks (originally the OpenStep specification, but they're tracking Apple changes) could use more help! Oh, and we support (on *NIX) a superset of the Objective-C language that Apple supports on their products, so I wouldn't say that Obj-C is more limited on Linux.
That said, and I say this as the maintainer of the GNUstep Objective-C implementation, I'd recommend C++, but with the two caveats:
C++ is not an OO language. It sort-of supports OOP, but writing OO code in C++ is not the natural way of using the language.
Don't look at any version of the language before C++11. It's just terrible and will damage your brain.
C++11 and C++14 have cleaned up C++ a lot. With shared_ptr and unique_ptr, you can write code with sane memory management. With perfect forwarding, lambdas, and variadic templates, you can write code that has most of the benefits of a late-bound language. I like a lot of Objective-C, but Apple broke the 'simple, orthogonal syntax' when they added declared properties and a few other things. Any successful programming language eventually becomes a mess of compromises and ugly corners. Some, like Python and C++, start that way, but at least C++ has been slowly improving over the last couple of versions.
The one thing where Objective-C is still a clear winner is in writing libraries that want to maintain a stable ABI. This is insanely difficult in C++ because the language doesn't have a clean separation of interface and implementation and relies a lot on inlining and static binding for performance. The down side, of course, is that once you have a library in Objective-C you're limited to consumers who also want to use Objective-C.
Oh, and Qt GUIs suck beyond belief on OS X - not sure what they're like on Windows, but I wouldn't recommend them for a portable UI. Good MVC design and a native UI is the only way to go if you really want a cross-platform GUI app that doesn't suck.
If Pluto is a planet, then so is Eris (which is larger), and Earth's moon (around 5 times larger than Pluto) is possibly a binary planet. Ganymede, the largest moon in the solar system, is under 3% the mass of Earth and is about ten times bigger than Pluto. There are quite a lot of moons bigger than Pluto, so would you want to classify them all as planets?
Zoom right in on the bits that you think are white, so that they fill your entire monitor. They're obviously blue. For a lot of us, that's the colour that we see when we look at it in context as well. I can see how you'd interpret it as being white by overcompensating for the colour in the bottom right, but that doesn't stop you from being wrong. The gold bits are gold when you zoom in (mostly, some are black), but a shiny black often looks yellow-gold in overexposed photos.
Who says the OS should provide nothing useful and let app makers make their money on it?
If you set up a straw man, then it's very easy to kill it. The issue is not an OS providing something, it's that Microsoft, which had a near-monopoly in the desktop space, used the money from selling the OS to fund development in another market (browsers) and then bundled their version, undercutting the competition with cross subsidies. There was a thriving browser market before IE was introduced, but it's hard to compete when most of your customers are forced to pay to fund the development of your competitor.
The last 5 years is long after this was an issue. Windows 98 was the release that triggered the lawsuit and it had been EOL for a long time five years ago.
Generally Fundamental Evangelical Christians teach humility and service to others and subscribe to the view that others are more important than me. That's exactly opposite to what you claim "ALL" religion is.
Really? Because that's exactly the set of values that I'd choose to indoctrinate my serfs with.
"You know that those who are recognized as rulers of the Gentiles lord it over them; and their great men exercise authority over them. But it is not this way among you, but whoever wishes to become great among you shall be your servant; "For even the Son of Man did not come to be served, but to serve, and to give His life a ransom for many."
Or, to summaries: 'Hey oppressed people, don't think about following a leader from amongst yourself, that kind of thing always ends badly'.
Laplink also had a neat mode where it would install on the remote machine for you (which was useful for me, because it came on 3.5" floppies and one machine only had a 5.25" drive). The mechanism for this was quite interesting - you ran command.com on the remote machine machine, telling it to use com1 as the console device (something I hadn't been aware DOS could do). Then it would use the type command (similar to cat on UNIX systems) to write a stream of data from the standard input to a file and finally run that file.
This obviously raises the question of why, when you have a serial console with working flow control, do you need laplink at all? If you have a null modem cable and a lot of patience, then you can always extract files by writing them to standard output and reading them off with a serial program - just make sure that you've correctly configured the UART first. If you're a bit paranoid, then running something like par2 first (I think there are DOS binaries and they're pretty small, though they may take a while on a 386) and you'll be able to recover small data errors.
Copying 160MB over a serial connection won't be fast, but I'm assuming that this isn't urgent if it's been sitting on a 160MB disk for years without backups...
IE itself can EASILY be removed from a system. Delete the EXE, done. Its been that way ALWAYS. Even during the court battles.
While this is technically true, it's also misleading. You could delete iexplore.exe, but don't expect a working system afterwards. Lots of other parts of Windows (and Office) invoked iexplore.exe directly, rather than providing a web view with MSHTML.dll or invoking the default browser via the URL opening APIs.
What is this, 1998? IE was never part of the kernel. The complaints were:
MSHTML.dll (around which IE was a very thin wrapper) was installed by default and used by loads of things.
Lots of things in Windows that should have used MSHTML.dll to embed a web view, or just invoked the default browser, used IE so that you couldn't uninstall IE without breaking Windows.
MS bundled IE with Windows and used their near monopoly in the desktop OS market to gain a dominant position in the browser market and push Netscape (and a few other browser makers) out of business.
It was never part of the kernel and never ran with system-level privileges.
I've not been paying much attention to Windows for a few years, but does IE still have the same poor security reputation? I was under the impression that it did the multiprocess thing and sandboxed each instance, putting it in the same ballpark as Chrome and Safari and ahead of Firefox (which is finally going to start adding sandboxing support now). Did they manage to screw up the sandboxing and make something that's still trivially exploitable, or are you just repeating ten-year-old information?
I saw a recent review of a smartphone that had two screens, one LCD and one eInk. The modern eInk display is able to get a high enough refresh for interactive use and doesn't drain the battery when done. The screen that I'd love to see is eInk with a transparent OLED on top, so that text can be rendered with the eInk display and graphics / video overlaid on the OLED. The biggest problem with eInk is that the PPI is not high enough to make them colour yet. You get 1/3 (or 1/4 if you want a dedicated black) of the resolution when you make the colour and so that means you're going to need at least 600PPI to make them plausible.
The other problem that they've had is that LCDs have ramped up the resolution. My first eBook reader had a 166PPI eInk display. Now LCDs are over 300PPI but the Kindle Paperwhite is only 212PPI, so text looks crisper on the LCD than the eInk display, meaning that you're trading different annoyances rather than having the eInk be obviously superior. With real paper you get (at least, typically a lot more than) 300DPI and no backlight.
The problem here is latency. You're adding (at least) one cycle latency for each hop. For neural network simulation, you need to have all of the neurones fire in one cycle and then consume the result in the next cycle. If you have a small network of 100x100 fully connected neurones then the worst case (assuming wide enough network paths) with a rectangular arrangement is 198 cycles to get from corner to corner. That means that the neural network runs at around 1/200the the speed of the underlying substrate (i.e. your 200MHz FPGA can run a 1MHz neural network).
Your neurones also become very complex, as they need to all be network nodes with store and forward and they are going to have to handle multiple inputs every cycle (consider a node in the middle. In the first cycle it can be signalled by 8 others, in the next it can be signalled by 12 and so on. The exact number depends on how you wire the network, but for a flexible implementation you need to allow this.
What's the justification for compilation unit boundary? It seems like you could expose the layout of the struct (and therefore any compiler shenanigans) through other means within a compilation unit. offsetof comes to mind.:-)
That's the granularity at which you can do escape analysis accurately. One thing that my student explored was using different representations for the internal and public versions of the structure. Unless the pointer is marked volatile or any atomic operations occur that establish happens-before relationships that affect the pointer (you have to assume functions that you can't see the body of contain operations), C allows you to do a deep copy, work on the copy, and then copy the result back. He tried this to transform between column-major and row-major order for some image processing workloads. He got a speedup for the computation step, but the cost of the copying outweighed it (a programmable virtualised DMA controller might change this).
I suppose you could do that in C++ with template specialization. In fact, doesn't that happen today in C++11 and later, with movable types vs. copyable types in certain containers? Otherwise you couldn't have vector >. Granted, that specialization is based on a very specific trait, and without it the particular combination wouldn't even work.
The problem with C++ is that these decisions are made early. The fields of a collection are all visible (so that you can allocate it on the stack) and the algorithms are as well (so that you can inline them). These have nice properties for micro optimisation, but they mean that you miss macro optimisation opportunities.
To give a simple example, libstdc++ and libc++ use very different representations for std::string. The implementation in libstdc++ uses reference counting and lazy copying for the data. This made a lot of sense when most code was single threaded and caches were very small but now is far from optimal. The libc++ implementation (and possibly the new libstdc++ one - they're breaking the ABI at the moment) uses the short-string optimisation, where small strings are embedded in the object (so fit in a single cache line) and doesn't bother with the CoW trick (which costs cache coherency bus traffic and doesn't buy much saving anymore, especially now people use std::move or std::shared_ptr for the places where the optimisation would matter).
In Objective-C (and other late-bound languages) this optimisation can be done at run time. For example, if you use NSRegularExpression with GNUstep, it uses ICU to implement it. ICU has a UText object that implements an abstract text thing and has a callback to fill a buffer with a row of characters. We have a custom NSString subclass and a custom UText callback which do the bridging. The abstract NSString class has a method for getting a range of characters. The default implementation gets them one at a time, but most subclasses can get a run at once. The version that wraps UText does this by invoking the callback to fill the UText buffer and then copying. The version that wraps in the other direction just uses this method to fill the UText buffer. This ends up being a lot more efficient than if we'd had to copy between two entirely different implementations of a string.
Similarly, objects in a typical JavaScript implementation have a number of different representations (something like a struct for properties that are on a lot of objects, something like an array for properties indexed by numbers, something like a linked list for rare properties) and will change between these representations dynamically over the lifetime of an object. This is something that, of course, you can do in C/C++, but the language doesn't provide any support for making it easy.
Depends on whether they care about performance. To give a concrete example, look at AlphabetSoup, a project that started in Sun Labs (now Oracle Labs) to develop high-performance interpreters for late-bound dynamic languages on the JVM. A lot of the specialisation that it does has to do with efficiently using the branch predictor, but in their case it's more complicated because they also have to understand how the underlying JVM translates their constructs.
In general though, there are some constructs that it is easy for a JVM to map efficiently to modern hardware and some that are hard. For example, pointer chasing in data is inefficient in any language and there's little that the JVM can do about it (if you're lucky, it might be able to insert prefetching hints after a lot of profiling). Cache coherency can still cause false sharing, so you want to make sure that fields of your classes that are accessed in different threads are far apart and ones accessed together want to be close - a JVM will sometimes do this for you (I had a student work on this, but I don't know if any commercial JVM does it).
Heck, in C / C++, such as transformation is actually illegal
Actually, it isn't if the compiler can prove that the layout is not visible outside of the compilation unit. I did have a student work on this, but the performance gains were negligible in most C code because complex data structures tend to leak across compilation unit boundaries (this may be less true with LTO). Even then, if you can recognise data structures that are bad then you can probably teach programmers not to use them, or put them in a standard library where their implementations can be easily changed.
It's much more interesting in environments with on-the-fly compilation, because then you can adapt data structures to use. Even then, you can do it outside of the compiler (for example, the NeXT implementations of the Objective-C collection classes would switch between a few different internal representations based on the data that you put in them).
Slashdot Mirror
Code runs. It continues to run. And, over time, the requirements change. Maintenance is adapting the code to the new requirements. If you don't understand why this is important, then I can only assume that no one is using code that you've written.
This is a confusion in terms. Personally I blame Sun. An interpreter IS a form of compiler, it is the term used to refer compilation at run time
No, sorry. A compiler is, in theoretical terms, a partial application of an interpreter to a program. In practical terms, a compiler transforms the input into some other form, which is then executed, whereas an interpreter executes the input directly. JIT compilation is still compilation. A just-in-time compiler is the term given to compilers that produce their output just before it is executed, as opposed to ahead-of-time (AoT) compilers, which produce it all up front, even if some paths are never executed.
There's some complication, because most environments that do JIT compilation also include interpreters that gather profiling information to incorporate into the JIT compiled code and to improve startup times. JavaScript implementations, in particular, often spend a reasonable amount of time in the interpreter because most web pages contain a load of JavaScript that's only run one or two times and the time taken to compile it is more than the time saved to execute it. Some have multiple compilers - JavaScriptCore from the WebKit project has an interpreter and three different JIT compilers that have different points in the space between compilation time and execution time - they'll recompile hot paths multiple times as they're executed more, with more optimisation each time. The key difference between the interpreter and compilers here is that the compilers are each invoked once on a segment of code and it's then executed without involving the compiler. The interpreter is involved every time the bytecode is run. It reads a bytecode and then jumps to the segment of interpreter code that executes it and then returns. The compiler takes a sequence of bytecodes, generates a fragment of native code to execute them, and then this fragment is combined with other fragments to produce a running program.
The shader compilers in drivers, however, are not JIT compilers. They are AoT compilers that are invoked at load time - often at install time. They don't compile the code just before it's run, they typically compile it once and cache the result for multiple invocations of the program. Some drivers (Windows and Android come to mind) have a mechanism that allows you to do the compilation at install time. Unlike most JIT environments, graphics drivers don't tend to use run-time profiling for optimisation, the bytecode exists solely for the purpose of providing an ISA-neutral distribution format.
Ugh, trust MS to fuck up a reasonable UI choice. On OS X, by default, it only happens for programs and requires you to close the dialog and then bring up the context menu for the program while holding a modifier key. You don't know how to do it unless you've actually read all of the way to the end of the dialog, so it generally protects people.
There are some interesting corner cases though, such as shell scripts. The file manager doesn't know if the thing that you tell it to open a shell script with is a text editor or a script interpreter, so may warn spuriously.
There are two problems. The first is that the OS allows you to run porn.jpg.exe having downloaded it from some random place on the 'net. I don't think that either OS X or Windows do: they'll both pop up a thing saying 'You are trying to run a program downloaded from the Internet, do you really want to?', which isn't normally something that happens when people try to open a file so ought to trigger them to avoid it (if it doesn't, then seeing the .exe extension probably won't either).
The second is that the OS allows programs and other file types to set icons at all before their first run. This also leads to confused deputy-like attacks where you think you're opening a file with one program but are actually opening it with something that will interpret it as code. The solution to this is probably to have programs keep their generic program icon until after their first run. If you double click on something that has a generic program icon, then you probably intend to run it...
This post needs a '-1 not even wrong' moderation. I started to write a reply to your points, but I honestly can't tell if you're trolling or completely fail to understand any of the parts of the hardware and software stacks involved.
Not really. Self has multiple prototype chains, Smalltalk and Java have only single inheritance. Both JavaScript and Smalltalk lack any declarative mechanism for defining classes in the language and do so by manipulating objects.
an LLVM-based bytecode for its shading language to remove the need for a compiler from the graphics drivers
This removes the need for a shader language parser in the graphics driver. It still needs a compiler, unless you think the GPU is going to natively execute the bytecode. If you remove the compiler from a modern GPU driver, then there's very little left...
There are a few. Smalltalk obviously does, as does Self. Lisp also can, depending on how it's used. JavaScript is probably the mainstream language that fits closest (it's actually very close to Smalltalk). Java and C# both mostly do, though they wouldn't count as pure OO.
C++ is a language that is very good for generic programming. It doesn't really meet Alan Kay's definition of OO (and he's the one who coined the term), nor does it pass the Ingalls Test for OO. It has classes, but method dispatch is tied to the class hierarchy so if you want to really adopt an OO style you need to use multiple inheritance and pure abstract base classes, which is a very cumbersome way of using C++.
The worst C++ code is written by people who are thinking in C when they write C++, but the second-wrost C++ code is written by people who are really thinking in Smalltalk. If you're one of these people, then learn Objective-C: the language is far better at representing how you think about programs.
Any programming language can be used to write code in any style. You can write good OO code with a macro assembler if you want. However, every language has a set of styles that fit naturally with the language and ones that don't. You can force C++ to behave in an OO way, and it sort-of works, but it's not using the language in the most efficient way.
The main advantage of auto is in templates, where the type is something complex derived from template instantiations. You simply don't want to make it explicit. Oh, and in lambdas, where explicitly writing the type of the lambda is very hard (though you generally cast to std::function for assignment). As to using a float instead of an int... I have no idea how you'd do that with auto. The type of auto is the type that you initialise it with. If you're using a platform where you don't have hardfloat, then why do you have APIs that return floats? There's your bug, the use of auto was just a symptom.
And if you've never seen anyone use the algorithms library, then you must be using C++ in a very specialised environment. I've not seen any C++11 code that didn't use std::move. I've rarely seen a nontrivial C++ file that didn't use std::min or std::max, and most code will also use std::copy. The only code that I've seen that didn't use the algorithms library included is own, poorly optimised and buggy, versions of several of them.
First, WindowsMaker doesn't use Objective-C, it's written in C. However, GNUstep, which is the open source implementation of the Cocoa frameworks (originally the OpenStep specification, but they're tracking Apple changes) could use more help! Oh, and we support (on *NIX) a superset of the Objective-C language that Apple supports on their products, so I wouldn't say that Obj-C is more limited on Linux.
That said, and I say this as the maintainer of the GNUstep Objective-C implementation, I'd recommend C++, but with the two caveats:
C++11 and C++14 have cleaned up C++ a lot. With shared_ptr and unique_ptr, you can write code with sane memory management. With perfect forwarding, lambdas, and variadic templates, you can write code that has most of the benefits of a late-bound language. I like a lot of Objective-C, but Apple broke the 'simple, orthogonal syntax' when they added declared properties and a few other things. Any successful programming language eventually becomes a mess of compromises and ugly corners. Some, like Python and C++, start that way, but at least C++ has been slowly improving over the last couple of versions.
The one thing where Objective-C is still a clear winner is in writing libraries that want to maintain a stable ABI. This is insanely difficult in C++ because the language doesn't have a clean separation of interface and implementation and relies a lot on inlining and static binding for performance. The down side, of course, is that once you have a library in Objective-C you're limited to consumers who also want to use Objective-C.
Oh, and Qt GUIs suck beyond belief on OS X - not sure what they're like on Windows, but I wouldn't recommend them for a portable UI. Good MVC design and a native UI is the only way to go if you really want a cross-platform GUI app that doesn't suck.
If Pluto is a planet, then so is Eris (which is larger), and Earth's moon (around 5 times larger than Pluto) is possibly a binary planet. Ganymede, the largest moon in the solar system, is under 3% the mass of Earth and is about ten times bigger than Pluto. There are quite a lot of moons bigger than Pluto, so would you want to classify them all as planets?
Zoom right in on the bits that you think are white, so that they fill your entire monitor. They're obviously blue. For a lot of us, that's the colour that we see when we look at it in context as well. I can see how you'd interpret it as being white by overcompensating for the colour in the bottom right, but that doesn't stop you from being wrong. The gold bits are gold when you zoom in (mostly, some are black), but a shiny black often looks yellow-gold in overexposed photos.
Who says the OS should provide nothing useful and let app makers make their money on it?
If you set up a straw man, then it's very easy to kill it. The issue is not an OS providing something, it's that Microsoft, which had a near-monopoly in the desktop space, used the money from selling the OS to fund development in another market (browsers) and then bundled their version, undercutting the competition with cross subsidies. There was a thriving browser market before IE was introduced, but it's hard to compete when most of your customers are forced to pay to fund the development of your competitor.
The last 5 years is long after this was an issue. Windows 98 was the release that triggered the lawsuit and it had been EOL for a long time five years ago.
Generally Fundamental Evangelical Christians teach humility and service to others and subscribe to the view that others are more important than me. That's exactly opposite to what you claim "ALL" religion is.
Really? Because that's exactly the set of values that I'd choose to indoctrinate my serfs with.
"You know that those who are recognized as rulers of the Gentiles lord it over them; and their great men exercise authority over them. But it is not this way among you, but whoever wishes to become great among you shall be your servant; "For even the Son of Man did not come to be served, but to serve, and to give His life a ransom for many."
Or, to summaries: 'Hey oppressed people, don't think about following a leader from amongst yourself, that kind of thing always ends badly'.
This obviously raises the question of why, when you have a serial console with working flow control, do you need laplink at all? If you have a null modem cable and a lot of patience, then you can always extract files by writing them to standard output and reading them off with a serial program - just make sure that you've correctly configured the UART first. If you're a bit paranoid, then running something like par2 first (I think there are DOS binaries and they're pretty small, though they may take a while on a 386) and you'll be able to recover small data errors.
Copying 160MB over a serial connection won't be fast, but I'm assuming that this isn't urgent if it's been sitting on a 160MB disk for years without backups...
IE itself can EASILY be removed from a system. Delete the EXE, done. Its been that way ALWAYS. Even during the court battles.
While this is technically true, it's also misleading. You could delete iexplore.exe, but don't expect a working system afterwards. Lots of other parts of Windows (and Office) invoked iexplore.exe directly, rather than providing a web view with MSHTML.dll or invoking the default browser via the URL opening APIs.
It was never part of the kernel and never ran with system-level privileges.
I've not been paying much attention to Windows for a few years, but does IE still have the same poor security reputation? I was under the impression that it did the multiprocess thing and sandboxed each instance, putting it in the same ballpark as Chrome and Safari and ahead of Firefox (which is finally going to start adding sandboxing support now). Did they manage to screw up the sandboxing and make something that's still trivially exploitable, or are you just repeating ten-year-old information?
I saw a recent review of a smartphone that had two screens, one LCD and one eInk. The modern eInk display is able to get a high enough refresh for interactive use and doesn't drain the battery when done. The screen that I'd love to see is eInk with a transparent OLED on top, so that text can be rendered with the eInk display and graphics / video overlaid on the OLED. The biggest problem with eInk is that the PPI is not high enough to make them colour yet. You get 1/3 (or 1/4 if you want a dedicated black) of the resolution when you make the colour and so that means you're going to need at least 600PPI to make them plausible.
The other problem that they've had is that LCDs have ramped up the resolution. My first eBook reader had a 166PPI eInk display. Now LCDs are over 300PPI but the Kindle Paperwhite is only 212PPI, so text looks crisper on the LCD than the eInk display, meaning that you're trading different annoyances rather than having the eInk be obviously superior. With real paper you get (at least, typically a lot more than) 300DPI and no backlight.
Your neurones also become very complex, as they need to all be network nodes with store and forward and they are going to have to handle multiple inputs every cycle (consider a node in the middle. In the first cycle it can be signalled by 8 others, in the next it can be signalled by 12 and so on. The exact number depends on how you wire the network, but for a flexible implementation you need to allow this.
What's the justification for compilation unit boundary? It seems like you could expose the layout of the struct (and therefore any compiler shenanigans) through other means within a compilation unit. offsetof comes to mind. :-)
That's the granularity at which you can do escape analysis accurately. One thing that my student explored was using different representations for the internal and public versions of the structure. Unless the pointer is marked volatile or any atomic operations occur that establish happens-before relationships that affect the pointer (you have to assume functions that you can't see the body of contain operations), C allows you to do a deep copy, work on the copy, and then copy the result back. He tried this to transform between column-major and row-major order for some image processing workloads. He got a speedup for the computation step, but the cost of the copying outweighed it (a programmable virtualised DMA controller might change this).
I suppose you could do that in C++ with template specialization. In fact, doesn't that happen today in C++11 and later, with movable types vs. copyable types in certain containers? Otherwise you couldn't have vector >. Granted, that specialization is based on a very specific trait, and without it the particular combination wouldn't even work.
The problem with C++ is that these decisions are made early. The fields of a collection are all visible (so that you can allocate it on the stack) and the algorithms are as well (so that you can inline them). These have nice properties for micro optimisation, but they mean that you miss macro optimisation opportunities.
To give a simple example, libstdc++ and libc++ use very different representations for std::string. The implementation in libstdc++ uses reference counting and lazy copying for the data. This made a lot of sense when most code was single threaded and caches were very small but now is far from optimal. The libc++ implementation (and possibly the new libstdc++ one - they're breaking the ABI at the moment) uses the short-string optimisation, where small strings are embedded in the object (so fit in a single cache line) and doesn't bother with the CoW trick (which costs cache coherency bus traffic and doesn't buy much saving anymore, especially now people use std::move or std::shared_ptr for the places where the optimisation would matter).
In Objective-C (and other late-bound languages) this optimisation can be done at run time. For example, if you use NSRegularExpression with GNUstep, it uses ICU to implement it. ICU has a UText object that implements an abstract text thing and has a callback to fill a buffer with a row of characters. We have a custom NSString subclass and a custom UText callback which do the bridging. The abstract NSString class has a method for getting a range of characters. The default implementation gets them one at a time, but most subclasses can get a run at once. The version that wraps UText does this by invoking the callback to fill the UText buffer and then copying. The version that wraps in the other direction just uses this method to fill the UText buffer. This ends up being a lot more efficient than if we'd had to copy between two entirely different implementations of a string.
Similarly, objects in a typical JavaScript implementation have a number of different representations (something like a struct for properties that are on a lot of objects, something like an array for properties indexed by numbers, something like a linked list for rare properties) and will change between these representations dynamically over the lifetime of an object. This is something that, of course, you can do in C/C++, but the language doesn't provide any support for making it easy.
In general though, there are some constructs that it is easy for a JVM to map efficiently to modern hardware and some that are hard. For example, pointer chasing in data is inefficient in any language and there's little that the JVM can do about it (if you're lucky, it might be able to insert prefetching hints after a lot of profiling). Cache coherency can still cause false sharing, so you want to make sure that fields of your classes that are accessed in different threads are far apart and ones accessed together want to be close - a JVM will sometimes do this for you (I had a student work on this, but I don't know if any commercial JVM does it).
Heck, in C / C++, such as transformation is actually illegal
Actually, it isn't if the compiler can prove that the layout is not visible outside of the compilation unit. I did have a student work on this, but the performance gains were negligible in most C code because complex data structures tend to leak across compilation unit boundaries (this may be less true with LTO). Even then, if you can recognise data structures that are bad then you can probably teach programmers not to use them, or put them in a standard library where their implementations can be easily changed.
It's much more interesting in environments with on-the-fly compilation, because then you can adapt data structures to use. Even then, you can do it outside of the compiler (for example, the NeXT implementations of the Objective-C collection classes would switch between a few different internal representations based on the data that you put in them).