Hacker News new | past | comments | ask | show | jobs | submit login

> What comes after programming languages?

I've been working on this for several years, though a startup seems the wrong vehicle for it. I think the description in the RFS is misguided:

"We’re interested in helping developers create better software, faster. This includes new ways to write, understand, and collaborate on code, and the next generation of tools and infrastructure for delivering software continuously and reliably."

There's a blind spot in prose like this that gets repeated all over the place in our community: it emphasizes writing over reading. I think we have to start with reading. My hypothesis is that we need to reform the representation of programs to address this use case: I download the sources for a tool I use, wanting to make a tweak. How can I orient myself and make a quick change in just one afternoon? This is hard today; it can take weeks or months to figure out the global organization of a codebase.

You can't "deliver software continuously and reliably" until you rethink its underpinnings. Before the delivery problem there's a literacy problem: we programmers prefer to write our own, or to wrap abstraction layers over the code of others, rather than first understanding what has come before.

More on my approach: http://akkartik.name/about




We already have the tools to deliver software continuously and reliably. They are called containers and virtual machines. The problem as usual is not with the technology. If you look back we had SmallTalk virtual machines some time ago that you could pause, ship over the network, and pick up where you left off.

Reading is not the issue as well because most code is terrible and it doesn't matter how easy you make it to read the code I'm still going to waste my time reading it. So I'd say that the problem again lies elsewhere. Few people have the aesthetic sense to write elegant code. It doesn't matter how many tools and abstractions you throw at the problem there are still going to be people writing terrible code.

Writing and reading code or doing anything else with it is in many ways like art. It is also like science and craft and a bunch of other things that require creativity. Even with the accessibility of paints and all the accompanying technology we still don't have the likes of Michaelangelo and Picasso being any more prevalent than they were around the time those guys were alive. Literature is another good example. We teach everyone to read and write but it doesn't matter how much money or technology you throw at it (ebooks, libraries, etc.) we still don't have any more great writers than we did a century ago.

This is not a technology problem. It is a culture and human problem for which you are not likely to find a technical solution.


Totally agree. My 2 additional cents.

Most reasonably skilled programmers can read code. They choose not to. Cultural problem not technical one.

I've been in the industry a long time and the best codebases I've seen had a handful of things in common:

* They were written by highly competent programmers who all had an interest in doing a good job. * The code was neat, well-document, and sensibly structured based on agreed upon standards. * The programmers writing them weren't forced to inject changes faster than they could compensate for them.

That's it. Most of the disasters in industry are the result of extrinsic demands. People not caring or people. People documenting nothing. People under extreme deadline pressure hammering in something that then has massive, long-term design ripple effects on the rest of the codebase. Do this several dozen times and you're almost certain to produce a disaster and some point.

Therefore, most software problems have to do with people in over their heads or making changes haphazardly to meet deadlines. These cultural issues seem largely to stem from people thinking that writing software is a deterministic process - it isn't, and has more in common with chaotic systems than linear deterministic systems. Hell, I've written virtually the exact same piece of software twice at one company and each time produced both identical bugs and completely new bugs.

We would probably benefit more from understanding what software actually is and educating people about that than attempt to technologize away our problematic understanding of technology.</screed>


> most code is terrible... Few people have the aesthetic sense to write elegant code...

Elegant code does not necessarily mean readily understandable code (or "readable" code). For example, some Haskell programmers like writing extremely elegant code -- so elegant that you can base a whole new (elegant) branch of mathematics on it -- yet it is no more readable than, say, many early BASIC programs.

But why pick on Haskell? I've never seen Microsoft Word's code, but let's imagine it were the paragon of OOP design. Then, I'd like to add a feature similar to the spellchecker, that tests whether consecutive sentences rhyme. Now, I could probably find the spell-checking code rather easily, only to learn that it is attached to the main program via the most beautifully intricate plugin system -- with lifecycle management, runtime loading and unloading and whatnot -- that it takes me a few days only to learn that bit.

