While I like echarts I have found it somewhat challenging to extend their functionality.
I wanted a Gantt chart and while I did achieve what I wanted it wasn't without having to delve into the their source and putting log statements everywhere.
I happen to be using ant design and I've had the same issues there.
Its a bit all over the place and the translations are not great, but i will stick with it.
Also using Ant Design with eCharts. Having to funnel the designers to not use gradients for all the charts has been fun. While eCharts supports _some_ gradients, it's been a PITA for certain chart types.
I also made the mistake of using Ant Design Pro Forms since I wanted to use the StepForm Wizard component. All of the tsdocs are in Chinese and it's barely documented for more than their example use cases :'}
Some parts of the api are a bit confusing especially with more recent version upgrades but I still have found it to be the most powerful open source library that’s not D3.
I'll give you natives, but men, whites, Asians, and non-socialists can be found in abundance, existing freely and flourishing on any college campus in America.
It requires the same amount of labour from my part but it delivers the same outcome every time.
That is what tools do, they act as an extension and allow you to do things not easily done otherwise.
If the hammer sometimes hammers, sometimes squeaks and sometimes screws then it requires extra labour from my part just to make it do what purpose specific tools do, and that is where frustrations arise.
This is the kind of non-serious argument he's talking about. There are plenty of tools that require supervision to get good results. That doesn't make them useless.
My 3D printer sometimes prints and sometimes makes spaghetti. Still useful.
They never said it was useless. You just invented that straw man in your head.
3D printing is largely used for prototyping where its lossy output is fine. But using it for production use cases requires fine tuning it can be 99.9% reliable. Unfortunately we can't do that for LLMs hence why it's still only suitable for prototyping.
But you can adjust the output of a LLM and still come out ahead in both time and mental effort than writing it by hand. Unlike a 3D printer, it doesn't have to be right the first time around to still be useful.
You don't use 3D printing to do large-scale production. If you agree that AI should only be used in prototype code and nothing else, then your argument makes sense.
Off the top of my head apartheid in South Africa, ethnic cleansing of Albanians and genocide in Serbia, WWII... maybe indirectly, end of oppressive horrible USSR where I was born
I'm not sure where "here" is and who you think you speak for, but as a European, I am strictly against regulation, in particular vague regulation made by non-elected EU bureaucrats. And no, freedom of speech and a discussion about the pros and cons is also not "unacceptable". It is part of the democratic process.
The AI act was voted by very-much-elected members of the EU parliament, in 2023, with a large consensus: 523 votes for, 46 against, 49 abstentions. [1]
You seem to very strict about the kind of political discourse that you would allow.
And I'm going to even elaborate on how problematic is your "net positive or society" and who would possibly be in charge of determining that.
I, too, find tools hard to use after I intentionally break them.
It's unfortunate that Typescript even provides this casting hack, though it's necessary for gradual, optional typing. The very first thing I would do on such a project is spend the time to fix those broken types, because it will pay back in full in productivity after a short time.
if you abuse the type system enough, most languages will have weaker typing.
"the language" is not enough per se, you have to use the tools it gives you to gain some advantage: those projects were clearly actively avoiding strong typing, for whatever reason
I think this comment doesn't add to the discussion.
It's like saying you can kill yourself in any vehicle.
Might be true (or maybe not), but doesn't add to the discussion of vehicle safety.
One might equally say that the embracing of reflection in Java and C# pretty much solidifies the case against static typing for complicated projects.
I'd tend to think the important feature here is strong typing, not static typing, and indeed TypeScript, which is hampered by the anemic type system of its parent JavaScript, it not the best example of strong typing.
Ultimately, strong typing is a hill I'm willing to die on, too. But a lot of people making arguments on this topic are conflating it with static typing, which just isn't the same thing. In general, that gives me the impression you haven't done enough work in enough different languages to really have an informed opinion. The type systems of different languages work within the context of the language as a whole, with tools like REPLs, test frameworks, constraint checkers, static analyzers, and IDEs carrying a lot of the work that might be attributed to a type system. There are a lot of confounding factors here, and if you're only talking about a few languages and you are making mistakes like conflating static=strong and dynamic=weak, you don't have the breadth of experience to understand what the benefits and downsides of strong types are.
Though uncommon, strong dynamic type systems do exist. Scheme is probably the most popular example, although its type system isn't the strongest. This is the approach I'm taking with Fur[1], which attempts to have as strong a type system as possible while still being dynamic. Python is... stronger than many other popular languages (i.e. JavaScript), but still does a lot of coercion (particularly around truth-y/false-y values--duck typing is a bit of a grey area in that it's sort of arguably weak typing, but also arguably indicates a capable type system rather than a weak type system).
But perhaps more critically, weak static type systems also exist, such as C, which is the source of many of the world's most serious bugs. It's highly unwise to assume that static typing is strong typing.
> We have projects in java7 still which span thousands of LoC and juniors can just jump in using their IDE and make some sort of contribution.
This seems to be a main reason certain people like it. It gives a sense of productivity. However I think it is misguided. It’s a false sense of productivity. Can they commit? Maybe, yes. Will it be right? Maybe, and more likely with types to handhold. But does it mean they understand the data model and the domain of the codebase they’re working in? No. No typing forces you to know what your code is actually doing.
It takes longer to be productive, but you’ll be productive because you know what you’re doing. Not because the IDE held your hand.
Widget factories or scrum farms will no doubt like the “ease” of jumping into a codebase that has typing, but I’m not yet convinced it’s better or that much better for the experience developer. I need to think on it more. For certain though I’ve seen enough in my time to know that how quickly a junior can “just jump in and make some sort of contribution” is not a good measurement.
Your argument sounds like a language should make it hard to understand parts of a codebase without understanding the underlying parts as well.
I would argue this goes against the goal of abstracting problems to keep complexity manageable.
Of course abstractions can be misunderstood and misused, but is that an argument for not having them?
"Truly understanding what goes on" and "static typing" are in no way correlated, let alone causations.
You are making a false dichotomy.
It's perfectly possible to work in a dynamic codebase without understanding the domain, business, logic or big picture. And it's just as perfectly possible to build a statically typed codebase that forces you to understand the whole entirety before being able to make a change.
Now, whether it's actuallygood to enforce true understanding of the Whole, before being able to work on a subset, is another debate. One that, unsurprisingly, has long been proven to be false. It's why we consider modules, functions, boundaries, coupling, classes, microservices, layers, and so fort and so on.
Nope. A new dev will need a lot longer to understand a large python codebase than a java one.
In fact, if all the developers change, it's a virtual certainty that none will ever understand the python code, while the odds are about even for java.
(But then, the types aren't the only factor for that.)
reply