101–110 of 167 posts
Earlier quoted context omitted.
templates are lazily evaluated
> templates are lazily evaluated At runtime? like Scheme? http://www.shido.info/lisp/scheme_lazy_e.html
Earlier quoted context omitted.
But since its all turing complete... this can be said of anything. There’s nothing stopping you from doing OOP in haskell, or functional in C, or procedural in prolog, if you’re willing to put in the effort. Disregarding “comfort”, or rather, how much the language lends itself to a style, makes the notion of programming paradigms meaningless, and we’re still left with something we all know exists, but have no way to…
Different programming paradigms are not about what can be computed it is about what can be expressed in the syntax and semantics of the language. This is an important distinction. Brainfuck is capable, technically, of computing anything that Haskell can compute. However, it would be foolish to call it a functional (paradigm-sense) language. It lacks higher order functions and many other elements. You could construct…
For example, I would say that GTK+ is written in an object-oriented style. But, despite that, I would not say that OOP is a member of C's repertoire of language paradigms.
Earlier quoted context omitted.
Having lambda doesn’t mean to be FP. One of the core features missing in Java (JavaScript also) is TCO(tail call optimization)
Tail call optimization is more or less unimportant, because you can express any recursion with iteration and most of the time the explicitly iterative version is even safer and better. TCO only adds zero-cost for recursions based on tail calls, that's nice to have but recursion is a bit of a hobby-horse of CS professors anyway. It only makes sense in languages that have their own stack, i.e., have no hard stack limit…
Earlier quoted context omitted.
I've written an article on error handling some point and ended up with: "An error is when the program is operating outside the intended path of execution." What counts as intended is a question of definition, but in concrete examples of local reasoning within a function this question is usually easier to answer. Thinking about it in terms of (explicit or implicit) contracts, like Bertrand Meyer, sounds like a smart i…
> Warning: Textual logging is not an error handling strategy. Logs are not meant for machine consumption so it’s hard to have automated monitoring based on them. I'd beg to disagree. As for the general statement of your post, I like how you're talking about stakeholders and (specification) bounds but I don't think it's an actionable viewpoint. The idea of "Bubbling up errors" inside a program is caught in the softwar…
To clarify, in the context of the article, "making errors observable from the outside" is not meant at the per-function level, but meant at the level of the whole program, which includes abort(). I should improve the wording there.
abort() is perfectly legitimate if you can't recover within the same process. It's not at odds with routing to the right stakeholder, as long as the parent process catches the crash and does appropriate error handling (e.g. "Send a crash report" dialogs or other watchdogs).
Regarding textual logging, I'm not sure exactly which part you disagree with. :) I'm aware that people commonly write regex-based extractors, and I've done the same, but having the choice I'd always go for a more schema-ful error reporting channel. That's more lightweight both for reading and for writing it, and avoids a whole class of regex bugs.
Earlier quoted context omitted.
Different programming paradigms are not about what can be computed it is about what can be expressed in the syntax and semantics of the language. This is an important distinction. Brainfuck is capable, technically, of computing anything that Haskell can compute. However, it would be foolish to call it a functional (paradigm-sense) language. It lacks higher order functions and many other elements. You could construct…
There's a whole lot of stuff you can do, short of writing interpreters, to construct library-level support for a paradigm in a language that lacks language-level support for that paradigm. For example, I would say that GTK+ is written in an object-oriented style. But, despite that, I would not say that OOP is a member of C's repertoire of language paradigms.
OO languages and functional languages support each other's paradigms (more easily) than a pure imperative language would support either. And both OO and FP languages support declarative styles (like relational or logic languages) better than C would.
EDIT: It's also worth pointing out that C++ really achieved OO (initially) by using macros on top of C. So having a sufficiently expressive meta-language is also important to this. Via such a meta-language, you can achieve many more paradigms in a language than using the language alone.
But many languages lack a meta-language or don't have a standard meta-language which people can rely on.
Earlier quoted context omitted.
Having lambda doesn’t mean to be FP. One of the core features missing in Java (JavaScript also) is TCO(tail call optimization)
Tail call optimization is more or less unimportant, because you can express any recursion with iteration and most of the time the explicitly iterative version is even safer and better. TCO only adds zero-cost for recursions based on tail calls, that's nice to have but recursion is a bit of a hobby-horse of CS professors anyway. It only makes sense in languages that have their own stack, i.e., have no hard stack limit…
There are some recursive structures that are just much more natural than their iterative counterparts. Parsing (as lysium suggests in the sibling post), for example.
But also things like graph and tree traversals, and many search algorithms related to those same structures. If you attempt a tree traversal iteratively, you have to maintain the return stack manually, rather than permitting the language to do it for you (assuming a full traversal and not a search, a search could be done iteratively without much trouble).
Earlier quoted context omitted.
The problem with "choose the best paradigm/computational-model for the job" is that mastering each of the possibilities takes a lot of time for the average programmer. It may be better to master a few than spend so much extra time mastering them all. I have accused some academics of "promoting ideas that require more education" so as to line their wallet. It didn't go over well and I got counter-accused of "promoting…
> The average programming career is relatively short-lived: you either have to move into management, analysis, project planning, etc. or be subject to agism. I won't dispute the problems in the industry, but I'm not sure you can really say the career is relatively short-lived. I've been at it for 20 years, and while there are far fewer of my age-peers than there are of younger coders, the number is also far from zero…
https://www.businessinsider.com/silicon-valley-age-programme...
An interesting point raised by this paper is that when a program requires pervasive modifications (e.g. checking the error code returned by C functions), adding a new concept to the language (e.g. C++ exceptions) can systematically make these changes unnecessary, therefore simplifying the program. Perhaps this is how programming language designers ought to vet language ideas: do the proposed changes make certain patt…
The wikipedia summary of the JavaScript design rational is decent; it also kind of explains why it's so odd: > In 1995, Netscape Communications recruited Brendan Eich with the goal of embedding the Scheme programming language into its Netscape Navigator.[11] Before he could get started, Netscape Communications collaborated with Sun Microsystems to include in Netscape Navigator Sun's more static programming language J…
Earlier quoted context omitted.
The problem with "choose the best paradigm/computational-model for the job" is that mastering each of the possibilities takes a lot of time for the average programmer. It may be better to master a few than spend so much extra time mastering them all. I have accused some academics of "promoting ideas that require more education" so as to line their wallet. It didn't go over well and I got counter-accused of "promoting…
Perhaps if most everything an industry uses is learned in college, you're setting that industry up for a low skill cap and thus maybe ageism. Anyways, if someone can get more done by using skills XYZ, maybe they'll outcompete firms not using it, and now we all have to learn XYZ or be relegated to more junior positions ¯\_(ツ)_/¯
Some orgs might be, but they are better off hiding their secret from competitors, and thus we are not likely to hear about it.
Warren Buffett often expresses shock that universities and investment organizations ignore his well-published techniques, following BS and fads instead. He and other "value investors" have big bucks lasting decades to prove it; they don't. They only have silver words and catchy-sounding theories. IT is the same, I'm afraid to say.
The GREAT LIE of IT is that there's not a lot of real science in "computer science", beyond machine efficiency. It's much easier to do science and math to test and measure machines than it is the human mind, but code is meant for the human mind as much as machines. Humans make, read, and modify software, not machines: computers are just dumb automatons (hopefully) following instructions verbatim.
> We end our discussion of inheritance with a cautionary tale. In the 1980s, a very large multinational company initiated an ambitious project based on object-oriented programming. Despite a budget of several billion dollars, the project failed miserably. One of the principal reasons for this failure was a wrong use of inheritance. Who did that, exactly?
There is a right time and place to use OO (and inheritance) and wrong places and times to use it, and it takes training AND experience to know the difference. Further, a lot of it depends on the language; some languages have poor OO models, forcing one to use lambda's etc. instead. In my opinion, a better OO language reduces the need to use lambdas. I know this is a controversial statement, but I stand by it.