It's a reference-counting garbage collector that never allows the reference count to exceed one, and requires explicit reference count management from the programmer (free() calls).
A good programmer will know the platform well, and will choose algorithms and code constructs that are appropriate for it. When these are chosen poorly, performance suffers. This is not a situation that is unique to Java, C#, C++, or any other platform.
he's probably talking about TFS as its known to be useless at merging. Nothing to do with VS at all, though his problems with solution projects and CI could be more to do with MSBuild and TFS's pretty poor build system.
Yeah, we don't use TFS. I haven't come across any issues with MSBuild as a build system, though.
The only thing I can think of where he'd have a point that VS is poor is the way projects depend on each other. Microsoft's "best practise" is to put all projects into a single huge solution so they can reference each other rather than building projects and referencing them from a common directory (as.net projects don't seem to like absolute paths in references... and if you put a reference path in your project, it turns out it gets stored in the per-user file, not anything that gets stored in source control. The old C++ way of include and link paths was a much better system when projects start to get big)
You're incorrect. Here's an excerpt from an old.csproj (which you should be storing in source control... the.suo and.csproj.user files are the per-user files) which shows a reference to a pre-compiled.dll file:
Note that using absolute paths is generally a poor idea, as it requires every development machine to be set up exactly the same. Instead, solutions should contain subdirectiores, each containing one project. Project references such as the one above then always work, even when projects participate in multiple solutions (we do this ALL THE TIME). It took some time for us to work out a solid process on this, but we seem to have arrived at a very satisfactory solution. When we do references to pre-compiled DLLs (and we only do this for third-party libraries), there's a subdirectory at the solution level that contains those. That way, when multiple projects reference (for example) SQLite, they all reference the same version of it.
Wait, what? There's a million DI frameworks for Java too. I'm not defending anything, except maybe competence and avoiding reliance on "patterns" and "frameworks".
Overlapped I/O (or, on Unix, AIO). Learn it. Live it. Dedicating a thread to each open socket is the most brain-dead way to implement a system. It's like bubble sort for sockets. It's simple, it's easy, it's what the noobs do the first time around, but it should never, ever, be used in a system that requires performance.
By the way, C# supports asynchronous I/O using completion ports (on Windows). I don't know for sure if Java does, but I think NIO.2 might.
6 times the RAM required for a GC to function properly? Over what? Just how, exactly, is malloc()/free() not a garbage collector? It serves the same purpose, it simply requires more handholding to do so.
You're pretty ignorant. If you measure "performance" by checking how high you can get the graph in the task manager, trust me, I can cap out as many CPU cores as a machine has, and do a lot of I/O simultaneously, in Java or C#, and I can do it trivially.
Furthermore, thanks to the JIT compiled nature of Java and C#, number crunching is just fine on these platforms, thank you very much. Even in the early days, right when.NET came out, it was fine. We ran a simple number-crunching test, calculating Fibonacci numbers, and even then, C showed zero advantage over C#, and neither showed much advantage over VB6 for that particular problem.
I enjoy target shooting. Is that a legitimate purpose? If not, should we ban snowboards, since they have no legitimate purpose, and injure people all the time?
Is your Python implementation interpreted, or JIT-compiled? Is your Java implementation interpreted, or JIT-compiled? Is your C# implementation interpreted, or JIT-compiled?
Of the three, at least two are almost certainly JITted. Can you guess which two?
Um, given the subject of the article, I'm pretty confident construction has begun, and so I'm going to apply basic logic here and say that 2017/2018 are reactor start-up dates.
Slashdot Mirror
Ssh. They're having fun, let them be.
What does malloc()/free() do that GC does not? What does GC do that malloc()/free() do not?
If I'm wrong, show me. What word did I redefine? If I'm so obviously wrong, it should be easy for you to point to how I did it.
So, I'm clever, therefore I'm wrong? Sorry, I don't follow the logic. If I'm wrong, show me. If not, skip the ad hominem.
It's a reference-counting garbage collector that never allows the reference count to exceed one, and requires explicit reference count management from the programmer (free() calls).
A good programmer will know the platform well, and will choose algorithms and code constructs that are appropriate for it. When these are chosen poorly, performance suffers. This is not a situation that is unique to Java, C#, C++, or any other platform.
he's probably talking about TFS as its known to be useless at merging. Nothing to do with VS at all, though his problems with solution projects and CI could be more to do with MSBuild and TFS's pretty poor build system.
Yeah, we don't use TFS. I haven't come across any issues with MSBuild as a build system, though.
The only thing I can think of where he'd have a point that VS is poor is the way projects depend on each other. Microsoft's "best practise" is to put all projects into a single huge solution so they can reference each other rather than building projects and referencing them from a common directory (as .net projects don't seem to like absolute paths in references... and if you put a reference path in your project, it turns out it gets stored in the per-user file, not anything that gets stored in source control. The old C++ way of include and link paths was a much better system when projects start to get big)
You're incorrect. Here's an excerpt from an old .csproj (which you should be storing in source control... the .suo and .csproj.user files are the per-user files) which shows a reference to a pre-compiled .dll file:
<Reference Include="SecureBlackbox, [...]">
<SpecificVersion>False</SpecificVersion>
<HintPath>C:\Program Files\EldoS\SecureBlackbox.NET\Assemblies\NET_20\SecureBlackbox.dll</HintPath>
</Reference>
Here's an excerpt from a .csproj showing project references (which are preferred):
<ProjectReference Include="..\myproj\myproj.csproj">
<Project>{F4895F92-1E42-4322-9886-0585A5F06035}</Project>
<Name>myproj</Name>
</ProjectReference>
Note that using absolute paths is generally a poor idea, as it requires every development machine to be set up exactly the same. Instead, solutions should contain subdirectiores, each containing one project. Project references such as the one above then always work, even when projects participate in multiple solutions (we do this ALL THE TIME). It took some time for us to work out a solid process on this, but we seem to have arrived at a very satisfactory solution. When we do references to pre-compiled DLLs (and we only do this for third-party libraries), there's a subdirectory at the solution level that contains those. That way, when multiple projects reference (for example) SQLite, they all reference the same version of it.
There are CI solutions for TFS, but we don't use TFS, we use Subversion. I imagine that when we move off Subversion it will be on to Git.
Besides, the poster I replied to (which may or may not be you) specifically said they'd be interested in hearing about C# DI frameworks...
Wait, what? There's a million DI frameworks for Java too. I'm not defending anything, except maybe competence and avoiding reliance on "patterns" and "frameworks".
Including his sig...
Please, for the love of all that's holy, do not let Javascript become the "one true language". It's a steaming pile of terrible language design.
Also, Python (the language) is for people who didn't think VB's whitespace-significant syntax went far enough.
Overlapped I/O (or, on Unix, AIO). Learn it. Live it. Dedicating a thread to each open socket is the most brain-dead way to implement a system. It's like bubble sort for sockets. It's simple, it's easy, it's what the noobs do the first time around, but it should never, ever, be used in a system that requires performance.
By the way, C# supports asynchronous I/O using completion ports (on Windows). I don't know for sure if Java does, but I think NIO.2 might.
6 times the RAM required for a GC to function properly? Over what? Just how, exactly, is malloc()/free() not a garbage collector? It serves the same purpose, it simply requires more handholding to do so.
We do CI with C#, using TeamCity. I don't know what these "conflicts" are that you see all the time, but perhaps you're the problem?
There's a million of them. Take your pick. Or, you could just write maintainable/testable code without relying on some jackass' DI "framework".
You're pretty ignorant. If you measure "performance" by checking how high you can get the graph in the task manager, trust me, I can cap out as many CPU cores as a machine has, and do a lot of I/O simultaneously, in Java or C#, and I can do it trivially.
Furthermore, thanks to the JIT compiled nature of Java and C#, number crunching is just fine on these platforms, thank you very much. Even in the early days, right when .NET came out, it was fine. We ran a simple number-crunching test, calculating Fibonacci numbers, and even then, C showed zero advantage over C#, and neither showed much advantage over VB6 for that particular problem.
How do students have a union? What are they going to do, strike? Refuse to attend classes? I'm sure the school is shaking in its boots...
Disclaimer: I'm from the US and have very little post-high-school formal education.
I enjoy target shooting. Is that a legitimate purpose? If not, should we ban snowboards, since they have no legitimate purpose, and injure people all the time?
They're called "absorption refrigerators": http://en.wikipedia.org/wiki/Absorption_refrigerator
The point was, if you use Java or C#, there is no "if you", they just are (in any implementation you're likely to be using, anyway).
Is your Python implementation interpreted, or JIT-compiled?
Is your Java implementation interpreted, or JIT-compiled?
Is your C# implementation interpreted, or JIT-compiled?
Of the three, at least two are almost certainly JITted. Can you guess which two?
Um, given the subject of the article, I'm pretty confident construction has begun, and so I'm going to apply basic logic here and say that 2017/2018 are reactor start-up dates.
I've never bought a gun that didn't come with one. I wonder if that's something to do with the state I live in (UT)?