Hacker Newsnew | comments | show | ask | jobs | submit | login

> Essentially, it seems like another "wouldn't it be nice if everything were written in $LANG, even the OS?".

In all honesty, I'm not sure you read the article. The entire point is the idea to deploy tiny chunks of code, independently, in any language.

reply


> The entire point is the idea to deploy tiny chunks of code, independently, in any language.

What does "tiny chunk of code" mean? According to the article:

> Literally, a simple interface that did one (or very few) things well.

Hmm, sounds like the UNIX philosophy to me. Operating on code in a language-agnostic way? Sounds like scripting to me...

> What if instead you could deploy classes.

Classes are a language feature, so this looks to be asking for an alternative scripting language.

> What if your operating system was in a way an API to deploy services (it is!) > but the size of the code deployed was so small that it would in turn be hard > to make mistakes.

That's the point of UNIX: do one thing and do it well; compose the pieces using scripts.

Of course, UNIX is not perfect, it's just an obvious comparison. I mentioned a few others above. That's what I got from the article, after squinting through the jargon ("deploy" instead of execute, "services" instead of processes, etc.)

reply


All hardware companies I've seen on the inside are like this. Philips, FEI, Cisco, ASML, Océ. Somehow, when software isn't the only part that matters, people stick their heads in the sand and pretend like the 1980's never ended. I've given up trying to figure out why or change it.

It's the only reason I only do web stuff now. I like both domains, but the hardware / embedded software industries are just retarded.

reply


Longtime embedded engineer here:

There is a reason they are "retarded" (BTW, please don't use that word). It comes down to the following:

1) Embedded engineers are generally EE that have taken a course or two in software. Generally they are the "best software guys" from a group of middling to poor software guys. As such, they reach for tools they are familiar with.

2) The product from embedded engineering is much different from web development. It might ship on a ROM, for a part with < 64kRAM. In circumstances such as this, knowing your toolchain won't add any complexities you don't understand is very important, and it doesn't get much simpler than C. (Also, most good embedded engineers use a restricted set of C that doesn't include things like printf and malloc.)

reply


> BTW, please don't use that word

Good point. I won't anymore.

Your experience matches with mine (especially point 1). It's a sad state of affairs, really.

Wrt point two, true, but these days there's a vanishingly small number of problems that can only be solved cost-efficiently on microcontrollers and C.

My favourite example is ASML, world market leader in chip machines, which sell at millions of dollars a piece and could be specced to have any computing power needed, effectively, and has a software stack of 30 million lines of C.

Running on microcontrollers and Sun Solaris computers.

reply


I think it has more to do with the first point. That's the culture, and culture tends to perpetuate itself, especially if it's a big corp where people stick around way longer than in startups, and it's a much bigger burden to switch tools.

reply


[flagged]

Surely "toolchain" is not a joke in this context.

Basically it is "compiler and friends". For example: http://en.m.wikipedia.org/wiki/GNU_toolchain

reply


I used to work at Cisco, and I have the exact same opinions.

reply


Cool:

    erlang:unique_integer([monotonic])
