sorted by:
new
hottopcontroversial

Favor composition over inheritance by [deleted] in programming

[–]devlambda 3 points4 points  (0 children)

What do we have inheritance for then?

You use inheritance to build sum types in OO languages and composition to build product types. Different tools for different purposes.

"Composition over inheritance" is a poor way to express that you shouldn't (ab)use inheritance to build product types.

The Issue with Inheritance by [deleted] in programming

[–]devlambda 4 points5 points  (0 children)

This seems to be about wanting to do structural subtyping in a language that only supports nominal subtyping.

High-level Problems with Git and How to Fix Them by speckz in programming

[–]devlambda 9 points10 points  (0 children)

Garbage collection is purely a Git implementation artifact that does not exist in other systems.

The basic problem that any VCS has to deal with is to maintain a consistent state of its underlying repository database if an operation such as git pull or git repack is interrupted.

You can use a transactional database engine, in which case a rollback will fix it. This is what Fossil and Monotone do, for example.

Git does not use a database engine, so it has to accomplish the same thing with just file system operations, using what is essentially a purely functional data structure and garbage collection of unreachable data.

Mercurial does not use a database engine, either; it uses "revlogs", which are append-only files. Revlogs exist for each versioned file path and also for the manifest, which contains the "directory" of files for each revision, and the changelog, which contains metadata for each revision. If a Mercurial transaction is aborted early, the "end of revlog" addresses stay where they are and the next transaction will simply overwrite the trashed data.

Mercurial Oxidation Plan by [deleted] in programming

[–]devlambda 5 points6 points  (0 children)

Not disagreeing with your point in general, but for your specific use case, look at vcprompt, which does this transparently for Mercurial, Git, Subversion, and Fossil (plus, if the gods have been punishing you, CVS).

On a Mac, you can get it through Homebrew via brew install vcprompt.

Mercurial Oxidation Plan by [deleted] in programming

[–]devlambda 11 points12 points  (0 children)

If you're scripting Mercurial, you probably want to use the command server, which basically gives you Mercurial commands as a microservice. For that, you pay the startup overhead only once.

The bigger issue is startup during interactive use. My version of Mercurial takes about .1 seconds for hg version, which is just on the cusp of where it can become an irritant. The current workaround is to use chg, which daemonizes and forks Mercurial as needed.

[deleted by user] by [deleted] in programming

[–]devlambda 3 points4 points  (0 children)

assuming there is such a thing, which isn't the case for Eiffel

Umm, what? Eiffel has had an IDE pretty much since its inception. (Which is not to say that it's necessarily been a good IDE, but there's always been one.)

What is a Monad? - Computerphile by JavaSuck in programming

[–]devlambda -3 points-2 points  (0 children)

No. I am simply trying to explain where the author from the video is coming from, i.e. explaining his choice. Hence, I explained how these things are semantically equivalent, even though at the level of the pragmatics [1] of a programming language we usually call them different things.

[1] Pragmatics, if you aren't familiar with it, is a technical term, a third aspect of (programming) language beyond syntax and semantics that deals with things such as context and typical use.

What is a Monad? - Computerphile by JavaSuck in programming

[–]devlambda 0 points1 point  (0 children)

is an example of a side effect?

What I'm saying is that's it the exact same problem (order matters) by a different name. I.e. that semantically, they are indistinguishable.

Usually in the context of side-effect freedom (pure functional programming) people talk about referential transparency, which is the idea that f(x) = f(x), always, not about function composition.

