# Dynamic Typing and No Class Method?
**URL:** https://discourse.julialang.org/t/dynamic-typing-and-no-class-method/31257
**Category:** Internals & Design
**Tags:** proposal
**Created:** [November 19, 2019, 7:47am UTC](https://discourse.julialang.org/t/dynamic-typing-and-no-class-method/31257 "2019-11-19T07:47:46Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@LarkyJulia](https://discourse.julialang.org/u/LarkyJulia)
#### Post date: [November 19, 2019, 7:47am UTC](https://discourse.julialang.org/t/dynamic-typing-and-no-class-method/31257/1 "2019-11-19T07:47:46Z")
Except the long keyword sugestions which is doomed to be ignored. I have two more suggestions for Julia:
1: Dynamic Typing: I actually think dynamic typing is not necessary if it influence the running performance or it bring messes during run time while undiscovered during development, I almost never run into a situation when dynamic typing is indispensable. It is like a useless function of allowing the car to explode when driving.
2: No class method: compared with the first one, this one really got me. Cause dynamic typing is there, I can just not using it, maybe someone like it. But this one, I cannot stand. I agree, that scientific computing have many interactions between two objects, which will have influences on both. And writing these influences in any of the class will make the code looks clumsy. But there are many situations I want to define some properties for an object, the properties of itself, forexample, when stimuli are added on, what reaction or change will this object have, and I may change the stimuli-reaction relationship function during the scientific research. There got be methods for that kind, so that I can maintain the code better. This is only one reason, the other reason is: when so many programming paradigm is available and mature today, why Julia, the new born advanced language, stick to one paradigm? Not even opening the possibility of others. Is there any internal difficulties of doing these?
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [November 19, 2019, 8:49am UTC](https://discourse.julialang.org/t/dynamic-typing-and-no-class-method/31257/2 "2019-11-19T08:49:26Z")
> [@LarkyJulia](#):
>
> I almost never run into a situation when dynamic typing is indispensable. It is like a useless function of allowing the car to explode when driving.
Please don’t take this this the wrong way, but it is usually best to use a language for a while before suggesting fundamental changes. Also, its better to accept that fact that — for better or worse — a lot of the basic design principles of Julia are fixed now for practical purposes. The things you are talking about has been there from the very beginning (2012) and are the result of very careful consideration. See
> **[Julia: A Fast Dynamic Language for Technical Computing](https://arxiv.org/abs/1209.5145)**
>
> Dynamic languages have become popular for scientific computing. They are generally considered highly productive, but lacking in performance. This paper presents Julia, a new dynamic language for technical computing, designed for performance from the...
> **[Julia: A Fresh Approach to Numerical Computing](https://arxiv.org/abs/1411.1607)**
>
> Bridging cultures that have often been distant, Julia combines expertise from the diverse fields of computer science and computational science to create a new approach to numerical computing. Julia is designed to be easy and fast. Julia questions...
Dynamic dispatch (if that’s what you are referring to) is actually crucial for some programs (eg those reading in data which cannot be typed _a priori_), and the performance impact can then be mitigated:
[https://docs.julialang.org/en/v1/manual/performance-tips/#kernel-functions-1](https://docs.julialang.org/en/v1/manual/performance-tips/#kernel-functions-1)
> [@LarkyJulia](#):
>
> No class method: compared with the first one, this one really got me. Cause dynamic typing is there, I can just not using it, maybe someone like it. But this one, I cannot stand.
You can search the forum for many discussions along these lines; they do come up from time to time.
---
### Author:  [@tim.holy](https://discourse.julialang.org/u/tim.holy)
#### Post date: [November 19, 2019, 9:57am UTC](https://discourse.julialang.org/t/dynamic-typing-and-no-class-method/31257/3 "2019-11-19T09:57:27Z")
> But there are many situations I want to define some properties for an object, the properties of itself, forexample, when stimuli are added on, what reaction or change will this object have, and I may change the stimuli-reaction relationship function during the scientific research. There got be methods for that kind, so that I can maintain the code better.
It’s really just a question of whether you like your nouns or verbs to come first, and since `obj.property(otherargs...)` is the same thing (except for tab-completion) as `property(obj, otherargs...)`, multiple dispatch is a strictly more powerful paradigm than OOP.
If you _really_ need that dot-syntax and don’t want to pay the performance cost of a `getproperty` method, you can add properties as fields like this:
```julia
julia> struct CoreType{T}
x::T
y::T
end
julia> struct OOPWrapper{T,S}
core::CoreType{T}
sum::S
function OOPWrapper{T}(x, y) where T
core = CoreType{T}(x, y)
s = ()->core.x + core.y
new{T,typeof(s)}(core, s)
end
end
julia> obj = OOPWrapper{Int}(1, 2)
OOPWrapper{Int64,var"#11#12"{CoreType{Int64}}}(CoreType{Int64}(1, 2), var"#11#12"{CoreType{Int64}}(CoreType{Int64}(1, 2)))
julia> obj.sum()
3
```
> when so many programming paradigm is available and mature today, why Julia, the new born advanced language, stick to one paradigm?
[“It’s commonly said that there are 6 ways to implement any low-level task in C++, and 5 of them are likely to end in disaster.”](https://www.quora.com/Why-is-C++-considered-a-bad-language) Supporting many different paradigms makes the language less readable (if you write Julia code in a different paradigm than I do, it’s harder for me to read your code), confusing for newcomers, and harder to maintain. I don’t think any of those are good things.
I know _you’re_ new to Julia, but please believe me that many of us have been using Julia for years, have large code bases, are very happy with the design decisions that went into the language, and would view changes like you’re proposing as making the language worse. It’s not that we’re closed-minded, or unable to perceive what you see; it’s that we’ve lived with Julia for a while and appreciate the choices.
---
### Author:  [@oheil](https://discourse.julialang.org/u/oheil)
#### Post date: [November 19, 2019, 9:58am UTC](https://discourse.julialang.org/t/dynamic-typing-and-no-class-method/31257/4 "2019-11-19T09:58:26Z")
We already have fast and statically typed languages.
But fast and dynamically typed was not so much available or the fast part of the language was/is encapsulated C code.
---
### Author:  [@LarkyJulia](https://discourse.julialang.org/u/LarkyJulia)
#### Post date: [November 19, 2019, 12:23pm UTC](https://discourse.julialang.org/t/dynamic-typing-and-no-class-method/31257/5 "2019-11-19T12:23:32Z")
Thank you very much, I’ll try it for my next project.😁Didn’t use it yet, studying yet.