I wish this was a more common API function. Being able to do ordering without having to think about time and concurrency is really nice (I know x86 has an interlocked increment that you could just use on an arbitrary global variable, but that means that you're not safe across crashes).

reply


This is elixir, but can be called from erlang: https://github.com/nirvana/flaky/

It gives a unique value from any node in a cluster of nodes running this-- without any coordination-- such that you can guarantee they are sortable in order of creation. (to a small increment of fungibility-- two flakes created on different nodes in the same millisecond might be out of order, but they will be unique and in order with any flakes created in other milliseconds.)

reply


> Isn't the way it mixes in HTML, CSS classes and JS altogether something we were trying to get away from a few years ago?

That's a best practice for web sites. If you're making a website (where every page has roughly the same look and structure, but just different content), then it's probably a good best practice to have.

It all went haywire, however, when using the web for applications. While well-designed applications also have commonalities to them (button styles, margins, etc), the various screens and dialogs in an application vary way more in structure than the various pages on a typical informational web site tend to do.

It turns out that separating logic and presentation in web applications the way you would on web sites is a very bad match. You simply end up putting logic that is very closely tied together in three different places. E.g. typical jQuery code that falls apart the moment you change either the HTML (turn a div into a span, whatever), or the css class names, or the jquery selector/handler code, all of which is located in different files deep in a different directory hierarchy. For each single widget in your app (button, dropdown, LoginScreen, etc), it's much better to put all that code together.

And that's what React lets you do.

(note that this means that you really do want to tie your styles closely to your react components too - either inside the JS or with e.g. one .sass file for each React component)

reply


> It turns out that separating logic and presentation in web applications the way you would on web sites is a very bad match. You simply end up putting logic that is very closely tied together in three different places.

As a web developer for the past 10 years I can't disagree with this more. It wasn't the easiest thing to accomplish maybe 5 years ago but it was always doable and now with web components it's incredibly easy.

React is cool but I wouldn't call separating logic and presentation bad. I would call that a best practice.

reply


Web Components does what React essentially does, bring them together.

reply


As with all technologies it matters how they are used; I simply stated web components make the separation easier than ever before but that doesn't mean the same can't be done with JSX.

I think it's very important to keep the interface away from the logic. Creating components in React that only drive the user interface isn't bad but it's not as straightforward as something native like dealing directly html and css. I've worked with many designers who are awesome at styling and making pages look great but when they have to edit any type of scripting or something outside of HTML / CSS it's a whole new skill-set they need to learn to be effective (a skill-set they don't really need that the majority do not have).

reply


Some components turn out to need logic though - consider some of the Twitter Bootstrap components that rely on JavaScript. They would not work without the JS.

I do agree that there are concerns when it comes to having people edit certain aspects if they specialize, I have seen similar things in the past. I would say that this depends on the people you work with.

reply


> Some components turn out to need logic though

Depends on what we're referring to when we talk about logic. I consider the user anything the user directly interacts with while with the logic I was mostly referring to business logic. It's fine to have interactive pieces that need JavaScript as long as they're kept away from the business logic.

My rule of thumb is: the user interface and the business logic should be separated to the point where you can completely replace the business logic without touching the user interface and vice versa. That's the separations I strive for and it's incredibly helpful when a designer wants to completely rearrange everything about the user interface because only one area needs changing.

reply


I agree with this. I also think it that keeping logic out of views is a good idea, but I think that like many one-liners, there is more to it than just that.

I think that there is a certain amount of logic that is necessary in our views. Otherwise, JavaScript would not exist. Manipulating the DOM via the vanilla API or via jQuery is only hiding that logic in another file. The logic is still there, and calling it "separate" is not useful, in my opinion.

I like the way React bundles this view-specific logic and the markup together. Now I don't have to look at some HTML and wonder if some JavaScript somewhere is messing with it.

CSS is another matter entirely. CSS doesn't change behavior and is another concern entirely, so I do still prefer it to live in its own files rather than being inline. React doesn't change anything about this, and that is fine by me.

reply


I wouldn't call separating logic and presentation bad. I would call that a best practice.

Even if that is true, it is not clear that trying to separate HTML, CSS and JS necessarily achieves a useful degree of separation between logic and presentation.

In "traditional" application development, we have long recognised that things like keeping the underlying data isolated from any particular presentation or interaction style can have advantages. However, you wouldn't find a lot of people arguing for creating a dialog box in some visual design tool in your IDE, writing separate code in a programming language to populate its controls and respond to interactions with them, and then somehow trying to join the dialog and the code up while keeping everything at arm's length.

Modular design has always been about keeping related aspects of a program together and minimising other dependencies. This means you can do useful things like changing one part of a program without running into surprising or uncontrolled side effects elsewhere. But if you have different aspects of the application that inherently do change together, as is often the case with HTML/CSS/JS in a web app, there is little benefit to trying to separate them for dogmatic reasons.

reply


> Even if that is true, it is not clear that trying to separate HTML, CSS and JS necessarily achieves a useful degree of separation between logic and presentation.

