|
Mr. Glass posted:what if i told you this language already exists go on...
|
#
?
Apr 12, 2015 17:11
|
|
|
|
| # ? Jun 11, 2024 00:10 |
|
|
proponents of dynamic typing may not usually realize popular statically typed languages like C# have at least good enough type inference, lambdas, and higher order functions which would be contrary to their experience w/ older versions of C++/java even java/C++ kind of have those now looking at languages inspired by ml (e.g. F#, ocaml, haskell) kind of makes it obvious static typing does not imply unnecessary boilerplate and makes it more difficult to see the advantages of dynamic typing
|
|
#
?
Apr 12, 2015 17:12
|
|
|
Soricidus posted:e: every time this comes up I start thinking that really what I want is optional typing, is that mainstream yet php7
|
|
#
?
Apr 12, 2015 17:21
|
|
|
c# has static typing by default and an optional dynamic keyword for dynamic typing that's probably a much better approach than dynamic typing by default w/ optional static typing if you care about things like reading a program later
|
|
#
?
Apr 12, 2015 17:25
|
|
|
Blinkz0rz posted:go on... haskell has all those things 
|
|
#
?
Apr 12, 2015 17:33
|
|
|
some people on the internets are even confused and think that static type inference is dynamic typing http://stackoverflow.com/questions/3647824/why-use-dynamic-typing-in-c
|
|
#
?
Apr 12, 2015 17:35
|
|
|
there's basically no experimental way you could verify whether dynamic typing or static typing is better than the other for real world programming projects you'd need a large sample size of multi-year multi-developer projects w/ developers of similar skillsets w/ regular project attrition using different static and dynamically typed languages all solving the same problem but in a way that a particular language's frameworks and library ecosystem doesn't give them a significant advantage over other languages and there'd still be bikeshedding about the languages chosen and languages that haven't been invented yet
|
|
#
?
Apr 12, 2015 17:44
|
|
|
Shinku ABOOKEN posted:this is why i was playing with kotlin And in between the two is List<Butt> todolist = new ArrayList<>().
|
|
#
?
Apr 12, 2015 17:51
|
|
|
type inference is just a loving quality of life thing. Foo foo = new Foo() is exactly why plangers mock java. the traditional strengths of dynamic languages can effectively be brought to static languages. that's why i like the swift language.
|
|
#
?
Apr 12, 2015 17:57
|
|
|
oh wow java still doesn't have type inference for variable declarations likecode:lol
|
|
#
?
Apr 12, 2015 17:57
|
|
|
even when a language has type inference for variable declarations, there will still be a camp that insists on not using it as a general rule http://www.brad-smith.info/blog/archives/336
|
|
#
?
Apr 12, 2015 18:02
|
|
|
Notorious b.s.d. posted:scala and groovy let you have your static type system on the jvm without spending time typing out boilerplate. flexible like a scripting language, typechecked like java we're investigating groovy/grails for a system we're rolling out and groovy really seems like a wet dream. static typing and a REPL, thank you. although I havent really gotten into groovy too deeply yet. it kinda seems like types are optional which is bleh. scala might be nicer but egh
|
|
#
?
Apr 12, 2015 18:08
|
|
|
comedyblissoption posted:even when a language has type inference for variable declarations, there will still be a camp that insists on not using it as a general rule I'll admit that I don't love code:because it gives up the documentary value of the types. if you have a good IDE to cope with that I guess it's OK, but without it you find yourself chasing declarations a lot. otoh I don't really mind code:which has the same issue, so it's not a principled stance
|
|
#
?
Apr 12, 2015 18:11
|
|
|
If people are working with development environments that don't let them easily find the return type of a function, they should get or demand better development environments. This is true regardless of whether or not the language supports type inference or your project's policy on type inference. Even if someone makes an error in type because someone made a wrong assumption about the type of Butts, the compiler will catch the error for them. Only very contrived cases would allow both an error in type by both the compiler and programmer.
|
|
#
?
Apr 12, 2015 18:20
|
|
|
Subjunctive posted:otoh I don't really mind In this case though, immediately seeing that it has a KickAll method gives you some information about the type, if you're familiar with the codebase. Also the value is immediately discarded, which means it's not occupying your mental symbol table with incomplete information as you read later parts of the function.
|
|
#
?
Apr 12, 2015 18:29
|
|
|
comedyblissoption posted:c# has static typing by default and an optional dynamic keyword for dynamic typing haskell has this too
|
|
#
?
Apr 12, 2015 18:34
|
|
|
Subjunctive posted:if you write Hack in checked mode, you get a lot of that optional typing devolves to no typing it's cool that they will statically check the type data that no one will bother to use, i guess?
|
|
#
?
Apr 12, 2015 18:39
|
|
|
rrrrrrrrrrrt posted:haskell has all those things so does scala ..and f# ..and groovy ..and lots of other choices, to fit your personal tastes and project needs good languages exist, let's use them end the tyranny of p-langs
|
|
#
?
Apr 12, 2015 18:41
|
|
|
Notorious b.s.d. posted:optional typing devolves to no typing why does it devolve to no typing? if the file says it's checked then you have to provide type information (where it can't be inferred). you're going to go change the checking mode to avoid putting type info in your patch? feel bad for you, dude.
|
|
#
?
Apr 12, 2015 18:42
|
|
|
Shinku ABOOKEN posted:this is why i was playing with kotlin this is really important type inference doesn't exist to stop you from physically punching in more letters it's not gonna gently caress up my day's productivity to type out "ArrayList<Butt> todolist = someMethod()" six times. it's going back to fix it later that breaks my balls if the someMethod() return type changes later, in a world with type inference, i don't have to gently caress with anything as long as the program remains internally consistent. if something will be broken by the change, the compiler will tell me. if not, everything goes along as before. type inference is having your cake and eating it too. dynamism and also correctness, without trade-offs.
|
|
#
?
Apr 12, 2015 18:44
|
|
|
Notorious b.s.d. posted:scala def map[B, That](f: A => B)(implicit bf: CanBuildFrom[Repr, B, That]): That
|
|
#
?
Apr 12, 2015 18:45
|
|
|
fart simpson posted:def map[B, That](f: A => B)(implicit bf: CanBuildFrom[Repr, B, That]): That no worse than c++. and unlike c++, i don't find myself interacting with unreadable method signatures and stack traces. sure, "map" has an ugly type manifest, but it's easy to use, and when errors arise a normal human being can read the stack trace. (if you wanted to put your finger on something disgusting in scala, you should have pointed at the macro system. eurghhhh)
|
|
#
?
Apr 12, 2015 18:46
|
|
|
Notorious b.s.d. posted:no worse than c++ lol
|
|
#
?
Apr 12, 2015 18:47
|
|
|
Subjunctive posted:why does it devolve to no typing? if the file says it's checked then you have to provide type information (where it can't be inferred). you're going to go change the checking mode to avoid putting type info in your patch? feel bad for you, dude. ok so how many php libraries are available on hack in checked mode? my guess would be "0" it's cool that the language feature exists but i'm not going to get to port any php to it, because third parties aren't doing so this is what happened to attempts at ruby type systems, too. and perl. perl has a sophisticated type system available but lol
|
|
#
?
Apr 12, 2015 18:48
|
|
|
scala seems alright i guess, but i dont see why you'd use it in a world where haskell and f# etc exist
|
|
#
?
Apr 12, 2015 18:49
|
|
|
quote:no worse than c++. and unlike c++,
|
|
#
?
Apr 12, 2015 18:50
|
|
|
anyway im really liking rust's immutability by default. it's the first non functional programming language i've seen that does that, and it's v cool
|
|
#
?
Apr 12, 2015 18:53
|
|
|
Notorious b.s.d. posted:this is really important Sounds like you should have used List instead of ArrayList when you declared your local variable!
|
|
#
?
Apr 12, 2015 18:55
|
|
|
an O(n) return type change is just the reasonable price you pay for being able to know your types later when you print out your source code
|
|
#
?
Apr 12, 2015 19:00
|
|
|
CPColin posted:Sounds like you should have used List instead of ArrayList when you declared your local variable! no, it's much better to be able to switch to any type in the universe than to be able to switch to another List implementation.
|
|
#
?
Apr 12, 2015 19:03
|
|
|
comedyblissoption posted:an O(n) return type change is just the reasonable price you pay for being able to know your types later when you print out your source code i'd love to know how you can do the equivalent refactoring in less than O(n) in any other language
|
|
#
?
Apr 12, 2015 19:04
|
|
|
ocaml is really good guys.
|
|
#
?
Apr 12, 2015 19:09
|
|
|
comedyblissoption posted:even when a language has type inference for variable declarations, there will still be a camp that insists on not using it as a general rule this guy is not all wrong he says sometimes an explicit type declaration makes the code clearer. and, i guess, sometimes it does.
|
|
#
?
Apr 12, 2015 19:11
|
|
|
Mr. Glass posted:i'd love to know how you can do the equivalent refactoring in less than O(n) in any other language Notorious b.s.d. posted:this is really important
|
|
#
?
Apr 12, 2015 19:12
|
|
|
Notorious b.s.d. posted:this guy is not all wrong
|
|
#
?
Apr 12, 2015 19:13
|
|
|
fart simpson posted:scala seems alright i guess, but i dont see why you'd use it in a world where haskell and f# etc exist the oo features of scala are really nice also java interop but nobody's making you use scala. there are lots of good languages. we live in a time of abundance. it's not important to me whether you choose f# or scala, so long as you stop choosing python
|
|
#
?
Apr 12, 2015 19:13
|
|
|
Mr. Glass posted:i'd love to know how you can do the equivalent refactoring in less than O(n) in any other language ignore incompatibilities until a user catches them run-time O(n) by attrition, that's just as good as O(1), right?
|
|
#
?
Apr 12, 2015 19:13
|
|
|
oh lol i thought you were being sarcastic in the other direction
|
|
#
?
Apr 12, 2015 19:15
|
|
|
Mr. Glass posted:oh lol i thought you were being sarcastic in the other direction
|
|
#
?
Apr 12, 2015 19:18
|
|
|
|
| # ? Jun 11, 2024 00:10 |
|
|
Notorious b.s.d. posted:it's not important to me whether you choose f# or scala, so long as you stop choosing python can we talk about the problem of python and other dynamic languages in cs education? when i went to school we started with java and c, but now in an effort to be more broadly appealing i guess, a lot of intro cs sequences are using python. i'm not one of those assholes who thinks that if you can't learn pointer arithmetic you shouldn't be programming at all because you're not a REAL nerd... i understand that especially people from other majors may just want to pick up some python on the side, and they have no interest in being a "software engineer". but for cs majors i worry that neglecting static type systems early on, when students are developing programming habits that they'll carry on into the future, leads to confusion when types are introduced later, and you get people like tbc who just can't wrap their minds around how static typing could be useful. basically i feel about p-langs the same way dijkstra felt about basic... we risk poisoning the minds of a whole generation of future programmers (who we'll have to supervise)
|
|
#
?
Apr 12, 2015 19:27
|
|