gdp

32 ms·

301.
by gdp 17y ago
I see. I'm still not sure how you justify your (revised) statement. What's fashionable about it? You don't think people do stuff because they think it makes them better programmers, rather than because of some perceived fashion trend? Sim
302.
by gdp 17y ago
Huh? Are you suggesting that people use functional programming languages such as Haskell or ML because they are fashionable? Where on earth are you living such that they are fashionable? I wanna live there.
303.
by gdp 17y ago
> There is a reason that research into functional languages is limited to an old or new functional language. Without syntax and compiler support you don't gain any power to offset the limitations I don't understand what this means. &#
304.
by gdp 17y ago
Concurrency in general is hard. You'll find that most uses of concurrency in production systems is restricted to very specific patterns. This is probably not a conscious decision, rather it's just very likely that straying too far from ve
305.
by gdp 17y ago
Most JVM implementations that I am aware of do sane things with respect to optimisation of immutable values.
306.
by gdp 17y ago
Sure, but that would be deliberately going against the tips in the article. The idea is to not mutate values, rather, you instantiate new objects to store new values.
307.
by gdp 17y ago
That sounds like really broken compiler or build script behaviour, rather than something intrinsically wrong with the use of final .
308.
by gdp 17y ago
Sure, but I used the word modern . As in, "of the modern era". There are old functional programming languages and there are young functional programming languages. The fact is that most of the interesting research into programming langu
309.
by gdp 17y ago
He is advocating using a style more like modern functional programming languages such as ML, Haskell and F#. The example in #8 is essentially recreating primitive tuple types present in the languages I just mentioned. Given that the overhe
310.
by gdp 17y ago
Really good advice. Whenever I encounter Java code that employs some or more of these techniques, I feel a little bit better about the world.
311.
by gdp 17y ago
Or do. Dying is fabulous for record sales. Perhaps the same applies to startups.
312.
by gdp 17y ago
I did reasonably significant work on the ModelJUnit project for several months, but these days I'm back to concentrating on my own crazy schemes. http://www.cs.waikato.ac.nz/~marku/mbt/modeljunit/
313.
by gdp 17y ago
This article could be alternatively titled "characteristics of programmers I wouldn't want to work with". Seriously, this sounds like a recipe book for one person writing code in isolation that nobody cares about, rather than any sort of se
314.
by gdp 17y ago
And that would be an interesting thing to see a blog post about too!
315.
by gdp 17y ago
No, that the reported popularity of COBOL is at odds with the anecdotal evidence.
316.
by gdp 17y ago
The sentence after that one says: "That probably says more about my isolation as a programmer than anything else". The point is valid, if only to speak of an interesting separation and the generally low-visibility of COBOL in parts of the p
317.
by gdp 17y ago
But a specification could be ambiguous, with the need for human intervention to resolve ambiguity through the 'compilation' process. And I'm not sure that I'm aware of any production-grade systems that use declarative English as a specifica
318.
by gdp 17y ago
Try to consider all possibilities for failure and all inputs or contingencies. If you are still coding and don't want to interrupt your "flow" to go write an error handler, just put an assertion or a comment or something that will force yo
319.
by gdp 17y ago
Problem solving is fun, and programming is a convenient way to access a large class of problems and express solutions to them. When the problem solving bit is done, the rest is just typing. I'd rather spend more time solving interesting p
320.
by gdp 17y ago
Who said anything about novelty? Referring to tools that do most of what is described seems to negate any claims of novelty.
321.
by gdp 17y ago
Sure, the distinction between writing specification and writing code is pretty artificial. A specification may be incomplete or ambiguous. Through stepwise refinement, multiple (formal) steps are taken towards a more concrete implementati
322.
by gdp 17y ago
I don't think there's really such a thing as a "one-time project". It is very rare that you would create a piece of software in its entirety with no variation from your original design or conception of the software, and then never revisit
323.
by gdp 17y ago
I like the premise of the article, but there are two shortcomings. 1) Kiwifruit are distributed through existing food distribution networks. New Zealand's economy is primarily driven by agricultural exports, and so they have good (cheap!)
324.
by gdp 17y ago
I'm not sure that "design" is necessary up-front. There are plenty of good strategies for rapid application development. I think what _is_ necessary is plenty of up-front _thought_, as in "why am I creating software?" and "what does it ne
325.
When are we going to stop writing code?(plsadventures.blogspot.com)
7 points by gdp 17y ago|33 comments
326.
by gdp 17y ago
This article appears to argue against basic facts about formal languages and the limits of machines. The argument seems to go something like "I don't like programming languages because they force me to work in a certain way! Now, here's a