I agree and this is why I continued to iterate OP's word usage of separating logic and presentation. Separation of HTML, CSS and JavaScript isn't always useful or straight forward but separating business logic from the user interface is incredibly important, in my opinion.

Separation of HTML, CSS and JavaScript is more of an organizational thing in my mind. JSX makes the syntax awkward and more complex in my opinion especially when you're working with a group of designers who are constantly tweaking styles, element layouts, etc. But for a team of only developers it's not so bad. Still I personally find it easier to simply avoid JSX either way.

reply


Separation of HTML, CSS and JavaScript isn't always useful or straight forward but separating business logic from the user interface is incredibly important, in my opinion.

I agree, but if we're talking about using a front-end framework like React here, wouldn't that mean we're only talking about the UI parts of the application anyway?

Personally I'm not a big fan of either big frameworks generally or some details of React in particular, but the people behind React do make reasonable arguments in favour of their more component-based separation of concerns.

reply


> I agree, but if we're talking about using a front-end framework like React here, wouldn't that mean we're only talking about the UI parts of the application anyway?

I don't think so; when working on code for a web application there is always code, styling and html elements that deal ONLY with the presentation side of it but then there is also code that handles talking to the backend, negotiating with web sockets, etc. That code really needs to be separated and what I'm referring to.

> the people behind React do make reasonable arguments in favour of their more component-based separation of concerns.

I love component based separations and I get the feeling many of us are talking about similar things.

reply


I don't think so; when working on code for a web application there is always code, styling and html elements that deal ONLY with the presentation side of it but then there is also code that handles talking to the backend, negotiating with web sockets, etc. That code really needs to be separated and what I'm referring to.

Right, but React isn't normally used for things like back-end comms. It's often loosely described as being for the "V" in "MVC", which makes sense given the whole declarative specification of DOM content angle and the one-way data binding style.

reply


Is the distinction between web sites and web apps really valid, though? No matter how dynamic your site is, you still have certain responsibilities to your users, including giving them the best user experience you can, but also things like accessibility, sane SEO, bookmarkable resources, and, in the long run, maintainability. Is a highly dynamic site really a "get out of jail free card" for best practices?

reply


> Is a highly dynamic site really a "get out of jail free card" for best practices?

No, of course not. React proposes to replace one "best practice" by a different one. In React, the best practice is to divide your application up in a deep hierarchy of components, each of which adds one single little layer of abstraction over the other. Then, put all the logic and presentation that's relevant for that little piece of abstraction together inside that little component.

This way, you have very good separation of concerns - all "Button" stuff is together in the Button component, all AreYouSureDialog stuff is together in the AreYouSureDialog component (which in turn uses Button components), and so on. Because components can only interact with each other via props and refs, you also have very fine-grained control over the interface: it's difficult for the programmer of a parent component to influence the behavior of the child component any further than by the interfaces that the child component explicitly exposes for that (= props, and public methods for use via refs).

How is all that a "get out of jail free card"?

I've found that this design principle works very well with teams, even with junior team members. I've seen people who had never gotten further than building 10000-line CSS files with all kinds of horrible hacks let loose in a React project. After we explained the component principle and made an example component to easily copy&paste, they independently and without further encouragement started making React components for each little possibly-reusable part of the application. Buttons, frames, dialogs, cards, lists, you name it. React really makes it easy to make well-structured code and difficult to make things a mess.

I don't see how and of this impacts any of the responsibilities you mention (good UX, accessibility, etc) so I can't respond to that part of your comment.

reply


it's difficult for the programmer of a parent component to influence the behavior of the child component

You seem to focus only on the few drawbacks of CSS inheritance and to ignore its biggest advantages like you don't have to write declaration for every and each element on the page and rely instead on inheritance for props to cascade properly.

Yeah sometimes undesired consequences occur on elements but it's easy to remedy the situation if you know what are you doing but by moving all the presentation info to your logic layer in development, and then littering the structure/content layer i.e. HTML via style attribute in run time, this is unacceptables and can't be seen as progress for the industry in any way.

reply


> You seem to focus only on the few drawbacks of CSS inheritance and to ignore its biggest advantages like you don't have to write declaration for every and each element on the page and rely instead on inheritance for props to cascade properly.

