|
Building A Node.JS Server That Won’t Melt – A Node.JS Holiday Season, part 5
|
#
?
Jan 15, 2013 19:22
|
|
|
|
| # ? Jun 1, 2024 14:28 |
|
|
Otto Skorzeny posted:cscope has existed for a zillion years and is a good bit better than this smalltalk was cool because it nailed all that
|
|
#
?
Jan 15, 2013 19:26
|
|
|
Sang- posted:some language *used* to do this - compile no matter what but I can't remember its name Then you have completely agrammatical langs like tcl that just don't give fucks I had the best pl flame war once with this guy who thought XML was stupid because somehow tcl already did what XML did and everyone should just use tcl Gazpacho fucked around with this message at 19:32 on Jan 15, 2013 |
|
#
?
Jan 15, 2013 19:27
|
|
|
Gazpacho posted:I think pl/I was really big about accepting any statement however malformed tcl isn't agrammatical but tbf xml is stupid because lisp has always existed
|
|
#
?
Jan 15, 2013 19:32
|
|
|
Cocoa Crispies posted:yeah but powerful-langs (or maybe p-lang is short for "post-c language") basically require you to actually call the function to know if it exists, and most of them have a flexible concept of "argument" too First there was BCPL, then B, then C, now P-langs. That's how it goes, right?
|
|
#
?
Jan 15, 2013 19:38
|
|
|
protobuf is really cool and is going to make this project super easy thanks google. thoogle
|
|
#
?
Jan 15, 2013 19:44
|
|
|
Cocoa Crispies posted:tcl isn't agrammatical but tbf xml is stupid because lisp has always existed
|
|
#
?
Jan 15, 2013 19:52
|
|
|
Jerry SanDisky posted:protobuf is really cool and is going to make this project super easy Yes it is, I loving love it for making my client sever apis. Automatically versioned binary messages that are forward and backward compatible and are portable across languages? gently caress you SOAP Web Services
|
|
#
?
Jan 15, 2013 19:53
|
|
|
Not saying lisp is a bad language just drat unattractive, it's the Lyle lovett of langs
|
|
#
?
Jan 15, 2013 19:55
|
|
|
Gazpacho posted:Not saying lisp is a bad language just drat unattractive, it's the Lyle lovett of langs lisp is beautiful
|
|
#
?
Jan 15, 2013 20:37
|
|
|
Hard NOP Life posted:Yes it is, I loving love it for making my client sever apis. Automatically versioned binary messages that are forward and backward compatible and are portable across languages? seriously, protobufs is awesome. we use thrift here which as far as i understand is basically the same idea. but not having to deal with xml hell is fantastic.
|
|
#
?
Jan 15, 2013 20:53
|
|
|
lol @ people using language with bad xml support.
|
|
#
?
Jan 15, 2013 21:27
|
|
|
Shaggar posted:lol @ people using language with bad xml support. Platforms, not languages in my case.
|
|
#
?
Jan 15, 2013 21:34
|
|
|
one of my endpoints is java, shaggar
|
|
#
?
Jan 15, 2013 21:40
|
|
|
java makes xml ez.
|
|
#
?
Jan 16, 2013 00:19
|
|
|
guns make violence ez but it doesn't mean you should use either one
|
|
#
?
Jan 16, 2013 00:23
|
|
|
Shaggar posted:java makes xml ez.  says otherwise
|
|
#
?
Jan 16, 2013 00:23
|
|
|
idk what terrible stuff android Linux does but i wouldn't be surprised if they broke xml stuff on purpose
|
|
#
?
Jan 16, 2013 00:28
|
|
|
shags do you have any links to a good primer on dependency injection
|
|
#
?
Jan 16, 2013 01:22
|
|
|
#include export_import.h import java.j2ee.hypernate add clogo.jqueryscript
|
|
#
?
Jan 16, 2013 01:24
|
|
|
HORATIO HORNBLOWER posted:shags do you have any links to a good primer on dependency injection the picocontainer project site has a good overview. picocontainer is also a good starting point bc all it does is DI. i didn't really "get" DI when I started using Spring bc the DI stuff is mixed with a lot of other crap. useful crap but it gets in the way if you don't know wtf
|
|
#
?
Jan 16, 2013 01:29
|
|
|
Cocoa Crispies posted:xml is stupid because lisp has always existed this is only true for a few perverse misuses of xml (xaml, xslt) the core idea in lisp S-exprs was that code could be data, and data could be code xml is so, so far from that. it's just a machine-validate-able meta-document format: design a format, specify valid documents in either Schema or DTD form, and any documents in your format can be parsed and validated universally, by any xml parser anywhere. if your xml can be code, and your code can be xml, you are doing it wrong.
|
|
#
?
Jan 16, 2013 02:47
|
|
|
also lisp S-exprs didn't have any idea of validation. it either passed through a reader macro successfully, or it didn't. to recap: 1. the core ideas of xml are just completely missing from lisp. 2. if you add the core ideas of lisp to xml, you are a monster. xml should never be code 3. if you add the core ideas of xml to lisp, you're a weird bastard, just use a lisp xml library sheesh
|
|
#
?
Jan 16, 2013 02:49
|
|
|
HORATIO HORNBLOWER posted:shags do you have any links to a good primer on dependency injection tbh idk of any specific tutorials, as i learned most of it through a combo of it being thrust upon me and specific implementation goals. if you're talking specific implementations the spring documentation isn't bad. some of it is kind of lovely though, especially some of they're database stuff cause 1) its build around hibernate which is poo poo and 2) it features a lot of spring dependencies inside the code which defeats part of the point of DI. the real basic DI is pretty simple to get a handle on, imo. You've got some object that does stuff based on its internal fields. Where you would normally initialize those fields in the object itself, you can use DI to inject those fields at runtime. In spring you'd wire the beans up in a config file. This lets you do stuff like have different runtime implementations per environment/function w/out changing the code. You can also really easily test code since it involves configuration changes instead of code changes to inject different objects for testing. Also, a lot of sw8 frameworks use spring for stuff like CXF. This lets you do super rad poo poo like change the implementation of an object from a local class to a webservice with a few lines of xml and absolutely no code changes. its cool The biggest problems you'll run into are doing something dumb like putting a bunch of spring dependencies inside your code thus creating yourself a new static dependency on spring or overcomplicating things and injecting stuff that you don't need to. Theres also stuff like aspect oriented programming which is black magic. its useful for things like being able to mark all the methods in a class as @Transactional without touching the code. Or in spring-mybatis where it will map the abstract methods in an interface to a method in your mapping file and then generate the proxies automatically for you at runtime. but beyond that it is the realm of the dark gods where we dare not tread. Its cool stuff if you use it right and if you have some specific questions I could probably help more. trust ur instincts tho. bad DI smells the same as bad code.
|
|
#
?
Jan 16, 2013 02:53
|
|
|
Notorious b.s.d. posted:this is only true for a few perverse misuses of xml (xaml, xslt) lisp is trash for idiots. xml is the best. xaml is the best.
|
|
#
?
Jan 16, 2013 02:53
|
|
|
Nomnom Cookie posted:the picocontainer project site has a good overview. picocontainer is also a good starting point bc all it does is DI. i didn't really "get" DI when I started using Spring bc the DI stuff is mixed with a lot of other crap. useful crap but it gets in the way if you don't know wtf yeah that's a good point. spring kind of assumes you know what you want to do with DI first. also another tip: if you see dependencies in your code on the DI framework and they aren't A) at the starting injection point or B) part of a standalone DI utility library you've written then you should physically cringe cause it aint right.
|
|
#
?
Jan 16, 2013 02:57
|
|
|
Shaggar posted:lisp is trash for idiots. xml is the best. xaml is the best. xml has some flaws, but it is on balance pretty awesome xaml is a perverse misuse of good technology. xml brings no benefit to xaml as a language, and xml is too loving wordy to be syntax for code.
|
|
#
?
Jan 16, 2013 02:57
|
|
|
xaml isn't code its markup
|
|
#
?
Jan 16, 2013 03:01
|
|
|
a java class that isn't abstract or final is bad
|
|
#
?
Jan 16, 2013 03:06
|
|
|
Notorious b.s.d. posted:the core idea in lisp S-exprs was that code could be data, and data could be code see it's some genius poo poo in lisp, but when x86 does it
|
|
#
?
Jan 16, 2013 03:20
|
|
|
star war s-exprs
|
|
#
?
Jan 16, 2013 03:23
|
|
|
mccarthy never intended for s-exprs to be the standard syntax of lisp, that was a historical accident and measuring all other languages against it is the surest sign of a lisp fanboy
|
|
#
?
Jan 16, 2013 03:59
|
|
|
HORATIO HORNBLOWER posted:shags do you have any links to a good primer on dependency injection the basic motivation behind dependency injection is that a piece of properly modularized code can't do everything or else it isn't modular. the other pieces of code that particular piece of code needs to function correctly are its dependencies. the usual way of handling dependencies that people first learn about is using imperative code to pull them in during execution. if someone needs a connection to the database they'll start out by writing all the connection code where they need it when they first start programming. more experienced programmers know to stick it into its own module so that they can change the implementation without needing to change every place it's used. that's fine but what if you want to use a mock instead of the real thing or you need something from the servletcontext and it's a unit test? with dependency injection, you don't include the code needed to retrieve the dependency where you need it. instead the idea is to identify what the dependencies are and provide places where they can be injected (called injection points oddly enough). di frameworks usually offer options for stuff like setters, constructors or just sticking the values directly into fields. identification can be by class alone or might also include annotations to specify a particular type. the other half is making the code that provides the dependencies. in guice, the framework i have the most experience with, this is done by making modules which define one or more dependencies that they can provide using factory methods, constructors and various other options. if a module depends on something else to construct whatever it's providing, it simply declares its dependencies just like anything else. in other words di is recursive. an example would be a module providing a user's configuration settings. in order to get that, it needs the user id and a database connection. a different module might provide the user id by looking it up from the servlet session and a third module might provide a database connection from a pool. as an alternative you could just make a module that returns a mock user config and doesn't depend on anything. or you could have a module which just provides a hardcoded user id. when you run a program using di, you pass in a set of modules to produce an injector. the injector is what you use to actually start creating objects. for testing you don't need to provide every module needed in production and you can pass in different modules that exist only for unit tests. the framework then matches what the modules provide with what they depend on and wires each injection point to a provider. naturally having no provider that can satisfy a dependency is an error, as is having two ambiguous providers. (guice allows for multiple providers to inject a set or map containing one item from each provider.) it really does look like black magic at first, and i struggled with it myself. my advice is that so long as you remember that it's just matching providers up with injection points, dependency injection is surprisingly simple.
|
|
#
?
Jan 16, 2013 04:06
|
|
|
1337JiveTurkey posted:the basic motivation behind dependency injection is that a piece of properly modularized code can't do everything or else it isn't modular. the other pieces of code that particular piece of code needs to function correctly are its dependencies. the usual way of handling dependencies that people first learn about is using imperative code to pull them in during execution. gently caress this
|
|
#
?
Jan 16, 2013 04:13
|
|
|
dependency injection = the hotness way of bootstrapping the pieces of your app that different people are working on so that the app "just works" without you having to manage unique startup protocols for each piece
Gazpacho fucked around with this message at 04:28 on Jan 16, 2013 |
|
#
?
Jan 16, 2013 04:21
|
|
|
injection junction, what's your function hooking up DBs and services and caches
|
|
#
?
Jan 16, 2013 04:22
|
|
|
dependency injection sounds complicated because it provides flexibility in legacy languages like c# and java, and is usually explained in those terms in p-languages you can just replace classes or methods on classes to do things like swap in mock objects for tests or change storage backends
|
|
#
?
Jan 16, 2013 04:48
|
|
|
lol
|
|
#
?
Jan 16, 2013 04:50
|
|
|
Shaggar posted:lol ikr, no idea why legacy people make such a big deal out of something so simple
|
|
#
?
Jan 16, 2013 04:51
|
|
|
|
| # ? Jun 1, 2024 14:28 |
|
|
di kind of falls over when people overuse it and half their goddamned app is written in an xml file, with legit runtime config scattered throughout but god knows where. that's not really an improvement.
|
|
#
?
Jan 16, 2013 05:15
|
|
