Open Side Menu Go to the Top
Register
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** ** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **

04-20-2018 , 08:16 AM
What are the actual arguments for C? Is it just "has pointers" && "static typing"? Because I probably wouldn't vote for Java either, I'd vote for C++.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-20-2018 , 12:24 PM
I've programmed C++ off and on for 2 decades. It's a terrible language and frankly, it's gotten worse.

ETA: I have a few ebooks of "stuff you should never do in C++" and they are voluminous and full of surprises, stuff that seems like it would be fine, but isn't.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-20-2018 , 12:38 PM
I don't think I would teach C as a first language, but I think there's a lot of valuable knowledge that can be had by learning C at some point. Not so much in terms of programming language features (e.g. pointers or typing or whatever) but in terms of understanding how data structures are actually organized in memory, how memory management generally works, and from there why it is that some kinds of algorithms are much slower than others. It's mostly just that C is low level enough that you don't get abstracted away from those details.

I definitely agree that a lot of the time you don't have to know this to be good in a lot of programming jobs, but I still think it's valuable to know. Also interesting! C was my first language and I'm sure I'm biased, but I also think in my career I've gotten a lot of use out of having in depth knowledge in a lot of areas, from stuff like memory management to network protocols. I don't need that knowledge 95% of the time, but it is very helpful that 5%. Plus I just think that's the fun part.

As an example, I worked on a C# client that included a large reporting/analytics library. That code base was also run under Mono on a server for some scheduled reporting tasks, or for generating reporting output that took too long and needed to be queued and executed later. There was an issue with Mono crashing occasionally, which I tracked down to a versioning issue where the Mono runtime was relying on out-of-date kernel behavior related to the brk() system call, which for some godforsaken reason the library was calling directly instead of using malloc or calloc or whatever. Fortunately it could be fixed just by recompiling mono with an option to prefer MMAP for memory allocation. 95% of my work in that job was writing C# code that executed on Windows workstations, but I wouldn't have fixed that issue if I hadn't once spent a lot of time understanding linux memory management.

And of course when you get to fix something like that you look like a genius, which I feel like can't be that bad career-wise. YMMV
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-20-2018 , 12:46 PM
Quote:
Originally Posted by kerowo
You do you probably just call it a reference instead...
I guess? In that "hey you'll need to deep copy your js arrays and objects or bad things might happen". That's literally as far as I'll ever need to go down the manual memory control road and my life is much better for it.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-20-2018 , 01:03 PM
Haha my new job is in C++.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-20-2018 , 01:09 PM
Quote:
Originally Posted by RustyBrooks
I've programmed C++ off and on for 2 decades. It's a terrible language and frankly, it's gotten worse.

ETA: I have a few ebooks of "stuff you should never do in C++" and they are voluminous and full of surprises, stuff that seems like it would be fine, but isn't.
For production code C++ to me is much than C, not even close.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-20-2018 , 01:10 PM
Quote:
Originally Posted by Wolfram
The post you linked to has a lot erroneous conclusions.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-20-2018 , 01:12 PM
Quote:
Originally Posted by well named
I don't think I would teach C as a first language,
Agree totally with this.

Quote:
but I think there's a lot of valuable knowledge that can be had by learning C at some point. Not so much in terms of programming language features (e.g. pointers or typing or whatever) but in terms of understanding how data structures are actually organized in memory, how memory management generally works, and from there why it is that some kinds of algorithms are much slower than others. It's mostly just that C is low level enough that you don't get abstracted away from those details.

I definitely agree that a lot of the time you don't have to know this to be good in a lot of programming jobs, but I still think it's valuable to know. Also interesting! C was my first language and I'm sure I'm biased, but I also think in my career I've gotten a lot of use out of having in depth knowledge in a lot of areas, from stuff like memory management to network protocols. I don't need that knowledge 95% of the time, but it is very helpful that 5%. Plus I just think that's the fun part.

As an example, I worked on a C# client that included a large reporting/analytics library. That code base was also run under Mono on a server for some scheduled reporting tasks, or for generating reporting output that took too long and needed to be queued and executed later. There was an issue with Mono crashing occasionally, which I tracked down to a versioning issue where the Mono runtime was relying on out-of-date kernel behavior related to the brk() system call, which for some godforsaken reason the library was calling directly instead of using malloc or calloc or whatever. Fortunately it could be fixed just by recompiling mono with an option to prefer MMAP for memory allocation. 95% of my work in that job was writing C# code that executed on Windows workstations, but I wouldn't have fixed that issue if I hadn't once spent a lot of time understanding linux memory management.

And of course when you get to fix something like that you look like a genius, which I feel like can't be that bad career-wise. YMMV
Like you posted YMMV
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-20-2018 , 01:17 PM
Quote:
Originally Posted by adios
For production code C++ to me is much than C, not even close.
Much what than c++?

Anyway, C++ isn't really a competitor to C, it's a competitor to Java and C# and stuff like that.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-20-2018 , 01:25 PM
I guess my attitude in general is that I'll never be able to learn everything, so I do have to pick and choose, but I can see value in learning a lot of different things. That doesn't mean that every programmer should learn the exact set of things that I've learned, of course. But I'm always skeptical of claims that some subset of programming knowledge isn't valuable on the grounds that someone doesn't use it most of the time.

At the moment things I'd like to understand much better include some of the big data DB solutions like Google BigTable, or just NoSQL implementations in general, how to actually use neural networks and machine learning in practice, or how to figure out when to consider using them, and what is a good style of coding for ruby. :P
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-20-2018 , 01:38 PM
Quote:
Originally Posted by kerowo
You do you probably just call it a reference instead...
True and in C++ there is

The auto keyword where the compiler deduces the type I.E. not statically typed.
Using "smart" pointer mechanisms prevent inevitable "memory leaks" that happen when using dynamic memory allocation.

I am not beating the drum for C++ in lieu of using say something like Python, JS, C#, etc., far from it. FWIW grue's perspective is the right perspective.

However, C++ is much preferred to C in the problem domains it applies to. There are some very basic reasons why:
1 - Rogue pointer issues (trashed pointers, null pointers) are nasty and difficult to root out.

2 - Memory leaks caused by using dynamic allocation are also nasty problems to resolve.

3 - STL is much better in producing reliable and secure code than the standard C library.

4 - Encapsulation is easy in C++. Encapsulation in C is a joke.

5 - Polymorphism in design is relatively easy to in C++. In C, not so much.

6 - Templates which I guess you could say is part of encapsulation but there far more useful than that. Templates make C++ "Turing Complete" at compile time which brings about a lot of potential for weeding at defects at compile time as opposed to weeding them out at run time.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-20-2018 , 02:08 PM
Quote:
Originally Posted by RustyBrooks
I've programmed C++ off and on for 2 decades. It's a terrible language and frankly, it's gotten worse.

ETA: I have a few ebooks of "stuff you should never do in C++" and they are voluminous and full of surprises, stuff that seems like it would be fine, but isn't.
That's probably the problem. You were writing non-modern C++, i.e pre C++11.

Unless you're writing something hardware specific, there's no need to ever choose C over C++11.

Sent from my SAMSUNG-SM-G925A using Tapatalk
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-20-2018 , 02:30 PM
Also, the fact that you CAN write bad C++ doesn't make it a bad language to teach or in general. Especially in this context when we're comparing it against languages such as C which also have a TON of bad things about it (undefined behavior, suboptimal programming patterns, etc.).

I highlighted C++ because it provides a unique combination of the desire to expose low level concepts with powerful algorithm design features.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-20-2018 , 02:37 PM
Quote:
Originally Posted by :::grimReaper:::
That's probably the problem. You were writing non-modern C++, i.e pre C++11.
Obviously I was, but I haven't been for the last several years. Although there are surely features of modern C++ I don't use well or properly - although that's not limited to me. I have tracked down some doozies associated with std::move()

Quote:
Unless you're writing something hardware specific, there's no need to ever choose C over C++11.
And I don't. As I said above, they are not competitors in the professional space. But I'd still prefer to teach C over C++ to absolute beginners.


Quote:
Originally Posted by saw7988
Also, the fact that you CAN write bad C++ doesn't make it a bad language to teach or in general. Especially in this context when we're comparing it against languages such as C which also have a TON of bad things about it (undefined behavior, suboptimal programming patterns, etc.).
But that's not really what we're talking about here. C++ is full of things that look and seem fine/right, but that are bound to cause problems or bugs.

Also, I really don't think C has much undefined behavior, not nearly as much as C++. std::move() for example, has no defined behavior for what happens to the data in the variable, except, I think, that it has to represent valid data for the underlying type. That means if you make a mistake with it (such as accessing the data after performing the move) it may work fine on the compiler/platform you work on, and break somewhere else. C++ is absolutely riddled with this.

The reason it's riddled with it, more so than C, is that it also has tons of features and a very extensive language. This also makes it a lot more useful.

I don't program professionally in C and I wouldn't really want to. I don't think C is a superior language for professional work. But I'd rather explain it to newcomers than C++.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-20-2018 , 02:54 PM
Note: there are actually 2 std::moves, I'm talking about the "move-semantic" one, http://en.cppreference.com/w/cpp/utility/move
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-20-2018 , 03:12 PM
Quote:
Originally Posted by jjshabado
I think its important that people can understand something like this and figure out where the bug (assuming this isn't the desired functionality) is:

Code:
>>> def foo(n, l=[]):
...         l.append(n)
...         print l
>>> foo(1)
[1]
>>> foo(2)
[1, 2]
>>> foo(3,[])
[3]
>>> foo(4)
[1, 2, 4]
But I don't really care too much about deeper pointer / reference knowledge. Or like the "Is Java pass by reference or pass by value" arguments. If you know and understand how the code actually works, I don't care too much about your semantics.
That's a very Python-specific question - in C++ the defaulted argument would be newly-constructed each time you enter the function (assume it's a std::vector<> or something). I was surprised the Python snippet would behave like that.

Quote:
Originally Posted by RustyBrooks
I've programmed C++ off and on for 2 decades. It's a terrible language and frankly, it's gotten worse.
Oh man, I love C++11. Strongly disagree here.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-20-2018 , 03:47 PM
So one of my 4 onshore devs quit/gave his 2 weeks and today's his last day. Its my fault, but for the first time in a bit I took a look at the project repo on sourcetree. 0 commits from him since March. How pissed would you be? I'm like at a 8/10 especially since we have been on a unit test kick for the past few weeks and I have to do all of his components now. IDK seems completely unprofessional. Whatever at least I don't have to think for the next couple days.. thanks Jest.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-20-2018 , 05:10 PM
in this week's adventures in Java for my frequency counter assignment, I need to use lambdas.

probable rant incoming in 2 days
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-20-2018 , 05:32 PM
Quote:
Originally Posted by goofyballer
That's a very Python-specific question - in C++ the defaulted argument would be newly-constructed each time you enter the function (assume it's a std::vector<> or something). I was surprised the Python snippet would behave like that.
I'm not talking about the python part of that. I just mean that if you understand references you can figure out whats happening there fairly easily. If you don't understand references, you'll be super confused.

You can come up with equivalent situations in many different languages.

Edit: And yeah, when I hit a bug like this, it took me awhile to hunt it down because its not at all what I was expecting.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-20-2018 , 08:40 PM
I implemented Freq counter using only hashmaps and lambdas, the maps had strings that mapped to data or to functions and that was the only way you were allowed to call class methods or get/write data.

It’s probably the ugliest code I’ve ever written. Unsafe casts everywhere and practically unreadable.

Lambdas are cool though. The way java implements them is kind of awkward feeling but it’s a cool feature.

Python lambdas look much sexier. I’m worried I might fail because there’s no way the TA can read this.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-20-2018 , 10:39 PM
Quote:
Originally Posted by Grue
So one of my 4 onshore devs quit/gave his 2 weeks and today's his last day. Its my fault, but for the first time in a bit I took a look at the project repo on sourcetree. 0 commits from him since March. How pissed would you be? I'm like at a 8/10 especially since we have been on a unit test kick for the past few weeks and I have to do all of his components now. IDK seems completely unprofessional. Whatever at least I don't have to think for the next couple days.. thanks Jest.
Yea when people have decided to leave they sometimes just totally check out and I agree it is unprofessional.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-20-2018 , 11:15 PM
Quote:
Originally Posted by jmakin
Python lambdas look much sexier. I’m worried I might fail because there’s no way the TA can read this.
My main complaint about python lambdas is that they have to be a single "expression" and they're actually fairly limited.

So for example you can't do this
Code:
lambda x, y:
  x['foo'] = y
You can't have any multi-line lambdas and so forth. You end up doing contortions sometimes. On the plus side you can make embedded functions and they have access to the variables in the outside function. That has it's oddities too though.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-20-2018 , 11:37 PM
Oh, ok. Java lambdas are a little more expressive then, but you need to declare an interface for it which can only have one method inside them (i think, pretty sure, I was messing around with it).

At that point though i kept thinking "why not just make an inner class" but i get why they're occasionally powerful. Also is much faster than making an object, because I think passing a lambda as a parameter just injects the code straight into that reference. could be way off but the freq counter I wrote with them, which is usually pretty slow when i use maps, was lightning fast.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-21-2018 , 01:41 AM
Quote:
Originally Posted by RustyBrooks
And I don't. As I said above, they are not competitors in the professional space. But I'd still prefer to teach C over C++ to absolute beginners.
Agreed. C++11 is far too complex to throw at a beginner.


Quote:
Originally Posted by RustyBrooks
Also, I really don't think C has much undefined behavior, not nearly as much as C++. std::move() for example, has no defined behavior for what happens to the data in the variable, except, I think, that it has to represent valid data for the underlying type.
Can you elaborate?

std::move is cool, but let's not forget some of the stronger assets of C++11, e.g. std::unique_ptr, templates, that C lacks.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote

      
m