The point is that software is complicated, and very non-standardized. Code readability rests only in part on its structure, and a lot on how many "advanced" language features are used, the number of libraries used and their familiarity. You'll probably find "terrible" code that uses a couple of popular, mature libraries, that you're familiar with, much easier to understand than the most "elegant" polyglot codebase (written in both Python and Haskell, because, you know, the best tools were picked for each job) that makes use of 10 of the newest, shiniest libraries you've read a lot about on HN and always wanted to learn but never had the time to.


I didn't say we need to teach people to write elegant code. See my examples at http://akkartik.name/post/tracing-tests. I take this perverse joy in coming up with ugly code that is suited to its surroundings, and I'm extremely well-suited for programming because when it comes to code our aesthetics are like George Costanza's instincts (http://en.wikipedia.org/wiki/The_Opposite).

I want programming to be like reading, with most people able to skim most article-length pieces of prose -- even if it's poorly written -- and get a sense for its global organization. That doesn't require teaching everyone to write like Shakespeare.


Good luck. I'm still not going to read terrible code no matter how easy it is. It took me a while to come to this realization but aesthetically unpleasant code is indicative of the author's abilities and without elevating the level of all programmers I don't see how making code easier to read is going to make much difference. Some tooling might make it easier/faster to come to the conclusion that some piece of software is not worth investing more time in but with enough experience that judgement is not hard to make. Note that LibreSSL was a fork and rewrite of OpenSSL. Even if it was easier to navigate OpenSSL it still would have been the correct decision to scrap large swaths of it because it was horrendous code, easy to read or not.


Thanks for the luck. We might be in violent agreement or disagreement depending on what code you consider aesthetically pleasant. Everyone can agree on the crap, but can you share examples of code that you liked that might help me triangulate on your aesthetics. Alternatively, I'd be interested to hear if my published projects are pleasant or not. To help you triangulate on mine: http://akkartik.name/post/readable-bad.

To reiterate, you're responding to things I didn't say. Code shouldn't have to be perfectly designed to be readable, and nobody should have to wade through utter crap either. Very often code starts out nice when it has one author or three, and gradually turns to crap as more cooks are added. I want to eliminate that dependency on author churn, to have it be beautiful or ugly based on the capabilities of the programmers involved, not on the difficulty they had understanding those who came before. To make progress on this project, I find it most valuable to utterly ignore aesthetics.


I don't think we are agreeing or disagreeing. I do want tools that make it easier to navigate and understand code and I also want cultural shifts in programmer communities that lead to better software overall. I'm just saying the communal aspect is more important than any given programmer's ability to navigate code but the two are obviously intertwined in complicated ways.

