Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What can be learned from studying long gone development practices?

shape-of-code.coding-guidelines.com

Post reply on HN
Print view View original

131–140 of 142 posts

Re: What can be learned from studying long gone development practices?

#131

Post by lmm »

flir wrote: post #122
lmm wrote: post #69

Earlier quoted context omitted.

> Top-down/procedural fits really nicely with the unix command line philosophy. Loose coupling and pipes. I don't think that follows at all. Unix shell programming is very much a bottom-up philosophy where you write a bunch of generic tools and then string them together to solve your actual problem at the last minute.

But the individual tool itself? It takes a bunch of inputs, does some processing on them, and spits out a bunch of outputs. That doesn't feel like a good fit for procedural to you? I guess what I'm saying is that the complete input state of the program is known the moment you hit enter. As opposed to a GUI where a user could flip a switch at any point during the program's lifetime and mess with its internal state, wh…

I guess you're saying that if you're writing a small function that's fully understood then procedural top-down is a good way to do it.

I don't know. Personally even for a fairly small tool I'd want to build it bottom-up by composing smaller functions, and I think you'd gain a lot of reusability that way - indeed I'd say many of the classic unix tools suffer from being programs rather than libraries, and it's a shame there's such a hard boundary between shell and the tools it uses.

If anything I suspect the causality goes in the other direction - if you want to make a big system using procedural programming and C, then you have to split it into processes that are simple enough to comprehend in their entirety, and that have a very simple state model where they essentially just take input and give output and don't have any persistent state between invocations. But when you put it like that, Unix shell-and-pipeline style starts to seem like an effort to invent functional programming, just at a somewhat more coarse-grained level.

Re: What can be learned from studying long gone development practices?

#132

Post by laumars »

oblio wrote: post #126
laumars wrote: post #120

Earlier quoted context omitted.

You’re way off the mark! 1. Might happen occasionally but rarely would anyone adopt a vanity language 2. Nope 3. Lol this is just a rehash of 1. 4. Languages can’t be licensed, compilers can. And that’s why we often have multiple different compilers. 5. Now you’re getting close. The actual reason is: Trying to solve a different problem Believe it or not, problems can vary massively from one field of IT to another. So…

Ever heard of C#, J#, Typescript, Kotlin, Go?

Yes and only C# was created because of NIH syndrome:

C# - Created by Microsoft after Sun sued them over Java. But C# (or rather .NET) did still solve several problems with Java’s JVM (eg it’s much easier for end users to work with, it supports native widgets, first class Windows support) and personally I find C#’s syntax a little more grown up too. It’s also worth noting that C# has since evolved into its own language (rather than just being a Java knock off).

J# - there isn’t any other functional language that targets .NET so there is a distinct problem J# seeks to solve.

TypeScript - That language clearly aims to solve several short comings of JavaScript, such as type safety.

Kotin - I don’t know much about this language personally but the Wikipedia article answers my point for me:

> In July 2011, JetBrains unveiled Project Kotlin, a new language for the JVM, which had been under development for a year.[17] JetBrains lead Dmitry Jemerov said that most languages did not have the features they were looking for

Go - this filled a massive hole at the time: languages that had the guarantees of a statically compiled language while being as quick to learn and develop on as a JIT compiled language and which were cross platform. I actually adopted Go in version 1.0 for a personal project specifically because it solved problems with the other mainstream languages - problems that were very relevant to the project I was creating.

I’m an old fart with 30 years of software development experience across well over a dozen different languages (you could easily treble that if you want to include machine or compiler specific dialects too). The problem many have when they see the term “general purpose” is they assume it means “best suited for all purposes” but actually it just means “can solve most problems with some degree of success”. Thus there will naturally be specific domains where even the most versatile languages are superseded by another language. And that’s fine. Good programmers can adapt to using the right tools. Whereas bad programmers will reach for the same tools regardless of the problem because they’re too lazy or too ignorant to learn anything else.

Re: What can be learned from studying long gone development practices?

#133

Post by wtallis »

laumars wrote: post #118
wtallis wrote: post #108

Earlier quoted context omitted.

