|
if static typing is all-or-nothing, buddy i don't know what to tell you cause it ain't ever gonna be all
|
#
?
Apr 4, 2018 06:47
|
|
|
|
| # ? Jun 5, 2024 01:11 |
|
|
still, seems reasonable to gripe about the lack of 1970s-era technology in a greenfield programming language designed by, and for use at, loving google
|
|
#
?
Apr 4, 2018 07:05
|
|
|
rjmccall posted:if static typing is all-or-nothing, buddy i don't know what to tell you cause it ain't ever gonna be all
|
|
#
?
Apr 4, 2018 08:34
|
|
|
rjmccall posted:if static typing is all-or-nothing, buddy i don't know what to tell you cause it ain't ever gonna be all it’s more of a something or nothing proposition golang offers a type system so deeply impoverished that the static type checker cannot possibly benefit the programmer it accepts the null hypothesis
|
|
#
?
Apr 4, 2018 08:39
|
|
|
homercles posted:Russ Cox's comments from 2009 epitomise the compromises made with various implementations of generics: do you want slow programmers, slow compilers and bloated binaries, or slow execution times? (they don't know and the Go language devs are very conservative in adding new features) Where does conventional ML-style parametric polymorphism fall on this scale? I'm guessing "slow execution times" since polymorphic variables end up being heap-allocated unless the compiler does monomorphisation, but I'm not sure. (The term "generics" is also dumb. Where did it come from?)
|
|
#
?
Apr 4, 2018 09:18
|
|
|
Notorious b.s.d. posted:it’s more of a something or nothing proposition it offers a simple and minimalist type system. for a language introduced in the 2010s, it is surprisingly seat-of-the-pants and not well thought out. it's arguably similar to c's type system, but with "void*" changed to "interface{}". but to say it "cannot possibly benefit the programmer" is wrong. the brutalist minimalism of c's type system remains a strong argument. c++, java, and c# each tried to bolt on generics and they all failed in different ways. it's not an easy problem. rust has the advantage of already being loving ml, and it's still very awkward to work with.
|
|
#
?
Apr 4, 2018 10:31
|
|
|
tbqh i think it is pretty wise to make maps a first-class thing either way. sure, provide a map interface and have the first-class ones implement it if you want, but have a first-class default one that gets easy-to-write literals, and have apis accept them explicitly in most cases it is very much in the same vein as having a first class idea of an array or list, it is not meant to imply that no sequence should be done in any other way, but it is just too common a thing to have every occurrence potentially be some wacky implementation that may strain against the expected (and usually quite complex) contract at every turn
|
|
#
?
Apr 4, 2018 11:03
|
|
|
quote:Rob Pike is like Henry Ford, except when people said “faster horses” he said “that is the best idea I’ve ever heard.”
|
|
#
?
Apr 4, 2018 11:32
|
|
|
Suspicious Dish posted:it's arguably similar to c's type system, but with "void*" changed to "interface{}". i feel like this is giving it too much credit, at least void* has a single null value https://golang.org/doc/faq#nil_error https://stackoverflow.com/questions/13476349/check-for-nil-and-nil-interface-in-go also goes to rjmccall's "nullability can be a valid design decision" comment, if you make everything nullable then you give people tools to work with that like optional chaining go is a mishmash of ideas you might have if you wrote c all your life, like "the only concurrency problem is not enough threads", and "maybe we could have a couple of typed structures as a compiler extension" and it turns out they're mostly bad ideas except the one that people shouldn't have to care about async soup when writing code, that's a good idea. that, the single binaries and the latency-over-throughput gc focus carries it atm imo. i expect rust is eating into the curlable cli tool case very quick, we'll see about the simple http daemons, the future stuff looks very complicated
|
|
#
?
Apr 4, 2018 12:14
|
|
|
look at these scrubs not writing their http daemons in erlang and or elixir tbh python 3 suits my needs for like 99% of code it's really come along well. if the graal implementation ever gets done it's game over for a lot of these scrub tier langs
|
|
#
?
Apr 4, 2018 13:02
|
|
|
Python's biggest drawback that I've seen is the inability to ship small, platform agnostic binaries. You are end up installing via pip, as a whl or source, and then hoping your transitive dependencies are sensical. Hot take: I think the hard freeze on python 2.7 for 15 years was tremendously helpful for adoption. I kind of want them to cool it after python 3.6 for another decade just so I don't have to constantly worry about minor version backwards compat, leave that to the third parties
|
|
#
?
Apr 4, 2018 14:09
|
|
|
How are c#s generics a "failure"? I'm aware of edge cases, but calling them a failure seems a bit much. They're certainly better than nothing.
|
|
#
?
Apr 4, 2018 14:34
|
|
|
Cybernetic Vermin posted:tbqh i think it is pretty wise to make maps a first-class thing either way. sure, provide a map interface and have the first-class ones implement it if you want, but have a first-class default one that gets easy-to-write literals, and have apis accept them explicitly in most cases Why not just have syntactic sugar for the map interface instead of loving up your API such that it only accepts one particular implementation of map? Just what kind of wacky implementations of map do you expect to crop up?
|
|
#
?
Apr 4, 2018 15:12
|
|
|
Suspicious Dish posted:the brutalist minimalism of c's type system remains a strong argument. C's type system is actively unhelpful. it almost never catches errors in program logic, and it frequently trips you up on things you categorically do not care about the C type system was a failed experiment -- bcpl had a much simpler type system that caught approximately the same classes of error with much less effort from the programmer Suspicious Dish posted:c++, java, and c# each tried to bolt on generics and they all failed in different ways. it's not an easy problem. it is indeed a hard problem. c++, java, and c#'s designers made hard decisions about parameterized types. these decisions have tradeoffs and consequences. but they have to be made! if you just throw your hands up and tell everyone to cast to void*, you undermine your type system so badly that it no longer serves a purpose
|
|
#
?
Apr 4, 2018 16:00
|
|
|
suffix posted:i feel like this is giving it too much credit, at least void* has a single null value this is a very good post
|
|
#
?
Apr 4, 2018 16:01
|
|
|
i like javascript's type system
|
|
#
?
Apr 4, 2018 16:25
|
|
|
akadajet posted:i like javascript's type system you do strike me as the sort of person who likes huffing a big wet fart
|
|
#
?
Apr 4, 2018 16:36
|
|
|
sticking Flow's type system on top of js does make things at least somewhat bearable
|
|
#
?
Apr 4, 2018 16:39
|
|
|
or typescript
|
|
#
?
Apr 4, 2018 16:43
|
|
|
i wonder what it says about me that my favorite languages nowadays are types bolted on top of languages that don't support them aka python3+mypy and typescript
|
|
#
?
Apr 4, 2018 16:44
|
|
|
Thermopyle posted:i wonder what it says about me that my favorite languages nowadays are types bolted on top of languages that don't support them that you’ll be writing java inside of two years. 
|
|
#
?
Apr 4, 2018 16:47
|
|
|
what's better, flow or typescript?
|
|
#
?
Apr 4, 2018 16:48
|
|
|
jony neuemonic posted:that you’ll be writing java inside of two years. ha! i stopped writing java like 7 years ago once I moved away from Android dev HappyHippo posted:what's better, flow or typescript? when it comes to syntax they're both fine, but the typescript community is way larger so there's a lot more info and tooling support for TS. plus I always get the feeling that microsoft puts a lot more developer work into TS then facebook does into flow
|
|
#
?
Apr 4, 2018 16:51
|
|
|
HappyHippo posted:what's better, flow or typescript? both don't provide any real value besides making java people feel more comfortable with a dynamic type system.
|
|
#
?
Apr 4, 2018 16:56
|
|
|
HappyHippo posted:what's better, flow or typescript? never used typescript the one time i used flow i found the error messages totally useless. i had misspelled a property name and the error pointed me to the definition of the type, not the line where the misspelled call was being made code:
|
|
#
?
Apr 4, 2018 17:02
|
|
|
Plank Walker posted:never used typescript oh yeah i forgot this most important part...TS generally has better errors than Flow, but from what I understand flow has gotten better then it used to be
|
|
#
?
Apr 4, 2018 17:04
|
|
|
yeah i haven't actually used flow in the last three months or so so they've probably rewritten the entire thing from scratch a couple of times since then
|
|
#
?
Apr 4, 2018 17:08
|
|
|
If I had to pick a javascript bolt-on lang it'd be TS. Mostly because it has a lot more mindshare.
|
|
#
?
Apr 4, 2018 17:09
|
|
|
everyone posted:nullability just let me dereference 0 i put something important there
|
|
#
?
Apr 4, 2018 17:40
|
|
|
the problem with embedded programmers is less that you want to do unusual things and more that you really hate the idea that you should bear any responsibility for doing it a thing you could easily do as an embedded programming team: pay a compiler engineer for a month to give you an abi that makes the null pointer -1 or whatever a thing you will actually do as an embedded programming team: bitch endlessly that it wasn’t already done for you for free and that nobody really understands your plight
|
|
#
?
Apr 4, 2018 17:51
|
|
|
rjmccall posted:a thing you will actually do as a programmer: bitch endlessly
|
|
#
?
Apr 4, 2018 17:54
|
|
|
rjmccall posted:the problem with embedded programmers is less that you want to do unusual things and more that you really hate the idea that you should bear any responsibility for doing it i like this post because with some limited substitutions you can use it for any sort of programmers (maybe even any sort of people!)
|
|
#
?
Apr 4, 2018 17:55
|
|
|
Fiedler posted:Why not just have syntactic sugar for the map interface instead of loving up your API such that it only accepts one particular implementation of map? Just what kind of wacky implementations of map do you expect to crop up? because if you accept varying implementations for maps you have to code defensively around the code you are running, as it will loosely conform to a complex contract instead of actually being a predictable map of things you need to operate on it is a bad idea to abstract the idea of very basic stuff, try to fix the baseline data structures. if someone with a custom map really can't afford to convert their thing to a standard map for the call they are probably performance-conscious enough that they'll want to control the implementation more closely anyway
|
|
#
?
Apr 4, 2018 17:55
|
|
|
rjmccall posted:the problem with embedded programmers is less that you want to do unusual things and more that you really hate the idea that you should bear any responsibility for doing it did you just tell me to -ffreestanding myself
|
|
#
?
Apr 4, 2018 18:01
|
|
|
JawnV6 posted:did you just tell me to -ffreestanding myself
|
|
#
?
Apr 4, 2018 18:05
|
|
|
Notorious b.s.d. posted:C's type system is actively unhelpful. it almost never catches errors in program logic, and it frequently trips you up on things you categorically do not care about are you saying you never had a useful typing error message out of a c compiler, ever? because yikes, you must have been using some pretty bad c compilers. the issue is you're saying "the C type system is not expressive. by simply adding generics, the system becomes fully expressive". but you've never really said why just that one feature would get you away from interface{}.
|
|
#
?
Apr 4, 2018 18:14
|
|
|
im a little disappointed that c11 didn't add the widely-used containerof() macro to stddef.h
|
|
#
?
Apr 4, 2018 18:17
|
|
|
Suspicious Dish posted:the issue is you're saying "the C type system is not expressive. by simply adding generics, the system becomes fully expressive". but you've never really said why just that one feature would get you away from interface{}. it's not that it becomes fully expressive, it's that it becomes minimally expressive without generics or some other parameterized type, it is not possible to have a compiler-checked list type. I think being able to implement List<T> is a minimum bar for expressing program invariants in the type system. it's not the final word on the subject, it is just the very first step to making the type system useful instead of a burden c fails. golang fails. bcpl fails. c++, java, and c# all succeed. why do you think this is? how can we build a statically typed language with type-checked user-implemented containers without generics?
|
|
#
?
Apr 4, 2018 18:41
|
|
|
Notorious b.s.d. posted:it's not that it becomes fully expressive, it's that it becomes minimally expressive I agree with nbsd on this point, it's not all or nothing. Java did the bare minimum with it's generics and it has some holes, but at least it's useful now compared to the all the casting bullshit prevalent before Java 5
|
|
#
?
Apr 4, 2018 18:53
|
|
|
|
| # ? Jun 5, 2024 01:11 |
|
|
Cybernetic Vermin posted:because if you accept varying implementations for maps you have to code defensively around the code you are running, as it will loosely conform to a complex contract instead of actually being a predictable map of things you need to operate on Look at C#'s IDictionary. There are multiple good implementations of that interface. These aren't strange edge cases - - you're not going to spend any time worrying whether that IDictionary someone passed in is a SortedDictionary or a Dictionary, because they both satisfy the interface.
|
|
#
?
Apr 4, 2018 19:17
|
|