This presentation explains what problems React inline CSS solves. https://speakerdeck.com/vjeux/react-css-in-js

EDIT: I gave wrong presentation link initially.

reply


This presentation explains what problems React inline CSS solves

Could you please summarize in a few sentences what are these probs this approach deem to solve?

Because I have seen demos and talks from React people and I was appalled at their neglect of best practices and bending the rules just to push their product and technologies on the community

reply


My main complaint with CSS in JS is that a strict naming convention solves a lot of the problems without coupling styles in application bundles. Basically, I don't want to invalidate my JS bundle just to include a new visual theme.

Luckily, you can use CSS best practices with React.

The problems mentioned in the presentation, followed by some CSS-friendly solutions --

1) Global namespace: all selectors are global

Use a naming convention.

2) Dependencies: no way to specify that a block of markup depends on a particular CSS module

Use a build process and a naming convention that includes a component name.

3) Dead code elimination: difficult to determine when styles are no longer needed

Loop over components and extract CSS component names from class attributes.

4) Minification: can't minify class names in markup

Not a bottleneck, nobody cares.

5) Sharing constants: can't share constants/variables with javascript

Use rework/postcss.

6) Non-deterministic resolution: loading styles asynchronously can result in different results since specificity assumes later rules should override earlier rules and async load order is arbitrary

Use SUIT CSS to prevent collisions and normalize specificity.

7) Isolation: base component CSS can be trashed by authors of subcomponents, making it difficult to change base CSS.

Reduce responsibilities of base component CSS. Encourage use of modifier classes. Ban tag selectors from component CSS. Use a SUIT CSS compliance checker.

I use SUIT CSS with React and couldn't be happier.

reply


Seriously, all these points sound very fancy and I suspect that they bring unequivocal productivity gain to the dev environment but my main beef with FB or any other org is that they push this workflow or other methodologies as universal best practices or even distort reality and claim that mixing content/presentation/logic is the only right way to "separation of concerns" and all what you knew before about this topic is a hoax and big lie.

reply


Why are you looking at this as "bending the rules" instead of as creating new rules for a new way of building web applications? Just hand-waving "best practices" doesn't actually mean that something is best practices if someone else comes up with a better practice.

reply


You guys have to convince us first that mixing content+structure/presentation/logic is the best way to go forward in web development for the following reasons 1,2,3 ..etc.

I'm all for progress and challenging/questioning previous norms or traditions. I hate dogma and dogmatic people like the next guy but I need first to see improvement in the new thing before going adopting it.

What I see now frankly is the opposite of progress. I see people advocating for dispensing of "separation pf concerns" & "progressive enhancement" in the name of "progress" and "modernization" but in reality it's just a lame excuse to regress to a state of affairs that we guys fought too hard to combat it and bring awareness to the community of its pitfalls and shortcomings.

reply


>You guys have to convince us first that mixing content+structure/presentation/logic is the best way to go forward in web development for the following reasons 1,2,3 ..etc.

There are a million articles and talks that provide exactly this. If you don't find them convincing that's fine, but don't act like no one is providing them.

> I see people advocating for dispensing of "separation pf concerns" & "progressive enhancement" in the name of "progress" and "modernization"

If that's what you see then you're looking in some weird places. The drivers behind React aren't just vague ideas like "modernization", they're the real-world benefits people are seeing when developing and using these new ideas. You're doing a disservice to everyone by fabricating the reasons behind these ideas just because you don't like them.

>in reality it's just a lame excuse to regress to a state of affairs that we guys fought too hard to combat it

This really just seems like a stodgy "get off my lawn, kids!" approach, which is at odds with your "I hate dogma" statements. Do you honestly believe that people are pushing in this direction solely as an excuse to regress things and make it worse? Even if you think that it is "regressing" things, you can't possibly be so conservative and entrenched as to actually believe that is people's goal, can you?

reply


There are a million articles and talks that provide exactly this. If you don't find them convincing that's fine, but don't act like no one is providing them.

If you have been asked what's the most important convincing reason to switch to React, what would be your answer?

