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
Segmentation Fault
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)
Should have RTFA I guess, I now realize Mr Pike just talks in circles and really didn't have anything of value to say other than 'programming is hard'.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
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.
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".
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...
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.
Linus has a fetish for C. He'll say anything.
...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.
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.
What do you expect? To me it appeared to be little more than stumping for the programming language he wrote - Google Go. Which has yet to impress me. They say that it's flexible like an interpreted language but fast like a compiled one. To me, it seems like it's missing all the cool shit that makes me USE an interpreted language, but doesn't provide the same low-level access that makes me use a compiled one! All languages have their niche, I suppose, and I guess I'm just not the target demographic for Google Go
If I had a nickel for every time I had a nickel, I'd be richcursive!
...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
embedded python for shits and giggles
I know what you mean, but out of context it sounds so horribly wrong.
"This post contains words, known to the State of California to cause thought. Wash brain thoroughly after reading."
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?
to trust anything they say or do
Or, maybe, instead of trusting what they say, you could, you know, RTFA and see if the arguments are valid and maybe post some counter arguments.
I hope you know that JavaScript is one of the most used languages in the world, and that is it not controlled by Google. That in fact Google does not control Python either. And that one of the reasons JavaScript is popular is because it's accessible and easier to learn since you can start without caring about OO or functional programming. A 13 year old can just start document.write-ing his way into a webdeveloper career, print_r-ing his way through Wordpress after Wordpress site for his friends, family and local barbershop.
Seriously, there's no conspiracy here, and comparing to Microsoft is lame in this context. (Although, Microsoft is also starting to see the value of dynamic languages lately, hmm, maybe they and Google have a point?)
This same rant has apeared generation after generation, and often from peope smart nough to know better. It's why COBOL was invented, with syntax like.
I kid you not, Adm Hopper actually thought that would make programming easier, and she was no moron.
Guess what guys? The reason programming is hard is because you must clearly and unambiguously state what you want to have happen. Yes, the languages could surely be better - the syntax and intricacies of C++ are pretty nightmarish, and Java only fixes some of those issues while introducing others. There's surely a better way to do resource management, and multi-threading, that are less error prone without making you give up needed control. But it's still going to be hard to solve hard problems, and you're still going to need to be very precise and detailed in describing how to solve a problem.
Irreducible complexity is irreducible.
Socialism: a lie told by totalitarians and believed by fools.
... 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.
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"?
A guy who co-authored a couple of books with Brian Kernigan and co-invented UTF-8 with Ken Thompson is entitled to his opinions, although after watching the OSCON speech, I'm inclined to believe he shoulder the lighter part of the burden on those projects.
dontMakeMeTellYouWhatToDo(); -- turing complete
In soviet Russia, God creates you!
Not to mention that, no matter what language you use, certain algorithms are going to be inherently complex, and in these areas the "simple" or "true" languages fall flat on their face. I've been coding in one form or another since the mid-1980s, and what I've seen from the "simple" languages is that they might be useful for teaching, but try to write a complex application or solve complex problems, and that simplicity simply makes the code even larger and more awkward.
The world's burning. Moped Jesus spotted on I50. Details at 11.
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.
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()
UTF-8 was one moment of genius insight ("make sure the escape sequences cant be confused with notmal characters"), and the rest was trivial. The details weren't even very well thought through beyond that one clever idea: real standards deal mostly with error handling, and UTF-8 totally dropped the ball on that, leaving RFC 3629 to pick up the slack. If anything, co-inventing UTF-8 is an argument that he doesn't know much about real-world programming (Ken has of course proven himself elsewhere). Being the author of RFC 3629 (F. Yergeau) and cleaning up the mess would make one's opinions much more interesting!
Socialism: a lie told by totalitarians and believed by fools.
I'll bite. What would you do to make it shorter? That seems pretty sane to me. I'm assuming the language's methods are determined by the signature. There's not that much (maybe the []) you could remove and still determine what is being passed in.
Lack of planning on your part does not constitute an emergency on mine.
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.
Should have RTFA I guess, I now realize Mr Pike just talks in circles and really didn't have anything of value to say other than 'programming is hard'.
No, he doesn't. TFA-writer Joab Jackson talks in circles and doesn't have anything of value to say. Mr. Pike, on the other hand, appears to be saying that Google Go fixes a lot of unnecessary complexity in Java and C++.
His keynote isn't linked from either the Slashdot summary or TFA, but can be seen here: http://www.youtube.com/watch?v=5kj5ApnhPAE
Want a high quality FOSS RTS game? Try Warzone 2100!
Big != evil. While M$ uses their clout to squish the competition, bribe the government(s), and get away with plenty other unlawful stuff, Google grows mostly by providing a superior product. There is a long way before (if) they become the new M$.
I was just reading over this page the other day and thinking to myself how bloated Java is getting.
Tsunami -- You can't bring a good wave down!
C. It's just the right thing to do.
Yes, irreducible complexity is irreducible. But C++ has plenty of reducible complexity.
Adjusting code for multi-threading or moving from 32 to 64bit are two simple examples. It's reasonable to consider a compiler having the smarts to do that. Garbage collection is another obvious example that many languages have dealt with. Memory protection.
I dunno, that's what comes to mind immediately. C++ let's you handle virtually every registry action and memory copy. That's not a bad thing, but it's probably not necessary for a lot of the programs it's used for. More to the point, it likely costs many of those programs a lot of developer/testing/user time because they're putting a lot of time into resolving the same issues again and again that the compiler is perfectly capable of handling.
I think the article pretty succinctly draws the ends of the spectrum between assembler and non-typed interpreted languages. The real question is where does the best compromise lie on that spectrum. It's going to be different for every product, but the supposition in the article is that C++ is way too far towards assembler.
Personally, I can agree with that.
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);
LET NEWBALANCE = BALANCE - DEBIT
perfectly logical to me, and not excessively terse. And most BASIC environments don't require LET.
-uso.
What you hear in the ear, preach from the rooftop Matthew 10.27b
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.
]{
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.
Yep, it's like different natural human languages. Some are much simpler than others, and don't have so many cases and tenses and such. However, to express more complex thoughts (such as "he would have liked to go home"), you have to be extremely wordy, whereas with a more complex language, you just use a different verb tense.
[nt]
I've lost some sleep already. Google is just not doing things right as before.
Should have RTFA I guess, I now realize Mr Pike just talks in circles and really didn't have anything of value to say other than 'programming is hard'.
You are aware that he literally (co)-wrote the book on UNIX. While you may disagree with his ideas, his credentials are impeccable.
What we have here is feature creep.
Usage: km/h for speed (kilometers per hour); kph for very slow impulses (kilopond hours).
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.)
... "make sure the escape sequences cant be confused with notmal [sic] characters"...
That was figured out _long_ before UTF-8. In fact, having been born in 1956, Rob Pike was probably exposed to the concepts of Control Codes and bisync as well as all the other framing methods that use escape characters to indicate in-band signalling.
Have you ever wondered what all those control characters are doing wasting space down there under decimal 32? Link management, that's what. Start of Header, Start of Text, End of Text, End of Transmission, etc. They were all used to keep systems in sync across the (nasty) comm lines of the day. Even [XYZ]-modem used a similar setup.
Tiller's Rule: Never use a word in written form that you've only heard and never read. You will end up looking foolish.
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
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..."
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 must have missed something. Since when do the rantings of one lone academic who works at Google mean that this was the rantings of more than one person, or even the official position of the entire company?
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.
Modula-2 and Pascal are what I learned, too. "First one, then the other!"
Populus vult decipi, ergo decipiatur...
"Force shits upon Reason's back." - Poor Richard's Almanac
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.
C++ done right with scoped classes doesn't need garbage collection. No, really it doesn't, most people have just never worked with scoped classes, and it's mind-boggling that they don't show up in C++0x (other than the half-useless auto_ptr we've always had). I have a real problem with garbage collection in production code, because it's freaking hard to find and plug resource leaks. If you forget to close a file in a garbage collected language, it will probably get closed eventually when the garbage collector cleans up, but the program likely has some bug anyhow, and the GC has made it a horrible intermittant bug that changes behavior in a lab environment!
C++ has two key abilities that any good language needs, but few have: scoped resoruces (but only in that it allows you to add them yourself!), and const references. Why are people still making high level languages where references aren't const by default?!? In C# I can't (usually) tell from the function signature whether changing an argument will change the caller's copy, nor can I be sure from an interface that a given function won't alter what I pass to it - what insanity is that? (And Java is only slightly better.)
Socialism: a lie told by totalitarians and believed by fools.
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.
In response to != replace
President Bush initiated the War of Terrorism in response to the 9-11 attacks.
President Bush initiated the War of Terrorism to replace the 9-11 attacks.
It's why COBOL was invented, with syntax like.
SUBTRACT DEBIT FROM BALANCE GIVING NEWBALANCE.
I kid you not, Adm Hopper actually thought that would make programming easier, and she was no moron.
COBOL was designed like this so it could be read and understood by corporate auditors and accountants - and for the recruitment and training of accountants as COBOL programmers.
It makes perfect sense when you remember that modern bookkeeping rules are the product of hundreds of years of law and practical experience which the neolithic geek did not have.
Yes, you can do it the sane way. But my point was that someone actually thought the verbose way was easier to understand!
Socialism: a lie told by totalitarians and believed by fools.
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.
I get the impression that developers sometimes forget that programming languages are engineering tools. People building houses don't complain that the hammers and nails aren't pretty while they build a foundation. Part of your job is dealing with hard, ugly, complex things. You're instructing a machine.
I was joking.. ;-) But DocumentFactoryFactory is even better!
-- dnl
No, I think you missed the point entirely here: those escape sequences would begin with a control character, but contain normal characters. So if you were grepping for "foo" you might get a false positive because "foo" appeared in an escape sequence. UTF-8 ensures that will never happen. Any existing code that uses reasonable algorithms to search or sort ASCII text still works reliably with UTF-8 text, but didn't with earlier escape sequence schemes.
Socialism: a lie told by totalitarians and believed by fools.
Yes, and it doesn't impress me. Writing isn't hard.
He also promptly called UNIX dead, and pretty much trash talks about everything that isn't his and how his is better, yet no one seems to give a shit and no one that matters uses it.
Anything he's contributed too that people actually use, they use because of what other people did, not his contributions.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Yeah, it's not like Google is driving past your house to take pictures and index your WiFi network or anything. Sheesh!
Wouldn't that make it unfit for enterprise use?
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
"In response to != replace"
A lot of companies wanted Java for their internal apps, because C++ was just too nasty. For them, it was definitely a matter of replacement, at least for those apps. The banks that used NeXTStep/OpenStep in the 90s wanted to get away from the inherent vendor risk, and they eventually bailed out to Java. They could have bailed out to C++ any time in the 90s if that were seen as acceptable. (Some probably did.)
September 2011: Looking for Cocoa/iOS work in Boston area Cocoa Programmer Quincy, MA
Does FoobarFactoryFactory keep all of it's possible factory configuration options in a ConfigurationMapMapMap>>?
Nearly everything I was unhappy about in C++ is better in D.
That's, "La angla estas tro malfacila! Parolu esperante."
Come on over to Lernu.net and learn Esperanto for real.
C++ is a multi-threaded environment with shared resources is vastly harder than Java. That's what makes the garbage collector worthwhile. I agree that using the stack where possible with your scoped classes is good, but sometimes you just gotta use the heap, shared the object around between threads and synchronize your resources. Then you're told you have to make it work on the Mac, Windows and the Linux servers, but don't have time to integrate three sets of libraries. See where Java might be useful now?
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.
Good thing Google doesn't have an illegally close relationship with the government that benefits the company!
Java and C++ aren't overly complex because they give you tools to unambiguously describe an algorithm; every language has that. Java and C++ are "complex and bureaucratic" because they supply a huge set of tools not for describing algorithms, but for describing how other programmers are allowed to interface and reuse algorithms. Algorithms that are unambiguous to the interpreting machine can be VERY ambiguous to another programmer that has to call or extend the original, so formalisms of interfaces and types and generics are added so that developers can use the language to tell other developers what to do and set policy.
Don't blame me, I voted for Baltar.
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.
That example is exactly why I dislike "simple" languages - by trying to be intuitive they make the problem more difficult.
Applescript is a great example - I knew what I wanted to do, and in a normal language it might have taken me 20 minutes, but it ended up taking half a day figuring out which words made it jump through different hoops. Not to mention that some similar words behaved completely differently, and minor changes in the order of words in a sentence completely changed functionality.
The point is, when you put things in natural language it becomes difficult to ascertain what will produce the result you want, since there are so many ways to phrase a request. In the end you need to learn the same amount of details about the syntax, it just makes you type more and becomes easier to confuse a programming word with an everyday word accidentally.
I think you're confusing Java with Javascript. They are completely two different things.
I'm aware of who he is, what he does now and what he's done in the past. I've now seen his keynote.
My opinion hasn't changed. He has nothing to say and talks himself in circles, I'm guess you just don't see it due to lack of understanding, of course maybe I'm the one that doesn't understand.
Who knows, but I'm going to stick with my original assessment that he's just a blow hard spewing about his latest creation and how everyone elses sucks because his creation some how mysteriously fixes the problem that no one else has.
You go listen to what he has to say, I'll continue getting things done while you go play with a new language because its 'better' until you realize that its exactly the same as all the others.
When you start telling me that the language is the problem I realize instantly that you aren't that great of a programmer. My one exception to this is Visual Basic (not BASIC, VB specifically). It is a shitty environment because of the shit support library MS made for it.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
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)
But each complex piece of code should only be written once.
When I first started everybody had to know how to write sorts, btrees, and hash tables.
If you where really into it you learned how to create a sparse array.
So many of those things have been folded into libraries now which is a good thing.
The real problem then becomes a massive collection of libraries.
Which adds all sorts of new complexity.
I do think that c++ and java have gotten more complex than you need but mainly because of the growth of the standard libraries.
Of course I would really like to go with managed memory solutions but even that has it's limits. I wouldn't be really happy using those in an embedded situation.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
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?
and it's mind-boggling that they don't show up in C++0x (other than the half-useless auto_ptr we've always had).
I thought shared_ptr (from boost) was being added to the standard library?
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.
...plus the idea that there are a variety of things to build and thus a variety of appropriate tools depending on the project.
Skyscraper welders and residential framing carpenters both build buildings but they're worlds apart.
A Pirate and a Puritan look the same on a balance sheet.
Irreducible complexity is irreducible.
Still, I'd like to stress that picking the right language for your task can greatly reduce problem complexity.
For instance, algorithms are much more compact and easier to understand using a functional programming language. E.g. compare quicksort in Haskell and C - see http://www.haskell.org/haskellwiki/Introduction.
Complex concurrent programs remains challenging even with an excellent (IMO) concurrency library like the one in Java 1.5+. But switch to Erlang, and you'd find many concurrency patterns are expressed more naturally.
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
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.
Doh. You're right. Reading fail.
September 2011: Looking for Cocoa/iOS work in Boston area Cocoa Programmer Quincy, MA
But the argument list is horrendous
Normally, reference counted pointers (C++'s shared_ptr) work just as easily as GC for resoruces that need to be on the heap. But of course there are exceptions. One of the great disappointments of C++0x is that it lost "opt-in" garbage collection for those exceptions. But, in general, "opt-in" garbage collection would be an excellent idea in a modern language. (C++0x does have threads in the standard library though, and of course there have been open source cross-platform libraries for threads forever.)
Java solves some very useful problems, but IMO it doesn't solve them the best way: the dependence on bytecode can be avoided simply by providing good (language-standard!) libraries over the system-specific stuff. Don't underestimate the value of being able to debug close to the metal! Sometimes you have a system-specific bug, and if the only layer you have acces to is system-independent stuff that's a huge pain.
Socialism: a lie told by totalitarians and believed by fools.
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];
Even [XYZ]-modem used a similar setup.
Not quite. Xmodem and Ymodem use SOH and STX to denote start of sectors and ACK/NAK, but after that it's just a raw 8-bit file dump to the checksum/crc bytes with no concern for character set encoding. Zmodem uses DLE and escapes out most of the C0 bytes (XON/XOFF and CAN must be escaped regardless of session flags), but doesn't use the rest of the codes for anything.
Most of C0/C1 codes mixed right in with the text for formatting/presentation, e.g. embedding backspaces followed by underscores to get underlined text. Some of the others did link-level too. It was a mess, so much so that parsers for ANSI X3.64 / ECMA-48 style escape sequences take a LOT of work to get right (passing 'vttest' is not trivial).
UTF-8 isn't bad. It specifies that character decoding be done before any other processing including C0/C1 and ANSI escape sequences, which makes it very easy to integrate on the reading side. Harder is dealing with wide chars on the screen and user I/O. Compared to Avatar's repeat character and ANSI fallback features, it's much more bang for the buck. And let's not talk about "ANSI Music" and it's use of SO (Ctrl-N) because it's the "music symbol" in CP437!
(Disclaimer: I've written a console-based terminal emulator that does a decent VT102/220, UTF-8, X/Y/Zmodem/Kermit, and lots of other things.)
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.
...Google Go. Which has yet to impress me.
There are some impressive parts of it that would make me want to use it over C, but it seems like it's still in its nascent stages and not ready for serious use yet. The biggest thing I can see that it needs is full two-way integration with existing C code...cgo is a terrible hack that only works to call C code from Go. They also need the ability to create shared libraries to allow C code to call into Go programs.
I've been disappointed to see them ignoring that kind of stuff and instead focusing on all the Go packages. If you solve the integration with C, the standard library stuff becomes less important because everything they'd implement has a C equivalent that could be used until they've had a chance to implement a Go version.
Try an IDE that *doesn't* suck. Having used NetBeans, Eclipse, Visual Studio, and Xcode, I have to say that Xcode is orders of magnitude suckier than the rest. Netbeans and Eclipse both work on OSX.
That said, I think IDEs do tend to be too helpful. I'm tired of having to erase the extraneous parenthesis that Eclipse throws in. (I know there's probably configuration options to change that behavior, but there are so many options I wouldn't know where to begin.)
shared_ptr solves a different problem. An example of a scoped resource is a file handle that you allocate on the heap, that automatically closes the file when you leave scope, whether by returning or by an exception flying past. With scoped resources you can just stop thinking about all the "does my resource get cleaned up if this happens" cases entirely! You should never explicitly clean up a resource, so there's no way to forget to do so in some corner case. Just like a "using" block in C#, except it's the default, so you can't forget to do it (the most malevolent bugs I've fought were people forgetting to use a using block).
Combine this idea with shared_ptr and it works for heap resources too, not just stack resources.
Socialism: a lie told by totalitarians and believed by fools.
Sure you can model everything into a set of classes, but that doesn't mean you should always do so.
This is what bothers me about Java. You're forced to model everything into a set of classes.
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.
For instance, algorithms are much more compact and easier to understand using a functional programming language.
Sure, if you spend all day inventing clever algorithms. But that's a dream job, and probably describes less than 1% of professional programming work. The initial learning curve for functional languages is pretty steep, and the time spent it would probably be a net loss for most careers (sadly enough).
I have a huge problem with most attempts to "hide the complexity" of concurrent progamming: the dreaded common thread pool. If my process has 5 different places where a problem is solved concurrently, and in one of those places everything stalls out due to long timeouts on I/O errors or something, it must not cause the other 4 places to grind to a halt. That's a terrible abstraction layer, because you just created and hidden incredibly important dependencies, which I need not to be there in the first place. Have all the clean expression you want, if you're going to sneak in inappropriate dependencies I don't want it.
Socialism: a lie told by totalitarians and believed by fools.
Besides, using "using" works nicely for scoping classes.
No man is an island... But I wouldn't mind having a bigger moat.
Great Example!
"Going to war without the French is like going deer hunting without your accordion." ~General Norman Schwarzkopf
Sure, but there's no other way to do a large project if you can't enforce promises that code you don't understand won't wreck your code. C++ and Java are complete overkill for any problem that one programmer can solve in a week and that's a lot of modern programming, but that bureaucratic stuff is there for a reason.
Socialism: a lie told by totalitarians and believed by fools.
I've never had a problem with C# garbage collection. I close my files when I'm done with them rather than in the descructor for example. I have had many problems with C++ memory allocation and COM reference counts however. I've spent hundreds of hours over the years trying to find out why a given object still has a reference count and is not destructing. I've also spent countless hours tracking weak references and null pointers. Not fun... and never again now that I use C# for most (but not all) of my coding.
No man is an island... But I wouldn't mind having a bigger moat.
http://www.dangermouse.net/esoteric/ook.html
Please do not read this sig. Thank you.
What's wrong with that?
They can have as much of the light bouncing off my house as they want, if I cared I would put up a fence. The Wifi I broadcast is all encrypted but if they want to record what that machine shouts I say go for it.
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.
Quicksort in C#: array.sort(); There... done. :)
And yes, I could code quicksort from scratch, but what is the bloody point? I'm not trying to show off and very few people get to see my code anyway.
I argue that picking the "right" language was once a very important thing. These days it is getting to be less so. It is far more important to pick the "right" design pattern.
I recomend the following book for any coder. Know it and live it.
http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612
No man is an island... But I wouldn't mind having a bigger moat.
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?
As far as I'm concerned COBOL is the perfect programming language. I'm a little biased as I worked as a COBOL programmer for a time, but you have to admit the syntax is very easy to read.
A well written COBOL program is like reading a little battle plan. It tells you, in plain English, what it intends to do and the ruthlessness of a COBOL compiler forces you to create readable, structured code.
Every COBOL programmer knows where the period is supposed to be. C programmers still haven't figured out where the braces should be. It says a lot about a language when you have decades-long debates about punctuation in your code. It encourages a lack of programming discipline which I feel is the leading reason why software is so buggy today.
Bibo Ergo Sum.
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.
As I said elsewhere in this topic, the most malevolent bugs I've ever dealt with are where someone forgot to use a "using" block (malevolent because the bug would act differently in the lab and the customer site, becuase it was all dependent on when the garbage collector ran).
malloc() and free() works nicely for managing memory, you just need to get it right every time. "Using" blocks make it easier to get it right every time, but are still prone to human error. In a good programing language, the "using" block would be implicit by default when you allocated the object, and you would need to declare it "shared" or somehting for those corner cases where you want it to survive leaving scope (and done properly, "shared" would only create a problem where there was an algorithmic error, not a simple oversight).
Socialism: a lie told by totalitarians and believed by fools.
I am pretty sure I heard such a speech 10 years ago, before Java came out.
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.
Sure, if you can get the "closing them when I'm done with them" right every time, never failing due to human error, you're golden. However, one wonders why you'd need a garbage collector, or for that matter a text editor - can't you just move the bits around on disk with the power of your mind? :)
But, yeah, any time you see weak pointers a living hell awaits. Garbage collection is much better for those corner cases (and, dammit, for a while C++0x had "opt-in" garbage collection, but lost it. It's the best of both worlds!) I'm not the biggest fan of WCF, but it does have one thing goint for it: it's not COM.
Socialism: a lie told by totalitarians and believed by fools.
... 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.
So what? If your house is visible from a public street, people are perfectly free to take pictures of it. And if you're too stupid to enable encryption on your WiFi network, that's your problem.
"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.
the ruthlessness of a COBOL compiler forces you to create readable, structured code
You should ALTER your views on this subject.
Socialism: a lie told by totalitarians and believed by fools.
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.
How will you fence off a satellite image?
I know, I know, it's pointless to argue with Slashdotters who looooove Google.
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.
Most people don't understand WiFi networking and don't realize they're broadcasting anything. I didn't say people weren't free to take pictures of your house. I'm just pointing out that you're supporting a company whose CEO said only criminals worry about privacy. If you're okay with that, then Google loves fans like you!
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? :*)
But we learned to avoid go2 back in the days when structured programming was new...
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
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+
Rarely have a problem with closing files. Much more often have a problem with opening them. Opt-in GC is nice, but can cause confusion in large systems because it is easy to confuse objects and forget which is GC'd and which must be manually de-allocated. I also like that GC can run when the CPU is not in use. It's like automatically multi-threading your deallocation for speed optimization (at the expense of memory of course). Agreed on WCF and COM. I think all MS developers are familiar with the term "Dll hell".
No man is an island... But I wouldn't mind having a bigger moat.
No need to invent clever algorithms if you know and understand the basic design patterns. These patterns (mostly) transcend languages and help to create understandable and efficient code.
No man is an island... But I wouldn't mind having a bigger moat.
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.
I can disagree with Google's CEO while still appreciating many of their products. Google's CEO is only one man, and many laws at various levels protect my privacy.
Do you agree with everything that every CEO of every company whose products you like has said? Somehow, I doubt it.
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.
Can you name some code that might illustrate this? It sounds interesting or at least amusing. I feel like I have come across really bad code in "simple" languages, code that would be easy to implement elegantly in a "complex" language, but I can't recall anything specific at the moment. I remember seeing a lot of truly bizarre code written in Apple BASIC back in the day (but then, some really cool hacks too).
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.
Open Office Basic is also a shitty language to work with, and the Open Office API is inconsistent.
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.
Python/Ruby/others
print 'hello world'
Java/C#/others
public class Hello {
public static void Main(String [] args) {
System.out.writeline("hello world");
}
}
When learning languages/programming, it is better to start with an interpreted language like Python or Ruby where you get immediate feedback and start simple.
Also, learn more than one type of programming language (Python, C, C++, Java, Haskell, Prolog, Lisp, Clojure, Groovy, Go, ...).
Djkstra said that Go2 was evil!
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.
I think the BASIC syntax is more natural to English than COBOL's syntax.
-uso.
What you hear in the ear, preach from the rooftop Matthew 10.27b
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!
That doesn't mean a whole lot if nearly everything you're unhappy about in D is better in C++. Frequently that's the case.
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.
No you don't.
You only need a wrapper class.
public class Somestuff {
public static void doStuff() { doMoreStuff(); }
public static void doMoreStuff() { System.out.println("mo stuff!"); }
public static void main(String[] args) { doStuff(); }
}
Yes, ugly code. Yes, perfect sample. Zero class instantiations.
Actually, a large part of a system I wrote in Java does just this because I couldn't spare the overhead of object creation.
This signature is DRM protected. By the DMCA, you are not allowed to counteract or oppose to it.
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?
While VB was many things, including obtuse, it's ability to extend itself through IDispatch was arguably it's strongest feature, making it far more extensible an environment than many in production today. The biggest downfall to VB was the myriad of VBA environments in Microsoft products - that were all slightly different, and a simple change from one version of Office to the next could break a truckload of applications - that's what sucked about VB.
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
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.
Yes, ugly code. Yes, perfect sample. Zero class instantiations.
But it's still part of a class. It's a stupid, extraneous requirement.
Well, at least C++ has only one standard library...
... 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.
n a good programing language, the "using" block would be implicit by default when you allocated the object, and you would need to declare it "shared" or somehting for those corner cases where you want it to survive leaving scope (and done properly, "shared" would only create a problem where there was an algorithmic error, not a simple oversight).
You've just described C++. Objects with automatic storage duration ("stack-allocated" for those not versed in standarteze) get cleaned up as their scope is gone, and to mark them "shared" you declare them using std::tr1::shared_ptr and allocate with "new".
When you start telling me that the language is the problem I realize instantly that you aren't that great of a programmer. My one exception to this is Visual Basic (not BASIC, VB specifically). It is a shitty environment because of the shit support library MS made for it.
Oh, c'mon. If you list VB, you've got to also give a honorary mention of PHP.
Then again, I don't see what's wrong with saying that language is a problem. It certainly can be. Almost never the only one, and rarely the primary one, but languages can be objectively better or worse (for specific tasks and in general, though those are separate measurements), and it's silly not to take that into consideration along with all other factors.
No, it's not. The class is never instantiated, which means it doesn't exist, and thus the functions can't be part of it.
If you want a class-restrictive language to yelp about, do smalltalk. It's nice, but it's still all-OOP.
And what about Ruby?
Still, if people put the methodology before them like a weapon of mass-disapprovement, they're going to get disappointed. En masse.
The old icelandic saying "árinni kennir illur ræðari" (a bad rower blames his oar) fits this discussion perfectly - a bad programmer blames the language.
This signature is DRM protected. By the DMCA, you are not allowed to counteract or oppose to it.
I'm not talking about what code the runtime sees. I'm talking about what I have to do as a programmer.
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
The problem isn't expressing subtraction. The problem is creating complexity where it isn't needed, usually in the name of some ivory tower abstracted reusability in a place where the code will never ever be reused.
Instead if only makes the code buggier, harder to understand, and eventually rewritten entirely because there are too many abstracted layers to make changes.
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".
NetBeans is awful, Eclipse is obtuse and never works right, Visual Studio often requires you to constantly screw with project and compiler settings to get things working correctly, and Xcode just doesn't offer much at all and fails on so many levels when it comes to dealing with errors and debugging. I agree with you on your IDE's being too helpful; which is why I use (G)Vim with a few plug-ins and extensions. I have everything from intellisense like suggestions to API reference help when I need it. Though I don't like it personally, emacs is also extremely awesome. The learning curve is a little rough, but pick one and stick to it for a week or so - you won't be able to go back to bulky commercial IDEs.
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!"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.
refcounts? you know about cycles, right?
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?
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
Your programming is no better, but you don't give a damn!
Donte Alistair Anderson Roberts - hi son!
Karma: Chameleon
Yes, and it doesn't impress me. Writing isn't hard.
He also promptly called UNIX dead, and pretty much trash talks about everything that isn't his and how his is better, yet no one seems to give a shit and no one that matters uses it.
Anything he's contributed too that people actually use, they use because of what other people did, not his contributions
Maybe writing is harder than you think :)
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.
One man? He's the CEO. His views influence the behavior of the company.
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...
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.
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.
That's an interesting point to bring up. In a simple language you're on your own to piece together a coherent sentence out of independent building blocks. In English there are tons of strong subject-verb agreement / idiom / tense rules that tightly bind together the sentence and make it very obvious when the sentence is ambiguous or incorrect.
TFS:
Like simple human languages, practically anything you care to write in weakly-typed languages like JavaScript will parse, but that doesn't mean that it will be interpreted the way you want. But if by some miracle you can get your Haskell program to compile then 90% of the time it will work perfectly on the first run.
So what? You're free to evaluate their products and choose to use them or not use them. I don't care what statements he's made, I only care about the products I use.
Again, do you screen every company that makes every product or service you consume, to make sure that company's CEO (or any CEO they've ever had) has never made a statement you disagree with?
I prefer PHP:
<?$a="Around the world, ";$b="$a$a<br>";echo str_repeat("<p>$b$b$b$b$a</p>",18);?>
Yes, I know I'm free to evaluate their products. Thanks for the reminder.
You can't separate the CEO's thoughts on privacy from the services the company puts out. Yes, I do choose not to use a company's products if the CEO, or anyone else high up in the company, has made a statement that reflects negatively on the way they're going to treat me as a customer. If Steve Ballmer said anyone who uses Windows 7 is an idiot, people would probably be less inclined to upgrade to Windows 7.
Eric Schmidt's proclamation that anybody who cares about their privacy is hiding something is a sign that he puts the company's desires for data collection and indexing above the customer's. You are no longer an individual; you're a set of data to be sold to advertisers. If you don't care about these things, then you are just the kind of unconcerned consumer that Google wants using their services.
Oh, my bad :)
If I mod you up, it doesn't necessarily mean I agree with what you've said, sorry.
Some guy who also happens to be the co-inventor of UTF-8, the author of the first Unix windowing system, co-creator of Plan9 and Inferno, and co-author of a couple of the most respected books on Unix programming and programming in general. To dismiss him as a guy who works for an ad company is ridiculous.
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
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!
Quiet down, you punk..
I'll believe in corporations having personhood when Texas executes one... - advocate_one
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.
C++ enables the right approach with clever use of templates, but by default you've just moved "make sure the allocations at the top of the funtion match the cleanup at the bottom" to "make sure the allocations in the constructor match the cleanup in the destructor". It's nice that you do it less often, but that's still just as prone to human error - for example, most C++ coders don't seem to realize that if you throw in the constructor, the destructor won't be called at all, and will allocate 2 or more resources in the constructor.
However, if each resource primitive has it's own (template-based) auto-cleanup, your destructors will usually be empty, and human error is out of the picture. I've helped create large code bases where there was only one line of code in the entire codebase where resource cleanup was done: the scoped template. If you only have to get it right once, you can.
Socialism: a lie told by totalitarians and believed by fools.
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.
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.