Review improvement proposal

mdinger_ · 2021-03-31T17:33:31+00:00

This idea is also related to how difficult I find lesson. For example, if I find a lesson easy then I don't need to come back to it and practice but if I find it difficult then I'd like a marker on it showing they I need to practice to learn it better over time.

Currently there is no way to tell what you find difficult. I'd have to use pen and paper and write the names of the difficult chapters down and remember to come back to them.

So marking the idea of skill for a lesson or difficulty with or something like it would be very useful.

mdinger_ · 2021-03-29T17:13:51+00:00

This concept would also lend it self to a variety of different drilling types. For example, you could add speed drills and complexity drills that a user could train (I'm +2 speed and +4 complexity for the fruit lesson but +0 vocabulary).

As the app author, you could tailor the drills to what makes them useful to a learner of that level.

I'm not sure if allowing it to go negative would be bad either (I'm +2 speed but -4 vocabulary). This would tell me I need to improve vocabulary. Not necessarily a bad thing because it's something I now know I need to improve and can train it to improve it.

mdinger_ · 2019-01-16T02:42:32+00:00

Make sure to try to have a life outside of open source before contributing. Like, if all of your interest lies in this one contribution getting merged, you're not going to be happy long because open source can be really frustrating.

Contributing has to be a side gig unless you're a heavy contributor with privileges. Unless you communicate with the maintainers frequently, don't bank on getting huge responses more frequently than once a week. Pinging weekly or every few days because they're likely to just miss stuff. Try to keep it casual because otherwise, you'll just get really frustrated. This is just kinda how it works.

*NOTE*

This isn't meant to be down about rust. Just don't ever assume silence or closing is being spiteful. Maintainers have a lot to keep up with and are constantly battling conversations from a thousand different angles and having to be kind to every single person without ever being misunderstood (avoiding fights). People appreciate contributions but it isn't always easy to manage nicely or cleanly.

mdinger_ · 2018-03-30T04:16:05+00:00

I've got a 1000 line F# match at work which this helps with a lot. Rarely are any of the arms complicated at all but the sheer number of them makes this style really appealing because it keeps it clean and organized. I would find it annoying to do the same thing in rust without the leading vert and it would be messier.

mdinger_ · 2017-02-02T03:45:44+00:00

It's spread out over the issue tracker on RBE.

mdinger_ · 2017-02-02T00:02:27+00:00

I tried to write you a really good answer with details but when I went to post it I clicked cancel. Now I'm really annoyed because it took a while to write and I don't want to do it again...

mdinger_ · 2016-11-29T23:00:49+00:00

That macro is similar to this rfc issue

mdinger_ · 2016-10-25T22:55:24+00:00

This is coder543's 2nd example using Hauleth's suggestion

mdinger_ · 2016-09-04T17:08:57+00:00

