Jump to content

  • Log In with Google      Sign In   
  • Create Account

Bearhugger

Member Since 05 May 2007
Online Last Active Today, 12:12 AM

Posts I've Made

In Topic: Oracle loses Java API case against Google

Yesterday, 07:59 PM

I'm most happy with the current situation personally.

 

On one hand the appeal court's judgement acknowledges the creative work required to create a good API. I mean, I don't have any respect for the Java Foundation Class' APIs I think they're a mess and I hate every second I spend coding in Java, but when I think of some really well made libraries such as (IMHO) LINQ or the Roslyn API in .NET, all the new modern async Javascript libraries out there, or the thread/promise/future libraries in modern C++, I see a lot of cleverness and creativity in their design and I'm glad that the copyright acknowledges the work that goes into creating them.

 

At the same time, compatibility between APIs is a sine qua non condition to make software work, to promote competitivity between software providers, for free open source alternatives to work, etc. They have also been used forever, as each piece of software is built on top of another. The fact that using or copying them is fair use is common sense and I can't think of what would have happened to our industry if Oracle had it's way.

 

So basically if I understand right, it looks like APIs have a copyright but using or implementing them is fair use, making their copyright look kind of symbolic. If my understanding is correct, this is *exactly* how I hoped it'd be.

 

Also, I really have to raise my hat to the members of the jury for making sense out of very technical computer science concepts such as APIs and object-oriented programming and taking the right decision. I doubt a lot of them were technical people, if any.

 

Too bad Oracle intends to go in appeal again. Hopefully the appeal court will serve them a legalese translation of "Go f... yourself!" because I'd really like the current state of affairs to stay the way it is.


In Topic: Should i learn Win32 or UWP?(C++, Directx)

14 May 2016 - 12:00 AM

People forget that before UWP, there was the Metro/Modern application platform for Windows 8 and now it's dead. What's telling us that Microsoft is not going to come out with some new API next year and kill off UWP? I mean, it's not like the platform has been without criticism; some big name game developers are already calling for the death of the platform, and tying the platform to the Windows Store when nobody actually uses the Windows Store or knows it exists doesn't exactly capture my heart as a developer. (Not even Apple can do that on the Mac.) As much as I dread using Qt, GTK, wxWidgets or MFC, I would pinch my nose and use those for now, and then cross my fingers that Microsoft gets things right for the UWP sooner than later. I would love to use the UWP for my project but as it is right now it's a no-go.

 

On a side note, I don't get why people dislike the CX language extensions so much. The objects of the UWP class library are glorified COM objects, and the CX extensions simplifies their manipulation as well as the creation of new ones, so why not make it easy on you and use those when you deal with Microsoft APIs? It still feels very much like C++ and is so much easier and convenient than the nameless mess that you have to deal with on competing platforms to get C++ to play well with the OSs. (Namely, JNI on Android and Objective-C on Apple.)


In Topic: Is it C# Territory?

06 May 2016 - 09:12 PM

Behemoth software is not monolithic in terms of programming languages. They can use more than one programming language. And heck, the .NET framework is *designed* to help making programs cross-languages manageable. Sometimes C# is better than C++, some other times it's the opposite. When you have millions invested in a project you use the right tool at the right place. I know that's kind of a boring answer in a debate, but really, that's what it is. :P

 

I mean, usually, yeah the core of a big program will be written in C or C++ if performance or portability matters. But what about other modules?

 

For automation (big software have some kind of macros support) they will embed a scripting language interpreter (usually Lua, Python, Ruby or Perl interpreter but sometimes they roll their own) and then write some of their own code in that scripting language when it makes more sense. For example, I'm pretty sure that Blizzard writes World of Warcraft's UI as preinstalled mod packs since there is a ton of Blizzard-authored stuff in WoW's addon folder.

 

Is your app just a thin client around a web service? A lot of mobile apps are. In that case, your server-side scripts are almost certainly not built in C++. You probably have a REST API that branches to some Java or Node.js code.

 

And then for updaters Adobe likes to use Java even though Photoshop is obviously not written in that language. Not quite sure why but they do.

 

If your place uses automated developer support tools such as build machines scripts or Q/A services -and if you're working on huge software you bet you're going to find those- then nope, you didn't code those in C++ either.

 

For games, a lot of studios opt for a mixed C++/C# solution for their content authoring software such as level editors. Seriously, think of Unity 3D.

 

So yeah, big software projects can use more than one programming languages. Actually, scrap that: it's not only the big software that does. I worked on a small program (only ~20,000 LoC) for a CNC automation solution and we used C++, C# and Ruby.


In Topic: Should getters and setters be avoided?

12 April 2016 - 10:14 AM

You need to take what you read with a grain of salt and evaluate whether it makes sense or applies to your project. ESPECIALLY when someone starts calling something always evil like in one of the linked URLs in the original post. At this point, I don't think there is anything that is always evil. I think I actually even have a good case for a goto in my rendering engine's code, which is the pinnacle of the NO-NOes in programming. (And I'm still looking to get rid of it.) So if you tell me that something as ubiquitous and proven as getters/setters are always evil, no, just no. Misused? Yeah, I think people often write a lot more getters and setters than they actually need to. But always evil? No. (And only a Sith deals in absolutes. :P)

 

The truth is that there are a lot of people in the programming circles that would like to make themselves a name by calling well accepted practices "evil" just because it's bad by some completely unpragmatic point of view, or because once upon a time someone misused the pattern or principle. Now it's get/set, last week singletons were evil. Next week if someone calls having a main() function an antipattern... well, remember I called it first here. :P

 

Don't ignore what you read, just have critical thinking. If you're a seasoned programmer, you know more about how to go with your project than some blogger with a book so listening advices and new method can never hurt, but in the end you're the one who can judge how to go with your project. A lot of those people writing about programming practices are academic Java programmers looking to sell their books or conferences. Probably the same type of people that state completely obvious things, wrap them in silly catchy acronyms like KISS, GRASP and SOLID and write PhD thesis around those, but I disgress...

 

I do think though that if you're going to write a data object with full read and write access and know it's going to remain that way, just write an old-fashioned plain-old-data struct. It's not "prettier" to have to write my_object.GetXXX() instead of my_object.XXX and for setters it's actually annoying if you like to do chain assignments or swaps. Qt is guilty of that a lot: you need to pass through methods to set the values of a vector or a matrix. It's just annoying. Don't do that.

 

This is kind of why I would like to see properties in C++: you can expose naked properties if you don't need to control reading and writing, and if you change your mind later and need a getter or setter, you can write them without breaking any code. But again, I disgress.


In Topic: My app cannot write files anywhere on Windows 10

07 April 2016 - 09:38 PM

The locations you listed have in common that they're either read-only or in a folder created in NSIS.

 

Look at the access rights of the folders created by NSIS in your User folder. Is it restricted in reading or writing? There may be an error in your NSIS script that makes it create folders that require admin rights, and therefore your app can't write in them.

 

Program Files and Program Data should be read-only so even the NSIS created folders should be read-only. (They're the equivalent of /usr on Mac/Linux.)


PARTNERS