Posts by AndrueC

Re: In a complete about face...

Do the shoes save our soles?

Re: Surely it's just a bit of civility

Or people who assume that I will be happy to be called Andy (or are just too lazy to bother using my full name).

When I was a young lad (back in the 80s :-/ ) I had a boss who insisted on calling me Andy 'Because it's easier'. I made a point of ignoring him. It was only a holiday job anyway.

Jesus saves!

..then Linneker gets it in on the rebound.

Oh, wrong joke. Sorry.

Comparing it the the analogy TV switch off is not the same, as that didn't involve having to visit every premises in the UK within 5 years.

Nor does this. It's pretty much the same process. The TV switch over required people to buy and configure a set top box. This switch over requires them to install and configure a VoIP adaptor. The only people who will need a home visit are the relatively small number of people who can't connect a small plastic box to their LAN and unplug their existing telephone from the master socket and plug it into the small plastic box.

Granted people who don't currently have broadband will need to get it installed but I assume there's some kind of plan for that. Possibly a small router/VoIP adaptor that can be plugged into the master socket. Still doesn't require a home visit for most people.

The only area of complexity is probably configuration. Currently I believe most VoIP systems are manual but hopefully the industry can spec up an autoconfiguration framework. Shouldn't be all that difficult to piggyback something of DHCP, DNS. Or maybe they can do something with PPP.

UK ISPs (actually their official name is CP - Communication Provider - because most do more than just internet services) are free to provide a VoIP service if they want (mine does but currently only to business users). It's just that until now there's been little need to make it available to residential customers. It's far simpler all round to let residential customers continue doing what they have been for the last 40 years - buy a phone and plug it into the phone socket.

Any CP can resell the openreach service through the WLR product. That's how most CPs (including BT) provide telephony services. Some CPs have gone a different route (called LLU) and have installed their own telecoms equipment in exchanges. They should be unaffected by the withdrawal of WLR but are presumably planning what they intend to do if/when copper is actually shut down.

From the sound of it the UK telecoms industry appears to intend doing exactly what you say other EU countries did. But first all the CPs have to be given a chance to comment on the plans and to prepare themselves. That's all this is. A perfectly sensible planning session to minimise the disruption.

WLR is very widely used and openreach can't just cancel the product overnight and leave CPs scrambling to provide their customers with an alternative.

Re: That's simply incorrect.

The issue I have is that using / try finally and analogues, require you to remember to use them.

Absolutely, that's why I don't consider C# using{} to be true RAII. Looking at our main code base of just over 4,000 files and nearly 17MB of source we've used finally 24 times. We've apparently used using{} 365 times (which seems surprisingly low).

I fell in love with RAII when I was a C++ developer and still miss it for complex resources. However what I do like about C# is the way I can pass classes into and out of methods without having to worry about who owns them or will dispose of them.

C++ has boost::share_ptr but now it's the C++ programmer who has to remember/choose to do something extra. There's no way I can search our source for all the places where we throw classes around but I bet it's a lot more than 365 times so on balance we've gained more from being able to do that than we've lost in having to remember to use using{} or finally{}.

But it's all swings and roundabouts. This is why we don't have (and shouldn't have) one language to rule them all. In other post someone replied to me pointing out that the .NET framework was probably written in C++. And that would be an excellent choice for such a project. It's efficient, powerful and performant. The people writing that code will be highly skilled and knowledgeable C++ developers and are thus a lot more likely to do things properly and safely.

It bothers me that some of the posters here seem to be thinking in terms of either/or. As if praising a feature of C# means that C++ should be dropped. I certainly mean no such thing. I'm simply highlighting one aspect of a certain class of language (managed) that I feel is a significant advantage over another class of language (unmanaged).

That doesn't mean that C# is on average better than C++. That's a pointless and dangerous way of thinking. It just means that if you are planning a new software project you should be aware that different languages have different strengths and you should feel free to pick the most suitable language for the task and for the staff you have available.

One thing I miss from C++ is the templates. C# has generics but it's a different way of thinking. In some ways they are better because we get full type checking. But in other ways they are worse because they require that you're working with a common 'ancestor'.

In C++ a template can be defined to call Wibble() on its specialisation and it will work with anything that has a Wibble() method. C# generics don't allow that unless you resort to reflection in which case a pox on you. Reflection is powerful and good but not as a way to implement a 'template' :)

C++ will protect you from errors if you use it correctly.

Yes, we know. But the point some of us are trying to make is that other languages protect you either if/when you don't use them correctly or by simply not allowing you to do stupid stuff. And programmers are human. We don't always do things correctly and we sometimes do stupid stuff.

In C++ it is easy to copy data off the end of an array. You might not notice you're doing that for a long time since most RTLs sub-allocate large blocks and running off the end of one array might not cause an access violation if the addresses lie within an allocated block of memory. You are free to trample on any areas of memory that belong to your process.

And std::vector doesn't prevent you using memcpy. You can memcpy() with a std::vector as the source and/or target without any comment from the compiler or RTL,

But in C# for instance if you supply Array.Copy() with bad ranges you'll get an exception and the code will safely stop. There are ways to do an unsafe array copy in C# but they are esoteric and by design are a pain in the bum.

As I've written elsewhere: I'm not trying to bash C++. But its proponents ought at least to understand that other languages have better protection and therefore they should consider using those languages where the efficiency and performance of C++ is not a requirement.

If you have a program written by someone who can't count, index an array or stay within memory bounds, then the language really isn't the problem.

Meanwhile, back on planet Earth.

These are extremely common problems and if you are trying to imply that no-one should employ a programmer that has or can fall victim to such a mistake then you're going to severely limit the pool of potential employees. Given that the world has a long-standing shortage of programmers of all abilities that doesn't bode well.

I'd also suggest that if you're attitude to a problem is 'we shouldn't employ stupid people' then you have a management problem. When you write code I /assume/ you include safeguards. Code that detects when things are not right and that acts to protect the system. Well that's what managed languages are doing.

And they are doing it more cheaply. There's a maxim in software development (all forms of engineering probably) that the sooner you catch an error the cheaper it is to fix it. Well you write code to detect and guard against out of range errors. Good. But some of us are using languages that don't let us (or discourage us) from making such mistakes in the first place. That's better because it's cheaper not to make a mistake than to detect and correct it.

More usually, you then see things like huge memory over-use because they just want everything in a memory-safe object permanently in memory all the time and let the computer worry about when to get rid of it (if it ever safely can!). I'm pretty sure that explains a lot of the "drag" of the memory-safe languages - a complete lack of understanding of the memory size/usage/management.

Memory is cheap and modern OSes page to disk anyway. For most applications the fact that a program would eventually die from memory mismanagement after a week is unimportant. Most applications rarely run longer than the working day anyway. And if developed with a managed language if the application crashes..meh. The users swears cracks a joke with their colleague and starts it up again. No real harm done.

Most applications don't have to be particularly robust, nor particular performant. They just have to not corrupt themselves or increase security risks to the system. Writing all software to the kinds of standards you advocate would cripple the industry. There aren't enough programmers of a high enough calibre so you'd just slow down the pace of innovation to a crawl.

Re: Unfair C++ bashing

This is because you can't write the underlying code (of their libraries) in that language yourself. This limits them very much.

Does it? I've been developing software in C# for well over ten years now and I've never been limited. The main focus of the company I work for is capturing digital audio and directing it to someone (or something) that can transcribe it then directing it on to someone else to review it, then on to someone else who can dispatch or file it. We interact extensively with the Windows audio API, third party information providers, web servers (some we wrote ourselves hosted on Azure).

Our main product is the market leader and used by more than half of GP surgeries in the UK. I don't feel limited. I feel empowered. A small team (two of us for this particular project) have achieved what we have because of C# not despite it.

If you need to talk to the hardware or the operating system from C# there is almost always a Nuget package available that does that. And if not there's always p/invoke. I can call any Windows API function that exists and it's usually pretty easy and safe to do so.

C++ is a powerful language and in the hands of a good programmer is great for almost anything. Arguably it underpins a lot of software development around the world. But there's a world-wide shortage of programmers so we have to accept that a significant number of our breed are not good. Frankly some of us are rubbish. But the software needs to be written. C#, Java, Rust, Python all the modern, managed languages are a great way to address this problem.

Re: That's simply incorrect.

I'll agree about RAII although I've got used to not having it now. C# has using{} which is almost RAII. It's not needed often but at least it avoids any ugliness where hierarchical init/teardown is needed. I haven't given any thought to GC or memory use for a long time. Of course that might mean that all the applications I work on fall over eventually but that appears not to be the case. Least-wise we have web servers that have been running uninterrupted for months and our desktop applications seem able to stay up for a couple of a days. We don't really need them to be 24/7/52 as for most of our customers if our application will survive the working day that's plenty good enough.

..true. If know about them and how to write them.

With languages like C# and Java it's a lot harder to write bad code. If code compiles it's almost certainly safe to run. As long as programmers are human and prone to human mistakes there will be value in languages that protect them from themselves.

Re: Unfair C++ bashing

..but you aren't forced to nor encouraged to. It's correct to say that you can avoid common errors in C++ by writing safe code. That's also true in assembler. It might be true in all languages. However some languages (like C#) make it difficult to screw up.

In C++ there are several ways to create strings and to pass them around. 'char *' remains an option and unless things have changed in the last decade the compiler doesn't flag it as bad programming. For sure we'd hope that no currently active C++ developer would use it (or would least go with 'const char *' to signal their intent if not provide actual protection) but it's their choice. And if they are interacting with a third party library or OS API they might have no choice.

But if you're working in C# you have to go out of your way to pass pointers to arrays around. Even calling third parties and API calls doesn't do that thanks to p/invoke in most cases. You might sometimes have to reach for the Marshal class but no-one does that out of choice.

This isn't to say that you can't write dangerous code in C# (or other higher level languages) but at least the language and runtime make it a lot more difficult. You generally have to try to be stupid in C# whereas in C++ you just have to be careless, thoughtless or lazy.

I thought the plan was to run the fibre to the DP rather than the cabinet, then just using G.FAST down the drop cables to hit the mythical 1Gbps.

Openreach's plan for FTTP is GPON. That's fibre to a passive optical switch then fibre to each property from there. True FTTP where each property has a dedicated fibre cable back to the exchange is not currently on the cards.

There was talk of using G.FAST from lamp posts and underground chambers but that seems to have been dropped. I think the problem was that the cost difference between 'G.FAST at the end of the road' and 'TPON switch at the end of road' was too small. It's cheaper to drop an unpowered PON node in a hole than a powered G.FAST DSLAM (the link back to the exchange is the same for both). For GPON the final fifty metres of fibre for each property will be more expensive but that can be done on demand and covered by installation costs.

While you rightly identify that V.FAST won't provide more speed to a significant number of users, I suspect it would allow a 100Mbps option (technically VDSL2 already does, but there are stability issues using this) but more importantly, it would address speed issues for those currently on VDSL2 cabinets but stuck at <40Mbps.

Sadly, no it won't. All DSL versions are impacted by distance for the same reason - higher frequencies do not travel as far. VDSL uses a higher range of frequencies than ADSL and that's why it drops off sooner. G.FAST uses higher frequencies than VDSL and that's why it's seriously distance limited.

If you can't get full speed VDSL (ie;80 Mb/s sync) you're unlikely to be able to get any form of G.FAST. There have been reports of people syncing in the high 70s on VDSL managing to get a viable G.FAST connection (just about achieving BT's self-imposed 100Mb/s threshold) but their upstream suffers as a result. A lot of them cancel the service and return to VDSL in order to get a more useful upstream speed.

A line that can't even support 40Mb/s with VDSL is going to be totally beyond G.FAST. It probably won't even register the presence of a signal let alone a viable one.

Using an analogy: Imagine there are a ten shelves in front of you each shelf contains better items than the one below. The bottom two shelves are cheap tat but you can reach both of them. The next four shelves are much better quality but unfortunately you can only reach three of them. The top five shelves have top notch gear on them. Unfortunately you have no chance whatsoever of getting at that stuff because you can't even reach the top shelf of the mid-tier stuff.

G.FAST could benefit the more distant users but only if it was allowed to utilise the full spectrum of frequencies. For technical reasons that is impossible. All three variants of DSL have their assigned frequency ranges and will never stray outside of them. G.FAST can only usefully operate on copper loop lengths less than 300 metres. Far less on aluminium of course.

Re: Step 1

Any new premises: FTTP straight away.

That's up to the property developer. Openreach runs schemes to encourage property developers to request fibre (things like same cost install as copper) and some developers are choosing to do that. Unfortunately a number of developers have been slow to make that choice.

Openreach can/will only install what the developer asks them to. If the developer asks for copper then copper is what openreach will install.