By "attacked" you probably meant "criticised"? Criticising something is not only a perfectly normal activity, it's a necessary one and is an important part of the scientific method.
Your statement implies that arguing is something bad. Arguing is presenting arguments that attempt to show (prove) why something is true or false. It's the most important tool (convincing each other) in the progress of civilization. If you don't try to convince each other, the only alternative, in the end, is just shoot whoever you disagree with.
And it also diminishes your value as a team member. If you can't convince others, means the reasons you present are weak and nobody would be interested in listening to you and therefore there's not much reason in having you around.
> And it also diminishes your value as a team member. If you can't convince others, means the reasons you present are weak and nobody would be interested in listening to you and therefore there's not much reason in having you around
Jeez, you extrapolated a personal observation all the way to a character assassination and firing letter paragraph.
Standups and 1on1 with you must be a blessing... a joy
If you think what I said is wrong, you're welcome to explain why. Personal attacks are neither productive nor interesting.
My reasoning is the following:
People would only listen to you if you can prove what you say is right, because nobody is interested in hearing wrong things or unexplained things, they just aren't helpful.
"We should use nodejs!" "Why?" "I don't want to argue, we just should." Is that helpful?
If you don't have the reasoning skills to convince others, you can't present constructive ideas and back them up with an explanation.
If you can't do that, literally, what is your value to the team? Blindly and quietly execute the will of other team members? That would take too much energy from those people, to direct you on every step of the way.
When you hire engineers, you expect them to give more than they take, otherwise they're a drain on the team resources.
Collective problem solving is impossible without arguing. Arguing is trying to improve something, identify mistakes, logical contradictions, basically you're doing the work of a compiler that checks your program for correctness. Would you want a compiler that always agreed with you, whatever you fed into it? Don't think so. Same thing with engineers working together to reach a common goal. You're checking and improving each other's ideas.
Edit: moreover, if you lack reasoning skills to convince others, means you lack reasoning skills themselves. How are you going to solve problems in the first place?
Presenting arguments isn’t bad if it’s about something important, but I think by “Hey, I’ve argued about shit all my life!” the GP takes issue more with the “shit” than the arguing.
Is this satire? What do you think is advanced about TS' type system and why?
Duck-typing that creates a minefield instead of providing correctness?
The unknown type that does the same?
TS is a step forward from JS, but JS's bar is so infamously low that making something better isn't a big achievement, especially compared to other languages with normal type systems.
I'm honestly curious. What other languages have a type system the would allow for this project? That is, (a subset of) SQL as a type. And assuming these languages exist, are they as ergonomic to the developer as TS while instrumenting the above?
Same thing but actually readable and maintanable would've been better implemented as a compile-time (build-time) script, basically source code generation.
Nobody said it's ergonomic to implement SQL in a type system. It was simply an answer to your question "What do you think is advanced about TS' type system and why?". It's advanced because you're able to implement SQL in types alone when with most languages you couldn't. The question on ergonomics is for the other languages where you can do this is it more or less ergonomic than this. Again that doesn't mean this IS ergonomic it's about finding a language with a powerful type system that could do it MORE ergonomically.
This thread made me read about conditional types in TS and in general more about its type system. I was ignorant. I agree now that it's advanced. Previously I only heard bad things about it without bothering to study it myself. Turns out, it's not all bad, there is some good as well. Still wouldn't want to work with it, ever; but that's beside the point.
Yes. What you don't see it that the TS language server provides things like autocomplete, definitions on hover, squiggly lines, sane error messages, etc. to the developer as they write the parsing code. What you don't see is that because that file compiles, it is guaranteed to parse (certain) "SQL" strings into types. This is because the code doesn't have to actually run to work, rather, TS's powerful type system does the parsing.
Source code generation wouldn't really provide the same end-user ergonomics and, frankly, would barely resemble the same project. How would that work? You generate source code from a SQL string and a data source? At that point you might as well just... write the actual code. The point of this package is that type information is dynamically assigned according to arbitrary "SQL" queries at compile-time[0].
Have you gone through short exercise I outlined below? Surely you can't think it would be better to manually generate type information than have it automagically available and enforced instantly as you work?
The closest thing I've seen to this is "type providers" in F#. Where, given a database connection, a "Provider" can offer compile-time contracts between your code and the schema of the database. What it does not do is provide contracts against arbitrary projections of the database (SQL queries). Of course one can write code that queries and transforms the data in a type-safe way, but these "transformations" must happen in F# for the compiler to infer any new types.
This project takes the above to a different level and infers the type of the result of an arbitrary (subset of) SQL operation before it is ever executed. It's fairly impressive.
[0] This has been pointed out more than once already, but this project does offer compile-time guarantees
What compile-time guarantees does that SQL library give? I don't see any docs or explanations at that Github repo and my TS knowledge is limited to be able to infer everything from a small code example.
Maybe clicking on the playground link would help your understanding of the project. You can literally hover over the types defined like:
type EX = Query<"some query string", db>;
and see the that the type as defined by the TS language server (i.e. in your editor) is the result of "running" the query without actually running the code. It's a little insane and somewhat akin to "type providers" in languages like F#.
For example, add this below `EX1` (line 66) in the TS Playground:
let names = (persons: EX1) => persons.map(person => person.name);
Now change the column alias in `EX1` to something other than "name" and see what happens. You see that? There is now a compile-time error.
Nope. Different domains shouldn’t share code or data. One domain may have a customer record with address info and another domain may have a customer record with past purchases.
Abstractions end up wiring things together that blur business rules.
Javascript has also evolved quite a bit and there is also TypeScript that improves on that. The language is not perfect by any means, but it gets better.
Source needed on that first claim. I've spent a decent amount of time in some developing countries and I came out with no confidence that these types of labor laws are ordinarily enforced, if they even exist. I think you grossly overestimate these protections for relatively low-skilled labor outside of the developed world.
I'm not taking the claim you replied to at face value (it's exceedingly extreme to even be plausibly true) but they at least included a "probably" to allow for some doubt.
Using any kind of management position as justification for anything tech-related won't have the effect you're probably aiming for. Dev going management is always downshifting.
