Given how many people think that railguns have no recoil because "there is no explosion" they might actually seriously believe what they just wrote.
Scientific illiteracy is through the roof.
Or maybe it's the same as it it's always been it's just that people that are scientifically illiterate are given platforms to speak their illiteracy as truth.
Never not UTC Everywhere.
There are markup languages for this purpose. And you store the rich text as normal text in that markup language. For the most part.
It's typically an XML or XML-like language, or bb-codes. MS Word for example uses XML to store the markup data for the rich text.
Simpler and more limited text needs tend to use markdown these days, like Lemmy, or most text fields on GitHub.
There's no need to include complex technology stacks into it!
Now the real hard part is the rendering engine for WYSIWYG. That's a nightmare.
And what does it imply?
That an AI might be better at writing documentation than the average dev, who is largely inept at writing good documentation?
Understandably, as technical writing isn't exactly a focus point or career growing thing for most devs. If it was, we would be writing much better code as well.
I've seen my peers work, they could use something like this. I'd welcome it.
Equal and opposite reaction.
There's a law for this. The matter is "pushing" against the ship, it doesn't have to push against anything else.
In fact having an atmosphere to push against actually reduces the effectiveness of thrust due to atmospheric pressure, which must be overcome. Which is why different engines are designed to run in atmosphere versus out of atmosphere.
If you throw a baseball in space you have transferred momentum to that baseball, pushing you back. You will move in the opposite direction (likely spin because you just imparted angular momentum onto yourself since you didn't throw from center of mass)
I go full chaos and look up where I last used it when I need a snippet...
If you do this enough you know how to design your solutions to be relatively flexible. At least for your backends.
Your frontend will always churn, that's the nature of the job.
Yeah but the ecosystem drags it about as far down as you can go.
Backend development for large applications relies on stability, the JS ecosystem has anything except stability.This is okay for FE development where you naturally have a lot of churn.
It's a reasonable expectation that a backend built today should be maintenance free and stable over the next 5-10 years if no more features or bugfixes are required. And is buildable, as is, anywhere in that timeframe with minimal or zero additional work.
Additionally, strong backends in the same ecosystem are similar, they use similar technologies, similar configs, similar patterns, and similar conventions. This is not the case for JS/TS backends, there is incredible churn that hurts their long term stability and the low-maintenance requirements of strong enterprise, and even more importantly small businesses backends.
Mature ecosystems provide this by default this is why C#/Java is so popular for these long-standing, massive, enterprise systems. Because they are stable, they have well established conventions, and are consistent across codebases and enterprises.
This is a perspective most devs in the ecosystem lack, given that half of all developers have < 5 years of experience and the vast majority of that is weighted into the JS ecosystem. It takes working with systems written in python, TS, JS, C#, Java....etc to gain the critical insight necessary to evaluate what is actually important in backend development.
Edit: to be clear this isn't just shitting on JavaScript because that's what people do, I work with it everyday, TS is by far my favorite language. 2/3 of my career is with JS/TS. This is recognizing actual problems that are not singularly solvable with the ecosystem that pulls down its liability for backend development. There are languages and ecosystems are much better for your back end it's not that scary to learn a new language (many of my co-workers would disagree it's not scary 😒)
Because your conservative funded news outlets have a very overt goal here.
Am I saying you are scientifically illiterate?
Based on the previous statements, yes. However, as a matter of fact, not necessarily insult.
The good news is you're following up with questions and want to learn more, instead of doubling down. With curiosity you will become more literate.
Maybe you were born with all the knowledge of the human race, but the rest of us have to learn it.
The education system in the country you are from has failed you. Assuming you are in your mid-late teens, or older, scientific topics should have already been taught in what North America would call "middle school" (11-14 years old). That teaches you things like conservation of momentum.
There is a reason why it's called illiteracy, because there is an expectation that the baseline level of education everyone in developed countries receives teaches them the fundamentals of how the world around them works. Without this fundamental understanding it's not possible to understand more complex topics that build upon it, stunting growth.
They're not on to anything here. As further stated by your comment.
This is a weird take given that the majority of projects relevant to this article are massive projects with hundreds or thousands of developers working on them, over time periods that can measure in decades.
Pretending those don't exist and imagining fantasy scenarios where all large projects are made up of small modular pieces (while conveniently making no mention to all of the new problems this raises in practice).
Replace functions replace files and rewrite modules, that's expected and healthy for any project. This article is referring to the tendency for programmers to believe that an entire project should be scrapped and rewritten from scratch. Which seems to have nothing to do with your comment...?
I do feel like C# saw C++ and said "let's do that" in a way.
One of the biggest selling points about the language is the long-term and cross repo/product/company..etc consistency. Largely the language will be very recognizable regardless of where it's written and by who it's written due to well established conventions.
More and more ways to do the same thing but in slightly different ways is nice for the sake of choices but it's also making the language less consistent and portable.
While at the same time important language features like discriminated unions are still missing. Things that other languages have started to build features for by default. C# is incredibly "clunky" in comparison to say Typescript solely from a type system perspective. The .Net ecosystem of course more than makes up for any of this difference, but it's definitely not as enjoyable to work with the language itself.
They work great when you have many teams working alongside each other within the same product.
It helps immensely with having consistent quality, structure, shared code, review practices, CI/CD....etc
The downside is that you essentially need an entire platform engineering team just to set up and maintain the monorepo, tooling, custom scripts, custom workflows....etc that support all the additional needs a monorepo and it's users have. Something that would never be a problem on a single repository like the list of pull requests maybe something that needs custom processes and workflows for in a monorepo due to the volume of changes.
(Ofc small mono repos don't require you to have a full team doing maintenance and platform engineering. But often you'll still find yourself dedicating an entire FTE worth of time towards it)
It's similar to microservices in that monorepo is a solution to scaling an organizational problem, not a solution to scaling a technology problem. It will create new problems that you have to solve that you would not have had to solve before. And that solution requires additional work to be effective and ergonomic. If those ergonomic and consistency issues aren't being solved then it will just devolve over time into a mess.
That single line of code may be using a slow abstraction, doesn't cover edge cases, has no caching of reused values, has no optimization for the common path, or any other number of issues. Thus being slower, fragile, or sometimes not even solving the problem it's meant to solve.
More often than not performance and robustness comes at a significant increase to the amount of code you have to write in high level languages... Performance optimizations especially.
A high performance parser I was involved in writing was nearly 60x the amount of code (~12k LOC) of the lowest LOC solution you could make (~200LOC), but also several orders of magnitude faster. It also covered more edge cases, and could short circuit to more optimal paths during parsing, increasing the performance for common use cases which had optimized code written just for them.
More lines of code = slower
It doesn't. This is a fundamental misunderstanding of software engineering and is flawed in almost every way. To the point of it being an armchair statement. Often this is even objectively provable...
The great thing about languages like C# is that you really don't need to "catch up". It's incredibly stable and what you know about C#8 (Really could get away with C# 6 or earlier) is more than enough to get you through the grand majority of personal and enterprise programming needs for the next 5-10 years.
New language versions are adding features, improving existing ones, and improving on the ergonomics. Not necessarily breaking or changing anything before it.
That's one of the major selling points really, stability and longevity. Without sacrificing performance, features, or innovation.
Probably not. Having actually played with making a WYSIWYG editor as a learning project markdown is too simplistic for the formatting needs of any non-trivial text editing, as a serialized storage format.
You almost always end up back with your own data structure that you serialize into something like XML for storage. Or you end up supporting HTML or non-spec compliant syntax in your markdown.
And if you care about performance, you're not actually working with XML, HTML, or Markdown in memory. You're working with a data structure that you have to serialize/deserialize from your storage format. This is where markdown becomes a bit more tedious since it's not as easy to work with in this manner, and you end up with a weird parsing layer in-between the markdown and your runtime data structures.
The commenter that's downvoted is more correct than not IMHO (Also why are we downloading discussions??). Markdown is ill suited for "most WYSIWYG needs". It tends to get augmented with XML or custom non-spec compliant syntax. The spec poorly supports layout (columns, image & media positioning, sizing...etc) and styling (font color, size, family, backgrounds...etc)
.Net + EF Core + Vue/TS + Postgres. Redis as needed, Kafka as needed.
I can get applications built extremely quickly, and their maintenance costs are incredibly low. The backends are stable, and can hang around for 5, 10+ years without issue or problems with ecosystem churn.
You can build a library of patterns and reusable code that you can bring to new projects to get them off the ground even faster.
Would recommend.
Too bad commenters are as bad as reading articles as LLMs are at handling complex scenarios. And are equally as confident with their comments.
This is a pretty level headed, calculated, approach DARPA is taking (as expected from DARPA).
.Net 8 will work on Linux just fine. But winforms will not, it's specifically a legacy windows-only UI framework.
You're going to have to jump through some incredible hoops to get it to work on Linux. Which are definitely not part of your normal curriculum.
To be fair Microsoft has been working on Garnet for something like 4+ years and have already adopted it internally to reduce infrastructure costs.
Which has been their MO for the last few years. Improve .Net baseline performance, build high performance tools on top of it, dog food them, and then release them under open source licenses.
C# on non-Windows is not impossible, but it's going to require effort infeasible for school projects like that one.
You mean winforms (The windows specific UI) on non-Windows? Otherwise this is incredibly misleading, and plain wrong.
C# in non windows is the norm, the default even, these days. I build, compile, and run, my C# applications in linux , and have been for the last 5+ years.
The designers as seen by designers is so right.
Nothing they come up with can be wrong, it's all innovative!!
This thread is a great example to why despite sharing knowledge we continually fail to write software effectively.
The person you're arguing with just doesn't get it. They have their own reality.
Yep, saw it one day before I had to have surgery, went into it and it gave me a couple day timer before it will vanish. So it timed out and I wasn't able to play around with it.
Yeah, but that's not what we're talking about here.
RTF has many more features than markdown can reasonably support, even with your personal, custom, syntaxes that no one else knows :/
I use markdown for everything, as much as possible, but in the context of creating a RTF WYSIWYG editor with non-trivial layout & styling needs it's a no go.
Great timing that Microsoft just released a drop-in replacement that's in order of magnitude faster: https://github.com/microsoft/garnet
Written in C# too, so it's incredibly easy to extend and write performant functions for.
It needs to be a bit more deployable though but they only just opened the repo, so I'll wait.
Hard agree.
Less code is not a positive metric to measure your implementation by, and is not a valid premise to justify itself. Often increasing the complexity (again, LOC is not an indicator of complexity), tanking performance, and harming the debugging experience is a common result of the mentality. Things that make software worse.
Not all one-liners are bad ofc, that's not the argument I'm making. It's about the mentality that less code is more good, where poor decisions are made on a flawed premise.
Yessss.
C#/.Net backends are the best. The long term stability, DevX, and the "it just works" nature of all the tooling makes it a great choice. It's also fast, which makes scaling for most applications a non-issue.
I've switched to postgres for DB from SQL server, have never looked back, would recommend.
Doesn't appear to show any charts on Chrome for mobile...
Seems to be a responsiveness issue, because it goes away in landscape mode, and the charts show.
Just a few hundred?
That's seems awfully short no? We're talking a couple hours of good flow state, that may not even be a full feature at that point 🤔
We have folks who can push out 600-1k loc covering multiple features/PRs in a day if they're having a great day and are working somewhere they are proficient.
Never mind important refactors that might touch a thousand or a few thousand lines that might be pushed out on a daily basis, and need relatively fast turnarounds.
Essentially half of the job of writing code is also reviewing code, it really should be thought of that way.
(No, loc is not a unit of performance measurement, but it can correlate)
Someone who shares their experiences gained from writing real world software, with introspection into the dynamics & struggles involved?
Your age (or mostly career progression, which is correlated) may actually be a reason you have no interest in this.
each line of code is a millisecond round their neck
My man here thinking performance optimizations= fewer lines of code 😂😂😂
The ecosystem is really it, C# as a language isn't the best, objectively Typescript is a much more developer friendly and globally type safe (at design time) language. It's far more versatile than C# in that regard, to the point where there is almost no comparison.
But holy hell the .Net ecosystem is light-years ahead, it's so incredibly consistent across major versions, is extremely high quality, has consistent and well considered design advancements, and is absolutely bloody fast. Tie that in with first party frameworks that cover most of all major needs, and it all works together so smoothly, at least for web dev.
I have a weird knack for reverse engineering, and reverse engineering stuff I've written 7-10 years ago is even easier!
I tend to be able to find w/e snippet I'm looking for fast enough that I can't be assed to do it right yet 😆
The follow on. Lots and LOTS of unrelated changes can be a symptom of an immature codebase/product, simply a new endeavor.
If it's a greenfield project, in order to move fast you don't want to gold plate or over predictive future. This often means you run into misc design blockers constantly. Which often necessitate refactors & improvements along the way. Depending on the team this can be broken out into the refactor, then the feature, and reviewed back-to-back. This does have it's downsides though, as the scope of the design may become obfuscated and may lead to ineffective code review.
Ofc mature codebases don't often suffer from the same issues, and most of the foundational problems are solved. And patterns have been well established.
/ramble
There is no context here though?
If this is a breaking change to a major upgrade path, like a major base UI lib change, then it might not be possible to be broken down into pieces without tripping or quadrupling the work (which likely took a few folks all month to achieve already).
I remember in a previous job migrating from Vue 1 to Vue 2. And upgrading to an entirely new UI library. It required partial code freezes, and we figured it had to be done in 1 big push. It was only 3 of us doing it while the rest of the team kept up on maintenance & feature work.
The PR was something like 38k loc, of actual UI code, excluding package/lock files. It took the team an entire dedicated week and a half to review, piece by piece. We chewet through hundreds of comments during that time. It worked out really well, everyone was happy, the timelines where even met early.
The same thing happened when migrating an asp.net .Net Framework 4.x codebase to .Net Core 3.1. we figured that bundling in major refactors during the process to get the biggest bang for our buck was the best move. It was some light like 18k loc. Which also worked out similarly well in the end .
Things like this happen, not that infrequently depending on the org, and they work out just fine as long as you have a competent and well organized team who can maintain a course for more than a few weeks.
Holy shit that's completely wrong.
It's for sure AI generated articles. Time to block softonic.
That's one of the selling points, yep
The CEO is a right wing trump worshiper.
Dig into the company's tweet history, and find archived tweets that were deleted for PR/white-washing reasons.
Long history of this stuff.