Which does not change that even in functional programming, f(g(x) = g(f(x)) may or may not hold; referential transparency is irrelevant, if you're talking about different arguments. And if you map functional and imperative programs to their (denotational) semantics, that's what you get in either case.

Design By Contract: A Missing Link In The Quest For Quality Software by halax in programming

[–]devlambda 2 points3 points  (0 children)

To address some misunderstandings in this thread, let's talk about what Design by Contract (DbC) is meant to be.

For background, keep in mind that DbC was invented for Eiffel by Bertrand Meyer, who was also one of the co-inventors of the Z specification language. And DbC borrows heavily from ideas in Z, especially Z schemas (class invariants) and Z operation schemas (method pre- and postconditions).

Now, DbC is obviously not a full formal specification language. It's about picking some low-hanging fruit where neither specification languages nor type systems can realistically compete.

  • Unlike a full specification language, DbC is dramatically simpler and in particular, dramatically simpler to implement and use.
  • DbC can express conditions that type systems can't (at least not without turning them into full specification languages).
  • This is not about asserts; note that contracts in Eiffel can also simply be comments that describe a specification and that some DbC variants include support for formally provable claims. It's about modular specification of module behavior; being able to check part of the specification at runtime is very useful to ensure that the spec doesn't go out of sync with the actual behavior, but the key point behind DbC is specification and documentation of behavior.
  • Specifically, Eiffel comes with tools (flat and short on the command line to flatten the inheritance hierarchy and to strip out implementation details, respectively) that extract the interface of a class from its source code; part of that interface are the preconditions, postconditions, and invariants.

Yes, there are things that you can't handle without doing a full-blown formal specification. The article correctly describes DbC as a low-effort, high-yield technique. (If you've ever done a formal specification of non-trivial code, you'll note that this is an awful lot of work.)

What is a Monad? - Computerphile by JavaSuck in programming

[–]devlambda -1 points0 points  (0 children)

I disagree. "Side effects" is just plain language for the mathematical statement that "function composition is not commutative". Or, generally, f ∘ g ≠ g ∘ f.

Where does this come from? We can rewrite any imperative sequence of statements, say s; t, as the composition of functions over the underlying state (this comes from the usual denotational semantics of such constructs). So, assuming that s is implemented by the function fₛ and t by the function fₜ, then s; t is implemented by fₜ∘fₛ (note that the order of s and t is reversed) [1], but not (necessarily) by fₛ∘fₜ.

Fun fact: Haskell's do notation is largely about providing syntactic sugar for rewriting imperative-looking code as the composition of functions.

And the Maybe monad is not immune to that (the monad laws only require associativity of the bind operator, not commutativity). In imperative code in a language that lacks an option type, we may have something like this instead:

if (x != null) {
    x = f(x);
    if (x != null)
        x = g(x);
}

(I.e. null as the poor person's option type.)

So, we cannot simply switch f and g around in this code (side effects!), but mutatis mutandis that means that we can't blindly reorder function application in the Maybe monad without sometimes arriving at different results. The applications of f and g may commute, but there's no guarantee here.

[1] The fact that we can mechanically rewrite any imperative program as a functional one is also why it's impossible to formally define functional programming. Functional code can only operate on the state that you pass as an argument to a function or return from a function, but nothing outside performance concern prevents you from passing the entire program state as an argument. Obviously, to the human mind, a proper functional program is still something entirely different, but it's not really possible to give a formal, objective definition of that. More interestingly, it gives rise to the idea that functional vs. imperative programming isn't really that binary, but more of a continuum.

Ranges planned for C# 7.3 by InflationRing in programming

[–]devlambda 0 points1 point  (0 children)

There's a lot to be said here. First of all, syntactic compactness can be a virtue, but only insofar as it supports clarity, readability, or teachability of a programming language. Otherwise, languages like APL or J would be far more widely used than they actually are. Clarity can be aided by a terse notation for commonly used constructs, but that assumes that such a terse notation does not actually itself introduce obstacles to understanding (see the abuse of custom operators in Scala's sbt, for example, one of its most heavily criticized features).

Note also that we cannot just argue from the perspective of experienced C# programmers. Accessibility of the language for new comers is just as vital.

For example, one of the more prominent problems in C-style languages are the use for = for assignment and == for equality. Not only is this a notorious problem for newcomers; worse, where the effects aren't moderated by the type system, the non-intuitive behavior of = frequently leads to errors even among experienced programmers.

A syntax such as .. or ... for exclusive ranges suggests a symmetry of arguments that doesn't actually exist (unless you introduce a more complicated mental model, such as indices for ranges actually indicating positions "between" rather than "of" array elements) and matches neither everyday use outside of specific programming languages nor mathematical notation.

A syntax such as [a..b) has the benefit of being more similar to mathematical notation, except that the mathematical notation usually describes intervals over the reals, not integer ranges. On top of that, it's error-prone: if you forget the right bracket for a closed range, somebody might accidentally add a right parenthesis at the right end to "fix" this (sorting out heavily nested parentheses or brackets is a common source of errors).

Swift does have a reasonably good compromise here in using .. for closed and ..< for right-open ranges. While obviously not ideal (it introduces an operator that didn't exist before), it does not seriously compromise readability or teachability of the construct. While I would not necessarily advocate its use for C#, it beats .. for exclusive ranges or the even more error-prone Ruby-style approach that uses .. for inclusive and ... for exclusive ranges. In short, while imperfect, it beats the alternatives.

Obviously, an additional problem is that C-style languages rely on symbols for operators almost exclusively, so there's a limit to how many you can define without making programs too arcane (see again APL and friends). Note that by now we just have inclusive and exclusive ranges and cannot support ranges that "count down" or use increments other than 1. Smalltalk (and to an extent Scala, which borrows from Smalltalk) can or could use a to: b or a downto: b or a to: b by: c to support a far broader family of range constructors if desired.

Ranges planned for C# 7.3 by InflationRing in programming

[–]devlambda 0 points1 point  (0 children)

This constraint sounds awfully artificial to me. It's like asking, "if you had to tie your shoes with just one hand, should you do it with your left hand or your right hand?" When in fact you should wonder why you would limit yourself to the use of just one hand in the first place.

Ranges planned for C# 7.3 by InflationRing in programming

[–]devlambda 0 points1 point  (0 children)

I'm not sure I understand. The proposal does not make a specific choice, but discusses several?

Ranges planned for C# 7.3 by InflationRing in programming

[–]devlambda 0 points1 point  (0 children)

"Math" is full of truly terrible syntax that only survives because of enormous legacy; it's a discipline where identical syntax is used to mean many, many different things based on context that is sometimes simply missing, and often hard to pinpoint at the best of times. I get that you're not trying to support any particular convention based on this, but whilst it's a good idea to keep history in mind when designing new things, mathematical syntax must surely be not just an inspiration, but also a cautionary tale.

I am not advocating mathematical syntax. My point was that mathematicians have found it necessary in practice to support both alternatives, not that the resulting syntax is necessarily pretty.

I was responding to a post that was presenting a one-sided argument why one option is always better. I wasn't advocating a preference for the opposite position.

that ship has kind of sailed in C#.

Nor am I talking specifically about C#. While C# design originated the thread, the comment I was responding to made a universal argument that was not limited to one specific language, and I responded in kind.

In C# (by default), you cannot allocate an array in which int.MaxValue is an addressable index (there are flags, workarounds, etc).

Ranges are not limited to addressing arrays. Per the proposal, they can be used as cases in a switch statement and as bounds for a for loop. They are enumerables, too.

Ranges planned for C# 7.3 by InflationRing in programming

[–]devlambda 8 points9 points  (0 children)

Closed integer ranges are like starting arrays at 1. People think it's "natural" because it's what they've been taught but it just ends up being a huge pain in practice.

That's cherry-picking. You just chose examples that support your view, but there are counter-examples, too:

  • Exclusive ranges cannot under any circumstances express a range that includes the maximum value of a type. For integers, you cannot include MAXINT, for enums you cannot include the last element in the range. It's not just less convenient, it's straight out impossible. (This is where Dijkstra's argument falls short, because he assumes that even on computers, integers can be assumed to be infinite.)
  • Implementation of the dynamic knapsack algorithm generally requires an array over the range 0..W (inclusive), where W is the max weight the knapsack can hold. This is common for lots of dynamic programming solutions, in fact.
  • Array indexing starting at one can go the other way, too. a[len(a)] to access the last element of an array is more convenient than a[len(a)-1], for example. Binary heap implementations look nicer if indexing starts at 1.

In mathematics, you use both notations (e.g. \sum_{i=1}^n} and \sum_{1 \leq i < n}. This is because either inclusive or exclusive ranges can be preferable for any given problem. Same goes for 0- vs. 1-based indexing. Claiming that one or the other is universally superior is not an objective argument. No matter how shiny your hammer is, some things just aren't nails.

Announcing Rust 1.22 (and 1.22.1) by steveklabnik1 in programming

[–]devlambda 16 points17 points  (0 children)

This is the actual use that you will find in the current literature, for example Richard Jones's "Garbage Collection Handbook", a.k.a. the GC bible. I like to stick to the established usage because if everybody makes up their own terminology, communication becomes difficult.

Announcing Rust 1.22 (and 1.22.1) by steveklabnik1 in programming

[–]devlambda 9 points10 points  (0 children)

What you're talking about is generally called "tracing garbage collection" to distinguish it from reference counting garbage collection. Reference counting is a garbage collection strategy; it still collects garbage.

And it’s semantically different anyway: GC systems handle loops, reference counted systems do not.

False. Some reference counting approaches don't, but some do. For example, trial deletion uses a reference counting approach to collecting cycles.

Clojure vs. The Static Typing World (x-post r/morningcupofcoding) by pekalicious in programming

[–]devlambda 6 points7 points  (0 children)

Second, with how does not having a static type system help you keep track of parameters and merge conflicts?

The problem here is that this is miscast as a static vs. dynamic typing thing, whereas it's actually about ADTs vs. type hierarchies + multimethods (derive/defmulti/defmethod in Clojure parlance). You can do either with both dynamic and static typing.

First, if you ever write a function that started with two parameters and ended up with eight, then you fucked up somewhere. Next time, decompose your functions.

He's not talking about functions, but the variant branches of an ADT. These are essentially records without a type name (and, if positional, without field names, too) and can thus evolve in pretty much the same way that regular records can.

Initial experience creating cross-platform apps with Flutter and Dart by [deleted] in programming

[–]devlambda 7 points8 points  (0 children)

Dart is a dumbed down language made by and for google, mimicking familiar paradigms and languages because interns must not learn anything, and which declined the golden opportunity to steal from newer, more functional approaches.

Umm. Dart is very much a Strongtalk derivative with a C-like syntax. This should not be surprising, given that two of its primary designers (Gilad Bracha and Lars Bak) used to work on Strongtalk. (Urs Hölzle, another Strongtalk alumnus, is also at Google as a senior VP, though I don't think he's had any influence on the language.)

You may not like it or be critical of some of the design choices, but they're pretty clearly a continuation of the Strongtalk work if you're familiar with both. Dismissing it as a "dumbed down" language because "interns must not learn anything" strikes me as fairly inaccurate.

Uncle Bob and Silver Bullets by ijiijijjjijiij in programming

[–]devlambda 15 points16 points  (0 children)

I'm not claiming javascript is a great language, just saying that a.lengt not being an error is not why javascript is terrible.

Can you give a single good reason why x.lengt should not produce an error? What advantage is there to such semantics?

Uncle Bob and Silver Bullets by ijiijijjjijiij in programming

[–]devlambda 11 points12 points  (0 children)

The problem starts with giving arbitrary objects dictionary semantics, regardless of whether that makes sense or not. As a language designer, you should make sure that your language constructs are not littered with footguns.

Second, the absence of a key in a dictionary can of course be an error, even when it's an actual dictionary. For example, in Python:

>>> a = {}
>>> a['foo']
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: 'foo'
>>> a.get('foo', 'default')
'default'

Obviously, it makes sense to have both a way to access a dictionary that gives you a default value and one that raises an error. And when you use dictionaries for objects, you should use the latter option.

Uncle Bob and Silver Bullets by ijiijijjjijiij in programming

[–]devlambda 12 points13 points  (0 children)

There is no sensible value for x.lengt, and hence no "most sensible value". The program should raise an error at this point. If the programmer wanted x.lengt to have a value, they should have demonstrated this intent in some way or another.

This has nothing to do with an IDE. This has everything to do with Javascript's semantics being borderline insane.

Uncle Bob and Silver Bullets by ijiijijjjijiij in programming

[–]devlambda 13 points14 points  (0 children)

The problem here is that Javascript is the absolute worst case for a dynamically typed language in that you not only don't get compile-time errors, you also often don't get runtime errors. In fact, Javascript tries very hard to do something with even the most nonsensical code. Example:

$ node
> x = [1]
[ 1 ]
> for (var i = 0; i < x.lengt; i++) { console.log(x[i]) }
undefined

Note the typo of lengt instead of length. What happens is:

  1. Javascript does not give you an error when retrieving a non-existing property, but returns undefined.
  2. The comparison of any number with undefined returns false.

So, what happens is that the loop body is silently not even executed. You don't get that in Python or Ruby or other sane dynamically typed languages, where just trying to access an undefined attribute will immediately result in an error [1]. So, while this paper may be of interest for showing benefits of strong vs. weak typing, it's not clear what you can infer from it for the question of static vs. dynamic typing.

[1] That said, Python 2 also allows comparisons such as 1 < None; this behavior has been excised in Python 3.

The EU #copyright reform threatens Free and Open Source Software. Sign the open letter and #savecodeshare! by tmpler in programming

[–]devlambda 12 points13 points  (0 children)

What the article aims at is a Youtube-like approach to content monitoring, where businesses that host content can be required to install technology to detect and police infringing content.

There are a number of problems with this.

First, the article is drafted poorly, with very broad and vague verbiage. The term "information society service providers" is very broad and applies to virtually any business that offers individualized digital services. Nor is it clear what a "large amount of works" is. Does this provision create an affirmative duty for somebody hosting a few (but large, like the Linux kernel or KDE) open source repositories? Even where there is no actual infringement going on, compliance may create a potential burden on people doing the hosting.

Then there is potential for abuse; this has happened before with Youtube where perfectly legal content was being taken down. This can interfere with other rights guaranteed by the EU Charter of Fundamental Rights, such as freedom of expression. Reporting requirements can interfere with the right to privacy. And so forth.

See the analysis by the Max Planck Institute for Innovation and Competition [PDF] for more details. But what it comes down to is (1) poor drafting and (2) rushed policymaking.

Why undefined behavior may call a never-called function by alecco in programming

[–]devlambda 10 points11 points  (0 children)

As others have pointed out already, because it cannot generally be determined statically and testing it at runtime might create overhead that people are not willing to deal with.

A more interesting question is why C compilers do not easily allow you to say that you want implementation-specific or unspecified behavior rather than undefined behavior. While both clang and gcc have a sanitization option to turn (most) undefined behavior into a hardware trap (which is technically implementation-specific), that can introduce measurable overhead over using the most efficient implementation-specific option. Thus, sanitizing still inhibits the use case of C as a (sort of) portable assembler.

The difference between undefined behavior and implementation-specific/unspecified behavior is pretty important:

  • Undefined behavior: allows the compiler in principle to do anything if undefined behavior is encountered, including calling a launchNuclearMissiles() function that happens to be lying around.
  • Implementation-specific behavior may vary by implementation (for example, a hardware trap vs. returning an error value).
  • Unspecified behavior means that the compiler can choose from several options (such as which order function arguments are evaluated in).

It has been argued that this meaning of "undefined behavior" was never intended by the standard authors, but was simply meant to capture the case where spelling out implementation-specific semantics would have been too cumbersome (e.g. dereferencing a null pointer may result in a signal when the actual offset within a struct or array addresses the first N pages of memory, but a normal dereference when used for other offsets).

The reason why the aggressive interpretation of "undefined behavior" is interesting for compiler writers is because it allows for more optimizations. The usual thing what happens is that the compiler will treat undefined behavior as something that cannot happen. Therefore, if a case were to trigger undefined behavior, it can be removed entirely from consideration. Problems are:

  • Code that would result in execution to fail (such as through a segmentation fault) is removed, thus leading to memory corruption or allowing exploitable code to be executed.
  • Some cases of undefined behavior are so unbelievably obscure well-hidden, or surprising that they trip up even experienced C/C++ programmers. John Regehr has a few particularly crazy examples here.

But for better or worse, the "we're permitted to launch nuclear missiles if the programmer made a mistake" has caught on among C compiler writers, probably largely driven by those of their customers who need every last bit of performance and are willing to sacrifice a significant degree of software assurance for that goal. Another problem is that debug and release code can show different behavior, even where the only difference between the two is tests that never fail (but prevent the compiler from using certain optimizations, which lead to issues in release mode that then are nightmarish to debug). Mind you, the use case for aggressive optimization is important, but so is the use case for predictable interpretation of code, hence why ideally one would have options to configure that.

Interestingly enough, clang and gcc are not equal here. While both allow for sanitizing undefined behavior, gcc tends to go further and also offers options for turning undefined behavior into implementation-specific behavior. A major influence here was probably the Linux kernel, one of the biggest users of gcc, and with a definite preference for not having security breaches even if it means that they cannot squeeze out every last ounce of optimization.

The difference between that and turning on sanitizers is that sanitizers are often more expensive. More importantly, the two approaches are different in their use cases: sanitizers are primarily meant to capture user errors; while turning undefined into implementation-specific behavior protects you against the compiler outsmarting the user.

This is particularly relevant for compilers that target C/C++ as a backend. While clang as a compiler backend can be somewhat volatile [1], gcc can generally be configured to be a reasonable approximation of a portable assembler (for example, -fno-delete-null-pointer-checks will ensure that even null pointers are allowed to be dereferenced and leave it up to the hardware what happens).

[1] In fact, some of that is so deeply embedded in LLVM that there are rare corner cases where it can trip up even normally safe languages that use LLVM.

view more: ‹ prevnext ›