5

Hair... Hehe

Comments
  • 1
    Next version of C# should accept it as an alias.

    No more pointless than some of the other shit they keep adding.
  • 2
    Kotlin:

    pubic fun hair() {
    }
  • 3
    Beards and mustaches are public pubic hair.
  • 2
    @donkulator C:

    #define pubic

    public int main()

    Not tested, but I think it's possible

    Maybe you can do
    #define pubic public in c#?
  • 1
    @retoor Don't think you can, unfortunately.

    This is why they need to add it to the language.
  • 1
    @donkulator make a transpiler. One for this, you could do provably in a half hour. It does require you to make a duplicate of all source, transpiler, and delete previous transpilatuon. I assume.

    How long is your estimation to build such thing?
  • 1
    @retoor Estimation is heresy.
  • 0
    @donkulator for business I would estimate eight hours btw. Finishing production grade transpiler on right hours is nice
  • 1
    @retoor C# has built-in support for source generators (used for xaml and protobuf among others), but to do this correctly you probably need to import the lexer from Roslyn to make sure that you only apply the transform where it's actually needed.
  • 1
    I'd say 2 days because anything that works with source code has to be tested to hell and I don't yet know whether I can run just the lexer or if I have to add a patched version of Roslyn into the repo to access a private API.
  • 2
    I still think PHP did it right

    catch (Exception $ex) {

    }
  • 0
    @lorentz isn't Rosalyn but hardcore? Something defined with #define replaces everything in source in exception of strings. Do you only have to know if pubic is not in a string. But two days would be fine too, but for myself it would be faster. I already made such thing. I made smth to put a debug line on every safe place. That actually took a few hours. Even in python that I used for it. Yh, normal person would use a debugger. I could rewrite the script to make a profiler out of it. Normally c tags code for profiling, now doing it yourself. Why not. But it became a serious c parser. I think Ive sent you the source of this terrible thing
  • 1
    @retoor Parsing and then serializing is the correct way to transform structured data like source code. You can get away with less if you can confidently say that you won't need any more features, but I spent my last half a year adding features to programs that were developed with that assumption in 2008 and have been continuously receiving new feature requests since then.
  • 0
    @lorentz if it was the task go replace pubic to public I would indeed juist write a script to do only check if it's replacing in a string, if someday more has to happen, that part won't be hard to migrate. Do, no I wouldn't implement a complete interpreter. Would not even know how to estimate that. My transpiler for adding debug lines was a few hours, but way not production quality source code. It did work on huge system source files that I catted, that's not bad. I don't know Roslyn. Maybe it's better, but it sounds like smth that will take some time to learn. Could be considered crazy to add for smth simple as the define. Doing some stringmanjpulation is fast and doesn't need 3rd party. Build server doesn't have to install Roslyn, a step that could be fragile ending up in maintenance
  • 1
    @retoor I mean, to properly check whether you're in a string you already need a decent sized parser because C# has like 4 different kinds of strings and one of them (interpolated $-strings) is a recursive grammar. And once you have that, you're assuming that new string types aren't going to be added to the language.

    besides, where did this requirement come from? Do we know that similar but separate features won't be coming soon? We probably don't.

    1/2
  • 1
    2/2

    I wanted to write a script to autogenerate fixtures for a new type of gizmo the company may sell, but I got shot down because we only need to do that like once every few years. Since then, every month we added a new type of gizmo, 4 in total. And if I had written that script in like a week, we could've also written a test suite for the gizmo type definition system.

    Doing things properly has hidden savings, probably way more of them than you realize. The only reason I'd do a shitty string replacer is for market research if we're not actually sure we need this, but even then I'd have to trust my managers to let me write it properly once the value has been asserted.
  • 0
    @lorentz the different string typed are no problem, my python c parser alsi had to know context of ( and { and /* */. It handled all. But four different ways does indeed add to estimation
  • 0
    I'm always making the bare minimal in best way possible. MVP approach
Add Comment