> All the counterarguments you've given are subjective to you (eg you know what tokens do in over languages, spent zero time learning the tokens of this language and thus you're clearly not going to know what a colon does in this language just by looking at it). I tried very hard to only bring up problems that were at least somewhat objective . Counting the number of superfluous symbols in the code is not purely subj…

The fact that the OP had a different opinion to yourself about what he found readable is proof enough that it is subjective and it’s laughable how you’ve demonstrated hnlmorg’s point while attempting to debunk it (eg your attempt at providing fact while your evidence is just more illustrations of familiarity which is entirely subjective).

> The fact that the OP had a different opinion to yourself about what he found readable is proof enough that it is subjective

Subjectivity isn't an absolute all-or-nothing question. An issue having some degree of subjectivity doesn't automatically put it into a purely subjective, "all answers are equally valid" realm.

> eg your attempt at providing fact while your evidence is just more illustrations of familiarity which is entirely subjective).

I referred to some quantifiable metrics. Those have nothing to do with familiarity. Whether a number is larger or smaller than another number is a fact unaffected by your level of familiarity with either number.

You're really not responding at all to the substance of my comments, so you really don't have any justification for calling me "laughable" at this point. There are plenty of ways you could try to substantively refute my comments, instead of rejecting everything generally while mixing in insults.

Re: What can be learned from studying long gone development practices?

#134

Post by int_19h »

Galanwe wrote: post #129
int_19h wrote: post #114

Earlier quoted context omitted.

But why would you do that, if it's simple and elegant? Really the only answer is that it has potentially unbounded stack consumption - but tail recursion solves exactly that problem.

Not all recursive algorithms are tail recursive; not all tail recursive algorithms can be correctly identified & tail optimized.

Right, but OP was specifically talking about tail recursion.

Re: What can be learned from studying long gone development practices?

#135

Post by flir »

lmm wrote: post #131
flir wrote: post #122

Earlier quoted context omitted.

But the individual tool itself? It takes a bunch of inputs, does some processing on them, and spits out a bunch of outputs. That doesn't feel like a good fit for procedural to you? I guess what I'm saying is that the complete input state of the program is known the moment you hit enter. As opposed to a GUI where a user could flip a switch at any point during the program's lifetime and mess with its internal state, wh…

I guess you're saying that if you're writing a small function that's fully understood then procedural top-down is a good way to do it. I don't know. Personally even for a fairly small tool I'd want to build it bottom-up by composing smaller functions, and I think you'd gain a lot of reusability that way - indeed I'd say many of the classic unix tools suffer from being programs rather than libraries, and it's a shame…

That's a fair assessment of my position, yes. But I got my start with JSP diagrams, pseudocode and command lines, so decomposition is very natural to me. It's my "first language", like English. And the comparison between good top-down structured and functional is one I've made myself.

Re: What can be learned from studying long gone development practices?

#136

Post by antonvs »

hnlmorg wrote: post #88
wtallis wrote: post #56

Earlier quoted context omitted.

> But of course aesthetics is subjective. (The term "subjective" here means what looks good to you might not look good to me, and vice versa.) Bullshit. There's so much that objectively deficient about that piece of code that I'm having trouble taking you seriously. If that comes at all close to being a representative sample of someone trying to make clear, readable code in that language, then the language was clearl…

> Bullshit. There's so much that objectively deficient about that piece of code I don't agree the GPs code is more aesthetically pleasing but he's right that it is subjective. All the counterarguments you've given are subjective to you (eg you know what tokens do in over languages, spent zero time learning the tokens of this language and thus you're clearly not going to know what a colon does in this language just by…

> I don't agree the GPs code is more aesthetically pleasing but he's right that it is subjective.

An easy way to see that these issues aren't subjective in general is to ask why absolutely no-one uses the kind of code given above unless they're forced to because of the platform they're using, e.g. a constrained embedded environment or whatever.

You either have to conclude that effectively all developers have the same subjective take on these issues, or that there's something beyond subjectivity at work. There are very good arguments for the latter.

Re: What can be learned from studying long gone development practices?

#137

Post by antonvs »

1vuio0pswjnm7 wrote: post #35
johnaspden wrote: post #10

I'm not sure you can call structured programming a fad! An awful lot of languages (I'd say all commonly used ones) use if/then/else, do..while, for..next, and so on, but I can't remember the last time I saw a program with a complicated control flow done by gotos. Such things were common in the 1970s, in fact the first professional program I ever read did it that way, and it took me ages to work out what was going on.…

