I'm not American and I often see captchas that ask about "cars" or "trucks". And they use similar images. I sometimes don't pass through those. My question is, when I see a truck and I'm being asked to select all cars, should I select the truck or not? For me a truck is a car. Is it not one?
That might depend on what 'truck' means to you! Is it equivalent to the British 'lorry', or does it include pickup trucks? I'm Australian, and for me 'truck' means 'lorry', pickups are a kind of ute, utes are a kind of car, and so trucks and cars are clearly distinct. (QED!) There seems to be endless room for cross-cultural ambiguity here though.
A side quest to yours - when I'm told to select traffic lights - should I include the pieces with just the poles or it's fine to select only the ones with actual lights? I never get through them.
The way I learned it, a "car" is any roofed 4+ wheeled vehicle up to van and SUV size (yeah, more Americanisms). Pickup trucks and larger are "trucks".
Even this exemplifies bad translations between two dialects of English. To me a van is a Ford Transit, but it sounds like to you a van is a Ford Galaxy (which I'd see as a "people carrier")
I think trucks are cars. I would pick any automobile, really even anything with 4+ wheels and a motor. I generally pass those.
The ones that get me are the street sign / street light ones. Do the poles count? What about a tiny edge of the sign that is barely visible in a neighboring square? Ugh.
The thing is that "probably" is the entire issue. You might just be training an AI that "truck" is a specific thing in the USA and something else where you happen to live ... or you might also be trying to guess what Google already thinks a "truck" is.
The stakes might be low (you get presented with another captcha) or astronomical (you get your account locked or something). There is literally no way to know with Google, it's a complete black box.
right but im sure whatever purpose it's using it for is going to be used against the commoners at some level -- weather it be to sell a new service at a higher price point, help further their monopoly, or to better create dark patterns (against us).
they have no "benefit of the doubt" -- it's pretty blatantly clear they are not on "our" side.
In my country, the Ford F150 truck would be referred to as a car or a "half-truck", while a semi-truck is what would be referred to as a truck. That's a piece of cultural difference that will dirty your training.
It might be called a car or a pickup truck but never just a truck by someone here. While "pickup truck" is an American inherited phrase which has truck in it, they're considered trucks about as much as a catfish is considered a cat.
ssh into a secured machine with port forwarding, then being able to access services exposed from that machine e.g. for web testing on Android, or using VNC / NoMachine to remote into it.
Is it the job of a computer scientist to run programs on servers though? That seems like specific technical training, not the subject of a computer science degree.
I think if you take it to the extreme, the job of computer scientist isn't to run any programs. It is to write them. To quote Knuth:
> Beware of bugs in the above code; I have only proved it correct, not tried it.
No, as a computer scientist, your job isn't to run programs on servers (or, at all).
As a person who needs to eat and pay rent though, I think it is fairly reasonable to expect you to know how to run programs you write, with or without an IDE. The reason for running programs without IDE is that most often, executing the program won't be a "javac Main.java && java Main", but probably some rather complicated maven/ant/gradle/shell/... command that you'll have to program your IDE to do anyways. If one can't even use a simple javac/java commands, one might have a very difficult time with those concepts.
And now, the overarching point is, does one as a student mindlessly click the green run button in Eclipse, or was one curious (and paying attention, because javac and java are usually taught in the first lecture) and actually tried to understand what's going on after you press the green button?
I'd go as far to even say that the curiosity of "what happens after I press this button" indeed is a job of a computer scientist.
Just my 2c, and why I expect fresh graduates to know a bit more than "class Dog extends Animal".
My point is the precise technical details of how to run one particular language in one particular environment are irrelevant and not the business of a university. You can pick up this practical skill anytime you need.
You're supposed to be learning the concepts. You can do that using an IDE.
I have no idea how to run an Erlang program on a server. Could I pick it up in five minutes if I needed to? Sure. So why do I need to learn it? Why do you care if I can do it coming out of university?
> Could I pick it up in five minutes if I needed to? Sure.
Yes, because you do know the basic concepts of using a CLI, the concepts around building your project, and the concepts of project metadata, build tools and etc.
When people can't run their programs without an IDE, it's because they don't know any of that. This is an at minimum 6 months learning of the unwritten culture of a profession. This is not something one can pick up in 5 minutes. It is also a huge signal that those people are missing other fundamental and important pieces of knowledge.
(That is, unless the OP is literally complaining that he threw people on a random computer CLI and people couldn't make their code run there. Personally, I have never seen anybody making this point, but I guess it's possible.)
But IDEs on developer devices can remotely interface with servers, and how many developers ever have physical access to a server rather than using it remotely from a workstation?
As a developer (though not by education a computer scientist), the vast majority of the software I cause to be run on servers is triggered automatically by updates to git repositories, and most of the rest is done via web consoles. Sure, I know how to do more, and that's sometimes even relevant to my work in terms of scripting what happens in CI/CD pipelines, etc., but running software on servers directly isn't really a central job duty.
And for the more pure ops people for whom it is, they are even less likely to have jobs that looks for a CS background.
Not many folks are developing on servers. Now, I will agree that devs should be able to write the Makefile/Dockerfile/whatever to tell the CI system how to build the artifacts that are deployed to the server, which does probably exceed what an IDE can do.
Ability to use the stack is a very important performance oriented feature. Similarily, ability to nest structs or other data structures without intermediate pointers. I hope this could be solvable!
Jonathan Blow's language is the most interesting from these three for me because it will have nice metaprogramming features. The document you linked to seems slightly outdated. One of the beta testers has published some more up to date videos with his language introduction and initial experience: https://youtube.com/watch?v=i1vbvikDiI8&index=1&list=PLhEuCy...
Personally, I agree with Jon in that he is not too bothered about being the "winner" with regarding to his language. He wants a tool that can help him actually solve problems he has. And he wants to make sure that his tool is good before releasing it to the public. Releasing a product before it is done is can of worms in itself, not to mention the problems related to open source software itself. So it is entirely respectable for why Jon has not been as opened up his language to the public yet.
I created Odin for the very same reason that I wanted a tool that made me more productive and helped me solve the problems that I actually have. Even if Odin only benefited myself, I would class that as a success, but it has been helping so many people create amazing things.
> Releasing a product before it is done is can of worms in itself
Perhaps, but a programming language which is released when “done” is essentially dead on arrival. I’d guess the people who created amazing things with Odin helped the language move forward, right? Nothing wrong with keeping something to oneself, but promising for a long time to move something into an open source model with no set date.. I’ve rarely seen that end well. Hope I’m proved wrong though!
well Jai is probably the least interesting language for me as the others actually exist. When Jai ever gets released, only then I can see all its warts and glories.
I mean it obviously exists. He livestreams coding on the language and in the language. Sure very few people can actually use it right now, but existence is not in question.
But existing for someone else, and existing where I can use it are two different things. I'm sure there are lots of cool tools and things that exist at big companies like Google (or more interestingly say the NSA) but for all my intents and purposes they don't because I can't interact with them.
A reverse corollary to Russell's Teapot? So what if there is a teapot orbiting Jupiter, I can't get it so it allows me no ability to serve tea. Therefore it might as well not exist!
I understand that. However my comment was just a statement that the existence the person above me was implying was useful existence. As in we can all be excited about this new tool, or game, or whatever, but if we never get to use it, its usefulness is moot. So while the language certainly exists we can observe him working on it, and he could even create a game using it that would have some societal impact, the current usefulness of the language to anyone except him is as if it did not exist at all.
Of course you could make the argument that its mere existence and him highlighting certain aspects could have influences on other language designers... and wow am I going down a tangent spiral now...
Anyways: TL;DR reality is objective but words can have complex semantics
But that's a big deterrent for a lot of people. Odin, Zig, and the like are languages that can be used right now. Yeah, they're not mature yet, but you don't have to wonder what it is like to program in them, and you can start building familiarity with them today.
It’s been a while since I was following Jai descriptions, but IIRC, Nim exists today and has all the meta programming features Jai is supposed to - and to a large extent so does D.
The GC can also run incrementally to meet deadlines. It’s not like a Java GC. It has been used in microcontrollers. People should probably learn more about it before shooting it down based on the word GC.
Java GC also has been used in microcontrollers, with soft real time deadlines, there are plenty of JVM vendors out there, including a couple that are only focused on embedded development like PTC, Aicas, Gemalto, microEJ, Virtenio.
Yes, with some relatively minor caveats, mostly having to release memory yourself.
Also, the arc/orc GC is shaping up and already allows you to use exclusively reference counted memory management - so, efficient and perfectly deterministic timing but still get automatic memory management. (As usual, if you introduce cycles, it becomes more complicated)
And the Nim compiler elides many ref/unref ops, as well as keeping objects thread-local, so most performance objections to ref counting don’t actually apply. (.... and you have a choice of other automatic GC modes, including “none”)
And D has the DasBetterC mode, but I'm not sure that's good enough: when the language has a GC by default, all the libraries use it, the APIs relies on it..
What good is a language if you can't (easily) use its libraries?
Nim’s relationship with GC is very different than any other language that I’ve used.
It has very different selectable GC systems - Boehm, Bacon/Dingle, reference counting, or real-time deadline mark-and-sweep, and “none”. Perhaps I forgot one. Some libraries rely on a specific GC behavior but most work with any (with the caveat that “none” requires you to manually deal with garbage).
Nim’s mark-and-sweep is suitable for embedded systems and games, unlike Java’s, and so is the ref counting one; but even if none of the GCs work for you, the fact that there’s many of them and they are mostly interchangeable means that the dependency on them is much, much weaker than you are used to (although it still exists)
Yes, the general idea is not new but the devil is in the details.
As far as I can tell, Odin's `using` is applicable in the same areas as Kotlin's, but I still favor Kotlin's scoped version. When I see "using foo;" in Odin, it's not quite obvious to me where the scope of applicability is.
Any reason why you didn't do something like
entity.use {
// "this" is now the entity instance
}
// back to your regular "this"
?
You can easily do the same in Odin, if you would like. However, `using` works for a lot more than that just this. `using` allows for many for type system features beyond a basic scope import like Pascal's with. `using` can be applied to procedure parameters, struct field declarations allow for subtype polymorphism (even of pointers), scope imports, and more.
Koltin's approach is limited to purely the same Pascal's `with` allowed.
But if you want to be clear:
{ using entity;
// the fields of "entity" are not usable in this scope
x = 123;
}
entity.x = 123;
