Yeah I think back to the first generic java SQL querying interface I wrote, vs ones in scripting languages like tcl or perl. Java wanted to know in advance the type of every column in every query. Scripting languages didn't care, until I wanted to treat a column as something specific.

Well, consider C++. Generally speaking, any templated collection will let you have foo<mytype> but if you want a collection that can hold "anything" you're left with foo<void *> and a lot of extra work - and, it has all the run time exception risks of an untyped language. Or, you can make a BaseType class, and make a foo<BaseType> or foo<BaseType *> and have IntType and StringType and FloatType and ButtType that all extend BaseType just so that you can have a statically typed foo container.

I haven't programmed for a living in Java since 1999 but I seem to recall that most of the built in types would take an "object" as a type (i.e. anything), but, if you wanted to actually execute a function on an object you had to do this dance of "if o is a string, then run o.whatever(), if o is a float, run o.somethingelse()" and so forth.

Have you tried https://golang.org/pkg/reflect/#DeepEqual

I think it works for both pointers and structs.

Well that's what you wanted though. It's like the unsafe keyword in Rust - they can't simultaneously let you skip all compile-time typechecks and guarantee runtime safety.

If you want to manually dispatch based on the type, you have to do the same thing in any language. If you're talking about the fact that you have to cast it to the right type before you can call methods that are available for that type, that will often reveal errors of the type you were talking about earlier, which is sort of the point.

This is a fantastic, well made point.

Right, I'm not saying they're doing it wrong, exactly, just that languages that don't have easy bucket-of-objects ability often lead you to something that is maybe even less safe than a more loosely typed language.

Yeah that's what I mean. They could all have a "draw" function but I have to make them into their real type before I can call "draw". C++ finally added "auto" in one of the recent updates to the spec, which is nice. This at least partly solves this problem (and ffs it keeps me from having to specify these pointless long iterator type names)

I'm not sure what the inflection point is, but I'd do the same thing if I was earning $100 / hour. The higher number is a massive opportunity to really make a go of something major and it seems foolish to me to not take advantage of that.

Recently, I was running 3 contracts all paying $50+ / hour. One ended, one is delayed over circumstance, and I changed my mind on another. The lower-paying work is part needed, part not needed.

For example, I was paid $200 for one day this past weekend. I met the person who advised me about being burned out along with some fascinating girl. The changes and the opportunity to explore and see new situations, companies, and people, is interesting to me, and sometimes I'm willing to take a hit in pay to experience and learn more.

Of course, locality helps a lot. Being LA has opened up many more opportunities to find new and interesting contracts, especially relating to programming, music, and other creative things I would never have thought of. LA is also very much a gig-based economy, more so than any other place I've been. I would like to work 7 days a week if I can, and I don't have to earn $400 every day.

It makes sense. I'm sorry you had a bad experience with various construction workers, but that's unfortunately the status quo. I don't have a lot of room to talk **** here, but that field is sort of the "out" for your average HS drop out, ex-con, and other types, though to be sure, there are quite a few people who are well-equipped to take on a Blue Chip job earning much more.

What I've found is that older people and non-union workers tend to give the best bang for the buck. A young lifer in the business generally won't work out. A union-person won't work because because they were trained do industrial construction and union workers are trained to not do anything but their little job (which means they won't pick up their own water bottle), plus they are trained to build, not fix or work around mistakes. I never heard of a residential union worker, but the skill-sets for each are very different. The tools, approaches, supplies, and thinking (or lack of) are worlds apart.

Regarding backgrounds, the person who taught me the most had a degree in mechanical engineering and used to work at JPL, but he just decided he'd rather do construction. It's not easy to find these types, but there are quite a few of them out there. They tend to work on higher end housing and charge what appears to be an arm and a leg, but like a good programmer or lawyer, they end up being much higher quality work and materials, yet end up costing about the same as average Joe Plumber at the end of the job.

There is a lot of defensiveness in some situations. I can be difficult to work in a situation where the home owner is staring you down all day because they think you are going to steal from them or break their toilet. Interior designers are the worst people on the planet.

One thing you quickly learn in contracting, no matter the field, is that you have to deal with people who inherently don't trust you. I get this a lot in programming (much more than I experienced in construction, actually), and that's okay since I'm often dealing with people who got harmed by a prior programmer or I'm number 15 in a line of failures. My only approach is saying very upfront what I can do, what I can't do, and showing them that I'm able to do part 1, and that generally diffuses the doubt.

I think that people find clear and straight-forward language refreshing; I don't think this is true in an interview setting. Also interviewing for a contract is talking about the problem at hand and solutions to the problem. This is much easier for me and aligns with my general attitude toward work.

To be fair, humans are fairly biased against high trust encounters. (For obvious evolutionary biology reasons.) So it isn't like this sort of behavior is common for everyone (obviously its gonna be common among upper-middle class/rich) and considering his underclass upbringing is likely incredibly foreign to him.

