gtrak

It's a question of where to focus your attention. Consider the explore/exploit trade-off. Boring tech may be a little, well, boring, but that means you get to spend your limited decision-making capacity on solving your actual problem. If your actual problem is betting on a niche language early, then go for it! Otherwise, use the thing that balances your existing knowledge, interest, existing 3rd-party resources and has the right outlook over the expected timeline to get your outcome.

I think this site leans pretty niche.

The web has killed desktop apps. I use linux, but I don't buy software on any platform besides games.

I think it makes sense for professional productivity apps, like CAD stuff.

I don't think basic desktop apps are worth a fee, since no one will buy them with all the free alternatives, but maybe a case can be made with something that ties into managed cloud compute services (like superhuman's use of AI).

The easy and dangerous way is to mount your entire hard drive inside virtualbox. Follow instructions here: https://www.virtualbox.org/manual/ch09.html#rawdisk

The issue occurs when you for example accidentally boot windows within windows, you can possibly get file corruption.

The workaround is to configure a virtual disk with only the partition you need plus a bootloader that can load it up. I haven't gotten that far.

EDIT: It seems there is an article about how to do this: http://lifehacker.com/how-to-dual-boot-and-virtualize-the-sa...

There is an alternative that I have found quite useful.

Create a Dualboot situation for normal linux work but set up a VM in your windows host that points to your bootloader and linux partition.

Now you have the best of both worlds, more memory and speed when you want it with native boot, but access to the dev environment from windows.

This was most effective in the case where a client required proprietary windows-only VPN software, but I wanted my dev environment. Configuring a vpn'd bridge adapter between Virtualbox+linux-guest and Windows host was a piece of cake.

Just a hunch, LLVM uses Static-Single-Assignment, which is just that, saving every single variable change.

I'm not sure what you mean.

Lines of code is an objective measure. How meaningful that might actually be, well, that's subjective.

I know neither.

I'd skip Objective-C and learn Swift to actually make a thing.

If you want general language knowledge, a really hairy production language and toolset isn't the place to look. You'll be fighting with lots of incidental stuff along the way.

Learning different kinds of languages will help you learn more languages.

There are objective measures. There aren't necessarily 'absolute' ones.

Lisp is relatively more concise than C or Java for the same tasks.

Java is relatively safer than C for the same tasks.

Every new dev machine should have an SSD.

It's under $1/GB

I really like this comment. But I bet some folks gloss over a particular point of importance.

For me, there's a huge advantage in literally using tree-paper, either for code-reading, designing, taking notes, what have you.

It involves more of your senses, it's more tangible, every letter is written with more care and the medium is incredibly flexible (maybe I feel like drawing a circle on a whim, can't do that in emacs.)

It's better for scratch-pads than a text-buffer, imo.

Insights come more consistently and easily after iteratively marking up a printout. It's just fully-intuitive.

Very strange to have a programmer culture that is afraid of thinking about performance.

It's treated like a hobgoblin.

Better stacktraces would be better, sure, but there are good arguments on both sides whether it's better to separate the language from the platform or not.

I prefer a thin, readable compiler and core library over such abstractions. I don't mind the stacktraces, but I could see how some people might.

The fact that clojure is host-centric makes clojure and clojurescript compelling to java or javascript programmers at the expense of some aesthetics, and it also has performance implications.

the practical difference between lists and seqs is laziness (details like chunking, too).

This is somewhat irrational critique, clojure was an opportunity to start fresh and graft a concurrency-focused lisp onto a pervasive runtime, not to reimplement ABCL. It fills a need.

I was always somewhat halfway interested in learning common lisp, but when clojure came along I actually got excited enough to do something about it.

You even say you're 'very happy' to be working in it, but I think 'an experiment in STM' is too reductionist and shallow to address the numerous use-cases that are improved by persistent data structures and the other features that clojure provides.

Maybe I'm a bit of a masochist, but it's not that hard to read the compiled output, especially when you have a decent mental model of what it should be. It doesn't look like idiomatic javascript, but the structure is pretty regular.

Here's an example for the kids at home.

compiled: https://github.com/gtrak/node-cljs-template/blob/master/src/...

from: https://github.com/gtrak/node-cljs-template/blob/master/src-...

What makes the right level of abstraction right? Seems like the units of abstraction have to be amenable to application (analogy), but rightness is fluid. If you have a turing machine, it might make more sense to write a JS compiler first because of the familiarity and perceived difficulty of translating your thoughts, but that's a statistical process of your own head. If you're a fresh mind, you would never create a JS compiler. The aggregated feedback of our social consciousness over time is what sets the 'rightness' of any approach by modulating the difficulty and expressiveness of each concept to each individual.

My interpretation: javascript is slowly catching up to the rest of the world. It's reach both makes it a lingua franca and slows it down. Maybe one day it will be suitable for real programming, if people who complain after 10 minutes would stop holding it back.

People prefer this incremental series of hacks to the existential despair of being faced with a cohesive system, say a lisp machine. :-)

I think at least the criticism of immutability and FP resulted from taking concepts to extremes. I made a point to address lock-in of different aspects of clojure in my post.

I think if you're mutating deeply nested things, or doing heavy algorithmic bookkeeping, it's worthwhile to evaluate different approaches (maybe pure java) as an 80/20 thing, and I wonder how hard it would be to have comparable mutability facilities and data structures as a library?

Of course, programmers want to get things done without spending time on building up their own tools, and I understand that.

there were changes to the core data structures in order to support reducers, namely the addition of polymorphic reduction by the collection. See: https://github.com/clojure/clojure/commit/5b281880571573c591...

It was a pretty transparent change.

FWIW, I agree, I would love to see an expert talk about real tradeoffs, both abstractly and in regards to clojure. I'm just kinda piecing it together from what I think Rich was thinking, what I've picked up from JoC, blogs, talks, and experience.

Yes, having to understand the details and implications of clojure's compilation was definitely painful, but the implementing code is accessible. There's always going to be some performance bottlenecks, I guess I'm more concerned with how hard are they to identify and overcome than they might have been having coded stuff up in pure java from the start? Or, once you're committed to a design, say refs and STM, and you hit such a problem, is it difficult to change course?

Yes, you're right. Tradeoffs was more of a theme than a commitment to being comprehensive. I guess I meant to portray design tradeoffs and their implications, and sort of what perceptions I have about them. It wasn't meant to speculate about what could have happened if different choices were made, or where I feel I'm missing out, or even to be super-objective. The main message was that the interaction of the design tradeoffs guides our subjective aesthetics, and those subjective inclinations result in our programs. Plus, I just wanted to compress the case for clojure for different people, in terms of clojure's design tradeoffs and their implications.

even with productive languages, there is such a thing as 'idiomatic'.. (I say to myself as I munge some legacy clojure)... I still prefer to work on old clojure code than new java code after a year and a half with it, even java written by 'experts'.

Real people have jobs writing clojure. I can't speak for Rust.

Macros will eventually be in core JS, see:

http://disnetdev.com/blog/2012/10/14/hygienic-macros-for-jav...

and http://brendaneich.github.com/Strange-Loop-2012/#/40 http://www.infoq.com/presentations/State-JavaScript

yes and no. Yes, because the example is a novel language feature in other languages that would be very difficult to implement. No, because these sorts of things are easy only when code is data, like lists, which is a design property of lisps, but not really captured within 'list processing'. I think perhaps there could exist a language that says it's good at lists and data without the macro system that makes this possible.

I think the counter-argument is this:

We have control over the amount of real reasoning we can do about our code. The hassle of the real can be minimized. For example, I like clojure, and there are real benefits to theoretical things like immutability by default, or garbage collection. This ability to reason mathematically while being practical is worth promoting in computer science and engineering. If I couldn't reason this way about programming, I wouldn't be a programmer. Engineering is the intersection from theory to practice, and I appreciate that in computing, incidental complexity can usually be traced back to someone's neglect. Without this, we only have heuristics.

There is no silver bullet, but things can be made measurably better. We can accept reality without giving up on reason. I think to prove it, we can look at the influence of mathematics on real discoveries in history, and maybe ponder if humans are just meant to think this way in order to make progress. I hope my code reflects more order (purity, generality, conciseness) than chaos (special cases, entropy, technical debt).

I would just call the procs thing a 'wart' and avoid using it. I don't think my opinion favors the mathematically inclined programmers over the empiricists.

So, let's think about the kinds of things that get done as a consequence of certain types of thinking.

Tradeoffs.

The real world is crappy, and we're depending on these academic types to free us from the drollness of it, because we don't all have time to invent an STM. If I wanted to write CRUD apps all day and say that's real-world, I suppose I could, but I would rather enjoy enlightenment.

Function invocation overhead, you say? Why would I want that?

How about Garbage Collection? It'll never work.

It's their responsibility to create foundational research, and it's ours to filter through it and prove the good bits with fire.

'Practical' is a red-herring, I think. We have no way to predict the future, but we all care about progress.

AOT already means something to clojurists. It means removing the extra runtime compilation phase of .clj into classfiles. The JIT is what the JVM does, which still occurs just like before.