Please no mention of web apps vs web docs. We're already established that.

- It has been all about progress and modernization all the time. Progress in terms of productivity gains and speed was the motivation behind dropping jQuery centered architecture and going for an MVC framework instead and it's what's motivating the spawning of these frameworks as well. I don't know why this point is contentious one for you.

Do you honestly believe that people are pushing in this direction solely as an excuse to regress things and make it worse?

I didn't say that and I don't believe that they're intentionally pushing in this way to harm the industry and the community but I do believe that , while in the midst of chasing the latest trendy object, they won't realize that they're giving up very valuable stuff that benefited the industry for a long time.

reply


You are already doing that in a normal template. Let us say you are building a shopping cart.

The template will contain logic like an iteration over what has currently been put in the basket. And maybe some condition that if the basket is empty you should show a friendly string instead. Then you have some additional logic in a js file that will collapse the list of items if the user does not want to see everything. This is usually done by using a id/class or html element to grab on to.

The idea behind React is that you put all possible states and ways the view can render in a component. You still would (generally) not have actual logic in it; like grabbing data from the server or calculating stuff.

It is different yes but I think it is a neat idea. We will have to see if it is a viable path forward but I think this "rethinking best practices" is really good and has already influenced the rest of the frameworks quite a lot.

reply


The main difference is that the logic in template files is the guest here while the markup is the host. We're used to include presentation info in <style> tags and code in <script> tags. So, it is not really a great deal of change to include template language within our content even though I still prefer logic-less or minimal logic template languages over full blown ones to avoid turning web pages into a whole mess.

But the problem with React is they are not being honest with marketing their technology. They claim that their approach to blending everything together as "separation of concerns " and some of their evangelists had even the nerve to claim that their approach is the only true way to best practices and that we have been doing it wrong all this time. So, it turned from product evangelism to pure propaganda for them.

If they were forthcoming about it from the get go "Hey guys, we know that violates SoC but you guys we'll make up in terms of productivity gains and speed what you will give up in maintenance and readability" but instead they keep pushing their propaganda and people seem to eat it up.

reply


It is still mixing presentation with logic if you use a template file. So why do you think it is alright to violate SoC in that case?

They have been very detailed with what you get with React and their first presentation was even called "Rethinking best practices".

It does not violate separation of concerns. For me it is the opposite and you actually have real separation of concerns instead of separation of technologies. And even if my project is pretty young it feels like it will be easier to maintain.

How often don't you have DOM manipulation (hiding or showing a div) in the same Javascript file as some actual logic. How is that separated concerns?

reply


It is still mixing presentation with logic if you use a template file. So why do you think it is alright to violate SoC in that case?

I am not puritan or dogmatic. That's what I have been trying to convey here. I'm pragmatic to the core but I am no propagandist.

If I was asked if template languages violate SoC, I would not hesitate to reply "SURE" but I'm keeping to a minimum and I'm using logic-less flavors instead.

But reinterpreting SoC as SoT and trying to evade admitting that you guys at fault is not really something to commend you on. Too much revisionism and propaganda for my taste.

reply


I think you're reading too much into it. I see it as a new way of working with new tools that Facebook has found to be better for them. We can try the new tools and see if it works better for us.

reply


I'm curious, which demos and talks are you referring to?

reply


One of those done at the latest ReactJS Conf where they introduced React Native. Check their channel on YT for the info.

reply


