Back To 'The Future of Programming'

theodp writes "Bret Victor's The Future of Programming (YouTube video; Vimeo version) should probably be required viewing this fall for all CS majors — and their professors. For his recent DBX Conference talk, Victor took attendees back to the year 1973, donning the uniform of an IBM systems engineer of the times, delivering his presentation on an overhead projector. The '60s and early '70s were a fertile time for CS ideas, reminds Victor, but even more importantly, it was a time of unfettered thinking, unconstrained by programming dogma, authority, and tradition. 'The most dangerous thought that you can have as a creative person is to think that you know what you're doing,' explains Victor. 'Because once you think you know what you're doing you stop looking around for other ways of doing things and you stop being able to see other ways of doing things. You become blind.' He concludes, 'I think you have to say: "We don't know what programming is. We don't know what computing is. We don't even know what a computer is." And once you truly understand that, and once you truly believe that, then you're free, and you can think anything.'"

Comments

I knew it

[ArcadeMan]

Every time some stupid colleagues of mine told me I was doing it wrong, I kept thinking they were close-minded idiots.

Turns out, I was right all along!

Re:I knew it

[chuckinator]

That depends. Were you able to deliver on time with your method?

Re:Short version?

[oodaloop]

What, TFS wasn't short enough for you?

Hmm

[abroadwin]

Yes and no, I think.

On the one hand, it is a good thing to prevent yourself from constrained thinking. I work with someone who thinks exclusively in design patterns; it leads to some solid code, in many cases, but it's also sometimes a detriment to his work (overcomplicated designs, patterns used for the sake of patterns).

Unlearning all we have figured out in computer science is silly, though. Use the patterns and knowledge we've spend years honing, but use them as tools and not as crutches. I think as long as you look at something and accurately determine that a known pattern/language/approach is a near-optimal way to solve it, that's a good application of that pattern/language/approach. If you're cramming a solution into a pattern, though, or only using a language because it's your hammer and everything looks like a nail to you, that's bad.

Re:Hmm

[orthancstone]

Use the patterns and knowledge we've spend years honing, but use them as tools and not as crutches.

Having just watched this video a few hours ago (sat in my queue for a few days, providence seemingly was on my side to watch it right before this story popped), I can say he argues against this very idea.

He mentions late in the talk about how a generation of programmers learned very specific methods for programming, and in turn taught the next generation of programmers those methods. Because the teaching only involved known working methods and disregarded any outlying ideas, the next generation believes that all programming problems have been solved and therefore they never challenge the status quo.

Much of his talk references the fact that many of the "new" ideas in computing were actually discussed and implemented in the early days of programming. Multiple core processing, visual tools and interactions, and higher level languages are not novel in any way; he's trying to point out that the earliest programmers had these ideas too, but we ignored or forgot them due to circumstances. For example, it is difficult to break out of the single processing pipeline mold when one company is dominating the CPU market by pushing out faster and faster units that excel at exactly that kind of processing.

While TFS hits on the point at hand (don't rest on your laurels), it is worth noting that the talk is trying to emphasize open mindedness towards approaches to programming. While that kind of philosophical take is certainly a bit broad (most employers would rather you produce work than redesign every input system in the office), it is important that innovation still be emphasized. I would direct folks to look at the Etsy "Code as Craft" blog as an example of folks that are taking varying approaches to solving problems by being creative and innovating instead of simply applying all the known "best practices" on the market.

I suppose that final comment better elaborates this talk in my mind: Don't rely on "best practices" as if they are the best solution to all programming problems.

Re:Hmm

[Kal Zekdor]

Much of his talk references the fact that many of the "new" ideas in computing were actually discussed and implemented in the early days of programming. Multiple core processing, visual tools and interactions, and higher level languages are not novel in any way; he's trying to point out that the earliest programmers had these ideas too, but we ignored or forgot them due to circumstances. For example, it is difficult to break out of the single processing pipeline mold when one company is dominating the CPU market by pushing out faster and faster units that excel at exactly that kind of processing..

I can attest to this. The phrase "Everything old is new again." (Or "All of this has happened before, and all of this will happen again." for you BSG fans) is uttered so frequently in our office that we might as well emblazon it on the door. It's almost eerie how well some of the ideas from the mainframe era fit into the cloud computing ecosystem.

Re:Hmm

[jythie]

As with so many things, it is a matter of balance. We now have what, 60 years or so of computer science under our collective belts, and there are a lot of good lessons learned in that time... but on the down side most people only know (or choose to see) a subset of that knowledge and over apply some particular way of doing things,.. then they get promoted, and whatever subculture within CS they like becomes the dogma for where they work.

Re:Hmm

[TsuruchiBrian]

Designs are only complicated when they are unique. If I write my own LinkedHashMap to store 2 values, it is overcomplicated. If I just invoke a standard java LinkedHashMap to store 2 values, then it's the same design, but since everyone knows what a java LinkedHashMap does, it is simple. Also It can be swapped out for a simple array with relative ease if the code is designed in a way that is maintainable.

Even if you are using design patterns, you should be leveraging not just the knowledge that other people have acquired, but also the APIS and routines available in libraries. This way switching your program from using a simple design to a complicated design patter is easy.

It shouldn't matter that you are using an overly fancy tool to solve a job that can be solved by a simple tool. Electrons are free. What isn't free is human time and effort. So just be sure not to design your application in a way that makes it hard to change.

Re:Hmm

[timeOday]

Much of his talk references the fact that many of the "new" ideas in computing were actually discussed and implemented in the early days of programming. Multiple core processing, visual tools and interactions, and higher level languages are not novel in any way; he's trying to point out that the earliest programmers had these ideas too, but we ignored or forgot them due to circumstances.

So what's the point? They want a cookie? They want people not to use these concepts even now that they are viable because they are not original enough? That industry must have been wrong to take sequential processing to the limit before taking on the extra complexity of parallelism?

The only prescriptive takeaway I see here that people shouldn't be afraid to innovate. Were they?

Re:Hmm

[sjames]

Only sometimes. As soon as your sledgehammer to squash a gnat has to interoperate with anything else, it becomes bloat. Possibly overcomplicated and error-prone bloat. In those cases, you might have been better off with a custom format that isn't overkill.

Re:Hmm

[TsuruchiBrian]

Custom flyswatters are almost always more error prone than widely used sledgehammers. Yes they are more bloated, but whether that matters depends on whether you are using 1 sledgehammer to swat a fly or a billion sledge hammers to swat a billion flies.

In any case, my point was not that we should be using sledge hammers to swat flies. My 2 points were that we should be using widely (thoroughly tested) tools rather than custom solutions, and if we anticipate the possibility of needing to swat a billion flies, using a tool that efficiently swats a billion flies, even if it swats 1 fly inefficiently (i.e. I am advocating scalability)

For example: Looking up 1 item in a linkedhashmap of 2 items is inefficient compared to checking 2 items in an array, but it doesn't matter because the difference is only a few clock cycles. Even if we never add the 1 billion items we thought we might, the worst case is not that bad. If we keep the array, the best case (only 1 item) is really fast, but the worst case (a billion items) is *really* slow. In this case the bloated software is either a little slower or *way* faster depending on how many items are in the container. That's the kind of bloat I can live with (i.e. I can't live with all kinds of bloat)

Re:Hmm

[sjames]

I'm talking about once it gets on the wire. When you want to interoperate, would you rather pares:

name\tdept\n

or

32K of XML that provides the same information.

There's probably something that automagically converts your hash into the XML based crap (probably with a binary blob thrown in just to make sure you get no benefits from the XML at all) but the world is better off if you devote 5 lines of code to doing it right.

Re:Hmm

[TsuruchiBrian]

Once it goes on the wire the format of data should be defined by a specification. That in itself is a design choice. Some things require an xml/json type of design to do them right.

The amount of code that *you* have to write, should be negligible no matter how you decide to do it. There are libraries that provide quick serialization and deserialization of xml data, which is why people use it.

If you are sending data over http (how most xml/html/json data gets sent), then the overhead from http will kill just about any efficiency you get from stripping the xml from a file and sending it as a binary.

Obviously you can use xml wrong. You can use *anything* wrong.

The fact that you refer to "XML based crap" leads me to wonder whether you are just biased against XML, and would never use it even if it were the best solution to a problem.

Re:Hmm

[sjames]

You obviously don't target constrained environments very often. It doesn't matter if there's a library for it if it dwarfs the actual application in storage and memory footprint.

There are places where a more complex data representation is called for. By all means use something appropriate. I referred to XML based crap because for every appropriate use I see, there's 9 more that are totally inappropriate. I also see a LOT of XML that would be perfectly reasonable but right in the middle of it someone plops a blob of binary.

As for HTTP, note that it is actually a fairly simple protocol based on tagged fields with a colon separator and \r\n field delimiter. That's why it took off like wildfire and works to this day. The same can be said for most of the critical protocols on the net. Not a < or > in sight until you get to the payload. It is only said to have a heavy overhead because it requires polling (with or without dirty tricks like a slow response) to deal with events where raw TCP does not. The rest of the overhead issues were solved with keep-alive.

Where there is real complexity to the data that calls for a heavier representation, I prefer JSON to XML. People find WAY too many ways to make XML ambiguous. It has the additional advantage that it grew up with realistic expectations while XML was the next great scheme to make everything automagically interoperate without even trying. That promise has come and gone several times and never worked out (naturally, only a genuine AI could make that work)

If it makes you feel better, I would have just as much (or more) complaint about someone trying to stuff necessarily complex data into tag:value\r\n format.

Executive summary: use the right tool for the right job.

Re:Hmm

[TsuruchiBrian]

You obviously don't target constrained environments very often. It doesn't matter if there's a library for it if it dwarfs the actual application in storage and memory footprint.

I deal with all kinds of environments from embedded systems systems with almost unlimited cores and ram.

I referred to XML based crap because for every appropriate use I see, there's 9 more that are totally inappropriate.

Which kinds of programming technologies aren't misused 90% of the time?

As for HTTP, note that it is actually a fairly simple protocol based on tagged fields with a colon separator and \r\n field delimiter. That's why it took off like wildfire and works to this day. The same can be said for most of the critical protocols on the net. Not a in sight until you get to the payload.

It's not binary. It's plaintext. What difference does which characters are the delimiters?

Where there is real complexity to the data that calls for a heavier representation, I prefer JSON to XML. People find WAY too many ways to make XML ambiguous. It has the additional advantage that it grew up with realistic expectations while XML was the next great scheme to make everything automagically interoperate without even trying.

The types of data represented by JSON and xml are basically the same. If you can find a way to make XML ambiguous, then you can find a way to make JSON ambiguous too. It seems like you just prefer colons to angle brackets for some reason.

I think XML is better than JSON, but it's not because it looks prettier or anything like that. I like it better because it has better integration with other tools like XSLT, xpath, and CSS. That's the only reason. If it weren't for that, I really wouldn't care which one I used. I thought it was kind of cool that json was executable javascript when it came out, but as it turns out it's not even safe to use it like that anyway.

It has the additional advantage that it grew up with realistic expectations while XML was the next great scheme to make everything automagically interoperate without even trying. That promise has come and gone several times and never worked out (naturally, only a genuine AI could make that work)

I don't care what some people promised XML would be able to do. It's just an encoding for hierarchical data, with some common libraries to encode and decode it. No more, no less. You don't need to take it for more than what it is.

Executive summary: use the right tool for the right job.

amen to that

Re:Hmm

[orthancstone]

The only prescriptive takeaway I see here that people shouldn't be afraid to innovate. Were they?

We've had 64 bit processors easily commercially available for over a decade and multiple core systems easily commercially available for half a decade plus. Meanwhile, many commercial code bases make little if any use of the available functionality (and part of that blame goes on the "XP 4 life!" crowd of Windows users/businesses).

I would argue that, yes, innovation is scary to many. The attempts to "modernize" often cost time and money that many business do not want to sacrifice because it interrupts the ongoing, already successful model they continue to ride.

Re:Hmm

[orthancstone]

> Don't rely on "best practices"

I would still like to have at least one person in the team that is aware of the best practices, so the team does not end up using worst practices while trying to do something good. The more you know, the more ideas you tend to get, but sometimes if you don''t know the answer, you might invent something that is better than before.

Certainly, and I don't think the speaker would argue against that kind of prudent behavior. But if all you've got at the table are a bunch of yes men nodding their heads in agreement with whatever prescribed method is listed from the manual, you likely will stagnate rather than innovate.

Re:Hmm

[sjames]

Which kinds of programming technologies aren't misused 90% of the time?

yes, many technologies are misused and abused. Most of them are only a problem for the programmer and the unfortunate person that inherits the code. Data interchange can multiply the misery, so needs special consideration.

It's not binary. It's plaintext. What difference does which characters are the delimiters?

Of course it's not binary. I certainly never said it was. What it is is just complex enough to get the job done. It is vastly superior to XML in that it is impossible to make it defy human readability without also breaking the standard. You can't mush it all together so that it looks like line noise without breaking it. You can't screw up by leaving unclosed tags without it being very obvious at a glance.

Yes, JSON and XML can encode the same structured data. However, unlike JSON, XML frequently can't decide if the value is an attribute of a tag or if the tag encapsulates the value. I have seen (too often) programs vomiting out XML that mixes the approaches depending ion which member of the team wrote the object being dumped. It seems better not to offer the ambiguity in the first place.

JSON has excellent integration w/ javascript for transforming the data into presentation in the browser (where it needs to happen anyway). It just happens that the turing-complete language you use to do that isn't a one trick pony. JSON being executable is a nice feature for debugguing but I agree, one must never actually use it that way in production.

I don't care what some people promised XML would be able to do.

I wouldn't care except that when such outlandish promises have been made, people try to actually do those things or perhaps worse, actually think those things are actually already done, and that's where the trouble starts. Understanding of the limitations of a technique or technology is important.

Re:Hmm

[TsuruchiBrian]

You can't mush it all together so that it looks like line noise without breaking it.

{"firstName":"John","lastName":"Smith","age": 25,"address": {"streetAddress": "21 2nd Street","city":"New York","state": "NY","postalCode": 10021},"phoneNumbers": [{"type": "home","number": "212 555-1234"},{"type": "fax","number": "646 555-4567"}]}

You can't screw up by leaving unclosed tags without it being very obvious at a glance.

Did I leave out any ending tags (e.g. } ] ) in that JSON code? I don't think I did, but who knows. I guess you just have to let the computer figure that out.

I have seen (too often) programs vomiting out XML that mixes the approaches depending ion which member of the team wrote the object being dumped. It seems better not to offer the ambiguity in the first place.

I hope you aren't saying this isn't a problem with JSON...

I agree with you about removing superfluous choices from programmers, but I also think giving people good choices prevents them from needing to use a hammer for everything. Maybe XML has more choices in general. Like with other languages with more power, you need to put forth some more self control when using them.

There are XML style guides just like there are C++ and java style guides. I have yet to see a language that inherently prevent people from writing bad code.

I am not in love with having 2 ways of representing data in XML (child nodes vs. attributes), but I have learned to use it in a way I find acceptable. I use attributes for anything that there should only be one of. and child nodes for anything that might be a list or has sub properties. This makes my XML code pretty attribute heavy compared with other people, but whatever.

Re:Hmm

[sjames]

{"firstName":"John","lastName":"Smith","age": 25,"address": {"streetAddress": "21 2nd Street","city":"New York","state": "NY","postalCode": 10021},"phoneNumbers": [{"type": "home","number": "212 555-1234"},{"type": "fax","number": "646 555-4567"}]}

Exactly. I'm absolutely certain that if you try to use that as an http request, it will fail (sure enough: 501 Method Not Implemented). meanwhile, even mushed up like that, I find that it defies reading a lot less than xml would, though judicious use of tab and newline would be appreciated.

In XML I have seen <name value='John'/> as well as <name>John</name> I don't see the JSON equivilent.

You missed that I only think JSON should ONLY be used if the data being represented is too complex for something simple like the HTTP header. If it can be represented in a simpler way, it should be.

Re:Hmm

[TsuruchiBrian]

I'm absolutely certain that if you try to use that as an http request, it will fail (sure enough: 501 Method Not Implemented).

It was just a wikipedia json structure with whitespace removed. Not an http request.

In XML I have seen <name value='John'/> as well as <name>John</name> I don't see the JSON equivilent.

{"name" : "John"} == <name value='John'/>

{"name" : ["John"] } == <name>John</name>

Re:Hmm

[sjames]

If only that was followed. I frequently see the <name>John</name> for where there is certainly NOT a list and never will be a list. That's because XML is quite ambiguous about that in practice. Note how JSON effectively conveys list vs simple data and string vs. numeric unambiguously.

As for the first part, I was talking about http (a simple representation for a simple data structure) and you replied with JSON (a less simple representation appropriate for a more complex data structure) for some reason.

Re:Hmm

[TsuruchiBrian]

As for the first part, I was talking about http (a simple representation for a simple data structure) and you replied with JSON (a less simple representation appropriate for a more complex data structure) for some reason.

You said:

Exactly. I'm absolutely certain that if you try to use that as an http request, it will fail (sure enough: 501 Method Not Implemented).

in response to the JSON I posted... so I thought you were trying to use the JSON as an HTTP header.

If only that was followed. I frequently see the John for where there is certainly NOT a list and never will be a list. That's because XML is quite ambiguous about that in practice. Note how JSON effectively conveys list vs simple data and string vs. numeric unambiguously.

Yes people use XML in a way that makes it a pain to deal with. In this example I agree people are more likely to do <name>John</name> than "name" : ["John"], but that is sort of incidental. People *could* do the JSON wrong too. They just don't. That's not a problem with XML but rather they way people use it (i.e. bad traditions, or lack of good traditions).

But there is stuff that looks nicer in xml than JSON, like text formatting.

<name>John <i>Italics <b>and Bold</b> </i> Smith</name>

looks a lot better than

{ "name" : [ {"text" : "John"}, {"i" : [ {"text" : "Italics" }, {"b" : [ { "text" : "and Bold" } ] } ] }, {"text" : "Smith"} ] }

I think each encoding has it's strengths and weaknesses.

Re:Hmm

[sjames]

Yes people use XML in a way that makes it a pain to deal with. In this example I agree people are more likely to do John than "name" : ["John"], but that is sort of incidental. People *could* do the JSON wrong too. They just don't.

if people do one wrong frequently and get the other right, it's probably a matter of the first being a faulty tool or a faulty culture has built uop around it. Either way, it''s an argument in favor of using the tool people get right.

John Italics and Bold Smith looks a lot better than { "name" : [ {"text" : "John"}, {"i" : [ {"text" : "Italics" }, {"b" : [ { "text" : "and Bold" } ] } ] }, {"text" : "Smith"} ] }

That's because JSON is a format for data exchange and you're trying to shoehorn presentation into it. If you want presentation, map it to HTML/CSS. Again, it's about using the right tool rather than sledgehammering gnats.

Re:Hmm

[TsuruchiBrian]

if people do one wrong frequently and get the other right, it's probably a matter of the first being a faulty tool or a faulty culture has built uop around it. Either way, it''s an argument in favor of using the tool people get right.

Yes I agree the culture is faulty, but I don't think that's necessarily a reason to abandon XML over trying to fix the culture. Even if everyone only used JSON for new projects, there is still a lot of XML out there that should be used correctly. We should be encouraging people to use every tool correctly.

That's because JSON is a format for data exchange and you're trying to shoehorn presentation into it. If you want presentation, map it to HTML/CSS. Again, it's about using the right tool rather than sledgehammering gnats.

HTML and XML are basically the same scheme. Even if I use CSS to do the display part, the HTML/XML needs to hold the data of the document. Yeah I used bold and italics tags in there, but even if I wanted to use CSS to do bold and italics, I would need for those special text sections to have their own classes/ids in order to modify them with CSS. That data needs to be stored somehow, and in this case I think XML is a better storage mechanism than JSON, even though JSON can do it.

Re:Hmm

[sjames]

It is still presentation. I agree, JSON isn't the right tool to store presentation, that's what HTML/CSS is for. XML is a superfluous superset of HTML in that case (or if you prefer, HTML is a more pertinent subset of XML).

Would you happen to be an InfoSys trainer?

[xxxJonBoyxxx]

>> We don't know what programming is. We don't know what computing is. We don't even know what a computer is.

Aha - they found the guy who trains InfoSys employees.

70s yeah right!

[rvw]

The future of programming, from the seventies, it's all hippie talk...

"We don't know what programming is. We don't know what computing is. We don't even know what a computer is." And once you truly understand that, and once you truly believe that, then you're free, and you can think anything.'"

Next thing we can throw our chairs out and sit on the carpet with long hair, smoke weed and drink beer....

Re:70s yeah right!

[Zero__Kelvin]

"Next thing we can throw our chairs out and sit on the carpet with long hair, smoke weed and drink beer...."

If you aren't doing it that way already, then you're doing it wrong.

Re:70s yeah right!

[rotaryexpress]

So...Steve Ballmer got part of it right? I mean, throwing chair's is his specialty right?

Re:70s yeah right!

[phantomfive]

The future of programming, from the seventies, it's all hippie talk...

What you don't understand is, in ~1980 with the minicomputer, Computer Engineering got set back decades. Programmers were programming with toggle switches, then stepped up to assembly, then started programming with with higher level languages (like C). By the 90s objects started being used which brought the programming world back to 1967 (Simula). Now mainstream languages are starting to get first-class functions. What a concept, where has that been heard before?

Pretty near every programming idea that you use daily was invented by the 80s. And there are plenty of good ideas that were invented back then that still don't get used much.

My two favorite underused (old) programming ideas:

Design by contract.
Literate programming.

If those two concepts caught on, the programming world would be 10 times better.

Re:70s yeah right!

[DamonHD]

I did an entire thesis with Tangle and Weave, and I'm glad that I did, but I'm not convinced that a narrative exposition is any better than the more random-access style that a hierarchical directory layout with some decent (embedded and out-of-line) documentation and viewer IDE does.

Rgds

Damon

Re:70s yeah right!

[DutchUncle]

In college in the 1970s, I had to read the Multics documents and von Neumann's publications. We're still reinventing things that some very clever people spent a lot of time thinking about - and solving - in the 1960s. It's great that we have the computer power and memory and graphics to just throw resources at things and make them work, but imagine how much we could make those resources achieve if we used them with the attitude those people had towards their *limited* resources. And we have exactly the same sets of bottlenecks and tradeoffs; we just move the balance around as the hardware changes. Old ideas often aren't *wrong*, they're just no longer appropriate - until the balance of tradeoffs comes around again, at which point those same ideas are right again, or at least useful as the basis for new improved ideas.

Re:70s yeah right!

[murdocj]

Speaking of setting programming back, the current push in languages to get rid of declaring types of variables and parameters has set us back a few decades. In languages like Ruby, you can't say ANYTHING about your code without executing it. You have no idea what type of objects methods receive or return, whether formal and actual parameters match, or whether types are compatible in expressions, etc. I actually like a lot of aspects of Ruby, but it seems like it's thrown about 50 years of improvement in programming language development.

Re:70s yeah right!

[jbolden]

Design by contract is my favorite way of handling interfaces. It really is a good idea.

Literate programming though I'm not sure if I see much point to. There are cool examples like mathematica notebooks but in general even very good implementation like Perl's POD and Haskell's literate mode just don't seem to offer all that much over normative source code. API documentation just doesn't need to be that closely tied to the underlying source and the source documentation just doesn't need to be literate.

As for your 1990s and Objects. I also disagree. Objects were used for implicit parallelism and complex flow of control. No one had flow of controls like a typical GUI to deal with in 1967. Event programming was a hard problem solved well.

As for PC's pushing back languages in general. I'd agree. Same way mobile is doing now by forcing people to think about writing programs to minimize electrical usage they are having to deal with low level details again.

Re:70s yeah right!

[jbolden]

Ruby is actually rather strongly typed. Shell is far more like what you are describing.

Re:70s yeah right!

[Shados]

I'm a static language guy myself, but its important to keep in mind that different problems have different solutions.

Doing heavy image processing or transnational operations, number crunching, I/O with third party APIs, etc? Yeah, static languages are probably better.

Doing prototyping, or UI intensive work? Most UI frameworks suck, but the ones designed for static languages generally suck more, because some stuff just can't be done (well), so they have to rely on data binding expressions, strings, etc, that are out control of the language. At least dynamic languages deal with those like they deal with everything else and have them as first class concepts.

Case in point: an arbitrary JSON string, in a dynamic language, can be converted to any standard object without needing to know what it will look like ahead of time. In a static language, you either need a predesigned contract, or you need a mess of a data structure full of strings that won't be statically checked, so you're back at square one. These type of use cases are horribly common in UI.

Re:70s yeah right!

[murdocj]

Yes and no. It's true that objects have classes, but that's entirely malleable, and there's no way to look at a particular piece of Ruby code and have any idea what class an object has, unless you actually see it being created (yes, yes, even then you don't know because classes can be modified on the fly, but let's ignore that for the moment). Basically, I can't look at a method and do anything except guess what parameters it takes. Personally, I think that's a bad thing.

Re:70s yeah right!

[SuricouRaven]

I dabble in image processing algorithms. A lot of the things I write for my own use end up being a C program to do the serious number crunching, with a perl script for the interface. Perl does all the pretty work, then just calls upon the compiled executable when serious performance is required.

Re:70s yeah right!

[Greyfox]

You still need to know what your JSON string will look like at some point in order to use it. It's always (for at least as long as I've been programming, a bit over 2 decades) been a problem that programmers don't fully know or understand their requirements, so they try to keep their code as generic as possible. The problem with that is that at some point you're going to have to do actual work with that code, so you end going through a labyrinth of libraries, none of which want to take the responsibility to actually do anything. All because they thought they might want to use that library for something else at some point. When design patterns guys/agile guys talk about "you aren't going to need it," this is what they're talking about. Code things you need right now and let the future sort itself out.

I was just talking to a guy today who's in the process of writing an entire fucking rest framework in C++ for an embedded system because his clients think they might want a fucking pony at some point in the future. Sure, they could just get some concrete requirements for what they need right now and design a system that will be smaller, faster and better than what he's building. Doesn't seem like anyone stopped to think about that.

Re:70s yeah right!

[lgw]

You ssem to be saying that using strings - and thus bypassing the static type checking of a static language - is worse that using a language with no static type checking in the first place. I don't see that at all.

Either you're fine with not knowing what the object looks like ahead of time - in which case you can't directly reference member names in any case, and strings are far better than reflection - or you have a specific subset of the object that you understand and needs to be how you expect it to be, and just want to ignore the rest - a partial contact (or contract for subset). The worst evil IMO is deserializers that don't let you ignore what you don't understand. That really kills you in a statically typed language, but it's a library problem not a language problem. My ideal is interacting with a statically typed object that represents only the subset of the JSON (or whatever) that I must understand, and blissful ignorance of the rest of it. Far too many libraries don't let you do that. Heck, I prefer binary protocols that work that way over JSON, but too many these day's don't even understand that's possible, let alone how to do it.

Re:70s yeah right!

[Shados]

Dynamic languages have better support for introspection, handling what happens when a property is missing, dealing with objects that aren't QUITE the same but "close enough", and deep nested dynamic data structures.

If you want to represent the same things in a static languages, you need things like arbitrarily nested dictionaries or very complex data structure with meta data. Thats why to handle a JSON string in Java or .NET, you'll need a JSON object framework. The parsing is the trivial part.

I also won't be able to use these JSON objects as real objects, with inheritance chains, polymorphic, etc, without a lot of work. If you're, let say, in javascript, and you parse a json string into an object with an appropriate prototype, you get all of it without needing to look at the data. Then your methods can do all the introspection to do the "magic".

That, again, comes in handy when dealing with object representations of arbitrary UI elements, and thats not limited to the web (WPF, Cocoa, or any other UI framework that use resource files of some kind to represent widgets).

So let say I only care about a specific part of my UI object tree... but I don't know -where- in my UI that part is. It could be arbitrarily nested, it could be dynamically added, IT COULD BY ADDED VIA A DIFFERENT PROGRAMMING LANGUAGE AT RUNTIME... It could be skinned with mixins.... You can deal with that in a static language (again, all the static languages UI frameworks do it). Its just a god damn clusterfuck.

Another example is invoking APIs written in a functional static programming language from a non-functional one. You can't just "serialize the part you care about" when you're dealing with actual code as opposed to serialized stuff. Then you end up with a mess of nested generics (or whatever the interface between the two languages look like). Not fun.

Don't get me wrong. These are very small subset of requirements, but when you hit them, reflection, attributes or meta programming is just not cutting it anymore. For everything else, static languages ftw.

Re:70s yeah right!

[Shados]

Maybe you do need to know, maybe you don't. Maybe the object is being introspected, maybe its used to feed to a template engine, maybe its just converted from one format to another. All these things can be done in any language. Some languages make it easier than others.

Static languages make structured stuff easy and dynamic stuff hard(er). Dynamic languages make dynamic stuff easier. Shocker, i know.

Re:70s yeah right!

[phantomfive]

If your unit tests have good code coverage this will not be a problem.

Re:70s yeah right!

[phantomfive]

Literate programming has two benefits: the idea that your program should be written more for another human to read instead of for a computer; and to make it obvious to a human the structure of your program. If you fulfill these you are doing literate programming.

As for your 1990s and Objects. I also disagree. Objects were used for implicit parallelism and complex flow of control. No one had flow of controls like a typical GUI to deal with in 1967. Event programming was a hard problem solved well.

I don't understand what relationship 1990s, objects, and implicit parallelism have to do with each other, you'll have to explain it more clearly. But the complex flow required by an OS managing multiple resources is significantly more difficult than a typical GUI.

Re:70s yeah right!

[fsterman]

imagine how much we could make those resources achieve if we used them with the attitude those people had towards their *limited* resources.

We would gain nothing, hell we would still have god-damn teletype machines if everyone was worried about wasting nanoseconds of compute time. We would get some multiple of compute increase but we would loose out on the exponential increases in human productivity that comes from dealing with all of those abstractions automatically.

But I think we agree in that we need to focus on fixing the problems that need fixing. It's more important to figure out what you need done and then figure out whether you will hand-craft machine code or whip-up some javascript hack.

Ahh, engineering!

Re:70s yeah right!

[jbolden]

That I agree with. Ruby is strongly typed with very aggressive and implicit type conversions. Anyway, strongly typed languages are dominant: C++, C#, Java; so it would make sense the alternatives are dynamic. Moreover scripting has always been dynamic.

I can understand the virtues of strongly typed. IMHO dynamic typing works best in programs under 20 lines of code, works OK 20-1000 and starts to fall apart after 1000. Most Ruby programs are under 1000 lines.

Re:70s yeah right!

[phantomfive]

I consider the important elements of literate programming to be: the idea that you are writing for a human, rather than for a computer; and making the structure of the program clear to other humans, rather than what's best for the compiler. If you do these, than I would say that you are doing literate programming.

If you have any other ideas on the topic I'd be interested in hearing them.

Re:70s yeah right!

[jbolden]

I understand the ideas behind it. But I'm not sure why understanding the structure of the program matters much. If it does, throw a few paragraphs in about the structure or include a doc to the side.

I don't understand what relationship 1990s, objects, and implicit parallelism have to do with each other, you'll have to explain it more clearly.

OK. Modern GUIs create a situation where operating systems have huge numbers of tasks lying around. Thousands and thousands of asymmetric potential threads passing messages to one another triggering actions. Some of these are the events triggered by the human others are programs kicking off events for later. Object Oriented programming guaranteed that Objects mostly contained their own independent memory which made this kind of implicit parallelism safe. All the data is bound to an object who owns that data and is manipulated through messaging not directly.

But the complex flow required by an OS managing multiple resources is significantly more difficult than a typical GUI.

A typically GUI OS is a designed to manage multiple resources.

Re:70s yeah right!

[phantomfive]

What GUI system are you using that has thousand and thousands of threads passing messages? I don't think you've really thought this through......all modern systems use only one thread. At a minimum the performance hit is often serious for thousands of threads. What you are describing seems to be the actor model, which was developed by the mid 70s.

I understand the ideas behind it. But I'm not sure why understanding the structure of the program matters much. If it does, throw a few paragraphs in about the structure or include a doc to the side.

Because structure is the key to understanding, in programming and literature.

Re:70s yeah right!

[jbolden]

Thousands of potential threads. And all of them OSX, Windows, KDE, Gnome. They all utilize tremendous numbers of objects able to operate with implicit parallelism. Generally in terms of execution threads some sort of thread pool is used to match actual CPUs to potential threads. In terms of modern systems using only one thread, look at any of the design of systems books that just ain't true. As for this being the actor model of concurrency. Yes it is. The event driven model's concurrency system was via. actors. The SmallTalk GUI was arguably the most explicit first use of mixing Objects and Events and the Windows designers cited this paradigm rather explicitly.
___

As for literate you aren't answering the question what the point is of the human understanding that limited amount about the program. You are just sort of asserting that limited understanding by a human is useful. That's the point in question. What value is a human's limited understanding in general? And even if it were important why not just use side documentation explicitly designed to achieve this understanding?

Re:70s yeah right!

[murdocj]

Well, it's a problem if I'm trying to actually read the code and understand what it does and what arguments it takes. Not to mention the wasted time when I pass the wrong argument type to a method and the problem doesn't show up until runtime. And god forbid that it's Ruby code using "method_missing", then I'm really screwed in so may ways it's hard to imagine. For example, in a Rails app you want to see if you are in the development environment:

if Rails.env.dev?

and that runs just fine... but ALWAYS returns false, because there is no "dev" environment, you should have said "development". It's so dynamic that it "works" even when it's wrong.

Again, Ruby has some cool ideas, but it's doesn't just throw out the baby with the bath water, it boils the baby in the water, and serves up the delicious (?) soup.

Re:70s yeah right!

[DutchUncle]

Sorry, I think you missed my intent. Lots of people have pointed out how much of their hot new computer power winds up being wasted on fancy-frosted-translucent-glass GUI effects which don't actually achieve anything. Not only is that a waste of my CPU time, it's a waste of so much computing resource around the world - and equally a waste of the time and effort of presumably clever and artistic developers.

Re:70s yeah right!

[phantomfive]

Well, it's a problem if I'm trying to actually read the code and understand what it does and what arguments it takes.

Don't write code so complicated that you can't easily tell what type is needed from inspection. Seriously, these are solved problems. You can write code with strong type-safety, or you can write code with runtime binding. Both are workable.

Re:70s yeah right!

[phantomfive]

As for literate you aren't answering the question what the point is of the human understanding that limited amount about the program. You are just sort of asserting that limited understanding by a human is useful.

The opposite. Literate programming makes it easier to understand programs.

In terms of modern systems using only one thread, look at any of the design of systems books that just ain't true.

Which GUI system doesn't? Swing? Openstep? .net? Android? They all use one thread.

Re:70s yeah right!

[DamonHD]

Naturally I *have* to ultimately present the program text in a form that the computer will be happy with, but I am very hot on appropriate human-centric documentation in-line and off-line, and phrases that make me spit include:

"It's self documenting."

"Oh it's hard to keep the comments in sync with the code."

Farg me!

I'm suffering on a new project from a slight lack of consideration as to what the coder following in your footsteps would need in order to understand what was intended vs what actually happened. As I fix that I can also improve the code behaviour and reliability, which happens to be critical for this application! I put lots of stuff in to make clearer to a human what is going on whether or not the compiler can deduce it, such as "final" practically everywhere possible in Java code so that the human does not have to worry about whether this, that and t'other might get changed in some non-trivial stretch of code. A little incident ~15 years ago where a coder/trader did not take care of such 'trivial' things and assumed instead cost our group $1m, for example, which I spotted when I came to tighten up the documentation and performance some time later. A little more exposition would have saved a lot of bother and cash...

I'd say that with the human-centric view (including thoughtful docs and unit tests) it's actually hard to write performant robust long-living systems, and LP was/is an interesting take on that. Good old Knuth!

I found the tangle and weave experience slightly tiresome from a purely logistical point of view, but all IDEs and so on (and the hardware to run them on) have come on in leaps and bounds, so that might simply not be an issue any more.

Re:70s yeah right!

[phantomfive]

Interesting, thanks.

Re:70s yeah right!

[lgw]

If you want to represent the same things in a static languages, you need things like arbitrarily nested dictionaries or very complex data structure with meta data. Thats why to handle a JSON string in Java or .NET, you'll need a JSON object framework. The parsing is the trivial part.

While I've seen people do that, it's often quite silly.

Usually, you can create a static object that represents what you care about, and simply ignore the rest - fast, easy, and the benefits of static type checking. People don't, of coruse, because they don't actually think about the problem.

So let say I only care about a specific part of my UI object tree... but I don't know -where- in my UI that part is. It could be arbitrarily nested, it could be dynamically added, IT COULD BY ADDED VIA A DIFFERENT PROGRAMMING LANGUAGE AT RUNTIME... It could be skinned with mixins.... You can deal with that in a static language (again, all the static languages UI frameworks do it). Its just a god damn clusterfuck.

Funny that you mention that. My home hobby coding project is a way to deal with that easily in C, because I hate the way modern ORM is done (the sticking point is just the same as your example). Once you're traversing runtime data structures unpredictable at compile time, you're conceptually traversing nested dictionaries, however that may be implemented. C is just lacking a nice friendly implementation of that concept.

Another example is invoking APIs written in a functional static programming language from a non-functional one. You can't just "serialize the part you care about" when you're dealing with actual code as opposed to serialized stuff. Then you end up with a mess of nested generics (or whatever the interface between the two languages look like). Not fun.

Been there, done that for a non-functional static programming language. It's quite easy if you actually stop and think about the problem first (but of course, all most no one does). Your static API (at the DLL boundary) is just a function that takes a serialized blob, and your actual contract (and language bindings) wrap that. Made a really handy cross-language RPC that way that made it quite reasonable to call back and forth between C# code and kernel code, but python bindings or whatever would have been just as nice.

Now I prefer a RESTful approach, where passing a serialized blob is normal and expected (and again, the contract is "one level up"). Maybe one day I'll write a nice tiny C REST server that can pass requests along to the ORM or to any-language handlers on the box.

Re:70s yeah right!

[DamonHD]

Whoops, still asleep when typing: "*I recall a pertinent* little incident..." and "I'd say that with*out* the human centric view...".

Rgds

Damon

Re:70s yeah right!

[jbolden]

.NET for sure uses multiple threads. The system maintains an entire pool of threads. The whole idea of Windows NT kernel was to allow multiple process each having multiple threads.

Re:70s yeah right!

[ultranova]

Lots of people have pointed out how much of their hot new computer power winds up being wasted on fancy-frosted-translucent-glass GUI effects which don't actually achieve anything. Not only is that a waste of my CPU time,

Aren't the GUI effects done by the GPU? Which doesn't really use any more power for frosted glass translucent blitting than just regular blitting.

Re:70s yeah right!

[phantomfive]

Not in the GUI

Re:70s yeah right!

[dkf]

IMHO dynamic typing works best in programs under 20 lines of code, works OK 20-1000 and starts to fall apart after 1000.

I know people with 10 million line scripting language programs that they use to run oil rigs. I think they're crazy to have a program that large! (In any language.)

But the real key to good practice isn't OOP so much as component-based programming where those components, and the glue between them, can be in different languages. Each component can be separately tested and has a defined interface, so that's great for robustness and scalability, and the right language for each part can be used. Every programming language implies its own set of abstractions, so using the one that has the most suitable ones for the particular problem being tackled in a component is a huge benefit, and yet the selection of abstractions is always a trade-off as you can't have them all. (Some things are just better off high-level, others low-level. And that's a simplification.) The best thing in the past 20-30 years of software engineering has been the gradual decline of the do-it-all-in-one-language dogma.

Re:70s yeah right!

[jbolden]

I agree with you do it all in one language was terrible. The big problem with systems designed in many languages is different languages have different cultures and assumptions. They also go through different cycles. Overtime it can be very difficult to handle such a system as the parts evolve.

Re:70s yeah right!

[akh]

Are you familiar with Inline::C? It lets you write Perl functions in C. The C code lives in the same file as the Perl code and is transparently compiled on an as-needed basis. Best of both worlds kind of thing. BTW, I write my image processing code the same as you: C for heavy lifting and Perl for all the rest.

Re:70s yeah right!

[Dabido]

Next thing we can throw our chairs out and sit on the carpet with long hair, smoke weed and drink beer....

So, no down sides then. :-)

Re:70s yeah right!

[sjames]

Well written code can be self-documenting. The problem is, most of the code claimed to be self-documenting is far far from it.

Re:70s yeah right!

[sjames]

We might have browsers that didn't grow to fill all available memory over a day or two.

The idea is to recognize that there's plenty of resources to do better than a teletype but that doesn't mean it's OK to use a gig of ram and 24 cores to sort a grocery list.

Re:70s yeah right!

[kermidge]

I caught that, thank you.

A friend worked for eighteen years for a large state agency in a mythical Great Lakes state, writing mostly engineering code along with benchmarking stuff for hardware acquisitions. He was, and is, nuts.

When given a new project, he'd do a rough design flowchart (!), then start writing the documentation, adding in blobs of pseudo-code to illustrate something or by way of walk-through. He'd go for days, even weeks, writing his doc, while his supervisor would be having fits. (As told by another friend who witnessed some of this.)

In all that time he delivered clean code on time and under budget. Last he heard, some twenty years later, most of his stuff is still used with but very small changes to reflect, for example, newer structural materials from contractors.

This all made a great impression upon me at the time, not in small part because he came damn close a few times to shooting me as he tried to teach me the simplest things about how to program.

I know very little and can do less, but this is one of the kinds of discussion I come here to read. Tnx.

Over-generalization error in line 4

[Zero__Kelvin]

"'The most dangerous thought that you can have as a creative person is to think that you know what you're doing,' ... 'Because once you think you know what you're doing you stop looking around for other ways of doing things and you stop being able to see other ways of doing things. You become blind.' "

Unless of course you know you know what you are doing, because you also know to never stop looking for new ways of doing things.

Re:Over-generalization error in line 4

[gweihir]

But if you know what you are doing, you still have a majority with no clue around you, in the worst case micro-managing you and destroying your productivity. I think the major differences between today and the early years of computing is that most people back then were smart, dedicated and wanted real understanding. Nowadays programmers are >90% morons or at best semi-competent.

Re:Over-generalization error in line 4

[Zero__Kelvin]

I couldn't agree with you more. My estimate has traditionally been about 80%, but I concede that I may be a bit of an optimist.

Re:Over-generalization error in line 4

[AK Marc]

Unless of course you know you know what you are doing, because you also know to never stop looking for new ways of doing things.

If you have to look for a new way to do something, then you don't know the answer, so how can you know you know what you are doing when you know you don't know the answer? When you are 100% confident in the wrong answer, you know you know what you are doing (and are wrong). If *ever* you know you know what you are doing, you don't.

Re:Over-generalization error in line 4

[gweihir]

Well, I did include the semi-competent, those that eventually do get there, with horrible code that is slow, unreliable, a resource-hog and a maintenance nightmare. Plain incompetent may indeed just be 80%. Or some current negative experiences may be coloring my view.

Re:Over-generalization error in line 4

[Zero__Kelvin]

"If you have to look for a new way to do something, then you don't know the answer,"

I'm not a big enough moron to think that there is one answer that can be called the answer. Your mileage clearly varies.

" If *ever* you know you know what you are doing, you don't."

Slashdot really needs a -1 anti-insightful option.

Epic facepalm

[girlintraining]

The most dangerous thought that you can have as a creative person is to think that you know what you're doing,' explains Victor.

Yeah. I bet Vincent Van Gogh thought he was total shit at painting, didn't know anything about paint mixing, brushes, or any of that. Look, I know what you're trying to say, Victor, but what you actually said made my brain hurt.

However, exploring new things and remembering old things are two different things. You can be good at what you do and yet still have a spark of curiousity to you and want to expand what you know. These aren't mutually exclusive. To suggest people murder their own egos in order to call themselves creative is really, really, fucking stupid.

You can, in fact, take pride in what you do, and yet be humble enough to want to learn more. It happens all the time.. at least until you're promoted to management.

Re:Epic facepalm

[DNS-and-BIND]

Well, you have to realize that the whole point of this exercise is to draw a line between "creative people" and "the other". We creative people are the good ones...those others...gosh, they're capable of violence. We good people are the correct ones, and it is not evil to look down on the humble folk. After all, what kind of creative would call himself fearful of people who can't create so much as a scrapbook unless they're following an example from youtube posted by...a creative.

Look, Vincent van Gogh is a role model emulated by creatives worldwide. The fact is, there are way too many non-creatives and they are screwing up the planet. Just imagine how much better the world would be if every member of the Tea Party suddenly disappeared overnight. Oh, we can dream....

Re:Epic facepalm

[girlintraining]

We creative people are the good ones...those others...gosh, they're capable of violence.

I don't see how the two are mutually exclusive. Oh, the creative ways I murder people in my fantasies!

After all, what kind of creative would call himself fearful of people who can't create so much as a scrapbook unless they're following an example from youtube posted by...a creative.

Depends. Are they armed with just a scrapbook and a laptop, or something more substantial?

The fact is, there are way too many non-creatives and they are screwing up the planet. Just imagine how much better the world would be if every member of the Tea Party suddenly disappeared overnight. Oh, we can dream....

A true creative doesn't want people dropping dead or disappearing... they want them doing something useful and productive so they don't have time to "screw up the planet."

Re:Epic facepalm

[Kal Zekdor]

The most dangerous thought that you can have as a creative person is to think that you know what you're doing,' explains Victor.

Yeah. I bet Vincent Van Gogh thought he was total shit at painting, didn't know anything about paint mixing, brushes, or any of that.

Um... yes actually. Van Gogh actually only sold one painting in his entire life, and he considered himself somewhat of a failure as a painter. He did not become famous until after his death.

Re:Epic facepalm

[Quila]

When I was doing design work, my mentor taught me the rules and told me to stay within them. After you've mastered the rules, learning the successes and mistakes of everybody before, then you can start breaking them as you explore new possibilities.

I am afraid this will convince people who know nothing yet to just go off in whatever direction they please, wasting massive time on things others already learned not to do, subjecting others to more horrible code.

Re:Epic facepalm

[AK Marc]

Yeah. I bet Vincent Van Gogh thought he was total shit at painting,

He probably did. He died a commercial failure. Critic reviews at the time were very critical of his work.

Re:Epic facepalm

[Anonymous Coward]

A true creative person doesn't say things like "A true creative person does X," because that imposes a restriction on future interpretations of "a true creative person" and destroys creativity.

Re:Epic facepalm

[Trifthen]

That's guaranteed to happen. The only question is the extent. There's bound to be a few who say, "Hey! I don't have to know what I'm doing. That one guy said so!" In reality, we know different. Progress is made by learning from the mistakes of others. :)

Re:Epic facepalm

[lgw]

A true creative doesn't want

