Dynamic Typing and No Class Method?

Internals & Design
1

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?

2

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

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

You can search the forum for many discussions along these lines; they do come up from time to time.

9 Likes
3

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> 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.” 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.

14 Likes
4

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.

6 Likes
5

Thank you very much, I’ll try it for my next project.:grin:Didn’t use it yet, studying yet.

3 Likes