> I often think about why/how medieval artists couldn't quite grasp how to depict depth in their paintings (as a lateral thinking technique).
The explanation for that is generally agreed on to have more to do with the aesthetics of early Christianity influencing Medieval practices, more than changes to human perception (source: I have a masters degree in Art History).
Not OP, though mild experience with art history and Christian history, but I suspect OP is talking about the intersection of art and the prevailing religion in Europe at the time (Christianity). Early Christian art was intentionally unrealistic in style specifically because the intent was often symbolism and representation rather than realism (this still holds true today for most Orthodox Christian art[0]). In fact, making it realistic would even border on idolatry (see Iconoclastic Controversy[1]).
That said, up until the European middle ages, nearly all art was that which was commissioned by the church. The style of the time permeated the art that wasn't commissioned by the church. As more non-religious art was commissioned, there was little need to remain working in that style and realism was embraced. I could be wrong, and probably am, but I think Catholicism is the only large Christian denomination that adopted realistic art.
I think depth was already understood by this point, though (see sculptures[2]). Again, I'm not OP, and I'm sure OP will have a more thorough explanation.
Good point. There’s also, to me, a perception of style and technique: there were a lot of stone-based art, made specifically to endure time. Bas-relief, a very fit approach of art for stone-based material had this specific style that got aesthetically and technically translated to paintings and stained glass, for an overall quite consistent style whatever the medium.
You can see the intent on many religious sculptures in medieval churches around e.g France: the technique is precise, so it’d be really easy for a sculptor to just compare and match to a living and breathing model, therefore they chose not to. Contemplating how churches tell stories through imagery, you can see how they used this style for emphasis on specific physical features to elicit strong emotional response instead, not entirely unlike those TVs in stores cranking up contrast to completely unrealistic levels.
This [1] is a painting from 1476. Notice how architecture and landscape has depth, but people are all +- the same size except for Mary and God.
You wouldn't want to draw mere mortals bigger than saints just because they happen to be closer. Peasants (which couldn't read and were the main target of these paintings) could get wrong ideas.
Not exactly what they mentioned, but check this out [1]. It talks about the perception of time in the middle ages, and how merchant time slowly substituted the impractical notions of church time. A professor of mine who was talking about medieval paintings and their ideas of space and time suggested this paper.
Ada was the first language I learned at university back in 2003 (I had previously taught myself C/C++, Assembler and VB). It had a huge impact on me and influenced my entire career and how I approach software engineering. These days languages like Erlang and Haskell are carrying on some of the ideas (modularity, type safety, concurrency, etc.) in more modern incarnations. But there is still something special about Ada.
Parsing a language like Haskell that does not use any parentheses and curly braces is slightly harder than a typical C like language (or Lisp for that matter). Haskell syntax is indentation sensitive, which require the parser to keep track of the indentation when parsing.
If you're doing combinator parsing, the offside combinator is a few lines. I have one in front of me as part of a demo Haskell-like syntax for Scheme as a command processor. You have to tag the lexemes with position information, but you presumably want that for error-reporting anyhow.
[As others have pointed out, you get the choice of layout in Haskell syntaxes and, as it happens, that Scheme syntax also allowed you to use sexp input.]
Using curly braces or parentheses to signify blocks of code is the trivial and natural way to implement a parser for a programming language. Doing anything else requires a conscious design decision and some effort and extra complexity. The C philosophy is to avoid complexity in the implementation in favor of a slightly more verbose language. The Haskell (ML) philosophy is the exact opposite. These design decisions have been cargo culted by later languages.
- make it easy to write and to read at the expense of having complexity in the parser / implementation. Programs (or documents) are written and read a lot of times, it's worth optimizing, as long as it does not make the implementation unmaintainable. I'm saying that as a writer of several manually crafted parsers.
- avoid ambiguities in the grammar at all cost. They just suck for every party involved.
As for indentation vs braces to delimit blocks, I practice both and don't really have any preference.
Copying and pasting python code is annoying (more so because it doesn't have macros or any metaprogramming really) and having to indent things in the python repl just feels dumb. I don't know anyone who thinks python does "well" in this area.
It does well but I'm not happy when I move code around and have to manually fix the indentation level at destination and check if I inadvertently broke an if or some loop. My editor does it for me with other languages and I have one less source of bugs.
VS Code tries to do it, but it’s heuristic based and generally fallible. (Disclaimer, work on vscode, not on python extension)
I much prefer working in languages wherein the series of tokens absolutely defines the semantics (as opposed to Python where the series of tokens + the context define the semantics)
Yep, but no editor can decide if the code must align with the last line of a loop or be indented out of the loop. I got at least one bug in production because of that, and a test that didn't catch the error.
Seat belts kill. They occasionally strangle people.
Yet they save far more than they kill, so we not only use them, but many countries mandate their use by law knowing people will die as a result.
It is morally justified because we're not sacrificing a known subset of people to save another known subset of people that don't overlap - we're sacrificing a small random subset of people to save a larger random subset drawn from the same larger set, and so reducing the chance of harm to all, rather than transferring it.
This distinction is key, and would reject most "random murders" you might propose.
Which is still under the assumption that there's some orders-of-magnitude-safer-AI-driving-paradise. With seatbelts, we know how many people are saved by them vs. killed by them. With AI driving, we are merely guessing.
It doesn't need to be "some orders-of-magnitude-safer-AI-driving-paradise". If it improves on human driving by 10%, it'd still save thousands of lives a year.
This is still very generous, given that we're many orders of magnitude away from even being close to being as safe as human drivers when it comes to autonomous driving.
Coming from a crowd that is probably intimately familiar with the limitations of Google Assistant's ability to understand the English language, I feel like we're being overly optimistic here.
I don't doubt that eventually we will be able to create safe autonomous vehicles, in the same way that eventually we will be able to treat cancers much more effectively than we do today.
However, I find it odd that posters are not applying same
level of optimism to other fields, nor applying the same level of skepticism to this field that they would apply to something like cancer research. Especially given that a breakthrough in cancer treatment could effectively save tens of millions of lives annually, versus the one million lives that could be saved if we completely eliminated automotive deaths. Which, again, is a moonshot given that autonomous processes in other industries still have an annual death toll.
Unfortunately, we don't know it that it will prevent any deaths. Some people hope that it will, but there's no hard data to show that programs with more deaths progress faster. The outcome could very well be that this strategy prevents 0 deaths and cause 10.
The road to hell is paved with good intentions, and the most dangerous path is the one in which the ends justify the means. If you don't achieve the ends... then you have nothing but tragedy and sorrow.
Journal does not imply peer reviewed. The word originates from Latin and simply means "daily". I.e. a periodical publication. An academic journal can be peer reviewed but that's not always the case.
It's interesting to understand the roots of words but in this case I think the relevant information to be considered is how the word is generally understood today in the context that it is currently presented.
There are very good reasons that aluminum is the best option for a mobile phone, rather than titanium. The most important is environmental. Aluminum is more abundant than titanium, it is easier and friendlier to extract/process. It can be recycled (very important!) and it is cheaper. Aluminum also has much better technical qualities. It is much lighter weight and easier to machine. It is softer, which means the casing will absorb most of the force from an impact when you drop your phone. And as others have pointed out; your screen or battery will break long before the structural casing. I have personally never been bothered with scratches on the casing of my iPhone. I'm much more worried about the overall environmental impact of the device.
Of the 8 reasons you listed why Al is allegedly superior, 7 are reasons that it's actually the lower-grade product and the 8th (drop resistance) is simply incorrect. To a first approximation, overall acceleration doesn't kill glass or batteries, it's the uneven application of force that kills them. I'd imagine that increasing the rigidity of the frame improves drop resistance a great deal.
Are you trying to argue that being cheaper, lighter weight and recyclable makes aluminum a worse choice for a mass produced mobile device? Are you insane?
I have been required to use Vue.js in a current project (a semi complex app with lots of forms). It's the perfect way for clueless js fanboys to write unmaintainable spaghetti code. It's nothing less than a poorly designed view layer with no kind of architecture or tooling. It's naive and harmful (because of the way it is being marketed). It's a hobby project by someone that think they know what they are doing, but are really just mindlessly copying features that sound cool from real projects without understanding the underlying complexities or real world challanges. I've worked on large code bases on many different projects, both front-end and backend, with many different frameworks and architectures (including most of the popular js frameworks). Vue.js is the single most stupid and pointless "application framework" I have ever used.
World's leading Clueless JS Fanboi here: I have literally no idea how you justify anything you just said with facts. If your statements actually had any basis in reality, you should do a write up, because I'm sure this information would be useful.
Every framework enables spaghetti code, why should Vue be any different? Heck, any beginner programmer is bound to make spaghetti code.
I'm not going to go into details why Vue is awesome (see all the other comments for that.), but I don't see you bringing any valid arguments for your statements. Sounds like a new framework has been pushed down your throat, and that hurts. I get it :)
Vue.js is basically just a js object wrapping a DOM node. It's claiming to be the equivalent to a full fledged MVC framework (or similar). But it only supplies the V and completely ignores the C and M. Leaving it up to you to invent your own framework on top of it. The parts that Vue.js do supply are not well thought out (Vuex is a nightmare). The parts that do work and are nice are simply straight out copied from other frameworks like Angular. When you give an average developer Vue.js as the only tool you end up with the same kind of code you get when trying to write a complex SPA with jquery: a Single-Pile-of-shit-App.
I'm curious about where you saw claims of Vue.js being a fully fledged MVC framework. Asking because I've always thought that Vue did a decent job of being forward about exactly what it is. Just reading the first paragraph of the guide (https://vuejs.org/v2/guide/):
"The core library is focused on the view layer only"
It seems to be pretty clear that it's meant to be a simple, easy to deploy, view layer only. I think it accomplishes that purpose pretty well. There are additional libraries (Vuex, VueRouter) which extend this core library into something coming close to a full MVVM framework, but those libraries are all maintained separately and not part of the core.
I'm a senior developer and sometimes I write spaghetti code using React/Redux. I always refactor later but the point is that you can replace instances of "Vue.js" in your comment with the name of _any_ framework and it could be true.
This is very anachronistic and factually untrue. Design has only been a commercialized and institutionalized occupation for the later part of the modern era. Before then the roles were reversed. Art before then was always the heavily institutionalized and rigid practice. An artist studio during the renaissance was more akin to a factory with highly educated staff churning out stylized and "functional" artwork for church and state. This all changed in the 18th and 19th centuries when the artist became more associated with bohemian life and the mode of production and the art market changed (became more privatized and merchantilism expanded). Design and architecture on the other hand changed from something that lowly "craftsmen" and random educated people engaged in on a hobby basis into a regulated industry. This processes got crystallized with the ideals of modernism and functionalism in the early 20th century. Ideas which prevail to this day.
The comparison with Reddit was mostly referring to the community curated feed of trending stories. I'm not sure what a Reddit plugin is (I'm not a regular Reddit user myself). But I agree with you that a big part of Reddit is the web interface and we are actually working on a web app to complement the mobile experience.
The explanation for that is generally agreed on to have more to do with the aesthetics of early Christianity influencing Medieval practices, more than changes to human perception (source: I have a masters degree in Art History).