This always occurs to me. How many great ideas are out there, that our future will accept as totally normal, but are now just "crackpot" ideas being pursued by weird people. (and a shout out to all the weird people pursuing crackpot ideas: I have no idea how you handle this much rejection, but I'm glad you can).
And how many never got accepted, despite being right? How many times has Academia failed the scientific process and rejected a correct hypothesis?
That's not even the full content of the frequency cell. What you also need to know are the people who left or were dissuaded because of what they ran into. Eg the mRNA researcher made it clear she almost left; you can be guaranteed if she didn't, others did. It's not the papers that were rejected, it's the ones never written.
We still have this sort of just world narrative about science that I no longer see as warranted. Maybe it was true in the past but not anymore.
Agree completely. Unfortunately expressing any doubts about "Science" these days gets you lumped in with the deniers and anti-vaxxers. Trying to explain "no, I'm totally with the Scientific Method, it's just I don't think Academia does a good job of following it" doesn't seem to cut through that.
It may not seem obvious to everyone, but the value is taking the notes (helps learning significantly), not reading them without context after the fact.
People who are interested in learning a subject without attending lectures would be better served by a textbook in the field.
I kept my notes from college. They're pretty much useless today because there's no context.
If I had had the foresight to bring along a cassette recorder, that would have been the context. But I didn't, and neither did anyone else. Of course, there's no way I could have afforded the large number of cassette tapes, either, so the point is moot.
It's too bad all those lectures are lost to history.
It's interesting to me that no one had a cassette recorder in class. When I was working on my degree in the mid 90s nearly everyone had a recorder on their desk while they were taking notes. I didn't record every class or even every lecture, I focused mostly on the topics/lectures where I had difficulties. If I 'got it' I usually recorded over that tape.
I may even have a box of them somewhere around here in the barn.
> It's interesting to me that no one had a cassette recorder in class.
Not too surprising given that a cassette tape in the 70's cost several dollars (equivalent to maybe $20 today). It was so expensive it simply didn't occur to people to record such things.
It's like photos. The cheapest 35mm photo cost a buck an image, and this was for slides, not prints. It's why photos of my college career are nearly non-existent. And movie film - forget about it.
I'd say it depends on the lecturer and how the lecture is held. Some read it specifically for the notes to be taken. And it is assumed that students would learn from these notes afterwards, which are much more concise compared to textbooks.
My notes were usually just copying whatever the prof wrote on the blackboard while lecturing. It was usually all I could do to keep up.
But reading the notes later would cause me to recollect what was said, and so the notes were very useful. Unfortunately, enough time has passed that I've forgotten what was said, and only have the notes.
It's like watching a sitcom with the sound turned off :-/
Maybe a "Paircast[0] for lecture notes"-type application could help with this. Records audio, maybe even transcribing it (if high enough quality), while also tracking how the notes relate to the audio across the time of the lecture.
As for lectures in the past, it is a shame we may have lost them, as it seems to me (purely speculatively) that the lectures from the 70s and 80s seemed to make a whole different class of programmers to the ones of today. Or maybe it was the tinkering and not the lectures, who knows.
I teach classes of ~500 students and classes of ~100 students.
While having individual projects is very nice and it works for smaller classes, it does not scale to average students.
I have once used individual projects to grade the ~100-student class and the amount of effort it takes is unbelievable.
For example, just your number "1." point, write a project proposal, is not so easy. It takes hours to write a good proposal and several back-and-forths between instructor and student to agree on a reasonable (not too advanced/not too basic) project.
Some might enjoy a teaser video of related work by some of the same authors: https://www.youtube.com/watch?v=baKHSXeIIaI. For context, the teaser was produced due to the conference going virtual because of the pandemic.
1. Mainstream CPUs get a lot more cores, making difference between software and hardware rendering disappear.
2. More and more features of programming languages for verifiable software (e.g., Dafny or Coq) get into mainstream languages, resulting in better overall software quality.
3. Computer mathematics (e.g., in Lean) gets traction, with some high-profile mathematics breakthroughs enabled.
4. Package manager-based attacks become more common.
5. Despite higher performance computers, a new level of abstraction in the process-container-vm stack makes up for performance.
6. Similarly, mainstream OSs will still lag and take seconds to, e.g., display the contents of the C drive.
The author unfortunately has a misunderstanding of equality.
Quoting him, "The equal sign is another mathematical concept that’s often misunderstood. It means, of course, that whatever is on either side of the equal sign is equivalent." This is actually wrong.
The equals sign (=) is a shorthand for stating not that the two sides are equivalent, but that they are the same (i.e., they are equal).
If they were just equivalent, we would use another sign, like ≡ (unicode U+2261).
As expressions, sure, they are not the same. But "2 + 3 = 5" is a statement about numbers, not about expressions. When you talk about numbers (the object of study), you do not (usually) talk about arithmetic expressions. Arithmetic expressions are part of the language used to talk about numbers.
When talking about arithmetic expressions themselves, you would use a meta-language (e.g., English). The arithmetic expressions would then be called the object-language (the language being studied). All of this should be pretty clear after taking a serious course in Logic.
I am not saying the choice of words is not sensible, I'm saying it it factually wrong.
I've worked on a similar project (https://profs.info.uaic.ro/~stefan.ciobaca/lnd.html), where the interface allows only for backwards proofs. The only action allowed is to click a proof rule to be applied next, and the proof is presented in Fitch-like notation. Currently limited to propositional logic (not first-order).
I disagree strongly. It looks obvious to me that they can be equal and that this is a special case. The comparison is done only after checking for A<B, and only if a boolean called "ActiveIfEqual" is true. I mean, I don't know how much more obvious they could have made it.
It only has little chance to turn out true if they're calculated in different ways and accumulate different error. If you're e.g. dividing two pairs of integers and comparing them, regular equality is likely to be fine.
A random sampling (with some overlap of already discussed issues):
* A less verbose syntax (want examples?) and less bizarre syntax :) Clearly subjective, but IMhO Haskell is a lot cleaner
* Constructors starts with uppercase, avoiding the issue the issue related to misspelled constructors (and allowing most editors highlight the constructor)
* Type-classes allow for sane overloading of functions and operands, solving the int/float problem of SML, but extending far beyond just that.
* As he mentions: the infix operator and the export from modules are both fixed in Haskell
* Supports binary numbers (sure, it's a trivial library issue, but possible because of type classes allow extending the concept of numbers)
* The polymorphic equality is solved in Haskell, again, with type classes, allowing us to define equality to any user defined type in a way that makes sense for it (including the set example)
* List concatenation is right associative (he mentions SML's left associative @ as a problem)
* SML's overflow on + problem are solved by not having overflow (j/k, Haskell lack of overflow on integers is a serious problem IMO, but other than making Int === Integer there's no easy solution).
So you are agreeing with the author, since he is critiquing Standard ML (not Haskell). It is clear that the paper was influential, since Haskell does not have the shortcomings described.