Would you please stop abusing the English language so roughly? What did it ever do to you? I'm sure it's very sorry, and wishes you would just stop hurting it like this.

Seriously, this is worse that mixing up lose and loose, because you're doing it on purpose.

Re:Epic facepalm

[Luna Argenteus]

I also bet that you only read the summary.
http://worrydream.com/dbx/

Re:Epic facepalm

[girlintraining]

Um... yes actually. Van Gogh actually only sold one painting in his entire life, and he considered himself somewhat of a failure as a painter. He did not become famous until after his death.

He considered himself a failure commercially... Because he was. He never stopped painting. That's fairly compelling evidence he knew he didn't suck... and that it was the world that was wrong, not him.

Just because you're bad at business doesn't mean you're bad at what you do. I know, I know... it's hard for people these days to understand that, but 'tis true.

Re:Epic facepalm

[Kal Zekdor]

Um... yes actually. Van Gogh actually only sold one painting in his entire life, and he considered himself somewhat of a failure as a painter. He did not become famous until after his death.

He considered himself a failure commercially... Because he was. He never stopped painting. That's fairly compelling evidence he knew he didn't suck... and that it was the world that was wrong, not him.

Just because you're bad at business doesn't mean you're bad at what you do. I know, I know... it's hard for people these days to understand that, but 'tis true.

Van Gogh was notoriously depressed. His entire career as an artist was little more than five years, ending with his suicide in 1890. The nature of his work changed dramatically at a rapid pace, pieces from a year before could almost be from another artist entirely. This all suggests that he was never truly satisfied with his works. It has nothing to do with the lack of financial success, but rather the lack of acceptance from his peers, who often derided him. He continued painting, not because he thought he was good at it, but because he wanted to get better.

Re:Epic facepalm

[Samantha Wright]

Massively out of context. The quote is about how people have been taught to assume procedural programming is the only way of programming. The point is that creative people are being limited by these mistaken assumptions.

Re:Epic facepalm

[Anonymous Coward]

Creativity is a natural process. Does wanting even come into it?
You do what you feel it is right to do. That is your creative process.

And is this Captcha smart or something? Seems like it's got a learning process going on...hopefully it won't crash when someone tries to create an infinite loop...

captcha: contain

Time for real apprenticeships in tech and not year

[Joe_Dragon]

Time for real apprenticeships in tech and not years of theory?

Re:Open the blinds

[robot256]

This is why no one ever reads patents before violating them. *ducks*

Re:Short version?

[Java Pimp]

Summary of TFS: There is no spoon.

Patents

[Diss Champ]

One reason I had so many patents relatively early in my career is I wound up doing hardware design in a much different area than I had planned on in school. I did not know the normal way to do things. So I figured out ways to do things.
Sometimes I wound up doing stuff normally but it took longer, this was OK as a bit of a learning curve was expected (they hired me knowing I didn't know the area yet).
Sometimes I did things a bit less efficiently than ideal, though this was usually fixed in design reviews.
But sometimes I came up with something novel, and after checking with more experienced folks to make sure it was novel, patented it.

A decade later, I know how a way to do pretty much everything I need to do, and get a lot less patents. But I finish my designs a lot faster:).

You need people who don't know that something isn't possible to advance the state of the art, but you also need people who know the lessons of the past to get things done quickly.

Wow man

[jackjumper]

I need some more bong hits to fully consider this

Re:Short version?

[Alwin Henseler]

You must be new here. That "pretentious philosophical BS" is like the spark in a fuel-and-oxygen filled chamber. It ignites into a heap of comments, and those comments are the actual story. Who needs an article when you can browse +5 funny / informative / interesting and -1 trolls?

As for the linked articles, that's just a cleverly disguised DDoS botnet setup. Some figured it out, but few seem to care the /. botnet is still operating. Heck, I'm even contributing people-time to it (on top of CPU cycles).

Become One with the WTF

[Trifthen]

'I think you have to say: "We don't know what programming is. We don't know what computing is. We don't even know what a computer is." And once you truly understand that, and once you truly believe that, then you're free, and you can think anything.'

I agree having an open mind is a good thing. There is, of course, taking things too far. Just throw away everything we've spent the last 40-50 years developing? Is there some magical aura we should tap into, and rock back and forth absorbing instead? Should we hum esoteric tantras under the enlightening influence of various chemical enhancements awaiting Computing Zen?

Someone watched The Matrix one too many times. There is no spoon!

Re:Become One with the WTF

[phantomfive]

We don't even know what a computer is.

Think of it like this. If you believe you already know what a computer is, then you are not likely to look for alternatives. If you're looking for alternatives, then you might come up with something interesting like this. If you just accept that super-scalar pipelines, the way Intel does it, is the best way, then you're not going to find a different, potentially better way of doing it.

Re:Become One with the WTF

[Trifthen]

Far from it. I seem to recall a researcher I read about over a decade ago who was designing a chip that worked more like a human neuron. Superscalar pipelines is just how Intel does instructions, and even they're trying to get away from it due to the cost of cache misses becoming more expensive as pipeline lengths increase. Having a talk on not being constrained to accepted dogma, and outright throwing away all known concepts are completely different things.

The very fact that you and I can even have this conversation, is because we know what those things mean. We know they've been tried. We know their limitations and strengths. We know there are alternatives. Having a strong grounding makes it possible to progress, even through occasional setbacks. Standing on the shoulders of giants, and all that. Throwing away everything you know and starting from scratch is very romantic, but it isn't very practical if you want to collaborate with others.

Re:Become One with the WTF

[lgw]

From TFA

It's possible to misinterpret what I'm saying here. When I talk about not knowing what you're doing, I'm arguing against "expertise", a feeling of mastery that traps you in a particular way of thinking.

But I want to be clear -- I am not advocating ignorance. Instead, I'm suggesting a kind of informed skepticism, a kind of humility.

Ignorance is remaining willfully unaware of the existing base of knowledge in a field, proudly jumping in and stumbling around. This approach is fashionable in certain hacker/maker circles today, and it's poison.

Knowledge is essential. Past ideas are essential. Knowledge and ideas that have coalesced into theory is one of the most beautiful creations of the human race. Without Maxwell's equations, you can spend a lifetime fiddling with radio waves and never invent radar. Without dynamic programming, you can code for days and not even build a sudoku solver.

It's good to learn how to do something. It's better to learn many ways of doing something. But it's best to learn all these ways as suggestions or hints. Not truth.

Learn tools, and use tools, but don't accept tools. Always distrust them; always be alert for alternative ways of thinking. This is what I mean by avoiding the conviction that you "know what you're doing".

Does that sound better?

All I know about 1973 ..

[bAdministrator]

.. is that C was seen as a major setback by Frances E. Allen and others.

It [C] was a huge setback for--in my opinion--languages and compilers, and the ability to deliver performance, easily, to the user.

Source:
Frances E. Allen
ACM 2006 Conference
http://www.youtube.com/watch?v=NjoU-MjCws4

The context here surrounds abstractions and not allowing users (programmers) to play with pointers directly (C, and later, C++), which is a setback concerning optimization, because of the assumptions/connections you make about/with the underlying machine.

If you want to learn more about the ideas of the 1960s and 1970s, I highly recommend looking up talks by Alan C. Kay ("machine OOP" which is Smalltalk in a nutshell), Carl Hewitt (actor model), Dan Ingalls, Frances E. Allen (programming language abstractions and optimization), Barbara Liskov ("data OOP" which is C++ in a nutshell), and don't stop there.

Re:All I know about 1973 ..

[phantomfive]

I highly recommend looking up talks by Alan C. Kay ("machine OOP" which is Smalltalk in a nutshell),

Do you have a specific talk in mind here? This sounds fascinating.

Re:All I know about 1973 ..

[bAdministrator]

The thing to get here is that there are basically two kinds of OOP, so to speak.

Here's a short discussion that covers it:
https://news.ycombinator.com/item?id=2336444

In Alan Kay land objects are sub-computers that receive messages from other sub-computers. In Barbara Liskov world objects are abstract data with operators and a hidden representation.

Kay OOP is closely related to the actor model by Carl Hewitt and others.

Liskov had her own idea of OOP, and she was not aware of Smalltalk (Kay, Ingalls) at the time. She started work on her own language, CLU, at the same time as Smalltalk was developed.

Re:All I know about 1973 ..

[lgw]

Sure, if you're doing high level programming (and plenty were in the 70s just as today), C is a bad tool. If you're writing an I/O driver and the hardware works though updates to specific memory addresses, well, you need to be aware of pointers.

I see the biggest failing of C itself was this notion of "int", where you don't know how many bits that is. If you're writing the kind of code that belongs in C, you have to know that, and endless 16-32 and 32-64 bit porting nightmares were the result. It wasn't until C99 that int32_t became standard.

The mistake was mistaking "you can write a program that will compile for all platforms" for "your program will do what you expect on all platforms for which it compiles". The latter being rather more useful.

Re:All I know about 1973 ..

[Wootery]

If you're writing the kind of code that belongs in C, you have to know that, and endless 16-32 and 32-64 bit porting nightmares were the result. It wasn't until C99 that int32_t became standard.

