OSDev.org

Brendan wrote:

skeen wrote:

Brendan wrote: Imagine a triangle like this:

Code: Select all

                  |\
                  |_\
                  |  \
  Skill/knowledge |   \
                  |    \
                  |     \
                  |      \
                  |_______\
                   Number of people

Brendan wrote:Stupid people like Bjarne Stroustrup and Simon Peyton Jones try their hardest to destroy programming for 95% of the people on earth; and amazing people like Alan Kay are trying their hardest to bring programming to 100% of the people on earth.

Okay, so while I like the idea of having programming be a common skill, alike mathematics, then there's something that I'd like to note;

If somebody is to build a piece of medical equipment, which my life depends on, then I'd like them to be at the top of the triangle, this goes for programmers, as well as other engineers. Because programming correctly in a multi-threaded environment using languages alike C/C++ actually require knowledge, as proven by Therac. - And I'll agree that this is partly because of the languages.

For medical equipment, I agree, but most software isn't as critical.

For programming correctly in multi-threaded environments, I don't think it's the language's fault. The problems are that the "procedural programming" model is bad ( causes the need for locks, etc); and a lot of programmers simply didn't have the knowledge/experience to deal with concurrency properly.

It's nice that we agree, also for medical equipment it should really be done in something like Coq.

And if you think it's the paradigms fault, then well, the language that uses that paradigm is somewhat an accomplice, and we can agree, that the use for locking is indeed troublesome, and hence you need knowledge/education and/or experience, to deal with it, that is unless you use another paradigm.

Brendan wrote:

skeen wrote:Also I'd like to argue, that programming is not simple, simply because of the immense required complexity of large software systems (i.e. not language complexity, even though that may be contributing), and because of the rather complex mathematical foundation, also Stroustrup is not trying to destroy programming for the 95%, he's trying to make it more accessible! - Which is quite a task with C++ indeed!

I'd argue that designing complex systems is hard (including breaking large things into sufficiently small things that can be implemented easily); while programming should be simple (laborious rather than complex). Like I said in my previous post, the tools for software design either don't exist or suck a lot, so nobody uses them, so design problems end up being implementation problems.

As I wrote in the other answer, implementation is actually a part of the design process, at least to me, and I already stated what my goals for a programming language is, that is mainly to be able to express my intent. And yes programming should be simple, but no simpler than I'm able to express my intent, without having to deal with breaking it into smaller bits, than I'd like.

Brendan wrote:

skeen wrote:Alan Kay, on the other hand, is indeed doing some fantastic work! Compared to Stroustrup however, he's got the easier approach, as he's not bound by billions of lines of code, which cannot be broken, and an entire C++ committee with various interests and intents for the languages. He's able to focus on one intent, that is bringing programming to the 100%, that being said, Etoys is actually a domain specific programming language in that sense (even though it may be general purpose).

Just for fun, do a google search for "designed by committee"...

Just did, and there's more truth in that, than one can be comfortable with, however this is always the case, when several people are in charge, now isn't it

Brendan wrote:

skeen wrote:

Brendan wrote:To deal with the inherent complexity of large projects, you need software engineering tools and not programming tools. These are things like UML diagrams, and breaking large/complex systems into smaller/simpler things when the system is being designed (before anything is implemented at all). People that think things like generics are going to help with the "inherent complexity of large projects" problem are trying to solve the wrong problems in the wrong tools - these things do not help at all, they only make the "complexity of programming languages" problem worse.

I partly agree, to deal with the complexity of large systems, you definitely need software engineering tools, however if programming tools are able to help you out with the same task, why not make sure of that as well?

Because it's the wrong tool for the job. It's like using belt-sander to cut wood - it's technically possible, and you could improve the belt-sander to make it cut wood better, but you're doing something very very wrong.

If I were to cut a lot of wood, and there were no proper saws, then I'd rather have a weird belt-sander. That is without any saws that can do it on their own, I'd rather use bring in improper tools and get the job done.

Brendan wrote:

skeen wrote:Programming language tools is not *the* solution, it is *part* of the solution for complexity.

If you did improve a belt-sander to make it cut wood better, it's very likely that you'd just end up with a tool that isn't as good at sanding wood. Programming languages are tools to help with implementing the design, one small piece at a time, until the entire design is implemented. They aren't a part of the solution for design complexity, just like a belt-sander isn't part of the solution to cutting wood.

What I'd end up, is a swiss army knife, that's able to do a lot of things. I'll end up with something which is general purpose! - While I'll not be able to do things as well as some domain specific tool, then I'll be able to do everything reasonably bad!

Brendan wrote:

skeen wrote:I agree, that we can't always do this, but in the current context, the usage of Ada merely provided another syntax, which was 'alien' to some (most?) or us. Bear in my mind, that generics in C++ was actually influenced by Ada.

And while I'd love to use other languages to communicate my ideas, I'd still like to reach the audience. This applies to spoken language as well as programming language, however I doubt most people here would like to spend the time it takes to learn Danish, just for me to express myself in a more native way. I don't want people to learn some language, just to get my point, if I'm able to somewhat loselessly translate it into another language. This also applies to programming languages.

We can't use today's language, to discuss today's problems, if no-one (or only a small subset) speaks the languages of today.

Excellent! Now look back at my "triangle of knowledge", and assume you're trying to reach the huge audience in the middle of the triangle rather than the negligible minority at the top...

I never said I don't want to reach a huge audience in the middle, I just stated that I like my house to be built by an educated contractor, rather than a group of 10year olds.

Also I honestly think that most of the people in this fora, is actually somewhere near the top of the dreaded "triangle of knowledge", at least when related to programming, and OSes.

Kevin wrote:

skeen wrote:And really I think the discussion of generics, is above language specific details, C++ is merely the vessel for examples, rather than what we are, and should be discussing. Because if we are to actually discuss languages in specific, then I'd like to abandon C++ before someone starts attacking that directly, rather than the concepts we use it to explain, since C++ is indeed a hacky language.

This is actually the reason why I didn't use C++ (besides the other one, that my C++ is really weak). Brendan started with the assumption that generics = C++ templates, and while I can understand that someone finds too C++ templates too powerful because you can do really complex things with them, I wanted to point out that this isn't a problem of the concept of generics in general, but of the specific way that C++ implements them.

Java would have been a reasonable choice as well, but it's a bit less different, so it wouldn't have shown as much things that you can do differently and still have generics (like the explicit instantiation, or explicitly declared required operations, both of which I find really interesting features).

I do think it's generally accepted to state, that having a Turing complete type system, may be a little over the edge, at least in the programming language community, as it's a pain in the a**, to deal with in static analysis, compiler design, ect. However it allows one to do things, which are indeed out of the ordinary, and it's innovative in that sense.

Please note that innovative != reasonable != good. Even though correlation can imply causation.

And as for Java generics, they are mostly for implementing collections, which is fine on it's own, but it's not really the generic paradigm.

Also C++ templates are indeed a laaaaarge superset, to most generics.

Brendan wrote:

Kevin wrote:

Yes, with specialisations some code is reused, but then you've got a pieces spread all over the place turning something that should've been easy to read into an annoying "find the shrapnel" maintenance headache.

Right, you get the library and its users separated. That's a good thing.

Code: Select all

Do you                                     honestly think
it's easier                                  to read code
with different                                  pieces in
different                                         places?

Ithinkit'saloteasiertoreadtext,whenithasLOGICALseparation. --> I think it's a lot easier to read text, when it has LOGICAL separation.

And I think it's reasonable to decouple; algorithms and data structures, implementation and interface, data structures and data contained, ...

The main point is, that the separation is logical one; you should only break stuff up, if it makes sense to do so!

On a last note before I'm off;
I'm sorry that I haven't been responding for the last few days, and that I'm now answering in a burst.

Deal with it

Hi,

skeen wrote:

Brendan wrote:For programming correctly in multi-threaded environments, I don't think it's the language's fault. The problems are that the "procedural programming" model is bad ( causes the need for locks, etc); and a lot of programmers simply didn't have the knowledge/experience to deal with concurrency properly.

It's nice that we agree, also for medical equipment it should really be done in something like Coq.

And if you think it's the paradigms fault, then well, the language that uses that paradigm is somewhat an accomplice, and we can agree, that the use for locking is indeed troublesome, and hence you need knowledge/education and/or experience, to deal with it, that is unless you use another paradigm.

I'd be more tempted to call it a historical artefact - a paradigm (and languages) from an era before concurrency became a concern, with work-arounds (locks, etc) applied over time to make them usable for something they weren't designed for. It's not ideal, but it's become entrenched, so it persists. Now people are reaching for work-arounds for the work-arounds (transactional extensions intended to avoid some of the complexities of locking) in the hope that will help. It won't.

skeen wrote:

Brendan wrote:I'd argue that designing complex systems is hard (including breaking large things into sufficiently small things that can be implemented easily); while programming should be simple (laborious rather than complex). Like I said in my previous post, the tools for software design either don't exist or suck a lot, so nobody uses them, so design problems end up being implementation problems.

As I wrote in the other answer, implementation is actually a part of the design process, at least to me, and I already stated what my goals for a programming language is, that is mainly to be able to express my intent. And yes programming should be simple, but no simpler than I'm able to express my intent, without having to deal with breaking it into smaller bits, than I'd like.

I think most of the time "implementation as part of the design process" is just a symptom of unsuitable design tools. The only case I can think of where it's not a symptom is where you want to slap together a prototype as part of research, but I wouldn't want to try to convert something like that into a decent quality piece of software.

skeen wrote:

Brendan wrote:

skeen wrote:I partly agree, to deal with the complexity of large systems, you definitely need software engineering tools, however if programming tools are able to help you out with the same task, why not make sure of that as well?

Because it's the wrong tool for the job. It's like using belt-sander to cut wood - it's technically possible, and you could improve the belt-sander to make it cut wood better, but you're doing something very very wrong.

If I were to cut a lot of wood, and there were no proper saws, then I'd rather have a weird belt-sander. That is without any saws that can do it on their own, I'd rather use bring in improper tools and get the job done.

As a temporary work-around, yes. However; if you were a company that made tools and noticed everyone was cutting wood with belt-sanders, then surely you'd at least try to create a tool designed for cutting wood.

Of course this isn't a new idea - there are tools for design. Most are UML editors where you create your UML diagrams, then start implementing the code and find that it doesn't match the diagram and throw the diagram away.

This is one of the things I've been thinking about for ages - trying to "invent" some new design tool that I'll eventually build into the IDE. I really don't think I've managed to come up with anything that's good enough yet.


Cheers,

Brendan

Brendan wrote:Of course this isn't a new idea - there are tools for design. Most are UML editors where you create your UML diagrams, then start implementing the code and find that it doesn't match the diagram and throw the diagram away.

And most of those (well, in fact all that I know) suck so bad as editors that you want to throw them away and switch to pen and paper. When we absolutely had to use a UML editor for some university projects, we were quickly fed up with how hard these tools make it to input data so that we started looking for more efficient solutions. And there was indeed one: Write source code stubs and use the reverse engineering functionality of the UML tool.

This really tells everything about the state of existing UML tools. (Existing a few years ago, but I would be surprised if it had changed.)

Hi,

Kevin wrote:

Brendan wrote:Of course this isn't a new idea - there are tools for design. Most are UML editors where you create your UML diagrams, then start implementing the code and find that it doesn't match the diagram and throw the diagram away.

And most of those (well, in fact all that I know) suck so bad as editors that you want to throw them away and switch to pen and paper. When we absolutely had to use a UML editor for some university projects, we were quickly fed up with how hard these tools make it to input data so that we started looking for more efficient solutions. And there was indeed one: Write source code stubs and use the reverse engineering functionality of the UML tool.

This really tells everything about the state of existing UML tools. (Existing a few years ago, but I would be surprised if it had changed.)

I had the same/similar experience. I think UML is a little too formal, not obvious enough (unlikely to be understood properly by someone that hasn't seen it before), and most UML tools try to get you to add too much detail; and these things make it more work than necessary. It's also better suited to OOP and awkward for languages that aren't object oriented.

Flowcharts aren't too formal and are obvious enough; but can't work for design because they're far too close to the source code. I would like to use flow charts as alternative source code representation though, to help people learn how to program (e.g. start with flowcharts for 1 week, then switch between flowchart and text until the learner gets used to text).

TDD (Top Down Design) works well for breaking large and complex things down into smaller more manageable pieces. This is what my Programming "Views" idea is trying to do. I don't think it captures enough information on its own though - there's still something missing (and possibly 2 or more things missing). I just don't know what the missing things are.

I think one of the things missing is something that shows threads (e.g. which pieces of code are used by which threads); and I suspect that for my system this might be something that shows "actors" and how those actors are mapped to threads. I'm not sure though, and don't know what it would look like or what would be needed to make sure the diagram and the actual source code stay synchronised.


Cheers,

Brendan

Brendan wrote: I think most of the time "implementation as part of the design process" is just a symptom of unsuitable design tools. The only case I can think of where it's not a symptom is where you want to slap together a prototype as part of research, but I wouldn't want to try to convert something like that into a decent quality piece of software.

As stated I always prototype as a part of the design process, mostly to weed out bad designs early. As for converting prototypes into quality software, I kinda like doing this, as the unit tests from the prototype, ensures that the prototype functionality isn't broken. While new unit tests, ensure all the corner cases will be covered.

Brendan wrote:

skeen wrote:

Brendan wrote: Because it's the wrong tool for the job. It's like using belt-sander to cut wood - it's technically possible, and you could improve the belt-sander to make it cut wood better, but you're doing something very very wrong.

If I were to cut a lot of wood, and there were no proper saws, then I'd rather have a weird belt-sander. That is without any saws that can do it on their own, I'd rather use bring in improper tools and get the job done.

As a temporary work-around, yes. However; if you were a company that made tools and noticed everyone was cutting wood with belt-sanders, then surely you'd at least try to create a tool designed for cutting wood.

Of course this isn't a new idea - there are tools for design. Most are UML editors where you create your UML diagrams, then start implementing the code and find that it doesn't match the diagram and throw the diagram away.

This is one of the things I've been thinking about for ages - trying to "invent" some new design tool that I'll eventually build into the IDE. I really don't think I've managed to come up with anything that's good enough yet.

You know what would be cool? - If the weird belt sander, replaced the sand belt with a chain, and found it actually outperformed the ordinary saw quite a bit! - Also as for UML, the main issue to me, is that it's really only geared towards OOP.

Hi,

skeen wrote:

Brendan wrote: I think most of the time "implementation as part of the design process" is just a symptom of unsuitable design tools. The only case I can think of where it's not a symptom is where you want to slap together a prototype as part of research, but I wouldn't want to try to convert something like that into a decent quality piece of software.

As stated I always prototype as a part of the design process, mostly to weed out bad designs early. As for converting prototypes into quality software, I kinda like doing this, as the unit tests from the prototype, ensures that the prototype functionality isn't broken. While new unit tests, ensure all the corner cases will be covered.

Heh - often my prototypes are the minimum necessary to research an idea. This means there's no unit tests, I don't bother checking for errors (e.g. assume malloc, open, etc always work), I use the simplest/laziest algorithms, I might put input files directly into the source code (e.g. "char *inputFile = "hello\n This is the input file...\n") to avoid bothering with file IO, there's no multi-threading (even when it's obviously needed), etc. There's no way any of it is usable, as it's designed to be fast/easy to implement (then discarded).

skeen wrote:

Brendan wrote:

skeen wrote:If I were to cut a lot of wood, and there were no proper saws, then I'd rather have a weird belt-sander. That is without any saws that can do it on their own, I'd rather use bring in improper tools and get the job done.

As a temporary work-around, yes. However; if you were a company that made tools and noticed everyone was cutting wood with belt-sanders, then surely you'd at least try to create a tool designed for cutting wood.

Of course this isn't a new idea - there are tools for design. Most are UML editors where you create your UML diagrams, then start implementing the code and find that it doesn't match the diagram and throw the diagram away.

This is one of the things I've been thinking about for ages - trying to "invent" some new design tool that I'll eventually build into the IDE. I really don't think I've managed to come up with anything that's good enough yet.

You know what would be cool? - If the weird belt sander, replaced the sand belt with a chain, and found it actually outperformed the ordinary saw quite a bit! - Also as for UML, the main issue to me, is that it's really only geared towards OOP.

For a belt-sander you need a wide flat surface for the belt to pass over. For a chainsaw you need a thin blade, not a wide flat surface. For programming you need all the gory details of the specific piece/s you're working on. For design, you want to see a lot more and the details just get in the way.

Mostly, you can (and probably should) have a hybrid tool for design and programming (and building and testing), but they're all very different activities with different "sub-tools". This makes the IDE more like a tool box containing several tools (e.g. belt-sander and chainsaw).


Cheers,

Brendan

One tiny observation; it looks like you've drifted from the original topic. Brendan, can you split the topic at some point & delete this post?

Hi,

Candy wrote:One tiny observation; it looks like you've drifted from the original topic. Brendan, can you split the topic at some point & delete this post?

Hrm - here's a very interesting (and quite welcome) surprise! It's been a long time since I've had the pleasure of seeing Candy on these forums

In general, I don't like moderating my own posts - it can be a little hard to remain professional/unbiased, so...

Candy, you are still a moderator here, would you mind splitting this topic at some point and deleting both of these posts?


Thanks,

Brendan

<OT>
Damn, Brendan beat me to it.
@Candy Welcome, um... back from 2011.
<OT>