Poll extension...
-
Benefits of working in the kernel, it hasnt really changed in decades, seriously.
Very lucky indeed. Always wanted a chance to work in this area. But, very rare opportunities. In the other hand, I wonder if you ever get bored of doing the same kind of job again and again. I do...
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
-
Very lucky indeed. Always wanted a chance to work in this area. But, very rare opportunities. In the other hand, I wonder if you ever get bored of doing the same kind of job again and again. I do...
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
Linux is in demand, Windows less so, but when a firm does need that skill it is hard to find someone to do it, so it pays well. However, bored? Never, each problem is so distinct that it is never dull. For me the work is the project, not the environment, and they are ever changing and sometimes very complex.
-
Kornfeld Eliyahu Peter wrote:
It seems only about 15% of us consider .NET Core as platform for development
Who is "us"? Tiobe index only places C# at 5% and Java is only 12%. However given the spike in the numbers this year I expect that there is a data collection problem (which happened years ago also.) TIOBE Index | TIOBE - The Software Quality Company[^]
Kornfeld Eliyahu Peter wrote:
2. Or does not consider .NET Core as a good choice for that
I expect some of that it true. However, in my experience, people rationalize (not objectively) technology choices based either on what has succeeded for themselves individually in the past or failed for themselves. So, for example, that is why many people jumped on the NoSQL bandwagon because they do not know how to use a relational database correctly.
jschell wrote:
Tiobe index only places C# at 5% and Java is only 12%. However given the spike in the numbers this year I expect that there is a data collection problem (which happened years ago also.) TIOBE Index | TIOBE - The Software Quality Company[^]
I find it amusing that Visual Basic is #14. For a language that so many dismiss, it's been dead for 15 years and yet it's still in the top 20. In 1981 I had a professor tell the class that COBOL was a dead language and no one should waste time learning it. I have a friend who has come out of retirement 3 times for COBOL projects. :laugh:
-
Linux is in demand, Windows less so, but when a firm does need that skill it is hard to find someone to do it, so it pays well. However, bored? Never, each problem is so distinct that it is never dull. For me the work is the project, not the environment, and they are ever changing and sometimes very complex.
Munchies_Matt wrote:
it is hard to find someone to do it
If only finding someone "willing" to do it was enough. It's hard to develop experience on this. To me it feels like the chicken/egg problem at this stage in my career.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
-
Munchies_Matt wrote:
it is hard to find someone to do it
If only finding someone "willing" to do it was enough. It's hard to develop experience on this. To me it feels like the chicken/egg problem at this stage in my career.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
It is a bit like that. Problem is most hardware for windows is US designed, so the drivers are written there, though more and more are being done in places like India (usually badly in my experience) and Taiwan. MSFT has tried to make it easier with the WDF model, which is a lot easier to use, much of the hard work is done for you, but unless you go into the WDM foundation of the kernel you wont understand just how complex it is. And it is mind bendingly complex. I got a lucky break, a UK defence firm wanted a driver for one of their ISA bus network cards for NT4, so I dug into the DDK and taught myself how to do it. It was a tough learning curve, but NDIS is a simple model, so it was a good start really. I did a serial driver for the same firm later on, it had an unusual protocol, so the off the shelf one wouldnt work. After that it took about 5 years of writing windows drivers before I really became competent. It takes that long. Now, 20 years later, I know it pretty much inside out, though you can always be surprised by the subtlety of the API, and the MSFT documentation is not always that good. And with that I have done some pretty weird and wonderful drivers, like one to control CPU speed, so an app can run flat out, but at low CPU speed, for processing at night. Or the current one I am working on, bridging USB, so it takes USB traffic in and sends it out to some FW that then mimics that device to another PC at the far end. Very very fiddly, because all the USB config data has to be passed on, as well as a route back from the far end whcih actually does the configuration, and the class and vendor requests. And it has to support up to 8 devices... It is a seriously complex architecture, I really hope I dont have to maintain in in 5 years, I will have no idea how it works! :)
-
It is a bit like that. Problem is most hardware for windows is US designed, so the drivers are written there, though more and more are being done in places like India (usually badly in my experience) and Taiwan. MSFT has tried to make it easier with the WDF model, which is a lot easier to use, much of the hard work is done for you, but unless you go into the WDM foundation of the kernel you wont understand just how complex it is. And it is mind bendingly complex. I got a lucky break, a UK defence firm wanted a driver for one of their ISA bus network cards for NT4, so I dug into the DDK and taught myself how to do it. It was a tough learning curve, but NDIS is a simple model, so it was a good start really. I did a serial driver for the same firm later on, it had an unusual protocol, so the off the shelf one wouldnt work. After that it took about 5 years of writing windows drivers before I really became competent. It takes that long. Now, 20 years later, I know it pretty much inside out, though you can always be surprised by the subtlety of the API, and the MSFT documentation is not always that good. And with that I have done some pretty weird and wonderful drivers, like one to control CPU speed, so an app can run flat out, but at low CPU speed, for processing at night. Or the current one I am working on, bridging USB, so it takes USB traffic in and sends it out to some FW that then mimics that device to another PC at the far end. Very very fiddly, because all the USB config data has to be passed on, as well as a route back from the far end whcih actually does the configuration, and the class and vendor requests. And it has to support up to 8 devices... It is a seriously complex architecture, I really hope I dont have to maintain in in 5 years, I will have no idea how it works! :)
Thanks for the insight. I once started experimenting kernel mode driver development. I wanted make this Zebra printer receive commands via USB (it only received via serial port). Since I didn't have much time I ended up giving it up while I was digging and learning how complex it was.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
-
IMHO: - It's expensive, not all companies can afford Microsoft (small companies would rather go for open source platforms) - It's dependent on Microsoft support team for any deep internal bugs (can result in bad planning at the very least, doesn't always work for big companies with super strict deadlines) - It's somehow limited, meaning that you cannot always do the thing you want to do because it's been decided for you (our domain is about learning, adapting, innovating, and frameworks that do not allow this are generally frown upon) - Mobile is out
.NET Core 'is' the OS version of .NET. Welcome to 2017.
-
Thanks for the insight. I once started experimenting kernel mode driver development. I wanted make this Zebra printer receive commands via USB (it only received via serial port). Since I didn't have much time I ended up giving it up while I was digging and learning how complex it was.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
I have known a few people have a try for a few months, then give up. It really takes years and years to get an idea of how it works.
-
It seems only about 15% of us consider .NET Core as platform for development, the question is why? 1. Either no interest in multiplatform 2. Or does not consider .NET Core as a good choice for that Any opinions?
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
I started to build a new version of our sample web API in .NET Core, but stopped when I discovered that Entity Framework Core does not yet support stored procedures or views in any manner. I couldn't even force feed it by hand.
-
IMHO: - It's expensive, not all companies can afford Microsoft (small companies would rather go for open source platforms) - It's dependent on Microsoft support team for any deep internal bugs (can result in bad planning at the very least, doesn't always work for big companies with super strict deadlines) - It's somehow limited, meaning that you cannot always do the thing you want to do because it's been decided for you (our domain is about learning, adapting, innovating, and frameworks that do not allow this are generally frown upon) - Mobile is out
I'll let myself out... Delete post Delete account Delete browser Delete keyboard Remove the plug ... Wake up in a futuristic world No but seriously, I never read a word, sorry about that, I was thinking about .NET framework in general. I'll have a read at the core. Now is it comedy gold? well to each his own.
-
jschell wrote:
So, for example, that is why many people jumped on the NoSQL bandwagon because they do not know how to use a relational database correctly.
So, while I largely agree with your point about how individual performance with tech may vary, I think you're falling victim to the same hypothesis in regards to NoSQL. The fact is that if you don't understand relations, and by extension a relational database, you cannot succeed with a document store.
"There are three kinds of lies: lies, damned lies and statistics." - Benjamin Disraeli
Nathan Minier wrote:
The fact is that if you don't understand relations, and by extension a relational database, you cannot succeed with a document store.
I doubt that in general. First many smaller (data) apps can get by just fine with a less than optimal relational database. And the same applies to a NoSQL database. However when one runs into an unusual problem with the relational database, then one is likely to attempt to solve it in the database, and without the skill, that is problematic. NoSQL, for most, means the solution must be external to the database so it seems 'better' to those without the SQL skill. Note as well that at least anecdotally I have the experience to back this up as I know individuals who do not like relationals because of the skill level required (they specifically say that) so they choose NoSQL. Other than that I can also hypothesize that object models map directly to NoSQL whereas one must consider more carefully how to do such a mapping with relationals. With skill the relational mapping is easy but without out it, a failure to map can lead to problems that would not necessarily show up with NoSQL. And because those without the skill might have encountered the various problems, due to lack of skill, and problems that cannot exist with NoSQL they think it is better. Doesn't mean that the incorrect implementation that lead to the problem in the first place was not needed to solve some other problem, but they neglect to properly take into account the need to solve the original problem.
-
jschell wrote:
Tiobe index only places C# at 5% and Java is only 12%. However given the spike in the numbers this year I expect that there is a data collection problem (which happened years ago also.) TIOBE Index | TIOBE - The Software Quality Company[^]
I find it amusing that Visual Basic is #14. For a language that so many dismiss, it's been dead for 15 years and yet it's still in the top 20. In 1981 I had a professor tell the class that COBOL was a dead language and no one should waste time learning it. I have a friend who has come out of retirement 3 times for COBOL projects. :laugh:
-
Nathan Minier wrote:
The fact is that if you don't understand relations, and by extension a relational database, you cannot succeed with a document store.
I doubt that in general. First many smaller (data) apps can get by just fine with a less than optimal relational database. And the same applies to a NoSQL database. However when one runs into an unusual problem with the relational database, then one is likely to attempt to solve it in the database, and without the skill, that is problematic. NoSQL, for most, means the solution must be external to the database so it seems 'better' to those without the SQL skill. Note as well that at least anecdotally I have the experience to back this up as I know individuals who do not like relationals because of the skill level required (they specifically say that) so they choose NoSQL. Other than that I can also hypothesize that object models map directly to NoSQL whereas one must consider more carefully how to do such a mapping with relationals. With skill the relational mapping is easy but without out it, a failure to map can lead to problems that would not necessarily show up with NoSQL. And because those without the skill might have encountered the various problems, due to lack of skill, and problems that cannot exist with NoSQL they think it is better. Doesn't mean that the incorrect implementation that lead to the problem in the first place was not needed to solve some other problem, but they neglect to properly take into account the need to solve the original problem.
I'm sorry, that's simply not factual. Entity relationships are still a very real concern in an object store because they can lead to serious concurrency issues if not handled properly. Data structure design is just as important, and not even handled all that differently. It just doesn't have a safety net that SQL does; it will not immediately fail when a relationship mapping is not performed correctly. As the most basic example would include an object property that references a specific entity. Unless you map that relationship properly you will end up with a copy of that entity stored in the data model, in the state that it was in when serialized, rather than a reference to an entity in another collection, which is what you want as that will be the master source for state on that entity. Yes, it will appear to work, but you have a giant bug that might not be detectable until the system encounters a concurrency error between the real state of the object and the state tracked by the copy attached to the entity that you're working with. If you don't understand the data relations, you will never find the bug in this system. That's what I meant in the section of text you quoted. Appearance of functionality is not success; actual functionality is success.
"There are three kinds of lies: lies, damned lies and statistics." - Benjamin Disraeli
-
I saw a new job posting in the last couple of weeks where they were looking for a RPG programmer. No other language skills were listed.
I've seen ads for Clipper. Lot of old code out there which is low enough in priority to not get replaced. I know someone who has software in production that runs on a 286. It doesn't run on newer technology (not that anyone thinks of a 386 as "new") so they have kept the same 286 in production since 1992. still works fine ... although when the hardware dies (when, not an if) things should get interesting.
-
I'm sorry, that's simply not factual. Entity relationships are still a very real concern in an object store because they can lead to serious concurrency issues if not handled properly. Data structure design is just as important, and not even handled all that differently. It just doesn't have a safety net that SQL does; it will not immediately fail when a relationship mapping is not performed correctly. As the most basic example would include an object property that references a specific entity. Unless you map that relationship properly you will end up with a copy of that entity stored in the data model, in the state that it was in when serialized, rather than a reference to an entity in another collection, which is what you want as that will be the master source for state on that entity. Yes, it will appear to work, but you have a giant bug that might not be detectable until the system encounters a concurrency error between the real state of the object and the state tracked by the copy attached to the entity that you're working with. If you don't understand the data relations, you will never find the bug in this system. That's what I meant in the section of text you quoted. Appearance of functionality is not success; actual functionality is success.
"There are three kinds of lies: lies, damned lies and statistics." - Benjamin Disraeli
Nathan Minier wrote:
Entity relationships are still a very real concern in an object store because they can lead to serious concurrency issues if not handled properly.
Yes. They can. But not that they will. Which is what I was trying to convey. Smaller domains are less likely to experience those sorts of problems. And that is relevant when the implementer doesn't have enough skills to understand why it is important from the beginning. But in the same way, for some domains, it might never be important.
Nathan Minier wrote:
Appearance of functionality is not success; actual functionality is success.
Again I can only repeat that I know people that are choosing NoSQL because they had problems with SQL. Not because the business solution required NoSQL. And from what I have been able to see of the business, in general, SQL would have been a better choice.
-
I probably should have written it clearer - Java is more mature than .NET Core. I don't think that can be disputed? Performance wise, every ASP.NET application I've seen takes a long time (> 20s) to return a response when cold. On Java applications, the response is instant. Up until lately, .NET has had the drawback of only running on Windows Servers which (probably thanks to the heavy desktop components, general Windows baggage and IIS) runs slower on the same hardware before we've even started talking about making requests. .NET Core running on Kestrel on Linux should (theoretically) be an improvement on all that but the jury's still out as it's a new, immature and generally untested technology. I'm a dyed-in-the-wool C#/.NET developer but as far as developing cross-platform web applications Java has been the go-to technology. Until .NET Core can prove itself (and that's going to take years), Java will remain at the top.
jschell wrote:
In terms of "performance" all that matters is that which impacts the business
True enough, but a lot of businesses are moving to the cloud (Azure or AWS) where every CPU tick, every scrap of RAM or storage costs money.. performance is going to be a big factor for more and more companies over the next few years (and it already is for many).
Now is it bad enough that you let somebody else kick your butts without you trying to do it to each other? Now if we're all talking about the same man, and I think we are... it appears he's got a rather growing collection of our bikes.
Brent Jenkins wrote:
I probably should have written it clearer - Java is more mature than .NET Core. I don't think that can be disputed?
Yes and no in terms of the rest of your response. First one must differentiate between the languages of Java and C# and the eco system in which those languages might be used, such as IIS and tomcat. In terms of that I think that Java has an edge. However I wouldn't use what I think of as an edge to make my sole stack determination.
Brent Jenkins wrote:
Performance wise, every ASP.NET application I've seen takes a long time (> 20s) to return a response when cold
I did credit gateway card processing on C#. It was necessary to performance test the server and what I found that the server had zero impact compared the actual measured time that the card processors themselves had on the system. So at least in that business any delay was no more than noise to something over which I had no control anyways. Same would have been true with Java.
Brent Jenkins wrote:
every scrap of RAM or storage costs money.. performance is going to be a big factor for more and more companies over the next few years (and it already is for many).
So far everything I have seen or read suggests that it often, now, comes down to one specific metric which can often be surprising. Even more so now that cloud services are attempting to divide up the entire processing stack so they can charge for each individual piece. I recall reading a story about one business that went from tens of dollars a month to thousands because AWS (I believe) fixed a bug on the AWS side which meant they could now accurately track some metric that they had added billing for.
