|
eschaton posted:that’s a fine way to do things in Smalltalk, it’s clear there that everything is a message-send including iteration for all of ruby's manifold flaws, literally everything is message-sending. that is how the language worked from day one. this was, indeed, shaped by perl. all OO operations in perl are message-sending, influenced by smalltalk. ruby took the basic design of perl and extended it "backwards" to the language primitives. since ruby 1.0 had no perl 4.x to with which to remain backwards-compatible, it's turtles all the way down. there is little or no non-OO baggage hanging around that doesn't respond to the same message passing as user objects.
|
#
?
Oct 15, 2017 05:47
|
|
|
|
| # ? May 22, 2024 09:59 |
|
|
Notorious b.s.d. posted:this is entirely true, but it's equally true of virtualenv and python. deffo true honestly I kinda think this is why go took off so hard for tooling the whole gopath thing is the stupidest loving thing I've ever heard, and dependency management is braindead just like every other scripting language, but only one person actually needs to make the build work. if all you need is to run it, you just download the binary and it works
|
|
#
?
Oct 15, 2017 06:52
|
|
|
eschaton posted:the meta programming is way better in Lisp and Smalltalk than in Ruby because everyone’s special DSLs fit in with the base language so much more, and you can therefore develop much better tooling to work with them (and bring more of the standard tooling to bear too) what if we wrote a language for people who werent showboating assholes though
|
|
#
?
Oct 15, 2017 12:30
|
|
|
who would write it?
|
|
#
?
Oct 15, 2017 13:45
|
|
|
tef posted:what if we wrote a language for people who werent showboating assholes though this was supposedly an explicit design goal for go, and what we got instead was a language designed by showboating assholes for people they think are stupid and incapable of learning
|
|
#
?
Oct 15, 2017 13:55
|
|
|
Internet Janitor posted:this was supposedly an explicit design goal for go, and what we got instead was a language designed by showboating assholes for people they think are stupid and incapable of learning dunno about that, go used that an an excuse to avoid features rather than justify the featureset go wasn't so much designed but, it's part of a long series of hacks on C, starting with plan 9 so, plan9 c added things like anonymous structs alef came later, adding tuples, channels. (it also had generics) it wasn't until limbo came along that gc, modules, and types started coming after values then golang kicks off, from the original plan9 c compiler as for golang itself, it didn't really design that much, outside of the interface {}, gopath, and go fix/fmt and it still doesn't have much in the way of metaprogramming, or fancy semantics i'm not sure "showboating assholes for people they think are stupid and incapable of learning" is a reasonable descriptor when go came out, people were asking (and still) ask for a scalaz like feature set it wasn't so much that they thought go programmers were incapable of learning, or that they woudl be stupid but that the programs they were writing would be boring, not needing too much decoration that a new programmer shoudn't be burdened with learning a lof of new ideas to get started but yeah rob pike is a complete rear end in a top hat a lot of the time so i hear
|
|
#
?
Oct 15, 2017 14:49
|
|
|
in practice i have a pretty sour opinion of go because all of the go codebases i have seen, including those written by experts and contributors to the language itself, are composed of reams upon reams of repetitive, copy-pasted logic. whether it is the lack of generics driving people to manually template-expand custom data structures, the lack of exceptions driving people to manually template-expand error propagation, or the general fear and loathing of anything except endless fields of for loops cultivated by the community's vocal anti-intellectual stance, golang appears to cultivate technical debt. it's like a built-in linguistic broken-window scenario: tools to abstract and reuse code reasonably do not exist by design so huh I guess I'll just mound on more garbage. how simple. at the micro level, go code is indeed straightforward and permits local reasoning. i argue that the sprawl of go codebases more than compensates for this benefit.
|
|
#
?
Oct 15, 2017 17:11
|
|
|
Go just seems like it only aspires to fulfill Google's specific use case, which is C + garbage collection + static linking as a replacement for C for linux command line programs and network daemons, with the one modern addition of message-passing concurrency. It has already done that, so they don't really have any need for features like generics which would be necessary to turn it into a decent general-purpose language.
|
|
#
?
Oct 15, 2017 17:53
|
|
|
tef posted:but that the programs they were writing would be boring, not needing too much decoration ... java?
|
|
#
?
Oct 15, 2017 18:55
|
|
|
hackbunny posted:... java? honesty not that bad in hindsight, athough 1.5 could have happened quicker, and giving up on hardware jvms and embracing invoke dynamic, sure
|
|
#
?
Oct 15, 2017 20:39
|
|
|
Internet Janitor posted:in practice i have a pretty sour opinion of go because all of the go codebases i have seen, including those written by experts and contributors to the language itself, are composed of reams upon reams of repetitive, copy-pasted logic. yeah but the alternative is scalaz where it's one line of code you don't understand instead of 20 you do 
|
|
#
?
Oct 15, 2017 20:40
|
|
|
the solution to scalaz poo poo is simple. dont put that crap in the std.
|
|
#
?
Oct 15, 2017 20:48
|
|
|
tef posted:yeah but the alternative is scalaz where it's one line of code you don't understand instead of 20 you do literally the only other alternative yeah
|
|
#
?
Oct 15, 2017 23:59
|
|
|
gonadic io posted:literally the only other alternative yeah yep it's almost like it is a tradeoff rather than an arbitrary set of good and bad points like, having a language with relatively simple to implement features with a goal of fast compilation times might not end up with generics, or row polymorphism, or lenses or a language that's about expressing higher order combinators in a more object setting might not end up with boilerplate, but might have achingly slow compilation times and a definition of map that's worth writing a blog post about or a language that's about pay as you go, really means a lot of boilerplate because for the most part, as you go, you pay
|
|
#
?
Oct 16, 2017 01:57
|
|
|
As I grow older, I find my tastes change. My preferred codebases to fix bugs in and maintain are those that are relatively dense, long, and shallow. From that perspective, C and Go tend to be pretty readable. I've never written Go, and from what I've read, it's certainly not in any way a perfect language, but it doesn't offend me the way modern JavaScript practice does -- single-line functions in their own modules, blog posts by people who proudly proclaim they got rid of the if statement in their code... I do wonder how many people, especially proponents of metaprogramming, sit down and read code in one sitting like I do.
|
|
#
?
Oct 16, 2017 02:13
|
|
|
my totally flippant opinion of Go and Node.js is that they're the two communities that are the largest proponents of microservices because both language are lacking in terms of facilities to allow the abstractions and code organization required to make a large code base maintainable. The weaknesses in the languages must be palliated by architectural patterns which enforce concepts (i.e. demarcations of programming in the large vs. programming in the small) that are hard to express with the base language itself.
|
|
#
?
Oct 16, 2017 06:26
|
|
|
fits in nicely with that idea that design patterns exist to fill in holes in the language itself
|
|
#
?
Oct 16, 2017 06:45
|
|
|
it seems to me that microservices is more about a weird obsession with decoupling, taken to a ridiculous extreme. like for example each microservice must have its own database, and you have to create other microservices to keep those databases synced  I never noticed a correlation with specific programming languages, to me it feels more like a "natural evolution" to OOP's obsession with encapsulation and something about enterprise bureaucracies.
|
|
#
?
Oct 16, 2017 12:58
|
|
|
microservices are easier to patch, upgrade, and scale. they are good afaik.
|
|
#
?
Oct 16, 2017 13:06
|
|
|
Symbolic Butt posted:you have to create other microservices to keep those databases synced
|
|
#
?
Oct 16, 2017 13:28
|
|
|
Symbolic Butt posted:it seems to me that microservices is more about a weird obsession with decoupling, taken to a ridiculous extreme. like for example each microservice must have its own database, and you have to create other microservices to keep those databases synced this is the post of a person who read the wiki for microservices but has never worked with them in any capacity decoupling at the service level is super cool and good. obviously it can be taken to extremes but so can anything. just model your domains and find the logical separations between operations and their storage requirements
|
|
#
?
Oct 16, 2017 14:07
|
|
|
I'm just repeating what some microservices book said about how you should "refactor your monolithic database", maybe I just looked into a particularly terrible book? but idk, I vaguely remember some post from MALE SHOEGAZE describing this kind of dumbass attitude towards microservices databases, so I feel like that's a common approach that people take seriously.
|
|
#
?
Oct 16, 2017 14:34
|
|
|
microservices shouldn't have databases. the second they do, they're no longer micro.
|
|
#
?
Oct 16, 2017 15:24
|
|
|
people do take the microservice databases approach seriously and they are idiots
|
|
#
?
Oct 16, 2017 17:51
|
|
|
luv 2 cosplay as google whilst working for an idiot 4 man fart startup
|
|
#
?
Oct 16, 2017 17:54
|
|
|
necrotic posted:people do take the microservice databases approach seriously and they are idiots at my job each microservice has its own (mongo) database and entities that need to be available to multiple services (there are tons of them, as you can imagine) are synced by dumping them into kafka. it's a nightmare and the worst system i've ever dealt with. i've repeatedly broached the idea of consolidating the databases because there's just no reason to have them split up but "this would result in coupling" so it's never going to happen.
|
|
#
?
Oct 16, 2017 17:55
|
|
|
maybe you should decouple from your job
|
|
#
?
Oct 16, 2017 18:15
|
|
|
MALE SHOEGAZE posted:i've repeatedly broached the idea of consolidating the databases because there's just no reason to have them split up but "this would result in coupling" so it's never going to happen. you should have replied "with your face, fat chance"
|
|
#
?
Oct 16, 2017 18:18
|
|
|
MALE SHOEGAZE posted:at my job each microservice has its own (mongo) database and entities that need to be available to multiple services (there are tons of them, as you can imagine) are synced by dumping them into kafka. it's a nightmare and the worst system i've ever dealt with. a service should have its own persistent database when its the owner of that data and all state changes go through it. if another service can't correctly interact with that data through just the first service's apis then they probably aren't separate services, and they are already coupled. the only difference is with one service you have a tractable coupling problem and with 2+ you have an intractable coupling problem. Symbolic Butt posted:it seems to me that microservices is more about a weird obsession with decoupling, taken to a ridiculous extreme. like for example each microservice must have its own database, and you have to create other microservices to keep those databases synced having not worked at a very small company doing microservices, i always get the feeling that there is not enough consideration of ownership since everyone works on everything and you're operating at a scale that sweeping cross service changes are still fast. as you scale up and teams break apart and have more concrete ownership lines, state synchronization across service boundaries becomes somewhere between untenable and insane. at the same time you probably haven't developed an internal culture of being a good service owner, so you have difficult to use safely APIs and backwards incompatible changes out the wazoo. imagine (almost) every service you build as being owned by a separate team with a distinct reporting structure, whose customers have no idea what the internal implementation is and rely on documented and undocumented API behaviors, who get really pissed when you break any of those behaviors, and whose only means of contacting you is via a pager at 2am. if you do that, you'll probably write fewer and better services :/ tl;dr treat your service like its the kernel and your customers are userspace
|
|
#
?
Oct 16, 2017 18:27
|
|
|
also event-driven synchronization and post-hoc reconciliation are the 1920s devil and you should probably go somewhere else first for your fix consistent transactions are the bedrock of any successful large tech company, and its no surprise that google and amazon are built on top of consensus as a service
|
|
#
?
Oct 16, 2017 18:31
|
|
|
MALE SHOEGAZE posted:at my job each microservice has its own (mongo) database and entities that need to be available to multiple services (there are tons of them, as you can imagine) are synced by dumping them into kafka. it's a nightmare and the worst system i've ever dealt with. go work with your friend on that .net stuff
|
|
#
?
Oct 16, 2017 18:34
|
|
|
I haven’t really dealt with microservices, but I have dealt with a monolith that thought it was a microservice. It would call itself over HTTP.
|
|
#
?
Oct 16, 2017 18:35
|
|
|
MononcQc posted:my totally flippant opinion of Go and Node.js is that they're the two communities that are the largest proponents of microservices because both language are lacking in terms of facilities to allow the abstractions and code organization required to make a large code base maintainable. The weaknesses in the languages must be palliated by architectural patterns which enforce concepts (i.e. demarcations of programming in the large vs. programming in the small) that are hard to express with the base language itself. wow i never thought about it this way but you are completely loving right
|
|
#
?
Oct 16, 2017 19:07
|
|
|
fleshweasel posted:I haven’t really dealt with microservices, but I have dealt with a monolith that thought it was a microservice. It would call itself over HTTP. 
|
|
#
?
Oct 16, 2017 19:22
|
|
|
Suspicious Dish posted:As I grow older, I find my tastes change. My preferred codebases to fix bugs in and maintain are those that are relatively dense, long, and shallow. From that perspective, C and Go tend to be pretty readable. I've never written Go, and from what I've read, it's certainly not in any way a perfect language, but it doesn't offend me the way modern JavaScript practice does -- single-line functions in their own modules, blog posts by people who proudly proclaim they got rid of the if statement in their code... i wonder how many proponents of metaprogramming ever sit down and read someone else's code
|
|
#
?
Oct 16, 2017 19:27
|
|
|
JewKiller 3000 posted:wow i never thought about it this way but you are completely loving right also the people who gravitate towards bad langs like go and node tend to be those who dislike good frameworks, libraries, and standards which would require better language features.
|
|
#
?
Oct 16, 2017 19:31
|
|
|
fritz posted:i wonder how many proponents of metaprogramming ever sit down and read someone else's code I stopped touting metaprogramming after trying to use other people's code. What a loving nightmare and I hate that I ever liked it.
|
|
#
?
Oct 16, 2017 20:05
|
|
|
necrotic posted:I stopped touting metaprogramming after trying to use other people's code. What a loving nightmare and I hate that I ever liked it.
|
|
#
?
Oct 16, 2017 20:50
|
|
|
necrotic posted:I stopped touting metaprogramming after trying to use other people's code. What a loving nightmare and I hate that I ever liked it.
|
|
#
?
Oct 16, 2017 21:32
|
|
|
|
| # ? May 22, 2024 09:59 |
|
|
same these days i just do functional programming wank in js to scratch that itch instead lol react and its whole ecosystem do kind of act as enablers for it, too
|
|
#
?
Oct 16, 2017 21:39
|
|