|
i want to know why you think java looks like some compiler IR. also sulk how's the job hunt
|
#
?
Oct 12, 2014 18:23
|
|
|
|
| # ? Jun 9, 2024 00:11 |
|
|
FamDav posted:i want to know why you think java looks like some compiler IR. My job hunt is going great, thanks for asking.
|
|
#
?
Oct 12, 2014 18:24
|
|
|
FamDav posted:i want to know why you think java looks like some compiler IR. yeah, java might be endlessly verbose but it's very readable.
|
|
#
?
Oct 12, 2014 18:24
|
|
|
Notorious b.s.d. posted:loving lol that was my point -- you can't. hence my statement: ruby and java both have the curse that the program is identical to the sum of information that can be deduced about the program. it just manifests in opposite ways -- in java most of your program is redundant, and in ruby the extra information never becomes available FamDav posted:i literally have no idea what you're trying to argue except that you can't deduce anything about a ruby program? type inference is the future and people are weirdly resistant to it
|
|
#
?
Oct 12, 2014 18:25
|
|
|
hepatizon posted:that was my point -- you can't. hence my statement: ruby and java both have the curse that the program is identical to the sum of information that can be deduced about the program. it just manifests in opposite ways -- in java most of your program is redundant, and in ruby the extra information never becomes available what the gently caress are you talking about java is very amenable to static analysis. it is a sane language designed by smart people to be used by idiots like us
|
|
#
?
Oct 12, 2014 18:30
|
|
|
Notorious b.s.d. posted:what the gently caress are you talking about my point is that much of the static analysis is redundant with the type/exception declarations, which gives the source code a very poor signal-noise ratio. static analysis also yields optimization-y stuff but that's beside the point. the solution is of course type inference comprehend more, anger less
|
|
#
?
Oct 12, 2014 18:38
|
|
|
hepatizon posted:my point is that much of the static analysis is redundant with the type/exception declarations, which gives the source code a very poor signal-noise ratio. static analysis also yields optimization-y stuff but that's beside the point. the solution is of course type inference Type inference in code is only as useful as to how inferable it is to the code's reader.
|
|
#
?
Oct 12, 2014 18:40
|
|
|
triple sulk posted:Type inference in code is only as useful as to how inferable it is to the code's reader. if you mean presenting the inferred type to the reader, there are trivial solutions like mouse-hover tooltips and IDE display modes. too bad java implementers didn't realize this http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4459053 posted:This is a well reasoned and logical RFE (that's rare enough that I feel
|
|
#
?
Oct 12, 2014 18:51
|
|
|
i don't get the point of all these posts. ruby is terrible because it's a p-lang and all p-langs are terrible. it may be that ruby programmers are more inclined to use lovely techniques like monkey-patching and pointless DSL-building, but there's really nothing about ruby-the-language that encourages or permits this behavior any MORE than python or even javascript does. people who go on about the distinctions between p-langs are either the sort who think syntax is the hardest part of learning a new language, or they're partisans of a particular p-lang (these frequently occur together)
|
|
#
?
Oct 12, 2014 18:56
|
|
|
hepatizon posted:if you mean presenting the inferred type to the reader, there are trivial solutions like mouse-hover tooltips and IDE display modes. too bad java implementers didn't realize this java can't really do this because of subtyping. consider the example you quoted: Map m = getMap(); suppose getMap returns a java.lang.HashMap. then if i write simply "let m = getMap()", what do i mean? it could be: HashMap m = getMap(); Map m = getMap(); Collection m = getMap(); ... Object m = getMap(); how is java supposed to know?
|
|
#
?
Oct 12, 2014 18:58
|
|
|
Notorious b.s.d. posted:these things are related. it's a chicken/egg problem. folks like hepatizon are why we have useless type systems and bad package systems yeah i know im just being snarky
|
|
#
?
Oct 12, 2014 19:11
|
|
|
JewKiller 3000 posted:java can't really do this because of subtyping. consider the example you quoted: the inferred type of 'm' is the specific return type of the rvalue. if the rvalue is a conditional statement, the inferred type is the union of all possible return types from the branches are there other reasons to declare an interface/superclass as a variable's type? i can't remember hepatizon fucked around with this message at 19:15 on Oct 12, 2014 |
|
#
?
Oct 12, 2014 19:12
|
|
|
JewKiller 3000 posted:i don't get the point of all these posts. ruby is terrible because it's a p-lang and all p-langs are terrible. it may be that ruby programmers are more inclined to use lovely techniques like monkey-patching and pointless DSL-building, but there's really nothing about ruby-the-language that encourages or permits this behavior any MORE than python or even javascript does. people who go on about the distinctions between p-langs are either the sort who think syntax is the hardest part of learning a new language, or they're partisans of a particular p-lang (these frequently occur together) isn't there though? in python you can import a library and there's no chance it could have overwritten the base integer type. it sounds like that's possible in ruby and one of the things tef is complaining about?
|
|
#
?
Oct 12, 2014 19:16
|
|
|
JewKiller 3000 posted:java can't really do this because of subtyping. consider the example you quoted: c# has exactly this feature, it wouldn't be technically impossible for java
|
|
#
?
Oct 12, 2014 19:19
|
|
|
hepatizon posted:the inferred type of 'm' is the specific return type of the rvalue. if the rvalue is a conditional statement, the inferred type is the union of all possible return types from the branches yeah what you say makes sense, i'm not sure how to argue, basically i'm just going off the theorem that type inference is undecidable in the presence of subtyping (i.e. for system f-sub). unfortunately i am not smart enough to understand the intuition behind the proof, or why it might not apply in this case 
|
|
#
?
Oct 12, 2014 19:19
|
|
|
JewKiller 3000 posted:but there's really nothing about ruby-the-language that encourages or permits this behavior any MORE than python or even javascript does lol no
|
|
#
?
Oct 12, 2014 19:37
|
|
|
JewKiller 3000 posted:java can't really do this because of subtyping. consider the example you quoted: in C# it would infer that m's type is whatever getMap()'s type signature says it returns. so if getMap() says it returns a Map, 'm' will have the type Map
|
|
#
?
Oct 12, 2014 19:39
|
|
|
fart simpson posted:isn't there though? in python you can import a library and there's no chance it could have overwritten the base integer type. it sounds like that's possible in ruby and one of the things tef is complaining about? if you put a top level def you are adding a new method to object 
|
|
#
?
Oct 12, 2014 19:39
|
|
|
Notorious b.s.d. posted:in C# it would infer that m's type is whatever getMap()'s type signature says it returns. so if getMap() says it returns a Map, 'm' will have the type Map ah ok so it requires that you annotate the types of your functions. that works
|
|
#
?
Oct 12, 2014 19:41
|
|
|
JewKiller 3000 posted:ah ok so it requires that you annotate the types of your functions. that works why couldn't it also infer the return types of your functions?
|
|
#
?
Oct 12, 2014 19:48
|
|
|
in C# it's just a readability measure. often the type is obvious and typing a long type signature adds nothing to readability:code:code:for reasons i do not understand well enough to explain, the scala compiler can't do global type inference. e.g. it can't infer the types of arguments to functions
|
|
#
?
Oct 12, 2014 19:49
|
|
|
JewKiller 3000 posted:yeah what you say makes sense, i'm not sure how to argue, basically i'm just going off the theorem that type inference is undecidable in the presence of subtyping (i.e. for system f-sub). unfortunately i am not smart enough to understand the intuition behind the proof, or why it might not apply in this case yeah i don't have the theoretical background to understand much of this. it seems like the undecidability might arise from stuff like "impredicative polymorphism"? not sure if that would apply to anything in java intuitively, i'm pretty sure that if your language's core functions (the ones implemented in a lower-level language) have explicit type annotations, any program written in your language can have its types 100% inferred, without type declarations in variable assignments, function signatures, or anywhere else fart simpson posted:why couldn't it also infer the return types of your functions? yup. the return type could even vary depending on the (also inferred) types of the arguments, and you can still statically infer all types in the context of a particular call hepatizon fucked around with this message at 19:53 on Oct 12, 2014 |
|
#
?
Oct 12, 2014 19:50
|
|
|
hepatizon posted:intuitively, i'm pretty sure that if your language's core functions (the ones implemented in a lower-level language) have explicit type annotations, any program written in your language can have its types 100% inferred, without type declarations in variable assignments, function signatures, or anywhere else subtyping and overloading make global type inference impossible. i am not smart enough to explain it. google "hindley-milner" for the deets i guess
|
|
#
?
Oct 12, 2014 19:53
|
|
|
this is supposed to be the simplest walkthrough of hindley-milner inference and its consequences and fuckin' A is it over my head http://akgupta.ca/blog/2013/05/14/so-you-still-dont-understand-hindley-milner/
|
|
#
?
Oct 12, 2014 19:54
|
|
|
fart simpson posted:why couldn't it also infer the return types of your functions? because if you try to extend the hindley-milner type inference algorithm based on unification to solve a set of subtyping inequality constraints then you get an instance of the semi-unification problem which is generally undecidable. no i don't know what that means. but searches for those terms should bring up some papers written by people who do  hepatizon posted:intuitively, i'm pretty sure that if your language's core functions (the ones implemented in a lower-level language) have explicit type annotations, any program written in your language can have its types 100% inferred, without type declarations in variable assignments, function signatures, or anywhere else yes, this is basically how core ML works. but there is no subtyping in core ML
|
|
#
?
Oct 12, 2014 19:57
|
|
|
JewKiller 3000 posted:because if you try to extend the hindley-milner type inference algorithm based on unification to solve a set of subtyping inequality constraints then you get an instance of the semi-unification problem which is generally undecidable. you can still infer return types w/ local type inference (scala does it, c# and java could do it) you can't infer the types of the arguments
|
|
#
?
Oct 12, 2014 19:59
|
|
|
gently caress hm let's use success typing  also i found it easier to understand HM through CHR and other constraint systems
|
|
#
?
Oct 12, 2014 20:00
|
|
|
JewKiller 3000 posted:because if you try to extend the hindley-milner type inference algorithm based on unification to solve a set of subtyping inequality constraints then you get an instance of the semi-unification problem which is generally undecidable. ok, that was obvious. dumb question
|
|
#
?
Oct 12, 2014 20:00
|
|
|
Notorious b.s.d. posted:you can still infer return types w/ local type inference (scala does it, c# and java could do it) yeah there are various restrictions you can impose to make the problem decidable and i guess that is one of them. i just avoid subtyping, worksforme 
|
|
#
?
Oct 12, 2014 20:00
|
|
|
Is Julia a plang?
|
|
#
?
Oct 12, 2014 20:18
|
|
|
Notorious b.s.d. posted:subtyping and overloading make global type inference impossible. i am not smart enough to explain it. overloading on parameter type definitely goes out the window if your parameter types are undeclared. i don't think sacrificing those is a big problem -- those can be moved to pattern-matching inside the method (obviously out of the question for java BC, though). overloading on number of params seems like it'd still work i definitely don't understand the subtyping thing. it's frustratingly hard to read about. Notorious b.s.d. posted:this is supposed to be the simplest walkthrough of hindley-milner inference and its consequences and fuckin' A is it over my head heh yeah, was already banging my head against it Notorious b.s.d. posted:you can still infer return types w/ local type inference (scala does it, c# and java could do it) you can infer parameter types in a particular call context, where the arguments are just expressions with known (inferred) types. then you can infer the return type of the function with those specific parameter types. this leads a weird situation: function defs can have arbitrary semantics, but they become specific and concrete in the context of a call http://dynamicsofprogramming.blogspot.com/2013/12/duck-typing-vs-structural-typing.html hepatizon fucked around with this message at 20:30 on Oct 12, 2014 |
|
#
?
Oct 12, 2014 20:27
|
|
|
tef posted:ruby: it is not a p lang it is worse than a p lang a pee lang p++ hepatizon posted:keep the nickel and buy yourself an opinion you can back up lol jfc is there a correlation between lack of self awareness and ruby use
|
|
#
?
Oct 12, 2014 21:54
|
|
|
Deacon of Delicious posted:lol jfc when i make frothing personal accusations, it's always in self-defense
|
|
#
?
Oct 12, 2014 22:14
|
|
|
hepatizon posted:frothing personal accusations ok, so that's 1 for "yes"
|
|
#
?
Oct 12, 2014 22:17
|
|
|
fart simpson posted:i post on this small programming mailing list and we collaborate on small projects together sometimes and there's this one guy that is always trying to convince people to rewrite as much as possible in shell scripts and makefiles. i don't get it. we have people using mac, linux, and windows It's using Makefiles on Windows that is pretty brain dead, I'm not sure if I would categorize it worse than oodles of batch scripts though. Some people really love to make really obnoxiously awful build systems, I guess it's Dunning Kruger or job safety mentality, I just see it as mental. I guess WiX is actually usable via Make these days, for packaging apps, but CPack with CMake can be incredibly convenient.
|
|
#
?
Oct 12, 2014 22:18
|
|
|
Deacon of Delicious posted:ok, so that's 1 for "yes" hey person, say something funny or even interesting
|
|
#
?
Oct 12, 2014 22:19
|
|
|
let's read this blog post about type inference, see what it says. hmm: Lend itself to a simple, terse symbolic representation, e.g. rather than saying “the expression formed by applying the first expression to the second expression has the type of a function from strings to some type we don’t care to specify in the current context” we could simply say “e1(e2) : String → t”.  Suppose I’ve already been able to infer that a variable duck has type Animal. Suppose furthermore that I’ve inferred that speak is a method of type Animal -> String. Then I can infer that speak(duck) has type String. And any reasoning of this form is valid type inference. We’ll formalize that as follows: Γ ⊢ e0 : τ → τ′ Γ ⊢ e1 : τ ———————————————————————————— Γ ⊢ e0(e1) : τ′  ...  are you loving kidding me?! this... this is why you needed a blog post titled So You Still Don't Understand Hindley-Milner? Part 1, 2, 3 in the first place
|
|
#
?
Oct 12, 2014 22:22
|
|
|
Max Facetime posted:are you loving kidding me?! did you read the part where he explains what each bit of thatt notation means. using this guy right here Γ ⊢ e0 : τ → τ′ Γ ⊢ e1 : τ ———————————————————————————— Γ ⊢ e0(e1) : τ′ Gamma is the set of things known to be true. this might be 1 is an Int, or that ID goes from any type to any type, or that the variable x happens to be a String. the sideways T is really just set membership. its say that we have whats on the right in the left. i assume you're good with the type annotations. the horizontal line can be thought of as a proof arrow. if everything on top is known to be true, then whats below is also true. so putting it all together, its saying if you know a particular expression is type X to Y, and another expression of type X, then when you apply the first expression to the second (like calling a function), then that expression has to have type Y. the phrasing is probably more like "Gamma must also contain this statement" but thats more how its thought of as an algorithm. FamDav fucked around with this message at 22:31 on Oct 12, 2014 |
|
#
?
Oct 12, 2014 22:28
|
|
|
FamDav posted:did you read the part where he explains what each bit of thatt notation means. all plt papers by law must have a page that's nothing but deduction hieroglyphics
|
|
#
?
Oct 12, 2014 22:42
|
|
|
|
| # ? Jun 9, 2024 00:11 |
|
|
yes it's naming all those symbols using small words and going by the comments the formulations are probably almost correctly written tooo ... but the underlying problem with Γ ⊢ e0 : τ → τ′ Γ ⊢ e1 : τ ———————————————————————————— Γ ⊢ e0(e1) : τ′ is lovely syntax and the solution to that is not more of 
|
|
#
?
Oct 12, 2014 22:42
|
|