I'm using PyCharm on a whim for Django development and I am legitimately perplexed at how accurate the code completion is in this thing, even with HTML templates
What's the thought on cmake these days? Seems pretty powerful and straightforward. But every time I download something I need to compile for Ubuntu instead of using cmake, I have to download some godamn build engine written in Python or Ruby to build it. And of course...then I have to build the build engine..
Well I am not an impartial source, as I am paid to work on CMake.
But I consider it to be the C++ meta-build system you compare everything else against. Generally CMake design has been one where any desired use-case is allowed, this means it can support many different projects but it does cause the problem that CMake has at-least 2 ways to solve any problem.
+1
admanbunionize your workplaceSeattle, WARegistered Userregular
I'm using PyCharm on a whim for Django development and I am legitimately perplexed at how accurate the code completion is in this thing, even with HTML templates
What's the thought on cmake these days? Seems pretty powerful and straightforward. But every time I download something I need to compile for Ubuntu instead of using cmake, I have to download some godamn build engine written in Python or Ruby to build it. And of course...then I have to build the build engine..
Well I am not an impartial source, as I am paid to work on CMake.
But I consider it to be the C++ meta-build system you compare everything else against. Generally CMake design has been one where any desired use-case is allowed, this means it can support many different projects but it does cause the problem that CMake has at-least 2 ways to solve any problem.
I still try and use it where I can.
At the start of my current contract, I managed to slip it in, and it made cross platform development so easy.
Previously, they used to have separate Windows solution/project files, and hand rolled Makefiles for each target Linux platform.
This made simple things like adding a file or a define to be very difficult, which, to be blunt, was a silly and stupid situation to be in.
I swapped it to cmake, and had to beat some heads in, but otherwise a smooth transition. So easy to do cross platform development now.
Don't get me wrong. CMake is my tool of choice when it comes to building any project, even if they don't want cross platform development.
Building a collection of executables, shared, and static libraries and than installing them is still a 'hard' problem on all platforms, and having to only think of the problem inside of the CMake view of the world reduces the complexity for me.
The fact that you don't have to convert anything to "strict" TypeScript if you don't want to is helpful, too. All your vanilla JavaScript is already good to go. Everything is already the "any" type, and you can get more specific whenever there's a need.
I actually kind of wish this wasn't the case. I am a fan of both dynamic and static typing, but I find that when they're mixed it's almost always a "worst of both worlds situation". I'd rather they force your whole project to be TypeScript just so that there aren't any secretly still dynamic bits hidden inside of other TypeScript projects I use as a dependency or work on.
I feel the same way about the dynamic keyword in C#. Part of me is very happy it exists and the rest of me hopes I never actually see it.
There's a compiler option for that: "noImplicitAny". You can have "any" types, but you have to explicitly say it is of type "any", like using the "dynamic" type in C#. Harder to get going on existing projects, but a good option to enable on new ones for sure.
+1
mightyjongyoSour CrrmEast Bay, CaliforniaRegistered Userregular
CMake is absolutely fantastic for compiled languages. It's my go-to for C++ because it's so much easier to think in terms of cmake.
I think it has significantly less benefit for say Python projects.
Well unless you python project needs to build a collection of fortran and c libraries :biggrin:
why not just skip the middleman and punch yourself right in the gut
there's a python library for that
There's a Ruby library, too. But it doesn't work with your version of Ruby. Sorry.
3DS: 4098-4243-6127
0
jaziekBad at everythingAnd mad about it.Registered Userregular
edited April 2017
I've had almost a straight week of nothing but refactoring and writing some tests for code I wrote about a year and a half ago.
Man it is crazy how much better you can get at this stuff in a year.
I managed to get the load time for this app down from a little over 2 minutes to just under 10 seconds. It's incredibly satisfying.
Also its nice to be able to play around with newer c# features. Replacing String.Format and StringBuilder with $"whatever{var}whatever", and all the if(x != null){ z = x.y} with z= x?.y may not really improve performance at all, but it just looks so much cleaner. Making event invocation just event?.Invoke(this,args); is especially nice.
GnomeTankWhat the what?Portland, OregonRegistered Userregular
edited April 2017
I like CMake, a lot, but I also hate CMake for what it says about the C++ development ecosystem: It's a fucking mess. A god damn mess. C++ has so much to learn from what modern languages are doing with package and dependency management. For all the shit we give things like NPM, Gem and NuGet they have been a quantum leap forward in managing third party dependencies.
I like CMake, a lot, but I also hate CMake for what it says about the C++ development ecosystem: It's a fucking mess. A god damn mess. C++ has so much to learn from what modern languages are doing with package and dependency management. For all the shit we give things like NPM, Gem and NuGet they have been a quantum leap forward in managing third party dependencies.
Cool, I wasn't sure if something better had come along or what. (for C)
I've had almost a straight week of nothing but refactoring and writing some tests for code I wrote about a year and a half ago.
Man it is crazy how much better you can get at this stuff in a year.
I managed to get the load time for this app down from a little over 2 minutes to just under 10 seconds. It's incredibly satisfying.
Also its nice to be able to play around with newer c# features. Replacing String.Format and StringBuilder with $"whatever{var}whatever", and all the if(x != null){ z = x.y} with z= x?.y may not really improve performance at all, but it just looks so much cleaner. Making event invocation just event?.Invoke(this,args); is especially nice.
I had a play around with the TPL framework while picking up C# the last little while. I'm hoping and praying I don't have to mess around with any older parallel stuff, because the newer way of doing things is just infinitely easier.
I've had almost a straight week of nothing but refactoring and writing some tests for code I wrote about a year and a half ago.
Man it is crazy how much better you can get at this stuff in a year.
I managed to get the load time for this app down from a little over 2 minutes to just under 10 seconds. It's incredibly satisfying.
Also its nice to be able to play around with newer c# features. Replacing String.Format and StringBuilder with $"whatever{var}whatever", and all the if(x != null){ z = x.y} with z= x?.y may not really improve performance at all, but it just looks so much cleaner. Making event invocation just event?.Invoke(this,args); is especially nice.
I had a play around with the TPL framework while picking up C# the last little while. I'm hoping and praying I don't have to mess around with any older parallel stuff, because the newer way of doing things is just infinitely easier.
Yeah, I've done a lot of work with CF 3.5 and it's a complete pain in the ass. Partially because it's running on CE, which sucks, but more because it's old. I think.
3DS: 4098-4243-6127
0
GnomeTankWhat the what?Portland, OregonRegistered Userregular
I've had almost a straight week of nothing but refactoring and writing some tests for code I wrote about a year and a half ago.
Man it is crazy how much better you can get at this stuff in a year.
I managed to get the load time for this app down from a little over 2 minutes to just under 10 seconds. It's incredibly satisfying.
Also its nice to be able to play around with newer c# features. Replacing String.Format and StringBuilder with $"whatever{var}whatever", and all the if(x != null){ z = x.y} with z= x?.y may not really improve performance at all, but it just looks so much cleaner. Making event invocation just event?.Invoke(this,args); is especially nice.
I had a play around with the TPL framework while picking up C# the last little while. I'm hoping and praying I don't have to mess around with any older parallel stuff, because the newer way of doing things is just infinitely easier.
The TPL is great, but I an old bird get off my lawn type when it comes to the async/await keywords. I know how they work, and I know they are syntactic sugar over the top of the TPL...but the number of people who don't, and have no clue what the actual order of execution looks like when using them, just causes them to be confusing for a lot of people. The pure TPL may not be as sexy with it's lack of syntactic sugar, but people know what the hell my code is trying to do at a glance.
I remember when I suggested, probably 8+ years ago in here, that C++ needed to get with the times in re: its build environment and several people got a little upset that I'd even suggest it
and maybe I should use a language not C++ because that's not what it's there for
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
I remember when I suggested, probably 8+ years ago in here, that C++ needed to get with the times in re: its build environment and several people got a little upset that I'd even suggest it
and maybe I should use a language not C++ because that's not what it's there for
Well it's still kinda true.
Definitely don't use it unless you need it, warts and all. If you don't need to contend with its bullshit, I'm inclined to think you may have better options these days!
I remember when I suggested, probably 8+ years ago in here, that C++ needed to get with the times in re: its build environment and several people got a little upset that I'd even suggest it
and maybe I should use a language not C++ because that's not what it's there for
Well it's still kinda true.
Definitely don't use it unless you need it, warts and all. If you don't need to contend with its bullshit, I'm inclined to think you may have better options these days!
still!
it's one of the few things that likely needs to be brought into the 21st century
it worked fine for projects with like 3-4 dozen files, I suppose, but it's the largest wart of them all
C# works for me though
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
0
GnomeTankWhat the what?Portland, OregonRegistered Userregular
I remember when I suggested, probably 8+ years ago in here, that C++ needed to get with the times in re: its build environment and several people got a little upset that I'd even suggest it
and maybe I should use a language not C++ because that's not what it's there for
Well it's still kinda true.
Definitely don't use it unless you need it, warts and all. If you don't need to contend with its bullshit, I'm inclined to think you may have better options these days!
This isn't personal against you, but: I think this is a terrible attitude. C++ still has a ton to offer as an object oriented language that can interface with literally anything C-based in the world, and run at incredible speeds. I think it would be used for a lot MORE things if the warts around the eco system were sanded away. We're putting more and more complex software on more and more resource constrained devices and something like C++ could shine in that arena if the ecosystem to get it bootstrapped, and the dependency management around it, weren't a nightmare hellscape.
Disclaimer: C++ was my first "big boy I'm a professional now" language, so I do have a bias towards it.
I've had almost a straight week of nothing but refactoring and writing some tests for code I wrote about a year and a half ago.
Man it is crazy how much better you can get at this stuff in a year.
I managed to get the load time for this app down from a little over 2 minutes to just under 10 seconds. It's incredibly satisfying.
Also its nice to be able to play around with newer c# features. Replacing String.Format and StringBuilder with $"whatever{var}whatever", and all the if(x != null){ z = x.y} with z= x?.y may not really improve performance at all, but it just looks so much cleaner. Making event invocation just event?.Invoke(this,args); is especially nice.
I had a play around with the TPL framework while picking up C# the last little while. I'm hoping and praying I don't have to mess around with any older parallel stuff, because the newer way of doing things is just infinitely easier.
The TPL is great, but I an old bird get off my lawn type when it comes to the async/await keywords. I know how they work, and I know they are syntactic sugar over the top of the TPL...but the number of people who don't, and have no clue what the actual order of execution looks like when using them, just causes them to be confusing for a lot of people. The pure TPL may not be as sexy with it's lack of syntactic sugar, but people know what the hell my code is trying to do at a glance.
Yeah, that's a good shout. The book I have goes into detail on the proper nitty gritty of TPL, so I'll make sure I understand the underlying code too.
I remember when I suggested, probably 8+ years ago in here, that C++ needed to get with the times in re: its build environment and several people got a little upset that I'd even suggest it
and maybe I should use a language not C++ because that's not what it's there for
Well it's still kinda true.
Definitely don't use it unless you need it, warts and all. If you don't need to contend with its bullshit, I'm inclined to think you may have better options these days!
This isn't personal against you, but: I think this is a terrible attitude. C++ still has a ton to offer as an object oriented language that can interface with literally anything C-based in the world, and run at incredible speeds. I think it would be used for a lot MORE things if the warts around the eco system were sanded away. We're putting more and more complex software on more and more resource constrained devices and something like C++ could shine in that arena if the ecosystem to get it bootstrapped, and the dependency management around it, weren't a nightmare hellscape.
Disclaimer: C++ was my first "big boy I'm a professional now" language, so I do have a bias towards it.
Most of my C++ was because it was for "serious game devs" and due to hardware and language advancements it really isn't as necessary as it used to seem. We are getting a wider and wider gulf between "more than enough power" and "smart device baby power" and I have better options than C++ for either nowadays, it feels.
As in, anything that I used to use C++ for I would move to C#, and if it can't handle a language of that level then I am probably looking at C, if I have a compiled language at all. I don't have much use for "tight code" that allows me the luxury of useful C++?
I used to be a big C++ pusher and I just don't see any of justifications that I used to have. If you describe a problem, it is much much much less likely that I will choose C++ for it, and I see similar among my peers.
I remember when I suggested, probably 8+ years ago in here, that C++ needed to get with the times in re: its build environment and several people got a little upset that I'd even suggest it
and maybe I should use a language not C++ because that's not what it's there for
Well it's still kinda true.
Definitely don't use it unless you need it, warts and all. If you don't need to contend with its bullshit, I'm inclined to think you may have better options these days!
This isn't personal against you, but: I think this is a terrible attitude. C++ still has a ton to offer as an object oriented language that can interface with literally anything C-based in the world, and run at incredible speeds. I think it would be used for a lot MORE things if the warts around the eco system were sanded away. We're putting more and more complex software on more and more resource constrained devices and something like C++ could shine in that arena if the ecosystem to get it bootstrapped, and the dependency management around it, weren't a nightmare hellscape.
Disclaimer: C++ was my first "big boy I'm a professional now" language, so I do have a bias towards it.
Most of my C++ was because it was for "serious game devs" and due to hardware and language advancements it really isn't as necessary as it used to seem. We are getting a wider and wider gulf between "more than enough power" and "smart device baby power" and I have better options than C++ for either nowadays, it feels.
As in, anything that I used to use C++ for I would move to C#, and if it can't handle a language of that level then I am probably looking at C, if I have a compiled language at all. I don't have much use for "tight code" that allows me the luxury of useful C++?
I used to be a big C++ pusher and I just don't see any of justifications that I used to have. If you describe a problem, it is much much much less likely that I will choose C++ for it, and I see similar among my peers.
Well, as a concrete example of something that C++ can't interface with... the Unity engine.
Edit: Also Android. I think a lot of it is less that hardware is more powerful these days so much as software is more complex these days (which is enabled by more powerful hardware). Way fewer programmers (proportionally) are writing stuff from scratch to run directly on an OS, and way more are working off existing platforms/frameworks, which coerce you into using whatever languages they support, which is increasingly not C++.
I remember when I suggested, probably 8+ years ago in here, that C++ needed to get with the times in re: its build environment and several people got a little upset that I'd even suggest it
and maybe I should use a language not C++ because that's not what it's there for
Well it's still kinda true.
Definitely don't use it unless you need it, warts and all. If you don't need to contend with its bullshit, I'm inclined to think you may have better options these days!
This isn't personal against you, but: I think this is a terrible attitude. C++ still has a ton to offer as an object oriented language that can interface with literally anything C-based in the world, and run at incredible speeds. I think it would be used for a lot MORE things if the warts around the eco system were sanded away. We're putting more and more complex software on more and more resource constrained devices and something like C++ could shine in that arena if the ecosystem to get it bootstrapped, and the dependency management around it, weren't a nightmare hellscape.
Disclaimer: C++ was my first "big boy I'm a professional now" language, so I do have a bias towards it.
Most of my C++ was because it was for "serious game devs" and due to hardware and language advancements it really isn't as necessary as it used to seem. We are getting a wider and wider gulf between "more than enough power" and "smart device baby power" and I have better options than C++ for either nowadays, it feels.
As in, anything that I used to use C++ for I would move to C#, and if it can't handle a language of that level then I am probably looking at C, if I have a compiled language at all. I don't have much use for "tight code" that allows me the luxury of useful C++?
I used to be a big C++ pusher and I just don't see any of justifications that I used to have. If you describe a problem, it is much much much less likely that I will choose C++ for it, and I see similar among my peers.
Well, as a concrete example of something that C++ can't interface with... the Unity engine.
Edit: Also Android. I think a lot of it is less that hardware is more powerful these days so much as software is more complex these days (which is enabled by more powerful hardware). Way fewer programmers (proportionally) are writing stuff from scratch to run directly on an OS, and way more are working off existing platforms/frameworks, which coerce you into using whatever languages they support, which is increasingly not C++.
Nah, Android and C++ are good. Working on some of that right now. I wouldn't call it excellent, but I'd call it better than CE.
on iOS there's still a pretty easy-to-make performance case for C and C++ in some situations. particularly string/char processing. objective-c just sucks at it. I'm guessing swift isn't much better
if i need to process strings in bulk and not make my users wait, i gotta bust out the C
even the newer apple hardware meets its limits quite quickly
0
OrcaAlso known as EspressosaurusWrexRegistered Userregular
As in, anything that I used to use C++ for I would move to C#, and if it can't handle a language of that level then I am probably looking at C, if I have a compiled language at all. I don't have much use for "tight code" that allows me the luxury of useful C++?
What would you use C for that you think C++ is not appropriate for?
As in, anything that I used to use C++ for I would move to C#, and if it can't handle a language of that level then I am probably looking at C, if I have a compiled language at all. I don't have much use for "tight code" that allows me the luxury of useful C++?
What would you use C for that you think C++ is not appropriate for?
Usually it's because of name mangling when you export libraries. C doesn't have it, and C++ you have to do extra stuff.
Unless you have a need to use C++ things like classes, it's sometimes easier to just have C do it. At the point where you need C for a performance reason all the benefits of things like new and delete are probably gone anyways.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
bring up how the PM wasted hundreds of thousands of dollars on the russian team for no benefit and they're still around, so why not a QA person that didn't do anything wrong?
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
It's almost dangerously easy to serialize a Go struct to JSON so I ended up thinking "eh, let's just make this struct into JSON" without really considering a structure tailored for the JSON output. Lesson learned for the future, make a struct just for the JSON format.
Make sure you get a good one. I'm working with a third party, client-required QA team now that bases their tests on what the devs tell them to test. Consequently, when I discovered that a search field behaved oddly when searching for a string with an apostrophe, I knew we had an sql injection vulnerability. That the QA people didn't find. Because we didn't tell them specifically to test fields for SQL injection.
I mean, you expect QA to bring a base level of testing skills and knowledge to the table, right? Otherwise, why bother?
Posts
i actually
do not know
how they know
Well I am not an impartial source, as I am paid to work on CMake.
But I consider it to be the C++ meta-build system you compare everything else against. Generally CMake design has been one where any desired use-case is allowed, this means it can support many different projects but it does cause the problem that CMake has at-least 2 ways to solve any problem.
they're in your head
zombie
zombie
I still try and use it where I can.
At the start of my current contract, I managed to slip it in, and it made cross platform development so easy.
Previously, they used to have separate Windows solution/project files, and hand rolled Makefiles for each target Linux platform.
This made simple things like adding a file or a define to be very difficult, which, to be blunt, was a silly and stupid situation to be in.
I swapped it to cmake, and had to beat some heads in, but otherwise a smooth transition. So easy to do cross platform development now.
Building a collection of executables, shared, and static libraries and than installing them is still a 'hard' problem on all platforms, and having to only think of the problem inside of the CMake view of the world reduces the complexity for me.
There's a compiler option for that: "noImplicitAny". You can have "any" types, but you have to explicitly say it is of type "any", like using the "dynamic" type in C#. Harder to get going on existing projects, but a good option to enable on new ones for sure.
I think it has significantly less benefit for say Python projects.
why not just skip the middleman and punch yourself right in the gut
there's a python library for that
I tried to use a JavaScript version of the library but npm punched me in the gut first because my path was too long.
Am I doing this right? =P
That's only if you use R instead of Numpy.
wait npm actually gave you useful information
Touche, sir!
There's a Ruby library, too. But it doesn't work with your version of Ruby. Sorry.
Man it is crazy how much better you can get at this stuff in a year.
I managed to get the load time for this app down from a little over 2 minutes to just under 10 seconds. It's incredibly satisfying.
Also its nice to be able to play around with newer c# features. Replacing String.Format and StringBuilder with $"whatever{var}whatever", and all the if(x != null){ z = x.y} with z= x?.y may not really improve performance at all, but it just looks so much cleaner. Making event invocation just event?.Invoke(this,args); is especially nice.
Cool, I wasn't sure if something better had come along or what. (for C)
I had a play around with the TPL framework while picking up C# the last little while. I'm hoping and praying I don't have to mess around with any older parallel stuff, because the newer way of doing things is just infinitely easier.
http://steamcommunity.com/id/pablocampy
Yeah, I've done a lot of work with CF 3.5 and it's a complete pain in the ass. Partially because it's running on CE, which sucks, but more because it's old. I think.
The TPL is great, but I an old bird get off my lawn type when it comes to the async/await keywords. I know how they work, and I know they are syntactic sugar over the top of the TPL...but the number of people who don't, and have no clue what the actual order of execution looks like when using them, just causes them to be confusing for a lot of people. The pure TPL may not be as sexy with it's lack of syntactic sugar, but people know what the hell my code is trying to do at a glance.
and maybe I should use a language not C++ because that's not what it's there for
Well it's still kinda true.
Definitely don't use it unless you need it, warts and all. If you don't need to contend with its bullshit, I'm inclined to think you may have better options these days!
still!
it's one of the few things that likely needs to be brought into the 21st century
it worked fine for projects with like 3-4 dozen files, I suppose, but it's the largest wart of them all
C# works for me though
This isn't personal against you, but: I think this is a terrible attitude. C++ still has a ton to offer as an object oriented language that can interface with literally anything C-based in the world, and run at incredible speeds. I think it would be used for a lot MORE things if the warts around the eco system were sanded away. We're putting more and more complex software on more and more resource constrained devices and something like C++ could shine in that arena if the ecosystem to get it bootstrapped, and the dependency management around it, weren't a nightmare hellscape.
Disclaimer: C++ was my first "big boy I'm a professional now" language, so I do have a bias towards it.
Yeah, that's a good shout. The book I have goes into detail on the proper nitty gritty of TPL, so I'll make sure I understand the underlying code too.
http://steamcommunity.com/id/pablocampy
Most of my C++ was because it was for "serious game devs" and due to hardware and language advancements it really isn't as necessary as it used to seem. We are getting a wider and wider gulf between "more than enough power" and "smart device baby power" and I have better options than C++ for either nowadays, it feels.
As in, anything that I used to use C++ for I would move to C#, and if it can't handle a language of that level then I am probably looking at C, if I have a compiled language at all. I don't have much use for "tight code" that allows me the luxury of useful C++?
I used to be a big C++ pusher and I just don't see any of justifications that I used to have. If you describe a problem, it is much much much less likely that I will choose C++ for it, and I see similar among my peers.
Well, as a concrete example of something that C++ can't interface with... the Unity engine.
Edit: Also Android. I think a lot of it is less that hardware is more powerful these days so much as software is more complex these days (which is enabled by more powerful hardware). Way fewer programmers (proportionally) are writing stuff from scratch to run directly on an OS, and way more are working off existing platforms/frameworks, which coerce you into using whatever languages they support, which is increasingly not C++.
Nah, Android and C++ are good. Working on some of that right now. I wouldn't call it excellent, but I'd call it better than CE.
if i need to process strings in bulk and not make my users wait, i gotta bust out the C
even the newer apple hardware meets its limits quite quickly
What would you use C for that you think C++ is not appropriate for?
Started function name with lowercase = not exported = doesn't run.
Usually it's because of name mangling when you export libraries. C doesn't have it, and C++ you have to do extra stuff.
Unless you have a need to use C++ things like classes, it's sometimes easier to just have C do it. At the point where you need C for a performance reason all the benefits of things like new and delete are probably gone anyways.
Turns out I had this button:
<Button block className="search-button" onClick={() => { }} >SEARCH</Button>I want a QA team.
bring up how the PM wasted hundreds of thousands of dollars on the russian team for no benefit and they're still around, so why not a QA person that didn't do anything wrong?
Awesome this is going to be a fun day.
edit; I put a console.log in a place and now it's working like it was intended. Are you fucking with me now javascript???
Make sure you get a good one. I'm working with a third party, client-required QA team now that bases their tests on what the devs tell them to test. Consequently, when I discovered that a search field behaved oddly when searching for a string with an apostrophe, I knew we had an sql injection vulnerability. That the QA people didn't find. Because we didn't tell them specifically to test fields for SQL injection.
I mean, you expect QA to bring a base level of testing skills and knowledge to the table, right? Otherwise, why bother?