Regardless, its just another social norm he needs to understand and comply with. No one speaks like Lebron James in corporate America. And no one has a level of trust like they're living in the projects and criminality is rampant.

NB: Not that I disagree with what cb said in any way, just trying to explain why daveT is struggling with this.

so it seems to me that switchMap should almost always be used rather than mergeMap.

Speaking of high trust vs. low trust - good news everyone! The Chinese have a solution.

http://www.wired.co.uk/article/chine...ivacy-invasion

But you don't have to use it everywhere, you just use it for the things you need. I use this type of pattern often in statically typed languages but it's still so much safer because I'm not forced to use this pattern everywhere. And the mistakes like the ones you and LL were talking about are still caught, because there's no need for these things to be untyped. It's like the difference between a zoo and a jungle. Sure there are dangerous wild animals in both places, but one does a much better job of containing them and warning you where appropriate. That you could in theory do stupid things at a zoo and get eaten by a tiger doesn't mean it's just as unsafe and you might as well do without all the fences and so on.

6 years ago. Practically all modern statically typed languages have similar features - Go, Scala, C#, C++, F#, OCaml, Haskell, etc, etc - Java is the only exception I can think of. Meanwhile I'm still finding 4 year-old bugs in JS that wouldn't even compile in a statically typed language.

To me, 6 years ago is recent. And actually as someone who writes C++ for windows, osx and various linux flavors, it actually kinda is. OSX in particular has had ancient versions of gcc by default.

C++ is also a strange example to use when discussing static typing because it also differs from Pythons of the world on so many other dimensions. You want to compare Python against Go and Ruby against Scala and JavaScript against C# - languages that are at least vaguely similar aside from types.

I came across that in my searching yesterday and noticed one case where it fails in my test code (this is from memory but should be right I think):

Output is false, false, and while in practice this is probably an unlikely situation to come across, it seems like an unfortunate side effect of the fact that an interface can be both a pointer and a struct at different times, and will behave differently as a result, while appearing the same the whole time (i.e. the language strongly discourages the use of interface pointers) to the person writing code.

Does it bother anyone else that languages can't agree upon an abbreviation for "function"? There's function, func, fun, and fn. You could even throw Python's "def" in there, but even without that we're memorizing 4 different variations of the word function.

Tcl uses "proc"
Lisp uses "defun"

I've probably seen some others

People can't agree on anything in general - if they did, we wouldn't have all these different languages. I'm guessing you're not a fan of this project:

https://en.wikipedia.org/wiki/Endang...guages_Project

Haha yea I'm sure there's a ton of others... I shouldn't have brought up Python, because my random thought was really about the function abbreviations, not just "different syntax" in general. I play around with Rust and Kotlin in my spare time, but you see a lot of JavaScript everywhere (for obvious reasons) and now reading Go code just topped it off

Wow, first time using SQL Server ever. What a nightmare of a system.

I'm running this on a docker image. I'm simply trying to bulk load a txt, csv or xlsx file and make it work. By default, a newline is "\n" , but since there's who-knows-what, you have to use some 0x0a. Despite defining a delimiter as a TAB, it STILL truncates the data and blows up with a bunch of errors!

Oh, and what does it do when it "succeeds?" Nothing. Nothing at all. No messages, no new rows, no errors. I'm truly stuck and can't believe nothing is working.

Okay, seriously, anyone know how to load a flippin' txt, csv, or xlsx file onto SQL Server?

I've never done it in the SQLServer magic way, I just use scripts for it. I haven't worked with SQLServer since about 2008 so I don't think I even have anything around that I've used.

The scripting I use for database stuff these days is built around sqlalchemy, which supports MSSQL. I could probably make you a sample if you want. It'll probably be slower than the build in bulk insert from file thing they have, but it'll probably be OK.

It's all good. I think it's the usual encoding issue between Linux and Windows, and MSSQL didn't quite fix all of that. I also had to use docker because MSSQL requires an outdated version of openssl, because heartbleed I guess.

IMO, SQL Server isn't ready for Linux yet.

I didn't know they'd even bothered to put it on linux. I'm not quite sure why they did, tbh. I guess maybe they're trying to capture some legacy server applications?

(The reason it seems odd to me is that I don't think anyone who prefers linux is going to choose MSSQL over the other offerings, so the only reason I can think of why you would is if you had an app that already ran on MSSQL server and you were tired of running NT servers)

C++ std::tuple

You have to provide a type to the template. It does not hold arbitrary types at run time. The closest you can get is std::tuple<void *, void*> and so forth.

This is, pretty much exactly, the premise of an episode of Black Mirror. (3x01 Nosedive).

My brothers startup just went under and now he's looking for a new job. Only been at it for 10 months. Reminder to always keep your resume up to date. A month ago they were looking to move to a bigger office and now they are tanking.