8 ms·

I don't know whose brilliant idea it was to turn TypeScript's type system into a Turing-complete language but now many developers are actually using it as such

I don't know whose brilliant idea it was to turn TypeScript's type system into a Turing-complete language but now many developers are actually using it as such on real projects and it's a massive productivity drain and it makes some code impossible to read... Often, the IDE can't even display the type when you hover over the variable because it's too darn complicated. Did anyone ever think "Hang on, maybe the problem, the reason why coding is so difficult is that interfaces are often too darn complicated to keep track of? Oh, wait a minute, if the interfaces were really simple, would we even need TypeScript at all? Why don't we just design our software in such a way that the interfaces between components are simple so that we can easily remember which functions accept what kinds of input without losing our train of thought? Wait a minute, this idea already exists? It's called loose coupling and high cohesion. How in Alan Kay's name did I not think of it before???"

sk0g 3y ago
If the Typescript team got carte blanche to create their own language, it would likely be... C#. TS is complicated and chaotic because the language it compiles down to is. TS' aim is to model the behaviour seen in JS in a flexible, user-friendly type system. Good luck! What doesn't make sense to me is when teams (like mine) have a blank slate and the choice of any mainstream backend language, and then opt in to that ecosystem anyway. TS is good when you're coming from JS sure, but some of us have used more "sane" languages like C# and Go :(
- deleted 3y ago
  [deleted]
- seedboot 3y ago
  > If the Typescript team got carte blanche to create their own language, it would likely be... C#. This is sarcasm, right? The creator of TS is the lead architect of C#
  - dnadler 3y ago
    I feel like that’s supporting the parent, right?
    - chrisco255 3y ago
      Not really, because it's not a question of if TS creators got to make their own language.
  - sk0g 3y ago
    And C# iterates at a rapid pace, with lots of language features being added, some of which would would not be possible in TS. C# is in some ways less shackled by the runtime it has to target, while TS compiles away entirely. The CLR can be changed to suit .net/C# needs, and JS is not under their control.
- edem 3y ago
  I come from a Java / Kotlin background and TS is totally fine.
  - sk0g 3y ago
    Some quirks I've noticed are typed objects not performing any validations, like for building DTOs. Structural typing so the newtype pattern is not possible without some awkward hacks. A general "disconnect" between compile time and run time behaviour, so once you start casting your errors are relegated to property access/usage time, which makes — IMO excessive — test coverage paramount in catching bugs wherever you have conditional logic. I would have gone with C# or Kotlin if I had the luxury of choice, but I'll get that with a deliberate career move maybe.
    - ncallaway 3y ago
      If you’re taking in data from an external source that needs to be validated, I highly recommend a schema library like zod, that can produce a typescript type. That way you can define the type in a single place, have runtime validation for that type, but also be able to use the type in typescript at compile time.
      - sk0g 3y ago
        Can you use something like Zod with the newtype pattern? I use DDD-style types for domain specific data over primitives.
- formulathree 3y ago
  Go is sane? I just started using it and the parsing libraries all standardize tags and reflection. Not exactly sane. Go is one of the most clunkiest awkward languages I've ever worked with. The only benefit is that it's somewhat easy to learn.
  - sk0g 3y ago
    Go is sane for some definitions of the word! If I got to choose a language to work with though, it would definitely be Kotlin or C#, but I prefer Go over Python because there are fewer ways to solve problems, leading to generally simpler code. It's like a modernised C but for web/infrastructure. Unfortunately ignores about 3 decades worth of progress in other languages, and is simplistic to a fault. Jumping into an unknown codebase is easier than every other language I've used as a result.
    - 6D794163636F756 3y ago
      Go has it's time and place just like C. The developers chose to ignore that progress and created the C for distributed and parallelizeable code. Using go for what you use JavaScript for is like using C to do Java work. Sure you can do it, but it's not going to be easy and you're going to have a bad time. As you've said, Go is sane by some definitions of the word but a user should know what types of sanity and insanity they are willing to work with and which are inherent to their problem space
    - formulathree 3y ago
      [dead]