I've always suspected (and I could certainly be wrong) the main cause of 32/64-bit pain is not actually that the programmer can't (or rather, shouldn't) depend on the limits of the fixed-point primitive types, but instead that programmers stupidly assume things like "an int will always be wide enough to hold the value of a pointer". C being over-lenient with implicit-casts is largely to blame, of course.

The mistake was mistaking "you can write a program that will compile for all platforms" for "your program will do what you expect on all platforms for which it compiles". The latter being rather more useful.

You're ignoring the reason C went the way it does: performance. 'int' can translate to whatever is fastest, not whatever the spec demands (like in Java, say). It's a tradeoff, and as C is a language which puts speed over just about anything else, I can't fault their decision there.

That's not to say int32_t shouldn't have been there from the beginning, mind. We can 'have it all', in this case.

Re:All I know about 1973 ..

[bAdministrator]

You're ignoring the reason C went the way it does: performance. 'int' can translate to whatever is fastest, not whatever the spec demands (like in Java, say). It's a tradeoff, and as C is a language which puts speed over just about anything else, I can't fault their decision there.

C actually makes it a lot harder to produce the best, optimized code, because the language constructs are too closely tied to the machine domain. An optimizing compiler has less leeway in how it can re-arrange and streamline the logic to reach the goal.

Re:All I know about 1973 ..

[bAdministrator]

Only the compiler/bridge needs to know about the physical resources you work with. The user only needs a model of the hardware to work with. The compiler/bridge should then be able to produce the optimal code with no language overhead. Unfortunately, the way software is done today is still very ad hoc. There is little or no state modelling so you could map out or simulate what happens with the resources. We'd need model representations for all the hardware.

Re:All I know about 1973 ..

[lgw]

In C99 this is called int_fast32_t: give me the fastest size that holds at least 32 bits. That's what was needed all along - well, with a shorter, less obnoxious name. If I'm counting higher that 2^16, I just don't care how fast that 16 bit int is, my program will fail mightily. But if you can do 64-bits faster than 32-bits, maybe that's OK.

Re:All I know about 1973 ..

[Wootery]

the language constructs are too closely tied to the machine domain. An optimizing compiler has less leeway in how it can re-arrange and streamline the logic to reach the goal.

Well no, not in this instance. You're right that, say, the way C forbids rearranging of structs (a restriction intended to make it predictable for very low-level work) can hurt performance, but in the topic we're discussing C is actually less strict that most languages; the compiler is free to choose whether 'int' means a 32 bit or 64 bit fixed-point type.

Re:All I know about 1973 ..

[Wootery]

In C99 this is called int_fast32_t: give me the fastest size that holds at least 32 bits. That's what was needed all along

Interesting, I hadn't heard of that.

Re:Time for real apprenticeships in tech and not y

[Anonymous Coward]

I think most companies would rather have the slavery of unpaid internships then actually have to train people.

Too simplistic

[gweihir]

We do know a number of things about programming. One is that it is hard and that it requires real understanding of what you intend to do. Another is that languages help only to a very, very limited degree. There is a reason much programing works is still done in C, once people know what they are doing, language becomes secondary and often it is preferable if it does not help you much but does not stand in your way either. We also know that all the 4G and 5G hype was BS and that no language will ever make the (today prevalent) semi-competent or incompetent programmer into a productive highly competent programmer. We know that OO done well (Eiffel, Python, some few others) is nice, but that it still requires real understanding from the people using it or it is worse than not having it. And we know that it is easy to get OO badly wrong (C++, Java, etc.) making it counter-productive. We also know that architecture and design can and often is more critical than implementation. And we know that many "modern" languages cause more problems than they solve because of performance issues, code bloat, bad readability, etc. (Yes, Java, I am looking in your direction.) We also know that design patterns are nice in theory, but do not hold up in practice, mostly because most people calling themselves programmers have no clue about them, but also because patterns do only solve part of the problem.

So, no, I don't think there is a problem with programming. I am however convinced that there is a problem with the majority of the people calling themselves "programmers' these days. A real eye opener is this: http://www.codinghorror.com/blog/2010/02/the-nonprogramming-programmer.html
Even those regarded as "competent" often take months to accomplish what really competent people can do in days or even hours. I this regularly.

Re:Too simplistic

[bussdriver]

The big disappointment when I read about the 1st "design patterns", other than liking the idea of encouraging generic and somewhat uniform descriptions of solutions, I found many of them were solutions to problems created by JAVA and other restricted thinking.

See Fast Food Nation; the parts about industrialization and how it took expertise and eliminated it in favor of simple mechanistic low wage zero talent jobs.

Re:Too simplistic

[gweihir]

Indeed. Some things were nice to see a bit more formalized, but the patterns are typically far too lean to fit a real problem. I also think that many things were formalized in the pattern community early on, just to get some mass. Most of these had better been left informal, as good programmers had no issues with them anyways and bad programmers did not get what they truly meant.

The analogy with Java is a good one, as my experience with Java is that once you have a certain skill, it stands constantly in your way and due to bad performance you cannot just replace the bad mechanisms that are there, you have to use them.

Still, the pattern community tried to do one very useful things: Make standardized components possible. Many engineering disciplines do most of their work with standardized components. We know now that the time is not ripe for software to go that way, unless performance is non-critical and the problem to be solved is simple. But both are often not the case. Yet to find that put, the effort had to be made. Unfortunately, most of the pattern community does not understand that their efforts have failed at this time. Some do.

Re:Time for real apprenticeships in tech and not y

[gweihir]

No. Time for real theory coupled with real experience. Apprenticeships only work when the profession is ruled by real craftsmen. The programmers today rarely qualify, hence real apprenticeships would only make things worse.

Re:Short version?

[BreakBad]

...who needs an article when you can browse +5 funny / informative / interesting and -1 trolls?

Here at /. I just look at the pictures. Playboy, now thats a different story.

'Back to the Future' of Programming

[stillnotelf]

I was intrigued until I noticed that where I put the quote marks, and where the quote marks actually were, were not the same place. So much for the "Mr. Perl Extreme-Fluxing Agile Capacitor."

can't have unpaid internships any more

[Joe_Dragon]

and what about internships with out the university part.

better feel for stability in the 70s/80s

[a2wflc]

Most people I worked with in the 80s (and learned from in the 70s) had a good feel for concepts like "stable systems", "structural integrity", "load bearing weight", and other physical engineering concepts. Many from engineering degrees (most of them weren't CS grads like me), and a lot from playing with legos, erector sets, chemistry sets, building treehouses (and real houses). These concepts are just as important in software systems, but I can only think of a handful of people I've worked with over the last 20 years who had a feel for the stability of a system (physical or software) or an ability to find system weaknesses when a bug is found rather than fix a programming error.

That's very important for development time and quality. To go fast you need to know where it's important to go slow. You have to know what's important to get right at the start (structurally) so you can change requirements as needed and not risk breaking the system or requiring a lot of rewriting (or refactoring). Your framework should be a stable "frame" for the system (like a building or car), not a set of libraries you cobble together for speed of implementation. After deploy, "bugs" are easy to fix but system weaknesses are not.

On the other hand, a lot of things have improved. Tools, methods, and specializations allow a team to be comprised of some people who understand systems (architects, senior developers) and others who specialize in certain areas (html, db, communication protocols, builds, etc). And there are many more people available who are capable in specific areas so far more teams can exist doing many more applications. If we only had the same percentage of people writing software now as in the 70s & 80s and those people had the backgrounds developers had then, we'd be producing better software but orders of magnitude less of it.

Re:better feel for stability in the 70s/80s

[Samantha Wright]

No, no, don't think like that. All CS graduates need is to love and appreciate the nature of the fine bureaucracy at Central Services. If you don't know what a BeanFactory is, you're not a programmer!

If it's any consolation, the experience of getting a feel for system stability can be acquired by writing a really complex program in a terrible environment, such as PHP or classic Visual Basic. Perhaps a pithy book on the topic of the art of programming might help bring some of that back.

Those days are LONG gone.

[Anonymous Coward]

they hired me knowing I didn't know the area yet

Those days are long gone.

And it's interesting that you actually innovated while you were learning. That's something that corporate America should consider.

They won't.

Today is just same old same but different names and pseudo innovation. Coupled with old farts pretty much being thrown out, the youngsters actually believe the rehash tech they're working with is "new" and "innovative" - and then they wonder why they get sued for patent infringement.

It's not necessarily the IP laws: you're just reinventing the wheel and calling it a "ground synergistic scalable momentum enabling device" and the guy who owns the wheel patent has an issue with that.

Not always - but usually.

Re:Those days are LONG gone.

[znrt]

And it's interesting that you actually innovated while you were learning. That's something that corporate America should consider.

he actually didn't say that. he just said he filed some patents. that's all corporate x really wants. and yes ...

It's not necessarily the IP laws

... it's totally the IP laws. if it weren't you wouldn't have thrown in the word "corporate" while talking about innovation. innovation IS essentially a learning process. patenting is just about claiming property.

Software reinvents the wheel

[trout007]

I find it interesting that people in software think they are the first ones to ever design complicated things. It seems there are so many arguments over design styles and paths. All they need to do is look at what other engineering fields have done for the past 100+ years. It's pretty simple. When you are working in a small project where the cost for failure and rework is low you can do it however you want. Try out new styles and push technology and techniques forward. When it comes to critical infrastructure and projects where people will die or lose massive amounts of money you have to stick with what works. This is where you need all of the management overhead of requirements, schedules, budgets, testing, verification, operation criteria, and the dozens of other products besides the "design".

I'm a mechanical and a software engineer. When I'm working on small projects with direct contact with the customers it's easy and very minimal documentation is needed. But as more people are involved the documentation required increases exponentially.

Re:Short version?

[AK Marc]

So it was a TED talk?

You mean like the Antikythera Mechanism?

[Latent Heat]

http://en.wikipedia.org/wiki/Antikythera_mechanism

We don't even know what a "job" is

[Latent Heat]

Yeah.

We don't even know what "employment" is, what a "salary" is, and what "benefits" are . . .

Re:Short version?

[Anonymous Coward]

Wait, I thought Programming is Ruby, Computing is in the Cloud, a Computer is something you rent from Amazon! Who cares about the underlying 40 year old code that seems to just work and why it's there? I won't get any VC if I don't have a wacky logo and cloudy this and that.

The base is set. The abstractions are open

[Beeftopia]

So, we know what the computer does. It's this: List of x86 instructions. It executes those instructions. The device stores and executes instructions.

We think in terms of programming languages. The language abstracts away the complexity of manually generating the instructions. Then we build APIs to abstract away even more. So we can program a ball bouncing across a screen in just a few lines rather than generating tens of thousands of instructions manually, because of abstraction built upon abstraction.

In hardware, they build more complex circuits and give us more instructions. Perhaps one day mathematicians will come up yet a different device which can "do what we want", whatever that may be. The early computers were created to facilitate computation - calculation. Then people came up with programming languages (aka compilers) to generate the instructions automatically. The hardware was extended to do more things - draw a dot on a monitor for example. People discovered they could represent abstract concepts in programming languages. Then it was off to the races.

I think all complex systems are built evolutionarily. From single-celled organisms to eventually man. And it's done by taking the basic building blocks and building more and more complex systems from those building blocks. The basic stored instruction computer is settled (right?). We're doing all sorts of weird and interesting things with it, from playing Tetris, to emailing cat videos, to modeling hurricanes. And of course porn. Looking at porn.

Where does it end? Well, man can manage a certain amount of complexity (not much). He uses tools (in this case computers) to leverage his ability to manage complexity, as the device can represent all sorts of abstract concepts in code.

Re:Time for real apprenticeships in tech and not y

[Shados]

Won't change much. Even the "real theory" is half assed except in a select few colleges, usually (but not always) the high end ones. Then the professors that are good at the theory are usually impossibly terrible at the engineering aspect but still pass on their words as laws.

Its really an awkward situation.

Suggested Reading: Mythical Man Month

[kye4u]

If you want some relevant history and insight on the struggles and triumphs of software engineering, I highly suggest reading the Mythical Man-Month.

What was surprising to me was the fact that something written in the 60's about software development is still very relevant today.

The engineers who worked on the IBM System/360 OS discovered software engineering through pure trial and error.

One of the classic insights from the book that I've seen companies (i.e. Microsoft) violate over and over is Brooke's Law. Brooke's law states that "adding manpower to a late software project makes it later." It is incredible how we reinvent the wheel everyday instead of taking time learn the from the trials and mistakes of others.

Another surprising insight to me at the time was the following. Although the engineers were working on a very technical problem, the biggest challenges they had to overcome were social/people challenges.

The mess at the bottom

[Animats]

A major problem we have in computing is the Mess at the Bottom. Some of the basic components of computing aren't very good, but are too deeply embedded to change.

• C/C++ This is the big one. There are three basic issues in memory safety - "how big is it", "who can delete it", and "who has it locked". C helps with none of these. C++ tries to paper over the problem with templates, but the mold always comes through the wallpaper, in the form of raw pointers. This is why buffer overflow errors, and the security holes that come with them are still a problem.

  The Pascal/Modula/Ada family of languages tried to address this. All the original Macintosh applications were in Pascal. Pascal was difficult to use as a systems programming language, and Modula didn't get it right until Modula 3, by which time it was too late.

• UNIX and Linux. UNIX was designed for little machines. MULTICS was the big-machine OS, with hardware-supported security that actually worked. But it couldn't be crammed into a PDP-11. Worse, UNIX did not originally have much in the way of interprocess communication (pipes were originally files, not in-memory objects). Anything which needed multiple intercommunicating processes worked badly. (Sendmail is a legacy of that era.) The UNIX crowd didn't get locking right, and the Berkeley crowd was worse. (Did you know that lock files are not atomic on an NFS file system?) Threads came later, as an afterthought. Signals never worked very well. As a result, putting together a system of multiple programs still sucks.
• DMA devices Mainframes had "channels". The end at the CPU talked to memory in a standard way, and devices at the other end talked to the channel. In the IBM world, channels worked with hardware memory protection, so devices couldn't blither all over memory. In the minicomputer and microcomputer world, there were "buses", with memory and devices on the same bus. Devices could write anywhere in memory. Devices and their drivers had to be trusted. So device drivers were usually put in the operating system kernel, where they could break the whole OS, blither all over memory, and open security holes. Most OS crashes stem from this problem. Amusingly, it's been a long time since memory and devices were on the same bus on anything bigger than an ARM CPU. But we still have a hardware architecture that allows devices to write anywhere in memory. This is a legacy from the PDP-11 and the original IBM PC.
• Academic microkernel failure Microkernels appeared to be the right approach for security. But the big microkernel project of the 1980s, Mach, at CMU, started with BSD. Their approach was too slow, took too much code, and tried to get cute about avoiding copying by messing with the MMU. This gave microkernels a bad reputation. So now we have kernels with 15,000,000 lines of code. That's never going to stabilize. QNX gets this right, with a modest microkernel that does only message passing, CPU dispatching, and memory management. There's a modest performance penalty for extra copying. You usually get that back because the system overall is simpler. Linux still doesn't have a first-class interprocess communication system. (Attempts include System V IPC, CORBA, and D-bus. Plus various JSON hacks.)
• Too much trusted software Application programs often run with all the privileges of the user running them, and more if they can get it. Most applications need far fewer privileges than they have. (But then they wouldn't be able to phone home to get new ads.) This results in a huge attackable surface. The phone people are trying to deal with this, but it's an uphill battle against "apps" which want too much power.
• Lack of liability Software has become a huge industry without taking on the liability obligations of one. If software companies were held to the standards of auto companies, software would work a lot better. There are a few areas where software companies do take on liability. Avionics, of course. But an

Re:The mess at the bottom

[SuricouRaven]

The whole x86/64 architecture is a mess when you get deep enough. It suffers severely from a commitment to backwards compatibility - your shiny new i7 is still code-compatible with an 80386, you could install DOS on it quite happily. But the only way to fix this by now is a complete start-over redesign that reflects modern hardware abilities rather than trying to pretend you are still in the era of the z80. That just isn't commercially viable: It doesn't matter how super-awesome-fast your new computer is when no-one can run their software on it. Only a few companies have the engineering ability to pull it off, and they aren't going to invest tens of millions of dollars in something doomed to fail. The history of computing is littered with products that were technologically superior but commercially non-viable - just look at how we ended up with Windows 3.11 taking over the world when OS/2 was being promoted as the alternative.

The best bet might be if China decides they need to be fully independant from the 'Capitalist West' and design their own architecture. But more likely they'll just shamelessly rip off on of ARM or AMD's designs (Easy enough to steal the masks for those - half their chips are made in China anyway) and slap a new logo on it.

Re:The mess at the bottom

[Tablizer]

Regarding C/C++, Those languages are optimized to be close to the hardware; that's their forte: they are semi-assembler-language. If you optimize the language for software engineering improvements (code design & reliability), then you likely de-optimize it for hardware. Use Java, ADA, Pascal, or Eiffel if S.E. is your main goal but not performance. C/C++ exists because they fit a certain need on the performance-versus-human-friendly continuum. It's like a slider widget with performance on one end and human-friendly (SE) on the other end. Nobody yet knows how to optimize for both at the same time (other than build a CPU that fits a specific language).

UNIX was designed [as a MULTICS clone] for little machines. MULTICS was the big-machine OS, with hardware-supported security that actually worked. But it couldn't be crammed into [small hardware]. Worse, UNIX did not originally have much in the way of interprocess...

Revive MULTICS. Solved! That'll be $129.00 please.

Software has become a huge industry without taking on the liability obligations of one...

Such increases the cost of software so much that most orgs do not wish to pay extra for liability. NASA has learned how to make almost perfect software when needed, but it's extremely labor intensive. Until somebody finds a way to add reliability for much less than known techniques can, it's a no-go.

Re:The mess at the bottom

[Animats]

Regarding C/C++, Those languages are optimized to be close to the hardware; that's their forte: they are semi-assembler-language. If you optimize the language for software engineering improvements (code design & reliability), then you likely de-optimize it for hardware.

This is a common, and dangerous, misconception. It's quite possible to have efficient languages that are close to the hardware without having buffer overflows all over the place. Pascal did it. The various Modulas did it. Ada does it. Go is getting close. Subscript checking is really cheap, and often free, if the compiler understands how to optimize it. Hoisting subscript checks out of loops is important. The current Go compiler gets the easy cases (FOR loops), which is enough to keep the overhead down for inner math loops. (Math inner loops in Go would optimize better if it had real multidimensional arrays. That may happen.)

We don't have many good alternatives. Hard-compiling Java to machine code (which GCC can do) never caught on. The Modula family died with DEC. Ada was just too wordy. C is fixable, as I point out occasionally, but that's never going to happen short of a 9/11 sized event caused by insecure software. Garbage collected languages are unsuited for low-level programming, although they can go fast.

C++ was supposed to fix C, but the C++ committee went off into template la-la land, and overcomplicated the language.

Re:The mess at the bottom

[VilLynne]

> "Lack of liability" Don't forget Hardware's role in Liability. Also, regarding the possibility of future laws on software/hardware liability; if it happens, no sane insurance company would sell liability insurance to tech companies.

Re:The mess at the bottom

[SuricouRaven]

Some of the problems were pointed out:
- The device access model is still stuck in the ISA age, when peripherals were just wired up to the address and data buses. That isn't how things are done now - even the PCI-e 'bus' is actually a series of high-speed serial links. This means that all device drivers have to run in kernel memory space. Stability and security problems result.

- The 16-bit 'real' addressing mode. Another relic of the past, but still can't be abandoned without breaking the boot process. Lose that, and you could lose some complexity in silicon.

- Even the 32-bit mode could arguably go. The only upside it has over 64-bit is slightly lower memory usage when there are a lot of pointers being used, and it's a real headache at the OS level maintaining two variations on every library to support both 32-bit and 64-bit programs. Lose 32-bit, and you lose a load more complexity. Also means you could lose PAE as a bonus.

- There are opcodes for handling BCD. These are just completly pointless.

Re:The mess at the bottom

[darkHanzz]

The best bet might be if China decides they need to be fully independant from the 'Capitalist West' and design their own architecture

I'm not so sure if you have ever seen the Chinese way of designing; fiddle with it until it seems to work. Search for Huawei's security problems and you'll get the drift. Hardware design is really not done better.

Re:The mess at the bottom

[Tablizer]

Pascal doesn't do well with dynamic structures so far.

Re:The mess at the bottom

[dkf]

Lack of liability

You know why we have that? Because nobody wants to pay for what it would cost to do it the other way. They'd mostly rather have cheaper stuff without the liability insurance, with customers purchasing their own insurance if they want. We know this is a winning model because that's what everyone — the "market" — chooses when given have a chance. (Some parts of the market work the way you seem to prefer, usually those with safety-critical systems, but they're very expensive and very much the exceptional cases.)

Re:The mess at the bottom

[SuricouRaven]

I'm not saying to abandon superscalar. It works, and x86 shows it can work very well. I just want to see an 'x86 successor.' Same general design, but abandoning thirty-odd years of legacy crud resulting in a slimmed-down design that can learn from mistakes made and better reflect the design of a modern system rather than try to make modern hardware look like something that would connect up to a Z80.

Re:The mess at the bottom

[david_thornley]

C/C++: Modern C++, properly written, doesn't have the problems you attribute to it. (Granted, there's a lot of bad C++ code out there.) There's nothing inherently wrong with raw pointers if properly used, except that they offer facilities that should not be used (such as deletion). Treat them as non-owning, and std::unique_ptr and std::shared_ptr as expressing ownership. (It might be a good idea to write a nonowning_ptr that you can't delete through.) std::vector can be used to avoid buffer overflows (using .at() instead of [] regularly for subscripts). C++ is hardly problem-free, but it annoys me when people complain about things that have been fixed.

UNIX and Linux: There have been large, complicated, systems in competition. They lost. Currently, the only real competitor is Microsoft Windows. Meanwhile, people work on new operating systems. If one comes out considerably superior, it will have its chance in competition, and if Unix/Linux is the mess you claim it will have serious competitive advantages. I'm not sure what you want here (Multics back?).

Too much trusted software: This is a mess, all right, but it's not at the bottom. We're pretty much stuck with the NT/Unixlikes duopoly for large-scale deployments, but the way to address this issue is, simply, to write your programs not to ask for permissions you don't need. Applications can be modified and replaced. There are indirect ways, also. Vista introduced UAC, which isn't directly much good as security, but which punished applications that wanted too many privileges by annoying their users, creating market disincentives for permission-grabbing.

Lack of liability: This is not a software issue per se, but rather a market one. The solution is not to have legal standards for software liability, but to make companies more practically liable in general. If companies had to pay more for their screw-ups, they'd have incentive to get reliable software. This, and the trusted software issue above, are also issues in the software market. When first-to-market is more profitable than reliability and diminished attack surfaces, we get software that is buggy, easy to attack, and financially successful. There is value in buggy software, as long as the bugs aren't too bad

Other than shared memory latency, pretty good.

[Baldrson]

This guy is a ray of light from the younger generation. He's avoided grappling with the hard problem of shared memory latency, but other than that, he's doing pretty good. You have to deal with shared memory latency to handle a wide range of modeling problems, not the least of which is real-time multicore ray tracing like this.

The Future is to scrap what you think is and .

[3seas]

.... realize what IS! http://abstractionphysics.net/pmwiki/index.php

Re:High and low voltages

[SuricouRaven]

Ever heard of analog computers? They existed. There were a few made using tri-state logic too, and a lot of the early ones used base ten arithmatic in hardware via dekatron tubes.

Entertaining, but...

[msobkow]

It's an entertaining presentation, but I don't think it's anything nearly as insightful as the summary made it out to be.

The one thing I take away from his presentation is that old ideas are often more valuable in modern times now that we have the compute power to implement those ideas.

As a for-example, back in my university days (early-mid 1980s), there were some fascinating concepts explored for computer vision and recognition of objects against a static background. Back then it would take over 8 hours on a VAX 7/80 to identify a human by extrapolating a stick figure and paint a cross-hair on the torso. Yet nowadays we have those same concepts implemented in automatic recognition and targetting systems that do the analysis in real time, and with additional capabilities such as friend/foe identification.

No one who read about Alan Kay's work can fail to recognize where the design of the modern tablet computer really came from, despite the bleatings of patent holders that they "invented" anything of note in modern times.

So if there is one thing that I'd say students of programming should learn from this talk, it is this:

Learn from the history of computing

Whatever you think of as a novel or "new" idea has probably been conceptualized in the past, researched, and shelved because it was too expensive/complex to compute back then. Rather than spending your days coding your "new" idea and learning how not to do it through trial and error, spend a few of those days reading old research papers and theories relevant to the topic. Don't assume you're a creative genius; rather assume that some creative genius in the annals of computing history had similar ideas, but could never take them beyond the proof-of-concept phase due to limitations of the era.

In short: learn how to conceptualize and abstract your ideas instead of learning how to code them. "Teach" the machine to do the heavy lifting for you.

Re:"We" know this? Don't speak for the rest of us.

[Greyfox]

I went to work at a C project a few years back. It was a monolithic app with a bunch of custom file parsers built in for something vaguely resembling a home-grown ETL system. It was transitioning from a very small (1-2 developers) to a small (5-6 developers) project. A lot of the code was... bad. I spent a week bounding all their string copies, which eliminated a number of their crashes. Then I ran some tests with libefence, which isolated most of the rest of the sigsegvs pretty quickly. We still had the occasional data file cause a crash, so I ended up implementing a launcher for it which would read the batch directory and fork a new process with a single file at a time. It'd monitor the exit value of the process and if it was nonzero or died with a signal, it'd move the file out of the way so processing could continue on the rest of them. Thing about those C projects, if you know how to use your tools, the language isn't any worse to deal with than any other one. And if you actually take the time to fix your segfaults, they tend to stay fixed.

These days I like to work in C++. My usual MO is to write a class and unit tests for that class at the same time. If a problem arises in that class later, I can add a new test for it while I'm fixing it. With the C++11 standard, cppunit and a few boost libraries, C++ development really isn't any more difficult than Java development. If you write your own libraries with an eye toward building useful objects that you could use again later on, your development velocity should speed up over time (in either language.)

I've seen some horrific java projects too. Sure, your NullPointerException won't exit the program... IF you catch it. Or catch any exceptions. A lot of java projects I've seen don't. You go look at the logs and find an application has been crapping exceptions into the logs for the last 5 years and no one's ever bothered to investigate or fix them. You can still leak resources and memory in Java, as well. I see that a lot too. Adding any MQ server seems to pretty much guarantee it. I've also run across some very nasty gotchas in the language that typically wouldn't be a problem if you're not trying to use brute force and ignorance on a problem. Moral of this story is, just because you're using Java doesn't mean you can hire chimpanzees to write your code for you. Code written by bad programmers will suck no matter what the language, code written by good programmers will be great. That was as true in 1960 as it is now.

Solved in 1959

[Tablizer]

The near ideal programming language was invented in 1959: Lisp. It has nearly open-ended abstraction ability via simple syntax: flexibility without clutter. It's a thing of design beauty.

However, nobody has figured out how to leverage it for team programming and fungible staff. Regimented languages just seem to work better for your standard cubicle teams.

Re:They always fall the first time.

[Wootery]

*Re-reads summary in Laurence Fishburne's voice*

Re:"We" know this? Don't speak for the rest of us.

[gweihir]

Try writing something like GIMP in Java, it will fail horribly. GIMP is OO C (yes, not C++), something that requires actual skill. This does not make people that have that skill slower, it makes them faster. Yes, I admit that I nowadays mix Python and C modules, because doing glue code that has low performance needs is easier in modern scripting, while the C classes give me the control and performance needed for many things.

But Java? That thing is an abomination. Neither fast nor simple. Neither well structured nor giving you a lot of freedom. Doing OO so badly, it is staggering. Full of syntactic noise that makes even the simplest things long and hard to read.

Java is a tool for cretins and the only reason it is getting the job done (badly) is that there are so many cretins writing software these days, nothing else.

Re:"We" know this? Don't speak for the rest of us.

[gweihir]

Well said. One permanent problem with Java is that it is inherently slow and takes extraordinary skills to get to run fast. Most Java folks do not have that skill. I have seen really large, critical and expensive Java projects fail, because things were just to damn slow. The same thing could never have been slow in C, as it would have meant intentionally wasting inordinate amounts of CPU and memory. True, the team that wrote that Java would never have finished the code in C, but a much smaller team of people with good skills would have. And a really good team might even have written native code for the time-critical stuff an kept the Java interface. But there are very, very few people that can do that.

I think he got it wrong why we got lost ...

[Qbertino]

I think he got it wrong why we got lost.

It's not because we didn't or don't know. It's because software was free back then. Hardware was so bizarly expensive and rare that no one gave a damn about giving away software and software ideas for free. It's only when software was commercialised that innovation in the field started to slow rapidly. The interweb is where it was 18 years ago because ever since simply because people are busy round the clock 24/7 trying to monetise it rather than ditching bad things and trying new stuff.

Then again, x86 wining as an archtecture and unix as software model probably does have a little to do with it aswell. We're basically stuck with early 80ies technology.

The simple truth is:
CPU and system development need's its iPhone/iPad moment - where a bold move is made to ditch out decade old concepts to make way for entirely new ones!

Look what happed since Steve Jobs and his crew redid commodity computing with their touch-toys. Imagine that happening with system architecture - that would be awesome. The world would be a totally different place in 5 years from now.

Point in case: We're still using SQL (Apollo era software technology for secretaries to manually access data - SQL is a fricking END-USER INTERFACE form the 70ies!!!) as a manually built and rebuilt access layer to persistance from the app level. That's even more braindead than keeping binary in favour of ASM, as given as example in the OPs video-talk.

Even ORM to hide SQL is nothing but a silly crutch from 1985. Java is a crutch to bridge across plattforms because since the mid 70ies people in the industry have been fighting turf wars over the patented plattforms and basically halted innovation (MS anyone?). The sceomorphic desktop metaphor is a joke - and allways has been. Stacked windowing UIs are a joke and allways have been. Our keyboard layout is a provisionary from the steam age, from before the zipper was invented (!!). E-Mail - one of the bizarest things still to be in widespread use - is from a time when computers weren't even connected yet, with different protocolls for every little shit it does, bizar, pointless, braindead and arcane concepts like the seperation of MUA, editor and seperate protocolls for sending and recieving - a human async communication system and protocol so bad it's outclassed by a shoddy commercial social networking site running from webscripts and browser-driven widgets - I mean WTF??? etc... I could go on and on ...

The only thing that isn't a total heap of shit is *nix as a system, and that's only because everything worthwhile being called Unix today is based on FOSS where we can still tinker and move forward with babysteps like fast no-bullshit non-tiling window managers, complete OpenGL accelerated avantgarde UIs (I'm thinking Blender here), workable userland and OS seperation and a matured way to handle text-driven UI, interaction and computer controll (zshell & modern bash).

That said, I do believe if we'd come up with a new, entire FOSS hardware arcitecture "2013" with complete redo and focus on massive parallel concurrency and build a logic-and-constraint driven touch-based direct-maniplation-interface system - think Squeak.org completely redone today for modern retina touch display *without* the crappy desktop - that does away with seperation of filesystem and persistance seperation and other ancient dead-ends, we'd be able to top and drop *nix in no time.

We wouldn't even miss it. ...

But building the bazillionth web framework and next half-assed x.org window manager and/or accompaning windows clone or redoing the same audio-player app / file manager / UI-Desktop toolkit every odd year from bottom to top again appears to be more fun I guess.

My 2 cents.

Re:I think he got it wrong why we got lost ...

[geezer nerd]

It's because software was free back then. Hardware was so bizarly expensive and rare that no one gave a damn about giving away software and software ideas for free.

As someone who was working in the computing milieu back in those days, let me tell you that you have THAT comment completely wrong! Back in the old days nobody gave anything away, unless you might share something with the guy at the next desk working in the same shop. You might share something with a colleague at another university, say, but realized that you did not know how to set it up to run on his particular computing system.

Back then, every manufacturer of hardware tended to create their own OS and compilers. It was very hard to share software of any kind because unless you had a machine from the big guys (IBM) there was just not enough of a common market to make the headaches worthwhile. Remember it took people to take the orders, pack the product, and ship it out. There were no online servers where one could make an online request and download the result. Delivery of software was often done in the form of punchcard decks, or maybe on a tape that turned out to not quite work on your tape drive. Typically, if one could find software available (I am talking about libraries and tools here, not big accounting packages.) and make it available on your machine, it would be maybe "almost" useful, but require you to go in and tweak it somehow.

By contrast, today I can sit at my home computer half a world away from much of the software is and select and easily acquire massive useful packages of free high quality software that can help me create amazing things sitting in my home office. That is something I could never have done 50 years ago.

Re:Time for real apprenticeships in tech and not y

[gweihir]

I had the luck to have a really good theoretician do the introductory CS year at university for me and that he invested a lot of effort to find out how to do these things well in practice. I only later found out that the years before and after (they did rotate the introductory year) got a far, far worse education, either by bad practitioners or by theoreticians with exactly the problem you describe.

The bottom line is however that to be really good, you have to understand both theory and practice and you have to understand both well. The people that do can do things individually or in small teams that you require 100's of people to do otherwise and that then routinely fail. The problem really is that producing software is a game for highly qualified experts and not for the masses of "programmers" that currently do it. But the industry is way to immature to understand that. Compared to mechanical engineering, we are in the age where steam engines routinely explodes and otherwise performed badly. Now I had the pleasure to have a mechanical engineer to explain to me how steam pressure tanks are done today, and this is light-years from what they did back then. It is an absolute expert's game and nothing that would ever be given to an inexperienced junior engineer. But then, there are quality requirements, and if a pressure tank explodes, they will come after the engineers that messed up, because there is no excuse for that happening. Or take medicine. What goes on in software is that medical technicians do open-heart surgery. Completely unacceptable and bound to fail in most cases.

Re:Yeah but

[Samantha Wright]

And all such traditions have been vastly improved by subsequent paradigm shifts towards more willingness to experiment with radical ideas.

Re:How's that working out?

[Samantha Wright]

I'm not sure how that proves traditional programming paradigms are better than some of the alternatives we have available.

Re:"We" know this? Don't speak for the rest of us.

[Greyfox]

It's not even that the language is inherently slow. Its programmers just don't put much thought into storage or optimization. Just shove everything into a map and call it good. Or install a framework that shoves everything into a map for them. I've run across several cases where the programmer seemed to be trying to implement the least-optimum solution to his problem, and the company will just throw gigabytes of RAM at the VM without question because nobody seems to know any better. C, you HAD to roll your own, or stuff everything into a massive char* array and bludgeon it into submission. Everyone's so afraid of pointers in C because most people just did that instead of building proper structs and code to manage their memory access.

Re:Time for real apprenticeships in tech and not y

[DigiShaman]

What can be automated has been automated! When IT get's to the point of forming a schema for apprenticeships, it's at that very moment human beings will no longer be needed. Again, because now you have a template to automate the work.

Or to put it another way, IT is still staffed by people because the loop is still open. If the loop can be closed, you just need machines. And that's the entire point of development; to get to the point where you can close the loop.

Re:"We" know this? Don't speak for the rest of us.

[gweihir]

Well, yes and no. There is a lot of overhead in Java object instances. Sometimes you can avoid that and sometimes you cannot. But the thing is that in C you actually have to intentionally waste resources, while in Java it is very easy to do and very much non-obvious.

As to pointers in C, people that are afraid of them do not qualify as competent programmers in my eyes. Pointers are very reliable, very efficient and very elegant to use if you know what you are doing. With modern "quick fit" memory allocators (such as the one in the GNU C library) allocating and freeing lots of small memory pieces is extremely efficient and you need pointers to handle them. Of course, if you do not know what you are doing, pointers end up being the "goto" of data. I think people are just afraid of pointers because they separate the competent from the incompetent really fast.

Wait

[Kizul Emeraldfire]

I thought only Koreans could major in CounterStrike! :-)

(All right, I'll admit — I don't think I know what the 'CS' stands for in the context it's being used in the summary. Are they talking about Cisco Systems? To be honest, I'm not really interested in watching the video to find out. I just wanted to make the above (probably-overused (and for that, I apologize)) joke.)

x86 CPUs have been mostly RISC since the 486

[evanh]

x86 CPUs have been mostly RISC since the 486. This became particularly true with the separation of the fast and complex pipes.

I think it would be fairer to say x86 turned out to be an OK instruction set for stack based compilers.

Table Oriented Programming [re: 70's yeah right!]

[Tablizer]

I'd like to see "Table Oriented Programming" explored some more, and perhaps dynamic databases. I learned a lot of interesting techniques using dBASE and its derivatives years ago. Sure, dBASE had some clunky parts, but it also allowed or simplified things that current tools make complicated. (Those who complained the most about dBASE tried to use it like C++, which is a mistake.)

Tables are often more visual and compact to encode certain kinds of information, such as Data Dictionaries to encode field and column info. Objects are too verbose for such.

Re:Table Oriented Programming [re: 70's yeah right

[phantomfive]

Are you referred to as TopMind on a different forum?

Re:Table Oriented Programming [re: 70's yeah right

[Tablizer]

Actually, I'm Batman, but don't tell anybody.

Re:Table Oriented Programming [re: 70's yeah right

[phantomfive]

I've been reading things about table oriented programming on the c2 wiki, but I don't really understand it. I'm not sure if there is something somewhere that is a good introduction to the topic.......I'd be interested in learning more.

Re:Table Oriented Programming [re: 70's yeah right

[phantomfive]

btw, I really like this quote of yours: "No programming paradigm, short real AI, will substitute for an unwillingness of humans to plan."

Re:Table Oriented Programming [re: 70's yeah right

[Tablizer]

Here's some somewhat-simplified examples:

http://www.geocities.com/tablizer/prpats.htm

http://www.geocities.com/tablizer/cntrl1.htm

(This account will die soon, so copy it locally, or find the Reocities equivalent, which suffers formatting glitches.)

Re:Table Oriented Programming [re: 70's yeah right

[phantomfive]

k, I'll check them out