However engine makers either can't or won't make engines big enough to make a plane the size of a 747 or A380 with only two engines. One large plane means one aircrew, one landing slot at the airport and generally larger planes have better fuel economy per passenger mile.

So if you can fill 747s or A380s then they may still make sense compared to a greater number of smaller 2-engined planes.

Not to diminish your point (you were probablly talking about legality rather than feasability) but I expect you probablly could get over 600 passengers on a 777 if you were prepared to throw the safety rules out the window. el-al once put over a thousand people on a 747 http://www.guinnessworldrecord... . If we assume a similar ration of "maximum legal passenger capacity" to "maximum possible passenger capacity" then you should be able to stuff about 742 passengers on a 777.

I disagree with your professor here, each tool you add to the toolbox carries a cost. Especially if you want to maintain the code on a long term basis or reuse code between projects. So you need to strike a balance between the number of tools in your toolbox and the appropriateness of the tool to the job.

It's pretty difficult to avoid C/C++, even if you don't actually code in it will find the interfaces to your operating system are defined in terms of C and possibly C++. If you are programming devices too small to run an OS you will often find a C (and maybe C++ if you are lucky) compiler is the only compiler available. So the question with a new language is not just "is this better for the application than C/C++" but "is this language sufficiently better than C/C++ to justify the costs of adding it to the toolbox and the cost of potential future problems if I want to port the application to a different target or reuse parts of it in an applicaiton for a different target".

And much as I like object pascal I have to say that I think the answer to that question is probablly no.

but in practice what you have in c is more likely

double a = b/c

is that doing floating point division or floored division? you can't tell without going and searching for the defintion of b and c and if you want floating point division of two integer arguments (a perfectly reasonable thing to want to do in many situations) you have to start putting in typecasts. It gets even worse in dynamically typed languages that use derivatives of C syntax.

Unfortunately it seems it's owner has gone to the "charge locked in customers a shitload of money" strategy. That may be profitable in the short term but it's not going to win you many new customers when the alternatives are free. Theres a starter edition whose price is a bit more paletable but whose license terms are most certainly not.

Theres lazarus of course, not sure how that compares nowadays.

And the lesson is if you care about privacy you should avoid storing your data with multinational companies because every nation in which the company operates is a nation that could potentially coerce the company into handing over your data..

AIUI the original plan was not to have it at all but they couldn't get office converted to metro in time so they included the desktop mode but crippled it by forbidding desktop apps other than the handful bundled with the OS (a cut down version of office, some of the built in windows tools).

The only reason I can see for crippling the desktop mode on the arm port was pushing developers to switch to metro.

Would windows on arm have succeeded if people could just recompile their software for it rather than having to redesign their software to fit within the constraints of metro and then on top of that pay a 30% appstore fee to MS? We will never know for sure but I strongly suspect it would have had a better chance than in the crippled state it was sold in.

From a software perspective what sets memory/IO mapped busses apart from each other is how the OS reads and/or sets their configuration, not what they are like on an electrical level. ISA was either manually configured or (later) used a hacked on plug and play mechanism. EISA had it's own configuration system.

Java protects against some of the common screwups that lead to security holes in C (and to a lesser extent C++) programs. It simply won't let you do things like read/write beyond the end/before the start of an array, perform an unprotected typecast between two object types or use memory that you have already freed. However there are many other classes of security hole it doesn't help with.

Java sees lots of security patches for a couple of reasons

1: Java provides sandboxing features intended to allow safe running of untrusted code. Unfortunately such sandboxes seem to be very difficult to get right (whether it's java applets, flash or javascript in browsers).
2: Java provides a massive standard library. It's virtually an OS within an OS and that means lots of code to be potentially vulnerable (especially in light of point 1)

The tricky situation comes if you've built your application on top of windows network functionality rather than directly on top of TCP/IP. That can make it very difficult to lock things down with a firewall because the high risk ports and the ports your application relies on can be one and the same.

And then there is a the question of portability. There is a C compiler for virtually anything powerful enough to support a compiler. C++ rules out some of the smaller microcontrollers but is available virtually everywhere else. Sure the code may need some work to remove platform specific assumptions, deal with missing library functionality on very small targets or deal with compiler bugs but that is still likely to be much easier than a complete rewrite.

Any new language that is intended to be compiled to native code (either at compile time or at runtime by a JIT) has a massive uphill struggle to come close to the portability of C/C++. AIUI GDC only got proper support for arm linux very recently and is still missing proper support (e.g. the libphobos standard library) for many architectures.

Scripting languages have things a bit easier because they usually piggyback on the existing C/C++ compilers. So the developers for the most part only have to worry about OS portability, not CPU portability.

Theres a couple of causes

One is something called interleaving, DSL uses forward error correction algorithms to provide resistance to noise/interference. However these algorithms fall apart if there are too many bit errors in a block. To reduce the chance of this happening in the face of interference spikes they interleave the blocks (such that a burst of interference has a small effect on multiple blocks rather than a large effect on one block) but this comes at a price in terms of latency. At least here in the UK some of the more techie ISPs will turn this off if asked.

The other is that your "first hop" can be considerablly longer than just the DSL line to the telephone exchange because your connection tunnels through the phone providers network to reach the ISP. If you are on a small ISP in the UK your packets will most likely go to london before they hit a visible IP router. Larger providers are likely to hit the IP network sooner but it may still be a considerable distance from where you live.

Desperate teenagers who are priced out from getting insurance any other way!

As I understand it it comes down to table lookups. The details of full unicode support are unfortunately not trivial and theres a reason libraries like ICU are as big as they are.

As I understand it normally the base character is first and then things added to it follow.

So if you cut the end off a string and cut in the middle of a cluster then the last character may be missing some bits but the string is likely to be otherwise OK.

If you cut the start off a string and cut in the middle of a cluster things get messier. You then have combining characters at the start of the string with nothing to combine with. If you just ask a display library to display it then it's going to be down to the display library what happens but I expect the combiners will either be not displayed at all or displayed with no base. If you add the cut string to the end of another string then the combiners will combine with whatever was at the end of the string you combined it with.

All in all you will probablly end up with something "ugly but usable".

No it's moved from mainstream support to extended support. Still nearly 5 years left before EOL.

You don't get any free support incidents with OEM copies anyway and most crippling bugs will have been fixed or worked around by now. So for most users the transition from mainstream support to extended support isn't really a massive deal.