> Teaching how to code should be about problem-solving and effectively using the tools of a programming language to solve it. Say for example modeling a card game. Even better if the example is a continuous improvement starting from the very basics, hard coding stuff, and then increasing the scope as follows:
How funny! This is exactly the approach Jenny Greene and I took in Head First C# (O'Reilly), right down to the way we start with cards and suits, then ordering, building up to a complete card game.
You start with a static card on the screen and slowly add more robust features until you have a fully working card game.
I was able to follow this course in 2014 as a freshmen in high school and it certainly influenced my trajectory to being a professional mobile and web developer today. The greatest nugget I took away from this is that programming is not about actually knowing anything about the computer: it's about declaring "this is what I want" in a computer-friendly way and then following through with "how the hell do I get you to get out of my way?" aimed at the compiler. Although work experience has taught me that you also sometimes need to port this approach to managers and coworkers.
I also think this is why generic questions like "how do I learn programming?" put you in the wrong direction. You don't care about programming, you want to build an app, or a website, or a business, or a game. The first step is admitting what you actually want and then you accidentally end up learning programming along the way.
Thanks for posting your project in full. Too much of RDF/linked data is in the abstract, to big to see the moving parts, or behind propriety doors. I'm at the beginning of the learning curve so it's much appreciated and quite a number of things about the data workflow clicked in - nice to see a graph and instance create process in rd4j.
I'm wondering if you've come across an approach to push the outputs of quantitative sparql queries such as your shot points% to a visualization tool..but, I'm looking for a semantically aware approach.
So as to be informative to this forum.. what do I mean... I'm not talking about a basic flow of the output a flat file (e.g. csv) and digest by a generic tool - take the pick of zillions of libraies here, but Power BI is my current bug bear where Microsoft has sold the promise of self serve BI but leaves everyone else to manaage the chaos of cleaved, chewed and duplicated data and fragile and disconnected calculation(DAX measure) code base.
So what am I looking for ?
Let's call them "measures", but in the rdf construct they are sparql queries as you've documented so well. The measure operates on data that meets constraints of it's type and cardinality amongst other things, but which has, if required been automatically changed as to the conforiming "pattern" using constraint rules. I then build my client application with visuals e.g. a chart or map that displays the sparql query results. The visual changes based on properties or constraints on that data. More over the acutal measure is stored with the data and encapsualted in the client application. Plus it has full provenance also included. I note here that general ontology and instance visualization tools abound, but not what you could call BI tools for charting etc.
I have been building my skills and work flow in a team that's adopting shacl and spin rules to drive data ignestion through to interfaces in the Topbraid tool set. The space is coming along but for this use case of charting and visualizing seems to have stalled, with the above UISPIN work now deprecated and waiting... maybe for shacl and some shacl javascript mappings to come to the rescue.
I've found some interesting new work using webcomponents (polymer/LitElement) that makes sense:
https://blog.resc.info/reboot-of-using-interface-encapsulati...
But it feels a long way away for me to tackle conceptually and skills wise with yet another code framework to get on top of.
> The team realized that the process could be reversed: given a computer model of a 3D object, the researchers calculated what it would look like from many different angles, and then fed the resulting 2D images into a ordinary slide projector.
I'm pretty sure the researchers were using a normal computer projector and not a slide projector. But in my imagination, they printed a bunch of slides, fed them into a carousel projector, and pointed them at an old Smuckers jelly jar full of resin.
> And unlike with object recognition that uses cameras, there are no privacy concerns, or need to maintain line-of-sight or good lighting conditions. Radar works through different materials and in the dark as well as the light.
Wait, what? The ability to see through walls and not require line of sight leads to fewer privacy concerns?
Seems to me the privacy concerns are significantly greater for radar than facial recognition. Radar can see places that cameras can't, and while it doesn't capture color information, it does capture detailed 3D data that camera-based systems need to interpolate.
Plus, you know, the whole working through walls thing. Seems like there are at least as many opportunities for abuse as with facial recognition technology.
Firstly, I think (though I could be wrong) that when they talk about privacy concerns they mean the sort of concerns the average person would have about having a camera about... I.e. naked or compromising pictures of themselves getting leaked. I would guess this wouldn't be a problem with radar as it doesn't create images.
Out of curiosity though, not having much knowledge on the subject myself, what would be your security concerns? I would be genuinely interested in knowing what we should be looking out for, privacy wise, with such technology.
Don’t confuse privacy with secrecy. I know what you do in the bathroom, but you still close the door. That’s because you want privacy, not secrecy. (From I have nothing to hide. Why should I care about my privacy? : https://medium.com/@FabioAEsteves/i-have-nothing-to-hide-why...)
But privacy is relevant here. Easy example: a person whispering,their private conversation no loses it's privacy due to lip movements being read. Two people enter a room and exchange an item for cash,with radar their transaction loses privacy.
Emotional manipulation. Using radar to detect emotional states with 70% accuracy for the general public was achieved 2 years ago by the EQ Radio team at MIT.
They did this by detecting breathing & heart rate at a level of accuracy on par with wired sensors.
This tech works through walls for multiple people at a time, whether they're sitting still or moving.
The world is not emotionally responsible enough to protect against this tech.
If the technology were fetishised, the tech itself would acquire the status of fetish, which isn't the same as the tech being used to ends of fulfilling a fetish (e.g voyeurism). Some brands arguably promote technology fetishism, but fetishism isn't necessarily sexual, for instance the theory of commodity fetishism.
Radar can create images just not true to life color photos. But, leak such a photo of a couple in their bedroom with the blinds closed and you have a problem.
If you mean from the inside that’s a question of contrast. Look at a tv in a dark room through one side of a t-shirt a few inches from your face and it’s a non issue. Try the same while the side facing you is well lit and it does not work.
Under some situations you can see through thin cloth blinds like this from the outside, but that’s mostly poor blind choices.
It's actually a blind on my backporch similar to this: https://images-na.ssl-images-amazon.com/images/I/71rijF9vnlL... , but it has tiny gaps in-between each slats... I could see through the blind when I was zoomed in to 300mm while being a meter away from it... I could see my neighbor's house and the slats were invisible in the picture. Kind of creepy but I don't have this camera anymore so I cannot do anymore tests...
The video linked below literally has an example of this technology recognizing individual credit card even when stacked. While (I assume) the CVV code isn't readable because it's not embossed into the card this still seems like exactly the kind of application that does have privacy implications.
Imagine someone sticking these under the chair in a cafe and skimming the card numbers of everyone who sits down.
I've been looking for an example that shows how pattern matching can make code much both compact and readable. I think this does nicely. Here's an example in Scala:
(1 to 100).map(i => (i % 3, i % 5) match {
case (0, 0) => "FizzBuzz"
case (0, _) => "Fizz"
case (_, 0) => "Buzz"
case _ => s"$i"
}).foreach(println)
Compare that to the rest of the examples on the page. The only one that comes close in either readability or compactness (in my opinion) is the Rust example, mainly because it's syntactically almost identical, just a bit more verbose. I'm really excited that C# 8 will support similar syntax with _ discards.
Well, yes, you're right – like beauty, readability is in the eye of the beholder. I've been writing a ton of Scala code lately, and my version is very Scala-like, so it looks better to me.
That said, I think there are several advantages:
• It's more compact, with fewer lines and fewer characters, but at least as readable
• There's simple separation of concerns: it only has a single print statement – the whole range is transformed, then printed – which makes it easy to refactor later if I need to use those values for something other than printing
• It's obvious that all of the cases are handled
• In an amazing coincidence, it looks like code I write :) so I personally prefer it
If you're implying that there are times that if/elif/else syntax is more readable than pattern matching, then yes, absolutely! There are times when one is preferable, and times when the other is.
Pattern matching is especially nice when you need to include conditionals and types:
vehicle match {
case car: Car if (car.passengers > 2) => addToHovLane(car)
case truck: Truck => reject("No trucks allowed")
case _ => totalTraffic += 1
}
There's a lot of casting going on there, and it's all handled in the pattern match. Converting this to if/else statements would require a lot of type tests and intermediate variables. Personally, I think that would make things harder to read.
That said, sometimes (often!) the more compact code is, the harder it is to read. I think it's always worth taking a few extra characters to improver readability. So I only use pattern matching with types and discards when I think it makes the code more readable and more flexible (e.g. easier to refactor, improves separation of concerns).
BTW, thanks for pushing back on this. I'm working on the 4th edition of Head First C# (O'Reilly), and C# added syntax very similar to this (borrowed from F#). Writing this reply gave me the opportunity to start thinking through how I want to teach it.
Pattern matching seems like a useful technique. The languages I use most often don't have it, so I haven't used it much personally. I can see how it would be nice to have for your vehicle example and things like that. FizzBuzz is just so trivial that I don't think the benefits really shine through as benefits and seem more like just alternate syntax.
Well for one, the cases of a match statement are guaranteed to use the same variables and return the same output, in every case — the equivalent if-elseif-else does not offer the same guarantees, and has to be read in full to reach the same conclusion
So the statements are equivalent in whole, but the difference is that a match statement requires less reading (as it holds more meaning)
I agree with you. Pattern matching is detrimental to readability in this case. Everybody can understand your example above. The pattern matching one leaves me a little O_o (pun intended) despite I'm using pattern matching everyday in Elixir.
I think that’s more a matter of familiarity than of readability proper. The same argument could have been made against Arabic numerals, against the use of “=“ for assignment and “==“ for equality (“=“ had been used in mathematics for equality for ¿centuries?), etc.
One could also argue that, by using the knowledge that “is divisible by 3 and 5” is equivalent to “is divisible by 15”, the code using %15 is cleverer than the example that just follows the problem description.
The Haskell example is quite similar to the Scala/Rust example as well. I guess you could rewrite the Haskell version to match your Scala version pretty closely as well if you prefer doing the tuple construction and then matching on the tuple, like in your Scala version, instead of doing it directly inside the pattern match.
Something like this, with the caveat that I haven't done any proper coding in Haskell in years and I don't have an interpreter installed to verify correctness.
The step in the composition chain breaking down the integers into ordered pairs of the remainders is classy. Well done. For added points we now need an ADT to represent the different possible results of the computation :)
When I was studying computer science at Carnegie Mellon in the '90s, I played bass in a band, and the guitar player was a grad student at the Robotics Institute working on the autonomous vehicle project, the reason CMU was part of the consortium in the article. NavLab 2 was an Army Humvee with a laser scanner mounted on the front, along with some cameras and a bunch of other sensors, and some powerful-at-the-time computers (Sun SPARCstations, IIRC) in back. It was a pretty impressive sight: https://www.cs.cmu.edu/Groups/ahs/images/navlab_1_5_images/n...
It was usually parked in the Field Robotics garage, but if you went out early on a weekend morning, you might catch it driving itself slowly around Schenley Park (which is right next to CMU campus) – without anyone at the wheel, which was really unreal and sci-fi-ish at the time.
I remember one story of a jogger who was surprised to suddenly run across it. The story goes that the he or she screamed and actually fainted. The truck was programmed to stop if it found itself in front of any obstacle, so when the jogger came to, there was the truck looming above.
I have no idea if the story is actually true, but I like it anyway.
I remember it running autonomously on the little roads in Schenley Park, which were wide just enough for the vehicle but not open to traffic. Unfortunately, I never learned what happened to the jogger.
I heard the same story about the jogger being hit by the autonomous Humvee at CMU. I ended up going somewhere other than CMU, but the onsite interview process included a tour, and that tour mentioned this jogger being 'hit'.
I've known people who lived a life very similar to the one this person describes: moving from town to town, making art wherever they go, meeting new people, floating from relationship to relationship, not much money or stuff to their name, nothing really tying them down. The difference is that they were the sort of people who said "f_ck 'normal' society and its expectations" – an attitude that I don't see much these days – and, maybe as a result of that attitude, they were really happy people.
> I used to think I was the one who had it all figured out. Adventurous life in the city! Traveling the world! Making memories! Now I feel incredibly hollow. And foolish. How can I make a future for myself that I can get excited about out of these wasted years?
I hope she can learn to stop thinking about those years as wasted. She saw and did things that most people never get to see or do because they're too busy working. Plenty of 35-year-olds are in debt, upside-down on their houses, in miserable marriages, and just a few years from getting divorced, buying a convertible, and dating someone inappropriately young for them. More than a few of them would envy her life.
The vast majority of players won't realize that they can run untrusted code just by typing a few characters into a chat window. To be fair, most chat windows don't work that way.
One of the biggest misconceptions about markets is that the most recent trade price is the current value. But that's not actually true – it's approximately true in heavily traded markets (like S&P 500 stocks). But for a much less frequently traded market (like brownstones in Park Slope, Brooklyn or apartments in downtown Minneapolis) where there are only a handful of transactions each week, the price doesn't actually reflect value. It reflects the most recent price paid – and if there aren't a lot of buyers, then the actual value is lower than that price.
Most people who have done a lot of options trading have seen this in practice: if you're trying to sell a really thinly traded option RIGHT NOW, most of the time the latest price is a higher than the price you'll get. That's because there was only one buyer at the time, and someone else got that person's bid. So now you'll have to go to the next-most-interested buyer, and you'll probably need to lower your asking price a bit because otherwise he or she would have been the most recent buyer.
All of this is masked in heavily traded markets. But it's a lot more apparent in housing. However, that's complicated by the fact that people REALLY HATE lowering their asking price, so instead of seeing prices drop, housing markets typically just see volume go down. And recent lower transaction prices are often dismissed by sellers ("That person was just desperate to sell, I'm going to wait for someone to pay what my house is worth").
How funny! This is exactly the approach Jenny Greene and I took in Head First C# (O'Reilly), right down to the way we start with cards and suits, then ordering, building up to a complete card game.