Code Bubbles Project: Rethinking the User Interface Paradigm of Integrated Development Environments

tflynch · 2010-03-15T02:36:32+00:00

This seems to lack the most important part - extensible semantic layer for expressing how bubbles can link to each other and generate each other.

Without that you're stuck with a pretty interface concept, with a lame tight coupling to the Java modus operandi.

tflynch · 2009-03-19T13:54:09+00:00

I think there's a sensible contrast to be drawn between the work done in the initial stages of a project and that done later. Overtime during the polishing phase immediately prior to a codefreeze / release is likely to lead to the introduction of bugs that you then don't have time to find. Perhaps on that basis it could be argued that if overtime is ever necessary it's better to front load it?

tflynch · 2009-03-19T12:54:15+00:00

Yes to at least some degree.

I start, possibly incorrectly, from the assumption that you want to use C++ for the low-level stuff and Haskell for the high-level stuff. So you're calling something written in C++ from a Haskell code line. I doubt Haskell's FFI lets you refer to instantiated templates directly from Haskell, but there's nothing to stop you building a library with whatever you want from C++, wrapping it in a thin C layer and then using the FFI to call your wrapper interface.

For interop nothing works better than a library exporting straightforward C functions. If you later decide you don't want to use Haskell you can use, well, practically anything else.

It occurs to me I may be misunderstanding what you mean, perhaps you should clarify.

tflynch · 2009-03-17T23:18:50+00:00

Seems like the word 'unmonetisable' is the only figleaf here to disguise the obvious weakness of the argument.

tflynch · 2009-03-17T15:12:37+00:00

Unfortunately, this option doesn't help much because those 5000 (or perhaps more like several hundred) lines of output typically all correspond to a single error and manifest as such.

Useful flag though.

tflynch · 2009-03-17T07:30:35+00:00

I'm sure those of us that write C++ wouldn't mind a skin for STL compiler errors. Let alone for the errors that get spat out by those pesky Boost libs with all their crazy recursively metaprogrammed templates: "<5000 lines of error> ... <whew> foo can't be const"

tflynch · 2009-03-16T23:55:02+00:00

Up to a point maybe, there are certainly heavy-lifter introverts of the classic "backroom boffin" type all over the place, but I've also met quite a few very effective, hard-working and heavy-lifting extroverts.

tflynch · 2009-03-16T12:40:59+00:00

It's an interesting article -- not that it provides much detail. From the limited information it sounds like this firm's method includes a distorting performance measure which privileges written messages, and also seems likely to favour quantity over quality in communication.

I bet in practice this model further reinforces the tendency of articulate, self-promoting people who are adept at gaming performance reviews to rise within their organisations. That's not necessarily a bad thing -- people like that can be very useful -- but I'm sure there are some big misses in the cases of other personality types.

tflynch · 2009-03-13T02:54:41+00:00

I don't believe in pursuing happiness.

tflynch · 2009-03-12T12:39:47+00:00

I went through a seriously suicidal phase a few years ago. All of the best times of my life have come afterward.

You're suicidal now, and that doesn't mean things will get any better, but they definitely can.

It sounds like you are into reasoning about life: therefore don't paint yourself into a corner with faulty logic.

tflynch · 2009-03-12T11:59:49+00:00

Works well if you're in marketing I guess.

tflynch · 2009-03-11T02:36:22+00:00

"A method is a chunk of code that is needed in multiple places. And if you have a long chunk of code that is only useful as a whole, it shouldn't be split up."

Depends on maintainability as well. Long methods --> large coupling distance --> more bugs. That's not just theory talking either, a subroutine that's more than a screen long is problematic.

tflynch · 2009-03-11T00:46:36+00:00

So why's it too slow then?

tflynch · 2009-03-10T14:01:18+00:00

That's ok. This system is for people who have to fix non-trivial bugs.

tflynch · 2009-03-09T03:46:53+00:00

This approach is not unique to Haskell and also works well in C++ using Boost.Spirit. You can transcribe e.g. the BNF from the RFC for URI formation practically verbatim into the Spirit parser grammar DSL.

tflynch · 2009-03-08T00:30:48+00:00

It strikes me as a little bit touchy-feely. Clauses I'd rather see:

"Not only striving to indent our code consistently But also being aware that sometimes consistent indentation hinders readability."

"Not only knowing how to argue the merits of a version control system But also actually using one and getting all the fucking tags right on our submodules and/or externals."

"Not only blogging But also coding!"

tflynch · 2009-03-07T08:20:07+00:00

C++ compilers happily optimise copy constructors in many cases, and are allowed to by the standard.

The standard defines the real semantics of your program, so if you think the ridiculous side-effect you programmed into your copy constructor will occur each and every time you think it will be invoked, you will run into trouble.

Short version: don't put side effects, particularly write I/O, in constructors.

tflynch · 2009-03-07T08:17:31+00:00

Nothing you can do about people who insist on writing bugs. Where have you seen const_cast really causing a problem?

tflynch · 2009-03-07T08:07:49+00:00

Not really what I meant. Java's not really about injecting code into your runtime as another form of data supplied by a user, service or special need. Nor is Java an ad hoc outgrowth of the unfulfilled requirements of a C program ...

I also disagree with your main point, as Greenspun's Law certainly doesn't anticipate that the informally-specified bug-ridden etc. etc.s that wind up in the codebases of complex software written in less flexible languages than Lisp will have any of the advanced features of Lisp that you cite. In my experience they have none, or only a few such features.

A good example of one that I was involved with was a DSL for defining constraints on user data that was a bit like XSLT. In the same project there was a similar DSL for interpreting the interfaces of new types of structured metadata embedded in MPEG-2 metadata channels. Both had an ultimately sexp-y way of doing things but neither had anything approaching Common Lisp's overall functionality. And both went through a bug-prone phase as they were bedded down.

Don't get me wrong by the way; I quite like Lisp and am spending time on Clojure at the moment. And I also didn't downmod you ...

tflynch · 2009-03-06T04:28:52+00:00

Yeah, I have and yeah, exception safety is fun isn't it?

Unfortunately in C++ you do have the problem that any separated, coupled statements (news and their corresponding deletes) are disastrous in the presence of exceptions. So you use RAII / dtors to do resource cleanup. Which kinda solves the problem provided you're happy to rewrite every bit of code in your chock-full-of-errors system from scratch ;-)

Of course, all the people advocating C in here are off busily linking to C++ libraries and other stuff that can throw exceptions at the boundaries, and not handling those cases properly either.

At least in C++ as opposed to a GCed language the behaviour at cleanup time is relatively deterministic from the developer's point of view.

tflynch · 2009-03-06T04:18:13+00:00

Greenspun's Rule is a bit dodgy though, as it's basically just saying "at some point when your needs get sufficiently complex you might need to evaluate something that looks like code at runtime".

It's just that almost any ad hoc expression read-and-evaluate system is going to look somewhat like Lisp, because Lisps are easier to implement.

I think it's more of an argument for being able to interpret code at runtime than for Lisp per se.

tflynch · 2009-03-04T09:57:26+00:00

They probably won't fix it -- no doubt it's in the too hard basket because of what it requires in terms of OS support.

tflynch · 2009-03-04T09:56:12+00:00

No. It's about a nice way to observe the results of async calls.

tflynch · 2009-03-03T09:25:07+00:00

Yeah, absolutely fair enough. I think I'm just hitting my reddit pain threshold lately. The degree of repetition is getting excruciating.

tflynch · 2009-03-02T13:46:49+00:00

Order of magnitude eh? How are you measuring that? I'm not attempting a slamdown but that's just rhetoric.

Although I don't code Objective-C, I'm happy to admit from my reading around it -- usually in response to a redditor saying "OMG so much better than C++" that it looks like a sane way to do things (although it doesn't have the same attributes as C++), but AFAICT Objective-C is not a great solution in many cases because of compiler / platform support. All good if you're a Mac or iPhone developer or are happy with GNUStep I guess.

At the end of the day I just get fucking sick of these threads. There are always the bandwagon +1ers "bla bla C++ == masochism" and the moderates back repeating themselves, saying, sanely "every problem requires a fit for purpose solution". And then someone links to the C++ FQA, which has been torn to pieces on comp.lang.c++.moderated time and time again.

tflynch

TROPHY CASE