141–150 of 184 posts
Earlier quoted context omitted.
Well then, so much for it being Computer Science ...
As-is, CS really is much closer to a branch of mathematics than a science.
Earlier quoted context omitted.
It's true, but it's more a treatment then addressing the root cause. Rich Hickey, creator of Clojure has a fun quote that goes something like: "You thought you wanted TDD, but really you wanted an interactive REPL." My gripe with TDD, is that it gets tedious in its own way. Always needing to eventually mock some aspects of the code, and always working in the small, you start feeling distant from the medium and large…
It's a pretty good treatment. I think the solving the root cause would be something like a constant time compiler, which I don't think is going to happen. You don't need to mock at all if you do DI and modularity well in Guice or Spring or something else (it can be the rare exception for a few libraries that use say private constructors). You can also write 3-5 line tests that will absolutely test everything in your…
Ya, I agree, tests are a good treatment, the best for most languages. A good interactive REPL is often better though. Clojure has tests, good IDEs and debuggers. Yet people don't care about them as much, because the REPL solves most problems. In return, it means the IDEs and debuggers aren't as good as Java, because people care less and so also invest less in them, and sometimes I'd want a better IDE or debugger to complement the great REPL experience, but I wouldn't trade the great interactive REPL for them.
Earlier quoted context omitted.
Nowadays I feel that experience with some type system at least as powerful as Haskell's is required to criticize static typing... Well, of course, you can criticize it without such experience, but that only serves to look foolish when you complain about stuff that is solved for a decade. Are you really complaining about lack of generics?
Come back to me when the most used programming languages have a type system like Haskell's. Then we can talk about the benefits of static typing over dynamic typing. Until then, static typing is mostly "expected a HashMap , got a HashMap " or other pedantic stuff like that which is only really meaningful to the compiler.
We never get there if the conversation about types is dominated by people who have only used Java-like type systems. Even ignoring that, demanding that powerful type systems be ubiquitous before discussing their benefits is a complete non sequitur. There's no excuse for ignorance, here.
Earlier quoted context omitted.
TDD can help with this. I more often than not, will write a unit test or functional test first, then work on the code for that test where I'm just running that one test until it succeeds. After I have individual parts working, I will integrate everything, which again will just be another integration test run from the IDE. I realize this isn't always possible, and is probably easier to do in a managed language, but yo…
It's true, but it's more a treatment then addressing the root cause. Rich Hickey, creator of Clojure has a fun quote that goes something like: "You thought you wanted TDD, but really you wanted an interactive REPL." My gripe with TDD, is that it gets tedious in its own way. Always needing to eventually mock some aspects of the code, and always working in the small, you start feeling distant from the medium and large…
I think that the a good workflow is to do initial experiments on a REPL followed, once I get an idea of the code will look, by writing tests and the actual code that will run in production.
Earlier quoted context omitted.
To be fair, in Clojure you have to reach for horrible external hacks like Component and Mount to have a "real" interactive development.
Not really, I often don't need them. They're mostly for being able to reset the full app state back to how it is at startup. You can also just restart the REPL, though some people find waiting 5 second for that too annoying. I wish the restart times were much faster, but its not as big a problem as most people make it sound like. Often time, you can just learn to mold your program in smarter ways, so that you don't g…
That's true only if clojure is your only dependency, in real project with libraries is more like 15 seconds with lein repl, cider is much worse.
Do you have other recommendations for a language that meets these criterias?
Some would say Common Lisp.
Earlier quoted context omitted.
Can you expand on what is meant by algorithms and computing, and what you mean that computers mostly do instead?
The skill of programming is really about translating tasks that are semantically meaningful to humans (ie making a user friendly online booking site for a hotel) into "meaningless" instructions that can be computed by a turing complete machine. That's very different from, say, deriving a faster partition algorithm by using half-swaps instead of full swaps (as demonstrated by Andrei Alexandrescu last year).
Pssst! Hey, buddy, that's what an algorithm is.
Agree whole heartedly! That's why my favorite language is Clojure. That interactivity, instant feedback, seeing the program running as you are tweeking it, its a bliss to use and it creates better more functional software. Imagine playing music as you hear it when trying to come up with a good melody. Now imagine not playing it, but composing it on music sheets instead, and occasionaly playing what you've got every 1…
Well, actually, let's explore the metaphor. Here's how I compose music. First, I use a highly-flexible prototyping instrument to quickly iterate on melodic ideas. Normally this is either humming or whistling. "Our first instrument," as an instructor used to call it. I do this until the melody is catchy enough to start sticking in my mind. Then I'll look at alternate parts, like countermelodies, B/C sections, harmonie…
This language is small enough to write on a single piece of paper
Check, Clojure is one of the most concise language out there. I use it for hand writing code or when coding on my phone, because its so short.
fully contains all of its abstractions
Yup. In fact, you need to change your mindset, you don't write instructions in Clojure, you search for the functions that do what you want and arrange them in the order you need. Think micro-library.
has focused notation for specific instruments
Lisps like Clojure are the kings of DSLs. This is literally their bread and butter.
and permits debugging any part of a program by cutting any contiguous subprogram out and turning that fragment into its own live environment.
Yes, that's what the REPL lets you do. Load any subset of the program into a live running environment.
I'd write a program first on a prototyping platform which is so lightweight that nearly any prototype program will run, and I'd use that to write out the entire first draft of my program.
This is the idea behind dynamic programming which was invented by Lisp. Clojure will run almost any code, correct or not, no question asked. It does not put constrain on you, though it highly suggests the use of safe tools over unsage ones, it lets you cut yourself if you want too.
Then, I'd incrementally move pieces of my program transparently onto a more rigorously-precise framework which is more restrictive about types but makes it easier to compose modules and let them stay composed.
This is my ideal too. There's not yet the golden graal for this, but Clojure is currently focused on this very last part. Composing modules is actually pretty trivial, because it supports performant immutable datastructures as first class, open polymorphism, defaults to functionally pure constructs and wraps all state in safe managed containers.
Now as for correctness checks, it has optional types, but the implementation is a work-in-progress, and is stagnating a bit. Optional generative tests is the current strategy being explored, as well as highly powerful runtime checks. Still in alpha though. Static analysis is also being worked on, though soundness is not a target, also in alpha at this point.
If its any consolation though, the only two studies I could find about defect rates relating to programming language choice showed that Clojure does as well as Hakell. Which means it had some of the lowest defect rates of the languages tested, averaging a tad behind Haskell, and doing better then Scala and F#. Obviously besting Java, C++, Python, Ruby, C#, Go, etc. It was an outlier in that sense, as it was the only non staticly typed check language to do so well.
Earlier quoted context omitted.
Well then, so much for it being Computer Science ...
Since computers are built by people for people, it does seem like we're missing the most important and difficult science in favor of doing the science that's easy to do. It's easy to reason about how a system that I designed will perform. It's hard to answer the questions of how our technology choices affect other people. It would be great if science could help us design high quality systems with a limited budget, or…
That would be sociology or one of its siblings, no?
... or, at best, the piddly "ethics" course that gets tacked on to most undergraduate CS degree programs?
I have happily traded working in a nice language with slow iteration times to working in a lousy language with very, very fast turnaround. My favorite extreme example was the time I used a super fast 6502 assembler environment that would do the "change a line of code and get the target running" cycle in a couple of seconds. This kind of interaction is magical . You're still writing kind of crappy assembly language, b…
> to working in a lousy language with very, very fast turnaround. [...] The PHP "builds" as fast as I can refresh a browser page. This observation ( "workflow" ) was one of the 3 bullet points outlined by Keith Adams' 2013 presentation "Taking PHP Seriously" .[1][2] (KA's presentation was partially a response to 2012 "PHP a Fractal of Bad Design". [3]) Basically, the horrendous inconsistencies and flaws outlined in "…
So I get the benefits of static types, plus the benefits of fast iteration, PLUS the benefits of a fully dynamic language for when I want to accomplish something quickly.
It's a full win-win-win. Throw in linting to avoid the legacy JavaScript crap and it's pretty awesome.
Earlier quoted context omitted.
It's kind of my point: LISP does (mostly) provide instant feedback, but it's not used much in the real world (every big LISP success I've heard of wound up either being translated into a shlub language, or resulted in the teams using it having a really hard time hiring people and scaling).
Ya, I think that's just the familiarity hump. Most people don't get over it, and the few that did geek out too much about the possibility of infinite macros, and how you could extend Lisp, while eventually realising how few made it past the familiarity hump and starting to feel isolated they eventually move to something else. It's hard to break this habit of familiarity, it's self replicating, because the less famili…
Some people (myself included) don't like the aesthetics of Lisp as a language, nor do we like the enforced functional program structure, nor do we like the lack of infix operators. Maybe I "didn't have good enough teachers," but for every other language I've ever learned I didn't need those "good teachers" to achieve a strong level of mastery, and I've learned more than a dozen to a high level of mastery.
After a while you have to stop blaming the people and instead just admit that Lisp isn't as awesome-for-all-purposes as some famous people seem to think it is.