Learning from Ada
monkeysnatchbanana.com
monkeysnatchbanana.com
I think this dynamic plays out in a lot of technology evaluation decisions. It's probably why techs like Javascript, MongoDB, Ruby on Rails, Java, PHP, MySQL, Wordpress, etc. have gotten widespread adoption despite numerous technical flaws. They have a very low barrier to getting something useful up on screen, and feed peoples' need for instant gratification. When you feel good about yourself while using the language, you feel good about the language.
The interesting thing about the software industry is that network effects are often so strong that it's rational for a disciplined, expert developer to use one of these technologies rather than something more niche that plays to their expertise. You may hate Java, but if you need to use Hadoop/Storm/SparkML/OpenNLP and the myriad of well-tested libraries, it may be a lot better choice than building your own distributed big-data stack.
I guess this is the idea behind "Worse is Better" [1]. It makes me wonder if "better" will ever be "better" (perhaps after the pace of adoption in the software industry slows down, and we start spending time getting known product architectures right rather than finding the next big unknown product architecture), or whether by that time the entrenched base written on top of ad-hoc technologies will be too big to change.
It might not be just about that. Sometimes you don't know what you're doing, and you have to find out first. What use is it if you painstakingly design and craft a perfectly engineered program, only to find out that you actually needed something else? Being able to experiment is precious. Being forced to handle everything before the thing even compiles is not all that useful at times. There's a reason why interactive environments like Lisp and Smalltalk don't force you to define all functions that could plausibly get called (and when they do get called, you can even add them on the fly and continue).
How? By building the structure/hard stuff first and letting the compiler verify it while leaving out the uninteresting parts.
A very simple example. Let's say you have some data model with people, addresses, whatever. You want to see what you need to do to get a list of addresses for some group of people.
You start by defining the structure of your data model (this can depend on DB schema, business requirements, whatever):
data Person = Person { name :: String, city :: String }
data Address = Address { city :: String, zipcode :: String, street :: String }
getAddresses :: [Person] -> [Address]
getAddresses = undefined
addressForPerson :: Person -> Address
addressForPerson = undefined
getAddresses = map addressForPerson
Now we can go back to `addressForPerson` and implement that. But turns out, we only have a city stored in Person, so the best we can do is get back a list of potential addresses for each person. So we need to adjust that type signature:
addressForPerson :: Person -> [Address]
addressForPerson = undefined
getAddresses :: [Person] -> [[Address]]
Granted, this is a very simple example, but I hope it illustrates how static languages facilitate extremely fast prototyping. Sure, a Lisp REPL is very very nice, but in my personal experience it's no match for a type system. We didn't even have to mock data to start experimenting!
(And yes, Haskell, OCaml, PureScript, Elm etc all have a REPL too).
Why shouldn't I be able to do this on a meta-level? There does not appear to be any restriction on, for example, Lisp code regarding the use of problem solvers and provers. The same should go for other metalanguages (perhaps even better, without forcing me into specific semantics).
(Likewise, generative solutions might reduce this problem simply by performing a sequence of correctness-preserving transformations from a higher-level specification. That would shift the burden to checking the specification, which would require a custom checker anyway. Haskell's capability to check or automatically derive stuff seemed limited the last time I looked at it.)
Also, using a type checker to wholly check your Lisp code basically makes it a static language, the difference then is pretty much philosophical I'd say.
I'd rather avoid someone forcing me into using a hardcoded type system, among other reasons because I'm contemplating a (perhaps novel?) search-based program/expression-manipulating system that wouldn't play well with any fixed typing system. For one thing, the types of expression results (being return values of operators applied to input expressions or programs) can easily be emergent (is the resulting expression linear? Is it an odd function? Is it analytically integrable? Etc.) and not easily arrived at in something ML-like. If I had to use something like Haskell, I'd still be rolling out my own type system/prover on top of the existing language implementation anyway. However, types in general (as something you can compute with in the meta-program) would be absolutely mandatory for a system like this (for example, some algorithms or operations can have more desirable refinements that work only on subsets of values - consider determinants of triangular matrices, with triangular matrices being an emergent type - and I absolutely want to find out if such a thing is available for the specific problem being transformed), just not types that any specific existing language offers, to my knowledge.
So it's not that I dismiss the notion of proving things about programs - that is a vital thing to have - but the ability to impose restrictions on a program from the outside seems much more flexible to me than going for some fixed type discipline that could force me to straddle inconvenient fixed walls in the structure of a complicated program (such as this transformation system that would search the tree of possible transformations for a result with some desirable properties, with the transformations concisely expressed in some very-high-level DSL source code).
The small amount of scientific study around what type checking and static typing gives you is that you avoid around 3% of bugs but even those 3% are easier to fix than the effort in writing them correctly in the first place. While I agree that the subject needs more study but what we know now: the real win would be to have a dev process that lowers criticality of failure (like TDD, CI and other Agile processes) and dispense with static typing for most projects.
Maybe I need to spend some time in Haskell and come over to your way of seeing it. But the studies show that constructing the type system for your problem is very difficult and remains error prone. People routinely make mistakes with types systems of all kinds. I've found I spend more time making the compiler happy that it does making me happy.
With property based testing, your system will come up with mock data for you.
But still, my point stands - writing tests during early experimentation is a lot harder than just altering some type and letting the compiler infere what needs to be done or what you broke.
I've spent some time writing Clojure and still use dynamic languages a lot for smaller tasks, so I know both sides. This doesn't mean much, but I'd really encourage you to try some ML language and spend some time with a nice type system. Haskell is probably too big a time investment, so maybe try Elm [0] - it's very beginner friendly and a lot of the people using it come from JavaScript.
Wow, then you are extremely lucky because bugs like that would occasionally consume a whole day of senior developer time at my previous Python job.
It seems like a symptom of other problems more than anything, and using a staticly typed language will just make those problems manifest in a different way.
http://games.greggman.com/game/dynamic-typing-static-typing/
If you are writing all of your code from scratch, then it doesn't happen too often. You usually have enough of the current context in your head to avoid most type level mistakes.
The real strengths come from two situations.
The first is refactoring. There is just no contest here. Having every single place where your change affects the test of the program identified automatically is extremely useful.
The second is returning to old code and either trying to understand it or make small changes to it.
For an example of a project which I worked on for months, given N molecular graphs, find the maximum common subgraph which is in at least M of them. I did all that in Python. I don't think static types would have made a difference.
Matrix algorithms are an even more clear example. They work with a single numeric type, in a 1D vector or 2D array. It's hard to confuse the types. On the other hand, it's easy to get the algorithms wrong, and choosing the right algorithm can require a lot of design space exploration.
Just think of the number of clustering algorithms available which you might want to try out through prototyping before spending the time to scale things up. How does static typing really help there?
reduceGraph :: Graph a -> Graph Reduced
[0] In some languages, like older versions of pascal, arrays of different lengths were different types, which was a horror for writing generic code.
Beyond strong typing, do you get the sense that static typing significantly improve prototyping ability for matrix analysis code?
Even with no knowledge of the problem space, I can think of a whole bunch of static types off the top of my head.
You've already given your input type: N molecular graphs, and a number M.
You've also given your output type: the maximum common subgraph which is in at least M of the given N molecular graphs.
Straight away I can spot a problem with this, since there are no programs of this type. In particular, there is no valid output when M > N. Hence I would refine the input type to ensure that M <= N.
Since it appears in your input type, it would be useful to have a type for "molecular graph". Likewise, based on your output type, it would probably be useful to have types for "subgraph of g", "common subgraph of gs", "maximum common subgraph of gs" and "subset of gs".
Naively, I'd give your program a type something like this:
(m : Nat, gs : Set MolecularGraph, m <= size gs) -> (hs : SubSet gs, size hs >= m, MaximumCommonSubgraph hs)
Whether it would be more or less appropriate for your situation is, of course, an entirely separate issue ;)
If instead of having separate Person and Address types you just use strings for everything (even "lists" can be strings - just keep the data serialized into HTML, or XML) then you can your program is likely to "do something" if you just compose a bunch of functions together. Sure, your code might have a bunch of logic bugs (like HTML injection / XSS) but at least it does something!
Static typing is great once you leave this "stringly typed" world and start separating your values into strongly-typed types. When you get a type error from passing a value to the function then its nice if you can be warned about this at compilation time.
A sufficiently expressive type system will guide you and hold your hand over the course of the refactoring. It will determine for you the precise cascading effect of any code changes you make. And if you forgot to write a unit test to handle some edge case, the chances are pretty decent that the type system will detect it for you anyway.
In terms of writing a new piece of software whose design you haven't fleshed out yet, my approach in a language like Haskell is in fact very experimental, but quite different from something like Python. Rather than writing lots of little tests and trying to get bare-bones functionality implemented passing those tests, I often completely ignore tests and let the type system guide me. I try to flesh out the types that my program will need at a high level and just go from there. I call it "type-driven development", and it's extremely useful for early-stage exploratory programming, because it lets you play around with the structure of the program without worrying about any details. This is only possible in a language those type system is powerful enough to actually encode nontrivial aspects of a program's high-level structure.
I make sure at every point that I have a codebase that passes the type checker. It may not be interesting to actually run it at an early stage, but in many ways that actually makes exploratory problem solving even easier.
In many cases, this approach will reveal architectural issues early on that you may not have realized existed until you'd already written thousands of lines of code in something like Python. The real point is that either way you will have to face those issues if you want to end up with a working piece of software. But it's a lot easier to face them early on, when little code depends on them, rather than later on.
The former encompasses situations like contract development, signal processing, control & embedded systems, compilers, maintenance programming, etc. I've found that strictly typed languages like Haskell, Ada, or Rust can be very helpful here, even for exploratory programming. In this situation, you know (and have little control over) the data that goes into your program and the requirements that it must meet, and if it doesn't do so, it's because you made a mistake somewhere.
But many types of exploratory programming involve unknown inputs or unknown outputs. Think of data mining or scientific computing, where the issue is often that you have unclean data and your task is to figure out how it's messed up and how to fix it as quickly as possible. Or UI software (both web and mobile) and tech entrepreneurship, where the big unknown is often how the user will react to the software and where they will find value in it. I've found that dynamic languages are great for this, because the whole point is you don't know what the data will look like, let alone how it will be structured.
It was interesting to me that the two alternatives you mentioned were "write lots of little tests" or "let the type system guide what needs to be fixed". For a lot of the exploratory programming I've been doing lately, the most efficient approach is just "let it break". Go make your changes, and if some part of the system doesn't work anymore, just take note of that. Because the act of letting things break gives you important information. If you don't care, then obviously that feature wasn't very important to the system to begin with, and you should rip it out entirely. If you do care, you should fix it, and then write some tests to make sure it doesn't break again. This way, you can build a rough rank ordering of how important features are, so that when you're faced with engineering trade-offs (and you always are), you have a solid, experience-based intuition about what you really need to support and what you can let slide.
With all that said, I like your distinction at the beginning of your comment a lot. A lot of my recent work has focused very much on a problem domain where the input data is very well understood, but the transformations applied to that data are complex and not all that well understood. I've found that Haskell has worked extremely well for me in this case, but I think you make a compelling point that it may not work quite so well in cases where the input data is the unknown, but the transformations are fairly well understood already. Perhaps this is why languages like Python have dominated the machine learning space, and strictly-typed languages just never really took off there.
This works fine in Haskell, thanks in part to laziness. There needn't be a tradeoff here.
In a strict language, a type error would mean the bricked off expression that doesn't type-check would spread like an infection to any expression that incorporated it.
In Haskell, I can dance around sub-expressions that don't type-check at runtime and evaluate things optionally.
The technique doesn't work in practice otherwise.
I don't see why. Functions in a strict language are evaluated lazily. Any type error within a function wouldn't spread beyond that function.
Even strict-by-default languages that let you easily make values explicitly lazy would mean type level churn, if not term level.
The value part is important because it means you can't really talk about partially implemented hypothetical results where you know how to handle one branch of a function, but not another. This is a super common divide-and-conquer technique in Haskell.
Could possibly half-ass it if you have some kind of panic functionality, but it'll fail unconditionally in a strict language when the result of the function is forced. In Haskell, if you don't use the bottom, it doesn't blow up.
I'm not arguing universally against what you're proposing by any means, but it doesn't seem like a clearly superior approach to me. The bottom line is that "let it break" takes many forms. There's your version, there's my type coherence version, there's Erlang's version with supervisor trees, etc. I think it's hard to argue that any of these is universally superior to the others.
This is far from the whole software industry, but it's a segment that tends to be of disproportionate interest to HN readers, given the startup-focused origins of this site.
[1] I somehow forgot that I enjoyed it a lot and loved that thing that I'd avoid like plague a few years later (I don't care about it now, for or against)
For implementation, it's whatever tool best fits the job.
C is a good compromise, but it requires real discipline. The CPython and Linux code bases are great examples of how C can be wielded well in practice. But of course C also famously offers unlimited opportunities to make a complete hash of things. I certainly wouldn't recommend it to anyone as their first and only language.
An alternative approach is to be bilingual. For my current project the final code is in C++98 - sometimes there's no good alternative. But I do most of my experimentation, tooling and prototyping in Python. Python's excellent C/C++ interoperability is a huge benefit in this.
I definitely agree with the article that you shouldn't avoid hard things that improve you. But in choosing between ADA and C, the right answer is both and neither.
That said, its easy range types and discriminated unions make writing C-level code SO much nicer.
The advantage of this is that it's much harder to screw up block terminations --- one thing I've done many times in C is when closing a chain of blocks with:
}
}
}
do_something();
}
}
end if;
end;
end case;
do_something();
end loop;
end;
It also lacks memory safety, despite being a safety-oriented language.
If someone added a better syntax to Ada (probably easy) and Rust-like memory safety (probably hard), that would make it a higher-value proposition.
EDIT: There's also an article demonstrating a hole in Ada type safety: http://www.enyo.de/fw/notes/ada-type-safety.html
If you're restricting yourself to access types you have good memory safety. Access types cannot be aliased unless declared so, and are subject to accessibility checks to verify that they are "live". Unsafe stuff in Ada must be used explicitly; you cannot, in general, accidentally the whole stack or heap unless you are using a pathological coding style.
I shouldn't have to make such checks in the first place. Not making a mistake in the first place is preferable to detecting it later on.
Not trying to detect a mistake is a great way to form the impression that you're not making them in the first place.
Having the compiler check your work for mistakes and flagging them up early is better than letting them slide.
Unless you can design your compiler to make a class of mistake impossible, as we were discussing.
DRY is far from being "most fundamental". Much more fundamental and important are keeping modules composable, not mixing things of different abstraction level in the same block of code, avoiding circular dependencies, or avoiding unnecessary dependencies are more fundamental. DRY is just most easily enforcable, that's why it's so popular.
To my mind, this is a corollary of DRY: if you are not repeating yourself, then you are reusing code, which, by definition will have made it composable.
> not mixing things of different abstraction level in the same block of code
Never heard this one, frankly. I happily mix addition (arithmetic, machine-level operation) and, say, Dice Coefficient in the same line of code.
> avoiding circular dependencies
Probably a good principle, but not fundamental: https://en.wikipedia.org/wiki/Meta-circular_evaluator
> avoiding unnecessary dependencies are more fundamental
Avoiding anything that's unnecessary is generally a good idea.
> To my mind, this is a corollary of DRY: if you are not repeating yourself, then you are reusing code, which, by definition will have made it composable.
You don't get composability from DRY, as merely extracting common snippet of code into a function doesn't make magically the function easy to put somewhere else. Just "reusing code" doesn't make it composable. You can reuse body of a car for something different, but it doesn't make it composable, so there's no "by definition".
DRY is just a different thing than composability.
>> not mixing things of different abstraction level in the same block of code
> Never heard this one, frankly. I happily mix addition (arithmetic, machine-level operation) and, say, Dice Coefficient in the same line of code.
It's a practical thing. You don't put opening TCP connection to a database service in the same chunk of code as building SQL query to be sent through the connection.
>> avoiding circular dependencies
> Probably a good principle, but not fundamental
Oh yes it is. If code doesn't adhere to it, it ends up being a tangled, monolitic mess of brittleness. As with every rule, there are cases when it makes sense not to apply it, but this doesn't make it less fundamental than DRY.
For example, instead of having an ORM define a mapping between classes and tables in, say, XML, DRY dictates that the mapping ought to be where it belongs, namely in the class declaration itself.
Ada's repetition is really more about readability. If you see an "end", you always knows what it matches. (Personally, I think it's useless.)
Yours is an arbitrarily narrow interpretation of the principle. To quote Dave Thomas, DRY states that
"Every piece of knowledge in the development of something should have a single representation."
The name of your function or block is one such piece.
I agree that having the compiler check the consistency of the redundant statements ameliorates the situation somewhat, but it would be better if the problem wasn't there at all.
Most people take DRY to mean you shouldn't duplicate code.
That's not its intention. The idea behind DRY is far
grander than that. [...] DRY says that every piece of
system knowledge should have one authoritative,
unambiguous representation
DRY is not "be terse". For example, turning a literal into a constant is DRY, because it reduces to a single "authorative, unambiguous representation". But "x = x + 1" (which certainly looks redundant) is not anti-DRY, nor is "end Foo;".
The author's central argument is "don't give up on a language that's hard because it might have significant, practical advantages." In particular, he argues that Ada might be superior to C because C suffers from segfaults or other memory-related issues that Ada does not suffer from. Because C was initially easier to write, he went with it.
I think this principle — that it is worth sticking with a language despite difficulty in writing it — is flawed. While Ada was both difficult and resolved memory issues, languages like Python graceful avoid memory issues without being difficult to write.
Naturally, language safety is greater than ensuring memory integrity. Haskell ensures memory integrity and type safety and happens to be a hard language. I think that Haskell is a stepping stone. That in the future, languages will be safer, but also easier to write. That we haven't solved this paradox — that a language can be both safe and easy to use — is merely a matter of time. For now, I'll keep writing Python.
Anyway, please don't compare languages like Ada and Python. That's like comparing Forth and Smalltalk or apples with oranges. They have different purposes. Ada compiles to executables that run around as fast as C and C++, and like those languages it's not very suitable for rapid lego-brick type programming. For gluing together existing libraries, languages like Python are awesome but you wouldn't want to write an Operating System in Python.
Abstraction has costs. They can be reduced, but they don't evaporate.
I used to be a big fan of Python, but having used Scala for a few years I wouldn't go back.
What this tells me is that the author gained some insight, but still did not learn his lesson: one of the worst mistakes one can make in programming is learning new languages, just because they are there. Pick at most three languages covering 95-99% of required functionality, then master the living daylights out of them; you'll become seemingly superhuman at programming, writing small, portable code in fraction of the time it will take dingle-dongs out there to do the same thing. Just because you know your tools so well. To be clear: it takes about a decade working in a language every day, eight hours per day, to begin to master it. So that's per language, and I wrote pick three languages. Don't cater to fashion, because there is always some dingle-dong out there thinking he can invent a new language where things can be done easier and better, but that's not true at all.
I think C is an excellent and useful language which doesn't attempt to change the way you program. While one can argue that one shouldn't be able to compile mistakes; the cost of avoiding mistakes often exceeds the cost of amending them. A sort of personal “It's easier to ask for forgiveness than for permission” situation.
I often ponder whether the time I spend debugging C programs is worth it. Each time I conclude that I wouldn't have bothered to write it without C.
I wrote an incremental generational garbage collector in C, and rather regretted the time I spent debugging it. If I wanted it to be at all concurrent, I think I would've given up doing it in C.
Right tool for the right job and all that. But lately I've strongly been preferring Rust, Ada, and ATS for anything I'd use C for.
Turbo Basic, Turbo Pascal, Modula-2 did the job just fine.
Turbo Pascal, Turbo BASIC, and Modula-2 don't have any of the ugly formality of Ada though. I'm not making the point that C and C alone is the only language less frustrating than Ada. I'm saying that for many systems, the comfort and simplicity of C allow you to solve problems which would be too frustrating to solve in Ada.
I find Modula-2 pretty dreamy; it's a shame that it's mostly dead.
object message.
object + arg. "There are very few valid names for these sorts of messages"
object argNameOne: argOne argNameTwo: argTwo.
This is pretty much all of SmallTalk's synax. Yes, really. There's also syntax for local variables, and returning values from method calls, and maybe one or two other things. That's it.
It should also be noted that Smalltalk is inseparable from its IDE and image. GNU Smalltalk tries, but it's not the same. To speak of one is to speak of the other, so I shall speak of both.
Smalltalk code exists entirely within its image, along with all the tools that make up the IDE. It's sort of an OS in and of itself, although you can interact with the native system. The practical upshot is that when you edit smalltalk code, you have all the source code for the entire implementation along for the ride: You can not only query Smalltalk about your own code, you can query it about itself using the same mechanism. You can also edit and debug your app in real time, as it runs. Smalltalk's debugger allows to to inspect every single stack frame, and make changes to your source as necessary. You aren't editing text that will become objects: You are editing objects. And because the entire system state is saved to the image, none of the changes you make to the running code will be lost, unlike most Lisps, where changes you make at the REPL go away as soon as your app shuts down. It's truly unlike anything else you will see.
For example, booleans are an object that can have two values: True and False. There's also two methods on the boolean object, ifTrue: and ifFalse:, and they both take a code block/anonymous function as the only argument. Both True and False override these functions. True's version of ifTrue: calls the code it's passed, and False's version does nothing (and vice-versa for ifFalse:).
For example:
a < b ifTrue: [^'a is less than b'] ifFalse: [^'a is greater than or equal to b']
They're implemented more or less as a standard library package rather than a language construct. You could potentially extend the boolean class with different implementations of ifTrue and ifFalse, maybe reversing the logic or logging the branch taken or whatever. The functionality can be changed dynamically.
I think it's neat when a language eats itself like that.
1980 - Alan Kay creates Smalltalk and invents the term "object oriented."
When asked what that means he replies, "Smalltalk programs are just objects."
When asked what objects are made of he replies, "objects." When asked again he says
"look, it's all objects all the way down. Until you reach turtles."I already write go professionally but sound like in the long term rust will be a better deal...