BLitzMax - Improvements (Marks interview)
BlitzMax Forums/BlitzMax Programming/BLitzMax - Improvements (Marks interview)
| ||
| In the (excellent) 1st issue of BlitzMax coder magazine Mark mentioned a couple of ideas for improvements to BlitzMax which caught my attention #1 - Using := as a shortcut to declaring types ====================================== I'm definitely in favour of this one. Anything that reduces the amount of actual coding required. The idea is to remove the variable 'declaring' part and get Max to auto-declare accordingly As an example:
' BEFORE
Global font:TImageFont = LoadImageFont("somefont.ttf")
' AFTER
Global font:= LoadImageFont("somefont.ttf")
This method ties in nicely with existing shortcuts (such as :+ and :- ) Gets my vote #2 - Case sensitive naming ====================================== Touched upon as a consideration. Again, a welcome improvement However, this ideally would be an optional higher 'strict' level I can't think off hand what would make a good directive name (MegaStrict / UltraStrict) ? Strict SuperStrict and now .. the mother of all spankings: UltraStrict ' Case sensitive checking Feel free to discuss other 'improvements' you can think of One other suggestion I can think of is the If .. Then .. Else shortcut ' INSTEAD OF If spriteposX>gfxWidth Then AlienX=25 Else AlienX=45 ' SHORTCUT AlienX = (spriteposX>gfxWidth) ? 25 : 45 |
| ||
| Mark says in the article that are just some thoughts that would mean a blitzmax 2.0 and this is not even planned, so it may never happen... |
| ||
| erm, no and no :) #1 - makes code unreadable. Global someObject:= AmazingEngineFunctionSomewhere() Now I've got to go digging to see what someObject is and what it's capable of. #2 - It would be nice to force people to tidy up their code [when it's shared stuff, i don't care what you do behind closed doors :) ], but allows one hell of a sloppy mess to occur.... type mysooperdoopertype end type type Mysooperdoopertype end type type mysooperDoopertype end type Case sensitive coding needs to die with the dinosours imho. I've spent >10 years with C/C++ being completely anal about this, I don't want it to come back now :) |
| ||
| but allows one hell of a sloppy mess to occur.... It allows it, but who in their right mind is going to oppose case sensitivity because you're (as in you specifically, not the hypothetical) going to do something stupid with it? It'd be like saying you shouldn't be allowed to drink hot cocoa because someone might do something stupid like throwing it in their face for their own amusement, causing 2nd degree burns. |
| ||
| #1 would be handy for noobies, but I prefer to declare what the types are... matibee, in your example for #2 use Java convention, much nicer: Type MySooperDooperType End Type Also #3 Generics, would be very nice :) |
| ||
| Now I know why I'm not allowed hot drinks :D Crap example I know, but I am against case sensitivity. I like using case to make readable type and function names, but hate being nit picked on it at compile time. It's a throw back to age best forgotten. |
| ||
| Also #3 Generics, would be very nice :) now, we're talking. Yes please! |
| ||
| It's a throw back to age best forgotten. IIRC QuickBasic automatically reformatted your code to match a specific case: If you originally initialize mysooperdoopervariable and later type it as MySooperDooperVariable, all previous occurances will change to match the new case as well. |
| ||
| I'd like ( want) that in blitzmax we can redefine operator like (+,-,*,/) for 3d maths and matrix it will very very useful. |
| ||
| > It allows it, but who in their right mind is going to oppose case sensitivity because you're (as in you specifically, not the hypothetical) going to do something stupid with it? Might just be my luck, but EVERY time I've been given a C based program this has happened. (I've only worked on a handful and they were not the best - but even allowing it to happen is wrong, end of story) |
| ||
| I like using case to make readable type and function names, but hate being nit picked on it at compile time I agree that it's terribly annoying when it comes to constantly trying to please the complier. Java is a pain in the royal rear end just trying to get the code to compile. It's an endless cycle of [Complie/Run - fix complaint]It even complains on things like case 08 (where the padded 0 causes a mild tremor on the Richter scale for Java) Makes me want to rename it 'Anal' Provided Case sensitivity is an OPTION then coders can take it or leave it as they wish |
| ||
| Shortcuts are nice to save time while typing, but if you implement it it's best that the text gets converted directly like blIDE does. string$ gets converted to string:String directly for example. If someone would post examples with codes like 'AlienX = (spriteposX>gfxWidth) ? 25 : 45' I bet most new programmers won't directly understand what it means or does. It's because BlitzMax was a Basic language that I bought it in the first place and Basic needs to be read easily. |
| ||
| Java is a pain in the royal rear end just trying to get the code to compile. It's and endless cycle of [Complie/Run - fix complaint] You are kidding, obviously? Given that my editor flags incorrect variable names and such with a red underscore, it's hard to miss them. Actually, anyone coding Java without an IDE these days... Masochist? |
| ||
| Personally I did not like many of the suggested changes. := reminds me of Pascal, and why make it more to type when = is perfectly sufficient? Once you introduce := you now have to think about the meaning of what you're typing more. Also case sensitivity is the most annoying thing in the world about writing javascript, for example ... I would only be happy about it if it were totally optional, like a `CaseSensitive` command at the start of the program similar to Strict. |
| ||
| Mark says in the article that are just some thoughts that would mean a blitzmax 2.0 and this is not even planned, so it may never happen... Aye. He never said anything of that was going to happen, and I doubt any of it will happen.#1: No, that's a bad habit. And anyone who looks at a line like that might have to look up the documentation on the method/function being called. #2: SuperStrict is fine, and this is still BASIC. I do not like the idea of case-sensitivity, seeing as most of the programmers here are either stuck in a Blitz3D mind-set, or have very bad, inconsistent coding style. #3: I've never really used C/C++ so that line made little sense to me without the Max version. Again, this is still BASIC, and we don't need confusing things like that to scare away even more beginners (the code is so not Blitz). |
| ||
| I don't care much for option 1 and 2, although case sensitivity would be nice to have. However, generics is something I would be all over! I'll take 2 please :) |
| ||
| Might just be my luck, but EVERY time I've been given a C based program this has happened. (I've only worked on a handful and they were not the best - but even allowing it to happen is wrong, end of story) You probably shouldn't be coding if that's what you do when given case sensitivity. Just stop now and spare everyone the pain and suffering. >_> |
| ||
| Java is a pain in the royal rear end just trying to get the code to compile. It's and endless cycle of [Complie/Run - fix complaint] You tried NetBeans? |
| ||
| > You probably shouldn't be coding if that's what you do when given case sensitivity. To be clear, it was not me, it was stuff I was given to take over, and every time it had two or three variables all spelled the same - with different capitalization. One of them did it to differentiate between locals and globals, what fun that was. (NOT) |
| ||
| To be clear, it was not me, it was stuff I was given to take over, and every time it had two or three variables all spelled the same - with different capitalization. One of them did it to differentiate between locals and globals, what fun that was. (NOT) Then if you were in charge, you should have fired the people responsible. It's really depressing when people who write code like that get hired by anyone. |
| ||
| @Brucey: Actually, anyone coding without an IDE these days... Masochist? Fixed that for you. ;) |
| ||
| Fixed that for you. ;) Indeed :-) Currently working on a solution. |
| ||
| who in their right mind is going to oppose case sensitivity Well, I'll bite: Death to case sensitivity! Die, case sensitivity, die! Let's all stomp on the face of case sensitivity! Die, die, die! (I assume that makes my position clear... :P ) However, going by the context in the article, I imagine Mark is only referring to the difference between type names and variables names, such as you'd find in Blitz2D/3D, where you can go: rocket:Rocket = CreateRocket (), as I remember this coming up in early BlitzMax testing. (You can't do this in 'Max.) You can do: rocket.rocket = CreateRocket () in Blitz2D/3D, ie. a variable can have the same name and case as a type, but as things were arranged differently behind the scenes in 'Max (in ways I do not pretend to understand), I assume rocket.Rocket would be a possibility in the 'new' case-sensitive world, while rocket.rocket might not, given the reference to differentiating based on case-sensitivity (ie. both variable and type are the same in the case of rocket.rocket). I'm not sure I think it's worth the confusion any more, but why someone would want a variable or type called rocket and a separate variable or type called Rocket, I truly cannot fathom. Or, to put it another way, who in their right mind is going to oppose case insensitivity?! I'm sure (by which I mean I pray) that if Mark intends full case-sensitivity, it would be totally optional. Differentiating between variables and types based on case-sensitivity I can handle, but like SuperStrict I think that preventing me from doing what I want to do (as in rocket:rocket or rocket:Rocket) might actually be a good idea after all... ! Still, I have to ask: why on earth would you want (variables) rocket:Int/Rocket:Int, or (types) r:rocket/r:Rocket, to be treated differently? |
| ||
| Or, to put it another way, who in their right mind is going to oppose case insensitivity?! Nobody here, most likely. You propose it for a C standard and I'm sure you'll have a riot. The point is opposing case sensitivity because, god forbid, someone might do something stupid is in itself a stupid argument. You can already do plenty of stupid things in BlitzMax, and you will always be able to do something stupid in any language ever created. (With the exception of INTERCAL, which would probably lecture you if you do something stupid.) The only argument anyone here has against case sensitivity is that they'll think of it as an inconvenience, not because you can do something stupid or because they think it's somehow a flaw in language design. I think everyone should just admit that much and stop making up horrible reasons that they think are technical flaws. |
| ||
| I would be in favor of case sensitivity. The faster object containers sound like a good idea as well. My highest requests would be more control over the GC and improvement in the threaded GC, which is so slow it usually kills whatever gains you get from threading. |
| ||
| #1 - Using := as a shortcut to declaring types Well, this is basically the same as non-Strict code, where you don't need to specify a type. As has been pointed out, this makes the code very unclear, unless you know what the returning type is (from a function call). The only reason to have this, is laziness :-p I'm pro case-sensitivity and generics. |
| ||
| Like James states why do you need it? I can think of no other way to confuse code more than to have two identically named items whether there is a capital here or a capital there. Readability of the code starts to get shot to sh*t when you have this going on. local rocket:Rocket=New Rocket local rOcket:int=5 local roCKet:String="Rocket" local rockeT:rockEt.rockeT.ROCket... I would love to see a compelling argument for it. I don't know of any myself other than supporting habits brought over from other languages. This is one thing that I believe exists for the shear purpose of complicating code. I know I know... rocket is the type/class, Rocket is the instance or vice-versa... blah! |
| ||
| I wouldnt mind := as an Editor shortcut (hint hint ziggy), but I agree it would make code comprehension a nightmare. And No to point 2 |
| ||
| Yeah, I'm against case sensitivity also. |
| ||
| Case-sensitivity as a promoter of 'code cleanliness' only works if the base code that the developer has to work with is clean. ...And I guess pretty much all the modules out there use good standards so that really isn't an issue. |
| ||
| Personally I did not like many of the suggested changes. := reminds me of Pascal, and why make it more to type when = is perfectly sufficient? The := assignment operator in Pascal makes perfect sense to me, since it is the standard notation in algebra.Talking about the suggested additions, I'm all in for generic programming. Case sensitive identifiers are OK, as long as they are optional. I agree that the weak typing would make code harder to read, but nothing forces you to use it. |
| ||
| I can think of no other way to confuse code more than to have two identically named items Case sensitivity can be use as you stated, but its to help you in the long run. Most coding can be done in very strange and messy ways... thats when standards come into play. In a team of programmers, its vital... imagine coder#1 declaring rocket, then coder#2 using rocket as Rocket, coder#3 comes along and call it rockeT etc... For a solo developer I would still like to use it as it would keep the code neat and tidy. After a few months of not working on a project and you go back to it, you would be forced to use the same variable names etc... But in the end, each to their own... |
| ||
| Don't we have bigger fish to fry?! See below. Maybe inline maths to types:
Type TVec3
Field x#,y#,z#
Inline :+ (v1:TVec3, v2:TVec3)
Return Vec3(v1.x+v2.x, v1.y+v2.y, v1.z+v2.z)
End Inline
End Type
Local a:TVec3 = Vec3(1,2,3)
Local b:TVec3 = Vec3(10,20,30)
a :+ b
I'd wet myself if i could do that...or something similar. |
| ||
| But really, why allow rocket:Int and Rocket:Int? I haven't seen a convincing argument yet! Why do you want this to be 'allowed'? Can any pro-case-sensitivity freak of nature (um, sorry, slightly quasi-religious slant crept in there!) actually provide a single compelling argument as to why this would be useful, rather than suggesting why I'd be "stupid" to use rocket vs Rocket (which I'm not even proposing to do anyway)? In all seriousness, why would anyone really want case-sensitive variables, types, filenames (I turn this off in Linux bash shells ASAP since it's stupid), etc? That's all I really would like the answer to. (This is different to the idea of allowing differently-cased variable names and types, though I no longer think even this is a particularly great idea -- having been a previous challenger of TRocket, TImage, types, etc, in the early days of BlitzMax, ie. as someone who wanted to call rocket:Rocket, etc!) |
| ||
| why allow rocket:Int and Rocket:Int Hi James, Im not talking about the declartion of variables (it would be very bad practice to declare two variables with the same name but in different cases) I talking about the use of them: In BlitzMax you are allowed to do the following: Global rocket:Int rocket = 1 Rocket = 10 rOcKeT = 20 Using case-sensitivie coding you could only do the following: Global rocket:Int rocket = 1 rocket = 10 rocket = 20 And if you tried to do Rocket = 10, you would get a compiler error... |
| ||
| I am here to say I oppose mandaroty case sensitivity, all over again. The number one problem I've ever had trying to write javascript code hasn't been syntax errors or coding bugs, but simply that something doesn't work properly because I forgot to make a single letter the correct case. It's really, REALLY annoying. I know there are some benefits to it, like making sure you are referring to the correct variables and all that. But it IS much easier to not HAVE to think about it. I'll for it so long as it's optional, and I think if mark is considering making things easier for beginners then he won't make it mandatory to have to type everything so exactly. |
| ||
| javascript Theres your problem :) Javascript is a horrid language to write and debug! In Blitz, the compiler would point to your error straight away... |
| ||
| Make it an IDE option then.. leave the compiler alone. Or if it does go in, how about.. Anal Strict or OCD Strict |
| ||
| #1 - Using := as a shortcut to declaring types ---> how to make unreadable code * #2 - Case sensitive naming ---> how to make unreadable code * ** #3 - If .. Then .. Else shortcut ---> could be handy * Based on the assumption BlitzMax IS an 'easy-to-access' & 'fast-developing' language. ** I dont' really understand the need of Case sensitive naminig (in program language or in file system): for a 'human' (the user that needs to 'read' the program or to 'use' the computer) there is NO REAL difference having a folder called Customer or customer: I doubt there'are people that can decide to have a folder Customer for archiving paying customers, and customer for all the others. It's more logic to have 2 different name (Customer_paying and Customer). In my opinion #1 and #2 are a lost of time for Mark to implement, in whatsever language he wants to create in future... |
| ||
| Hi therevills, Using case-sensitivie coding you could only do the following: Global rocket:Int rocket = 1 rocket = 10 rocket = 20 And if you tried to do Rocket = 10, you would get a compiler error... What I don't get is what actual use this is, given that rocket, Rocket and rOCKET are all the same anyway. Put another way, what's the harm in having defined rocket:Int and then calling Rocket = 10? |
| ||
| I wouldnt mind := as an Editor shortcut (hint hint ziggy), but I agree it would make code comprehension a nightmare. BLIde already has its own shortcuts: FLD MyField:Tlist --> Field MyFiels:Tlist = New Tlist GLB MyGlobal:Timage --> Global Myglobal:TImage = New TImage LCL MyLocal:TMap--> Local MyLocal:TMap = New TMap this is not yet documented, but will be soon. You can use it freely on current BLIde versions. |
| ||
| given that rocket, Rocket and rOCKET are all the same anyway IMHO I think thats the problem :) Maybe Ive done too much Java programming - LOL In a team of coders, case-sensitive helps enforce standards and everybody is on the same page. One of the reasons I think BlitzMax is great is the option to use SuperStrict as I like my code nice and neat, and I know what variables types are used. I also like Jim's idea of UltaStrict. Doesnt SuperStrict (Strict?) give you a slight increase in speed too (as it forces you to declare the type)? I wonder if UltraStrict would too? |
| ||
| Don't we have bigger fish to fry?! Indeed Chroma. If operator overloading is a very complex addition to the bmax compiler (and I can imagine it is), would it be easier to allow C/C++ modules to extend the available base types? A module for vector math for example would add a Vec3 type that's known to the compiler, and * + - / operations etc would be defined by the module for the compiler to look up and link to. Ok, this is taking the language away from Basic (for the module authors) but there'd only be one definitive library for vector/matrix/quat math making it an easy community project. I'd like true public / private type member access too. It won't be difficult for the compiler to spot illegalities. |
| ||
| 1) I think, while this reduces code writing only a tiny little bit (writing less to code more is good), it adds a lot of unreadability. IMO not worth it. 2) I think it does not fit in a BASIC language, and personally think it does only hamper the devs. If your team is writing rocket, Rocket and rockeT all over the place, they need to be whipped around with a large trout. What is infinitely mode valuable, especially for beginner programmers, is having a coding style tutorial. From my web development past I traditionally use lowercase_with_underscore for variables, lowerUpperCamelCase() for functions and CamelCase for type/class declaration. While some purists may abhor mixing casing styles in code, this way I can instantly recognize the broad nature of a specific thing in my code. Frankly, enforcing it at the compiler level is attacking the symptom, not the cause. Learn good coding practices and agree with your team to use a consistent coding style, and the different-coding-style will never hit you. Different styles in coding is a project standardization/communication problem, not a compiler problem. 3) Now, this is one thing I like. While it might take a little bit for beginners to get used to, it's not overly daunting, and several short,simple if-then-elses can be replaced with the ternary operator. I am all for it. Seriously, if a beginner programmer is too thick-headed to understand that it is a simplified if-then-else with no elseif, (s)he shouldn't be coding at all. 4)Now yeah, the bigger fish to fry. While we are at it, If we are going to have operator overloading, function overloading could come along for the ride too. Granted, it's a bit of an advanced concept, but beginners don't have to use them at first. You will only wish those features when you want to go a bit further, optimize/simplify some part of your code. |
   |