Java is a statically typed language which couldn't care less for type safety
-
dependency injection.
This is a fancy way to say "pass interfaces into functions", isn't it?
And when people go to do it, they fuck it up.
I'm sure I won't.
:DThat's what scares me about Functional Programming entering the mainstream. Not the paradigm itself, which has some really good ideas, but how people are going to contort it into a fucked up mess and produce code that haunts me in my dreams.
You can write FORTRAN in any language...
-
This is a fancy way to say "pass interfaces into functions", isn't it?
Yeah, this stuff isn't complicated but people still aren't getting it. What to do?
Some seem to think the answer is to dis-empower other devs by leaving out language features: lambdas, macros, operator overloading, implicits, etc. But then we're hindering ourselves. I know how to use that stuff and I don't want to be hindered.
-
Yeah, this stuff isn't complicated but people still aren't getting it. What to do?
Some seem to think the answer is to dis-empower other devs by leaving out language features: lambdas, macros, operator overloading, implicits, etc. But then we're hindering ourselves. I know how to use that stuff and I don't want to be hindered.
As a developer who takes pride in their work, I feel it is incumbent upon me to get familiar with any new concepts I come across which I don't understand. I have the duty to raise myself up, rather than demanding that everyone else stoop to my level.
I would suggest "better interviewing techniques", but then again, I never get invited to conduct interviews anyway...
-
This is a fancy way to say "pass interfaces into functions", isn't it?
Not exactly. Inversion of Control is "pass interfaces into functions". Dependency Injection is when a unit of code says "I need the current implementation of this interface" and a third piece of code is responsible for searching through registered providers for the current implementation.
-
Yeah, this stuff isn't complicated but people still aren't getting it. What to do?
Stop calling it by the dumb name "dependency injection"? Which is the WORST terminology? Just a thought.
It's not as bad as "inversion of control" which requires (to understand the terminology) that the programmer have anthropomorphized her code into "controlling" things. If you don't have this weird mindset where your classes are entities capable of "controlling" other entities, that term is utterly opaque.
Some seem to think the answer is to dis-empower other devs by leaving out language features: lambdas, macros, operator overloading, implicits, etc. But then we're hindering ourselves. I know how to use that stuff and I don't want to be hindered.
The solution is to add those features in such a way that everybody can use them. Probably a lost cause in C++, but in the C# world it's working pretty damned well.
-
I'd say you have it the other way around -- DI is "pass interfaces/functions/classes (aka tools) into functions", IoC is when you have a framework that's responsible for searching for implementations when asked "I need the current implementation of this interface"
(BTW -- there is nothing that prohibits you from injecting a concrete class type or even a function, in languages that support such)
The solution is to add those features in such a way that everybody can use them. Probably a lost cause in C++, but in the C# world it's working pretty damned well.
I'll agree here -- Python does a pretty good job overall with this sort of thing as well. C++:- didn't have the benefit of quite as much experience with overloaded operators, OO-style generics (vs. FP implementations of generic concepts a la ML and Haskell), and such
- had to jump through a lot more compiler hoops because of the need to function on a minimal runtime (this is why templates look weird if you're used to C# generics)
-
Dependency Injection is when a unit of code says "I need the current implementation of this interface" and a third piece of code is responsible for searching through registered providers for the current implementation.
I think even this is too specific; e.g. that's a way to get dependency injection.The point of DI is to try to avoid referring to concrete classes ever. Obviously this is impossible because you can't have interfaces all the way down, but even if you are good about always using interfaces in parameters and stuff, you still need to know the concrete class when you
newit.DI says "get rid of as many
news as you can". You can do that by pushing the responsibility for creating an object fromfoo()to its caller (as tarunik said), by using abstract factories, or with a fancy DI framework that goes and looks up the current implementation, but fundamentally the reason you're doing this is to get rid ofnews because those always refer to concrete classes.(Or at least that's my take anyway. I program in C++ on code bases that don't make much use of interfaces. Most of the above is what I've taken away from a couple Google tech talk videos. So take it for what it's worth.)
-
I'd say you have it the other way around -- DI is "pass interfaces/functions/classes (aka tools) into functions", IoC is when you have a framework that's responsible for searching for implementations when asked "I need the current implementation of this interface"
Wikipedia disagrees with you. Not that Wikipedia is the final word, but it is something.
[quote=Wikipedia]
In software engineering, dependency injection is a software design pattern that implements inversion of control for software libraries. Caller delegates to an external framework the control flow of discovering and importing a service or software module. Dependency injection allows a program design to follow the dependency inversion principle where modules are loosely coupled.
[/quote]
-
Wikipedia disagrees with you. Not that Wikipedia is the final word, but it is something.
DI and IoC are oft-muddled by Javaites (and their C# counterparts) who only ever encounter DI in the context of Spring and friends.
I find that the meanings I use work much better when you're taking a DIY approach instead of relying on a framework to do it for you.
-
Sadly, the CLR does not offer an object system on par with that of one of the oldest languages, to the point where you cannot port CLOS to .NET.
Is CLOS good, or is its different-ness just the product of the "we are Lisp therefore we must do everything differently" mindset? Somewhere I read that CLOS didn't achieve wide adoption because each lone Lisp hacker had already macro-ed together their own object system when it arrived.
-
DI and IoC are oft-muddled by a lot of people.
Inversion of Control means an inversion of the traditional control flow of procedural programming, where your application code instruments library code to get something done. Instead, the library code instruments bits and pieces of your application.
Lambda delegates, callbacks, promises, evented systems, etc. are all things typically used for or with Inversion of Control.
DI (dependency injection) means the dependent bits of code you are calling out to are not looked up from inside your own code, but injected from the outside. You can either set all of that up by hand, or you can use a DI framework that uses IoC to instrument the construction of your classes for you in such a way that it can inject the dependencies for you.
I.e. IoC is one way to achieve DI.
-
simplicity of development.
So you don't use an IDE, then?
Because that's the only way I can comprehend any claim that dynamic languages are easier to use than static. There are so many ways IDEs can help you out when writing strongly-typed code; dynamic languages simply cannot compete.
-
So you don't use an IDE, then?
Because that's the only way I can comprehend any claim that dynamic languages are easier to use than static. There are so many ways IDEs can help you out when writing strongly-typed code; dynamic languages simply cannot compete.
Dynamic languages are kinda cool, at least on the outset, and have their uses.
But goddamn they can be such a pain to work with, and I highly prefer languages with strong types. Compile-time type safety FTW.
-
Dynamic languages are kinda cool, at least on the outset, and have their uses.
But goddamn they can be such a pain to work with, and I highly prefer languages with strong types. Compile-time type safety FTW.Eh, horses for courses. Both have their strengths and weaknesses. In an ideal world, you probably want your application logic written in a dynamically-typed language (so it's easy to iterate and deploy changes) running on an engine written in statically-typed language (so it's provably correct and fast)...
-
In an ideal world, you probably want your application logic written in a dynamically-typed language (so it's easy to iterate and deploy changes) running on an engine written in statically-typed language (so it's provably correct and fast)...
That's how I've been doing my apps for 20 years now. It's particularly effective for GUIs, where scripting the controller (and some pieces of the view sometimes) can make things enormously simpler.
-
In an ideal world, you probably want your application logic written in a dynamically-typed language (so it's easy to iterate and deploy changes) running on an engine written in statically-typed language (so it's provably correct and fast)
I think you just described Unreal Tournament (UnrealScript run by a C++ engine) ;)
-
I think you just described Unreal Tournament (UnrealScript run by a C++ engine) ;)
Which was ditched in UE4 since apparently maintaining it was a pain in the ass, so now it's just pure C++.
-
Seems an odd choice; they could have switched to Lua or something (I think the Source engine uses Lua for scripting?)
-
-
Seems an odd choice; they could have switched to Lua or something (I think the Source engine uses Lua for scripting?)
I think they wanted to move away from any sort of scripting languages for a number of reasons. Here's a post by a developer outlining why they went C++ only:
Why C++ for Unreal 4?
I was just curious, why did Unreal 4 decide to go with C++? I know Unity is in C#, and a lot of other games utilize C# as well as javascript. I was just curious, new programmer on engines here, only about a year and a half/2 years in, so go easy! Dev
EDIT: And I'm pretty sure no Valve game uses Lua, I think that's only GMod.
-
Here's a post by a developer outlining why they went C++ only:
I can understand the desire to get unified debugging (the other points in the linked post are more of a reflection of bad practices or the selection of a wrong interoperability abstraction level*) but the downside of that is when you're trying to deal with “scripted” events (as in things based on triggers, not the language they're written in). Some games use a lot of those, and having to do lots of C++ for what are essentially level design concerns is going to be nasty.
* That's a non-trivial task, real greybeard-level stuff. Get it wrong and you've got decades of pain ahead, yet you won't notice for years either.
-
but the downside of that is when you're trying to deal with “scripted” events (as in things based on triggers, not the language they're written in). Some games use a lot of those, and having to do lots of C++ for what are essentially level design concerns is going to be nasty.
Which I guess is what Blueprint is for (which is basically Kismet's replacement as a visual node-based scripting thingy, although I'm not sure if that completely negates the purpose of dropping Unrealscript for the aforementioned reasons ;))
-
Nothing stops you from embedding your own scripting language in UE4.
-
Which I guess is what Blueprint is for (which is basically Kismet's replacement as a visual node-based scripting thingy, although I'm not sure if that completely negates the purpose of dropping Unrealscript for the aforementioned reasons ;))
My prediction is that will grow into the sort of horrible morass they had before, because the forces pushing them towards that are the same. It takes a lot of experience and being forcefully strict about interface separation to avoid that black hole of suck.
They'd be better with a general scripting engine since that would at least be strongly disinclined to let the shit flow back that way. (It'd be like letting the requirements of the game engine flow into the C++ specification; not gonna happen…)
-
Some sound reasoning; still think there should be some form of scripting though
-
My prediction is that will grow into the sort of horrible morass they had before, because the forces pushing them towards that are the same. It takes a lot of experience and being forcefully strict about interface separation to avoid that black hole of suck.
Yeah, particularly since the "visual scripting" bit appeals to a lot of people who aren't comfortable learning traditional programming languages, and everybody seems to want to program their entire game with it, resulting in stuff like this:
And, of course, as they attempt to write more and more complicated logic, there's a stronger and stronger push to expose more of the C++ side to it...
-
I was going to say that I didn't see what was wrong with that image (it seems clear, concise, encapsulated) but then I realized that those three identical blocks in the lower left (and the two up top) were actually redrawn in each instance.
-
Yeah, particularly since the "visual scripting" bit appeals to a lot of people who aren't comfortable learning traditional programming languages, and everybody seems to want to program their entire game with it, resulting in stuff like this:
We see exactly the same thing with scientific workflows. People stuff more and more in, and the advantage of using a visual programming language drops off a lot faster than for a text-based language. You get to the point where using a text language gets easier, and then you're back with scripting, except now you've got an expensive-to-maintain mostly-useless GUI wrapped around the outside.
BTDTGTT-S
-
In an ideal world, you probably want your application logic written in a dynamically-typed language (so it's easy to iterate and deploy changes)
This is what I don't get. .Net provides an interesting case study since it you could choose to write particular assembly in a static language like C#, or a dynamic language like Python with IronPython. I don't see the choice of language making it easier or harder to iterate or deploy.
I once heard the same argument applied to putting business logic in stored procedures. A co-worker mentioned to me that an advantage of stored procedures was that he can fix a bug directly in production. The extra speed of deployment comes from not having any QA or discipline, not from the technology choice.
-
I don't see the choice of language making it easier or harder to iterate or deploy.
Languages with a REPL are much faster to iterate, as you can usually just edit a live version of the code in situ until it gives you what you want and then recover the program you want to make from the session log. They also allow types of debugging that are typically harder to achieve with a compiled programming language (such as being able to dynamically change things to introduce watching of the code without disrupting the flow of the program).
The cost is that they have more overhead than fully compiled programming languages need to have.
-
EDIT: And I'm pretty sure no Valve game uses Lua, I think that's only GMod.
Wut?
Valve uses Lua for things like weapons, and it's all over the place for heroes and gamestate in Dota 2
-
There are so many ways IDEs can help you out when writing strongly-typed code; dynamic languages simply cannot compete.
Dynamic languages are kinda cool, at least on the outset, and have their uses.But goddamn they can be such a pain to work with, and I highly prefer languages with strong types
You're buttuming that all dynamically typed languages are weakly and/or sloppily typed. News flash: the original wasn't, and neither are a few other common ones (such as Python)
-
You're buttuming that all dynamically typed languages are weakly and/or sloppily typed. News flash: the original wasn't, and neither are a few other common ones (such as Python)
But they don't go “Naughty programmer! SPANK! SPANK! SPANK!” when you change the type of value held in a variable. (The types are associated with the values, not the variables.)
-
Languages with a REPL are much faster to iterate, as you can usually just edit a live version of the code in situ until it gives you what you want and then recover the program you want to make from the session log. They also allow types of debugging that are typically harder to achieve with a compiled programming language (such as being able to dynamically change things to introduce watching of the code without disrupting the flow of the program).
Have you ever used Visual Studio? You can do all of those things in C#. Classic VB did it all back in 1993.
-
Have you ever used Visual Studio?
Have they ported it to non-Windows platforms?
(I've used similar things with Java. It's not the same as real REPL.)
-
So, you equate REPL with dynamic languages because you don't have access to good enough tools. Those of us who do don't see the benefit of dynamic languages. Please stop associating debugging flexibility with dynamic languages, it's associated with good tooling. As a counter example, VB Script is dynamic, but is a pain to debug.
-
Which was ditched in UE4 since apparently maintaining it was a pain in the ass, so now it's just pure C++.
Well, there's the whole Kismet visual scripting environment...
-
I think you just described Unreal Tournament (UnrealScript run by a C++ engine) ;)
I just described a lot of things :)
-
they could have switched to Lua or something
Lua is dreadful—nobody wants to use it...
-
Lua is dreadful
I'd characterise it as “hobbled” since it needs to be backed up with an embedding to do anything useful, and those embeddings are usually not very well done. But maybe you have different ideas about what the problems are; after all, I've not used it very much…
-
But maybe you have different ideas about what the problems are; after all, I've not used it very much…
If I want to use a scripting language which doesn't have proper integer support, and wonky ideas about variable scoping, then I would probably elect to use Javascript, TYVM. At least JS makes some kind of tenuous distinction between an Array and an Object and doesn't try to glom the two concepts together...
Lua, because storing doubles* in tables is all you'll ever need...
* OK, you can have strings and binary blobs as well. Truly with this type system, you are spoiling us...
EDIT: How did I forget: Lua "arrays" start their numbering from 1! It's just madness!
-
-
Here's a long page of people arguing about what number array indexes should start at on the Lua Users Wiki:
-
If I want to use a scripting language which doesn't have proper integer support, and wonky ideas about variable scoping, then I would probably elect to use Javascript, TYVM.
Lua 5.3 (the latest version of the language) introduced distinct integer and floating point number types. The default configuration is to use 64 bit integers and double-precision (64-bit) floats.
Personally, I find Lua's (block-level) variable scopes much more sane than JavaScript's (function-level). The only oddity is that undeclared variables default to global, but there are development-time and runtime tools to help catch unintentional globals.
-
The only oddity is that undeclared variables default to global,
Oh yeah, I forgot about that little gem..
Personally, I find Lua's (block-level) variable scopes much more sane than JavaScript's (function-level).
My point being: at least if you have some JS experience, you can put it on your résumé, and it might even get you a job...
-
-
Sounds a lot like Perl.
Yeah, except perl has
use warnings; use strict;so you can mitigate the damage...
-
So, you equate REPL with dynamic languages because you don't have access to good enough tools. Those of us who do don't see the benefit of dynamic languages. Please stop associating debugging flexibility with dynamic languages, it's associated with good tooling. As a counter example, VB Script is dynamic, but is a pain to debug.
Define "good enough tools" -- I've used VS before, and use it at my current job -- and sure as heck don't know how the heck you could Edit and Continue on a C++ header file!
-
-
Edit and Continue on a C++ header file!
Come now! You'd only do it for the inlined functions, constants and templates in that file.
http://c2.com/cgi/wiki?AlternateHardAndSoftLayers
