Hacker Newsnew | past | comments | ask | show | jobs | submit | more dmux's commentslogin

>Disclaimer: This library is not related to the MISRA C standard or guidelines. The name "MisraStdC" comes from the author's name, Siddharth Mishra, who is commonly known as "Misra" among friends.

Why include the letters Std then? This seems like a purposeful typo-squatting effort and definitely makes me suspicious.


Wow! Thanks for pointing that out, so misleading…


yep, glad you pointed that out. To explain a bit more : MisraStdC is 3 parts : Misra + Std + C - Misra is derived from my name. That's why I needed to specify that the repo is not related to the MISRA standard.


How does MisraStdC = Siddharth Mishra?

Misra and not Mishra? You randomly drop the h? And it just so happens dropping the H makes it a typo squat basically.

Siddharth has a T after the D. So std should be sdt.. at best.

Just be honest lol


Std is short for standard :-) It's pretty std.


That doesn't explain the worst part though. Why drop a random H?


You do understand people's concern here though right?

Because it seems like you're being purposefully obtuse at this point.


Thanks for the clarification but it makes zero sense


because it's my personal standard. I use it more than I use standard C utils.


Did you really take the name mishra and make it into misra.h then call your library MisraStdC and expect people to believe the confusion isn't intentional? This whole thing feels incredibly dishonest.


Ok I'm saying this for the last time so I'll over-explain so everyone can follow the idea properly.

Not all people can pronounce names correctly. In a language some names are easier to pronounce if you take away a few letters. Some may find using Sid as short form for Siddharth, because it's just easier.

Now from my childhood, some friends used to pronounce my name differently. I noticed that they don't use the 'h' in Mishra, so I started using 'Misra' instead. They found it easier to pronounce and I felt connected more. Those who could pronounce it correctly, still used Misra because it's just easier and sounds more personal. Friends and loved ones do that. It's also sometimes called as a nickname, where you give other names to a loved one.

Now, it also just happens that my native language has the same root word for Misra and Mishra aaaand they mean the same! It essentially means a mixture of different things.

Now even if all this this reason does not sound good to you, just ignore it. It is my project, my name. I can pronounce however I want, with whatever spelling I want. A project is named by it's maintainer. I can name it exactly MISRA and still be happy with it because it's my project, I'm the maintainer.

I did mention that this is not related to the MISRA standard because I felt like users should know and not confuse it with my library.

I tried to ignore this matter but people over internet just keep poking you saying you're dishonest. Please don't bother yourself with the name of things, just use it if you need it otherwise ignore it. It's an advice for life. Name of things does not matter, it's what they do and achieve. I've put honest work into this library and I won't accept someone sitting behind a screen just say that I'm dishonest, I'm purposefully choosing this name. It is my name, I chose it, names clash in this world at least. Two entities can have same name but of different origin and use case.

Thanks for reading this if you read it till here.


I tried to ignore this matter but people over internet just keep poking

Did you really think naming something MisraStdC, then posting it to the internet, then rationalizing it wouldn't be noticed?

It's not even your name or a standard.

It really looks like you are trying to name it something that people would find from searches then somehow walk it back and come with a story after.


While I do think there might be some squatting here, I have to defend that dropping the h is also a common spelling of that name.


A large part of flightaware.com’s systems were written in TCL.


I think this is the first time I've seen a github badge (with number of stars) that's for the website itself and not the language repo!


I've heard this referred to as "primitive obsession." You can find a lot of writing that covers the pros and cons.


>If you wanted a scream you could just make one yourself.

I would personally find it really difficult to produce a scream that replicated the sound of abject terror produced by the whistle.


Maybe if you tried out of the blue, but if there was a cultural incentive to practice you could probably learn to do it fairly easily.


This sound seems easier to produce with an instrument than with training. It's like a half-human, half-beast, raspy, very loud AAAAAAAAAH! Takes much less training to use the whistle properly than to imitate a signature scream perfectly.


My abject terror scream is a last chance for comedy.


This article strengthens my belief that butterflies are some of the most metal animals out there. Flying around at 25mph? Metal. Drinking tears? Metal. Electrostatically charged?! Metal.


You can add to the list the colors of their wings, rendered by a complex nanostructure that is triply periodic [1].

[1]: https://math.ucr.edu/home/baez/butterfly.html


>In terms of convention over configuration, Ruby's metaprogramming is crucial for the name-based class conventions that make Rails so convenient. For instance, if you have a class User with the attribute name, at runtime Rails dynamically adds methods to the User class, allowing you to do things like User.find_by_name("Alice"). Rails uses Ruby's metaprogramming capabilities to accomplish this.

This can be accomplished in statically typed languages too. For example, Java has an ORM called Cayenne that generates models based on database tables. You can get similar functionality and ensure you're not accidentally calling something like `find_by_nam`


ActiveRecord doesn't generate models based on database tables, it uses conventions on table and attribute names along with Ruby's metaprogramming capabilities to define behaviour on models automatically. From my understanding, Cayenne requires manual mapping of the database to your models, which is done via XML files that are either handwritten or generated by their GUI application and have to be regenerated on every database change. That's a far cry from the ease of use of ActiveRecord. How you value that ease of use versus your desire for static typing is up to you, but they’re not comparable from a functionality point of view.

And like I said above while you might be able to recreate some of Rails' functionality in other languages, you wouldn't be able to replicate all of it with the same fluidity and readability that you have in Rails


    def log_then_get(url, context)
      puts "Requesting #{url}..."
      get(url, context)
    end
 
    def get(uri, context)
      response = Net::HTTP.get(uri)
      puts caller(0).join("\n")
      response
    end
 
    def get_http_thread(url)
      Thread.new do
        log_then_get(URI(url), Thread.current)
      end
    end

Good example of the downsides of dynamic typing:

1) get_http_thread takes a url (String) and converts it to a URI object

2) log_then_get defines its parameter as `url`, but really its expecting a URI object

3) get defines its parameter as `uri`, but we're passing it an argument called `url` from within log_then_get.

Lots of traps readily awaiting an unsuspecting programmer or newcomer to a project that contains code like this.


If you've ever sailed, a more apt analogy would be heeling over extensively (and potentially capsizing) due to a gale. You could be sailing along just fine and then all of a sudden you're overpowered. A sail, after all (at least when sailing towards the wind) acts just like a wing of a plane.


>The Boeing 707 jetliner involved disintegrated mid-air

I'm guessing their use of "disintegrated" there is supposed to be taken literally as dis-integrated, but upon first read, I took it for its more colloquial meaning (which to me is closer to pulverized, turn to dust, dissolve etc).


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: