|
honey the codewitch wrote: I'm glad we don't build bridges and skyscrapers.
We've been building physical structures for thousands of years, and writing software for less than 80. Architecture and civil engineering are obviously more mature disciplines than software engineering. Assuming civilization survives, I am certain that our software development efforts will be viewed by future engineers in the same manner that the builders of mud huts are viewed by modern civil engineers.
(But we do build some very impressive mud huts!  )
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Software techniques will undoubtedly improve, but there are things from 45 years ago that I don't find primitive. I think software will always be difficult because, unlike engineers, we continually evolve existing products and, unlike mechanics, we repair them while they are up and running.
|
|
|
|
|
|
I think you are giving too much credit with the "mud". Mud + straw bricks will last a very long time!
More like straw huts with a few sticks.
This is making me think of software before memory protection.
I imagine a village with thatched roofs side by side by side.
Each house is an app. The thatched roofs are the ram for that app.
The village is the whole machine.
A fire in one house would rapidly jump roofs and take out the entire village.
|
|
|
|
|
englebart wrote: Mud + straw bricks will last a very long time!
Yes, in the right climate. It is not well suited to climates with heavy rains.
This is beside the point. No modern architect would seriously consider using mud (or mud + straw) for a building, and likewise no future software engineer would think of using the techniques (or lack of them  ) used in most current software.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Clay is actually a very good building material and it's used occasionally to construct ecological buildings. See for example Clay Houses - Resilient Fireproof Unique and Attractive[^]
That said, it's advantages are so impressive that it's hard to understand why it's not used more widely.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Do you mean raw clay, or baked clay? Raw clay tends to go soggy when wet...
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Not baked (as in bricks).
When building a structure, the clay needs to be wet so it merges tightly with the rest of the material and pores get closed. It needs to dry for quite some time, so you might run into trouble building large structures unless you can be very sure to have a long period of dry weather.
I know it works pretty well because my brother used clay (pellets) and straw to replace the walls in his studwork house. No problems with soaking at all.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
I sit corrected. 
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Don't worry. I'm not an expert, but I guess that our ancestors took ages to learn why some 'mud' huts lasted forever while others melted away in the very first rain storm. 
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
But we do build software that keeps aircraft in the sky (that's a system failure, arguably, but involves the software), keeps nuclear reactors from melting down, and calculates dosages for medical devices...
I've developed software that is currently flying on passenger aircraft and I can tell you with certainty that the practices and processes used for those lines of code were vastly different than what's used for most software - the NASA Software Engineering Handbook is a pretty good example of this.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Don't even get me started on the dosages one. A multithreading issue killed 3 people (as i recall) connected to machines delivering chemo treatments.
Real programmers use butterflies
|
|
|
|
|
And we do build mars orbiter software[^] that uses imperial units 
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
|
32768 m/s should be fast enough for anybody! 
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Air traffic control, aircraft avionics
Medical equipment
Law enforcement communications
Defense electronics and C3I
Manufacturing controls, especially for food and medication
...
All of these applications and many more have profound human health and safety implications.
We build much more than bridges and skyscrapers.
Software Zen: delete this;
|
|
|
|
|
fair point. 
Real programmers use butterflies
|
|
|
|
|
I agree.
And have done since the The Beginning (Turbo Pascal 5.5 and Turbo C++ 1.0).
No language should be purely OO, multi-paradigm (ptui) is the only true path.
Use OO when it makes sense, but not wen it doesn't.
You're not alone out here.
Requisite link:
Stevey's Blog Rants: Execution in the Kingdom of Nouns[^]
|
|
|
|
|
I find it interesting that you now use objects less than when you first started to code. I would've thought that it would work the other way around. But maybe that's for us dinosaurs who first learned structured programming and later had to think in terms of objects. If you learn objects first, I can see it progressing in the opposite direction.
I'm curious as to what you meant by C++ changing your attitude towards objects. Maybe you started to use them less because C++ has too much boilerplate!
Sure, a standalone piece of code will be smaller, faster, and easier to understand if it isn't broken up into many little objects. But you called it a "little HTTP server". What if it had to be big? Or support other protocols? Or be integrated with a large system?
The larger the system, the more important it is to achieve reuse and abstraction, which means separating concerns and using polymorphism, inheritance, and encapsulation. Without this, developers clone and tweak code that can't be reused because it's admixed with other concerns. It also becomes harder and harder to add new capabilities, because they have to interwork with components that exhibit superfluous diversity. A maze of twisty little passages, all different.
That said, OO can get overused and won't solve everything. It would be great if it could be coupled with aspect-oriented programming, but I haven't seen a good way to do that, and aspects may simply be intractable when it comes to cleanly separating concerns.
|
|
|
|
|
I can't really find much to argue with here, as I do believe OO has its place, even if i wonder if it hasn't made a mess of things too.
I moved away from objects with C++ once I learned STL which led me to generic programming which deals in aspects moreso than objects.
Real programmers use butterflies
|
|
|
|
|
The STL is definitely generic programming, but I don't see what it has to do with aspects.
By aspects, I mean things that are orthogonal to a class's purpose but that are impossible to decouple from its implementation. Here are some examples[^]. If you use the code described in that article, without modification, you'll also drag in a pile of other things, whether you want them or not. Even if you do want them, it becomes a question of whether their implementations are what you want.
|
|
|
|
|
I know what aspects are.
To be clear:
Where they tie in here, is you create "services" for your classes - implemented as templates that take your own class as a template argument.
Those allow you to encapsulate orthogonal class services to a degree. It doesn't always allow for complex cross-cutting scenarios, and arbitrarily wrapping methods with pre and post code takes some vtbl foolery (microsoft takes this approach with certain ATL internals) but you get your aspects this way.
It's kind of primitive and just as "kludgy but powerful" as templates are. Between the above and using type traits and such you can get it to do a lot of what you would do with aspect oriented builtins in a higher level language
Real programmers use butterflies
|
|
|
|
|
I think I see what you're getting at. Is there an example that you can point to?
If I'm guessing correctly, it would probably fit in well with what Sutter suggests in Virtuality[^]. If every virtual function is private and invoked by a non-virtual function that is public, that provides a place to add pre- and post-code. But it would certainly have some limitations.
|
|
|
|
|
I'd have to dig up some of old code off of my one drive if it's there. i wasn't using github until more recently.
People usually don't describe it the way I do. It's a technique I picked up while doing research into making a rather ambitious business integration system with COM+ like features. Someone demonstrated cross cutting functionality using the Curiously recurring template pattern - Wikipedia[^]
It gave me one of those aha moments, and since, whenever I see a CRTP like above, i half expect it.
Dr. Dobbs has an article about doing cross cutting but they don't use generic programming to do it.
<h1>Aspect-Oriented Programming & C++</h1> | Dr Dobb's[^]
But if you poke at it you can see there's opportunities for factoring into a template
Real programmers use butterflies
|
|
|
|
|
 Couldn't agree more!
A bit of personal history: once upon a time when I was a young student of programming (an a fairly brilliant one if I may modestly say so  ) I started arguing with one of my professors about the merits of structured programming which I thought it led to far more bloated programs compared with the self-modifying code that I was able to churm. He was wise enough to just encourage me to stick with the structured code even if sometimes my unorthodox style would led to very efficient programs. In time I've got to see the error of my ways specially when I started working with a team and having to share code with humans not only with computers.
When I learned OO it was equally hard at first to get used to it and my programs would have all the flaws a beginner OO programmer would do: too many classes, ill-defined responsibilities, multiple inheritance... you name it, I've done them all.
Generic programming came along and I thought in the beginning that I need a debugger for the obscure error messages that the compiler threw at me.
To make a long story short, each one of these steps brought something to my understanding and now I think I can choose the right tool for each problem. Throwing one of them away would not make me a better programmer.
To the man with a hammer everything looks like a nail!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
