|
Do you guys know if the recent eHarmony breach was php-based? I noticed they're running php and their press release said 'third party dlls' so I'm just assuming...
|
# ? Feb 11, 2011 22:55 |
|
|
# ? Jun 3, 2024 22:09 |
|
These things seem like they're almost always SQL injection, which is revolting.
|
# ? Feb 11, 2011 22:56 |
|
|
# ? Feb 13, 2011 20:02 |
|
no, you fool, don't you remember what happened the last time somebody posted Minecraft code in here?! but anyway code:
|
# ? Feb 13, 2011 20:09 |
|
Janin posted:
|
# ? Feb 13, 2011 20:51 |
|
zootm: Wouldn't it make more sense to make methods like that take no arguments and access a static Random instance somewhere if they need one?
|
# ? Feb 13, 2011 20:59 |
|
zootm posted:This is apparently a method which can return a varied number (using the Random) or a constant depending on what type of block (allegedly what the class represents) it is. It's sadly not a coding horror. Edit: aw what the gently caress
|
# ? Feb 13, 2011 21:00 |
|
zootm posted:This is apparently a method which can return a varied number (using the Random) or a constant depending on what type of block (allegedly what the class represents) it is. This sounds as abominable as copious goto usage. Is there a justification for it?
|
# ? Feb 13, 2011 22:19 |
|
The Reaganomicon posted:This sounds as abominable as copious goto usage. Is there a justification for it? What is so abominable about it? Some blocks always spit out the same number of items, some blocks spit out a random number and use the passed in RNG. This one is for a particular block that produces four of something. But it has to conform to the block interface so it just doesn't do anything with the Random. As to why he doesn't just use a public static RNG elsewhere, I don't know but that doesn't make this abominable
|
# ? Feb 14, 2011 01:26 |
|
Internet Janitor posted:zootm: Wouldn't it make more sense to make methods like that take no arguments and access a static Random instance somewhere if they need one?
|
# ? Feb 14, 2011 01:47 |
|
zootm posted:Maybe. I don't think that it's a terrible horror, though. Avoiding centralised static instances isn't a particularly poor coding pattern, given that even in this case it couples everything that uses a Random together. Having said that passing the Random in to the constructor might have made it easier to deal with, and the static reference would hardly be a sin in a monolithic codebase like Minecraft or 90% of other software. Yeah, I'm sure he's doing it this way so he can pass in a mock Random object from all his unit tests.
|
# ? Feb 14, 2011 04:46 |
|
No Safe Word posted:What is so abominable about it? Oh whoops, I completely misinterpreted that code. Shouldn't post while tired.
|
# ? Feb 14, 2011 06:51 |
|
quote:When you define static fields (also called class fields) of type String, you can increase application speed by using static variables (not final) instead of constants (final). The opposite is true for primitive data types, such as int. http://docs.blackberry.com/en/developers/deliverables/5716/Using_static_vars_for_strings_447038_11.jsp
|
# ? Feb 15, 2011 21:14 |
|
Lysandus posted:http://docs.blackberry.com/en/developers/deliverables/5716/Using_static_vars_for_strings_447038_11.jsp Oh god, this is a Blackberry JVM implementation only thing, right?
|
# ? Feb 15, 2011 21:19 |
|
It looks like the Blackberry JVM is really bad:quote:Optimizing division operations
|
# ? Feb 15, 2011 21:30 |
|
Did RIM do the Joel Spolsky thing and use an intern who didn't know Java or the language he was working in in order to write a JVM that bad?
|
# ? Feb 15, 2011 21:43 |
|
Ugg boots posted:Oh god, this is a Blackberry JVM implementation only thing, right? Thankfully yes.
|
# ? Feb 15, 2011 21:47 |
|
It's probably a straightforward interpreter, with zero optimization:quote:Optimizing subexpressions
|
# ? Feb 15, 2011 21:47 |
|
Scaevolus posted:It's probably a straightforward interpreter, with zero optimization:
|
# ? Feb 15, 2011 21:58 |
|
Wouldn't replacing division with bitshifts be the compiler's responsibility, and not the interpreter? As for the Minecraft code, isn't the real WTF that all of his blocktypes are defined by the code instead of in a property file or separate scripting language? I realize this guy wrote 99% of the code by himself but I can't imagine any artists or game designers that want to write Java code just to add in a few new assets.
|
# ? Feb 15, 2011 23:04 |
|
Outlaw Programmer posted:Wouldn't replacing division with bitshifts be the compiler's responsibility, and not the interpreter? No. If blocks can have different behaviors based on their type then it's not really a horror to implement those behaviors in code. Where the code is stored isn't really of concern - if a game designer wanted to create a new block type with its own custom behaviors they'd have to write code no matter what. Implementing something that lets you write the code in a language other than Java is a ton of work for no gain (everyone working on the project right now knows Java ... at least, for some definition of "knows") As for art... well, if he's hardcoding the art assets then yeah that's stupid but I doubt his texture files are actually stored in the java code. And it isn't really dumb to use constant strings to refer to your art assets either. Depending on the design, that might make it harder to have many different block graphics that all share a blocktype, but if it's all done through polymorphism and instance properties then that's pretty trivial too.
|
# ? Feb 15, 2011 23:49 |
|
Scaevolus posted:It looks like the Blackberry JVM is really bad Speaking as someone who's had the misfortune to do Blackberry development - yes, the Blackberry JVM and runtime libraries all belong in this thread. gently caress RIM, and gently caress the Blackberry. Ryouga Inverse posted:No. If blocks can have different behaviors based on their type then it's not really a horror to implement those behaviors in code. Where the code is stored isn't really of concern - if a game designer wanted to create a new block type with its own custom behaviors they'd have to write code no matter what. Implementing something that lets you write the code in a language other than Java is a ton of work for no gain. Untrue. If that were the case, languages like Lua wouldn't be showing up all over the place. Pulling this sort of game logic (as opposed to engine logic) into external scripts has a number of benefits, including making it a shitload easier to mod, and making development easier because you no longer have to recompile the entire game every time to change something - just "/reload" from in game and your changes are ready to be tested. This also means you can make your game crazy moddable without exposing the guts of the engine to everyone, although in Minecraft's case specifically the obfuscation used is so pitiful that it hardly matters. It's not "a ton of work" either; if you're using something like Lua, there are seamless or nearly-so Java APIs to it. It's trivial if the engine is designed with this in mind from day one, and even retrofitting it in isn't very hard.
|
# ? Feb 16, 2011 00:37 |
|
Ryouga Inverse posted:No. If blocks can have different behaviors based on their type then it's not really a horror to implement those behaviors in code. Where the code is stored isn't really of concern - if a game designer wanted to create a new block type with its own custom behaviors they'd have to write code no matter what. Implementing something that lets you write the code in a language other than Java is a ton of work for no gain (everyone working on the project right now knows Java ... at least, for some definition of "knows") I can kind of see that, but it seems like the different blocks are 99% similar. I think he's doing something like: code:
code:
|
# ? Feb 16, 2011 01:48 |
|
I know we build lots of apps which, at least initially, are configured via compiled code. But the configuration bits are written to be externalized when we need to fob that bit off to folks who don't do C#. It is a very trivial thing to load an object hierarchy from structured data if you build the hierarchy to be data in the first place. On the flip side, you have a very configurable, testable extensible system. The blackberry platform is a coding horror from what I understand. Unfortunately we've got them deployed to 85% of our work force, so any mobile app we use either has to work well on a BB (good luck short of things hand-crafted by RIMM themselves) or I get to spend lots of time explaining why it won't work on your lovely blackberry.
|
# ? Feb 16, 2011 02:23 |
|
ToxicFrog posted:Untrue. If that were the case, languages like Lua wouldn't be showing up all over the place. Pulling this sort of game logic (as opposed to engine logic) into external scripts has a number of benefits, including making it a shitload easier to mod, and making development easier because you no longer have to recompile the entire game every time to change something - just "/reload" from in game and your changes are ready to be tested. Almost all individually (and many professionally) developed games start with behavior logic hard-coded. As they become successful, they shift models to pull the behaviors into external data files. Neither way is terrible, or cost-free. One should note it only makes development easier if you're spending a significant amount of time modifying script-effected-behaviors. Retrofitting, while not insurmountable, could easily take weeks given the existing code base. That's a lot of time without bug fixes, other features, or whatever. It's a trade-off (though I agree he should make the investment). Kelson fucked around with this message at 02:28 on Feb 16, 2011 |
# ? Feb 16, 2011 02:26 |
|
Kelson posted:Oh come on; pulling game logic into external script files provides some enormous advantages on big projects, but hefty costs initially [especially to retrofit]. Perhaps he should rend the behavior code free, integrate a scripting engine, and refactor surrounding code to handle scripts properly. Perhaps that's too time/effort intensive though. Agree with this completely. A lot of people seem to forget that Minecraft was originally made as a throwaway indy game but struck it big practically overnight. Notch didn't seem even almost prepared for MC to be as much of a success as it has been. edit: There's also the fact that even if he did go back and fix it all, he'd probably be writing it from scratch and would end up changing lots of tiny little things that would get at least half the community in a "NOTCH IS loving US AGAIN" uproar. The easiest way to imagine it for a software developer would be this; He made a nice little tool for a couple of friends, who then spread it out and now the whole company uses it, who then sell it and now it's a commercial product. Suddenly his little tool has millions of users who rely on the faults as much as they complain about them, and if he takes so much as a week off to do something other than expanding the product (Like, say, fixing all the quickly hacked-together code), half of the users lose their poo poo and send him death threats. AntiPseudonym fucked around with this message at 08:01 on Feb 16, 2011 |
# ? Feb 16, 2011 06:57 |
|
Outlaw Programmer posted:I think that might be better expressed in a properties file like: This is the fatal mistake made by frameworks like Spring XML, as well. As awful as Java can be, it is not improved by replacement with XML. These "configuration" files are always deployed along with the application and are never changed at run time. They dictate the wiring and behaviours of code and are rarely anything other than a representation of a shorter Java program. These configuration files are, in other words, code, albeit code with little to no compile-time checking and a more verbose syntax. Outlaw Programmer posted:Even without Lua or another scipting framework, externalizing these things can give you a lot of flexibility. This isn't just specific to Minecraft; I've seen it in production business code as well. Java developers are almost infamous for favoring complex type hierarchies when some other options might be simpler and more flexible. In any case, the trichotomy between "scripts", "configuration" and "code" is a false one. All three of these items are code describing the behaviour of the game world. The properties file example has literally no advantages over encoding the items in code unless 1) you plan on changing them a lot and 2) you have a lot of examples. The syntax is slightly less cumbersome than Java code, but it has less expressive power (unless you feel like going to town on that expression language you don't need) and introduces a new unnecessary syntax into your project. The Lua-like-language solution makes sense if one really does not want to encode the game world in Java (wouldn't blame you, although Lua in particular is usually used to avoid scripting game worlds in C or C++, which are considerably more dangerous to fool around with in a world description), but if you're comfortable writing your game world in Java there's no real problem with that here.
|
# ? Feb 16, 2011 11:49 |
|
Outlaw Programmer posted:Even without Lua or another scipting framework, externalizing these things can give you a lot of flexibility. This isn't just specific to Minecraft; I've seen it in production business code as well. Java developers are almost infamous for favoring complex type hierarchies when some other options might be simpler and more flexible. Main problem in doing that in config files with pure Java is the static nature of the language which sort of fights back quite heavily if you try to do anything dynamic with it. That said, adding any scripting language to the Java environment is nowadays laughably since there's JitLua, Jython, Groovy, Scala etc. etc. which all support hotloading scripts and interpreting the scripts either individually or doing a JIT compilation for that native bytecode goodness the oldschool Java devs are using as an argument against scripting. Also I think that the actual quoted block code is ugly anyway, why not just have the random in the class, it's called random for a reason and I really can't believe it would be too heavy to have multiple instances of Random around - if it is, inject it into class through constructor at least so that you can be clean about it.
|
# ? Feb 16, 2011 18:49 |
|
I haven't had the chance to read the full source code for Minecraft, but take a look at the list of classes, specifically all the ones related to Blocks: https://spreadsheets.google.com/ccc?key=0AgPl2O82XX1pdFp2SnQxZUNuVWVJeHl0eGRSdnRDNGc&hl=en&authkey=CJvxgKgM#gid=0 If you've ever played Minecraft, you'll see that most of the blocks (dirt, stone, sand, gravel, snow) are really similar. The differences between them are mostly superficial: their appearance, what tools work best on them, whether or not they are affected by gravity, etc. I feel that each of these behaviors would be better implemented as parameters or properties instead of subclasses. Anyway, I would agree that in many cases, I would rather just express this stuff in pure Java code. However, I feel like notch really backed himself into a corner here, maybe because he didn't anticipate how popular Minecraft would become. His inheritance approach probably did speed up his initial development, but now that there is demand for a true mod community, he might be better off with a different approach. In any case, I don't think this qualifies as a true "horror" so I apologize for the derail.
|
# ? Feb 16, 2011 19:06 |
|
quote:This is the fatal mistake made by frameworks like Spring XML, as well. As awful as Java can be, it is not improved by replacement with XML. These "configuration" files are always deployed along with the application and are never changed at run time. They dictate the wiring and behaviours of code and are rarely anything other than a representation of a shorter Java program. These configuration files are, in other words, code, albeit code with little to no compile-time checking and a more verbose syntax. This needed to be said. Shipping "configuration" files that your application code depends on being a certain way just to function is common horror that I don't think is called out enough.
|
# ? Feb 16, 2011 20:26 |
|
^^ I don't disagree, but where zootm's argument goes off the rails in the assumption that any use of external scripting or configuration falls into this category. The experience of Adobe, Blizzard, Gas Powered Games, Firaxis, and Relic directly contradicts this, and shows that such an architecture has very real benefits.
|
# ? Feb 16, 2011 21:06 |
|
Goddammit google docs. pre:1/17/2011 15:27:00,$0.8,$52519.8300000001,15805 1/17/2011 4:32:00,$50,$52519.0300000001,15150 1/16/2011 23:50:00,$20,$52469.0300000001,14868
|
# ? Feb 17, 2011 02:56 |
|
Who the gently caress uses floats to store monetary amounts
|
# ? Feb 17, 2011 03:09 |
|
ToxicFrog posted:Who the gently caress uses floats to store monetary amounts
|
# ? Feb 17, 2011 03:33 |
|
Google Docs is implemented in Javascript. If I understand correctly, JS numbers are ALL stored as 64-bit doubles.
|
# ? Feb 17, 2011 04:27 |
|
Internet Janitor posted:Google Docs is implemented in Javascript. If I understand correctly, JS numbers are ALL stored as 64-bit doubles. Yeah but still they should ditch the decimal point and treat the numbers as cents
|
# ? Feb 17, 2011 04:33 |
|
Sewer Adventure posted:Yeah but still they should ditch the decimal point and treat the numbers as cents It still isn't going to work if you do anything which involves multiplying by non-integral numbers such as interest rates. Even then the interest rates still won't work unless you can express them as the sum of several powers of two. The least that can be said is that they're not something like GTINs. Handling those unambiguously when reading in an Excel file is not fun.
|
# ? Feb 17, 2011 06:36 |
|
ToxicFrog posted:^^ I don't disagree, but where zootm's argument goes off the rails in the assumption that any use of external scripting or configuration falls into this category. The experience of Adobe, Blizzard, Gas Powered Games, Firaxis, and Relic directly contradicts this, and shows that such an architecture has very real benefits. In any case, though, I think the scripting approach is sound; I hoped to defend the non-scripting approach in the case where one has a relatively simple world and is already using a high-level (Java jokes go here) language. I didn't intend to malign scripting as a general approach, it's both sensible and proven.
|
# ? Feb 17, 2011 12:06 |
|
Outlaw Programmer posted:If you've ever played Minecraft, you'll see that most of the blocks (dirt, stone, sand, gravel, snow) are really similar. The differences between them are mostly superficial: their appearance, what tools work best on them, whether or not they are affected by gravity, etc. I feel that each of these behaviors would be better implemented as parameters or properties instead of subclasses. quote:Anyway, I would agree that in many cases, I would rather just express this stuff in pure Java code. However, I feel like notch really backed himself into a corner here, maybe because he didn't anticipate how popular Minecraft would become. His inheritance approach probably did speed up his initial development, but now that there is demand for a true mod community, he might be better off with a different approach.
|
# ? Feb 17, 2011 12:22 |
|
|
# ? Jun 3, 2024 22:09 |
|
zootm posted:I don't disagree with that in general but due to Java's general suckiness, passing in a dynamic value like this as a parameter is non-trivial. Unless you want to pass in an implementation of some obscene interface called BlockDispersalCalculator or something, you're stuck. It is a language limitation though, what you suggest is generally sensible. Correct me if I'm wrong, but by passing in a dynamic value you don't mean passing in an enum value do you?
|
# ? Feb 17, 2011 15:47 |