That article you linked to (http://alistair.cockburn.us/ASD+book+extract%3A+%22Naur,+Ehn...) connects the dots really well. Programming is really about building theories and then implementing them with computational building blocks and then transferring the understanding of those theories. Short of developing mind reading I think there is an irreducible complexity in that endeavor that is impossible to skirt around.

In light of that article I'd like to amend my comment about aesthetically pleasant code. Some programmers are good at structuring things so that the overarching theory is present throughout all code level structures. That kind of code is both aesthetically pleasant and easy to read. I don't know if this is some kind of special talent of if it can be learned but given that most software is a confused mess I'm willing to bet there is a large talent component.


Yeah, he may well be right and I might be totally barking up the wrong tree. But that just seems so depressing I can't help but tilt at this particular windmill. The hope is that his theory will become obsolete if the activity of programming changes radically enough.

I started out thinking you couldn't solve social problems with technical solutions. Now I think social problems arise in the context of configurations of technical energy barriers. Making something easier can make good behavior more or less likely to arise. So it behooves technologists to think hard about what they make easier. But this is getting abstract, and I need to show examples of what I'm trying, what I'm keeping and what I'm discarding. If you send me an email I'll show you what I have.


>>It took me a while to come to this realization but aesthetically unpleasant code is indicative of the author's abilities

Not necessarily. It can also be indicative of the circumstances in which the code was written. Even great programmers can write terrible code if they are stressed out or overworked. So you can't just look at the code they have written and jump to conclusions about their programming ability.


Yes times 1,000!

This is what we're trying to address at Sourcegraph (https://sourcegraph.com/). 80% of programming is about reading and understanding code, not writing code.

Why don't existing tools focus more on helping people read and understand code--and, more broadly, collaborate on a development team? Things like:

* seeing everywhere a function or class is used, in context (like https://sourcegraph.com/github.com/joyent/node/.CommonJSPack... on the right side)

* seeing who at your company knows the most about an area of your codebase

* seeing the history of changes, in terms of functions/modules added, not just lines (like https://sourcegraph.com/github.com/fsouza/go-dockerclient/.c...)

* having a long-lived discussion about a module/class/function that doesn't vanish after a commit is merged or the file's lines shift around

So far, most of the innovation in programming tools has been in editors or frameworks, not in collaboration and search tools for programmers.

While there are great editors and frameworks, the lopsidedness is unfortunate because making it easier for programmers to learn and reuse existing code and techniques, and to collaborate on projects, can have a much bigger impact than those other kinds of tools. That's because, in my experience, the limiting factors on a solo developer's productivity are the editors and frameworks she uses, but the limiting factor on a development team's productivity is communication (misunderstanding how to use things, reinventing the wheel, creating conflicting systems, not syncing release timelines, etc.).


FWIW, I think this is absolutely fucking genius and everyone should check it out...

...but I can't give you money without Java/Scala support. Roadmap? Pleeeeease? =)


Do the JetBrains IDEs support this?

Find All Usages and Jump To Definitions are the reason I spend 400 EUR on Resharper licenses, it makes reading code so much easier..


Yes please! Also, I didn't see bitbucket support; hopefully you folks are working towards that?


Yes, we are working on better Bitbucket support (on par with our GitHub integration). You can follow or +1 the thread at https://github.com/sourcegraph/sourcegraph.com/issues/213 so you get updates.


The site doesn't seem to list which languages are supported.


Currently it's Python, Go, Ruby, and JavaScript (node.js only; not client-side yet). Java is coming soon. It does say it on the homepage and the docs page. Where were you looking? We'll make it clearer.


Brooks addresses this:

Perhaps the biggest gain yet to be realized in the programming environment is the use of integrated database systems to keep track of the myriads of details that must be recalled accurately by the individual programmer and kept current in a group of collaborators on a single system.

Surely this work is worthwhile, and surely it will bear some fruit in both productivity and reliability. But by its very nature, the return from now on must be marginal.

Tools will not solve the essential difficulties of software engineering.


Thank you for the initial posting, so much true. Brook's comment is a bit old and there usually evolve things to adress issues: His integrated database system is: The web, (project-)wikis, issue tracking, version control, (discussion&help-)forums, the code and comments in code. Anyways, it's true: Reading code often is a nightmare... but at least for me also because of over-abstraction/complication (done by IT guys/colleagues) and misdevelopments/trends/hypes (mainly done by the IT industry).


I have similar needs to understand complex code base such as 5-20gb of Android platform code, so I wrote an webapp/site for that:

It lets you cross reference and document any language with gigabytes of code, e.g. Android platform code. Jelly bean ~9 gb of code.

Try it out: http://www.srcmap.org/s/sl.htm/p=android-4.2.2_r1

Sample Documents created from that app are here:

http://www.srcmap.org/p/1/4af293f91271/Android_Init_startup_...

http://www.srcmap.org/p/1/80c16319d25e/Docker.html

http://www.srcmap.org/p/6/4a88339ceef3/mtpd_source_code_stud...

http://www.srcmap.org/p/1/212c9a285186/Google_IO_2014____sch...

The ux is ok. A few gigabytes of code db running in a cheapest $5 instance of Digital Ocean.

The app is very simple ~8 mb of standalone binary, no external dependency do any other app/db.


What does the yc folks/alum think? Good enough to get into yc?


Who are you selling it to / what's your plan to grow any part of the biz?


For now, free for individual developers to help validate and get tractions, like to see if i can entice free higher level license with exchange for contents/sharings, Doesn't seem to be working.

I like to sell it as team/site license for large dev team in the future. The traction doesn't seem to be there yet.

Because my burn rate is < $150 per year, I have ~1500 users / month come to the site from pure google search alone.

I am just slowly experiment with different features/msg/channels.


Very cool! This needs Java support and integration with IntelliJ IDEA.


This is a great point. I am always struck by how there are so many times where, if I could sit down with the original program author for 5 - 10 minutes, I could understand more from that interactive back-and-forth than several hours of reading code in solitude.

This tells me it's not that understanding how that code works is intellectually difficult; rather it's discovering how it works is time-consuming.

It would be amazing if you could "interact" with the code about its structure and intent the same way you might interact with its author.


As it happens, I've been working on something like that. Still pretty half-baked, but send me an email and I'll show you what I have. Email in profile.

"There are so many times where, if I could sit down with the original program author for 5 - 10 minutes, I could understand more from that interactive back-and-forth than several hours of reading code in solitude."

Peter Naur wrote a paper in 1985 where he conjectured that this seemed to be a universal law. No matter how much documentation authors provided, new programmers still needed to talk to them. http://alistair.cockburn.us/ASD+book+extract%3A+%22Naur,+Ehn...


Would love to. Email sent.


Could it also be that the structure and intent of the code is ambiguous even to the author? I often feel this way when reading code, and also writing code or explaining it to others....


I always thought it would be cool to record audio the whole time the editor is open, and the programmer would just talk the whole time about his thought process. Then the audio would be broken up and indexed with the source code.

So you could choose to hear what the author was saying right when he was working on a certain area of the code. (You'd normally turn it off, but if you're really stuck it might be a good last resort.)


I do this with a notebook. When I'm coding I always jot down notes and thoughts. As long as you can remember the date when something was coded, you can see what I was thinking while writing it.

Has helped me figure out what the hell I'm doing many a time.


It also doesn't help that very few projects bother documenting for developers. I believe some traditional UML tactics and other documentation could often not only help with on boarding developers but also lead to a realization of just how convoluted the structure is currently.


That has got to be one of the most awesome mission statements I've read in a long time. Clear, directed, actionable, all good things.

FWIW I think you are exactly right, it made me sad that Google expected people to be 'useless' for anywhere from 6 to 9 months of their early employment as they tried to get their head around the code base and tools. Having the ability to eliminate that spin up time would probably triple their productivity numbers.


With any improvement in programming language technology, we narrow the disparity between human and computer representations of logic. In it's simplest form, this is the premise of language designers.

The biggest difficulty with current languages is their reliance on absolute determinacy. Programmers must express in exact form what computations ought be performs, and the languages possesses no intelligence in themselves. I think this needs to change. Inference should have applications outside type declaration, and the vast knowledge base that is the Internet should be taken into account.

At this point, there are two promising pursuits that I've seen. First is Wolfram Language, which you've all heard of. The other is Escher, which enables "programming in analogies". It's on early stages right now, but I'd encourage you to check it out at https://github.com/gocircuit/escher.


The problem with analogy-based programming is the lack of determinacy. There are no guarantees when it comes to abstract, knowledge-based inference. And so many concepts in modern programming would have to be abandoned to make this shift. Unit tests, for instance, would lost value dramatically.

In the end, an analogy-based approach seems inevitable though, especially once natural language-based inexact. grow popular. Everyday speech is littered with ambiguities, and programming "languages" need to handle these. They can't throw compilation errors upon each inexact command.


I'm not as confident as you, but yes I've been watching Escher development for some time.


Declarative approaches (like answer set programming, or satisfiability modulo theories) revolve around expressing what the final result should look like, with no regard for how the result is achieved.


I'm also surprised at this one.

The software fulfillment process has a lot of issues.

We are stuck in a local maxima and jumping the chasm to the next maxima with ideas like "what comes after programming languages" is really really hard.

Sadly, one of the biggest hurdles is self preservation because software developers don't want "software development accessible to the widest part of our society". I hate to say it, but there are Luddites among us.

So, I tend to agree that a startup is the wrong vehicle for this.

> I think we have to start with reading.

I agree with this point. People understand things differently. There should be multiple ways for people to read and understand software programs. Unfortunately, there is only one major way now and that is with source code.

I do think that tools like IFTTT are moving us towards more accessibility but it is a small step.

I like what you are working. Keep the conversation going.


> Sadly, one of the biggest hurdles is self preservation because software developers don't want "software development accessible to the widest part of our society". I hate to say it, but there are Luddites among us.

It's a strange form of Luddism that seeks to limit opportunities to integrate the existing skills of the labor force into the structure of production. We don't have much in the way of unions or guilds, so perhaps the only effective way to restrict the labor supply is to keep the tools user-unfriendly.


I think you're correct in that what you're working on comes before what comes after programming languages†; you're working on the penultimate paradigm. Being able to trace, visualize, give context to and zoom in and out of the relationships of code would be a significant multiplier in the way it will allow accelerated understanding of novel and forgotten code. The value of this can't be overstated. In key ways, which the smalltalk people are very diligent in making sure no one forgets, we've gone backwards in this area.

But are you sure the RFS actually disagrees with you? What you're working on covers 2/3 of what the RFS deems worth focusing on. Collaboration and understanding.

†I think it's clear what comes after programming languages. A return to their roots. Programming a computer today is like moving by telling every single muscle what to do. To make writing code easier we want to be able to do more with less, to have the code figure out from context what the best thing to do is. We want more intelligence in our compilers. It is telling how powerful the notion of AI is when so many world changing ideas (functional programming, OOP, search, Databases [influence goes: prolog -> datalog -> SQL]) are compromises, failed attempt and detritus of AI projects.


I think you're absolutely right. But the penultimate step is worth highlighting separately, the way the right lemma can render a proof obvious. Especially given how difficult a proposition this penultimate step is. It's like saying you want a better algorithm for multiplication when you use roman numerals.

So I'll stand by my statement that the RFS's phrasing is -- not wrong, but rather -- misguided as stated. Or maybe "misleading" would be better, but that carries connotations of malice.


I’ve seen a good example of this recently. Nipype [1] produces network visualization of neuroimaging processing code[2]. They still look like a gnarled nest, but, for other neuroimaging people, they’re a lot easier to read then the actual code.

1 http://nipy.sourceforge.net/nipype/ 2 http://nipy.org/nipype/0.4.1/_images/graphviz-01bb1b88b33f7c...


Absolutely, and this problem is so profound because it's become part of the platforms we are supposed to deliver stable products on.

Software engineering won't exist as a profession until it really is turtles all the way down, and not a pig on a fish on a tiger etc.


> a pig on a fish on a tiger etc.

Is this a reference to something, or should I point here if I want to reference this idea?


Emphasis on reading. In my experience writing good code or effecient writing/debugging of code only came after: 1. Learning to read the project code i.e. understanding idioms, structures, execution paths, project syntax+language 2. Learning to extrapolate i.e. anticipating answers or making good guesses for inevitable questions during code writing. Questions like where/when should I do this or where/when is this info I need actually available

Both those things literally only came after reading so much code! No shortcuts from the Dev environment (idea, docs) aside from navigation and search!


I am the founder a developer tools startup and I've thought a lot about the future of programming. To be honest, the developer tools market is extremely competitive ("everything must be free") and it is not for the faint of heart. That said, if anyone wants to chat sometime in the Bay Area about future dev tools and/or startups around them, I'd be happy to meet. (contact info at https://wukix.com/contact)


Hi Wes! I enjoyed your talk on Mocl at the Bay Area Lisp meetup last year.


Thanks! I hope there is another BALisp meetup soon. The recent Parallac thing was cool, although it clearly needed more Lisp :)


There are some interesting ideas that could help with reading and writing programs:

from Bret Victor:

http://worrydream.com/LearnableProgramming/

and intentional programming from Charles Simonyi:

http://en.wikipedia.org/wiki/Intentional_programming

https://www.youtube.com/watch?v=tSnnfUj1XCQ


The first article is a great read.


I'm pretty sure that our assumption that programming languages will look like programming languages in the future is sort of like the assumption that phones will always have buttons on them.

Once Apple and other companies showed what the world looks like when a phone is a giant touch screen + giant battery, phones with buttons become a niche, not the norm.

I don't know what the programming paradigm is that completely changes that, but I do know that I haven't seen it yet and everything we've done so far seems to completely miss the mark.

Someone is going to come along with some other radical assumption about what designing/implementing software really is about.

I know that it is not about static vs dynamic, functional vs. imperative, etc. like we've traditionally thought. Maybe it will be more like using Excel or Gmail. Maybe it will be more like flowcharts, or maybe just like sketching out a structure and the machine knows how to wire it together for you. Maybe humans won't be involved at all.

Speculation is endless, but nobody has had the iPhone unveil of new programming paradigms yet.


Speaking from personal experience, the thought: "Take away languages. Now what do I use instead?" can be paralyzing.

I'll suggest an alternative approach that might stimulate your neurons. Look back at the ways that your life is improved reading code today compared to twenty years ago. When I look back, the highlights for me are:

a) version control, and

b) automated tests

Forget all their benefits to the people writing code. For me, the guy with one afternoon to make a tweak to an alien codebase, it has been invaluable to have not just the current snapshot of a codebase but a story of its evolution so that I can see what the skeleton of the program used to look like in a simpler time, and gradually play enhancements forward atop it[1]. It has also been invaluable to be in situations where I can go, hmm why do I need _, why don't I just rewrite it as _, try it, and find a failing test with an enlightening name.

What's common to these two ideas is that they are additive. You don't have to give up programming languages. You just need new ways to share information between programmers besides just the code that runs "in production". My current favorite candidate for the next augmentation for codebases is logs. More info: http://akkartik.name/post/tracing-tests. If that whets your appetite feel free to get in touch. My email is in my profile.

[1] More details of how this helps: http://akkartik.name/post/wart-layers


I agree on readability as a prime area for improvement. Thats one of the things I tried to tackle in Obvious (http://retromocha.com/obvious/) but readability is a human/social/communication problem.

Programming as it is now is a 2 way communication mechanism, we are writing code for other humans to understand, but for a machine to translate into what we intend for the machine to execute.

So, your point of making code a better human to human communication mechanism is absolutely correct.

What I really wonder about is what set of tools could exist that could solve whole sets of low level problems that we are specifying now that we shouldn't. Sort of like, right now we have blueprints and so on, and then humans look at those and build a house. Yet, with 3-D printed houses, you feed a set of materials and specifications into a machine, and you get a house built for you.

What is the programming equivalent that would allow us to "3-D print" software, so to speak? For physical things, it seems to be the combination of 3-D CAD systems, 3-D printers, and maybe some thought about how things need to be designed to fit this approach.

I have no idea exactly, but I could see a future where instead of paying people to hand craft all the code, that a series of features, modules, structure, etc. are specified, and the software is just "built". There would be more effort in the specification, but less on the build.


I remember programming a Lego robot with this visual puzzle piece method as a kid. It was awesome. I have a feeling something similar already exists for general purpose programming. I can definitely see something visual-based that hides a lot of unnecessary details working for a lot of basic applications - at least to get the skeleton of an MVP up.


My guess is that one thing that future software will have is automatic generation of user interfaces.

I think "naked objects" or "apache isis" are the best examples we've got for that for now , but they are rooted in somewhat complex java code, instead of being rooted in an easy to use tool, such that lets the business analyst who had some course , sit with the client and fully define a running system , step by step. In some cases the auto-generated UI would be good as it is , and the system will be used as-is.

In other cases , we might need easy tools to customize the UI.


The assumption that UI design must be done by hand is probably one of the most important "bottleneck" in software development.

When you think about it, the job of a designer is often quite systematic. You have some entities/data you need to communicate to the user, through whatever interface/device that's available to him. A touchscreen, a keyboard, knobs, LEDs, microphone, speaker, paper, etc.

When your "user" is a computer, JSON (while not perfect) seems to do the job as an interface. In the case of humans, JSON does a poor job at efficiently communicating information.

For humans:

- A calendar is better than "2012-11-05"

- A color is better than "#FF3300"

- An image is better than "http://example.com/image.png"

- A clickable link is better than "http://example.com/document.html"

The list goes on. We can easily generate a basic UI based on complex entities, and map specific types to custom/reusable templates if needed.

Now that your UI can automatically be generated from data, you can build an app (business model) once, and make it usable (and actually look and feel good/native) on any device. A smartwatch, a smartphone, a smarttv, etc.

Basically, the core of software development should be knowledge representation. Describe the world semantically (with RDF or similar technologies), and let the UI-compiler generate a UI for any given target platform, language, culture, user preferences. That's what responsive design should be all about.


What you're saying is reasonable, and there are lots of people attempting to make RAD systems. Unfortunately, they always place severe limitations on the kind of software that can be created with them, and hence none of them have become particularly popular.

It seems that there's something missing from all the existing implementations of your suggestion. Perhaps it is that the UI and data flow primitives that we have aren't flexible enough to express a lot of business models, thus requiring custom implementations.


Delphi, Visual Basic, FoxPro and Access were all extremely popular RAD tools exactly because they made creating a certain class of systems extremely easy.


I had the misfortune of using Visual FoxPro once upon a time. It was horrifyingly bad, but perhaps by that time (2002-2004) it was suffering serious impedance mismatch with the rest of technology which had moved on. Anyway, I wouldn't call it a good example :)

Regardless, that was kind of my point - all these systems are only good as long as you stay within their constraints. The unfortunate thing is that the constraints always end up being way too tight in practice.


I saw apache is as mention.it nearly the same what i doing now.consider as code block-From database column can create application.Upon combobox figure come foreign key value.The reason i do this,client keep playing what if scenario form like this is this suppose to validate or not?Why code block instead of user define validation.They will some part wanted to customize triple field combobox filter.It cannot be done via user define column based rule.


I just started a new job and have hopped into the first codebase I'll need to work with that I didn't write from scratch myself. I've just been pining for a way to browse through this code as easily as documents in a web browser. Maybe that's the wrong paradigm, but man, there's got to be a better way to read code that lends itself to understanding what's going on. Even though my IDE can "find usages" and I can set breakpoints and step through things, the breakpoints get hit so fast that it's hard to internalize things before hitting "play" again. But stopping for too long breaks the real-time nature of the system. Which I guess is too many words which essentially mean, "I've recently felt this pain, and I agree."


I recently had that experience as well... felt that the code was pretty terrible but didn't want to say anything as the new guy. Toiled at patching it for a month and a half before sitting down and having a talk with some of the more senior developers about my issues. Turns out that I kind of vocalized what a lot of people had been thinking and we rewrote it in less than half the number of lines in about 3 weeks. Not sure what the moral is here, other than that some code is bad.


I've really enjoyed your writing on your blog at http://akkartik.name which I found through your guests posts at Ribbonfarm. Have you been writing anywhere else about your work or thoughts about readable programs?


Thanks! No new projects/demos/prototypes yet beyond the links at the bottom of http://akkartik.name/about, but I have a half-baked project in the works. Let's chat more offline; I sent you an email.


I feel very strongly about this and have very crude ideas about what I want (e.g., expressed here: https://news.ycombinator.com/item?id=8283025).

Would love to get in touch with you.


That comments sounds earily close to what is shown in this video http://www.infoq.com/presentations/tools-language-workbench. It's all working and I think the eclipse website is already hosting most of it.


Thanks for this, exactly what I wanted to see. It has dragged my thinking forward by miles. I should invest time in MPS, embeddr etc.


Yes, I have opinions on this approach. In its favor, Charles Simonyi's working on it: http://en.wikipedia.org/wiki/Intentional_programming. But let's discuss it over email. Mine is in my profile.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: