111–120 of 136 posts
Earlier quoted context omitted.
Apple releases code under free licenses because they are required to and do exactly that minimum required.
That's not entirely true. launchd was released under a free license, and it was one of the most interesting innovations in software in a long while, for example.
Earlier quoted context omitted.
> .NET has never had "DLL Hell" I take it you've never worked on a .Net solution with projects targeting both full framework and Core framework. Core v1.x stuff was a nightmare - haven't had so many issues with versioning in 20 years. Core v2.0 was still pretty bad but each v2 point release made decent strides - and specific packages would get updated out of band at times to fix issues. But to say .Net has never had…
DLL Hell had nothing to do with project development. It was a problem of application deployment and running applications with DLLs in shared locations. https://en.wikipedia.org/wiki/DLL_Hell The problem arises when the version of the DLL on the computer is different than the version that was used when the program was being created. Other than the GAC, which was never recommended for use anyway, .NET has never had DLL…
If .NET/C# could output native binaries for Windows Desktop apps, I could seriously think about switching to C# over C++. How do people deal with securing their source code otherwise? Quite trivial to get the source from a decompiled C# exe file.
UWP makes use of AOT compiled .NET via .NET Native.
How do people secure they C++ code otherwise, it is quite trivial to use IDA or HexRays.
Earlier quoted context omitted.
It's quite trivial to get the source from a C# exe file in the same way as a decompiler makes it trivial to get the source from a C++ exe file. Obfuscators are common if you're concerned about the symbols leaking. If you don't include the .PDB debugging symbol files it's much the same as native binary code. The .NET virtual machine code is a little more expressive but is superficially similar to x86 native code. In m…
A C# binary can be decompiled back to easy to read source code. Show me how this can be done with a compiled C++ binary. It is a valid concern.
Earlier quoted context omitted.
> I had to ditch ReSharper to get to 2019 because together with the performance of the IDE itself, it just wasn't usable. R# ate gigs of Ram and Roslyn does the same. It's not surprising since they basically do the same thing, in managed code! But I can't pay the CPU time and memory to analyze my code TWICE on every edit. I'm holding off on 2019 as much as I can. Between 'forcing' an upgrade for .NET Core 3.0 and the…
Is Rider 64-bit?
Earlier quoted context omitted.
> the overall size of your code has increased a lot over time, causing performance issues due to issues that have existed for a long time, but weren't being felt yet. Not really. A simple empty project displays the same problems. You can try going back to 2017 right now with any project you're working on, you'll feel the difference instantly. Intellisense simply takes longer to respond, and likewqise other editor fun…
Interesting. I've observed the opposite, with VS 2017 often being unbearably slow in comparison as the codebase gets large. But I can appreciate that you may be experiencing the opposite. I highly recommend filing issues, especially if you can do so with a specific, reproducible problems. Those tend to get resolved quite quickly.
The issues are getting resolved in the public bug trucker, pretty quickly indeed, typically saying "can't reproduce, won't fix", sometimes "not a bug, won't fix".
I'm not sure the software problems are getting resolved.
Earlier quoted context omitted.
I had to ditch ReSharper to get to 2019 because together with the performance of the IDE itself, it just wasn't usable. R# ate gigs of Ram and Roslyn does the same. It's not surprising since they basically do the same thing, in managed code! But I can't pay the CPU time and memory to analyze my code TWICE on every edit. I also suspect things like switching build configuration offers thousands of opportunities to have…
I highly suggest giving Rider (also by JetBrains) a try. They run most things in separate processes/threads instead of running everything in the UI thread like VS does. It's almost a drop-in replacement.
Earlier quoted context omitted.
There is reason AST is called abstract syntax tree not just syntax tree. Many syntax details like parentheses or choice between alternative syntax forms are there only to avoid syntactic ambiguity, improve readability or historical reasons and don't affect the semantics or even error messages. It's not surprising for compiler authors to choose discarding some of the unnecessary information as early as possible to sav…
It's called abstract syntax tree because the concrete syntax is not a tree, it's an list of characters. Not because it makes semantic -invariant transformations.
It's called abstract syntax tree to distinguish it from parse trees (a.k.a. concrete syntax trees).
wile they spent time rewriting the same shit
people came with swift, go and rust
c#, just like java, both old people who refuse to get rid of their JIT bullshit, RIP to both of them
I still can't believe more people aren't leveraging the Roslyn APIs to write compiler extensions or additional tools around C#. It's conceptually powerful.
We've written a custom compiler from C# to Java and JavaScript based on Roslyn. Over time it gained more features and target languages as well (Python is in progress, we can also emit a working GWT wrapper for the JavaScript output, we can emit TypeScript typings or just normal TypeScript as well, etc.). For us this helps us in offering our products on various different platforms without having to write the code in d…