I started learning Julia today so I have some random comments/questions.
Firstly, Julia looks great. It is only the second dynamic language that I
have ever seriously felt like using. The first dynamic language I liked was
Ruby, until I came to appreciate the shortcomings of a dynamic language in
large programs and in the general case, such as:
- no compile-time detection for common (semantic) mistakes
- no intellisense
- even if you had intellisense you couldn't tell what types are accepted by
a method (when a method is undocumented, having type information is vastly
better than nothing!)
- poor performance
While I'm not sure if Julia can address the first problem very well, in
other respects it seems superior to other dynamic languages. I use C# a lot
and one of the best things about C# is its *perfect* intellisense, i.e. if
the IDE shows a method, then I can call it, and if the the IDE does not
show a method, it does not exist or it is inaccessible (there are
exceptions, but none worth mentioning). I guess Julia can't have this kind
of perfection, but perhaps it could come close under some circumstances...
someday... right?
Now, I'm on Windows and I noticed that pressing Ctrl+Any Arrow Key or
Shift+Any Arrow Key causes the process to immediately terminate!! WTF
- I hoped Shift+Left would select one character and Ctrl+Left would move
one word to the left.
In the manual, in Control Flow it says: "Exceptions can be created
explicitly with throw." I think this should say "Exceptions can be raised
explicitly with throw." An expression like DomainError() *creates* an
exception, yes?
The section on Tasks begged a question. What happens when I do this?
julia> function producer()
produce("1");
produce("2")
end
producer (generic function with 1 method)
julia> producer()
julia> # what did I just do???
http://docs.julialang.org/en/release-0.2/manual/types/ says:
> - Only values, not variables, have types — variables are simply names
> bound to values.
>
>
Huh? I'm pretty sure variables can have types, otherwise how could Julia
optimize "x::Int8" into 1 byte and store it efficiently? It's confusing to
claim variables do not have types when everything else I've seen tells me
they do. In fact, the possibility of assigning types to variables (and not
just values) is one of the greatest advantages of Julia over other dynamic
languages. So to say that variables do not have types is as
counterproductive as it is confusing.
We are told bits types must be a multiple of 8 bits. Why? I can see
multiple reasons why Julia would internally round up sizes to multiples of
8, but it seems like a mere "implementation detail". Why require the formal
definition to say, for instance, that Bool is 8 bits?
We are told about incomplete initialization
in http://docs.julialang.org/en/release-0.2/manual/constructors/ :
> Although it is generally a good idea to return a fully initialized object
> from an inner constructor, incompletely initialized objects can be returned:
>
> type Incomplete
> xx
>
> Incomplete() = new()end
> julia> z = Incomplete();
>
> While you are allowed to create objects with uninitialized fields, *any
> access to an uninitialized field is an immediate error*: [emphasis mine]
>
> julia> z.xxaccess to undefined reference
>
> When I saw this I was puzzled because this behavior would seem to block
Julia's famed optimization capabilities. I was not surprised to find out
that the manual is incomplete and should be changed:
julia> type Some{T}
value::T
Some()=new()
Some(v::T)=new(v)
end
julia> Some{Int}()
Some{Int64}(0)
julia> Some{Int}()
Some{Int64}(237821312)
julia> Some{Int}()
Some{Int64}(125)
julia> Some{Integer}().value
ERROR: access to undefined reference
julia> Some{Integer}()
Some{Integer}(#undef) # did printing that secretly involve catching an
error?
That reminds me, the Julia manual doesn't mention the syntax of comments,
nor does it use any comments for the first 6 chapters since it's all REPL.
So I figured out the comment syntax by guessing.
I hate 1-based indexes. Eww. I know it's not going to change at this
point... I'm just sayin'. I thought in modern times the question had been
settled.
The way that types-of-types work in Julia strikes me as kind of bizarre. So
some tuples are types and others are not types? I just have to say, wow!
That's something else. It's a bit shocking to see the base language and
metalanguage/reflection mixed like that. I sort of see the advantage, that
you can express a tuple's type very simply as e.g. (Int, Int) rather than,
say, Tuple{Int, Int}. But wouldn't there be disadvantages to this in
reflective code? This particular magic just makes me feel... uneasy.
When introducing the peculiar syntax (::Type{T}, x::Number)
in http://docs.julialang.org/en/release-0.2/manual/conversion-and-promotion/,
I think the manual should mention that this basically means
(unused::Type{T}, x::Number) except that a variable is not defined. The
manual might have explained this syntax earlier, I don't know - users
shouldn't have to read and remember the whole manual from the beginning.
Similarly I think it bears repeating that "..." (e.g. in
+(promote(x,y)...)) is the "splicing" operator.
The Types chapter neglects to mention that (Foo,) is the syntax for a
one-tuple. The very concept of a one-tuple might be foreign to some
readers; for those that know of it, it may not be immediately obvious that
"(Real,)" is a 1-tuple, rather than a 2-tuple in which the second value is
somehow missing or empty.
Why doesn't this work?
julia> x::Int = 5
ERROR: x not defined
Okay, I think that's enough random stuff for now. G'day mates! Cheerio!
