Slashdot Mirror
Google Engineer Decries Complexity of Java, C++
snydeq writes "Google distinguished engineer Rob Pike ripped the use of Java and C++ during his keynote at OSCON, saying that these 'industrial programming languages' are way too complex and not adequately suited for today's computing environments. 'I think these languages are too hard to use, too subtle, too intricate. They're far too verbose and their subtlety, intricacy and verbosity seem to be increasing over time. They're oversold, and used far too broadly,' Pike said. 'How do we have stuff like this [get to be] the standard way of computing that is taught in schools and is used in industry? [This sort of programming] is very bureaucratic. Every step must be justified to the compiler.' Pike also spoke out against the performance of interpreted languages and dynamic typing."
doWhatIWant()
and
doItFaster(doWhatIWant)
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
So they are complex after all. Who would have thought...
Segmentation Fault
On what they mean for the language to do, and want the compiler to provide as much help as possible while allowing for as much flexibility as possible.
I'm sure Google will now tell us the javascript is the only way of the future, with embedded python for shits and giggles.
I'm sorry to say, Google is now officially my new Microsoft. Too big for their own good, to concerned with controlling the computing world for me to trust anything they say or do.
Shrug, I guess Google will go back to using VB and I'll become irrelevant as a programmer. I'm not going to lose any sleep over my concern for it happening.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
No,
What this world needs is competent programmers. C++ too hard for you? You shouldn't be programming. It's that simple.
"Efficient" languages are too complex. "Simple" languages are too inefficient.
Normally I'd write this off as "duh" but this is Rob Pike.
Oh wait, he's pushing something new that somehow manages to be easy and efficient? OK...
Pike detailed the shortcomings of such languages as a way of describing the goals that he and other Google engineers have for a new programming language they developed, called Go.
Oh, so he's pushing a competing product and denigrating his competition? Nothing to see here, I think.
I'd like to hear what he thinks about Perl.
0 = 1 + e^(Alt something)
And get your own company to think this way, too.
Interpreted code is great if you can babysit all the deployments. Generally, when you have to actually ship software, the sooner you find the bugs, the better. It doesn't get any earlier than compile time.
I have made brief forays into interpreted languages, and always feel immense pain and frustration from the lack of a compiler.
English estas too malmola! Paroli en Esperanto!
And where is the news here?
Picking the right tool for the job doesn't just cut down half the work time, but can help offset what sloppy workers do to destroy quality.
C++, Java, perl, C, forth, and sh are all different languages, and well suited to different jobs. But when all you have is a nailgun (i.e. all you are fluent in is a single language), every project starts looking like nailgun job, including your own foot.
Google Engineer promotes Google language Go and claims it addresses weaknesses of existing languages, including Java and C++.
Democracy Now! - your daily, uncensored, corporate-free
This guy has a lot of nerve telling other folks what programming language to use.
And i have the same problem with java/C++, and btw, the inventor of C++ standard says so.....So, why do we continue to produce Java/C++ bloatware???
You should bash Java, and C++ devs will agree. You should bash C++, and Java devs will agree.
Now you bashed both languages that has probably the most devs. Except some dynamic languages, of course (PHP and JS comes to mind).
Oh, you insulted them, too.
OMG...
How about "Rob Pike Decries Complexity of Java, C++" instead?
|Rob Pike| >> |Google Engineer|
Shorter Rob Pike: all those other languages suck, but the one I invented rocks. It's elegant and simple just like Lisp was back in the sixties!
I'm reminded of this blog post I read, where the author described it as "The Hurricane Lantern Effect". You look at someone else performing a task, and you think "geez, what an idiot! I can do it better in ten different ways!".
Then they hand the task off to you, and you slowly realize that each of your ten improvements isn't actually any better.
I bet you that if it's still around in ten years, someone else will decry Go 10.0 as being a "bureaucratic programming language".
If I need to write something very complex that no one else has written before, I can be confident that I can get the job done in C or C++. The mainstream compilers available today are mature and have well known behaviour. This simply cannot be said for any of the more recent languages, such as Python and Ruby (for example), that are *already* struggling with compatibility, performance and development issues that also plagued the "old" languages for years after their initial adoption. There is certainly something to be said for new interesting languages that can potentially make things easier, but IMHO there is FAR FAR more to be said for old languages that are much better understood for those who practice software engineering, rather than just "programming".
For an engineer working on the sort of massively complex computing problems that face the likes of Google he is entirely correct that the likes of Java and C++ are over-engineered and unnecessary for what he faces. That's spot on (I imagine, I'm not a Google engineer).
But most of today's computing problems aren't like that. The software industry has exploded in the past couple of decades, with close to every single business now demanding bespoke development in the form of websites, desktop apps, etc.
Those tasks are carried out by "code monkey" level people. People who need the over-engineering of a modern language because they're not really capable of writing code anywhere near the processor layer. They're puzzle solvers - people who glue together cookie-cutter libraries with the minimum of thinking. The people who use the languages Pike is decrying aren't the ones who're writing the frameworks and libraries that make it all so complicated, they're the ones who have to use libraries because they can't write code to do what the library does for them. It's hand-holding. It's necessary. Maybe not in the offices of Google, but definitely in the offices of "Joe Random Web Design Inc".
http://twitter.com/onion2k
These sorts of languages (and the underlying religious cults they bring with them) are probably appropriate for some uses. But what I see done in my life-critical real-time processor applications borders on criminal. Data hiding? How the f'ing hell do I check what is going on to the bit level is some twit determined to "hide the data". This is particularly apt right now, because we are adding a feature to our code that was almost trivial to add to our FORTRAN simulations, and because of the "cult of classes" C++ programming it's damn near impossible in the final product, and completely impossible to look at and tell what the heck it's doing. Trying to test it like a black box is never going to get to the level we need.
We started having peer reviews of the code, and my colleagues and I are the designers of the system, so we would hypothetically need to sign off on it. We went for two hours to get 10 lines into it, no one could explain how it was working but that we should just "trust the compiler". That didn't fly with us, so the solution was to *not have us present at the peer reviews* since we were "disruptive"
What we need is someone that can write straightforward procedural code, but no one seem to be willing or able to do it any more. It has all the features of a cult or a secret society, even when you get someone to understand and agree, they won't deviate from their dogma.
See, I'm already thinking about extentions.
doWhatIWantEvenThoughImTellingYouToDoSomethingElse()
Nostalgia isn't what it used to be.
"Pike also spoke out against the performance of interpreted languages and dynamic typing."
So, something for everyone to disagree with...
"Complexity" is a weird thing to hear whined about from a programmer who's apparently shilling for a language where this:
s := sum([]int{1,2,3})
is considered the "short way" to pass an array literal to a function...
Rob Pike likes to program in Forth in his spare time.
Take the cheese to sickbay, the doctor should see it as soon as possible - B'Elanna Torres, "Learning Curve"
slowDownAndCrashSoICanSellAnUpgrade();
The ______ Agenda
doWhatISayNotAsIDo()
Wherever you go... There you are. B.B.
...that they chose Java for their Android dev environment then...
Do not meddle in the C++ of Googlers, for it is subtle and quick to segfault?
Almost everyone programming computers these days seems to be too eager to forget what the computer is actually calculating. When you are writing software that has any need to perform within certain memory or time constraints, or scale to any degree at all, you need to understand your program at that level.
For example, for high performance searching it is critical to understand pointer arithmetic to build an effective hash table. Without that, either your substitute search algorithm doesn't scale efficiently, or you're depending on a likely-less-than-optimal generic library.
I knew a database developer who insisted that each record in a database match the block size of the disk in use. The computer then calculated the block that contained the desired record and read/wrote only that block. Developers in high-level languages just wouldn't give a shit.
I knew a graphics developer who looked for every opportunity to use powers of two so he could use bit-masking and rotating: rotate 1 bit right to divide by two, or XOR with 0x07 to get modulus 8, etc.
Optimization by understanding what the computer is actually calculating is fading fast, and teaching Java at the university level only accelerates that trend.
Slashdot previously interviewed Rob Pike.
Ceci n'est pas une signature.
That's what I program in Esperanto.
Go has the same problems. They try to make it 'simpler' but along the way they actually make it more complex.
For example, try-catch-finally idiom is an easy and standard way to deal with exceptions. But no, they had to invent their own half-assed implementation just to be 'minimal'.
Also, they insist on using fucking _return_ _codes_ to indicate errors. WTF? It only makes code more complex because of tons of stupid 'if error' statements.
Personally, I like Rust's ( http://wiki.github.com/graydon/rust/project-faq ) design more. At least, it has some new features.
I looked at Go. Not that impressed. Its easy to talk shit like this guy, but its a whole other thing to present a complete alternative.
...perhaps he should find another line of work. Quite frankly, I love C++, and Java to a lesser degree. C and its big brother C++ are great languages to learn. They teach you more about how the computer uses the code you're writing than something like CodeBlocks where you just fit them together in the right order. Good luck debugging software at a real-world company if you don't like C.
As for Java, I think it's a pretty inefficient language, but so is C# and .NET applications in general. Any managed code has overhead.
If you hate Java so much, why did you base your phone OS around it?
I could see if he was railing against Assembly or Fortran or something, but then even still many people love Assembly too. My Machine Architecture teacher was a fiend for it, and once I learned how it really worked it wasn't that bad for me either. I, for one, am proud to say that I could manually write machine code (if I really had to) though I have no plans to do so. I think every true computer programmer should BE ABLE to do so, whether or not they ever do. That would, in my eyes, make a programmer worth their salt.
If the only way you can accept an assertion is by faith, then you are conceding that it can't be taken on its own merits
Bring back Oberon and Modula-2! and teach Pascal in school again!!!
Not to sound like a dummy amounst you... but when we worked with Pascal I 'got it'. Towards the end, C++ was making headway... that's win I had to change from a major in CS to a major in marketing with a minor in CS!! LOL!!!!!
Who needs anything more complex than FORTRAN?
Some mornings it's hardly worth chewing through the restraints to get out of bed.
You could at least mention that Rob Pike had a large part in designing Plan 9, a programming language called Limbo, and oh, UTF-8, and that by "he and other Google engineers", TFA means Ken Thompson, who created B (a predecessor to C) and had a part in creating an operating system called Unix.
These two people are the closest thing to a "computer scientist" there probably is, and I'd wager they know quite a lot about programming language design. Pike is known about his feelings towards programming languages like C++.
Rob Pike made a talk about Go and programming language design and makes some interesting points. It's available on youtube.
Java/C++ are attractive because they have the momentum of a large community behind them. Newer, more friendly languages like ruby or c# may not have the same libraries available as some of the more well-entrenched languages do. Or, they might have similar functionality that does not perform as well due to some overhead of the language itself. Another reason we deal with these languages is legacy code. Once upon a time, coders of old wrote a massive system, spanning millions of lines. At that point, it's cheaper to maintain the system then rewrite it from scratch. It all comes down to how much work your language of choice incurs. At first glance, java and c++ are curmudgeon-y to deal with because you have to write more lines to implement function XYZ, but developers still use them because there are libraries and frameworks that implement functions A-W.
precisely because of what he seems to be complaining about, because they are feature packed and can do just about anything. Are they more difficult to learn and learn properly? Sure, but guess what? That's why its a job. Just like everyone else!
Your emergency room doctor knows the steps to bring you back from the half dead, very rarely does he need to use those skills when compared to everything else he does in the day. (broken bones, burns, run of the mill colds),but when he NEEDS that certain skill set to solve a major problem he has it available to him. Most other professions are the same way. You'll only need the hardcore stuff every great now and then; 95% of what you do will be the same old run of the mill, but when you need the hardcore, you need it, that's why they teach these languages as standards.
I tried my hardest back in college to really like programming. I failed. I was taught VB and Java. I just couldn't get around how foreign it is to me to think and write the way programmers do. I think we need a real natural language programming language that anyone can understand to use. Why not put the brains at Google to create such a programming language. I have been looking at Google's App Creator and it looks really neat. Visually creating programs is also another way to get people into programming.
I actually think that perl is the best programming language every designed.
(Waits for storms of laughter to subside)
No, really, I'm completely serious. perl is the English of programming languages. It takes the most useful parts of everything and mixes them all together into a useful conglomerate.
Much the same way you can use English to write a scientific dissertation, a sonnet (in full Billy S mode), or O RLY? perl can be as descriptive and formal or as loose and unbounded as the programmer chooses and it all JUST WORKS!
I **lothe** "bondage and discipline" languages that force me to think and write a certain way just because some would-be language guru thinks HIS way is the One True Path to enlightenment. perl gives me an expressive, more-than-one-way-to-do-it language that lets me think and work the way that best fits the problem at hand.
I have written enterprise-level perl code optimised for long-term maintainability and reliability (an LDAP server replication program that did schema translation). And I have written 5-second hacks that solved an immediate problem quickly and efficiently. perl lets me do this. No other language I've used matches perl's sheer versitility.
I love perl!
And I'm not at all ashamed to admit it.
DG
Want to learn about race cars? Read my Book
How many words are in english? A lot. (According to the OED folks, "The Second Edition of the 20-volume Oxford English Dictionary contains full entries for 171,476 words in current use, and 47,156 obsolete words. To this may be added around 9,500 derivative words included as subentries.") How many words does the average native english speaker know? According to this random website, 12,000-20,000 words. So English is complex, yet just 10% of the language meets a native speakers needs (less than that as we don't use all the words we know in normal conversation...except my wife when she's mad at me, then I hear every word she knows, many repeatedly)
So Java is complex. C++ is complex. I program in Java for my daily bread and I certainly don't use the entire language. It's only as complex as I need it to be. The complexity of my code is driven by what I'm trying to do, not by the language itself. And for code maintainability, I try to keep things as simple as possible.
It's been a long time since I've coded in a professional environment but I feel that having learned C++ you can learn any other language. It is complicated and verbose, but its extremely precise. Imagine having to learn how to manage memory with something like PHP. Actually -- because the new generation DOESNT LEARN C++ its why code is getting so sloppy now. There are easier languages sure, and using them can be fine, but if that's all you know, then you don't really know what your code is doing.
While I disagree with his general tone/point, I can agree that Java/C++ are overused. Both languages have been trying to push themselves as universal solutions (just look at all the crud added to C++ over the years from other languages) to be used in all domains, rather then were they are actually useful.
I feel this is bad in two directions.. it shoves the language into a domain where it does not fit, thus producing sub-par results... and it also ends up pulling parts of that domain back into the language, resulting in an increasingly bloated standard with redundant ways of accomplishing tasks.
Esp in C++, one has to keep asking 'so which C++ paradigm was this programmer working in?
We need to get rid of all the cruft of C++ and Java.. Things like Exceptions just add to Bloat... That's why GO is so superior.
... Go would be perfect if it also allowed for *some* manual memory management along with garbage collection. A large part of java's complexity that I see in big server type situations (> 8 G heap size) is that managing the gc parameters is almost a full time job. this is the theory and set of options you need to learn and internalize to get semi-satisfactory behavior from Sun's jdk1.5 gc. The complexity has only increased.... not decreased in later jdk's.
Yes, both languages are giant log jams of bilge. Glad someone said so. Back to C! Back to Scheme! We need a new OS too. There hasn't been a decent OS since CP/M.
Obvioulsy, hello world is not in any way a representation of the language as a whole, but it seems to me that Go is more complex that C++ and Python.
Go:
05 package main
07 import fmt “fmt” // Package implementing formatted I/O.
09 func main() {
10 fmt.Printf(“Hello, world; or ; or \n”);
11 }
C++ (haven't used in a while)
import #iostream
int main(){
cout "Hello World"
}
Python
def printer():
print "hello world"
I RTFA, really all he is saying is programming is Hard. Well Duh, I am sorry to hear that from Google Engineer. May be he will be better off using C# or VB.Net. Welcome to programming.
I kinda miss those days--easy to learn and embedded 6502 machine code subroutines to make things move faster.
"The only legitimate use of a computer is to play games." - Eugene Jarvis
The summary makes him sound like a winer with no solution. If you read TFA, you see he's pimping Google's new language, Go. That's perfectly understandable since they pay him; but TFA also points out that languages accumulate cruft over time, and Go is a baby.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
dontMakeMeTellYouWhatToDo(); -- turing complete
In soviet Russia, God creates you!
I used to be able to code in Basic, then in Turbo-Pascal, then in Turbo C, then in Turbo Assembler, Javascript, PHP.
But when I start XCode... I simply freeze because the damn thing is way to complex to even begin to understand what the hell I'm supposed to do with all those windows and menus.
That's the standard complaint of language designers about each other's product.
But which would you prefer: Simple programs in a complex language, or complex programs in a simple language?
(Not just an academic question. In a IRAD experiment on implementing TCP, the "control programmer" wrote about 300 lines of C for the 'ACK or Timeout' part of the protocol. I wrote 5 lines of Ada95.)
You obviously aren't paid by the hour to write java code, or else you'd have come up with something like:
ThreadFactory.getInstance().setExecutionTarget(new Runnable(){ public void run (doWhatIWant() }).addExecutionObserver(ExcecutionItemObserverFactory.getInstance()).start()
Which is much more "enterprise ready" than yours.
C++ is a metalanguage, in which you can define your own domain-specific language. That's all nice, but I suggest you don't. When you override operators like '=' and '+', you make things more confusing rather then prettier. Use a class when you need one, there's nothing wrong with structs and handles.
Before writing a program, ask yourself if it's inherently object oriented by nature. Sure you can model everything into a set of classes, but that doesn't mean you should always do so. I'm using dynamic datatypes, private attributes, inheritance, interfaces and then some all in pure C because they've been useful and are easy to implement. I'm not using Java-like exceptions and garbage collectors because I'm better off without them.
I'd use upper case only. You know, in some exotic environments... displays that can't display lower case letters.. the whole story all again..
e.g.:
DO_WHAT_I_WANT()
workItHarder makeItBetter doItFaster makesUsStronger moreThanEverHourAfterHour workIsNeverOver
The idea of programming as a semiskilled task, practiced by people with a few months' training, is dangerous. We wouldn't tolerate plumbers or accountants that poorly educated. We don't have as an aim that architecture (of buildings) and engineering (of bridges and trains) should become more accessible to people with progressively less training. Indeed, one serious problem is that currently, too many software developers are undereducated and undertrained.
Obviously, we don't want our tools--including our programming languages--to be more complex than necessary. But one aim should be to make tools that will serve skilled professionals--not to lower the level of expressiveness to serve people who can hardly understand the problems, let alone express solutions.
We can and do build tools that make simple tasks simple for more people, but let's not let most people loose on the infrastructure of our technical civilization or force the professionals to use only tools designed for amateurs.
- Bjarne Stroustrup
No sig today...
Some languages are way too complex and cumbersome, and this is being pushed about as something being 'good', or 'pro'.
whereas, in regard to practicality of applied sciences, engineering, realities of the production environment, this is BEYOND stupid to even propose. production environments need easy to use, simple, fast, fluid languages.
Read radical news here
Curse you techno!
I think he should try to write a few non-trivial programs in VBScript and see if he changes his tune.
Any insufficiently advanced magic is indistinguishable from technology.
C. It's just the right thing to do.
I never could grasp as to why we need to make programming "for everyone". Let's just realize that it's the complex task that it is and we'll all make more money.
We have a FoobarFactoryFactory class in the project I'm currently assigned to... yes, it's a factory that creates factories (which in turn create foobars). And the foobars are themselves generic-ish objects which can contain any number of different types of data.
And they have the nerve to tell me one of the qualities of higher-level devs is that "they tend to make things simpler than entry-level devs".
GiveMeMoney(DateTime.Now);
Even though for most people that's the first hurdle (and one that they fail), I'm not sure that this is the main reason programming is hard. I know plenty of people who've mastered the basic mechanics of doing that, and yet still don't program too well because they can't make their problem-solving ability scale to larger, more complex problems. You can understand at a fairly low level every single step that will be carried out to execute your program, yet be completely unable to write a large, modular and maintainable software system.
Are you adequate?
One of C's great advantages is not only that it is simple and very fast, it is also very close to the hardware -- when you make local variables, structures, assignments, etc... you have a good idea what the compiler needs to do. Likewise control structures, statements and so on.
The reason it is used is -- frankly -- because it kicks the ass of every other language out there (except machine and assembly) when it comes to both size and performance. This is because a C fragment turns into something very efficient and "close to the metal" if the compiler is even half-good, and that in turn is because what C does is very close to what the CPU does. Spend a couple weeks writing a C compiler -- just a C to ASM one for any CPU -- you'll see what I mean.
The only sense in which C is "harder" is that it takes more statements - because they tend to do simple things - than a higher level language to do many things. A little writing, a little building your own library... you'll have a nice resource for lists, memory management, graphics, in whatever area(s) your interest(s) lie(s.) And at that point, it's not harder -- it's easy, and it's fast as hell to write, and it *will* kick the butt of most other languages, as long as the understanding of the problem to be solved by the programmers is reasonably similar.
Also... I'm a huge fan of Python, use it all the time. Great language, totally wiped Perl out of my life (and for that, I am eternally grateful.) And as an interpreted language, it's not all that slow -- especially on a modern machine. But compared to C... no, I'd *never* use Python as a language for anything that required serious computation. You don't even need to go to C++ for some pretty cool OO - it's not only easy to do, it's educational and you'll actually understand what OO is doing, and why. If you need crazy OO, C++ is right there, and can remain efficient if you're really careful. Me, I rarely go there, but YMMV.
That whole too complex thing... what, was he hired by Google as a janitor? Or a janitor's helper? Seriously, too complex? For whom? Is he trying to teach a German Shepherd to program? Twit. If you came to my company for a job, and you told me C was "too complex" or "too hard", I'd just show you the door.
Have our standards really dropped that far?
I've fallen off your lawn, and I can't get up.
Objective C is arguably as complex as Java and C++. It's not hurting Apple any and the general integrity and quality of applications on Mac OS X is quite high. In contrast, Microsoft has much simpler language in Visual Basic and the application written in VB are arguably the lowest quality applications on that platform.
]{
This is coming from a guy that didn't think to use google before naming his language GO :-)
I still think that they should have renamed it to Google GO2.
It's not hard to learn Java but yes, it is often a complicated mess of shit when you want to use it on the web. Anything where you *have* to generate great swathes of code to keep your sanity is probably an over engineered shit solution.
Let's all switch to Ada.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
[nt]
What we have here is feature creep.
Usage: km/h for speed (kilometers per hour); kph for very slow impulses (kilopond hours).
You damn programmers, always forgetting about security. They key extensions are dontGetHacked() and protectAllPersonalData(). And of course once you're exhausted from all the computer hacking, you need to be able to call showMeBoobies()
If we're not supposed to code in Java/C++, and interpreted languages are a no-no, what's left? C, FORTRAN, and assembler? (I actually *love* C, but I don't have any illusions that it is the be-all and end-all of programming languages... IMO Python is capable of filling most of the niches that C does not.)
There is a middle ground here. Syntactically, there is nothing wrong with existing C-based languages. Simply building a better object framework accomplishes what Pike is trying to do, without changing languages. Thats why I use .NET, because if you learn to use the built-in objects, they do a lot of the work for you. Not to say .NET does this perfectly (far from it), but at least it seems to improve greatly with each new version. Ruby-on-Rails seems to be a step in the right direction as well - I tried it out and its nice, but it seems to make some simple tasks MORE complex with the standards vs. configuration philosophy. In summary: Pike is right, but we don't necessarily need a new language to accomplish what he wants - just better libraries. I think I will at least give Go a try though...
From TFA:
JavaScript is one of a whole batch of languages -- others include Ruby and Python -- that have been developed over the past 10 years in response to the growing complexity of C++ and Java.
Hmmm.....yes.....JavaScript was developed to replace C++...
I just hope, for the sake of your project, that the factory don't create foobars, but something else that you removed from the original
-- dnl
When I went to college in the late 1980's and early 1990's I learned as many programming langages as I could both in college and on my free time. Computer World thought I was notable enough to quote me as an expert on the subject based on a former Slashdot story.
Some argue that colleges should teach concepts and theories and choose the easiest language in which case BASIC (Classic Visual BASIC 6.0 and under) and Pascal (Turbo Pascal or Delphi) was used, then later as Java and C++ became popular because they can be cross platform.
Anyone remember growing up with 8 bit computers and using Pilot or Logo and giving commands to a turtle to draw stuff? It made programming fun.
But if anyone wants to do Modern Windows programing they'll need Visual BASIC 2008/2010, Visual C# 2008/2010 as that is what MS IT Shops run. You show them on your resume that you are a C++ and Java developer and they'll laugh at you and pass on you and hire someone with Visual Studio experience instead.
Don't forget Python/Jython, Ruby on Rails, and others.
I am trying to get off disability and do something as a hobby to help people. I want to write some beginner's eBooks on various programming languages as a cook book or step by step guide to learn how to program in Free Pascal, Free BASIC, ANSI C++, C#, Visual BASIC, Java, Python, and a few others. Make it the basics of the language from hello world to a program that maybe reads and writes records from a text file. Forget about the GUI and Objects and make it text based and cover those later. It will mostly be figuring out math problems and then maybe end up doing an employee payroll program that writes a report on salaries and checks. But will be under an OSS license so others can add to it and make it better later on. I'd also give source code with the PDF and consider putting it in RTF, ODF, and other formats so it can be read by almost anyone.
But my health and family come first.
Anyway the OSS versions if the OSS joins in we can turn into better eBooks. If not I will write intermediate and advanced versions of those books for sale for eBook readers and try to start up a small business as eBook readers and eBooks catch on.
All of this talk that "your language is too complex" is nonsense, look at how Complex the Modern English language is, so why don't we just drop English for Dutch/Flemish or German or French or Spanish? Hey learn the different dialects of Chinese as we owe their government a lot of money. BTW I am learning Thai, "Sawadee krup!" The r is usually silent and that is Thai for hello said by a male if a female says it then krup is replaced with ka. :) Yes I want to learn those languages as well but lack the time and money.
My resume was getting ridiculous as I had over 37+ programming languages I knew, most of them dead or dying or early being used. Maybe only 5+ are used in the modern world. So now if I rewrite it I will trim the number of languages to those still in use and say "and other programming languages not listed here, but ask for a separate sheet if interested."
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
Are you telling me that Esperanto (Estperanton == object form?) is like Latin, Russian, Greek, Farsi, and Sanskrit in using freakin' noun declensions?
Sarah McGlaughlin has a song lyric: "So you're working, building on a mystery, and choosing so carefully..."
I think another way to pose this poster's comments is: Are extended, overloaded, polymorphic etc object coding techniques always the optimal engineering solution?
In my experience, the answer is no.
Take the eternal mantra, particularly in the corporate domain, of writing reusable code. You can't reuse it if the guy who wrote it is gone and it imports and includes objects sourced from dozens or hundreds of other files, libraries, namespaces... (grab your rotten tomatoes know and get ready to throw!) A well written application, in assembler, C or Visual Basic or a page of ASP or PHP can be read as a self documenting whole and modified reliably and QA'd decisively.
Now covered in fresh tomato sauce, I freely admit that different tasks require different tools. But as someone who often has to focus on the business purpose of the code and not my personal mindset, simple readablity often trumps all else. And to the loon who attacked the original poster - attitudes like your closed mindedness make you the problem.
"Knowing everything doesn't help..."
People admire complexity. - Rob Pike
This, for example: http://en.wikipedia.org/wiki/Whitespace_(programming_language)
Look Java was a great try it just got a bit out of hand but it's close to what is needed.
To me the ideal language branches in two possible directions: something close to python+static_typing_capability or Objective_C_but_with_a_different_syntactic_form
I strongly suspect that that language that is as close to my ideal of python+static_typing is groovy. It has an almost seemless path from dynamic to compiled in it's syntax and java libs.
Objective C, everytime I look at it, I become convinced is what C++ should have been. All decisions seem really smart in hindsight. And it's very very minimimalist compared to C++. At the same time it has all the late binding advantages of Java. The only thing off-putting about it, is the method syntax. And even that, when you look carefully, is actually a really clever way to make things poly morphic.
Some drink at the fountain of knowledge. Others just gargle.
I think that, if anything, they've gotten less complex as the reliance on APIs and other pieced-together software components has increased. I certainly don't see a trend toward more complex software when I see all those iPhone fart apps.
My implementation of that is doTheRightThing().
The CB App. What's your 20?
Eventually, those higher-level devs will create a solution so generalized that it'll be its own programming language, within the programming language.
Although I mainly do hardware engineering, I also have done/do lots of 8/16/32 bit embedded prorgamming in C and C++. C is a terrific language for embedded. C++ is like a samurai sword, hard to truly master without killing yourself.
I truly loved VB6 as a RAD platform. I wrote a scientific application involving realtime data collection/control, database method and paramter control, realtime graphing, simultaneous multiple system control including sampling robots etc, that is still being used in hundreds of industrial labs around the world. It was written in around 4 months, and there is no way I could of done it in C++.
I think C++ sucks for end user app development for most of the reasons metioned by Rob Pike, but is has its place when you are close to the metal.
46137
Stroustrup (inventor of C++) is hardly a source of unbiased opinion on this topic. His elitist argument comes off sounding like "Calculators are bad because anyone can use them, engineers should use slide rules. Would you want someone designing a bridge who was too stupid to use a slide rule?" Professional programmers can be more productive if they are able to spend more time creating and less time fighting with their tools, and denying amateurs access to those tools sounds more like job-protectionism than professionalism.
Support Right To Repair Legislation.
I'm not even sure why I used "foobar". The actual class name is "DocumentFactoryFactory". ... not much better.
And this from the Company of ECMAScript!
Enough with the ECMAScript already!
Lets see have the functions you need are not supported by this or that browser and then throw in the crud from w and ie land and your left having to code things 2-3 ways and check browsers.
NO thanks.
Java or C/C++ is better.
1311393600 - Back to Black
I was joking.. ;-) But DocumentFactoryFactory is even better!
-- dnl
More realistically:
Syntax error detected at line 1...
doWhat??
Perl has a convoluted Object Oriented system, which is a bad thing these days. It also has lots of screwy legacy complexity. Hopefully Perl 6 will fix all this and remain Perl 5ish.
Wouldn't that make it unfit for enterprise use?
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
Does FoobarFactoryFactory keep all of it's possible factory configuration options in a ConfigurationMapMapMap>>?
That's, "La angla estas tro malfacila! Parolu esperante."
Come on over to Lernu.net and learn Esperanto for real.
What about an environment where you can eathily hide complexity and meta-information? Or, possibly, add new literalth? Where the bathe of the language is shifted to the Abthtract Thyntax Tree, not tho much the thyntax.
Fixed that for you. Programming with abstract syntax trees has been possible since Common Lisp if not earlier.
Worse... we're using Spring :(
If it can solve issues with programming with concurrency that Java and C++ have then it might be worth it but if it solves those problems then they will probably be incorporated as some point. I'm just tried of people like my boss saying that you just need to download Intel's compiler updates and then you're code will work with multicore perfectly. I've yet to find a magick bullet addon or compiler that's solved that issue, but if Google thinks they can do it the least I could do is check it out to see if it works.
You don't have to write in Java to run on Java. Languages like Clojure, Scala, and Groovy have come about an an answer to the complexity and verbosity of Java's syntax and structure - all running on the Java platform.
Java
// HelloWorld.java
class HelloWorld
{
public static void main(String args[])
{
System.out.println("Hello World!");
}
}
Groovy
println "hello, world"
Clojure
// hello.clj
(println "Hello World")
Brilliant observation! That is a problem with the pure Object Oriented style of code written by the typical Java Enterprise Programmer. Unfortunately all CompSci graduates all seem to produce this style of (crappy) code. I guess that is what the frameworks and textbooks show for pattern illustration, but it is a terrible style. However, this is not a fundamental flaw of the language itself (although it permeates most of the libraries). It is possible to simplify your code somewhat by consciously adopting a different style, that is POJO/Bean oriented and slightly more procedural. Also, if you take the 'simplify your code' mindeset rather than the 'purist O-O jihadi' approach (typical of Computer Scientists) you get a philosophy and code that is quite different. See BeanKeeper as an example of a library that rejects all the unnecessary constructs of man persistence frameworks. While BeanKeeper isn't perfect it is a step in the correct direction for Java.
From the article: "C++ came about because of people's frustration with working with the low-level C language" I think that's a bit oversimplified. Though I won't claim to know better than Rob Pike what caused C++ to come about, I do think there's more to it than can be said in one sentence. Part of the popularity of C++ was the new fashion of 'object-oriented' programming. Marketing types were eager to brag about how advanced they were because they were 'object-oriented' and the proof was that they were using an 'object-oriented' language. One thing I remember reading somewhere a long time ago, probably in some obscure usenet posting in sci.comp.lang or something, was that bugs were based on lines of code, and the language that got the job done with the fewest lines of code was the one that would have the fewest bugs. "Brevity is the soul of wit" according to Shakespeare's Falstaff, and the older I get, the more I tend to agree with that. APL is about the briefest language I ever encountered, but don't take that as a recommendation. (I sometimes think to myself that it gets its brevity by cheating, lots of special characters and operators, but I'm not ready to lodge that as an official quibble about it.) Hiding information, or fobbing it off into libraries, is one way to make things brief, but really, I think ideally, a language should present as much information in a 'page' of code as possible about what it is doing, and maybe APL, for someone really familiar with all the operators, would find APL to be great in that regard. I never had a chance to work with it with a proper keyboard and display myself. But if I were rich enough to be able to fund the development of a language, what I'd be asking my designers to go for would be, put as much information per character as possible about what the code is trying to do on the page in a human readable and human typeable, form.
In theory, theory and practice are the same; in practice they're different. (Yogi Berra & A. Einstein)
So he rips on traditional systems-programming languages for being too complex and requiring the compiler to justify everything, but then turns around and rips on dynamic typing, one of the biggest reducers of complexity in modern programming?
War is peace, complexity is simplicity, and Microsoft has always been at war with Google?
I looked at go and tried 2 months ago to find out if it had progressed. But that's one hard language to find. I mean, for a Google engineer, you might come up with a language that is easy to, well, Google? Or are they doing one of these: if you cannot find it we don't want you opinion kind of things? I mean, the C language is easier to Google!
Think Java and C++ are too bloated?
Don't like performance of interpreted languages?
That's a little language you might have heard of, its called C
If someone is passing you on the right, you are an asshole for driving in the wrong lane.
Ya know what I do? I write a few lines of gawk and do the job. I used to have to use netcat too, but now gawk does socket I/O so I ditched netcat.
If you can't solve a problem without using a language that requires a PhD in computer science, you aren't looking at the problem right.
I believe that would be com.sun.java.slowDownAndCrashSoICanSellAnUpgrade();
Look, the ideas of OO inheritance and polymorphism just represent what coders of "abstract" interfaces have been doing for years. A handle? Sure! Every "member function" is called with a pointer to the object as an implied argument. Functions specific to the class? Sure! static member functions. Need to separate interface from (one of) several possible implementations? Sure! No need for a hand coded and initialized dispatch table. The "virtual" keyword is your friend. And so on.
Now, that doesn't cover ALL the useful design patterns out there, but they really are common enough to have native language support.
If you've ever compared the kind of macro hackery that goes on to try to have some semblance of type-safety in C with a shared implementation (compare the various "STACK"s of different kinds of objects in openssl 0.9.8 and 1.0.0: lots of casting in the former, and attempts to hide it with macro hackery in the latter), you'd see what a blessing templates are.
And so on.
Have a problem with private, protected, and public members? Got something against information hiding? Really though, sometimes I wish I could friend all derived classes of some base class, though IIRC C++ won't let me. Would virtual protected friend be such a bad adornment to have? How about insisting that constructors of derived classes have the same signature (e.g. something like a virtual constructor)? That would save one from having a separate virtual "Init()" function? Why is it necessary? So I can pass the same arguments safely to the particular instance of an object I get from a factory when I ask the factory for an instance based on some run-time parameter WITHOUT needing to separate "construction" and "virtual initialization" when the distinction is artificial.
The whole point of the increasing subtlety and integration of common design patterns is to grant greater power to the programmer while also ensuring uniformity of implementation of the very most common and useful design patterns (though I can see arguments for overriding the implementation of virtual member dispatch tables to make them dynamic instead of being stuck with static ones in all instances).
Of course, with greater power comes greater responsibility. It's oft-said that while C lets you shoot yourself in the foot, C++ lets you chose among a dozen different ways of doing so.
I think what we really need is a mechanism to allow for the secure specification of language features that can not be used in certain circumstances. Smart pointers, and their benefits, are largely useless if any code-dufus can get their hands on a bald pointer to something and cache it away somewhere: '&' should be restricted as a member operator in some cases, to achieve this.
To put it bluntly: compilers for powerful languages should come with "training wheels" for (a) newbies, and (b) when one intentionally wants to restrict what one can express. In embedded systems, for example, it is usually desirable to preallocate all expected resources (including memory) at one phase of operational initialization, so that one knows one can't run out during later execution. Gimme a way to specify "thow shall not dynamically allocate memory here". Not because I want to shackle some other programmer because I think they are incompetent (though there is that benefit), but rather because I want the compiler to catch me coding something I didn't want to, for design reasons.
There is precedent for this: many early embedded C++ compilers intentionally did not support multiple inheritance, exceptions, or dynamic casting, arguably for performance reasons.
In Liberty, Rene
It's called C#.
What's wrong with that, google? Oh, yeah.. NOT INVENTED HERE
Go, can Go Blow. Hoopty fucking do, you eliminated the surrounding parenthesis in a for construct. *golfclap*
The project URL is here: http://golang.org/ Looks promising...
That's sign of a great OO programmer! If your code base is not super-metaphorical, you're clearly not using enough design patterns.
See, that's too complex.
needs to be: readMyMind();
err, even that's too complex, we need just one statement
"."
Only statement in the programming language should be "." denoting read software owner's mind and do exactly what they need to be done.
If the user is ever confused, the software must take the exactly correct action to rectify the situation.
No formatting C: just because the user blithely clicked 'Yes' to a confirmation, when the user has been mixed up the concepts of formatting and defragging.
On the other hand, if they intend to wipe the drive and re-install the OS and all software, while preserving all user data, then the OS must start and finish all this within 15 seconds, without asking any questions.
But the argument list is horrendous
They can use one my three implementations instead:
*(&theRightThing) = theProfitableThing;
doTheRightThing();
OR (simpler)
_((makeItSeemRight *)( doWhatIWant ))();
OR
item = new Thing;
[item makeThisEasy];
[item makeEveryoneElseThinkThisIsTheRightThing];
[item doIt];
That's a really crappy way of writing that code. Here's a better, more readable one (I've taken the liberty of guessing on the class names):
ExecutionItem spawnObservableThread(Runnable executionTarget, ExecutionObserver observer) {
ExecutionItem result = ThreadFactory.getInstance();
result.setExecutionTarget(executionTarget);
result.addExecutionObserver(observer);
return result;
}
void runIt() {
Runnable executionTarget = new Runnable() {
public void run() {
doWhatIWant();
};
}
ExecutionItem exec = spawnObservableThread(executionTarget, ExcecutionItemObserverFactory.getInstance());
exec.start();
}
The idea, well, it's just the basic good programming style thing that code should be written in terms of small reusable functions that do only one thing. So the main flaw of the original code there is that the details of spawning the thread and hooking it up to the Runnable and the observer are a common, reusable task that should go on its own spawnObservableThread() method.
There's really very little that can be done in terms of language features to make this code less verbose than what it is. The only things I can think of right away that would help would be lambdas and dependency injection.
Are you adequate?
Lisp can always give you a function (or macro (or OO method)) that churns out one of the above, which can in turn do anything it wants, including repeat the process.
Did you know, writing mini-languages is a well-known way to solve problems. Sadly, there are only a few languages in which I've known programs to use this technique. (C, Lisp, XML (which is all mini-language), and whatever Knuth wrote TeX in).
The business with deep pockets and large IT departments -that's banks and insurers- sort of drive us to monoculture. In earlier days it was COBOL that was suited to let hoards of application programmers be productive. Nowadays it's Java -with tons of restrictions. The idea is still to be able to follow the manufacturing industry and let programmers write predefined units. I this day and age still a crap idea IMHO bit the fact remains that deep pockets drive Java.
I'll learn new programming languages as soon as I can make money out of them. So today it's Java for me -and a bit of Perl, Bourne Shell and in extreme cases DOS BAT.
If I still were a student the situation would be different.
I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
I know that many will disagree with me, but about 10 years ago, when I set out to build up a large base of Linux application library code, I had to choose a language to invest in. I looked at perl, way too friggin slow, I looked at free pascal, which was really buggy at the time. I looked at some forgotten flavor of basic, which was in its infancy on Linux.
I ended up having to choose between C or C++, if I wanted anything close to optimal performance.
Happily, I didn't choose C++, and for the last 10 years, I have been derided by many who automatically assume that the ++ in C++ means its better. IMHO ... it doesn't mean that its better, it just means that its more bloated. A thing should be as simple as possible, not simpler. All you obfuscated C code contest fans out there, please, stay away. I prefer your "optimized" source language "tweaks" be as far away from my brain as possible, so that I don't accidentally assimilate your style via osmosis.
Source code, isn't just instructions for the computer to follow ... it is a form of stored knowledge. As programmers, we learn and research how the computer hardware works, and we store that information, in source code form, so that other people can benefit from our knowledge. Given this fact, I felt that C was a better investment, as not only would it be useable by all the C programmers out there, it could also be easily incorporated into C++ projects. Had I chosen C++, the source code could not have been incorporated into C projects, except via binary linking.
The process of writing and re-writing code, until you have a near optimal solution to a specific problem, regardless of the language, takes time. No amount of investing in PERL code will ever produce the near optimal results that you can obtain by investing in C code. Furthermore, once you have a near optimal solution in C, you can go balls to the wall optimal and incorporate ASM into it.
I may get flamed for it, but I'm gonna flat out say it. C is where it's at. You can even re-use your code on an 8-bit Arduino if you want. Or burn it to an FPGA.
Until someone comes out with a truly better solution, which C++ isn't, then I'm going to continue to invest in writing well documented, well designed, re-useable C code, as the last 40 years has yet to produce something better.
p.s. I know there are people with managers who need report X post haste, and perl fits that bill. That's not the kind of code I'm talking about. You wanna write throw away code in response to your supervisors emotional state, then it doesn't matter what you code it in, or how well its coded. rm solves everything.
call it MetaFactory
Its "more than ever hour after, OUR work is never over" come on man, every geek should know that song by heart.
http://www.dangermouse.net/esoteric/ook.html
Please do not read this sig. Thank you.
I must say I rarely find a comment on /. that I agree as much as I do with yours.
C and Python march hand in hand, one is for machine performance, the other is for programmer performance. If someone thinks C is too complex or too hard to learn then he shouldn't be working with programming computers, he's likely to cause great damage sooner or later.
However, there's one point where C will need a new approach: multiprocessing is coming. Since it seems like Moore's law has hit the ceiling at 3 GHz CPU speeds, all progress in performance for the foreseeable future will come from increasing the number of CPUs and cores working together.
I have done a lot of programming in multithreads using the pthread library lately and I feel that something better is needed, pthread is not close enough to the metal. I think some new fundamental elements may be needed in the language.
C is so great for programming because it mirrors the hardware closely. For instance, pointers work so well because they represent memory addresses. Before I learned C I had worked with Fortran, I still have some programs I wrote over 25 years ago. Today I look at those old Fortran programs and I wonder why I did some things the way I did. I see some convoluted loops and wonder why I did that because, with a quarter century hindsight on using pointers, I create almost instinctively the most efficient set of pointers to handle a data structure.
What programmers often don't realize is that the correct data structure may get orders of magnitude improvement in performance. To give one example, years ago, when I studied artificial neural networks, I read an article in the Doctor Dobb's magazine (January 1989, page 32, "Neural Networks and Noise Filtering" by Casey Klimasaukas). It was a good article, but the source code in C that came with it sucked. There was a struct _pe representing a processing element and each struct _pe had an array of struct _conn representing the connections to that element.
The problem is that in an artificial neural network what each neuron is doing is, basically, a convolution of two arrays. To do that efficiently in hardware you need to have the array elements contiguous in memory. When you put the connection weight in a structure together with other data you will not have that value contiguous with the weights of the other connections.
From an "object oriented" point of view that program was perfect. But if you want to use your multi-core CPU with that, the program sucks. That's the benefit you can get from programming in C that you won't get with other languages.
And don't tell me that raw performance does not matter because you can always get faster hardware. CPU clock speed has stopped at 3 GHz, we must learn to use our multicores if we want to evolve from now on.
I'm not even sure why I used "foobar". The actual class name is "DocumentFactoryFactory". ... not much better.
You could do some refactoring...It'd probably be a lot of work, so you could out source it to one of those places that specialize in that, a "refactoring factory". But all of that would require a proposal document...a DocumentFactoryFactory Refactoring Factory Document, if you will.
Track your TV Shows with your iPhone - FREE
This philosophy leads to awful code. Yes, it is perfectly reasonable for a program core function that performs B-C to assume that B and C are valid values. This doesn't mean that programs should not take care about data integrity, but rather that data integrity checks should be segregated from problem-solving code in order to make the program easier to maintain. Otherwise, you end up with your complex computation functions being riddled with data integrity checks right in the middle, making all sorts of insanse assumptions about what should be done with invalid data. This makes the complex computational code not only harder to read, but also provides an incentive to writing that code badly.
My most hated example is folks who write functions that, upon reaching a demonstrably bad state from which the computation can no longer recover, instead of throwing an exception do something stupid and irresposible like returning 0, null, empty string, empty list or whatever to the caller, who then runs with it and then either gets an error or produces a wrong answer. Writing "defensive" code in the way you advocate basically empowers people to write code like that, since they get to assume that it's the caller's responsibility to verify that the function's output is valid.
So, the general architecture should be:
See the Erlang Programming Rules and Conventions for some versions of these principles--in particular, aon't make assumptions about what the caller will do with the results of a function and do not program "defensively".
Are you adequate?
Very hard to find a main stream game that isn't written in C++. What with Ms pushing XNA and some other stuff like that there may start being a few more written in managed languages, but C++ still reigns supreme. Why? Speed. You can write some real efficient (from the processor's point of view) code if needed, but it still has higher level functions like being OO and the boost libraries to make thing easier.
Even on games made to be extensible, C++ is usually at the core. Civ 4 is mostly XML and Python. Pretty much all data is stored in XML, and the interactions of that stored in Python. However, the game engine is written in C++, as is the AI's DLL. The game core maybe you argue that is because they didn't want people messing with it but the AI they released the source code for. It is C++ because speed is essential.
Some programmers love to whine about C and C++, but they endure for many reasons. I'd also point out they form the core of most OSes. Linux is written in C. The Windows kernel is written in C, the higher level API/ABI stuff in C++ and only some of the user stuff in .NET. OS-X is again C and C++ at the low level, and Objective-C higher up. All of this is not coincidence.
doItRecursive(doWhatIWant) return doItRecursive(doItFaster(doWhatIWant));
It's possible to write crap code in any language. C++ just gives you more rope to hang yourself with. For example, I was googling the other day for fast vector classes and I found this gem. I see this kind of "trickery" all over the place. The ability to obfuscate your code like this is positively encouraged in the C++ community, at least among those who do not have to maintain their own code, or other people's.
I am pretty sure I heard such a speech 10 years ago, before Java came out.
Best Regards,
Condensed matter physicist - fluent in FORTRAN 66, FORTRAN 77, Fortran 90, Fortran 95 and even some parts of Fortran 2003.
So slashdot is posting a slashvertisement for Go. Shocker. There are so many raving google fanbois here.
That said, the points about Java, C++, and similar "do everything" languages aren't baseless. There's a lot to be said about using DSLs dedicated to specific software tasks. Reducing the domain coverage of a given tool significantly reduces the potential for doing unexpected things and adds dramatically more options for early detection of incorrect behaviors in the context of the task at hand.
Also, offering a better opportunity for modeling algorithms in a way that best suits that algorithm is a great goal too. However, no single language is the solution that this complaint begs for. So this slashvertisement for what is effectively just another Java is pretty unconvincing.
I read the script, and I think it would help my character's motivation if he was on fire. -Bender
The main problems of the major languages are known, but not widely recognized by many programmers.
The killer problems with C today mostly involve lying to the language. "int read(int fd, char* buf, size_t bufl);" is a lie; you're telling the compiler that the function accepts the address of a pointer, while in fact it accepts a reference to an array of char of length "bufl". This lie is the root cause of most buffer overflows. The other big problems with C involve the fact that you have to obsess on who owns what, both for allocation and concurrency locking purposes, yet the language provides no help whatsoever in dealing with those issues.
And that's where we are today.
... where credit is due. I'm still having his "The UNIX Programming Environment" book from 1984, co-authored by Brian W. Kernighan. Google has undeniably good engineers, but Rob was famous long before Google emerged at all.
cpghost at Cordula's Web.
If C++ and Java are "too hard" for him he should find another line of work. Retard developers... jeez
"Smartest Motherfucker in the Universe Syndrome" and many programmers are afflicted. They think they are so much smarter than everyone else. So any time they hear about a program having bugs or a security hole or a slowdown they say "Man the programmer that wrote that is an idiot! I could do so much better!"
Of course, they are not nearly as smart as they think they are, and have plenty of bad practices, bugs in their code, etc. they don't notice any of it, of course, because they believe what they did was great because of how smart they are. They can come up with a million tortured justifications for what something is how it is, or they'll just tell you that you are wrong.
Very, very common with geek types, probably because they tend to have an above average intelligence and thus are smarter than many people they meet and below average social skills.
After about eight years stuck at the same speed, I wonder what do you mean by "today".
Yes, yes, I know all about the Megahertz Myth. But that's the marketese speech for evading the issue. The fact is that the "Megahertz Myth" is a myth. It's obvious that, all other parameters being equal, doubling the CPU clock will double your performance. It was only when some companies couldn't keep increasing the CPU clock that they invented this lie that megahertz don't matter.
The problem with increasing performance by other ways than raw CPU clock is that it will not necessarily translate in performance increases for all applications. Apple and AMD had to carefully construct their benchmarks to justify this pseudo-myth.
It's true that, with the CPUs we have had for a decade now, many tasks can be done easily with interpreted languages that weren't possible before. That may be true for many corporate desktop applications, no one will care too much if it takes one or two seconds to get a list of how many "snibbo" widgets were returned for maintenance last month.
However, there are still many applications where CPU performance still falls short of the ideal. Improving those applications demands a language like C, because with "higher level" languages it's harder to get increased performance from parallelization. It's not always obvious which operations can be done in parallel and unless interpreters become a lot more efficient at this, there will always be room for compiled languages at the top.
And that is not understanding how a computer really thinks. What I mean is how a processor actually deals with data, how a program flows at the lowest level. I'm not saying everyone needs to be an assembly head, but there needs to be a good understanding of the fundamental realities of a computer. The reason is that a higher level programming language is just an attempt to make all that easier for humans to deal with. They can use a syntax that is easier for a human to create (rather than the extremely atomic nature of machine code), they can add features that are nice models for things we use (like objects), and they can enforce standards (like variable types) to keep us from screwing up as easy. At the end of the day though, they have to translate that all down to machine code and you have to play in the computer's world.
What that means is you have to have certain concepts, like exceptions. You can't have something where the language is told "Do this and if it does work, figure out why and make it work." Computers can be told to do something and if it doesn't work, it doesn't work. They have to have instructions as to what to do next or it just fails outright. That is just how it goes at the base level.
As such, languages are going to be a bit complex by their nature. They have to have all the complexity needed to deal with what the CPU does. Also, they probably have to have additional complexity to try and make things easier for humans.
It is just a balancing act and there isn't an ultimate perfect right answer. However trying to go all minimalist and cut out necessary shit is NOT useful because you just end up either making it hard to impossible to do things, or making more work for the programmer. Assembly is minimalist, look where that gets you.
We can't have a truly easy AND powerful language until we have AI. What we'd like is to be able to explain things to a computer in vague, human, terms and have it work with that. We can't do that yet, and who knows if we ever will. So for now, languages have to be a compromise between what humans want and what computers need. That means some complexity, and it means some concepts that humans may not be as familiar with. That's life.
They are called domain specific languages and are often very useful
Looks like slashdot isn't C++ friendly.
You sound like exactly the kind of programmer we want ! How about an interview ? We'll pay the flight to redmond.
This is just a symptom of the trend for programming languages to be as abstracted as the apailable computing power allows? Computers are now powerful enough for programming to be done entirely without the use of lines of code. Just like the generational changes from assembler to compiled code to interpreted code, the next jump will be to a programming method that requires even less technical skill. Maybe. We'll see soon, i hope!
I have no
I knew it was only the matter of time when somebody with a good pedigree will again hit C++ in favor of C or Java or... Python? (meh)
But to hit Java and C++ at the same time, that is something new.
++
Oh, so he's pushing a competing product and denigrating his competition?
"Product" is a pretty poor word choice for something that's given away in the way Go is. Pike doesn't really have much more to gain than *you* do from the adoption of Go and reduced use of C++ and Java.
Nothing to see here, I think.
Only if the substance of his criticism doesn't hold up. My experience suggests his objections are apt, and I might add that a casual dismissal of work by Rob Pike and Ken Thompson reflects more on you than them.
Tweet, tweet.
It just FEELS like "hour after hour work is never over".
C is full of baggage. The worst of it is the standard C library. From functions which do no bounds checking (vulnerable to security exploits), to a standard string library which was made for single byte ASCII encodings. In today's global world Unicode support is essential.
There are other things which are not in the basic C language but should: parallel programming support, sockets, a type system which more accurately reflects modern CPU architectures (where are the vector types, POPCNT, or FMA?).
C++ on the other hand has an overly verbose syntax, mixes data declarations with code (which makes compilation slow and code reviews cumbersome), has brain damaged standard I/O (C++ streams are horrible). C++ does not actually fix any of the actual issues in C, but adds tons of cruft in an attempt to improve the expressiveness of the C language while mostly failing. Oh and get this ISO C committee. I do not need to be able to declare my variables anywhere. Variable length arrays, now that was actually an improvement.
Java and C++ are bloated piles of crap, anyone with more than a decade of programming experience knows that. (I'm currently using C++ as my main development language so don't get me wrong.) He's also right about scripting languages, their performance mostly is shit. ("B..b..but Python with the new JIT compiler..." I hear them say. My reply is: "Oh yeah, well, I'd say it's a SHIT compiler, not a JIT compiler!")
Anyway, from time to time I enjoy checking out a programming languages I didn't use before. And like many people over the years I've used many and taken a look at even more of them. So I thought I'd share my opinions in a good old Usenet-style fashion, starting an immediate programming language flamewar. For a start, I still haven't found one that I really like, although most of the time the problem is not the language itself but the (lack of) support libraries anyway. Functional programming languages like Haskell or ML are nice and fast, but sometimes you just need mutable data structure for efficiency. They also far too often rely on arcane and overly complicated concepts. (Monads anyone? Why not program directly in category theory instead?) Lisp and Scheme are also nice but too dynamic - even with test suites you miss too many bugs. I haven't tried typed Racket yet, but knowing the traditional Racket (formerly Plt Scheme) quite well I suspect the typed version is just too much of an `addition' on top of the untyped language.
Now here is the language that I'd like to see but just doesn't seem to exist:
That's it. I know that a new language is not strictly speaking needed but I'd surely like to see one with the above features. Any volunteers? :*)
Same old tired, outdated stuff! Yawn.
``C++ and Java (in past years or decades, Pascal, Ada, or whatever) are too big, complicated and declarative. [Unassailable Axiom]
Dynamic languages are nice but are interpreted and have no static checking. [Please, believe me, I'm a famous programmer.]
Enter Wonder Language. Fixes all these problems. [I promise]''
My favourite is still:
Branch on Bug
OSCON 2010: Rob Pike, "Public Static Void"
Oh ok haha, sorry then man, carry on :B
Don't forget
addTheLifeSavingFeaturesINeed ButThatBloatTheOtherGuysWantAboutFuggedabodit
OH, you said FOObars!
Now you just need to derive a Foobar class that includes a FoobarFactoryFactoryFactory method (oh, and emacs). Of course once you add emacs, you can just implement the Foobar within the lisp interpreter within it's own emacs method.
But yeah, FoobarFactoryFactory is exactly the sort of thing that's wrong with Java.
I'm not even sure why I used "foobar". The actual class name is "DocumentFactoryFactory". ... not much better.
You could do some refactoring...It'd probably be a lot of work, so you could out source it to one of those places that specialize in that, a "refactoring factory". But all of that would require a proposal document...a DocumentFactoryFactory Refactoring Factory Document, if you will.
Why stop there? With only a little more abstraction you can have a DocumentFactoryFactoryRefactoringFactoryDocumentStrategyBuilderFactory. Next up, the Systems Hungarian annotation for that marvel of modern software engineering!
"Little does he know, but there is no 'I' in 'Idiot'!"
Here are my thoughts on the matter.
COBOL and FORTRAN came out and BASIC was created to teach it, it combined features of both. Many students took one intro course and that happened to be BASIC. When they graduated and the time came to do a programming project, BASIC was all they knew and so all that was used. BASIC, and the programming paradigm it was built around went into production. It was never intended for production uses.
The same thing happened with PASCAL. It was intended to be a teaching language but was put into production by the clueless.
OOP came along and everything shifted to C++ for many of the same reasons. The JAVA showed up, repeat the cycle. Java is now being used for large apps., when it first appeared it was intended for small scale internet apps. It was pushed into areas it wasn't intended for originally.
The feedback part of the cycle was that these projects then required people trained in that language and paradigm.
Another part of the problem is that many of those teaching programming don't know anything about managing projects.
That is how we got here. And in fact most of the code I've seen, and code I wrote when I had less experience, is nothing more than COBOL "in drag".
putting the 'B' in LGBTQ+
Oh dear, you're not part of the Windows Communication Foundation team are you?
I have this exact situation. I've spent the last 3 days reading about how bindings create binding elements that create channel listeners and/or channel factories that create one of about 7 different channel classes that may or may not do some sort of processing on the messsage that ultimately gets sent to the transport channel. And thats before taking behaviours and contracts into account. "Enterprise Ready" code sucks when all you want to do is search/replace to change a namespace before the message gets sent to the transport :(
The computer should never be allowed into an erroneous state. If an instruction does do that, it should not be allowed. So for example, if I do
#include "SomeHeaderFile.h"
and end up with a compiler error that SomeHeaderFile.h is not found...that means the IDE allowed me to do something stupid. Furthermore, it should know about possible dependencies and lead the programmer to possible dependencies.
If a function signature is
void MyFunction( int iParamOne, int iParamTwo );
and I do something like
bool bParam = false;
MyFunction( bParam, 1234 );
the IDE should stop me.
char* pLetters = new char[64];
pLetter[65];
Even the worst programmers might not do this, but I'm just making a point. Anyway, etc... with these types of ideas.
Almost every bug on the planet is a result of something stupid that really could be detected by the IDE/Compiler. I've never seen someone find a bug and say "My code was brilliant" These types of things shouldn't even be happening anymore.
The reason I feel really alone, is that everyone I know thinks these kinds of things are no big deal. Even if you waste 5 seconds as a programmer, that can add up to significant amounts of time and brain cycles.
One should never perform the same task twice on a computer, else they have missed the point of automation.
but no simpler, Albert Einstein said that. and i think that the choice of the language and abstraction level should be choose d according to the problem.
"Except mine. I wrote GO, its the holy grail."
*yawn*
---- Booth was a patriot ----
The Java Class library is huge, overly complicated, and incredibly difficult to learn how to use.
It could use a goodly amount of flattening.
It is a cryptic (to the uninitiated) but handy quick-n-dirty tool:
/^\s*#/;
/$self->skip/;
perl -pne '
s{\\}{/}g unless
' < pathlist.old > pathlist.new
And it is a full-featured, easy to read and write modern language:
perl -e '
use MooseX::Declare;
class Replacer {
has skip => (isa => "RegexpRef", is => "rw", default => sub { qr{^\s*#} });
has from => (isa => "RegexpRef", is => "rw", default => sub { qr{\\} });
has to => (isa => "Str", is => "rw", default => sub { "/" });
method filter (FileHandle $in, FileHandle $out) {
while (<$in>) {
s/$self->from/$self->to/g unless
print $out $_;
}
}
}
my $replacer = new Replacer;
$replacer->filter(\*STDIN, \*STDOUT);
' pathlist.old > pathlist.new
These two blocks of code do the same thing: replace back slashes with slashes
on all lines not starting with zero or more whitespace characters followed by
a hash character.
No language can be all things to all people, but Perl is currently all things
to me.
The language it was written in was Algol 68. What contributed to my success was an expressive static type system, and garbage collection. Unless you specifically turned run-time checking off, you could not break the run-time system.
Oh, and did I mention that the compiler generated low-level efficient code as well?
But there are few Algol 68 compilers around these days.
Looking to what *is* available nowadays, have a look at Modula 3. It's not my favourite style of syntax, but programs written in it tend to run fast and be easy to debug. Again, most of the bugproofing lies in the static checking and garbage collection. And it's a systems language. It has been used for implementing OS kernels and the like, as well as application programs. It's my language of choice at the moment. Get the CM3 implementation. Follow the link in the Wikipedia article.
Another attractive language is OCAML. I haven't much experience with it, but it seems to share the behaviour I've grown to love with Algol 68 and Modula 3. If anything, though, OCAML does too much automatic type inference. This leads lazy programmers to forget to mention types at many strategic code locations. making the code unnecessarily obscure.
It was actually Adam de Boor who discussed JavaScript.
And while JavaScript has its warts, all in all, it's a pretty nice language. If gmail is 400k+ lines of code in JavaScript, it would have been well over a million (if not four million) in Java.
Tweet, tweet.
Which does suggest that a good language should be capable of many different levels of abstraction, as required by the problem. In particular, the language shouldn't be what determines how you chop the problem into modules.
As somebody who had programmed, apart from C, C++ and Java a lot in LISP, Ruby, PROLOG, and OCaML (and a dozen others) I have had those feelings about C++ and Java for years. Larry Augustin is wrong about why these languages are so clumsy, verbose and subtle: it is because they are simply badly designed from start or because they inherit bad design from very old badly designed languages they want to be similar to.
Personally I think that Scala is a very good candidate for a language to solve most of the problems with C++ and especially Java. It is well designed, modern (supporting closures, currying, actors, pattern mathinc and more), without inconsistencies (like some things being objects and others not) has a lot of very useful language features and since it runs on the JVM it provides an excellent way to stay compatible with your existing Java software and gradually move to Scala.
I do not know GO nearly enough to comment on it.
"I think these languages are too hard to use, too subtle, too intricate. They're far too verbose and their subtlety, intricacy and verbosity seem to be increasing over time,"
I think these verbose languages are too hard to use, too subtle, too intricate, too verbose. They're far too verbose and their verbose subtlety, verbose intricacy and verbose verbosity seem to be increasing over time
increasing verbosity, you say
doIntegrateUnspokenUserRequirements();
At least there's one more old fogie out there. I have to agree but I don't think it's the language that's the problem.
It's the keyboard jockeys who insist that everything has to include a pattern of some sort or it's archaic crap.
-- Programming with boost is like building a house with lego. It's a cool but I wouldn't want to live in it
Sorry to say this, but you feel alone is because you are too green in programming. Do more, a lot more coding and you'll feel nothing is out of the ordinary.
One of C's great advantages is not only that it is simple and very fast,
What you say was true in the 1980's on the PDP-11. Today, C is a complex language; if you think it's simple, you don't understand it. It's complex because its semantics are so subtle: a lot of things are implementation dependent; they seem to work until you port your code. Furthermore, C is not an "efficient" language. On modern hardware, you need excellent optimization, but C's semantics make good optimization quite difficult.
It is possible to have a powerful, low-level, simple language; C isn't that language, not even close.
That whole too complex thing... what, was he hired by Google as a janitor?
Here's the Wikipedia entry on Rob Pike. Any experienced C/UNIX programmer should know who Pike is. He has been programming in C even longer than I have (I'm going on 30 years of C programming).
It's been a long time since I learned programming in C. Note I said "C", not "C++". C++ was new when I was learning. I learned C, then I took a look at the plus-plus extensions since the compiler I was using (Borland C++) supported it. After I got the gist of it and wrote some small programs using it, I said "Gee, that's nice, but it's the long way around unless you're working with really complex data" and never used it again. I still feel that way about it: being able to overload otherwise garden-variety operators to work with complex data is really cool, so are the other features of C++, but for many things they just aren't necessary and shouldn't be used.
Are YOU using the TOOL, or is the TOOL using YOU? Think about it!
See, I'm already thinking about extentions.
doWhatIWantEvenThoughImTellingYouToDoSomethingElse()
Too bad my wife already has a patent on that one!
Segmentation Fault
Despite their underlying simple syntax (which it is) C++ is complex as a whole. Same with Java. Any hack can program to their heart (read paychecks) content, but not everyone knows how to actually use these languages well and appropriately.
Do you know who you are dissing? Did you read the article? No, and no. He never said anything against C, he said C++ was too complex not C. So you echo him and slag him off over your misreading at the same time? One of the founders of your profession? Standards dropped? Yep, sure. But whose?
Next he tells me he wants computer scientists and programmers to solely use LabView and MatLab.
Gee..
I guess goog were hoping a lot more people to jump to the Go bandwagon just because they announced it. Yet it really didn't happen... I don't think bashing other languages is really going to improve on it.
Both c++ and Java have their strengths and uses. Java is IMHO HORRIBLY ANNOYING TO CODE IN, but that's actually its strength, it just won't let cowboys get away with doing the things they love to do. Sure, it has been lacking in things, but they update it around, the following update will have some very nice syntax for some data structures (it will get more complex).
The C's also have the advantage of being closer to the hardware, sure you don't need that most of the times, but when you do, they become a great tool in your box, really. It has improved a lot over the years (also known as getting more complex).
Interpreted languages cover for their downfalls when you don't need performance or want to do fancy things with paralel programming. Which is good. Python goes around also improving and getting more complex.
And there lies Go. Its main advantage over other langauges is exactly that. As it is basically undeveloped, it is much closer to what its creators originally wanted it to be. The thing is, that once it starts getting used, and users notice that for example it is pretty necessary for a compiled language to have say generics or exception handling... it will forcefully have to end getting modified and improved and thus it WILL become complex. I do not think that advertising it as "simpler" will work out as since it is a langauge that is intended to be used it is basically doomed to become more complex and thus this selling point will necessarily die. They should advertize it for its superior parallel computing and fast compiler speed, but simplicity... is just a bad idea.
Copyright infringement is "piracy" in the same way DRM is "consumer rape"
pretty well, actually.
damaged by dogma
you mean fork and kill?
Read between the lines. He doesn't think these languages are too hard to use for him, he thinks they're too hard to use for normal people.
On one hand, sometimes you really need such genericity.
On the other hand, every time you actually write a factory by hand, you need to keep in mind that the reason isn't because that kind of mundane work has to be done by a human, but because your language doesn't do its job due to it being oversimplified, and its features not good enough to express this kind of genericity explicitly, letting the compiler do all the actual work of generating repeating code (and folding it where it's duplicated). Java is a very good example of that, but most mainstream languages are guilty of it to one extent or another.
... Next time I'm looking for a job, remind me not to work for Microsoft.
This is off-topic, but you made me remember it...
CString, from MFC (you should all be shuddering right now) had a bug where under the right set of conditions, you could accidentally erase the data in every CString instance in your program. This becomes problematic in million-line programs.
I still haven't figured out why Microsoft didn't just use std::string.
Can I use this extension as a signature? It reflects my corporate overlords' current philosophy exactly... only they call it "Urgency"
... the more I like Object Pascal.
Indeed. If you want to shoot yourself in the foot - and you know you're going to do that, sooner or later - why not pick the most elegant and traditional tool for that? ~
And I was thinking something a little more classy:
neverGiveThisUp(You);
neverLetThisDown(You);
Common Sense
At this point I have used both OpenCOLLADA and OpenSocial from Google, and both I found overly complex and bizzare - as if their developers didn't understand how to write a clean API. They really feel to me like they were written by a graduate student who's experience with API coding up to that point was limited to a few College courses.
Now, as an application developer I really appreciate the power C/C++ affords me. Thread handling in C++ has been clumsy without libraries like boost::thread, but it's getting better and for obscenely complex threaded applications you can combine languages like OCaml and C++ with wrappers. I didn't RTFA because from the title I can tell it's another "I used this super high level language and it runs like crap but the code looks really pretty so I like it" article. I have two things to say about that:
1. If you are a competent low-level coder who just blows off all high level languages - learn Ruby: it's powerful and gorgeous and lets you code magnificently elegant software like you are creating art all without taking away control.
2. If you can't stand the complexity of C/C++; stick to coding applets and flash because you are not mentally capable or not properly trained at writing heavy system code. If you have never written an embedded C application with inline assembler, have never had to process data at the bit level, or don't fully understand what a "register" is or how to use one then you have no right to badmouth C. If you have never written a complex modular application that requires both high level interfaces and extremely fine control of hardware and memory then you have no right to badmouth C++.
So I guess my point is "shut up and just use the right tool for the right job".
They're harder because their brittle as fuck.
Show me virtually any large C program and I'll show you one that can crash, hard, due to pointer errors or similar.
The choices the language designers made, in many cases were baroque and atrocious, and the default behaviours if you make trivial mistakes or omissions will usually destroy something, often subtly, and often cause a crash a long way away from where the error was. This can make debugging 'entertaining' to say the least.
And C++ is if anything worse.
Java is a lot more robust, but annoyingly verbose, but even that has its problems.
Really, there's no good industrial-strength robust languages in common use.
Still, dealing with this mess keeps SW engineers employed, so it's not all bad.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"for their boss to program with
Wow, I just came up with a way to halve the size of the language! Instead of the special-case doItFaster(), we can just write doWhatIWant("faster")(doWhatIWant). Bam!
http://cm.bell-labs.com/cm/cs/tpop/ - Kernighan is the Kernighan from K & R. I doubt Kernighan would co-author a book with an amateur ...
Here is his bio - http://herpolhode.com/rob/ . I doubt you'd be hiring a bad programmer.
The Internet's nature is peer to peer - 20050301_cs_profs.pdf
This only applies to those of limited intellect.
This shows limited intellect: 'How do we have stuff like this [get to be] the standard way of computing that is taught in schools and is used in industry?'
School teaching and industry isn't perfect, neither is any programming language, but there is an extent to which in programming one can no longer advance in a language without understanding of the underlying principles.
Although not fully, for any scripting language there will be a vast swath of underlying operations that are based on the same system characteristics that Java and C++ express, being more of a reflection of the hardware.
Scripting languages already have poor performance. Out of sight out of mind will only sweep it under the rug for someone to trip on later.
Illegal character in numeric field? Or maybe that's just the COBOL compiler I had to use...one would hope that a better environment would provide more than a single possible error message and a highlighted line the most horrid shade of dull maroon regardless of what you f**ked up. Not quite as fun as assembly, but getting there...
Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
print "Hello World!"
end
REM And even "end" is optional.
Ignorance is curable, stupid is forever.
Are we stuck in a general purpose 3GL+API rut? Rails, Django, HTML and SQL show that stepping beyond a general purpose language can sometimes simplify creating programs. When do we decide to cross over from API's to domain specific languages, and what does that say about the limitations of 3GL's and API's?
That's just daft, punk
Having spent a few years working with IBM mainframes running 30-year-old COBOL and assembly code, the problems of maintainability are always sitting at the back of my mind when debates like this come up.
I've worked in Java and C commercially, and recently I've done a few web projects in PHP and JavaScript. I'm currently an academic researcher, and in that job I've spent some time writing Python and C++. I'm also familiar with the way we're teaching languages and programming, having been involved in the labs and lectures.
I think we are in danger of creating a "new wave" (apologies to French cinema) of legacy software. Whilst scripting, dynamically-typed, languages can be fun and faster as tools to build code in the first place, they do not constrain or discipline the programmer as much as something like Java. Object-orientation with static typing etc. took off because it is a great way to design (some, not all) software in a structured manner to improve communication between engineers and address concerns like maintainability.
I understand why people are using things like Ruby and Python right now, but I suspect it might be a short-termist view of the world. If you're planning to throw your website away, perhaps that's ok. Invariable though, things last much, much, longer than you expect them to.
We've already seen how poorly sites like Facebook scale - imagine what they will be like in another 10 years. We may well look back on these years of great web development as building a legacy that a lot of us spend the rest of our lives trying to reverse-engineer, fix and replace.
RS
this is why i like visual basic. quite good syntax and everything you need to develop an end user app. plus new vb.net has made it even more awesome. i know quite a few will bash this comment, but its one of the most popular language used and taught for precisely the reason mentioned in the article. though i believe c++ has its right place in OS and low level programming stuff. you cant replace it in that space.
Your programming is no better, but you don't give a damn!
Donte Alistair Anderson Roberts - hi son!
Karma: Chameleon
Similar background: 30 years of coding - academic, commercial, COBOL, C, C++, Java, Javascript, Python, ...
I've recently been looking at Java code so full of horribly complex calls to combinations of outdated horrible frameworks, that I was thinking the same thing - "We may well look back on these years of great web development as building a legacy that a lot of us spend the rest of our lives trying to reverse-engineer, fix and replace."
I was thinking that Rails or Django might at least reduce the amount of stuff to learn to get maintenance done.
some guy who happens to work for a company that wants the world to run a browser-based ad-delivery and user tracking system (err.. i mean 'operating system') is calling traditional development tools (used by present and future competition) outdated pieces of convoluted garbage. wow, big surprise there.
But you can do it in C++ as well:
do{
workIt(harder);
makeIt(better);
doIt(faster);
makesUs(stronger);
moreThanEver(hourAfterHour);
}while(workIs(neverOver));
Ok, lets all switch to High level OOP!
Oh, wait... But what will happen when the last grey-haired C/Asm coder dies and there won't be anybody to write a really good compiler for your stupid high level OOP?
If you don't have a good insight, how low level languages function, you shouldn't be tought high level OOP. You build building from ground up, not from middle!
Because of general stupidity, we're now having 64-bit CPU, so we could address more RAM. We don't need more RAM- we need better, more efficient game devs and we need people like those, who implemented addressing more than 4 gigs of RAM in GNU/Linux kernel god knows how long ago!
C++ OTOH, has many, many, many advantages over C.
Vou can program it like C but take advantage of a few extra things like automatic memory management (no need to use free()), better strings (no strcpy or buffer overflows), etc. C++ is every bit as good as C for this.
But ... for larger projects C++ provides proper control of resources (objects have defined lifetimes), exception handling (which combined with stack unwinding makes writing robust code much smaller/neater/easier), much better abstraction abilities (define your interfaces then worry about the details), better namespace control, etc.
I'm sure that as a C zealot you've argued your case against the assembly language zealots, and rightly so - there's a very good reason why people switched from assembly language to C once the C compilers reached maturity.
Well ... this is 2010 and that exact same reason is why they later switched from C to C++.
The reason is that C simply doesn't scale. Big projects are a LOT more work in C than in C++ (just like writing 640k programs in assembler was a lot more work than in C), and for zero gain. Learn to use your tools and the "efficiency" argument vanishes like morning mist.
No sig today...
Maybe you want to use the built-in java HashMap and replace your factory factory by the keyword 'new'.
Framework lovers will strike endlessly, regardless of the environment they are given to play / fool with.
But when you find your implementation sucks, you can always implement doTheRightThingRight(). Naturally, there will be another bug that changes the way in which it operates, necessitating real_doTheRightThingRight().
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
C / C++ too complex? Seriously?... As Chopper says, HTFU
That's exactly the point... it's too close to the hardware.
did you miss the part where the guy also bitched that interpreted languages are "too slow"?
Delphi has lost marketshare mainly because of crappy marketing. But damn it's an excellent OO language.
- The code is native.
- You have full OO capabilities (unlike VB, for example).
- You have classes at runtime and proper HTTP. (If I'm not mistaken, and I might be, C++ lacks this.)
- You can write assembly code inside a method/function, if you want/need that detail.
- UI designer.
As far as I can see, Delphi's problems are:
- No support for different platforms. (It doesn't even have a 64-bit compilation yet.)
- Marketing that keeps touting 2-tier RAD instead of proper OO, which is the main reason Delphi is so underrated.
- Too few competent OO developers. C# is running into the same problem, in that it's too easy to drop in and connect a few components to make something simple, whereas a proper, maintainable application really needs to be written with a well thought out business layer in the middle. That ease-of-use makes developers lazy, and attracts lazy developers.
It's called Domain Specific Language (DSL), and it's a a growing trend, you have for instance many tools on Eclipse to write your own DSL
"While Pike admitted that he was being somewhat facetious, he asserted that such questions still should be asked. C++ came about because of people's frustration with working with the low-level C language, and Java came about as a way to simplify C++. Over time, however, new features were added to both languages, making them more and more complex." Not exactly a ringing endorsement of C. When I first encountered C it thought it was someone's idea of a running joke. C++ is okay as it attempts to fix the numerous inherent limitations of C. In that sense, it has improved over the years. As for simplicity, ease of use, and execution speed, I miss Fortran.
I prefer PHP:
<?$a="Around the world, ";$b="$a$a<br>";echo str_repeat("<p>$b$b$b$b$a</p>",18);?>
Oh, my bad :)
If I mod you up, it doesn't necessarily mean I agree with what you've said, sorry.
Rob Pike criticism of Java and C++ is really advocacy for the new Google language, Go. Unfortunately, Go isn't a very good language, in my opinion. It makes things simpler by being less powerful. What we really need to replace C++ or Java is a language that can grow on demand. Otherwise, we'll keep hitting the limits of the language. And I can hit the limits of Go pretty quickly.
Also, it's time to go beyond imperative, text-oriented languages. Graphics, anyone? It's possible: Hello World in XL simply looks better!
-- Did you try Tao3D? http://tao3d.sourceforge.net
Programming languages are an evolutionary process. :)
I recall coding in ASM which has now been superseded? by 'higher' level languages and still has a bit to go yet. However there will always be people who prefer to drive rather than fly, it takes a bit longer to reach your destination....and might be a bit safer....or not
Engage.
Oh, please.
Type systems eliminate whole classes of errors. What does your unit test do? It eliminates one error. Big fuckin' whoop.
HAND.
Are you daft?
Fascism trolls keeping me up every night. When I starts a preachin', he HITS ME WITH HIS REICH!
Java and C++ are the most successful languages for a long time, so it's comprehensive that some ones simple doesn't like. Now talking serious... don't came to tell me that Go is a good language, because after a couple of weeks playing with it I could check that Go is nothing more than C with some .h libs!
I like Google though lately they are not being very honest with us, due that even with private browsing enable, Chrome still sending some sort of information, they have used a lot of WiFi without authorization, now releasing several versions of Android, that is very good for mobile platforms, though if the hardware don't follow it, they such probably will be let at side, because no one want to expend money to release one product and very soon that release be considerate old, and the company did not have time do pay off the investment. Now they want dictate the languages... what I see now is that they trying everything, and then looking for the roi in a few investments... and with this a lot people that supported those not so successful investments will be leave for behind. Good luck for those ones that trust blindly on Google.
Quiet down, you punk..
I'll believe in corporations having personhood when Texas executes one... - advocate_one
So Rob Pike doesn't like compiled languages, compiled/interpreted languages or interpreted languages. I guess if you're a Google "Distinguished Engineer" you can say anything and it makes it onto slashdot. What a shame. The guy is stuck in a space-time warp heading straight into a black hole.
GRRRRR!!!!! This is my #1 complaint with Microsoft and others who think they know better than me. If I copy an EndOfLine character and then paste, it damn well better paste that EOL and not trim it. Conversely, if I _didn't_ copy an EOL then for the love of God please do not add one for me!!!! I want to slap the snot out of programmers every time I try to do exactly what I want and the program decides I must have made a mistake and really wanted to do something else.
Google Engineer Decries Inadequacy of Own Brain. This article was obviously brought to us by the good folks at The Onion.
My ass. I've been doing this shit for 25+ years. I just get it and you don't you worthless fucking piece of shit Linux Lover.
"too hard to use, too subtle, too intricate"... I give up, it's just too funny!
Java is "too hard to use, too subtle, too intricate"...
What about English? Let's all speak in 4 letter words!
It'll be easier, less subtle, less intricate, and more expressive on top of that.
25+ years? Based on your view on programming and your attitude demonstrated here, you still haven't learned to behave like a grownup.
I've been doing this shit for 25+ years. I
25+ years? Based on your view on programming and your attitude demonstrated here, you still haven't learned to behave like a grownup.
What about Basic? Or is it "too hard to use" as well?
That's what I've seen done, but in addition Foobar is a virtual class which has a single private implementation MyFoobar. Since it's private you have FoobarFactory, which, of course, is also virtual, but also has a single private implementation MyFoobarFactory. So, we have FoobarFactoryFactor which gives you an instance of this single implementation of MyFoobarFactory, which you can use to create instances of the single MyFoobar class, all neatly wrapped in pure virtual classes.
You really need to be a senior system architect to make this kind of a code. It is obviously superior to simply making a class Foobar and creating instances with Foobar().
Any programming language is an interface to the computer system. That's all.
APL, was far superior, in that it leveraged prior knowledge of mathematical notation.
VB, was far superior, in that it leveraged prior knowledge of English language.
When you first look at C++, it's gobbledygook. Semantically, braces are mush, meaning multiple things. C++ does not leverage prior information, but forces the user to understand an entirely new symbolic vocabulary, rather than using and extending a controlled vocabulary as other languages do.
Please do not read this sig. Thank you.
So rather than debating me on an intellectual level, you insult me and then try to act all sophisticated when in fact you failed to comprehend my post. Since I know you're not capable of debating me, go fuck yourself.
I just didn't want to point out the obvious and if you hadn't thrown a tantrum, I might have had elaborated a little.
Old tactic to promote your new product. However focusing on "negative" aspects of some very strong languages I believe was a mistake. Let the time decide if "Go" is better or just another "Goo" that will end up in our digital world sewers.