As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I've had an argument with a friendly coder who was mildly damaged by Joel's Law of Leaky Abstractions. It is very hard to convince him of using any new framework/toolbox at all. I'm trying to present a point where "abstractions are fine as long as they allow low-level access to abstracted level".
Examples:
GWT - Google's superb Java-to-Javascript compiler, has JSNI - ability to write "native" Javascript if you really want to.
Hibernate - AFAIK has SQLQuery - way to write native SQL.
Java - JNI - if you miss C.
Is it sound?
Am I missing something?
Thanks
What I took from reading the leaky abstractions article wasn't that abstractions were bad, but that you should make it a point to understand what goes on under the hood, so that you can account for "unexpected" behavior, and avoid them.
What does your friend program in? Machine language? :)
Joel's point (as I understand it) is that by abstracting complexity away you are sacrificing the finer control over that underlying complexity. For anything but trivial cases you will eventually need to access that finer granularity of control at which point the abstraction breaks down.
So all abstractions are leaky (almost) by definition :
If there is complexity in a system, it must be there for a reason (or you should find a way to remove it) and so will occasionally be useful/vital.
By abstracting you are limiting the control you have over the underlying complexity.
When those 'occasionally's come along you will have to break the abstraction.
To some extent he has a point. Traditional c/unix development works to a platform that is simple enough to be able to understand more-or-less in its entirety. Modern platforms are orders of magnitude more complex, and understanding how all of the layers interact is much harder, often infeasible.
The law of leaky abstractions mainly applies when the framework does a bad job of managing the underlying complexity. Some of the ways in which a framework may be judged are its transparency (ease of understanding what's going on behind the scenes) and its ability to drop out to a custom workaround for limitations in its functionality.
When a framework does a lot of complex magic behind the scenes, diagnosing and troubleshooting become much harder, often requiring a disproportionately large amount of expertise in the underlying architecture of the framework. This means that productivity gains from the framework get absorbed in the extra effort of training and debugging the code. It also makes the framework difficult to learn and use with confidence, which is what your C programming friend is used to.
When a framework obstructs you from working around its limitations, then it becomes an impediment to development. When this happens often enough, the code base is either boxed in or becomes polluted with ever greater and messier hacks to work around the issues. This also leads to stability and debugging problems,
Examples of frameworks with these flaws abound. MFC was quite famous for failing to hide the underlying complexity of Win32. It also made extensive use of wizards that generated messy code that needed to be manually modified aftwrwards, defeating the purpose of having a code generator in the first place. Early Java GUI toolkits (AWT and early versions of Swing) have very little uptake in desktop applications because they obstructed developeers from implementing a native look-and-feel for the applications. SWT was built in no small part because of these limitations with Swing.
However, now Java has matured a bit, it could be argued that most of its early sins have been fixed in modern frameworks. J2EE is still a large, complex system, and developing a non-triviall user interface in a browser is also quite a substantial undertaking. Becoming proficient in this platform is quite a lot of work. However, it's not beyond the wit of man.
While I think its true that every abstraction is leaky, that is not necessarily a bad thing.
For example in traditional plain C (C#, Java, whatever) code you usually retrieve data from arrays by using loops, ifs etc. But that way you overspecify your solution to a problem.
The way SQL, Linq approach the same problem is more intelligent: You just say WHAT you want, the machine figures out how to do it. This way it is free of any specific ordering of commands from the traditional way and can split the work onto different cpus for example, or reorder stuff to make better use of caches etc.
So yes you give some control to the machine, but the machine has one big advantage over you: It is at the user/customer's place and that way can make on-demand decisions (like using multi-core, using advantage of MMX, whatever).
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
As the title states; the way one groups classes in PHP compared to for example Java, is it supposed to be different? I am currently reading O'Reilly's book OOA&D and in the chapters I've learned to use one class for each specific task and not one class for a grouped thing. Recently, I looked upon some code for a calendar, and the class was thousands of lines and had everything inside it that was to be used. However, this feels to me like it's violating the point of having many objects doing one task, but seeing as PHP is web development, is it supposed to be different? E.g. monster-classes.
Answer: use good design principles, even in PHP.
In addition to not creating Monster classes (also known as God-classes or objects) the following patterns are worth mentioning specifically:
Object naming:
Class names should be nouns because they are objects.
Method names should be verbs, because they are actions.
Cohesion. The short-version is basically: methods do one thing and do it well.
Property Visibility: Variables should private unless you've got a dang good reason not to, and in such case, use protected. Almost always you should avoid public.
Use interfaces and abstractions. Almost no one uses interfaces in PHP, but they should. It means that I can write my own implementation details but still hook in with some service that uses the class.
A somewhat outdated article on PHP design patterns that's still worth reading but is hard on the eyes.
Short-version:
If you are ever relying on an array to hold a particular structure it should probably be in a class.
An example from my life: ActiveRecord
What if I want to build a website that does not need any particular Active Record implemenation? At the moment, I'm quite stuck once I choose an implementation because they are all so unique. If they actually implemented an ActiveRecordInterface, I would be able to swap out my actual ActiveRecordEngine if I wanted to change.
I've learned object-oriented programming over 15 years ago and have been using it with C++, Java, Pascal. The PHP at that time was much less powerful than it is now. It took PHP about 10 years to implement Objects properly. They finally work fast, references are passed properly.
Unfortunately, many developers who started with PHP haven't got a grasp on a proper object-oriented design of software. The class is often used like a "library" and everyone speaks about de-coupling and having everything independent, so in many cases classes won't have parent.
There are no solid foundation what everyone could agree on and use. When you turn to the frameworks, some are better and other are worst in terms of the proper OOP. For instance, the proper Code Igniter framework is fast, secure, simple to use, but has very bad OOP design. The main reason is compatibility with PHP4.
For a better-structured frameworks, simply look at the source code of some of their components:
Tabs in Yii: http://code.google.com/p/yii/source/browse/tags/1.1.8/framework/web/widgets/CTabView.php
Tabs in Agile Toolkit:
https://github.com/atk4/atk4/blob/master/lib/View/Tabs/jUItabs.php
Tabs in CakePHP:
http://bakery.cakephp.org/%20articles/view/4caea0e3-ac74-409b-8693-435282f0cb67
My conclusion is that the language in itself is OK, but a lot of badly written code is out there.
It is not supposed to be so. Monser-classes are always "bad" because it is hard to fix bugs / implement new features or maintain your code.
Just because people have written the code and made the source available doesn't mean that it's always going to be good code.
The principles you're used to (small classes that do their one thing well) is a good one. But not every developer follows those principles.
In the PHP world, a lot of people have worked their way up through it from the early days, when everything was in a single procedural monolithic block of code -- and I've seen some horrendous examples of that still in everyday use. Converting one's mindset from that to an OOP structure at all can be a big leap for some people, and even for people who haven't come from that background, a lot of the code examples they would be learning from are, so it's not a surprise to see monster classes.
The short answer is to write code the way you're comfortable with and the way you've been taught. It sounds like you've got better coding practices ingrained into you than most PHP developers out there, so don't feel you have to change just because other people are doing things differently.
Don't know if this answers your question but my experience is that it's quite common for PHP scripts and plugins like the calendar you mention to be constructed in the monster-class kind of way because of PHP's poor support of namespaces and encapsulation. The same goes for Javascript which also tends to have superbig classes in some cases (jQuery for example).
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
The engine I've been wanting to remake is from a PlayStation 1 game called Final Fantasy Tactics, and the game is basically a 2.5D game I guess you could say. Low-resolution sprites and textures, and 3D maps for battlefields. The plan is to mainly load the graphics from a disc, or .iso (I already know the sectors the graphics need to be read from) and fill in the rest with game logic and graphics routines, and probably load other things from the disc like the map data.
I want this to be a multiplatform project, because I use Linux and would like for more people to join in on the project once I have enough done (and it's easy to get more people through platforms like Windows). I'll be making a website to host the project. Also, none of the graphics will be distributed, they'll have to be loaded from your own disc. I'd rather not have to deal with any legal issues.. At least not soon after the project is hosted on my site.
But anyway, here's my dilemma- I know quite a bit of Java, and some Python, but I'm worried about performance/feature issues if I make this engine using one of these two languages. I chose them due to familiarity and platform independence, but I haven't gotten too into graphics programming yet. I'm very much willing to learn, however, and I've done quite a bit of ASM work on the game- looking at graphics routines and whatnot. What would be the best route to take for a project like this? Oh, and keep in mind I'll eventually want to add higher-resolution textures in an .iso restructuring patch or something.
I'm assuming based on my results on Google that I could go with something like Pygame + OpenGL, JOGL, Pyglet, etc. Any suggestions on an API? Which has plenty of documentation/support for game or graphics programming? Do they have any serious performance hits?
Thank you for your time.
I'd recommend going with PySFML, and, of course, Python.
If you do your Python programming correctly , and if you really are willing to fiddle with C or ASM Python plugins for faster computations, you shouldn't really have too much performace hits.
First thing, I wouldn't worry too much about language performance at this moment. If you worry about performance unnecessarily and choose the wrong/hard platform, your project will be dead before it started..because it will take it longer for you to produce something and harder to get other people to join your project.
Since your are familiar with Java & Python, I'll suggest do your project with Jython or JRuby. That way you get to write in nice and powerful language with the benefit of Java runtime.
By choosing to run it on Java runtime you get:
Multi platforms support, so this address your concern about linux/window platform.
Latest Java runtime is very good and in most cases the JIT can perform equal or better to natively compiled program.
At the end of the day if you're passionate about the project and committed to getting the most out of the language you choose, the performance difference between java and python will be minimal if non-existent.
Personally speaking, the biggest challenge is finishing the project once it loses novelty and initial momentum. I suggest you go with whichever language you're more passionate about and are interested in plumbing the depths of, or one that could boost your resume.
Secondly, as you mention you're hoping to attract contributors, you may want to factor that into your decision. I can't comment much here, but have a look at similar projects with lots of activity.
Good luck!
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I'm looking into writing my first application of Google App Engine. C# is my 'native' language, and so writing the app in Java would of course be most logical. BUT, I'm a geek and would like to take to opportunity to learn something new.
Therefore its a toss-up between Python and Go.
Do you have a strong preference based on experience (ideally in the context of writing on App Engine).
If you've come from C# (or another similar language), how was the transition?
The recently-released Go runtime for App Engine is labelled experimental for a reason: Both Go and Go-on-appengine are new and in a state of change.
If you want to experiment with Go and running Go apps in the cloud, go for it. If you want to write a production app on App Engine, use Python or Java.
This question is about as subjective as they come, but I'll bite anyway.
Python is easier to learn, has a much larger development community, is mature, and has a lot of third-party libraries available for you to integrate into your application. It's a winner for sure.
That said, Go is an extremely well-designed language. Far, far more so than Python. Go was specifically designed to allow you to catch most mistakes at compile time, while Python is almost legendary for its ability to mask your mistakes. Go code tends to be easier to maintain. Go is also dramatically more efficient than Python -- several times faster or even several orders of magnitude faster, depending on what you're doing.
Both languages are very powerful and very fast to write code in -- you can accomplish a lot in a short amount of space. But Go is unfinished and still in a state of flux, with core APIs still changing. It has a comparatively small developer base, and very few "real world" usage examples. Nonetheless, even this early in its development, it's already shown to be a compelling alternative with a clear use case.
I did a Python app for GAE recently and coming from C# I had no problems/was able to pick it up in a few days tinkering with the docs and playing with the SDK (I had some previous experience with python).
Python is pretty intuitive, it's imperative and OO, might require a slight change in thinking from C# but nothing revolutionary - using the interactive interpreter will allow you to pick it up in a day IMO.
Learning how to use the datastore and figuring out other GAE specific API's (blobstore, image, mail) will probably be more work (it's specifics like transactions/groups, consistency modes ...) but you can figure that stuff out as you go/when you need it in your app.
One thing to note - recently announced pricing scheme makes Python a bad choice on GAE ATM because it cannot handle requests currently and this leads to one "instance" per request. This is also true for Go ATM (as far as I know). JVM OTOH can handle ~20 simultaneous requests per instance if I remember the mailing list conversations correctly. And you will be paying per instance/hour. This makes JVM the most practical choice if you plan on publishing your application in the near future.
Also using JVM you could use Scala (a new/cool language) and a framework like Lift which should theoretically allow you to port your code/avoid lock-in (disclaimer : I say theoretically because I'm only starting out with Scala and have no practical experience with Lift).
So I would recommend to look around the mailing list and see what other people are saying about the recent changes.
Personally I would prefer Python because is much, much more mature than Go.
In the past, I learnt, the hard way, what are the risks of choosing a not-so-mature technology.
Warning, I am biased to recommend Python because I like it but you should also be careful because I heard many complains about how much support does Google put on Python-App-Engine. People are asking for years to upgrade Python support and nobody hears them.
These being said, probably Java would be a smarter choice, especially because you are used to C#.
Go is still experimental on the GAE - so maybe not the best platform to learn a new language. Python is definitely a good choice.
Considering a new language do not forget that by choosing Java you get the JVM which allows not only Java code but also oder languages like: Scala, Grails, Clojure, JRuby any many others.
Python is since long supported on GAE - lots of tested information, infrastructure, etc. Go is new to GAE.
I would decide more on the language level. Coming from C#, choosing Python you go a bit more "high-level", whereas choosing Go goes more into the "low-level" direction. More low-level control, but also more concern about that. Choose Python if your interest is on application development, and Go if it's more about systems development. One important aspect for me would be that Go has actor-style concurrency built in, though I don't know how well supported this on GAE will be.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 14 years ago.
I have heard this a lot, the the Java API is poorly designed. Do you agree and if so, how? I know there are major issues with the Calendar/Date apis. The collections api takes a lot of boilerplate code to use. The File/IO API can be complicated for some things.
But, does this apply across the aboard? And to which versions of Java?
In short, Java APIs are OK.
Longer answer is that some APIs went through changes, sometimes significant, over Java releases and may contain odd pieces. Date, for instance, has quite a few deprecated methods. Nevertheless, what's important is that those API do exist. Java is strong with it's standard library where you can find API for almost anything (may be not always perfect API, but good enough).
P.S. Next time someone produces such a statement, ask him how many languages he designed himself in his life.
Java was not a poorly designed API. Java was made at a time when current best practices weren't exactly known. A lot of implementations were done in a way that are now frowned upon. Since that time there has been a LOT of work done in order to incorporate better techniques and practices. That is why there is a lot of deprecated code.
A bunch of this stuff is talked about in the AMAZING book Effective Java. Bloch talks about some of the "mistakes" that were made in the initial implementation and how they have worked at trying to fix them. If you are a serious Java developer and haven't checked out Effective Java I recommend it HIGHLY. (I actually recommend all of 3 of Bloch's books. He is an excellent writer with a thorough understanding of Java.)
Some of the "is the Java API bad" is covered in the book Effective Java.
There are some parts of the API, like java.util.Date that clearly are poorly designed (all but a couple of methods are deprecated as of JDK 1.1).
There are some other things, such as the lack of interfaces on some of the JDK 1.0 classes (which happened because there were no such thing as interfaces when they were created (interfaces were added before 1.0 but after 0.0).
There are some things that were not done "right" because the convention came after JDK 1.1 has a number of things in the AWT change due to JavaBeans and the naming conventions used).
There are some other things that were not possible before language changes such as enums and generics.
A lot of the API is good. Some of it is poor. The early stuff in JDK 1.0 was clearly written for HotJava (an all Java web browser) and was not really thought out for general consumption.
It is safe to say that the older the API the "poorer" it is. Newer APIs are designed with the knowledge of what came before it. That goes across langauges too - Java is (depending on your opinion) better than C++. C++ is (depending on your opinion) better than C, etc..
Java is old (it has its origins in the early 90s although it wasn't released to 1.0 until 1995 or so) and anything that old has APIs you can criticize. It's not that they're bad per se. They're simply a product of their time and that philosophy is now considered bad (usually with good reason but not always).
To address the ones you bring up:
Date is awful just because it's mutable. An immutable date class would be much cleaner (Calendar has the same problem);
A public constructor on String is, at best, problematic. There's some disagreement on whether or not this is even a problem. In my opinion it is but it's not a massive problem by any stretch;
The java.io.* classes remind me a little of the C++ iostream library in the sense that they were an experiment that I think history has shown to be not a success (if not a failure). Just look at the code you have to write to read a text file into a String. Most other languages have a standard call that'll do this.
And some others:
The pre-1.2 collections are problematic. Josh Bloch (of Effective Java fame) was the architect for the changes to the Java Collections framework in 1.2. It was a massive change for the good and include interfaces for all the classes, abstract implementations, etc;
java.util.Properties extends Hashtable. This is a classic example of a product of its time. In the 90s object frameworks tended to inherit from something. Nowadays the tendency is (rightly) composition over inheritance but that wasn't the case 10-15 years ago.
You could argue that it is "poorly designed" because if they had to do it over now, its authors would build it differently. However, they have made a laudable effort over the years trying to make the best of it. However, hindsight is 20/20.
The Java API has the same problem of any library that has to "evolve while running".
It had been so many years since Java first came out, and many design decisions on the language and the library have evolved. However, the need to be backward-compatible keeps constraining the API and changes to it.
There are many specific examples of usability issues (I've been studying them for the past few years), but then again, few APIs are perfect.
I wouldn't say all of it is poorly designed. The main problem is backward compatibility, people still expect features that have long become deprecated to be available so there code written 10 years ago won't have to be changed. This makes the API rather large and often allows multiple ways to do the same thing with out it being clear which one is better.
Is the Java API poorly designed and why?
No
Because, although it is not perfect, the amount of bad API's if way lot less than the part that is just great!
Anyway, you really should ask this, to whom you heard it from directly, otherwise it will be what in my country is called "Broken telephone" ( which otherwise is a great kids game :)) where each node in the chain of massages modifies the message subtlety and at the end something like:
I don't like java.util.Calendar
may end up to
Java API is completely broken and the desingner should be jailed.
Of course in the middle there's a "message transformation"!!!
:)
Like anything that is around for some time, it gets stale. As with .NET, Sun, et al, have tried to keep things new. But, time stagnates everything, especially considering you cannot change interfaces, only add, as changes break things. :-)
No, Java API is great for most parts, but some parts of it are just rotten. Everyone uses Date and Calendar as examples (here's the mandatory joda-time link) but I'd use XML API (the native/W3C one that is since there's several nowadays) as a good example too: The issue with that part of the whole API is that it just doesn't work as expected and doesn't conform to the rest of the API.
Also one important factor with Java API is that it's consistent and not just within itself but within versions and platforms (with the exception of AWT) and I sure haven't hit any magical spot with Java API yet which would've changed/broken something when doing a version switch.
I started using the Java API in ~1995. Any API which is that old is easy to criticize.
To answer the question of Why:
Java introduced enums too late - the API would be much better if it had enums from the beginning.
WORA (Write Once, Run Everywhere) - or as some say "Write Once, Debug Everywhere". It is incredibly difficult to make a great API when your target is the least common demoninator. No "real" Windows or Mac or Unix or Linux developer can ever be happy with Java.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I always hear that programmers try to pick the right tool for the job. I've never programmed in Java, so I was wondering What are its benefits? Why is it so popular? What should I use it for?
I just program recreationally. Is there anything about it that makes it particularly fun??
I think after 12 years or so, the "write once, run anywhere" mantra is almost true. Writing Java code pretty much isolates you from the platform dependent aspects of the systems on which you deploy it.
Portability
Incredible breadth of libraries
Bottom-up security
Performance
Robustness
Massive communities, the amount of help, libraries, IDE's, is huge (and thats a good thing).
For a casual programmer Java can teach a lot about object-oriented programming, and encourage good programming habits in general, without the need to worry about as many of the "messy" details (pointers, memory management) as, say, C++.
It's also a bit easier to debug "catastrophic" errors.
Java is really good at integration - there are specifications and implementations for integrating with many kinds of systems that you're likely to run into in an "enterprise" environment.
It's not really a "fun" language relative to popular high-level languages.
This seems to be getting healthy answers, but you might also want to look at "Why do people use Java?"
Java is a good language, but that is secondary to the importance of the standard library that comes with it. The jdk may not be the most elegant kit ever built, but it is extensive, powerful and reliable. Programming in Java the language is simple. Programming with appropriate reuse of the jdk is what it is all about.
Cross platform is in my opinion the most relevant benefit.
The main goal of Java was to create a programming language that could run anywhere. The target was GUI apps. This however never happen because the environment was too slow at the beginning ( now it has been improved ) but it prove true in the server side where the cost of development reduced a lot because the product development can be done in PCs and the deployment in very expensive hardware.
It brought easy of development also, because it was designed to have C++ like syntax but running on a virtual platform to avoid platform specific code. At first the penalty was the execution speed, because it was interpreted, but release after release the interpreters became more and more faster that even MS model its next generation of development after java and call it .net
Additionally You can have a read of the Java design goals here
I want to add one point: Java keeps a good compatibility to earlier versions. That means, your Java-projects are compile and run in most cases without any problem on newer versions. That seems to be a little point, but this stability in API's and language helps to build a big community around Java, including good tool-support.
Others already mentioned other important points:
good portability
lot's of libraries for nearly anything
easy debugging and easy to catch problems
There are only two reasons to use Java:
The Java Virtual Machine (Hotspot).
The huge amount of available libraries and tools.
There are other languages that run on the JVM and make better use of Java libraries than Java does, however.
After using Java for some time, I've come to the conclusion that it's fun to write in, limited in some very irritating ways, and it's performance is good though it seems that many programs are crippled by poor design.
I'm not sure if the latter is a function of Java, or an effect of Java.
In either case, in addition to all of the above stated benefits it's very useful for doing "net" related things. Treating resources with a simplified interface regardless of "where" the particular resource is, etc...
It is by no means a universal hammer.
oop provides like encypsilation ,inheritance,polymorphism not available in traditional programing .oop is closer to real life presentation of the programming
1. Relation ships can be representation using inheritance
2. Programme developement become easy due to increased modularity