Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)LY
Posts
65
Comments
357
Joined
2 yr. ago

  • Someone in the thread mentioned that to get the benefits of micro services in a monolith, you can use a linting rule to prevent dependencies across modules

    I don't think that makes any sense. The main benefit of microservices is organizational, more specifically how a single team gets to own all aspects of developing, managing, and operating a service.

    Lower in priority, there's enabling regional deployments and improved reliability.

    How are linting rules even expected to pull that off?

  • Being against this specific proposal does not mean people are happy with the current state of things. Is it possible that this particular proposal is bad and does not address the issues? I mean, the first item of grievance is complaining about how StackOverflow curates content by removing duplicate questions and problems that cannot be reproduced, with vague complains that this is newbie-friendly. Is this a reasonable complaint? I don't think so.

  • You can’t both be a good meeting-place for experts and a good place for novices to get expert advice and an advertising venue.

    I don't agree. There is no clear cutout between what means to be an expert and a novice. What content you're exposed to is the output of the service's support for user profiling and search. It is simply not possible to get rid of an important subset of your customer base without causing false positives and generate ill-will. Finally, we should keep in mind that yesterday's novice is today's expert.

  • From the video:

    Of course there is a market for real bulldozers, but it turns out there are so many people in this world that there is also a market for miniature bulldozers. A market enough to support a company that makes nothing but miniature bulldozers. Go sit under a three and think about that one for a while. It's wild. There is a lot of people. I can't believe this thing actually exists.

    ...and proceeds to buy one, and record themselves playing with it night and day.

  • The main problem is that dynamic linking is hard.

    That is not a problem. That is a challenge for those who develop implementations, but it is hardly a problem. Doing hard things is the job description of any engineer.

    Dynamic linking does not even reliably work with C++, an “old” language with decades of tooling and experience on the matter.

    This is not true at all. Basically all major operating systems rely on dynamic linking, and all of them support C++ extensively. If I recall correctly, macOS even supports multiple types of dynamic linking. On Windows, DLLs are use extensively by system and userland applications. There are no problems other than versioning and version conflicts, and even that is a solved problem.

    You get into all kind of UB when interacting with a separate DSO, especially since there are minimal verification of the ABI compatibility when loading a dynamic library.

    This statement makes no sense at all. Undefined behavior is just behavior that the C++ standard intentionally did not imposed restrictions upon by leaving the behavior without a definition. Implementations can and do fill in the blanks.

    ABI compatibility is also a silly thing to bring up in terms of dynamic linking because it also breaks for static linking.

    So dynamic linking never really worked,

    This statement is patently and blatantly false. There was no major operating system in use, not a single one, where dynamic linking is/was not used extensively. This has been the case for decades.

  • A database carry the schema, structure, that allow you to validate that you are still having the structure you want.

    So do all file formats.

    SQLite is both a file and a database, but what I’m saying is that people shouldn’t mess with the file, but the database interface instead.

    The same holds for all file formats: don't go around licking random bits in a file, use a client instead.

    I have nothing against third party clients, the important thing is keeping the structure.

    That's what file format clients are for, and anyone can even roll out their own if they want it.

    The facts a DB use the Filesystem behind the scenes, is an implementation details the user shouldn’t be much concerned about, some DB can do without Filesystems.

    That's really besides the point. The point is that it doesn't make sense to frame using databases over files as using a higher level client over persisted data.

  • Java is the only programming language to get popular as a result of marketing.

    I don't think this is true. Java is an outstanding tech stack and was revolutionary in a lot of ways, to the point that it motivated others to shamelessly clone it and in the process create other outstanding tech stacks. See C#.

    For starters, Java solved the deployment problem way before containerization was a thing. Developers could simply put together a fat JAR, drop it in a web server like Tomcat, and it would simply reload without a hiccup.

    Java is also very tooling-friendly, and has a solid versioning policy.

  • And if you’re not using Kotlin, you’re probably using Java for Android dev.

    Java is the dominant platform for web services, and some companies including FANGs even standardized their whole infrastructure around it.

    Also, Java is basically the default programming language in some degrees.

  • In IEEE, VB is way way down the list. Do IEEE members use VB less?

    TIOBE measures social media chatter. Odds are there are far more people posting noise about VB just due to the low barrier of entry.

    Also if I recall correctly VB is heavily used to customize Excel spreadsheets, which contributes to a larger potential userbase than any programming language.

  • Keep in mind that this is for « typical IEEE members », which I am pretty sure is not a great representative sample of programmers in general.

    It's still way better than counting references in YouTube and twitter, and weirdly enough TIOBE's results are in line with this poll.

    https://www.tiobe.com/tiobe-index/

  • The amount of unqualified people is staggering beginning with those who have no university education.

    I don't see it as a problem, because qualifications without competence are meaningless.

    You should be more concerned with how qualified people end up performing worse and being less educated, knowledgeable, and prepared than unqualified people.

  • Is it not generating HTML on the server to be served to the client?

    No, it generates the code that creates the DOM, sets the application state based on the user's setting, and updates the webapp to resume working in a consistent state.

    It basically sends a frozen instance of a full blown JavaScript application.

    What you’re describing is, in my opinion, an overly complicated form of dynamically rendering HTML on the backend.

    That's because you're oblivious to the problem domain,and thus you're falling back to the unrelated but similar sounding things you're familiar with to fill in the void of your understanding of the actual problem.

    Anyway, that’s my opinion on the matter

    My point is that your opinion is a misinformed one,and really doesn't hold up to scrutiny.

  • Why not another scripting language (no compile necessary)? (...) If I could write my scripts in a nice syntax, but be sure my users will be able to use it effortlessly by distributing to them compiled versions, then that would make both of our lives easier!

    Would it make sense to describe your idea as a typescript for bash or sh?

  • I remember the first time I read about that concept and immediately thought “you mean the way we’ve been writing websites since the 90s?”

    This is a poorly informed take. Your pop's dynamic html server side rendering has nothing to do with the problem of rendering DOMs generated by JavaScript running in a browser according to the client's state and leave it in a coherent state. Trying to pass off React's SSR for the same thing that was done in the 90s is like trying to pass off an Android app as the programs written for DOS.

  • I’m not a very trusting person and work alone though so this might just be an emotional decision. But it is nice having a project be composed of code that does just what is needed and nothing else. It makes it easier to fix bugs and especially to maintain the code.

    And that's one of the reasons microservices are a thing.

  • There is a lot of doubling. Why the heck is there Dart/Flutter? Just use Javascript/TypeScript.

    This blend of comment was once targeted at TypeScript. Still is.

    The truth of the matter is that the purpose of tools is to help people achieve their goal. JavaScript is awfully broken, and many people have been investing their time to come up with solutions to fix it. TypeScript is one of the approaches, but Dart is another one. JavaScript doesn't go away because it's the de facto standard to run arbitrary code in a browser, and it carries decades of legacy code. Thus people try and try. TypeScript is now on its 5th major release, and there's still plenty of work to improve upon the mess that's JavaScript. No wonder corporations like Google invest their resources building alternatives.