"... I can't remember the last time I saw a program with a complicated control flow done by gotos." Perhaps not "complicated" enough, but here's a fizzbuzz in spitbol (a fast SNOBOL interpreter). This is an unstructured, goto based language for non-numeric computation developed at Bell Labs. Would love to see a faster version in some popular, "structured" scripting language in the same number of characters. I find I…

I really don't understand the comparison you're trying to make. I learned SNOBOL from a university library book in the early 1980s, and used it on the university mainframe - but it's baffling to me that someone might want to continue using it today for anything other than nostalgic reasons. (If you're trolling, good one!)

There's an enormous amount of accidental/inessential complexity in the code you provided, and that's a big part of the reason no-one seriously uses SNOBOL or similarly primitive languages for anything serious today. Code like the above can't remotely scale to larger programs, and attempts to do so were notorious for their failure.

Here's a version of FizzBuzz in e.g. Haskell:

    fizz n | n `mod` 15 == 0  = "FizzBuzz"
           | n `mod` 3  == 0  = "Fizz"
           | n `mod` 5  == 0  = "Buzz"
           | otherwise        = show n
 
    mapM_ putStrLn $ map fizz [1..100]
Even the already rather simple control flow is abstracted away by the 'map' function, so there are no visible loops or gotos. Compare that to your program with a dozen labels and seven gotos, where the actual logic is buried in irrelevant cruft.

Even versions with more explicit control flow (i.e. without map) can be similarly readable, but if your goal is to minimize complex control flow, then rather than reverting to intractable gotos, go read "Lambda: The Ultimate GOTO" (http://dspace.mit.edu/handle/1721.1/5753), published in 1977, and learn to use functions for control flow.

Re: What can be learned from studying long gone development practices?

#138

Post by 1vuio0pswjnm7 »

antonvs wrote: post #137
1vuio0pswjnm7 wrote: post #35

Earlier quoted context omitted.

"... I can't remember the last time I saw a program with a complicated control flow done by gotos." Perhaps not "complicated" enough, but here's a fizzbuzz in spitbol (a fast SNOBOL interpreter). This is an unstructured, goto based language for non-numeric computation developed at Bell Labs. Would love to see a faster version in some popular, "structured" scripting language in the same number of characters. I find I…

I really don't understand the comparison you're trying to make. I learned SNOBOL from a university library book in the early 1980s, and used it on the university mainframe - but it's baffling to me that someone might want to continue using it today for anything other than nostalgic reasons. (If you're trolling, good one!) There's an enormous amount of accidental/inessential complexity in the code you provided, and th…

Better than Haskell and faster, too:

    fizzbuzz:{v:1+!x;i:(&0=)'v!/:3 5 15;r:@[v;i 0;{"Fizz"}];r:@[r;i 1;{"Buzz"}];@[r;i 2;{"FizzBuzz"}]};`0:$fizzbuzz 100

Re: What can be learned from studying long gone development practices?

#139

Post by antonvs »

1vuio0pswjnm7 wrote: post #138
antonvs wrote: post #137

Earlier quoted context omitted.

I really don't understand the comparison you're trying to make. I learned SNOBOL from a university library book in the early 1980s, and used it on the university mainframe - but it's baffling to me that someone might want to continue using it today for anything other than nostalgic reasons. (If you're trolling, good one!) There's an enormous amount of accidental/inessential complexity in the code you provided, and th…

Better than Haskell and faster, too: fizzbuzz:{v:1+!x;i:(&0=)'v!/:3 5 15;r:@[v;i 0;{"Fizz"}];r:@[r;i 1;{"Buzz"}];@[r;i 2;{"FizzBuzz"}]};`0:$fizzbuzz 100

You're wasting your own time.
Post reply on HN