• (disco) in reply to dkf

    I was actually thinking about reverse engineering the WXL, at least enough to work out what the interface actually is. The aim would be to get to the point where you can automatically generate an API description in some IDL (there's loads of variations on that theme) and then to use that to build the binding of choice.

    You shouldn't have to do this. That's the point.

  • (disco) in reply to Paul_Murray
    Paul_Murray:
    You shouldn't have to do this. That's the point.

    So? There's lots of things that one shouldn't have to do, but which end up being necessary anyway.

  • (disco) in reply to Gaska
    Gaska:
    In about two years, we will finally be able to.

    For how many years, meanwhile, we'll be able to do [something very obvious yet not implemented] in about two years?

  • (disco) in reply to another_sam
    another_sam:
    IDE support for languages is near-essential.
    I work just fine with simple text editor and terminal combo. It would be far better with IDE, but it isn't *that* important.
    another_sam:
    Dare I ask what problem domain you're working in where need for a GUI library intersects with the need for a systems programming language?
    Gamedev. It's nice to have e.g. a nice GUI level editor that renders the world with actual game code. Also, Rust is such a great language for things both low- and high-level that it's fit to replace both C++ and C# in their respective problem domains - it just needs to get more libraries.

    Fun fact: Rust 1.2 just came out the other day, and it has full support for dynamically sized types now (main benefit: upcasting smart pointers).

    PWolff:
    For how many years, meanwhile, we'll be able to do [something very obvious yet not implemented] in about two years?
    I don't understand what you mean.
  • (disco) in reply to CoyneTheDup
    CoyneTheDup:
    AFAIK, there's nothing wrong with this. You'd better not lietell Business LiesTM on your resume, but NP if they lietell Business TruthTM.

    That's how they see it.

  • (disco) in reply to Gaska
    Gaska:
    PWolff:
    For how many years, meanwhile, we'll be able to do [something very obvious yet not implemented] in about two years?

    I don't understand what you mean.

    Whenever someone says something will be done within the next two (or whatever number of) years, I sense a dèjá vu.

    (Most notorious example has been for a long time Duke Nukem Forever)

  • (disco) in reply to PWolff

    Ah, that. Well, we'll see in two years.

  • (disco)

    This is the best snoofle story I've read for a long time.

    Sadly my last job was a place not unlike this. I'm in South Africa and was contracted to a place called Multichoice. They are the satellite TV company here and are huge. I was employed as one of 15 people in two new SCRUM teams. All the developers were c# developers, but the work was mostly not c#. (We only found that out after we started.) And although business didn't know what they wanted, people could be fired for not delivering what was needed.

    I didn't know it when I started, but this project, called Evolution, had already been going, with deadlines forever being extended, for three years. Multichoice makes billions, so they were getting away with it. The contracting company suckered me in by offering me R10 000 more per month than what I was asking.

    Since we were all contractors, they had some legal leeway to fire people easily without worrying about the law, which only protects permanent employees in this country. They fired the whole other team of 8 people within three months of starting, and by the end of the year's contract I was the only original member left of my team. I was glad to get out of there.

  • (disco) in reply to Gaska
    Gaska:
    it just needs to get more libraries

    Hah! Libraries are the #1 thing that attracts developers to a language. Yes, you can do virtually anything in almost any language (provided you can make OS calls and are theoretically Turing-complete) but hardly anyone wants to have pull themselves totally up by their bootstraps; that'd be a lot of work…

  • (disco) in reply to dkf
    dkf:
    Hah! Libraries are the #1 thing that attracts developers to a language.
    Yep, that's definitely what happened with C++, JavaScript and Python 3.
    dkf:
    Yes, you can do virtually anything in almost any language
    But it takes a good language to do it neatly. For instance, I will never look at any new (to me) programming language that doesn't have built-in for-each on generators - it's simply such a great feature I almost can't live without it now.
    dkf:
    but hardly anyone wants to have pull themselves totally up by their bootstraps; that'd be a lot of work…
    "Hardly anyone" implies there *are* some people who would do it. And it takes only a single implementation to solve the "there's no lib for that" problem.
  • (disco) in reply to dkf
    dkf:
    Libraries are the #1 thing that attracts developers to a language

    Sometimes you don't have a choice:

    http://sdkdocs.roku.com/display/sdkdoc/BrightScript+Language+Reference

  • (disco) in reply to dkf

    Oh, and just to be clear - Rust already has dozens of very functional and well-polished libraries for many different things. It just doesn't have any complex native GUI solution like Qt, WinForms, JavaFX etc. But it's just a matter of time. Yes, this is the single most important framework to have, but it's still just one framework.

  • (disco) in reply to Gaska
    Gaska:
    But it's just a matter of time.

    Maybe. GUI toolkits are astonishingly complicated libraries, with very large amounts of asynchronous processing and a great deal of fiddly detail to get all the widgets to look and behave correctly.

  • (disco) in reply to dkf
    dkf:
    astonishingly complicated libraries, with very large amounts of asynchronous processing
    Frankly, that's **exactly the kind of software Rust was made for**, and most of its distinguishing features aim for **making exactly this kind of software easier to make**.
    dkf:
    a great deal of fiddly detail to get all the widgets to look and behave correctly
    While achieving perfection takes a lot of time, most applications suffice with fairly small set of available controls - buttons, text boxes, scroll bars. Once they're done, adding more is fairly simple - all the hardest problem are already solved by then. And this basic set of controls is certainly doable within span of few years, even including such nifty details as scrolling with arrows.

    Also, while reimplementing everything in pure Rust would take enormous effort, it's certainly doable in the long run, and in the mean time, a good wrapper for Qt or something else might pop up.

  • (disco) in reply to Gaska
    Gaska:
    a good wrapper for Qt or something else might pop up

    Isn't C/C++ code directly accessible for Rust? I mean, for Python you need wrappers like PyQT because there's no direct binding or it would take a lot of effort, but AFAIR Rust was built with this in mind.

  • (disco) in reply to FrostCat
    FrostCat:
    tarunik:
    Wouldn't you like it if your whole system was brought to its knees by a dialog box?
    The best way to get those idiots to see reason would be to write a demo for them that caused that to happen. Preferably when they were showing it to their bosses.

    "Oh, yeah, it does that sometimes. Unless you want to hire an high school kid to watch the server and click Ok, we can't do it that way. Of course, even if we did that, people who had to wait for him to notice it might get a bit upset, but at least we didn't make the BAs change their ideas."

    Note that as of Windows Vista/Server 2008 you don't actually get to see the dialog box, just the interactive services detection icon in the taskbar.
  • (disco) in reply to Eldelshell
    Eldelshell:
    Isn't C/C++ code directly accessible for Rust?
    Gaska:
    a **GOOD** wrapper
    <x>
  • (disco) in reply to Gaska
    Gaska:
    Once they're done, adding more is fairly simple - all the hardest problem are already solved by then.

    Get coding then! If you think all the problems are solved, it won't hardly take you any time at all!

  • (disco) in reply to dkf

    *adding project to my list of projects to do*

    1. Lua reimplementation
    2. Spaceship race game
    3. Adventure game engine
    4. Good terminal for Windows
    5. Resource management framework for games
    6. Limiter for my free-spinning mousewheel
    7. Custom gamepad with trackball on the left and 9 buttons on the right
    8. PCSX2 GPU plugin
    9. Qt wrapper for Rust
  • (disco) in reply to urkerab
    urkerab:
    Note that as of Windows Vista/Server 2008 you don't actually get to see the dialog box, just the interactive services detection icon in the taskbar.

    There, now you don't need that intern.

  • (disco) in reply to Gaska
    Gaska:
    I work just fine with simple text editor and terminal combo. It would be far better with IDE, but it isn't that important.

    I piss just fine in a bucket and wipe my ass with a sea sponge. It's be better with a toilet and toilet paper, but it isn't that important.

    Ok:

    1. For game dev, an IDE is fucking essential. Like, if there were ANY branch of software development where it's essential, that's it. How do you even manage your content? Jesus.

    2. If you know an IDE is better, why aren't you using one? "I know I'm using a worse solution because I keep using it because... shrug!" That makes no sense. Your brain is too fuzzy to even be building software at all.

    Gaska:
    Gamedev. It's nice to have e.g. a nice GUI level editor that renders the world with actual game code.

    If by "nice to have" you mean "FUCKING REQUIRED", then yes.

    Gaska:
    Fun fact: Rust 1.2 just came out the other day, and it has full support for dynamically sized types now (main benefit: upcasting smart pointers).

    Any language where you have to use the word "pointer" to describe anything in it is a shitty language.

  • (disco) in reply to Gaska
    Gaska:
    Yep, that's definitely what happened with C++, JavaScript and Python 3.

    I sense you're trying to be sarcastic, but that is what happened with C++ and JavaScript (and Python 3 hasn't been very successful.)

    C++ had the most important libraries in the 90s-- the ones that let you build hugely profitable GUI applications in Windows.

    JavaScript is so lousy with libraries nobody can keep them straight. This site alone uses like 47 of them.

  • (disco) in reply to Gaska
    Gaska:
    Oh, and just to be clear - Rust already has dozens of very functional and well-polished libraries for many different things. It just doesn't have any complex native GUI solution like Qt, WinForms, JavaFX etc.

    So it has everything except THE MOST IMPORTANT FUCKING THING FOR DEVELOPMENT.

    Awesome.

    Who's setting the priorities there at Rust Central? Mr. Magoo?

  • (disco) in reply to dkf
    dkf:
    Maybe. GUI toolkits are astonishingly complicated libraries, with very large amounts of asynchronous processing and a great deal of fiddly detail to get all the widgets to look and behave correctly.

    That's why you want to start early. You tackle the hard problems first, leave the easy problems to the open source numbnuts, since they're too incompetent to solve the hard ones anyway.

  • (disco) in reply to blakeyrat
    blakeyrat:
    I piss just fine in a bucket and wipe my ass with a sea sponge. It's be better with a toilet and toilet paper, but it isn't that important.
    Back in Roman Empire times, it made sense.
    blakeyrat:
    1) For game dev, an IDE is fucking essential. Like, if there were ANY branch of software development where it's essential, that's it. How do you even manage your content? Jesus.
    I've never seen anyone who uses IDE to manage resources like textures, models, levels, or anything non-code. Is the whole industry Doing It Wrong™?
    blakeyrat:
    2) If you know an IDE is better, why aren't you using one?
    Because there's no IDE for Rust? I would never work in Java, C#, C++, Python, PHP, Clojure, JavaScript, or any other language with a mature ecosystem without an IDE if I wasn't forced to by employer. But Rust is a young language and no one has yet developed a fully working IDE yet. There's [this Racer project](https://github.com/phildawes/racer) people tend to use to get code completion, and you can use GDB with Rust just fine, and there are attempts to stuff them both into Eclipse, Netbeans, Visual Studio, Vim and Atom, but they're all far from perfect - and I find fairly OK IDE far worse than no IDE at all.
    blakeyrat:
    If by "nice to have" you mean "FUCKING REQUIRED", then yes.
    [Merriam-Webster]() defines "require" as "to make it necessary for someone to do something". You don't need nice native GUI level editor that uses your game's code to render stuff to make levels for your game. You can get your stuff done too with just:
    • game-rendered GUI level editor that uses your game's code;
    • non-native-GUI level editor that doesn't use your game's code;
    • native-GUI level editor that doesn't use your game's code;
    • level editor with very primitive GUI;
    • level editor with no GUI;
    • no level editor at all

    and it all will work in the game just fine. Of course a nice tool shortens development time and is more pleasant to work with, but it's very far from "fucking required".

    blakeyrat:
    Any language where you have to use the word "pointer" to describe anything in it is a shitty language.
    Because?
  • (disco) in reply to blakeyrat
    blakeyrat:
    I sense you're trying to be sarcastic, but that is what happened with C++ and JavaScript (and Python 3 hasn't been very successful.)
    IIRC libraries were never C++'s forte, especially in the mid-80s and mid-2000s. JavaScript initially had no libraries at all. Python 3 might be not that successful, but there are people using it.
    blakeyrat:
    C++ had the most important libraries in the 90s
    Which is five to fifteen years after Stroustrup released the first edition of "The C++ Programming Language" book, which is the same kind of milestone as Rust 1.0 release. And Rust 1.0 release happened three months ago.
    blakeyrat:
    JavaScript is so lousy with libraries nobody can keep them straight. This site alone uses like 47 of them.
    Yet it's used by 99% of frontend web developers.
    blakeyrat:
    So it has everything except THE MOST IMPORTANT FUCKING THING FOR DEVELOPMENT APPLICATIONS I'M INTERESTED IN
    FTFY.
    blakeyrat:
    Who's setting the priorities there at Rust Central? Mr. Magoo?
    GUI libraries, just like 3D graphics libraries, XML parsing libraries, statistics libraries and many other kinds of libraries are not in the scope of Rust Central duties, at least currently - if by Rust Central you mean official Rust crew, who develop the language, the compiler and the standard library.
    blakeyrat:
    That's why you want to start early.
    It's still early. In two years, it will still be early.
  • (disco) in reply to Gaska
    Gaska:
    I've never seen anyone who uses IDE to manage resources like textures, models, levels, or anything non-code. Is the whole industry Doing It Wrong™?

    Actually, having something better than cobbled-together asset pipelines would be very nice -- the problem is that every game engine reinvents the asset management wheel in subtly different and square-ish ways, making it so that you can't really have a widely reusable integrated asset editing system in the same way you have an IDE. (You'd need a 3D editor with Blender-level scriptability to serve as a basis, first off, considering that you're dealing with a combination of artistic 3D modeling for characters and objects, something akin to BIM for indoor levels, heightmapping/terraforming for outdoor levels, and 2D image editing for textures and shader maps of various sorts. Never mind having to deal with audio assets....)

    blakeyrat:
    Any language where you have to use the word "pointer" to describe anything in it is a shitty language.
    Do we have to sentence you to writing Windows drivers in assembler for the rest of your life or something?

    You seem to have no comprehension of the fact that at the end of the day, there has to be code that's compiled down to machine language for your computer to run, and that code is going to have to deal with memory addressing at some point in its lifetime.

    Can we come up with a better way of expressing that in a high-level language than unrestricted pointers? Sure. But the underlying semantics of "this variable holds the address of something in memory" will not go away, and the ability to express that semantic in some way, shape, or form is one of the defining traits of a systems language (vs. an application or scripting language).

  • (disco) in reply to tarunik
    tarunik:
    Actually, having something better than cobbled-together asset pipelines would be very nice
    Agreed. But using programming IDE is a terrible choice for that.
    tarunik:
    You'd need a 3D editor with Blender-level scriptability to serve as a basis, first off, considering that you're dealing with a combination of artistic 3D modeling for characters and objects, something akin to BIM for indoor levels, heightmapping/terraforming for outdoor levels, and 2D image editing for textures and shader maps of various sorts. Never mind having to deal with audio assets...
    Have you ever heard of launching external tools from inside your application?
    tarunik:
    You seem to have no comprehension of the fact that at the end of the day, there has to be code that's compiled down to machine language for your computer to run, and that code is going to have to deal with memory addressing at some point in its lifetime.
    Actually, his criticism is right - the problem is, he thinks that every programming language that has pointers, deals with them in the exact same way as C and C++ (which is the worst way BTW, if you're not doing embedded/kernel/driver development).
    tarunik:
    Can we come up with a better way of expressing that in a high-level language than unrestricted pointers? Sure. But the underlying semantics of "this variable holds the address of something in memory" will not go away
    Sure it will. If it doesn't, your language has shitty abstraction over memory.
  • (disco) in reply to Gaska
    Gaska:
    Have you ever heard of launching external tools from inside your application?

    That's a valid approach as well; it depends on what route you wish to go down. I wonder if the whole "textures vs 3d objects" issue could be handled with some clever OLE-type trickery, even...

    Gaska:
    Actually, his criticism is right - the problem is, he thinks that every programming language that has pointers, deals with them in the exact same way as C and C++ (which is the worst way BTW, if you're not doing embedded/kernel/driver development).
    Which are exactly the applications that demand the most from a language's ability to go "down to the metal" and deal with the concepts the hardware provides. I agree that there are better ways to do it -- its just that we haven't found one that scores well for *both* memory-safety and power, yet.
    Gaska:
    Sure it will. If it doesn't, your language has shitty abstraction over memory.
    If you can come up with an abstraction over memory that is:
    • general enough to deal with memory-mapped I/O registers, program variables, and dynamically allocated objects, as well as corner cases like groveling through a stack frame
    • requires no garbage collection or other runtime-library support
    • can be supported on existing hardware without undue overhead (tagged pointers would be nice, but unfortunately, they tend to clash with other things chipmakers like to do)
    • and provides provable guarantees for some reasonable definition of "memory safety"

    I'd love to see it! (Rust is the closest I've seen, but it hasn't been pushed into enough applications yet for me to know if it can deal with those awkward cases, like memory-mapped I/O.)

  • (disco) in reply to Gaska
    Gaska:
    I've never seen anyone who uses IDE to manage resources like textures, models, levels, or anything non-code.

    You've never seen anybody in the game industry using Gamebryo, Torque, UnrealEd, Unity, CryEngine, IdTech, 4A, UbiArt Framework, etc, etc.

    Nobody. Ever uses any of those tools. In the game industry.

  • (disco) in reply to tarunik
    tarunik:
    You seem to have no comprehension of the fact that at the end of the day, there has to be code that's compiled down to machine language for your computer to run, and that code is going to have to deal with memory addressing at some point in its lifetime.

    Well duh.

    It's just that 99.9% of code shouldn't be that. And right now, something like 50% of code is.

  • (disco) in reply to blakeyrat
    blakeyrat:
    You've never seen anybody in the game industry using Gamebryo, Torque, UnrealEd, Unity, CryEngine, IdTech, 4A, etc, etc.
    None of them are IDEs in the way I understand it - which is text editor with syntax highlighting, code navigation (go to declaration etc.) and various other stuff directly related to writing code.
    blakeyrat:
    Well duh.

    It's just that 99.9% of code shouldn't be that.

    Do you mean JIT-ing into machine code is a bad idea? Or did you not understand what @tarunik was talking about?
  • (disco) in reply to Gaska
    Gaska:
    Do you mean JIT-ing into machine code is a bad idea? Or did you not understand what @tarunik was talking about?

    He's saying that your software probably isn't doing the JIT-ing. You're writing something that gets compiled, not compiling stuff or whatever. Probably.

  • (disco) in reply to Gaska
    Gaska:
    None of them are IDEs in the way I understand it - which is text editor with syntax highlighting, code navigation (go to declaration etc.) and various other stuff directly related to writing code.

    I think the problem is your definition of "IDE", not the products I mentioned.

    Do you think FlashBuilder is an IDE? Why/why not? Was it an IDE when it was Flash 8? Now you have me curious.

  • (disco) in reply to Gaska
    Gaska:
    Do you mean JIT-ing into machine code is a bad idea?

    Huh? I can't even figure out how you got from what I typed to here...

    Gaska:
    Or did you not understand what @tarunik was talking about?

    I believe I understand exactly what he's talking about.

  • (disco) in reply to blakeyrat
    blakeyrat:
    I think the problem is your definition of "IDE", not the products I mentioned.
    The problem with the term "IDE" is that its definition is very, very general, yet it's only ever used in a very, very narrow context. The popular definition of IDE is more or less "a text editor for programming that more or less understands what you're writing and actively helps you with it". So, while e.g. Unity fits the book definition, it doesn't fit the popular definition, and I meant the popular definition when I said that IDEs are a bad tool for organizing game assets.

    BTW - the very first example of "game IDE" you brought up, GameBryo engine, is a bunch of C++ libraries and several separate auxiliary applications like terrain editor or animation tool.

    blakeyrat:
    I believe I understand exactly what he's talking about.
    Okay, seems like I've got a little carried away and misread @tarunik's post. Sorry. I thought he was talking about that all code will eventually become assembly, while actually he meant that you need assembly to run any code other than assembly.
  • (disco) in reply to Gaska
    Gaska:
    The problem with the term "IDE" is that its definition is very, very general, yet it's only ever used in a very, very narrow context.

    ... by you it is. Apparently.

    I just consider it an environment for developing software which integrates several different tools to do so.

    You know, exactly like the term "integrated development environment" implies.

    Gaska:
    The popular definition of IDE is more or less "a text editor for programming that more or less understands what you're writing and actively helps you with it".

    I care not for what is popular.

    Gaska:
    BTW - the very first example of "game IDE" you brought up, GameBryo engine, is a bunch of C++ libraries and several separate auxiliary applications like terrain editor or animation tool.

    Gamebryo is an interesting example because its IDE (Creation Kit) is 99% wrangling meta-data (physics, AI, stats, damage, etc) and content, and the "code text editor" part is completely underdeveloped to the point of "barely present".

    Gaska:
    TW - the very first example of "game IDE" you brought up, GameBryo engine, is a bunch of C++ libraries and several separate auxiliary applications like terrain editor or animation tool.

    You are correct that Gamebryo itself isn't an IDE; I meant to type Creation Kit.

  • (disco) in reply to blakeyrat
    blakeyrat:
    ... by you it is. Apparently.
    Show me one source that refers to anything that isn't mainly a text editor as IDE. Just. One. Source.
    blakeyrat:
    You know, exactly like the term "integrated development environment" implies.
    Just like social justice implies social and justice.
    blakeyrat:
    Gamebryo is an interesting example because its IDE (Creation Kit) is 99% wrangling meta-data (physics, AI, stats, damage, etc) and content, and the "code text editor" part is completely underdeveloped to the point of "barely present".
    Are you sure you're talking about actual Gamebryo and not the Bethesda's in-house tooling?
    blakeyrat:
    You are correct that Gamebryo itself isn't an IDE; I meant to type Creation Kit.
    Yeah, I was right in previous paragraph. Still, have you ever wondered why it's called Creation Kit and not, say, IDE? And why no one refers to it as IDE? (Just tried to google it up and failed.)
  • (disco)
    Gaska:
    blakeyrat:
    I think the problem is your definition of "IDE", not the products I mentioned.
    The problem with the term "IDE" is that its definition is very, very general, yet it's only ever used in a very, very narrow context. The popular definition of IDE is more or less "a text editor for programming that more or less understands what you're writing and actively helps you with it". So, while e.g. Unity fits the book definition, it doesn't fit the popular definition, and I meant the popular definition when I said that IDEs are a bad tool for organizing game assets.

    I'm going to have to split the difference, here. Most Integrated Development Environments - including the much-maligned Emacs, if you want to called it one - are considerably more than just a programmer's editor (that's more the realm of Sublime Text, Scite, et al). They generally have features for organizing projects, including Make-style build management, multiple workspaces/projects; library managers; dependency managers; compiler option menus; resource file managers; macro recorders; plug-in systems for extensions; and so forth. Many, though not all, have visual UX development tools as well. No matter what you think of any particular IDE, you would have to agree that the difference between an IDE such as Visual Studio, Eclipse, NetBeans, QtBuilder, or MonoDevelop and a programmer's editor such as PyPE, Scite, Sublime Text, or Geany is considerable, even if there are some (Geany, Bluefish) that straddle the line between PE and IDE.

    That having been said, I agree with Gaska that Game Construction Kits such as Torque are something different from a classic IDE. Their focus is generally on a very narrow area of development, and most of their tools are focused on the process of constructing the game UX; the programming tools are often an afterthought. A GCK may have much in common with an IDE, and like an IDE usually will incorporate a programmer's editor, but they are their own class of tools.

    Gaska:
    blakeyrat:
    I believe I understand exactly what he's talking about.
    Okay, seems like I've got a little carried away and misread @tarunik's post. Sorry. I thought he was talking about that all code will eventually become assembly, while actually he meant that you need assembly to run any code other than assembly.
    Again, I think you are both missing the point: that for *some* classes languages, specifically system languages, require the ability to access memory references at a relatively low level of abstraction, but that this ability is not required or desirable for general applications programming. Yes, a *better* abstraction than raw typed pointers should be found, but at the end of the day, certain types of programs need to access memory more or less directly, and raw typed pointers, for better or worse, is the most common way to do this right now.

    EDIT: Wait, :WTF: just happened? I must have hit the wrong button by mistake, this was supposed to go in a different thread.

    bz - moved it here, where it seems to belong.

  • (disco) in reply to Gaska
    Gaska:
    Show me one source that refers to anything that isn't mainly a text editor as IDE. Just. One. Source.

    https://what.thedailywtf.com/t/the-coming-storm/50469/90?u=blakeyrat

    Gaska:
    Yeah, I was right in previous paragraph. Still, have you ever wondered why it's called Creation Kit and not, say, IDE? And why no one refers to it as IDE? (Just tried to google it up and failed.)

    It's an IDE whether or not people call it one.

  • (disco) in reply to blakeyrat
    blakeyrat:
    It's an IDE whether or not people call it one.
    This is the most stupid thing I heard all week. And it's just Tuesday!

    I'm done.

  • (disco) in reply to ScholRLEA
    ScholRLEA:
    Their focus is generally on a very narrow area of development, and most of their tools are focused on the process of constructing the game UX; the programming tools are often an afterthought.

    So?

    What in that sentence disqualifies Creation Kit from being an integrated development environment? It's an environment. It contains several tools all tightly-integrated. And its purpose is software development.

  • (disco) in reply to ScholRLEA
    ScholRLEA:
    Yes, a better abstraction than raw typed pointers should be found, but at the end of the day, certain types of programs need to access memory more or less directly, and raw typed pointers, for better or worse, is the most common way to do this right now.
    It's ironic how you emphasize the importance of raw pointers when working on a such low level you can't do any abstraction, while pointers themselves are abstraction over memory addresses.
  • (disco) in reply to ScholRLEA
    ScholRLEA:
    Yes, a better abstraction than raw typed pointers should be found, but at the end of the day, certain types of programs need to access memory more or less directly, and raw typed pointers, for better or worse, is the most common way to do this right now.

    I've been considering a notion of pointer "kind" actually -- where that "kind" would be associated with a memory region. For instance, a pointer to code would be one "kind" (basically, a function pointer), while a pointer to static variables would be another "kind", and a pointer to some fixed address (such as a MMIO reg) would be yet another "kind", likewise for pointers to stack variables and pointers to dynamically allocated memory.

  • (disco) in reply to Gaska
    Gaska:
    This is the most stupid thing I heard all week.

    You are dealing with a person who thinks "it doesn't work the way I think it should" is the definition of "bug".

  • (disco)

    Have any of you noticed that @blakeyrat hasn't answered why languages with a word "pointer" anywhere in them or in their derivative works are inherently bad?

  • (disco) in reply to Gaska
    Gaska:
    Have any of you noticed that @blakeyrat hasn't answered why languages with a word "pointer" anywhere in them or in their derivative works are inherently bad?

    Yes. He's constitutionally incapable of admitting he's wrong, so when he shuts up on a topic, that's how you know he's at least realized he's wrong.

  • (disco) in reply to FrostCat

    Blakey providing one of the only two instances of where he admitted he was slightly off the truth in 3... 2... 1...

  • (disco) in reply to Gaska

    I'll bet you a pendantry badge that he doesn't.

  • (disco) in reply to antiquarian

    You're on. But only if him saying that he CBA to dig it up counts as my win.

Leave a comment on “The Coming Storm”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article