Sign in or Join FriendFeed
FriendFeed is the easiest way to share online. Learn more »
Paul Buchheit
ooc - low-level / high-level goodness - http://ooc-lang.org/
Looks promising. C++ is too much of a disaster -- we need a real successor to C. "ooc is a modern, object-oriented, functional-ish, high-level, low-level, sexy programming language. it's translated to pure C with a source-to-source compiler. it strives to be powerful, modular, extensible, portable, yet simple and fast." - Paul Buchheit from Bookmarklet
Meh. I dislike post-fix'd declarations, and given that the assignment operator is frequently used, I think C's decision to make it a single character operator is the correct one. Otherwise, it doesn't seem any better than say, Objective C, D, or any of the other languages vying to be the next C. - Piaw Na
Have you looked at the D language? http://www.digitalmars.com/d/ It's been around for years and near the top of language shootouts in performance. - Ray Cromwell
Pointers? Do we really need pointers? - Gabe
Yes, if you're doing a systems language, you need pointers --- for writing device drivers, if nothing else. - Piaw Na
Based on the sample code, it appears to have a very direct interface to C, which I think is important for a systems language. For most things I'd rather just use Python, but for lower-level, perf-critical stuff, we need something else. D looks like too much, but I haven't tried it. - Paul Buchheit
Type inference, yummy - a main reason why Scala has mad traction these days - Christopher Galtenberg
Start by creating a really lightweight and easy to use development environment. I should be able to teach Jay Rosen to program in it. Back in the 80s there was serious compeititon in this area -- from Borland with Turbo Pascal and on the Mac, from Think Technologies with their C and Pascal systems. The languages aren't the issue, at least not for me. I want to program in C again, but the curve is too steep in all the environments. Give me a Turbo environment and some nice libraries, and lets go! :-) - Dave Winer
Piaw Na: For ':=' I've just made a homepage edit to make it very clear. := is decl-assign. Regular assign is '=' as in C/Java/etc. RTFM! ;) - 'n ddrylliog
Piaw Na: As for trying to be the next C... well, no =) The next C is probably C itself, since C hackers are way too picky to be satisfied with anyside above C (in high-level/low-level terms) - 'n ddrylliog
Btw, why is everyone thinking of ooc as a systems language? It can be used as such, but it's not really the goal. Do you all think so because it's compiled? - 'n ddrylliog
I'm thinking of it as a systems language because that's what I want. We already have reasonable options for higher-level stuff, but when writing a database or whatever, we're stuck with C or C++. - Paul Buchheit
Paul Buchheit: Hmm. High-performance implementations of current reasonable high-level languages are still pretty much experimental :/ (unladen swallow, shedskin, etc.) Why sacrifice performance? Many compiled languages have shown that expressivity isn't reserved to "interpreted" languages. =) - 'n ddrylliog
Piaw Na: about ooc being better or worse than Objective-C, D, etc. Well, D is really complex. It gives a *lot* of control, but it makes code less readable imho. As much as you may currently dislike it, the ooc syntax is (for some at least) more readable, so more maintainable, in general simpler, etc. (a lot less trickier than C++, for example. And if you don't see what I'm talking about, you haven't done enough C++) - 'n ddrylliog
Ocaml is pretty expressive, it has a REPL, and it's been in the top of the language shootout benchmarks for years. - Ray Cromwell
How does ooc compare to C#? If I had to write something like a compiler, I'd use C#. - Gabe
The missing dots really bother me. - τorƍue
C++ a disaster? I don't think so, its main problem is the lack of high level straightforward frameworks. IMHO generic programming is a deeper paradigm than OOP, but like functional languages has a slow learning curve, look at the matrix implementations/compiler optimizations in Boost! - Sebastian Wain from iPhone
Sebastian: C++ has lots of significant problems. For example, it's actually 3 languages: precompiler (#define), C++, and templates. The template language is so powerful that you can't even tell if the compiler will halt on a given program, let alone understand the error messages it produces. Just the shear size of the language, manual memory management, things like multiple inheritance, and vast overlapping standard libraries make it hard to program in by giving the progammer an overly large cognitive load. - Gabe
My two biggest gripes: Error messages from templates, specially from STL, can be notoriously hard to track down. And secondly, default implicit conversions can lead to hard to track down bugs. When you have a type system so complex you have to mentally "run the compiler" as you code, something's wrong. - Ray Cromwell
I've been doing nothing but C++ lately. It's not bad, but only because everyone subsets it. The compilers are horrible, but I don't think that's because nobody has an incentive to improve g++'s front-end. - Piaw Na
Ouch. decl-assign is terrible. I hate that. I think C's syntax (e.g., int a = 3; ) is much better than decl- assign. If you want to imitate C, at least make the declarations C-like. Personally, I think language design should be performed so that you can hand-code a compiler (i.e., no lex & yacc). Why? Because hand-coded compilers can much more easily produce human readable error messages than compiler-compiler generated compilers. Once you can do that, you've got a regular syntax that's easy to parse (and hence easy to read). But hey, that's me. I like C, Scheme, and can tolerate Java on a good day. I dislike C++ the language, but can mostly ignore it and pretend it's C. - Piaw Na
I've seen it argued that LL(k) compiler-compilers don't have this fault, because they generate recursive decent parsers that look somewhat like what you'd write by hand, JavaCC certainly has this attribute for example. Although I'm quite fond of the parser-combinator approach now. - Ray Cromwell
Gabe: the issue is: when you need performance you must follow the C++ path. Don't forget http://theory.stanford.edu/~amitp... - Sebastian Wain
What Ray said. yacc uses an LALR parser, and LALR parsers are kind of notorious for producing inscrutable error messages. LL(k) compiler-compilers can generate much more intuitive error messages, and the code they generate often looks like something a human would write. Both JavaCC and ANTLR are good LL(k) compiler-compilers. I believe LL(k) parsers aren't strictly as powerful as LALR parsers, but in practice most grammars that you'd actually want to parse can be parsed with LL(k), though you sometimes need to factor the grammar a bit differently for the parser to handle it. Sort of going along with Piaw's sentiment: if you can't parse it with LL(k) the syntax is probably too complicated for humans to deal with anyway. - Laurence Gonsalves
On the topic of ooc: the "object [space] method-call()" syntax is the most jarring thing about the syntax for me. I'm surprised that there doesn't seem to be any actual introduction to that syntax on the linked page -- it's just used several times without explanation. Also, I have to say I'm not a fan of conservative garbage collection. - Laurence Gonsalves
Yes, when I hand code parsers, I write them in recursive descent form. The problem with C++ is that it's not easily parseable in that form. And seriously, any language where you can write map<string, string>, but have to write map<string, vector<string> > is seriously messed up. - Piaw Na
+1 to Laurence's comment about conservative GC: that's plain evil. - Piaw Na
Yeah, Piaw only uses progressive GC, and even then he keeps complaining that it's finding ways to snatch defeat from the jaws of victory. - Daniel Dulitz
I believe JavaCC grammar repo has a relatively straightforward C++ grammar implemented, using LL(k) - Ray Cromwell
Piaw Na: You got so much wrong in so few comments that it's actually worrying. Decl-assign is not terrible. It's called type inference, and is used in a lot of modern languages (ML, C#, Scala) to make our lives easier, and limits repeating yourself and it works damn well. Grow up and learn other languages. So no, the goal is not to imitate C. Go use Objective-C/C#/C++/Java/D if you want C-like languages. - 'n ddrylliog
Piaw Na: Second: I have hand-written the ooc 0.3 compiler's parser, and it was a piece of cake, because the syntax is so simple and unambiguous. Having "object[space]field" is a non-issues since declarations are "name: type". And you're mistaken in thinking that the fact you can hand-write a parser for a grammar means that it's simple. It's the other way around. If you can write a LL(K)/LR/PEG grammar, then the syntax is *very* straightforward. And the new ooc compiler (rock) uses a PEG grammar.. - 'n ddrylliog
Conservative Garbage Collector: There are advantages 1) the performance is a lot better than you would expect (and actually faster than plain malloc/free for lots of small objects) 2) there are advantages, e.g. seamless integrations with all the C libs out there. 3) Writing a GC isn't easy, the Boehm has been around for years and is well-tested/optimized, portable, etc. Read the papers please :/ This thread is a showcase of ignorance and arrogance. - 'n ddrylliog
As for "Language blah is better". No, sorry, apples are not better than oranges. That's your personal taste. Well, good for you =) One size doesn't fit all. Why do you even bother? - 'n ddrylliog
why `diagonal := Vector3f new()` instead of `diagonal := new Vector3f()` or even `diagonal := Vector3f()` is this because someone felt he must not be like any other language? - Tzury Bar Yochay
I know several typed inference languages. I dislike them --- again, type inferencing never took off not because the technology was hard, but because programmers preferred the declarations --- it really helps. Not to mention tools like ctags/etags, etc., do a good job for popular programming environments (i.e., vi and emacs), which meant that languages without such support never get widespread use. - Piaw Na
Conservative Garbage Collector: 1) this is more an argument abut gc than conservative gc. I have no problems with gc, I just want accurate gc. 2) That's a fair point, but not enough to make me want to use conservative gc. I'd be happier managing resources from C libraries manually than worrying that hash values are confusing the collector. 3) Yes, writing a gc isn't easy, but I'm sure there are accurate collectors out there you could use. Any language that uses conservative gc is no more of a "garbage collected language" than C. - Laurence Gonsalves
@Piaw, a type inferenced language just means that the type is concretely there, just it doesn't need to be declared in syntax. Thus, any smart editor or IDE, or other tool could reify or show types on demand if the developer so chose. Ctags are a relatively primitive mechanism for source code indexing, once you have an editor which understands your language's AST/semantics, you don't want to go back. I really question why HashMap<String, LinkedList<T>> foo = new HashMap<String, LinkedList<T>>() is better than foo = new HashMap<String, HashMap<String, LinkedList<T>> - Ray Cromwell
Tzury: why 'diagonal := Vector3f new()'? Because new is simply a static method: http://ooc-lang.org/blog... Your definition of "any other language" must be "Java and C++" and both are inconsistent/magical on this issue, as opposed to, yeah, pretty much "any other language" (Smalltalk, Ruby, Io, ...) - 'n ddrylliog
I've never heard of this before. Feel a bit disconnected. - mikepk
Ray: for better or worse, most programmers out there are using Emcas and vi. Why? Because no other tool scales up when you're dealing with large code bases. (That's one reason why even some Java programmers at Google use vi and Emacs) I don't care how primitive the tools are, they have to get things done. - Piaw Na
I agree with Laurence about conservative GC. The big one is memory fragmentation. Once upon a time, when all we ever wrote were desktop apps, memory fragmentation didn't matter. For server side applications, it matters a heck of a lot, and any language that uses conservative gc might as well provide the delete operator. - Piaw Na
C++ can be used quite effectively without STL or complicated templates, but it will never be safe from corruption or memory leaks. - Todd Hoff
@Laurence 1) Yes and no. The performance gap between good conservative and precise (/accurate/exact) garbage collectors is less significant than one would think. 2) That's a valid point 3) Actually, I've thought of using Steve Dekorte's libgarbagecollector (look on GitHub). These are still plans though, Boehm was clearly the easiest option to start with, and ooc itself isn't bound to any type of GC (you can even completely disable it, and the SDK is currently being adapted to gc/no-gc usage with version blocks) - 'n ddrylliog
Easily one of the most fascinating threads on FriendFeed right now. You guys are talking mostly over my head but it reminds me that I need to get my ass out of managed languages one day. - Akiva
@mikepk The language+impl has only been out there for a few months. =) - 'n ddrylliog
@Todd Totally agreed, which explains some design choices in ooc. Memory leaks is a non-issue with a GC, and as for corruption, as long as you stay out of manual memory manipulation, the compiler does most the checking for you, statically. - 'n ddrylliog
@piaw: I think we're mostly in agreement, but I really don't think it's fair to say that "most programmers use Emacs and vi". I use vi a lot, but when it comes to Java/Scala code bases, I still use Eclipse (or IntelliJ, or whatever). Even at Google. I just don't map the *entire* Google Java code base into my workspace at once. I'm pretty sure the vast majority of Java developers at Google do the same. The value of code completion, refactoring tools, red error squigglies, etc., etc., are far too valuable to live without. - Joel Webber
Joel: sure, you can play tricks like mapping only what you use. But a surprising number of Java users at Google kick up vim/emacs just so they can use the *fast* low-latency search tools when they need to read code outside of what they've mapped. The numbers were really surprising to me. - Piaw Na
I've been using emacs for 2 decades and I still use it when I need to quickly edit something or slice and dice text with macros (or I write sed/perl to do it). But when I'm developing stuff, a switchover point occurs where emacs is no longer sufficient and I desire the IDE. Emacs is great for scripts where you can test for errors via a quick eval, but the cost of a compile is high in Java, so I prefer edit-time error checking and refactoring to eliminate the number of times I have to run a compile/test. There's just no comparison between using Emacs for Java or Scala vs Eclipse/IntelliJ. - Ray Cromwell
There is, once you get into Google-size (or even Linux-kernel-sized) code bases. But I guess I've living in the Google bubble for so long, the concept of not having mega-libraries doesn't even occur to me. And we've built enough fancy tools at Google that make Emacs way faster than Eclipse/IntelliJ (see http://code.google.com/p...). Latency matters! - Piaw Na
Ultimately, this is a search problem, something that google excels at. I'm not sure why you think Emacs has any innate advantage over Eclipse/IntelliJ for this. If GTags can be built for Emacs, it can be done for those IDEs. (Those IDEs already index all symbols and store them on disk) The issue here is that "find symbol" is necessary, but not sufficient, especially on large code bases. Developers want the equivalent of real-time spell/grammar check, they want code inspections, quick fixes, refactoring, instant doc popup, code completion. Some operations are quicker in Emacs yes, the latency is lower. On the other hand, the latency of finding the right method, completing the right code, diagnosing a bug, or refactoring a method is far lower on IDEs. Ctags for example, is practically worthless on many third party libraries. My experience has been that they'll be like 20 methods with the same name and no clue which one you should actually jump to, without manually tracing the entire callstack. - Ray Cromwell
Heh. I open sourced all the infrastructure, but not the ranking algorithms for code (which are google proprietary) Having seen lots of old Google hands work in Emacs, I think you'll find that they disagree. People have tried adding plugins to gtags for Eclipse/IntelliJ, but none have succeeded --- those IDEs aren't designed to take plugins quite the way Emacs does. Even Vim isn't as extensible. What I find when I encounter top engineers (at Google and elsewhere) is that they've customized Emacs to a degree that switching to an IDE would actually hurt their productivity. - Piaw Na
As a practical example, the Linux kernel core (minus the whole driver universe) is about 500kloc. The GWT compiler, which I work on, is about 500kloc. I have zero complains about my IDE's ability (IntelliJ 9) to deal with this code base. Call it a medium sized code base if you will. Too big IMHO to practically use with Emacs/VI (where I desire refactoring and other navigational goodies), but small enough for the IDE not to choke. IntelliJ9 creates a large number of disk-based indices on the code base and keeps them in sync, so to me, it boils down to a matter of search indices, how they are architected, how they are kept in sync, as to whether the problem is scalable. - Ray Cromwell
What you'll find is that top engineers everywhere have heavily customized environments, scripts, editors, libraries, even their own programming languages, that make switching hard. Anecdotal evidence doesn't really prove anything, if "old hands" is meant to covey argument by authority. Like I said, I've been personally using Emacs since 1987, I use a bevy of ELisp, Perl, Awk, and other scripts on a regular basis. I'm not knocking these tools, I'm just saying that just because someone is used to something and not willing to change, doesn't prove anything. Lots of Americans say they LOVE their Healthcare system and don't want to change it. - Ray Cromwell
I think the mindset difference is huge. Codebase too big? The IDE solution is to subset. The EMACS solution is to create a search index held in memory and apply search technology to it. The size of the community hacking away on these tools also matters. - Piaw Na
Piaw, you do realize that the IDE solution (I can't speak for Eclipse), is to build a search index and apply search technology? IntelliJ spiders all your reachable code and files on project setup (now, as a background process since it can take some time) and serves up IDE functions by consulting the index. In fact, it's very much like Google Suggest. I can type symbol lookup requests (just tried it on 500k codebase) and it responds in milliseconds. I can "Find Usages" on this code base (like find all uses of JNode) and again, milliseconds. These IDEs are already doing what you suggest, they are just doing more, like indexing type relationships as well. - Ray Cromwell
Oh yeah, but they do it on disk and so have high latency when the code base scales up. I know, because people switch to Emacs/gtags from those IDEs for that reason. :-) - Piaw Na
Google's code base is large? I mean, I know the data it holds and indexes is very large, but somehow I assumed the code itself was quite small. - Andrew C (✔)
Actually, they cache some or all of the indices in memory depending on heap, at least according to the IntelliJ lead, if you increase heap, you lower cache thrashing. I still don't see why you think ETags/CTags/etc is any different in this regard. IntelliJ uses a similar index structure, it just records a bitmask on each tag as to the context (comment, identifier, method, field, etc). You either cache some or all in memory, or issue I/O to disk or a network server for assistance. There's nothing fundamental about Emacs architecture vs the IDEs changes tractability or scalability in this regard. IntelliJ already has a server-side component that can offload code analysis (TeamCity) and share it amongst clients, it's not too hard to imagine them serving up indices from the server as well, if there were a demand for it. - Ray Cromwell
@Andrew: I assume Piaw's talking about the *entire* code base, apps and all. That's a lot of code. - Joel Webber
gtags keeps it all in memory on a server, so there's no disk seek latency. There's nothing fundamental about the IDEs that makes this stuff impossible to do. It's just far easier to do in Emacs when there's just one of you. Once the prototype gets going, it's usefulness allows others to add in more useful functionality. Until recently, things like IntelliJ weren't even open source, so you couldn't add the functionality if it wasn't there, even if you wanted to. Eclipse was always open sourced, but adding extensions to eclipse is also a substantial project, not an afternoon hack. - Piaw Na
Thanks Joel. Yes, I'm talking about the entire codebase. All of it. :-) - Piaw Na
@Piaw, Ray: It's becoming clear to me that we're all essentially saying the same thing. To deal with a large, complex code base, you need good tools. IDEs vs. Emacs isn't really much of a dichotomy if they're both building indices and cross-references of your code base and serving them up to you within the editor. They're both IDEs, n'est-ce pas? - Joel Webber
Yes, I'm just saying, if you need to build something in a hurry, it's far easier to do it in Emacs. But more importantly, ignoring a base of Emacs/Vi users when designing your programming language is ignoring a large percentage of the population. And in some cases, it's a large percentage of a very influential population. - Piaw Na
@Piaw I somehow lost your point between the "omg I don't like type inference" and the "you're ignoring Emacs/Vim users". It's still straight-forward to look for declarations of things, what's your problem? It's precisely why := and = are separate operators - 'n ddrylliog
You'll get no argument from me. I'm a fan of diversity in programming, and I do use emacs daily. IntelliJ/Eclipse would do well to offer a simple in-editor tool for building plugins via any Java scripting engine and support saving those persistently. I guess my point is, I can't live without Etags functionality, and now I can't live without all the other features I've gotten used to: find ancestors, subclasses, implementors, refactor (numerous), completion (of everything), instant availability of documentation in method, instant checks for code style, readability, spelling, probable bugs, etc. Maybe it's because i"m getting older and losing brain cells. - Ray Cromwell
Even without any support, editing ooc in at text editor (I personally use Vim and Geany for .ooc) is very easy, cause you can search for "whatever:" (notice the ':') and be done with it. Try doing that with a C/C++/Java codebase =) That's the payback of a simple, non-ambiguous consistent syntax - 'n ddrylliog
And AFAIK, most ooc users/contributors/hackers use vim. A few use emacs, too. We have a vim syntax file, and a contributor is looking into writing an emacs mode. =) - 'n ddrylliog
@Piaw, Ray, et al: To finish my previous thought -- There will always be some point at which an IDE (be it Emacs or Eclipse) will fail to scale. The time and space required to deal with the code base eventually grows without bound, and you simply aren't going to load it into a single machine's memory. Even if you could load all of Google's code (or at least its index) into a single instance, perhaps you'd hit a brick wall at all of its external dependencies' code. Or that plus the Linux kernel. Or whatever. At which point, you'd do what I (and I'm sure many others do) -- accept a tradeoff and perform *some* tasks using, e.g., Google Code Search. But that's in *addition* to my IDE, not *instead* of it. Use the right tool for the job, I always say. - Joel Webber
Or you do the work to integrate the external search tool (or whatever) into the IDE. Emacs is designed to make that easy. The other IDEs that are around today, not so much. Code Search introduces a lot of latency. gtags as implemented internal to Google has sub 300ms response times. Whenever it goes down, I get complaints from people, declaring that "it's just too much work to remember where files are." - Piaw Na
I think Piaw's concern with type inference comes from the fact that explicitly stating the type of something acts as documentation. With type inference that documentation goes away. For example, in ooc, suppose I search for "whatever:" and I see "whatever:= foo()". What's the type? Whatever foo() returns. So now I have to look up foo(). Suppose it uses type inference on its return type (assuming that's possible in ooc). Now I have to dig even deeper. - Laurence Gonsalves
I'm guessing the IDE digression related to the fact that a sufficiently smart IDE can add the implicit type information back by doing the same type inference as the compiler. The problem with going down that road is that you're coupling the code editor and the language. Either your editor needs special language support so it can do the type inference, or you have to put up with not having an easy way of knowing something's type. - Laurence Gonsalves
I don't understand how you can do conservative garbage collection without leaking memory. - Gabe
Gabe: In theory, you can't. In practice, Hans Boehm did a lot of studies in the 1990s showing you that the leakage is very tiny. The real problem is memory fragmentation. With accurate GC, you can actually improve the locality of your data structures in memory (e.g., by putting elements of a linked list or array next to each other so a cache fetch brings them all into cache), with conservative GC, you can't do that. - Piaw Na
@Laurence: type inference: For me, the advantages far outweighs the drawback(s) (And, no, no return type inference in ooc). Plus, you don't *have to* use type inference. You can declare type explicitly in your whole codebase if you feel like it. - 'n ddrylliog
For the record: I'm not saying I necessarily agree with Piaw's distaste for type inference. I've thought about the issue in the past, but haven't used languages with type inference enough to have an opinion one way or the other. The lack of return type inference might be a good compromise, as it would tend to limit how far you'd have to search to figure out the type of something, while still eliminating a lot of the "busy work" in languages that require that you specify the type of everything. - Laurence Gonsalves
@Laurence You've come to the exact same reasoning as me =) - 'n ddrylliog
I do still think you should explain the "object[space]method-call" syntax somewhere on that page. Up until the point where you use that syntax ooc looks vaguely similar to C/Pascal/Algol/etc., so seeing this unfamiliar syntax with no explanation is confusing. - Laurence Gonsalves
@Laurence I just edited the homepage. Better now? - 'n ddrylliog
I really like the way C# handles pointers and GC: All objects are allocated from the GC heap. If you need a pointer to a GC-able object, you only get it by pinning it. Once the pointer goes out of scope the object gets unpinned. And you can only use pointers in code marked "unsafe" so it's obvious to the reader. - Gabe
Gabe - does the fact that C# is not compiled to machine code like C++ make it slower? - Robert Felty
Rob: C# gets compiled to native machine code when you run the code. There's also a program that ships with .Net called ngen which will create a native image without having to run the code. - Gabe
It would be nice if Microsoft open-sourced C#/.net. I know there is Mono, but that seems like it will always be second-class. - Paul Buchheit
What happened to the "Opening .Net Framework's Source Code" project, any ideas? - Özkan Altuner
I guess Rotor isn't good enough, huh? - Gabe
I was thinking of an actual open/free license. - Paul Buchheit
Paul Graham on object orientation: http://www.paulgraham.com/noop... - Donald C. Lindsay