- taeric 3y ago
  This feels like an odd excuse moreso than a reason. Consider that most folks consider compiling software to go down to an assembly language. Which often has crazy semantics and intrinsics that many of us don't understand or know about. I suspect what you mean is that they aren't just compiling down to JavaScript, but they are wanting to do so in a way that there is no foreign function interface (FFI) consideration for folks in either language. That is, largely to say, they don't want a Typescript runtime?
  - sk0g 3y ago
    Precisely, TypeScript only exists at compile time. Half their goals relate to this fact, which leads to constraints regarding what the language can achieve. > 3. Impose no runtime overhead on emitted programs. > 4. Emit clean, idiomatic, recognizable JavaScript code. > 7. Preserve runtime behavior of all JavaScript code. > 8. Use a consistent, fully erasable, structural type system. https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...
    - taeric 3y ago
      I'm curious on reasons why not to build a new runtime. That it is hosted in javascript seems like something that shouldn't be that big of a deal.
- mattpallissard 3y ago
  > TS is complicated and chaotic because the language it compiles down to is I hear this regularly but don't think it holds water. Other statically typed languages compile to any number of targets without issue; machine code, llvm, and even JS.
oslac 3y ago
It's also bad because you have to, as a programmer, actually type out the types a lot (compared to say, Ocaml, Haskell or Rust), and like you say, it makes it impossible to read.
- jongjong 3y ago
  Personally, I don't get much value out of TypeScript based on how I structure my code. I usually use 'any' types everywhere until my code is fully working and then, just before I open my PR, I have to painstakingly define types and replace all the 'any' references everywhere... Then whenever I get warnings while doing this, it's always related to me messing up the type definitions themselves and not related to my code. It feels like the type system is the error-prone part and my code is the reliable part... Should be the reverse; types are supposed to help me write my code but I find that it's my code (simple interfaces) which help me write my types. Type annotation work is definitely the annoying part which slows me down and breaks my train of thought. That said, I don't dislike TypeScript in theory as a language if used carefully. It may just be worth the annotation effort (kind of like how comments are usually worth the time they take to write). I just don't think it's worth the additional transpilation step and all the compatibility and source mapping issues that come with it.
  - bellerose 3y ago
    [dead]
  - Shrezzing 3y ago
    >I usually use 'any' types everywhere until my code is fully working and then, just before I open my PR, I have to painstakingly define types and replace all the 'any' references everywhere.... It feels like the type system is the error-prone part and my code is the reliable part This is akin to throwing water over an oil pan fire, then being frustrated at the water for your house burning down. You need to either use the Typescript way throughout your dev process, or not use Typescript. Both of those options are valid, but you're currently doing half of both, resulting in unnecessary frustrations.
draw_down 3y ago
[dead]
PUSH_AX 3y ago
At some point someone needs to have the balls to create and push a better language than JS in the browser. It's a huge and scary undertaking, but until it happens we are firmly in transpile/good language -> WASM land for the foreseeable future. TS is lauded, but I really think it's just the best of a bad bunch.
- jenscow 3y ago
  There's Dart. But at the time, many complained of the lack of jQuery support and needing to transpile to support other browsers, so it didn't get the interest it deserved.
  - troupo 3y ago
    I don't think Dart is meaningfully better than JS (for some vague definition of better)
    - jenscow 3y ago
      It provides opt-in type safety. Unlike TS, it's not a language extension.
- xeonmc 3y ago
  LuaJIT?
- chrisco255 3y ago
  There's absolutely no reason to push another language in the browser. Just make wasm your compile target. It's assembly for a reason.
  - PUSH_AX 3y ago
    Sure, if you're writing a lib... If you're writing software and you're consuming libs and frameworks, a fragmented ecosystem sounds less than ideal.
amw-zero 3y ago
I think that’s a major simplification of what’s going on in software development. Alan Kay invented OO, and everyone says the same thing about OO - that it’s over complicated and slows down development. And then everyone replies with, “well that’s not _real_ OO - if you did OO right the software would be perfect!” Except real OO cannot be done. So, yea types are a tool and should be used wisely. But let’s not pretend like there’s some magical methodology out there that removes complexity from software.
- formulathree 3y ago
  Functional programming does this. Probably not Haskell level ninja types or passing functions around like dependency injection, but the idea of separating state and io away from pure logic does indeed remove complexity. Ironically the separation of state away from logic is why backend web development tends to be easier than say game development.
noduerme 3y ago
Typescript is perfectly fine as a nice way to clarify what you're trying to write in Javascript - and it's much more pleasant, coming from more strictly typed languages, to deal with TS. But golf should only go so far. I draw the line somewhere around ternaries being used in type definitions. Like, shut up and actually write the function body, I'll figure out what it does. >> but now many developers are actually using it as such on real projects Seriously? That sounds like being bored and overpaid and/or not having enough pressure to make actual web and implement new features.
resonious 3y ago
If you have freaky type-level metaprogramming in your project (even in a dependency) I think it just means people are playing around. Someone did that stuff for probably more for fun than to solve a real technical problem.
- csjh 3y ago
  To be fair it’s fun to write ridiculous types to get ridiculously specific intellisense
goda90 3y ago
Part of the problem that Typescript can help solve is that JavaScript can be tricky with undefined, null and accidentally casting numbers and strings to each other. It's really a godsend for very large web apps that have large teams of developers with more than 0% turnover.
- giraffe_lady 3y ago
  ReScript solves this problem with a much much simpler type system and stronger inference at the cost of forcing you to handle nulls and undefined as Options. I get that typescript's decision was to model js's behavior exactly in the type system. But now having seen the costs of that and how much can be gained by relatively small constraints on js I think it was a mistake.
dgb23 3y ago
"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" - Brian Kernighan
- klysm 3y ago
  So if I work hard to make a program really easy to debug, then I’m making it harder to debug?
  - dgb23 3y ago
    I think the term "clever" is used to describe unnecessary complexity and indirection, which makes the code harder to debug. I agree with the notion that simplicity is hard though.
- teo_zero 3y ago
  Easy: I'll invest the same effort but for the double of time.
patrickthebold 3y ago
In my experience it's quite difficult to keep things simple. It's a constant battle and sometimes we fail. If you are using typescript you can either go down the path of using `as` and `any`, which at that point the benefits start declining. Or you can work really hard with typescript and make something complicated that correctly matches your code's logic. But saying, "write simple code" doesn't really help much without saying how to do it.
xeonmc 3y ago
is your name Criss by any chance?
mrkeen 3y ago
> Why don't we just design our software in such a way that the interfaces between components are simple so that we can easily remember which functions accept what kinds of input Good luck in defining 'simple'. For me, a simple function only accepts inputs which it knows how to handle, and performs no side effects. Bonus points if it always terminates. Personally I cannot maintain this level of simplicity without a type checker. But on the plus side, you're still allowed to remember what your functions accept! The checker only kicks in if you get it wrong.
madeofpalk 3y ago
You're a lot smarter, and have significantly better memory than I do. Once an application has like beyond 10 different interfaces (whther data structures or function signatures) I simple cannot memorise them flawlessly.
ericHosick 3y ago
> the reason why coding is so difficult is that interfaces are often too darn complicated to keep track of? Haven't brought this up in a while. Ya. I feel coding is hard due to complex interfaces. I once worked on a programming abstraction, mechanisms, aiming for a consistent interface for easy composition. Key features of mechanisms were: 1) All data types were mechanisms 2) A Mechanism needed no context (parameters) when invoked. 3) Composition of a mechanism could take any number of mechanisms (primitives at this point are treated as mechanisms) and return a mechanism. 4) Upon invocation, a mechanism functions in one or more modes, returning either a primitive data type or another mechanism. Think of it as currying or Lisp's S-expressions, but supercharged, envisioned as a base for Visual Programming Languages. An example of composition using mechansisms: // Compose addTwo = print( map( add( 2, emitFromRange(0, 20, 4) ) ) ); Which is saying "Print a mapping of adding 2 to an emitted range from 0 to 20 by 4." // Invoke addTwo()
goto11 3y ago
A goal of TypeScript was that it could be added incrementally to already existing JavaScript code. This meant it has to support a wide variety of crazy pattern used in already existing JavaScript frameworks and libraries. If you want simple interfaces, just write simple interfaces. TypeScript does not prevent you from that. But it makes complex things possible, when you need it. If you work with developers who like to make things needlessly complex, the solution is not to make the tools less powerful.
_a_a_a_ 3y ago
Had you laid on the sarcasm a bit less thickly I might be more sympathetic but I'm not, Mr. smartest-person-in-the-room. Keep looking down on all the idiots who think they know more than you and wasted their lives producing blatant rubbish. For those of a less elevated intellect, I think the answer is that becoming Turing Complete is actually a very low bar. Once you've got recursion and pattern matching I'm pretty sure it just drops out in the wash. "Type checking is unification" (some computer scientist or other, possibly Luca Cardelli)

sk0g 3y ago

If the Typescript team got carte blanche to create their own language, it would likely be... C#. TS is complicated and chaotic because the language it compiles down to is. TS' aim is to model the behaviour seen in JS in a flexible, user-friendly type system. Good luck! What doesn't make sense to me is when teams (like mine) have a blank slate and the choice of any mainstream backend language, and then opt in to that ecosystem anyway. TS is good when you're coming from JS sure, but some of us have used more "sane" languages like C# and Go :(

deleted 3y ago
[deleted]
seedboot 3y ago
> If the Typescript team got carte blanche to create their own language, it would likely be... C#. This is sarcasm, right? The creator of TS is the lead architect of C#
- dnadler 3y ago
  I feel like that’s supporting the parent, right?
  - chrisco255 3y ago
    Not really, because it's not a question of if TS creators got to make their own language.
- sk0g 3y ago
  And C# iterates at a rapid pace, with lots of language features being added, some of which would would not be possible in TS. C# is in some ways less shackled by the runtime it has to target, while TS compiles away entirely. The CLR can be changed to suit .net/C# needs, and JS is not under their control.
edem 3y ago
I come from a Java / Kotlin background and TS is totally fine.
- sk0g 3y ago
  Some quirks I've noticed are typed objects not performing any validations, like for building DTOs. Structural typing so the newtype pattern is not possible without some awkward hacks. A general "disconnect" between compile time and run time behaviour, so once you start casting your errors are relegated to property access/usage time, which makes — IMO excessive — test coverage paramount in catching bugs wherever you have conditional logic. I would have gone with C# or Kotlin if I had the luxury of choice, but I'll get that with a deliberate career move maybe.
  - ncallaway 3y ago
    If you’re taking in data from an external source that needs to be validated, I highly recommend a schema library like zod, that can produce a typescript type. That way you can define the type in a single place, have runtime validation for that type, but also be able to use the type in typescript at compile time.
    - sk0g 3y ago
      Can you use something like Zod with the newtype pattern? I use DDD-style types for domain specific data over primitives.
formulathree 3y ago
Go is sane? I just started using it and the parsing libraries all standardize tags and reflection. Not exactly sane. Go is one of the most clunkiest awkward languages I've ever worked with. The only benefit is that it's somewhat easy to learn.
- sk0g 3y ago
  Go is sane for some definitions of the word! If I got to choose a language to work with though, it would definitely be Kotlin or C#, but I prefer Go over Python because there are fewer ways to solve problems, leading to generally simpler code. It's like a modernised C but for web/infrastructure. Unfortunately ignores about 3 decades worth of progress in other languages, and is simplistic to a fault. Jumping into an unknown codebase is easier than every other language I've used as a result.
  - 6D794163636F756 3y ago
    Go has it's time and place just like C. The developers chose to ignore that progress and created the C for distributed and parallelizeable code. Using go for what you use JavaScript for is like using C to do Java work. Sure you can do it, but it's not going to be easy and you're going to have a bad time. As you've said, Go is sane by some definitions of the word but a user should know what types of sanity and insanity they are willing to work with and which are inherent to their problem space
  - formulathree 3y ago
    [dead]
taeric 3y ago
This feels like an odd excuse moreso than a reason. Consider that most folks consider compiling software to go down to an assembly language. Which often has crazy semantics and intrinsics that many of us don't understand or know about. I suspect what you mean is that they aren't just compiling down to JavaScript, but they are wanting to do so in a way that there is no foreign function interface (FFI) consideration for folks in either language. That is, largely to say, they don't want a Typescript runtime?
- sk0g 3y ago
  Precisely, TypeScript only exists at compile time. Half their goals relate to this fact, which leads to constraints regarding what the language can achieve. > 3. Impose no runtime overhead on emitted programs. > 4. Emit clean, idiomatic, recognizable JavaScript code. > 7. Preserve runtime behavior of all JavaScript code. > 8. Use a consistent, fully erasable, structural type system. https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...
  - taeric 3y ago
    I'm curious on reasons why not to build a new runtime. That it is hosted in javascript seems like something that shouldn't be that big of a deal.
mattpallissard 3y ago
> TS is complicated and chaotic because the language it compiles down to is I hear this regularly but don't think it holds water. Other statically typed languages compile to any number of targets without issue; machine code, llvm, and even JS.

oslac 3y ago

It's also bad because you have to, as a programmer, actually type out the types a lot (compared to say, Ocaml, Haskell or Rust), and like you say, it makes it impossible to read.

jongjong 3y ago
Personally, I don't get much value out of TypeScript based on how I structure my code. I usually use 'any' types everywhere until my code is fully working and then, just before I open my PR, I have to painstakingly define types and replace all the 'any' references everywhere... Then whenever I get warnings while doing this, it's always related to me messing up the type definitions themselves and not related to my code. It feels like the type system is the error-prone part and my code is the reliable part... Should be the reverse; types are supposed to help me write my code but I find that it's my code (simple interfaces) which help me write my types. Type annotation work is definitely the annoying part which slows me down and breaks my train of thought. That said, I don't dislike TypeScript in theory as a language if used carefully. It may just be worth the annotation effort (kind of like how comments are usually worth the time they take to write). I just don't think it's worth the additional transpilation step and all the compatibility and source mapping issues that come with it.
- bellerose 3y ago
  [dead]
- Shrezzing 3y ago
  >I usually use 'any' types everywhere until my code is fully working and then, just before I open my PR, I have to painstakingly define types and replace all the 'any' references everywhere.... It feels like the type system is the error-prone part and my code is the reliable part This is akin to throwing water over an oil pan fire, then being frustrated at the water for your house burning down. You need to either use the Typescript way throughout your dev process, or not use Typescript. Both of those options are valid, but you're currently doing half of both, resulting in unnecessary frustrations.

draw_down 3y ago

[dead]

PUSH_AX 3y ago

At some point someone needs to have the balls to create and push a better language than JS in the browser. It's a huge and scary undertaking, but until it happens we are firmly in transpile/good language -> WASM land for the foreseeable future. TS is lauded, but I really think it's just the best of a bad bunch.

jenscow 3y ago
There's Dart. But at the time, many complained of the lack of jQuery support and needing to transpile to support other browsers, so it didn't get the interest it deserved.
- troupo 3y ago
  I don't think Dart is meaningfully better than JS (for some vague definition of better)
  - jenscow 3y ago
    It provides opt-in type safety. Unlike TS, it's not a language extension.
xeonmc 3y ago
LuaJIT?
chrisco255 3y ago
There's absolutely no reason to push another language in the browser. Just make wasm your compile target. It's assembly for a reason.
- PUSH_AX 3y ago
  Sure, if you're writing a lib... If you're writing software and you're consuming libs and frameworks, a fragmented ecosystem sounds less than ideal.

amw-zero 3y ago

I think that’s a major simplification of what’s going on in software development. Alan Kay invented OO, and everyone says the same thing about OO - that it’s over complicated and slows down development. And then everyone replies with, “well that’s not _real_ OO - if you did OO right the software would be perfect!” Except real OO cannot be done. So, yea types are a tool and should be used wisely. But let’s not pretend like there’s some magical methodology out there that removes complexity from software.

formulathree 3y ago
Functional programming does this. Probably not Haskell level ninja types or passing functions around like dependency injection, but the idea of separating state and io away from pure logic does indeed remove complexity. Ironically the separation of state away from logic is why backend web development tends to be easier than say game development.

noduerme 3y ago

Typescript is perfectly fine as a nice way to clarify what you're trying to write in Javascript - and it's much more pleasant, coming from more strictly typed languages, to deal with TS. But golf should only go so far. I draw the line somewhere around ternaries being used in type definitions. Like, shut up and actually write the function body, I'll figure out what it does. >> but now many developers are actually using it as such on real projects Seriously? That sounds like being bored and overpaid and/or not having enough pressure to make actual web and implement new features.

resonious 3y ago

If you have freaky type-level metaprogramming in your project (even in a dependency) I think it just means people are playing around. Someone did that stuff for probably more for fun than to solve a real technical problem.

csjh 3y ago
To be fair it’s fun to write ridiculous types to get ridiculously specific intellisense

goda90 3y ago

Part of the problem that Typescript can help solve is that JavaScript can be tricky with undefined, null and accidentally casting numbers and strings to each other. It's really a godsend for very large web apps that have large teams of developers with more than 0% turnover.

giraffe_lady 3y ago
ReScript solves this problem with a much much simpler type system and stronger inference at the cost of forcing you to handle nulls and undefined as Options. I get that typescript's decision was to model js's behavior exactly in the type system. But now having seen the costs of that and how much can be gained by relatively small constraints on js I think it was a mistake.

dgb23 3y ago

"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" - Brian Kernighan

klysm 3y ago
So if I work hard to make a program really easy to debug, then I’m making it harder to debug?
- dgb23 3y ago
  I think the term "clever" is used to describe unnecessary complexity and indirection, which makes the code harder to debug. I agree with the notion that simplicity is hard though.
teo_zero 3y ago
Easy: I'll invest the same effort but for the double of time.

patrickthebold 3y ago

In my experience it's quite difficult to keep things simple. It's a constant battle and sometimes we fail. If you are using typescript you can either go down the path of using `as` and `any`, which at that point the benefits start declining. Or you can work really hard with typescript and make something complicated that correctly matches your code's logic. But saying, "write simple code" doesn't really help much without saying how to do it.

xeonmc 3y ago

is your name Criss by any chance?

mrkeen 3y ago

> Why don't we just design our software in such a way that the interfaces between components are simple so that we can easily remember which functions accept what kinds of input Good luck in defining 'simple'. For me, a simple function only accepts inputs which it knows how to handle, and performs no side effects. Bonus points if it always terminates. Personally I cannot maintain this level of simplicity without a type checker. But on the plus side, you're still allowed to remember what your functions accept! The checker only kicks in if you get it wrong.

madeofpalk 3y ago

You're a lot smarter, and have significantly better memory than I do. Once an application has like beyond 10 different interfaces (whther data structures or function signatures) I simple cannot memorise them flawlessly.

ericHosick 3y ago

> the reason why coding is so difficult is that interfaces are often too darn complicated to keep track of? Haven't brought this up in a while. Ya. I feel coding is hard due to complex interfaces. I once worked on a programming abstraction, mechanisms, aiming for a consistent interface for easy composition. Key features of mechanisms were: 1) All data types were mechanisms 2) A Mechanism needed no context (parameters) when invoked. 3) Composition of a mechanism could take any number of mechanisms (primitives at this point are treated as mechanisms) and return a mechanism. 4) Upon invocation, a mechanism functions in one or more modes, returning either a primitive data type or another mechanism. Think of it as currying or Lisp's S-expressions, but supercharged, envisioned as a base for Visual Programming Languages. An example of composition using mechansisms: // Compose addTwo = print( map( add( 2, emitFromRange(0, 20, 4) ) ) ); Which is saying "Print a mapping of adding 2 to an emitted range from 0 to 20 by 4." // Invoke addTwo()

goto11 3y ago

A goal of TypeScript was that it could be added incrementally to already existing JavaScript code. This meant it has to support a wide variety of crazy pattern used in already existing JavaScript frameworks and libraries. If you want simple interfaces, just write simple interfaces. TypeScript does not prevent you from that. But it makes complex things possible, when you need it. If you work with developers who like to make things needlessly complex, the solution is not to make the tools less powerful.

_a_a_a_ 3y ago

Had you laid on the sarcasm a bit less thickly I might be more sympathetic but I'm not, Mr. smartest-person-in-the-room. Keep looking down on all the idiots who think they know more than you and wasted their lives producing blatant rubbish. For those of a less elevated intellect, I think the answer is that becoming Turing Complete is actually a very low bar. Once you've got recursion and pattern matching I'm pretty sure it just drops out in the wash. "Type checking is unification" (some computer scientist or other, possibly Luca Cardelli)