|
Ator posted:page 444 of this haskell book and the authors still havent introduced monads
|
#
?
Feb 25, 2017 05:53
|
|
|
|
| # ? May 22, 2024 07:08 |
|
|
Ator posted:page 444 of this haskell book and the authors still havent introduced monads Is it learn you a haskell? http://learnyouahaskell.com
|
|
#
?
Feb 25, 2017 05:59
|
|
|
is it bad of me to not like python because it relies so heavily community libraries that are almost universally terrible? it always seems like theres a huge hassle trying to get things to work and i just really dont see how this is a good language for rapid prototyping. I mean the actual coding itself is fast as gently caress, but wrangling libraries ends up eating up all the time that i save. am i just supposed to become jaded to dealing with all this bullshit?
|
|
#
?
Feb 25, 2017 08:25
|
|
|
contrary to some people's belief, dynamic typing isn't good for "rapid prototyping"
|
|
#
?
Feb 25, 2017 08:37
|
|
|
dynamic typing actually makes it harder to use libraries and every library has their own informal way to document the types of their API that are not enforced so you're constantly looking up terrible documentation
|
|
#
?
Feb 25, 2017 08:50
|
|
|
SpaceClown posted:is it bad of me to not like python because it relies so heavily community libraries that are almost universally terrible? you learn the few important libraries you need and mainly work with them for your prototypes. Any additional ones should take a few minutes to get the basics. scipy/numpy for number stuff + whatever new is out there request/alchemy/flask/django/etc for web stuff I've yet to see a mature popular language with libraries that don't require a long time to learn. hell even objC/swift which is completely in the apple ecosystem and all the common libraries are coming from the source, it still takes forever to learn the apis and do the things you want to do
|
|
#
?
Feb 25, 2017 08:51
|
|
|
comedyblissoption posted:contrary to some people's belief, dynamic typing isn't good for "rapid prototyping" python is not the best language for all purposes but it does what it's good at very well
|
|
#
?
Feb 25, 2017 09:00
|
|
|
SpaceClown posted:is it bad of me to not like python because it relies so heavily community libraries that are almost universally terrible? what are you trying to do because yeah for the numeric stuff im familiar with, python has by far and away the best stack of any programming language
|
|
#
?
Feb 25, 2017 09:00
|
|
|
MeruFM posted:it's fast because you don't have to define your own types as you are mixing different structures together to see what works with some semblance of strong typing on primitives resolving the most common and difficult to debug issues. comedyblissoption fucked around with this message at 09:08 on Feb 25, 2017 |
|
#
?
Feb 25, 2017 09:03
|
|
|
refactoring and renaming poo poo is also way easier
|
|
#
?
Feb 25, 2017 09:07
|
|
|
i don't see how changing types is faster in static lang when you don't even need to define it in a dynamic language the advantage of a static language is you get guarantees by being forced to define some limitations it's like saying unit tests make building a prototype faster, when the entire point of a prototype is about loving around to see if something is even feasible.
|
|
#
?
Feb 25, 2017 09:08
|
|
|
it's faster because you have it statically verified by a robot that tells you where you need to fix breakages caused by your type changes in a dynamically typed lang you cross your fingers and waste a lot of time hitting issues from your changes while debugging
|
|
#
?
Feb 25, 2017 09:09
|
|
|
good type inference makes defining your static types generally much less of a burden than in say java or traditional c++
|
|
#
?
Feb 25, 2017 09:10
|
|
|
the thing with dynamic typing is you're still constantly thinking about types. you can't program without thinking about types. it's just all implicit and the only thing you're really saving is the time spent typing the type constraints and the type definitions. imo, the bottleneck in programming, even for prototyping code, is not the slowdown of having to type that your parameter is of type int.
|
|
#
?
Feb 25, 2017 09:23
|
|
|
MeruFM posted:it's fast because you don't have to define your own types as you are mixing different structures together to see what works with some semblance of strong typing on primitives resolving the most common and difficult to debug issues. it's by far the language i like to use when teaching beginner programming
|
|
#
?
Feb 25, 2017 09:53
|
|
|
imo assembly is the best beginner programming language for several reasons that i dont feel like posting but in your heart of hearts you know im right.
|
|
#
?
Feb 25, 2017 09:55
|
|
|
lol okay there's definitely more crazy people in here than the last time i was active in this thread I assume by assembly, you're only counting the basic math + logic + coprocessor registry stuff and not the entire x86/87 instruction set that is keeping intel from making a good mobile chip
|
|
#
?
Feb 25, 2017 10:08
|
|
|
my first programming language was microsoft's variant of C++ 98 since that was what was used in our high school programming language class. the AP tests were done in C++ too. C++ for pedagogy is ill-advised and probably absolutely killed the interest in programming that many in that class might have otherwise had.
|
|
#
?
Feb 25, 2017 10:21
|
|
|
comedyblissoption posted:my first programming language was microsoft's variant of C++ 98 since that was what was used in our high school programming language class. the AP tests were done in C++ too. C++ for pedagogy is ill-advised and probably absolutely killed the interest in programming that many in that class might have otherwise had. good
|
|
#
?
Feb 25, 2017 11:35
|
|
|
comedyblissoption posted:the thing with dynamic typing is you're still constantly thinking about types. you can't program without thinking about types. it's just all implicit and the only thing you're really saving is the time spent typing the type constraints and the type definitions. No you don't. 95%+ of the time you just shove all the poo poo in a dictionary and go to town on it. You look at the docs for the keys you want, put the keys you have, and then turn it to JSON through serialization or some poo poo that just translates everything for you. A language like python even lets you turn a dictionary directly into named arguments of a function call if you want. You think about types all the time because that's how you should build systems in a statically typed language with a decent type system; types first. You just happen to carry that baggage into the dynamic langs you use.
|
|
#
?
Feb 25, 2017 14:39
|
|
|
comedyblissoption posted:the thing with dynamic typing is you're still constantly thinking about types. you can't program without thinking about types. it's just all implicit and the only thing you're really saving is the time spent typing the type constraints and the type definitions. finally, a new shaggar
|
|
#
?
Feb 25, 2017 14:51
|
|
|
comedyblissoption posted:the thing with dynamic typing is you're still constantly thinking about types. you can't program without thinking about types. it's just all implicit and the only thing you're really saving is the time spent typing the type constraints and the type definitions. yep it turns out my types are pretty simple though because i'm not slapping together partial functions inside something about to be cps transformed so that i can define a strict evaluation order
|
|
#
?
Feb 25, 2017 14:53
|
|
|
i love static typing enthusiasts they come up with every single excuse as to why their approach is objectively better, and then write you a system that gives you stack traces in the type inference engine and not your actual code tef fucked around with this message at 15:03 on Feb 25, 2017 |
|
#
?
Feb 25, 2017 14:58
|
|
|
i mean it's not like static type systems have type holes in them (they do), or you have to work around the limitations to express code trivial with runtime checks (you do) or have to resort to runtime checks anyway behind the scenes because let's be honest length checking is hard
|
|
#
?
Feb 25, 2017 14:59
|
|
|
i mean static type systems are "technically correct" and are just as friendly and nice to work with as "technically correct" people
|
|
#
?
Feb 25, 2017 15:02
|
|
|
static typing is objectively better
|
|
#
?
Feb 25, 2017 15:29
|
|
|
typing gets confused to a great extent because people confuse the abstractions attached to it and the ability to declaratively state constraints about data the former overappreciated and the latter underappreciated mostly
|
|
#
?
Feb 25, 2017 15:49
|
|
|
i like static typing because i'm a big ol' idiot and it lets me offload thinking to my tools
|
|
#
?
Feb 25, 2017 16:53
|
|
|
can i get the room's feelings on putting retry logic in client apps just because your loving microservices are so goddamn unreliable they constantly throw weird errors? i'm very much against it because i've written microservices that loving work reliably, but idk how to fight this awful fuckshit team who's so insistent on me changing my apps!
|
|
#
?
Feb 25, 2017 16:57
|
|
|
I worked with a python library where all function arguments were kwargs so I had to look up the docs for every single function rather than having the IDE tell me what to expect and that sucks but that's not really dynamic typings fault I guess.
|
|
#
?
Feb 25, 2017 17:00
|
|
|
i like languages with optional type checking bc then you can add typehints if you want or just leave them off because sometimes you don't really need to be reminded of what goes where
|
|
#
?
Feb 25, 2017 17:01
|
|
|
FormatAmerica posted:can i get the room's feelings on putting retry logic in client apps just because your loving microservices are so goddamn unreliable they constantly throw weird errors? the ideal way to think about this is that the microservice extends a small bit into the client app rather than having the client app talking over the network that is, the app should talk to a service that goes reasonable lengths to stay stable and actually make sure requests get services, but it is not really an important detail if that service happens to run in the same memory space as the client app. abstraction layers should seldom coincide with physical layers for example, since the physical layer is bound to have complex failure scenarios, and you will want both sides of such a failure to exist within the same unit of abstraction
|
|
#
?
Feb 25, 2017 17:23
|
|
|
i dont think about types
|
|
#
?
Feb 25, 2017 18:39
|
|
|
I like programming with types it scratches an itch in my brain
|
|
#
?
Feb 25, 2017 18:50
|
|
|
i use touch typing
|
|
#
?
Feb 25, 2017 19:01
|
|
|
FormatAmerica posted:can i get the room's feelings on putting retry logic in client apps just because your loving microservices are so goddamn unreliable they constantly throw weird errors? a poorly written service is a thing but you should have retry logic around throttling and network failures that is just baked into every client. and some services also expose guarantees or constraints around APIs that you need to accommodate for, like eventually consistent propagation of updates. you also need to consider how your application behaves when that service goes down or (even worse imo) that service becomes slow or intermittently fails. you need to consider how your service will degrade due to dependency failures and design accordingly. and then fix it when you find out what you missed. so I would say (not knowing if you're consuming a poorly designed service) that you need to lean into the fact that you're talking over a network and that people are talking over a network to your service.
|
|
#
?
Feb 25, 2017 19:05
|
|
|
FamDav posted:a poorly written service is a thing but you should have retry logic around throttling and network failures that is just baked into every client. and some services also expose guarantees or constraints around APIs that you need to accommodate for, like eventually consistent propagation of updates. thanks to all for the effortposts, our issues are mostly microservices calling other services & failing further up the stack then sending us back a nastygram but you have inspired me to at least handle client to server network issues with a retry.
|
|
#
?
Feb 25, 2017 19:43
|
|
|
FormatAmerica posted:thanks to all for the effortposts, our issues are mostly microservices calling other services & failing further up the stack then sending us back a nastygram but you have inspired me to at least handle client to server network issues with a retry. you can also consider throttling requests to that service on your end, if you have reason to believe your request rate is causing issues
|
|
#
?
Feb 25, 2017 19:51
|
|
|
FormatAmerica posted:thanks to all for the effortposts, our issues are mostly microservices calling other services & failing further up the stack then sending us back a nastygram but you have inspired me to at least handle client to server network issues with a retry. wait so did you really think the network works 100% of the time.
|
|
#
?
Feb 25, 2017 20:22
|
|
|
|
| # ? May 22, 2024 07:08 |
|
|
MeruFM posted:lol okay i dont mean learn x86 at all. imo i think x86 needs to be retired, cisc architectures are such an outdated doctrine and its embarrassing that it's been allowed to exist this long.
|
|
#
?
Feb 25, 2017 20:27
|
|