Accessibility, SEO and bookmarkable resources aren't always a requirement. The GMail app (as opposed to the login page) for example doesn't need SEO. If you're targeting a known specific audience then you don't necessarily have to focus on accessibility. Bookmarkable resourecs doesn't always make sense either, for example if you're making a web based image editor (although I suppose you could create bookmarks into each images editing history or something if you're doing non-destructive editing) . Maintainability is of course important, but I've yet to see a convincing argument that one approach gives a priori better maintainability.

reply


As a low vision computer user that supports disabled people on the web, and whose father spent 30 years working with disabled people, I can tell you for a fact that for some people, accessibility should be a requirement all the time.

Especially as more things go toward the web.

The disabled is a club anyone here can join, at any time.

reply


Using the GP's example, it would take a huge amount of effort to make an online image editor accessible to the blind. I'm not sure that would be time well spent.

All the GP is saying is that the trade-offs will depend on your audience.

reply


Building and application doesn't automatically mean discarding accessibility, SEO or sane URLs. Modern JS-frameworks like React handle them quite easily.

reply


Yes, it is valid. To quote Tantek:

  >  if it’s not curlable, it’s not on the web.
http://tantek.com/2015/069/t1/js-dr-javascript-required-dead

reply


The reason I usually prefer to separate script and markup is that it makes the logic easier to test and those tests less brittle when the markup changes. Not having had any experience with react, I was wondering what the accepted approach to testing is?

reply


React can run without a real DOM attached.

One common way is to have React render into a simulated DOM (e.g. https://github.com/tmpvar/jsdom) and then trigger event handlers with code. You make assertions over the structure of the rendered DOM to know whether things went fine, all without a browser attached.

A dumber way that works remarkably OK too for simpler scenarios is to just have React render stuff to HTML strings and do regexes over those strings. Hacky, and if you're doing serious app development you probably don't want this, but it's a very easy way to get started.

reply


What about desktop/mobile applications - is it ok to mix your logic and presentation there?

reply


This is a great question. The little iOS development that I've done it seems like the script and style are tied together with the markup.

I think about how painful it would be adding a custom button(new behavior) to a notification on a website: you either add an event listener to the dom and listen for it to bubble or add it to the button directly(the easier option). These new web frameworks seem to be adding it directly to the dom node -- we're back to <a onClick="function('value')"> which is faster, but traditionally harder to manage. But since everything is a structured component (all of these things implement an interface) we can build them faster and worry about it on the component level and not the markup level.

I've been playing with React and Riot and it is a very interesting approach. You can build things out a lot faster than you used to and that is what matters in the end. The user will not care if you separate concerns (as long as the page renders and is accessible, but that is another story).

reply


Not familiar with react and barely JavaScript, but why is <a onClick="function('value')"> bad? I mean as longs as the function calls a function on another module and doesn't contain any more logic than that. The other module remains testable, and the only logic in the UI is a function call. If the interface of the module changes, sure the UI would have to change, but I tend to think people over think things at this point (my opinion and I hope it doesn't distract from my original question).

reply


As far as I'm concerned <a onClick="function('value')"> was bad because 'function' was a global variable reference.

I don't think that's the case for React though so I'm not sure if the GP saw some other drawbacks in it (apart from the aesthetic of separating logic from presentation.)

reply


In React, you would do <a onClick={this.props.foo('value')}> (for example) - JSX would interpolate that and set up the appropriate click binding, and the function is local to the component.

reply


My experience with iOS development is that you just have to hack things together in whatever way works. Frequently you'll get a screen 70% of the way there with slick but inflexible visual editor, then need to copy and paste a bunch of imperative methods to modify things further at runtime. All of this separation of concerns stuff is a bit lofty for iOS.

reply


Oh come on, the author was like 19 when he wrote it. Of course it's a little entitled and ranty :)

reply


This article can be summarized by "I implemented shouldComponentUpdate and stopped mutating my data to make that easy". It's a good write up of what is otherwise standard Reactjs practice, but it really doesn't warrant all the 4000% nonsense. "How I used shouldComponentUpdate to make React rendering faster" would've been a more obvious title.

reply


Wow. That looks like a dream come true. (if only it worked on my computer)

I guess a Windows or Linux version is never going to happen? I'd love to be able to run this.

reply


Unfortunately, it's very unlikely. I'm a Mac developer and that's why Monodraw is written for OS X (in Obj-C).

I'm a supporter of all platforms but I do not have any cross-platform desktop GUI skills.

reply


Windows or Linux people who want to do ASCII art should do it in DOSBOX with THEDRAW: http://www.syaross.org/thedraw/

reply


Did you read the article at all? It's hardly even comparable.

reply


I'm confused; how is this not comparable? It's creating a pixmap directly from strings. I'm not saying this project is bad or uncool, I'm just saying this isn't a completely new idea.

reply


The ASCIImage rendering code described in the post we're discussing is actually resolution independent vector graphics. You can draw neatly pixel aligned stuff with it, as is shown in the screenshots, but it's vector graphics.

reply


I'm not saying the author didn't make something far more advanced or cool; but the beginning of the article makes it seem like ey thinks ey is the first to ever come up with such an idea, which is false. I was never trying to say that the project is a knock-off.

reply


Exactly. The core concept here is defining images for icons in the code itself, rather than loading them from external resources. XPM was one early way of doing that, allowing you to define bitmapped images in a static array of characters representing the pixel colours, and was a very neat hack. Now this extends and improves the idea, allowing you to define images for icons in your code, using an array of characters to represent the lines in an image, and define a vector graphic. It's definitely in the same conceptual space, although there doesn't seem to have been any direct inspiration from the earlier format. Both are very cool ideas...

reply


Fair enough. I certainly did not mean to pretend anything like this.

reply


I'm not American and I have a question. Everybody in this thread repeats to "never talk to law enforcement without your lawyer present". I don't have a lawyer. I don't know a lawyer. I've hardly ever even talked to a lawyer. If I were in the USA and I'd get picked up for questioning, I wouldn't know who to call.

Does every American "have a lawyer"? Do you know their phone number by heart? Is having a lawyer like having a health insurance, in that you could do without but it'd be pretty stupid? Isn't that a suffocating thought? How do you deal with it?

reply


No, I think that most Americans don't have a lawyer on call.

The typical advice I have heard is to do a little research on lawyers in your city, and have a phone number of a reputable lawyer (or a few) in your wallet in case of a potentially severe legal situation. When you call them and establish a relationship where you are paying for their services they become "your lawyer".

(this is not advice, I'm not a lawyer, etc)

reply


> (this is not advice, I'm not a lawyer, etc)

Related: will people sue you if you don't include that disclaimer?

reply


IANAL, but I believe that in this case the disclaimer is just a courtesy. That is, before one makes a life-altering decision, one should consult a real attorney, not just us morons on HN.

reply


If you don't include it when discussing any vaguely law-related matter, Internet Tough Guys will be quick to call you out for "practicing law without a license". [1]

[1] https://news.ycombinator.com/item?id=9088475

reply


If you are a lawyer, you need to make clear that something you say isn't "legal advice" because you can otherwise be held accountable for it.

I think the "IANAL" disclaimer is just a step beyond that so non-lawyers can't be mistaken for acting as lawyers giving out legal advice (not sure what liabilities that would entail).

reply


The disclaimer is just a way to say "this is a complex subject; things might be different in your situation; get real legal advice". A lawyer would use something "I am not your lawyer" or "I am not a lawyer in your jurisdiction".

reply


If you give legal advice while not qualified then yes. Same as if you e.g. sell food without having the relevant hygiene certification.

Would anyone treat a random internet comment as legal advice? Hopefully not.

reply


No, most people I know don't have an actual lawyer they know already. "don't talk without your lawyer" means to get a lawyer representing you before you talk. It isn't meant to imply that you must have one to begin with.

reply


So how do you google for an appropriate lawyer when in custody and you only get one phone call? Not cynical, I really wonder. I guess the exact same problem exists where I live (the Netherlands).

reply


https://www.popehat.com/2011/05/27/how-to-cold-call-a-lawyer...

reply


"So — you have a name. Either it's the name of someone who has been recommended to you, and they are expecting your call, or it's someone who was on the first page of Google results for +oh +shit +need +lawyer +Pismo Beach +dwarf +public +indecency +hedge-clippers or something.

What do you need to do?"

Ah, PopeHat.

reply


There's no "gotcha" where you have to find a lawyer under certain constraints or they get to question you without one.

You have the right to legal counsel. That means they have to let you do what you need to do to find a lawyer, or provide you with one. They can't just say, "sorry, time's up, now we go question you anyway." They could in theory detain you for a while longer without a lawyer, but they couldn't continue to question you.

reply


In the Netherlands, you don't 'get one phone call'. You have (since very recently, and only in some cases) the right to talk to 'a' lawyer before you are questioned. Hence, either the police provides you with one if you don't know who you'd like, or the questioning has to wait until your lawyer is present (bar some limits like withing x time, I don't know the procedural rules by heart - how things are actually applied also varies by area).

So if it takes 3 phone calls, so be it.

reply


The whole "you get exactly one phone call" is largely a movie trope used for dramatic effect. The exact number of phone calls you get is very much dependent on where you got arrested, what you got arrested for and even the mood of the person in charge. But basically you'll generally be allowed to (eventually) make the number of calls necessary to either get a hold of your lawyer or get a hold of someone who can find and call a lawyer for you.

reply


http://tvtropes.org/pmwiki/pmwiki.php/Main/OnePhoneCall

http://skeptics.stackexchange.com/questions/2274/you-have-th...

reply


In Germany, in many cities and towns, local attorney associations provide emergency phone numbers. The provide free legal advice on the phone and provide you with a free attorney for the duration emergency (e.g. while a search warrant is executed).

Intrestingly, I just noticed that I have the number stored in my cell phone (since before I had a smart phone). That may not be the smartest way to do it.

reply


Another German here. I have legal insurance. Comes with a card for your wallet listing a 24 hrs hotline that puts you in touch with a lawyer (for free) within seconds.

I've actually made use of it several times to get a professional opinion on difficult situations.

reply


I would imagine they have duty lawyers on call or Public Defenders or something.

reply


I believe every single EU country will have public lawyers that you can talk to while arrested. It might take a few hours to get one summoned,but you definitely can. Obviously this is not an option when you are being interviewed by the police on the street.

reply


The "don't talk to the police without a lawyer" thing is a meme that is pretty overblown. It doesn't hold for stuff like getting a minor speeding ticket, being a witness to a crime that clearly you aren't involved in, the cop just talking to see whats up (when you aren't otherwise committing crimes).

You really need a lawyer:

When the cops are interrogating you

When you are a suspect or it looks like you may be one. If your wife winds up dead, you are a suspect. If money at work goes missing and you had access, you are a suspect. But if you just happen to see a random kid get hit my a car, you can talk to the police without a lawyer.

When you actually committed a crime.

Or if you are were involved in some accident, dispute, whatever and there might be a lawsuit.

But, IMO, if you try to lawyer up at a traffic stop (when you aren't committing real crimes), when a cop asks how you are doing in a park, or when you are clearly a third party witness; then you'll probably just cause yourself more grief by asking for the lawyer.

Lawyers are expensive, you make yourself suspicious, and you might cause the cops to detain you longer.

reply


If you ask for a lawyer and don't have one, (I THINK) they're obligated to either get you one (public defenders are free) or wait for your lawyer to arrive before interrogating you. You can refuse to answer police questions, and theoretically nothing bad happens to you (though they get to keep holding you until the lawyer arrives).

reply


most American's have no lawyer to call. the expression "don't talk to police without your lawyer present" should be extrapolated to mean all of the following:

if the police want to question you, say no. if the police serve you with a warrant and detain you for questioning, exercise your 5th amendment right (the right to remain silent, so as to avoid self-incrimination). the only thing you should say to a police officer when you are being questioned is that you will not answer any questions until you have consulted legal council. if you do not have legal council available you may request a public defender (another legal right of citizens). if you have the means to hire a private attorney instead, its probably better to do that. only a lawyer who is professionally obligated to represent you can give you good legal advice about what you should and should not say to the police.

reply


Wow the "old news" idea blows me away. I really, really want that.

reply


You would probably really enjoy Delayed Gratification. It's a quarterly publication that wraps up global news day by day from 6 to 3 months prior (e.g. the March issue covers Oct/Nov/Dec). They have a great mix of short and long form articles and I think a reasonable balance for world news.

http://www.slow-journalism.com/

reply


I use http://www.reddit.com/r/worldnews/top/?sort=top&t=month for that. Most news are ~20 days old. I check it about once or twice a month.

reply

More

Guidelines | FAQ | Support | API | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact

Search: