Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Static, Ahead of Time Compiled Julia

juliacomputing.com

Post reply on HN
Print view View original

61–70 of 87 posts

Re: Static, Ahead of Time Compiled Julia

#61

Post by hyperpape »

openasocket wrote: post #57
StefanKarpinski wrote: post #50

Earlier quoted context omitted.

"Strong typing" and "weak typing" don't really mean anything: http://blogs.perl.org/users/ovid/2010/08/what-to-know-before... You probably mean "static typing" versus "dynamic typing" which I wrote a bit about in the context of Julia here: http://stackoverflow.com/questions/28078089/is-julia-dynamic... Basically, I think "type stability" hasn't really been a thing in the past because in dynamic languages, people have…

I disagree: strong and weak typing are fairly well defined terms. I'm going off the definition given in "Programming Language Pragmatics," which states "a language is strongly typed if it never allows an operation to be applied to an object that does not support it; a language is said to be statically typed if it enforces strong typing at compile time."

I happen to think that there are meaningful things you can express by saying "Strong Typing" or "Weak Typing" (https://news.ycombinator.com/item?id=9256695), though "well defined" might be stretching it. However, I don't like this definition at all.

Both JavaScript and Python prohibit operations on types that don't support them. They both have TypeErrors (or something similar) that are thrown at runtime for certain operations, while others produce a result.

The difference is just that JavaScript allows a bunch of operations that Python prohibits, including several that serve almost no purpose.

Is allowing 1 + "1" allowing an operation on a type that doesn't support it, or does your language just allow adding numbers and strings? There is no principled way to answer that question.

Re: Static, Ahead of Time Compiled Julia

#62

Post by igouy »

openasocket wrote: post #47
vanderZwan wrote: post #28

> For example, the Julia community seems to have coined the term “type-stability” to describe a concept that static / compiled languages have historically enforced and dynamic / scripting languages have historically disregarded. I was not aware that this was a Julia neologism. It seems like such an appropriate term for discussing how to make code make the most out of JIT-compilation.

The closest concept I can think of is the concept of "strong typing," that a value does not change type based on its context, which is a fairly widely used term. It seems like Julia has some form of weak typing, at least between the different numeric primitives, and "type stability" refers to avoiding any usage of weak typing. I don't know a lot about Julia, though, so I could be way off here.

So what is “strong typing”? This appears to be a meaningless phrase, and people often use it in a non-sensical fashion. To some it seems to mean “The language has a type checker”. To others it means “The language is sound” (that is, the type checker and run-time system are related). To most, it seems to just mean, “A language like Pascal, C or Java, related in a way I can’t quite make precise”.

"Programming Languages: Application and Interpretation" Shriram Krishnamurthi, 2003.

Re: Static, Ahead of Time Compiled Julia

#63

Post by igouy »

openasocket wrote: post #57
StefanKarpinski wrote: post #50

Earlier quoted context omitted.

"Strong typing" and "weak typing" don't really mean anything: http://blogs.perl.org/users/ovid/2010/08/what-to-know-before... You probably mean "static typing" versus "dynamic typing" which I wrote a bit about in the context of Julia here: http://stackoverflow.com/questions/28078089/is-julia-dynamic... Basically, I think "type stability" hasn't really been a thing in the past because in dynamic languages, people have…

I disagree: strong and weak typing are fairly well defined terms. I'm going off the definition given in "Programming Language Pragmatics," which states "a language is strongly typed if it never allows an operation to be applied to an object that does not support it; a language is said to be statically typed if it enforces strong typing at compile time."

Type safety is the property that no primitive operation ever applies to values of the wrong type.

"Programming Languages: Application and Interpretation" Shriram Krishnamurthi, 2003.

Re: Static, Ahead of Time Compiled Julia

#64

Post by pjmlp »

jakub_h wrote: post #58
pjmlp wrote: post #2

Julia is really following Lisp and Dylan's footsteps! Congratulations to all involved in pushing the actual state of dynamic languages.

"following Lisp and Dylan's footsteps" I hope not, especially regarding popularity.

I was thinking in terms of language design and tooling. :)

Agree with you.

Re: Static, Ahead of Time Compiled Julia

#65

Post by PeCaN »

g0wda wrote: post #60
PeCaN wrote: post #49

Earlier quoted context omitted.

No, x |> f is equivalent to f(x) while (f ∘ g)(x) is equivalent to g(f(x)). Specifically, x |> f results in a value (of the type of the return value of f) while f ∘ g results always results in a function.

Why not make one for yourself? ;) julia> (∘)(f, g) = x -> f(g(x)) ∘ (generic function with 1 method) julia> (sum ∘ rand)(10) 3.397728240035534 Tip: type \circ to get ∘

I know, but why isn't something like this in core? * did function composition a while ago, but it was removed (beats me why) and hasn't been replaced.

Enough Perl6 has left me with (.) to get ∘ :-)

Re: Static, Ahead of Time Compiled Julia

#66

Post by CyberDildonics »

jacobolus wrote: post #48
StefanKarpinski wrote: post #36

Earlier quoted context omitted.

The main valid complaints in Dan's post were: 1. Insufficient testing & coverage. Code coverage is now at 84% of base Julia, from somewhere around 50% at the time he wrote this post. While you can always have more tests (and that is happening), I certainly don't think that this is a major complaint at this point. 2. Package issues. Julia now has package precompilation so package loading is pretty fast. The package ma…

> The main valid complaints [...] the legitimate issues raised [...] This is a really passive-aggressive weaselly phrasing. I’d recommend reconsidering this type of tone in public discussion responses. Instead of suggesting that the other complaints were invalid or illegitimate, you could just not mention them at all, or at least use nicer language in brushing them aside. E.g. “... the main actionable complaints...”…

Giving any validity to someone with an obvious ax to grind is already going above and beyond.

Re: Static, Ahead of Time Compiled Julia

#67

Post by openasocket »

hyperpape wrote: post #61
openasocket wrote: post #57

Earlier quoted context omitted.

I disagree: strong and weak typing are fairly well defined terms. I'm going off the definition given in "Programming Language Pragmatics," which states "a language is strongly typed if it never allows an operation to be applied to an object that does not support it; a language is said to be statically typed if it enforces strong typing at compile time."

I happen to think that there are meaningful things you can express by saying "Strong Typing" or "Weak Typing" ( https://news.ycombinator.com/item?id=9256695 ), though "well defined" might be stretching it. However, I don't like this definition at all. Both JavaScript and Python prohibit operations on types that don't support them. They both have TypeErrors (or something similar) that are thrown at runtime for certain…

The strong vs. weak typing axis is a more of a spectrum. Virtually every language has some form of weak typing, especially with the numeric types. I guess the litmus test for whether or not a given operation allows weak typing is if it is equivalent to implicit coercion. Languages like Java allow the operation "one" + 1, which is equivalent to "one" + (1).toString() (basically, you'd have to box the integer first to actually make this compile), so it is performing an implicit coercion, and thus an example of weak typing. In the same situation Python would throw an error, and is thus an example of strong typing.

That litmus test is probably not enough to make a true formal definition, but does allow you to make objective comparisons between languages for certain operations.

Re: Static, Ahead of Time Compiled Julia

#68

Post by CyberDildonics »

PeCaN wrote: post #65
g0wda wrote: post #60

Earlier quoted context omitted.

Why not make one for yourself? ;) julia> (∘)(f, g) = x -> f(g(x)) ∘ (generic function with 1 method) julia> (sum ∘ rand)(10) 3.397728240035534 Tip: type \circ to get ∘

I know, but why isn't something like this in core? * did function composition a while ago, but it was removed (beats me why) and hasn't been replaced. Enough Perl6 has left me with (.) to get ∘ :-)

Get involved then, Julia isn't exactly the illuminate.

Re: Static, Ahead of Time Compiled Julia

#69

Post by StefanKarpinski »

openasocket wrote: post #67
hyperpape wrote: post #61

Earlier quoted context omitted.

I happen to think that there are meaningful things you can express by saying "Strong Typing" or "Weak Typing" ( https://news.ycombinator.com/item?id=9256695 ), though "well defined" might be stretching it. However, I don't like this definition at all. Both JavaScript and Python prohibit operations on types that don't support them. They both have TypeErrors (or something similar) that are thrown at runtime for certain…

The strong vs. weak typing axis is a more of a spectrum. Virtually every language has some form of weak typing, especially with the numeric types. I guess the litmus test for whether or not a given operation allows weak typing is if it is equivalent to implicit coercion. Languages like Java allow the operation "one" + 1, which is equivalent to "one" + (1).toString() (basically, you'd have to box the integer first to…

By this definition, Julia is as strongly typed as possible: no automatic promotion or conversion is ever done for anything, including numbers. What appears to be "weak typing" is a clever application of multiple dispatch system with built-in fallback methods for numeric operations. See

http://docs.julialang.org/en/latest/manual/conversion-and-pr...

Re: Static, Ahead of Time Compiled Julia

#70

Post by nickpsecurity »

StefanKarpinski wrote: post #41
ChrisFoster wrote: post #33

Earlier quoted context omitted.

I'm an enthusiastic julia user, observer and very minor contributor. IMO a lot of the issues in this constructive rant have been addressed to some extent. For context, here's the previous HN discussion https://news.ycombinator.com/item?id=8809422 Going through the post in order: The stable releases still have some bugs as you would expect in a young language, but 0.4 is now well below my tolerance level. For a rough…

> I've no idea about the "private and semi-private communications" and I can only hope things were patched up there. I'm the co-creator that Dan was talking about. He wrote a bunch of less-than-charitable comments on the aforementioned semi-private forum – not specifically to me, but where he surely knew I would read them – to which I responded with: https://gist.github.com/StefanKarpinski/c72219ff8ce261172b11 You ca…

Luu's claims made me hold off on pushing people to contribute to Julia as I waited for corroboration (or refutation) of them. I appreciate you linking to that very fair post that replies to it. The contrast between how the two of your present your claims adds credibility to yours. I also got a great laugh out of part about one guy that barely speaks English using the project as a personal Stackoverflow. A problem I'd have not anticipated starting a language/compiler project haha.

Curious, are you all still coding the internals of the compiler in femtolisp, is most of it written in Julia indirectly relying on that, or no LISP now? A barrier to entry question basically.

Post reply on HN