AI in the sense of "player vs. AI" is widely understood.
AI does not require ML.
"It's part of the history of the field of artificial intelligence that every time somebody figured out how to make a computer do something—play good checkers, solve simple but relatively informal problems—there was a chorus of critics to say, 'that's not thinking'."
AI does not mean ML, it is a broad field that is a superset and not a subset of ML. Or as Wikipedia describes it:
>In computer science, artificial intelligence (AI), sometimes called machine intelligence, is intelligence demonstrated by machines, in contrast to the natural intelligence displayed by humans and animals. Leading AI textbooks define the field as the study of "intelligent agents": any device that perceives its environment and takes actions that maximize its chance of successfully achieving its goals.
Every program that has ever existed does this. So, you're saying that all programs that have ever existed, then, are all AI. You make no distinction whatsoever.
I would say that the more a program thinks on its own which actions to take to maximize its chances of success, the closer to AI it is.
If it's doing exactly what it's explicitly told, then it's not really intelligent, is it?
I strongly disagree. For example, in this algorithm, there is "knowledge": the knowledge of the programmer that realizes that following a person moving can mean also follow one of the previous positions of that person (especially if we can revert to follow that person again at some point), and this knowledge is encoded in an algorithm using code, that is, yes, those "if-then statements" you seem to despise.
For years (but even now) Artificial Intelligence meant understanding how intelligent behaviors worked, and then understand what is the sequence of "if-then"s that could express those behaviors in an artificial setting. Use statistical inference is a "hack" (unavoidable, often) to cover the cases in which such behaviors seem to be too complex to be grasped - and then expressed - by one simple and/or comprehensive algorithm, but the (possibly unattainable) ideal would be having everything expressed as "pretty much an if-then statement" indeed.
> the (possibly unattainable) ideal would be having everything expressed as "pretty much an if-then statement" indeed.
This is flatly incorrect - the point of AI is to have a machine achieve intelligent behaviors without explicit programming.
If an "if-then" must be written by a programmer for every single behavior, then this is called "programming". It is not called "artificial intelligence".
No, the point of AI is to have agents achieve goals based on observing an environment. Nothing says they have to be complicated agents or not explicitly programmed. Any book on Computer Science AI will be largely filled with agents that use rather explicit logic and algorithms.
Still incorrect. And I would urge you to read one of these books you reference - they ALL aim to achieve that agent's action ON ITS OWN - i.e., by learning from its environment, and NOT by being explicitly programmed.
Yes, there are many explicit if-else style programs in Russel & Norvig, & other books - but those are the 'training wheels', until better methods are developed. For actual AI, the training wheels are supposed to come off, and the agent learns and acts on its own.
There is a distinction between what is AI and what is state of the art AI. Simple approaches are AI but not state of the art AI. At one point massive rule based systems were considered state of the art for example and those were nothing but explicit if-else statement. Now they're not but they're still AI.
BASIC, for example, would be considered merely a training wheel in any book on programing languages but it is nonetheless a programing language.
That's fair. I guess I meant more "the frontier of academic AI", but then again I don't really keep up with academic AI at all, so I might just be wrong about what academic AI is. I can't really make any strong claims about academia.
My stronger claim is that this falls so squarely within the bounds of "game AI" that it's fairly ludicrous to say it's not AI.
Such a wrong take. Decision trees are nothing more than if statements. Fancier versions of those (random forests) are consistently near SOTA algorithms like neural networks (and beat them on tabular datasets frequently). AI can be just a shit ton of if/else statements.
AI is much broader than ML. In gaming specifically you typically label behavior of dynamic, life-like entities as AI. Behavior trees, state-machines, path-finding and so on. A typical example: the ghosts in pacman.
My first game was a homework assignment: write a 1-player pong game (like arkanoid without the bricks). I juiced it up a bit by adding a second "AI" player with a very rudimentary ball-following algorithm.
if (ai.x - pad > ball.x)
move_ai(-max_speed);
else if (ai.x + pad < ball.x)
move_ai(max_speed);
... or something like that, with some bounds checking and some logic for smaller moves. Bottom line, "just an if/then statement" can be sufficient to make a playable game with a challenging (or even unbeatable) computer player. Tic tac toe is another example of this.
A* search, any kind of heuristic estimation, learning, or simulated reasoning. All of those things would count.
We don't need mathematical optimization to call it "AI", but there SHOULD be more than a simple if-then.
At least show me that you're path-finding. That's not even being done here - this is just path-following.
"I leave a trail, you follow it." Explain to me how that qualifies as AI. Simple BFS/DFS achieves a lot more than this - which is considered by most to not even really be AI.
I think this is for people who already know Python, and just need a quick memory aid. I agree for a complete and correct reference I would recommend the documentation, as you said.
A proper cheatsheet takes liberties for the sake of achieving both brevity and comprehensiveness at the same time.
While I agree the notation is a bit weird, I disagree that there is any standard notation for types. The Python docs in particular fail for exactly one of the things I like about TFA - it tells you the type of the output of each function in its angle-bracketed style.
Take, for example, the definition of the operation s[i:j] in the Python docs: the result is "slice of s from i to j". Is that the same type as the input? Is it an iterator? No information.
I doubt most people are confused about the output, but a reference is specifically for people who are uncertain about how a function works.
In one of your math courses you'll eventually run across what they call "set builder notation.
The notation for this is a decent example that shouldn't be too hard to follow. What it's basically saying is
{2x: x∈[1,10)}
with the implication that x is an integer. We usually read the colon (or sometimes a vertical bar) as "such that". I know my explanation is somewhat lacking, but you can probably see the parallels there. You'll probably get to it this year or next.
I'm very aware of set builder notation, and also not a fan. I mean it beats a lot of other things mathematicians were probably doing before they agreed to it, but it's still not ideal in my eyes.
My example (formatted again below), is probably an interesting middle ground, because both the left and right are only mildly interesting. While most often (not always) in math I've seen the right be "trivial".
trivial right: { 2x : x ∈ ℝ }
mildly interesting right: { 2x : x ∈ [1,10) }
complex right: { 2x : x ∈ [0, ∞].filter(...) }
In the top two cases, things aren't so bad. But as we digress to the third case I fear we'd be better of like:
[0, ∞].filter(...).map(|x| 2x)
This is generally how I'd solve the issue. I've made a point of avoiding talking about nested array comprehensions, since these get completely impossible to reason about statically for me.
EDIT: Just because I' on a bit of a rant ATM, I might as well complete it...
In Rust we also have where clauses, however you still must at least introduce the name up front. For example:
fn foo<A>(..., a: A, ...) where A: ...
This solves the problem of name resolution in my head while I try and read this function, since there's always a namespace you're operating within. Without the leading `<A>` I'd be left wondering WTF `a: A` means.
As a person who often struggled in math for perhaps many reasons, this was a common issue for me.
First you define things, then you use them.
No other rule makes sense generally, and I challenge anyone to prove me wrong.
Now is a simple set like { 2x : x ∈ ℝ } going to confuse me, probably not... but when variables are just thrown around all willy nilly, I get confused pretty quick.
I never understood list comprehensions, and was always slightly resentful of (in my mind) their illogical ordering until I realized they were mimicking mathematical expressions.
I wouldn't call this a functional argument, per se, although many functional languages encourage the kind of syntax I'm advocating for here. And some may not...
Basically I write things like `data.map(|x| ...).filter(|x| ...)`, or just `data.fold(|x| ...)` and I'm quite happy.
The origin of the "standup" is just a regular daily coordination meeting - like thousands of organizations have always had.
Ever heard of a "morning sales meeting"? They've existed for decades - short, to the point, 15-20 min. No one's ever heard of scrum in sales meetings. This kind of thing exists in hundreds of other businesses as well.
Much like everything else in scrum, they are just trying to take credit for something people already did - so they can package it and sell it back to people as if it were a novel idea.
There's nothing new or special about scrum - except a reduction in productivity because of the additional overhead and meetings.
The think I don't like about scrum is that they teach that you literally don't need to know a single thing about the underlying business - in fact, that is discouraged - following the process to the letter is what counts.
It is sold as a one-size-fits-everything process model, which can be run by non-programmers with zero experience who took a few workshops and got a scrum "certification".
It applies to any business - now including finance, accounting, and more ...
So I'd say by definition, a scrum company can achieve level -1 or 0 at best. It fits the Level 0 description PERFECTLY.
An actual formalized process which could be optimized would have to be set by subject matter experts after some deliberation. And would be designed to make an impact on product and quality.
Scrum can never achieve this - because the fundamental idea is that you can manage any business with the same established process - it will fix all of them ... no matter what the problem is ...
Yeah, I read this link also - before posting above. There is no 'username' or 'password' term on that page - nor any positive checkmark in any security column for the open-source tier.
'Basic' tier does have 'File and Native Authentication'. But it is far from clear what that means.
More importantly, in several different places that _are_ clear about security in the Elastic documentation, it repeatedly says "there is no security", "assume anyone who can reach elastic is a superuser" ... and more ...
So if that is not true, the documentation should probably change ...
It's definitely complicated, and can be quite confusing due to the number of subscription tiers, the ambiguity around terminology, and historical documentation.
We need need to find a way to bring more clarity to the documentation, and we try, but the subscriptions page, in particular, is very difficult. It's already very long, so we don't want to add detailed explanations to individual points but it's hard to find short sentences that are both accurate and well understood by a variety of audiences.
To be clear:
- There is no security in Open Source elasticsearch.
- There is security in the free "basic" license. It is, at the time of writing, disabled by default.
- Early versions of Elasticsearch had no security at all.
- The security product that we (Elastic) produced was exclusively a paid feature for many years
- If you download the latest version of the Elastic-licensed distribution of Elasticsearch (which is the default download if you get it from our website or package repositories), you get a version on which you can enable security, free of charge, without needing to register, with no expiry.
The only documentation I found which says "there is no security", etc is from old blog articles (e.g. this one from 2013 https://www.elastic.co/de/blog/found-elasticsearch-security). We don't do a great job of indicating that the information on those articles is out of date.
At any point of time, if you feel that docs are not appropriate kindly raise a issue in https://github.com/elastic/docs. You could also consider contributing to docs. Appreciate it!
Other than that, we have a very live discourse forum. You can also put up all sort of questions discuss.elastic.co.
Still want a more real time chat, you can join slack group too ela.st/slack.
I feel the term "Data Engineer" gets used for a lot of catch-all "we have problems that need an owner" situations.
There's not much consistency across job postings and interviews for this kind of thing.
I just interviewed for one "Data Engineer" position which consisted of nearly 100% stored procedures. No one knew what else to call it, and they didn't want to advertise for a DBA, because there were no real DBA responsibilities. So "Data Engineer" was chosen.
Another "Data Engineer" position was almost entirely Spark. There was no SQL involved - they expected all applicants to be Spark experts, with a deep knowledge of Scala.
It's hard to know what to expect out of "Data Engineer" positions until you walk into a place and start asking questions in the interview.
For us it's simply the runtime you target. A frontend engineer writes code for the browser. A mobile engineer writes code for iOS or Android. A backend engineer writes code for servers. A data engineer writes code for the analytical/warehouse environment.
It was typically backend engineers doing the data pipelines to expose records from their own services, until the company got bigger and the analysts got more demanding, and that became a dedicated role.
Ah gotcha, the problem isn't that it's a vague job title, the problem is that the job description for a particular position may not set expectations clearly enough
No - I'm trying to say that people often don't even know what the DE really needs to do. They know they have back-end problems, and need someone to clean them up.
But often the hiring manager believes it's probably mostly SQL or mostly python, and advertises that. They really don't know - because someone left, and they are trying to replace them.
So you get there, and talk to the hiring manager, and they're like "are you good in SQL?".
Then you talk to someone closer to the problem, and they're like "most of it's in Java - how's your Java?".
Then someone even closer to the position says, "well, most of the work we need done is really in Scala".
It's your job to just take it over, and make it happen. "Fix the data" - using our existing patchwork of tools ...
This isn't always the case - but given the nature of the problem, this happens a hell of a lot more often than with Soft Eng's.
You're seeing the same thing happen with the "Data Engineer" title as what has happened with "Data Scientist."
In the hiring market, many positions that were previously titled "Data Analyst"/etc were renamed "Data Scientist." Similarly "Database Engineer"/"Data Warehouse Engineer"/"DBA"/etc were renamed "Data Engineer."
Why? Various reasons:
One might be the need to give people a sexier title because they don't want to be "just a data analyst."
Another case might be, hiring managers and recruiting teams changing their title to capture more views for people searching using these terms.
And why are people searching for jobs using these terms? Articles like the ones in the original post, and "Data Scientist: The sexiest job of the 21st century" ;)
I had to stop calling one of my previous roles “data engineering” because people thought I was just doing SQL script ETL... which really was maybe 30% of the job, but apparently that’s too menial to give you programmer cred.
> Young people starting out in the labor market often have The Fear that they will never find a job or never find a good job or another good job.
Young people fear it. Older people know it.
> Quit.
Not everyone is a 20-something silicon valley kid with companies falling all over themselves to throw money at them.
Hiring is effectively broken these days - especially in the software world.
If you're not from a top-flight university, maybe a little older, or in any other way less flashy/attractive in the job market, it can take months or sometimes years to get decent job interviews.
You can't just walk away from a decent income because idealism.
I thought older people are more valuable since they have more experience. There isn't much physical difference between 20, 40 and 55 year old people unless something like alzheimer kicks in, especially in our field where the job includes reading stuff and pressing button.
LoL, wait till you hit 50. I hope it doesn't come as too much of a shock. Do what you can to save up as much money as you possibly can in your 20s, 30s and 40s because it becomes a lot harder to find gigs when you hit 50 (even mid 40s in many cases).
I'm in my mid-50s. Took me 9 months to find a gig a couple years ago when I was looking. Now to be completely honest that's also because I can afford to be pretty picky at this point and I was only applying for stuff that looked really interesting. And if it looked like there was just too much bullshit I wasn't interested. When you hit your 50s you've seen a lot of bullshit in your time and can smell it a mile away. So yeah, it works both ways. There's definitely ageism, but many of us who are aged have saved up enough so we are also picky about what we want to take.
I'm currently between gigs again (previous contract may come back when they get funding so I'm kind of biding my time because that was a good place to work and good places to work can be hard to find). I don't want to call it quits and retire just yet, but I'm finding less and less that's non-bullshit out there these days. And the way interviewing is done these days... well, let's just say it makes me want to retire. I like the work, but I hate the interviewing.
The often cited reason is that young people are easier to manipulate and exploit (overtime, passion, kool-aid about the company "mission" etc.), or more charitably phrased are more "adaptable" and less set in their ways.
They have fewer responsibilities, no family etc. They are more idealistic and don't have the same cynical/sour/realist/seeing-through-the-bullshit outlook that older people have.
For hiring discrimination? I mean, that’s kind of a hard question to answer.
Personally I think there are lots of people who have an idea in their head (not always consciously) of what a hotshot developer looks like. And it’s not the old guy. And I think this manifests as concerns about “culture fit” or being overqualified or other vague objections.
We ALL have biases. It’s on hiring managers and HR departments and all of us to actively work to minimize their effects. This is hard to do and, unfortunately, some people don’t care to try.
But certainly there are other reasons too. Bias in hiring is a tough problem.
>>I thought older people are more valuable since they have more experience. There isn't much physical difference between 20, 40 and 55 year old people
Older people have families, don't buy the "lets work 20 hours a day," or "we're a startup" despite being founded in 2000 or whatever, and that's a liability to some. (Another thing, is that they might be less willing to take orders from their 23 year old boss.)
My personal experience is that the very best managers use "asking questions" as their main management tool as this is effective to reveal all aspects of a situation and get employees to understand and support the decisions that follow.
Weak managers like to "take decisions" as a display of their value as a manager. This value elevation is undermined by old experienced employees who can point out bad decisions or that the manager doesn't understand the consequences of the decisions, i.e. a fear of being "exposed". Weak managers fear anything that makes them seem weak, like asking questions.
Definitely true on the not putting up with bullshit part. As a 50 something I find I have no patience anymore for bullshit. Companies prefer younger folks because they're so much easier to manipulate and control.
I'm very sympathetic to this perspective. If your options are:
1. Stay at unethical job you hate.
2. Get a new job you don't hate.
Well, the answer is pretty obvious. But there is a deeper challenge, which is the choice between:
1. Stay at unethical job you don't hate.
2. Damage/destroy your career and job prospects.
This latter scenario is really a "damned if you do, damned if you don't" situation. It forces you to pick. Would you rather be virtuous (i.e. ethical), or be paid?
> You can't just walk away from a decent income because idealism.
Sure you can. You just choose not to -- and (IMO) that's fine.
Given the trouble we have hiring, it’s hard for me to imagine someone qualified to be a median talent software engineer would have trouble easily finding new employment elsewhere. (The median interview candidate is much, much worse than the median engineer because the worse you interview, the more frequently you show up on interview loops.)
If you’re median or better and in a city with a reasonable tech scene, you are probably going to have a straightforward path. If you’re median or better and not where tech is, look for remote jobs (admittedly harder) or move where tech is.
If your skills are notably below the median, staying put and working on your skills might be the most sensible course and changing jobs once you can interview and place well.
How many people respond to your job ads? Where I live (major US metropolis), it's about 200-700 per job (according to linkedin, anyways).
The biggest trouble for a soft. eng is getting to a real person. Once that is done, convincing them that you're median or better is the easy part. Most resumes are just screened out by a machine, or reviewed by a clueless HR dept that has no idea what a median-talent software engineer looks like.
I have taught hundreds of CS undergrads in this city, and have had some of the very brightest tell me they've put out 500-600 resumes, and never heard back a thing. Many do get jobs though - even some of the worst performers.
It's very hit-and-miss - not nearly as deterministic as you make it sound.
I totally agree with your points, especially the last, and didn’t mean to suggest it was deterministic at all.
Interviewing is a lossy, semi-random practice for both sides. Candidates and firms take different approaches to address this randomness, but it’s still ultimately not a digitally precise (repeatable) not even especially accurate system. You could be the next Jon Carmack and fail to get an offer from 10 straight interviews for relevant positions. “Too experienced; we don’t really do what he’s interested in; bad culture fit; too good culture fit-we want more diversity; simply preferred another candidate; decided to not move forward with the role; lost the budget; existing employee transferred; never was a real open position anyway but we legally had to advertise it...”
What else are they supposed to do? Apply to the same job again? There's little you can do if you never make contact or hear back. You just apply to other positions. But what if you don't hear from those either ... ?
Open to suggestions here - but no stalker advice, please - I do not condone friending hiring managers on linkedin/fb, or some of the other creepy tactics we've seen recently.
I think the skillful students generally believe that investing effort to become skillful is all that's needed - and that doing so will eventually pay off.
This is sadly not really true as a general statement.
I have had many 'successful' students - who got more than one offer to choose from. Once, I asked one - who now works at a major investment bank - "so, great job - any advice I should pass on to other students if they ask about job-hunting?" (taking note for myself also - as I am a soft. eng mainly, and only teach part-time).
I expected something like "invest in your skills" or python, or java, or databases, or interview questions ...
The response was: "yeah - copy and paste the job description to the bottom of your resume, and turn the font color to white - so humans can't see it, but the machine will still read it and label you a good match for the job".
My point here is that the current system seems to work best for those who 'game' it to behave in unintentional ways - as opposed to filtering for actually skillful applicants.
Are you sure that many resumes of qualified candidates aren't screened out prior to making it to your desk? Hiring websites are awful. And there's absolutely no quality control - how do you even know who's not making it through who probably should be? Is anybody actually doing that kind of testing?
> (The median interview candidate is much, much worse than the median engineer because the worse you interview, the more frequently you show up on interview loops.)
Not sure I understand what you're saying here. People who haven't needed to interview in a long time are probably not good at interviewing but good engineers nonetheless. Conversely, people who are good at interviewing might be because they've had a lot of practice.
If you assume some correlation, even imperfect, between SWE effectiveness and interview performance, the least effective SWEs are likely to both be looking for work more often and require more interviews per successful job search, so will be way over-represented in the “who applies to interview” pool.
Joel Spolsky said it well: “A lot of companies think they're hiring the top 1 percent because they get 100 resumés for every open position. They're kidding themselves. When you fill an opening, think about what happens to the 99 people you turn away. They don't give up and go into plumbing. They apply for another job. There's a floating population of applicants in your industry that apply for nearly every opening posted online, even though many of them are qualified for virtually none of these positions.“
Don't pay much attention to what Sokoloff said. In theory, he's kinda right, but that's not how it works in the real world. And I don't know if you and him/her live in the same area/country.
I've had a rough time looking for jobs, due to 2 main reasons: not getting it right when adapting the resume to a job posting. Many ATS just discard resumes that doesn't have the exact words that they use on the job posting. Even if you are saying the same thing with different words...
The other was the phone interviews, made by a HR person looking for who knows what. For most applies that I did, I didn't get a phone interview. After phone interviews, didn't hear back.
I only got 2 technical interviews for like, 100 applications. One was for the job I'm currently in, the other I declined because I got the job offer to my current job. Both I got through recommendations, even if the people recommending me didn't know me. But they looked at my resume and put it stray to the HR manager for them to talk to me.
I also had a friend (not in IT) that was not getting anything. I told he to look for recommendations. She went to LinkedIn, found someone that worked or used to work at a company she wanted to go, and talked to the person, got recommended, and got the job.
> my age has never been brought up. Not even once IIRC
No one will ever bring it up.
Do you really think someone will take on the liability of discussing your [age|race|sex|sexual orientation] in an interview? ESPECIALLY as a reason to NOT hire you?
> You don't need to be a 20-something to land a good job.
Agreed. However, your chances drop precipitously as you age.
Studies have found this to be the case repeatedly - with very little evidence to the contrary.
> You just need to be somewhat good at what you do.
This is a vague statement that makes your premise unfalsifiable. If someone is not hired because of ageism, it is always possible to say they weren't good enough at their jobs, because good enough is never defined.
It's not illegal to mention it. It's illegal to not hire someone for that reason. For that reason, mentioning it would be stupid, whether you are discriminating illegally or not, and so it's a common misconception that mentioning or asking certain questions is illegal.
You leave a trail for the enemy to follow, and they follow it.
It's not even path-finding, it's path-following. Which is pretty much an if-then statement.
It's a neat, simple approach, and fun to watch. But there isn't any learning, or knowledge, or other AI.