There should be a calm AI voice stating what they should be doing based on some heuristics. Based on angle of attack, engine power and the last recorded reliable speed, I feel a simple system should be able to make projection of the current speed and throw some warning when pilot input are becoming real stupid.
It exists, and it'a called the ECAM. Last recorded reliable airspeed is usually never used, because an upset condition can change it very drastically fast. These systems help resolve upsets way more often then they miss and these engineers did their homework.
Hearing is also the first sense to go when people panic; this flight had the stall warning blaring for over a minute straight and it didn't occur to the pilots that they may not be in overspeed, but stall.
(It is of course not perfect, sometimes conditions become dependent on one another and their order is not always great - see this simulated simultaneous engine fire and engine failure right after takeoff, where flying on your burning engine might be better than turning into a 1000ft glider: https://www.youtube.com/watch?v=ZRbLLO385_c)
What does this mean, concretely speaking? Do you mean you can't remember the right syntax when trying to program in it?
I know its syntax is complicated but I never felt this has caused me trouble. I guess writing a parser for it would be extremely hard, but that's another story.
I understand this coming from a newcomer but after a while it felt like second-nature to me. I was curious about parent poster, because they said they are using Ruby for years.
How does this make it confusing? What information do you feel () gives you?
You might say:
foo().bar().baz()
Ah well these are clearly method calls, they have ().
But this is Ruby:
foo.bar.baz
These are clearly method calls too, because in Ruby there’s nothing else they could possibly be. The ()s don’t actually disambiguate anything. Unlike C or Java or some other languages with some notion of bare access to internal fields, there are always and only method calls.
There's a bunch of things to pay attention to in Ruby. I wouldn't say these get too hairy, but they trip students up for very understandable reasons.
* `a ||= b` is not just `a = a || b`, but `a || a = b`
* The distinction between defaults arguments and hash arguments in functional signatures has many edge cases -- but it's much much better in Ruby 3.
* There are still 2 pieces of syntax for hashes (`{a: 1}` and `{:a => 1}`) They are the same.
* Curly bases show up a fair bit for a language that's not a braces language. :) They're in hashes, blocks, and % strings. e.g. `%w{a b c}` is the same as `%w|a b c|`. They're also used in string interpolation, e.g. `"Hello, #{name}"`.
* There are sometimes many ways to do the same thing. There's Procs, blocks, and lambdas. % strings work with many characters.
* `unless` for `if not...` and get wonky.
* Overusing "surprise if" e.g. `do_thing if other_thing` can be hard to read.
* It's so easy to monkey-patch and extend primitive classes, you might not realize when libraries do it.
All of these are features that I actually find nice to use in the right contexts. But they can pop up when you don't expect, and they can definitely make Ruby a challenge to learn. That said with a little discipline (or just a linter ;)), I find a lot of Ruby code a joy to read and write.
Yeah I don't get why you would deliberately make the flow control confusing and backwards like that. Python list comprehensions are the same. They make the information flow backwards.
This also has the effect of making nesting really confusing.
I’ve written both professionally and personally found Python makes it harder to see the early out, which makes it less valuable/explicit as a guard.
The Ruby pattern is clear up front on what it is rather than being a bag of conditions that you have to get to the end of to discover what they trigger.
It's even worse when you combine the two complaints:
do_thing unless other_thing
Which of course you find in many Ruby codebases.
Python list comprehensions seem less painful to me because they read almost like the WHERE clause in SQL simple SELECTs. Definitely not the most straightforward thing one encounters in Python though.
wow, thanks. I worked with ruby for more than 5 years, and `||=` never surprised me.
TLDR On the distinction between `a = (a || b)` and `a || (a = b)`:
* There is no difference when `a` and `b` are local variables (unless `a` is undefined, but that's an edge case)
* The distinction manifests when `a=` is a method. (It could be a `[]=` or some attr_accessor). Then `a = (a || b)` always invokes `a=`, whereas `a || (a = b)` only invokes `a=` when `a` is falsey.
In essence however, `a ||= b` respects the intuitive definition that it sets `a` to `b` if and only if `a` is falsey.
Yeah, it's not usually an issue in practice. But I do see students get confused trying things out...and it's likely because learning in an interpreter doesn't often look like "real" code does.
>Then I decided to have a look at Ruby on Rails, just to see what I could learn from the competition. I watched two fascinating movies, but they went a bit too fast to really understand what was going on, and there seemed to be a fair amount of sleight of hand in the examples (a lot of default behavior that just happens to do the right thing for the chosen demo). Again, the templating language seems a weird mixture of HTML and Ruby, and I find Ruby's syntax grating (too many sigils). I believe I heard Greg Stein say recently that if you are really good in Ruby, CSS, HTML and SQL, you can produce great websites quickly with Rails -- but if you don't, you produce lousy websites quickly (just like with PHP).
I quoted Guido's point about Ruby syntax 15 years ago in this lua-l discussion about Lua, Python, Lisp, and Ruby syntax, and the importance of not naming programming languages after naughty bits:
>[...] A little story to explain why in house languages are bad:
>Years ago I worked for a company that had an in-house language (90-94) called Lull. [...]
>(*) Come be real, who uses Lisp for commercial projects? Great language, but too many parens and no one uses it. Its the equivalent of Esperanto. So much promise, so little delivery. [...]
>Don Hopkins 15 years ago
>I read your message about "Lull" and a Dutch guy sitting behind me
laughed out loud when I said the name of your language. (My dictionary
says "lul" means "prick" or "cock" in slang, so it's a bit more explicit
than "dick"!) This just goes to prove that how you name a language is
important (but not as important as designing the language so it doesn't
suck...)!
>On the "too many parens" excuse for disliking Lisp: so why do you use
XML and HTML? They have TWICE the number of parens, which are pointy
instead of rounded, but lots of people seem to use them anyway. So "too
many parens" is just a convenient and shallow excuse for disliking Lisp
that avoids examining the real issue.
>The real problem that many people have with Lisp is because it's
perceived as a homosexual programming language, which causes unconscious
cognitive dissonance, so people have to grasp for more socially
acceptable reasons for disliking the language (like "too many parens").
Nobody wants to just say "I hate Lisp because it sounds gay", so instead
they say "too many parens", even though most other languages suffer from
too few parens, and are much less readable than Lisp because of their
insane hierarchies of precedence rules. Programming tips 101: ALWAYS use
parens even if you're sure the precedence rules will make your
expression do what you want, because 1) other people need to be able to
read the code and 2) you may be wrong. Drop any copy of K&R on the table
so it lands on the spine and opens to a commonly used page, and I bet it
opens on the table of precedence rules, because that's the page everyone
always turns to. Lisp code never suffers from this problem.
>The first thing most typical homophobic Americans think of when they
hear the word Lisp is the gay stereotype of speaking with a lisp, so it
unconsciously terrifies them. And the fact that "lambda" signifies unity
under oppression, and is used as the gay/lesbian/bisexual/transgendered
symbol only reinforces that impression:
http://en.wikipedia.org/wiki/LGBT_symbol#Lambda ...And then there's the
purple cover of Structure and Interpretation of Computer Programs, with
the two gay dudes on the cover.
>Anyway, millions of people program in Lisp every day with C syntax, but
they just call it JavaScript, and suffer without macros, because of the
inferior C syntax.
>-Don
>Fabien 15 years ago
>@Don: your theory is fine for US people, but lack of love for Lisp is also
observed in non-English speaking places. I learned quite recently that the
word "lisp" also had another meaning than "nail clippings in oatmeal".
>My guess would rather be that Lisp doesn't encourage common idioms and
development approaches across people and teams, which makes it hard to:
>- get into code you didn't develop
>- work with more than a couple of teammates
>- find a library that addresses your problem
>- if you have several problems and find a lib to address each of them, get
those libs to work together despite their incompatible macro hacks.
>That, and Lisp took waaaay too long to acknowledge its platforms. It
pretended to be OS independent, which meant many non-standard,
non-compatible ways to interface with OSes, and therefore, plenty of
platform issues as soon as you wanted to port or deploy a non-trivial
solution. As written somewhere by Paul Graham, "Unix has won, get used to
it".
>Don Hopkins 15 years ago
>Now that's some spot-on criticism of Lisp, much better than the "too
many parenthesis" excuse that gets thrown around by linguistic
homophobes suffering from cognitive dissonance.
>I'm still waiting to hear somebody claim that they refuse to use XML and
HTML because they have too many parenthesis (angled brackets).
Or for somebody who hates Lisp's parenthesis but tolerates XML and HTML
to explain why <foo>bar</foo> is easier to read than (foo bar).
>Perl and C++ have way too much punctuation in general, and Ruby made a
cargo cult design mistake in imitating Perl syntax.
I agree with Guido van Rossum's comment on Ruby: "I find Ruby's syntax
grating (too many sigils)".
http://www.artima.com/forums/flat.jsp?forum=106&thread=14614...
>Wow, in what language does lisp mean nail clippings in oatmeal, and
where can I get some of that stuff? It sounds delicious!
>"Using these toolkits is like trying to make a bookshelf out of mashed
potatoes." -- Jamie Zawinski, on X-Windows toolkits.
The problem with lisp is `lack` of sigils to give one enough sense of flow.
Moving the ( to the left of the function name somehow feels as disconcerting as gazing upon an non-trivial Haskell function and trying to map the type signature line to the function definition directly following.
Confusion is the mother of "Back to python, where I can knock this out."
To my eyes, sigils create turbulence, not flow. And they don't have obvious well defined standard meanings, and aren't self documenting or easy to look up in a manual or dictionary.
Who can even remember how ASCII punctuation should be "alphabetized" in an index, let alone Unicode?
However the pure parens of Lisp code look like concentric ripples on still water, instead of the raging rapids of pathologically punctuated Perl code.
Jack Kerouac and William Shakespeare and Hunter S. Thompson all managed to write beautiful laminar flowing text with words, without resorting to sputtering splashes and eddies of excessive punctuation.
Would you really want to read and maintain somebody else's quirky code written in a programming language designed by e e cummings?
The most difficult and important part of programming is choosing the right words and names, to help the reader understand your meaning and intention.
But there are only a few punctuation characters, unless you resort to inscrutable C++ digraphs, trigraphs, unicode, ambiguous smilies ;), and emojis. (Is that punctuation after the smilie a drool, or an Oxford comma?)
Do you really believe peppering your code with punctuation and emojis instead of using meaningful evocative words makes it "flow" better?
He was making an April Fools joke, but Bjorn Stroustrup's proposal for Generalizing Overloading for C++2000 would have actually improved the language's flow!
My friend and brilliant Lisp hacker Ken Kahn (who teaches kids AI programming with the Snap! visual programming language) was just inspired to explore these stylistic visualizations of Lisp programs with Dall-E:
> Who can even remember how ASCII punctuation should be "alphabetized" in an index, let alone Unicode?
Ideally, the entries should mostly be one character long, at most two, and appear i a dedicated non-alphanumeric index section that runs for no more than half a page.
What I really like about GraphQL is that it completely get rides of the silly verb questions such as
- POST or PUT or PATCH?
- Why can't my GET or DELETE requests have a JSON body?
It is just a better interface, even if it where to be used exactly as REST without any nesting. I used the Appollo server in NodeJS and it was so natural to make parallel queries and let the query planner take care of the parallelism for me...
If you don't like the verbs you can always just use POST for everything...
My experience with GraphQL was a pain. We could have reduced queries if we changed our front end dev patterns, but we didn't and had the same number of queries as a REST pattern would have provided. Our GraphQL backend was a cobbled together mess of microservices that struggled with performance and stability. Queries could fail and we often wouldn't know why and bugs persisted for months despite work on them. We couldn't do simple things like cache queries to be reused between application launches without backflips and juggling expertise, Apollo client and all... And on and on and on.
Granted, not the best engineering shop. But in poor shops I find REST is simpler and thus less broken in practice.
Love Django. But we are using Django with Gunicorn at work and we are having massive concurrency issues (1 process, gthread)... More than 4 concurrent requests waiting on a slow IO and the whole thing melts down...
This is definitely something about your local setup or config. We routinely run hundreds and thousands of simultaneous connections through various versions of Django without much trouble.