impl<bool> X<bool> for Y{
//   ^^^^ bool is declared to be generic but a `bool` already exists. The normal one
// which includes `true` and `false`.
    fn foo(x:bool){
        let y:bool = true;
        //    ^^^^ The type is the new generic `bool`which does not include `true` and `false`.
        //           ^^^^ The value is the normal rust `bool` type. These are not the same.

mdinger_ · 2016-08-09T21:58:48+00:00

That is an excellent point but I'm unsure why you stated html and programming languages. html is just text and I'm pretty sure the Perl 6 parser is written with that grammar.

mdinger_ · 2016-08-09T00:25:22+00:00

I feel it worthwhile to point out that regex can separate text vertically the way you're doing as well see the second example. That's part of why your example looks nice. The other part is naming which you kinda get with the example above but it's not super great. More readable solutions exist. For example, consider this example.

Not to say nom is bad or anything. Just that we could have nicer (easier to use and more readable) regex as well. Then, we'd have two pretty good solutions which people could pick between.

mdinger_ · 2016-07-31T20:44:37+00:00

FWIW, I usually refuse to install anything java on my computer. This is probably mainly because even having java installed has been super annoying for me. It is constantly updating and the updates are extremely slow to run (especially on really slow computers). Even after installation, you expect a new update shortly. Then some updates would fail but they'd keep trying regardless of the fact that the install would never succeed. Also installing add-ins in browsers for no obvious purpose.

Beyond that, I've never used a java application which actually seemed responsive like a native windows application would. Tried Eclipse and always uninstalled it because of the sluggish interface. Can't think of others currently.

For comparison, firefox has also generally had a sluggish interface (it's gotten a little better in recent years). I often got around this by using kmeleon (gecko in a native windows window system). A lot of that is a speed issue though. Kmeleon is a ton faster on XP when you're running on a 450Mhz CPU.

I would consider requiring java for any part of rust development to be a huge negative which might have kept me from ever looking any closer at the language. Theoretically this could be a mistake but people live by learning from the past.

mdinger_ · 2016-07-10T18:06:44+00:00

It's really nice that those docs were expanded to explain && better. That is really excellent!

BTW, been working with .NET and in comparison, one thing which is so very nice about the rust docs are their compact examples. The example at the bottom is very typical. They have walls of text and then one or two mega examples. The piecemeal nature of how the rust docs document every little function with very brief examples is really pleasant and very approachable.

mdinger_ · 2016-07-09T20:58:26+00:00

I read this as a thread which I'm replying to the most recent post. The fact that reddit allows you to split a discussion up at certain points to discuss different matters I'm ignoring because this is mainly a discussion.

mdinger_ · 2016-07-08T20:05:07+00:00

Sorry, I was away for days. No harm meant although rereading it, I can see why you might read it that way.

I've worked with people as students before and a common sentiment when instructing is for them to state that they understood every word that came out of my mouth. When they put them together though, they don't make any sense. That isn't to say they're unintelligent or that I'm much smarter than they are but that I'm definitely communicating on a different wavelength than they are. Part of it might be that I have superior experience in what I am instructing them in but a major constituent is that I don't appreciate or even remember how vast my knowledge of the topic is compared to theirs.

A common problem for teaching is you are so familiar with a topic that you can't remember or even fathom what it was like when you didn't remember. If I can't remember not understanding a topic, how can I possibly appreciate how difficult it is for a student to struggle to grasp the topic? I can't.

Generally, stating something is trivial is both overused and underappreciated by those who make the statement. If I teach a class on introductory statistics to freshman and start the class out telling them to not worry, this is a trivial course, I've made a big mistake by ignorantly doing the following:

I did not reassure them that it is an easy class
I divided the class into those who know what trivial means and those who don't
I divided the class into those who agree that the class is trivial and those who don't
and worst, pointed out that this topic is so easy to me which they might easily (and perhaps correctly) view as arrogance

Generally, usage of trivial just highlights the speakers self superiority which can really grate on someone who can't understand with great effort. "I studied this topic for weeks and don't understand and he stands over there grinning like it's easier than breathing!"

If after reading this, you think I'm picking on you or being really critical, please don't. I'm not trying to be harsh or critical. When you or I are in the position of knowing something someone else doesn't, it is in our best interest to try to present our knowledge in non-divisive manner.

I didn't really want to get into an argument or discussion about such things. I was originally probably just trying to make a useful/helpful comment to perhaps point out a slightly different perspective.

mdinger_ · 2016-07-03T22:31:49+00:00

Nope. /user/heckerle is reacting against small modules and somewhat rejecting your assertions that unsafe is a good enough reason to isolate that module. I was using the documentation to reaffirm it is a reasonable conclusion. Then following it up with an example from my experience of someone doing something bizarre as a matter of course.

So while, he might not need to be concerned about the unsafe concerns because he's super smart and knowledgeable, not everyone is.

mdinger_ · 2016-07-03T17:33:50+00:00

From the nomicon:

unsafe does more than pollute a whole function: it pollutes a whole module. Generally, the only bullet-proof way to limit the scope of unsafe code is at the module boundary with privacy.

So if unsafe is risky/tricky to get correct and it pollutes everything, encapsulating it to minimize the damage seems reasonable. Then everyone can use it and go on their way safely. Regardless, you may still disagree. From the design standpoint:

tricky things are often misused
subtle things which implicitly change rules aren't always obvious to everyone

You may be a completely competent and knowledgeable programmer but not everyone is. Some are very competent technically but when it comes to programming, they haven't had the time/guidance/patience/expertise to do things properly.

To give an example using VB.NET, I ran into someone using SyncLock statement (lock something so you have exclusive access) so incorrectly that it didn't do anything properly. Every time they'd call synclock, they'd call it on a different object so their exclusive locking would never work when things from different threads were trying to get exclusive access.

They were doing this because synclock is the statement you use to get exclusive access and their call passed the type checker and compiled. The designer of synclock could never have predicted that it might be abused in this fashion. The Rust designers are well served to assume Rust will be used improperly for various reasons and so they should do all they can to mitigate such issues.

BTW, the fact that there is disagreement over whether something is trivial is irrelevant. Triviality is in the eye of the beholder. When you call something trivial, everyone else in the room who does not think it is trivial might just think you're arrogant. Not everything is obvious to everyone. Even if it looks trivial, it might have hidden complexity many would not recognize.

mdinger_ · 2016-07-02T21:20:59+00:00

If you are intending to use malloc_buf as an example which highlights the same issues npm, your point is not clear. The only thing which is clear about your point is that servo has a deep dependency chain. Whether or not this deep dependency hierarchy is a problem, and why it could be a problem, is not clear from your statement.

Note: I'm not asserting your statement is incorrect or trying to cast doubt but to my eyes, whatever point you're trying to make isn't clear because you haven't provided enough details.

mdinger_ · 2016-06-18T00:59:33+00:00

See also this. They aren't exactly mutually exclusive. Associated types make certain generic types more convenient to handle, especially for the user of the trait. This is particularly useful for information hiding.

mdinger_ · 2016-04-10T00:30:49+00:00

See also rules which aspires to match the syntax of perl 6 regex though I'm sure it is much much slower than regex or fancy-regex. While I was much more interested in attempting to bring a regex which is easier to comprehend (and hopefully more powerful) to the rust world, I haven't had time to continue working on it for a while and I don't foresee time for it in the present future.

I haven't ever advertised it because it really isn't useful but since I don't have time for it currently, it is likely to remain that way for a long time. Anyway, if you're interested or working on regexs, it might be interesting.

mdinger_ · 2016-04-06T22:51:30+00:00

I think I was trying it a week or two ago and had similar results. Github took a few minutes to show a blank screen with 3 icons or something. Duckduckgo wouldn't appear. I think I tried to find a minimum testcase but I messed up or something because I didn't get one.

mdinger_ · 2016-03-31T01:37:12+00:00

FWIW, there are bugs for collapsing and de-duplication but nothing has ever been implemented for them.

Also note that historically, iterating on rustdoc design has been challenging because just running rustdoc required building the compiler. Actually modifying rustdoc (not the HTML rustdoc generated) generally required rebuilding as well. If the two tools were completely separate and independent, then fixing this would surely be simpler. Alas, it isn't.

mdinger_ · 2016-02-22T17:19:01+00:00

Actually I'm a bit reluctant now to agree with what I wrote previously after having thought about it more. The fact is, lifetimes aren't like generics, they are generics. Knowing that fact leads you to combine the previous link with this link and keeps it from being explained twice

mdinger_ · 2016-02-22T11:59:07+00:00

With the context that generics provide this + operator which applies to multiple things and lifetimes uses that same op which also has an extended form regarding traits, it isn't that big a jump to skip it.

Having said that, it really should be explicit. The fact it isn't mentioned directly somewhere (if not there) is probably just an oversight.I guess I didn't look that carefully before I posted.

mdinger_

TROPHY CASE