You download a trial of the software. You hack it so that it's no longer time/serial restrictred.
Now, if the software detects this and encrypts/destroys itself, did it really affect your property?
You didn't legally acquire the software. You're the one breaking the law. If the software says it will do this-perhaps in a splash screen-then does it really count as ransom?
That's like saying you're violating a crook's privacy by using lojack to trace a stolen car.
Java != Slow, but that doesn't mean it's good.
on
Quake2 Engine In Java
·
· Score: -1, Flamebait
Maybe this will lay waste to claims that java is slow, bloated, and sucks.
Java was never slow and bloated when compared to members of its own weight class. You may be tired of people saying "Java is slow!" but I'm even more tired of Java Developers parading this around, like they only not just found out about it. We're all happy for you folks. Welcome to the year 2001. Now, can we please start focusing on the real issues?
I've only recently started doing heaving Java programming, and I have to say that the language is a dream to code with (provided you use a decent IDE).
Ahh. Yes. Java, a dream to code with provided you use a decent IDE. Most people can code quite well with a 100 line elisp module to handle formatting, brace/paren matching and complile control. Java people needs the equivalent of a bustling shipyard with hundreds of dockworkers to move code around.
Whizbang IDEs are nifty and all, but here's my feeling on it: if your language is so hard to work with that you require and IDE to develop and refactor in a reasonable amount of time/effort, then you do not have a language that is "a dream to code in." Having worked with Java, I'd say a powerful IDE like Eclipse is a requirement.
It's not that these IDEs are bad! They're great, but they should be the icing on the cake. Your language should allready be usable pre-IDE.
I'll take it over C++ any day, and MS's MFC is horrible on comparison.
Not that I'm a huge C++ lover, but I have to say... you're right. It is a horrible comparison. MFC is the absolute worst environment in C++. Feel free to continue ignoring quality C++ tools for application development, like Qt, TAO, and the outright amazing Boost libraries.
Sorry. Just because you can make a very old and relatively simple hardware-based game engine run in Java doesn't suddenly mean it doesn't suck. It still sucks, it's just that people are finally realizing why it sucks so badly (and it's not speed).
Umm, hate to break it to you, but the terser languages can (and do!) play that game. Lisp has some awesome IDEs (not to mention that Emacs is itself, essentially a big Lisp IDE).
The idea that your code is so tough to manipulate that you need an IDE to make it viable should say somethign to you about the language in question. When we talk about the future of coding and machine-assisted development, I don't think this is the vision we want to see.
Refactoring Java code can be very tedious, especially if you chage a type that goes into a collection. Even with the new Java Generics, this is going to be a huge pain. In Python or Ruby or Lisp, it's transparent. Heck, even in modern statically typed languages like Haskell and OCaml, it tends to be almost transparent.
Java's manifest typing model is outdated and cumbersome. This fundamental feature of the language lends itself to every aspect of work within. The Libraries may employ some great OO patterns, but they still can't escape the fundamental... well... clumsiness of the language.
As for the next argument against Java? Why doesn't Sun trust developers? Sun feels it's okay to use operator overloading on strings, why can't I use it for my complex number class?
The argument that "you might abuse it" is a lame argument at best. Bad programmers shouldn't program professionally. Do you let a bad basketball player stay on a pro team? Do you let a bad accountant manage your money? Do you let a bad contractor build you a crappy house? Do you let a bad manager control the fate of, um, your... company?... Err, nevermind that last one. But you get the point, I hope.
The only reason I can see for this attitude is that Java wants to bring bad programmers into the fold. Why? Well... let's put on our cynical tin-foil hats and theorize for a second?
Good programmers tend to cost more than bad programmers, because of their reputation and experience and skillsets.
Modern HR policies seem to suggest "many medium-pay employees" over "one or two large-pay employees".
Java skill is so common that there is incredible competition for every job that appears.
Forgive me if I think someone is trying to screw over real software talent by commoditizing it. The sad thing about it is that this makes the consumer the ultimate victim, since they rely on poorly-made software.
And before you say, "That's just conspiracy theory" consider how much money there is in the software market, and how many people there are who have no fscking clue about what goes into good software making decisions on how it will be made.
Hanlon's razor could probably account for it just as well as my little tinfoil pirate hat.
The reason Java is considered 'uncool' in a majority of cases is a lot like the reason certain people are considered uncool in high school. It's mostly prejudice from people who are desperate to be accepted by their peers. Certainly some people have given Java a fair shake and decided they hate it, but the majority are just jumping on the bandwagon.
BS. Java is eclipsing Cobol now. Everyone has used it. If you've written code, you've probably at least written one small app in Java. Ubiquity is a double-edged sword.
Now, people hating Haskell might just be jumping ona a bandwagon. People who hate Lisp might be jumping on a bandwagon. People who hate Ruby might be jumping on a bandwagon. These languages are comparitively rare.
But Java? No.
Frankly I expect better from geeks. It's come to the point where I don't even listen anymore because every diatribe against Java is based on some small pet peeve or overly specific scenario. Everyone rehashes the same old arguments ad nauseam. Quit yer bitchin' and write some goddamn code and you might be useful for once.
How about this then? Java's type system sucks. It sucks, sucks, sucks. Java generics are only marginally fixing the problem. You cannot design your program up front. Heck, to refactor Java most programmers say you need tools. If your language is so intractable that it requires a tool to make refactoring reasonable, then you have a crappy language.
Java's primary GUI API, Swing, is not "brilliant." It's obtuse, lacks many features, and is unnecessarily slow.
Java's "Native Interface" (or FFI, "Foreign Function Interface") is hideous. It's difficult to get much of anything done at all. Ruby and Python provide much better models.
Are these complaints general and clear enough? Java is so riddled with flaws that it's amazing it's gotten this far. A living testament to the fact that marketing overcomes all.
Nobody thinks that Real is defending anything but its own interest. Nevertheless, despite that greedy motivation, what they are doing here is positive.
What exactly is positive? Real isn't campaigning to open the format. They're campaigning for their corporation to be let in on a slice of the pie.
I wonder how they will look like in the future when they will sue some hacker's ass because they have broken their stream format to make a free player (as in speech).
Umm... why do they need to do any such thing? You could open "Lispy-named's Music Store" right now. You could put MP3s and AACs on there.
The DRM only gets put on for purchased music. It is not intrisic to the iPod. The iPod is already open to competition. Feel free to make a service that sells music for it.
What's happening here is that Real wants to force Apple to support Real's DRM and proprietarty format. No one in the open source world stands to gain anything from this.
This isn't about DRM, or the DMCA, or anything of the sort. All that's businesses posturing and playing grown-up. It's expected, even if it's tedious.
What Real is trying to do is shame Apple into doing their engineering for them. Apple has a tightly coded product that sells very well, but which profit margins are smaller on.
Real comes along, figures out how to slip Harmony into Apple's current system, then complans when Apple says, "We reserve the right to break compatibility with this 3rd party, closed source product that is directly in competition with our music store."
People need to stop confusing the issues. Real wants Apple to give them something for nothing. It's a concrete effort to not break compatibility with this product, which can be measured in man-hours and engineering dollars.
And what excatly does Apple get back in return? Has Real made any effort to make Apple's job easier? If Real wants to open the iPod to their format, then they can pay Apple to do so, or offer up the engineering hours to keep everything working.
Or hey, they could open up THEIR format to Apple. Now there's a thought.
MacOS X is Posix compliant in spirit and in letter, and is "Unixy". This is a no brainer. Crawl back in your hole.
As for custom ROM images, dude, everyone does that. You're holding Apple to a standard no one else meets. It's not even fair, every motherboard needs detailed and specific configuration.
Comparing Quartz with DirectX isn't terribly unfair. It's also one of the minor sticking points. Quartz, incedently, is based on an Open Standard, OpenGL. DirectX is a standard unto itself. It's pointless to bitch about it anyways, though, since the underlying drivers are ALSO closed source. Get the hardware comapnies to open up first, otherwise the software being open is pointless.
As for your crack about 50x more programs, it's a cheap shot. I was referring to a specific comment Raymond made.
Apple has opened the OS. Apple has opened Rendezvous, which is a freaking crown jewel of the mac experience. Apple has advanced GCC tremendously. Apple is leading the way on next-gen web applications.
What more does Apple have to do. It seems like the only way to win with some folks is to not make any money at all.
However, Apple is the only company that sells a complete computer system that runs MacOS. That makes them a hardware monopoly.
Since we seem to need a refresher course in what monopoly means:
Exclusive control by one group of the means of producing or selling a commodity or service.
A company or group having exclusive control over a commercial activity
But let's not lose context here. They're talking about whole categories of service. Look, I know you like Mac OS X. I love it. But it's not a necessary thing. There are plenty of other OS's. Software companies are not forced to release Apple-only software unless Apple shells out the cash and buys them outright.
And even then, we see Apple release PC versions and appeal to the PC market with the iPod.
There are plenty of other choices. Apple does not control the market. They are a tiny little corner-sliver of the market. Once they have Microsoftian marketshare, then we can worry.
Until then, calling a company that doesn't even have 10% of the marketshare in an open market a monopoly is a gross abuse of the word.
Where the hell am I supposed to buy a non-Apple PowerPC motherboard that boots MacOS natively (not through something like MaconLinux on LinuxPPC)? The last company that tried to sell complete systems sourced their motherboards by buying real Apple boards as spare parts from Apple repair centers, and Apple wasted no time in releasing the hounds (lawyers) on them.
The biggest obstacle is getting the OpenFirmware set up just so. And you can, as you mentioned, use LinuxPPC as a trampoline if you find this obstacle insurmountable.
The issue isn't about opening Fairplay and risking its security by obscurity. The issue is allowing other copy protected music to play on iPods (whether that's a good thing or not) and Apple protecting its iTunes/iPod vendor lock in.
Riiight. So Apple now has to cater to other companies who want to sync with their hardware. Why exactly? Because it's "fair"? I'm confused. Apple can't stop Real from releasing this software, but Apple doesn't need to help them either. The iPod is coded like an embedded system. Compatibility with a 3rd party extension would be hard to maintain. Not worth Apple's time. Remember, they have to maintain the code.
Unless of course Real paid Apple for their time and gave them the format and the hoops they had to jump through. But then Real would complain that it's their IP, and it would undercut their online music store if Apple could offer their songs in Real Format too.
Let's get this straight. You're telling a small company in a competitive market that is currently favorable to give up advantages. Not because it's the law, or that it's even ethical. It's because people would find it convenient.
Real can't even be bothered to maintain mac compatibility on their store! This kind of deal has to go both ways. Real is getting something from Apple if Apple allows this deal. And what does Apple get in return? Apple can't afford to give away something for nothing, and all the work to keep Real's extension working would fall on their engineers!
Oh, and Real has a real history of quality software. I'm sure Apple is quite confident in Real's software engineering ability. NOT!
I could see Real saying, "Apple. We will give you money if you allow our files to play on your player. We'll pay you for the engineering and a royalty because we're in on your brand." I could even see Apple seriously considering such a deal. Heck, I could see Apple buying Real and heavily leveraging their tech to push themselves further in the PC side of the music world.
I cannot see Apple giving handouts to a competitor that doesn't want to give anything back except more competition.
Well, considering how much Apple has done for, say, GCC... saying they don't give a damn about open source is a rather tough statement to justify.
Incedentally, I'm curious what closed standards you're talking about here. The OS? Posix compliant, pretty fair standard. The hardware? It's all stock parts and OpenFirmware. It doesn't get much more open. How about we attack Cocoa's underlying window system, Quartz Ex? Bzzt. While the source isn't open, all the APIs and the supporting protocols are. Sure, Eric S. Raymond can't hack Quartz directly, but you'd be surprised how little that matters.
Look at what parts of Apple's OS are really closed source. It might surprise you to realize how little of the essential stuff is actually closed source.
You can build a computer capable of running Mac OS without resorting to buying one at apple. It's hard though. The hardware that meets Apple's specs is pretty rare.
You can do it though.
The only place this "openness" argument comes into play is with FairPlay. Know why it's closed? Because FairPlay is effectively security through obscurity. You can't make a system that really does what people want.
Maybe by "closed" you meant "expensive". I'll agree to that.
They don't believe it because hackers are part of a demographic that's notoriously anti-organized-religion.
With folks like Ashcroft at the helm of one of the more frightening departments of the government, people associate Republicans with money, power, and religion.
What I think most people fail to realize is that right now, neither party really sticks to their core values. The Democrats want to restrict freedoms under the guise of social and economic reform. The Republicans want to restrict freedom under the guise of security and religous appeal.
Which of these looks more dangerous to the typical hacker's social sensibilities? It doesn't matter if in the end, the core of the US is totally ruined and discarded. All people see right now is the road to get there.
From all reports, a PHB wanted Yahoo! Stores based in a language that was more mainstream. Yahoo! sunk a lot of money into trying to redo what PG's group did. And in the end they lost several features and had to write a bare-bones lisp interpreter in Java to get only about 1/2 of the html generation and templating functionality.
What was cheaper? Hire two (relatively expensive) Lisp hackers to maintain and upgrade the project, or sick whole teams of wage-slave-class developers to literally downgrade the product.
From reports, they even reimplemented the C code for image generation and the perl glue code. It must have been like watching lemmings march off a cliff. Lemmings with huge wallets.
The economics calculations that go on in these people's minds boggles me. It really does.
Python? Well it's basically Ruby with slightly less dynamism (to me anyways, guess which one I learned first). But Python programmers use many interesting OO idioms in their code which I've used in other languages (albeit awkwardly).
In my (not-so) humble opinion, Python is up there with Smalltalk and Self in terms of "interesting OO environments."
That I can readily agree with -- the more languages one learns the better IMO. But this is generally independent of which languages you select (so long as they aren't derivitives of one another), and has nothing to do with the superiourity of Python, or Python developers over Java developers.
Yeah, but that statement collapses back to "learn languages X and (P or Q or R) and (A or B or C)" It really doesn't mean much. Paul and Eric Raymond recommend learning Lisp. It's an eye-openining experience. Some languages expose you to more ideas than others.
Java exposes you to one very narrow set of what's possible in programming. C's window is equally narrow (although much more complex due to the fact that C code can take the hardware into account much more, and tends to have tighter hooks to the OS). Lisp's window is quite wide. Ruby and Python and Ocaml also have very wide windows.
So, by selecting your languages carefully, you can learn a lot more in a smaller set or known languages. Thusly, virtuous programmers (which is to say lazy, of course) will pick and choose their languages very carefully, and it does matter which they learn.
Consider that Graham's premiere hack was Yahoo! Stores. It wasn't a huge project in LOC count (PG says this is because it was in Lisp). However, it was big enough that Yahoo! had trouble reimplementing it in more conventional languages (and in the end, actually wrote a simple lisp interpreter to handle part of it).
Yahoo! Stores wasn't a "small" project by any sense of the word. Maybe the upper boundries of "medium."
I don't think that structure or strong typing precludes good design
or tests. You can have it all.
Tests are good and fine, and everyone ought to use them. Indeed.
Agreed. However, I feel some strong type systems make good,
test-driven design harder. Some type systems do not.
But keeping me from passing the wrong arguments to the wrong function
is another source of bugs eliminated. A source of bugs which can
sometimes be rather insidious, since parameters can come from anywhere
and get passed through 20 function calls. They can come from a user
who (sometimes even deliberately) enters wrong data, the web designer
who did this small change in the template and replaced the numeric ids
with string ones, or the poor maintenance programmer who has a
deadline to fix something he doesn't even understand.
And the nice part about using a well-designed dynamic language is that
you can plan for this, incrementally add code, hot-swap modules with
debug modes, and actually look at the system at run-time in a much
more powerful fashion. For instance... Deep in a library call in a C++
project, one of your methods throws an exception. You didn't know what
that exception was. Your catch(...) handler can't tell you.
If you were using a language with more dynamic features, this problem
could be solved.
Even then, this concern suggests to me that you haven't worked on a
big system in a test-driven fashion using one of these languages. Such
problems tend to become apparent rather quickly.
And let me stress the last part: maintenance is the bigger problem,
not writing the code. It's also the under-manned part: while when
coding you could get only 10,000 lines per person, in maintenance one
single person can well get a 100,000 or even 1,000,000 line project
alone.
Actually, I consider this issue to be orthogonal to the language. If
the code is well designed and idiomatic, it will be maintainable. If
it is not, it will not. If we're talking about refactoring, this is
why good unit tests and test-driven design is so important, they act
as your safety net.
Working as I do in C++, I find the type system to be less than helpful
when I have to do this kind of work. I've done 3 of these kinds of
cleanup jobs. Only 1 of them had working unit tests (one didn't have
tests at all!). Of the three, all were poorly written and used very
unusual (not idiomatic) constructs (longjmp is verboten, people!). The
only one I could edit with confidence was the one with unit tests.
That person sees the program like through a keyhole. It's like seeing
the Sixtine Chapel fresco for the first time... through a pinhole. You
can scroll the view, but you see a couple of square inches at any
given time. Good luck seeing the big picture. Good luck remembering
it.
All paradigms of programming give people ways to encapsulate work into
bite/keyhole sized chunks. Be it Object Oriented or Functional (or
even database languages, purely declarative and relational), they give
you ways to design with foresight.
I believe this is not related to the type system. Although in the
absense of unit tests, a type checker can sure be better than nothing!
And so I respond:
- where the heck _is_ the code that does that?
* Checking for a symbol is an IDE job or a documentation job, and the
design clarity is what will tell you where it is. How would type
systems help you with this?
- where does it get its parameters from?
* Finding callers is a lexical search away. Heck, if your IDE doesn't
find callers, get Emacs and do a tags search. Unless your language
supports coroutines, this is rather difficult to determine statically
with any real precision.:)
- are those parameters what I think they are? (E.g., does it always
get
Mostly, you're dead on right. Especially about PHBs or programmers who don't think critically about their work reading one book and trying to rigorously apply its principles without thought or reason.
The GOF Patterns book has wreacked nearly as much havok as it has helped to prevent.
But when you say:
And some of the flamewars (e.g., about how any kind of structure or strong typing sucks) are nothing but proof that someone never was in a large project, but is extrapolating out of their ass anyway.
I must take exception. If you really believe that this buys you anything in the long run, you're the one extrapolating out of your ass.
Let me qualify this though. If you're on a competant team who knows the language, and you are doing test-driven (not necessarily test-first, mind you) designs, then you're probably in better shape than a good static-typing-driven team.
Let's discard Haskell and the ML family for just a second, the truth is that in most of these higher-level languages, 1 line of code is worth many more than the equivalent Java or C/C++ line. Sometimes, we can even get into 10:1 ratios.
A 100000 line project is huge. But a 10000 project is managable by one skilled person. If your language, dynamically typed as it may be, lets you cut down the overall size of the project it is going to be a net win. Program size is to system difficulty as speed is to car breaking distance; the dominant term in the equation.
Bringing ML-family languages into the mix, YMMV. I don't like them, but some people do and that's fine. If you're going to use static typing, at least use a modern system for it.
Don't mix your religious preferences in with your very good rational arguments please. Lots of people on Slashdot can't seem to separate them.
Did Apple go straight to court? No! They said, "Stop it. We don't want you doing this. It's probably illegal anyways. Keep at it, and we WILL call the cops."
If that's not fair warning, what exactly is? You may have the luxury of going, "S'all good." when your neighbor has loud music on in the morning, but what about the people who have work in the morning?
Don't confuse the issue by saying that Apple is being overly litigious. No one is in court yet.
That's cool and all, but maybe you could just use an OS that doesn't require constant ghosting? Sounds like you've automated the task, so that means it must happen fairly often.
If that's the case, are you really getting bang for your buck? I dunno, but in our linux shop we don't reghost the machines, or reinstal the OS. They just don't break. I've never had to ghost/reinstall the few OS X boxes either.
A car that breaks often and is easy to replace or a car that doesn't break. I know which one saves me more money in the long run. Rememeber that as an IS guy, your time is money. If every computer in your shop could, at any moment, have to be reghosted, then you're probably wasting a lot of money as opposed to setting the machine up once and letting it run for longer periods without human intervention.
I know a lot of developers who also have to get down and dirty with UI design. I myself have had to do it as well. A lot of times, we actually have really good usability ideas, but it's hard to do right.
GUI programming is obnoxious in all but the best of frameworks. Making the intuitive interface, like something that's drag'n'drop, does what you expect no matter what you actually did, and interacts neatly with the OS is such a monumental coding effort that many times, it's a harder problem than what the program is actually supposed to do!
You'll notice that in Mac OS X apps written in Cocoa, you tend to see lots more whizbang features than in an app written in MFC. This is because the toolkit makes it easier for the developers to express these clever ideas.
UI designers get props, they know lots of tricks to make over a decent UI as an outstanding one, but if the developers can't live up to the design in a reasonable amount of time and effort, you're going to continue to see crappily interfaced software.
Both Java and C# have full dynamic type information and full reflection; the reflection system of standard CommonLisp has some limitations in comparison (although individual CommonLisp implementations often provided implementation-specific workarounds).
I suspect you haven't worked much with Lisp. Lisp's syntax (or lack thereof) means that macros, which are code generation specifications, are so much more powerful than lexical macros its not even a fair comparison. Further, they are safer and easier to code. So easy, in fact, that nearly every Lisp project includes dozens of macros (which in turn can generate the equivalent of thousands of lines of code). Can you say this about most Java or C# projects, where Code Generation is still considered a design smell?
Further, because the (same) Lisp image is running for the compile and run cycless, it's significantly easier to degenerate and compile and load code even late in a life cycle.
Both Java and C# have full dynamic type information and full reflection; the reflection system of standard CommonLisp has some limitations in comparison (although individual CommonLisp implementations often provided implementation-specific workarounds).
Again, you haven't worked with Lisp enough recently. In every way that could possibly matter, Lisp's facilities are superior. Especially now that the Meta-Object Protocol has seen widespread adoption, the facilities of Lisp are so far superior to C# and Java that it's not fair to compare them. It's possible to do Smalltalk-style metaclass programming, to dynamically update and reflect upon classes (and update all running instances transparently, try that in Java!), and to completely change classes dynamically.
Lisp syntax is nice, and you can program the JVM and CLR with Lisp syntax. But while I fully believe that Lisp syntax is great for programming, I think for data structures, it is a compromise, and XML and similar standard representations fulfill similar functions for other languages.
Given your inexperience with Lisp-like languages (which shows quite plainly), you might want to consider looking into it more before making such a bizzare statement. One of the reasons lispniks get so grumpy about XML is that XML is a more verbose version of S-expressions, but gets a lot of hype in the press (where Lisp suffers a lot).
When it comes down to it, they're practicaly equivalent except:
S-expressions are more convenient for human use and parsing.
XML is more convenient for computer use and parsing.
Otherwise, they're essentially the same and represent things in a similar fashion. Please update your mental database accordingly.
So, Java and C# aren't exactly like Lisp--they have made different choices, and you may or may not like the overall package. They are clearly not "dynamic" in the important sense of being "interactive" by default (although bsh helps). But in some ways (reflection, dynamic code generation, etc.), I think they are arguably better dynamic languages than Lisp ever was.
If the Lisp community ever got its act together and actually learned from Java/C#, they could produce a great response, something that combines the best of Java/C# and Lisp. But I doubt that's going to happen any time soon.
Lisp DID listen. They came up with CLOS and the MOP (meta-object protocol). If you bothered to understand what they did, you'd see they beat C# and Java to the punch by nearly a decade, and they're still ahead in every way that matters to programmers.
To even complain that "Lisp isn't dynamic compared to C#/Java," is actually hard for me to understand. Please, name one operation that you can do in C# but cannot do in Lisp (that makes sense to do in Lisp and C#). I know Java and Lisp pretty well, and I can't think of one.
It's great to see such a mainstream product as PHP being powered by a Lisp dialect(even if it is a Lisp-1).
In your Apple menu, you'll find a "Get New Software..." menu item. Selecting it brings up your (default, not necessarily Safari) browser, and shows you that listing. If you're interested, you can search by name or look by category.
I think you're going to have a hard time claiming it's hidden when there is a link to that region from the Apple Menu, which is ALWAYS VISIBLE.
... that while Sun can create classes with special semantics and overloaded operators, you the developer (you know, the person doing real work and/or paying for what Sun offers) cannot.
People talk about the consistency and elegance of the Java language, and it's hooey. Sun breaks their own rules all the time to give convenient little features like String +, but developers can't do the same thing.
I can't help but wonder why. Are developers not trustworthy enough?
No it's not. In fact, it's not even close to the definition of the "halting problem". The Halting Problem is "Given input X, and program Y, will Y ever finish it's calculation, and halt on when given X as an input". It's a 'problem' for which no computer program can be written to solve.
It has nothing to do with whether or not a compiler can convert a recursive algorithm into a non-recursive one.
You need to work on your compsci fundamentals. Many problems involving source code transformation reduce to the halting problem. The question that the compiler is asking in a general case destructive-recursive-to-destructive-iterative is, "Are these two programs equivalent?" This is clearly a case of the halting problem.
In practice, these kinds of optimizations can be pulled off in special case scenarios because the optimizer knows, a priori, about them. I would not be surprised if Sun's optimizer programmers threw this one in, maybe as a proof of concept or maybe for fun.
In theory, the only way you can really do this kind of transformation reliably is to make your program very simple. One of the reasons that functional languages like removing destructive operations and enforcing stateless functions is that it makes these kinds of optimizations easy.
Scheme for example, enforces optimization of tail-recursion to a loop. This is a hard problem in general, but Scheme's design has the consequence of making the optimization practical to do consistently.
Common Lisp. on the other hand, doesn't have such a simple basic structure and as such can't promise things like this.
Since the function called is virtual, there isn't much the compiler can do in ways of inlining.
This is outdated. The types of the arguments are known and fixed. The return types are known. The whole point of entering in all these tiresome type keywords (not to mention keeping them consistent) is to let the compiler do optimizations like this.
The only time that the virtual part comes into play is when the type really is unknown within that block, like when it comes into a function call as a parameter. The fact that G++ can't say, "Oh look, a NthToggle is coming out of value() even though it's typed as Toggle" for such a simple case" is kind of depressing.
I'd be curious to see if the IBM or Intel optimizing compilers could do that better. I know that other language compilers do this sort of thing, and in those languages all method calls are virtual.
Slashdot Mirror
You download a trial of the software. You hack it so that it's no longer time/serial restrictred.
Now, if the software detects this and encrypts/destroys itself, did it really affect your property?
You didn't legally acquire the software. You're the one breaking the law. If the software says it will do this-perhaps in a splash screen-then does it really count as ransom?
That's like saying you're violating a crook's privacy by using lojack to trace a stolen car.
Whizbang IDEs are nifty and all, but here's my feeling on it: if your language is so hard to work with that you require and IDE to develop and refactor in a reasonable amount of time/effort, then you do not have a language that is "a dream to code in." Having worked with Java, I'd say a powerful IDE like Eclipse is a requirement.
It's not that these IDEs are bad! They're great, but they should be the icing on the cake. Your language should allready be usable pre-IDE.
Not that I'm a huge C++ lover, but I have to say... you're right. It is a horrible comparison. MFC is the absolute worst environment in C++. Feel free to continue ignoring quality C++ tools for application development, like Qt, TAO, and the outright amazing Boost libraries.Sorry. Just because you can make a very old and relatively simple hardware-based game engine run in Java doesn't suddenly mean it doesn't suck. It still sucks, it's just that people are finally realizing why it sucks so badly (and it's not speed).
The idea that your code is so tough to manipulate that you need an IDE to make it viable should say somethign to you about the language in question. When we talk about the future of coding and machine-assisted development, I don't think this is the vision we want to see.
Refactoring Java code can be very tedious, especially if you chage a type that goes into a collection. Even with the new Java Generics, this is going to be a huge pain. In Python or Ruby or Lisp, it's transparent. Heck, even in modern statically typed languages like Haskell and OCaml, it tends to be almost transparent.
Java's manifest typing model is outdated and cumbersome. This fundamental feature of the language lends itself to every aspect of work within. The Libraries may employ some great OO patterns, but they still can't escape the fundamental... well... clumsiness of the language.
As for the next argument against Java? Why doesn't Sun trust developers? Sun feels it's okay to use operator overloading on strings, why can't I use it for my complex number class?
The argument that "you might abuse it" is a lame argument at best. Bad programmers shouldn't program professionally. Do you let a bad basketball player stay on a pro team? Do you let a bad accountant manage your money? Do you let a bad contractor build you a crappy house? Do you let a bad manager control the fate of, um, your... company?
The only reason I can see for this attitude is that Java wants to bring bad programmers into the fold. Why? Well... let's put on our cynical tin-foil hats and theorize for a second?
Forgive me if I think someone is trying to screw over real software talent by commoditizing it. The sad thing about it is that this makes the consumer the ultimate victim, since they rely on poorly-made software.
And before you say, "That's just conspiracy theory" consider how much money there is in the software market, and how many people there are who have no fscking clue about what goes into good software making decisions on how it will be made.
Hanlon's razor could probably account for it just as well as my little tinfoil pirate hat.
Now, people hating Haskell might just be jumping ona a bandwagon. People who hate Lisp might be jumping on a bandwagon. People who hate Ruby might be jumping on a bandwagon. These languages are comparitively rare.
But Java? No.
How about this then? Java's type system sucks. It sucks, sucks, sucks. Java generics are only marginally fixing the problem. You cannot design your program up front. Heck, to refactor Java most programmers say you need tools. If your language is so intractable that it requires a tool to make refactoring reasonable, then you have a crappy language.Java's primary GUI API, Swing, is not "brilliant." It's obtuse, lacks many features, and is unnecessarily slow.
Java's "Native Interface" (or FFI, "Foreign Function Interface") is hideous. It's difficult to get much of anything done at all. Ruby and Python provide much better models.
Are these complaints general and clear enough? Java is so riddled with flaws that it's amazing it's gotten this far. A living testament to the fact that marketing overcomes all.
The DRM only gets put on for purchased music. It is not intrisic to the iPod. The iPod is already open to competition. Feel free to make a service that sells music for it.
What's happening here is that Real wants to force Apple to support Real's DRM and proprietarty format. No one in the open source world stands to gain anything from this.
This isn't about DRM, or the DMCA, or anything of the sort. All that's businesses posturing and playing grown-up. It's expected, even if it's tedious.
What Real is trying to do is shame Apple into doing their engineering for them. Apple has a tightly coded product that sells very well, but which profit margins are smaller on.
Real comes along, figures out how to slip Harmony into Apple's current system, then complans when Apple says, "We reserve the right to break compatibility with this 3rd party, closed source product that is directly in competition with our music store."
People need to stop confusing the issues. Real wants Apple to give them something for nothing. It's a concrete effort to not break compatibility with this product, which can be measured in man-hours and engineering dollars.
And what excatly does Apple get back in return? Has Real made any effort to make Apple's job easier? If Real wants to open the iPod to their format, then they can pay Apple to do so, or offer up the engineering hours to keep everything working.
Or hey, they could open up THEIR format to Apple. Now there's a thought.
MacOS X is Posix compliant in spirit and in letter, and is "Unixy". This is a no brainer. Crawl back in your hole.
As for custom ROM images, dude, everyone does that. You're holding Apple to a standard no one else meets. It's not even fair, every motherboard needs detailed and specific configuration.
Comparing Quartz with DirectX isn't terribly unfair. It's also one of the minor sticking points. Quartz, incedently, is based on an Open Standard, OpenGL. DirectX is a standard unto itself. It's pointless to bitch about it anyways, though, since the underlying drivers are ALSO closed source. Get the hardware comapnies to open up first, otherwise the software being open is pointless.
As for your crack about 50x more programs, it's a cheap shot. I was referring to a specific comment Raymond made.
Apple has opened the OS. Apple has opened Rendezvous, which is a freaking crown jewel of the mac experience. Apple has advanced GCC tremendously. Apple is leading the way on next-gen web applications.
What more does Apple have to do. It seems like the only way to win with some folks is to not make any money at all.
But let's not lose context here. They're talking about whole categories of service. Look, I know you like Mac OS X. I love it. But it's not a necessary thing. There are plenty of other OS's. Software companies are not forced to release Apple-only software unless Apple shells out the cash and buys them outright.
And even then, we see Apple release PC versions and appeal to the PC market with the iPod.
There are plenty of other choices. Apple does not control the market. They are a tiny little corner-sliver of the market. Once they have Microsoftian marketshare, then we can worry.
Until then, calling a company that doesn't even have 10% of the marketshare in an open market a monopoly is a gross abuse of the word.
Buy everything but the motherboard somewhere else, if you're worried. People have done it without giving a dollar to Apple.The biggest obstacle is getting the OpenFirmware set up just so. And you can, as you mentioned, use LinuxPPC as a trampoline if you find this obstacle insurmountable.
Riiight. So Apple now has to cater to other companies who want to sync with their hardware. Why exactly? Because it's "fair"? I'm confused. Apple can't stop Real from releasing this software, but Apple doesn't need to help them either. The iPod is coded like an embedded system. Compatibility with a 3rd party extension would be hard to maintain. Not worth Apple's time. Remember, they have to maintain the code.Unless of course Real paid Apple for their time and gave them the format and the hoops they had to jump through. But then Real would complain that it's their IP, and it would undercut their online music store if Apple could offer their songs in Real Format too.
Let's get this straight. You're telling a small company in a competitive market that is currently favorable to give up advantages. Not because it's the law, or that it's even ethical. It's because people would find it convenient.
Real can't even be bothered to maintain mac compatibility on their store! This kind of deal has to go both ways. Real is getting something from Apple if Apple allows this deal. And what does Apple get in return? Apple can't afford to give away something for nothing, and all the work to keep Real's extension working would fall on their engineers!
Oh, and Real has a real history of quality software. I'm sure Apple is quite confident in Real's software engineering ability. NOT!
I could see Real saying, "Apple. We will give you money if you allow our files to play on your player. We'll pay you for the engineering and a royalty because we're in on your brand." I could even see Apple seriously considering such a deal. Heck, I could see Apple buying Real and heavily leveraging their tech to push themselves further in the PC side of the music world.
I cannot see Apple giving handouts to a competitor that doesn't want to give anything back except more competition.
Well, considering how much Apple has done for, say, GCC... saying they don't give a damn about open source is a rather tough statement to justify.
Incedentally, I'm curious what closed standards you're talking about here. The OS? Posix compliant, pretty fair standard. The hardware? It's all stock parts and OpenFirmware. It doesn't get much more open. How about we attack Cocoa's underlying window system, Quartz Ex? Bzzt. While the source isn't open, all the APIs and the supporting protocols are. Sure, Eric S. Raymond can't hack Quartz directly, but you'd be surprised how little that matters.
Look at what parts of Apple's OS are really closed source. It might surprise you to realize how little of the essential stuff is actually closed source.
You can build a computer capable of running Mac OS without resorting to buying one at apple. It's hard though. The hardware that meets Apple's specs is pretty rare.
You can do it though.
The only place this "openness" argument comes into play is with FairPlay. Know why it's closed? Because FairPlay is effectively security through obscurity. You can't make a system that really does what people want.
Maybe by "closed" you meant "expensive". I'll agree to that.
They don't believe it because hackers are part of a demographic that's notoriously anti-organized-religion.
:)
With folks like Ashcroft at the helm of one of the more frightening departments of the government, people associate Republicans with money, power, and religion.
What I think most people fail to realize is that right now, neither party really sticks to their core values. The Democrats want to restrict freedoms under the guise of social and economic reform. The Republicans want to restrict freedom under the guise of security and religous appeal.
Which of these looks more dangerous to the typical hacker's social sensibilities? It doesn't matter if in the end, the core of the US is totally ruined and discarded. All people see right now is the road to get there.
Of course, beware the gross generalizations.
From all reports, a PHB wanted Yahoo! Stores based in a language that was more mainstream. Yahoo! sunk a lot of money into trying to redo what PG's group did. And in the end they lost several features and had to write a bare-bones lisp interpreter in Java to get only about 1/2 of the html generation and templating functionality.
What was cheaper? Hire two (relatively expensive) Lisp hackers to maintain and upgrade the project, or sick whole teams of wage-slave-class developers to literally downgrade the product.
From reports, they even reimplemented the C code for image generation and the perl glue code. It must have been like watching lemmings march off a cliff. Lemmings with huge wallets.
The economics calculations that go on in these people's minds boggles me. It really does.
Python? Well it's basically Ruby with slightly less dynamism (to me anyways, guess which one I learned first). But Python programmers use many interesting OO idioms in their code which I've used in other languages (albeit awkwardly).
In my (not-so) humble opinion, Python is up there with Smalltalk and Self in terms of "interesting OO environments."
Yeah, but that statement collapses back to "learn languages X and (P or Q or R) and (A or B or C)" It really doesn't mean much. Paul and Eric Raymond recommend learning Lisp. It's an eye-openining experience. Some languages expose you to more ideas than others.
Java exposes you to one very narrow set of what's possible in programming. C's window is equally narrow (although much more complex due to the fact that C code can take the hardware into account much more, and tends to have tighter hooks to the OS). Lisp's window is quite wide. Ruby and Python and Ocaml also have very wide windows.
So, by selecting your languages carefully, you can learn a lot more in a smaller set or known languages. Thusly, virtuous programmers (which is to say lazy, of course) will pick and choose their languages very carefully, and it does matter which they learn.
Consider that Graham's premiere hack was Yahoo! Stores. It wasn't a huge project in LOC count (PG says this is because it was in Lisp). However, it was big enough that Yahoo! had trouble reimplementing it in more conventional languages (and in the end, actually wrote a simple lisp interpreter to handle part of it).
Yahoo! Stores wasn't a "small" project by any sense of the word. Maybe the upper boundries of "medium."
Agreed. However, I feel some strong type systems make good, test-driven design harder. Some type systems do not.
And the nice part about using a well-designed dynamic language is that you can plan for this, incrementally add code, hot-swap modules with debug modes, and actually look at the system at run-time in a much more powerful fashion. For instance... Deep in a library call in a C++ project, one of your methods throws an exception. You didn't know what that exception was. Your catch(...) handler can't tell you.
If you were using a language with more dynamic features, this problem could be solved.
Even then, this concern suggests to me that you haven't worked on a big system in a test-driven fashion using one of these languages. Such problems tend to become apparent rather quickly.
Actually, I consider this issue to be orthogonal to the language. If the code is well designed and idiomatic, it will be maintainable. If it is not, it will not. If we're talking about refactoring, this is why good unit tests and test-driven design is so important, they act as your safety net.
Working as I do in C++, I find the type system to be less than helpful when I have to do this kind of work. I've done 3 of these kinds of cleanup jobs. Only 1 of them had working unit tests (one didn't have tests at all!). Of the three, all were poorly written and used very unusual (not idiomatic) constructs (longjmp is verboten, people!). The only one I could edit with confidence was the one with unit tests.
All paradigms of programming give people ways to encapsulate work into bite/keyhole sized chunks. Be it Object Oriented or Functional (or even database languages, purely declarative and relational), they give you ways to design with foresight.
I believe this is not related to the type system. Although in the absense of unit tests, a type checker can sure be better than nothing!
And so I respond:
"Concise" isn't the word I'd use.
The GOF Patterns book has wreacked nearly as much havok as it has helped to prevent.
But when you say:
I must take exception. If you really believe that this buys you anything in the long run, you're the one extrapolating out of your ass.Let me qualify this though. If you're on a competant team who knows the language, and you are doing test-driven (not necessarily test-first, mind you) designs, then you're probably in better shape than a good static-typing-driven team.
Let's discard Haskell and the ML family for just a second, the truth is that in most of these higher-level languages, 1 line of code is worth many more than the equivalent Java or C/C++ line. Sometimes, we can even get into 10:1 ratios.
A 100000 line project is huge. But a 10000 project is managable by one skilled person. If your language, dynamically typed as it may be, lets you cut down the overall size of the project it is going to be a net win. Program size is to system difficulty as speed is to car breaking distance; the dominant term in the equation.
Bringing ML-family languages into the mix, YMMV. I don't like them, but some people do and that's fine. If you're going to use static typing, at least use a modern system for it.
Don't mix your religious preferences in with your very good rational arguments please. Lots of people on Slashdot can't seem to separate them.
Did Apple go straight to court? No! They said, "Stop it. We don't want you doing this. It's probably illegal anyways. Keep at it, and we WILL call the cops."
If that's not fair warning, what exactly is? You may have the luxury of going, "S'all good." when your neighbor has loud music on in the morning, but what about the people who have work in the morning?
Don't confuse the issue by saying that Apple is being overly litigious. No one is in court yet.
That's cool and all, but maybe you could just use an OS that doesn't require constant ghosting? Sounds like you've automated the task, so that means it must happen fairly often.
If that's the case, are you really getting bang for your buck? I dunno, but in our linux shop we don't reghost the machines, or reinstal the OS. They just don't break. I've never had to ghost/reinstall the few OS X boxes either.
A car that breaks often and is easy to replace or a car that doesn't break. I know which one saves me more money in the long run. Rememeber that as an IS guy, your time is money. If every computer in your shop could, at any moment, have to be reghosted, then you're probably wasting a lot of money as opposed to setting the machine up once and letting it run for longer periods without human intervention.
I know a lot of developers who also have to get down and dirty with UI design. I myself have had to do it as well. A lot of times, we actually have really good usability ideas, but it's hard to do right.
GUI programming is obnoxious in all but the best of frameworks. Making the intuitive interface, like something that's drag'n'drop, does what you expect no matter what you actually did, and interacts neatly with the OS is such a monumental coding effort that many times, it's a harder problem than what the program is actually supposed to do!
You'll notice that in Mac OS X apps written in Cocoa, you tend to see lots more whizbang features than in an app written in MFC. This is because the toolkit makes it easier for the developers to express these clever ideas.
UI designers get props, they know lots of tricks to make over a decent UI as an outstanding one, but if the developers can't live up to the design in a reasonable amount of time and effort, you're going to continue to see crappily interfaced software.
Further, because the (same) Lisp image is running for the compile and run cycless, it's significantly easier to degenerate and compile and load code even late in a life cycle.
Again, you haven't worked with Lisp enough recently. In every way that could possibly matter, Lisp's facilities are superior. Especially now that the Meta-Object Protocol has seen widespread adoption, the facilities of Lisp are so far superior to C# and Java that it's not fair to compare them. It's possible to do Smalltalk-style metaclass programming, to dynamically update and reflect upon classes (and update all running instances transparently, try that in Java!), and to completely change classes dynamically. Given your inexperience with Lisp-like languages (which shows quite plainly), you might want to consider looking into it more before making such a bizzare statement. One of the reasons lispniks get so grumpy about XML is that XML is a more verbose version of S-expressions, but gets a lot of hype in the press (where Lisp suffers a lot).When it comes down to it, they're practicaly equivalent except:
- S-expressions are more convenient for human use and parsing.
- XML is more convenient for computer use and parsing.
Otherwise, they're essentially the same and represent things in a similar fashion. Please update your mental database accordingly. Lisp DID listen. They came up with CLOS and the MOP (meta-object protocol). If you bothered to understand what they did, you'd see they beat C# and Java to the punch by nearly a decade, and they're still ahead in every way that matters to programmers.To even complain that "Lisp isn't dynamic compared to C#/Java," is actually hard for me to understand. Please, name one operation that you can do in C# but cannot do in Lisp (that makes sense to do in Lisp and C#). I know Java and Lisp pretty well, and I can't think of one.
It's great to see such a mainstream product as PHP being powered by a Lisp dialect(even if it is a Lisp-1).
In your Apple menu, you'll find a "Get New Software..." menu item. Selecting it brings up your (default, not necessarily Safari) browser, and shows you that listing. If you're interested, you can search by name or look by category.
I think you're going to have a hard time claiming it's hidden when there is a link to that region from the Apple Menu, which is ALWAYS VISIBLE.
... that while Sun can create classes with special semantics and overloaded operators, you the developer (you know, the person doing real work and/or paying for what Sun offers) cannot.
People talk about the consistency and elegance of the Java language, and it's hooey. Sun breaks their own rules all the time to give convenient little features like String +, but developers can't do the same thing.
I can't help but wonder why. Are developers not trustworthy enough?
You need to work on your compsci fundamentals. Many problems involving source code transformation reduce to the halting problem. The question that the compiler is asking in a general case destructive-recursive-to-destructive-iterative is, "Are these two programs equivalent?" This is clearly a case of the halting problem.
In practice, these kinds of optimizations can be pulled off in special case scenarios because the optimizer knows, a priori, about them. I would not be surprised if Sun's optimizer programmers threw this one in, maybe as a proof of concept or maybe for fun.
In theory, the only way you can really do this kind of transformation reliably is to make your program very simple. One of the reasons that functional languages like removing destructive operations and enforcing stateless functions is that it makes these kinds of optimizations easy.
Scheme for example, enforces optimization of tail-recursion to a loop. This is a hard problem in general, but Scheme's design has the consequence of making the optimization practical to do consistently.
Common Lisp. on the other hand, doesn't have such a simple basic structure and as such can't promise things like this.
This is outdated. The types of the arguments are known and fixed. The return types are known. The whole point of entering in all these tiresome type keywords (not to mention keeping them consistent) is to let the compiler do optimizations like this.
The only time that the virtual part comes into play is when the type really is unknown within that block, like when it comes into a function call as a parameter. The fact that G++ can't say, "Oh look, a NthToggle is coming out of value() even though it's typed as Toggle" for such a simple case" is kind of depressing.
I'd be curious to see if the IBM or Intel optimizing compilers could do that better. I know that other language compilers do this sort of thing, and in those languages all method calls are virtual.